Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Yum update. Reboot. 2. 3. Actual results: Aug 5 15:31:27 xenon kernel: BUG: warning at kernel/softirq.c:138/local_bh_enable() (Not tainted) Aug 5 15:31:27 xenon kernel: [<c042b0cf>] local_bh_enable+0x45/0x92 Aug 5 15:31:27 xenon kernel: [<c06002bd>] cond_resched_softirq+0x2c/0x42 Aug 5 15:31:27 xenon kernel: [<c059adf3>] release_sock+0x4f/0x9d Aug 5 15:31:27 xenon kernel: [<c05df75a>] inet_stream_connect+0x116/0x1ff Aug 5 15:31:27 xenon kernel: [<c0436e71>] autoremove_wake_function+0x0/0x35 Aug 5 15:31:27 xenon kernel: [<c0599b21>] sys_connect+0x82/0xad Aug 5 15:31:27 xenon kernel: [<c059adb6>] release_sock+0x12/0x9d Aug 5 15:31:27 xenon kernel: [<c059c29d>] sock_setsockopt+0x4a2/0x4ac Aug 5 15:31:27 xenon kernel: [<c0598d12>] sys_setsockopt+0x6d/0xa7 Aug 5 15:31:27 xenon kernel: [<c059a368>] sys_socketcall+0xac/0x261 Aug 5 15:31:27 xenon kernel: [<c0475028>] sys_close+0x6e/0xa5 Aug 5 15:31:27 xenon kernel: [<c0404f70>] syscall_call+0x7/0xb Aug 5 15:31:27 xenon hcid[1659]: Bluetooth HCI daemon Aug 5 15:31:27 xenon sdpd[1663]: Bluetooth SDP daemon Aug 5 15:31:27 xenon kernel: [<c0600000>] __sched_text_start+0x6e8/0x89e Aug 5 15:31:27 xenon sdpd[1663]: Starting SDP server Aug 5 15:31:27 xenon kernel: ======================= Expected results: Normal boot. Reverted to release kernel 2.6.21-1.3194.fc7. Boots OK. Additional info: Platform is HP E42 Model A7655T PC, 1.7 GHz P4. 512 MB memory. EIDE disk.
Error message on the boot screen shows: ata1: SRST failed (errno=-16) I have a second HP e42 with a different size hard disk/memory. The other e42 boots 2.6.22-41.fc7 just fine. The machine with the panic has 512MB of RAM. The one that booted fine has 768MB. dmesg output on the machine with the panic (when booted on 2.6.21): ata1: port is slow to respond, please be patient (Status 0x80) ATA: abnormal status 0x7F on port 0x000101f7 ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: ATA-7: WDC WD1600JB-00REA0, 20.00K20, max UDMA/100 ata1.00: 312581808 sectors, multi 16: LBA48 ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: configured for UDMA/100 scsi1 : ata_piix ata2.00: ATAPI, max UDMA/33 ata2.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA WDC WD1600JB-00R 20.0 PQ: 0 ANSI: 5 SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) The successful machine under 2.6.22: libata version 2.21 loaded. ata_piix 0000:00:1f.1: version 2.11 PCI: Setting latency timer of device 0000:00:1f.1 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001fc00 irq 14 ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001fc08 irq 15 usb 1-1: configuration #1 chosen from 1 choice ata1.00: ATA-6: WDC WD3000JB-00KFA0, 08.05J08, max UDMA/100 ata1.00: 586072368 sectors, multi 16: LBA48 ata1.00: configured for UDMA/100
Try adding "pci=nomsi,nommconf" to the kernel boot options.
I added that information to the options. Same result. The boot area is located on /dev/VolGroup00/LogVol00. ata1: SRST failed (errno=-16) Reading all physical volumes. This may take a while... No volume groups found Volume group "VolGroup00" not found Unable to access resume device (/dev/VolGroup00/LogVol01) mount: could not find filesystem '/dev/root' Note the change from LogVol00 to LogVol01 at the end of the string.
I tore down the computer and discovered that the primary IDE connects only to the hard disk. The CDROM is connected to the secondary IDE. The hard disk had been optioned with MASTER with SLAVE PRESENT. The correct option should have been MASTER only. That explains the "slow response" that triggered the panic. I changed the jumper to MASTER only. The 2.6.22 kernel booted just fine. This still may be worthy of investigation as the 2.6.21 kernel was capable of booting the drive with the MASTER with SLAVE PRESENT jumper configuration. 2.6.22 is the first release based on libata. Perhaps some improvements are in order to make the new library more robust. I'm going to leave the status as new until someone in control of the code decides otherwise.