linux-kernel - Re: Suggestions for debugging ata_piix and ahci driver failures on Xen pv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 6 Feb 2009 14:32:07 +0200
From:	Pasi Kärkkäinen <pasik@....fi>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: Suggestions for debugging ata_piix and ahci driver failures on Xen pv_ops dom0 kernel (2.6.29-rcX)

On Thu, Feb 05, 2009 at 06:45:02PM -0600, Robert Hancock wrote:
> Pasi Kärkkäinen wrote:
> >Hello!
> >
> >I'm trying to figure out what's wrong with the pv_ops dom0 kernel/patches 
> >[1]
> >causing at least ata_piix and ahci drivers to fail to work.
> >
> >There was legacy IRQ enabling problem earlier with the pv_ops dom0 
> >patches, which pretty much prevented the disks from being detected.. but 
> >that got fixed. It could still be something related to Xen/dom0 irq 
> >handling.. 
> >I'd be glad if someone could take a look at this 2.6.29-rc3-tip pv_ops 
> >dom0 kernel boot log
> >and comment about _possible_ causes for such behaviour of ata_piix and 
> >ahci:
> >
> >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-11-xen331-linux-2.6.29-rc3-atadebug3.txt
> >
> >In that testing box I have just one IDE hdd attached to ata_piix 
> >controller, the AHCI controller doesn't
> >have any disks attached.
> >
> >The exact same kernel works OK without problems on baremetal without Xen
> >hypervisor. 
> 
> Seems like me like ata_piix is not receiving any interrupts.. the 
> polling-based IDENTIFY and SET FEATURES work, but the READ NATIVE MAX 
> ADDRESS times out and so does the READ DMA that gets tried next.
> 

OK. Thanks for pointing this out. 

> Note that the ata_piix controller is in legacy mode, not native mode, so 
> it's using IRQ 14 and 15, not whatever the hardware may otherwise 
> indicate. Could be the problem is related to that.
>

Yep. With earlier version of pv_ops dom0 patches devm_request_irq() call failed 
for IRQ 14 and 15 in ata_piix driver, but that has been fixed now.. 

Calling devm_request_irq() returns success now, but maybe it doesn't actually
work and do what it should? 

Thanks for your reply!

-- Pasi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/