[Prism54-devel] [PATCH] prism54 snapshot fix for 2.6.11 & IRQ
line too busy
Luis R. Rodriguez
mcgrof at ruslug.rutgers.edu
Wed Mar 16 15:14:03 UTC 2005
On Mon, Mar 14, 2005 at 09:26:07PM +0100, Sebastian K?gler wrote:
> Hi,
>
> Attached patch should fix some driver model changes in the latest SVN snapshot
> offered on prism54.org.
>
> I'm being bitten by http://prism54.org/cgi-bin/bugzilla/show_bug.cgi?id=121 ,
> so I tried the latest snapshot (patch-2.6-prism54-svn-latest from yesterday's
> svn, according to the date apache showed). This snapshot caused me compile
> errors in pci_save_state and pci_restore_state, as well as unresolved symbols
> using 2.6.11:
>
> prism54: Unknown symbol pci_dma_sync_single
>
> With attached patch, it compiled fine and I was able to modprobe prism54.
>
> However, the IRQ line too busy is still there. dmesg says the following:
>
> ap_net_ioctl: Ioctls for AP devices are NOT supported in this driver.
> eth1: resetting device...
> eth1: uploading firmware...
> eth1: firmware version: 0.8.0.0
> eth1: firmware upload complete
> eth1: no 'reset complete' IRQ seen - retrying
> eth1: no 'reset complete' IRQ seen - retrying
> eth1: interface reset failure
> prism54: Your card/socket may be faulty, or IRQ line too busy :(
> ap_net_ioctl: Ioctls for AP devices are NOT supported in this driver.
> eth1: resetting device...
> eth1: uploading firmware...
> eth1: firmware version: 1.0.4.3
> eth1: firmware upload complete
> eth1: no 'reset complete' IRQ seen - retrying
> eth1: no 'reset complete' IRQ seen - retrying
> eth1: interface reset failure
> prism54: Your card/socket may be faulty, or IRQ line too busy :(
>
>
> I'd like to know if anyone is working on that issues, I'm afraid it exceeds my
> skills to fix it myself, but I'd be happy if I can help (testing, e.g.).
>
> My card is a
>
> 0000:07:00.0 Network controller: 3Com Corporation 3com 3CRWE154G72 [Office
> Connect Wireless LAN Adapter] (rev 01)
> Subsystem: 3Com Corporation: Unknown device 6001
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping-
> SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
> <MAbort- >SERR- <PERR-
> Latency: 80 (2500ns min, 7000ns max), Cache Line Size: 0x20 (128 bytes)
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at 21000000 (32-bit, non-prefetchable) [size=8K]
> Capabilities: [dc] Power Management version 1
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> /proc/interrupts says:
>
> CPU0
> 0: 796726 XT-PIC timer
> 1: 1125 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 3: 77 XT-PIC ohci1394
> 5: 5716 XT-PIC yenta, uhci_hcd
> 7: 0 XT-PIC uhci_hcd
> 8: 4 XT-PIC rtc
> 9: 1858 XT-PIC acpi
> 11: 5 XT-PIC yenta, eth1, Intel 82801CA-ICH3
> 12: 119 XT-PIC i8042
> 14: 11265 XT-PIC ide0
> 15: 23 XT-PIC ide1
> NMI: 0
> LOC: 0
> ERR: 0
> MIS: 0
>
>
> I've uploaded a little more info to http://vizzzion.org/~sebas/oc/
>
> I have the above issue with a handmade 2.6.11 and also with a debian-provided
> 2.6.10.
>
> Is it a good idea to file a bug similar to the above mentioned to kernel.org's
> bugzilla? (prism54.org's 121 is about 2.4, so the issue might be new to 2.6
> users).
> Is there a workaround for this, so I can use the card in the meantime?
The patch you provided does fix the compile errors but I'm still waiting
to hear from netdev on how we should deal with pci_dma_sync_single for
2.4 (nasty ifdef, inline routine, or just use non-single dma routine).
This should be no bug although I should fix the message and mention that
you most likely have a softmac card which is not supported. 3com started
selling the same card model with the same PCI ID and even with the same
FCC ID but with a different chipset. I've purchased a card from 3com to
confirm this and its true. Anyone know if this is legal? I'm looking
into it and haven't yet found info to tell me whether this is or not.
Basically -- you just have a softmac card. A similar patch will be
commmitted but later after netdev review on how to deal with 2.4
backporting.
Thanks,
Luis
--
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84 A34A 6ADD 4937 E20A 525E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://prism54.org/pipermail/prism54-devel/attachments/20050316/3c4fec94/attachment.pgp
More information about the Prism54-devel
mailing list