Re: Realtek RTL8110 (SB) watchdog timeout.
On Fri, Aug 01, 2008 at 03:12:05AM +0200, Eugene Butusov wrote: Hi, After updating from 7.0-RELEASE to STABLE (around 15/08) my NIC refuses to handle large file transfers. pciconf -lv [EMAIL PROTECTED]:4:0:0: class=0x02 card=0x001a6409 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller' class = network subclass = ethernet Log messages: re: watchdog timeout re: link changed to DOWN re: link changed to UP When someone tried to copy large (i.e. 700MB) file from samba share (local gigabit network) or ftp (same LAN), the NIC was reseted. For a while host was not accesible from the network, and then it came back with log messages shown above. I've tried to tune samba socket options (SO_RCVBUF=16384 SO_SNDBUF=16384), and this fixed the problem for samba users. One interesting thing: copying file to windows XP machine worked fine, while Vista (SP1 x64) caused the problem. What solved the problem definitely was disabling TSO for re0 (ifconfig One of developer also reported TSO issue. But his hardware was a plain 8169S. Given that you're seeing TSO issues on 8110SB I'm afraid all RealTek 8169/8110 series may suffer from the TSO issues. Under certain circumtances, the controller generates corrupted frames for TSO case and this seem to be resulted in watchdog timeouts. I'm not sure recent PCIe based 8168/8110 family also suffers from the issue as no one have complained the issue. re0 -tso). I haven't notice any performance drop and it works fine, but I'm just curious what happened to the 'good' driver from 7.0-RELEASE. I don't think re(4) in 7.0-RELEASE is bug free. If you check commit logs in RELENG_7 you may see what I mean. At the time of re(4) overhauling, I added TSO to re(4). Generally TSO shall not increase Tx performance but TSO significantly saves CPU cycles for TCP bulk transfers. The saved CPU power could be used for other tasks. Anyway, thanks for reporting, I'll disable TSO in next monday. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
em(4) on FreeBSD is sometimes annoying
Hello, I don't remember anymore when I reported it the first time. I think it was around 4.x or something like that. The em(4) bug is still there after years. Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems. I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's extremely annoying on Thinkpads, when you just want to plug in your laptop somewhere. -- Martin signature.asc Description: PGP signature
Re: em(4) on FreeBSD is sometimes annoying
Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? I'm afraid I don't see your problem at all. My em interfaces appear as they should, even if not connected to a switch. And when I connect an em interface to a switch, I get link and things work as expected. Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems. This may well be the case - but not that the em driver handles several different chip models. You may have a problem which is specific to one or a few chip models. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
On Fri, Aug 01, 2008 at 02:20:05PM +0200, Martin wrote: I don't remember anymore when I reported it the first time. I think it was around 4.x or something like that. The em(4) bug is still there after years. Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems. Generally speaking (with my other NICs, specifically Pro/1000 NICs), I have not seen this behaviour. The em(4) driver behaves very well and does 802.3u auto-neg of speed/duplex properly. I have used many different revisions of Pro/1000 on FreeBSD and haven't seen this behaviour. Most commonly what you're reporting is the result of a switch upstream which isn't fully compatible or properly doing 802.3u auto-neg. Rebooting the machine (thus tearing down link hard, and resetting the entire chip) often works in this situation. You can also try setting the speed and duplex (media and mediaopt) in your ifconfig_emX line in rc.conf to see if that helps (on some switches it does). The behaviour you're reporting I've seen on old 3Com XL 509x cards with Cisco switches, for example. I gladly await more flame mails from people telling me Yes, that is a known problem with Cisco switches in the past, but it does not happen any more, but even present-day Cisco switches we use at our workplace (alongside em(4) NICs) behave erroneously just like in the past. *shrug* Everyone has a different experience. I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's extremely annoying on Thinkpads, when you just want to plug in your laptop somewhere. I have a Thinkpad T60p. I'll try booting FreeBSD on it next week and see if I can reproduce the behaviour. I'll also include what switch brands/models are being plugged into. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming ABI Breakage in RELENG_7
* Ken Smith [EMAIL PROTECTED] [080729 08:47] wrote: Normally the FreeBSD Project tries very hard to avoid ABI breakage in Stable Branches. However occasionally the fix for a bug can not be implemented without ABI breakage, and it is decided that the fix warrants the impact of the ABI breakage. We have one of those situations coming along for RELENG_7 (what will become FreeBSD 7.1). The ABI breakage should only impact kernel modules that are not part of the baseline system (those will be patched by the MFC) which deal with advisory locks. As such the impact should not cause many people problems. The work that will be MFCed fixes issues with filesystem advisory locks, and moves the advisory locks list from filesystem-private data structures into the vnode structure. The MFC will be done by Kostantin Belousov some time this coming Friday (August 1st, 2008) if you have concerns and want to watch for it. Ken, Can you point at a cvs/svn log or two that details the change and why? Everyone else: For those confused about what ABI breakage means: It means that you'll need to recompile your kernel modules and potentially your system utilities that access kernel data structures to display statistics. It seems like in this particular case you won't need to recompile, but it's a good idea just to be safe to recompile kernel, world and any third party kernel modules you have. thank you, -Alfred ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming ABI Breakage in RELENG_7
On Fri, Aug 01, 2008 at 05:44:17AM -0700, Alfred Perlstein wrote: * Ken Smith [EMAIL PROTECTED] [080729 08:47] wrote: Normally the FreeBSD Project tries very hard to avoid ABI breakage in Stable Branches. However occasionally the fix for a bug can not be implemented without ABI breakage, and it is decided that the fix warrants the impact of the ABI breakage. We have one of those situations coming along for RELENG_7 (what will become FreeBSD 7.1). The ABI breakage should only impact kernel modules that are not part of the baseline system (those will be patched by the MFC) which deal with advisory locks. As such the impact should not cause many people problems. The work that will be MFCed fixes issues with filesystem advisory locks, and moves the advisory locks list from filesystem-private data structures into the vnode structure. The MFC will be done by Kostantin Belousov some time this coming Friday (August 1st, 2008) if you have concerns and want to watch for it. Ken, Can you point at a cvs/svn log or two that details the change and why? MFCed as r181119. See the log for all details. pgpvh5xa2WgAK.pgp Description: PGP signature
re: no toe capability message
I had just cvsup'd when I found this, but having done so again it now appears fixed. Thanks! Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
Hi, On 1 Aug 2008, at 13:20, Martin wrote: Hello, I don't remember anymore when I reported it the first time. I think it was around 4.x or something like that. The em(4) bug is still there after years. Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems. I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's extremely annoying on Thinkpads, when you just want to plug in your laptop somewhere. Well it's not a problem for my TP T41 (just tested with 5.0R and 7.0R), the NIC probes as: Intel (R) PRO/1000 Network Connection Version - 6.7.3 and I've never seen it on sundry other boxes with em. That doesn't mean it can't happen, of course. -- Martin -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED]fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
On Fri, 1 Aug 2008, Martin wrote: I don't remember anymore when I reported it the first time. I think it was around 4.x or something like that. The em(4) bug is still there after years. Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? The card range supported by the if_em driver is huge, so it wouldn't be surprising if this is a hardware bug affecting a relatively narrow line of parts. I've added Jack Vogel to the CC line, as he's the Intel developer responsible for maintaining our if_em driver. I don't promise he can help either, but it's worth a try :-). Robert Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems. I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's extremely annoying on Thinkpads, when you just want to plug in your laptop somewhere. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
Royce Williams wrote, on 7/22/2008 10:38 PM: Jeremy Chadwick wrote, on 7/22/2008 9:34 PM: On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. We use the same hardware (board and chassis), and have no such problems running both RELENG_6 and RELENG_7. I don't think your issue is specific to the board or chassis. Kris's explanation makes a lot more sense. :-) Jeremy/Kris/Clifton - Looks like we have consensus. :-) Thanks, all of you, for your helpful insight. I've bumped vm.kmem_size up to 400M on half of the affected boxes, leaving the other half as a control group. I'll report back once I have something to report. After having bumped up to 400M, a few boxes panic'd again yesterday. I caught a core, and it is kmem_map too small, just as Kris suspected: Jul 31 15:38:05 [redacted] savecore: reboot after panic: kmem_malloc(4096): kmem_map too small: 419430400 total allocated The docs state that 400M should be plenty for systems up to 6G, but Kris said earlier in this thread that it's better to say 'increase until the pain stops'. :-) Accordingly, I have some some follow-up questions; hopefully, this will be useful to others. - What is a reasonable increment? (I'm trying 448M next). - What are the practical and hard maximums? - I suspect that it's worth trying to make kmem 'as big as I need, but no bigger', so that non-kernel memory is also maximized? - In a larger sense, if 400M is probably big enough for 6G systems, and these are 4G systems, should I be suspicious that 400M isn't cutting it? In other words, is there a point at which should I be looking for obvious places where the kernel is eating too much memory and reduce them, rather than feeding it more? For example, I recall now that a network guy in my group did some sysctl tuning relating to networking on these systems, and I see from man tuning(7) that a number of these tweaks (obviously) can cause increased kernel consumption. $ egrep -v '^#|^$' /etc/sysctl.conf | sort kern.corefile=/var/cores/%U/%N-%P.core kern.ipc.maxsockbuf=8388608 kern.ipc.maxsockets=32768 kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 kern.maxfiles=262144 kern.maxfilesperproc=65535 net.inet.ip.portrange.first=8192 net.inet.ip.portrange.hifirst=8192 net.inet.ip.portrange.hilast=65535 net.inet.ip.portrange.last=65535 net.inet.ipf.fr_tcpclosed=60 net.inet.ipf.fr_tcpclosewait=120 net.inet.ipf.fr_tcphalfclosed=300 net.inet.ipf.fr_udptimeout=120 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.msl=1 net.inet.tcp.mssdflt=1460 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65535 vfs.nfs.iodmax=32 vfs.nfs.iodmin=8 My apologies for not including this sooner. I didn't think of it until yesterday, primarily because it had been fine under 6.2. In retrospect, that was bad reasoning. Royce -- Royce D. Williams - http://royce.ws/ Reason is a very light rider, and easily shook off. - Jonathan Swift ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Adding device to FreeBSD 6.3-STABLE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to add the zyd device to FreeBSD. The zyd driver allready is in FreeBSD 7.0. Which steps do I have to take to add the zyd device to FreeBSD? Jack -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFIkzSKPh5RwW/NzC4RAqMKAJ987kbR57nNejUHOaNPOLabP2jKWACgm6Ts iOvTzyGUw1evnXmmHSa6+RA= =f1r1 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
If the poster gives me EXACT hardware list I will see about repro'ing the problem inhouse. We do not do much of anything with laptops but I will see. Oh and a pciconf would help too. Jack On Fri, Aug 1, 2008 at 7:43 AM, Robert Watson [EMAIL PROTECTED] wrote: On Fri, 1 Aug 2008, Martin wrote: I don't remember anymore when I reported it the first time. I think it was around 4.x or something like that. The em(4) bug is still there after years. Hasn't anyone really noticed yet that em(4) only appears when you boot FreeBSD with the interface physically attached to a switch for example? If you attach it later, after boot up, the interface won't power up and appear in the interface list (ifconfig)? The card range supported by the if_em driver is huge, so it wouldn't be surprising if this is a hardware bug affecting a relatively narrow line of parts. I've added Jack Vogel to the CC line, as he's the Intel developer responsible for maintaining our if_em driver. I don't promise he can help either, but it's worth a try :-). Robert Steps to reproduce: 1) Switch your PC/laptop off. Really OFF, no reboot. 2) Disconnect the em(4) NIC from your switch. 3) Boot FreeBSD. 4) Plug in the ethernet cable. 5) Tataa! All leds at the NIC stay off. You won't be able to use em(4) unless you reboot your machine. Something is not being initialized properly on em(4) devices, it seems. I have had 3 of 3 em(4) NICs so far, where this bug shows up. And it's extremely annoying on Thinkpads, when you just want to plug in your laptop somewhere. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding device to FreeBSD 6.3-STABLE
On Friday 01 August 2008, Jack Raats wrote: I would like to add the zyd device to FreeBSD. The zyd driver allready is in FreeBSD 7.0. Which steps do I have to take to add the zyd device to FreeBSD? Sorry, what are you asking? What version of FreeBSD are you using and what do you need help doing? JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding device to FreeBSD 6.3-STABLE
John Nielsen wrote: On Friday 01 August 2008, Jack Raats wrote: I would like to add the zyd device to FreeBSD. The zyd driver allready is in FreeBSD 7.0. Which steps do I have to take to add the zyd device to FreeBSD? Sorry, what are you asking? What version of FreeBSD are you using and what do you need help doing? JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] To make the device available without recompiling your kernel you do the following: kldload if_zyd To have zyd available after reboots add it to /boot/loader.conf as: if_zyd_load=YES ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
Royce Williams wrote: Royce Williams wrote, on 7/22/2008 10:38 PM: Jeremy Chadwick wrote, on 7/22/2008 9:34 PM: On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. We use the same hardware (board and chassis), and have no such problems running both RELENG_6 and RELENG_7. I don't think your issue is specific to the board or chassis. Kris's explanation makes a lot more sense. :-) Jeremy/Kris/Clifton - Looks like we have consensus. :-) Thanks, all of you, for your helpful insight. I've bumped vm.kmem_size up to 400M on half of the affected boxes, leaving the other half as a control group. I'll report back once I have something to report. After having bumped up to 400M, a few boxes panic'd again yesterday. I caught a core, and it is kmem_map too small, just as Kris suspected: Jul 31 15:38:05 [redacted] savecore: reboot after panic: kmem_malloc(4096): kmem_map too small: 419430400 total allocated The docs state that 400M should be plenty for systems up to 6G, but Kris said earlier in this thread that it's better to say 'increase until the pain stops'. :-) Accordingly, I have some some follow-up questions; hopefully, this will be useful to others. - What is a reasonable increment? (I'm trying 448M next). - What are the practical and hard maximums? - I suspect that it's worth trying to make kmem 'as big as I need, but no bigger', so that non-kernel memory is also maximized? - In a larger sense, if 400M is probably big enough for 6G systems, and these are 4G systems, should I be suspicious that 400M isn't cutting it? In other words, is there a point at which should I be looking for obvious places where the kernel is eating too much memory and reduce them, rather than feeding it more? For example, I recall now that a network guy in my group did some sysctl tuning relating to networking on these systems, and I see from man tuning(7) that a number of these tweaks (obviously) can cause increased kernel consumption. $ egrep -v '^#|^$' /etc/sysctl.conf | sort kern.corefile=/var/cores/%U/%N-%P.core kern.ipc.maxsockbuf=8388608 kern.ipc.maxsockets=32768 kern.ipc.nmbclusters=65535 kern.ipc.somaxconn=4096 kern.maxfiles=262144 kern.maxfilesperproc=65535 net.inet.ip.portrange.first=8192 net.inet.ip.portrange.hifirst=8192 net.inet.ip.portrange.hilast=65535 net.inet.ip.portrange.last=65535 net.inet.ipf.fr_tcpclosed=60 net.inet.ipf.fr_tcpclosewait=120 net.inet.ipf.fr_tcphalfclosed=300 net.inet.ipf.fr_udptimeout=120 net.inet.tcp.delayed_ack=0 net.inet.tcp.inflight.enable=0 net.inet.tcp.msl=1 net.inet.tcp.mssdflt=1460 net.inet.tcp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 net.inet.udp.recvspace=65535 vfs.nfs.iodmax=32 vfs.nfs.iodmin=8 My apologies for not including this sooner. I didn't think of it until yesterday, primarily because it had been fine under 6.2. In retrospect, that was bad reasoning. Royce The statement that 400MB should be enough for up to 6GB is completely bogus. The amount of memory your kernel needs is a function of the work you give it to do. On i386 the kernel only has 1GB of address space though you can increase it by tuning KVA_PAGES at the expense of less memory available to user processes (everything comes out of 4GB address space). So that is the upper bound although other things need to fit in there too. On amd64 the situation is more complicated but on older versions than 8.0 there is 2GB for the kernel address space and in practise a limit of about 1500MB of kmem. It is possible that you are hitting a memory leak but I would just increase kmem further and see if it persists. Looking at vmstat -m etc may help to figure out if something is leaking over time. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding device to FreeBSD 6.3-STABLE
On Friday 01 August 2008 12:13:41 pm John Nielsen wrote: On Friday 01 August 2008, Jack Raats wrote: I would like to add the zyd device to FreeBSD. The zyd driver allready is in FreeBSD 7.0. Which steps do I have to take to add the zyd device to FreeBSD? Sorry, what are you asking? What version of FreeBSD are you using and what do you need help doing? From the subject line, I imagine Jack is using 6.3-STABLE and wants to backport the driver from 7.0 to 6.3. Backporting most drivers from 7.0 to 6.x isn't a big deal (can generally just copy over and compile). However, zyd(4) is a wireless driver and the net80211 wireless networking stack is quite different in 6.x vs 7.0, so that is where it would be complicated to backport the driver. I'm not intimately familiar with net80211 in either branch, so I'm unsure how much work the backport would be. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding device to FreeBSD 6.3-STABLE
On 8/1/08, Jack Raats [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to add the zyd device to FreeBSD. The zyd driver allready is in FreeBSD 7.0. Which steps do I have to take to add the zyd device to FreeBSD? You need to obtain these revisions to compile zyd: sys/dev/usb/if_zyd.c 1.13 sys/modules/zyd/Makefile 1.1 Revision 1.14 was when the net80211 wireless networking stack was committed. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_6 tinderbox] failure on i386/pc98
TB --- 2008-08-02 01:59:54 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-02 01:59:54 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2008-08-02 01:59:54 - cleaning the object tree TB --- 2008-08-02 02:00:23 - cvsupping the source tree TB --- 2008-08-02 02:00:23 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/pc98/supfile TB --- 2008-08-02 02:00:35 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-02 02:00:35 - cd /src TB --- 2008-08-02 02:00:35 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything TB --- 2008-08-02 02:54:18 - generating LINT kernel config TB --- 2008-08-02 02:54:18 - cd /src/sys/pc98/conf TB --- 2008-08-02 02:54:18 - /usr/bin/make -B LINT TB --- 2008-08-02 02:54:18 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-08-02 02:54:18 - cd /src TB --- 2008-08-02 02:54:18 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Aug 2 02:54:18 UTC 2008 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] machdep.o(.text+0xa92): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xa9c): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xaeb): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xaf8): In function `init386': : undefined reference to `SMP_prvspace' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-08-02 03:04:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-02 03:04:36 - ERROR: failed to build lint kernel TB --- 2008-08-02 03:04:36 - tinderbox aborted TB --- 3044.68 user 361.33 system 3881.68 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
On Fri, 1 Aug 2008 09:24:53 -0700 Jack Vogel [EMAIL PROTECTED] wrote: If the poster gives me EXACT hardware list I will see about repro'ing the problem inhouse. We do not do much of anything with laptops but I will see. Oh and a pciconf would help too. Hi Jack, pciconf -lv gives me: [EMAIL PROTECTED]:2:0:0:class=0x02 card=0x200117aa chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet One thing, I have to add. I described the behavior wrong. The adapter actually IS available in the interface list, but it gets no carrier. Sorry for that. This is what I get from ifconfig when the NIC is plugged in: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether xx:xx:xx:xx:xx:xx media: Ethernet autoselect status: no carrier All LEDs are off. Device was found on boot: em0: Intel(R) PRO/1000 Network Connection 6.9.5 port 0x3000-0x301f mem 0xee000 000-0xee01 irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: xx:xx:xx:xx:xx:xx -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
On Fri, 1 Aug 2008 05:42:24 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: Hi Jeremy, Most commonly what you're reporting is the result of a switch upstream which isn't fully compatible or properly doing 802.3u auto-neg. It is attached to a cheap switch here. Also at my office it is not coming up. And I have NEVER this problem when the laptop is already plugged in. Rebooting the machine (thus tearing down link hard, and resetting the entire chip) often works in this situation. You can also try setting the speed and duplex (media and mediaopt) in your ifconfig_emX line in rc.conf to see if that helps (on some switches it does). This is what I get, when I plug it in and try to configure something: # ifconfig em0 mediaopt full-duplex ifconfig: SIOCSIFMEDIA (media): Device not configured But it accepts up, down and even inet address. LEDs are off and still no carrier. The behaviour you're reporting I've seen on old 3Com XL 509x cards with Cisco switches, for example. I've heard of the autonegotiation problem, but it rather looks to my as if something is getting initialized during BIOS boot and FreeBSD is not doing it correctly. I have a Thinkpad T60p. I'll try booting FreeBSD on it next week and see if I can reproduce the behaviour. I'll also include what switch brands/models are being plugged into. Once again. I made a mistake describing the problem. I'm really sorry for this. The interface actually appears in the ifconfig list, but I cannot get it up. It always shows no carrier. No matter what I try. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
