I have a new laptop (Dell 9400) that I am trying to work with Xen 3.0.
Xen works fine, runs windows XP under HVM.
But, the Xen kernel on Dom0 has a few problems with some of the hardware.
The network card is a Broadcom 4400 10/100BaseT.
Normally loading the b44 module gives this:
Apr 28 20:07:53 ipanema kernel: [4294683.185000] b44.c:v0.97 (Nov 30, 2005)
Apr 28 20:07:53 ipanema kernel: [4294683.185000] ACPI: PCI Interrupt
0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 177
Apr 28 20:07:53 ipanema kernel: [4294683.189000] eth0: Broadcom 4400
10/100BaseT Ethernet 00:14:22:f2:57:36
(under an Ubuntu kernel - 2.6.15-21-686 #1 SMP PREEMPT)
Works similarly under a vanilla 2.6.16.
When running a Xen patched 2.6.16 (as per
https://wiki.ubuntu.com/XenVirtualMachine/XenOnUbuntuDapper) or on the Xen
live CD, I get:
Apr 27 00:28:31 ipanema kernel: [ 20.038669] b44.c:v0.97 (Nov 30, 2005)
Apr 27 00:28:31 ipanema kernel: [ 20.038700] ACPI: PCI Interrupt
0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
Apr 27 00:28:31 ipanema kernel: [ 20.038710] b44: No usable DMA
configuration, aborting.
Apr 27 00:28:31 ipanema kernel: [ 20.040248] ACPI: PCI interrupt for
device 0000:03:00.0 disabled
Apr 27 00:28:31 ipanema kernel: [ 20.040251] b44: probe of 0000:03:00.0
failed with error -5
Am I doing something wrong?
The first difference here is that ACPI allocates IRQ 17 instead of IRQ
177. Hope that rings bells for somebody :-)
This is the relevant output of lspci -vvvv while it''s running under
2.6.16:
0000:03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0
100Base-TX (rev 02)
Subsystem: Dell: Unknown device 01cd
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort-
<MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin A routed to IRQ 177
Region 0: Memory at dcbfe000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
and the first two lines of lspci -nvvvv
0000:03:00.0 0200: 14e4:170c (rev 02)
Subsystem: 1028:01cd
Laptop is Dell 9400 Core Duo T2600 2Gb Ram , SATA 100Gb
The ultimate aim is to use the Intel VT extensions to run unmodified OSes
underneath, but that''s not that useful without networking.
Other hints of problems: noticable graphics corruption under framebuffer
console while running xen kernel. Also the cdrom is inaccessible under the
Xen Kernel.
cheers,
Woody
PS: I posted this to Xen-user previously but got no answers :-(
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
This ought to be attributed to the fact that B44 supports only 30-bit DMA addresses (and does special checking), but XenLinux doesn''t have a distinct DMA zone restricted to 24-bit addresses, and both dma_alloc_coherent() and swiotlb are restricting physical addresses to 31 bits only (at least the former could certainly look at the device''s DMA mask and use that value rather than hard-coding 31). Jan>>> <xen@wood.id.au> 12.05.06 09:57 >>>I have a new laptop (Dell 9400) that I am trying to work with Xen 3.0. Xen works fine, runs windows XP under HVM. But, the Xen kernel on Dom0 has a few problems with some of the hardware. The network card is a Broadcom 4400 10/100BaseT. Normally loading the b44 module gives this: Apr 28 20:07:53 ipanema kernel: [4294683.185000] b44.c:v0.97 (Nov 30, 2005) Apr 28 20:07:53 ipanema kernel: [4294683.185000] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 177 Apr 28 20:07:53 ipanema kernel: [4294683.189000] eth0: Broadcom 4400 10/100BaseT Ethernet 00:14:22:f2:57:36 (under an Ubuntu kernel - 2.6.15-21-686 #1 SMP PREEMPT) Works similarly under a vanilla 2.6.16. When running a Xen patched 2.6.16 (as per https://wiki.ubuntu.com/XenVirtualMachine/XenOnUbuntuDapper) or on the Xen live CD, I get: Apr 27 00:28:31 ipanema kernel: [ 20.038669] b44.c:v0.97 (Nov 30, 2005) Apr 27 00:28:31 ipanema kernel: [ 20.038700] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17 Apr 27 00:28:31 ipanema kernel: [ 20.038710] b44: No usable DMA configuration, aborting. Apr 27 00:28:31 ipanema kernel: [ 20.040248] ACPI: PCI interrupt for device 0000:03:00.0 disabled Apr 27 00:28:31 ipanema kernel: [ 20.040251] b44: probe of 0000:03:00.0 failed with error -5 Am I doing something wrong? The first difference here is that ACPI allocates IRQ 17 instead of IRQ 177. Hope that rings bells for somebody :-) This is the relevant output of lspci -vvvv while it''s running under 2.6.16: 0000:03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) Subsystem: Dell: Unknown device 01cd Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 Interrupt: pin A routed to IRQ 177 Region 0: Memory at dcbfe000 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- and the first two lines of lspci -nvvvv 0000:03:00.0 0200: 14e4:170c (rev 02) Subsystem: 1028:01cd Laptop is Dell 9400 Core Duo T2600 2Gb Ram , SATA 100Gb The ultimate aim is to use the Intel VT extensions to run unmodified OSes underneath, but that''s not that useful without networking. Other hints of problems: noticable graphics corruption under framebuffer console while running xen kernel. Also the cdrom is inaccessible under the Xen Kernel. cheers, Woody PS: I posted this to Xen-user previously but got no answers :-( _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 May 2006, at 08:57, <xen@wood.id.au> wrote:> I have a new laptop (Dell 9400) that I am trying to work with Xen 3.0. > > Xen works fine, runs windows XP under HVM. > > But, the Xen kernel on Dom0 has a few problems with some of the > hardware. > > The network card is a Broadcom 4400 10/100BaseT.B4400 can apparently DMA only to low 1GB of memory. Xen does not have an allocation pool that guarantees to only return memory that low. Hence you''re stuck for the time being. You could try working around by changing B44_DMA_MASK in drivers/net/b44.c to 0x7fffffff. Maybe it''ll turn out that only certain broken chips have this DMA limitation. Or you can hack the DMA pool to only return memory <1GB rather than <2GB (as it does currently). That''ll be a slightly bigger hack though. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 May 2006, at 09:57, Jan Beulich wrote:> This ought to be attributed to the fact that B44 supports only 30-bit > DMA addresses (and does special checking), but > XenLinux doesn''t have a distinct DMA zone restricted to 24-bit > addresses, and both dma_alloc_coherent() and swiotlb are > restricting physical addresses to 31 bits only (at least the former > could certainly look at the device''s DMA mask and > use that value rather than hard-coding 31).If dma_alloc_coherent isn''t doing that then it should be patched to do so. Even though it won''t help right now (since Xen will reject any requests more restricted than 31 bits) it will be needed when Xen is fixed to support basket-case hardware. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 12.05.06 11:03 >>> > >On 12 May 2006, at 09:57, Jan Beulich wrote: > >> This ought to be attributed to the fact that B44 supports only 30-bit >> DMA addresses (and does special checking), but >> XenLinux doesn''t have a distinct DMA zone restricted to 24-bit >> addresses, and both dma_alloc_coherent() and swiotlb are >> restricting physical addresses to 31 bits only (at least the former >> could certainly look at the device''s DMA mask and >> use that value rather than hard-coding 31). > >If dma_alloc_coherent isn''t doing that then it should be patched to do >so. Even though it won''t help right now (since Xen will reject any >requests more restricted than 31 bits) it will be needed when Xen is >fixed to support basket-case hardware.I agree, but this wouldn''t help this specific case, as the driver also (and mostly) uses pci_map_single on skb->data, which ends up in swiotlb. Since swiotlb does its allocation and range restriction during init, adjusting things here would likely be more complicated (or cost performance, if one wanted to further restrict the range upon use when needed). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 May 2006, at 10:15, Jan Beulich wrote:> I agree, but this wouldn''t help this specific case, as the driver also > (and mostly) uses pci_map_single on skb->data, > which ends up in swiotlb. Since swiotlb does its allocation and range > restriction during init, adjusting things here > would likely be more complicated (or cost performance, if one wanted > to further restrict the range upon use when > needed).When we support more flexible allocation in Xen, we''ll fix up the swiotlb to automatically try to grab some lower memory and/or allow the address mask for the physical memory in the swiotlb to be specified on the kernel command line. It sounds like 30-bit-addressable memory will be a good thing to try for automatically at init. I''d thought that 31-bit was really as bad as it got (except for old ISA-ish hardware with 24-bit limitations, which we''ll never support). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Keir Fraser (Keir.Fraser@cl.cam.ac.uk) wrote:> When we support more flexible allocation in Xen, we''ll fix up the > swiotlb to automatically try to grab some lower memory and/or allow the > address mask for the physical memory in the swiotlb to be specified on > the kernel command line.What''s the plan here? I''ve seen a few bug reports due to 28-bit device limitations (sound cards). thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12 May 2006, at 19:27, Chris Wright wrote:>> When we support more flexible allocation in Xen, we''ll fix up the >> swiotlb to automatically try to grab some lower memory and/or allow >> the >> address mask for the physical memory in the swiotlb to be specified on >> the kernel command line. > > What''s the plan here? I''ve seen a few bug reports due to 28-bit device > limitations (sound cards).Memory below 16MB isn''t going to happen, at least on 32-bit Xen. It''d be easier on 64-bit Xen as we don''t need separate notions of Xen heap and guest heap. We could support pretty much anything more than 24 bits though. It''s just a case of making the Xen buddy allocator more flexible and keep separate buddy lists for different address widths. If we fix for things like b4400, we should be fixed for the crappy sound cards too. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel