Date: Thu, 04 Nov 1999 12:52:47 -0700 From: Warner Losh <imp@village.org> To: Will Andrews <andrews@technologist.com> Cc: mobile@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: laptop problems Message-ID: <199911041952.MAA09155@harmony.village.org> In-Reply-To: Your message of "Wed, 03 Nov 1999 23:12:37 EST." <3.0.6.32.19991103231237.008b0d40@mail.psn.net> References: <3.0.6.32.19991103231237.008b0d40@mail.psn.net> <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
In message <3.0.6.32.19991103231237.008b0d40@mail.psn.net> Will Andrews writes: : 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. That's usually an indication that something is wrong. : Plus, 'pccard0' is being used even : though it's not in the kernel currently loaded. It must be, or it won't work at all. : Here's the kernel output (that I found erroneous): : pcic: polling, can't alloc 0 : pcic: polling, can't alloc 0 Hardwire your pcic's irq to one that works. : 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. :\ Hmmm. Looks like I'll need access to the hardware to fix it then. Or Matt Dodd will. : 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. I woundn't expect it to. : 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. Patches? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911041952.MAA09155>