I am not running any raid or mirroring. So I don't think that this is going to be fixed by the raid patch. This is pretty much the whole messages on the screen. There is some before this, but it is the normal boot stuff. ata1: failed to set xfermode, disabled ata2: failed to set xfermode, disabled Reading all physical volumes. This may take a while... No volume groups found Unable to find volume group "V0" Error: /bin/lvm exited abnormally with value 5 ! (pid 328) mount: error 6 mounting ext3 Error opening /dev/console!!!!: 2 Error dup2'ing fd of 0 to 0 Error dup2'ing fd of 0 to 1 Error dup2'ing fd of 0 to 2 Switchroot: mount failed: 22 Kernel panic - not syncing: Attempted to kill init! And that all that happens the machine has to be rest to do anything. It's like it can't set the xfermode for the SATA disks and so it can't find any disk to boot from and just dies. -----Original Message----- From: fedora-test-list-bounces@xxxxxxxxxx [mailto:fedora-test-list-bounces@xxxxxxxxxx] On Behalf Of Dwaine Garden Sent: Saturday, April 01, 2006 12:35 AM To: For testers of Fedora Core development releases Subject: Re: kernel-2.6.16-1.2069_FC4 sata panic --- Jerry Williams <jwilliam@xxxxxxxxxxxx> wrote: > I installed the new kernel-2.6.16-1.2069_FC4 and my > machine starts to boot > and then says: > ata1: failed to set xfermode, disabled > ata2: failed to set xfermode, disabled > > Then it complains that it can't find any volume > groups, there is one, but I > don't think that it can see my SATA disks. It > prints out a few more things > and panics. I am running Fedora Core 4, planning on > going to 5 after it has > settled some. > > Grub kernel line: > kernel /vmlinuz-2.6.16-1.2069_FC4 ro root=/dev/V0/L1 > acpi=off rhgb quiet > > Should I try something else on the kernel command > line? > Thanks! > Jerry > > > With 2.6.15-1.1833_FC4 kernel some of dmesg looks > like: > CPU: AMD Athlon(tm) XP 2600+ stepping 01 > PCI: Bypassing VIA 8237 APIC De-Assert Message > Uniform Multi-Platform E-IDE driver Revision: > 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; > override with idebus=xx > VP_IDE: IDE controller at PCI slot 0000:00:0f.1 > PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 0 > VP_IDE: chipset revision 6 > VP_IDE: not 100% native mode: will probe irqs later > VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller > on pci0000:00:0f.1 > ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: > hda:pio, hdb:DMA > ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: > hdc:DMA, hdd:pio > Probing IDE interface ide0... > hdb: Pioneer DVD-ROM ATAPIModel DVD-500M 010, ATAPI > CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > hdc: SONY DVD RW DRU-510A, ATAPI CD/DVD-ROM drive > ide1 at 0x170-0x177,0x376 on irq 15 > hdb: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(66) > Uniform CD-ROM driver Revision: 3.20 > hdc: ATAPI 32X DVD-ROM DVD-R CD-R/RW drive, 8192kB > Cache, UDMA(33) > SCSI subsystem initialized > libata version 1.20 loaded. > sata_via 0000:00:0f.0: version 1.1 > sata_via 0000:00:0f.0: routed to hard irq line 11 > ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma > 0xD800 irq 11 > ata2: SATA max UDMA/133 cmd 0xE000 ctl 0xDC02 bmdma > 0xD808 irq 11 > ata1: SATA link up 1.5 Gbps (SStatus 113) > ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 > 85:7c69 86:3e01 87:4003 > 88:407f > ata1: dev 0 ATA-7, max UDMA/133, 490234752 sectors: > LBA48 > ata1: dev 0 configured for UDMA/133 > scsi0 : sata_via > ata2: SATA link up 1.5 Gbps (SStatus 113) > ata2: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 > 85:7c69 86:3e01 87:4003 > 88:407f > ata2: dev 0 ATA-7, max UDMA/133, 490234752 sectors: > LBA48 > ata2: dev 0 configured for UDMA/133 > scsi1 : sata_via > Vendor: ATA Model: Maxtor 6Y250M0 Rev: > YAR5 > Type: Direct-Access ANSI > SCSI revision: 05 > SCSI device sda: 490234752 512-byte hdwr sectors > (251000 MB) > SCSI device sda: drive cache: write back > SCSI device sda: 490234752 512-byte hdwr sectors > (251000 MB) > SCSI device sda: drive cache: write back > sda: sda1 sda2 sda3 < sda5 sda6 sda7 > > sd 0:0:0:0: Attached scsi disk sda > Vendor: ATA Model: Maxtor 6Y250M0 Rev: > YAR5 > Type: Direct-Access ANSI > SCSI revision: 05 > SCSI device sdb: 490234752 512-byte hdwr sectors > (251000 MB) > SCSI device sdb: drive cache: write back > SCSI device sdb: 490234752 512-byte hdwr sectors > (251000 MB) > SCSI device sdb: drive cache: write back > sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 > > sd 1:0:0:0: Attached scsi disk sdb > device-mapper: 4.4.0-ioctl (2005-01-12) initialised: > dm-devel@xxxxxxxxxx Did you get these messages on the screen? device-mapper: dm-stripe: Target length not divisible by chunk size. device-mapper: error adding target to table. dmraid has a bug which is being patched. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186842 A patch was submitted for kernel 2.6.16 Here it is. [PATCH] dm stripe: Fix bounds The dm-stripe target currently does not enforce that the size of a stripe device be a multiple of the chunk-size. Under certain conditions, this can lead to I/O requests going off the end of an underlying device. This test-case shows one example. echo "0 100 linear /dev/hdb1 0" | dmsetup create linear0 echo "0 100 linear /dev/hdb1 100" | dmsetup create linear1 echo "0 200 striped 2 32 /dev/mapper/linear0 0 /dev/mapper/linear1 0" | \ dmsetup create stripe0 dd if=/dev/zero of=/dev/mapper/stripe0 bs=1k This will produce the output: dd: writing '/dev/mapper/stripe0': Input/output error 97+0 records in 96+0 records out And in the kernel log will be: attempt to access beyond end of device dm-0: rw=0, want=104, limit=100 The patch will check that the table size is a multiple of the stripe chunk-size when the table is created, which will prevent the above striped device from being created. This should not affect tools like LVM or EVMS, since in all the cases I can think of, striped devices are always created with the sizes being a multiple of the chunk-size. The size of a stripe device must be a multiple of its chunk-size. (akpm: that typecast is quite gratuitous) Signed-off-by: Kevin Corry <kevcorry@xxxxxxxxxx> Signed-off-by: Alasdair G Kergon <agk@xxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxx> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx> -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list