[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Update on Xen on my hardware with nForce SATA

  • To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
  • From: Milan Holzäpfel <lists@xxxxxxxx>
  • Date: Fri, 18 Feb 2005 19:35:56 +0100
  • Delivery-date: Fri, 18 Feb 2005 18:36:32 +0000
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>

Hash: SHA1


I complained some time ago that a the dom0-kernel (2.6.9-based) inside
Xen would wait forever when trying to detect the hard disks connected
via the S-ATA controller, which is provided by the nForce 250Gb chipset.

The problem guessed by Keir (IIRC) was that the interrupt routing didn't
work because Xen didn't use ACPI to do it.  This will be fixed when Xen
lets Linux do the IRQ routing stuff. 

The following hardware changes have been made since then:

 - ATi Radeon 8500 has been replaced with a GeForce 6600GT
 - BIOS was updates to v1.5.  Quote from the changelog:
   "Update NVRAID ROM firmware to Ver:4.60."

I tried a some days ago, and I was surprised that the complete boot
process did ok. (No lockup; this was with recent unstable IIRC.)

Today I tested once more, first with stable.  (kernels based on 2.6.10) 
Boot worked fine, but e.g. "dd if=/dev/sda of=/dev/zero & dd if=/dev/sdb
of=/dev/zero" produces a lockup.  So does "pppd call dsl.normal", which
should make an internet connection using my "Fritz! Card DSL" (whose
binary only driver is another topic...).  

When this kind of lockup occurs, I can still switch the virtual
terminals, and I can even feed INIT's programmes waiting for a login
name with one, but nothing will ever come up asking me for a password.
- From the pppd command, I also got this line displayed by syslog-ng on a
virtual terminal (but not written to harddisk):

| [date and hostname] ata1: command 0x35 timeout, stat 0x50 hos_stat 0x24

(Additional files are available at <URL:http://mjh.name/files/tmp/xen-1/>)

Second test was with unstable, which always locked up after the message
"Console: colour VGA+ 80x25".  (Compiling with GCC 3.3.4 instead of
3.4.3 makes no difference.)

 - Now I'm curious: Were there any changes made to Xen which might have
   caused things to change?  Might the 2.6.9 -> 2.6.10 update have done
   the trick?  Is my h/w update or the BIOS update likely to be the cause?

 - Telling from the kernel dmesgs, I'd guess that the ACPI/IRQ handling 
   changes mentioned earlier haven't been done already.  I'd be happy to  
   test as soon as they are coded :)  (Any plans when these will be done?)

 - I'd also be glad to privde more information if you are interested.


- -- 

                   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


Version: GnuPG v1.2.6 (GNU/Linux)


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.
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.