linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* libata exception handling messages at boot on qemu
@ 2008-01-08 19:23 Andi Kleen
  2008-01-08 20:17 ` Jim Paris
  2008-01-08 21:04 ` Alan Cox
  0 siblings, 2 replies; 7+ messages in thread
From: Andi Kleen @ 2008-01-08 19:23 UTC (permalink / raw)
  To: linux-ide


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 HARDDISK    0.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-ROM            QEMU     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 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: 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: libata exception handling messages at boot on qemu
  2008-01-08 19:23 libata exception handling messages at boot on qemu Andi Kleen
@ 2008-01-08 20:17 ` Jim Paris
  2008-01-08 21:04 ` Alan Cox
  1 sibling, 0 replies; 7+ messages in thread
From: Jim Paris @ 2008-01-08 20:17 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-ide

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/qemu-devel@nongnu.org/msg11844.html

-jim

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: libata exception handling messages at boot on qemu
  2008-01-08 19:23 libata exception handling messages at boot on qemu Andi Kleen
  2008-01-08 20:17 ` Jim Paris
@ 2008-01-08 21:04 ` Alan Cox
  2008-01-08 21:21   ` Andi Kleen
  1 sibling, 1 reply; 7+ messages in thread
From: Alan Cox @ 2008-01-08 21:04 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-ide

On Tue, 8 Jan 2008 20:23:52 +0100
Andi Kleen <andi@firstfloor.org> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: libata exception handling messages at boot on qemu
  2008-01-08 21:21   ` Andi Kleen
@ 2008-01-08 21:19     ` Alan Cox
  2008-01-08 21:37       ` Andi Kleen
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Cox @ 2008-01-08 21:19 UTC (permalink / raw)
  Cc: Andi Kleen, linux-ide

> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: libata exception handling messages at boot on qemu
  2008-01-08 21:04 ` Alan Cox
@ 2008-01-08 21:21   ` Andi Kleen
  2008-01-08 21:19     ` Alan Cox
  0 siblings, 1 reply; 7+ messages in thread
From: Andi Kleen @ 2008-01-08 21:21 UTC (permalink / raw)
  To: Alan Cox; +Cc: Andi Kleen, linux-ide

On Tue, Jan 08, 2008 at 09:04:28PM +0000, Alan Cox wrote:
> On Tue, 8 Jan 2008 20:23:52 +0100
> Andi Kleen <andi@firstfloor.org> 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: libata exception handling messages at boot on qemu
  2008-01-08 21:19     ` Alan Cox
@ 2008-01-08 21:37       ` Andi Kleen
  2008-01-08 21:40         ` Alan Cox
  0 siblings, 1 reply; 7+ messages in thread
From: Andi Kleen @ 2008-01-08 21:37 UTC (permalink / raw)
  To: Alan Cox; +Cc: Andi Kleen, linux-ide

On Tue, Jan 08, 2008 at 09:19:31PM +0000, 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: libata exception handling messages at boot on qemu
  2008-01-08 21:37       ` Andi Kleen
@ 2008-01-08 21:40         ` Alan Cox
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Cox @ 2008-01-08 21:40 UTC (permalink / raw)
  Cc: Andi Kleen, linux-ide

On Tue, 8 Jan 2008 22:37:16 +0100
Andi Kleen <andi@firstfloor.org> wrote:

> On Tue, Jan 08, 2008 at 09:19:31PM +0000, 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.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2008-01-08 21:42 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-08 19:23 libata exception handling messages at boot on qemu Andi Kleen
2008-01-08 20:17 ` Jim Paris
2008-01-08 21:04 ` Alan Cox
2008-01-08 21:21   ` Andi Kleen
2008-01-08 21:19     ` Alan Cox
2008-01-08 21:37       ` Andi Kleen
2008-01-08 21:40         ` Alan Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).