[Prism54-users] Re: Prism54-users digest, Vol 1 #174 - 11 msgs

[Luis R. Rodriguez]

Marc,

On Fri, Feb 27, 2004 at 08:34:31PM +0100, Marc Smeets wrote:
> On Tue, 2004-02-17 at 21:04, prism54-users-request@prism54.org wrote:
> > Hi,
> >=3D20
> > you also got problems with your 3com officeconnect? Ik keep getting
> > "soft reset timed out" errors just after loading the firmware. I
> > addressed the list before, and there were some other people having the
> > same problem. But unfortunatly the error is not fixed (yet).
>
>=20
> Try disabling acpi at boot time, acpi=3D3Doff in your kernel boot
> parameters. Let us know how it goes.

Just for the record, it's acpi=3Doff. Don't know how that "3D" got in
there.

>         Luis
>=20
> Disabling has no effect. It just will not work. I can't stand it because
> it should be working. Here is my dmesg after inserting the pccard.
> Kernel has been confgured using cvs of a couple of days ago and about 15
> others between the end of december and now.
> laptop cs: cb_alloc(bus 2): vendor 0x10b7, device 0x6001
> laptop PCI: Enabling device 02:00.0 (0000 -> 0002)
> laptop eth1: prism54 driver detected card model: 3COM 3CRWE154G72
> laptop eth1: islpci_open()
> laptop eth1: resetting device...
> laptop eth1: uploading firmware...
> laptop eth1: firmware uploaded done, now triggering reset...

> laptop eth1: device soft reset timed out

This means we asked the card to reset itself and somehow the hardware
never replied saying "Hey I reset myself!" (use "start" as synonymous to
"reset" here). If this happens it can be the signs of a faulty card.
Have you tested your card on another Operating System?

> laptop eth1: timeout waiting for mgmt response 100, trigging device
> laptop eth1: timeout waiting for mgmt response
> --- repeated 3 times ---
> laptop eth1: mgmt tx queue is still full
> --- repeated 15 times ---

> laptop eth1: mgt_commit has failed. Restart the device

The same... basically we never hear the card say, "Hey I finished doing
what I was supposed to do, what's next?!".

> laptop eth1: mgmt tx queue is still full
> laptop dhcpcd[2333]: dhcpStart: retrying MAC address request (returned
> 00:00:00:00:00:00)
> laptop dhcpcd[2333]: dhcpStart: retrying MAC address request (returned
> 00:00:00:00:00:00)

Pointless, at this point you should concentrate not on getting on IP but
looking for the reason why the card is not responding.

> laptop Assuming someone else called the IRQ
> laptop Assuming someone else called the IRQ
> laptop Assuming someone else called the IRQ

cat /proc/interrupts=20

I'd like to see how busy your IRQ line where your eth1 is. I bet its
jammed :)

> laptop eth1: hot unplug detected
> laptop eth1: removing device
> laptop eth1: islpci_close ()
> laptop dhcpcd[2333]: recvfrom: Network is down
> laptop dhcpcd[2333]: sendto: No such device
> laptop modprobe: modprobe: Can't locate module eth1
> laptop dhcpcd[2333]: dhcpStop: ioctl SIOCSIFADDR: No such device
> laptop modprobe: modprobe: Can't locate module eth1
> laptop dhcpcd[2333]: dhcpStop: ioctl SIOCSIFFLAGS: No such device
> laptop rc-scripts: Failed to bring eth1 up
> laptop cs: cb_free(bus 2)

Yeah, other pointless info.

> Although the irq should indicate that something is wrong (eth0=3Dlan nic
> wants the same irq) I still get the same errors without the module
> loaded for my lan nic.

Your IRQ may still be busy, and thus then the chances are that any
device on that line can be buggy/driver-buggy; although per PCI-spec
they should behave themselves while sharing the line.

Anyone here on the list have a prism54 card on an IRQ line that is HELL
BUSY and working flawlessly? If not share your experiences. It *could*
be our driver still not playing right sharing the line. Note though,
that on a busy IRQ line all devices and their drivers are suspects.

> It tryes to reset the device, but it can't. I don't get it.

Here's a TODO list:=20

1. Test with our latest Driver. Ie, like Feb 27's.
If it works, then the fix must've been disabling IRQs before requesting
a new IRQ (submitted by Denis Vlasenko on Feb 26). If it doesn't work
proceed with the next item.

2. Test your card on another box or OS and see how it works there.=20
If it works flawlessly on another Linux box, then we know it must be
one of your other devices/drivers on the IRQ line / related. If you are
able only to test it on Windows then that would only allow us to
determine if your card is not the problem. Note though: if you test it
on windows do thorough tests :)

Hopefully we'll be able to norrow the blame after this.

	Luis

--=20
GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E