Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]
On Mon, 31 Dec 2018 at 21:05, Mark Millard wrote: [...] > But if you have a form of hang-up that shows no sign of being tied > to kevent or hangs-up only sometimes, I'd be surprised if the __packed > change(s) would fix the issue. With the __packed-modified qemu-user-static, the amd64->armv7 crossbuilds does not hang anymore, but I get build failures instead. Interestingly enough, an unmodified qemu-user-static gets further along in a amd64->armv6 crossbuild, with only one reproducible hang. Cheers. -- Jonathan Chen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A reliable port cross-build failure (hangup) in my context (amd64->armv7 cross build, with native-tool speedup involved) [details of a specific qemu-arm-static source code problem]
On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports wrote: > > [Removing __packed did make the size and offsets match armv7 > and the build worked based on the reconstructed qemu-arm-static.] Thanks for the analysis Mark! I've been suffering quite a few hangups with my ports crossbuilds on amd64->armv7 on 12-STABLE, and I'll be trying your suggestions to see whether it resolves the issue. Cheers. -- Jonathan Chen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Failing to retrieve source tarballs for anything.
On 2 September 2018 at 05:25, Alex McKeever wrote: > After compiling PKG, when I go to ports to compile anything (my eMac can run > FreeBSD but not modern Linux due to the version of the Radeon GPU) it fails > to retrieve any of the source tarballs for any of the software, desktop > environments etc. I would like help to fix this, as I’d like to run something > current. > How old is your ports tree? It it up to date? What sort of problems are you seeing in fetching the port sources? Since no one else has reported any problems, it is most likely something to do with your local environment. Cheers. -- Jonathan Chen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Junior Kernel Hacker task: improve vnode-v_tag
While on the subject of VFS locking... Accessing devfs through a nullfs redirection causes a panic() due to locking issues. I haven't had time to look at this in detail yet, if somebody wants to jump up and fix the problem, feel free... -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3CXFE575CT-JP with NEWCARD doesn't work
On Mon, Sep 03, 2001 at 08:26:16PM +0900, Yoichi NAKAYAMA wrote: I just cvsup'ed and buildkernel with NEWCARD. Then my note book doesn't recognize MAC address of the card(3CXFE575CT-JP) following are concerning log for new kernel and old kernel(cvsup'ed 2-3 weeks ago) This looks like it could have been caused by my moving the default io range around. The IO port assigned to your card could be in conflict with something else. Try the following patch, which reverts to the old range. It would be really nice if the pci bus code could just do these assignments automagically... Index: pccbb.c === RCS file: /export/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.24 diff -u -r1.24 pccbb.c --- pccbb.c 2001/08/27 11:23:05 1.24 +++ pccbb.c 2001/09/05 15:44:45 @@ -1243,8 +1243,8 @@ start = end = tmp; break; case SYS_RES_IOPORT: - if (start = 0x1000) - start = 0x1000; + if (start = 0x3000) + start = 0x3000; if (end start) end = start; break; -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 3CXFE575CT-JP with NEWCARD doesn't work
On Tue, Sep 04, 2001 at 11:25:25AM +0200, Mark Santcroos wrote: Hi Warner, On Mon, Sep 03, 2001 at 10:24:31AM -0600, Warner Losh wrote: Looks like the mass commit broke stuff :-( I have a ToPIC100 chipset in my Toshiba Portege 3110CT. Last 'week' the updates broke my pcmcia support partially. Booting with a card inserted, inserted during boot or inserted after booting works fine just as before. But if I remove my card, I can't get it to work again without rebooting. The code doesnt seem to notice that I remove it, let alone re-insert it again. I read the printf saying the the support for this card may be broken, so it won't surprise you probably. Note that I tested src/sys/pccard/ from August 20 this morning and that worked fine. Please let me know if I can be of any help debugging/coding this. A complete dmesg from a verbose boot with both the successful and failed attempts would be a good start. It would also be useful to know what card you're using. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: In article [EMAIL PROTECTED], David O'Brien [EMAIL PROTECTED] wrote: What is the right mailing list to plead for more anoncvs mirrors? I doubt that pleading would help, but volunteering might. :-) For occational personal use, you may use [EMAIL PROTECTED]:/home/ncvs CVS_RSH=ssh The none ssh encryption method is available. You may use it by adding the appropiate lines to ~/.ssh_config I'd prefer it if people wouldn't overuse this, otherwise I might have to take it away, as the machine has limited bandwidth/resources. The repository syncs via cvsup twice a day. - You need an MFS filesystem with zillions of inodes, because anonymous CVS just hammers the disk with tiny lock files or state files. If they are on a drive that has moving parts, your system will tear itself apart. setting CVSREADONLYFS to 1 will prevent locking. This also means you don't need to give the anoncvs user write access to the lock directory. I presume this is where most of the anoncvs hogness lies, so this should make it go quite a bit faster. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more anoncvs servers Re: none
On Wed, Sep 05, 2001 at 11:41:13AM -0700, John Polstra wrote: In article [EMAIL PROTECTED], Jonathan Chen [EMAIL PROTECTED] wrote: On Wed, Sep 05, 2001 at 10:54:20AM -0700, John Polstra wrote: - You need an MFS filesystem with zillions of inodes, because anonymous CVS just hammers the disk with tiny lock files or state files. If they are on a drive that has moving parts, your system will tear itself apart. setting CVSREADONLYFS to 1 will prevent locking. This also means you don't need to give the anoncvs user write access to the lock directory. I presume this is where most of the anoncvs hogness lies, so this should make it go quite a bit faster. Nope. Anoncvs.freebsd.org already has/had CVSREADONLYFS set, but that did not eliminate the need for the MFS. If I recall correctly, remote CVS creates a shadow checkout tree of CVS/ directories and their administrative files for each client. That's what hammers the disk on the server. Yep, you are right. cvs writes the shadow stuff in /tmp. bleah. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/cardbus cardbus.c cardbus_cis.c cardbus_cis.h cardbusvar.h src/sys/dev/pccard card_if.m pccard.c pccardvar.h src/sys/dev/pccbb pccbb.c pccbbvar.h src/sys/sys rman.h
On Tue, Aug 28, 2001 at 12:07:10PM +0200, Michael Reifenberger wrote: On Mon, 27 Aug 2001, Jonathan Chen wrote: ... The fix I committed this morning should get around these issues. Please tell me if you run into any more problems. This works (now) for supported card like my ep0 (3COM...) but reboots for unsupported cards like my sandisk-smartmedia etc.. Is this by intention? My /etc/pccard.conf entries for this cards are: No, that is not by intention, nor can I tell what is wrong. I've tried sticking in unknown cards without ill effect. What would be helpful is if you supplied at least the panic message, and a backtrace when the panic occues. Or if this is a spontaneous reboot (which I really doubt), the dmesg from a verbose boot up to the point of reboot would be a first step... Also, /etc/pccard.conf is not used with newcard. You are using newcard, right? -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/dev/cardbus cardbus.c cardbus_cis.c cardbus_cis.h cardbusvar.h src/sys/dev/pccard card_if.m pccard.c pccardvar.h src/sys/dev/pccbb pccbb.c pccbbvar.h src/sys/sys rman.h
On Wed, Aug 29, 2001 at 01:05:30AM +0200, Michael Reifenberger wrote: On Tue, 28 Aug 2001, Jonathan Chen wrote: ... No, that is not by intention, nor can I tell what is wrong. I've tried sticking in unknown cards without ill effect. What would be helpful is if you supplied at least the panic message, and a backtrace when the panic occues. Or if this is a spontaneous reboot (which I really doubt), the dmesg from a verbose boot up to the point of reboot would be a first step... The boot message is attached in boot.txt. The backtrace is following tomorrow ( hopefully after building a new kernel) That won't be necessary. I now know what causes the panic. Actually, that's not really important. There's something strange going on with the second non-ep card insertion. Is this a memory card you're trying to use? -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Userbase of -current
On Sun, Aug 19, 2001 at 08:27:21AM -1000, Vincent Poy wrote: Or, simply unplug the harddrive from your laptop and plug it into another machine to do the install. When I fubar'ed my laptop's fs not too long ago, I hot-plugged my laptop harddrive into my desktop, issued an atacontrol reinit, and proceeded to merrily run sysinstall under a chroot. Of course, this is by no means the proper way, but it gets the job done... This idea will work since I can always use the notebook hDD with the adapter to the desktop but what does the atacontrol reinit do exactly since couldn't I just do a fresh install and just move the drive? atacontrol allows for hot-swapping of ata devices. Don't worry about it if you just plan on installing the laptop drive and turning on the computer. It'll act like any other normal drive. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Userbase of -current
On Sat, Aug 18, 2001 at 05:56:19PM -1000, Vincent Poy wrote: Speaking about -current and laptops, I know Warner mentioned the 3COM 3CXFEM656C working in -current but what's the proper way to install FreeBSD on a IBM ThinkPad 770Z with that NIC/Modem combo since the floppy disks don't seem to show the card on a 6162001 snapshot from current.FreeBSD.ORG. I was thinking about making a CD of the snapshot but is there a bootable ISO available? The FreeBSD boot floppies do not support NEWCARD. I could perhaps look into generating a newcard-kernel.flp once 4.4 is released and current.freebsd.org is fixed, if people thing that it's a good idea. But for now, you can either install FreeBSD from a DOS partition, or IIRC current.jp.freebsd.org generates bootable ISO's of -current. But I can't seem to connect right now so I can't check... Or, simply unplug the harddrive from your laptop and plug it into another machine to do the install. When I fubar'ed my laptop's fs not too long ago, I hot-plugged my laptop harddrive into my desktop, issued an atacontrol reinit, and proceeded to merrily run sysinstall under a chroot. Of course, this is by no means the proper way, but it gets the job done... -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NEWCARD support for aironet driver an(4) (kern/24854)
On Fri, Aug 17, 2001 at 01:11:03AM -0700, Sam Habash wrote: Any good reason why the the patch in this PR hasn't yet been committed to the tree? Can you clearify exactly what the problem is under newcard? Or is it just not supporting the newcard interface? I'm using my aironet (340) card under newcard without any problems. Of course, I'm running a patched newcard which fixes the reinsertion problem. (available at http://people.freebsd.org/~jon/newcard.patch.3) I'll get that committed when I get it mostly style(9) complient. Incidentally, does anyone know of a place which sells the LMC352 (pccard version of the 350 without built in antenna) in units of one at a reasonable price? I'm using the LMC342 right now and could almost kill for the increased power. But all the online stores I've seen either don't carry them or sells them in packs of 20... -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vty numbering with devfs
Pre-DEVFS, vty's were named ttyv0-ttyvf, ttyv10-ttyv1f, etc. When DEVFS is used, the vty's are numbered base-36 instead of base-16. This breaks X if the first 16 tty's are in use. What I want to know is whether we intended to implement this new scheme of tty numbering (to be consistant across all devices perhaps?) or whether this change was unintended. Either case, this should be a quick fix in either syscons or X. (Yes, I'm one of those loons who use 36 vty's) -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cardbus woes
On Thu, Dec 14, 2000 at 12:47:51PM -0800, John Baldwin wrote: In other news, while wandering through the cardbus code, I discovered that pccbb softc's have an internal mutex much to my surprise, and that they weren't quite being used properly AFAICT. In the pccb0 kthread, they were acquired/released without Giant. However, in the rest of the pccbb driver, they are acquired/released with Giant. This leads to lock order violations which could potentially deadlock the machine at some point. Also, the pccbb0 kthread holds the mutex across the entire card insertion and removal events, which is not quite right. Mutexes should only be held for short periods of time. As such, I've futzed around with the mutex operations in the pccbb driver some. It may not be completely correct, but I think it is an improvement. The patch for this can be found at http://www.FreeBSD.org/~jhb/patches/pccbb.patch. [I just now recalled your mentioning this a while back, so here's my much delayed response] Originally I had write the code with spl's, and at one point decided to convert them to mutex after finding spl's don't do anything. However, I don't claim to know a whole lot about mutexes or FreeBSD's implementation of it. Perhaps someone can point me to the Great Definitive Source? The first thing I'm unclear about is the deal with Giant. My understanding is that Giant is something one would acquire if he wanted to be really exclusive, or something like that. John - you mentioned I was acquiring/releasing with/without Giant - but I don't see how I'm doing things differently in and out of the kthread. The only place I mentioned Giant was right before kthread_exit, and that's necessary least kthread_exit calls panic() on me. On your patch, you acquire Giant at the start of the kthread - wouldn't that hold onto the lock until the thread exits, and make other things attempting to lock Giant block? As for the 'holding onto mutex for a long time' problem, I'm not sure if your solution is best. I originally put in the locks firstly because that's how NetBSD had it, and secondly so that card removal interrupts while card is still attaching wouldn't be lost. Your patched version allows for wakeup() to be called while insertion/removal is being processed. I've glanced through the code and didn't see anything that requires mutual exclusivity between the kthread the the interrupt handler, so perhaps a better solution would be to simply not use mutex at all? Comments? -- (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] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
On Tue, Nov 21, 2000 at 01:28:46PM -0700, Justin T. Gibbs wrote: That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner I'd rather have a seek/read interface than have a callback. As I see it, there are several ways this can be implemented, with several issues to consider. 1) How is the information passed? a) callback b) driver code calling cardbus_get_cistuple(dev, tuplenum) 2) When is the information passed? a) before probe (for callback) b) between probe and attach (for callback) c) automatically after attach (for callback) d) when child requests (for either) 3) When is the information read? a) Once when CIS is read and parsed initially by the bridge, and once when it's time to pass the info to child. b) Only once when CIS is read and parsed initially by the bridge. CIS info is stored in malloc'ed kernel memory c) This point may be moot if the cardbus bus does not read CIS, or if the bridge reading/parsing CIS step is delayed. Personally, I am somewhat torn between using callback or not, but I'm leaning more towards using an interface like cardbus_get_cistuple(). The reasoning behind this is that we may not know when, if ever, a driver would need CIS data. It might need this information in the probe code (unlikely for correctly implemented cardbus hardware and driver set, but IMHO we should keep the interface for cardbus and pccard the same, and pccard drivers might need this functionality) Having callbacks before attach that are actually useful might introduce a whole lot of messiness we don't need. As for point 3, I think that we should read the CIS prior to probe or attach of the child driver, and save the information in memory. My reasoning is that we can't be sure whether we can map and read the CIS after the driver is in control. For all we know the hardware might have been put into some mode where CIS reading would be turned off. True a driver programmer can get around that, but why not just stick it in the ivars to begin with? -- (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] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cardbus fixes
d allow the resource manager to allocate a range that doesn't appear to overlap with another allocation but does due to the bridges constraints. I might look into adding the concept of hierarchical resource pools to the resource manager so that, for example, the cardbus bridges pool will always grow in 4K increments from its parent resource pool. The parent would then grow according to its own requirements, etc. This will be very cool... -- (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] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My Cardbus and Xircom Realport Ethernet II 10/100 experience...
On Mon, Oct 23, 2000 at 10:17:06PM +0200, Ron Klinkien wrote: I run FreeBSD 5.0 on my Compaq Presario 1246 laptop including an Xircom Realport Ethernet II 10/100 cardbus card. My kernel includes: device cardbus device pccbb device xe [snip dmesg] According to files in /usr/src/sys/dev/xe/* the card is supported by the xe driver. What to do to get this card working? I have the feeling I got real close... Use device dc and miibus instead. The xe driver only support the 16bit version of the Realport. -- (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] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
On Sun, Sep 17, 2000 at 05:31:45AM -0700, David Greenman wrote: in summary: PR kern/18756 contains a patch (against -stable, alas, sorry) which fixes kernel hangs in the fxp driver on some laptops after a resume from suspend. while quite a few people appear to be using this patch successfully, it hasn't been committed -- david greenman had an entirely reasonable objection to one aspect of the patch's behavior. unfortunately, my knowledge of the kernel isn't sufficient to adequately address david's concerns, and though i've mailed him to ask for guidance twice over the past 4 months, i haven't received a response. that's probably my fault, i probably should have been mailing -current to being with. I can only find the 5/22 email regarding this, so I seem to have missed your second message. With over a thousand emails a day coming into my inbox, this shouldn't be too surprising. My response to the 5/22 message was this: ... This could be a problem. If an interrupt occurs, it must be acknowledged otherwise you'll be stuck in an infinit loop - PCI interrupts are level sensitive and must be cleared in the ISR. ... In short, while it may fix a hang in your laptop case, it opens the driver up to a hang if an unexpected interrupt occurs while IFF_RUNNING is clear. I think this is dangerous enough that I don't think the code should not be compiled as part of the standard driver. One just cannot ignore level- sensitive PCI interrupts. While programming for cardbus under FreeBSD, I ran into similar issues that when cards were powere down or removed where they would go into an infinite loop reading status registers. What actually happens is the register returns 0x whenever it is read, and the resolution I used was to check whether it is equal to 0x and do appropiate measures when it is found to be true. It looks from reading the PR that this might be a similar issue here -- that the card is powered down during suspend and of wakeup the reads to FXP_CSR_SCB_STATACK and cbp-cb_status returns 0xff. I believe this issue can be resolved by checking whether what was read equals 0x and abort the loop. This should be fairly safe as interrups shouldn't happen during powerdown (and can't be ack'ed anyway)... -- (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] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
On Wed, Aug 23, 2000 at 01:51:16PM -0500, Visigoth wrote:
Sorry for the cross post but
Would it be possible to revert the DPT commits made by peter on
Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the
dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have
production machines that need worlds built for some other updates as
well.. I would be happy to install a -CURRENT machine and help debug
until it works, but for right now, there is NO DPT support in -STABLE for
the DPT PM3334UW. I had a pr started, but haven't been able to get any
response from the current maintainer.
I am going to install a -CURRENT machine with a DPT in it and
start the process of working on the issue, but it would be nice if we can
keep -STABLE stable... ;)
I just updated on my -STABLE machine and ran into the same exact problem.
I also have on the machine SMP with APIC. The fix for this problem is
simple:
Index: dpt_pci.c
===
RCS file: /export/ncvs/src/sys/dev/dpt/dpt_pci.c,v
retrieving revision 1.17.2.1
diff -u -r1.17.2.1 dpt_pci.c
--- dpt_pci.c 2000/08/07 18:48:14 1.17.2.1
+++ dpt_pci.c 2000/08/26 21:40:26
@@ -106,7 +106,7 @@
}
rid = 0;
- irq = bus_alloc_resource(dev, SYS_RES_IRQ, rid, 0, ~0, 1, RF_ACTIVE);
+ irq = bus_alloc_resource(dev, SYS_RES_IRQ, rid, 0, ~0, 1, RF_ACTIVE |
+RF_SHAREABLE);
if (!irq) {
device_printf(dev, "No irq?!\n");
error = ENOMEM;
(Everybody in unison, say "Doh!")
Since this didn't change in the past two months, I'm guessing this was
caused by somebody else futzing with APIC. In any case, I don't see why
the DPT card shouldn't be allowed to share IRQs, and I'm now running the
latest -STABLE on my DPT card.
PS. Sorrry Matt for foiling your evil plot to get a free RAID card. ;)
--
(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] /_///
) No electrons were harmed during production of this message (
~
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
