Date: Wed, 03 Nov 1999 23:12:37 -0500 From: Will Andrews <andrews@technologist.com> To: Warner Losh <imp@village.org> Cc: mobile@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: laptop problems Message-ID: <3.0.6.32.19991103231237.008b0d40@mail.psn.net> In-Reply-To: <199911012325.QAA09846@harmony.village.org> References: <Your message of "Mon, 01 Nov 1999 18:15:13 EST."<3.0.6.32.19991101181513.0081bb40@mail.psn.net> <3.0.6.32.19991101181513.0081bb40@mail.psn.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 04:25 PM 11/1/99 -0700, you wrote: >What's your eeporm problem? I have fixed and committed patches to the >ep driver where the card wasn't being identified. I thought I sent you something about this before.. My card IS getting recognized, and seems to be on the appropriate port, BUT, I think memory pointers are getting mixed up, because it's returning the _WRONG_ MAC address. Plus, 'pccard0' is being used even though it's not in the kernel currently loaded. Here's the kernel output (that I found erroneous): pcic: polling, can't alloc 0 pcic: polling, can't alloc 0 Here's the pccardd output: ep0: <3Com 3C574B, Megahertz 3CCFE574BT or Fast Etherlink 3C574-TX> at port 0x240-0x25f irq 10 slot 0 on pccard0 ep0: Ethernet address 4b:57:4b:57:4b:57 ep0: strange connector type in EEPROM, assuming AUI Yes, I have a 3Com 3CCFE574BT that has worked with -CURRENT before. And yes, the kernel sources (at least relevant to pccard) is up to date, including your EEPROM an pcic_p.c (or whatever) fixes. The devclass_alloc_unit() problem was fixed by the pcic_p.c fix, but EEPROM problems lurk. :\ >Me too. I'll know when I get home tonight. Well? *cross fingers* :) --- It's been a few days since I wrote this reply. I've been hacking /sys/dev/ep/if_ep.c, trying to figure out what's wrong. I originally thought the ep_get_macaddr() function's for() loop was erroneous in that it uses an integer `i' in the for loop instead of a u_int_16. That theory didn't go (still got the wrong MAC addresses.. something's not right.), however, I did find out that the polling thing was caused by pcic's IRQ not being assigned properly. I hardwared the pcic_irq = 11; in my /sys/pccard/pcic.c, and that removed the error. So, somebody borked pcic.c in this respect somewhere (haven't looked further yet), although this hardwire didn't fix the MAC address problem. Then I had a look at the odd EEPROM problem, which seems to have been caused by erroneous values in IFM_ETHER_10T, etc. I put in a debugging device_printf(), and found my ifm.ifmedia (whatever's in the switch() with a default: that outputs the error message above (it's in /sys/dev/ep/if_ep.c)) to equal 0. What the hell's wrong with this thing? IFM_ETHER_10T should be 0, judging by the array definition given. Perhaps you meant to use an enum? Anyway, I plugged in a case 0: to see if that fixed the problem, and it did. So, something's borked with that too. /me will check CVS logs tomorrow to see if in one place or another ep_get_macaddr(), etc. got borked somehow. Thoughts / Comments? -- Will Andrews <andrews@technologist.com> GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.6.32.19991103231237.008b0d40>