Re: 3Com 3c905C-TX
Out of curiosity, do only 3c509's exibit this behavior, or is this the core problem with 3c59x's as well? My experiences have not been consistent with these cards, and I had assumed it was due to buggy code in the 3-Com chipset. I've noticed flaky behavior from the Vortex [3c59x] card as well. Just now I have been wrestling with an ISA 3c509 which has a Lucent 40-01304 chip on it. At first the card was detected, and later not detected [on a different OS.]I vote for the fxp's as well, I've had hardly any problems with them. Is there a way to lock down the card by hacking the driver, so it won't try to auto-negotiate the connection? On Wed, 1 May 2002, Sten wrote: On Wed, 1 May 2002, Guido Kollerie wrote: snip Unfortunately the switch is unmanaged hence I am not able to explicitely set the switch to 100 Mbits full-duplex. Using ifconfig to set the nic to 10baseT/UTP and then back to 100baseTX full-duplex doesn't help. Only a reboot will bring the NIC back to 100 Mbits full duplex mode. Please note that due to vagaries in the auto-negotiation spec 3com and cisco dont work well together. And 3coms ( on linux atleast ) have the added bonus of sometimes deciding to change speed/duplex just for the heck of it. The only way to use them reliably is to force both the card and the switch. We came to the conclusion that fxp's are a nicer option. IMHO just creating a reliable and clearly defined auto-negotiation protocol will do more for ethernet speed than gigabit ethernet :). -- Sten Spans What does one do with ones money, when there is no more empty rackspace ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why would my IRQs suddenly move?
This sounds like a necessary consequence of the "PCI crapshoot." On Tue, 23 Jan 2001, Mike Meyer wrote: Mike Smith [EMAIL PROTECTED] types: After installing a fresh cvsup last Sunday, I find that my usb printer quit working. Some investigation shows that this is because the uhci and fxp are now on the same IRQ. Why would this cause your printer to stop working? Have you determined that this is actually the case, or did you only just notice that they're on the same IRQ? I don't know why it would cause the printer to stop working. I didn't just notice that the IRQs were the same - I checked for it specifically. What I noticed was that the printer wasn't working, and lpq showed it as possibly offline. When I first installed the USB printer, I had the exact same problem - until I changed changed the hardware config so that the fxp and uhci weren't using the same IRQ. That's why I checked for this case. Anyone got a clue as to why the IRQ would change? Is there anything in FreeBSD that could change it? Has it actually changed? I'm still trying to figure that one out. I haven't been able to get a config with the fxp and uhci on different IRQs. I've got a doctor's appointment, after which I'm going to pull the fxp and see how that goes. Thanx, mike -- Mike Meyer [EMAIL PROTECTED]http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
Just out of curiousity, has anyone documented how much of a performance hit there is with the i386 code enabled in the kernel? Regards, Glen Gross On Thu, 18 Jan 2001, Mike Smith wrote: That's one of the big reasons that we're 4.x based right now rather than 3.x based, despite 4.x's slightly larger memory footprint. That and 4.x's much better c++ compiler. Well, Warner, I've never done embedded systems. So, tell me, do they actually use any C++ code in embedded systems? C++ has a rather high overhead as far as disk space memory goes. I would imagine that 99%+ of embedded systems do not use C++ code except perhaps for a very small amount of the code. You have a very vivid imagination. Unfortunately, imagination isn't very helpful here; the whole idea is to do stuff that's actually useful, not just what we'd imagine might be useful. And in that regard, a *lot* of application programming (which includes programming for embedded systems) is done using c++ compilers. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
OK, but it makes sense to me that for certain applications, it makes sense to utilize the old hardware since it is still readily available and cheap. In particular, why not install FreeBSD on i386 for use in routers? In many cases there is a negligible performance advantage from using faster CPU's. Sure, we can build our own kernels for such applications, but if there is an i386 kernel available, it's a plus for FreeBSD in my opinion. Otherwise I would be inclined to try to put together a "distribution" of FreeBSD optimized for low-end systems. But I suspect PicoBSD already fits that requirement. On Tue, 16 Jan 2001, Will Andrews wrote: On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: Wont this make installing using sysinstall a bit hard? I know the generic kernel includes all the CPU lines, so that all cpu's are recognized... so are you going to just take this line out of the generic kernel, and have a special kern.flp disk with a generic kernel that only has the i386 support in it? I don't think it's worth the effort. By the time 5.0-RELEASE goes out, the 386 will have been around for over 10 years (actually I think it has already reached that point and gone beyond). There are not likely to be many more installs of FreeBSD on 386's, let alone 5.x installs. People who *really* want to install 5.x on a 386 can generate their own kernel and such. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
AWE-64 no longer detected...
Since my last cvsup, my Soundblaster AWE-64 card is no longer detected. unknown: Audio can't assign resources unknown: Game can't assign resources unknown0: WaveTable at port 0x620-0x623 on isa0 Has anyone else seen this problem? Below is the full dmesg output. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.1-RC2 #10: Fri Nov 10 20:44:42 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/clonix.sound Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (166.40-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 67108864 (65536K bytes) avail memory = 59555840 (58160K bytes) Preloaded elf kernel "kernel" at 0xc03e3000. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd000-0xd01f irq 9 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port 1 power on failed, IOERROR uhub0: port 2 power on failed, IOERROR chip1: Intel 82371AB Power management controller port 0x5f00-0x5f0f at device 7.3 on pci0 pci0: S3 ViRGE DX/GX graphics accelerator at 9.0 irq 0 ahc0: Adaptec aic7860 SCSI adapter port 0xd800-0xd8ff mem 0xffeef000-0xffee irq 11 at device 10.0 on pci0 ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs isa0: too many dependant configs (8) isa0: unexpected small tag 14 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ep0: 3Com 3C509-TPO EtherLink III at port 0x300-0x30f irq 10 on isa0 ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: eeprom failed to come ready. ep0: Ethernet address 00:00:00:00:00:00 ex: WARNING: board's EEPROM is configured for IRQ 3, using 5 ex0: Intel EtherExpress(TM) PRO Adapter at port 0x200-0x20f iomem 0xc8000-0xcbfff irq 5 on isa0 ex0: Ethernet address 00:aa:00:b8:cc:e8 unknown: Audio can't assign resources unknown: Game can't assign resources unknown0: WaveTable at port 0x620-0x623 on isa0 ep1: 3Com 3C509B-TPO EtherLink III (PnP) at port 0x210-0x21f irq 12 on isa0 ep1: Ethernet address 00:60:97:50:cf:72 BRIDGE 990810, have 11 interfaces -- index 1 type 6 phy 0 addrl 6 addr 00.00.00.00.00.00 -- index 2 type 6 phy 0 addrl 6 addr 00.aa.00.b8.cc.e8 -- index 3 type 6 phy 0 addrl 6 addr 00.60.97.50.cf.72 IPsec: Initialized Security Association Processing. IPv6 packet filtering initialized, default to accept, unlimited logging ad0: 6149MB WDC AC36400L [13328/15/63] at ata0-master using UDMA33 acd0: CDROM CD-ROM CDU4011 at ata1-master using PIO4 Waiting 7 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: FUJITSU M2684S-512 2035 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 507MB (1039329 512 byte sectors: 64H 32S/T 507C) ex0: not multicast capable, IPv6 not enabled ex0: promiscuous mode enabled To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Intel Etherexpress support?
Is it possible to use the old Intel EtherExpress-16 cards with FreeBSD? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
eexpress.c
Is it possible to use an old Intel EtherExpress-16 card with FreeBSD? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
