kernel-2.6.16-1.2069_FC4 sata panic

Jerry Williams jwilliam at xmission.com
Sun Apr 2 00:30:57 UTC 2006 

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 at redhat.com
[mailto:fedora-test-list-bounces at redhat.com] 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 at xmission.com> 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 at redhat.com

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 at us.ibm.com>
Signed-off-by: Alasdair G Kergon <agk at redhat.com>
Signed-off-by: Andrew Morton <akpm at osdl.org>
Signed-off-by: Linus Torvalds <torvalds at osdl.org>

-- 
fedora-test-list mailing list
fedora-test-list at redhat.com
To unsubscribe: 
https://www.redhat.com/mailman/listinfo/fedora-test-list

More information about the fedora-test-list mailing list