| Summary: | [abrt] kernel: BUG: unable to handle kernel NULL pointer dereference at 00000050 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vesa Halttunen <vesuri> | ||||
| Component: | kernel | Assignee: | Eric Sandeen <esandeen> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | abrt_hash:15554fa5b5fd5dd04f48dfdfcc6e643b42bb162e | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-04-03 21:25:26 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Vesa Halttunen
2012-01-21 14:55:58 UTC
Odds are it was ext4 given the backtrace :) Was it still properly connected when you unmounted, or was it possibly previously disconnected... (In reply to comment #1) > Was it still properly connected when you unmounted, or was it possibly > previously disconnected... It was still connected. Somewhat off-topic, but for some reason I've been seeing a lot of kernel oopses after installing Fedora 16. I've practically never seen any on any earlier Fedora release on exactly the same hardware. Some of them have also been ext4-related but not umount-related. Unfortunately abrt hasn't stored/hasn't been able to store information about them. I guess I'll have to start taking screenshots with a camera and posting bugs that way... If you use hibernate, that's suspect. Tons of people are hitting bugs post-hibernate, and I cannot get a handle on the problem. void invalidate_inode_buffers(struct inode *inode)
{
if (inode_has_buffers(inode)) {
struct address_space *mapping = &inode->i_data;
struct list_head *list = &mapping->private_list;
struct address_space *buffer_mapping = mapping->assoc_mapping;
spin_lock(&buffer_mapping->private_lock);
while (!list_empty(list))
__remove_assoc_queue(BH_ENTRY(list->next));
spin_unlock(&buffer_mapping->private_lock);
}
}
we oopsed down the spin_lock path; private_lock is offset 0x50 (80) into the address_space, so presumably inode->i_data->assoc_mapping was NULL.
(gdb) offsetof private_lock address_space
$3 = 80
Oh; I said "Odds are it was ext4" but I meant ext2; the ext4 driver handles ext2 in F16. I'll see if I can see how we got here...
(In reply to comment #3) > If you use hibernate, that's suspect. I don't. (In reply to comment #4) > Oh; I said "Odds are it was ext4" but I meant ext2; the ext4 driver handles > ext2 in F16. I'll see if I can see how we got here... Yep, it's ext2 - it's the /dev/sdc1 partition listed under "Filesystem Information". Were you using quotas on the ext2 fs? (In reply to comment #6) > Were you using quotas on the ext2 fs? No. Well, nothing obvious here. :( Is this repeatable? Anything interesting about the files on the fs, or what you were doing to it prior to the unmount? (In reply to comment #8) > Well, nothing obvious here. :( Is this repeatable? I think I've seen this particular problem twice, but can't repeat for example right now. Or let's try... ...nope. :) > Anything interesting > about the files on the fs, or what you were doing to it prior to the unmount? Perhaps the most interesting thing is that the drive is connected via USB: [ 4739.717029] usb 2-2: new high speed USB device number 7 using ehci_hcd [ 4739.963310] usb 2-2: New USB device found, idVendor=07ff, idProduct=00ff [ 4739.963314] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4739.963317] usb 2-2: Product: ATAPI-6 Bridge Controller [ 4739.963319] usb 2-2: Manufacturer: Prolific Technology Inc. [ 4739.963321] usb 2-2: SerialNumber: 283A [ 4739.963796] scsi9 : usb-storage 2-2:1.0 [ 4740.963951] scsi 9:0:0:0: Direct-Access ST332062 0A 3.AA PQ: 0 ANSI: 0 I ran e2fsck on the fs and the fs seemed to be fine. I don't remember doing anything particularly special before this happened. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. Created attachment 574860 [details]
Screenshot showing the problem
Still reproducible with 3.3.0-4.fc16.i686.PAE. I unmounted the ext2 filesystem on an external USB drive and got this.
I'm afraid this bug is invalid. Even though I've been dealing with faulty memory numerous times and running memtest86 has usually been the first thing I do when a system starts crashing, for some reason I didn't run the test this time since the system seemed otherwise stable. After noticing that files also got randomly corrupted on all the drives connected to the system and the drives themselves reported to be fine, I ran the test and of course one of the memory modules was broken. I'm pretty sure it has been causing this problem as well. Please close this bug with any resolution you see fit. I'll reopen the bug if the problem persists. Ok, based on the previous comment, this is not a bug, but bad hardware. Thanks for the feedback! Do reopen if it reappears. Thanks, -Eric |