nFroce SATA lockup

* nFroce SATA lockup - problem location tracked down
@ 2004-12-01 20:37 Milan Holzäpfel
  2004-12-02  9:30 ` Keir Fraser
  0 siblings, 1 reply; 3+ messages in thread
From: Milan Holzäpfel @ 2004-12-01 20:37 UTC (permalink / raw)
  To: xen-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I finally did some more tests with system with nForce3-250Gb SATA
controller, whose driver locks the system at boot time when inside xen.

The following was used:
 - mobo with nForce3-250 Gb chipset, which has got a S-ATA controller
 - sata_nv from 2.6.10-rc2-bk11 pushed into vanilla 2.6.9, patched with 
   Xen and reiser4
 - some Xen stable bk snapshot from a few days ago

Files: <URL:http://mjh.name/misc-files/xen-caps-20041130/>

 - cap.*: captures from serial console
 - cap.linux.*: native linux bootup
 - cap.xenolinux.*: linux inside xen bootup
 - cap.*.dbg.*: kernel command line option "debug" passed
 - cap.*.nd-dbg: libata debug enabled (ATA_DEBUG, ATA_VERBOSE_DEBUG, ATA_IRQ_TRAP)
 - also the are two kernel .config files, and lspci output 
   (from native linux)
 - cap.xenolinux.extra-dbg:  log output with some extra dbg options
   added by me
 - driver/scsi/libata-core.c, include/linux/libata.h, kernel/sched.c:
   files with my extra stuff added

The lockup takes place in drivers/scsi/libata-core.c, in function
ata_dev_set_xfermode().  The call which does not return is
wait_for_completion(&wait) (line 1837).

Inside wait_for_completion(), which is defined in kernel/sched.c, the
last call of this function is schedule(), line 2862.  I added some extra
debug output into wait_for_completion() and schedule(), which shows that
schedule() runs on and on, checking some stuff each few moments.  I'd
assume that schedule() checks whether the thread locked by
wait_for_completion should get unlocked, but this condition never seems
to be fulfilled, maybe because of some address glibberish or whatever.

At the site mentioned above you can also find my modified version of
libata-core.c, libata.h and sched.c, and the boot output when using
these versions (cap.xenolinux.extra-dbg).

Now I'd hope that this information will help you to get a closer view of
the problem, and maybe even get an idea of a solution, since the deeper
I dig into all this code, the more other code I have to read to get an
idea of what's actually going on.  (and hey, I am by no means sth. like
a experienced C programmer ;) ) 

I'd be happy to provide whatever other information might be useful,
however.

TIA
Milan

- -- 

                   Milan Holzäpfel alias jagdfalke alias jag

Antworten direkt an mich                             Answers directly to me
gehen bitte an eine Addresse,                        go to an address one
die man hier finden kann:                            can find here, please:

Kontaktinfos sowie                                   Contact infos as well as
Öff GnuPG-Schlüssel    <URL:http://con.mjh.name/>    GnuPG Public Key
GnuPG Fingerabdruck     4C8A 5FAF 5D32 6125 89D1     GnuPG Fingerprint
                        0CE5 DB0C AF4F 6583 7966

                    http://www.deppenleerzeichen.de/                        

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBritx2wyvT2WDeWYRAuT6AKDIuhEDQBiy/Bm0dUkitZeN2JNw1wCg1HPH
d+k0NBqFFZcxvK1RnyUsPo8=
=uSd/
-----END PGP SIGNATURE-----

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

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