Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Tue, Jan 18, 2000 at 02:48:25AM -0800, Frank Mayhar wrote:
Interestingly, I rebuilt world with the latest pccardd changes and,
suddenly, the 589D started working perfectly. Unfortunately, the
574BT doesn't work at all now. It appears to configure properly, but
it doesn't transmit or receive.
My 574BT works if you hardcode the pccardd IRQ to 9. I did this by
editing rc.pccard and replaced the pccard line with:
pccardd -i 9 -f ${pccard_conf}
It works fine for me. I think there's something wrong with pccardd, and
that's why it keeps using IRQs I don't even have specified in
pccard.conf. I should do more research on this, though.
--Will
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
Warner Losh wrote:
In message [EMAIL PROTECTED] Will Andrews writes:
: On Tue, Jan 18, 2000 at 02:48:25AM -0800, Frank Mayhar wrote:
: Interestingly, I rebuilt world with the latest pccardd changes and,
: suddenly, the 589D started working perfectly. Unfortunately, the
: 574BT doesn't work at all now. It appears to configure properly, but
: it doesn't transmit or receive.
: My 574BT works if you hardcode the pccardd IRQ to 9. I did this by
: editing rc.pccard and replaced the pccard line with:
:
: pccardd -i 9 -f ${pccard_conf}
:
: It works fine for me. I think there's something wrong with pccardd, and
: that's why it keeps using IRQs I don't even have specified in
: pccard.conf. I should do more research on this, though.
Are you sure that pccard_conf isn't set to /etc/pccard.conf.sample?
I've *NEVER* seen pccardd use interrupts that it wasn't told about,
and I've tried many times to reproduce this.
Just for the record, it turned out that the problem I saw with the 574BT
was cured by moving pcic0 from irq 11 (which the PCI bus had appropriated)
to irq 10. I put the 574 on my last free IRQ, 3. (Don't you hate laptops?)
Many, many thanks to Matt Dodd and Warner Losh for their help, patience,
suggestions and code! They were terrific.
Now I'm looking forward to the newcard cardbus support so I can finally use
the 575BT which came with the laptop. (Tapping fingers impatiently. :-)
--
Frank Mayhar [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
In message [EMAIL PROTECTED] Will Andrews writes:
: On Tue, Jan 18, 2000 at 02:48:25AM -0800, Frank Mayhar wrote:
: Interestingly, I rebuilt world with the latest pccardd changes and,
: suddenly, the 589D started working perfectly. Unfortunately, the
: 574BT doesn't work at all now. It appears to configure properly, but
: it doesn't transmit or receive.
:
: My 574BT works if you hardcode the pccardd IRQ to 9. I did this by
: editing rc.pccard and replaced the pccard line with:
:
: pccardd -i 9 -f ${pccard_conf}
:
: It works fine for me. I think there's something wrong with pccardd, and
: that's why it keeps using IRQs I don't even have specified in
: pccard.conf. I should do more research on this, though.
Are you sure that pccard_conf isn't set to /etc/pccard.conf.sample?
I've *NEVER* seen pccardd use interrupts that it wasn't told about,
and I've tried many times to reproduce this.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
In message [EMAIL PROTECTED] Frank Mayhar writes: : Now I'm looking forward to the newcard cardbus support so I can finally use : the 575BT which came with the laptop. (Tapping fingers impatiently. :-) Hope you are tapping something soft :-) Wouldn't want you to hurt yourself, or have others hurt you from the annoying racket :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Monday, 17 January 2000 at 8:24:20 -0800, Frank Mayhar wrote: Sorry for the delay on this reply; I was going over some old email and came across this only a week late. Jonathan Chen wrote: With what little pccard/ethernet programming experiences I've had, this problem seems to be caused by the interrupt for the card getting lost somewhere before getting processed by the handler. The reason you still get traffic is because of the watchdog. (Try uncommenting the commented out lines in sys/dev/ep/if_ep.c in the function ep_if_watchdog(), you should start seeing lots of kernel messages saying "ep: watchdog".) After looking briefly at the ep files, I saw something that doesn't seem right. In sys/dev/ep/if_ep_pccard.c around line 176, there's a comment that says "Fake IRQ must be 3". Now maybe the card requires it, or maybe the original author just didn't have anything on IRQ 3, I don't know. So, I'd suggest turning off com2 or whatever you have on irq3, -or- change the "fake irq" to something else you do have free on the next line (ie, 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I hope Warner gets some more free time. ;) According to the docs, this "Fake IRQ must be 3" is legitimate. The IRQ programmed into the resource config register in window 0 _must_ be 3: "any other value will disable the IRQ line drivers." (Quoted from the doc. As for the other problem with collisions, I did a search on the word collision on sys/dev/ep/if_ep.c, and found only one mention at around line 620. The comment says "TXS_MAX_COLLISION - we shouldn't get here". I suspect it does get there, so I suggest putting a printf there to find out. I also suspect that the card may require a reset or some other stuff if and when it "gets there". If that's the case, someone else with the specs on the 589 cards can look that up and do it. I can state pretty categorically that, at least in my case, we're _not_ getting here. As I said in an earlier email, I'm still having interrupt problems with the 589 (I have a 3C589D) and the 574BT. I haven't tracked it down yet, but I'm hunting. I do know, at least, that I'm not receiving _any_ interrupts from either card. So far I don't know why. The fact it's appearing with two different cards which work for other people tends to point away from the cards and towards some common factor, such as your laptop. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
Greg Lehey wrote: The fact it's appearing with two different cards which work for other people tends to point away from the cards and towards some common factor, such as your laptop. True. Interestingly, I rebuilt world with the latest pccardd changes and, suddenly, the 589D started working perfectly. Unfortunately, the 574BT doesn't work at all now. It appears to configure properly, but it doesn't transmit or receive. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Tue, 18 Jan 2000, Frank Mayhar wrote: Interestingly, I rebuilt world with the latest pccardd changes and, suddenly, the 589D started working perfectly. Unfortunately, the 574BT doesn't work at all now. It appears to configure properly, but it doesn't transmit or receive. Ok, I need the output of 'dmesg', 'ifconfig -a', your kernel config, and 'ident /sys/dev/ep/*'. I suspect you'll find that the 574BT may be in the 'OACTIVE' state as indicated in the flags section of ifconfig. Please try tcpdumping on ep0 and on another box (using the MAC address of the 574) and seeing if any traffic is visable. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
Sorry for the delay on this reply; I was going over some old email and came across this only a week late. Jonathan Chen wrote: With what little pccard/ethernet programming experiences I've had, this problem seems to be caused by the interrupt for the card getting lost somewhere before getting processed by the handler. The reason you still get traffic is because of the watchdog. (Try uncommenting the commented out lines in sys/dev/ep/if_ep.c in the function ep_if_watchdog(), you should start seeing lots of kernel messages saying "ep: watchdog".) After looking briefly at the ep files, I saw something that doesn't seem right. In sys/dev/ep/if_ep_pccard.c around line 176, there's a comment that says "Fake IRQ must be 3". Now maybe the card requires it, or maybe the original author just didn't have anything on IRQ 3, I don't know. So, I'd suggest turning off com2 or whatever you have on irq3, -or- change the "fake irq" to something else you do have free on the next line (ie, 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I hope Warner gets some more free time. ;) According to the docs, this "Fake IRQ must be 3" is legitimate. The IRQ programmed into the resource config register in window 0 _must_ be 3: "any other value will disable the IRQ line drivers." (Quoted from the doc. As for the other problem with collisions, I did a search on the word collision on sys/dev/ep/if_ep.c, and found only one mention at around line 620. The comment says "TXS_MAX_COLLISION - we shouldn't get here". I suspect it does get there, so I suggest putting a printf there to find out. I also suspect that the card may require a reset or some other stuff if and when it "gets there". If that's the case, someone else with the specs on the 589 cards can look that up and do it. I can state pretty categorically that, at least in my case, we're _not_ getting here. As I said in an earlier email, I'm still having interrupt problems with the 589 (I have a 3C589D) and the 574BT. I haven't tracked it down yet, but I'm hunting. I do know, at least, that I'm not receiving _any_ interrupts from either card. So far I don't know why. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
In message [EMAIL PROTECTED] Jonathan Chen writes: : "Fake IRQ must be 3". Now maybe the card requires it, or maybe the : original author just didn't have anything on IRQ 3, I don't know. So, I'd : suggest turning off com2 or whatever you have on irq3, -or- change the : "fake irq" to something else you do have free on the next line (ie, : 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I : hope Warner gets some more free time. ;) I don't think this is the problem. The pccard interface has one interrupt pin that is mapped by the pcic bridge (or some other pccard/cardbus bridge) to the main bus of the system. I didn't change that from the 3.x driver... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Friday, 7 January 2000 at 23:46:49 +1100, Darren Reed wrote: In some email I received from Warner Losh, sie wrote: In message [EMAIL PROTECTED] Josef Karthauser writes: : My 3c589d works just fine now, along with suspend/resume :) (under 4.0). The issue with the 3c589d is with its speed. It is falling back to the timeout routine to send data rather than getting an interrupt when the tx has happened (or something like this, I'm reporting second hand stuff). Whatever it is, results in ping times being 1000ms then 10ms then 1000ms then 10ms...when it responds. This doesn't look typical of the problems we've been discussing. First, they appear to occur more with -CURRENT, and secondly they don't affect the ping times. What I've been seeing is that everything is fine until a collision occurs, after which something times out and it takes a 1 second timeout before it continues. It's easiest to see with long ftp transfers. i.e. it's a mistake to use FreeBSD 3.x with the 3c589d. Mine worked fine under 3.x. The problem seems to have crept in in about October last year (1999). On Friday, 7 January 2000 at 12:52:28 -0800, Mike Smith wrote: The issue with the 3c589d is with its speed. It is falling back to the timeout routine to send data rather than getting an interrupt when the tx has happened (or something like this, I'm reporting second hand stuff). Whatever it is, results in ping times being 1000ms then 10ms then 1000ms then 10ms...when it responds. This is typical for interrupt misconfiguration for this driver. When you get the interrupt configuration right, it works fine. (No, getting the interrupt configuration right is not a trivial task.) That may be the answer for Darren's problem. It's definitely not the case for the ones we have been discussing on -mobile. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
[[ Moved to just current ]] In message [EMAIL PROTECTED] Greg Lehey writes: : That may be the answer for Darren's problem. It's definitely not the : case for the ones we have been discussing on -mobile. There are definitely known issues with the ep0 driver. Right now it doesn't interrupt quite right on Rx packets. That's the majority of the problems in current driver, at least with the 3c589D that I have. I see only about 150kBps from the card. I've not had time to deal with looking for this problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3C589 problems (was: 4.0 code freeze scheduled for Jan 15th)
On Sun, Jan 09, 2000 at 09:26:45PM -0700, Warner Losh wrote: [[ Moved to just current ]] In message [EMAIL PROTECTED] Greg Lehey writes: : That may be the answer for Darren's problem. It's definitely not the : case for the ones we have been discussing on -mobile. There are definitely known issues with the ep0 driver. Right now it doesn't interrupt quite right on Rx packets. That's the majority of the problems in current driver, at least with the 3c589D that I have. I see only about 150kBps from the card. I've not had time to deal with looking for this problem. With what little pccard/ethernet programming experiences I've had, this problem seems to be caused by the interrupt for the card getting lost somewhere before getting processed by the handler. The reason you still get traffic is because of the watchdog. (Try uncommenting the commented out lines in sys/dev/ep/if_ep.c in the function ep_if_watchdog(), you should start seeing lots of kernel messages saying "ep: watchdog".) After looking briefly at the ep files, I saw something that doesn't seem right. In sys/dev/ep/if_ep_pccard.c around line 176, there's a comment that says "Fake IRQ must be 3". Now maybe the card requires it, or maybe the original author just didn't have anything on IRQ 3, I don't know. So, I'd suggest turning off com2 or whatever you have on irq3, -or- change the "fake irq" to something else you do have free on the next line (ie, 0x3000- 0xa000 if you have IRQ10 free). If this works, great... if not, I hope Warner gets some more free time. ;) As for the other problem with collisions, I did a search on the word collision on sys/dev/ep/if_ep.c, and found only one mention at around line 620. The comment says "TXS_MAX_COLLISION - we shouldn't get here". I suspect it does get there, so I suggest putting a printf there to find out. I also suspect that the card may require a reset or some other stuff if and when it "gets there". If that's the case, someone else with the specs on the 589 cards can look that up and do it. (I'll have to admit, I looked only briefly, and know virtually nothing about how the pccard stuff works on freebsd, have no ep card, nor ever looked at the documentation for it, so what just said may be completely wrong -- don't be surprised if it doesn't work.) -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\Jonathan Chen [EMAIL PROTECTED] /_/// ) The surest protection against temptation is cowardice. --MT ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
