Kernel ops bei 2.6.8
- Voyager_MP
- Beiträge: 628
- Registriert: 22.06.2004 10:04:07
- Wohnort: Aachen
Kernel ops bei 2.6.8
Hi, das kommt wenn ich versucht mit mplayer eine avi datei per nfs zu starten.
Kann da einer was mit anfangen, gleiche .config in kernel 2.6.7 macht überhaupt keine probleme.
Aug 14 20:34:57 mp kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000014
Aug 14 20:34:57 mp kernel: printing eip:
Aug 14 20:34:57 mp kernel: e1850cbe
Aug 14 20:34:57 mp kernel: *pde = 00000000
Aug 14 20:34:57 mp kernel: Oops: 0002 [#5]
Aug 14 20:34:57 mp kernel: PREEMPT
Aug 14 20:34:57 mp kernel: Modules linked in: nfs lockd sunrpc snd_pcm_oss vmnet vmmon snd_mixer_oss ndiswrapper nvidia nls_iso8859_1 nls _cp437 hangcheck_timer cpufreq_powersave acpi freq_table sd_mod sg ov511 snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd _mpu401_uart snd_rawmidi snd_seq_device snd pl2303 usbserial 8250_pci ehci_hcd usbkbd irport irtty_sir sir_dev 8250 serial_core nvram cpu id yenta_socket raw1394 ide_scsi sbp2 usbvideo videodev usbmouse
Aug 14 20:34:57 mp kernel: CPU: 0
Aug 14 20:34:57 mp kernel: EIP: 0060:[<e1850cbe>] Tainted: P
Aug 14 20:34:57 mp kernel: EFLAGS: 00210246 (2.6.
Aug 14 20:34:57 mp kernel: EIP is at nfs_request_init+0x1e/0x30 [nfs]
Aug 14 20:34:57 mp kernel: eax: 00000000 ebx: db91da00 ecx: 00000000 edx: c15eb5c0
Aug 14 20:34:57 mp kernel: esi: c12e80c0 edi: db91da00 ebp: df4d4000 esp: df4d5bf0
Aug 14 20:34:57 mp kernel: ds: 007b es: 007b ss: 0068
Aug 14 20:34:57 mp kernel: Process mplayer (pid: 17754, threadinfo=df4d4000 task=d3644170)
Aug 14 20:34:57 mp kernel: Stack: d2336a3c c92891c0 db91da00 e184f141 db91da00 c92891c0 c15eb5c0 00000000
Aug 14 20:34:57 mp kernel: 00000001 00000004 00000002 c12e80c0 00001000 d2336a3c 00000000 e1851dc4
Aug 14 20:34:57 mp kernel: c92891c0 d2336a3c c12e80c0 00000000 00001000 00000000 df4d5ce8 c12e80d8
Aug 14 20:34:57 mp kernel: Call Trace:
Aug 14 20:34:57 mp kernel: [<e184f141>] nfs_create_request+0xb1/0xf0 [nfs]
Aug 14 20:34:57 mp kernel: [<e1851dc4>] readpage_async_filler+0x94/0x150 [nfs]
Aug 14 20:34:57 mp kernel: [<c013e159>] read_cache_pages+0xc9/0x150
Aug 14 20:34:57 mp kernel: [<e1851ee3>] nfs_readpages+0x63/0xe0 [nfs]
Aug 14 20:34:57 mp kernel: [<e1851d30>] readpage_async_filler+0x0/0x150 [nfs]
Aug 14 20:34:57 mp kernel: [<c013e318>] read_pages+0x138/0x150
Aug 14 20:34:57 mp kernel: [<c013b650>] __alloc_pages+0x310/0x370
Aug 14 20:34:57 mp kernel: [<c013e632>] do_page_cache_readahead+0x102/0x1a0
Aug 14 20:34:57 mp kernel: [<c013e7dd>] page_cache_readahead+0x10d/0x210
Aug 14 20:34:57 mp kernel: [<c0137475>] do_generic_mapping_read+0xf5/0x4c0
Aug 14 20:34:57 mp kernel: [<c0137b3b>] __generic_file_aio_read+0x20b/0x240
Aug 14 20:34:57 mp kernel: [<c0137840>] file_read_actor+0x0/0xf0
Aug 14 20:34:57 mp kernel: [<c0137bcb>] generic_file_aio_read+0x5b/0x80
Aug 14 20:34:57 mp kernel: [<e184ad58>] nfs_file_read+0xa8/0xf0 [nfs]
Aug 14 20:34:57 mp kernel: [<c0154580>] do_sync_read+0x80/0xb0
Aug 14 20:34:57 mp kernel: [<c0147d43>] vma_merge+0x153/0x1d0
Aug 14 20:34:57 mp kernel: [<c0148470>] do_mmap_pgoff+0x5b0/0x6e0
Aug 14 20:34:57 mp kernel: [<c0154668>] vfs_read+0xb8/0x130
Aug 14 20:34:57 mp kernel: [<c0154911>] sys_read+0x51/0x80
Aug 14 20:34:57 mp kernel: [<c010513b>] syscall_call+0x7/0xb
Aug 14 20:34:57 mp kernel: Code: ff 40 14 89 43 18 8b 5c 24 08 83 c4 0c c3 8d 74 26 00 8b 4c
Kann da einer was mit anfangen, gleiche .config in kernel 2.6.7 macht überhaupt keine probleme.
Aug 14 20:34:57 mp kernel: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000014
Aug 14 20:34:57 mp kernel: printing eip:
Aug 14 20:34:57 mp kernel: e1850cbe
Aug 14 20:34:57 mp kernel: *pde = 00000000
Aug 14 20:34:57 mp kernel: Oops: 0002 [#5]
Aug 14 20:34:57 mp kernel: PREEMPT
Aug 14 20:34:57 mp kernel: Modules linked in: nfs lockd sunrpc snd_pcm_oss vmnet vmmon snd_mixer_oss ndiswrapper nvidia nls_iso8859_1 nls _cp437 hangcheck_timer cpufreq_powersave acpi freq_table sd_mod sg ov511 snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd _mpu401_uart snd_rawmidi snd_seq_device snd pl2303 usbserial 8250_pci ehci_hcd usbkbd irport irtty_sir sir_dev 8250 serial_core nvram cpu id yenta_socket raw1394 ide_scsi sbp2 usbvideo videodev usbmouse
Aug 14 20:34:57 mp kernel: CPU: 0
Aug 14 20:34:57 mp kernel: EIP: 0060:[<e1850cbe>] Tainted: P
Aug 14 20:34:57 mp kernel: EFLAGS: 00210246 (2.6.
Aug 14 20:34:57 mp kernel: EIP is at nfs_request_init+0x1e/0x30 [nfs]
Aug 14 20:34:57 mp kernel: eax: 00000000 ebx: db91da00 ecx: 00000000 edx: c15eb5c0
Aug 14 20:34:57 mp kernel: esi: c12e80c0 edi: db91da00 ebp: df4d4000 esp: df4d5bf0
Aug 14 20:34:57 mp kernel: ds: 007b es: 007b ss: 0068
Aug 14 20:34:57 mp kernel: Process mplayer (pid: 17754, threadinfo=df4d4000 task=d3644170)
Aug 14 20:34:57 mp kernel: Stack: d2336a3c c92891c0 db91da00 e184f141 db91da00 c92891c0 c15eb5c0 00000000
Aug 14 20:34:57 mp kernel: 00000001 00000004 00000002 c12e80c0 00001000 d2336a3c 00000000 e1851dc4
Aug 14 20:34:57 mp kernel: c92891c0 d2336a3c c12e80c0 00000000 00001000 00000000 df4d5ce8 c12e80d8
Aug 14 20:34:57 mp kernel: Call Trace:
Aug 14 20:34:57 mp kernel: [<e184f141>] nfs_create_request+0xb1/0xf0 [nfs]
Aug 14 20:34:57 mp kernel: [<e1851dc4>] readpage_async_filler+0x94/0x150 [nfs]
Aug 14 20:34:57 mp kernel: [<c013e159>] read_cache_pages+0xc9/0x150
Aug 14 20:34:57 mp kernel: [<e1851ee3>] nfs_readpages+0x63/0xe0 [nfs]
Aug 14 20:34:57 mp kernel: [<e1851d30>] readpage_async_filler+0x0/0x150 [nfs]
Aug 14 20:34:57 mp kernel: [<c013e318>] read_pages+0x138/0x150
Aug 14 20:34:57 mp kernel: [<c013b650>] __alloc_pages+0x310/0x370
Aug 14 20:34:57 mp kernel: [<c013e632>] do_page_cache_readahead+0x102/0x1a0
Aug 14 20:34:57 mp kernel: [<c013e7dd>] page_cache_readahead+0x10d/0x210
Aug 14 20:34:57 mp kernel: [<c0137475>] do_generic_mapping_read+0xf5/0x4c0
Aug 14 20:34:57 mp kernel: [<c0137b3b>] __generic_file_aio_read+0x20b/0x240
Aug 14 20:34:57 mp kernel: [<c0137840>] file_read_actor+0x0/0xf0
Aug 14 20:34:57 mp kernel: [<c0137bcb>] generic_file_aio_read+0x5b/0x80
Aug 14 20:34:57 mp kernel: [<e184ad58>] nfs_file_read+0xa8/0xf0 [nfs]
Aug 14 20:34:57 mp kernel: [<c0154580>] do_sync_read+0x80/0xb0
Aug 14 20:34:57 mp kernel: [<c0147d43>] vma_merge+0x153/0x1d0
Aug 14 20:34:57 mp kernel: [<c0148470>] do_mmap_pgoff+0x5b0/0x6e0
Aug 14 20:34:57 mp kernel: [<c0154668>] vfs_read+0xb8/0x130
Aug 14 20:34:57 mp kernel: [<c0154911>] sys_read+0x51/0x80
Aug 14 20:34:57 mp kernel: [<c010513b>] syscall_call+0x7/0xb
Aug 14 20:34:57 mp kernel: Code: ff 40 14 89 43 18 8b 5c 24 08 83 c4 0c c3 8d 74 26 00 8b 4c
Gruß Michel
- fred19726
- Beiträge: 507
- Registriert: 18.07.2002 03:38:38
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Heidelberg (DE)
-
Kontaktdaten:
Hi,
das sieht nach dem nfs Problem aus weswegen der 2.6.8.1er rausgebracht wurde. Versuchs mit dem 2.6.8.1er und alles wird gut
MfG Fred
das sieht nach dem nfs Problem aus weswegen der 2.6.8.1er rausgebracht wurde. Versuchs mit dem 2.6.8.1er und alles wird gut
MfG Fred
2 Dinge sind Unendlich, das Universum und die Menschliche Dummheit,
wobei ich mir beim Universum nicht sicher bin
-- Albert Einstein
wobei ich mir beim Universum nicht sicher bin
-- Albert Einstein
- Voyager_MP
- Beiträge: 628
- Registriert: 22.06.2004 10:04:07
- Wohnort: Aachen
- C_A
- Beiträge: 1082
- Registriert: 22.04.2004 14:51:01
- Lizenz eigener Beiträge: GNU General Public License
Den 2.6.8.1er findest du hier:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
- Savar
- Beiträge: 7174
- Registriert: 30.07.2004 09:28:58
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Berlin
aber soweit ich weiß ist der 2.6.8.1er nur ein gepatchter 2.6.8er der den Fehler hatte. Das hatte an und für sich nichts mit dem 2.6.7er zu tun.. aber Probieren geht über studierenC_A hat geschrieben:Den 2.6.8.1er findest du hier:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
- Savar
- Beiträge: 7174
- Registriert: 30.07.2004 09:28:58
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Berlin
C_A hat geschrieben:Ja genau, er hat das Problem ja auch beim 2.6.8er und nicht beim 2.6.7er.Savar hat geschrieben:Das hatte an und für sich nichts mit dem 2.6.7er zu tun.. aber Probieren geht über studieren
MfG
C_A
sorry das Zitat ging nicht direkt an dich sondern an "fred19726" Posting und dem beschriebenen NFS Problem
/EDIT: AUA ok ich merk es ist zu spät.. irgnoriert meinen Text einfach..
- der_schreiner
- Beiträge: 8
- Registriert: 31.07.2004 12:52:53
- Wohnort: Abtwil SG (CH)
-
Kontaktdaten:
2.6.8.2 wäre angebracht
2.6.8.2 wäre angebracht damit man auch wieder CD und DVD brennen kann
Dieser 2.6.8'er hats in sich, ist irgenwie einfach zu früh released worden.
Aber machen wir nicht alle Fehler? Naja Torvalds schlechter Tag gehabt
Dieser 2.6.8'er hats in sich, ist irgenwie einfach zu früh released worden.
Aber machen wir nicht alle Fehler? Naja Torvalds schlechter Tag gehabt
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Re: 2.6.8.2 wäre angebracht
Nope, das mit dem Brennen ist Absicht. Damit wurde eine Sicherheitslücke geschlossen, die es allen Usern die den Brenner nutzen dürfen ermöglichte z.B. die Firmware auf dem Brenner zu löschen, und das Gerät damit zu zerstören. 2.6.8 filtert jetzt Befehle, falls der user CAP_RAW_IO nicht hat, und das ist für alle ausser root nicht der Fall. cdrecord geht als root. In den nächsten Kernel Versionen wird das Filtering dann etwas weniger pauschal sein (Filterliste) und es sollte dann wieder gehen.der_schreiner hat geschrieben:2.6.8.2 wäre angebracht damit man auch wieder CD und DVD brennen kann
Dieser 2.6.8'er hats in sich, ist irgenwie einfach zu früh released worden.
Aber machen wir nicht alle Fehler? Naja Torvalds schlechter Tag gehabt ;-
Auf jeden Fall ist diese Änderung volle Absicht.
PatrickChangelog-2.6.8 hat geschrieben:<torvalds@ppc970.osdl.org>
Be a bit more anal about allowing SCSI commands to be sent.
Normal users shouldn't have access to the raw device anyway
unless they are in the trusted "disk" group, but let's require
RAWIO capabilities. That's what the original SCSI interfaces
did anyhoo.
We probably _should_ just require write access, but that will
need more of a code change to pass down the file descriptor.
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de
- der_schreiner
- Beiträge: 8
- Registriert: 31.07.2004 12:52:53
- Wohnort: Abtwil SG (CH)
-
Kontaktdaten:
Aber dann wars ja zu früh
Aber dann wars ja zu früh, schliesslich wäre es ein mehraufwand an Code, der sicherlich noch gemacht werden muss. Oder sehe ich das falsch?
Ich meine es ist schön meinen Brenner zu schützen, nur sind die meisten Firmware Update sowieso für Windows gemacht, und ich denke wenn es Linux fähige gibt, benötigt man für dessen Installation sicherlich trotzdem root Rechte, wenn die Firmware schlau aufgebaut ist, sollte sie sich nur als root ausführen lassen.
Aber was solls ich kann wieder brennen
Ich meine es ist schön meinen Brenner zu schützen, nur sind die meisten Firmware Update sowieso für Windows gemacht, und ich denke wenn es Linux fähige gibt, benötigt man für dessen Installation sicherlich trotzdem root Rechte, wenn die Firmware schlau aufgebaut ist, sollte sie sich nur als root ausführen lassen.
Aber was solls ich kann wieder brennen
- Savar
- Beiträge: 7174
- Registriert: 30.07.2004 09:28:58
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Berlin
die Firmware an sich spielt sich doch nicht selber ein!!
Es gibt Befehle (SCSI) mit denen man beliebigen Code in den Speicher des Brenners schreiben kann. Normalerweise sollte das nur die Firmware sein aber du kannst ja auch eine nette Textdatei raufschieben und schon hast du einen Brenner ohne "Betriebssystem" (wenn man das jetzt mal so ausdrücken darf)..
Es gibt Befehle (SCSI) mit denen man beliebigen Code in den Speicher des Brenners schreiben kann. Normalerweise sollte das nur die Firmware sein aber du kannst ja auch eine nette Textdatei raufschieben und schon hast du einen Brenner ohne "Betriebssystem" (wenn man das jetzt mal so ausdrücken darf)..
- pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
Welcher Teil von "das Gerät zerstören" ist unklar? Wenn man das macht, ist der Brenner Schrott, keine Rettung möglich (Reparatur ist teurer als ein neuer)die Firmware auf dem Brenner zu löschen, und das Gerät damit zu zerstören.
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de