Sven Kretzschmar
2004-Aug-13 22:01 UTC
[Xen-devel] Partial workaround for probs with 3ware Controller
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
Nuno Silva
2004-Aug-13 23:51 UTC
[Xen-devel] Re: Partial workaround for probs with 3ware Controller
-----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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Ian Pratt
2004-Aug-14 00:27 UTC
Re: [Xen-devel] Re: Partial workaround for probs with 3ware Controller
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Nuno Silva
2004-Aug-14 01:45 UTC
Re: [Xen-devel] Re: Partial workaround for probs with 3ware Controller
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser
2004-Aug-14 08:38 UTC
[Xen-devel] Re: Partial workaround for probs with 3ware Controller
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser
2004-Aug-14 15:42 UTC
Re: [Xen-devel] Re: Partial workaround for probs with 3ware Controller
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser
2004-Aug-14 17:53 UTC
Re: [Xen-devel] Re: Partial workaround for probs with 3ware Controller
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Sven Kretzschmar
2004-Aug-14 18:51 UTC
Re: [Xen-devel] Re: Partial workaround for probs with 3ware Controller
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
Keir Fraser
2004-Aug-15 08:44 UTC
Re: [Xen-devel] Re: Partial workaround for probs with 3ware Controller
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Sven Kretzschmar
2004-Aug-15 20:33 UTC
Re: [Xen-devel] Re: Partial workaround for probs with 3ware Controller
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
> > 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, > SvenAha, 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Sven Kretzschmar
2004-Aug-16 18:08 UTC
[Xen-devel] Re: [FIXED] probs with 3ware Controller
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
-----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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel