libata exception handling messages at boot on qemu
Is there a workaround for the long ugly boot messages on sees
with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks
quite ugly.
I suppose that's a qemu device model bug or could it be a Linux
problem?
-Andi
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14
ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15
ata1.00: ATA-7: QEMU HARDDISK, 0.9.0, max UDMA/100
ata1.00: 14062608 sectors, multi 16: LBA48
ata1.00: configured for MWDMA2
ata2.00: ATAPI: QEMU CD-ROM, 0.9.0, max UDMA/100
ata2.00: configured for MWDMA2
scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK0.9. PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 14062608 512-byte hardware sectors (7200 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DP
O or FUA
sd 0:0:0:0: [sda] 14062608 512-byte hardware sectors (7200 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DP
O or FUA
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: CD-ROMQEMU QEMU CD-ROM 0.9. PQ: 0 ANSI: 5
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH complete
ata2: DRQ=1 with device error, dev_stat 0x49
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
res 41/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x3 (HSM violation)
ata2.00: status: { DRDY ERR }
ata2: soft resetting link
ata2.00: configured for MWDMA2
ata2: EH
Re: libata exception handling messages at boot on qemu
Andi Kleen wrote: Is there a workaround for the long ugly boot messages on sees with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks quite ugly. I suppose that's a qemu device model bug or could it be a Linux problem? I believe this has been fixed in QEMU CVS: http://www.mail-archive.com/[EMAIL PROTECTED]/msg11844.html -jim - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata exception handling messages at boot on qemu
On Tue, 8 Jan 2008 20:23:52 +0100 Andi Kleen [EMAIL PROTECTED] wrote: Is there a workaround for the long ugly boot messages on sees with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks quite ugly. I suppose that's a qemu device model bug or could it be a Linux problem? libata actually bothers to check things like data directions and device state. This as far as I can tell is a qemu bug. I did look at the relevant code but it was so vomitously horrible I didn't investigate in detail. I believe the Xen qemu fork is ok ? Alan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata exception handling messages at boot on qemu
On Tue, Jan 08, 2008 at 09:04:28PM +, Alan Cox wrote: On Tue, 8 Jan 2008 20:23:52 +0100 Andi Kleen [EMAIL PROTECTED] wrote: Is there a workaround for the long ugly boot messages on sees with libata and qemu (0.9.0 CVS 070719)? It boots eventually, but it looks quite ugly. I suppose that's a qemu device model bug or could it be a Linux problem? libata actually bothers to check things like data directions and device state. This as far as I can tell is a qemu bug. I did look at the relevant code but it was so vomitously horrible I didn't investigate in detail. I believe the Xen qemu fork is ok ? It's fixed in qemu CVS as Jim pointed out. Still it's a little annoying to always have to update qemu from rpms to CVS. Since I assume that qemu code base is wide spread and if a workaround is not too ugly I think it would be nice if the kernel handled that. -Andi - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata exception handling messages at boot on qemu
Since I assume that qemu code base is wide spread and if a workaround is not too ugly I think it would be nice if the kernel handled that. Qemu behaves exactly the same way as a broken device in a situation where data corruption may occur. It would be extremely bad to remove sanity checking in storage subsystems just to deal with a silly bug in an emulator. Alan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata exception handling messages at boot on qemu
On Tue, Jan 08, 2008 at 09:19:31PM +, Alan Cox wrote: Since I assume that qemu code base is wide spread and if a workaround is not too ugly I think it would be nice if the kernel handled that. Qemu behaves exactly the same way as a broken device in a situation where data corruption may occur. It would be extremely bad to remove sanity checking in storage subsystems just to deal with a silly bug in an emulator. It could just a quirk e.g. matching on the ID string? -Andi - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata exception handling messages at boot on qemu
On Tue, 8 Jan 2008 22:37:16 +0100 Andi Kleen [EMAIL PROTECTED] wrote: On Tue, Jan 08, 2008 at 09:19:31PM +, Alan Cox wrote: Since I assume that qemu code base is wide spread and if a workaround is not too ugly I think it would be nice if the kernel handled that. Qemu behaves exactly the same way as a broken device in a situation where data corruption may occur. It would be extremely bad to remove sanity checking in storage subsystems just to deal with a silly bug in an emulator. It could just a quirk e.g. matching on the ID string? Qemu has been fixed for months, if they are slack about releases or it only got fixed in one of the gazillion branches of qemu that's their problem. That code is so horrible to look at I doubt that is the only problem and I did seriously look into it before deciding that qemu was just to gross to even work out what the bugs were. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
