Partial workaround for probs with 3ware Controller

Partial workaround for probs with 3ware Controller

[Sven Kretzschmar]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]


Ok, I found a temporary workaround (not a good one though)
for the probs with the 3ware card.
If the option "ignorebiostables" is given as Xen kernel boot
option, then the 3ware card is initialized and configured
correctly with no problems. Also mounting and using
filesystems on the connected RAID array worked.

However, this is a very bad workaround, because it implies
"nosmp" which means that the second cpu in the server
is completely useless :-(

I also tried using only the Xen kernel boot option "noacpi" and/or
"nosmp", but that did not help with the 3ware driver.
Also the option "acpi=off" or "pci=noacpi" as XenLinux 2.6.7
boot option did not help.

Attached to this post is the bootlog from both booting with
(xendump-ibt.txt) and without (xendump-norm.txt) "ignorebiostables"
option set.

The Motherboard used is a Dual-Xeon Tyan S2721-533 V1.02
with 2 Xeon 2.6Ghz processors and 1 GIG RAM.
HT was disabled in the bios.

It seems there's still a bug or incompatibility with Xen concerning
Interrupts or Interrupt routing (?) because on vanilla 2.6.7 kernels,
the 3ware driver has no problems, even with high IRQ numbers
(like #72) assigned.

@Ian: I compiled Xen this time with "make clean", "debug=y make",
         "debug=y make install". However I could not see any more
         output from Xen than before as I compiled without "debug=y".
         Is this normal or did I make a mistake ? Does the bootlog
         in the attachment look as if the debug option was set ?

 HTH,
    Sven

P.S.: Thanks to Nuno Silva :) Although your hint was not really applicable, it
         at least led me in the correct direction, after I have browsed some
         reports about other 3ware controller probs in the internet.

*********** REPLY SEPARATOR  ***********

On 13.08.2004 at 17:58 Ian Pratt wrote:

>>
>> >Doing a cat /proc/interrupts and seeing if you're getting any
>> >for the device would be interesting.
>> Yes, on both a vanilla 2.6.7 and Xen 2.6.7 its IRQ 72 (Phys-irq 3ware
>Storage Controller)
>> on my machine.
>
>It looks like you're only ever receiving one interrupt for the
>3ware card.... very suspicious.
>
>Can you try rmmod'ing the 3ware module and re-insmod'ing it. I
>want to see whether you get one interrupt per init attempt, or
>one ever.
>
>Also, please can you do a debug build of Xen (debug=y) and then
>post the output of the machine booting.
>
>Ian



[-- Attachment #2: xendump.xzip --]
[-- Type: application/zip, Size: 10290 bytes --]

Re: Partial workaround for probs with 3ware Controller

[Nuno Silva]

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

Sven Kretzschmar wrote:
| Ok, I found a temporary workaround (not a good one though)
| for the probs with the 3ware card.
| If the option "ignorebiostables" is given as Xen kernel boot
| option, then the 3ware card is initialized and configured
| correctly with no problems. Also mounting and using
| filesystems on the connected RAID array worked.

from xendump-norm.txt:

(XEN) Initialised 1023MB memory (262128 pages) on a 1023MB machine
(XEN) Xen heap size is 10604KB
(XEN) CPU0: Before vendor init, caps: bfebfbff 00000000 00000000, vendor = 0
(XEN) CPU#0: Hyper-Threading is disabled
(XEN) CPU caps: bfebfbff 00000000 00000000 00000000
(XEN) found SMP MP-table at 000ff780
(XEN) Memory Reservation 0xff780, 4096 bytes
(XEN) Memory Reservation 0xf9500, 4096 bytes
(XEN) ACPI: RSDP (v000 ACPIAM                                    ) @
0x000f4fa0
(XEN) ACPI: RSDT (v001 A M I  OEMRSDT  0x02000304 MSFT 0x00000097) @
0x3fff0000
(XEN) ACPI: FADT (v002 A M I  OEMFACP  0x02000304 MSFT 0x00000097) @
0x3fff0200
(XEN) ACPI: MADT (v001 A M I  OEMAPIC  0x02000304 MSFT 0x00000097) @
0x3fff0300
(XEN) ACPI: OEMB (v001 A M I  OEMBIOS  0x02000304 MSFT 0x00000097) @
0x3ffff040
(XEN) ACPI: DSDT (v001  0ABBP 0ABBP000 0x00000000 INTL 0x02002026) @
0x00000000
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 Pentium 4(tm) XEON(tm) APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x06] enabled)
(XEN) Processor #6 Pentium 4(tm) XEON(tm) APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
(XEN) Processor #130 invalid (max 16)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
(XEN) Processor #131 invalid (max 16)
(XEN) Using ACPI for processor (LAPIC) configuration information


Another wild guess:

Some months ago linux had a few problems counting the processors when
they were described non-sequentially (0, 6, 130, 131 -- like xen is
reporting). My guess is that Xen is using that (old) linux acpi code.
This limits the number of processors seen and may cause problems with
LAPIC/IO-APIC/etc.

IIRC, some users corrected part of this issue with a BIOS upgrade, but
not 100%. Current linux acpi code deals better with this kind of bios.

Also, don't worry about performance for now: AFAICT you are only running
with one processor. The other one is disabled ;-)

Does (non-xen) 2.6.7 reports the same acpi processor ID's? Is there a
newer BIOS for that box?

Can xen hackers confirm if the acpi code is up-to-date?

Kind regards,
Nuno Silva

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBHVP1OPig54MP17wRAmqOAKC9ZklZHQDwpQmaSA1rRiyZcBVj4gCfdpz9
3y+VflzKzDeQfEd9fYkkvok=
=K9eA
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: Partial workaround for probs with 3ware Controller

[Ian Pratt]

 
> Some months ago linux had a few problems counting the processors when
> they were described non-sequentially (0, 6, 130, 131 -- like xen is
> reporting). My guess is that Xen is using that (old) linux acpi code.
> This limits the number of processors seen and may cause problems with
> LAPIC/IO-APIC/etc.

Well spotted.
 
> Can xen hackers confirm if the acpi code is up-to-date?

The current acpi/apic code is around 2.4.22 vintage, which is
after most of the nasty bios table parsing problems.

It probably wouldn't hurt to freshen it, though. 

Any volunteers?

Ian





-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: Partial workaround for probs with 3ware Controller

[Nuno Silva]

Ian Pratt wrote:
>>Can xen hackers confirm if the acpi code is up-to-date?
> 
> The current acpi/apic code is around 2.4.22 vintage, which is
> after most of the nasty bios table parsing problems.
> 
> It probably wouldn't hurt to freshen it, though. 
> 
> Any volunteers?

Not me. I can't (won't) ruin a good project like xen :-)
(ehehehehe)

Anyway, maybe if all the cpus are detected the current code will work 
(an upgrade is still the better way...).

Just edit xeno-unstable.bk/xen/include/asm-x86/config.h and change:
"#define NR_CPUS 16" to
"#define NR_CPUS 160".

This will waste some memory for some structs but it shouldn't hurt, YMMV.

Doing a diff from mpparse.c in xen and 2.6 demonstrates that the method 
to find if the processor is invalid or not has changed:
@@ -987,7 +836,7 @@
         struct mpc_config_processor processor;
         int                     boot_cpu = 0;
-       if (id >= MAX_APICS) {
+       if (MAX_APICS - id <= 0) {
                 printk(KERN_WARNING "Processor #%d invalid (max %d)\n",
                         id, MAX_APICS);
                 return;

Also, 2.6 acpi code works better in some boxen. Maybe because it's more 
bleeding edge?

Regards,
Nuno Silva




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Partial workaround for probs with 3ware Controller

[Keir Fraser]

> Another wild guess:
> 
> Some months ago linux had a few problems counting the processors when
> they were described non-sequentially (0, 6, 130, 131 -- like xen is
> reporting). My guess is that Xen is using that (old) linux acpi code.
> This limits the number of processors seen and may cause problems with
> LAPIC/IO-APIC/etc.
> 
> IIRC, some users corrected part of this issue with a BIOS upgrade, but
> not 100%. Current linux acpi code deals better with this kind of bios.
> 
> Also, don't worry about performance for now: AFAICT you are only running
> with one processor. The other one is disabled ;-)
> 
> Does (non-xen) 2.6.7 reports the same acpi processor ID's? Is there a
> newer BIOS for that box?
> 
> Can xen hackers confirm if the acpi code is up-to-date?

I'll investigate an upgrade to 2.6 ACPI code. Doing the same for APIC
and IO-APIC code would probably also be sensible...

Sven: Do you have a boot dump from a working vanilla (non-Xen) kernel?
It'd be interesting to see what it is getting right.

 -- Keir


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: Partial workaround for probs with 3ware Controller

[Keir Fraser]

> > Does (non-xen) 2.6.7 reports the same acpi processor ID's? Is there a
> > newer BIOS for that box?
> > 
> > Can xen hackers confirm if the acpi code is up-to-date?
> 
> I'll investigate an upgrade to 2.6 ACPI code. Doing the same for APIC
> and IO-APIC code would probably also be sensible...
> 
> Sven: Do you have a boot dump from a working vanilla (non-Xen) kernel?
> It'd be interesting to see what it is getting right.

Hmmm... an upgrade to 2.6 code would be a non-trivial undertaking. But
Sven has got the 3ware controller working in vanilla 2.4.26.

I've updated our bootstrap ACPI code to code from the 2.4.26 tree -- it
looks like a bunch of additional parsing has been added in so, fingers
crossed, it may well make a difference. :-)  I also checked APIC,
IO-APIC, and PCI code but nothing there seems to have changed very
much. 

Sven: please pull the latest Xen and give it a go. If it still fails,
then send the new boot output from a Xen debug build, as you did
before. 

 Cheers,
 Keir


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: Partial workaround for probs with 3ware Controller

[Keir Fraser]

> Hmmm... an upgrade to 2.6 code would be a non-trivial undertaking. But
> Sven has got the 3ware controller working in vanilla 2.4.26.
> 
> I've updated our bootstrap ACPI code to code from the 2.4.26 tree -- it
> looks like a bunch of additional parsing has been added in so, fingers
> crossed, it may well make a difference. :-)  I also checked APIC,
> IO-APIC, and PCI code but nothing there seems to have changed very
> much. 
> 
> Sven: please pull the latest Xen and give it a go. If it still fails,
> then send the new boot output from a Xen debug build, as you did
> before. 

Another thing that is well worth trying is to disable 'ACPI support'
in your vanilla Linux 2.4.26 build configuration.

If you then look in your build tree's '.config' file you should see
CONFIG_ACPI_BOOT enabled, but no other CONFIG_ACPI options.

This much more accurately reflects the state of ACPI support in
Xen. If you build Linux with that configurations and your 3ware
controller fails to work then it means that we need to pull the ACPI
interpreter into Xen. That might not be too hard, but then
again... :-) 

 -- Keir


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: Partial workaround for probs with 3ware Controller

[Sven Kretzschmar]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]


I am sorry Keir, but your new code changes did not help
with the 3ware driver problem...
I cloned the Xen repository in a new directory to be sure
it's clean.
I used the changeset up to 1.1222 (MP table parsing).

In the attachment (zipped) you'll find the following boot logs:

1.) Xen2.4.26.txt   Log of non-working Xen boot
2.) linux2.4.26.txt  Log of vanilla and working Linux2.4.26 and ACPI support
                            switched off, like you proposed...3ware still working.
3.) linux2.6.7.txt    Log of vanilla and working Linux 2.6.7 boot.

Btw: Booting with XenLinux 2.6.7 including your new changes also did
not work with the 3ware driver.

HTH somehow.
I am sorry that it's still not working...

Nethertheless: have a nice weekend everybody ;-)

  Sven

*********** REPLY SEPARATOR  ***********

On 14.08.2004 at 18:53 Keir Fraser wrote:

>> Hmmm... an upgrade to 2.6 code would be a non-trivial undertaking. But
>> Sven has got the 3ware controller working in vanilla 2.4.26.
>>
>> I've updated our bootstrap ACPI code to code from the 2.4.26 tree -- it
>> looks like a bunch of additional parsing has been added in so, fingers
>> crossed, it may well make a difference. :-)  I also checked APIC,
>> IO-APIC, and PCI code but nothing there seems to have changed very
>> much.
>>
>> Sven: please pull the latest Xen and give it a go. If it still fails,
>> then send the new boot output from a Xen debug build, as you did
>> before.
>
>Another thing that is well worth trying is to disable 'ACPI support'
>in your vanilla Linux 2.4.26 build configuration.
>
>If you then look in your build tree's '.config' file you should see
>CONFIG_ACPI_BOOT enabled, but no other CONFIG_ACPI options.
>
>This much more accurately reflects the state of ACPI support in
>Xen. If you build Linux with that configurations and your 3ware
>controller fails to work then it means that we need to pull the ACPI
>interpreter into Xen. That might not be too hard, but then
>again... :-)
>
> -- Keir



[-- Attachment #2: bootdumps.xzip --]
[-- Type: application/zip, Size: 14235 bytes --]

Re: Re: Partial workaround for probs with 3ware Controller

[Keir Fraser]

Hmmm... some output is missing from the vanilla Linux 2.4 log, because
the console logging level isn't including debug messages.

To be specific: there should be a dump of IO-APIC content between the
lines --
 testing the IO APIC.......................
 .................................... done.

'dmesg -n 9' may get you these messages, or changing
kernel/printk.c:DEFAULT_CONSOLE_LOGLEVEL to 9. If none of this helps,
edit include/linux/kernel.h and change the definition of KERN_DEBUG to
the same as KERN_ALERT ("<1>").

 -- Keir

> 
> I am sorry Keir, but your new code changes did not help
> with the 3ware driver problem...
> I cloned the Xen repository in a new directory to be sure
> it's clean.
> I used the changeset up to 1.1222 (MP table parsing).
> 
> In the attachment (zipped) you'll find the following boot logs:
> 
> 1.) Xen2.4.26.txt   Log of non-working Xen boot
> 2.) linux2.4.26.txt  Log of vanilla and working Linux2.4.26 and ACPI support
>                             switched off, like you proposed...3ware still working.
> 3.) linux2.6.7.txt    Log of vanilla and working Linux 2.6.7 boot.
> 
> Btw: Booting with XenLinux 2.6.7 including your new changes also did
> not work with the 3ware driver.
> 
> HTH somehow.
> I am sorry that it's still not working...
> 
> Nethertheless: have a nice weekend everybody ;-)
> 
>   Sven


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: Partial workaround for probs with 3ware Controller

[Sven Kretzschmar]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]


Strange, somehow the serial line output did not include all of the bootlog.
I have now rebooted with vanilla 2.4.7 and included the output of dmesg
in the attachment to this post.
Strangely again, the dmesg output is not including the first around 10 lines
of the bootlog which was included in the serial log ..?!
However it includes the stuff now you were asking for, and I was able
to spot quite some differences (In the IRQ redirection tables, column "Vect.")
If this is still not enough debug output, please drop me a line
and I will make your proposed changes to kernel/printk.c .

HTH,
   Sven


*********** REPLY SEPARATOR  ***********

On 15.08.2004 at 09:44 Keir Fraser wrote:

>Hmmm... some output is missing from the vanilla Linux 2.4 log, because
>the console logging level isn't including debug messages.
>
>To be specific: there should be a dump of IO-APIC content between the
>lines --
> testing the IO APIC.......................
> .................................... done.
>
>'dmesg -n 9' may get you these messages, or changing
>kernel/printk.c:DEFAULT_CONSOLE_LOGLEVEL to 9. If none of this helps,
>edit include/linux/kernel.h and change the definition of KERN_DEBUG to
>the same as KERN_ALERT ("<1>").
>
> -- Keir
>
>>
>> I am sorry Keir, but your new code changes did not help
>> with the 3ware driver problem...
>> I cloned the Xen repository in a new directory to be sure
>> it's clean.
>> I used the changeset up to 1.1222 (MP table parsing).
>>
>> In the attachment (zipped) you'll find the following boot logs:
>>
>> 1.) Xen2.4.26.txt   Log of non-working Xen boot
>> 2.) linux2.4.26.txt  Log of vanilla and working Linux2.4.26 and ACPI
>support
>>                             switched off, like you proposed...3ware
>still working.
>> 3.) linux2.6.7.txt    Log of vanilla and working Linux 2.6.7 boot.
>>
>> Btw: Booting with XenLinux 2.6.7 including your new changes also did
>> not work with the 3ware driver.
>>
>> HTH somehow.
>> I am sorry that it's still not working...
>>
>> Nethertheless: have a nice weekend everybody ;-)
>>
>>   Sven



[-- Attachment #2: dmesg.xzip --]
[-- Type: application/zip, Size: 3997 bytes --]

[FIXED] probs with 3ware Controller

[Keir Fraser]

> 
> Strange, somehow the serial line output did not include all of the bootlog.
> I have now rebooted with vanilla 2.4.7 and included the output of dmesg
> in the attachment to this post.
> Strangely again, the dmesg output is not including the first around 10 lines
> of the bootlog which was included in the serial log ..?!
> However it includes the stuff now you were asking for, and I was able
> to spot quite some differences (In the IRQ redirection tables, column "Vect.")
> If this is still not enough debug output, please drop me a line
> and I will make your proposed changes to kernel/printk.c .
> 
> HTH,
>    Sven

Aha, lazy programming bit me. So the bug was nothing to do with BIOS
table parsing -- it was because the controllers's IRQ was greater than
63. :-)

Xen should now correctly virtualise IRQs all the way up to 127.

 -- Keir


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: [FIXED] probs with 3ware Controller

[Sven Kretzschmar]

I tested the new code and as you might have already expected, 
the 3ware controller and driver works now with Xen -- nice job :)

 Sven

*********** REPLY SEPARATOR  ***********

On 16.08.2004 at 09:21 Keir Fraser wrote:

>> 
>> Strange, somehow the serial line output did not include all of the
>bootlog.
>> I have now rebooted with vanilla 2.4.7 and included the output of dmesg
>> in the attachment to this post.
>> Strangely again, the dmesg output is not including the first around 10
>lines
>> of the bootlog which was included in the serial log ..?!
>> However it includes the stuff now you were asking for, and I was able
>> to spot quite some differences (In the IRQ redirection tables, column
>"Vect.")
>> If this is still not enough debug output, please drop me a line
>> and I will make your proposed changes to kernel/printk.c .
>> 
>> HTH,
>>    Sven
>
>Aha, lazy programming bit me. So the bug was nothing to do with BIOS
>table parsing -- it was because the controllers's IRQ was greater than
>63. :-)
>
>Xen should now correctly virtualise IRQs all the way up to 127.
>
> -- Keir





-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: [FIXED] probs with 3ware Controller

[Nuno Silva]

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

Keir Fraser wrote:
| Aha, lazy programming bit me. So the bug was nothing to do with BIOS
| table parsing -- it was because the controllers's IRQ was greater than
| 63. :-)
|
| Xen should now correctly virtualise IRQs all the way up to 127.

Hi!

I don't know if it's something that can cause trouble in the future so
I'm posting it so that someone more fit to judge can decide:

puma:/home/nuno# cat /proc/interrupts
~           CPU0       CPU1
~  0:     419664     363307    IO-APIC-edge  timer
~  1:        945        699    IO-APIC-edge  i8042
~  7:          0          0    IO-APIC-edge  parport0
~  8:          4          0    IO-APIC-edge  rtc
~  9:          0          0   IO-APIC-level  acpi
~ 12:       9433       8376    IO-APIC-edge  i8042
~ 14:      38328      31705    IO-APIC-edge  ide0
~ 15:         27         24    IO-APIC-edge  ide1
169:      29959      23244   IO-APIC-level  uhci_hcd, uhci_hcd,
radeon@PCI:1:0:0
177:          3          5   IO-APIC-level  uhci_hcd, bttv0, bt878
185:          0          0   IO-APIC-level  libata, uhci_hcd
193:          3          0   IO-APIC-level  ehci_hcd
201:        338          0   IO-APIC-level  Intel ICH5
209:          0          0   IO-APIC-level  ivtv: iTVC15/16 mpg2 encoder
chip
217:       2609       2142   IO-APIC-level  SysKonnect SK-98xx, ohci1394
NMI:        220        209
LOC:     782792     782703
ERR:          0
MIS:          0

This is a "real" box (not xenolinux) and, as you can see, I have irq
lines up  to 217!

This is with MSI/MSI-X enabled in kernel 2.6.x... With MSI disabled the
irq lines stay under 24.

127 is too low or this MSI stuff doesn't matter in a xen environment?

Regards,
Nuno Silva

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBKrcjOPig54MP17wRAhstAJ9I6nUvYu66qJSXxR72xn+TGG2JOwCgkgAz
6N3E3TuUtEo8od/bVJuz+sQ=
=FuGT
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285

Re: Re: [FIXED] probs with 3ware Controller

[Keir Fraser]

Xen IRQ/PCI code is based on Linux 2.4, which doesn't support MSI.

Even if we did, I believe those large IRQ numbers aren't really
IRQs. MSI devices don't have an IRQ because they send a trap vector
directly to the CPU.

This leads me to realise that guest OSes never really need to see real
IRQ numbers, so at some point I'll probably refactor that code. At
least for MSI devices, we can lie about the IRQ number.

 -- Keir


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Keir Fraser wrote:
> | Aha, lazy programming bit me. So the bug was nothing to do with BIOS
> | table parsing -- it was because the controllers's IRQ was greater than
> | 63. :-)
> |
> | Xen should now correctly virtualise IRQs all the way up to 127.
> 
> Hi!
> 
> I don't know if it's something that can cause trouble in the future so
> I'm posting it so that someone more fit to judge can decide:
> 
> puma:/home/nuno# cat /proc/interrupts
> ~           CPU0       CPU1
> ~  0:     419664     363307    IO-APIC-edge  timer
> ~  1:        945        699    IO-APIC-edge  i8042
> ~  7:          0          0    IO-APIC-edge  parport0
> ~  8:          4          0    IO-APIC-edge  rtc
> ~  9:          0          0   IO-APIC-level  acpi
> ~ 12:       9433       8376    IO-APIC-edge  i8042
> ~ 14:      38328      31705    IO-APIC-edge  ide0
> ~ 15:         27         24    IO-APIC-edge  ide1
> 169:      29959      23244   IO-APIC-level  uhci_hcd, uhci_hcd,
> radeon@PCI:1:0:0
> 177:          3          5   IO-APIC-level  uhci_hcd, bttv0, bt878
> 185:          0          0   IO-APIC-level  libata, uhci_hcd
> 193:          3          0   IO-APIC-level  ehci_hcd
> 201:        338          0   IO-APIC-level  Intel ICH5
> 209:          0          0   IO-APIC-level  ivtv: iTVC15/16 mpg2 encoder
> chip
> 217:       2609       2142   IO-APIC-level  SysKonnect SK-98xx, ohci1394
> NMI:        220        209
> LOC:     782792     782703
> ERR:          0
> MIS:          0
> 
> This is a "real" box (not xenolinux) and, as you can see, I have irq
> lines up  to 217!
> 
> This is with MSI/MSI-X enabled in kernel 2.6.x... With MSI disabled the
> irq lines stay under 24.
> 
> 127 is too low or this MSI stuff doesn't matter in a xen environment?
> 
> Regards,
> Nuno Silva
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFBKrcjOPig54MP17wRAhstAJ9I6nUvYu66qJSXxR72xn+TGG2JOwCgkgAz
> 6N3E3TuUtEo8od/bVJuz+sQ=
> =FuGT
> -----END PGP SIGNATURE-----
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285