WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen Kernel (3.0.2) breaks b44 module

To: <xen@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen Kernel (3.0.2) breaks b44 module
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Fri, 12 May 2006 10:57:25 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 12 May 2006 01:57:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <00a801c67599$bfc2ab50$fe02420a@BDR529>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <00a801c67599$bfc2ab50$fe02420a@BDR529>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx 
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel