strange oops in iput. (2.6.23.1)
I got a report from a user this morning with the following oops. Unable to handle kernel NULL pointer dereference at 0038 RIP: [] iput+0x18/0x7b PGD 6fdf9067 PUD 7810c067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: berry_charge tun vfat fat usb_storage appletalk ipx p8023 i915 drm dcdbas ipt_MASQUERADE iptable_nat nf_nat bridge rfcomm l2cap autofs4 sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq arc4 ecb snd_seq_device blkcipher snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iwl3945 snd_page_alloc mac80211 tg3 snd_hwdep firewire_ohci hci_usb i2c_i801 i2c_core video firewire_core snd option cfg80211 button battery bluetooth ac output usbserial soundcore sg iTCO_wdt crc_itu_t joydev iTCO_vendor_support sr_mod cdrom dm_snapshot dm_zero dm_mirror dm_mod ata_generic ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Pid: 277, comm: kswapd0 Not tainted 2.6.23.1-42.fc8 #1 RIP: 0010:[] [] iput+0x18/0x7b RSP: 0018:810037f11d60 EFLAGS: 00010283 RAX: RBX: 8103fcc8 RCX: 8103fcf8 RDX: 8103fcf8 RSI: 817c5d50 RDI: 8103fcc8 RBP: 0001 R08: 0001 R09: 817c5b60 R10: 0282 R11: 817c5c30 R12: 817c5d00 R13: 0060 R14: 0001 R15: 0100 FS: () GS:810037c2c300() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0038 CR3: 6f40a000 CR4: 26a0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process kswapd0 (pid: 277, threadinfo 810037f1, task 810037f05020) Stack: 810037cc6870 810ab41a 0282 810037cc6870 810ac118 817c5c30 810037cc6870 817c5d00 810ac2e1 8137e220 b98c Call Trace: [] d_kill+0x21/0x43 [] prune_one_dentry+0x3a/0xee [] prune_dcache+0x115/0x163 [] shrink_dcache_memory+0x1c/0x36 [] shrink_slab+0xdc/0x154 [] kswapd+0x318/0x4a8 [] autoremove_wake_function+0x0/0x2e [] kswapd+0x0/0x4a8 [] kthread+0x47/0x73 [] child_rip+0xa/0x12 [] flat_send_IPI_mask+0x0/0x4c [] kthread+0x0/0x73 [] child_rip+0x0/0x12 Code: 48 8b 40 38 75 04 0f 0b eb fe 48 85 c0 74 0b 48 8b 40 28 48 Which appears that inode->i_sb was null which afaict, shouldn't ever happen. How is this possible? A race perhaps? (only ext3 filesystems were in use) Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
strange oops in iput. (2.6.23.1)
I got a report from a user this morning with the following oops. Unable to handle kernel NULL pointer dereference at 0038 RIP: [810ad479] iput+0x18/0x7b PGD 6fdf9067 PUD 7810c067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: berry_charge tun vfat fat usb_storage appletalk ipx p8023 i915 drm dcdbas ipt_MASQUERADE iptable_nat nf_nat bridge rfcomm l2cap autofs4 sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq arc4 ecb snd_seq_device blkcipher snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iwl3945 snd_page_alloc mac80211 tg3 snd_hwdep firewire_ohci hci_usb i2c_i801 i2c_core video firewire_core snd option cfg80211 button battery bluetooth ac output usbserial soundcore sg iTCO_wdt crc_itu_t joydev iTCO_vendor_support sr_mod cdrom dm_snapshot dm_zero dm_mirror dm_mod ata_generic ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Pid: 277, comm: kswapd0 Not tainted 2.6.23.1-42.fc8 #1 RIP: 0010:[810ad479] [810ad479] iput+0x18/0x7b RSP: 0018:810037f11d60 EFLAGS: 00010283 RAX: RBX: 8103fcc8 RCX: 8103fcf8 RDX: 8103fcf8 RSI: 817c5d50 RDI: 8103fcc8 RBP: 0001 R08: 0001 R09: 817c5b60 R10: 0282 R11: 817c5c30 R12: 817c5d00 R13: 0060 R14: 0001 R15: 0100 FS: () GS:810037c2c300() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0038 CR3: 6f40a000 CR4: 26a0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process kswapd0 (pid: 277, threadinfo 810037f1, task 810037f05020) Stack: 810037cc6870 810ab41a 0282 810037cc6870 810ac118 817c5c30 810037cc6870 817c5d00 810ac2e1 8137e220 b98c Call Trace: [810ab41a] d_kill+0x21/0x43 [810ac118] prune_one_dentry+0x3a/0xee [810ac2e1] prune_dcache+0x115/0x163 [810ac34b] shrink_dcache_memory+0x1c/0x36 [8107bc99] shrink_slab+0xdc/0x154 [8107c576] kswapd+0x318/0x4a8 [810493c1] autoremove_wake_function+0x0/0x2e [8107c25e] kswapd+0x0/0x4a8 [8104926c] kthread+0x47/0x73 [8100c9e8] child_rip+0xa/0x12 [8101dd1e] flat_send_IPI_mask+0x0/0x4c [81049225] kthread+0x0/0x73 [8100c9de] child_rip+0x0/0x12 Code: 48 8b 40 38 75 04 0f 0b eb fe 48 85 c0 74 0b 48 8b 40 28 48 Which appears that inode-i_sb was null which afaict, shouldn't ever happen. How is this possible? A race perhaps? (only ext3 filesystems were in use) Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote: > Well, I for one use the 2.2 ide patches extensively (on almost all of my > machines, including a heavy-duty backup server), and haven't seen any > problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for > example. I have been using the udma ide patches for a long time and as long as you stay away from known buggy drives controllers you are fine. BTW: The machine i reported the bug for is mostly running on SCSI - Only /var/tmp is an large IDE drive. > I don't mean to say the ide patches are 100% bug free, but I wouldn't > consider them as the prime suspect for an oops that happened elsewhere > either. It could be hw or any other part of kernel just as well... What > about memtest86? I'll try Flo -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 Why is it called "common sense" when nobody seems to have any? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
On Tue, Jun 26, 2001 at 11:56:51AM +0100, you [Stephen C. Tweedie] claimed: > Hi, > > On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote: > > > Well, I for one use the 2.2 ide patches extensively (on almost all of my > > machines, including a heavy-duty backup server) > > It is highly hardware-dependent. A huge amount of effort was spent > early in 2.4 getting blacklists and hardware tweaks right to work > around problems with specific chipsets with ide udma. Just because it > works for one person doesn't give you any confidence that it won't > trash data for somebody else. Well, the report said 'Intel BX chipset' - that's as solid as chipsets get (to loosely quote Alan). Almost all of my boxes are BX (one has HPT366 in addition, and another one was changed to Via686a recently), and I imagine that BX gets most testing since it is very common chipset. Moreover, it only does UDMA33, not any fancy 66 or 100 stuff (although I haven't had problems with those either on HPT366, HPT370 nor 686a). As said, it could be the ide patch, but surely there are other just as likely suspects as well. -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
Hi, On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote: > Well, I for one use the 2.2 ide patches extensively (on almost all of my > machines, including a heavy-duty backup server) It is highly hardware-dependent. A huge amount of effort was spent early in 2.4 getting blacklists and hardware tweaks right to work around problems with specific chipsets with ide udma. Just because it works for one person doesn't give you any confidence that it won't trash data for somebody else. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
On Mon, Jun 25, 2001 at 07:42:13PM +0100, you [Stephen C. Tweedie] claimed: > Hi, > > On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote: > > > > oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) > > The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4 > ones, and simply can't be trusted as a baseline for debugging other > code. Can you reproduce this problem without them applied? The oops > here is a networking oops on the face of it, and I wouldn't expect to > see that on 2.2 unless something was corrupting memory. Well, I for one use the 2.2 ide patches extensively (on almost all of my machines, including a heavy-duty backup server), and haven't seen any problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for example. I don't mean to say the ide patches are 100% bug free, but I wouldn't consider them as the prime suspect for an oops that happened elsewhere either. It could be hw or any other part of kernel just as well... What about memtest86? -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
On Mon, Jun 25, 2001 at 07:42:13PM +0100, you [Stephen C. Tweedie] claimed: Hi, On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote: oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4 ones, and simply can't be trusted as a baseline for debugging other code. Can you reproduce this problem without them applied? The oops here is a networking oops on the face of it, and I wouldn't expect to see that on 2.2 unless something was corrupting memory. Well, I for one use the 2.2 ide patches extensively (on almost all of my machines, including a heavy-duty backup server), and haven't seen any problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for example. I don't mean to say the ide patches are 100% bug free, but I wouldn't consider them as the prime suspect for an oops that happened elsewhere either. It could be hw or any other part of kernel just as well... What about memtest86? -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
Hi, On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote: Well, I for one use the 2.2 ide patches extensively (on almost all of my machines, including a heavy-duty backup server) It is highly hardware-dependent. A huge amount of effort was spent early in 2.4 getting blacklists and hardware tweaks right to work around problems with specific chipsets with ide udma. Just because it works for one person doesn't give you any confidence that it won't trash data for somebody else. Cheers, Stephen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
On Tue, Jun 26, 2001 at 11:56:51AM +0100, you [Stephen C. Tweedie] claimed: Hi, On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote: Well, I for one use the 2.2 ide patches extensively (on almost all of my machines, including a heavy-duty backup server) It is highly hardware-dependent. A huge amount of effort was spent early in 2.4 getting blacklists and hardware tweaks right to work around problems with specific chipsets with ide udma. Just because it works for one person doesn't give you any confidence that it won't trash data for somebody else. Well, the report said 'Intel BX chipset' - that's as solid as chipsets get (to loosely quote Alan). Almost all of my boxes are BX (one has HPT366 in addition, and another one was changed to Via686a recently), and I imagine that BX gets most testing since it is very common chipset. Moreover, it only does UDMA33, not any fancy 66 or 100 stuff (although I haven't had problems with those either on HPT366, HPT370 nor 686a). As said, it could be the ide patch, but surely there are other just as likely suspects as well. -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote: Well, I for one use the 2.2 ide patches extensively (on almost all of my machines, including a heavy-duty backup server), and haven't seen any problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for example. I have been using the udma ide patches for a long time and as long as you stay away from known buggy drives controllers you are fine. BTW: The machine i reported the bug for is mostly running on SCSI - Only /var/tmp is an large IDE drive. I don't mean to say the ide patches are 100% bug free, but I wouldn't consider them as the prime suspect for an oops that happened elsewhere either. It could be hw or any other part of kernel just as well... What about memtest86? I'll try Flo -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 Why is it called common sense when nobody seems to have any? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
Hi, On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote: > > oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4 ones, and simply can't be trusted as a baseline for debugging other code. Can you reproduce this problem without them applied? The oops here is a networking oops on the face of it, and I wouldn't expect to see that on 2.2 unless something was corrupting memory. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops in iput
Hi, oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) Intel BX chipset, SCSI Disks Symbios chipset - The crashing process is the master process of "postfix" an MTA. Just before the crash all processes on that machine started to segfault in nameserver resolution (remote dns server) and after 2-3 minutes this oops happened. ksymoops 2.3.4 on i686 2.2.19. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19/ (default) -m /boot/System.map-2.2.19 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 4ed90398 current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 4ed90330 ebx: ecx: edx: c01eef0c esi: 4ed90330 edi: ce27ed00 ebp: 0002 esp: cf04ddac ds: 0018 es: 0018 ss: 0018 Process master (pid: 297, process nr: 31, stackpage=cf04d000) Stack: cf1859a0 0001 cef7db18 cef7db18 cf1859a0 c015882f 4ed90330 ce27ec80 0002 ced90330 ced90330 ce27ed00 0002 ceadc0c0 cfce5860 c0158be3 ced903e0 ceeda140 0002 ceeda140 ced90330 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 46 68 85 c0 74 09 8b 40 18 85 c0 74 02 89 c3 85 db 74 10 >>EIP; c0133ca7<= Trace; c015882f Trace; c0158be3 Trace; c011b26c Trace; c01262bd <__fput+25/54> Trace; c011d2b5 Trace; c012745c Trace; c0127453 Trace; c01139bb Trace; c012634b Trace; c011073e Trace; c0113958 Trace; c01184f4 Trace; c011847d Trace; c0109fbb Trace; c0b1 Trace; c0109583 Trace; c010a100 Code; c0133ca7 <_EIP>: Code; c0133ca7<= 0: 8b 46 68 mov0x68(%esi),%eax <= Code; c0133caa 3: 85 c0 test %eax,%eax Code; c0133cac 5: 74 09 je 10 <_EIP+0x10> c0133cb7 Code; c0133cae 7: 8b 40 18 mov0x18(%eax),%eax Code; c0133cb1 a: 85 c0 test %eax,%eax Code; c0133cb3 c: 74 02 je 10 <_EIP+0x10> c0133cb7 Code; c0133cb5 e: 89 c3 mov%eax,%ebx Code; c0133cb7 10: 85 db test %ebx,%ebx Code; c0133cb9 12: 74 10 je 24 <_EIP+0x24> c0133ccb 1 warning issued. Results may not be reliable. -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 Why is it called "common sense" when nobody seems to have any? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops in iput
Hi, oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) Intel BX chipset, SCSI Disks Symbios chipset - The crashing process is the master process of postfix an MTA. Just before the crash all processes on that machine started to segfault in nameserver resolution (remote dns server) and after 2-3 minutes this oops happened. ksymoops 2.3.4 on i686 2.2.19. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19/ (default) -m /boot/System.map-2.2.19 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 4ed90398 current-tss.cr3 = 00101000, %cr3 = 00101000 *pde = Oops: CPU:0 EIP:0010:[c0133ca7] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 4ed90330 ebx: ecx: edx: c01eef0c esi: 4ed90330 edi: ce27ed00 ebp: 0002 esp: cf04ddac ds: 0018 es: 0018 ss: 0018 Process master (pid: 297, process nr: 31, stackpage=cf04d000) Stack: cf1859a0 0001 cef7db18 cef7db18 cf1859a0 c015882f 4ed90330 ce27ec80 0002 ced90330 ced90330 ce27ed00 0002 ceadc0c0 cfce5860 c0158be3 ced903e0 ceeda140 0002 ceeda140 ced90330 Call Trace: [c015882f] [c0158be3] [c011b26c] [c01262bd] [c011d2b5] [c012745c] [c0127453] [c01139bb] [c012634b] [c011073e] [c0113958] [c01184f4] [c011847d] [c0109fbb] [c0b1] [c0109583] [c010a100] Code: 8b 46 68 85 c0 74 09 8b 40 18 85 c0 74 02 89 c3 85 db 74 10 EIP; c0133ca7 iput+13/228 = Trace; c015882f sock_release+57/60 Trace; c0158be3 sock_close+3f/4c Trace; c011b26c clear_page_tables+ac/b4 Trace; c01262bd __fput+25/54 Trace; c011d2b5 exit_mmap+115/120 Trace; c012745c fput+20/54 Trace; c0127453 fput+17/54 Trace; c01139bb mmput+3f/48 Trace; c012634b filp_close+5f/6c Trace; c011073e send_sig_info+182/2c0 Trace; c0113958 mm_release+10/34 Trace; c01184f4 do_exit+140/2a0 Trace; c011847d do_exit+c9/2a0 Trace; c0109fbb do_signal+21f/298 Trace; c0b1 sys_kill+61/70 Trace; c0109583 sys_sigreturn+b7/e8 Trace; c010a100 signal_return+14/18 Code; c0133ca7 iput+13/228 _EIP: Code; c0133ca7 iput+13/228 = 0: 8b 46 68 mov0x68(%esi),%eax = Code; c0133caa iput+16/228 3: 85 c0 test %eax,%eax Code; c0133cac iput+18/228 5: 74 09 je 10 _EIP+0x10 c0133cb7 iput+23/228 Code; c0133cae iput+1a/228 7: 8b 40 18 mov0x18(%eax),%eax Code; c0133cb1 iput+1d/228 a: 85 c0 test %eax,%eax Code; c0133cb3 iput+1f/228 c: 74 02 je 10 _EIP+0x10 c0133cb7 iput+23/228 Code; c0133cb5 iput+21/228 e: 89 c3 mov%eax,%ebx Code; c0133cb7 iput+23/228 10: 85 db test %ebx,%ebx Code; c0133cb9 iput+25/228 12: 74 10 je 24 _EIP+0x24 c0133ccb iput+37/228 1 warning issued. Results may not be reliable. -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 Why is it called common sense when nobody seems to have any? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops in iput
Hi, On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote: oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4 ones, and simply can't be trusted as a baseline for debugging other code. Can you reproduce this problem without them applied? The oops here is a networking oops on the face of it, and I wouldn't expect to see that on 2.2 unless something was corrupting memory. Cheers, Stephen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
