From ebutusov at gmail.com Fri Aug 1 01:40:01 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Fri Aug 1 01:40:08 2008 Subject: Realtek RTL8110 (SB) watchdog timeout. Message-ID: <489262E5.3010304@gmail.com> Hi, After updating from 7.0-RELEASE to STABLE (around 15/08) my NIC refuses to handle large file transfers. pciconf -lv re0@pci0:4:0:0: class=0x020000 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 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. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From pyunyh at gmail.com Fri Aug 1 08:09:34 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Aug 1 08:09:42 2008 Subject: Realtek RTL8110 (SB) watchdog timeout. In-Reply-To: <489262E5.3010304@gmail.com> References: <489262E5.3010304@gmail.com> Message-ID: <20080801080721.GB9206@cdnetworks.co.kr> 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 > > re0@pci0:4:0:0: class=0x020000 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 From nakal at web.de Fri Aug 1 12:20:13 2008 From: nakal at web.de (Martin) Date: Fri Aug 1 12:20:21 2008 Subject: em(4) on FreeBSD is sometimes annoying Message-ID: <20080801142005.473c17ca@zelda.local> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080801/bca7b993/signature.pgp From sthaug at nethelp.no Fri Aug 1 12:27:31 2008 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Fri Aug 1 12:27:38 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080801142005.473c17ca@zelda.local> References: <20080801142005.473c17ca@zelda.local> Message-ID: <20080801.142728.74660240.sthaug@nethelp.no> > 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, sthaug@nethelp.no From koitsu at FreeBSD.org Fri Aug 1 12:42:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Aug 1 12:42:31 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080801142005.473c17ca@zelda.local> References: <20080801142005.473c17ca@zelda.local> Message-ID: <20080801124224.GA17183@eos.sc1.parodius.com> 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 Chadwick jdc 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 | From alfred at freebsd.org Fri Aug 1 12:44:18 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Fri Aug 1 12:44:24 2008 Subject: Upcoming ABI Breakage in RELENG_7 In-Reply-To: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> Message-ID: <20080801124417.GA76659@elvis.mu.org> * Ken Smith [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 From kostikbel at gmail.com Fri Aug 1 12:50:39 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Aug 1 12:50:49 2008 Subject: Upcoming ABI Breakage in RELENG_7 In-Reply-To: <20080801124417.GA76659@elvis.mu.org> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <20080801124417.GA76659@elvis.mu.org> Message-ID: <20080801125005.GI97161@deviant.kiev.zoral.com.ua> On Fri, Aug 01, 2008 at 05:44:17AM -0700, Alfred Perlstein wrote: > * Ken Smith [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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080801/05e219c6/attachment.pgp From danallen46 at airwired.net Fri Aug 1 13:20:19 2008 From: danallen46 at airwired.net (Dan Allen) Date: Fri Aug 1 13:20:35 2008 Subject: no toe capability message Message-ID: I had just cvsup'd when I found this, but having done so again it now appears fixed. Thanks! Dan From rb at gid.co.uk Fri Aug 1 13:27:51 2008 From: rb at gid.co.uk (Bob Bishop) Date: Fri Aug 1 13:27:59 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080801142005.473c17ca@zelda.local> References: <20080801142005.473c17ca@zelda.local> Message-ID: 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: 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 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From rwatson at FreeBSD.org Fri Aug 1 15:00:27 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Aug 1 15:00:34 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080801142005.473c17ca@zelda.local> References: <20080801142005.473c17ca@zelda.local> Message-ID: <20080801154208.W6085@fledge.watson.org> 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 > From royce at alaska.net Fri Aug 1 16:10:00 2008 From: royce at alaska.net (Royce Williams) Date: Fri Aug 1 16:10:18 2008 Subject: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ In-Reply-To: <4886D1E9.1090905@alaska.net> References: <488638DA.7010005@alaska.net> <20080723053404.GA46617@eos.sc1.parodius.com> <4886D1E9.1090905@alaska.net> Message-ID: <48933557.8010904@alaska.net> 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=10000 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 From jack at jarasoft.net Fri Aug 1 16:18:45 2008 From: jack at jarasoft.net (Jack Raats) Date: Fri Aug 1 16:18:52 2008 Subject: Adding device to FreeBSD 6.3-STABLE Message-ID: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> -----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----- From jfvogel at gmail.com Fri Aug 1 16:24:56 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Aug 1 16:25:03 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080801154208.W6085@fledge.watson.org> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> Message-ID: <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> 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 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 >> > From lists at jnielsen.net Fri Aug 1 16:45:53 2008 From: lists at jnielsen.net (John Nielsen) Date: Fri Aug 1 16:46:00 2008 Subject: Adding device to FreeBSD 6.3-STABLE In-Reply-To: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> Message-ID: <200808011213.41335.lists@jnielsen.net> 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 From pprocacci at datapipe.com Fri Aug 1 17:02:01 2008 From: pprocacci at datapipe.com (Paul Procacci) Date: Fri Aug 1 17:02:08 2008 Subject: Adding device to FreeBSD 6.3-STABLE In-Reply-To: <200808011213.41335.lists@jnielsen.net> References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> <200808011213.41335.lists@jnielsen.net> Message-ID: <48933F23.1050201@datapipe.com> 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 "freebsd-stable-unsubscribe@freebsd.org" > 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" From kris at FreeBSD.org Fri Aug 1 18:07:51 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Fri Aug 1 18:07:59 2008 Subject: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+ In-Reply-To: <48933557.8010904@alaska.net> References: <488638DA.7010005@alaska.net> <20080723053404.GA46617@eos.sc1.parodius.com> <4886D1E9.1090905@alaska.net> <48933557.8010904@alaska.net> Message-ID: <489350F4.5070009@FreeBSD.org> 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=10000 > 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 From jhb at freebsd.org Fri Aug 1 19:26:31 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Aug 1 19:26:38 2008 Subject: Adding device to FreeBSD 6.3-STABLE In-Reply-To: <200808011213.41335.lists@jnielsen.net> References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> <200808011213.41335.lists@jnielsen.net> Message-ID: <200808011442.37048.jhb@freebsd.org> 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 From burt at cs.miami.edu Fri Aug 1 19:34:16 2008 From: burt at cs.miami.edu (burt rosenberg) Date: Fri Aug 1 19:34:26 2008 Subject: reboot sometimes freezes, adaptic scsi card possible problem Message-ID: On reboot, one out of 10 times, reboot (from hardware initialization) stops. Referring to this portion of the dmesg -v output, of a successful boot, where i have marked ">>>HERE<<<" is where the boot freezes on an unsuccessful boot. This is a constnat problem, on 6.2 as well as 6.3 unchanged. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on 63XXESB2 chip acd0: setting UDMA33 on 63XXESB2 chip acd0: CDRW drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 1536KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc mfid0: on mfi0 mfid0: 139392MB (285474816 sectors) RAID volume '' is optimal GEOM: new disk mfid0 mfi0: 3796 (270874608s/0x0008/0) - Battery temperature is normal mfi0: 3797 (270874608s/0x0008/0) - Battery started charging mfi0: 3798 (270874608s/0x0008/0) - Current capacity of the battery is above threshold >>>>>>>>>>>HERE<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ahd0: Selection Timeout on A:10. 0 SCBs aborted ahd1: Selection Timeout on A:0. 0 SCBs aborted ahd0: Selection Timeout on A:11. 0 SCBs aborted ahd1: Selection Timeout on A:1. 0 SCBs aborted ahd0: Selection Timeout on A:0. 0 SCBs aborted ahd1: Selection Timeout on A:10. 0 SCBs aborted ahd0: Selection Timeout on A:1. 0 SCBs aborted ahd1: Selection Timeout on A:11. 0 SCBs aborted ahd0: Selection Timeout on A:2. 0 SCBs aborted ahd1: Selection Timeout on A:12. 0 SCBs aborted ahd0: Selection Timeout on A:3. 0 SCBs aborted I have enclose various files with my hardware profile. [burt@mcclellan ~]$ uname -a FreeBSD mcclellan.cs.miami.edu 6.3-RELEASE-p3 FreeBSD 6.3-RELEASE-p3 #8: Wed Jul 30 13:02:03 EDT 2008 burt@mcclellan.cs.miami.edu:/usr/obj/usr/src/sys/MCCLELLAN amd64 Dell PowerEdge 2950; ahd0@pci15:3:0: class=0x010000 card=0x00409005 chip=0x80169005 rev=0x10 hdr=0x00 vendor = 'Adaptec Inc' device = 'ASC-39320A Ultra320 SCSI Controller' class = mass storage subclass = SCSI scbus0 on ahd0 bus 0: at scbus0 target 6 lun 0 (sa0,pass0) < > at scbus0 target -1 lun -1 () scbus1 on ahd1 bus 0: < > at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: camcontrol_devlist.out Type: application/octet-stream Size: 338 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080801/573fde6b/camcontrol_devlist-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.out Type: application/octet-stream Size: 40374 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080801/573fde6b/dmesg-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: dmidecode.out Type: application/octet-stream Size: 17997 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080801/573fde6b/dmidecode-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: pciconf_-l_-i.out Type: application/octet-stream Size: 8836 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080801/573fde6b/pciconf_-l_-i-0001.obj From swhetzel at gmail.com Sat Aug 2 00:24:47 2008 From: swhetzel at gmail.com (Scot Hetzel) Date: Sat Aug 2 00:24:54 2008 Subject: Adding device to FreeBSD 6.3-STABLE In-Reply-To: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> References: <6A7AD37501FA4199B44BBBB03B0EE368@jarasoft.net> Message-ID: <790a9fff0808011724n25179c9coeaa94393ffd40dd7@mail.gmail.com> On 8/1/08, Jack Raats 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 From tinderbox at freebsd.org Sat Aug 2 03:04:33 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Aug 2 03:04:45 2008 Subject: [releng_6 tinderbox] failure on i386/pc98 Message-ID: <20080802030436.55069241A2@freebsd-legacy.sentex.ca> 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 From nakal at web.de Sat Aug 2 04:47:31 2008 From: nakal at web.de (Martin) Date: Sat Aug 2 04:47:39 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> Message-ID: <20080802064727.042d5e3d@web.de> On Fri, 1 Aug 2008 09:24:53 -0700 "Jack Vogel" 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: em0@pci0:2:0:0: class=0x020000 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=8843 metric 0 mtu 1500 options=19b ether xx:xx:xx:xx:xx:xx media: Ethernet autoselect status: no carrier All LEDs are off. Device was found on boot: em0: port 0x3000-0x301f mem 0xee000 000-0xee01ffff irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: xx:xx:xx:xx:xx:xx -- Martin From nakal at web.de Sat Aug 2 05:00:20 2008 From: nakal at web.de (Martin) Date: Sat Aug 2 05:00:28 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080801124224.GA17183@eos.sc1.parodius.com> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> Message-ID: <20080802070015.7f64c862@web.de> On Fri, 1 Aug 2008 05:42:24 -0700 Jeremy Chadwick 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
. 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 From imp at bsdimp.com Sat Aug 2 06:22:27 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Aug 2 06:22:44 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? In-Reply-To: <372128.56919.qm@web51502.mail.re2.yahoo.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> Message-ID: <20080802.002039.58462077.imp@bsdimp.com> In message: <372128.56919.qm@web51502.mail.re2.yahoo.com> fbsd2 writes: : Greetings list, : : Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen : : http://www.freebsd.org/releases/7.0R/relnotes.html and : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 : : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA Doesn't look like anybody has answered this question... 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or tinybsd to get that small. You'll likely been unable to do a 'make installworld' to get this size. You'll have to create an image and push it over to this machine somehow. In the 3.x time frame, I had FreeBSD booting with the standard scripts in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries to about 18MB (a few more were added). I haven't built a system based on 7.x with this system due to a change in employment, but expect that it wouldn't be much larger than 20MB for these same files. Some careful honing could reduce that a little, but maybe not a lot. Typical embedded systems that I shipped were on the order of 24MB without X11 and 32-60MB for those with an X11 server. What's this box used for? Warner From kostikbel at gmail.com Sat Aug 2 06:35:43 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Aug 2 06:35:50 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? In-Reply-To: <20080802.002039.58462077.imp@bsdimp.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> Message-ID: <20080802063533.GO97161@deviant.kiev.zoral.com.ua> On Sat, Aug 02, 2008 at 12:20:39AM -0600, M. Warner Losh wrote: > In message: <372128.56919.qm@web51502.mail.re2.yahoo.com> > fbsd2 writes: > : Greetings list, > : > : Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen > : > : http://www.freebsd.org/releases/7.0R/relnotes.html and > : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 > : > : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA > > Doesn't look like anybody has answered this question... > > 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or > tinybsd to get that small. You'll likely been unable to do a 'make > installworld' to get this size. You'll have to create an image and > push it over to this machine somehow. > > In the 3.x time frame, I had FreeBSD booting with the standard scripts > in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries > to about 18MB (a few more were added). I haven't built a system based > on 7.x with this system due to a change in employment, but expect that > it wouldn't be much larger than 20MB for these same files. Some > careful honing could reduce that a little, but maybe not a lot. > Typical embedded systems that I shipped were on the order of 24MB > without X11 and 32-60MB for those with an X11 server. > > What's this box used for? Actually, on the normal RELENG_7/i386 install (i.e. done by buildworld/installworld), I get Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 257998 50422 186938 21% / /dev/ad0s1e 4129310 143676 3655290 4% /usr Note that you must supply INSTALL_NODEBUG=yes for installkernel, and the numbers shown are for WITHOUT_PROFILE=yes. Amd64 takes ~230Mb for merged / and /usr, this is both due to increased binary sizes and lib32. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080802/d7f4245b/attachment.pgp From imp at bsdimp.com Sat Aug 2 06:58:06 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Aug 2 06:58:13 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? In-Reply-To: <20080802063533.GO97161@deviant.kiev.zoral.com.ua> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <20080802063533.GO97161@deviant.kiev.zoral.com.ua> Message-ID: <20080802.005719.-75255160.imp@bsdimp.com> In message: <20080802063533.GO97161@deviant.kiev.zoral.com.ua> Kostik Belousov writes: : > : Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen : > : : > : http://www.freebsd.org/releases/7.0R/relnotes.html and : > : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 : > : : > : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA : > : > Doesn't look like anybody has answered this question... : > : > 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or : > tinybsd to get that small. You'll likely been unable to do a 'make : > installworld' to get this size. You'll have to create an image and : > push it over to this machine somehow. : > : > In the 3.x time frame, I had FreeBSD booting with the standard scripts : > in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries : > to about 18MB (a few more were added). I haven't built a system based : > on 7.x with this system due to a change in employment, but expect that : > it wouldn't be much larger than 20MB for these same files. Some : > careful honing could reduce that a little, but maybe not a lot. : > Typical embedded systems that I shipped were on the order of 24MB : > without X11 and 32-60MB for those with an X11 server. : > : > What's this box used for? : : Actually, on the normal RELENG_7/i386 install (i.e. done by : buildworld/installworld), I get : : Filesystem 1K-blocks Used Avail Capacity Mounted on : /dev/ad0s1a 257998 50422 186938 21% / : /dev/ad0s1e 4129310 143676 3655290 4% /usr : : Note that you must supply INSTALL_NODEBUG=yes for installkernel, and : the numbers shown are for WITHOUT_PROFILE=yes. : : Amd64 takes ~230Mb for merged / and /usr, this is both due to increased : binary sizes and lib32. Right, the numbers I quoted were for an opt-in system like tinybsd... They are good numbers to have at hand, since it is hard to buy flash media that's smaller than 1GB these days... Warner From tinderbox at freebsd.org Sat Aug 2 06:59:31 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Aug 2 06:59:52 2008 Subject: [releng_7 tinderbox] failure on i386/pc98 Message-ID: <20080802065928.95D501B5078@freebsd-stable.sentex.ca> TB --- 2008-08-02 05:40:06 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-08-02 05:40:06 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2008-08-02 05:40:06 - cleaning the object tree TB --- 2008-08-02 05:40:28 - cvsupping the source tree TB --- 2008-08-02 05:40:28 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2008-08-02 05:40:37 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-02 05:40:37 - cd /src TB --- 2008-08-02 05:40:37 - /usr/bin/make -B buildworld >>> World build started on Sat Aug 2 05:40:38 UTC 2008 >>> 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 >>> World build completed on Sat Aug 2 06:45:50 UTC 2008 TB --- 2008-08-02 06:45:50 - generating LINT kernel config TB --- 2008-08-02 06:45:50 - cd /src/sys/pc98/conf TB --- 2008-08-02 06:45:50 - /usr/bin/make -B LINT TB --- 2008-08-02 06:45:50 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-08-02 06:45:50 - cd /src TB --- 2008-08-02 06:45:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 2 06:45:50 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+0xc82): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xc8c): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xd11): In function `init386': : undefined reference to `SMP_prvspace' machdep.o(.text+0xd1d): 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 06:59:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-02 06:59:28 - ERROR: failed to build lint kernel TB --- 2008-08-02 06:59:28 - tinderbox aborted TB --- 3873.09 user 405.55 system 4762.05 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From h.schmalzbauer at OmniLAN.de Sat Aug 2 07:18:45 2008 From: h.schmalzbauer at OmniLAN.de (Harald Schmalzbauer) Date: Sat Aug 2 07:18:53 2008 Subject: newfs-msdos and default fat32 parameters Message-ID: <48940A53.3000004@OmniLAN.de> Hello, lately I wanted to create some DOS bootable SD-Cards (for simply BIOS updates, disk diagnostic tools etc...) After newfs_msdos -F32 -B VBR.bin (2.5G partition) the system just didn't continue booting after the MBR was loaded (VBR.bin is a 3 sectors dump of the DOS boot record which sys creates). When I directly wrote the dump back to sectors 63-65 and 69-71 the system booted! So I took my hex glasses and found some unfortunate default parameters of newfs_msdos. - MediaType is f0 but probably should read f8 (fixed disk) - The backup boot record should be located at offset 6, not 2. - There should be defined 63 hidden sectors With 'newfs_msdos -F32 -m 0xf8 -B VBR.bin -k 0x6 -o 63 -i 0x1 /dev/da6s1' every thing was fine. I'm no expert, I just found some FAT info. maybe the current defaults are wisley chosen. Maybe not? Best regards, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080802/e241b0c5/signature.pgp From h.schmalzbauer at OmniLAN.de Sat Aug 2 07:19:05 2008 From: h.schmalzbauer at OmniLAN.de (Harald Schmalzbauer) Date: Sat Aug 2 07:19:13 2008 Subject: 'diskinfo' problem with eSATA device (initio 1611) Message-ID: <4894075E.6090602@OmniLAN.de> Hello, for quick harddrive tests (SMART, noise, backup etc..) I bought a very nice "docking" station connected to my ICH9 SATA controller (http://www.sharkoon.com/html/produkte/externe_gehaeuse/sata_quickport_pro/index_en.html) I can read/write to inserted disks, also smartctl works, but my favourite test doesn't run: diskinfo -t /dev/ad10 returns: ioctl(DIOCGMEDIASIZE) failed, probably not a disk.: Inappropriate ioctl for device The eSATA bridge is a initio 1611 chip. I have another external SATA enclosure and there is the same problem. Any ideas what the reason is and how to "fix"? Best regards, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080802/e5f73477/signature.pgp From h.schmalzbauer at OmniLAN.de Sat Aug 2 08:42:53 2008 From: h.schmalzbauer at OmniLAN.de (Harald Schmalzbauer) Date: Sat Aug 2 08:43:05 2008 Subject: Feature request dev.ata.X.detached=1 Message-ID: <48941E0A.1040300@OmniLAN.de> Hello, while eSATA get's widle used I don't like to detach a channel first before I can hotplug a new disk. Would it be possible to implement a sysctl which tells the controller at boot time to keep some channels detached? Best regards, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080802/50dce92a/signature.pgp From tinderbox at freebsd.org Sat Aug 2 09:21:15 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sat Aug 2 09:21:22 2008 Subject: [releng_6 tinderbox] failure on i386/pc98 Message-ID: <20080802092119.113CF241A2@freebsd-legacy.sentex.ca> TB --- 2008-08-02 08:08:10 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-08-02 08:08:10 - starting RELENG_6 tinderbox run for i386/pc98 TB --- 2008-08-02 08:08:10 - cleaning the object tree TB --- 2008-08-02 08:08:34 - cvsupping the source tree TB --- 2008-08-02 08:08:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/i386/pc98/supfile TB --- 2008-08-02 08:08:40 - building world (CFLAGS=-O2 -pipe) TB --- 2008-08-02 08:08:40 - cd /src TB --- 2008-08-02 08:08:40 - /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 09:10:55 - generating LINT kernel config TB --- 2008-08-02 09:10:55 - cd /src/sys/pc98/conf TB --- 2008-08-02 09:10:55 - /usr/bin/make -B LINT TB --- 2008-08-02 09:10:55 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-08-02 09:10:55 - cd /src TB --- 2008-08-02 09:10:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 2 09:10:55 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 09:21:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-08-02 09:21:18 - ERROR: failed to build lint kernel TB --- 2008-08-02 09:21:18 - tinderbox aborted TB --- 3051.72 user 368.83 system 4388.99 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-i386-pc98.full From torfinn.ingolfsen at broadpark.no Sat Aug 2 10:55:58 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sat Aug 2 10:56:05 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080802070015.7f64c862@web.de> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> Message-ID: <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> On Sat, 02 Aug 2008 07:00:15 +0200 Martin wrote: > 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. Just to be sure: also if the first command you try on the interface is 'ifconfig up'? -- Regards, Torfinn Ingolfsen From jfvogel at gmail.com Sat Aug 2 17:34:49 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat Aug 2 17:34:56 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080802064727.042d5e3d@web.de> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> Message-ID: <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> On Fri, Aug 1, 2008 at 9:47 PM, Martin wrote: > On Fri, 1 Aug 2008 09:24:53 -0700 > "Jack Vogel" 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: > > em0@pci0:2:0:0: class=0x020000 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=8843 metric 0 mtu > 1500 options=19b > ether xx:xx:xx:xx:xx:xx > media: Ethernet autoselect > status: no carrier > > All LEDs are off. > > Device was found on boot: > > em0: port 0x3000-0x301f > mem 0xee000 000-0xee01ffff irq 16 at device 0.0 on pci2 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: xx:xx:xx:xx:xx:xx > > -- > Martin > Telling me what kind of NIC it is isn't going to help, 82573's are working the world over :) What exactly is your laptop, what model, is the NIC a LOM (on the motherboard) or some addin. Some random thoughts: There should be NO need to specify full duplex, if you have to do that then you have some problem with your switch. Are you loading the driver as a module, or is it static? So, if you do this: get a cable and eliminate any switch, just a back to back connection between two machines, then if you load the driver and ifconfig address up... what happens?? Jack From sam at freebsd.org Sat Aug 2 18:39:25 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Aug 2 18:39:32 2008 Subject: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ? In-Reply-To: <20080802.002039.58462077.imp@bsdimp.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> Message-ID: <4894A9D8.2090606@freebsd.org> M. Warner Losh wrote: > In message: <372128.56919.qm@web51502.mail.re2.yahoo.com> > fbsd2 writes: > : Greetings list, > : > : Given recent EOL announcements, I'm trying to upgrade an ancient machine from 5.5 to 7. It has 80 Mb total in the root partition, /home/, /var/, /usr/, and /tmp/ on other partitions, and NFS mounts /usr/src, /usr/obj, and /usr/ports from a slightly newer/faster box. I've seen > : > : http://www.freebsd.org/releases/7.0R/relnotes.html and > : http://marc.info/?l=freebsd-stable&m=121278826119286&w=2 > : > : which seem to suggest that even with INSTALL_NODEBUG during buildkernel, 7 might not fit in an 80 Mb /. Must I partition a new disk to give more space to /, or can I find more space by deleting /stand/, /modules/, and possibly /rescue/ to shoehorn a custom 7.x kernel in the available space? TIA > > Doesn't look like anybody has answered this question... > > 80MB is plenty, even for 7.x. However, you'll have to use nanobsd or > tinybsd to get that small. You'll likely been unable to do a 'make > installworld' to get this size. You'll have to create an image and > push it over to this machine somehow. > > In the 3.x time frame, I had FreeBSD booting with the standard scripts > in 13MB without compression. 4.x, 5.x and 6.x bloated these binaries > to about 18MB (a few more were added). I haven't built a system based > on 7.x with this system due to a change in employment, but expect that > it wouldn't be much larger than 20MB for these same files. Some > careful honing could reduce that a little, but maybe not a lot. > Typical embedded systems that I shipped were on the order of 24MB > without X11 and 32-60MB for those with an X11 server. > > What's this box used for? > > I've been looking at nanobsd for a couple of applications and working to reduce the footprint of the images without hacking special rules. With the existing set of WITHOUT knobs in the build system you get a 48M image. With my additional knobs I have this down to 24M. There are still numerous bits of junk that must be removed with special rules unless I go the complete route and add WITHOUT knobs for just about everything. I'd much prefer an opt-in configuration scheme but wasn't keen on what I see in existing packaging systems. Like you I have my own packaging system (works on HEAD and RELENG_[4567] though stuff <7 is probably rotted) but hope to move away from it. In the long run I doubt nanobsd will work for a true embedded application (with my private tools my current RELENG_7 firewall is 10M and includes bind+dhcpd). The other area that I hope to improve on in nanobsd is build time. At the moment you're required to build a bunch of stuff just to throw it away. This is unacceptable with our current build times being so long. My main motivation for improving nanobsd is to offer it as a way to package embedded cross-builds. I've got examples to cross-build images for the AVILA board (it's trivial and I'm sure can be done by other systems like tinybsd so long as they use the buildworld infrastructure). To get past the current 24M barrier I'll need to attack individual applications. For example bind is currently huge and ancillary tools like dig are almost as big! I haven't looked at why but for my current firewall I crunchgen bind and related tools into an image together w/ various other bits. If we're ever to consider building images for flash parts (not compact flash) then we'll need to do a lot of work to pare down the bloat--or replace current apps w/ special purpose replacements a la busybox (not something I find appealing). Sam From nakal at web.de Sat Aug 2 20:40:50 2008 From: nakal at web.de (Martin) Date: Sat Aug 2 20:40:57 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> Message-ID: <20080802224046.3b547283@web.de> On Sat, 02 Aug 2008 12:55:53 +0200 Torfinn Ingolfsen wrote: > Just to be sure: also if the first command you try on the interface is > 'ifconfig up'? Hello Torfinn, good point, no. The problem appears when the first thing called on this interface is dhclient (caused by ifconfig_em0="DHCP"). I could also provoke this behavior after the interface was once up had an IP and was working (ping). All I need to do is to disconnect the NIC from the switch when I type "/etc/rc.d/netif restart". I have noticed further strange effects here. The behavior seems to be even more complex. After I typed "/etc/rc.d/netif restart", I waited until I get "giving up" message. Then I plugged the cable in. After about 30 seconds the link LED was on. I noticed that at this point I couldn't get an address using DHCP. So I disconnected physically the NIC (no cable) and link LED was still on! ifconfig showed me "state: active" with no cable plugged in. After further 30 seconds the LED went off. I attached the NIC again to the switch again and after 30 seconds again I got some other effect. The link LED went on (status: active) and the data LED was permanently blinking (about 2,5 times a second). I pulled the cable again and now the link LED is still on and the data LED still blinking (since about 10 minutes already). By the way... Now I'm typing this E-Mail without an ethernet cable plugged in and the link status LED is still on and the other data LED is blinking. -- Martin From ebutusov at gmail.com Sat Aug 2 21:15:35 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Sat Aug 2 21:15:45 2008 Subject: 7-STABLE, gjournal and fsck. Message-ID: <4894CE6D.2000204@gmail.com> Hi, Recently I've decided to play with gjournal. Main reason was a promise of avoiding full fsck check after unclean shutdown. I've successfuly configured gjournal on existing filesystems (all UFS). And then it happened - my system had a power failure. After boot, it forced me to run fsck manualy. Nothing special, I did it before... But this time it failed on gjournaled disks. So, when I was dropped to the single-user shell, I tried: fsck /dev/ad4s1g.journal It said: CANNOT READ BLK: xxxx CONTINUE? [yn] I typed 'y' and nothing happened. Here is the log: -8<- Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g contains data. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g contains journal. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad4s1g clean. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d contains data. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d contains journal. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1d clean. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e contains data. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e contains journal. Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1e clean. ... Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal Aug 2 19:13:43 matrix kernel: Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] Aug 2 19:13:43 matrix kernel: Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: 727112224, 727112225, 727112226, 727112227, Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT FILE SYSTEM PARTITION ->8- After ctrl+d the system tried to continue boot, and again threw me into shell because of the same reason: -8<- Aug 2 19:13:43 matrix kernel: WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck Aug 2 19:13:43 matrix kernel: mount: ->8- Like I mentioned, only gjournaled filesystems failed to pass fsck. Other labels passed. I was in a hurry, because the machine acts as a local file server, and I was standing against the wall, because one of gjournaled disks was the share itself... What I did was mounting gjournaled partitions in ro mode (it warned me that they were not cleanly unmounted) and doing some backup. Then I removed gjournal (gjournal clear, tunefs -J disable) from journaled disks, ran fsck (few errors of type: PARTIALLY ALLOCATED INODE), and then I was able to turn on softupdates back and mount the fs in rw mode. I've double checked the disk's SMART results in case of hardware failure, but they were ok. My question is: what could cause such problem? Why only gjournaled fs are affected? Is there a solution? Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From torfinn.ingolfsen at broadpark.no Sat Aug 2 21:50:12 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sat Aug 2 21:50:19 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080802224046.3b547283@web.de> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> <20080802224046.3b547283@web.de> Message-ID: <20080802235010.facd4cb9.torfinn.ingolfsen@broadpark.no> On Sat, 02 Aug 2008 22:40:46 +0200 Martin wrote: > good point, no. The problem appears when the first thing called on > this interface is dhclient (caused by ifconfig_em0="DHCP"). I could So, if you don't automatically configure the interface, but instead do something like: 'ifconfig em0 up' and then the DHCP stuff does the interface work then? -- Regards, Torfinn Ingolfsen From koitsu at FreeBSD.org Sat Aug 2 21:58:14 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Aug 2 21:58:20 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <4894CE6D.2000204@gmail.com> References: <4894CE6D.2000204@gmail.com> Message-ID: <20080802215814.GA20164@eos.sc1.parodius.com> On Sat, Aug 02, 2008 at 11:15:25PM +0200, Eugene Butusov wrote: > Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 > Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE > READ: 727112224, 727112225, 727112226, 727112227, > Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT > FILE SYSTEM PARTITION > ... > I've double checked the disk's SMART results in case of hardware > failure, but they were ok. > > My question is: what could cause such problem? Why only gjournaled fs > are affected? Is there a solution? 1) What brand of disks are these? Can you show them in dmesg? 2) Can you provide smartctl -a /dev/ad4 output please? -- | Jeremy Chadwick jdc 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 | From jille at quis.cx Sat Aug 2 22:07:38 2008 From: jille at quis.cx (Jille) Date: Sat Aug 2 22:07:46 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <4894CE6D.2000204@gmail.com> References: <4894CE6D.2000204@gmail.com> Message-ID: <4894D462.5@quis.cx> Hello, I also had those "PARTIALLY ALLOCATED INODE", errors. They only happened on one disk (SATA with PCI SATA converter), and my other ATA disks worked fine. I unplugged my SATA disk, and the ATA's started giving errors. Well, whatever, I screwed up my hardware with a really dumb mistake (don't even dare telling you) and that let it give some quite random errors. So you might want to do some real good hardware checks ;) -- Jille Eugene Butusov schreef: > Hi, > > Recently I've decided to play with gjournal. Main reason was a promise > of avoiding full fsck check after unclean shutdown. I've successfuly > configured gjournal on existing filesystems (all UFS). And then it > happened - my system had a power failure. After boot, it forced me to > run fsck manualy. Nothing special, I did it before... But this time it > failed on gjournaled disks. > > So, when I was dropped to the single-user shell, I tried: > > fsck /dev/ad4s1g.journal > > It said: > > CANNOT READ BLK: xxxx > CONTINUE? [yn] > > I typed 'y' and nothing happened. Here is the log: > > -8<- > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad4s1g clean. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1d clean. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1e clean. > ... > Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 > Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE > READ: 727112224, 727112225, 727112226, 727112227, > Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT > FILE SYSTEM PARTITION > ->8- > > After ctrl+d the system tried to continue boot, and again threw me into > shell because of the same reason: > > -8<- > Aug 2 19:13:43 matrix kernel: > WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck > Aug 2 19:13:43 matrix kernel: mount: > ->8- > > Like I mentioned, only gjournaled filesystems failed to pass fsck. Other > labels passed. I was in a hurry, because the machine acts as a local > file server, and I was standing against the wall, because one of > gjournaled disks was the share itself... > > What I did was mounting gjournaled partitions in ro mode (it warned me > that they were not cleanly unmounted) and doing some backup. Then I > removed gjournal (gjournal clear, tunefs -J disable) from journaled > disks, ran fsck (few errors of type: PARTIALLY ALLOCATED INODE), and > then I was able to turn on softupdates back and mount the fs in rw mode. > I've double checked the disk's SMART results in case of hardware > failure, but they were ok. > > My question is: what could cause such problem? Why only gjournaled fs > are affected? Is there a solution? > > Best regards, From ebutusov at gmail.com Sat Aug 2 22:14:47 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Sat Aug 2 22:14:55 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <20080802215814.GA20164@eos.sc1.parodius.com> References: <4894CE6D.2000204@gmail.com> <20080802215814.GA20164@eos.sc1.parodius.com> Message-ID: <4894DC4C.7030001@gmail.com> Jeremy Chadwick wrote: > On Sat, Aug 02, 2008 at 11:15:25PM +0200, Eugene Butusov wrote: >> Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal >> Aug 2 19:13:43 matrix kernel: >> Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 >> Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] >> Aug 2 19:13:43 matrix kernel: >> Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE >> READ: 727112224, 727112225, 727112226, 727112227, >> Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT >> FILE SYSTEM PARTITION >> ... >> I've double checked the disk's SMART results in case of hardware >> failure, but they were ok. >> >> My question is: what could cause such problem? Why only gjournaled fs >> are affected? Is there a solution? > > 1) What brand of disks are these? Can you show them in dmesg? > 2) Can you provide smartctl -a /dev/ad4 output please? > Here it is: 1) dmesg | grep WDC > ad4: 476940MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA150 2) smartctl -a /dev/ad4 > smartctl version 5.37 [i386-portbld-freebsd7.0] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: WDC WD5000AAKS-00A7B0 Serial Number: WD-WMASY1630383 Firmware Version: 01.03B01 User Capacity: 500 107 862 016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Aug 3 00:10:53 2008 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (10800) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 127) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 155 155 021 Pre-fail Always - 5208 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 9 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 051 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 192 10 Spin_Retry_Count 0x0032 100 253 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 9 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 8 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 9 194 Temperature_Celsius 0x0022 112 102 000 Old_age Always - 35 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 051 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From rizzo at iet.unipi.it Sat Aug 2 22:54:40 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Aug 2 22:54:47 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <4894A9D8.2090606@freebsd.org> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> Message-ID: <20080802225643.GA84798@onelab2.iet.unipi.it> On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: ... > I've been looking at nanobsd for a couple of applications and working to > reduce the footprint of the images without hacking special rules. With ... > If we're ever to consider building images for flash parts (not compact > flash) then we'll need to do a lot of work to pare down the bloat--or > replace current apps w/ special purpose replacements a la busybox (not > something I find appealing). related to this thread -- does anyone have experience in trying to build busybox on FreeBSD ? Also, what would you suggest as a small scripting language to be used in this kind of platform for implementing CGI scripts (and preferably able to use sockets/select) ? The various perl/python/php and friend are in the 10MB range once you pick up a little bit of libraries (sockets etc) and the tangle of modules they require; awk (which is present in busybox) is ok-ish for some things, but doing I/O and calling external programs with it is very unfriendly; javascript/spidermonkey is on the 500KB range but it doesn't have a library to play with sockets... cheers luigi From jfvogel at gmail.com Sat Aug 2 23:01:38 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sat Aug 2 23:01:45 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080802224046.3b547283@web.de> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> <20080802224046.3b547283@web.de> Message-ID: <2a41acea0808021601u13147294r9dc44a737119648@mail.gmail.com> On Sat, Aug 2, 2008 at 1:40 PM, Martin wrote: > On Sat, 02 Aug 2008 12:55:53 +0200 > Torfinn Ingolfsen wrote: > >> Just to be sure: also if the first command you try on the interface is >> 'ifconfig up'? > > Hello Torfinn, > > good point, no. The problem appears when the first thing called on this > interface is dhclient (caused by ifconfig_em0="DHCP"). I could also > provoke this behavior after the interface was once up had an IP and was > working (ping). All I need to do is to disconnect the NIC from the > switch when I type "/etc/rc.d/netif restart". > > I have noticed further strange effects here. The behavior seems to > be even more complex. > > After I typed "/etc/rc.d/netif restart", I waited until I get "giving > up" message. Then I plugged the cable in. After about 30 seconds the > link LED was on. I noticed that at this point I couldn't get an address > using DHCP. Well DUH, the agent exited, thats why it said "giving up" :) That ain't complex behavior, its behaving as designed. > So I disconnected physically the NIC (no cable) and link LED was > still on! ifconfig showed me "state: active" with no cable plugged in. > After further 30 seconds the LED went off. > > I attached the NIC again to the switch again and after 30 seconds > again I got some other effect. The link LED went on (status: active) > and the data LED was permanently blinking (about 2,5 times a second). I > pulled the cable again and now the link LED is still on and the data > LED still blinking (since about 10 minutes already). Ya, so the update is slow, the fact that the LED is blinking means you have an autoneg failure, so again, its your switch not the NIC. Let me guess, you have some 100Mb home router and you are trying to plug a gig nic into it and forcing the speed maybe? I asked for a hardware list, now that includes the switch. Jack From koitsu at FreeBSD.org Sat Aug 2 23:06:27 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Aug 2 23:06:34 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <4894DC4C.7030001@gmail.com> References: <4894CE6D.2000204@gmail.com> <20080802215814.GA20164@eos.sc1.parodius.com> <4894DC4C.7030001@gmail.com> Message-ID: <20080802230626.GA24435@eos.sc1.parodius.com> On Sun, Aug 03, 2008 at 12:14:36AM +0200, Eugene Butusov wrote: > 2) smartctl -a /dev/ad4 > ... > 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 > 200 Multi_Zone_Error_Rate 0x0008 100 253 051 Old_age Offline - 0 > ... The other SMART stats look okay, but can you run an offline test which should update counters 198 and 200? smartctl -t offline /dev/ad4 should do the trick. It may take some time, especially if the disk is being used. And for clarification: just because the test is called "offline" does not mean it brings the disk offline (it doesn't). :-) -- | Jeremy Chadwick jdc 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 | From sam at freebsd.org Sat Aug 2 23:07:48 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Aug 2 23:07:55 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <20080802225643.GA84798@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> Message-ID: <4894E8C3.5060004@freebsd.org> Luigi Rizzo wrote: > On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: > ... >> I've been looking at nanobsd for a couple of applications and working to >> reduce the footprint of the images without hacking special rules. With > ... >> If we're ever to consider building images for flash parts (not compact >> flash) then we'll need to do a lot of work to pare down the bloat--or >> replace current apps w/ special purpose replacements a la busybox (not >> something I find appealing). > > related to this thread -- does anyone have experience in trying > to build busybox on FreeBSD ? My last experience w/ busybox was >1 year ago and I'm not sure I was using anything close to up to date, but...it was utterly linux-specific. Given what it does and what I saw in the code I'd be more inclined to write one from scratch. But having said that I'm not really sure it's worthwhile; I think I'd rather put effort into putting some of the existing tools on a diet (possibly under #ifdefs) and then use crunchgen. I'm pretty sure you'd come up with something higher quality and with a similar footprint. > > Also, what would you suggest as a small scripting language to be used > in this kind of platform for implementing CGI scripts (and preferably > able to use sockets/select) ? > > The various perl/python/php and friend are in the 10MB range once you > pick up a little bit of libraries (sockets etc) and the tangle of > modules they require; awk (which is present in busybox) is ok-ish for > some things, but doing > I/O and calling external programs with it is very unfriendly; > javascript/spidermonkey is on the 500KB range but it doesn't have > a library to play with sockets... Not sure about scripting languages but what's really needed is a lightweight http solution that supports ssl. This can go a long way before you get to php et. al. My last project of this sort used tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we didn't try to fit in flash, we used compact flash parts. I think tinyhttpd+php is also what m0n0wall and pfsense use but haven't looked in a while. Sam From xi at borderworlds.dk Sat Aug 2 23:24:30 2008 From: xi at borderworlds.dk (Christian Laursen) Date: Sat Aug 2 23:24:36 2008 Subject: busybox and small scripting languages on FreeBSD ? In-Reply-To: <20080802225643.GA84798@onelab2.iet.unipi.it> (Luigi Rizzo's message of "Sun\, 3 Aug 2008 00\:56\:43 +0200") References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> Message-ID: Luigi Rizzo writes: > Also, what would you suggest as a small scripting language to be used > in this kind of platform for implementing CGI scripts (and preferably > able to use sockets/select) ? Take a look at lua. It should have a pretty small footprint looks pretty easy to use - either standalone or embedded in you own programs. -- Christian Laursen From rizzo at iet.unipi.it Sat Aug 2 23:34:09 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Aug 2 23:34:16 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <4894E8C3.5060004@freebsd.org> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <4894E8C3.5060004@freebsd.org> Message-ID: <20080802233613.GA85083@onelab2.iet.unipi.it> On Sat, Aug 02, 2008 at 04:07:47PM -0700, Sam Leffler wrote: > Luigi Rizzo wrote: ... > >Also, what would you suggest as a small scripting language to be used > >in this kind of platform for implementing CGI scripts (and preferably > >able to use sockets/select) ? ... > Not sure about scripting languages but what's really needed is a > lightweight http solution that supports ssl. This can go a long way > before you get to php et. al. My last project of this sort used > tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we > didn't try to fit in flash, we used compact flash parts. I think > tinyhttpd+php is also what m0n0wall and pfsense use but haven't looked > in a while. I think this http/ssl problem is reasonably well addressed by mini_httpd (this is Jeff Pozkanzer's code, about 50kb) and a small SSL library which you find in ports/security/xyssl (300kb). Mini_httpd uses the regular openssl libraries, but the xyssl API is reasonably similar to the SSL_* calls in openssl so it should be relatively straightforward to use in mini_httpd -- I did this in another project, even though only on the client side of https http://info.iet.unipi.it/~luigi/FreeBSD/minixmlrpc/ and it took very short time to adapt the code from openssl to xyssl. cheers luigi From koitsu at FreeBSD.org Sat Aug 2 23:38:15 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Aug 2 23:38:22 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <4894E8C3.5060004@freebsd.org> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <4894E8C3.5060004@freebsd.org> Message-ID: <20080802233814.GA25565@eos.sc1.parodius.com> On Sat, Aug 02, 2008 at 04:07:47PM -0700, Sam Leffler wrote: > Luigi Rizzo wrote: >> On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: >> ... >>> I've been looking at nanobsd for a couple of applications and working >>> to reduce the footprint of the images without hacking special rules. >>> With >> ... >>> If we're ever to consider building images for flash parts (not >>> compact flash) then we'll need to do a lot of work to pare down the >>> bloat--or replace current apps w/ special purpose replacements a la >>> busybox (not something I find appealing). >> >> related to this thread -- does anyone have experience in trying >> to build busybox on FreeBSD ? > > My last experience w/ busybox was >1 year ago and I'm not sure I was > using anything close to up to date, but...it was utterly linux-specific. > Given what it does and what I saw in the code I'd be more inclined to > write one from scratch. I've also dealt with Busybox under Linux, specifically on embedded environments (Linksys WRT54G-series). And I agree -- the code is absolutely *horrible*. It resembles years of multiple people hacking on it, one line at a time, with code comments ranging from very few to none. I found a major file descriptor leak in the Busybox code, and Googling details revealed that the Debian folks had also found it. Throughout numerous parts of Busybox, close(2) wasn't being called. The implications here are tremendous, especially since this program is being toted as "a fantastic application suite for embedded systems". The bug has since been fixed, but that kind of mistake is negligent. I would highly recommend creating something else from the ground up, or as Sam recommended, slimming down existing applications. > Not sure about scripting languages but what's really needed is a > lightweight http solution that supports ssl. This can go a long way > before you get to php et. al. My last project of this sort used > tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we > didn't try to fit in flash, we used compact flash parts. I think > tinyhttpd+php is also what m0n0wall and pfsense use but haven't looked > in a while. I'm sure PHP suffices for environments which have CF/SD cards, or actual ATA disks -- but for real embedded environments (read: 4-8MB flash, etc.) PHP won't work. The stripped binary comes out to a little over 2MB. If the webserver chosen supported something like an extended version of server-parsed HTML, that could be benefitial here. Also, I'll take a moment to point out that the webserver that's used on the WRT54G platform (I believe Busybox's internal HTTP server, but I could be wrong) is horrible performance-wise. It doesn't matter what flavour of release (Tomato, Thibor, DD-WRT, OpenWRT, etc.) you go with -- a single page load results in a good 40-50 individual TCP connections being made to the webserver. You can practically deadlock the box by continually clicking Reload in your browser. This is probably because the webserver doesn't support Keepalives or HTTP/1.1, but again, the implications are horrible when you consider these boxes are commonly being used for NAT; resource starvation seems likely. If tinyhttp supports 1.1 or Keepalives, great, problem solved. -- | Jeremy Chadwick jdc 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 | From torfinn.ingolfsen at broadpark.no Sat Aug 2 23:50:56 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sat Aug 2 23:51:03 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? Message-ID: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> Hello, got this old machine, a SX270[1] that I thought I would put to use as my workstation (yes, my current workstation have lower specs than this machine). I have installed FreeBSD[2] 7.0-stable on it (i386). Normal[3] and verbose[4] dmesgs are available. Everything seems to work, but there is one thing tha doesn't: it doesn't report thermal parameters via acpi: root@kg-work2# sysctl hw.acpi.thermal sysctl: unknown oid 'hw.acpi.thermal' n fact the whole acpi section from sysctl seems a bit incomplete: root@kg-work2# sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 There is an acpidump[5] available too (from 'acpidump -dt'). The bios on this machine is from 2004, and that might be the cause. I couldn't find a newer bios than version A06, release date 09/29/2004. Does anybody know about a newer bios for thios machine anywhere? Or does anybody know how to fix the DSDT in the bios to enable thernal reporting? Or perhaps there is a way to read the temperature off the cpu, like the coretemp(4) driver? For those who wonders: yes, I have tried mbmon, lmmon from ports, but they didn't report anything useful as far as temperature goes. root@kg-work2# mbmon -d -A ioctl(smb0:open): No such file or directory SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM available on it!! Summary of Detection: * No monitors found. InitMBInfo: Bad file descriptor This program needs "setuid root"!! Output from 'lmmon -si': Motherboard Temp Voltages 255C / 491F / 528K Vcore1: +3.984V Vcore2: +3.984V Fan Speeds + 3.3V: +3.984V + 5.0V: +6.654V 1: 0 rpm +12.0V: +15.938V 2: 0 rpm -12.0V: -15.938V 3: 0 rpm - 5.0V: -6.654V I think 255 degrees Celsius is a bit unrealistic, the machine can't fry eggs yet. :-) Any good hints will be gratefully accepted. References: 1) SX270 - http://tingox.googlepages.com/sx270 2) http://tingox.googlepages.com/sx270_freebsd 3) http://tingox.googlepages.com/w2-dmesg-7.0-stable-20080721.txt 4) http://tingox.googlepages.com/w2-dmesg-7.0-stable-20080721_verbose.txt 5) http://tingox.googlepages.com/sx270-acpidump-dt-20080721.txt.gz -- Regards, Torfinn Ingolfsen, Norway From andymac at bullseye.apana.org.au Sun Aug 3 02:29:23 2008 From: andymac at bullseye.apana.org.au (Andrew MacIntyre) Date: Sun Aug 3 02:29:31 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <20080802225643.GA84798@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> Message-ID: <48950685.4020303@bullseye.andymac.org> Luigi Rizzo wrote: > Also, what would you suggest as a small scripting language to be used > in this kind of platform for implementing CGI scripts (and preferably > able to use sockets/select) ? > > The various perl/python/php and friend are in the 10MB range once you > pick up a little bit of libraries (sockets etc) and the tangle of > modules they require; awk (which is present in busybox) is ok-ish for > some things, but doing I/O and calling external programs with it is > very unfriendly; I've not tried to do this myself (had no need), but Python does support having its standard library code in a ZIP archive. The .py (source) files can be omitted, so the ZIP archive only needs to contain the byte compiled files (.pyc, and .pyo if you ever use Python's -O option). With a stripped interpreter, I'd estimate you might get an install down to ~6MB, with non-essentials (for an embedded production environment) removed. But you do have to work at it... :-( I hear Lua is compact and capable, including sockets support, but have never looked at it. -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From jeremy at segpub.com.au Sun Aug 3 02:52:53 2008 From: jeremy at segpub.com.au (Jeremy Bogan) Date: Sun Aug 3 02:53:00 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <20080802233613.GA85083@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <4894E8C3.5060004@freebsd.org> <20080802233613.GA85083@onelab2.iet.unipi.it> Message-ID: <7DE3CD09-5DE0-4DCB-BF03-A17A3E9EC602@segpub.com.au> Nginx works nicely in a small environment. On 03/08/2008, at 9:36 AM, Luigi Rizzo wrote: > On Sat, Aug 02, 2008 at 04:07:47PM -0700, Sam Leffler wrote: >> Luigi Rizzo wrote: > ... >>> Also, what would you suggest as a small scripting language to be >>> used >>> in this kind of platform for implementing CGI scripts (and >>> preferably >>> able to use sockets/select) ? > ... >> Not sure about scripting languages but what's really needed is a >> lightweight http solution that supports ssl. This can go a long way >> before you get to php et. al. My last project of this sort used >> tinyhttp (I think, whichever one Jeff Pozkanzer did) and php. But we >> didn't try to fit in flash, we used compact flash parts. I think >> tinyhttpd+php is also what m0n0wall and pfsense use but haven't >> looked >> in a while. > > I think this http/ssl problem is reasonably well addressed by > mini_httpd (this is Jeff Pozkanzer's code, about 50kb) and a small > SSL library which you find in ports/security/xyssl (300kb). > > Mini_httpd uses the regular openssl libraries, but the xyssl API is > reasonably similar to the SSL_* calls in openssl so it should be > relatively straightforward to use in mini_httpd -- I did this in > another project, even though only on the client side of https > http://info.iet.unipi.it/~luigi/FreeBSD/minixmlrpc/ > and it took very short time to adapt the code from openssl to xyssl. > > cheers > luigi > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > -- jeremy bogan [ jeremy@segpub.com.au ] segment publishing - design.develop.host From db at db.net Sun Aug 3 03:16:20 2008 From: db at db.net (Diane Bruce) Date: Sun Aug 3 03:16:27 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <20080802233814.GA25565@eos.sc1.parodius.com> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <4894E8C3.5060004@freebsd.org> <20080802233814.GA25565@eos.sc1.parodius.com> Message-ID: <20080803031615.GA46483@night.db.net> On Sat, Aug 02, 2008 at 04:38:14PM -0700, Jeremy Chadwick wrote: > On Sat, Aug 02, 2008 at 04:07:47PM -0700, Sam Leffler wrote: > > Luigi Rizzo wrote: > >> On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: > >> ... > >>> I've been looking at nanobsd for a couple of applications and working > >>> to reduce the footprint of the images without hacking special rules. ... > >>> compact flash) then we'll need to do a lot of work to pare down the > >>> bloat--or replace current apps w/ special purpose replacements a la > >>> busybox (not something I find appealing). What's wrong with /rescue being used for this? ls -ltai /rescue 70662 -r-xr-xr-x 121 root wheel 3728352 Jul 22 14:56 [ 70662 -r-xr-xr-x 121 root wheel 3728352 Jul 22 14:56 atacontrol 70662 -r-xr-xr-x 121 root wheel 3728352 Jul 22 14:56 atmconfig Still a little too large? gzipped it's a little less -r-xr-xr-x 1 db wheel 1772385 Aug 2 23:11 /tmp/vi.gz I bet it would be easier to trim down the number of utilities in /rescue to make a smaller image than to make busybox go. > >> related to this thread -- does anyone have experience in trying > >> to build busybox on FreeBSD ? > > > > My last experience w/ busybox was >1 year ago and I'm not sure I was > > using anything close to up to date, but...it was utterly linux-specific. > > Given what it does and what I saw in the code I'd be more inclined to > > write one from scratch. busybox is the worst pile of doggie doo doo I have ever had the misfortune to see. It should be put into a brown paper bag and set on fire after putting it on RMS's doorstep and ringing the doorbell. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From koitsu at FreeBSD.org Sun Aug 3 03:19:12 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Aug 3 03:19:23 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> Message-ID: <20080803031912.GA38781@eos.sc1.parodius.com> On Sun, Aug 03, 2008 at 01:50:53AM +0200, Torfinn Ingolfsen wrote: > The bios on this machine is from 2004, and that might be the cause. I > couldn't find a newer bios than version A06, release date 09/29/2004. > Does anybody know about a newer bios for thios machine anywhere? The first questions to ask are: 1) does this machine even have a H/W monitoring IC on it, and 2) is it enabled/wired to thermistors and fans? > Or does anybody know how to fix the DSDT in the bios to enable thernal > reporting? I don't think this is possible. > Or perhaps there is a way to read the temperature off the cpu, like the > coretemp(4) driver? What processor is in it? Not a Core2Duo. I'm guessing since it's circa 2004, probably a Pentium 3 or 4, or possibly an older AMD. None of those, to my knowledge, have on-die temperatures -- they all rely on external H/W monitoring. I just checked http://tingox.googlepages.com/sx270 and sure enough, an older P4. coretemp(4) won't work with this. > For those who wonders: yes, I have tried mbmon, lmmon from ports, but > they didn't report anything useful as far as temperature goes. healthd, lmmon, and mbmon/xmbmon are all fairly "old", and expect the H/W monitoring IC to be in a specific place, and that the tie-ins exist. > Any good hints will be gratefully accepted. I would start by booting the machine into Windows and install SpeedFan. If that thing is able to detect and provide thermal data, then we can continue from there. Otherwise chances are there's no H/W monitoring IC on the board. P.S. -- If you look at the mainboard and see a Winbond chip, that does not guarantee there's H/W monitoring capabilities. Many of the Winbond ICs provide Super I/O (legacy stuff: floppy, LPT, ISA/PCI interface, etc.), and it's entirely up to the board engineers which IC they use, and if they bother implementing H/W monitoring tie-ins. -- | Jeremy Chadwick jdc 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 | From uspoerlein at gmail.com Sun Aug 3 08:00:21 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Sun Aug 3 08:00:38 2008 Subject: ddb(4) scripts not working in RELENG_7? Message-ID: <20080803075744.GA1555@roadrunner.spoerlein.net> Hi Robert, I was testing a patch and getting a panic (page fault while in kernel mode) in RELENG_7 running multiuser mode, but no scripts were automagically run, although I configured ddb_enable=YES in rc.conf. It simply dropped me to the interactive ddb(4) prompt, nothing more. Do you have any idea what I could be missing? Btw, you might wanna update the ddb(8) manpage's History section, as the feature seems to first appear in 7.1 :) % egrep "ddb|dump" /etc/rc.conf dumpdev="/dev/ad0s3" ddb_enable="YES" % sysctl debug.ddb.scripting.scripts debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From ebutusov at gmail.com Sun Aug 3 10:37:17 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Sun Aug 3 10:37:26 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <20080802230626.GA24435@eos.sc1.parodius.com> References: <4894CE6D.2000204@gmail.com> <20080802215814.GA20164@eos.sc1.parodius.com> <4894DC4C.7030001@gmail.com> <20080802230626.GA24435@eos.sc1.parodius.com> Message-ID: <48958A31.1000305@gmail.com> Jeremy Chadwick wrote: > On Sun, Aug 03, 2008 at 12:14:36AM +0200, Eugene Butusov wrote: >> 2) smartctl -a /dev/ad4 >> ... >> 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 >> 200 Multi_Zone_Error_Rate 0x0008 100 253 051 Old_age Offline - 0 >> ... > > The other SMART stats look okay, but can you run an offline test which > should update counters 198 and 200? smartctl -t offline /dev/ad4 should > do the trick. It may take some time, especially if the disk is being > used. > > And for clarification: just because the test is called "offline" does > not mean it brings the disk offline (it doesn't). :-) I did smartctl -t offline /dev/ad4, here is the results: 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline - 0 I think the problem lies in fsck itself. Somehow it is was unable to deal with journaled filesystems It has failed to read them and mark them as clean. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From rwatson at FreeBSD.org Sun Aug 3 10:54:43 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 3 10:54:50 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you Message-ID: Dear all: This is an advance warning that, late next week, I will be merging a fairly large set of changes to the IPv4 and IPv6 protocols layered over the inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, UDP, and raw sockets on both IPv4 and IPv6. I will post a further e-mail announcement along with patch set and schedule in a day or two once it's prepared. The thrust of this change is to replace the mutexes protecting the inpcb and inpcbinfo data structures with read-write locks (rwlocks). These structures represent, respectively, particular sockets and the global socket lists for all socket types in IPv4 and IPv6 except for SCTP. When you run netstat, inpcbinfo is the data structure referencing all connections, and each line in the nestat output reflects the contents of a specific inpcb. In the current stage of this work, the intent is to improve performance for datagram-related protocols on SMP systems by allowing concurrent acquisition of both global and connection locks during receive and transmit. This is possible because, in the common case, no connection or global state is modified during UDP/raw receive and transmit at the IP layer, so a read lock is sufficient to prevent data in those structures from unexpectedly changing. For receive, socket layer state is modified, but this is separately protected by socket layer locks. On transmit, no state is modified at any layer, so in principle we will allow fully parallel transmit from multiple threads down to about the routing and network interface layers, whereas previously they would bottleneck in UDP. The applications targeted by this change are threaded UDP server applications, such as BIND9, nsd, and UDP-based memcached. Kris Kennaway and Paul Saab have done fairly extensive testing with the changes and demonstrated significant performance improvements due to reduced contention and overhead. Perhaps they can mention some of those numbers in a follow-up to this post. The reason for the heads up is that, while carefully-tested, changes of this sort do come with risks. We've carefully structured them so as to avoid breaking the ABIs for netstat, etc, but it's not impossible that some problems will arise as the changes settle. The goal, however, is to see these performance improvements in 7.1, and since they've had a bit to shake out in 8.x and seen some heavy use, I think now is the right time to merge them. In any case, I will send out e-mail in a couple of days with a proposed merge patch and schedule for merging, and perhaps if you are in a positition where you might benefit from these improvements, or have interesting UDP or raw-socket based applications running on 7.x, you could test the candidate patch before it's merged, reporting any problems. Unless I receive negative feedback, I will plan on merging the changes late in the week, and keep a close eye on stable@ for any reports of problems. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From torfinn.ingolfsen at broadpark.no Sun Aug 3 11:52:54 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sun Aug 3 11:53:02 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803031912.GA38781@eos.sc1.parodius.com> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> <20080803031912.GA38781@eos.sc1.parodius.com> Message-ID: <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> On Sat, 02 Aug 2008 20:19:12 -0700 Jeremy Chadwick wrote: > On Sun, Aug 03, 2008 at 01:50:53AM +0200, Torfinn Ingolfsen wrote: > The first questions to ask are: 1) does this machine even have a H/W > monitoring IC on it, and 2) is it enabled/wired to thermistors and > fans? Yes, but so far I haven't found out anything by searching. > What processor is in it? Not a Core2Duo. I'm guessing since it's > circa 2004, probably a Pentium 3 or 4, or possibly an older AMD. Pentium 4. From dmesg: CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2593.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 > None of those, to my knowledge, have on-die temperatures -- they all > rely on external H/W monitoring. Ok, so what is the 'TM' feature of this cpu then? cpuid thinks it is a thermal monitor: Intel-specific functions: Version 00000f29: Type 0 - Original OEM Family 15 - Pentium 4 Extended family 0 Model 2 - Intel Pentium 4 processor (generic) or newer Stepping 9 Reserved 0 Brand index: 9 [Intel Pentium 4 processor] Extended brand string: " Intel(R) Pentium(R) 4 CPU 2.60GHz" CLFLUSH instruction cache line size: 8 Hyper threading siblings: 2 Feature flags: bfebfbff: FPU Floating Point Unit VME Virtual 8086 Mode Enhancements DE Debugging Extensions PSE Page Size Extensions TSC Time Stamp Counter MSR Model Specific Registers PAE Physical Address Extension MCE Machine Check Exception CX8 COMPXCHG8B Instruction APIC On-chip Advanced Programmable Interrupt Controller present and enabled SEP Fast System Call MTRR Memory Type Range Registers PGE PTE Global Flag MCA Machine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension CLFSH CFLUSH instruction DS Debug store ACPI Thermal Monitor and Clock Ctrl MMX MMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore SSE Streaming SIMD Extensions instruction set SSE2 SSE2 extensions SS Self Snoop HT Hyper Threading TM Thermal monitor 31 reserved Feature flags set 2: 00004400: CID Context ID xTPR Send Task Priority messages TLB and cache info: 50: Instruction TLB: 4KB and 2MB or 4MB pages, 64 entries 5b: Data TLB: 4KB and 4MB pages, fully assoc., 64 entries 66: 1st-level data cache: 8KB, 4-way set assoc, 64 byte line size 40: No 2nd-level cache, or if 2nd-level cache exists, no 3rd-level cache 70: Trace cache: 12K-micro-op, 4-way set assoc 7b: 2nd-level cache: 512KB, 8-way set assoc, sectored, 64 byte line size > I just checked http://tingox.googlepages.com/sx270 and sure enough, an > older P4. coretemp(4) won't work with this. I know, I just thought that ther might be something similar for the TM feature of Pentium 4's. > I would start by booting the machine into Windows and install > SpeedFan. If that thing is able to detect and provide thermal data, Ouch. I was hoping that I wouldn't have to do that. The machine have no internal CD-drive, and for some reason doesn't want to boot from a (usb) external cd-drive either (kind of funny - it boots from flash drives and external hard drives. But cd-rom -no). I was hoping to solve this without windows in the picture. -- Regards, Torfinn Ingolfsen From davidn04 at gmail.com Sun Aug 3 11:58:54 2008 From: davidn04 at gmail.com (David N) Date: Sun Aug 3 11:59:04 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <4894CE6D.2000204@gmail.com> References: <4894CE6D.2000204@gmail.com> Message-ID: <4d7dd86f0808030433l6cda06ccjba154d6f0cee7d0e@mail.gmail.com> 2008/8/3 Eugene Butusov : > Hi, > > Recently I've decided to play with gjournal. Main reason was a promise of > avoiding full fsck check after unclean shutdown. I've successfuly configured > gjournal on existing filesystems (all UFS). And then it happened - my system > had a power failure. After boot, it forced me to run fsck manualy. Nothing > special, I did it before... But this time it failed on gjournaled disks. > > So, when I was dropped to the single-user shell, I tried: > > fsck /dev/ad4s1g.journal > > It said: > > CANNOT READ BLK: xxxx > CONTINUE? [yn] > > I typed 'y' and nothing happened. Here is the log: > > -8<- > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad4s1g clean. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1d clean. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e > contains data. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e > contains journal. > Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1e clean. > ... > Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 > Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] > Aug 2 19:13:43 matrix kernel: > Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: > 727112224, 727112225, 727112226, 727112227, > Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT FILE > SYSTEM PARTITION > ->8- > > After ctrl+d the system tried to continue boot, and again threw me into > shell because of the same reason: > > -8<- > Aug 2 19:13:43 matrix kernel: > WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck > Aug 2 19:13:43 matrix kernel: mount: > ->8- > > Like I mentioned, only gjournaled filesystems failed to pass fsck. Other > labels passed. I was in a hurry, because the machine acts as a local file > server, and I was standing against the wall, because one of gjournaled disks > was the share itself... > > What I did was mounting gjournaled partitions in ro mode (it warned me that > they were not cleanly unmounted) and doing some backup. Then I removed > gjournal (gjournal clear, tunefs -J disable) from journaled disks, ran fsck > (few errors of type: PARTIALLY ALLOCATED INODE), and then I was able to turn > on softupdates back and mount the fs in rw mode. I've double checked the > disk's SMART results in case of hardware failure, but they were ok. > > My question is: what could cause such problem? Why only gjournaled fs are > affected? Is there a solution? > > Best regards, > -- > _/_/ .. Eugene Butusov > _/_/ ... www.devilka.info > _/_/ .... ebutusov(at)gmail(dot)com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > Hi, Did you re-create your file systems? How did you create the journal? eg. newfs /dev/ad4s1g.journal ? or did you just enable journal on the partition? via tunefs? Regards David N From rsmith at xs4all.nl Sun Aug 3 12:08:50 2008 From: rsmith at xs4all.nl (Roland Smith) Date: Sun Aug 3 12:08:57 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> <20080803031912.GA38781@eos.sc1.parodius.com> <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> Message-ID: <20080803120842.GA58127@slackbox.xs4all.nl> On Sun, Aug 03, 2008 at 01:52:51PM +0200, Torfinn Ingolfsen wrote: > On Sat, 02 Aug 2008 20:19:12 -0700 > Jeremy Chadwick wrote: > > > On Sun, Aug 03, 2008 at 01:50:53AM +0200, Torfinn Ingolfsen wrote: > > The first questions to ask are: 1) does this machine even have a H/W > > monitoring IC on it, and 2) is it enabled/wired to thermistors and > > fans? > > Yes, but so far I haven't found out anything by searching. > > > What processor is in it? Not a Core2Duo. I'm guessing since it's > > circa 2004, probably a Pentium 3 or 4, or possibly an older AMD. > > Pentium 4. From dmesg: > CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2593.51-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > Features=0xbfebfbff > Features2=0x4400 > Logical CPUs per core: 2 Have you tried sysutils/mbmon? Or running 'sysctl hw.acpi|grep tz'? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080803/3752ab08/attachment.pgp From david at wood2.org.uk Sun Aug 3 12:15:58 2008 From: david at wood2.org.uk (David Wood) Date: Sun Aug 3 12:16:05 2008 Subject: reboot sometimes freezes, adaptic scsi card possible problem In-Reply-To: References: Message-ID: Hi Burt, In message , burt rosenberg writes >On reboot, one out of 10 times, reboot (from hardware initialization) stops. This is about a Dell PowerEdge 2950. I'd start by upgrading the BIOS - and whilst you're at it, I'd bring the whole machine up to date, as the BMC firmware, backplane firmware and PERC firmware are all likely to be out of date as well. The Dell System Build and Update Utility CD with the Server Updates DVD will handle all the necessary updates. The ISOs are available on the Dell Downloads site. The current System Build and Update Utility CD is rather old - I'd use the System Management Tools and Documentation DVD in its place (which boots into the System Build and Update Utility). You boot the System Build and Update Utility CD (or System Management Tools and Documentation DVD), tell the machine that the repository is on a DVD, and it will prompt you to change disk. Insert the Server Updates DVD. You will need console access - keyboard, mouse and monitor. I think I noticed a USB KVM somewhere amongst the information you gave. You don't have a DRAC 5 in the machine - if you did, you could have used the DRAC console. This system handles the correct sequencing of the upgrades (for example, you should upgrade the BMC firmware before the BIOS - at least, I believe that's the correct order, but I'd have to check) and carries out the upgrades in an environment where your hard disks aren't mounted. You may even find you have hard disk firmware updates outstanding. The BIOS in the machine is old - version 1.2.0. The next revision, 1.3.7, which is far from the latest, has something that sounds possibly relevant: Fixed possible issue of system device re-enumeration after power failures. There are also potential updates for your processor microcode and memory reference code just by updating the BIOS. Obviously, upgrading all the firmware in your machine is a potentially dangerous operation. My experience is that all will go well, but I can't guarantee that you won't hit trouble. Best wishes, David -- David Wood david@wood2.org.uk From ebutusov at gmail.com Sun Aug 3 12:35:57 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Sun Aug 3 12:36:05 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <4d7dd86f0808030433l6cda06ccjba154d6f0cee7d0e@mail.gmail.com> References: <4894CE6D.2000204@gmail.com> <4d7dd86f0808030433l6cda06ccjba154d6f0cee7d0e@mail.gmail.com> Message-ID: <4895A61F.8030502@gmail.com> David N wrote: > 2008/8/3 Eugene Butusov : >> Hi, >> >> Recently I've decided to play with gjournal. Main reason was a promise of >> avoiding full fsck check after unclean shutdown. I've successfuly configured >> gjournal on existing filesystems (all UFS). And then it happened - my system >> had a power failure. After boot, it forced me to run fsck manualy. Nothing >> special, I did it before... But this time it failed on gjournaled disks. >> >> So, when I was dropped to the single-user shell, I tried: >> >> fsck /dev/ad4s1g.journal >> >> It said: >> >> CANNOT READ BLK: xxxx >> CONTINUE? [yn] >> >> I typed 'y' and nothing happened. Here is the log: >> >> -8<- >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g >> contains data. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 4059706613: ad4s1g >> contains journal. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad4s1g clean. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d >> contains data. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 188084099: ad6s1d >> contains journal. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1d clean. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e >> contains data. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal 2559963968: ad6s1e >> contains journal. >> Aug 2 19:13:43 matrix kernel: GEOM_JOURNAL: Journal ad6s1e clean. >> ... >> Aug 2 19:13:43 matrix kernel: ** /dev/ad4s1g.journal >> Aug 2 19:13:43 matrix kernel: >> Aug 2 19:13:43 matrix kernel: CANNOT READ BLK: 727112224 >> Aug 2 19:13:43 matrix kernel: CONTINUE? [yn] >> Aug 2 19:13:43 matrix kernel: >> Aug 2 19:13:43 matrix kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: >> 727112224, 727112225, 727112226, 727112227, >> Aug 2 19:13:43 matrix kernel: /dev/ad4s1g.journal: CANNOT FIGURE OUT FILE >> SYSTEM PARTITION >> ->8- >> >> After ctrl+d the system tried to continue boot, and again threw me into >> shell because of the same reason: >> >> -8<- >> Aug 2 19:13:43 matrix kernel: >> WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck >> Aug 2 19:13:43 matrix kernel: mount: >> ->8- >> >> Like I mentioned, only gjournaled filesystems failed to pass fsck. Other >> labels passed. I was in a hurry, because the machine acts as a local file >> server, and I was standing against the wall, because one of gjournaled disks >> was the share itself... >> >> What I did was mounting gjournaled partitions in ro mode (it warned me that >> they were not cleanly unmounted) and doing some backup. Then I removed >> gjournal (gjournal clear, tunefs -J disable) from journaled disks, ran fsck >> (few errors of type: PARTIALLY ALLOCATED INODE), and then I was able to turn >> on softupdates back and mount the fs in rw mode. I've double checked the >> disk's SMART results in case of hardware failure, but they were ok. >> >> My question is: what could cause such problem? Why only gjournaled fs are >> affected? Is there a solution? >> >> Best regards, >> -- >> _/_/ .. Eugene Butusov >> _/_/ ... www.devilka.info >> _/_/ .... ebutusov(at)gmail(dot)com >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > Hi, > > Did you re-create your file systems? How did you create the journal? > > eg. newfs /dev/ad4s1g.journal ? > > or did you just enable journal on the partition? via tunefs? I did it this way: /dev/ad4s1g is my /home, an existing partition umount /home gjournal label -f /dev/ad4s1g tunefs -J enable -n disable /dev/ad4s1g.journal (added 'async' option to /etc/fstab for /home and changed entry to /dev/ad4s1g.journal) mount /home It worked until power failed... :) Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From koitsu at FreeBSD.org Sun Aug 3 13:18:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Aug 3 13:18:16 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <48958A31.1000305@gmail.com> References: <4894CE6D.2000204@gmail.com> <20080802215814.GA20164@eos.sc1.parodius.com> <4894DC4C.7030001@gmail.com> <20080802230626.GA24435@eos.sc1.parodius.com> <48958A31.1000305@gmail.com> Message-ID: <20080803131809.GA65161@eos.sc1.parodius.com> On Sun, Aug 03, 2008 at 12:36:33PM +0200, Eugene Butusov wrote: > Jeremy Chadwick wrote: >> On Sun, Aug 03, 2008 at 12:14:36AM +0200, Eugene Butusov wrote: >>> 2) smartctl -a /dev/ad4 >>> ... >>> 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 >>> 200 Multi_Zone_Error_Rate 0x0008 100 253 051 Old_age Offline - 0 >>> ... >> >> The other SMART stats look okay, but can you run an offline test which >> should update counters 198 and 200? smartctl -t offline /dev/ad4 should >> do the trick. It may take some time, especially if the disk is being >> used. >> >> And for clarification: just because the test is called "offline" does >> not mean it brings the disk offline (it doesn't). :-) > > I did smartctl -t offline /dev/ad4, here is the results: > > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always > - 0 > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline > - 0 > 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always > - 0 > 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline > - 0 > > I think the problem lies in fsck itself. Somehow it is was unable to > deal with journaled filesystems It has failed to read them and mark them > as clean. Yep, I agree, SMART-wise your disk looks fine. It's worth noting that there's been reports of the ATA subsystem reporting I/O errors on LBAs which don't even appear to be valid. I'm left wondering if somehow that's what's happening here. I'm not sure why fsck would handle most of the gjournal'd blocks but not others. -- | Jeremy Chadwick jdc 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 | From dnelson at allantgroup.com Sun Aug 3 13:23:11 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Sun Aug 3 13:23:19 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> <20080803031912.GA38781@eos.sc1.parodius.com> <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> Message-ID: <20080803132309.GC93138@dan.emsphone.com> In the last episode (Aug 03), Torfinn Ingolfsen said: > On Sat, 02 Aug 2008 20:19:12 -0700 Jeremy Chadwick wrote: > > > On Sun, Aug 03, 2008 at 01:50:53AM +0200, Torfinn Ingolfsen wrote: > > The first questions to ask are: 1) does this machine even have a > > H/W monitoring IC on it, and 2) is it enabled/wired to thermistors > > and fans? > > Yes, but so far I haven't found out anything by searching. > > > What processor is in it? Not a Core2Duo. I'm guessing since it's > > circa 2004, probably a Pentium 3 or 4, or possibly an older AMD. > > Pentium 4. From dmesg: > CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2593.51-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > Features=0xbfebfbff > Features2=0x4400 > Logical CPUs per core: 2 > > > None of those, to my knowledge, have on-die temperatures -- they all > > rely on external H/W monitoring. > > Ok, so what is the 'TM' feature of this cpu then? >From what I can find on Intel's site for your CPU, TM is an emergency switch that lowers the CPU speed to pervent overheating that could damage the processor. Under normal circumstances, it should never trip, and its on/off status (not temperature) is only readable by two pins on the CPU. It can be disabled and enabled by software, but not monitored. http://download.intel.com/design/Pentium4/datashts/29864312.pdf "The Thermal Monitor feature helps control the processor temperature by activating the Thermal Control Circuit (TCC) when the processor silicon reaches its maximum operating temperature. The TCC reduces processor power consumption by modulating (starting and stopping) the internal processor core clocks. The Thermal Monitor feature must be enabled for the processor to be operating within specifications. The temperature at which Thermal Monitor activates the thermal control circuit is not user configurable and is not software visible." > > I just checked http://tingox.googlepages.com/sx270 and sure enough, an > > older P4. coretemp(4) won't work with this. > > I know, I just thought that ther might be something similar for the > TM feature of Pentium 4's. > > > I would start by booting the machine into Windows and install > > SpeedFan. If that thing is able to detect and provide thermal data, > > Ouch. I was hoping that I wouldn't have to do that. The machine have > no internal CD-drive, and for some reason doesn't want to boot from a > (usb) external cd-drive either (kind of funny - it boots from flash > drives and external hard drives. But cd-rom -no). > > I was hoping to solve this without windows in the picture. -- Dan Nelson dnelson@allantgroup.com From koitsu at FreeBSD.org Sun Aug 3 13:43:29 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Aug 3 13:43:36 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> <20080803031912.GA38781@eos.sc1.parodius.com> <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> Message-ID: <20080803134328.GA65256@eos.sc1.parodius.com> On Sun, Aug 03, 2008 at 01:52:51PM +0200, Torfinn Ingolfsen wrote: > On Sat, 02 Aug 2008 20:19:12 -0700 > Jeremy Chadwick wrote: > > > On Sun, Aug 03, 2008 at 01:50:53AM +0200, Torfinn Ingolfsen wrote: > > The first questions to ask are: 1) does this machine even have a H/W > > monitoring IC on it, and 2) is it enabled/wired to thermistors and > > fans? > > Yes, but so far I haven't found out anything by searching. Then the only possibility is to take a very high-resolution photo (read: 2048x1536 or higher) and send it to someone who can identify ICs (I'm good at recognising H/W monitoring ICs :-) ). But even that won't guarantee anything; an IC that supports H/W monitoring may be found/present but it may not be wired to support such (or the board lacks thermistors), or possibly the silkscreening is false (which I myself have personally seen on some server boards). > Ok, so what is the 'TM' feature of this cpu then? > cpuid thinks it is a thermal monitor: > Intel-specific functions: > Version 00000f29: > Type 0 - Original OEM > Family 15 - Pentium 4 > Extended family 0 > Model 2 - Intel Pentium 4 processor (generic) or newer > Stepping 9 > Reserved 0 This gets into semantics: "what exactly does 'monitor' mean?" The P4 TM feature is more of a thermal manager and not so much a "monitor" in the sense of what you think it might be (re: ability to provide thermal statistics to a program). It *is* a "monitor" in the sense that it reads temperature, but there's no way to access that internal data. I believe the P4 TM is used to decrease power usage (disabling some features, enabling some power-saving modes, etc.) based on temperature. It probably induces some form of clock throttling too, but it's probably done very differently compared to present-day Core2Duo processors, for example (and those processors DO have on-die per-core temperature monitors which you can monitor, re: coretemp(4)). Here's some reference material confirming my claim: http://www.intel.com/support/processors/pentium4/sb/cs-007999.htm http://www.digit-life.com/articles2/intel-thermal-features/index.html http://www.overclockers.com/articles517/ The point is, none of the internal data is accessible. I have never seen a program provide any sort of thermal data on a P4, unless there's an external H/W monitoring IC (with a thermistor that sits physically under the processor mounting socket) installed. You'll find such features on P4 server boards -- commonly Winbond ICs, with a thermistor that sits directly under the CPU. > > I just checked http://tingox.googlepages.com/sx270 and sure enough, an > > older P4. coretemp(4) won't work with this. > > I know, I just thought that ther might be something similar for the TM feature of Pentium 4's. Nope, because it's not something you can get data from. > > I would start by booting the machine into Windows and install > > SpeedFan. If that thing is able to detect and provide thermal data, > > Ouch. I was hoping that I wouldn't have to do that. The machine have no internal CD-drive, > and for some reason doesn't want to boot from a (usb) external cd-drive either (kind of funny - it boots from flash drives and external hard drives. But cd-rom -no). > > I was hoping to solve this without windows in the picture. You could try Linux. Their lm-sensors project is incredibly thorough, but based on what I've looked at in the code, it's hit-or-miss. It does do a form of auto-probing (which is very risky IMHO). Speedfan's auto-detection method is better, and safer (especially if there's an SMBus interface with H/W monitoring IC tie-ins made available). Again, this would only allow you to detect whether or not there's an actual H/W monitoring IC on the board somewhere. I'm strongly doubting there is. You could contact Dell and ask, but their Support folks probably have no idea what a hardware monitoring IC is (or will lie to you and say "Yes it has it" even though it may not). -- | Jeremy Chadwick jdc 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 | From rwatson at FreeBSD.org Sun Aug 3 13:49:01 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 3 13:49:07 2008 Subject: ddb(4) scripts not working in RELENG_7? In-Reply-To: <20080803075744.GA1555@roadrunner.spoerlein.net> References: <20080803075744.GA1555@roadrunner.spoerlein.net> Message-ID: On Sun, 3 Aug 2008, Ulrich Spoerlein wrote: > I was testing a patch and getting a panic (page fault while in kernel mode) > in RELENG_7 running multiuser mode, but no scripts were automagically run, > although I configured ddb_enable=YES in rc.conf. > > It simply dropped me to the interactive ddb(4) prompt, nothing more. Do you > have any idea what I could be missing? Dear Ulrich: I have been using DDB scripts on 7-STABLE without any problems, but I'm not sure I've tried it with a page fault, just regular panics. Could you try entering the debugger via "sysctl debug.kdb.panic=1", which forces a panic, and see if your scripts run then? Perhaps there's some inconsistency in how we're entering the debugger. If things still appear not to be happening, try setting up a kdb.enter.default script and see if that works? The ddb(4) command provids a slightly more user-friendly way of accessing the scripts from userspace -- you can just do "ddb scripts" to list them. FWIW, using the exactly scripts you have below, I produced a textdump without any problems on 7-STABLE. > Btw, you might wanna update the ddb(8) manpage's History section, as the > feature seems to first appear in 7.1 :) Indeed. I'll update that, thanks! Robert N M Watson Computer Laboratory University of Cambridge > > % egrep "ddb|dump" /etc/rc.conf > dumpdev="/dev/ad0s3" > ddb_enable="YES" > % sysctl debug.ddb.scripting.scripts > debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods > kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset > kdb.enter.witness=run lockinfo > > > Cheers, > Ulrich Spoerlein > -- > It is better to remain silent and be thought a fool, > than to speak, and remove all doubt. > From marck at rinet.ru Sun Aug 3 14:18:00 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Aug 3 14:18:12 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <4895A61F.8030502@gmail.com> References: <4894CE6D.2000204@gmail.com> <4d7dd86f0808030433l6cda06ccjba154d6f0cee7d0e@mail.gmail.com> <4895A61F.8030502@gmail.com> Message-ID: <20080803181633.U64745@woozle.rinet.ru> On Sun, 3 Aug 2008, Eugene Butusov wrote: EB> > Did you re-create your file systems? How did you create the journal? EB> > EB> > eg. newfs /dev/ad4s1g.journal ? EB> > EB> > or did you just enable journal on the partition? via tunefs? EB> EB> I did it this way: EB> EB> /dev/ad4s1g is my /home, an existing partition EB> EB> umount /home EB> gjournal label -f /dev/ad4s1g EB> tunefs -J enable -n disable /dev/ad4s1g.journal EB> (added 'async' option to /etc/fstab for /home and changed entry to EB> /dev/ad4s1g.journal) EB> mount /home EB> EB> It worked until power failed... :) No surprize. with you `gjournal label' command you've effectively destroyed last 1G of UFS. You should use external journal provider in such case. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From louie at transsys.com Sun Aug 3 14:26:23 2008 From: louie at transsys.com (Louis Mamakos) Date: Sun Aug 3 14:26:37 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <20080802225643.GA84798@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> Message-ID: <9C6216B2-AB67-45A2-900C-3492340737DF@transsys.com> On Aug 2, 2008, at 6:56 PM, Luigi Rizzo wrote: > On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: > ... >> I've been looking at nanobsd for a couple of applications and >> working to >> reduce the footprint of the images without hacking special rules. >> With > ... >> If we're ever to consider building images for flash parts (not >> compact >> flash) then we'll need to do a lot of work to pare down the bloat--or >> replace current apps w/ special purpose replacements a la busybox >> (not >> something I find appealing). > > related to this thread -- does anyone have experience in trying > to build busybox on FreeBSD ? > > Also, what would you suggest as a small scripting language to be used > in this kind of platform for implementing CGI scripts (and preferably > able to use sockets/select) ? > > The various perl/python/php and friend are in the 10MB range once you > pick up a little bit of libraries (sockets etc) and the tangle of > modules they require; awk (which is present in busybox) is ok-ish for > some things, but doing > I/O and calling external programs with it is very unfriendly; > javascript/spidermonkey is on the 500KB range but it doesn't have > a library to play with sockets... I'd also suggest looking at Lua, as someone else mentioned. It's BSD licensed, and written explicitly for small footprint, embedded applications. There's a port to the Lego Mindstorms controller, for example. The Lua language is written in ANSI C, and has a small set of well defined interfaces to the OS for opening files, memory allocation, etc. There are a number of web based Lua application environments; google for "Lua Kepler" for one such example. There's also a couple of Wiki platforms written in Lua. I think of Lua as the sort of tool you might use these days as compared to Tcl some years ago. It also would be suitable for replacing FORTH in /boot/loader as something that's still small and compact enough, with many fewer sharp edges exposed to users.. louie From ebutusov at gmail.com Sun Aug 3 15:03:33 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Sun Aug 3 15:03:40 2008 Subject: 7-STABLE, gjournal and fsck. In-Reply-To: <20080803181633.U64745@woozle.rinet.ru> References: <4894CE6D.2000204@gmail.com> <4d7dd86f0808030433l6cda06ccjba154d6f0cee7d0e@mail.gmail.com> <4895A61F.8030502@gmail.com> <20080803181633.U64745@woozle.rinet.ru> Message-ID: <4895C8B8.1030506@gmail.com> Dmitry Morozovsky wrote: > On Sun, 3 Aug 2008, Eugene Butusov wrote: > > EB> > Did you re-create your file systems? How did you create the journal? > EB> > > EB> > eg. newfs /dev/ad4s1g.journal ? > EB> > > EB> > or did you just enable journal on the partition? via tunefs? > EB> > EB> I did it this way: > EB> > EB> /dev/ad4s1g is my /home, an existing partition > EB> > EB> umount /home > EB> gjournal label -f /dev/ad4s1g > EB> tunefs -J enable -n disable /dev/ad4s1g.journal > EB> (added 'async' option to /etc/fstab for /home and changed entry to > EB> /dev/ad4s1g.journal) > EB> mount /home > EB> > EB> It worked until power failed... :) > > No surprize. with you `gjournal label' command you've effectively destroyed > last 1G of UFS. You should use external journal provider in such case. Thanks, it explains everything. Ehm... well, next time I'll do it the right way. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From gaijin.k at gmail.com Sun Aug 3 16:09:42 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sun Aug 3 16:09:49 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <20080802225643.GA84798@onelab2.iet.unipi.it> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> Message-ID: <1217778109.953.23.camel@RabbitsDen> On Sun, 2008-08-03 at 00:56 +0200, Luigi Rizzo wrote: > On Sat, Aug 02, 2008 at 11:39:20AM -0700, Sam Leffler wrote: > ... > > I've been looking at nanobsd for a couple of applications and working to > > reduce the footprint of the images without hacking special rules. With > ... > > If we're ever to consider building images for flash parts (not compact > > flash) then we'll need to do a lot of work to pare down the bloat--or > > replace current apps w/ special purpose replacements a la busybox (not > > something I find appealing). > > related to this thread -- does anyone have experience in trying > to build busybox on FreeBSD ? > > Also, what would you suggest as a small scripting language to be used > in this kind of platform for implementing CGI scripts (and preferably > able to use sockets/select) ? Tcl? # ls -l /usr/local/bin/tclsh8.5 -rwxr-xr-x 1 root wheel 9369 Jul 23 20:16 /usr/local/bin/tclsh8.5 # ldd /usr/local/bin/tclsh8.5 /usr/local/bin/tclsh8.5: libtcl85.so => /usr/local/lib/libtcl85.so (0x2807b000) libm.so.5 => /lib/libm.so.5 (0x28167000) libc.so.7 => /lib/libc.so.7 (0x2817c000) # ls -l /usr/local/lib/libtcl85.so lrwxr-xr-x 1 root wheel 13 Jul 23 20:16 /usr/local/lib/libtcl85.so -> libtcl85.so.1 # ls -l /usr/local/lib/libtcl85.so.1 -r-xr-xr-x 1 root wheel 4146961 Jul 23 20:16 /usr/local/lib/libtcl85.so.1 # ldd /usr/local/lib/libtcl85.so.1 /usr/local/lib/libtcl85.so.1: libm.so.5 => /lib/libm.so.5 (0x2826f000) libc.so.7 => /lib/libc.so.7 (0x2807e000) It's socket support was good enough for me to have written variety of network clients in it (POP3, LPD, NNTP), and it is fairly easy to extend further as needed. Shared library above could be built in statically for some gain in size and start-up speed, or left as-is if you are running your own things with Tcl interpreter built-in. HTH, -- Alexandre "Sunny" Kovalenko (????????? ?????????) From torfinn.ingolfsen at broadpark.no Sun Aug 3 17:59:34 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sun Aug 3 17:59:42 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803132309.GC93138@dan.emsphone.com> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> <20080803031912.GA38781@eos.sc1.parodius.com> <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> <20080803132309.GC93138@dan.emsphone.com> Message-ID: <20080803195918.8f4c7500.torfinn.ingolfsen@broadpark.no> On Sun, 03 Aug 2008 08:23:09 -0500 Dan Nelson wrote: > >From what I can find on Intel's site for your CPU, TM is an emergency > switch that lowers the CPU speed to pervent overheating that could > damage the processor. Under normal circumstances, it should never > trip, and its on/off status (not temperature) is only readable by two > pins on the CPU. It can be disabled and enabled by software, but not > monitored. Ah, ok - that explains it. Not much use for me then. (Ok, it is good that this is there, but I can't use it for temperature monitoring) Thanks for explaining it! -- Regards, Torfinn Ingolfsen From torfinn.ingolfsen at broadpark.no Sun Aug 3 18:03:02 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sun Aug 3 18:03:09 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803120842.GA58127@slackbox.xs4all.nl> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> <20080803031912.GA38781@eos.sc1.parodius.com> <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> <20080803120842.GA58127@slackbox.xs4all.nl> Message-ID: <20080803200249.73489fbd.torfinn.ingolfsen@broadpark.no> On Sun, 03 Aug 2008 14:08:42 +0200 Roland Smith wrote: > Have you tried sysutils/mbmon? Or running 'sysctl hw.acpi|grep tz'? Yes. :-) I wrote that in my initial post in this thread, I believe. :-) -- Regards, Torfinn Ingolfsen From v.melnik at uptime.ua Sun Aug 3 19:08:37 2008 From: v.melnik at uptime.ua (Vladimir Melnik) Date: Sun Aug 3 19:08:51 2008 Subject: 7-STABLE, mpd-4.4.1_1 and others... Message-ID: <20080803184951.GK10693@venik.uplink.net.ua> Hello! We encountered some strange problem with 7.0-RELEASE and 7.0-STABLE. We have an amd64 server which works as core-router on our small network. There are almost one hundred ipfw-pipes for limiting bandwidth, mpd-4.4.1_1 for termination pptp-sessions, ng_ipacct-20061223 for traffic counting and quagga-0.99.9_7 for bgp- and ospf-routing. SOmetimes mpd goes a little crazy: it stops working, but process doesn't stop. Process stays in memory as "uninterruptable" process: PID STAT WCHAN COMMAND 5891 Ds ngsock mpd4 When we trying to send a SIGKILL to this process, nothing changes, of course. But the most strange thing is there: when we trying to reboot the system, system just hangs. There are no messages in logs, no messages on console, it just hangs and doesn't react upon any actions. There was no such problem on 6.2-RELEASE, so we are dissapointed a little. :) Thank you very much in adcance for your help and sorry for my bad English. -- V.Melnik From rwatson at FreeBSD.org Sun Aug 3 19:08:42 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Aug 3 19:08:51 2008 Subject: HEADS UP: netatm removed (was: Re: netatm removal warning) (fwd) Message-ID: Just an FYI that I'm going to proceed with the somewhat overdue removal of the netatm code from RELENG_7 shortly. netatm was disconnected from the 7.x build before the release of 7.0 as part of the MPSAFE network stack work, with the intent of removing it before 7.1 if it wasn't updated to be MPSAFE. Since that has not happened, and we have several other ATM stacks that are actively maintained in the tree, the time has come to remove the unbuilding and unusable netatm parts. With any luck, this change will not cause any disruption. Below you can find my announcement relating to an identical change to 7.x in May. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 26 May 2008 00:06:33 +0100 (BST) From: Robert Watson To: current@FreeBSD.org, arch@FreeBSD.org Cc: net@FreeBSD.org Subject: HEADS UP: netatm removed (was: Re: netatm removal warning) On Wed, 21 May 2008, Robert Watson wrote: >> 10 March 2008 E-mail warning to arch@/net@ >> 10 April 2008 E-mail warning to arch@/net@ >> 10 May 2008 Removal of netatm from HEAD >> 20 May 2008 Removal of netatm from RELENG_7 >> >> Obviously, netatm will remain in the revision control history should anyone >> wish to ressurect it after that date. However, I suspect that those >> interested in ATM on FreeBSD have long since been using Harti's netgraph ATM >> framework. > > Somehow the dates slipped pasted more quickly than I had hoped -- this is the > HEADS UP that, on a slightly delayed schedule, I will be trimming netatm from > the src tree for HEAD, and then a week or two later, from RELENG_7. Assuming > all goes well, this should result in no functional change at all. Per the long-announced schedule, netatm has now been removed from the CVS HEAD. Assuming no unexpected problems, it will likewise be removed from RELENG_7 in a few weeks. I apologize in advance if there's any build disruption; this touched a lot of Makefiles, and while netatm hasn't been connected to the build in ten months, there is always a risk of problems with a change of this scope. I'll keep an eye out for tinderbox warnings and correct as quickly as possible if any arise. Thanks, Robert N M Watson Computer Laboratory University of Cambridge _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From Nic.Reveles at gatech.edu Mon Aug 4 01:45:21 2008 From: Nic.Reveles at gatech.edu (Nic Reveles) Date: Mon Aug 4 01:45:29 2008 Subject: Using Portupgrade? In-Reply-To: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> Message-ID: <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> Hello, I've recently updated to freeBSD 6.3-STABLE from 5.3-RELEASE (amd64) and am struggling with out of date ports. I have tried updating 'ports-all' and 'src-all' numerous times (does src-all include ports-all? It takes forever) along with portupgrade. For example, when trying to login to an account using the bash shell I got the following error that prevents logging in. ld-elf.so.1: Shared object "libintl.so.6" not found So I tried: portupgrade -r bash, which did not fix anything. I was able to fix it by going into the ports directory and 'make deinstall' then 'make install'. But there are many other ports that are still broken. Is there an easy way to fix them all at once (using portupgrade)? I've tried 'portupdate -ar', which had a lot of xorg installation errors... eventually I found an entry in '/usr/ports/UPDATING' about updating xorg. But following the instructions seems to give an error that suggests following the instructions! 1) I switched to portupgrade-devel following UPDATING instructions. I believe this was successful. # portupgrade -f -o ports-mgmt/portupgrade-devel portupgrade # rm -f /usr/ports/INDEX*.db /var/db/pkg/pkgdb.db # pkgdb -fu 2) I rebuilt 'INDEX' # cd /usr/ports && make index 3) I set environment variable 'XORG_UPGRADE' to 'yes'. 4) I gave portupgrade "a small bit of help" (quoting 'UPDATING') # portupgrade -Rf libXft 5) I do not know if I have any gstreamer ports installed, so I tried both (neither did the trick). # portupgrade -a -x 'gstreamer*' ---> Upgrading 'xorg-libraries-6.8.2' to 'xorg-libraries-7.3_2' (x11/xorg-libraries) ---> Building '/usr/ports/x11/xorg-libraries' ===> Cleaning for xorg-libraries-7.3_2 /usr/X11R6 exists, but it is not a symlink. Installation cannot proceed. This looks like an incompletely removed old version of X. In the current version, /usr/X11R6 must be a symlink if it exists at all.Please read /usr/ports/UPDATING (entry of 20070519) for the procedure to upgrade X.org related ports.*** Error code 1 Stop in /usr/ports/x11/xorg-libraries. ---> Skipping 'x11/libdnd' (libdnd-1.1) because a requisite package 'xorg-libraries-6.8.2' (x11/xorg-libraries) failed (specify -k to force) [a million more skipping errors...] So I feel confident that I'm doing something incorrect since nothing seems to work after updating (or fails while updating). Could someone point me in the right direction? Nic From koitsu at FreeBSD.org Mon Aug 4 02:26:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 4 02:26:26 2008 Subject: Using Portupgrade? In-Reply-To: <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> References: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> Message-ID: <20080804022618.GA4790@eos.sc1.parodius.com> On Sun, Aug 03, 2008 at 09:20:08PM -0400, Nic Reveles wrote: > I've recently updated to freeBSD 6.3-STABLE from 5.3-RELEASE (amd64) and am struggling with out of date ports. I have tried updating 'ports-all' and 'src-all' numerous times (does src-all include ports-all? It takes forever) along with portupgrade. src-all does not include ports-all. "It takes forever" is wonderfully vague. :-) Chances are the cvsup server you're using is slow (usually caused by heavy disk I/O, not so much network I/O); pick another. Try them all, find one which is fast. I'd recommend a couple I commonly use, but then everyone will start using them....... :-) > For example, when trying to login to an account using the bash shell I got the following error that prevents logging in. > ld-elf.so.1: Shared object "libintl.so.6" not found This indicates bash is linked to a library that doesn't exist on your machine. On my RELENG_6 machine, there is no libintl.so.6 -- there's a libintl.so.8 (significantly newer). > So I tried: portupgrade -r bash, which did not fix anything. I was able to fix it by going into the ports directory and 'make deinstall' then 'make install'. But there are many other ports that are still broken. Is there an easy way to fix them all at once (using portupgrade)? The method I use for upgrading our systems is often shunned by other administrators because "it requires too much work", but it *always* works without any hitches. 1) Back up /usr/local. rsync -av /usr/local/ /usr/local.old/ works. 2) Save output from pkg_info somewhere (e.g. in a Notepad window, etc.) 3) pkg_delete -a -f 4) rm -fr /usr/local 5) rm -fr /var/db/pkg/* 6) rm -fr /var/db/ports (this probably isn't necessary, but why not) 7) Start installing all of your ports again If you have X on your machine, this method will very likely not make you happy, as I've heard people with X often have 300+ ports installed. I can't help you with X, as I don't use it. > 2) I rebuilt 'INDEX' > # cd /usr/ports && make index Waste of time. cd /usr/ports && make fetchindex > So I feel confident that I'm doing something incorrect since nothing seems to work after updating (or fails while updating). Could someone point me in the right direction? I'd start by ceasing use of portupgrade. Try Doug Barton's portmaster, which is in ports/ports-mgmt/portmaster. It's an extensive shell script, and does not require ruby. It might actually upgrade all of your ports for you, although your system may be in a state of disarray as a result of upgrading major OS versions. -- | Jeremy Chadwick jdc 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 | From pyunyh at gmail.com Mon Aug 4 02:38:15 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Aug 4 02:38:23 2008 Subject: Realtek RTL8110 (SB) watchdog timeout. In-Reply-To: <20080801080721.GB9206@cdnetworks.co.kr> References: <489262E5.3010304@gmail.com> <20080801080721.GB9206@cdnetworks.co.kr> Message-ID: <20080804023600.GC21401@cdnetworks.co.kr> On Fri, Aug 01, 2008 at 05:07:21PM +0900, To Eugene Butusov wrote: > 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 > > > > re0@pci0:4:0:0: class=0x020000 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. > FYI: I've committed TSO patch to HEAD with svn revision r181271. -- Regards, Pyun YongHyeon From imb at protected-networks.net Mon Aug 4 02:52:37 2008 From: imb at protected-networks.net (Michael Butler) Date: Mon Aug 4 02:52:46 2008 Subject: vmstat -z bucket failures? Message-ID: <48966EEE.5070208@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get this on all my -stable boxes .. imb@aaron:/home/imb> vmstat -z |less ITEM SIZE LIMIT USED FREE REQUESTS FAILURES ~ [ .. ] 128 Bucket: 524, 0, 214, 10, 1300, 249 Is this mis-reporting or 'real' failures? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkiWbu4ACgkQQv9rrgRC1JLAWACguIf6Dnz+UdAvNbi/f2Atpcq0 W4EAnjBmXSlVE6sKeOpch71os0M+3MWU =swvL -----END PGP SIGNATURE----- From alex-goncharov at comcast.net Mon Aug 4 03:24:44 2008 From: alex-goncharov at comcast.net (Alex Goncharov) Date: Mon Aug 4 03:24:51 2008 Subject: Using Portupgrade? In-Reply-To: <20080804022618.GA4790@eos.sc1.parodius.com> (message from Jeremy Chadwick on Sun, 3 Aug 2008 19:26:18 -0700) References: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> <20080804022618.GA4790@eos.sc1.parodius.com> Message-ID: ,--- You/Jeremy (Sun, 3 Aug 2008 19:26:18 -0700) ----* | I'd start by ceasing use of portupgrade. Try Doug Barton's portmaster, | which is in ports/ports-mgmt/portmaster. It's an extensive shell | script, and does not require ruby. Over the last couple of months, I've made a few shy attempts to switch from `portupgrade' to 'portmaster', but every time I try it, I find something that keeps me using the former. Don't remember everything of that sort but here are a couple of things I would like to ask portmaster users' opinion and advice about: 1. I see a significant difference in the time it takes to get the same information using the two tools: ------------------------------ # time portversion -v | wc -l 473 real 0m3.772s user 0m2.462s sys 0m1.114s # time portmaster -L | wc -l 488 real 0m50.042s user 0m29.762s sys 0m15.470s ------------------------------ I run `portversion' a lot, and this kind of performance difference is one argument for sticking with `portupgrade'. 2. It looks like there are no `portmaster' equivalents to `portupgrade' `-P' and `-PP' options, which I want to have. Is this something that can be resolved by a smarter use of `portmaster' and/or its documentation? Thanks, -- Alex -- alex-goncharov@comcast.net -- From dougb at FreeBSD.org Mon Aug 4 05:14:57 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 4 05:15:04 2008 Subject: Portmaster questions (Was: Re: Using Portupgrade?) In-Reply-To: References: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> <20080804022618.GA4790@eos.sc1.parodius.com> Message-ID: <4896904E.9070807@FreeBSD.org> It's really not appropriate to hijack the portupgrade thread for this, so I'm starting a new subject. Also, please respect followups to -ports. Alex Goncharov wrote: > Don't remember everything of that sort but here are a couple of things > I would like to ask portmaster users' opinion and advice about: > > 1. I see a significant difference in the time it takes to get the same > information using the two tools: As I understand it, portupgrade uses the INDEX file to determine whether ports are up to date. Portmaster recurses through each installed port and does 'make -V PKGVERSION'. > 2. It looks like there are no `portmaster' equivalents to > `portupgrade' `-P' and `-PP' options, which I want to have. If portupgrade does the job for you, keep using it. :) I have said many times that I'm not looking to write a portupgrade replacement. Use the right tool for the job(s) you have to do. Good luck, Doug -- This .signature sanitized for your protection From nakal at web.de Mon Aug 4 08:53:45 2008 From: nakal at web.de (Martin) Date: Mon Aug 4 08:53:53 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808021601u13147294r9dc44a737119648@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> <20080802224046.3b547283@web.de> <2a41acea0808021601u13147294r9dc44a737119648@mail.gmail.com> Message-ID: <20080804105335.4cd5df47@zelda.local> Am Sat, 2 Aug 2008 16:01:35 -0700 schrieb "Jack Vogel" : Hi, > > After I typed "/etc/rc.d/netif restart", I waited until I get > > "giving up" message. Then I plugged the cable in. After about 30 > > seconds the link LED was on. I noticed that at this point I > > couldn't get an address using DHCP. > > Well DUH, the agent exited, thats why it said "giving up" :) > That ain't complex behavior, its behaving as designed. I'm describing the circumstances WHEN everything happens. I was trying to show you that even the cable is plugged in you cannot get an IP. The NIC is in a kind of "dead" state. > Ya, so the update is slow, the fact that the LED is blinking means you > have an autoneg failure, so again, its your switch not the NIC. I have this problem with every kind of switch. The switch at home is a 100Mbit switch made by Digitus (5-port). > Let me guess, you have some 100Mb home router and you are trying > to plug a gig nic into it and forcing the speed maybe? This is true except for the "forcing the speed" part. It's set to "media: Ethernet autoselect". > I asked for a hardware list, now that includes the switch. Digitus DN-5001C: http://www.amazon.de/Assmann-Digitus-DN-5001C-Switch-Fast/dp/B0009FHTWI -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080804/7c0bfbde/signature.pgp From nakal at web.de Mon Aug 4 09:08:34 2008 From: nakal at web.de (Martin) Date: Mon Aug 4 09:08:41 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080802235010.facd4cb9.torfinn.ingolfsen@broadpark.no> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> <20080802224046.3b547283@web.de> <20080802235010.facd4cb9.torfinn.ingolfsen@broadpark.no> Message-ID: <20080804110825.3e1699be@zelda.local> Am Sat, 02 Aug 2008 23:50:10 +0200 schrieb Torfinn Ingolfsen : > On Sat, 02 Aug 2008 22:40:46 +0200 > Martin wrote: > > > good point, no. The problem appears when the first thing called on > > this interface is dhclient (caused by ifconfig_em0="DHCP"). I could > > So, if you don't automatically configure the interface, but instead do > something like: > 'ifconfig em0 up' > and then the DHCP stuff > does the interface work then? Hi Torfinn, I've put "/sbin/ifconfig em0 up" into rc.local. Now the behavior is slightly different. Steps: 1) I switch laptop on with cable unplugged. Everything ok (DHCP failed, of course; this is normal). 2) I plug the cable in: "state: active". Yay! This is OK! 3) NIC does not get IP (one time it got the correct IP but the it lost it again, I could see by repeatedly typing "ifconfig em0"). 4) I kill the dhclient. 5) I manually start "dhclient em0". No response (DHCPREQUEST, DHCPDISCOVER, does not finish). 6) I start "ifconfig em0 down" and once again "dhclient em0" (this time without "ifconfig em0 up"!). 7) Got an IP, without delays (as it should be). -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080804/87a661ba/signature.pgp From koitsu at FreeBSD.org Mon Aug 4 09:13:25 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 4 09:13:33 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080804105335.4cd5df47@zelda.local> References: <20080801142005.473c17ca@zelda.local> <20080801124224.GA17183@eos.sc1.parodius.com> <20080802070015.7f64c862@web.de> <20080802125553.d9c83a55.torfinn.ingolfsen@broadpark.no> <20080802224046.3b547283@web.de> <2a41acea0808021601u13147294r9dc44a737119648@mail.gmail.com> <20080804105335.4cd5df47@zelda.local> Message-ID: <20080804091325.GA25795@eos.sc1.parodius.com> On Mon, Aug 04, 2008 at 10:53:35AM +0200, Martin wrote: > Am Sat, 2 Aug 2008 16:01:35 -0700 > schrieb "Jack Vogel" : > > > After I typed "/etc/rc.d/netif restart", I waited until I get > > > "giving up" message. Then I plugged the cable in. After about 30 > > > seconds the link LED was on. I noticed that at this point I > > > couldn't get an address using DHCP. > > > > Well DUH, the agent exited, thats why it said "giving up" :) > > That ain't complex behavior, its behaving as designed. > > I'm describing the circumstances WHEN everything happens. I was trying > to show you that even the cable is plugged in you cannot get an IP. The > NIC is in a kind of "dead" state. > > > Ya, so the update is slow, the fact that the LED is blinking means you > > have an autoneg failure, so again, its your switch not the NIC. > > I have this problem with every kind of switch. > > The switch at home is a 100Mbit switch made by Digitus (5-port). Can you try repeating the problem under Linux? It may be a bit much to ask, but I believe there's an Ubuntu Live CD you can download + burn + boot. You could try repeating the behaviour there. If it's identical, or at least "still broken", then it's less likely FreeBSD's fault. > > Let me guess, you have some 100Mb home router and you are trying > > to plug a gig nic into it and forcing the speed maybe? > > This is true except for the "forcing the speed" part. It's set to > "media: Ethernet autoselect". Which means it's using auto-neg, which Jack says (based on the information he has) may be failing upon link loss + reconnect. As described, auto-negotiation has to be properly implemented on both the NIC/PHY and on the switch, as well as handled properly in the NIC driver. I can tell you that in the case of the Intel 82573E and FreeBSD's em(4) driver (version 6.x.x), auto-neg is performed properly, including when link is lost/cable pulled. I've personally tested this on numerous consumer switches (D-Link, Linksys, and Hawking Technologies), as well as enterprise switches (specifically ProCurve and Cisco). I can tell you that I've seen odd speed negotiation failures with Netgear consumer switches (100mbit being chosen instead of gigE). In fact, this weekend in my home, I just migrated from a D-Link switch to an HP ProCurve switch. I powered off one switch, installed the new one, powered it on, and link came up. Took a couple minutes. But then I decided to re-organise some of my cabling, which caused another disconnect. Here's evidence: em0: port 0x4000-0x401f mem 0xe8000000-0xe801ffff irq 16 at device 0.0 on pci13 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:97:25:40 em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet icarus# bzgrep "kernel: em0" /var/log/all.log.3.bz2 Jul 31 06:28:23 icarus kernel: em0: link state changed to DOWN Jul 31 06:30:17 icarus kernel: em0: link state changed to UP Jul 31 06:32:36 icarus kernel: em0: link state changed to DOWN Jul 31 06:32:53 icarus kernel: em0: link state changed to UP And absolutely no problems: icarus# netstat -in -I em0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:30:48:97:25:40 32941661 0 34620277 0 0 em0 1500 192.168.1.0/2 192.168.1.51 32915748 - 35942133 - - icarus# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:97:25:40 inet 192.168.1.51 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active What I'm saying is "I don't know what to tell you". I'm not doubting your claims, but it would be worthwhile to test on Linux to see if it's a FreeBSD driver issue, something with the NIC/PHY, the way the NIC/PHY is implemented on the computer, or even the cable (yes really!). I'd start with the obvious: try replacing the cable, and go with a CAT5e cable that's pre-made (rather than self-rolled, if you're using such). -- | Jeremy Chadwick jdc 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 | From 000.fbsd at quip.cz Mon Aug 4 09:36:37 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon Aug 4 09:36:44 2008 Subject: Portmaster questions (Was: Re: Using Portupgrade?) In-Reply-To: References: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> <20080804022618.GA4790@eos.sc1.parodius.com> Message-ID: <4896CDBA.8090905@quip.cz> Alex Goncharov wrote: > ,--- You/Jeremy (Sun, 3 Aug 2008 19:26:18 -0700) ----* > | I'd start by ceasing use of portupgrade. Try Doug Barton's portmaster, > | which is in ports/ports-mgmt/portmaster. It's an extensive shell > | script, and does not require ruby. > > Over the last couple of months, I've made a few shy attempts to switch > from `portupgrade' to 'portmaster', but every time I try it, I find > something that keeps me using the former. > > Don't remember everything of that sort but here are a couple of things > I would like to ask portmaster users' opinion and advice about: > > 1. I see a significant difference in the time it takes to get the same > information using the two tools: > > ------------------------------ > # time portversion -v | wc -l > 473 > > real 0m3.772s > user 0m2.462s > sys 0m1.114s > > # time portmaster -L | wc -l > 488 > > real 0m50.042s > user 0m29.762s > sys 0m15.470s > > ------------------------------ > > I run `portversion' a lot, and this kind of performance difference > is one argument for sticking with `portupgrade'. You do not have to run portversion or portmaster or any other 3rd party tool to check versions of installed ports. Use pkg_version which is included in base system and then you are independent of port management tools changes. portversion is using INDEX, portmaster not. pkg_version (by default) do not use INDEX, but have option to use it and then become clear winner (in speed): portmaster -L Usr: 11.431s Krnl: 4.179s Totl: 0:15.96s portversion -v Usr: 2.076s Krnl: 0.615s Totl: 0:02.75s pkg_version -v Usr: 9.803s Krnl: 3.183s Totl: 0:13.23s ## using INDEX, see man pkg_version for details ## pkg_version -vI Usr: 0.233s Krnl: 0.041s Totl: 0:00.31s With INDEX you can see results almost immediately: # time pkg_version -vIL = amavisd-new-2.5.4,1 < needs updating (index has 2.6.1,1) awstats-6.7,1 < needs updating (index has 6.8_1,1) courier-authlib-base-0.60.6 < needs updating (index has 0.61.0) courier-authlib-mysql-0.60.6 < needs updating (index has 0.61.0) mod_python-3.3.1 < needs updating (index has 3.3.1_1) nmap-4.62 < needs updating (index has 4.68) openvpn-2.0.6_8 < needs updating (index has 2.0.6_9) py25-docutils-0.4 < needs updating (index has 0.5) py25-pygments-0.9 < needs updating (index has 0.10) subversion-python-1.4.6_2 < needs updating (index has 1.5.1) trac-0.10.4_1 < needs updating (index has 0.11_2) trac-ctxtnavaddplugin-1.1.r1 < needs updating (index has 1.1.r1_2) trac-iniadmin-0.1 < needs updating (index has 0.1_2) Usr: 0.227s Krnl: 0.036s Totl: 0:00.27s CPU: 92.5% As I had problems with portupgrade's handling of dependencies, I am converted to portmaster. Only one feature that I am missing in portmaster is ability to "do something" before / after application install / upgrade (eg: restart of daemon, directory permission setting, backup of configs etc.) Miroslav Lachman From nakal at web.de Mon Aug 4 09:49:20 2008 From: nakal at web.de (Martin) Date: Mon Aug 4 09:49:26 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> Message-ID: <20080804113448.0a4b3991@zelda.local> On Sat, 2 Aug 2008 10:34:47 -0700 "Jack Vogel" wrote: > Telling me what kind of NIC it is isn't going to help, 82573's are > working the world over :) What exactly is your laptop, what model, > is the NIC a LOM (on the motherboard) or some addin. Hi Jack, this is a Lenovo Thinkpad T60p model 2007-93G. It's the standard built-in NIC by Lenovo on the mainboard. > There should be NO need to specify full duplex, if you have to do > that then you have some problem with your switch. No, I don't have to specify full duplex. Earlier someone has asked me if it might be some problem with the autonegotiation. I don't think it is. > Are you loading the driver as a module, or is it static? Static. > So, if you do this: get a cable and eliminate any switch, just a > back to back connection between two machines, then if you load the > driver and ifconfig address up... what happens?? Ok, I've done that. I connected my laptop directly to my home router. At the other side we have an xl(4) NIC, btw. Faulty variant: 1) Boot with cable disconnected. DHCP fails, of course, which is ok. 2) I plug in the cable where on the other side sits xl(4). ifconfig shows me "no carrier", all LEDs at the NIC are off. No way to get an IP. No way to get "status: active", by "ifconfig em0 up/down". Ok: 1) Boot with cable directly connected to xl(4) at the other side. 2) em0 gets instantly an IP from DHCP server running on xl(4). -- Martin From utisoft at googlemail.com Mon Aug 4 10:00:17 2008 From: utisoft at googlemail.com (Chris Rees) Date: Mon Aug 4 10:00:23 2008 Subject: em(4) on FreeBSD is sometimes annoying Message-ID: Martin wrote: > On Sat, 02 Aug 2008 12:55:53 +0200 > Torfinn Ingolfsen wrote: > >> Just to be sure: also if the first command you try on the interface is >> 'ifconfig up'? > > Hello Torfinn, > > good point, no. The problem appears when the first thing called on this > interface is dhclient (caused by ifconfig_em0="DHCP"). I could also > provoke this behavior after the interface was once up had an IP and was > working (ping). All I need to do is to disconnect the NIC from the > switch when I type "/etc/rc.d/netif restart". > > I have noticed further strange effects here. The behavior seems to > be even more complex. > > After I typed "/etc/rc.d/netif restart", I waited until I get "giving > up" message. Then I plugged the cable in. After about 30 seconds the > link LED was on. I noticed that at this point I couldn't get an address > using DHCP. > > So I disconnected physically the NIC (no cable) and link LED was > still on! ifconfig showed me "state: active" with no cable plugged in. > After further 30 seconds the LED went off. > > I attached the NIC again to the switch again and after 30 seconds > again I got some other effect. The link LED went on (status: active) > and the data LED was permanently blinking (about 2,5 times a second). I > pulled the cable again and now the link LED is still on and the data > LED still blinking (since about 10 minutes already). > > By the way... > Now I'm typing this E-Mail without an ethernet cable plugged in and the > link status LED is still on and the other data LED is blinking. > > -- > Martin > I may have misunderstood the purpose of this, but do you have the bpf compiled into your kernel? If you're having DHCP troubles, this could be a problem. Chris From koitsu at FreeBSD.org Mon Aug 4 10:23:08 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 4 10:23:17 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080804113448.0a4b3991@zelda.local> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> Message-ID: <20080804102307.GA28928@eos.sc1.parodius.com> On Mon, Aug 04, 2008 at 11:34:48AM +0200, Martin wrote: > On Sat, 2 Aug 2008 10:34:47 -0700 > "Jack Vogel" wrote: > > > Telling me what kind of NIC it is isn't going to help, 82573's are > > working the world over :) What exactly is your laptop, what model, > > is the NIC a LOM (on the motherboard) or some addin. > > Hi Jack, > > this is a Lenovo Thinkpad T60p model 2007-93G. It's the standard > built-in NIC by Lenovo on the mainboard. I also have a T60p (though a different model/type number). Note that the BIOSes for the T60p have historically documented numerous changes to how the NIC is initialised and "fiddled with", **especially** if PXE booting is enabled (regardless if a PXE boot itself is performed or not). My employer sent a company-wide message to all owners of the T60p asking that they upgrade their BIOS solely to address link negotiation failures occasionally seen when PXE booting. Meaning: I would not be surprised if this issue proved to be something specific to Lenovo laptops, possibly this model. When I return to work on Wednesday night, I'll try to reproduce what you see (we have Juniper, Cisco, Extreme, and Netgear switches there), then bring the laptop home and test against a D-Link switch, as well as my ProCurve. I can tell you that I have absolutely no problems under Windows Vista when pulling the CAT5 cable out and reinserting it; and yes, DHCP is used. (I do this literally on a nightly basis, which is how/why I'm so sure.) -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Mon Aug 4 10:24:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 4 10:24:27 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: References: Message-ID: <20080804102419.GB28928@eos.sc1.parodius.com> On Mon, Aug 04, 2008 at 11:00:16AM +0100, Chris Rees wrote: > Martin wrote: > > > On Sat, 02 Aug 2008 12:55:53 +0200 > > Torfinn Ingolfsen wrote: > > > >> Just to be sure: also if the first command you try on the interface is > >> 'ifconfig up'? > > > > Hello Torfinn, > > > > good point, no. The problem appears when the first thing called on this > > interface is dhclient (caused by ifconfig_em0="DHCP"). I could also > > provoke this behavior after the interface was once up had an IP and was > > working (ping). All I need to do is to disconnect the NIC from the > > switch when I type "/etc/rc.d/netif restart". > > > > I have noticed further strange effects here. The behavior seems to > > be even more complex. > > > > After I typed "/etc/rc.d/netif restart", I waited until I get "giving > > up" message. Then I plugged the cable in. After about 30 seconds the > > link LED was on. I noticed that at this point I couldn't get an address > > using DHCP. > > > > So I disconnected physically the NIC (no cable) and link LED was > > still on! ifconfig showed me "state: active" with no cable plugged in. > > After further 30 seconds the LED went off. > > > > I attached the NIC again to the switch again and after 30 seconds > > again I got some other effect. The link LED went on (status: active) > > and the data LED was permanently blinking (about 2,5 times a second). I > > pulled the cable again and now the link LED is still on and the data > > LED still blinking (since about 10 minutes already). > > > > By the way... > > Now I'm typing this E-Mail without an ethernet cable plugged in and the > > link status LED is still on and the other data LED is blinking. > > > > -- > > Martin > > > I may have misunderstood the purpose of this, but do you have the bpf > compiled into your kernel? If you're having DHCP troubles, this could > be a problem. I have never seen "device bpf" cause any sort of DHCP-related problems on FreeBSD. Can you expand on this, and provide reference material confirming such? -- | Jeremy Chadwick jdc 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 | From utisoft at googlemail.com Mon Aug 4 10:29:44 2008 From: utisoft at googlemail.com (Chris Rees) Date: Mon Aug 4 10:29:52 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080804102419.GB28928@eos.sc1.parodius.com> References: <20080804102419.GB28928@eos.sc1.parodius.com> Message-ID: 2008/8/4 Jeremy Chadwick : > On Mon, Aug 04, 2008 at 11:00:16AM +0100, Chris Rees wrote: >> Martin wrote: >> >> > On Sat, 02 Aug 2008 12:55:53 +0200 >> > Torfinn Ingolfsen wrote: >> > >> >> Just to be sure: also if the first command you try on the interface is >> >> 'ifconfig up'? >> > >> > Hello Torfinn, >> > >> > good point, no. The problem appears when the first thing called on this >> > interface is dhclient (caused by ifconfig_em0="DHCP"). I could also >> > provoke this behavior after the interface was once up had an IP and was >> > working (ping). All I need to do is to disconnect the NIC from the >> > switch when I type "/etc/rc.d/netif restart". >> > >> > I have noticed further strange effects here. The behavior seems to >> > be even more complex. >> > >> > After I typed "/etc/rc.d/netif restart", I waited until I get "giving >> > up" message. Then I plugged the cable in. After about 30 seconds the >> > link LED was on. I noticed that at this point I couldn't get an address >> > using DHCP. >> > >> > So I disconnected physically the NIC (no cable) and link LED was >> > still on! ifconfig showed me "state: active" with no cable plugged in. >> > After further 30 seconds the LED went off. >> > >> > I attached the NIC again to the switch again and after 30 seconds >> > again I got some other effect. The link LED went on (status: active) >> > and the data LED was permanently blinking (about 2,5 times a second). I >> > pulled the cable again and now the link LED is still on and the data >> > LED still blinking (since about 10 minutes already). >> > >> > By the way... >> > Now I'm typing this E-Mail without an ethernet cable plugged in and the >> > link status LED is still on and the other data LED is blinking. >> > >> > -- >> > Martin >> > >> I may have misunderstood the purpose of this, but do you have the bpf >> compiled into your kernel? If you're having DHCP troubles, this could >> be a problem. > > I have never seen "device bpf" cause any sort of DHCP-related problems > on FreeBSD. > > Can you expand on this, and provide reference material confirming such? > > -- > | Jeremy Chadwick jdc 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 | > > Sorry, I was referring to the possible absence of it. Ref: http://www.freebsd.org/doc/en/books/handbook/network-dhcp.html , section 27.5.4: "Make sure that the bpf device is compiled into your kernel. To do this, add device bpf to your kernel configuration file, and rebuild the kernel." Chris -- R< $&h ! > $- ! $+ $@ $2 < @ $1 .UUCP. > From nakal at web.de Mon Aug 4 10:51:51 2008 From: nakal at web.de (Martin) Date: Mon Aug 4 10:51:58 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080804102307.GA28928@eos.sc1.parodius.com> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> Message-ID: <20080804125138.59ed0252@zelda.local> Am Mon, 4 Aug 2008 03:23:07 -0700 schrieb Jeremy Chadwick : > When I return to work on Wednesday night, I'll try to reproduce what > you see (we have Juniper, Cisco, Extreme, and Netgear switches > there), then bring the laptop home and test against a D-Link switch, > as well as my ProCurve. Hi Jeremy, I'm trying some other things here. Before you waste time on PEBKAC problems ;) (which I now suspect to be). Let me try to install the latest GENERIC on my laptop first. I have made some modifications with polling and some other stuff like HZ and zero copy sockets. I tried several things now: Windows XP worked fine. Ubuntu also. FreeBSD 7.0R install CD works, too. Of course, there might be some other things from userland that cause the problem and that don't run during install (powerd?). I have to check it first to narrow down the problem. Thanks to all people here for helping me so far. I would not get that many ideas what to look at, if I hadn't asked. Sometimes, I expect too much to run flawlessly together, I think. I will tell more when I have checked the things I mentioned. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080804/716377e5/signature.pgp From nakal at web.de Mon Aug 4 15:45:40 2008 From: nakal at web.de (Martin) Date: Mon Aug 4 15:45:48 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080804125138.59ed0252@zelda.local> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> Message-ID: <20080804174458.4dda8369@zelda.local> Am Mon, 4 Aug 2008 12:51:38 +0200 schrieb Martin : > I'm trying some other things here. Before you waste time on > PEBKAC problems ;) (which I now suspect to be). Let me try to install > the latest GENERIC on my laptop first. I've build fresh world and then kernel (GENERIC configuration), I also removed everything from rc.conf except host name assignment, and ifconfig_re0="DHCP". I have still same effect as described before. Booting without ethernet cable will prevent me to get link "status: active" on em(4), when I try to use it later. GENERIC from FreeBSD 7.0 CD installation works fine. I checked it again. I can boot without cable in my NIC, "try" to assign an IP using DHCP and then plug the cable in and I have link. Is there a difference how /etc/rc.d/netif handles a NIC with DHCP and how the installation CD is handling it? Once again, steps to reproduce this behavior: 1) Power the laptop OFF. Really OFF, I mean. No reboots! 2) Detach the cable from NIC. 3) Boot FreeBSD. Let it pass the DHCP phase (ifconfig_em0="DHCP") until login appears. 4) Attach the cable to the NIC. 5) Voila... no link. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080804/42967157/signature.pgp From mwisnicki+freebsd at gmail.com Mon Aug 4 16:05:20 2008 From: mwisnicki+freebsd at gmail.com (Marcin Wisnicki) Date: Mon Aug 4 16:05:27 2008 Subject: Portmaster questions (Was: Re: Using Portupgrade?) References: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> <20080804022618.GA4790@eos.sc1.parodius.com> <4896904E.9070807@FreeBSD.org> Message-ID: On Sun, 03 Aug 2008 22:14:54 -0700, Doug Barton wrote: > It's really not appropriate to hijack the portupgrade thread for this, > so I'm starting a new subject. Also, please respect followups to -ports. > > Alex Goncharov wrote: >> Don't remember everything of that sort but here are a couple of things >> I would like to ask portmaster users' opinion and advice about: >> >> 1. I see a significant difference in the time it takes to get the same >> information using the two tools: > > As I understand it, portupgrade uses the INDEX file to determine whether > ports are up to date. Actually I think it uses bdb "cache" of index (INDEX-7.db) and also lies about it (says "up-to-date with port" instead of "up-to-date with index"). It's not even doing a good job at it, standard pkg_version significantly outperforms it: # time portversion -v | wc -l 769 real 0m15.027s user 0m9.235s sys 0m5.173s # time pkg_version -Iv | wc -l 769 real 0m4.707s user 0m3.648s sys 0m0.798s From biancalana at gmail.com Mon Aug 4 16:49:59 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Mon Aug 4 16:50:06 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <8e10486b0807040834m27a38254k5261535d93d70ce6@mail.gmail.com> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> <1215105220.32135.18.camel@buffy.york.ac.uk> <8e10486b0807031041o54349836i31c5da84ebda70f6@mail.gmail.com> <1215176991.36376.24.camel@buffy.york.ac.uk> <8e10486b0807040834m27a38254k5261535d93d70ce6@mail.gmail.com> Message-ID: <8e10486b0808040949ka12edf0o38e3a790d620992e@mail.gmail.com> On 7/4/08, Alexandre Biancalana wrote: > On 7/4/08, Gavin Atkinson wrote: > > It's not a solution, but it may well be a great help in diagnosing where > > the problem lies: it would be useful to know if the driver is simply > > failing to detect the correct number of ports, or if the driver > > physically cannot use them. > > > > In /usr/src/sys/dev/digi/digi.c, line 510, you'll see the following > > code: > > > > if (sc->numports == 0) { > > device_printf(sc->dev, "%s, 0 ports found\n", sc->name); > > sc->hidewin(sc); > > return (0); > > } > > > > Just before that section, can you add a line "sc->numports = 32;", > > recompile, and see if the missing 16 ports are usable? If they are, I > > suspect fixing the driver will be trivial. > > > Wow !! Now the 32 ports are detected and devices created. > > # digictl -d 1 -r /dev/digi0.ctl > > digi0: Got init reset after 0 us > digi0: BIOS uploaded > digi0: BIOS started after 0 us > > digi0: BIOS booted after 1619 iterations > > digi0: Loading FEP/OS > digi0: FEP/OS loaded > digi0: FEP/OS started after 28 iterations > > digi0: Digiboard PCI PC/Xem ASIC, 32 ports found > > # ls /dev/cuaD?? | wc -l > 32 > > I will connect some modems to that ports to test and let you know. Modems connected but they only work on ports of the first module, any decice connected on ports of second module does not work. Any other idea ? Thank you From jfvogel at gmail.com Mon Aug 4 17:18:52 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Aug 4 17:18:59 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080804174458.4dda8369@zelda.local> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> Message-ID: <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> The focus here on the laptop distracted me, but someone else at work reminded me. Its very important that you run the EEPROM fix for the 82573 that i posted a long while back, search in email archive for it. Its a DOS executable that will patch your EEPROM. I am not sure if the Lenova's need it, but get it, run it, and then see if your problem goes away. Jack On Mon, Aug 4, 2008 at 8:44 AM, Martin wrote: > Am Mon, 4 Aug 2008 12:51:38 +0200 > schrieb Martin : > >> I'm trying some other things here. Before you waste time on >> PEBKAC problems ;) (which I now suspect to be). Let me try to install >> the latest GENERIC on my laptop first. > > I've build fresh world and then kernel (GENERIC configuration), I also > removed everything from rc.conf except host name assignment, and > ifconfig_re0="DHCP". I have still same effect as described before. > > Booting without ethernet cable will prevent me to get link "status: > active" on em(4), when I try to use it later. > > GENERIC from FreeBSD 7.0 CD installation works fine. I checked it > again. I can boot without cable in my NIC, "try" to assign an IP using > DHCP and then plug the cable in and I have link. > > Is there a difference how /etc/rc.d/netif handles a NIC with DHCP and > how the installation CD is handling it? > > Once again, steps to reproduce this behavior: > > 1) Power the laptop OFF. Really OFF, I mean. No reboots! > 2) Detach the cable from NIC. > 3) Boot FreeBSD. Let it pass the DHCP phase (ifconfig_em0="DHCP") until > login appears. > 4) Attach the cable to the NIC. > 5) Voila... no link. > > -- > Martin > From Nick.Barnes at pobox.com Mon Aug 4 17:26:34 2008 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Mon Aug 4 17:26:43 2008 Subject: 5.x to 6.x or 7.x with 64MB / Message-ID: <49120.1217868483@thrush.ravenbrook.com> I have a machine which I have recently upgraded using cvsup, from 4.x to RELENG_5, as a staging post en route to 7.x. The upgrade went well until installworld ran out of disk on / and I realised it was only 64BMB. My bad; should have checked before upgrading. With help from an on-site colleague the installworld was nursed to completion. But can I get the same machine up to 6.x or 7.x without repartitioning? Advice please. Partitions are as follows. ad0 2439 M ad0s1 2439 M ad0s1a 64 M / ad0s1b 128 M swap ad0s1e 1024 M /var ad0s1f 600 M /home ad0s1g 623 M - ad1 57259 M ad1s1 57259 M ad0s1a 10240 M /usr It occurs to me that if ad0s1a is insufficient then I could use ad0s1g as swap, and repurpose ad0s1b as a new /. Is it straightforward to installworld/mergemaster to somewhere other than / ? Nick B From royce at alaska.net Mon Aug 4 17:35:23 2008 From: royce at alaska.net (Royce Williams) Date: Mon Aug 4 17:35:31 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> Message-ID: <48973DD9.20303@alaska.net> Jack Vogel wrote, on 8/4/2008 9:18 AM: > The focus here on the laptop distracted me, but someone else at work > reminded me. Its very important that you run the EEPROM fix for > the 82573 that i posted a long while back, search in email archive > for it. Its a DOS executable that will patch your EEPROM. > > I am not sure if the Lenova's need it, but get it, run it, and then > see if your problem goes away. Martin, there's also a link to it from Jeremy's "Commonly Reported Issues" page: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Look for "DOS-based EEPROM". Jack, is this issue the same one that is documented here? http://e1000.sourceforge.net/doku.php?id=known_issues#v_l_e_tx_unit_hang_messages ... and addressed by this script? http://e1000.sourceforge.net/doku.php?id=tx_unit_hang If so, the script could be used without booting from a DOS disk. If this is unrelated or is an unsafe way to apply this fix, that would be handy to know. Royce -- Royce D. Williams - http://royce.ws/ A finished person is a boring person. - Anna Quindlen From jfvogel at gmail.com Mon Aug 4 17:54:53 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Aug 4 17:55:00 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <48973DD9.20303@alaska.net> References: <20080801142005.473c17ca@zelda.local> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> <48973DD9.20303@alaska.net> Message-ID: <2a41acea0808041054j1523a6d6gcb8b7f726bfbc4a9@mail.gmail.com> Thanks for the pointer Royce, and yes that's the issue, and if you want to boot Linux and use that instead of DOS then more power to you. Cheers, Jack On Mon, Aug 4, 2008 at 10:35 AM, Royce Williams wrote: > Jack Vogel wrote, on 8/4/2008 9:18 AM: >> The focus here on the laptop distracted me, but someone else at work >> reminded me. Its very important that you run the EEPROM fix for >> the 82573 that i posted a long while back, search in email archive >> for it. Its a DOS executable that will patch your EEPROM. >> >> I am not sure if the Lenova's need it, but get it, run it, and then >> see if your problem goes away. > > Martin, there's also a link to it from Jeremy's "Commonly Reported > Issues" page: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Look for "DOS-based EEPROM". > > > Jack, is this issue the same one that is documented here? > > http://e1000.sourceforge.net/doku.php?id=known_issues#v_l_e_tx_unit_hang_messages > > > ... and addressed by this script? > > http://e1000.sourceforge.net/doku.php?id=tx_unit_hang > > > If so, the script could be used without booting from a DOS disk. If > this is unrelated or is an unsafe way to apply this fix, that would be > handy to know. > > > Royce > > -- > Royce D. Williams - http://royce.ws/ > A finished person is a boring person. - Anna Quindlen > From royce at alaska.net Mon Aug 4 18:15:59 2008 From: royce at alaska.net (Royce Williams) Date: Mon Aug 4 18:16:05 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808041054j1523a6d6gcb8b7f726bfbc4a9@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> <48973DD9.20303@alaska.net> <2a41acea0808041054j1523a6d6gcb8b7f726bfbc4a9@mail.gmail.com> Message-ID: <4897475D.3020600@alaska.net> Jack Vogel wrote, on 8/4/2008 9:54 AM: > On Mon, Aug 4, 2008 at 10:35 AM, Royce Williams wrote: >> Jack Vogel wrote, on 8/4/2008 9:18 AM: >>> The focus here on the laptop distracted me, but someone else at work >>> reminded me. Its very important that you run the EEPROM fix for >>> the 82573 that i posted a long while back, search in email archive >>> for it. Its a DOS executable that will patch your EEPROM. >>> >>> I am not sure if the Lenova's need it, but get it, run it, and then >>> see if your problem goes away. >> Martin, there's also a link to it from Jeremy's "Commonly Reported >> Issues" page: >> >> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues >> >> Look for "DOS-based EEPROM". >> >> >> Jack, is this issue the same one that is documented here? >> >> http://e1000.sourceforge.net/doku.php?id=known_issues#v_l_e_tx_unit_hang_messages >> >> >> ... and addressed by this script? >> >> http://e1000.sourceforge.net/doku.php?id=tx_unit_hang >> >> >> If so, the script could be used without booting from a DOS disk. If >> this is unrelated or is an unsafe way to apply this fix, that would be >> handy to know. > Thanks for the pointer Royce, and yes that's the issue, and if you > want to boot Linux and use that instead of DOS then more power to > you. Excellent! For some folks, booting from a Knoppix or Ubuntu CD might be easier than trying to gen up a DOS-bootable USB key. I think that recent Knoppix and Ubuntu include ethtool out of the box. Point of clarity: the script that I linked to above is to test/invoke the problem, not to "address" it. Below is the script that calls ethtool to change the actual bits: http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh Royce -- Royce D. Williams - http://royce.ws/ The only normal people are the ones you don't know very well. -A.Adler From uspoerlein at gmail.com Mon Aug 4 18:29:32 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Mon Aug 4 18:29:45 2008 Subject: ddb(4) scripts not working in RELENG_7? In-Reply-To: References: <20080803075744.GA1555@roadrunner.spoerlein.net> Message-ID: <20080804182334.GA1480@roadrunner.spoerlein.net> Hi Robert, On Sun, 03.08.2008 at 14:49:00 +0100, Robert Watson wrote: > On Sun, 3 Aug 2008, Ulrich Spoerlein wrote: > > I was testing a patch and getting a panic (page fault while in kernel mode) > > in RELENG_7 running multiuser mode, but no scripts were automagically run, > > although I configured ddb_enable=YES in rc.conf. > > > > It simply dropped me to the interactive ddb(4) prompt, nothing more. Do you > > have any idea what I could be missing? > > I have been using DDB scripts on 7-STABLE without any problems, but I'm not > sure I've tried it with a page fault, just regular panics. Could you try > entering the debugger via "sysctl debug.kdb.panic=1", which forces a panic, > and see if your scripts run then? Perhaps there's some inconsistency in how > we're entering the debugger. If things still appear not to be happening, try > setting up a kdb.enter.default script and see if that works? Spot on! Entering via sysctl works as expected; the 'default' script will also be executed after a page fault, but not the panic-script. So either page faults should call the panic-script or some sort of kdb.enter.pfault should be introduced? Either way, I see another manpage update coming up :) Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From torfinn.ingolfsen at broadpark.no Mon Aug 4 18:45:55 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Mon Aug 4 18:46:03 2008 Subject: Temperature monitoring on old desktop - Dell OptiPlex SX270? In-Reply-To: <20080803134328.GA65256@eos.sc1.parodius.com> References: <20080803015053.e67a39ee.torfinn.ingolfsen@broadpark.no> <20080803031912.GA38781@eos.sc1.parodius.com> <20080803135251.60d4bb7d.torfinn.ingolfsen@broadpark.no> <20080803134328.GA65256@eos.sc1.parodius.com> Message-ID: <20080804204522.98cb8b5e.torfinn.ingolfsen@broadpark.no> On Sun, 03 Aug 2008 06:43:28 -0700 Jeremy Chadwick wrote: > Then the only possibility is to take a very high-resolution photo > (read: 2048x1536 or higher) and send it to someone who can identify Ok, if I want to do that, I guess my Fujifilm Finepix F40fd (8 Mpixel) shold be able. > ICs (I'm good at recognising H/W monitoring ICs :-) ). But even that > won't guarantee anything; an IC that supports H/W monitoring may be For now, I'll lok at software tests to identify anything. > The P4 TM feature is more of a thermal manager and not so much a > "monitor" in the sense of what you think it might be (re: ability to > provide thermal statistics to a program). It *is* a "monitor" in the > sense that it reads temperature, but there's no way to access that > internal data. Yes, Dan Nelson also explained that to me. Thanks for explaining! > You could try Linux. Their lm-sensors project is incredibly thorough, Ok, I did so yesterday, see the SX270 and Xubuntu page[1]. > but based on what I've looked at in the code, it's hit-or-miss. It I tested with sensors-detect from lm-sensors, but it was a miss. :-( sensors-detect output here[2]. > Again, this would only allow you to detect whether or not there's an > actual H/W monitoring IC on the board somewhere. I'm strongly > doubting there is. It seems you are right. References: 1) http://tingox.googlepages.com/sx270_xubuntu 2) http://tingox.googlepages.com/sx270-xubuntu-sensors-detect-2008080.txt BTW, I will be traveling for about a week now, and don't know if I will have any connectivity at all. -- Regards, Torfinn Ingolfsen From jfvogel at gmail.com Mon Aug 4 18:47:33 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Aug 4 18:47:44 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <4897475D.3020600@alaska.net> References: <20080801142005.473c17ca@zelda.local> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> <48973DD9.20303@alaska.net> <2a41acea0808041054j1523a6d6gcb8b7f726bfbc4a9@mail.gmail.com> <4897475D.3020600@alaska.net> Message-ID: <2a41acea0808041147o210e3541g10b82fc99791a9df@mail.gmail.com> Right, the Linux driver implemented the ability to write as well as read the eeprom, I've always been hesitant to add that. But for some it will be easier to boot Linux and run the script. Thanks for adding the URL Royce. Jack On Mon, Aug 4, 2008 at 11:15 AM, Royce Williams wrote: > Jack Vogel wrote, on 8/4/2008 9:54 AM: >> On Mon, Aug 4, 2008 at 10:35 AM, Royce Williams wrote: >>> Jack Vogel wrote, on 8/4/2008 9:18 AM: >>>> The focus here on the laptop distracted me, but someone else at work >>>> reminded me. Its very important that you run the EEPROM fix for >>>> the 82573 that i posted a long while back, search in email archive >>>> for it. Its a DOS executable that will patch your EEPROM. >>>> >>>> I am not sure if the Lenova's need it, but get it, run it, and then >>>> see if your problem goes away. >>> Martin, there's also a link to it from Jeremy's "Commonly Reported >>> Issues" page: >>> >>> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues >>> >>> Look for "DOS-based EEPROM". >>> >>> >>> Jack, is this issue the same one that is documented here? >>> >>> http://e1000.sourceforge.net/doku.php?id=known_issues#v_l_e_tx_unit_hang_messages >>> >>> >>> ... and addressed by this script? >>> >>> http://e1000.sourceforge.net/doku.php?id=tx_unit_hang >>> >>> >>> If so, the script could be used without booting from a DOS disk. If >>> this is unrelated or is an unsafe way to apply this fix, that would be >>> handy to know. > >> Thanks for the pointer Royce, and yes that's the issue, and if you >> want to boot Linux and use that instead of DOS then more power to >> you. > > Excellent! For some folks, booting from a Knoppix or Ubuntu CD > might be easier than trying to gen up a DOS-bootable USB key. I > think that recent Knoppix and Ubuntu include ethtool out of the box. > > Point of clarity: the script that I linked to above is to test/invoke > the problem, not to "address" it. Below is the script that calls > ethtool to change the actual bits: > > http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh > > > Royce > > > -- > Royce D. Williams - http://royce.ws/ > The only normal people are the ones you don't know very well. -A.Adler > From nakal at web.de Mon Aug 4 18:52:56 2008 From: nakal at web.de (Martin) Date: Mon Aug 4 18:53:02 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <48973DD9.20303@alaska.net> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> <48973DD9.20303@alaska.net> Message-ID: <20080804205252.74141013@web.de> On Mon, 04 Aug 2008 09:35:21 -0800 Royce Williams wrote: > Jack Vogel wrote, on 8/4/2008 9:18 AM: > > The focus here on the laptop distracted me, but someone else at work > > reminded me. Its very important that you run the EEPROM fix for > > the 82573 that i posted a long while back, search in email archive > > for it. Its a DOS executable that will patch your EEPROM. > > > > I am not sure if the Lenova's need it, but get it, run it, and then > > see if your problem goes away. > > Martin, there's also a link to it from Jeremy's "Commonly Reported > Issues" page: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Look for "DOS-based EEPROM". Hi Royce, thank you for the link. I've read this issue description and I'm not sure if it helps. I don't have any "watchdog timeouts" and my EEPROM data looks clean: Interface EEPROM Dump: Offset 0x0000 xxxx xxxx xxxx xxxx xxxx xxxx ffff ffff 0x0010 0053 0103 026b 2001 17aa 109a 8086 80df 0x0020 0000 2000 7e54 0000 0014 00da 0004 2700 0x0030 6cc9 3150 073e 040b 298b 0000 f000 0f02 (I masked out the MAC address) -- Martin From jfvogel at gmail.com Mon Aug 4 19:12:27 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Aug 4 19:12:36 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080804205252.74141013@web.de> References: <20080801142005.473c17ca@zelda.local> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> <48973DD9.20303@alaska.net> <20080804205252.74141013@web.de> Message-ID: <2a41acea0808041212g4d8790dds712e9e2309827f75@mail.gmail.com> OK, so your EEPROM is does not have the bug. As I was saying before, I would like to see what back to back behavior is. And, BTW, back to back does NOT mean hook to the switch, that's the very thing that is suspicious. It means NIC to NIC, no DHCP, assigned addresses. And then see that you pass traffic, and then unhook cable, see if link goes down, reconnect and it should go up. Oh, and exactly what kernel, and driver revision are you using. Jack On Mon, Aug 4, 2008 at 11:52 AM, Martin wrote: > On Mon, 04 Aug 2008 09:35:21 -0800 > Royce Williams wrote: > >> Jack Vogel wrote, on 8/4/2008 9:18 AM: >> > The focus here on the laptop distracted me, but someone else at work >> > reminded me. Its very important that you run the EEPROM fix for >> > the 82573 that i posted a long while back, search in email archive >> > for it. Its a DOS executable that will patch your EEPROM. >> > >> > I am not sure if the Lenova's need it, but get it, run it, and then >> > see if your problem goes away. >> >> Martin, there's also a link to it from Jeremy's "Commonly Reported >> Issues" page: >> >> http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues >> >> Look for "DOS-based EEPROM". > > Hi Royce, > > thank you for the link. I've read this issue description and I'm not > sure if it helps. I don't have any "watchdog timeouts" and my EEPROM > data looks clean: > > Interface EEPROM Dump: > Offset > 0x0000 xxxx xxxx xxxx xxxx xxxx xxxx ffff ffff > 0x0010 0053 0103 026b 2001 17aa 109a 8086 80df > 0x0020 0000 2000 7e54 0000 0014 00da 0004 2700 > 0x0030 6cc9 3150 073e 040b 298b 0000 f000 0f02 > > (I masked out the MAC address) > > -- > Martin > From v.haisman at sh.cvut.cz Mon Aug 4 19:15:53 2008 From: v.haisman at sh.cvut.cz (=?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?=) Date: Mon Aug 4 19:16:00 2008 Subject: Top, TIME and CPU columns Message-ID: <48974E22.6010406@sh.cvut.cz> Hi, I have noticed this weirdness in top. Sometimes I can see no process having more than single percents in the (W)CPU column, yet there is one for that the TIME column is steadily increasing by 1 second per second. How is this (W)CPU column computed? Shouldn't it report something like 1/NCPU * 100 or something? -- VH -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 219 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080804/6a805d9e/signature.pgp From ronald-freebsd8 at klop.yi.org Mon Aug 4 19:42:14 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Mon Aug 4 19:42:26 2008 Subject: 5.x to 6.x or 7.x with 64MB / In-Reply-To: <49120.1217868483@thrush.ravenbrook.com> References: <49120.1217868483@thrush.ravenbrook.com> Message-ID: On Mon, 04 Aug 2008 18:48:03 +0200, Nick Barnes wrote: > I have a machine which I have recently upgraded using cvsup, from 4.x > to RELENG_5, as a staging post en route to 7.x. The upgrade went well > until installworld ran out of disk on / and I realised it was only > 64BMB. My bad; should have checked before upgrading. With help from > an on-site colleague the installworld was nursed to completion. But > can I get the same machine up to 6.x or 7.x without repartitioning? > Advice please. > > Partitions are as follows. > > ad0 2439 M > ad0s1 2439 M > ad0s1a 64 M / > ad0s1b 128 M swap > ad0s1e 1024 M /var > ad0s1f 600 M /home > ad0s1g 623 M - > ad1 57259 M > ad1s1 57259 M > ad0s1a 10240 M /usr > > It occurs to me that if ad0s1a is insufficient then I could use ad0s1g > as swap, and repurpose ad0s1b as a new /. Is it straightforward to > installworld/mergemaster to somewhere other than / ? That is very well doable. On boot you can interrupt the boot process by pressing space an set another location for the kernel. More information is here. http://www.freebsd.org/doc/en/books/handbook/boot-blocks.html The rest is just about files. After you copy everything in ad0s1b (with a fs in it) you can boot from ad0s1b:/boot/kernel. I think you can do something like make installkernel DESTDIR=/blabla, but I'm not sure. Maybe more easy is booting with a LIVE-cd. Than you can mount everything needed for installworld in /mnt/tmproot, so you get: /mnt/tmproot mounted the _new_ / partition (ad0s1b?) /mnt/tmproot/usr where /usr is mounted (ad0s1a) /mnt/tmproot/var where /var is mounted (ad0s1e) Do a chroot /mnt/tmproot and than run installworld and mergemaster as usual from /usr/src. Don't forget to make a backup. It is on your own risk. ;-) Ronald. From gaijin.k at gmail.com Tue Aug 5 01:00:34 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Tue Aug 5 01:00:42 2008 Subject: Using Portupgrade? In-Reply-To: <20080804022618.GA4790@eos.sc1.parodius.com> References: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> <20080804022618.GA4790@eos.sc1.parodius.com> Message-ID: <1217898021.1191.14.camel@RabbitsDen> On Sun, 2008-08-03 at 19:26 -0700, Jeremy Chadwick wrote: > On Sun, Aug 03, 2008 at 09:20:08PM -0400, Nic Reveles wrote: > > I've recently updated to freeBSD 6.3-STABLE from 5.3-RELEASE (amd64) and am struggling with out of date ports. I have tried updating 'ports-all' and 'src-all' numerous times (does src-all include ports-all? It takes forever) along with portupgrade. > > src-all does not include ports-all. > > "It takes forever" is wonderfully vague. :-) Chances are the cvsup > server you're using is slow (usually caused by heavy disk I/O, not so > much network I/O); pick another. Try them all, find one which is fast. > I'd recommend a couple I commonly use, but then everyone will start > using them....... :-) One can install sysutils/fastest_cvsup and run fastest_cvsup -c -- Alexandre "Sunny" Kovalenko (????????? ?????????) From koitsu at FreeBSD.org Tue Aug 5 01:34:49 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 5 01:34:56 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <20080801154208.W6085@fledge.watson.org> <2a41acea0808010924u22603c61p10e47237fad5b6fb@mail.gmail.com> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> Message-ID: <20080805013448.GA64950@eos.sc1.parodius.com> On Mon, Aug 04, 2008 at 10:18:50AM -0700, Jack Vogel wrote: > The focus here on the laptop distracted me, but someone else at work > reminded me. Its very important that you run the EEPROM fix for > the 82573 that i posted a long while back, search in email archive > for it. Its a DOS executable that will patch your EEPROM. > > I am not sure if the Lenova's need it, but get it, run it, and then > see if your problem goes away. The tool Jack is referring to is below. I knew saving it for a rainy day would be worth it. :-) http://people.freebsd.org/~koitsu/em_82573_manc_fix.zip -- | Jeremy Chadwick jdc 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 | From alex-goncharov at comcast.net Tue Aug 5 01:35:53 2008 From: alex-goncharov at comcast.net (Alex Goncharov) Date: Tue Aug 5 01:36:06 2008 Subject: Portmaster questions (Was: Re: Using Portupgrade?) In-Reply-To: <4896904E.9070807@FreeBSD.org> (message from Doug Barton on Sun, 03 Aug 2008 22:14:54 -0700) References: <696148549.2959541217812741596.JavaMail.root@mail3.gatech.edu> <1938178730.2959681217812808135.JavaMail.root@mail3.gatech.edu> <20080804022618.GA4790@eos.sc1.parodius.com> <4896904E.9070807@FreeBSD.org> Message-ID: ,--- Doug Barton (Sun, 03 Aug 2008 22:14:54 -0700) ----* | It's really not appropriate to hijack the portupgrade thread for this, | so I'm starting a new subject. Also, please respect followups to | -ports. [ Being an inexperienced poster: sorry. Am I using a good cc: list now? ] | Alex Goncharov wrote: | > 1. I see a significant difference in the time it takes to get the same | > information using the two tools: | As I understand it, portupgrade uses the INDEX file to determine | whether ports are up to date. Portmaster recurses through each | installed port and does 'make -V PKGVERSION'. | | > 2. It looks like there are no `portmaster' equivalents to | > `portupgrade' `-P' and `-PP' options, which I want to have. | If portupgrade does the job for you, keep using it. :) I have said | many times that I'm not looking to write a portupgrade replacement. | Use the right tool for the job(s) you have to do. `---------------------------------------------------------------* Thank you for `postmaster' -- I do like it and am not trying to criticize. Hoped that somebody knowledgeable would tell me how to use the available port management tools better, which you just did re: "versions", thanks. ,--- Miroslav Lachman (Mon, 04 Aug 2008 11:36:58 +0200) ----* | You do not have to run portversion or portmaster or any other 3rd party | tool to check versions of installed ports. Use pkg_version which is | included in base system and then you are independent of port management | tools changes. | pkg_version (by default) do not use INDEX, but have option to use it and | then become clear winner (in speed): Thank you -- I didn't know that and am switching to "pkg_version -I" now!.. | As I had problems with portupgrade's handling of dependencies, I am | converted to portmaster. `---------------------------------------------------------------* I've also had enough problems with portupgrade's -R option and essentially stopped using it (the option). ,--- Marcin Wisnicki (Mon, 4 Aug 2008 15:24:37 +0000 (UTC)) ----* | It's not even doing a good job at it, standard pkg_version significantly | outperforms it: `---------------------------------------------------------------* Well, I guess I'll make another, better informed attempt to switch to portmaster now. Thank you all who replied for the useful information! -- Alex -- alex-goncharov@comcast.net -- From DarkStone at mu.com Tue Aug 5 03:13:05 2008 From: DarkStone at mu.com (DarkStone MuOnline Server) Date: Tue Aug 5 03:13:11 2008 Subject: DarkStone MuOnline Server Challenge you To a Duel. Message-ID: <200808042138.m74Lcfh31366@www.377963.com> [votenew.jpg] _________________________________________________________________ [pixel.gif] www.darkstonemu.net [pixel.gif] [pixel.gif] [pixel.gif] [pixel.gif] [muonlinedarkstoneadv256vo4.gif] DarkStone MuOnline DarkStone MU Online is a MMORPG that takes the player, into a fantasy world full of excitement, adventure and monsters. With several ways to train a character, multiple character classes, and a vast continent to explore, GMO is a sure way to a unique adventure. Join thousands of players from all over the world and help defend the Continent of Legend, clearing it from the clenches of Kundun and his forces forever. . With new content and features being introduced regularly, this game is perfect for those looking for an exciting MMO experience. [pixel.gif] [pixel.gif] [pixel.gif] You start off as a Dark Wizard, a Dark Knight, Dark Lord, Magic GLadiator, a Summoner or a Fairy Elf, with accordant strengths and weaknesses. You can save different base characters, a fun feature that allows you to begin play as a wizard, and later, restart and switch to a knight--but not both at the same time. The look of your character changes to reflect any new accoutrements you get, including wings and spells. There's also a coordinate system on display, so it's easier to move around the elaborate MU world. Items can be combined in many different ways, but more game experience gets you better gear. You can even fight other players, but be warned: if you kill too many innocents, you'll be branded a murderer. Server Stats: ON * Experience: 1000x * Drops: 80% * Reset Level: 399 keep stats * Shops: +7 items. (you have to find some shops for the good items.) * Bless Bug On * Register: http://www.darkstonemu.net/DarkStone-Register.html * Download: http://www.darkstonemu.net/DarkStone-Downloads.html Official Game Installer: http://darkstonemu.net/Download/DarkStoneMu.exe In order to play free just enter your [1]Site and download the [2]Client. We encourage you to visit the DarkStone MU Online forums at [3]http://darkstonemu.net/ _________________________________________________________________ *Please do not respond to this e-mail as your reply will not be received. References 1. http://www.darkstonemu.net/DarkStone-Register.html 2. http://www.darkstonemu.net/DarkStone-Downloads.html 3. http://www.craiova-online.ro/rds-mu-server-212/ From peterjeremy at optushome.com.au Tue Aug 5 10:44:40 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Aug 5 10:44:54 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <8e10486b0808040949ka12edf0o38e3a790d620992e@mail.gmail.com> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> <1215105220.32135.18.camel@buffy.york.ac.uk> <8e10486b0807031041o54349836i31c5da84ebda70f6@mail.gmail.com> <1215176991.36376.24.camel@buffy.york.ac.uk> <8e10486b0807040834m27a38254k5261535d93d70ce6@mail.gmail.com> <8e10486b0808040949ka12edf0o38e3a790d620992e@mail.gmail.com> Message-ID: <20080805104436.GT1359@server.vk2pj.dyndns.org> On 2008-Aug-04 13:49:58 -0300, Alexandre Biancalana wrote: >Modems connected but they only work on ports of the first module, any >decice connected on ports of second module does not work. ISTR the problem I ran into was that the octet read out of the driver bore little resemblance to the serial data written into the port. The bit-rate would match and framing was reported as correct but I would get nonsense in the top or bottom 4 bits. My notes are at work and I'll try and dig them up tomorrow. >Any other idea ? All I can suggest is comparing the Linux driver with the FreeBSD one (and maybe someone needs to confirm if it works in Linux). I couldn't find a difference but maybe someone will see something I missed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/289aeba0/attachment.pgp From sebster at sebster.com Tue Aug 5 10:55:23 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Tue Aug 5 10:55:30 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 Message-ID: <48982B58.4000406@sebster.com> Hi, I'm running FreeBSD 6.3 (I know, I should upgrade), and I just bought an add-on pci SATA controller for 2 extra SATA disks. However, a lot of disk activity on the drives will often cause the machine to crash and spontaneously reboot. I checked out which chipset was on the card with pciconf -lv and I found it was the Sil 3512. Googling showed me that I'm not the only one with problems using this card. Does anybody have experience with a (preferably not too expensive) 2-port SATA expansion card which does not have any issues running under FreeBSD 6.3/7.0? [pciconf -lv output] atapci0@pci0:10:0: class=0x018000 card=0x35121095 chip=0x35121095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'Sil 3512 SATALink/SATARaid Controller' class = mass storage [/var/log/messages before the crash] Aug 5 11:16:14 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)]error = 6 Aug 5 11:16:17 piglet last message repeated 9 times Regards, Sebastiaan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/ef0dd537/smime.bin From nakal at web.de Tue Aug 5 10:57:50 2008 From: nakal at web.de (Martin) Date: Tue Aug 5 10:57:58 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808041212g4d8790dds712e9e2309827f75@mail.gmail.com> References: <20080801142005.473c17ca@zelda.local> <20080802064727.042d5e3d@web.de> <2a41acea0808021034g588fdc77w50797f473e8809b0@mail.gmail.com> <20080804113448.0a4b3991@zelda.local> <20080804102307.GA28928@eos.sc1.parodius.com> <20080804125138.59ed0252@zelda.local> <20080804174458.4dda8369@zelda.local> <2a41acea0808041018nc60b3uf53d2e898a73d9a9@mail.gmail.com> <48973DD9.20303@alaska.net> <20080804205252.74141013@web.de> <2a41acea0808041212g4d8790dds712e9e2309827f75@mail.gmail.com> Message-ID: <20080805125735.5673ce35@zelda.local> Am Mon, 4 Aug 2008 12:12:24 -0700 schrieb "Jack Vogel" : > OK, so your EEPROM is does not have the bug. As I was > saying before, I would like to see what back to back behavior is. > > And, BTW, back to back does NOT mean hook to the switch, > that's the very thing that is suspicious. It means NIC to NIC, > no DHCP, assigned addresses. And then see that you pass > traffic, and then unhook cable, see if link goes down, reconnect > and it should go up. With no /etc/rc.d/netif script involved during startup everything always works as expected. If I comment the line ifconfig_re0="DHCP" and start my laptop. I can assign the address. I can ping the other NIC. If can unhook the cable the LED goes off, link goes down, I can plug it in again, I can ping again. I have also no problems if I start without ifconfig_re0="DHCP" and run "dhclient em0" while ethernet cable is unplugged. If I plug it in again, everything works like above. But: If I startup with ifconfig_em0="DHCP" AND (binary and!) no cable nothing of this works correctly. There must be something ifconfig_em="DHCP" causes on startup that running dhclient does not cause and that provokes the dead state. > Oh, and exactly what kernel, and driver revision are you using. Kernel is FreeBSD-STABLE compile date Mon Aug 4 13:41:43 CEST 2008. It's GENERIC. The em(4) driver is the one used in this STABLE version of yesterday. I should perhaps mention that I have some other problems with this laptop. I cannot boot with a PCMCIA wireless card (atheros) already in the slot, or I get 100% load on cbb(4) and the system is not usable. If I boot without the Atheros card and I plug it in later, it mostly is detected. AND I get sometimes an NMI when Atheros card is in use AND (binary and again!) the laptop is on battery. This happens also on Linux. AND the laptop will almost never recognize the Atheros card, if I am using a text terminal with high resolution (set by vidcontrol MODE_280 with VESA support compiled in; cannot reproduce now, because I'm using GENERIC). I don't know if these things are related. I will get some other laptop in one or two months. I hope these things won't bother me anymore. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/690ce851/signature.pgp From igorr at canmos.ru Tue Aug 5 11:37:54 2008 From: igorr at canmos.ru (Igor V. Ruzanov) Date: Tue Aug 5 11:38:02 2008 Subject: Query timeouts on FreeBSD 7 over network In-Reply-To: <15CEC87F00BB7B4CA0E904C5FCF05646243E8601@exchangenj1> References: <15CEC87F00BB7B4CA0E904C5FCF05646243E8601@exchangenj1> Message-ID: > I've tried with the ULE scheduler and 4BSD and tried with and with > out PREEMPTION turned on. Nothing makes a difference. First of all you could try to connect only two machines via cross-over cable, no any switches between the machines, no any VLANs and so on. FreeBSD-7.0 works better with ULE-scheduler and kernel should be preemtive (options PREEMPTION in kernel config). - what is your kernel config? > I'm pretty sure this is related to the OS or the em driver in some way, because if I disable all ICMP rate limiting and run an extended ping from the local firewall, I experience a very low amount of random packet loss in no pattern, unlike if you have the ICMP rate limiting enabled. Once again it would be better if you do analyze the traffic going throuth the em-interface excluding your DNS testing data. Try to get the network with no any walking packets but dnsperf traffic and no any upinks and/or downlinks. > Also, are there any documented recommendations for sysctl values for FreeBSD when running BIND for optimal performance? - What options did you provide to configure script during BIND building? One of necessary options should be --enable-threads if you build BIND under FreeBSD 7.0. +-------------------------------------------+ ! CANMOS ISP Network ! +-------------------------------------------+ ! Best regards ! ! Igor V. Ruzanov, network operational staff! ! e-Mail: igorr@canmos.ru ! +-------------------------------------------+ From koitsu at FreeBSD.org Tue Aug 5 12:16:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 5 12:16:40 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <48982B58.4000406@sebster.com> References: <48982B58.4000406@sebster.com> Message-ID: <20080805121632.GA88406@eos.sc1.parodius.com> On Tue, Aug 05, 2008 at 12:28:40PM +0200, Sebastiaan van Erk wrote: > However, a lot of disk activity on the drives will often cause the > machine to crash and spontaneously reboot. I checked out which chipset > was on the card with pciconf -lv and I found it was the Sil 3512. > Googling showed me that I'm not the only one with problems using this > card. Yes, most of the Silicon Image ICs I've read about have odd driver problems or general issues (even under Windows). The system rebooting is an odd one; you sure your PSU can handle two disks? > Does anybody have experience with a (preferably not too expensive) > 2-port SATA expansion card which does not have any issues running under > FreeBSD 6.3/7.0? Promise makes some consumer-priced cards which work very well under FreeBSD (sos@ has full documentation on their cards). Their RAID controllers (the consumer-level ones) **do not** require that you use RAID; they support JBOD, and the disks will show up under FreeBSD as ad(4) devices. (If you choose to use the RAID, you'll still see the ad(4) disks, but you'll also see an ar(4) device too. This has the added advantage of you being able to monitor SMART stats on the disks themselves directly, etc... > [pciconf -lv output] > atapci0@pci0:10:0: class=0x018000 card=0x35121095 chip=0x35121095 > rev=0x01 > hdr=0x00 > vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > device = 'Sil 3512 SATALink/SATARaid Controller' > class = mass storage > > [/var/log/messages before the crash] > Aug 5 11:16:14 piglet kernel: > g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)] error = 6 > Aug 5 11:16:17 piglet last message repeated 9 times Are you sure this is being caused by the controller? Have you checked SMART statistics on both disks? Assuming error == errno, errno 6 is "Device not configured". There's been recent discussion of such messages being caused by the use of gmirror or gjournal, when the mirror/journal is improperly set up. (In one users' case, he was receiving similar errors, as well as the filesystem failing during fsck. Turns out he incorrectly configured journalling, which nuked the last ~1MB of his UFS filesystem.) I'm not saying this is the reason for the messages you see, but it's something to keep in mind. -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Tue Aug 5 12:24:45 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 5 12:24:51 2008 Subject: Query timeouts on FreeBSD 7 over network In-Reply-To: References: <15CEC87F00BB7B4CA0E904C5FCF05646243E8601@exchangenj1> Message-ID: <20080805122444.GB88406@eos.sc1.parodius.com> On Tue, Aug 05, 2008 at 03:04:50PM +0400, Igor V. Ruzanov wrote: >> I've tried with the ULE scheduler and 4BSD and tried with and with >> out PREEMPTION turned on. Nothing makes a difference. > First of all you could try to connect only two machines via cross-over > cable, no any switches between the machines, no any VLANs and so on. > FreeBSD-7.0 works better with ULE-scheduler and kernel should be > preemtive (options PREEMPTION in kernel config). > - what is your kernel config? > >> I'm pretty sure this is related to the OS or the em driver in some way, because if I disable all ICMP rate limiting and run an extended ping from the local firewall, I experience a very low amount of random packet loss in no pattern, unlike if you have the ICMP rate limiting enabled. I believe -stable just got added to this thread, so I'm not sure if these details were provided prior. My apologies if this stuff has already been dealt with. 1) Are there any messages from the kernel about watchdog timeouts or other anomalies pertaining to the network? Look in dmesg. 2) pciconf -lv (only include the Ethernet entries please), vmstat -i and netstat -in output. 3) Try disabling MSI/MSI-X via /boot/loader.conf variables (you'll need to reboot after this): hw.pci.enable_msi="0" hw.pci.enable_msix="0" 4) Disabling TSO on the interface, and in the OS: ifconfig emXX -tso sysctl net.inet.tcp.tso=0 -- | Jeremy Chadwick jdc 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 | From sebster at sebster.com Tue Aug 5 13:13:01 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Tue Aug 5 13:13:08 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080805121632.GA88406@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> Message-ID: <489851DB.20406@sebster.com> Hi, Thanks for the reply. Jeremy Chadwick wrote: > Yes, most of the Silicon Image ICs I've read about have odd driver > problems or general issues (even under Windows). The system rebooting > is an odd one; you sure your PSU can handle two disks? Well, I've got a 450W Asus PSU in there, but I've also got 6 hard disks and 1 dvd-rom drive (mostly inactive) in there. The hard disks are mostly 250/300GB but the two new ones are 1TB SATA drives. But the 450W should easily be enough, shouldn't it? >> Does anybody have experience with a (preferably not too expensive) >> 2-port SATA expansion card which does not have any issues running under >> FreeBSD 6.3/7.0? > > Promise makes some consumer-priced cards which work very well under > FreeBSD (sos@ has full documentation on their cards). > > Their RAID controllers (the consumer-level ones) **do not** require that > you use RAID; they support JBOD, and the disks will show up under > FreeBSD as ad(4) devices. (If you choose to use the RAID, you'll still > see the ad(4) disks, but you'll also see an ar(4) device too. This has > the added advantage of you being able to monitor SMART stats on the > disks themselves directly, etc... I'll have a look at that if I can't get this one stable. They're reasonably priced, so if they're good with FreeBSD then that looks like a good option to me. >> [pciconf -lv output] >> atapci0@pci0:10:0: class=0x018000 card=0x35121095 chip=0x35121095 >> rev=0x01 >> hdr=0x00 >> vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' >> device = 'Sil 3512 SATALink/SATARaid Controller' >> class = mass storage >> >> [/var/log/messages before the crash] >> Aug 5 11:16:14 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)] error = 6 >> Aug 5 11:16:17 piglet last message repeated 9 times > > Are you sure this is being caused by the controller? Have you checked > SMART statistics on both disks? Assuming error == errno, errno 6 is > "Device not configured". I did look at the smart stats [pasted them below]. What I will try next is just to switch the two 250GB SATA drives on my main board with the two 1TB drives on the controller and see if I still get the problems if I really increase the load on the two 1TB drives. > There's been recent discussion of such messages being caused by the use > of gmirror or gjournal, when the mirror/journal is improperly set up. > (In one users' case, he was receiving similar errors, as well as the > filesystem failing during fsck. Turns out he incorrectly configured > journalling, which nuked the last ~1MB of his UFS filesystem.) > > I'm not saying this is the reason for the messages you see, but it's > something to keep in mind. I'll try reconfigure the geom. I used an online tutorial, but I'm not quite sure that I did everything correctly, though fsck worked alright. I did do this one differently than usual though, usually I use full disk mirror after I already initialized one of the disks, and then I convert it to a mirror by using: sysctl kern.geom.debugflags=16 gmirror label -v -b round-robin gm0 /dev/ad0 gmirror insert gm0 /dev/ad2 (Especially useful when you want the entire FreeBSD install to be mirrored). I guess I can try this on the extra disks as well. Regards, Sebastiaan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/a26136a8/smime.bin From sebster at sebster.com Tue Aug 5 13:16:43 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Tue Aug 5 13:17:00 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080805121632.GA88406@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> Message-ID: <489852B9.9060708@sebster.com> Hi, Sorry for forgetting to paste the smart details. Pressed send too quickly. However, when I did check the smart stats again, I noticed I'd been smartctling the wrong disk (duh), and smart was not enabled on the new disks. I enabled it now, and it comes with a bunch of warnings and other stuff.... Considering it wasn't enabled, maybe the errors wouldn't show up anyway, but here's the output of the smartctl command just in somebody sees something to worry about in it... (The ECC recovery count looks rather high, I tried -F samsung and -F samsung2 but that didn't help). Regards, Sebastiaan root@piglet(ttyp3:59:0):~# smartctl -a /dev/ad4 smartctl version 5.37 [i386-portbld-freebsd6.3] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103UJ Serial Number: S13PJ1BQ606865 Firmware Version: 1AA01112 User Capacity: 1,000,204,886,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Not recognized. Minor revision code: 0x52 Local Time is: Tue Aug 5 15:15:20 2008 CEST ==> WARNING: May need -F samsung or -F samsung2 enabled; see manual for details. SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (11811) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 198) minutes. Conveyance self-test routine recommended polling time: ( 21) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 090 090 011 Pre-fail Always - 4050 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 4 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 230 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 4 13 Read_Soft_Error_Rate 0x000e 253 253 000 Old_age Always - 0 183 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 184 Unknown_Attribute 0x0033 100 100 099 Pre-fail Always - 0 187 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 190 Temperature_Celsius 0x0022 056 056 000 Old_age Always - 740818988 194 Temperature_Celsius 0x0022 052 052 000 Old_age Always - 48 (Lifetime Min/Max 0/12324) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 153751007 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 0 Warning: ATA Specification requires self-test log structure revision number = 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective Self-Test Log Data Structure Revision Number (0) should be 1 SMART Selective self-test log data structure revision number 0 Warning: ATA Specification requires selective self-test log data structure revision number = 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. root@piglet(ttyp3:60:0):~# Jeremy Chadwick wrote: > On Tue, Aug 05, 2008 at 12:28:40PM +0200, Sebastiaan van Erk wrote: >> However, a lot of disk activity on the drives will often cause the >> machine to crash and spontaneously reboot. I checked out which chipset >> was on the card with pciconf -lv and I found it was the Sil 3512. >> Googling showed me that I'm not the only one with problems using this >> card. > > Yes, most of the Silicon Image ICs I've read about have odd driver > problems or general issues (even under Windows). The system rebooting > is an odd one; you sure your PSU can handle two disks? > >> Does anybody have experience with a (preferably not too expensive) >> 2-port SATA expansion card which does not have any issues running under >> FreeBSD 6.3/7.0? > > Promise makes some consumer-priced cards which work very well under > FreeBSD (sos@ has full documentation on their cards). > > Their RAID controllers (the consumer-level ones) **do not** require that > you use RAID; they support JBOD, and the disks will show up under > FreeBSD as ad(4) devices. (If you choose to use the RAID, you'll still > see the ad(4) disks, but you'll also see an ar(4) device too. This has > the added advantage of you being able to monitor SMART stats on the > disks themselves directly, etc... > >> [pciconf -lv output] >> atapci0@pci0:10:0: class=0x018000 card=0x35121095 chip=0x35121095 >> rev=0x01 >> hdr=0x00 >> vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' >> device = 'Sil 3512 SATALink/SATARaid Controller' >> class = mass storage >> >> [/var/log/messages before the crash] >> Aug 5 11:16:14 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)] error = 6 >> Aug 5 11:16:17 piglet last message repeated 9 times > > Are you sure this is being caused by the controller? Have you checked > SMART statistics on both disks? Assuming error == errno, errno 6 is > "Device not configured". > > There's been recent discussion of such messages being caused by the use > of gmirror or gjournal, when the mirror/journal is improperly set up. > (In one users' case, he was receiving similar errors, as well as the > filesystem failing during fsck. Turns out he incorrectly configured > journalling, which nuked the last ~1MB of his UFS filesystem.) > > I'm not saying this is the reason for the messages you see, but it's > something to keep in mind. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/392530bb/smime.bin From koitsu at FreeBSD.org Tue Aug 5 15:05:42 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 5 15:05:50 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <489852B9.9060708@sebster.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> <489852B9.9060708@sebster.com> Message-ID: <20080805150542.GA95948@eos.sc1.parodius.com> On Tue, Aug 05, 2008 at 03:16:41PM +0200, Sebastiaan van Erk wrote: > Sorry for forgetting to paste the smart details. Pressed send too quickly. A note for the list: Sebastiaan and I are discussing the details off-list. I don't know if he forgot to CC the list on his replies, or if he intentionally sent them to me directly. :-) Just thought I'd make note of that here, in case readers wonder what becomes of this issue. -- | Jeremy Chadwick jdc 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 | From lists at lozenetz.org Tue Aug 5 15:30:58 2008 From: lists at lozenetz.org (Anton - Valqk) Date: Tue Aug 5 15:31:05 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080805150542.GA95948@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> <489852B9.9060708@sebster.com> <20080805150542.GA95948@eos.sc1.parodius.com> Message-ID: <48986E17.8060506@lozenetz.org> Hi, I'm interested and following the thread, can you pls send the communication that's of importance to all at the end? cheers, valqk. Jeremy Chadwick wrote: > On Tue, Aug 05, 2008 at 03:16:41PM +0200, Sebastiaan van Erk wrote: > >> Sorry for forgetting to paste the smart details. Pressed send too quickly. >> > > A note for the list: Sebastiaan and I are discussing the details > off-list. I don't know if he forgot to CC the list on his replies, or > if he intentionally sent them to me directly. :-) > > Just thought I'd make note of that here, in case readers wonder what > becomes of this issue. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ericlin at tamama.org Tue Aug 5 16:07:47 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Tue Aug 5 16:07:54 2008 Subject: Max size of one swap slice Message-ID: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> Hi All, Recently we found that we can only allocate 32GB for one swap slice. Does there is any sysctl oid or any kernel option to increase it? Why we have this restriction? From sebster at sebster.com Tue Aug 5 16:16:42 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Tue Aug 5 16:16:49 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080805150542.GA95948@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> <489852B9.9060708@sebster.com> <20080805150542.GA95948@eos.sc1.parodius.com> Message-ID: <48987CE4.8070509@sebster.com> Hi, Sorry about that, I believe I only messed up on my first reply, and I thought I mailed that to the list as well after I noticed I messed up. Thing is, I'm used to replying to mailing lists using the "Reply" button and unfortunately the reply doesn't go to the mailing list when I do that... Some people don't like it when you send it to the mailing list and CC it to them personally, but since you apparently do, I'll just use reply-all from now on. Sorry again about the mistake, Regards, Sebastiaan Jeremy Chadwick wrote: > On Tue, Aug 05, 2008 at 03:16:41PM +0200, Sebastiaan van Erk wrote: >> Sorry for forgetting to paste the smart details. Pressed send too quickly. > > A note for the list: Sebastiaan and I are discussing the details > off-list. I don't know if he forgot to CC the list on his replies, or > if he intentionally sent them to me directly. :-) > > Just thought I'd make note of that here, in case readers wonder what > becomes of this issue. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/8989e622/smime.bin From scf at FreeBSD.org Tue Aug 5 16:24:57 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Tue Aug 5 16:25:04 2008 Subject: Stuck in geli Message-ID: Rarely, a geli partition I have freezes a process in bufwait state. It occurs after an ATA timeout message: Aug 5 03:47:13 thor kernel: ad10: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=219028637 The geli partition resides on an Intel MatrixRAID RAID1 mirror using the ICH9R chipset (Asus P5K-E/WIFI). Killing (even -9) the process does not work. Rebooting is the only solution, yet the system is unable to flush the buffers and complete a clean unmounting. Both drives in the mirror have both survived a smartctl -t offline scan. Also, a previous time it was with ad12, so I strongly doubt it is the drive. It seems like a geli partition is unable to handle a timeout from a drive. ad10: Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST3160827AS ad12: Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST3160827AS Sean P.S. I could not help myself with the subject line. :) -- scf@FreeBSD.org From david at catwhisker.org Tue Aug 5 16:47:08 2008 From: david at catwhisker.org (David Wolfskill) Date: Tue Aug 5 16:47:15 2008 Subject: Max size of one swap slice In-Reply-To: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> References: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> Message-ID: <20080805162425.GO44815@bunrab.catwhisker.org> On Tue, Aug 05, 2008 at 11:39:11PM +0800, Lin Jui-Nan Eric wrote: > ... > Recently we found that we can only allocate 32GB for one swap slice. Yes. > Does there is any sysctl oid or any kernel option to increase it? Why > we have this restriction? I don't know why, though I suspect it may have something to do with the way storage in the swap space is allocated & addressed. You may, however, have more than 1 swap space. (Per man pages for swapon(8) and swapoff(8), the default maximum is 4.) Peace, david -- David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/713b483a/attachment.pgp From cswiger at mac.com Tue Aug 5 17:01:39 2008 From: cswiger at mac.com (Chuck Swiger) Date: Tue Aug 5 17:01:47 2008 Subject: Max size of one swap slice In-Reply-To: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> References: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> Message-ID: On Aug 5, 2008, at 8:39 AM, Lin Jui-Nan Eric wrote: > Recently we found that we can only allocate 32GB for one swap slice. > Does there is any sysctl oid or any kernel option to increase it? Why > we have this restriction? This size limitation likely predates the availability of disks larger than 32GB. It's hard to conceive of why you'd want to add so much swap space, anyway-- if you've got programs which actually need to deal with 10s of gigabytes worth of data, then they ought to maintain a smaller/ reasonable-sized working set in RAM and do disk I/O as needed themselves rather than depend upon the VM pager, anyways. (Well, when using a BSD-derived kernel, anyways. Some of the Mach kernels support userland VM pager implementations, so that things like a database or Photoshop can provide their own pager which understands their workload and chooses which pages to evict or replace better than the default system pager algorithm can.) Regards, -- -Chuck From sebster at sebster.com Tue Aug 5 17:08:30 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Tue Aug 5 17:08:40 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080805150301.GA94198@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> <48984BF1.60805@sebster.com> <20080805150301.GA94198@eos.sc1.parodius.com> Message-ID: <48988904.80509@sebster.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080805/60f00b4d/smime.bin From max at love2party.net Tue Aug 5 17:19:36 2008 From: max at love2party.net (Max Laier) Date: Tue Aug 5 17:19:43 2008 Subject: Max size of one swap slice In-Reply-To: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> References: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> Message-ID: <200808051919.34577.max@love2party.net> On Tuesday 05 August 2008 17:39:11 Lin Jui-Nan Eric wrote: > Recently we found that we can only allocate 32GB for one swap slice. > Does there is any sysctl oid or any kernel option to increase it? Why > we have this restriction? this is a consequence of the data structure used to manage swap space. See sys/blist.h for details. It *seems* that you *might* be able to increase the coverage by decreasing BLIST_META_RADIX, but that's from a quick glance and most certainly not a good idea. However, the blist is a abstract enough API so that you can likely replace it with something that supports 64bit addresses (and thus 512*2^64 bytes of swap space per device) ... but I don't see why you'd want to do something like this. Remember that you need memory to manage your swap space as well! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From dillon at apollo.backplane.com Tue Aug 5 18:29:25 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Aug 5 18:29:33 2008 Subject: Max size of one swap slice References: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> <200808051919.34577.max@love2party.net> Message-ID: <200808051829.m75ITLmS029177@apollo.backplane.com> :> Recently we found that we can only allocate 32GB for one swap slice. :> Does there is any sysctl oid or any kernel option to increase it? Why :> we have this restriction? : :this is a consequence of the data structure used to manage swap space. See :sys/blist.h for details. It *seems* that you *might* be able to increase the :coverage by decreasing BLIST_META_RADIX, but that's from a quick glance and :most certainly not a good idea. : :However, the blist is a abstract enough API so that you can likely replace it :with something that supports 64bit addresses (and thus 512*2^64 bytes of swap :space per device) ... but I don't see why you'd want to do something like :this. Remember that you need memory to manage your swap space as well! : :-- :/"\ Best regards, | mlaier@freebsd.org :\ / Max Laier | ICQ #67774661 The core structures can handle 2 billion swap pages == 2TB of swap, but the blist code hits arithmatic overflows if a single blist has more then (0x40000000 / BLIST_META_RADIX) = 1G/16 = 64M swap blocks, or 256GB. I think the VM/BIO system had additional overflow issues due to conversions back and forth between PAGE_SIZE and DEV_BSIZE which further restricted the limit to 32GB. Those restrictions may be gone now that FreeBSD is using 64 bit block numbers, so you may be able to pop it up to 256GB with virtually no effort (but you need to test it significantly!). With some work on the blist code only (not its structures) the arithmatic overflow issues could also be resolved, increasing the swap capability to 2TB. I do not recommend changing any of the core blist structure, particularly not BLIST_META_RADIX. Just don't try :-). You do NOT want to bump the swap block number fields to 64 bits. Also note that significant memory is used to manage that much swap. It's a factor of 1:16384 or so for the blist structures and probably about the same amount for the vm_object tracking structures. 32G of swap needs around 2-4MB of wired ram. -Matt Matthew Dillon From dg at dglawrence.com Tue Aug 5 18:37:33 2008 From: dg at dglawrence.com (David G Lawrence) Date: Tue Aug 5 18:37:39 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: Message-ID: <20080804020228.GG1663@tnn.dglawrence.com> > The thrust of this change is to replace the mutexes protecting the inpcb > and inpcbinfo data structures with read-write locks (rwlocks). These That's really cool and directly affects my current work project. I'm developing (have developed, actually) a multi-threaded, 5000+ member VoIP/SIP conferencing server called Nconnect. It a primarily UDP application running on FreeBSD 7. This generates and receives about 250,000 UDP packets a second, with 200 byte packets, resulting in about 400Mbps of traffic in each direction. The current bottleneck is the kernel UDP processing. It should be possible to scale to 10000+ members if kernel UDP processing had optimal concurrency. Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm looking forward to the MFC. -DG Dr. David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 Pave the road of life with opportunities. From datahead4 at gmail.com Tue Aug 5 19:18:21 2008 From: datahead4 at gmail.com (Matt) Date: Tue Aug 5 19:18:28 2008 Subject: Upcoming ABI Breakage in RELENG_7 In-Reply-To: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> Message-ID: On Tue, Jul 29, 2008 at 10:45 AM, Ken Smith 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. > Just updated to 7-STABLE last night and found that Truecrypt (which uses a combination of fuse and mdconfig to mount its encrypted volumes) is now completely unable to mount its encrypted volumes. I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no avail. As Truecrypt is implementing an encrypted file system, I am assuming at this point that the kernel ABI breakage may be what is causing this new problem. Are the any calls in particular that I should be looking for in the Truecrypt code to see where it might be choking on the new kernel ABI? I've briefly reviewed some of the changes in r181119 but lack the experience to discern anything useful from them. I'd like to file an issue with the Truecrypt devs if I can get an idea of where the breakage might be. Thanks, Matt > Thanks. > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > > From dougb at FreeBSD.org Tue Aug 5 22:09:23 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Aug 5 22:09:30 2008 Subject: Upcoming ABI Breakage in RELENG_7 In-Reply-To: References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> Message-ID: <4898CF8F.1080802@FreeBSD.org> Matt wrote: > Just updated to 7-STABLE last night and found that Truecrypt (which > uses a combination of fuse and mdconfig to mount its encrypted > volumes) is now completely unable to mount its encrypted volumes. > I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no > avail. Silly question, but did you build AND install both a new world AND a new kernel before you rebuilt your ports? Doug -- This .signature sanitized for your protection From datahead4 at gmail.com Wed Aug 6 01:21:34 2008 From: datahead4 at gmail.com (Matt) Date: Wed Aug 6 01:21:55 2008 Subject: Upcoming ABI Breakage in RELENG_7 In-Reply-To: <4898CF8F.1080802@FreeBSD.org> References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <4898CF8F.1080802@FreeBSD.org> Message-ID: On Tue, Aug 5, 2008 at 5:09 PM, Doug Barton wrote: > Matt wrote: >> >> Just updated to 7-STABLE last night and found that Truecrypt (which >> uses a combination of fuse and mdconfig to mount its encrypted >> volumes) is now completely unable to mount its encrypted volumes. >> I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no >> avail. > > Silly question, but did you build AND install both a new world AND a new > kernel before you rebuilt your ports? > Yes - full, clean (deleted /usr/obj/* before build) build on world + kernel. I've run it through a couple ktrace runs looking for obvious problems, but haven't found anything that I can interpret yet. It appears the failures are triggering around some file-descriptor errors, but nothing that makes any sense yet. I'll look at things a little closer when I get some more time - need to boot into a backup copy of the 7-RELEASE system to get some baselines. Matt > Doug > > -- > > This .signature sanitized for your protection > > From koitsu at FreeBSD.org Wed Aug 6 03:17:51 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 6 03:18:00 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <48988904.80509@sebster.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> <48984BF1.60805@sebster.com> <20080805150301.GA94198@eos.sc1.parodius.com> <48988904.80509@sebster.com> Message-ID: <20080806031751.GA33798@eos.sc1.parodius.com> On Tue, Aug 05, 2008 at 07:08:20PM +0200, Sebastiaan van Erk wrote: > Jeremy Chadwick wrote: >> On Tue, Aug 05, 2008 at 02:47:45PM +0200, Sebastiaan van Erk wrote: >>> Hi, >>> >>> Thanks for the reply. >>> >>> Jeremy Chadwick wrote: >>>> Yes, most of the Silicon Image ICs I've read about have odd driver >>>> problems or general issues (even under Windows). The system rebooting >>>> is an odd one; you sure your PSU can handle two disks? >>> Well, I've got a 450W Asus PSU in there, but I've also got 6 hard >>> disks and 1 dvd-rom drive (mostly inactive) in there. The hard disks >>> are mostly 250/300GB but the two new ones are 1TB SATA drives. But >>> the 450W should easily be enough, shouldn't it? >> >> Without getting into semantics, a 450W PSU may be on the light side for >> 6 disks. I'm fairly amazed you're able to power up that machine without >> disk errors or other problems during POST. You'll be having 6 disks >> spin up all simultaneously -- and spin-up is when disks draw the most >> power, and possibly during normal operation. >> >> If you have a different (or larger) PSU, I would recommend trying that >> to see if it addresses your problem. A PSU which isn't providing enough >> power will cause the disks to occasionally disconnect from the bus, or >> the machine sporadtically lock up, reboot (power-cycle), or other odd >> things. > > Unfortunately I don't have a larger PSU lying around, but I could buy > one; though I'd like to try some other stuff first because I've had 6 > disks in my PC before without any problems. See the very bottom of my mail. I don't believe the PSU is the problem, after reviewing your SMART statistics. > <...parts of thread cut...> > My other (on-board) SATA controller is a VIA controller; and I've never > had any problems with it (although the hardware raid messed up once a > year or 2 ago, and since then I've been using software raid without any > issues). Okay, so you've got an onboard VIA (VT6410) SATA controller, an onboard VIA IDE controller, and a PCI SATA controller. I'd still like to know which disks are attached to what controller, and if any of the devices are sharing IRQs. Can you provide the output from the following two commands? dmesg | egrep 'atapci|(ad|ata)[0-9]+' vmstat -i I'm just trying to narrow stuff down. >> Your recommended method of troubleshooting (swapping the 250G for the >> 1TB) is a good idea. But hear me loud and clear: just because you >> switch the disks and the problem disappears for a few hours doesn't mean >> it's gone. There have been **many** people who have shown up on the >> mailing lists stating "I did and now it works!", only to find >> that a week later it *didn't* fix the problem. > > Yes, I don't really expect it to solve the problem, but was thinking > that at least I could try and stress test the known working disks on the > controller and try to see if it's the controller that's the problem or > the disks (or something else). I've been able to reproduce the crashes > pretty well by just doing a lot of disk IO on the 1TB disks only (so the > other disks were pretty idle during the tests). It's interesting that the disks which are giving you trouble are Samsung disks. There's some history here which you should be made aware of: In July, Daniel Eriksson reported data corruption occurring with his nVidia MCP55 chipset when 1TB Samsung disks were attached to it. The same disks on another controller performed fine. The corruption was being detected by ZFS as checksum errors. (UFS/UFS2 won't detect this sort of thing, unless the corruption is occurring somewhere within the filesystem tables.) http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043427.html Soren Schmidt (ata(4) author) replied that there are some nVidia chipset-related fixes for ATA in -CURRENT, and provided a patch. Daniel reported that the patch made absolutely no difference: http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043434.html Daniel also tried using a firmware patch for his Samsung disks, which limit the SATA speed to SATA150, but the speed was still negotiated as SATA300 (indicating the vendors' own f/w patch is broken, or FreeBSD does not play well with it). The f/w patch didn't fix his problem either: http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043432.html zbeeble@gmail.com reported using his MCP55 controller without any problem -- as long as he didn't use Samsung disks. He stated that he believes Samsung disks are PATA disks that use a PATA-to-SATA adapter inside of the drive, leading to problems (and yes, those adapters are known to cause all sorts of mayhem): http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043485.html I'm not sure what became of the thread; Daniel never provided a post-mortem. I'm left to believe he probably took zbeeble@gmail.com's advice and switched to another disk vendor. > <...parts of thread cut...> > <...smartctl output for both Samsung disks...> Thanks for upgrading to 5.38. All the SMART statistics for these disks look okay. Can you run some SMART tests on the disks? You can run these tests while the disks are in use (but I/O will make the test take longer to complete): smartctl -t short /dev/ad4 smartctl -t short /dev/ad6 Then you'll need to look at the SMART self test log, as well as the SMART error log, to see if anything is returned. Make sure the tests have completed (the Status field should be "Completed without error", unless an error was found of course): smartctl -a /dev/ad4 smartctl -a /dev/ad6 If nothing is found, try a different test (also safe to run during operation; don't let the word "offline" scare you), and repeat looking at the logs once more. This test may take some time, though: smartctl -t offline /dev/ad4 smartctl -t offline /dev/ad6 At this point, I'm inclined to believe the issue is specific to those Samsung disks. I do not believe your PSU is a problem; the SMART statistics would be showing a higher number of power-cycles if the disks were losing power. Worth noting (about Samsung disks) is that smartctl has options to work around 3 different firmware bugs. The bugs are SMART statistics-related, but those kind of mistakes don't give me "warm fuzzies". Be wary. :-) -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Wed Aug 6 03:30:17 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 6 03:30:24 2008 Subject: Stuck in geli In-Reply-To: References: Message-ID: <20080806033016.GA35921@eos.sc1.parodius.com> On Tue, Aug 05, 2008 at 10:45:16AM -0500, Sean C. Farley wrote: > Rarely, a geli partition I have freezes a process in bufwait state. It > occurs after an ATA timeout message: > Aug 5 03:47:13 thor kernel: ad10: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=219028637 This looks like the issue I've been tracking for months now. I'm sorry the document isn't complete; it's an issue of time... http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > The geli partition resides on an Intel MatrixRAID RAID1 mirror using the > ICH9R chipset (Asus P5K-E/WIFI). Killing (even -9) the process does not > work. Rebooting is the only solution, yet the system is unable to flush > the buffers and complete a clean unmounting. After reading my above Wiki page, I hope you consider disabling MatrixRAID and avoiding it entirely on FreeBSD. There are patches to address major issues which have been sitting untouched, despite patches included, for 2+ years. Draw your own conclusions. Also, you won't be able to kill -9 a process in that state. The kernel (or some piece of it) is hung, not the process. The fact that a reboot is required also does not surprise me. You *might* have been able to detach the ATA/SATA channel using atacontrol to get access to the system, but then again it might result in a system panic (see Wiki). > Both drives in the mirror have both survived a smartctl -t offline scan. This doesn't really mean anything; the SMART statistics, self-test log, and error log are what's more important. Chances are it's not a disk issue though... > Also, a previous time it was with ad12, so I strongly doubt it is the > drive. It seems like a geli partition is unable to handle a timeout > from a drive. The problem is not with geli(4), as I see it. > ad10: > Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family > Device Model: ST3160827AS > > ad12: > Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family > Device Model: ST3160827AS My experiences with disk timeouts on FreeBSD is that the OS does not handle it well at all, regardless of geli(4) being used or not. The entire system can deadlock, and in some cases panic (which for me is the more common result). I can't help myself here -- Linux's libata handles this much more elegantly. In the case of a failure similar to the above, there is a brief system deadlock and then full system recovery with EIO (I/O error) being returned to any process stuck in that state. There *is* data loss, but I don't think there's anything one can do about that (on Linux or FreeBSD); journalling filesystems should solve that aspect. -- | Jeremy Chadwick jdc 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 | From bu7cher at yandex.ru Wed Aug 6 04:15:09 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Wed Aug 6 04:15:17 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <48982B58.4000406@sebster.com> References: <48982B58.4000406@sebster.com> Message-ID: <48992532.9080503@yandex.ru> Sebastiaan van Erk wrote: > [/var/log/messages before the crash] > Aug 5 11:16:14 piglet kernel: > g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, > length=16384)]error = 6 > Aug 5 11:16:17 piglet last message repeated 9 times Can you show which messages where before these? -- WBR, Andrey V. Elsukov From andrew at modulus.org Wed Aug 6 04:18:12 2008 From: andrew at modulus.org (Andrew Snow) Date: Wed Aug 6 04:18:20 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <48992532.9080503@yandex.ru> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> Message-ID: <4899259D.2000106@modulus.org> I heartily recommend 3ware controllers for FreeBSD 6/7, even if you only need 2 ports. - Andrew From morgan.s.reed at gmail.com Wed Aug 6 04:36:40 2008 From: morgan.s.reed at gmail.com (Morgan Reed) Date: Wed Aug 6 04:36:47 2008 Subject: 5.x to 6.x or 7.x with 64MB / In-Reply-To: <49120.1217868483@thrush.ravenbrook.com> References: <49120.1217868483@thrush.ravenbrook.com> Message-ID: On Tue, Aug 5, 2008 at 2:48 AM, Nick Barnes wrote: > It occurs to me that if ad0s1a is insufficient then I could use ad0s1g > as swap, and repurpose ad0s1b as a new /. Is it straightforward to > installworld/mergemaster to somewhere other than / ? The DESTDIR directive will allow you to redirect your installworld to a different location, as for mergemaster IIRC this can be done (been a while since I was working on my embedded stuff that needed all this FreeBSD 6.something in about 8MB) but I can't remember what switches. It might be worth considering building /bin and /sbin dynamically (20oddMB to about 500kB), mind I can't remember where the required libs would be, if they're in /lib it'd be all good, if they're in /usr/lib you're stuck. All things considered I think your best option is to move / to a different partition. Should be relatively painless to do from a LiveCD, mount everything, duplicate / to somewhere else, modify fstab and the bootloader config, reboot. From sebastian.tymkow at gmail.com Wed Aug 6 07:03:16 2008 From: sebastian.tymkow at gmail.com (=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=) Date: Wed Aug 6 07:03:24 2008 Subject: Query timeouts on FreeBSD 7 over network In-Reply-To: <20080805122444.GB88406@eos.sc1.parodius.com> References: <15CEC87F00BB7B4CA0E904C5FCF05646243E8601@exchangenj1> <20080805122444.GB88406@eos.sc1.parodius.com> Message-ID: <692660060808052335v38eac379me6680103158e5e35@mail.gmail.com> Hi, I've got similar problem on FreeBSD 6.2 stable. I upgraded bind from 9.4 to 9.5 but it didn't help. Machine has load on level 30-45% CPU and 80%-130% WCPU. Similar machine with FreeBSD 4.x works fine with the same bind version. Best regards, Sebastian Tymkow From ericlin at tamama.org Wed Aug 6 07:13:22 2008 From: ericlin at tamama.org (Lin Jui-Nan Eric) Date: Wed Aug 6 07:13:31 2008 Subject: Max size of one swap slice In-Reply-To: References: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> Message-ID: <47713ee10808060013h10dd3f57ma5f45e69a322743a@mail.gmail.com> On Wed, Aug 6, 2008 at 12:46 AM, Chuck Swiger wrote: > It's hard to conceive of why you'd want to add so much swap space, anyway-- > if you've got programs which actually need to deal with 10s of gigabytes > worth of data, then they ought to maintain a smaller/reasonable-sized > working set in RAM and do disk I/O as needed themselves rather than depend > upon the VM pager, anyways. We are running varnish, and found that it is not stable while using mmap mode. We don't know whether if the problem is in the code of varnish or file system, but we found that if we run varnish using malloc mode with big swap, it became stable. Thank you all for the information, I'll try to look into the kernel code. From lists at groll.co.za Wed Aug 6 08:51:15 2008 From: lists at groll.co.za (Jonathan Groll) Date: Wed Aug 6 08:51:21 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <48982B58.4000406@sebster.com> References: <48982B58.4000406@sebster.com> Message-ID: <20080806082115.GB21896@groll.co.za> On Tue, Aug 05, 2008 at 12:28:40PM +0200, Sebastiaan van Erk wrote: > Hi, > > I'm running FreeBSD 6.3 (I know, I should upgrade), and I just bought an > add-on pci SATA controller for 2 extra SATA disks. > > However, a lot of disk activity on the drives will often cause the > machine to crash and spontaneously reboot. I checked out which chipset > was on the card with pciconf -lv and I found it was the Sil 3512. > Googling showed me that I'm not the only one with problems using this card. I can personally affirm that similar problems existed for me with a SiI 3114 under 7.0-STABLE, but have since moved the card into a Linux machine. Cheers, Jonathan. From ws at au.dyndns.ws Wed Aug 6 09:01:08 2008 From: ws at au.dyndns.ws (Wayne Sierke) Date: Wed Aug 6 09:01:15 2008 Subject: Fatal trap 12/TIMEOUT - READ_DMA (was Re: Stuck in geli) In-Reply-To: <20080806033016.GA35921@eos.sc1.parodius.com> References: <20080806033016.GA35921@eos.sc1.parodius.com> Message-ID: <1218012345.4383.106.camel@predator-ii.buffyverse> On Tue, 2008-08-05 at 20:30 -0700, Jeremy Chadwick wrote: > This looks like the issue I've been tracking for months now. I'm sorry > the document isn't complete; it's an issue of time... > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > My experiences with disk timeouts on FreeBSD is that the OS does not > handle it well at all, regardless of geli(4) being used or not. The > entire system can deadlock, and in some cases panic (which for me is > the more common result). > Recently I returned to my desktop system to find it had rebooted itself and found the following: # kgdb /boot/kernel/kernel /var/crash/vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". There is no member named pathname. Error while mapping shared library sections: rtc.ko: No such file or directory. Reading symbols from /boot/kernel/vesa.ko...Reading symbols from /boot/kernel/vesa.ko.symbols...done. done. Loaded symbols for /boot/kernel/vesa.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/green_saver.ko...Reading symbols from /boot/kernel/green_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/green_saver.ko Error while reading shared library symbols: rtc.ko: No such file or directory. Unread portion of the kernel message buffer: ad1: TIMEOUT - READ_DMA retrying (1 retry left) LBA=67332091 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc075ce24 stack pointer = 0x28:0xe52f1c04 frame pointer = 0x28:0xe52f1c1c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 18 (swi6: task queue) trap number = 12 panic: page fault cpuid = 0 Uptime: 1d11h41m37s Physical memory: 1519 MB Dumping 214 MB: 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc076a137 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc076a3f9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:572 #3 0xc0a71aec in trap_fatal (frame=0xe52f1bc4, eva=392) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a71d70 in trap_pfault (frame=0xe52f1bc4, usermode=0, eva=392) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a7271c in trap (frame=0xe52f1bc4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a584ab in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc075ce24 in _mtx_lock_sleep (m=0xc5abedcc, tid=3302165152, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:335 #8 0xc07693b6 in _sema_post (sema=0xc5abedcc, file=0x0, line=0) at /usr/src/sys/kern/kern_sema.c:79 #9 0xc050bd30 in ata_completed (context=0xc5abed80, dummy=1) at /usr/src/sys/dev/ata/ata-queue.c:481 #10 0xc079ce85 in taskqueue_run (queue=0xc4d21680) at /usr/src/sys/kern/subr_taskqueue.c:255 #11 0xc079d193 in taskqueue_swi_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:297 #12 0xc074acfb in ithread_loop (arg=0xc4d2a940) at /usr/src/sys/kern/kern_intr.c:1036 #13 0xc0747ad9 in fork_exit (callout=0xc074ab50 , arg=0xc4d2a940, frame=0xe52f1d38) at /usr/src/sys/kern/kern_fork.c:783 #14 0xc0a58520 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) This is the first time I've examined one of these DMA TIMEOUT events. I've probably seen a handful of these over the last few years, perhaps 2 to 4 per year. Unfortunately this system also occasionally faults from X-related hangs - or what I otherwise assume to be X-related. In any case I don't often get cores left behind that I've noticed. # atacontrol info ata0 Master: ad0 ATA/ATAPI revision 6 Slave: ad1 ATA/ATAPI revision 6 >From another system I have here (a VIA EPIA/?6.3-PRERELEASE) I can only find one TIMEOUT instance from the last 3 years, but with no discernible consequences. In fact that system has been rock-solid. It's a mail server, runs courier-imap, apache-1.3, samba, mysql and assorted other stuff, but is not heavily loaded. Jan 2 03:30:20 lillith-iv kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=3196031 # atacontrol info ata0 Master: ad0 ATA/ATAPI revision 6 Slave: ad1 ATA/ATAPI revision 6 Anyway, I don't know whether there's any significant or useful information in that vmcore. Perhaps someone could let me know? Wayne From gavin at FreeBSD.org Wed Aug 6 09:34:45 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Wed Aug 6 09:34:53 2008 Subject: DigiBoard Xem with 2 extenal modules In-Reply-To: <8e10486b0808040949ka12edf0o38e3a790d620992e@mail.gmail.com> References: <8e10486b0807030908i4c6f70bbp3f8e8907c7443259@mail.gmail.com> <1215105220.32135.18.camel@buffy.york.ac.uk> <8e10486b0807031041o54349836i31c5da84ebda70f6@mail.gmail.com> <1215176991.36376.24.camel@buffy.york.ac.uk> <8e10486b0807040834m27a38254k5261535d93d70ce6@mail.gmail.com> <8e10486b0808040949ka12edf0o38e3a790d620992e@mail.gmail.com> Message-ID: <1218015280.17311.11.camel@buffy.york.ac.uk> On Mon, 2008-08-04 at 13:49 -0300, Alexandre Biancalana wrote: > On 7/4/08, Alexandre Biancalana wrote: > > On 7/4/08, Gavin Atkinson wrote: > > > It's not a solution, but it may well be a great help in diagnosing where > > > the problem lies: it would be useful to know if the driver is simply > > > failing to detect the correct number of ports, or if the driver > > > physically cannot use them. > > > > > > In /usr/src/sys/dev/digi/digi.c, line 510, you'll see the following > > > code: > > > > > > if (sc->numports == 0) { > > > device_printf(sc->dev, "%s, 0 ports found\n", sc->name); > > > sc->hidewin(sc); > > > return (0); > > > } > > > > > > Just before that section, can you add a line "sc->numports = 32;", > > > recompile, and see if the missing 16 ports are usable? If they are, I > > > suspect fixing the driver will be trivial. > > > > > > Wow !! Now the 32 ports are detected and devices created. > > > > # digictl -d 1 -r /dev/digi0.ctl > > > > digi0: Got init reset after 0 us > > digi0: BIOS uploaded > > digi0: BIOS started after 0 us > > > > digi0: BIOS booted after 1619 iterations > > > > digi0: Loading FEP/OS > > digi0: FEP/OS loaded > > digi0: FEP/OS started after 28 iterations > > > > digi0: Digiboard PCI PC/Xem ASIC, 32 ports found > > > > # ls /dev/cuaD?? | wc -l > > 32 > > > > I will connect some modems to that ports to test and let you know. > > Modems connected but they only work on ports of the first module, any > decice connected on ports of second module does not work. > > Any other idea ? Sadly, I'm all out of ideas. If, with the change above, the ports were usable then it would have meant that the problem was around the code that configures the card and detects the number of ports. As the ports don't work even after forcing the number, it is possible that the driver simply does not support more than 16 ports at the moment. Unless you can get hold of a developer who knows the hardware (I've cc'd Brian as a possible person who fits this category), or are able to obtain the datasheets yourself, I think the only solution may be to compare the Linux driver to ours and see if it does anything differently during initialisation (especially before the code to detect the number of ports). Gavin From sebster at sebster.com Wed Aug 6 09:37:15 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Wed Aug 6 09:37:22 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <48992532.9080503@yandex.ru> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> Message-ID: <489970CC.4000103@sebster.com> Hi, Yes, good thing you pointed this out, I hadn't seen those yet: Aug 5 09:52:53 piglet ntpd[860]: kernel time sync enabled 2001 Aug 5 11:15:05 piglet kernel: rl1: watchdog timeout Aug 5 11:15:05 piglet kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=218885455 Aug 5 11:15:05 piglet kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=218885455 Aug 5 11:15:10 piglet kernel: rl1: watchdog timeout Aug 5 11:15:31 piglet kernel: rl1: watchdog timeout Aug 5 11:15:31 piglet kernel: ad6: FAILURE - device detached Aug 5 11:15:31 piglet kernel: subdisk6: detached Aug 5 11:15:31 piglet kernel: ad6: detached Aug 5 11:15:31 piglet kernel: rl1: watchdog timeout Aug 5 11:15:31 piglet kernel: rl1: watchdog timeout Aug 5 11:15:31 piglet kernel: ad4: FAILURE - device detached Aug 5 11:15:31 piglet kernel: subdisk4: detached Aug 5 11:15:31 piglet kernel: ad4: detached Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1: provider ad6 disconnected. Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1: provider ad4 disconnected. Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1: provider mirror/gm1 destroyed. Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1 destroyed. Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=112069312512, length=131072)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=112069443584, length=131072)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=112069574656, length=131072)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=112069705728, length=131072)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=112069836800, length=131072)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=112069967872, length=131072)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376121856, length=2048)]error = 6 Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)]error = 6 Aug 5 11:15:35 piglet last message repeated 13 times Regards, Sebastiaan Andrey V. Elsukov wrote: > Sebastiaan van Erk wrote: >> [/var/log/messages before the crash] >> Aug 5 11:16:14 piglet kernel: >> g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, >> length=16384)]error = 6 >> Aug 5 11:16:17 piglet last message repeated 9 times > > Can you show which messages where before these? > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080806/a86d5c4f/smime.bin From kometen at gmail.com Wed Aug 6 09:54:30 2008 From: kometen at gmail.com (Claus Guttesen) Date: Wed Aug 6 09:54:37 2008 Subject: zfs, raidz, spare and jbod In-Reply-To: References: Message-ID: > I installed FreeBSD 7 a few days ago and upgraded to the latest stable > release using GENERIC kernel. I also added these entries to > /boot/loader.conf: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > vfs.zfs.prefetch_disable=1 > > Initially prefetch was enabled and I would experience hangs but after > disabling prefetch copying large amounts of data would go along > without problems. To see if FreeBSD 8 (current) had better (copy) > performance I upgraded to current as of yesterday. After upgrading and > rebooting the server responded fine. > > The server is a supermicro with a quad-core harpertown e5405 with two > internal sata-drives and 8 GB of ram. I installed an areca arc-1680 > sas-controller and configured it in jbod-mode. I attached an external > sas-cabinet with 16 sas-disks at 1 TB (931 binary GB). > Replying to my own mail! :-) I believe I have found at least a work-around to alleviate this issue. First of all I upgraded to zfs ver. 11 by using Pawels patch. The upgrade itself does not solve any issue. Then I upgraded the firmware as advised by Areca-support. The firmware-upgrade has minor changes related to disk-temperature-reading and will probably not change anything either. I changed the configuration on each disk on the areca arc-1680-controller to passthrough-mode and rebooted. After re-creating the zpool I have not had any errors while copying 718 GB of small files from my solaris-nfs-server. I'm performing a local copy atm. and have 'zpool offline'd one disk and 'zpool replace'd with the spare. While the replace is in progress write-performance naturally takes a hit but the resilver-progress is progressing steadily and will use approx. 2 hours and 45 minutes in total to complete. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From sebster at sebster.com Wed Aug 6 09:56:55 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Wed Aug 6 09:57:06 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080806031751.GA33798@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <20080805121632.GA88406@eos.sc1.parodius.com> <48984BF1.60805@sebster.com> <20080805150301.GA94198@eos.sc1.parodius.com> <48988904.80509@sebster.com> <20080806031751.GA33798@eos.sc1.parodius.com> Message-ID: <48997565.3090307@sebster.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080806/c77be995/smime.bin From koitsu at FreeBSD.org Wed Aug 6 09:57:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 6 09:57:56 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <489970CC.4000103@sebster.com> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> Message-ID: <20080806095748.GA52551@eos.sc1.parodius.com> On Wed, Aug 06, 2008 at 11:37:16AM +0200, Sebastiaan van Erk wrote: > Yes, good thing you pointed this out, I hadn't seen those yet: > > Aug 5 11:15:05 piglet kernel: rl1: watchdog timeout > Aug 5 11:15:05 piglet kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=218885455 > Aug 5 11:15:05 piglet kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=218885455 > Aug 5 11:15:10 piglet kernel: rl1: watchdog timeout > Aug 5 11:15:31 piglet kernel: rl1: watchdog timeout > Aug 5 11:15:31 piglet kernel: ad6: FAILURE - device detached > Aug 5 11:15:31 piglet kernel: subdisk6: detached > Aug 5 11:15:31 piglet kernel: ad6: detached > Aug 5 11:15:31 piglet kernel: rl1: watchdog timeout > Aug 5 11:15:31 piglet kernel: rl1: watchdog timeout > Aug 5 11:15:31 piglet kernel: ad4: FAILURE - device detached > Aug 5 11:15:31 piglet kernel: subdisk4: detached > Aug 5 11:15:31 piglet kernel: ad4: detached > Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1: provider ad6 disconnected. > Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1: provider ad4 disconnected. > Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1: provider mirror/gm1 destroyed. > Aug 5 11:15:31 piglet kernel: GEOM_MIRROR: Device gm1 destroyed. > Aug 5 11:15:31 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)] error = 6 Kudos to Andrey for asking a simple yet incredibly benefitial question. You have a much greater problem here, and it doesn't look specific to your disks. It looks as if an interrupt is stalled or locked. I'm willing to bet your rl1 Realtek NIC and your ATA controller (associated with disks ad4 and ad6) use the same IRQ. vmstat -i output should help clear that up, or dmesg output. I'll tell you that there have been some watchdog timeout fixes committed to rl(4) in recent months, depending upon what specific model and revision of Realtek NIC you have. No offence intended, but Realtek is definitely the worst of the bunch. I'm willing to bet it's an on-board NIC too. :-) I'm CC'ing PYUN Yong-Hyeon here, as he presently maintains/works on the rl(4) driver, and might be able to help determine if the Realtek NIC is what's causing all of this, or if the ATA chipset (is this the VIA? We don't know yet) is causing it first. Finally, what motherboard brand and model is this, and what BIOS revision or version? -- | Jeremy Chadwick jdc 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 | From sebster at sebster.com Wed Aug 6 10:11:04 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Wed Aug 6 10:11:11 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080806095748.GA52551@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> Message-ID: <489978B9.5080405@sebster.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080806/12815f7d/smime.bin From sebster at sebster.com Wed Aug 6 10:11:51 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Wed Aug 6 10:11:58 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <489978B9.5080405@sebster.com> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <489978B9.5080405@sebster.com> Message-ID: <489978E8.4090804@sebster.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080806/5d30157e/smime.bin From koitsu at FreeBSD.org Wed Aug 6 10:19:42 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 6 10:19:49 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080806095748.GA52551@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> Message-ID: <20080806101941.GA52952@eos.sc1.parodius.com> On Wed, Aug 06, 2008 at 02:57:48AM -0700, Jeremy Chadwick wrote: > vmstat -i output should help clear that up, or dmesg output. Sebastiaan has included vmstat -i output in another part of this thread, as well as dmesg output for the ATA disks and controllers: atapci0: port 0xd200-0xd207,0xd300-0xd303,0xd400-0xd407,0xd500-0xd503,0xd600-0xd60f mem 0xf6081000-0xf60811ff irq 18 at device 10.0 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0xd700-0xd707,0xd800-0xd803,0xd900-0xd907,0xda00-0xda03,0xdb00-0xdb0f,0xdc00-0xdcff irq 20 at device 15.0 on pci0 ata4: on atapci1 ata5: on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xdd00-0xdd0f at device 15.1 on pci0 ata0: on atapci2 ata1: on atapci2 ad0: 286188MB at ata0-master UDMA133 ad1: 239372MB at ata0-slave UDMA133 acd0: DVDR at ata1-master UDMA33 ad4: 953869MB at ata2-master SATA150 ad6: 953869MB at ata3-master SATA150 ad8: 239372MB at ata4-master SATA150 ad10: 239372MB at ata5-master SATA150 interrupt total rate irq6: fdc0 10 0 irq14: ata0 645057 7 irq15: ata1 58 0 irq16: rl0 7168276 82 irq17: rl1 914667 10 irq18: atapci0 30072876 347 irq20: atapci1 1126099 12 irq21: uhci0 uhci* 308 0 irq23: vr0 3265771 37 cpu0: timer 173289011 1999 Total 216482133 2498 Here's a breakdown, so no one gets confused: ad0 = 300GB Maxtor disk, attached to on-board VIA IDE controller ad1 = 250GB Maxtor disk, attached to on-board VIA IDE controller ad4 = 1TB Samsung disk, attached to Silicon Image SATA controller ad6 = 1TB Samsung disk, attached to Silicon Image SATA controller ad8 = 250GB Maxtor disk, attached to on-board VIA SATA controller ad10 = 250GB Maxtor disk, attached to on-board VIA SATA controller IRQ 14 -- atapci2 = On-board VIA IDE controller (primary) IRQ 15 -- atapci2 = On-board VIA IDE controller (slave) IRQ 16 -- rl0 = Realtek NIC IRQ 17 -- rl1 = Realtek NIC IRQ 18 -- atapci0 = Silicon Image SATA controller IRQ 20 -- atapci1 = On-board VIA SATA controller An APIC is obviously in use here. The problem reported is with disks ad4 and ad6, residing on the Silicon Image controller. When the problem happens, rl1 emits watchdog timeouts, and disks ad4 and ad6 fall off the bus. SMART statistics on both ad4 and ad6 show no signs of the disks being power-cycled, sector errors, or anything that would indicate either disk is bad. His PSU is 450W, brand unknown. Sebastiaan, do you know if the BIOS on this system has a Health monitor, showing voltages and temperatures of things? If so, can you reboot the system, go into that part of the BIOS, and write down (or take a photo) of the voltages/temperatures? I'm wondering if maybe one of the voltages is too low or high, or fluxuates severely with so many devices. It could be enough to cause some of the ASICs to malfunction, possibly multiples... I cleared the possibility of this being a PSU problem, but that was before I knew you were seeing watchdog timeouts on one of your NICs at the *exact same time* as disks off the Silicon Image controller. -- | Jeremy Chadwick jdc 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 | From scf at FreeBSD.org Wed Aug 6 14:24:23 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Wed Aug 6 14:24:32 2008 Subject: Stuck in geli In-Reply-To: <20080806033016.GA35921@eos.sc1.parodius.com> References: <20080806033016.GA35921@eos.sc1.parodius.com> Message-ID: On Tue, 5 Aug 2008, Jeremy Chadwick wrote: > On Tue, Aug 05, 2008 at 10:45:16AM -0500, Sean C. Farley wrote: >> Rarely, a geli partition I have freezes a process in bufwait state. >> It occurs after an ATA timeout message: >> Aug 5 03:47:13 thor kernel: ad10: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=219028637 > > This looks like the issue I've been tracking for months now. I'm sorry > the document isn't complete; it's an issue of time... > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting Time grows on the tree next to my money tree. :) I understand. >> The geli partition resides on an Intel MatrixRAID RAID1 mirror using >> the ICH9R chipset (Asus P5K-E/WIFI). Killing (even -9) the process >> does not work. Rebooting is the only solution, yet the system is >> unable to flush the buffers and complete a clean unmounting. > > After reading my above Wiki page, I hope you consider disabling > MatrixRAID and avoiding it entirely on FreeBSD. There are patches to > address major issues which have been sitting untouched, despite > patches included, for 2+ years. Draw your own conclusions. Yuck. I used the on-board "RAID", so the system could dual-boot Windows XP and FreeBSD. Is there any way to use gmirror to mirror the entire disk with XP on one slice and FreeBSD on another? ;) OK. I think I know that answer. Does XP have software RAID1? I can setup XP on one slice and gmirror on another. Is mirroring a slice any easier today? I followed information from the following links to do this before on my server: http://lists.freebsd.org/pipermail/freebsd-stable/2005-February/011699.html I forget. MatrixRAID does not destroy any data if RAID1 is disabled. Correct? > Also, you won't be able to kill -9 a process in that state. The > kernel (or some piece of it) is hung, not the process. The fact that > a reboot is required also does not surprise me. > > You *might* have been able to detach the ATA/SATA channel using > atacontrol to get access to the system, but then again it might result > in a system panic (see Wiki). I did not feel safe even without a possible panic to detach the channels and attach them again. Would I not suffer data loss with everything mounted? *snip* Sean -- scf@FreeBSD.org From andy at xecu.net Wed Aug 6 14:35:53 2008 From: andy at xecu.net (Andy Dills) Date: Wed Aug 6 14:36:00 2008 Subject: PPP doesn't set the correct interface in 7-STABLE Message-ID: <20080806101147.Y50885@shell.xecu.net> I'm trying to setup pptpd to enable VPN connections. This worked well in all versions of FreeBSD prior to 7. Now, however, the interface in the routing table is incorrectly set to that of the ethernet card, rather than the appropriate tun interface. There is a months-old bug report detailing this: http://www.freebsd.org/cgi/query-pr.cgi?pr=122068&cat= He mentions two workarounds: there are two way to fix it. 1. use differenet subnet for vpn. Don't use the same subnet for vpn routing. user-ppp will set the correct routing table. 2. downgrade to FreeBSD 6.2 #2 isn't really an option, and #1 isn't clear to me. I tried a couple of different configurations and the interface never seems to get set correctly. Suggestions? Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- From adrian at freebsd.org Wed Aug 6 15:16:35 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Wed Aug 6 15:16:42 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: <1217778109.953.23.camel@RabbitsDen> References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <1217778109.953.23.camel@RabbitsDen> Message-ID: 2008/8/3 Alexandre Sunny Kovalenko : > Tcl? Are those sizes stripped? Stripped: * lua-5.1 is 134k * liblua.so.1 is 148k * haserl (using liblua) is 79k * lua cgi, lua socket, sqlite3 (dynlinked to libsqlite3.so.8), ltn12, md5, mime - all up, 450k I'm pretty impressed with lua thus far. All thats needed is some lightweight and sensible cgi code that doesn't expect the kepler project framework to be installed and you're set. I haven't yet sat down and stared much at haserl internals but it provides the CGI runtime environment which cgilua actually doesn't (gah!) and provides the very basic bits needed to handle GET/POST/uploads. 2c, Adrian From gaijin.k at gmail.com Wed Aug 6 15:26:26 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Wed Aug 6 15:26:34 2008 Subject: busybox and small scripting languages on FreeBSD ? (was Re: 80 Mb / enough for 7.x? OK to delete /stand/ and /modules/ ?) In-Reply-To: References: <372128.56919.qm@web51502.mail.re2.yahoo.com> <20080802.002039.58462077.imp@bsdimp.com> <4894A9D8.2090606@freebsd.org> <20080802225643.GA84798@onelab2.iet.unipi.it> <1217778109.953.23.camel@RabbitsDen> Message-ID: <1218036370.1202.8.camel@RabbitsDen> On Wed, 2008-08-06 at 22:51 +0800, Adrian Chadd wrote: > 2008/8/3 Alexandre Sunny Kovalenko : > > Tcl? > > Are those sizes stripped? No. They are also from Tcl 8.5 and are *much* larger than that of 8.4. Here is statically built, stripped tclsh8.4: # ls -lh tclsh -rwxr-xr-x 1 sunny wheel 651K Aug 6 11:18 tclsh # ldd tclsh tclsh: libm.so.5 => /lib/libm.so.5 (0x28118000) libc.so.7 => /lib/libc.so.7 (0x2812d000) In my case, main attraction of Tcl was the ability to build it (statically if needed) into the application. Additional benefit being that with some malice and forethought you can use your application as the generic Tcl interpreter when you need one ;) -- Alexandre "Sunny" Kovalenko (????????? ?????????) From koitsu at FreeBSD.org Wed Aug 6 15:28:15 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 6 15:28:22 2008 Subject: Stuck in geli In-Reply-To: References: <20080806033016.GA35921@eos.sc1.parodius.com> Message-ID: <20080806152814.GA65023@eos.sc1.parodius.com> On Wed, Aug 06, 2008 at 09:24:20AM -0500, Sean C. Farley wrote: > On Tue, 5 Aug 2008, Jeremy Chadwick wrote: >> After reading my above Wiki page, I hope you consider disabling >> MatrixRAID and avoiding it entirely on FreeBSD. There are patches to >> address major issues which have been sitting untouched, despite >> patches included, for 2+ years. Draw your own conclusions. > > Yuck. > > I used the on-board "RAID", so the system could dual-boot Windows XP and > FreeBSD. > > Is there any way to use gmirror to mirror the entire disk with XP on one > slice and FreeBSD on another? ;) OK. I think I know that answer. > Does XP have software RAID1? I can setup XP on one slice and gmirror on > another. It seems unlikely that XP would natively have a form of software RAID-1 since it's deemed a desktop system, while the Server products (e.g. 2003 and 2008) probably do. A multi-OS-friendly solution might be to pick up a cheap Promise RAID controller and use that, since drivers are available for Windows XP and the card works without hitches on FreeBSD (just install FreeBSD on the ar0 device, voila). Keep in mind that I haven't tested a failure scenario on those Promise cards (e.g. 2 disks in a RAID1 config, pull the disk FreeBSD booted off of while the OS is up and see what happens), but I can if someone is curious. I'd really like to see those Intel MatrixRAID bugs addressed. It's available on many server-class boxes (hello Supermicro), and it's *incredibly* useful for admins with 2-disk servers that want a form of failover in the case one of the disks dies -- and want that form of failover nearly transparent to the underlying OS (most of us want this because we don't want to deal with the "oh look, FreeBSD doesn't know how to boot off this" situation). Some Supermicro boxes even let you pick between using Intel MatrixRAID or Adaptec HostRAID, via a BIOS option (yes really!). FreeBSD has bugs with MatrixRAID, and doesn't appear to support HostRAID at all. > Is mirroring a slice any easier today? I followed information from the > following links to do this before on my server: > http://lists.freebsd.org/pipermail/freebsd-stable/2005-February/011699.html Not sure, I've not any experience with gmirror. > I forget. MatrixRAID does not destroy any data if RAID1 is disabled. > Correct? I remember playing with MatrixRAID on one of our PDSMi+ boxes. After I encountered aforementioned FreeBSD issues with MatrixRAID, I went into the MatrixRAID BIOS and chose to delete the array. If I remember right, I was asked if while deleting the array I wanted to "delete the data". The question was phrased in such a way which made me wonder, "are they talking about the MatrixRAID metadata, or do they mean wiping the first 512 bytes of each disk?" The ambiguity of the question and the way the on-screen details were written made me unsure how to answer it. I believe I chose "No" regardless. When FreeBSD booted (off of one of the two disks), the bootloader worked but claimed it couldn't find any filesystems. Now, I'm not sure if that's expected (maybe the C/H/S data looks different under MatrixRAID than without? I don't know). The best answer to your question would be: "back everything you have up before doing it". Not the answer you want to hear, I'm sure, but it's the safe one. >> Also, you won't be able to kill -9 a process in that state. The >> kernel (or some piece of it) is hung, not the process. The fact that >> a reboot is required also does not surprise me. >> >> You *might* have been able to detach the ATA/SATA channel using >> atacontrol to get access to the system, but then again it might result >> in a system panic (see Wiki). > > I did not feel safe even without a possible panic to detach the channels > and attach them again. Would I not suffer data loss with everything > mounted? With MatrixRAID? Oh yes, definitely, and probably worse than if you weren't using it. Without MatrixRAID? Also definitely, but hopefully fsck would fix the problems. Take a look at PR 108924, specifically my step-by-step comments. I detach a channel (done automatically by yanking the disk; FreeBSD at least knows when to detach the channel on its own) with filesystems mounted via ar0. The outcome is not pretty. Ideally, if you did "atacontrol detach ata0" OR if the disk fell off the bus, the array should go into degraded mode. There should be no data loss, because even though you just lost ata0 (ad0), you still have ata1 (ad1). Ideally, you would address the problem, then do "atacontrol attach ata0". The array would start rebuilding, then eventually be fine. But consider what happens when the kernel panics upon reattach -- you've just guaranteed data loss on the other disk in the mirror, and you've probably just horked whatever data was possibly written to the disk you just reattached (looking at it from a MatrixRAID BIOS perspective, since I have a feeling it does some stuff on its own). And then, making matters even worse, consider PR 102210 -- since a kernel panic induces a reboot....... Now I'm sure you see how severe this situation is. This is the exact sort of situation people try to avoid by using RAID-1, yet by using it, they're taking the exact risks they're trying to avoid. Quite ironic, isn't it. -- | Jeremy Chadwick jdc 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 | From andrewd at webzone.net.au Wed Aug 6 15:44:24 2008 From: andrewd at webzone.net.au (Andrew D) Date: Wed Aug 6 15:44:37 2008 Subject: PPP doesn't set the correct interface in 7-STABLE In-Reply-To: <20080806101147.Y50885@shell.xecu.net> References: <20080806101147.Y50885@shell.xecu.net> Message-ID: <4899C430.1030004@webzone.net.au> Sorry I should add, in the second 'for' it should start with 0 if you're not using the first interface for another vpn (ie openvpn) or connection (ie dsl/dialup). Andy Dills wrote: > I'm trying to setup pptpd to enable VPN connections. This worked well in > all versions of FreeBSD prior to 7. > > Now, however, the interface in the routing table is incorrectly set to > that of the ethernet card, rather than the appropriate tun interface. > > There is a months-old bug report detailing this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=122068&cat= > > He mentions two workarounds: > > there are two way to fix it. > 1. use differenet subnet for vpn. Don't use the same subnet for vpn > routing. user-ppp will set the correct routing table. > 2. downgrade to FreeBSD 6.2 > > #2 isn't really an option, and #1 isn't clear to me. I tried a couple of > different configurations and the interface never seems to get set > correctly. > I have a similar problem on one server that I manage. I run the following script every 30 secs. not exactly elegant, but does the job. #!/usr/local/bin/bash LNET='10.10' # local network DEFIP='254' # default gateway ip INT='fxp0' # interface for i in `/usr/bin/netstat -nr |grep $INT |awk '{print $1}'|grep $LNET|grep -v $DEFIP|grep -v '/'`; do /sbin/route delete $i done for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do IP=`ifconfig tun$i 2>/dev/null|grep inet|head -n 2 |tail -n 1|awk '{print $4}'` if [ -n "$IP" ];then RO=`netstat -nr | grep $IP |grep tun$i` if [ -z "$RO" ]; then /sbin/route add $IP -iface tun$i fi fi done HTH cya Andrew > > Suggestions? > > Thanks, > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From andrewd at webzone.net.au Wed Aug 6 15:44:25 2008 From: andrewd at webzone.net.au (Andrew D) Date: Wed Aug 6 15:44:38 2008 Subject: PPP doesn't set the correct interface in 7-STABLE In-Reply-To: <20080806101147.Y50885@shell.xecu.net> References: <20080806101147.Y50885@shell.xecu.net> Message-ID: <4899C303.50708@webzone.net.au> Andy Dills wrote: > I'm trying to setup pptpd to enable VPN connections. This worked well in > all versions of FreeBSD prior to 7. > > Now, however, the interface in the routing table is incorrectly set to > that of the ethernet card, rather than the appropriate tun interface. > > There is a months-old bug report detailing this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=122068&cat= > > He mentions two workarounds: > > there are two way to fix it. > 1. use differenet subnet for vpn. Don't use the same subnet for vpn > routing. user-ppp will set the correct routing table. > 2. downgrade to FreeBSD 6.2 > > #2 isn't really an option, and #1 isn't clear to me. I tried a couple of > different configurations and the interface never seems to get set > correctly. > I have a similar problem on one server that I manage. I run the following script every 30 secs. not exactly elegant, but does the job. #!/usr/local/bin/bash LNET='10.10' # local network DEFIP='254' # default gateway ip INT='fxp0' # interface for i in `/usr/bin/netstat -nr |grep $INT |awk '{print $1}'|grep $LNET|grep -v $DEFIP|grep -v '/'`; do /sbin/route delete $i done for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do IP=`ifconfig tun$i 2>/dev/null|grep inet|head -n 2 |tail -n 1|awk '{print $4}'` if [ -n "$IP" ];then RO=`netstat -nr | grep $IP |grep tun$i` if [ -z "$RO" ]; then /sbin/route add $IP -iface tun$i fi fi done HTH cya Andrew > > Suggestions? > > Thanks, > Andy > > --- > Andy Dills > Xecunet, Inc. > www.xecu.net > 301-682-9972 > --- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From mike at sentex.net Wed Aug 6 15:54:38 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Aug 6 15:54:46 2008 Subject: PPP doesn't set the correct interface in 7-STABLE In-Reply-To: <20080806101147.Y50885@shell.xecu.net> References: <20080806101147.Y50885@shell.xecu.net> Message-ID: <200808061554.m76FsZlm092227@lava.sentex.ca> At 10:16 AM 8/6/2008, Andy Dills wrote: >I'm trying to setup pptpd to enable VPN connections. This worked well in >all versions of FreeBSD prior to 7. I would turf pptpd and look at mpd51 from the ports. It is far, far better maintained and is quite solid as an LNS as well as PPTP termination server. ---Mike From alex.kovalenko at verizon.net Wed Aug 6 16:23:54 2008 From: alex.kovalenko at verizon.net (Alexandre "Sunny" Kovalenko) Date: Wed Aug 6 16:24:01 2008 Subject: Should PCCARDs (as in not CardBus cards) work on RELENG_7? Message-ID: <1218039623.1202.28.camel@RabbitsDen> For all the odd reasons I needed to use PCCARD device with my RELENG_7 machine. Upon insertion I have got the message "Card has no function" (full message with hw.pcccard.debug=1 and hw.pccard.cis_debug=1 is below). This behaves similarly with two memory card readers, 3CXM556 modem, 802.11b adapter (Prism?) and IBM EtherJet (log below is from the last one). CardBus cards (couple of the FireWire and couple of 802.11g adapters) are detected and work just fine. The bridge is: cbb0@pci0:21:0:0: class=0x060700 card=0x201c17aa chip=0x04761180 rev=0xb4 hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh R/RL/5C476(II)' class = bridge subclass = PCI-CardBus The system is RELENG_7 as of July 30th. Devices cardbus, cbb and pccard are built into the kernel. The question is: should these work, and if yes, how do I troubleshoot it further? I could have FireWire console hooked up to this laptop (without occupying CB slot), so I can do some debugging. Conversely, I can ship any of the cards, listed above to the interested developer. Any pointers or suggestions will be appreciated. ================ Message, produced upon card insertion ================= Aug 6 12:01:36 RabbitsDen kernel: pccard0: chip_socket_enable Aug 6 12:01:36 RabbitsDen kernel: pccard0: read_cis Aug 6 12:01:37 RabbitsDen kernel: cis mem map 0xe8c57000 (resource: 0xbf6d0000) Aug 6 12:01:37 RabbitsDen kernel: pccard0: CIS tuple chain: Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_NONE Aug 6 12:01:37 RabbitsDen kernel: 00 Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen kernel: TOO MANY CIS_NONE Aug 6 12:01:37 RabbitsDen kernel: unhandled CISTPL 0 Aug 6 12:01:37 RabbitsDen last message repeated 2021 times Aug 6 12:01:37 RabbitsDen kernel: CIS is too long -- truncating Aug 6 12:01:37 RabbitsDen kernel: CISTPL_END Aug 6 12:01:37 RabbitsDen kernel: ff Aug 6 12:01:37 RabbitsDen kernel: cis mem map e8c57000 Aug 6 12:01:37 RabbitsDen kernel: CISTPL_LINKTARGET expected, code 00 observed Aug 6 12:01:37 RabbitsDen kernel: pccard0: check_cis_quirks Aug 6 12:01:37 RabbitsDen kernel: pccard0: Card has no functions! Aug 6 12:01:37 RabbitsDen kernel: cbb0: PC Card card activation failed -- Alexandre "Sunny" Kovalenko (????????? ?????????) From baigsabeeh at gmail.com Wed Aug 6 17:06:28 2008 From: baigsabeeh at gmail.com (Sabeeh Baig) Date: Wed Aug 6 17:06:34 2008 Subject: Status of Linuxulator 2.6.16 Message-ID: What's the status of Linuxulator 2.6.16? I believe FreeBSD 7 still uses the older 2.4 version and the 2.6.16 support has to be explicitly enabled. I was hoping to check out Flash 9 via ports. Sabeeh Ahmed Baig From besko at msu.edu Wed Aug 6 18:03:16 2008 From: besko at msu.edu (Lisa Besko) Date: Wed Aug 6 18:03:23 2008 Subject: Swapping boot disks and getting mountroot> Message-ID: <4899E3AC.40201@msu.edu> I have a system running FBSD 6.2 release (if I remember correctly) that is running on a Sunfire X2100. The disk boots fine there and I seem to be able to move it to other X2100's. The problem is that I need to move it to a Sunfire X2200. When I move it to the X2200 I get a mountroot> prompt and the keyboard freezes up. I notice that it finds the device ad4 but then it tries to mount root from /dev/ad6s1a. I've edited the fstab to have it look for ad4s1a but it still won't boot. Anyone have any pointers or ideas? Thanks, Lisa B. From kris at FreeBSD.org Wed Aug 6 18:59:44 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Aug 6 18:59:51 2008 Subject: Max size of one swap slice In-Reply-To: <47713ee10808060013h10dd3f57ma5f45e69a322743a@mail.gmail.com> References: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> <47713ee10808060013h10dd3f57ma5f45e69a322743a@mail.gmail.com> Message-ID: <4899F49C.1000609@FreeBSD.org> Lin Jui-Nan Eric wrote: > On Wed, Aug 6, 2008 at 12:46 AM, Chuck Swiger wrote: >> It's hard to conceive of why you'd want to add so much swap space, anyway-- >> if you've got programs which actually need to deal with 10s of gigabytes >> worth of data, then they ought to maintain a smaller/reasonable-sized >> working set in RAM and do disk I/O as needed themselves rather than depend >> upon the VM pager, anyways. > We are running varnish, and found that it is not stable while using mmap mode. > We don't know whether if the problem is in the code of varnish or file > system, but > we found that if we run varnish using malloc mode with big swap, it > became stable. > > Thank you all for the information, I'll try to look into the kernel code. See http://www.freebsd.org/cgi/getmsg.cgi?fetch=540837+0+/usr/local/www/db/text/2008/freebsd-questions/20080706.freebsd-questions Kris From uspoerlein at gmail.com Wed Aug 6 20:12:42 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Wed Aug 6 20:12:55 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <200808041607.56160.jhb@freebsd.org> References: <20080730113449.GD407@cdnetworks.co.kr> <20080804010205.GA21401@cdnetworks.co.kr> <20080804182919.GB1480@roadrunner.spoerlein.net> <200808041607.56160.jhb@freebsd.org> Message-ID: <20080806200643.GA1554@roadrunner.spoerlein.net> On Mon, 04.08.2008 at 16:07:55 -0400, John Baldwin wrote: > On Monday 04 August 2008 02:29:19 pm Ulrich Spoerlein wrote: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x38 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc058ec16 > > stack pointer = 0x28:0xfb8b8ac8 > > frame pointer = 0x28:0xfb8b8ac8 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 1176 (powerd) > > db:0:kdb.enter.default> show pcpu > > cpuid = 0 > > curthread = 0xc4ec0aa0: pid 1176 "powerd" > > curpcb = 0xfb8b8d90 > > fpcurthread = none > > idlethread = 0xc3f80cc0: pid 10 "idle: cpu0" > > APIC ID = 0 > > currentldt = 0x50 > > db:0:kdb.enter.default> bt > > Tracing pid 1176 tid 100103 td 0xc4ec0aa0 > > device_is_attached(0,c87e6b40,fb8b8afc,0,101,...) at device_is_attached+0x6 > > cf_set_method(c420b600,c87e6b40,64,fb8b8ba4,c87e33b4,...) at > cf_set_method+0x6a3 > > cpufreq_curr_sysctl(c420d840,c4207000,0,fb8b8ba4,fb8b8ba4,...) at > cpufreq_curr_sysctl+0x232 > > sysctl_root(fb8b8ba4,4,1,c4ec0aa0,c4501d38,...) at sysctl_root+0x137 > > userland_sysctl(c4ec0aa0,fb8b8c14,4,0,0,...) at userland_sysctl+0x151 > > __sysctl(c4ec0aa0,fb8b8cfc,18,fb8b8ca0,46,...) at __sysctl+0xec > > syscall(fb8b8d38) at syscall+0x345 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28161bd3, esp = > 0xbfbfe8cc, ebp = 0xbfbfe8f8 --- > > db:0:kdb.enter.default> capture off > > > > Seems like I caught RELENG_7 during a bad time. Will update again. > > What cpufreq drivers do you have loaded and attached? This patch might work > around the issue, but I suspect there is a bug in one of the cpufreq drivers. Hi John, sorry for the slow update, please bear with me. This is on a first generation Pentium-M (Banias core) with EST (and also p4tcc attached, as I just discovered): CPU: Intel(R) Pentium(R) M processor 1.50GHz (1495.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf Features2=0x180 .. cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 300 dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% dev.acpi_perf.0.%parent: cpu0 dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.%driver: est dev.est.0.%parent: cpu0 dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 a kernel from 2008-06-13 is the last known working one. I just had the same crash with a kernel from sources at 2008-07-01 and am new recompiling for 2008-06-24. Your MFC of est.c rev 180044 might be the problem, I'll try a backout once I confirmed that the 2008-06-24 kernel is running stable. > Index: kern_cpu.c > =================================================================== > RCS file: /usr/cvs/src/sys/kern/kern_cpu.c,v > retrieving revision 1.27.2.2 > diff -u -r1.27.2.2 kern_cpu.c > --- kern_cpu.c 9 May 2008 19:02:10 -0000 1.27.2.2 > +++ kern_cpu.c 4 Aug 2008 20:07:41 -0000 > @@ -329,6 +329,8 @@ > /* Next, set any/all relative frequencies via their drivers. */ > for (i = 0; i < level->rel_count; i++) { > set = &level->rel_set[i]; > + if (set->dev == NULL) > + continue; > if (!device_is_attached(set->dev)) { > error = ENXIO; > goto out; > Will try that one too, hopefully tomorrow. Will also disable p4tcc. This was not attaching during the RELENG_6 times but leads to ridiculous rates of 75 MHz. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From uspoerlein at gmail.com Wed Aug 6 20:12:42 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Wed Aug 6 20:12:56 2008 Subject: What is cryptosoft0? Message-ID: <20080806201144.GB1554@roadrunner.spoerlein.net> Hi, today I discovered the following dmesg line on my laptop: cryptosoft0: on motherboard and I've not seen this one before, so: what is cryptosoft and should I care? I could imagine it's a pseudo-device by crypto(9) so the API is the same whether crypto hardware is installed or not. Anyway, I think a manpage link/update would be in order: % man -k cryptosoft cryptosoft: nothing appropriate Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From dillon at apollo.backplane.com Wed Aug 6 20:24:08 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Wed Aug 6 20:24:15 2008 Subject: Max size of one swap slice References: <47713ee10808050839k5b258831x66bc52f70b2c355b@mail.gmail.com> <47713ee10808060013h10dd3f57ma5f45e69a322743a@mail.gmail.com> <4899F49C.1000609@FreeBSD.org> Message-ID: <200808062012.m76KCmaZ042748@apollo.backplane.com> : :See : :http://www.freebsd.org/cgi/getmsg.cgi?fetch=540837+0+/usr/local/www/db/text/2008/freebsd-questions/20080706.freebsd-questions : :Kris Hmm. I see an issue that FreeBSD could correct to reduce wired memory use by the swap system. Your sys/blist.h has this: typedef u_int32_t u_daddr_t; /* unsigned disk address */ and your sys/types.h has this: typedef int64_t daddr_t; /* unsigned disk address */ sys/blist.h really assumes a 32 bit daddr_t. It's amazing the code even still works with daddr_t at 64 bits and u_daddr_t at 32 bits. Changing that whole mess in sys/blist.h to a different typedef name, say swblk_t (which is already defined to be 32 bits), and renaming u_daddr_t to u_swblk_t, plus also changing the swblock structure in vm/swap_pager.c to use a 32 bit array elements instead of 64 bit array elements will cut the size of struct swblock almost in half. There is no real need for swap block addressing > 32 bits. 32 bits gives you swap in the terrabyte range. struct swblock { struct swblock *swb_hnext; vm_object_t swb_object; vm_pindex_t swb_index; int swb_count; daddr_t swb_pages[SWAP_META_PAGES]; <<<<<<<<< this array }; Any arithmatic accessing the elements would also have to be vetted for any necessary promotions. -Matt Matthew Dillon From info at tecodryer.com Wed Aug 6 21:41:56 2008 From: info at tecodryer.com (TECO DRYER) Date: Wed Aug 6 21:42:23 2008 Subject: Teco Industry is in the business of corn, wheat, paddy, and Message-ID: <20080806214156.044A48FC08@mx1.freebsd.org> vegetable dr Sender: "TECO DRYER" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 7 Aug 2008 00:12:28 +0300 Message-ID: <20080806211228210.5B7A1D7470EC39A0@erkan-e90bf8060> X-Priority: 3 (Normal) Importance: Normal Teco Industry is in the business of corn, wheat, paddy, and vegetable drying machines and the production and marketing of silo & steel construction. Related to the machines that our company produce; Teco Industry has the representatives in Bulgaria, Albania, Ukraine, Tatarstan, Kazakhstan, Russia, Angola and Indonesia. Our partners in these countries are accepted as the leaders in the steel industry. The quality of produced machines is approved by international standards. Teco is guaranteed by CE and ISO 9001-2000 certificates. Teco also contributes to the national economy by creating jobs in designing, project, production, import and export. Teco materializes R&D activities with its professional staff. Quality results are presented to the customers during the production, import and export. Our company takes the leadership of producing and marketing nationally and internationally. For Grain, Oily Seeds, and Pulses: Silos Corn and Soybean Drying Machines Handling Systems like Bucket Elevator, Chain Conveyor and Helix Prop Towers and Catwalks for Handling Systems Unloading Truck Lifts Industrial Foundations, Steel Construction With the expert staff; we take an important target like ‘’Customer Satisfaction and Service Quality’’ and perform service and counseling duties successfully. -------------------------------------------------------------------------------- Contact Us , Teco Dryer Company is ready for a long partnership with you. Sales Engineer Erkan AYMAN eayman@tecodryer.com From kamuzon at milshop.ru Wed Aug 6 21:50:43 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Wed Aug 6 21:50:50 2008 Subject: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped) Message-ID: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> Hello. Dont know is this list right for this topic, but dont know witch one is. So I got 6.3-STABLE-200807-amd64-disc1.iso I have installed it cd /usr/ports/net/cvsup-without-gui/ make install make clean #cvsup some-stable-sup-file Connected to cvsup.xxxxxx.ru Bus error (core dumped) I cant get fresh src and ports trees and cant compile fresh 6.X-stable system with athlon64 optimization. :( How to fix cvsup? How to keep src-tree of 6.x-stable up-to-date without working cvsup? How to keep ports-tree up-to-date without working cvsup? PS I manage about 10 servers under 6.x-stable and cvsup under 6.3-stable is very important for me. Pls help. From kris at FreeBSD.org Wed Aug 6 21:55:51 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Aug 6 21:55:58 2008 Subject: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped) In-Reply-To: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> References: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> Message-ID: <489A1DE2.1020303@FreeBSD.org> Eugene Kazarinov wrote: > Hello. > Dont know is this list right for this topic, but dont know witch one is. > So > > I got 6.3-STABLE-200807-amd64-disc1.iso > I have installed it > cd /usr/ports/net/cvsup-without-gui/ > make install > make clean > > #cvsup some-stable-sup-file > Connected to cvsup.xxxxxx.ru > Bus error (core dumped) > > I cant get fresh src and ports trees and cant compile fresh 6.X-stable > system with athlon64 optimization. :( > > > How to fix cvsup? > How to keep src-tree of 6.x-stable up-to-date without working cvsup? > How to keep ports-tree up-to-date without working cvsup? > > > PS I manage about 10 servers under 6.x-stable and cvsup under 6.3-stable is > very important for me. > Pls help. This problem has been reported a couple of times but it is not clear what change caused it. Someone needs to do a binary search of the kernel source changes to work out when it started, then we can determine how to fix it. Kris From kamuzon at milshop.ru Wed Aug 6 21:59:19 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Wed Aug 6 21:59:26 2008 Subject: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped) In-Reply-To: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> References: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> Message-ID: <519867a90808061459x74b49ce5jc88d9b0d2b35ce21@mail.gmail.com> nice. After posting I think to get a look to manual.... if it has changed since last time then I look into.... and tatata... ;) "*Note:* The implementation of *CVSup* protocol included with the FreeBSD system is called *csup*. It first appeared in FreeBSD 6.2." 2008/8/7 Eugene Kazarinov > Hello. > Dont know is this list right for this topic, but dont know witch one is. > So > > I got 6.3-STABLE-200807-amd64-disc1.iso > I have installed it > cd /usr/ports/net/cvsup-without-gui/ > make install > make clean > > #cvsup some-stable-sup-file > Connected to cvsup.xxxxxx.ru > Bus error (core dumped) > > I cant get fresh src and ports trees and cant compile fresh 6.X-stable > system with athlon64 optimization. :( > > > How to fix cvsup? > How to keep src-tree of 6.x-stable up-to-date without working cvsup? > How to keep ports-tree up-to-date without working cvsup? > > > PS I manage about 10 servers under 6.x-stable and cvsup under 6.3-stable is > very important for me. > Pls help. > From jhb at freebsd.org Wed Aug 6 22:12:09 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Aug 6 22:12:15 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <20080806200643.GA1554@roadrunner.spoerlein.net> References: <20080730113449.GD407@cdnetworks.co.kr> <200808041607.56160.jhb@freebsd.org> <20080806200643.GA1554@roadrunner.spoerlein.net> Message-ID: <200808061811.28200.jhb@freebsd.org> On Wednesday 06 August 2008 04:06:43 pm Ulrich Spoerlein wrote: > On Mon, 04.08.2008 at 16:07:55 -0400, John Baldwin wrote: > > On Monday 04 August 2008 02:29:19 pm Ulrich Spoerlein wrote: > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x38 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x20:0xc058ec16 > > > stack pointer = 0x28:0xfb8b8ac8 > > > frame pointer = 0x28:0xfb8b8ac8 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 1176 (powerd) > > > db:0:kdb.enter.default> show pcpu > > > cpuid = 0 > > > curthread = 0xc4ec0aa0: pid 1176 "powerd" > > > curpcb = 0xfb8b8d90 > > > fpcurthread = none > > > idlethread = 0xc3f80cc0: pid 10 "idle: cpu0" > > > APIC ID = 0 > > > currentldt = 0x50 > > > db:0:kdb.enter.default> bt > > > Tracing pid 1176 tid 100103 td 0xc4ec0aa0 > > > device_is_attached(0,c87e6b40,fb8b8afc,0,101,...) at > > > device_is_attached+0x6 > > > cf_set_method(c420b600,c87e6b40,64,fb8b8ba4,c87e33b4,...) at > > > > cf_set_method+0x6a3 > > > > > cpufreq_curr_sysctl(c420d840,c4207000,0,fb8b8ba4,fb8b8ba4,...) at > > > > cpufreq_curr_sysctl+0x232 > > > > > sysctl_root(fb8b8ba4,4,1,c4ec0aa0,c4501d38,...) at sysctl_root+0x137 > > > userland_sysctl(c4ec0aa0,fb8b8c14,4,0,0,...) at userland_sysctl+0x151 > > > __sysctl(c4ec0aa0,fb8b8cfc,18,fb8b8ca0,46,...) at __sysctl+0xec > > > syscall(fb8b8d38) at syscall+0x345 > > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28161bd3, esp = > > > > 0xbfbfe8cc, ebp = 0xbfbfe8f8 --- > > > > > db:0:kdb.enter.default> capture off > > > > > > Seems like I caught RELENG_7 during a bad time. Will update again. > > > > What cpufreq drivers do you have loaded and attached? This patch might > > work around the issue, but I suspect there is a bug in one of the cpufreq > > drivers. > > Hi John, > > sorry for the slow update, please bear with me. > > This is on a first generation Pentium-M (Banias core) with EST (and also > p4tcc attached, as I just discovered): > > CPU: Intel(R) Pentium(R) M processor 1.50GHz (1495.15-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 > > Features=0xafe9f9bfT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE> Features2=0x180 > .. > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > > > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 300 > dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 > 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% > dev.acpi_perf.0.%parent: cpu0 > dev.est.0.%desc: Enhanced SpeedStep Frequency Control > dev.est.0.%driver: est > dev.est.0.%parent: cpu0 > dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1 > dev.cpufreq.0.%driver: cpufreq > dev.cpufreq.0.%parent: cpu0 > dev.p4tcc.0.%desc: CPU Frequency Thermal Control > dev.p4tcc.0.%driver: p4tcc > dev.p4tcc.0.%parent: cpu0 > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 > 2500/-1 1250/-1 > > a kernel from 2008-06-13 is the last known working one. I just had the > same crash with a kernel from sources at 2008-07-01 and am new > recompiling for 2008-06-24. > > Your MFC of est.c rev 180044 might be the problem, I'll try a backout > once I confirmed that the 2008-06-24 kernel is running stable. I doubt this will cause it. > > Index: kern_cpu.c > > =================================================================== > > RCS file: /usr/cvs/src/sys/kern/kern_cpu.c,v > > retrieving revision 1.27.2.2 > > diff -u -r1.27.2.2 kern_cpu.c > > --- kern_cpu.c 9 May 2008 19:02:10 -0000 1.27.2.2 > > +++ kern_cpu.c 4 Aug 2008 20:07:41 -0000 > > @@ -329,6 +329,8 @@ > > /* Next, set any/all relative frequencies via their drivers. */ > > for (i = 0; i < level->rel_count; i++) { > > set = &level->rel_set[i]; > > + if (set->dev == NULL) > > + continue; > > if (!device_is_attached(set->dev)) { > > error = ENXIO; > > goto out; > > Will try that one too, hopefully tomorrow. > > Will also disable p4tcc. This was not attaching during the RELENG_6 > times but leads to ridiculous rates of 75 MHz. If p4tcc attaching is new, that might point to the culprit. A good quick test would be to disable individual cpufreq drivers to find out which one causes the panic. -- John Baldwin From Nic.Reveles at gatech.edu Wed Aug 6 23:03:09 2008 From: Nic.Reveles at gatech.edu (Nic Reveles) Date: Wed Aug 6 23:03:16 2008 Subject: Using Portupgrade? In-Reply-To: <612629051.3696031218063540670.JavaMail.root@mail3.gatech.edu> Message-ID: <959029730.3696401218063787188.JavaMail.root@mail3.gatech.edu> Thanks for the help. I went ahead and installed portmaster and followed its instructions for deleting all ports and then reinstalling. 1. portmaster -l > ~/installed-port-list 2. Update your ports tree 3. portmaster --clean-distfiles-all 4. portmaster -Faf 5. pkg_delete '*' 6. rm -rf /usr/local/lib/compat/pkg 7. Manually check through /usr/local to make sure it is really empty That being said, I was really surprised to get a compilation error after this. I've updated ports- and src-all, but did I also need to delete somethings inside /usr/src before doing this? Thank you all for your help! :) ===> libgnomeui-2.22.1_2 depends on shared library: gvfscommon.0 - not found ===> Verifying install for gvfscommon.0 in /usr/ports/devel/gvfs ===> Installing for gvfs-0.2.5 ===> gvfs-0.2.5 depends on executable: gnome-mount - found ===> gvfs-0.2.5 depends on executable: mount_fusefs - not found ===> Verifying install for mount_fusefs in /usr/ports/sysutils/fusefs-kmod ===> Building for fusefs-kmod-0.3.9.p1.20080208_2 ===> fuse_module (all) "/usr/src/sys/conf/kern.mk", line 114: Malformed conditional (${MK_SSP} != "no" && ${CC} != "icc" && ${MACHINE_ARCH} != "ia64" && ${MACHINE_ARCH} != "arm" && ${MACHINE_ARCH} != "mips") "/usr/src/sys/conf/kern.mk", line 116: if-less endif make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0. *** Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod. *** Error code 1 From kris at FreeBSD.org Wed Aug 6 23:13:36 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Aug 6 23:13:43 2008 Subject: FreeBSD 6.3/amd64: cvsup: Bus error (core dumped) In-Reply-To: <519867a90808061459x74b49ce5jc88d9b0d2b35ce21@mail.gmail.com> References: <519867a90808061424t50e14c40t6ab9c6f1d849f53a@mail.gmail.com> <519867a90808061459x74b49ce5jc88d9b0d2b35ce21@mail.gmail.com> Message-ID: <489A301E.1080804@FreeBSD.org> Eugene Kazarinov wrote: > nice. > After posting I think to get a look to manual.... if it has changed since > last time then I look into.... > and tatata... ;) "*Note:* The implementation of *CVSup* protocol included > with the FreeBSD system is called *csup*. It first appeared in FreeBSD 6.2." Well, that is a workaround for some users, but it's not a solution. Kris From kamuzon at milshop.ru Thu Aug 7 00:00:34 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Thu Aug 7 00:00:40 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? Message-ID: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> Hello again. Situation 1 I have installed 6.3-STABLE-200807-amd64-disc1.iso #cd /usr/ports/net-mgmt/ng_ipacct/ #make install clean it's ok. It has installed. (sorry for my english) next Situation 2 I have installed 6.3-STABLE-200807-amd64-disc1.iso csup it to last src tree. csup it to last ports tree (as I can see ng_ipacct didn't change from 2006 year) make buildworld, buildkernel -KERNCONF=KMD; install it both, mergemastered and so on after reboot I got: #cd /usr/ports/net-mgmt/ng_ipacct/ #make install clean ====== ===> ng_ipacct-20061223 "Depends on kernel". *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. ====== When? Why? What's wrong? What's changed from 6.3-STABLE-200807 to "6.3-STABLE #0: Thu Aug 7 2008"? During one month?! My kernel config is ======= include GENERIC options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options DUMMYNET options IPFILTER options SMP options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_SOCKET options NETGRAPH_TEE ====== if I change kernel config to {to turn off(??) netgraph} ======= include GENERIC options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options DUMMYNET options IPFILTER options SMP ====== and rebuild kernel and then reboot and after that all is nothing change. It still ====== ===> ng_ipacct-20061223 "Depends on kernel". *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. ====== I dont understand. How to use ng_ipacct and traffic counting in last (super fresh up-to-date system =\) 6.3-stable? Or I need to downgrading to -RELEASE? Or to 6.2-STABLE? Where to read about state of ng_ipacct? google says nothing special. Pls help. I really need to resolv this problem. :( From sam at freebsd.org Thu Aug 7 00:40:55 2008 From: sam at freebsd.org (Sam Leffler) Date: Thu Aug 7 00:41:02 2008 Subject: What is cryptosoft0? In-Reply-To: <20080806201144.GB1554@roadrunner.spoerlein.net> References: <20080806201144.GB1554@roadrunner.spoerlein.net> Message-ID: <489A4496.2060602@freebsd.org> Ulrich Spoerlein wrote: > Hi, > > today I discovered the following dmesg line on my laptop: > > cryptosoft0: on motherboard > > and I've not seen this one before, so: what is cryptosoft and should I > care? > > I could imagine it's a pseudo-device by crypto(9) so the API is the same > whether crypto hardware is installed or not. > > Anyway, I think a manpage link/update would be in order: > > % man -k cryptosoft > cryptosoft: nothing appropriate > > It is what you suggest; a device associated with s/w crypto support. It was created so crypto requests can be submitted specifically to it (instead of a h/w device). This is currently used only for testing but the intent was also to use it when doing load-balancing and similar work. Sam From kamuzon at milshop.ru Thu Aug 7 00:51:53 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Thu Aug 7 00:52:01 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? In-Reply-To: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> References: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> Message-ID: <519867a90808061751y566ea52y983c626f80fd87ac@mail.gmail.com> By the way. I use this kernel config since 5.4-stable, then was 6.0, after that 6.2 and on one server is 6.3-PRERELEASE now. It works. My kernel config is > ======= > include GENERIC > > options IPFIREWALL > options IPFIREWALL_FORWARD > options IPFIREWALL_VERBOSE > options DUMMYNET > options IPFILTER > > options SMP > > options NETGRAPH > options NETGRAPH_ETHER > options NETGRAPH_SOCKET > options NETGRAPH_TEE > ====== > PS I have downgraded the system to 6.3-RELEASE-p3 nothing changes: It's still "Depends on kernel". What does it mean? From kamuzon at milshop.ru Thu Aug 7 01:19:44 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Thu Aug 7 01:19:52 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? In-Reply-To: <519867a90808061751y566ea52y983c626f80fd87ac@mail.gmail.com> References: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> <519867a90808061751y566ea52y983c626f80fd87ac@mail.gmail.com> Message-ID: <519867a90808061819h15e0094cv824256e38684bce1@mail.gmail.com> Ok Let's see There is /usr/ports/net-mgmt/ng_ipacct/Makefile "old" version is # $FreeBSD: ports/net-mgmt/ng_ipacct/Makefile,v 1.9 2008/06/02 16:27:40 skv Exp $ and containts these lines .ifndef PACKAGE_BUILDING NO_PACKAGE= "Depends on kernel" .endif last version is # $FreeBSD: ports/net-mgmt/ng_ipacct/Makefile,v 1.10 2008/08/05 07:19:31 erwin Exp $ and containts these lines .ifndef PACKAGE_BUILDING IGNORE= "Depends on kernel" .endif Should I change IGNORE to NO_PACKAGE and it should works fine for me? Or something would wrong? From joseph.koshy at gmail.com Thu Aug 7 02:04:30 2008 From: joseph.koshy at gmail.com (Joseph Koshy) Date: Thu Aug 7 02:04:37 2008 Subject: Swapping boot disks and getting mountroot> In-Reply-To: <4899E3AC.40201@msu.edu> References: <4899E3AC.40201@msu.edu> Message-ID: <84dead720808061904v398ff7cdieaeca41ed7a8207e@mail.gmail.com> > I notice that it finds the device ad4 but then it tries to mount root from > /dev/ad6s1a. I've edited the fstab to have it look for ad4s1a but it still > won't boot. Anyone have any pointers or ideas? Have you tried interrupting the boot sequence and setting new values for the `rootdev' and `root_disk_unit' loader variables? The loader(8) manual page has more information. Koshy From doconnor at gsoft.com.au Thu Aug 7 02:20:53 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Aug 7 02:21:01 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? In-Reply-To: <519867a90808061819h15e0094cv824256e38684bce1@mail.gmail.com> References: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> <519867a90808061751y566ea52y983c626f80fd87ac@mail.gmail.com> <519867a90808061819h15e0094cv824256e38684bce1@mail.gmail.com> Message-ID: <200808071114.46366.doconnor@gsoft.com.au> On Thu, 7 Aug 2008, Eugene Kazarinov wrote: > Ok > Let's see > > > There is > /usr/ports/net-mgmt/ng_ipacct/Makefile > > "old" version is > # $FreeBSD: ports/net-mgmt/ng_ipacct/Makefile,v 1.9 2008/06/02 > 16:27:40 skv Exp $ > and containts these lines > > .ifndef PACKAGE_BUILDING > NO_PACKAGE= "Depends on kernel" > .endif > > > last version is > # $FreeBSD: ports/net-mgmt/ng_ipacct/Makefile,v 1.10 2008/08/05 > 07:19:31 erwin Exp $ > and containts these lines > > .ifndef PACKAGE_BUILDING > IGNORE= "Depends on kernel" > .endif > > > Should I change IGNORE to NO_PACKAGE and it should works fine for me? > Or something would wrong? Seems like it, although if you aren't building packages then it shouldn't matter either way.. It does seem odd that it changed to IGNORE - NO_PACKAGE could be OK to use by itself. The logic for that doesn't really make sense either.. I CC'd the port maintainer about it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080807/e0f72674/attachment.pgp From kamuzon at milshop.ru Thu Aug 7 02:50:50 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Thu Aug 7 02:50:57 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? In-Reply-To: <200808071114.46366.doconnor@gsoft.com.au> References: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> <519867a90808061751y566ea52y983c626f80fd87ac@mail.gmail.com> <519867a90808061819h15e0094cv824256e38684bce1@mail.gmail.com> <200808071114.46366.doconnor@gsoft.com.au> Message-ID: <519867a90808061950p4a611403we7248af13e69dc5d@mail.gmail.com> > > > # $FreeBSD: ports/net-mgmt/ng_ipacct/Makefile,v 1.9 2008/06/02 > > NO_PACKAGE= "Depends on kernel" > > > > # $FreeBSD: ports/net-mgmt/ng_ipacct/Makefile,v 1.10 2008/08/05 > > IGNORE= "Depends on kernel" > > > > > > > > Should I change IGNORE to NO_PACKAGE and it should works fine for me? > > Or something would wrong? > > Seems like it, although if you aren't building packages then it > shouldn't matter either way.. > > It does seem odd that it changed to IGNORE - NO_PACKAGE could be OK to > use by itself. > > The logic for that doesn't really make sense either.. I CC'd the port > maintainer about it. > Thank you a lot. By the way I have one more question to port mantainer (dont know who is this). in rc.conf I have this line ng_ipacct_enable="YES" Sample ng_ipacct.conf contains these lines #ng_ipacct_enable="YES" ng_ipacct_modules_load="YES" ng_ipacct_modules_list="netgraph ng_ether ng_ipacct" after boot with these lines in config file I got in /var/log/messages: Aug 7 06:15:49 ph26 root: /etc/rc: WARNING: can not load kld module netgraph Aug 7 06:15:49 ph26 kernel: kldload: /boot/kernel/ng_ether.ko: Unsupported file type Aug 7 06:15:49 ph26 kernel: module_register: module ng_ether already exists! Aug 7 06:15:49 ph26 kernel: Module ng_ether failed to register: 17 Aug 7 06:15:49 ph26 root: /etc/rc: WARNING: can not load kld module ng_ether Aug 7 06:15:49 ph26 kernel: kldload: /boot/modules/ng_ipacct.ko: Unsupported file type IP accounting is working! If I change lines to #ng_ipacct_enable="YES" ng_ipacct_modules_load="YES" ng_ipacct_modules_list="" I got Aug 7 06:20:22 ph26 kernel: kldload: /boot/modules/ng_ipacct.ko: Unsupported file type IP accounting is still working! And If I change they to #ng_ipacct_enable="YES" #ng_ipacct_modules_load="YES" #ng_ipacct_modules_list="netgraph ng_ether ng_ipacct" I got Aug 7 06:11:53 ph26 root: /etc/rc: WARNING: $ng_ipacct_modules_load is not set properly - see rc.conf(5). Aug 7 06:11:53 ph26 kernel: kldload: /boot/modules/ng_ipacct.ko: Unsupported file type IP accounting is still working! Wonderful! :-\ So, as I understand all needed modules loading by kernel "by default"?! And as I understand, module ng_ipacct.ko is not needed to the system for IP accounting?! because its not loaded in working system (and it's not working (isnt it?)) because it is "Unsupported file type"?! So, from that port (ng_ipacct) on up-to-date FreeBSD-systems people need only executable (/usr/local/etc/rc.d/ng_ipacct) and conf (/usr/local/etc/rc.d/ng_ipacct.conf.sample renamed to /usr/local/etc/rc.d/ng_ipacct.conf) files? Nor kernel module?! So, If I dont want to get error response "kernel: kldload: /boot/modules/ng_ipacct.ko: Unsupported file type" in /var/log/messages then I could remove /boot/modules/ng_ipacct.ko and /boot/modules/linker.hints last one containes: 01 00 00 00 1C 00 00 00 02 00 00 00 09 6E 67 5F 69 70 61 63 ............ng_ipac 63 74 0C 6E 67 5F 69 70 61 63 63 74 2E 6B 6F 00 ct.ng_ipacct.ko. and all'll works fine after that? I'm afraid to delete these files, because I think system can becomes unbootable. Isn't it? PS uname -a FreeBSD ph26.yaol.ru 6.3-STABLE FreeBSD 6.3-STABLE #0: Thu Aug 7 05:32:15 MSD 2008 kamuzon@ph26.yaol.ru:/usr/obj/usr/src/sys/KMD amd64 PPS sorry for my english Thanks in advance. From doconnor at gsoft.com.au Thu Aug 7 03:14:08 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Aug 7 03:14:15 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? In-Reply-To: <519867a90808061950p4a611403we7248af13e69dc5d@mail.gmail.com> References: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> <200808071114.46366.doconnor@gsoft.com.au> <519867a90808061950p4a611403we7248af13e69dc5d@mail.gmail.com> Message-ID: <200808071244.03428.doconnor@gsoft.com.au> On Thu, 7 Aug 2008, Eugene Kazarinov wrote: > By the way I have one more question to port mantainer (dont know who > is this). run 'make maintainer' in the port directory. > So, as I understand all needed modules loading by kernel "by > default"?! And as I understand, module ng_ipacct.ko is not needed to > the system for IP accounting?! because its not loaded in working > system (and it's not working (isnt it?)) because it is "Unsupported > file type"?! > So, from that port (ng_ipacct) on up-to-date FreeBSD-systems people > need only executable (/usr/local/etc/rc.d/ng_ipacct) and conf > (/usr/local/etc/rc.d/ng_ipacct.conf.sample renamed to > /usr/local/etc/rc.d/ng_ipacct.conf) files? Nor kernel module?! The messages about already loaded modules are harmless, the port presumably errs on the side of caution if you have a minimal kernel. > So, If I dont want to get error response "kernel: kldload: > /boot/modules/ng_ipacct.ko: Unsupported file type" in > /var/log/messages then I could remove /boot/modules/ng_ipacct.ko and > /boot/modules/linker.hints > last one containes: I think the 'Unsupported file type' *warning* is due to an odd issue with amd64 kernel module support, it is harmless (although annoying). > I'm afraid to delete these files, because I think system can becomes > unbootable. Isn't it? if you deleted the kernel module for ipacct then you wouldn't be able to use it.. (maybe I don't understand what you mean) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080807/0f6e3386/attachment.pgp From doconnor at gsoft.com.au Thu Aug 7 03:17:06 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Aug 7 03:17:13 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? In-Reply-To: <200808071244.03428.doconnor@gsoft.com.au> References: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> <519867a90808061950p4a611403we7248af13e69dc5d@mail.gmail.com> <200808071244.03428.doconnor@gsoft.com.au> Message-ID: <200808071247.02042.doconnor@gsoft.com.au> On Thu, 7 Aug 2008, Daniel O'Connor wrote: > > So, If I dont want to get error response "kernel: kldload: > > /boot/modules/ng_ipacct.ko: Unsupported file type" in > > /var/log/messages then I could remove /boot/modules/ng_ipacct.ko > > and /boot/modules/linker.hints > > last one containes: > > I think the 'Unsupported file type' *warning* is due to an odd issue > with amd64 kernel module support, it is harmless (although annoying). To clarify here.. There are 2 bits of code in the kernel for loading modules - they get run in a certain (compiler/linker specific) order. It used to be they were run one way but now it is the other way around. These bits of code print warnings if the object format is wrong. So, one gets run on the module you want to load & fails (and prints the message you see). The next one is run and it understands that file type so loads it. If it was a bogus module that neither understood then the kldload would return an error. I believe a work around was applied recently so this is not so much of a problem any more. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080807/fc4f7347/attachment-0001.pgp From kamuzon at milshop.ru Thu Aug 7 03:21:48 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Thu Aug 7 03:21:55 2008 Subject: FreeBSD 6.3/amd64: ng_ipacct "Depends on kernel" ?? why? when? In-Reply-To: <200808071247.02042.doconnor@gsoft.com.au> References: <519867a90808061700i677df5e8u221fe39de2fd3e1@mail.gmail.com> <519867a90808061950p4a611403we7248af13e69dc5d@mail.gmail.com> <200808071244.03428.doconnor@gsoft.com.au> <200808071247.02042.doconnor@gsoft.com.au> Message-ID: <519867a90808062021n660dc046p7a68b57a3b2a9420@mail.gmail.com> > > So, one gets run on the module you want to load & fails (and prints the > message you see). The next one is run and it understands that file type > so loads it. > I understand now. Thank you a lot again. From alfred at freebsd.org Thu Aug 7 06:25:54 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Thu Aug 7 06:26:01 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <20080804020228.GG1663@tnn.dglawrence.com> References: <20080804020228.GG1663@tnn.dglawrence.com> Message-ID: <20080807060556.GD16977@elvis.mu.org> * David G Lawrence [080805 11:37] wrote: > > The thrust of this change is to replace the mutexes protecting the inpcb > > and inpcbinfo data structures with read-write locks (rwlocks). These > > That's really cool and directly affects my current work project. I'm > developing (have developed, actually) a multi-threaded, 5000+ member VoIP/SIP > conferencing server called Nconnect. It a primarily UDP application running > on FreeBSD 7. This generates and receives about 250,000 UDP packets a second, > with 200 byte packets, resulting in about 400Mbps of traffic in each > direction. The current bottleneck is the kernel UDP processing. It should > be possible to scale to 10000+ members if kernel UDP processing had optimal > concurrency. > Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm > looking forward to the MFC. David, one thing I noticed was that it appears that UDP sockets are serialized for copyout. Mainly that the socket is sblock()'d while the uiomove happens. I was trying to figure out a way to bypass this somehow. Perhaps just dequeuing and unlocking, the copyout after dropping the sblock. If there's some error, then requeue or discard the packet. I'll have to think about it. -Alfred From rwatson at FreeBSD.org Thu Aug 7 06:37:58 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Aug 7 06:38:06 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <20080807060556.GD16977@elvis.mu.org> References: <20080804020228.GG1663@tnn.dglawrence.com> <20080807060556.GD16977@elvis.mu.org> Message-ID: On Wed, 6 Aug 2008, Alfred Perlstein wrote: > * David G Lawrence [080805 11:37] wrote: >>> The thrust of this change is to replace the mutexes protecting the inpcb >>> and inpcbinfo data structures with read-write locks (rwlocks). These >> >> That's really cool and directly affects my current work project. I'm >> developing (have developed, actually) a multi-threaded, 5000+ member >> VoIP/SIP conferencing server called Nconnect. It a primarily UDP >> application running on FreeBSD 7. This generates and receives about 250,000 >> UDP packets a second, with 200 byte packets, resulting in about 400Mbps of >> traffic in each direction. The current bottleneck is the kernel UDP >> processing. It should be possible to scale to 10000+ members if kernel UDP >> processing had optimal concurrency. >> Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm >> looking forward to the MFC. > > David, one thing I noticed was that it appears that UDP sockets are > serialized for copyout. > > Mainly that the socket is sblock()'d while the uiomove happens. > > I was trying to figure out a way to bypass this somehow. Perhaps just > dequeuing and unlocking, the copyout after dropping the sblock. > > If there's some error, then requeue or discard the packet. > > I'll have to think about it. Or you can use the soreceive_dgram implementation in 8.x, which I will at some point MFC once I'm comfortable it doesn't contain any serious bugs. Robert N M Watson Computer Laboratory University of Cambridge From kes-kes at yandex.ru Thu Aug 7 07:39:34 2008 From: kes-kes at yandex.ru (KES) Date: Thu Aug 7 07:39:42 2008 Subject: ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local' Message-ID: <310261218093750@webmail34.yandex.ru> When .ifndef PACKAGE_BUILDING IGNORE= "Depends on kernel" .endif I get Depends on kernel When I change that to: .ifndef PACKAGE_BUILDING NO_PACKAGE= "Depends on kernel" .endif a get: kes# make deinstall reinstall clean ===> Deinstalling for net-mgmt/ng_ipacct ===> ng_ipacct not installed, skipping ===> Building for ng_ipacct-20061223 ===> ng_ipacct (all) Warning: Object directory not changed from original /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct cc -O -pipe -g -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ng_ipacct.c ng_ipacct.c: In function 'pcb_get_cred': ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local' *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. kes# From ask at develooper.com Thu Aug 7 08:24:48 2008 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Thu Aug 7 08:24:57 2008 Subject: i386 vs amd64? Message-ID: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> Hi everyone, We got 4 new SuperMicro boxes[1] with Xeon 3320 processors. They'll be used as firewalls / very basic routers (our network on one side, the world via a /29 on the other side). We currently use Soekris and PC Engine boxes for this (with custom NanoBSD images), so this will be a bit of an upgrade. :-) I was planning to install pfSense on them, but I'm losing faith in that a bit after figuring out that the pfSense project doesn't seem all that open[2]; so I'm considering just installing "plain FreeBSD 7" instead. So the question: Would I be happier with 64 or 32bit FreeBSD? Our Linux application and database servers are all 64 bit, but they also have 32GB RAM each. The "firewall boxes" are probably vastly overdone with memory at 4GB each. :-) A secondary question: Is the preferred way to upgrade a FreeBSD box still cd /usr/src; make update && make buildworld && ... ? (I mostly use FreeBSD for building my NanoBSD-flavor images these days, so I'm a bit out of touch). - ask [1] http://www.siliconmechanics.com/i15328/xeon-3000.php [2] http://forum.pfsense.org/index.php/topic,10769.0.html -- http://develooper.com/ - http://askask.com/ From koitsu at FreeBSD.org Thu Aug 7 09:04:22 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 7 09:04:30 2008 Subject: i386 vs amd64? In-Reply-To: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> References: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> Message-ID: <20080807090422.GA19885@eos.sc1.parodius.com> On Thu, Aug 07, 2008 at 12:58:06AM -0700, Ask Bj?rn Hansen wrote: > We got 4 new SuperMicro boxes[1] with Xeon 3320 processors. They'll be > used as firewalls / very basic routers (our network on one side, the > world via a /29 on the other side). We currently use Soekris and PC > Engine boxes for this (with custom NanoBSD images), so this will be a bit > of an upgrade. :-) What motherboard model is used on those boxes? The website doesn't say. The reason I'm asking is that I'm working on a H/W monitoring project which currently is focusing on Supermicro boards, and need more testers for boards I don't already have data for. :-) > I was planning to install pfSense on them, but I'm losing faith in that a > bit after figuring out that the pfSense project doesn't seem all that > open[2]; so I'm considering just installing "plain FreeBSD 7" instead. > > So the question: Would I be happier with 64 or 32bit FreeBSD? Our > Linux application and database servers are all 64 bit, but they also > have 32GB RAM each. The "firewall boxes" are probably vastly overdone > with memory at 4GB each. :-) We have numerous Supermicro machines in our co-lo, all of which run i386 except for one. The reason was that I hadn't spent the time to really get a feel for amd64 (all the machines run RELENG_6 except for the amd64 box, which runs RELENG_7). I run amd64 at home, and it's fine. I'm looking forward to being able to upgrade our SQL server in the co-lo to either 4GB or 8GB of RAM without having to bother with PAE (ugh!). But be aware that there still are some applications (ports) which don't behave correctly on amd64. So my recommendation is to build a test box that mimics your production environment, and make sure all of your stuff works on it. You might also be asking "is there some form of compatibility where amd64 can continue to run i386 binaries?" Yes, it's called lib32. I choose not to install it (during a FreeBSD install), and I disable it from buildworld by using WITHOUT_LIB32=true in /etc/src.conf (that file is new compared to older FreeBSD, so be aware). My attitude is "this is a 64-bit box, and you will recompile your programs to work on a 64-bit arch". Avoiding it also greatly decreases buildworld time. > A secondary question: Is the preferred way to upgrade a FreeBSD box > still cd /usr/src; make update && make buildworld && ... ? (I mostly > use FreeBSD for building my NanoBSD-flavor images these days, so I'm a > bit out of touch). First and foremost: to update the sources, you should use csup and not cvsup. csup comes in the base system, is written in C, and supports most all of the flags that cvsup does. The upgrade procedure is described in detail in /usr/src/Makefile. Here's what I'm referring to: # For individuals wanting to upgrade their sources (even if only a # delta of a few days): # # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot' (in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) Some footnotes: 1) You can put KERNCONF=WHATEVER in /etc/make.conf, thus avoiding the need to specify it during steps 3 and 4. 2) On amd64, your kernel config will go in /sys/amd64/conf, not /sys/i386/conf. (This may be obvious to most, but not so much to newer folks). 3) After step #5, and you're in single-user, you'll probably have to type "mount -a -t ufs" to get all of your filesystems mounted. 4) Don't skip the single-user step or try to do it from multi-user; I've seen numerous cases where /libexec/ld-elf.so.1 doesn't get updated as a result of people trying to avoid single-user. If you admin these boxes remotely, you're going to need serial console for the above. 5) Get familiar with mergemaster, specifically the side-by-side interactive diff feature. It looks scary the first time around, but once you learn that "r" applies the stuff you see on the right, and "l" applies the stuff you see on the left, you should be fine. -- | Jeremy Chadwick jdc 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 | From freebsd-stable at dino.sk Thu Aug 7 09:45:05 2008 From: freebsd-stable at dino.sk (Milan Obuch) Date: Thu Aug 7 09:45:13 2008 Subject: i386 vs amd64? In-Reply-To: <20080807090422.GA19885@eos.sc1.parodius.com> References: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> <20080807090422.GA19885@eos.sc1.parodius.com> Message-ID: <200808071134.41927.freebsd-stable@dino.sk> On Thursday 07 August 2008, Jeremy Chadwick wrote: > On Thu, Aug 07, 2008 at 12:58:06AM -0700, Ask Bj?rn Hansen wrote: [ snip ] > But be aware that there still are some applications (ports) which don't > behave correctly on amd64. So my recommendation is to build a test > box that mimics your production environment, and make sure all of your > stuff works on it. This means you should do some work before actually deciding the way to go... but it's the best way. Test and then use in production. Your own experience is worth an added bit of work. [ snip ] > 5) Get familiar with mergemaster, specifically the side-by-side > interactive diff feature. It looks scary the first time around, > but once you learn that "r" applies the stuff you see on the right, > and "l" applies the stuff you see on the left, you should be fine. Funny observation: "r" is on LEFT keyboard side, "l" is on RIGHT keyboard side. I for one have problem at times precisely for this reason, but I know this is an important step and one need to act with great care. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. From unga888 at yahoo.com Thu Aug 7 10:22:23 2008 From: unga888 at yahoo.com (Unga) Date: Thu Aug 7 10:22:30 2008 Subject: bsnmp header files question Message-ID: <253521.24170.qm@web57012.mail.re3.yahoo.com> Hi Could I know on i386 RELENG_7, what Makefiles install following header files: 1) /usr/include/bsnmp/snmpmod.h 2) /usr/include/bsnmp/snmp_mibII.h 3) /usr/include/bsnmp/snmp_atm.h Appreciate your reply very much. Kind regards Unga From gerrit at pmp.uni-hannover.de Thu Aug 7 11:41:32 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Aug 7 11:41:39 2008 Subject: Regression 7.0R -> 7-stable? Message-ID: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> Hi folks, I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 processor (triple core is somehow strange :-) and a lot of NVidia stuff onboard. I installed 7.0-R, which ran quite well except for the bge driver and snd_hda which both complained. After putting in an extra networking card I was able to install some more software and all appeared to be nice. Then I cvsupped to the recent 7-stable as of today. My hope was that maybe the bge or the sound card would improve from this. However, the new kernel I compiled does not run at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits there and does nothing anymore. I have verified this behaviour with amd64 snapshot images from July and August to make sure I did not compile a bad kernel. Both show the same behaviour. Are there any ideas what has changed from 7.0-R to recent 7.0-stable that could cause this? What can I do to debug/fix this? cu Gerrit From edwin at mavetju.org Thu Aug 7 11:48:00 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Thu Aug 7 11:48:08 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> Message-ID: <20080807114706.GA3286@k7.mavetju> On Thu, Aug 07, 2008 at 01:29:47PM +0200, Gerrit K?hn wrote: > Hi folks, > > I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 > processor (triple core is somehow strange :-) and a lot of NVidia stuff > onboard. I installed 7.0-R, which ran quite well except for the bge driver > and snd_hda which both complained. > After putting in an extra networking card I was able to install some more > software and all appeared to be nice. Then I cvsupped to the recent > 7-stable as of today. My hope was that maybe the bge or the sound card > would improve from this. However, the new kernel I compiled does not run > at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits > there and does nothing anymore. I have verified this behaviour with amd64 > snapshot images from July and August to make sure I did not compile a bad > kernel. Both show the same behaviour. > Are there any ideas what has changed from 7.0-R to recent 7.0-stable that > could cause this? What can I do to debug/fix this? Make sure you have this in your /etc/sysctl.conf: [~] edwin@k7>grep hyper /etc/sysctl.conf machdep.hyperthreading_allowed=1 Then with top you can see the CPUs in use ----------v PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 69200 edwin 9 44 0 236M 130M ucond 0 33:37 5.76% seamonkey-b 3317 edwin 1 71 0 38404K 33572K select 1 3:51 0.10% mutt 3015 edwin 1 45 0 403M 81672K select 0 101:52 0.00% Xorg Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From brix at FreeBSD.org Thu Aug 7 11:49:05 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Thu Aug 7 11:49:13 2008 Subject: bsnmp header files question In-Reply-To: <253521.24170.qm@web57012.mail.re3.yahoo.com> References: <253521.24170.qm@web57012.mail.re3.yahoo.com> Message-ID: <20080807113116.GB90026@tirith.brixandersen.dk> On Thu, Aug 07, 2008 at 03:22:21AM -0700, Unga wrote: > 1) /usr/include/bsnmp/snmpmod.h /usr/src/usr.sbin/bsnmpd/modules/Makefile > 2) /usr/include/bsnmp/snmp_mibII.h /usr/src/usr.sbin/bsnmpd/modules/snmp_mibII/Makefile > 3) /usr/include/bsnmp/snmp_atm.h /usr/src/usr.sbin/bsnmpd/modules/snmp_atm/Makefile Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080807/41cfbe92/attachment.pgp From koitsu at FreeBSD.org Thu Aug 7 12:19:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 7 12:19:47 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20080807114706.GA3286@k7.mavetju> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20080807114706.GA3286@k7.mavetju> Message-ID: <20080807121940.GA28212@eos.sc1.parodius.com> On Thu, Aug 07, 2008 at 09:47:06PM +1000, Edwin Groothuis wrote: > On Thu, Aug 07, 2008 at 01:29:47PM +0200, Gerrit K?hn wrote: > > Hi folks, > > > > I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 > > processor (triple core is somehow strange :-) and a lot of NVidia stuff > > onboard. I installed 7.0-R, which ran quite well except for the bge driver > > and snd_hda which both complained. > > After putting in an extra networking card I was able to install some more > > software and all appeared to be nice. Then I cvsupped to the recent > > 7-stable as of today. My hope was that maybe the bge or the sound card > > would improve from this. However, the new kernel I compiled does not run > > at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits > > there and does nothing anymore. I have verified this behaviour with amd64 > > snapshot images from July and August to make sure I did not compile a bad > > kernel. Both show the same behaviour. > > Are there any ideas what has changed from 7.0-R to recent 7.0-stable that > > could cause this? What can I do to debug/fix this? > > Make sure you have this in your /etc/sysctl.conf: > > [~] edwin@k7>grep hyper /etc/sysctl.conf > machdep.hyperthreading_allowed=1 > > Then with top you can see the CPUs in use ----------v > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 69200 edwin 9 44 0 236M 130M ucond 0 33:37 5.76% seamonkey-b > 3317 edwin 1 71 0 38404K 33572K select 1 3:51 0.10% mutt > 3015 edwin 1 45 0 403M 81672K select 0 101:52 0.00% Xorg I think you misread what he was saying. :-) He's saying that his system locks up hard after the kernel prints the "SMP: AP CPU #x Launched!" messages. I believe this is the 2nd or 3rd report we've had of this behaviour, re: system locking up hard after those messages. I'll see if I can find the past reports; I'm going off of memory, but they were in recent days. Also (for you Edwin), be aware of the security issues when enabling HTT, as well as the possible decrease in system performance (while increase in power draw) it can cause: http://en.wikipedia.org/wiki/Hyper-threading#Security http://en.wikipedia.org/wiki/Hyper-threading#Future -- | Jeremy Chadwick jdc 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 | From gerrit at pmp.uni-hannover.de Thu Aug 7 12:35:38 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Aug 7 12:35:45 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20080807121940.GA28212@eos.sc1.parodius.com> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20080807114706.GA3286@k7.mavetju> <20080807121940.GA28212@eos.sc1.parodius.com> Message-ID: <20080807143535.86c25613.gerrit@pmp.uni-hannover.de> On Thu, 7 Aug 2008 05:19:40 -0700 Jeremy Chadwick wrote about Re: Regression 7.0R -> 7-stable?: JC> I think you misread what he was saying. :-) He's saying that his JC> system locks up hard after the kernel prints the "SMP: AP CPU #x JC> Launched!" messages. Exactly. ;-) JC> I believe this is the 2nd or 3rd report we've had of this behaviour, JC> re: system locking up hard after those messages. I'll see if I can JC> find the past reports; I'm going off of memory, but they were in JC> recent days. Please let me know if I can provide any further information. However, I will probably not be on the net from tomorrow (Friday) until Monday. cu Gerrit From edwin at mavetju.org Thu Aug 7 12:37:01 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Thu Aug 7 12:37:08 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20080807121940.GA28212@eos.sc1.parodius.com> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <20080807114706.GA3286@k7.mavetju> <20080807121940.GA28212@eos.sc1.parodius.com> Message-ID: <20080807123606.GT3285@k7.mavetju> On Thu, Aug 07, 2008 at 05:19:40AM -0700, Jeremy Chadwick wrote: > On Thu, Aug 07, 2008 at 09:47:06PM +1000, Edwin Groothuis wrote: > > On Thu, Aug 07, 2008 at 01:29:47PM +0200, Gerrit K?hn wrote: > > > Hi folks, > > > > > > I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 > > > processor (triple core is somehow strange :-) and a lot of NVidia stuff > > > onboard. I installed 7.0-R, which ran quite well except for the bge driver > > > and snd_hda which both complained. > > > After putting in an extra networking card I was able to install some more > > > software and all appeared to be nice. Then I cvsupped to the recent > > > 7-stable as of today. My hope was that maybe the bge or the sound card > > > would improve from this. However, the new kernel I compiled does not run > > > at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits > > > there and does nothing anymore. I have verified this behaviour with amd64 > > > snapshot images from July and August to make sure I did not compile a bad > > > kernel. Both show the same behaviour. > > > Are there any ideas what has changed from 7.0-R to recent 7.0-stable that > > > could cause this? What can I do to debug/fix this? > > > > Make sure you have this in your /etc/sysctl.conf: > > > > [~] edwin@k7>grep hyper /etc/sysctl.conf > > machdep.hyperthreading_allowed=1 > > > > Then with top you can see the CPUs in use ----------v > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 69200 edwin 9 44 0 236M 130M ucond 0 33:37 5.76% seamonkey-b > > 3317 edwin 1 71 0 38404K 33572K select 1 3:51 0.10% mutt > > 3015 edwin 1 45 0 403M 81672K select 0 101:52 0.00% Xorg > > I think you misread what he was saying. :-) He's saying that his > system locks up hard after the kernel prints the "SMP: AP CPU #x > Launched!" messages. It's indeed a different interpretation of what I originally read. Sorry for the noise! Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From kamuzon at milshop.ru Thu Aug 7 12:48:14 2008 From: kamuzon at milshop.ru (Eugene Kazarinov) Date: Thu Aug 7 12:48:22 2008 Subject: i386 vs amd64? In-Reply-To: <20080807090422.GA19885@eos.sc1.parodius.com> References: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> <20080807090422.GA19885@eos.sc1.parodius.com> Message-ID: <519867a90808070548n5eee13adwb79b62bd2fecb67a@mail.gmail.com> Hello everybody. (sorry for my english) > > # For individuals wanting to upgrade their sources (even if only a > # delta of a few days): > # > # 1. `cd /usr/src' (or to the directory containing your source > tree). > # 2. `make buildworld' > # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is > GENERIC). > # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is > GENERIC). > # 5. `reboot' (in single user mode: boot -s from the loader > prompt). > # 6. `mergemaster -p' > # 7. `make installworld' > # 8. `make delete-old' > # 9. `mergemaster' > # 10. `reboot' > # 11. `make delete-old-libs' (in case no 3rd party program uses them > anymore) > Pls tell me what for I need 5 step? I have about 15 remote servers (10 on 6.X-stable and others on 7.0-stable). These servers are far far away from me and I really cant connect serial or keyboard to it. So I upgrade remotely without "# 5 reboot" very long time, starting from at least 5.4 (maybe 4.x I dont remember), 5.4-stable -> 6.0-stable, 6.0-stable -> 6.2-stable, 6.0/6.2-stable -> 6.3-stable and of couse 6.2/6.3-stable -> 7.0-stable. Only once I got a problem with /libexec/ld-elf.so.X then I try upgrade from 6.2-RELEASE-pX to 7.0-stable. Of couse I got phisical access to this server to repair it. I got this file from another server and then succesfully rebuild all the world with my "reception". This was really hard situation. (I use /rescue and have shamanian danced with tambourine around this server ;) lol ;) ) I dont remember why I had on that server this strange (for me) version (6.2-RELEASE). So have I a chance to upgrade remote servers without single mode? Now my practice is (a few last years): #cd /usr/src #mergemaster -p && make -j8 buildworld && make -j8 buildkernel KERNCONF=KMD && make installkernel KERNCONF=KMD && make installworld && mergemaster -iU && reboot *) -j8 on 2x- or 4x-kernels cpu and -j4 on 1x-kernel cpu *) some time I did "make -j4 installkernel KERNCONF=KMD" and "make -j4 installworld" but it's worked not stable. Sometimes it returns an error. Maybe hdd was not speedy - dont know why it was so and dont know how to say it all in english. :\ *) on Phenom 9750 with 2GB DDR2 800MHz memory "-j8 buildworld" makes in about 16 minutes and "-j8 buildkernel KERN..." in about 5 minutes. As a result all upgrade takes about 30 minutes or less. On x2 CPUs I put this long command in ssh-term and go away. When I come back "mergemaster -iU" is waiting me. And if I make major update (6.x to 7.x) I'll portupgrade all ports as in manual "portupgrade -faP" and then reboot after that "make delete-old" and "make delete-old-libs" and reboot All of this I do remotely. Is this way very wrong? I understand that it's not a "canonical" way but how I can do it right and remotely? Thanks in advance. From andy at xecu.net Thu Aug 7 14:05:41 2008 From: andy at xecu.net (Andy Dills) Date: Thu Aug 7 14:05:48 2008 Subject: PPP doesn't set the correct interface in 7-STABLE In-Reply-To: <200808061554.m76FsZlm092227@lava.sentex.ca> References: <20080806101147.Y50885@shell.xecu.net> <200808061554.m76FsZlm092227@lava.sentex.ca> Message-ID: <20080807095944.R46224@shell.xecu.net> On Wed, 6 Aug 2008, Mike Tancsa wrote: > At 10:16 AM 8/6/2008, Andy Dills wrote: > > > I'm trying to setup pptpd to enable VPN connections. This worked well in > > all versions of FreeBSD prior to 7. > > I would turf pptpd and look at mpd51 from the ports. It is far, far better > maintained and is quite solid as an LNS as well as PPTP termination server. Yep, it looks like this is definitely the best solution, for a number of reasons. Thanks for the pointer. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- From besko at msu.edu Thu Aug 7 14:25:30 2008 From: besko at msu.edu (Lisa Besko) Date: Thu Aug 7 14:25:37 2008 Subject: Swapping boot disks and getting mountroot> In-Reply-To: <84dead720808061904v398ff7cdieaeca41ed7a8207e@mail.gmail.com> References: <4899E3AC.40201@msu.edu> <84dead720808061904v398ff7cdieaeca41ed7a8207e@mail.gmail.com> Message-ID: <489B05D9.7030407@msu.edu> Joseph Koshy wrote: >> I notice that it finds the device ad4 but then it tries to mount root from >> /dev/ad6s1a. I've edited the fstab to have it look for ad4s1a but it still >> won't boot. Anyone have any pointers or ideas? > > Have you tried interrupting the boot sequence and setting new > values for the `rootdev' and `root_disk_unit' loader variables? > The loader(8) manual page has more information. No I haven't tried that yet. Will that get me to a point where I can trust it to boot on it's own to the correct disk all the time? LB -- Lisa Besko From petefrench at ticketswitch.com Thu Aug 7 16:27:55 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu Aug 7 16:28:05 2008 Subject: should looking at an interface with 'ifconfig' trigger a change ? Message-ID: I have a very odd problem here - two interfaces bundled using lagg in 'failover' mode, so one interface is active and the other not being used. if the carrier drops on the active one I expect it to failover, but it doesnt. ...until I type 'ifconfig bce0' to look at the status of the interface which has gone down. At which point it fails over properly! This is most odd - how can simply looking at the config of an interface trigger the failover ? It wont fail over otherwise either - you can leave it as long as you like and lagg wont realise that the active has gone down. The interfaces here are 'bce' by the way, if that make a difference.... -pete. From petefrench at ticketswitch.com Thu Aug 7 17:12:00 2008 From: petefrench at ticketswitch.com (Pete French) Date: Thu Aug 7 17:12:07 2008 Subject: should looking at an interface with 'ifconfig' trigger a change ? In-Reply-To: <20080807165712.GA37969@citylink.fud.org.nz> Message-ID: > The bce driver is not properly generating link state events. OK, that explains why it doesnt failover - but why does looking at it with ifconfig make a difference ? surely that should be 'read only ? -pete. From thompsa at FreeBSD.org Thu Aug 7 17:27:06 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Thu Aug 7 17:27:13 2008 Subject: should looking at an interface with 'ifconfig' trigger a change ? In-Reply-To: References: Message-ID: <20080807165712.GA37969@citylink.fud.org.nz> On Thu, Aug 07, 2008 at 05:27:53PM +0100, Pete French wrote: > I have a very odd problem here - two interfaces bundled using lagg > in 'failover' mode, so one interface is active and the other not being > used. if the carrier drops on the active one I expect it to > failover, but it doesnt. > > ...until I type 'ifconfig bce0' to look at the status of the interface > which has gone down. At which point it fails over properly! > > This is most odd - how can simply looking at the config of an > interface trigger the failover ? It wont fail over otherwise either - you > can leave it as long as you like and lagg wont realise that the active > has gone down. > > The interfaces here are 'bce' by the way, if that make a difference.... The bce driver is not properly generating link state events. Andrew From thompsa at FreeBSD.org Thu Aug 7 17:35:31 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Thu Aug 7 17:35:37 2008 Subject: should looking at an interface with 'ifconfig' trigger a change ? In-Reply-To: References: <20080807165712.GA37969@citylink.fud.org.nz> Message-ID: <20080807173525.GB37969@citylink.fud.org.nz> On Thu, Aug 07, 2008 at 06:11:58PM +0100, Pete French wrote: > > The bce driver is not properly generating link state events. > > OK, that explains why it doesnt failover - but why does looking at it > with ifconfig make a difference ? surely that should be 'read only ? ifconfig will cause the media status to be read from the hardware at which time the link change is generated as it is different to the stored value. cheers, Andrew From cswiger at mac.com Thu Aug 7 18:31:50 2008 From: cswiger at mac.com (Chuck Swiger) Date: Thu Aug 7 18:31:58 2008 Subject: i386 vs amd64? In-Reply-To: <200808071134.41927.freebsd-stable@dino.sk> References: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> <20080807090422.GA19885@eos.sc1.parodius.com> <200808071134.41927.freebsd-stable@dino.sk> Message-ID: On Aug 7, 2008, at 2:34 AM, Milan Obuch wrote: >> 5) Get familiar with mergemaster, specifically the side-by-side >> interactive diff feature. It looks scary the first time around, >> but once you learn that "r" applies the stuff you see on the right, >> and "l" applies the stuff you see on the left, you should be fine. > > Funny observation: "r" is on LEFT keyboard side, "l" is on RIGHT > keyboard > side. I for one have problem at times precisely for this reason, but > I know > this is an important step and one need to act with great care. Fortunately, the diffutils maintainer has accepted a patch to allow "1" and "2" (similar to http://www.pkix.net/~chuck/sdiff2.diff); hopefully your system is recent enough to include that change: Regards, -- -Chuck Begin forwarded message: > From: Chuck Swiger > Date: June 13, 2007 11:57:34 AM PDT > To: LI Xin > Cc: FreeBSD Current > Subject: Re: RFC: diff(1) update > > On Jun 13, 2007, at 2:10 AM, LI Xin wrote: >> I have done a first cut of bringing latest GNU diffutils (2.8.1) to >> the >> FreeBSD base system. This consists two parts of changes: >> [ ... ] >> Some notes: >> - I have tried to keep as most our local features (DIFF_OPTIONS, >> etc), >> but we still need to have some test cases to figure out whether >> there is >> regression. >> - Local changes are now maintained as patchsets. >> - Still need to find a better way to handle local manpage changes... >> >> Comments? > > Thanks for looking into updating diffutils, Xin. > > Paul Eggert, the diffutils maintainer, has recently adopted a patch > for sdiff which allows using "1" and "2" in addition to "l" and "r", > which is exceptionally useful when people are running mergemaster. > Also, v2.8.6 also includes a fix for invoking an editor in sdiff mode: > > Paul Eggert wrote: >> Chuck Swiger writes: >>> At least with diff-2.7 or thereabouts, invoking the >>> external editor via "e l" or "e r" would always fail and return the >>> warning from this line of diff code: >>> >>> fatal ("Subsidiary editor failed"); >> >> You can double-check, but I think that bug was fixed here: >> >> 2004-04-12 Paul Eggert >> >> * NEWS, configure.ac (AC_INIT): Version 2.8.6. >> ... >> * src/sdiff.c (check_child_status): Renamed from ck_editor_status, >> and >> accept a new arg MAX_OK_STATUS. All callers changed. >> Handle status 126/127 as per POSIX. >> > > ------ > >> Good point, thanks. I installed this: >> >> 2007-06-06 Paul Eggert >> >> * NEWS: Mention new sdiff aliases 1 and 2 for l and r. >> * doc/diff.texi (Merge Commands): Likewise. >> * src/sdiff.c (give_help): Give help for them. >> (edit): Support them. >> >> Index: NEWS >> =================================================================== >> RCS file: /cvsroot/diffutils/diffutils/NEWS,v >> retrieving revision 1.25 >> diff -u -p -r1.25 NEWS >> --- NEWS 5 Sep 2006 23:02:32 -0000 1.25 >> +++ NEWS 6 Jun 2007 23:40:12 -0000 >> @@ -14,6 +14,8 @@ User-visible changes since 2.8.7 (in "ve >> "Utility Syntax Guidelines" in the Minutes of the January 2005 >> Meeting . >> >> +* sdiff now understands '1' and '2' as synonyms for 'l' and 'r'. >> + >> Version 2.8.7 contains no user-visible changes. > > -- > -Chuck > > From besko at msu.edu Thu Aug 7 18:43:13 2008 From: besko at msu.edu (Lisa Besko) Date: Thu Aug 7 18:43:20 2008 Subject: Swapping boot disks and getting mountroot>===SOLVED In-Reply-To: <489B05D9.7030407@msu.edu> References: <4899E3AC.40201@msu.edu> <84dead720808061904v398ff7cdieaeca41ed7a8207e@mail.gmail.com> <489B05D9.7030407@msu.edu> Message-ID: <489B423F.3050102@msu.edu> I got thinks working by commenting out options ATA_STATIC_ID # Static device numbering in the kernel. I had to build a test kernel as described in /usr/src/UPDATING. I still got my mountroot> prompt but for a change is showed me some possible devices. I was able to ad0s1a to boot from. I rebooted to my working kernel and edited /etc/fstab to use ad0. Then booted my test kernel again. The system booted. I installed the kernel w/o ATA_STATIC_ID and was able to boot in my Sunfire X2100 and my X2200. LB Lisa Besko wrote: > > > Joseph Koshy wrote: >>> I notice that it finds the device ad4 but then it tries to mount root >>> from >>> /dev/ad6s1a. I've edited the fstab to have it look for ad4s1a but it >>> still >>> won't boot. Anyone have any pointers or ideas? >> >> Have you tried interrupting the boot sequence and setting new >> values for the `rootdev' and `root_disk_unit' loader variables? >> The loader(8) manual page has more information. > > No I haven't tried that yet. Will that get me to a point where I can > trust it to boot on it's own to the correct disk all the time? > > LB -- Lisa Besko From pluknet at gmail.com Thu Aug 7 21:26:08 2008 From: pluknet at gmail.com (pluknet) Date: Thu Aug 7 21:26:30 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <20080806200643.GA1554@roadrunner.spoerlein.net> References: <20080730113449.GD407@cdnetworks.co.kr> <20080804010205.GA21401@cdnetworks.co.kr> <20080804182919.GB1480@roadrunner.spoerlein.net> <200808041607.56160.jhb@freebsd.org> <20080806200643.GA1554@roadrunner.spoerlein.net> Message-ID: Hi, John. >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 0; apic id = 00 >> > fault virtual address = 0x38 >> > fault code = supervisor read, page not present >> > instruction pointer = 0x20:0xc058ec16 >> > stack pointer = 0x28:0xfb8b8ac8 >> > frame pointer = 0x28:0xfb8b8ac8 >> > code segment = base 0x0, limit 0xfffff, type 0x1b >> > = DPL 0, pres 1, def32 1, gran 1 >> > processor eflags = interrupt enabled, resume, IOPL = 0 >> > current process = 1176 (powerd) >> > db:0:kdb.enter.default> show pcpu >> > cpuid = 0 >> > curthread = 0xc4ec0aa0: pid 1176 "powerd" >> > curpcb = 0xfb8b8d90 >> > fpcurthread = none >> > idlethread = 0xc3f80cc0: pid 10 "idle: cpu0" >> > APIC ID = 0 >> > currentldt = 0x50 >> > db:0:kdb.enter.default> bt >> > Tracing pid 1176 tid 100103 td 0xc4ec0aa0 >> > device_is_attached(0,c87e6b40,fb8b8afc,0,101,...) at device_is_attached+0x6 >> > cf_set_method(c420b600,c87e6b40,64,fb8b8ba4,c87e33b4,...) at >> cf_set_method+0x6a3 >> > cpufreq_curr_sysctl(c420d840,c4207000,0,fb8b8ba4,fb8b8ba4,...) at >> cpufreq_curr_sysctl+0x232 >> > sysctl_root(fb8b8ba4,4,1,c4ec0aa0,c4501d38,...) at sysctl_root+0x137 >> > userland_sysctl(c4ec0aa0,fb8b8c14,4,0,0,...) at userland_sysctl+0x151 >> > __sysctl(c4ec0aa0,fb8b8cfc,18,fb8b8ca0,46,...) at __sysctl+0xec >> > syscall(fb8b8d38) at syscall+0x345 >> > Xint0x80_syscall() at Xint0x80_syscall+0x20 >> > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28161bd3, esp = >> 0xbfbfe8cc, ebp = 0xbfbfe8f8 --- >> > db:0:kdb.enter.default> capture off >> > Is it intentional? (kgdb) p level.rel_count $44 = 1986356271 First level.rel_set+5 are NULL in my case. (kgdb) p i $46 = 0 P.S. Same problem/hardware/bt/sysctl/dmesg on Banias 1.6GHz, worked ok on previous stable7 from Jun 16. hth, pluknet From delphij at delphij.net Thu Aug 7 22:36:37 2008 From: delphij at delphij.net (Xin LI) Date: Thu Aug 7 22:36:45 2008 Subject: ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local' In-Reply-To: <310261218093750@webmail34.yandex.ru> References: <310261218093750@webmail34.yandex.ru> Message-ID: <489B78DF.4000901@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 KES wrote: [...] | kes# make deinstall reinstall clean | ===> Deinstalling for net-mgmt/ng_ipacct | ===> ng_ipacct not installed, skipping | ===> Building for ng_ipacct-20061223 | ===> ng_ipacct (all) | Warning: Object directory not changed from original /usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct | cc -O -pipe -g -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc - -I/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct -I. -I@ - -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 - --param large-function-growth=1000 -fno-common -mno-align-long-strings - -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 - -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs - -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline - -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ng_ipacct.c | ng_ipacct.c: In function 'pcb_get_cred': | ng_ipacct.c:905: error: too few arguments to function 'in_pcblookup_local' | *** Error code 1 Newer FreeBSD versions requires a 'ucred' parameter, from my understanding it looks that one has to pass the current thread's ucred? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkibeN4ACgkQi+vbBBjt66DO6wCfeG4bbzuFs40CNR28aNFoR/ld P0UAniG1zwrzmQurBOg3yRSDejM4mEaN =mN+B -----END PGP SIGNATURE----- From delphij at delphij.net Thu Aug 7 22:55:41 2008 From: delphij at delphij.net (Xin LI) Date: Thu Aug 7 22:55:52 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> Message-ID: <489B7D62.4080606@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerrit K?hn wrote: | Hi folks, | | I have a rather new FujitsuSiemens Esprimo here with an AMD Phenom X3 | processor (triple core is somehow strange :-) and a lot of NVidia stuff | onboard. I installed 7.0-R, which ran quite well except for the bge driver | and snd_hda which both complained. | After putting in an extra networking card I was able to install some more | software and all appeared to be nice. Then I cvsupped to the recent | 7-stable as of today. My hope was that maybe the bge or the sound card | would improve from this. However, the new kernel I compiled does not run | at all. It boots up to CPU#1 and CPU#2 lauchned messages and then sits | there and does nothing anymore. I have verified this behaviour with amd64 | snapshot images from July and August to make sure I did not compile a bad | kernel. Both show the same behaviour. | Are there any ideas what has changed from 7.0-R to recent 7.0-stable that | could cause this? What can I do to debug/fix this? Could you please try disabling ACPI and boot? Additionally a 'boot -v' may reveal some useful information as well. Just some random thoughts. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkibfWEACgkQi+vbBBjt66CMKwCfcwhp75YfAKOsmPPmmXmzBGSp 3NEAn388u/YD77vpMTRS/QK6moSu3iu1 =1s3u -----END PGP SIGNATURE----- From sebastian.tymkow at gmail.com Fri Aug 8 05:58:12 2008 From: sebastian.tymkow at gmail.com (=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=) Date: Fri Aug 8 05:58:19 2008 Subject: Query timeouts on FreeBSD 7 over network In-Reply-To: <15CEC87F00BB7B4CA0E904C5FCF05646243E8601@exchangenj1> References: <15CEC87F00BB7B4CA0E904C5FCF05646243E8601@exchangenj1> Message-ID: <692660060808072258u24f5a701p67c81d9a7f8f34de@mail.gmail.com> Hi, I gave up and installed Debian (etch ) on other machine. I've tried FreeBSD 7.0 amd64 on blade machine also and it didn't work perfectly. On the same machine with Debian on board problems stopped. The most strange thing is that on other servers with FreeBSD 4.8 Stable everything works perfectly without problems even after bind upgrade. It looks like Bind and FreeBSD > 6.x have problems or maybe something is wrong with my machines. But how to explain that other system on the same machine works fie ? Best regards, Sebastian Tymk?w From unga888 at yahoo.com Fri Aug 8 06:07:04 2008 From: unga888 at yahoo.com (Unga) Date: Fri Aug 8 06:07:10 2008 Subject: sysinstall compilation issue Message-ID: <255533.64647.qm@web57001.mail.re3.yahoo.com> Hi This is i386 RELENG_7. Following section of the /usr/src/usr.sbin/sysinstall/Makefile does not generate C code properly: makedevs.c: Makefile rtermcap echo '#include ' > makedevs.c ${RTERMCAP} ansi | \ file2c 'const char termcap_ansi[] = {' ',0};' \ >> makedevs.c At compile time, above expands to: TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c Which generates C code as follows: const char termcap_ansi[] = { ,0}; That is, it generates 3 lines, which results a compilation error. I presume, intended generated code should be: const char termcap_ansi[] = {' ',0}; Am I right? That intended code can be generated by a modified statement as: TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c "const char termcap_ansi[] = {""' ',0};" What is wrong at my end? Note, I linked the rtermcap with ncursesw libraries, can that be the cause? Any ideas? Many thanks in advance. Kind regards Unga From vince at unsane.co.uk Fri Aug 8 09:10:35 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Fri Aug 8 09:10:48 2008 Subject: Upgrading from 6.x to 7.x In-Reply-To: <200808080821.35476.shinjii@maydias.com> References: <000501c8f890$185b8810$fd607e0a@Horbury.Internal> <200808080821.35476.shinjii@maydias.com> Message-ID: <489C0D86.3080702@unsane.co.uk> Warren Liddell wrote: > On Thursday 07 August 2008 23:18:34 Marc Coyles wrote: > >>> If i have read the man pages correct the command im using being ... >>> >>> # freebsd-update upgrade -r 7.0-CURRENT >>> >> # sh freebsd-update.sh -f freebsd-update.conf -r 7.0-RELEASE upgrade >> >> followed eventually by... >> >> # sh freebsd-update.sh -f freebsd-update.conf install >> >> I have just upgraded a 6.2 box to 7.0 Release following the instructions >> at >> http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade >> .html to the letter without issue (other than bind needing to be >> reinstalled from ports afterwards) >> >> L8rs! >> Marci >> > > > # freebsd-update -r 7.0-RELEASE upgrade > Looking up update.FreeBSD.org mirrors... 1 mirrors found. > Fetching public key from update1.FreeBSD.org... failed. > No mirrors remaining, giving up. > > # sh freebsd-update.sh -f freebsd-update.conf -r 7.0-RELEASE upgrade > freebsd-update.sh: Can't open freebsd-update.sh: No such file or directory > > I then did a search for the sh file .... > > # sh freebsd-update.sh -f freebsd-update.conf -r 7.0-RELEASE upgrade > File does not exist or is not readable: freebsd-update.conf > > freebsd-update is part of base system so there was no need to install it via > the port etc .. or is there ? > > no for versions of FreeBSD beyond 6.3 its in base and you dont need to install it seperately to upgrade between versions. freebsd-update -r 7.1-RELEASE upgrade seems to have an effect where 7.0-RELEASE no longer does. I have CCed freebsd-stable@ on this to see if anyone knows if this is intended or a mistake. Vince > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > From vince at unsane.co.uk Fri Aug 8 09:46:34 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Fri Aug 8 09:46:45 2008 Subject: Upgrading from 6.x to 7.x In-Reply-To: <200808081932.36648.shinjii@maydias.com> References: <000501c8f890$185b8810$fd607e0a@Horbury.Internal> <200808080821.35476.shinjii@maydias.com> <489C0D86.3080702@unsane.co.uk> <200808081932.36648.shinjii@maydias.com> Message-ID: <489C15F6.4080507@unsane.co.uk> Warren Liddell wrote: >> no for versions of FreeBSD beyond 6.3 its in base and you dont need to >> install it seperately to upgrade between versions. >> freebsd-update -r 7.1-RELEASE upgrade >> seems to have an effect where 7.0-RELEASE no longer does. I have CCed >> freebsd-stable@ on this to see if anyone knows if this is intended or a >> mistake. >> >> >> Vince >> > > # freebsd-update -r 7.1-RELEASE upgrade > Looking up update.FreeBSD.org mirrors... 1 mirrors found. > Fetching public key from update1.FreeBSD.org... failed. > No mirrors remaining, giving up. > > The getting of the public key seems to be the issue no matter how i go about > trying to upgrade .. so my question now is, why is this and are there other > mirror sites that can be used ? > > Below is my Uname -a output if it has any relevance.. > > FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE #11: Thu Aug 7 17:32:22 EST 2008 > shinjii@:/usr/obj/usr/src/sys/GENERIC amd64 > No idea if the fact you are on a -STABLE branch will matter (it could well, the box I tried to use the 7.0-RELEASE tag on was a -STABLE box too,) but my test seems to get different results to yours. Possibly an issue with the freebsd-update servers/mirrors? more likely that it doesnt support upgrading from an arbitrary point in the -STABLE tree. 10:05:58 ) 0 # freebsd-update -r 7.1-RELEASE upgrade Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 7.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/catpages world/dict world/games world/info world/manpages world/proflibs The following components of FreeBSD do not seem to be installed: src/cddl src/compat world/doc Does this look reasonable (y/n)? n (10:06:53 ) 0 # uname -a FreeBSD lobster.unsane.co.uk 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #0: Wed Jun 18 07:33:20 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 I would upgrade to a -RELEASE branch from source then try again. Vince From shinjii at maydias.com Fri Aug 8 09:50:03 2008 From: shinjii at maydias.com (Warren Liddell) Date: Fri Aug 8 09:50:11 2008 Subject: Upgrading from 6.x to 7.x In-Reply-To: <489C0D86.3080702@unsane.co.uk> References: <000501c8f890$185b8810$fd607e0a@Horbury.Internal> <200808080821.35476.shinjii@maydias.com> <489C0D86.3080702@unsane.co.uk> Message-ID: <200808081932.36648.shinjii@maydias.com> > no for versions of FreeBSD beyond 6.3 its in base and you dont need to > install it seperately to upgrade between versions. > freebsd-update -r 7.1-RELEASE upgrade > seems to have an effect where 7.0-RELEASE no longer does. I have CCed > freebsd-stable@ on this to see if anyone knows if this is intended or a > mistake. > > > Vince # freebsd-update -r 7.1-RELEASE upgrade Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching public key from update1.FreeBSD.org... failed. No mirrors remaining, giving up. The getting of the public key seems to be the issue no matter how i go about trying to upgrade .. so my question now is, why is this and are there other mirror sites that can be used ? Below is my Uname -a output if it has any relevance.. FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE #11: Thu Aug 7 17:32:22 EST 2008 shinjii@:/usr/obj/usr/src/sys/GENERIC amd64 From shinjii at maydias.com Fri Aug 8 09:50:14 2008 From: shinjii at maydias.com (Warren Liddell) Date: Fri Aug 8 09:50:22 2008 Subject: Upgrading from 6.x to 7.x In-Reply-To: <489C15F6.4080507@unsane.co.uk> References: <000501c8f890$185b8810$fd607e0a@Horbury.Internal> <200808081932.36648.shinjii@maydias.com> <489C15F6.4080507@unsane.co.uk> Message-ID: <200808081950.08029.shinjii@maydias.com> > I would upgrade to a -RELEASE branch from source then try again. > > Vince change my releng to 7 in the supfile and do a csup then do world & kernel and go from there ? From vince at unsane.co.uk Fri Aug 8 10:09:07 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Fri Aug 8 10:09:13 2008 Subject: Upgrading from 6.x to 7.x In-Reply-To: <200808081950.08029.shinjii@maydias.com> References: <000501c8f890$185b8810$fd607e0a@Horbury.Internal> <200808081932.36648.shinjii@maydias.com> <489C15F6.4080507@unsane.co.uk> <200808081950.08029.shinjii@maydias.com> Message-ID: <489C1B3F.8040809@unsane.co.uk> Warren Liddell wrote: >> I would upgrade to a -RELEASE branch from source then try again. >> >> Vince >> > > > change my releng to 7 in the supfile and do a csup then do world & kernel and > go from there ? > RELENG_7_0 for the -RELEASE 7 is -STABLE Vince > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From shinjii at maydias.com Fri Aug 8 10:24:17 2008 From: shinjii at maydias.com (Warren Liddell) Date: Fri Aug 8 10:24:31 2008 Subject: Upgrading from 6.x to 7.x In-Reply-To: <489C1B3F.8040809@unsane.co.uk> References: <000501c8f890$185b8810$fd607e0a@Horbury.Internal> <200808081950.08029.shinjii@maydias.com> <489C1B3F.8040809@unsane.co.uk> Message-ID: <200808082024.13166.shinjii@maydias.com> On Friday 08 August 2008 20:09:03 Vincent Hoffman wrote: > Warren Liddell wrote: > >> I would upgrade to a -RELEASE branch from source then try again. > >> > >> Vince > > > > change my releng to 7 in the supfile and do a csup then do world & kernel > > and go from there ? > > RELENG_7_0 for the -RELEASE > 7 is -STABLE > > Vince csup running on 7_0 system all ready backed up so lets see how well this all goes. Much tnxs to all who have supplied info on this, greatly appreciated. From pyunyh at gmail.com Fri Aug 8 10:47:45 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Aug 8 10:47:52 2008 Subject: should looking at an interface with 'ifconfig' trigger a change ? In-Reply-To: References: Message-ID: <20080808101831.GD38118@cdnetworks.co.kr> On Thu, Aug 07, 2008 at 05:27:53PM +0100, Pete French wrote: > I have a very odd problem here - two interfaces bundled using lagg > in 'failover' mode, so one interface is active and the other not being > used. if the carrier drops on the active one I expect it to > failover, but it doesnt. > > ...until I type 'ifconfig bce0' to look at the status of the interface > which has gone down. At which point it fails over properly! > > This is most odd - how can simply looking at the config of an > interface trigger the failover ? It wont fail over otherwise either - you > can leave it as long as you like and lagg wont realise that the active > has gone down. > > The interfaces here are 'bce' by the way, if that make a difference.... > Try attached patch and check whether bce(4) correctly reports link state changes. After seeing 'link state changed to UP' message, unplug the cable and see whether it reports link DOWN. The message should be printed in a second. Also try replugging cable and you should see link UP message within several seconds. Since auto-negotation takes more time you may have to wait for a while. -- Regards, Pyun YongHyeon -------------- next part -------------- --- sys/dev/mii/brgphy.c.orig 2008-01-22 10:23:10.000000000 +0900 +++ sys/dev/mii/brgphy.c 2008-01-22 12:32:41.000000000 +0900 @@ -364,16 +364,13 @@ break; } -#if 0 - /* Todo: Is this correct? */ /* Announce link loss right after it happens. */ if (sc->mii_ticks++ == 0) break; -#endif /* Only retry autonegotiation every mii_anegticks seconds. */ if (sc->mii_ticks <= sc->mii_anegticks) - goto brgphy_service_exit; + break; /* Retry autonegotiation */ From olli at lurza.secnetix.de Fri Aug 8 13:02:12 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Aug 8 13:02:19 2008 Subject: i386 vs amd64? In-Reply-To: <519867a90808070548n5eee13adwb79b62bd2fecb67a@mail.gmail.com> Message-ID: <200808081301.m78D1spC016676@lurza.secnetix.de> Eugene Kazarinov wrote: > > > [...] > > # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). > > # 5. `reboot' (in single user mode: boot -s from the loader prompt). > > # 6. `mergemaster -p' > > # 7. `make installworld' > > [...] > > Pls tell me what for I need 5 step? You need to reboot between installkernel and installworld because the new world might not run correctly with an old kernel, e.g. it might use new syscalls, or other changes happened in the ABIs between userland and kernel. That's why you have to boot into the new kernel first. Those kinds of changes happen rarely, especially on the -stable branches, but they _do_ happen. Single-user mode is required because old binaries might not run correctly with the new kernel. One example of such a change happened on 2007-08-06 in RELENG_6 (see UPDATING): An ioctl structure was changed for if_bridge, causing an incompatibility in the ifconfig(8) utility. This would break multi-user boot with the old ifconfig binary under the new kernel if you use any bridge interfaces. Of course, omitting the single-user reboot will work most of the time, because such ABI problems happen rarely. But when the rare case happens, you'll run into trouble. Therefore it is recommend to always reboot to single-user mode, even if you believe that it won't be necessary. Apart from that, it is usually good to have a quiescent system while installing the new world. Some programs might not like it when files are replaced unexpectedly beneath their butts. > #mergemaster -p && make -j8 buildworld && make -j8 buildkernel KERNCONF=KMD > && make installkernel KERNCONF=KMD && make installworld && mergemaster -iU You can do "make kernel KERNCONF=...". There's no reason to do buildkernel and installkernel separately. You can also put KERNCONF=... in /etc/make.conf so you don't have to type it each time on the commandline. > All of this I do remotely. Is this way very wrong? I understand that it's > not a "canonical" way but how I can do it right and remotely? Get remote access to the console, either using a serial console connection (physical or emulated), or remote KVM access. Or arrange to have somebody else perform the action (i.e. "remote hands"). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From markus at vervier.info Fri Aug 8 13:10:30 2008 From: markus at vervier.info (Markus Vervier) Date: Fri Aug 8 13:11:13 2008 Subject: em(4) on FreeBSD is sometimes annoying References: 20080804125138.59ed0252@zelda.local Message-ID: <489C4129.4090303@vervier.info> Hi, I just stumbled upon this thread. I experience the exact same behaviour as Martin on my Thinkpad X60: Thinkpad X60 Model: 1706GMG BIOS-Version 2.15 (7BETD4WW) FreeBSD 7.0 STABLE amd64 (from about two weeks ago) - same situtation on 7.0-RELEASE i386 -- Markus From olli at lurza.secnetix.de Fri Aug 8 13:15:21 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Aug 8 13:15:30 2008 Subject: i386 vs amd64? In-Reply-To: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> Message-ID: <200808081236.m78CagPH015579@lurza.secnetix.de> Ask Bj?rn Hansen wrote: > We got 4 new SuperMicro boxes[1] with Xeon 3320 processors. They'll > be used as firewalls / very basic routers (our network on one side, > the world via a /29 on the other side). We currently use Soekris and > PC Engine boxes for this (with custom NanoBSD images), so this will be > a bit of an upgrade. :-) > > I was planning to install pfSense on them, but I'm losing faith in > that a bit after figuring out that the pfSense project doesn't seem > all that open[2]; so I'm considering just installing "plain FreeBSD 7" > instead. > > So the question: Would I be happier with 64 or 32bit FreeBSD? Our > Linux application and database servers are all 64 bit, but they also > have 32GB RAM each. The "firewall boxes" are probably vastly overdone > with memory at 4GB each. :-) There are other reasons to prefer amd64 over i386, beside the amount of RAM and address space considerations. For example, in amd64 mode there are twice as many CPU registers available, enabling better optimizations for the C compiler. Furthermore those registers are twice as long, which means that 64bit quantities can be handled with single processor instructions. That doesn't necessarily mean that code will always run faster in amd64 mode. There have been reports of certain edge cases. But in general, amd64 code is faster. Also note that the networkign and packetfilter code uses quite a few 64bit variables (e.g. packet and byte counters). That's probably not significant for a small router, though. Bottom line: Install FreeBSD/amd64, unless you have _specific_ reasons to stay with i386. > A secondary question: Is the preferred way to upgrade a FreeBSD box > still cd /usr/src; make update && make buildworld && ... ? Yes, basically. Please see the section titled "To rebuild everything" in /usr/src/UPDATING, it lists all the steps required for an update. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure." -- Eric Allman From olli at lurza.secnetix.de Fri Aug 8 13:18:51 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Aug 8 13:18:59 2008 Subject: should looking at an interface with 'ifconfig' trigger a ?change ? In-Reply-To: <20080807173525.GB37969@citylink.fud.org.nz> Message-ID: <200808081318.m78DIaXJ017555@lurza.secnetix.de> Andrew Thompson wrote: > Pete French wrote: > > > The bce driver is not properly generating link state events. > > > > OK, that explains why it doesnt failover - but why does looking at it > > with ifconfig make a difference ? surely that should be 'read only ? > > ifconfig will cause the media status to be read from the hardware at > which time the link change is generated as it is different to the stored > value. Shouldn't that be considered a security flaw? After all, you can perform "ifconfig $IF" inside a jail to list the interface configuration, but you're not allowed to make any changes. Given your description above, it means that it is possible to modify the interface configuration (cause a failover) from within a jail. That's not good. I think that needs to be fixed, or at the very least it needs to be properly documented. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From olli at lurza.secnetix.de Fri Aug 8 13:36:39 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Aug 8 13:36:49 2008 Subject: sysinstall compilation issue In-Reply-To: <255533.64647.qm@web57001.mail.re3.yahoo.com> Message-ID: <200808081336.m78DaIoV018488@lurza.secnetix.de> Unga wrote: > This is i386 RELENG_7. > > Following section of the /usr/src/usr.sbin/sysinstall/Makefile does not generate C code properly: > > makedevs.c: Makefile rtermcap > echo '#include ' > makedevs.c > ${RTERMCAP} ansi | \ > file2c 'const char termcap_ansi[] = {' ',0};' \ > > > makedevs.c > > At compile time, above expands to: > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c > > Which generates C code as follows: > const char termcap_ansi[] = { > > ,0}; > > That is, it generates 3 lines, which results a compilation error. > > I presume, intended generated code should be: > const char termcap_ansi[] = {' ',0}; > > Am I right? No, it should generate an array containung a dump of the "ansi" termcap entry. Please see the file2c(1) manpage. > What is wrong at my end? > > Note, I linked the rtermcap with ncursesw libraries, can that be the cause? Any ideas? Yes, that's the cause. Why did you do that? FreeBSD's ncurses port contains a patch so the tgetent() function (which is used by rtermcap) returns the actual termcap entry in the buffer. The original ncurses code (which is terminfo based) doesn't do that. When you linked rtermcap with the wrong library, you restored the original behaviour of tgetent(), so the output of rtermcap was empty, so file2c produced invalid source. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From mh at kernel32.de Fri Aug 8 14:17:25 2008 From: mh at kernel32.de (Marian Hettwer) Date: Fri Aug 8 14:17:32 2008 Subject: should looking at an interface with 'ifconfig' trigger a?change ? In-Reply-To: <200808081318.m78DIaXJ017555@lurza.secnetix.de> References: <200808081318.m78DIaXJ017555@lurza.secnetix.de> Message-ID: <293d3dc9ebaee1119424aa58532d3c5d@localhost> Hi Oliver, On Fri, 8 Aug 2008 15:18:36 +0200 (CEST), Oliver Fromme wrote: > Andrew Thompson wrote: > > Pete French wrote: > > > > The bce driver is not properly generating link state events. > > > > > > OK, that explains why it doesnt failover - but why does looking at it > > > with ifconfig make a difference ? surely that should be 'read only ? > > > > ifconfig will cause the media status to be read from the hardware at > > which time the link change is generated as it is different to the > stored > > value. > > Shouldn't that be considered a security flaw? After all, > you can perform "ifconfig $IF" inside a jail to list the > interface configuration, but you're not allowed to make > any changes. > > Given your description above, it means that it is possible > to modify the interface configuration (cause a failover) > from within a jail. That's not good. I think that needs > to be fixed, or at the very least it needs to be properly > documented. > And regarding documentation. It should be documented, that lagg(4) won't work very well with bce(4). If it's nowhere documented that bce and failover with lagg doesn't work, some people might be screwed... Just my 0,02 cents ./Marian From torben.jakobsen at dk.ibm.com Fri Aug 8 14:27:31 2008 From: torben.jakobsen at dk.ibm.com (Torben Jakobsen) Date: Fri Aug 8 14:27:38 2008 Subject: AUTO: Torben Jakobsen is out of the office. (returning 2008-08-10) Message-ID: I am out of the office until 2008-08-10. I will respond to your message when I return. Please contact: - Erik Svennevig -- team/project manager - Pavan Gulati -- team/project manager - Bo Heegaard Hansen -- people manager - Lene Buch-Larsen -- resource deployment manager Note: This is an automated response to your message "?Re: should looking at an interface with 'ifconfig' trigger a ?change ?" sent on 8/8/08 15:18:36 . This is the only notification you will receive while this person is away. From hawei at free.fr Fri Aug 8 16:17:53 2008 From: hawei at free.fr (Harald Weis) Date: Fri Aug 8 16:18:00 2008 Subject: test message, please ignore Message-ID: <20080808160538.GA8851@pollux> From jfvogel at gmail.com Fri Aug 8 16:36:53 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Aug 8 16:37:04 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <489C4129.4090303@vervier.info> References: <489C4129.4090303@vervier.info> Message-ID: <2a41acea0808080936n589e277ao33ec08a75fdcbac2@mail.gmail.com> "me too" 's are of little help. Please elaborate on your "exact same", since each person's perception will be slightly different. So far I have heard nothing that sounds like a driver issue. Jack On Fri, Aug 8, 2008 at 5:50 AM, Markus Vervier wrote: > > Hi, > > I just stumbled upon this thread. I experience the exact same behaviour as > Martin on my Thinkpad X60: > > Thinkpad X60 Model: 1706GMG > BIOS-Version 2.15 (7BETD4WW) > FreeBSD 7.0 STABLE amd64 (from about two weeks ago) - same situtation on > 7.0-RELEASE i386 > > -- > Markus > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From hawei at free.fr Fri Aug 8 16:49:46 2008 From: hawei at free.fr (Harald Weis) Date: Fri Aug 8 16:50:04 2008 Subject: Audio CD problem on laptop VGN-SZ61MN Message-ID: <20080808081330.GA1203@sirius.local.net> Is there anyone out there who has installed FreeBSD on the above Sony laptop ? Both ''cat filename > /dev/dsp0.0'' or ''vlc cdda:///dev/acd0@1 are OK. If I run ''cdcontrol -f /dev/acd0 play'', there is no sound. But the output of ''cdcontrol -f /dev/acd0 status audio'' is alright. (same behaviour for cd0 instead of acd0) And the output of ''mplayer cdda://1//dev/acd0'' is: Playing cdda://1//dev/acd0. ++ WARN: open: Inappropriate ioctl for device **ERROR: fread (): Invalid argument On the other hand, DVD's play fine, for example with either ''vlc dvd:///dev/acd0@2'' or ''mplayer dvd://2'' I wonder whether the problem is related to the FAILURE line in dmesg: acd0: DVDR at ata0-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Adding ''device atapicam'' in the kernel doesn't make a difference. I found some messages concerning the FAILURE line in the mailing list archives, but no solution. Thank you in advance for any help. Harald Weis -- FreeBSD 7.0-RELEASE #0: Thu Aug 7 13:00:47 CEST 2008 From jhb at freebsd.org Fri Aug 8 16:49:51 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Aug 8 16:50:05 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <20080627031233.9DC4945047@ptavv.es.net> References: <20080627031233.9DC4945047@ptavv.es.net> Message-ID: <200808081249.28513.jhb@freebsd.org> On Thursday 26 June 2008 11:12:33 pm Kevin Oberman wrote: > > Date: Thu, 26 Jun 2008 23:53:44 +0200 > > From: Volker > > Sender: owner-freebsd-stable@freebsd.org > > > > On 12/23/-58 20:59, Kelly Black wrote: > > > Hello, > > > > > > I have a problem with loader. I recently upgraded from 6_rel to 7_rel. > > > Now when I install world there is a problem booting. > > > > > > Here is what I do: > > > cd /usr/src > > > make buildworld > > > make buildkernel KERNCONF=BLACK > > > make installkernel KERNCONF=BLACK > > > > > > At this point I can reboot and all is good. After boot I install the new world: > > > > > > cd /usr/src > > > mergemaster -p > > > reboot into single user mode > > > cd /usr/src > > > make installworld > > > mergemaster > > > > > > Now when I reboot there is a problem. I get an error that the system > > > cannot boot. Part of it looks like this: > > > Can't work out which disk we are booting from. > > > Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0: > > > > > > If I boot from a live disk and replace /boot/loader with > > > /boot/loader.old it boots up fine and everything looks good. A new > > > world and a new kernel. I would be grateful for any help or any > > > pointers. > > > > > > Sincerely, > > > Kel > > > > > > PS I do not do anything special with my loader config files: > > > > > > $ cat loader.conf > > >... > > > > Kelly, > > > > the /boot/loader.conf file does not come into play at that stage. Early > > in the loader code, loader needs to figure out, which disk (BIOS device) > > has been booted from. Until loader knows which device was booted up, > > it's unable to access any files (even loader.conf) on your boot device. > > > > As I've never seen such a problem while upgrading any system, I suspect > > your problem must be settings specific. Can you show me your kernel > > config or are you using a plain vanilla GENERIC? Which arch are we > > talking about? > > > > As I'm currently investigating another boot problem (but earlier in the > > boot chain), I'll check boot logic in the source code and may check for > > your issue, too, at that time, so it's just one effort. But please stay > > patient for some days, as I'm currently too busy. > > We just got hit by this. The loader never loads and nothing boots. But a > system admin discovered that the problem disappeared if the /boot.conf > file was deleted. It just contained '-P'. > > Once this file was removed, the system just booted up as expected. When > he changed it to -D or -h, the boot still locked up. So I had a little epiphany in the shower this morning and have a possible fix. I've suspected from the start that the hangs had to do with interrupts being disabled/enabled at the wrong time. However, I had always been assuming that the problem was interrupts being disabled when they should have been enabled. Now I think it's actually the reverse. :) Some background: There are three sorts of requests that BTX can handle that require dropping to real mode (previously this was done with virtual 8086 mode): 1) hardware interrupt, 2) user request (boot2/loader) to simulate a software interrupt (e.g. int 0x15 BIOS calls), 3) user request to perform a far call to a specified cs:ip in real mode. For all 3 of these requests, we do preserve the %eflags register at the time of the interrupt/user request and make it visible as-is to the real mode code with some possible modifications. Previously the only modifications I did was to disable interrupts (PSL_I) in case 1). When looking at this earlier, I noticed that none of the BTX clients (boot2/gptboot/loader) had ever explicitly initialized the eflags value that gets passed to BTX during vm86 requests, so the initial flags (including PSL_I) was garbage, and as a result, it was sort of random as to whether or not the real mode code for cases 2) and 3) was run with interrupts enabled or disabled. My realization this morning is that software interrupts ('int X') in real mode disable interrupts just like hardware interrupts do. Thus, my patch changes BTX to disable interrupts for both cases 1) and 2) now. I think this will fix the hangs. I'm still including the code to explicitly initialize the eflags for user requests to a known-good value. It still has interrupts enabled which means that case 3) should know always run with interrupts enabled (which is the desired state), but the client can disable interrupts in the eflags in the vm86 structure if desired. The updated patch (same URL, new patch) is at http://www.FreeBSD.org/~jhb/patches/btx_hang.patch -- John Baldwin From olli at lurza.secnetix.de Fri Aug 8 17:46:55 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Aug 8 17:47:02 2008 Subject: Audio CD problem on laptop VGN-SZ61MN In-Reply-To: <20080808081330.GA1203@sirius.local.net> Message-ID: <200808081746.m78HkQfn029890@lurza.secnetix.de> Harald Weis wrote: > Both ''cat filename > /dev/dsp0.0'' or ''vlc cdda:///dev/acd0@1 are OK. > > If I run ''cdcontrol -f /dev/acd0 play'', there is no sound. > But the output of ''cdcontrol -f /dev/acd0 status audio'' is alright. > (same behaviour for cd0 instead of acd0) Are you sure your mixer settings are OK? What's the output from /usr/sbin/mixer? Note that normal audio playback from software such as cat, vlc and mplayer go through the "pcm" channel of the mixer, while the direct CD playback (as initiated by cdcontrol) goes through the "cd" channel of the mixer. So please make sure that your "cd" channel isn't set to zero. Sometimes the channels are wired incorrectly in the hardware so it ends up a different channel -- If in doubt, just crank all the channels up to non-zero values. > And the output of ''mplayer cdda://1//dev/acd0'' is: > Playing cdda://1//dev/acd0. Are you sure this is the right syntax for mplayer? Normally I don't use mplayer for audio CDs, but I think when I tried it the syntax cd://1 or similar worked fine. You might need to have a symlink /dev/cd -> /dev/acd0c for that to work. At least I needed it back then. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio From markus at vervier.info Fri Aug 8 17:56:45 2008 From: markus at vervier.info (Markus Vervier) Date: Fri Aug 8 17:56:52 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808080936n589e277ao33ec08a75fdcbac2@mail.gmail.com> References: <489C4129.4090303@vervier.info> <2a41acea0808080936n589e277ao33ec08a75fdcbac2@mail.gmail.com> Message-ID: <489C88DB.6030000@vervier.info> Jack Vogel schrieb: > "me too" 's are of little help. Please elaborate on your "exact same", since > each person's perception will be slightly different. > > Hi Jack, maybe read it like: Thinkpad X60 1706GMG affected too, so the problem is not specific to Martins machine. I can write the same steps to reproduce the behaviour as Martin here: <--> Once again, steps to reproduce this behavior: 1) Power the laptop OFF. Really OFF, I mean. No reboots! 2) Detach the cable from NIC. 3) Boot FreeBSD. Let it pass the DHCP phase (ifconfig_em0="DHCP") until login appears. 4) Attach the cable to the NIC. 5) Voila... no link. <--> My perception is that if the em driver gets loaded without a cable being plugged in, no link can be established. I can workaround the problem when em was not build into the kernel, by unloading the em-kmod and reloading it again with the cable plugged in. If the cable is not plugged in the interface will always stay in state "no carrier". The NIC works fine under Windows / Linux on the same machine. -- Markus From mike at sentex.net Fri Aug 8 17:59:57 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Aug 8 18:00:04 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <489C88DB.6030000@vervier.info> References: <489C4129.4090303@vervier.info> <2a41acea0808080936n589e277ao33ec08a75fdcbac2@mail.gmail.com> <489C88DB.6030000@vervier.info> Message-ID: <200808081759.m78HxrHv009066@lava.sentex.ca> At 01:56 PM 8/8/2008, Markus Vervier wrote: 3) Boot FreeBSD. Let it pass the DHCP phase (ifconfig_em0="DHCP") until >login appears. >4) Attach the cable to the NIC. >5) Voila... no link. ><--> If you manually type, dhclient em0 does it work for you then ? ---Mike From markus at vervier.info Fri Aug 8 18:08:26 2008 From: markus at vervier.info (Markus Vervier) Date: Fri Aug 8 18:08:33 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <200808081759.m78HxrHv009066@lava.sentex.ca> References: <489C4129.4090303@vervier.info> <2a41acea0808080936n589e277ao33ec08a75fdcbac2@mail.gmail.com> <489C88DB.6030000@vervier.info> <200808081759.m78HxrHv009066@lava.sentex.ca> Message-ID: <489C8B99.40202@vervier.info> Mike Tancsa schrieb: > If you manually type, > dhclient em0 No, even if I type ifconfig em0 down && ifconfig em0 up it won?t work. The interface just gets no link until I reload the driver with a cable plugged. -- Markus From lakay at alcifer.org Fri Aug 8 18:12:35 2008 From: lakay at alcifer.org (Nathanael J) Date: Fri Aug 8 18:12:43 2008 Subject: Freebsd 7.0-RELEASE-p3 panics Message-ID: <7decde260808081047x2d577ffax1dea2aeb4db5d93e@mail.gmail.com> Hello, I've been having spurrious crash troubles with this box a while now and I haven't been able to figure out why. I've ran a couple memtest passes on it and it didn't pick up anything. Here's a backtrace I've been able to obtain. The kernel config is at the end. It's the generic kernel with ULE. I'm following chapter 11 of the developers' handbook, so if there's any information missing, let me know and I'll forward it over. I'm using this box as a test platform for backuppc so the only thing ever running on it is perl, or rsync wrapped in perl depending on how you look at it. I'd appreciate any help. Thanks. backuppc2# uname -a FreeBSD backuppc2.webair.com 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #0: Fri Aug 1 18:44:38 EDT 2008 root@backuppc2.webair.com:/usr/obj/usr/src/sys/CUSTOM amd64 backuppc2# kgdb kernel.debug /usr/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffc300be229a10 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff8065e222 stack pointer = 0x10:0xffffffffae417a20 frame pointer = 0x10:0xffffffffa49a3f00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 47 (syncer) trap number = 12 panic: page fault cpuid = 0 Uptime: 2h14m49s Physical memory: 4082 MB Dumping 426 MB: 411 395 379 363 347 331 315 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) list *0xffffffff8065e222 0xffffffff8065e222 is in softdep_disk_io_initiation (/usr/src/sys/ufs/ffs/ffs_softdep.c:3750). 3745 /* 3746 * Do any necessary pre-I/O processing. 3747 */ 3748 for (wk = LIST_FIRST(&bp->b_dep); wk != NULL; 3749 wk = markernext(&marker)) { 3750 LIST_INSERT_AFTER(wk, &marker, wk_list); 3751 switch (wk->wk_type) { 3752 3753 case D_PAGEDEP: 3754 initiate_write_filepage(WK_PAGEDEP(wk), bp); (kgdb) backtrace #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff804775f9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff804779fd in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff80730674 in trap_fatal (frame=0xffffff00035436a0, eva=18446742974253291728) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff80730a45 in trap_pfault (frame=0xffffffffae417970, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0xffffffff80731388 in trap (frame=0xffffffffae417970) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0xffffffff80716fee in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff8065e222 in softdep_disk_io_initiation (bp=0xffffffff9a615920) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3750 #9 0xffffffff80663d9f in ffs_geom_strategy (bo=0xffffff000363f530, bp=0xffffffff9a615920) at buf.h:436 #10 0xffffffff804dfcbf in bufwrite (bp=0xffffffff9a615920) at buf.h:429 #11 0xffffffff804d9d0f in vfs_bio_awrite (bp=0xffffffff9a615920) at buf.h:417 #12 0xffffffff804e3dc1 in vop_stdfsync (ap=0xffffffffae417bc0) at /usr/src/sys/kern/vfs_default.c:437 #13 0xffffffff804f3992 in sched_sync () at vnode_if.h:538 #14 0xffffffff80458d13 in fork_exit (callout=0xffffffff804f3350 , arg=0x0, frame=0xffffffffae417c80) at /usr/src/sys/kern/kern_fork.c:781 #15 0xffffffff807173be in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:415 #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000001 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000cc8000 in ?? () #41 0xffffffff80a50140 in tdg_maxid () #42 0xffffffff80a5c940 in tdq_cpu () #43 0xffffffff80a5c940 in tdq_cpu () #44 0xffffff00035436a0 in ?? () #45 0xffffff00035439a8 in ?? () #46 0xffffffffae417328 in ?? () #47 0x0000000000000000 in ?? () #48 0xffffffff80495ba8 in sched_switch (td=0xffffffff804f3350, newtd=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1898 #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffffae418000 ======================= cpu HAMMER ident CUSTOM # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons From jfvogel at gmail.com Fri Aug 8 18:31:28 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Aug 8 18:31:36 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <489C88DB.6030000@vervier.info> References: <489C4129.4090303@vervier.info> <2a41acea0808080936n589e277ao33ec08a75fdcbac2@mail.gmail.com> <489C88DB.6030000@vervier.info> Message-ID: <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> OK, I just got access to a machine, am going to install and see if I can repro this this afternoon. Jack On Fri, Aug 8, 2008 at 10:56 AM, Markus Vervier wrote: > Jack Vogel schrieb: >> >> "me too" 's are of little help. Please elaborate on your "exact same", >> since >> each person's perception will be slightly different. >> >> > > Hi Jack, > > maybe read it like: Thinkpad X60 1706GMG affected too, so the problem is not > specific to Martins machine. > > I can write the same steps to reproduce the behaviour as Martin here: > > <--> > Once again, steps to reproduce this behavior: > 1) Power the laptop OFF. Really OFF, I mean. No reboots! > 2) Detach the cable from NIC. > 3) Boot FreeBSD. Let it pass the DHCP phase (ifconfig_em0="DHCP") until > login appears. > 4) Attach the cable to the NIC. > 5) Voila... no link. > <--> > > My perception is that if the em driver gets loaded without a cable being > plugged in, no link can be established. > I can workaround the problem when em was not build into the kernel, by > unloading the em-kmod and reloading it > again with the cable plugged in. If the cable is not plugged in the > interface will always stay in state "no carrier". > The NIC works fine under Windows / Linux on the same machine. > > -- > Markus > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From oberman at es.net Fri Aug 8 20:04:49 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Aug 8 20:04:56 2008 Subject: Unable to build kernel Message-ID: <20080808200447.8F9954501A@ptavv.es.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080808/7f57eb52/attachment.pgp From mike at sentex.net Fri Aug 8 20:34:02 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Aug 8 20:34:09 2008 Subject: Unable to build kernel In-Reply-To: <20080808200447.8F9954501A@ptavv.es.net> References: <20080808200447.8F9954501A@ptavv.es.net> Message-ID: <200808082033.m78KXw7G009888@lava.sentex.ca> At 04:04 PM 8/8/2008, Kevin Oberman wrote: >Today I was unable to build a new kernel for 7-Stable. It dies when >linking the kernel, seemingly because of not finding the definitions for >some nfs stuff. I don't use nfs and always exclude both server and >client from my kernel. (Long config attached, if the list does not strip >nooptions NFSCLIENT # Network Filesystem Client >nooptions NFSSERVER # Network Filesystem Server >nooptions NFS_ROOT # NFS usable as root device, requires Can you build generic on its own ? What if you add to your config nooptions NFSLOCKD which recently got added to GENERIC. ---Mike From ertr1013 at student.uu.se Fri Aug 8 20:56:07 2008 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Fri Aug 8 20:56:15 2008 Subject: Unable to build kernel In-Reply-To: <20080808200447.8F9954501A@ptavv.es.net> References: <20080808200447.8F9954501A@ptavv.es.net> Message-ID: <20080808204053.GA77199@owl.midgard.homeip.net> On Fri, Aug 08, 2008 at 01:04:47PM -0700, Kevin Oberman wrote: > Today I was unable to build a new kernel for 7-Stable. It dies when > linking the kernel, seemingly because of not finding the definitions for > some nfs stuff. I don't use nfs and always exclude both server and > client from my kernel. (Long config attached, if the list does not strip > it.) At a guess you will have to exclude the nfs locking support too, which was added to GENERIC relatively recently. ('nooptions NFSLOCKD' ought to do the trick.) > > MAKE=make sh /usr/src/sys/conf/newvers.sh IBM-T43 > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > -ffreestanding -Werror vers.c > linking kernel.debug > nlm_advlock.o(.text+0x11a8): In function `nlm_advlock_internal': > /usr/src/sys/nlm/nlm_advlock.c:225: undefined reference to `nfs_vinvalbuf' > nlm_advlock.o(.text+0x1243):/usr/src/sys/nlm/nlm_advlock.c:236: undefined > reference to `nfs_ticks' > nlm_prot_impl.o(.text+0x29a1): In function `nlm_syscall': > /usr/src/sys/nlm/nlm_prot_impl.c:1482: undefined reference to `nfs_advlock_p' > nlm_prot_impl.o(.text+0x29a7):/usr/src/sys/nlm/nlm_prot_impl.c:1483: undefined > reference to `nfs_advlock_p' > nlm_prot_impl.o(.text+0x29b1):/usr/src/sys/nlm/nlm_prot_impl.c:1484: undefined > reference to `nfs_reclaim_p' > nlm_prot_impl.o(.text+0x29b7):/usr/src/sys/nlm/nlm_prot_impl.c:1485: undefined > reference to `nfs_reclaim_p' > nlm_prot_impl.o(.text+0x29cf):/usr/src/sys/nlm/nlm_prot_impl.c:1490: undefined > reference to `nfs_advlock_p' > nlm_prot_impl.o(.text+0x29d5):/usr/src/sys/nlm/nlm_prot_impl.c:1491: undefined > reference to `nfs_reclaim_p' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/IBM-T43. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > Time spent in user mode (CPU seconds) : 307.737s > Time spent in kernel mode (CPU seconds) : 34.429s > Total time : 8:12.87s > CPU utilisation (percentage) : 69.4% > Times the process was swapped : 0 > Times of major page faults : 233 > Times of minor page faults : 4231547 > Exit 1 > > I see no other reports of anything. Any ideas? > > Thanks, > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Content-Description: IBM-T43 > # > # IBM-T43 -- Kernel for IBM-T43 with debugging enabled > # > > include GENERIC > > ident IBM-T43 > > nooptions NFSCLIENT # Network Filesystem Client > nooptions NFSSERVER # Network Filesystem Server > nooptions NFS_ROOT # NFS usable as root device, requires NFSCLIENT > nooptions COMPAT_FREEBSD4 # Compatible with FreeBSD6 > nooptions COMPAT_FREEBSD5 # Compatible with FreeBSD6 > options IPFIREWALL # Start firewall at boot > options IPFIREWALL_VERBOSE # Enable logging to syslogd(8) > options IPFIREWALL_VERBOSE_LIMIT=100 # limit verbosity > options IPFIREWALL_DEFAULT_TO_ACCEPT # allow everything by default > > # Debugging for use in -current > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > nooptions INVARIANTS # Enable calls of extra sanity checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks for speeed > > # To make a uni-processor kernel, the next two are needed > nooptions SMP # Symmetric MultiProcessor Kernel > nodevice apic # I/O APIC > > # CPU frequency control (Does not work on T43!) > nodevice cpufreq > > # Bus support. > nodevice eisa > > # ATA and ATAPI devices > nodevice ataraid # ATA RAID drives > nodevice atapifd # ATAPI floppy drives > nodevice atapist # ATAPI tape drives > device atapicam # Emulate ATAPI devices as SCSI ditto via CAM > # needs CAM to be present (scbus & pass) > # SCSI Controllers > nodevice ahb # EISA AHA1742 family > nodevice ahc # AHA2940 and onboard AIC7xxx nodevices > nooptions AHC_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~128k to driver. > nodevice ahd # AHA39320/29320 and onboard AIC79xx nodevices > nooptions AHD_REG_PRETTY_PRINT # Print register bitfields in debug > # output. Adds ~215k to driver. > nodevice amd # AMD 53C974 (Tekram DC-390(T)) > nodevice hptiop # Highpoint RocketRaid 3xxx series > nodevice isp # Qlogic family > nodevice ispfw # Firmware for QLogic HBAs- normally a module > nodevice mpt # LSI-Logic MPT-Fusion > nodevice ncr # NCR/Symbios Logic > nodevice sym # NCR/Symbios Logic (newer chipsets + those of `ncr') > nodevice trm # Tekram DC395U/UW/F DC315U adapters > > nodevice adv # Advansys SCSI adapters > nodevice adw # Advansys wide SCSI adapters > nodevice aha # Adaptec 154x SCSI adapters > nodevice aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. > nodevice bt # Buslogic/Mylex MultiMaster SCSI adapters > > nodevice ncv # NCR 53C500 > nodevice nsp # Workbit Ninja SCSI-3 > nodevice stg # TMC 18C30/18C50 > > > # SCSI peripherals > device pass # SCSI passthrough device > > # RAID controllers interfaced to the SCSI subsystem > nodevice amr # AMI MegaRAID > nodevice arcmsr # Areca SATA II RAID > nodevice asr # DPT SmartRAID V, VI and Adaptec SCSI RAID > nodevice ciss # Compaq Smart RAID 5* > nodevice dpt # DPT Smartcache III, IV - See NOTES for options > nodevice hptmv # Highpoint RocketRAID 182x > nodevice hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx > nodevice iir # Intel Integrated RAID > nodevice ips # IBM (Adaptec) ServeRAID > nodevice mly # Mylex AcceleRAID/eXtremeRAID > nodevice twa # 3ware 9000 series PATA/SATA RAID > > # RAID controllers > nodevice aac # Adaptec FSA RAID > nodevice aacp # SCSI passthrough for aac (requires CAM) > nodevice ida # Compaq Smart RAID > nodevice mfi # LSI MegaRAID SAS > nodevice mlx # Mylex DAC960 family > nodevice pst # Promise Supertrak SX6000 > nodevice twe # 3ware ATA RAID > > # atkbdc0 controls both the keyboard and the PS/2 mouse > options KBD_RESETDELAY=500 > > # syscons is the default console driver, resembling an SCO console > options SC_HISTORY_SIZE=2000 > options SC_PIXEL_MODE #add support for the raster text mode > > # Parallel port > nodevice ppc > nodevice ppbus # Parallel port bus (required) > nodevice lpt # Printer > nodevice plip # TCP/IP over parallel > nodevice ppi # Parallel port interface device > nodevice vpo # Requires scbus and da > > # PCI Ethernet NICs. > nodevice de # DEC/Intel DC21x4x (``Tulip'') > nodevice em # Intel PRO/1000 adapter Gigabit Ethernet Card > nodevice ixgb # Intel PRO/10GbE Ethernet Card > nodevice le # AMD Am7900 LANCE and Am79C9xx PCnet > nodevice txp # 3Com 3cR990 (``Typhoon'') > nodevice vx # 3Com 3c590, 3c595 (``Vortex'') > > # Wireless NIC cards > nodevice wlan_scan_ap # 802.11 AP mode scanning > nodevice ath > > # Pseudo devices. > nodevice sl # Kernel SLIP > nodevice ppp # Kernel PPP > > # USB support > nodevice uhci # UHCI PCI->USB interface > nodevice ohci # OHCI PCI->USB interface > nodevice ehci # EHCI PCI->USB interface > nodevice usb # USB Bus (required) > nodevice udbp # USB Double Bulk Pipe devices > nodevice ugen # Generic > nodevice uhid # "Human Interface Devices" > nodevice ukbd # Keyboard > nodevice ulpt # Printer > nodevice umass # Disks/Mass storage - Requires scbus and da > nodevice ums # Mouse > nodevice ural # Ralink Technology RT2500USB wireless NICs > nodevice rum # Ralink Technology RT2501USB wireless NICs > nodevice urio # Diamond Rio MP3 Player > nodevice uscanner # Scanners > # USB serial devices > nodevice ucom # Generic tty coms > nodevice uark # Technologies ARK3116 based serial adapters > nodevice ubsa # Belkin F5U103 and compatible serial adapters > nodevice ubser # BWCT console serial adapters > nodevice uftdi # For FTDI usb serial adapters > nodevice uipaq # Some WinCE based devices > nodevice uplcom # Prolific PL-2303 serial adapters > nodevice uslcom # SI Labs CP2101/CP2102 serial adapters > nodevice uvisor # Visor and Palm devices > nodevice uvscom # USB serial support for DDI pocket's PHS > # USB Ethernet, requires mii > nodevice aue # ADMtek USB ethernet > nodevice axe # ASIX Electronics USB Ethernet > nodevice cdce # Generic USB over Ethernet > nodevice cue # CATC USB ethernet > nodevice kue # Kawasaki LSI USB ethernet > nodevice rue # RealTek RTL8150 USB Ethernet > > # Sound support (Requires System Management Bus for ICH) > device smbus > device iicbus > device iicbb > device intpm > device ichsmb > device smb > #device sound > #device snd_ich > -- Erik Trulsson ertr1013@student.uu.se From oberman at es.net Fri Aug 8 21:05:06 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Aug 8 21:05:13 2008 Subject: Unable to build kernel In-Reply-To: Your message of "Fri, 08 Aug 2008 16:34:01 EDT." <200808082033.m78KXw7G009888@lava.sentex.ca> Message-ID: <20080808210503.8EEEC45010@ptavv.es.net> > Date: Fri, 08 Aug 2008 16:34:01 -0400 > From: Mike Tancsa > > At 04:04 PM 8/8/2008, Kevin Oberman wrote: > >Today I was unable to build a new kernel for 7-Stable. It dies when > >linking the kernel, seemingly because of not finding the definitions for > >some nfs stuff. I don't use nfs and always exclude both server and > >client from my kernel. (Long config attached, if the list does not strip > > >nooptions NFSCLIENT # Network Filesystem Client > >nooptions NFSSERVER # Network Filesystem Server > >nooptions NFS_ROOT # NFS usable as root device, requires > > > Can you build generic on its own ? What if you add to your config > nooptions NFSLOCKD > > which recently got added to GENERIC. > Thanks, Mike (and Erik who also pointed this out) for the answer. Kernel linked just fine now that I have removed the NFS LOCKD. I should have looked at CVS for GENERIC changes. I did check UPDATING, but there was nothing there. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080808/5fe33265/attachment.pgp From rwatson at FreeBSD.org Fri Aug 8 21:21:13 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Aug 8 21:21:20 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: Message-ID: On Sun, 3 Aug 2008, Robert Watson wrote: > This is an advance warning that, late next week, I will be merging a fairly > large set of changes to the IPv4 and IPv6 protocols layered over the > inpcb/inpcbinfo kernel infrastructure. To be specific, this affects TCP, > UDP, and raw sockets on both IPv4 and IPv6. I will post a further e-mail > announcement along with patch set and schedule in a day or two once it's > prepared. Patches, which require the MFC of rwlock try-locking, which I did earlier today: http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff These incude the inpcb/inpcbinfo read/write locking changes (although not yet for raw/divert sockets). Any testing, especially with heavy UDP loads, would be much appreciated -- this are fairly complex changes, and also quite a complex MFC. Robert N M Watson Computer Laboratory University of Cambridge > > The thrust of this change is to replace the mutexes protecting the inpcb and > inpcbinfo data structures with read-write locks (rwlocks). These structures > represent, respectively, particular sockets and the global socket lists for > all socket types in IPv4 and IPv6 except for SCTP. When you run netstat, > inpcbinfo is the data structure referencing all connections, and each line in > the nestat output reflects the contents of a specific inpcb. > > In the current stage of this work, the intent is to improve performance for > datagram-related protocols on SMP systems by allowing concurrent acquisition > of both global and connection locks during receive and transmit. This is > possible because, in the common case, no connection or global state is > modified during UDP/raw receive and transmit at the IP layer, so a read lock > is sufficient to prevent data in those structures from unexpectedly changing. > For receive, socket layer state is modified, but this is separately protected > by socket layer locks. On transmit, no state is modified at any layer, so in > principle we will allow fully parallel transmit from multiple threads down to > about the routing and network interface layers, whereas previously they would > bottleneck in UDP. > > The applications targeted by this change are threaded UDP server > applications, such as BIND9, nsd, and UDP-based memcached. Kris Kennaway and > Paul Saab have done fairly extensive testing with the changes and > demonstrated significant performance improvements due to reduced contention > and overhead. Perhaps they can mention some of those numbers in a follow-up > to this post. > > The reason for the heads up is that, while carefully-tested, changes of this > sort do come with risks. We've carefully structured them so as to avoid > breaking the ABIs for netstat, etc, but it's not impossible that some > problems will arise as the changes settle. The goal, however, is to see > these performance improvements in 7.1, and since they've had a bit to shake > out in 8.x and seen some heavy use, I think now is the right time to merge > them. > > In any case, I will send out e-mail in a couple of days with a proposed merge > patch and schedule for merging, and perhaps if you are in a positition where > you might benefit from these improvements, or have interesting UDP or > raw-socket based applications running on 7.x, you could test the candidate > patch before it's merged, reporting any problems. Unless I receive negative > feedback, I will plan on merging the changes late in the week, and keep a > close eye on stable@ for any reports of problems. > > Thanks, > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From vrajan at stbernard.com Fri Aug 8 22:49:47 2008 From: vrajan at stbernard.com (Vijay Rajan) Date: Fri Aug 8 22:49:55 2008 Subject: errors building bsnmpd v1.12 on freebsd5.3 Message-ID: <57ED6273CD029C4F944A944D4F81423838198F7A97@SB-EXCHANGE1.stbernard.com> We have been trying to build bsnmpd 1.12 on freebsd 5.3 but have many weird issues building snmp_bridge, snmp_hostres & snmp_mibII modules. The errors seem to come from compiler strictness cc -fpic -DPIC -O -pipe -I/work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c -o mibII_route.So /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c: In function `sroutes_RB_INSERT_COLOR': /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c: In function `sroutes_RB_REMOVE_COLOR': /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement /work2/vrajan/head/products/rapid/freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c:516: warning: empty body in an if-statement How could the following line in freebsd5/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII_route.c throw so many errors? RB_GENERATE(sroutes, sroute, link, sroute_compare); We have not been successful in using the gcc -E option to get preprocessed code to analyze the issue. Any help will be appreciated. Thanks in advance Vijay From peterjeremy at optushome.com.au Fri Aug 8 23:12:40 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Aug 8 23:12:47 2008 Subject: i386 vs amd64? In-Reply-To: <200808081236.m78CagPH015579@lurza.secnetix.de> References: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> <200808081236.m78CagPH015579@lurza.secnetix.de> Message-ID: <20080808231232.GK64458@server.vk2pj.dyndns.org> On 2008-Aug-08 14:36:42 +0200, Oliver Fromme wrote: >For example, in amd64 mode there are twice as many CPU >registers available, enabling better optimizations for >the C compiler. Furthermore those registers are twice >as long, which means that 64bit quantities can be handled >with single processor instructions. OTOH, this means roughly 4 times as much processor state to save and restore on a context switch. It also means that longs and pointers are 64-bits instead of 32-bits, which makes executables larger (if you compare executables and libraries on disk between FreeBSD/i386 and FreeBSD/amd64, the latter are 10-15% larger). The VSZ of amd64 executables _appears_ significantly larger due to a bug in binutils and our rtld but this space is never referenced. >That doesn't necessarily mean that code will always run >faster in amd64 mode. There have been reports of certain >edge cases. But in general, amd64 code is faster. As always, the best benchmark is your own application mix. >Bottom line: Install FreeBSD/amd64, unless you have >_specific_ reasons to stay with i386. Keep in mind that, for most things, FreeBSD/amd64 can happily run 32-bit Linux and FreeBSD/i386 executables (though there's no easy way to build FreeBSD/i386 executables on FreeBSD/amd64). This does not extend to KLDs so 3rd-party 32-bit KLDs (eg the nVIDIA graphics driver). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080808/b27265a3/attachment.pgp From unixmania at gmail.com Sat Aug 9 00:17:42 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sat Aug 9 00:17:49 2008 Subject: Audio CD problem on laptop VGN-SZ61MN In-Reply-To: <20080808081330.GA1203@sirius.local.net> References: <20080808081330.GA1203@sirius.local.net> Message-ID: On Fri, Aug 8, 2008 at 5:13 AM, Harald Weis wrote: > Is there anyone out there who has installed FreeBSD on the above Sony > laptop ? > > Both ''cat filename > /dev/dsp0.0'' or ''vlc cdda:///dev/acd0@1 are OK. > > If I run ''cdcontrol -f /dev/acd0 play'', there is no sound. > But the output of ''cdcontrol -f /dev/acd0 status audio'' is alright. > (same behaviour for cd0 instead of acd0) > > And the output of ''mplayer cdda://1//dev/acd0'' is: > Playing cdda://1//dev/acd0. > ++ WARN: open: Inappropriate ioctl for device > **ERROR: fread (): Invalid argument > > On the other hand, DVD's play fine, for example with > either ''vlc dvd:///dev/acd0@2'' or ''mplayer dvd://2'' > > I wonder whether the problem is related to the FAILURE line in dmesg: > acd0: DVDR at ata0-master UDMA33 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > cd0 at ata0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > > Adding ''device atapicam'' in the kernel doesn't make a difference. > > I found some messages concerning the FAILURE line in the mailing list > archives, but no solution. Same result on my notebook (HP nx6320) and this is not a surprise. The "mixer" command does not show a "cd" input, meaning that there is no input port for the analog audio output of the CD drive (if any). The "status audio" arguments instructs cdcontrol to inquire the drive, not the audio device. NetBSD's "cdplay" supports digital transfer mode since version 4.0. Perhaps this feature could be implemented on cdcontrol. -- If you think things can't get worse it's probably only because you lack sufficient imagination. From zanchey at ucc.gu.uwa.edu.au Sat Aug 9 06:07:56 2008 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Sat Aug 9 06:08:05 2008 Subject: should looking at an interface with 'ifconfig' trigger a ?change ? In-Reply-To: <200808081318.m78DIaXJ017555@lurza.secnetix.de> References: <200808081318.m78DIaXJ017555@lurza.secnetix.de> Message-ID: On Fri, 8 Aug 2008, Oliver Fromme wrote: > Andrew Thompson wrote: > > ifconfig will cause the media status to be read from the hardware at > > which time the link change is generated as it is different to the stored > > value. > > Shouldn't that be considered a security flaw? After all, > you can perform "ifconfig $IF" inside a jail to list the > interface configuration, but you're not allowed to make > any changes. > > Given your description above, it means that it is possible > to modify the interface configuration (cause a failover) > from within a jail. That's not good. I think that needs > to be fixed, or at the very least it needs to be properly > documented. I can't see how this is a security flaw. The link is already down; ifconfig is merely updating the OS' knowlege of the link status to be closer to reality. David Adam zanchey@ucc.gu.uwa.edu.au From thompsa at FreeBSD.org Sat Aug 9 06:20:55 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sat Aug 9 06:21:09 2008 Subject: should looking at an interface with 'ifconfig' trigger a?change ? In-Reply-To: <293d3dc9ebaee1119424aa58532d3c5d@localhost> References: <200808081318.m78DIaXJ017555@lurza.secnetix.de> <293d3dc9ebaee1119424aa58532d3c5d@localhost> Message-ID: <20080809062049.GC95107@citylink.fud.org.nz> On Fri, Aug 08, 2008 at 04:00:56PM +0200, Marian Hettwer wrote: > Hi Oliver, > > On Fri, 8 Aug 2008 15:18:36 +0200 (CEST), Oliver Fromme > > > > Shouldn't that be considered a security flaw? After all, > > you can perform "ifconfig $IF" inside a jail to list the > > interface configuration, but you're not allowed to make > > any changes. > > > > Given your description above, it means that it is possible > > to modify the interface configuration (cause a failover) > > from within a jail. That's not good. I think that needs > > to be fixed, or at the very least it needs to be properly > > documented. > > > And regarding documentation. It should be documented, that lagg(4) won't > work very well with bce(4). If it's nowhere documented that bce and > failover with lagg doesn't work, some people might be screwed... I guess so although bce will not be the only one. Also spanning tree, carp and dhclient use link state events too, possibly others. Andrew From thompsa at FreeBSD.org Sat Aug 9 06:23:46 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sat Aug 9 06:23:59 2008 Subject: should looking at an interface with 'ifconfig' trigger a ?change ? In-Reply-To: <200808081318.m78DIaXJ017555@lurza.secnetix.de> References: <20080807173525.GB37969@citylink.fud.org.nz> <200808081318.m78DIaXJ017555@lurza.secnetix.de> Message-ID: <20080809060126.GB95107@citylink.fud.org.nz> On Fri, Aug 08, 2008 at 03:18:36PM +0200, Oliver Fromme wrote: > Andrew Thompson wrote: > > Pete French wrote: > > > > The bce driver is not properly generating link state events. > > > > > > OK, that explains why it doesnt failover - but why does looking at it > > > with ifconfig make a difference ? surely that should be 'read only ? > > > > ifconfig will cause the media status to be read from the hardware at > > which time the link change is generated as it is different to the stored > > value. > > Shouldn't that be considered a security flaw? After all, > you can perform "ifconfig $IF" inside a jail to list the > interface configuration, but you're not allowed to make > any changes. > > Given your description above, it means that it is possible > to modify the interface configuration (cause a failover) > from within a jail. That's not good. I think that needs > to be fixed, or at the very least it needs to be properly > documented. I dont think its a security flaw, this is meant to happen automatically after all. You cant make ifconfig change the link status within a jail, just catch up on reality. Andrew From eugen at kuzbass.ru Sat Aug 9 09:50:47 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sat Aug 9 09:50:54 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <200808081249.28513.jhb@freebsd.org> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> Message-ID: <20080809092200.GA70050@svzserv.kemerovo.su> On Fri, Aug 08, 2008 at 12:49:28PM -0400, John Baldwin wrote: > My realization this morning is that software interrupts ('int X') in real mode > disable interrupts just like hardware interrupts do. Thus, my patch changes > BTX to disable interrupts for both cases 1) and 2) now. I think this will > fix the hangs. I'm still including the code to explicitly initialize the > eflags for user requests to a known-good value. It still has interrupts > enabled which means that case 3) should know always run with interrupts > enabled (which is the desired state), but the client can disable interrupts > in the eflags in the vm86 structure if desired. > > The updated patch (same URL, new patch) is at > http://www.FreeBSD.org/~jhb/patches/btx_hang.patch Sigh, it does not fix my problem described here: http://groups.google.ru/group/muc.lists.freebsd.stable/browse_thread/thread/538039f40b469e2a I've just updated my 7.0-STABLE to latest sources, applied your patch using "cd /usr/src; patch -p6 < ~/btx_hang.patch", it has applied cleanly. Then I've rebuilt and reinstalled kernel and world and rebooted. My problem persists as it was. Eugene Grosbein From kostikbel at gmail.com Sat Aug 9 10:18:41 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Aug 9 10:18:48 2008 Subject: Freebsd 7.0-RELEASE-p3 panics In-Reply-To: <7decde260808081047x2d577ffax1dea2aeb4db5d93e@mail.gmail.com> References: <7decde260808081047x2d577ffax1dea2aeb4db5d93e@mail.gmail.com> Message-ID: <20080809101834.GL97161@deviant.kiev.zoral.com.ua> On Fri, Aug 08, 2008 at 01:47:18PM -0400, Nathanael J wrote: > Hello, > > I've been having spurrious crash troubles with this box a while now > and I haven't been able to figure out why. I've ran a couple memtest > passes on it and it didn't pick up anything. Here's a backtrace I've > been able to obtain. The kernel config is at the end. It's the generic > kernel with ULE. I'm following chapter 11 of the developers' handbook, > so if there's any information missing, let me know and I'll forward it > over. I'm using this box as a test platform for backuppc so the only > thing ever running on it is perl, or rsync wrapped in perl depending > on how you look at it. I'd appreciate any help. Thanks. > > backuppc2# uname -a > FreeBSD backuppc2.webair.com 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #0: > Fri Aug 1 18:44:38 EDT 2008 > root@backuppc2.webair.com:/usr/obj/usr/src/sys/CUSTOM amd64 > > backuppc2# kgdb kernel.debug /usr/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xffffc300be229a10 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff8065e222 > stack pointer = 0x10:0xffffffffae417a20 > frame pointer = 0x10:0xffffffffa49a3f00 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 47 (syncer) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 2h14m49s > Physical memory: 4082 MB > Dumping 426 MB: 411 395 379 363 347 331 315 299 283 267 251 235 219 > 203 187 171 155 139 123 107 91 75 59 43 27 11 > > #0 doadump () at pcpu.h:194 > 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb) list *0xffffffff8065e222 > 0xffffffff8065e222 is in softdep_disk_io_initiation > (/usr/src/sys/ufs/ffs/ffs_softdep.c:3750). > 3745 /* > 3746 * Do any necessary pre-I/O processing. > 3747 */ > 3748 for (wk = LIST_FIRST(&bp->b_dep); wk != NULL; > 3749 wk = markernext(&marker)) { > 3750 LIST_INSERT_AFTER(wk, &marker, wk_list); > 3751 switch (wk->wk_type) { > 3752 > 3753 case D_PAGEDEP: > 3754 initiate_write_filepage(WK_PAGEDEP(wk), bp); > (kgdb) backtrace > #0 doadump () at pcpu.h:194 > #1 0x0000000000000004 in ?? () > #2 0xffffffff804775f9 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff804779fd in panic (fmt=0x104
bounds>) at /usr/src/sys/kern/kern_shutdown.c:563 > #4 0xffffffff80730674 in trap_fatal (frame=0xffffff00035436a0, > eva=18446742974253291728) at /usr/src/sys/amd64/amd64/trap.c:724 > #5 0xffffffff80730a45 in trap_pfault (frame=0xffffffffae417970, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 > #6 0xffffffff80731388 in trap (frame=0xffffffffae417970) at > /usr/src/sys/amd64/amd64/trap.c:410 > #7 0xffffffff80716fee in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:169 > #8 0xffffffff8065e222 in softdep_disk_io_initiation > (bp=0xffffffff9a615920) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3750 > #9 0xffffffff80663d9f in ffs_geom_strategy (bo=0xffffff000363f530, > bp=0xffffffff9a615920) at buf.h:436 > #10 0xffffffff804dfcbf in bufwrite (bp=0xffffffff9a615920) at buf.h:429 > #11 0xffffffff804d9d0f in vfs_bio_awrite (bp=0xffffffff9a615920) at buf.h:417 > #12 0xffffffff804e3dc1 in vop_stdfsync (ap=0xffffffffae417bc0) at > /usr/src/sys/kern/vfs_default.c:437 > #13 0xffffffff804f3992 in sched_sync () at vnode_if.h:538 > #14 0xffffffff80458d13 in fork_exit (callout=0xffffffff804f3350 > , arg=0x0, frame=0xffffffffae417c80) at > /usr/src/sys/kern/kern_fork.c:781 > #15 0xffffffff807173be in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:415 This might be fixed by r177513 on HEAD, MFCed to RELENG_7 as r179082. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080809/6d7aea2e/attachment.pgp From kes-kes at yandex.ru Sat Aug 9 10:24:25 2008 From: kes-kes at yandex.ru (KES) Date: Sat Aug 9 10:24:33 2008 Subject: IMPORTANT! Network is unreachable Message-ID: <142431218277454@webmail85.yandex.ru> # uname -a FreeBSD gorodok.kes.net.ua 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #0: Sun Aug 3 13:18:21 EEST 2008 kes@gorodok.kes.net.ua:/usr/obj/usr/src/sys/KES_KERN_v7 i386 # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.16.1 UGS 0 3758 rl0 10.0.0.0/16 10.11.16.2 UG 0 150 rl0 10.11.15.0/24 link#2 UC 0 0 rl1 10.11.16.0/24 link#1 UC 0 0 rl0 10.11.16.1 00:e0:4c:59:50:7e UHLW 2 421 rl0 953 10.11.16.2 00:03:79:01:9b:d0 UHLW 2 0 rl0 786 127.0.0.1 127.0.0.1 UH 0 122 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 # ifconfig rl0 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0e:2e:db:4f:d4 inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xffffff00 broadcast 10.11.16.255 media: Ethernet autoselect (100baseTX ) status: active # ifconfig rl0 add 10.10.16.3/28 # ifconfig rl0 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0e:2e:db:4f:d4 inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.10.16.3 netmask 0xfffffff0 broadcast 10.10.16.15 media: Ethernet autoselect (100baseTX ) status: active # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.16.1 UGS 0 2751 rl0 10.0.0.0/16 10.11.16.2 UG 0 142 rl0 10.10.16.0/28 link#1 UC 0 0 rl0 10.10.16.3 00:0e:2e:db:4f:d4 UHLW 1 6 lo0 10.11.15.0/24 link#2 UC 0 0 rl1 10.11.16.0/24 link#1 UC 0 0 rl0 10.11.16.1 00:e0:4c:59:50:7e UHLW 2 119 rl0 1176 10.11.16.2 00:03:79:01:9b:d0 UHLW 2 0 rl0 1093 127.0.0.1 127.0.0.1 UH 0 122 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 After 5 min: # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.16.1 UGS 0 2859 rl0 10.0.0.0/16 10.11.16.2 UG 0 142 rl0 10.10.16.0/28 link#1 UC 0 0 rl0 10.10.16.3 00:0e:2e:db:4f:d4 UHLW 1 6 lo0 10.11.15.0/24 link#2 UC 0 0 rl1 10.11.16.0/24 10.11.16.14 UGC 1 0 rl0 10.11.16.1 10.11.16.14 UGHW 1 298 rl0 127.0.0.1 127.0.0.1 UH 0 122 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 Notice second link#1 disappeared # cat /var/log/messages Aug 9 12:54:58 gorodok kernel: arplookup 10.11.16.14 failed: host is not on local network Aug 9 12:54:58 gorodok kernel: arpresolve: can't allocate route for 10.11.16.14 Aug 9 12:54:59 gorodok kernel: arplookup 10.11.16.14 failed: host is not on local network Aug 9 12:54:59 gorodok kernel: arpresolve: can't allocate route for 10.11.16.14 Aug 9 12:55:00 gorodok kernel: arplookup 10.11.16.14 failed: host is not on local network Aug 9 12:55:00 gorodok kernel: arpresolve: can't allocate route for 10.11.16.14 Aug 9 12:59:59 gorodok kernel: arplookup 10.11.16.1 failed: host is not on local network Aug 9 12:59:59 gorodok kernel: arpresolve: can't allocate route for 10.11.16.1 Aug 9 12:59:59 gorodok kernel: arplookup 10.11.16.1 failed: host is not on local network Aug 9 12:59:59 gorodok kernel: arpresolve: can't allocate route for 10.11.16.1 And this repeats each 5min #netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.16.1 UGS 0 2902 rl0 10.0.0.0/16 10.11.16.2 UG 0 145 rl0 10.10.16.0/28 link#1 UC 0 0 rl0 10.10.16.3 00:0e:2e:db:4f:d4 UHLW 1 6 lo0 10.11.15.0/24 link#2 UC 0 0 rl1 10.11.16.0/24 link#1 UC 0 0 rl0 10.11.16.1 00:e0:4c:59:50:7e UHLW 1 2 rl0 1199 127.0.0.1 127.0.0.1 UH 0 122 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 Another 5 min left and this line appears again 10.11.16.0/24 link#1 UC 0 0 rl0 It seems this bug appears when multiple nets appear on same interface on 7.0-RELEASE-p3 on 7.0-STABLE this bug appears when you start routed daemon. In FreeBSD 6.3 this bug does not appear From rwatson at FreeBSD.org Sat Aug 9 11:05:59 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 9 11:06:06 2008 Subject: should looking at an interface with 'ifconfig' trigger a ?change ? In-Reply-To: <200808081318.m78DIaXJ017555@lurza.secnetix.de> References: <200808081318.m78DIaXJ017555@lurza.secnetix.de> Message-ID: On Fri, 8 Aug 2008, Oliver Fromme wrote: > Andrew Thompson wrote: > > Pete French wrote: > > > > The bce driver is not properly generating link state events. > > > > > > OK, that explains why it doesnt failover - but why does looking at it > > > with ifconfig make a difference ? surely that should be 'read only ? > > > > ifconfig will cause the media status to be read from the hardware at which > > time the link change is generated as it is different to the stored value. > > Shouldn't that be considered a security flaw? After all, you can perform > "ifconfig $IF" inside a jail to list the interface configuration, but you're > not allowed to make any changes. > > Given your description above, it means that it is possible to modify the > interface configuration (cause a failover) from within a jail. That's not > good. I think that needs to be fixed, or at the very least it needs to be > properly documented. While obviously a serious bug (link state notifications are required so that, for example, aggregates can take interfaces going down, or up, into account), I don't see this as a security flaw. The administrator intends for the higher abstraction state transition to be triggered by the lower one, but the problem is that the time it takes for that notification to take place is effectively non-deterministic. If they didn't want the higher level transition to take place, then they shouldn't have configured it that way. On the whole, we make no attempt to limit covert channels from jails to the host system, and there are potentially lots of interactions between them, so its not a violation of the security policy for jails. That said, this definitely needs to be fixed, as things like fail-over and routing updates happen pretty poorly otherwise. The epistemology of security flaws is complicated, needless to say... Robert N M Watson Computer Laboratory University of Cambridge From andrew at modulus.org Sat Aug 9 11:14:01 2008 From: andrew at modulus.org (Andrew Snow) Date: Sat Aug 9 11:14:08 2008 Subject: IMPORTANT! Network is unreachable In-Reply-To: <142431218277454@webmail85.yandex.ru> References: <142431218277454@webmail85.yandex.ru> Message-ID: <489D7BF1.2070709@modulus.org> Usually if there is more than IP in a given subnet on an interface, you give it a /32 netmask. Only the first IP in a subnet should have the full netmask. So your example should look like this: inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 KES wrote: > # uname -a > FreeBSD gorodok.kes.net.ua 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #0: Sun Aug 3 13:18:21 EEST 2008 kes@gorodok.kes.net.ua:/usr/obj/usr/src/sys/KES_KERN_v7 i386 > # netstat -nr > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 10.11.16.1 UGS 0 3758 rl0 > 10.0.0.0/16 10.11.16.2 UG 0 150 rl0 > 10.11.15.0/24 link#2 UC 0 0 rl1 > 10.11.16.0/24 link#1 UC 0 0 rl0 > 10.11.16.1 00:e0:4c:59:50:7e UHLW 2 421 rl0 953 > 10.11.16.2 00:03:79:01:9b:d0 UHLW 2 0 rl0 786 > 127.0.0.1 127.0.0.1 UH 0 122 lo0 > > Internet6: > Destination Gateway Flags Netif Expire > ::1 ::1 UHL lo0 > fe80::%lo0/64 fe80::1%lo0 U lo0 > fe80::1%lo0 link#4 UHL lo0 > ff01:4::/32 fe80::1%lo0 UC lo0 > ff02::%lo0/32 fe80::1%lo0 UC lo0 > # ifconfig rl0 > rl0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:0e:2e:db:4f:d4 > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > inet 10.11.16.9 netmask 0xffffff00 broadcast 10.11.16.255 > media: Ethernet autoselect (100baseTX ) > status: active From uspoerlein at gmail.com Sat Aug 9 11:29:49 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Sat Aug 9 11:29:55 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <200808061811.28200.jhb@freebsd.org> References: <20080730113449.GD407@cdnetworks.co.kr> <200808041607.56160.jhb@freebsd.org> <20080806200643.GA1554@roadrunner.spoerlein.net> <200808061811.28200.jhb@freebsd.org> Message-ID: <20080809111637.GA1798@roadrunner.spoerlein.net> Hi John, I now figured out the "who", the "why" still eludes me. So, after your MFC of ichss.c on June 27th the device now attaches at my laptop. It didn't before, so it could cause no trouble. With ichss loaded, the kernel will panic 1-3 minutes after powerd has been started (if I kill powerd early enough, it seems pretty stable). I'm now running a kernel from 2008-08-08 with hint.ichss.0.disabled="1" Applying your patch to kern_cpu.c does not help though. I'll be happy to try further patches to make ichss behave well, although I'll never use it for this laptop, as EST is the only technique useful on this old Pentium-M. > > Will also disable p4tcc. This was not attaching during the RELENG_6 > > times but leads to ridiculous rates of 75 MHz. > > If p4tcc attaching is new, that might point to the culprit. A good quick test > would be to disable individual cpufreq drivers to find out which one causes > the panic. p4tcc attaching was new relative to RELENG_6, not relative to my working 7.x kernel of 2008-06-13. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From uspoerlein at gmail.com Sat Aug 9 11:56:51 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Sat Aug 9 11:56:58 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <20080809092200.GA70050@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> <20080809092200.GA70050@svzserv.kemerovo.su> Message-ID: <20080809115642.GB1798@roadrunner.spoerlein.net> On Sat, 09.08.2008 at 17:22:01 +0800, Eugene Grosbein wrote: > On Fri, Aug 08, 2008 at 12:49:28PM -0400, John Baldwin wrote: > > > My realization this morning is that software interrupts ('int X') in real mode > > disable interrupts just like hardware interrupts do. Thus, my patch changes > > BTX to disable interrupts for both cases 1) and 2) now. I think this will > > fix the hangs. I'm still including the code to explicitly initialize the > > eflags for user requests to a known-good value. It still has interrupts > > enabled which means that case 3) should know always run with interrupts > > enabled (which is the desired state), but the client can disable interrupts > > in the eflags in the vm86 structure if desired. > > > > The updated patch (same URL, new patch) is at > > http://www.FreeBSD.org/~jhb/patches/btx_hang.patch > > Sigh, it does not fix my problem described here: > > http://groups.google.ru/group/muc.lists.freebsd.stable/browse_thread/thread/538039f40b469e2a > > I've just updated my 7.0-STABLE to latest sources, applied your patch > using "cd /usr/src; patch -p6 < ~/btx_hang.patch", it has applied cleanly. > Then I've rebuilt and reinstalled kernel and world and rebooted. > My problem persists as it was. I'm not sure about which piece of code you are talking here (boot0, boot1, boot2, loader?) But if it's one of the former, you dont need to installworld, but install new boot blocks using either fdisk -B or bsdlabel -B (or both). hth, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From m.seaman at infracaninophile.co.uk Sat Aug 9 12:22:41 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sat Aug 9 12:22:49 2008 Subject: IMPORTANT! Network is unreachable In-Reply-To: <489D7BF1.2070709@modulus.org> References: <142431218277454@webmail85.yandex.ru> <489D7BF1.2070709@modulus.org> Message-ID: <489D8C03.5050707@infracaninophile.co.uk> Andrew Snow wrote: > > Usually if there is more than IP in a given subnet on an interface, you > give it a /32 netmask. Only the first IP in a subnet should have the > full netmask. > > So your example should look like this: > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 /32 netmasks for 2nd and subsequent IP alias addresses used to be mandatory and are arguably more correct, but nowadays you can use the actual netmask for the network instead. Was fixed a year or two ago. It's a wetware compatibility thing -- other unixoid OSes never had the /32 netmask requirement, and it kept tripping people up when swapping between OSes. Unfortunately I can't say exactly what the problem the OP is experiencing is due to, but the way routes are appearing and disappearing on a 5 minute timescale does suggest dynamic routing problems to me. As a work-around, if the OP wanted to override the information routed gets from the network, then he could use /etc/gateways to have the local routed append some static routes to the routing table -- see routed(8) for the gory details. Losing a route for a directly attached network looks like a bug to me though. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080809/b815b597/signature.pgp From eugen at kuzbass.ru Sat Aug 9 13:02:15 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sat Aug 9 13:02:23 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <20080809115642.GB1798@roadrunner.spoerlein.net> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> <20080809092200.GA70050@svzserv.kemerovo.su> <20080809115642.GB1798@roadrunner.spoerlein.net> Message-ID: <20080809130211.GA27931@svzserv.kemerovo.su> On Sat, Aug 09, 2008 at 01:56:42PM +0200, Ulrich Spoerlein wrote: > > > The updated patch (same URL, new patch) is at > > > http://www.FreeBSD.org/~jhb/patches/btx_hang.patch > > > > Sigh, it does not fix my problem described here: > > > > http://groups.google.ru/group/muc.lists.freebsd.stable/browse_thread/thread/538039f40b469e2a > > > > I've just updated my 7.0-STABLE to latest sources, applied your patch > > using "cd /usr/src; patch -p6 < ~/btx_hang.patch", it has applied cleanly. > > Then I've rebuilt and reinstalled kernel and world and rebooted. > > My problem persists as it was. > > I'm not sure about which piece of code you are talking here (boot0, > boot1, boot2, loader?) But if it's one of the former, you dont need to > installworld, but install new boot blocks using either fdisk -B or > bsdlabel -B (or both). As Subject: says, I'm talking about /boot/loader and its command prompt. Eugene Grosbein From kes-kes at yandex.ru Sat Aug 9 13:23:43 2008 From: kes-kes at yandex.ru (KES) Date: Sat Aug 9 13:23:51 2008 Subject: Fwd: IMPORTANT! Network is unreachable Message-ID: <358831218288212@webmail24.yandex.ru> 09.08.08, 16:22, "Matthew Seaman" : > Andrew Snow wrote: > > > > Usually if there is more than IP in a given subnet on an interface, you > > give it a /32 netmask. Only the first IP in a subnet should have the > > full netmask. > > > > So your example should look like this: > > > > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 > /32 netmasks for 2nd and subsequent IP alias addresses used to be > mandatory and are arguably more correct, but nowadays you can use > the actual netmask for the network instead. Was fixed a year or > two ago. It's a wetware compatibility thing -- other unixoid OSes > never had the /32 netmask requirement, and it kept tripping people up > when swapping between OSes. > Unfortunately I can't say exactly what the problem the OP is experiencing > is due to, but the way routes are appearing and disappearing on a 5 > minute timescale does suggest dynamic routing problems to me. As a > work-around, if the OP wanted to override the information routed gets > from the network, then he could use /etc/gateways to have the local > routed append some static routes to the routing table -- see routed(8) > for the gory details. Losing a route for a directly attached network > looks like a bug to me though. > Cheers, > Matthew > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 /24 mask on each IPs on same interfaces is working fine on FreeBSD 6.3 So I do not think that problem is with the network mask. Because of even ping 10.11.16.14 returns network is unreachable! Now when I upgraded to v7 I see trouble described earlier. So this is must be counted as BUG of v7 5min period is seen without routed. With routed I get next picture: start routed: network is unreachable stop routed: network still unreacheable start routed: network is reachable stop routed: network is reacheable start routed: network is unreachable again The thing which is very interesting is: Why period is 5 min? From hawei at free.fr Sat Aug 9 14:14:06 2008 From: hawei at free.fr (Harald Weis) Date: Sat Aug 9 14:14:13 2008 Subject: Audio CD problem on laptop VGN-SZ61MN In-Reply-To: References: <20080808081330.GA1203@sirius.local.net> Message-ID: <20080809140339.GA1522@sirius.local.net> On Fri, Aug 08, 2008 at 09:17:40PM -0300, Carlos A. M. dos Santos wrote: > On Fri, Aug 8, 2008 at 5:13 AM, Harald Weis wrote: > > acd0: DVDR at ata0-master UDMA33 > > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > > cd0 at ata0 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > > cd0: 33.000MB/s transfers > > cd0: Attempt to query device size failed: NOT READY, Medium not present > Same result on my notebook (HP nx6320) and this is not a surprise. The > "mixer" command does not show a "cd" input, meaning that there is no > input port for the analog audio output of the CD drive (if any). The > "status audio" arguments instructs cdcontrol to inquire the drive, not > the audio device. > > NetBSD's "cdplay" supports digital transfer mode since version 4.0. > Perhaps this feature could be implemented on cdcontrol. Yes, that explains what happens on my notebook and corresponds to what the Handbook says: If all goes well, you should now have a functioning sound card. If your CD-ROM or DVD-ROM drive's audio-out pins are properly connected to your sound card, you can put a CD in the drive and play it with cdcontrol(1): % cdcontrol -f /dev/acd0 play 1 Indeed, both the 'mixer' command and the (much more comfortable) 'rexima' port show only 5 mixer devices: Mixer vol is currently set to 12:12 Mixer pcm is currently set to 30:30 Mixer speaker is currently set to 8:8 Mixer mic is currently set to 0:0 Mixer rec is currently set to 0:0 There is no 'cd' mixer device, and the only mixer device file on this notebook is '/dev/mixer0'. But this does not explain why mplayer, in contrast with vlc, refuses to play the CD, does it ? What is the meaning and reason of the above FAILURE lines ? 2 identical lines with the GENERIC kernel, 1 single line, if I add 'device atapicam'. That is apparently the only difference between the two cases. Thank you again and in advance for any further help. Harald -- FreeBSD 7.0-RELEASE #0: Thu Aug 7 13:00:47 CEST 2008 From unixmania at gmail.com Sat Aug 9 14:56:25 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sat Aug 9 14:56:32 2008 Subject: Audio CD problem on laptop VGN-SZ61MN In-Reply-To: <20080809140339.GA1522@sirius.local.net> References: <20080808081330.GA1203@sirius.local.net> <20080809140339.GA1522@sirius.local.net> Message-ID: On Sat, Aug 9, 2008 at 11:03 AM, Harald Weis wrote: > On Fri, Aug 08, 2008 at 09:17:40PM -0300, Carlos A. M. dos Santos wrote: >> On Fri, Aug 8, 2008 at 5:13 AM, Harald Weis wrote: > >> > acd0: DVDR at ata0-master UDMA33 >> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 >> > cd0 at ata0 bus 0 target 0 lun 0 >> > cd0: Removable CD-ROM SCSI-0 device >> > cd0: 33.000MB/s transfers >> > cd0: Attempt to query device size failed: NOT READY, Medium not present > >> Same result on my notebook (HP nx6320) and this is not a surprise. The >> "mixer" command does not show a "cd" input, meaning that there is no >> input port for the analog audio output of the CD drive (if any). The >> "status audio" arguments instructs cdcontrol to inquire the drive, not >> the audio device. >> >> NetBSD's "cdplay" supports digital transfer mode since version 4.0. >> Perhaps this feature could be implemented on cdcontrol. > > Yes, that explains what happens on my notebook and corresponds to > what the Handbook says: > If all goes well, you should now have a functioning sound card. If your > CD-ROM or DVD-ROM drive's audio-out pins are properly connected to your > sound card, you can put a CD in the drive and play it with > cdcontrol(1): > % cdcontrol -f /dev/acd0 play 1 > > Indeed, both the 'mixer' command and the (much more comfortable) 'rexima' > port show only 5 mixer devices: > Mixer vol is currently set to 12:12 > Mixer pcm is currently set to 30:30 > Mixer speaker is currently set to 8:8 > Mixer mic is currently set to 0:0 > Mixer rec is currently set to 0:0 > > There is no 'cd' mixer device, and the only mixer device file on > this notebook is '/dev/mixer0'. > > But this does not explain why mplayer, in contrast with vlc, refuses > to play the CD, does it ? No, doesn't. On my notebook I'm able to play audio CDs with mplayer using either your command syntax, "mplayer cdda://1//dev/acd0" and with the simpler one "mplayer cdda://1". The audio is bad, however (has periodic interruptions). This is certainly a problem in mplayer since GXine works fine. > What is the meaning and reason of the above FAILURE lines ? > 2 identical lines with the GENERIC kernel, > 1 single line, if I add 'device atapicam'. I doubt atapican has something to do with your problem but you can check this by booting with GENERIC and issue "kldload atapicam" later. I did it here and had no additional problem with mplayer besides the bumpy audio output. I guess your problem is in the CD drive. I suggest you to do three things: 1. Try to insert the CD and wait until it stops pinning before starting mplayer. Some drives are a bit lazy on media recognition. 2. Run "truss mplayer ..." and look for error messages. 3. Attempt to use a different player. Xine and/or one of its alternate front-ends like GXine or Kaffeine are good choices. -- If you think things can't get worse it's probably only because you lack sufficient imagination. From cliftonr at lava.net Sat Aug 9 18:37:24 2008 From: cliftonr at lava.net (Clifton Royston) Date: Sat Aug 9 18:37:32 2008 Subject: Fwd: IMPORTANT! Network is unreachable In-Reply-To: <358831218288212@webmail24.yandex.ru> References: <358831218288212@webmail24.yandex.ru> Message-ID: <20080809183721.GA9982@lava.net> On Sat, Aug 09, 2008 at 05:23:32PM +0400, KES wrote: > 09.08.08, 16:22, "Matthew Seaman" : > > Andrew Snow wrote: > > > Usually if there is more than IP in a given subnet on an interface, you > > > give it a /32 netmask. Only the first IP in a subnet should have the > > > full netmask. > > > > > > So your example should look like this: > > > > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 > > /32 netmasks for 2nd and subsequent IP alias addresses used to be > > mandatory and are arguably more correct, but nowadays you can use > > the actual netmask for the network instead. Was fixed a year or > > two ago. It's a wetware compatibility thing -- other unixoid OSes > > never had the /32 netmask requirement, and it kept tripping people up > > when swapping between OSes. > > Unfortunately I can't say exactly what the problem the OP is experiencing > > is due to, but the way routes are appearing and disappearing on a 5 > > minute timescale does suggest dynamic routing problems to me. As a > > work-around, if the OP wanted to override the information routed gets > > from the network, then he could use /etc/gateways to have the local > > routed append some static routes to the routing table -- see routed(8) > > for the gory details. Losing a route for a directly attached network > > looks like a bug to me though. ... > > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 > /24 mask on each IPs on same interfaces is working fine on FreeBSD 6.3 > So I do not think that problem is with the network mask. Because of even ping 10.11.16.14 > returns network is unreachable! > Now when I upgraded to v7 I see trouble described earlier. > So this is must be counted as BUG of v7 I happened to see recently a report of a similar problem with 7.0 on a private mailing list. Again, there were multiple IP addresses configured within the main subnet of the interface (this time configured as /32s on other physical interfaces) and again, after a while the system lost connectivity to its main subnet and "forgot" how to ARP for addresses on the interface. An important similarity - the routing info like yours showed the attached network with the G flag, as being reachable via the gateway address within the same subnet. I can't troubleshoot this, no access to the system in question, but I thought it might help to know that others have run into the same problem. > The thing which is very interesting is: > Why period is 5 min? Might be something to do with ARP? Not sure. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From jhb at freebsd.org Sat Aug 9 21:02:27 2008 From: jhb at freebsd.org (John Baldwin) Date: Sat Aug 9 21:03:24 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <20080809130211.GA27931@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <20080809115642.GB1798@roadrunner.spoerlein.net> <20080809130211.GA27931@svzserv.kemerovo.su> Message-ID: <200808091557.21767.jhb@freebsd.org> On Saturday 09 August 2008 09:02:12 am Eugene Grosbein wrote: > On Sat, Aug 09, 2008 at 01:56:42PM +0200, Ulrich Spoerlein wrote: > > > > The updated patch (same URL, new patch) is at > > > > http://www.FreeBSD.org/~jhb/patches/btx_hang.patch > > > > > > Sigh, it does not fix my problem described here: > > > > > > http://groups.google.ru/group/muc.lists.freebsd.stable/browse_thread/th > > >read/538039f40b469e2a > > > > > > I've just updated my 7.0-STABLE to latest sources, applied your patch > > > using "cd /usr/src; patch -p6 < ~/btx_hang.patch", it has applied > > > cleanly. Then I've rebuilt and reinstalled kernel and world and > > > rebooted. My problem persists as it was. > > > > I'm not sure about which piece of code you are talking here (boot0, > > boot1, boot2, loader?) But if it's one of the former, you dont need to > > installworld, but install new boot blocks using either fdisk -B or > > bsdlabel -B (or both). > > As Subject: says, I'm talking about /boot/loader and its command prompt. As you are getting BTX faults that is likely a separate issue. You will need to get a copy of the BTX fault message somehow. -- John Baldwin From jhb at freebsd.org Sat Aug 9 21:17:47 2008 From: jhb at freebsd.org (John Baldwin) Date: Sat Aug 9 21:17:53 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <20080809092200.GA70050@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> <20080809092200.GA70050@svzserv.kemerovo.su> Message-ID: <200808091717.31780.jhb@freebsd.org> On Saturday 09 August 2008 05:22:01 am Eugene Grosbein wrote: > On Fri, Aug 08, 2008 at 12:49:28PM -0400, John Baldwin wrote: > > My realization this morning is that software interrupts ('int X') in real > > mode disable interrupts just like hardware interrupts do. Thus, my patch > > changes BTX to disable interrupts for both cases 1) and 2) now. I think > > this will fix the hangs. I'm still including the code to explicitly > > initialize the eflags for user requests to a known-good value. It still > > has interrupts enabled which means that case 3) should know always run > > with interrupts enabled (which is the desired state), but the client can > > disable interrupts in the eflags in the vm86 structure if desired. > > > > The updated patch (same URL, new patch) is at > > http://www.FreeBSD.org/~jhb/patches/btx_hang.patch > > Sigh, it does not fix my problem described here: > > http://groups.google.ru/group/muc.lists.freebsd.stable/browse_thread/thread >/538039f40b469e2a > > I've just updated my 7.0-STABLE to latest sources, applied your patch > using "cd /usr/src; patch -p6 < ~/btx_hang.patch", it has applied cleanly. > Then I've rebuilt and reinstalled kernel and world and rebooted. > My problem persists as it was. In addition to my earlier message, it would probably be good to narrow down what breaks the loader for you. For example, does it work ok over serial and only break on vidconsole? Also, if you just backout sys/boot/i386/btx to 7.0-release and leave the rest of the sys/boot tree at 7.0-stable, do you get a working loader? -- John Baldwin From ler at lerctr.org Sun Aug 10 01:17:51 2008 From: ler at lerctr.org (Larry Rosenman) Date: Sun Aug 10 01:18:22 2008 Subject: IPMI Console: No luck once OS is booted Message-ID: <20080809195935.F4976@borg> I have a current RELENG_7 running on: http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm with the -3+ IPMI card. I can interact with the BIOS, etc, but no joy once we get past the loader. Anyone have ideas? Attached is the kernel config, and the /var/run/dmesg.boot file. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -------------- next part -------------- # # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.475 2007/04/10 21:40:12 pjd Exp $ cpu HAMMER ident BORG # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_4BSD # 4BSD scheduler options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. #options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT options INCLUDE_CONFIG_FILE # Debugging for use in -current options KDB # Enable kernel debugger support. options KDB_TRACE # Enable kernel debugger support. options KDB_UNATTENDED # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options STACK #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives device atapicam # ATA CAM Layer options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) device sg # Linux SG Stuff # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # 802.11 AMRR support # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners ############# # The cpufreq(4) driver provides support for non-ACPI CPU frequency control device cpufreq # Direct Rendering modules for 3D acceleration. device drm # DRM core module required by DRM drivers device radeondrm # ATI Radeon options HWPMC_HOOKS device smbus # Bus support, required for smb below. device intpm device ichsmb device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge device crypto # core crypto support device cryptodev # /dev/crypto for access to h/w device rndtest # FIPS 140-2 entropy tester device ipmi options SCTP options BREAK_TO_DEBUGGER options ALT_BREAK_TO_DEBUGGER device coretemp # Core temp (CORE procs and newer) -------------- next part -------------- Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #2: Fri Aug 8 22:41:48 CDT 2008 root@borg.lerctr.org:/usr/obj/usr/src/sys/BORG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5120 @ 1.86GHz (1862.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4284047360 (4085 MB) avail memory = 4113506304 (3922 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2000-0x201f mem 0xd8000000-0xd801ffff irq 18 at device 0.0 on pci6 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:8e:9f:f3 em1: port 0x2020-0x203f mem 0xd8020000-0xd803ffff irq 19 at device 0.1 on pci6 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:8e:9f:f2 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pci0: at device 8.0 (no driver attached) pcib10: irq 17 at device 28.0 on pci0 pci10: on pcib10 uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8500400-0xd85007ff irq 17 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered umass0: on uhub3 ums0: on uhub3 ums0: X report 0x0022 not supported device_attach: ums0 attach returned 6 pcib11: at device 30.0 on pci0 pci11: on pcib11 vgapci0: port 0x3000-0x30ff mem 0xd0000000-0xd7ffffff,0xd8200000-0xd820ffff irq 18 at device 1.0 on pci11 drm0: on vgapci0 info: [drm] Initialized radeon 1.25.0 20060524 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x18a0-0x18a7,0x1874-0x1877,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd8500800-0xd8500bff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 6 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: [ITHREAD] ichsmb0: port 0x1100-0x111f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa orm0: at iomem 0xc0000-0xcafff,0xcb000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 6 ZFS storage pool version 6 acd0: DMA limited to UDMA33, controller found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 ad4: 381554MB at ata2-master SATA300 ad6: 381554MB at ata3-master SATA300 ad8: 476940MB at ata4-master SATA300 ad10: 381554MB at ata5-master SATA300 ad12: 381554MB at ata6-master SATA300 ad14: 381554MB at ata7-master SATA300 ipmi0: IPMI device rev. 1, firmware rev. 1.2, version 2.0 ipmi0: Number of channels 8 ipmi0: Attached watchdog acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! cd1 at ata0 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-3 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a em0: link state changed to UP From alfred at freebsd.org Sun Aug 10 01:42:11 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Sun Aug 10 01:42:19 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: <20080804020228.GG1663@tnn.dglawrence.com> <20080807060556.GD16977@elvis.mu.org> Message-ID: <20080810014211.GY16977@elvis.mu.org> Robert, reviews of sorecv_drgram: /* XXXRW: sbwait() may not be as happy without sblock(). */ error = sbwait(&so->so_rcv); Does not need XXX, sbwait waits for data, it's not really related to sblock(). remove comment. The variable orig_resid can be removed, I think the purpose of it is to to restart blocking in the "generic sorecv" case, in your code you only set it, you never reference it. -Alfred * Robert Watson [080806 23:37] wrote: > > On Wed, 6 Aug 2008, Alfred Perlstein wrote: > > >* David G Lawrence [080805 11:37] wrote: > >>>The thrust of this change is to replace the mutexes protecting the inpcb > >>>and inpcbinfo data structures with read-write locks (rwlocks). These > >> > >> That's really cool and directly affects my current work project. I'm > >>developing (have developed, actually) a multi-threaded, 5000+ member > >>VoIP/SIP conferencing server called Nconnect. It a primarily UDP > >>application running on FreeBSD 7. This generates and receives about > >>250,000 UDP packets a second, with 200 byte packets, resulting in about > >>400Mbps of traffic in each direction. The current bottleneck is the > >>kernel UDP processing. It should be possible to scale to 10000+ members > >>if kernel UDP processing had optimal concurrency. > >> Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm > >>looking forward to the MFC. > > > >David, one thing I noticed was that it appears that UDP sockets are > >serialized for copyout. > > > >Mainly that the socket is sblock()'d while the uiomove happens. > > > >I was trying to figure out a way to bypass this somehow. Perhaps just > >dequeuing and unlocking, the copyout after dropping the sblock. > > > >If there's some error, then requeue or discard the packet. > > > >I'll have to think about it. > > Or you can use the soreceive_dgram implementation in 8.x, which I will at > some point MFC once I'm comfortable it doesn't contain any serious bugs. > > Robert N M Watson > Computer Laboratory > University of Cambridge -- - Alfred Perlstein From ler at lerctr.org Sun Aug 10 02:54:45 2008 From: ler at lerctr.org (Larry Rosenman) Date: Sun Aug 10 02:54:52 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: <20080809195935.F4976@borg> References: <20080809195935.F4976@borg> Message-ID: <20080809215249.T5563@borg> On Sat, 9 Aug 2008, Larry Rosenman wrote: > I have a current RELENG_7 running on: > http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm > > with the -3+ IPMI card. > > I can interact with the BIOS, etc, but no joy once we get past the loader. > > Anyone have ideas? > > Attached is the kernel config, and the /var/run/dmesg.boot file. I hate it when I post something, and then look at one setting on the card, and fix it myself. There is a key release timeout checkbox on the keyboard/mouse settings tab for the KVM that wasn't checked. Checking it fixed it. Sorry for the noise. :( > > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From shinjii at maydias.com Sun Aug 10 04:34:05 2008 From: shinjii at maydias.com (Warren Liddell) Date: Sun Aug 10 04:34:13 2008 Subject: Wireless net Card In-Reply-To: <20080807002141.319b3ffd@verizon.net> References: <200808051748.55133.shinjii@maydias.com> <200808070641.53857.shinjii@maydias.com> <20080807002141.319b3ffd@verizon.net> Message-ID: <200808101433.54554.shinjii@maydias.com> I downloaded the drivers for the chipset my belkin wireless card has, used ndisgen to create the kernel module, which all went aok .. however when trying to load the module it hard hangs the machine to the point of it restarting itself .. is there something i perhaps mybe missing or am i out in the cold in not being able to use this wireless card untill some time a freebsd driver is done ? From eugen at kuzbass.ru Sun Aug 10 05:24:53 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Aug 10 05:25:00 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <200808091557.21767.jhb@freebsd.org> References: <20080627031233.9DC4945047@ptavv.es.net> <20080809115642.GB1798@roadrunner.spoerlein.net> <20080809130211.GA27931@svzserv.kemerovo.su> <200808091557.21767.jhb@freebsd.org> Message-ID: <20080810052450.GA95676@svzserv.kemerovo.su> On Sat, Aug 09, 2008 at 03:57:21PM -0400, John Baldwin wrote: > As you are getting BTX faults that is likely a separate issue. You will need > to get a copy of the BTX fault message somehow. I've got a message from BTX only once and cannot reproduce it. However, I get loader hangs almost always while trying to type something in its loader prompt after a character or two entered. This machine is my home desktop and I can do any debugging needed, just ask. I can also use serial console, if needed. Eugene Grosbein From eugen at kuzbass.ru Sun Aug 10 06:27:31 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Aug 10 06:27:38 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <200808091717.31780.jhb@freebsd.org> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> <20080809092200.GA70050@svzserv.kemerovo.su> <200808091717.31780.jhb@freebsd.org> Message-ID: <20080810062726.GA3979@svzserv.kemerovo.su> On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote: > In addition to my earlier message, it would probably be good to narrow down > what breaks the loader for you. For example, does it work ok over serial and > only break on vidconsole? Also, if you just backout sys/boot/i386/btx to > 7.0-release and leave the rest of the sys/boot tree at 7.0-stable, do you get > a working loader? I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got working loader! I'll try to establish serial console and retest with RELENG_7 sources. Eugene Grosbein From hawei at free.fr Sun Aug 10 06:48:35 2008 From: hawei at free.fr (Harald Weis) Date: Sun Aug 10 06:48:42 2008 Subject: Audio CD problem on laptop VGN-SZ61MN In-Reply-To: References: <20080808081330.GA1203@sirius.local.net> <20080809140339.GA1522@sirius.local.net> Message-ID: <20080810065417.GA1164@pollux> On Sat, Aug 09, 2008 at 11:56:23AM -0300, Carlos A. M. dos Santos wrote: > 1. Try to insert the CD and wait until it stops pinning before > starting mplayer. Some drives are a bit lazy on media recognition. > > 2. Run "truss mplayer ..." and look for error messages. > > 3. Attempt to use a different player. Xine and/or one of its alternate > front-ends like GXine or Kaffeine are good choices. I'll be away from keyboard for two weeks or so. I shall reply then as soon as possible. Thanks again, Carlos. Bye Harald From eugen at kuzbass.ru Sun Aug 10 08:15:13 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Aug 10 08:15:20 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <200808091717.31780.jhb@freebsd.org> References: <20080627031233.9DC4945047@ptavv.es.net> <200808081249.28513.jhb@freebsd.org> <20080809092200.GA70050@svzserv.kemerovo.su> <200808091717.31780.jhb@freebsd.org> Message-ID: <20080810081509.GA21050@svzserv.kemerovo.su> On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote: > > Sigh, it does not fix my problem described here: > > http://groups.google.ru/group/muc.lists.freebsd.stable/browse_thread/thread > >/538039f40b469e2a > > I've just updated my 7.0-STABLE to latest sources, applied your patch > > using "cd /usr/src; patch -p6 < ~/btx_hang.patch", it has applied cleanly. > > Then I've rebuilt and reinstalled kernel and world and rebooted. > > My problem persists as it was. > > In addition to my earlier message, it would probably be good to narrow down > what breaks the loader for you. For example, does it work ok over serial and > only break on vidconsole? I've established serial console, switched back to 7.0-STABLE sources plus your patch and found that while vidconsole hangs, serial console is not affected and command prompt works without a problem with it. Eugene Grosbein From ler at lerctr.org Sun Aug 10 13:24:50 2008 From: ler at lerctr.org (Larry Rosenman) Date: Sun Aug 10 13:24:58 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: <20080809215249.T5563@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> Message-ID: <20080810082410.X1306@borg> On Sat, 9 Aug 2008, Larry Rosenman wrote: > On Sat, 9 Aug 2008, Larry Rosenman wrote: > >> I have a current RELENG_7 running on: >> http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >> >> with the -3+ IPMI card. >> >> I can interact with the BIOS, etc, but no joy once we get past the loader. >> >> Anyone have ideas? >> >> Attached is the kernel config, and the /var/run/dmesg.boot file. > > I hate it when I post something, and then look at one setting on the > card, and fix it myself. > > There is a key release timeout checkbox on the keyboard/mouse > settings tab for the KVM that wasn't checked. Checking it > fixed it. > > Sorry for the noise. :( Actually, it worked *ONCE*, and now is not behaving itself. Any ideas from other SuperMicro users? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From andrew at modulus.org Sun Aug 10 13:26:37 2008 From: andrew at modulus.org (Andrew Snow) Date: Sun Aug 10 13:26:45 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: <20080810082410.X1306@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> Message-ID: <489EEC85.9070600@modulus.org> Larry Rosenman wrote: >> There is a key release timeout checkbox on the keyboard/mouse >> settings tab for the KVM that wasn't checked. Checking it >> fixed it. >> >> Sorry for the noise. :( > Actually, it worked *ONCE*, and now is not behaving itself. > > Any ideas from other SuperMicro users? In the IPMI card's web interface, I remember having to fiddle with the "Keyboard/Mouse emulation" option to solve this problem. Try changing to the alternative settings. From daryl at isletech.net Sun Aug 10 14:00:26 2008 From: daryl at isletech.net (Daryl Richards) Date: Sun Aug 10 14:00:34 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: <20080810082410.X1306@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> Message-ID: What NIC does your server use? I'm currently trying to figure out a similar issue with my server, which use bge(4) I have a Sun Fire X2200. I can access the LOM no problem once Linux or Solaris is booted. But, once FreeBSD boots, it's no longer accessible from the NIC. Serial still works fine, it's just access via web or ssh. This happens from a fresh install, and also I've rebuild to -STABLE, and no joy either. These two cases might be related. On 10-Aug-08, at 9:24 AM, Larry Rosenman wrote: > On Sat, 9 Aug 2008, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> I have a current RELENG_7 running on: http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>> with the -3+ IPMI card. >>> I can interact with the BIOS, etc, but no joy once we get past the >>> loader. >>> Anyone have ideas? >>> Attached is the kernel config, and the /var/run/dmesg.boot file. >> >> I hate it when I post something, and then look at one setting on the >> card, and fix it myself. >> >> There is a key release timeout checkbox on the keyboard/mouse >> settings tab for the KVM that wasn't checked. Checking it >> fixed it. >> >> Sorry for the noise. :( > Actually, it worked *ONCE*, and now is not behaving itself. > > Any ideas from other SuperMicro users? > > -- > Larry Rosenman http://www.lerctr.org/~ler > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From ler at lerctr.org Sun Aug 10 15:23:05 2008 From: ler at lerctr.org (Larry Rosenman) Date: Sun Aug 10 15:23:12 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> Message-ID: <20080810102225.V1945@borg> On Sun, 10 Aug 2008, David Duchscher wrote: > On Aug 10, 2008, at 8:24 AM, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> On Sat, 9 Aug 2008, Larry Rosenman wrote: >>> >>>> I have a current RELENG_7 running on: >>>> http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>>> with the -3+ IPMI card. >>>> I can interact with the BIOS, etc, but no joy once we get past the >>>> loader. >>>> Anyone have ideas? >>>> Attached is the kernel config, and the /var/run/dmesg.boot file. >>> >>> I hate it when I post something, and then look at one setting on the >>> card, and fix it myself. >>> >>> There is a key release timeout checkbox on the keyboard/mouse >>> settings tab for the KVM that wasn't checked. Checking it >>> fixed it. >>> >>> Sorry for the noise. :( >> Actually, it worked *ONCE*, and now is not behaving itself. >> >> Any ideas from other SuperMicro users? > > > I don't have that IPMI card but I can say we have other cards of theirs > working. I would make sure the card is at the latest version of firmware. > The AOC-SIMSO(+) card was not detected correctly until we upgraded. I don't > know why the card is going away when freebsd boots since I assume you are on > the dedicated LAN interface with its own IP address. Yes. It's not going away, just doesn't see the key strokes. > > We do have a few issues with Supermiro IPMI and FreeBSD that share the Intel > NIC (em) with the OS. Once the NIC is detected, you can't talk to the IPMI > card until the NIC is configured with ifconfig. Even just an ifconfig up > will wake things back up. We ended up removing the em driver from the kernel > and loading it as a module to reduce this window. > > The other issue is with bridging since the IPMI packets get gobbled up and > never make it too the bridge. > > I do need to file PRs for these one of these days... > -- > DaveD > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From daved at tamu.edu Sun Aug 10 15:25:20 2008 From: daved at tamu.edu (David Duchscher) Date: Sun Aug 10 15:25:27 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: <20080810082410.X1306@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> Message-ID: <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> On Aug 10, 2008, at 8:24 AM, Larry Rosenman wrote: > On Sat, 9 Aug 2008, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> I have a current RELENG_7 running on: http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>> with the -3+ IPMI card. >>> I can interact with the BIOS, etc, but no joy once we get past the >>> loader. >>> Anyone have ideas? >>> Attached is the kernel config, and the /var/run/dmesg.boot file. >> >> I hate it when I post something, and then look at one setting on the >> card, and fix it myself. >> >> There is a key release timeout checkbox on the keyboard/mouse >> settings tab for the KVM that wasn't checked. Checking it >> fixed it. >> >> Sorry for the noise. :( > Actually, it worked *ONCE*, and now is not behaving itself. > > Any ideas from other SuperMicro users? I don't have that IPMI card but I can say we have other cards of theirs working. I would make sure the card is at the latest version of firmware. The AOC-SIMSO(+) card was not detected correctly until we upgraded. I don't know why the card is going away when freebsd boots since I assume you are on the dedicated LAN interface with its own IP address. We do have a few issues with Supermiro IPMI and FreeBSD that share the Intel NIC (em) with the OS. Once the NIC is detected, you can't talk to the IPMI card until the NIC is configured with ifconfig. Even just an ifconfig up will wake things back up. We ended up removing the em driver from the kernel and loading it as a module to reduce this window. The other issue is with bridging since the IPMI packets get gobbled up and never make it too the bridge. I do need to file PRs for these one of these days... -- DaveD From ler at lerctr.org Sun Aug 10 15:53:36 2008 From: ler at lerctr.org (Larry Rosenman) Date: Sun Aug 10 15:53:42 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> Message-ID: <20080810105252.S2191@borg> On Sun, 10 Aug 2008, Daryl Richards wrote: > What NIC does your server use? I'm currently trying to figure out a similar > issue with my server, which use bge(4) em(4), and the IPMI card has it's own NIC. > > I have a Sun Fire X2200. I can access the LOM no problem once Linux or > Solaris is booted. But, once FreeBSD boots, it's no longer accessible from > the NIC. Serial still works fine, it's just access via web or ssh. > > This happens from a fresh install, and also I've rebuild to -STABLE, and no > joy either. > > These two cases might be related. Hrm. That's interesting. > > On 10-Aug-08, at 9:24 AM, Larry Rosenman wrote: > >> On Sat, 9 Aug 2008, Larry Rosenman wrote: >> >>> On Sat, 9 Aug 2008, Larry Rosenman wrote: >>> >>>> I have a current RELENG_7 running on: >>>> http://www.supermicro.com/products/system/4U/7045/SYS-7045B-TR+.cfm >>>> with the -3+ IPMI card. >>>> I can interact with the BIOS, etc, but no joy once we get past the >>>> loader. >>>> Anyone have ideas? >>>> Attached is the kernel config, and the /var/run/dmesg.boot file. >>> >>> I hate it when I post something, and then look at one setting on the >>> card, and fix it myself. >>> >>> There is a key release timeout checkbox on the keyboard/mouse >>> settings tab for the KVM that wasn't checked. Checking it >>> fixed it. >>> >>> Sorry for the noise. :( >> Actually, it worked *ONCE*, and now is not behaving itself. >> >> Any ideas from other SuperMicro users? >> >> -- >> Larry Rosenman http://www.lerctr.org/~ler >> Phone: +1 512-248-2683 E-Mail: ler@lerctr.org >> US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From daved at tamu.edu Sun Aug 10 16:26:21 2008 From: daved at tamu.edu (David Duchscher) Date: Sun Aug 10 16:26:27 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: <20080810102225.V1945@borg> References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> Message-ID: On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: >> I don't have that IPMI card but I can say we have other cards of >> theirs working. I would make sure the card is at the latest >> version of firmware. The AOC-SIMSO(+) card was not detected >> correctly until we upgraded. I don't know why the card is going >> away when freebsd boots since I assume you are on the dedicated LAN >> interface with its own IP address. > Yes. It's not going away, just doesn't see the key strokes. Looking through your dmesg file, I don't see a USB keyboard being attached. On my system, the virtual keyboard is a USB keyboard. ukbd0: on uhub3 kbd2 at ukbd0 -- DaveD From ler at lerctr.org Sun Aug 10 17:03:41 2008 From: ler at lerctr.org (Larry Rosenman) Date: Sun Aug 10 17:03:48 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> <57BE2631-7AED-443A-88E4-62456C048DD4@tamu.edu> <20080810102225.V1945@borg> Message-ID: <20080810120156.O1324@borg> On Sun, 10 Aug 2008, David Duchscher wrote: > On Aug 10, 2008, at 10:22 AM, Larry Rosenman wrote: > >>> I don't have that IPMI card but I can say we have other cards of theirs >>> working. I would make sure the card is at the latest version of firmware. >>> The AOC-SIMSO(+) card was not detected correctly until we upgraded. I >>> don't know why the card is going away when freebsd boots since I assume >>> you are on the dedicated LAN interface with its own IP address. >> Yes. It's not going away, just doesn't see the key strokes. > > Looking through your dmesg file, I don't see a USB keyboard being attached. > On my system, the virtual keyboard is a USB keyboard. > > ukbd0: on uhub3 > kbd2 at ukbd0 Good catch. When I set it to disable USB Mass Storage when no image is loaded, the ukbd came alive, and I'm typing this on the IPMI Console. Thanks! > > -- > DaveD > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From kes-kes at yandex.ru Sun Aug 10 19:50:46 2008 From: kes-kes at yandex.ru (KES) Date: Sun Aug 10 19:50:54 2008 Subject: IMPORTANT! Network is unreachable In-Reply-To: <20080809143019.GB3984@home.opsec.eu> References: <358831218288212@webmail24.yandex.ru> <20080809143019.GB3984@home.opsec.eu> Message-ID: <375251218397837@webmail25.yandex.ru> 09.08.08, 18:30, "Kurt Jaeger" : > Hi! > > So I do not think that problem is with the network mask. Because of even ping 10.11.16.14 > > returns network is unreachable! > > Now when I upgraded to v7 I see trouble described earlier. > > So this is must be counted as BUG of v7 > It might be some issue with ARP timeouts ? 10.11.16.14 is local address tcpdump on the interface with this address shows nothing >The system learns > the other IPs using some indirect way and forgets it as soon > as the arp address times out ? I do not think so. Because of when I ping local address 10.11.16.14 for an our without breaking this ping. So mac address can not die because of timeout. It dissappears from kernel routing table by some other cause. I do not know which cause > > 5min period is seen without routed. > > With routed I get next picture: > > start routed: network is unreachable > > stop routed: network still unreacheable > > start routed: network is reachable > > stop routed: network is reacheable > > start routed: network is unreachable again > > > > The thing which is very interesting is: > > Why period is 5 min? > Why do you run routed ? I want to use RIP > Why don't you just statically assign the routes ? Because of I have two links to same place router1 --- LAN1 --- router2 | / LAN2 LAN3 | / router3 ---------/ router1: 10.0.16.1/24, 10.10.16.8/24 router2: 10.11.16.1/24, 10.0.16.3/24 router3: 10.11.16.14/24, 10.10.16.3/24 LAN1: 10.0.16.0 LAN2: 10.10.16.0 LAN3: 10.11.16.0 router3: rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0e:2e:db:4f:d4 inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.10.16.3 netmask 0xfffffff0 broadcast 10.10.16.15 media: Ethernet autoselect (100baseTX ) status: active I add 10.10.16.3 address to rl0 by mistake. It must be on rl1 interface. But when I added it I lose connection to my LAN. I think this behavior is bug so I describe problem in letters earlier From kes-kes at yandex.ru Sun Aug 10 20:03:59 2008 From: kes-kes at yandex.ru (KES) Date: Sun Aug 10 20:04:06 2008 Subject: IMPORTANT! Network is unreachable Message-ID: <666661218398631@webmail23.yandex.ru> 09.08.08, 22:37, "Clifton Royston" : > On Sat, Aug 09, 2008 at 05:23:32PM +0400, KES wrote: > > 09.08.08, 16:22, "Matthew Seaman" : > > > Andrew Snow wrote: > > > > Usually if there is more than IP in a given subnet on an interface, you > > > > give it a /32 netmask. Only the first IP in a subnet should have the > > > > full netmask. > > > > > > > > So your example should look like this: > > > > > > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 > > > /32 netmasks for 2nd and subsequent IP alias addresses used to be > > > mandatory and are arguably more correct, but nowadays you can use > > > the actual netmask for the network instead. Was fixed a year or > > > two ago. It's a wetware compatibility thing -- other unixoid OSes > > > never had the /32 netmask requirement, and it kept tripping people up > > > when swapping between OSes. > > > Unfortunately I can't say exactly what the problem the OP is experiencing > > > is due to, but the way routes are appearing and disappearing on a 5 > > > minute timescale does suggest dynamic routing problems to me. As a > > > work-around, if the OP wanted to override the information routed gets > > > from the network, then he could use /etc/gateways to have the local > > > routed append some static routes to the routing table -- see routed(8) > > > for the gory details. Losing a route for a directly attached network > > > looks like a bug to me though. > ... > > > > > > inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 > > > > inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 > > /24 mask on each IPs on same interfaces is working fine on FreeBSD 6.3 > > So I do not think that problem is with the network mask. Because of even ping 10.11.16.14 > > returns network is unreachable! > > Now when I upgraded to v7 I see trouble described earlier. > > So this is must be counted as BUG of v7 > I happened to see recently a report of a similar problem with 7.0 on > a private mailing list. Again, there were multiple IP addresses > configured within the main subnet of the interface (this time > configured as /32s on other physical interfaces) and again, after a > while the system lost connectivity to its main subnet and "forgot" how > to ARP for addresses on the interface. An important similarity - the > routing info like yours showed the attached network with the G flag, as > being reachable via the gateway address within the same subnet. > I can't troubleshoot this, no access to the system in question, but I > thought it might help to know that others have run into the same > problem. > > The thing which is very interesting is: > > Why period is 5 min? > Might be something to do with ARP? Not sure. > -- Clifton >I can't troubleshoot this, no access to the system in question You mean you can try to resolve trouble if you get access to machine? I also have tryed /32, but this do not help: gorodok# ifconfig rl0 rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0e:2e:db:4f:d4 inet 10.11.16.14 netmask 0xffffff00 broadcast 10.11.16.255 inet 10.11.16.9 netmask 0xffffffff broadcast 10.11.16.9 media: Ethernet autoselect (100baseTX ) status: active gorodok# ifconfig rl0 add 10.10.16.3/28 gorodok# ping 10.10.16.3 PING 10.10.16.3 (10.10.16.3): 56 data bytes ping: sendto: Network is unreachable ping: sendto: Network is unreachable ^C --- 10.10.16.3 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss gorodok# netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.16.1 UGS 0 32727 rl0 10.0.0.0/16 10.11.16.2 UG 0 0 rl0 10.10.16.0/28 10.10.16.3 UGC 0 2 rl0 10.11.15.0/24 link#2 UC 0 0 rl1 10.11.16.0/24 link#1 UC 0 0 rl0 10.11.16.1 00:e0:4c:59:50:7e UHLW 2 0 rl0 1193 10.11.16.2 00:03:79:01:9b:d0 UHLW 2 0 rl0 1126 10.11.16.9 10.11.16.9 UH 0 0 rl0 => 10.11.16.9/32 link#1 UC 0 0 rl0 10.11.16.12 00:0c:6e:ff:0b:35 UHLW 1 2472 rl0 1127 10.11.16.14 00:0e:2e:db:4f:d4 UHLW 1 31 lo0 127.0.0.1 127.0.0.1 UH 0 314 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 It seems v7 thinks that 10.10.16.3 is not local IP So it add route to 10.10.16.0/28 via gateway 10.10.16.3 I think something in wrong in algorithm of adding IP to system And somebody broke something in right code of FreeBSD 6.3 So I think if you diff file FreeBSD 6.3 and FreeBSD 7.0 that responsible for routing you can find mistake and it may be fixed easily =) From ler at lerctr.org Sun Aug 10 23:01:41 2008 From: ler at lerctr.org (Larry Rosenman) Date: Sun Aug 10 23:01:48 2008 Subject: ICRC's Message-ID: <20080810175934.X2427@borg> I'm getting the following on a zpool scrub: ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 pool: vault state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: scrub completed with 0 errors on Sun Aug 10 16:20:30 2008 config: NAME STATE READ WRITE CKSUM vault ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 17 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad4s1f ONLINE 0 0 0 ad4s1e ONLINE 0 0 0 ad4s1d ONLINE 0 0 0 errors: No known data errors I replaced the drive at ad8 because the original one would get an ICRC and then hang the bus. Smart info: smartctl version 5.38 [amd64-portbld-freebsd7.0] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3500630AS Serial Number: 9QG19C2Q Firmware Version: 3.AAE User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Aug 10 18:01:07 2008 CDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 163) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 105 100 006 Pre-fail Always - 9366477 3 Spin_Up_Time 0x0003 095 095 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 4 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 063 060 030 Pre-fail Always - 2364626 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 41 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 7 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 064 061 045 Old_age Always - 36 (Lifetime Min/Max 35/39) 194 Temperature_Celsius 0x0022 036 040 000 Old_age Always - 36 (0 32 0 0) 195 Hardware_ECC_Recovered 0x001a 068 064 000 Old_age Always - 207627383 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 94 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 110 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 110 occurred at disk power-on lifetime: 41 hours (1 days + 17 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 0f fe e7 36 49 Error: ICRC, ABRT 15 sectors at LBA = 0x0936e7fe = 154593278 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 00 0d e7 36 49 00 01:23:46.872 READ DMA c8 00 00 0d e6 36 49 00 01:23:46.871 READ DMA c8 00 00 0d e5 36 49 00 01:23:46.871 READ DMA c8 00 00 0d e4 36 49 00 01:23:46.870 READ DMA c8 00 00 0d e3 36 49 00 01:23:46.853 READ DMA Error 109 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 5f 88 62 a5 4f Error: ICRC, ABRT 95 sectors at LBA = 0x0fa56288 = 262496904 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 00 e7 61 a5 4f 00 01:11:12.732 READ DMA c8 00 00 e7 60 a5 4f 00 01:11:12.730 READ DMA c8 00 00 e7 5f a5 4f 00 01:11:12.729 READ DMA c8 00 00 e7 5e a5 4f 00 01:11:12.727 READ DMA c8 00 00 e7 5d a5 4f 00 01:11:12.724 READ DMA Error 108 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 1f d4 e1 db 43 Error: ICRC, ABRT 31 sectors at LBA = 0x03dbe1d4 = 64741844 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 40 b3 e1 db 43 00 01:10:40.553 READ DMA c8 00 40 73 e1 db 43 00 01:10:40.552 READ DMA c8 00 40 33 e1 db 43 00 01:10:40.487 READ DMA c8 00 00 33 e0 db 43 00 01:10:40.485 READ DMA c8 00 00 33 df db 43 00 01:10:40.484 READ DMA Error 107 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 3f 8e d2 e5 43 Error: ICRC, ABRT 63 sectors at LBA = 0x03e5d28e = 65393294 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 00 cd d1 e5 43 00 00:52:56.221 READ DMA c8 00 40 5a d1 e5 43 00 00:52:56.218 READ DMA c8 00 00 5a d0 e5 43 00 00:52:56.217 READ DMA c8 00 00 5a cf e5 43 00 00:52:56.216 READ DMA c8 00 c0 67 ce e5 43 00 00:52:56.215 READ DMA Error 106 occurred at disk power-on lifetime: 40 hours (1 days + 16 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 2f 51 6c 4e 4a Error: ICRC, ABRT 47 sectors at LBA = 0x0a4e6c51 = 172911697 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 80 00 6c 4e 4a 00 00:40:47.156 READ DMA c8 00 80 80 6b 4e 4a 00 00:40:47.156 READ DMA c8 00 80 00 6b 4e 4a 00 00:40:47.155 READ DMA c8 00 80 80 6a 4e 4a 00 00:40:47.155 READ DMA c8 00 80 00 6a 4e 4a 00 00:40:47.155 READ DMA SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 32 - # 2 Short offline Completed without error 00% 10 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Ideas? This is on a SuperMicro SYS-7045-TR+ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From koitsu at FreeBSD.org Sun Aug 10 23:41:59 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Aug 10 23:42:06 2008 Subject: ICRC's In-Reply-To: <20080810175934.X2427@borg> References: <20080810175934.X2427@borg> Message-ID: <20080810234159.GA89742@eos.sc1.parodius.com> On Sun, Aug 10, 2008 at 06:01:34PM -0500, Larry Rosenman wrote: > I'm getting the following on a zpool scrub: > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 > > I replaced the drive at ad8 because the original one would get an ICRC and then hang the bus. > > Model Family: Seagate Barracuda 7200.10 family > Device Model: ST3500630AS > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 105 100 006 Pre-fail Always - 9366477 > 7 Seek_Error_Rate 0x000f 063 060 030 Pre-fail Always - 2364626 > 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 41 > 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 7 > 190 Airflow_Temperature_Cel 0x0022 064 061 045 Old_age Always - 36 (Lifetime Min/Max 35/39) > 194 Temperature_Celsius 0x0022 036 040 000 Old_age Always - 36 (0 32 0 0) > 195 Hardware_ECC_Recovered 0x001a 068 064 000 Old_age Always - 207627383 > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 94 > > Error 110 occurred at disk power-on lifetime: 41 hours (1 days + 17 hours) > When the command that caused the error occurred, the device was active or idle. > > After command completion occurred, registers were: > ER ST SC SN CL CH DH > -- -- -- -- -- -- -- > 84 51 0f fe e7 36 49 Error: ICRC, ABRT 15 sectors at LBA = 0x0936e7fe = 154593278 > > Commands leading to the command that caused the error were: > CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name > -- -- -- -- -- -- -- -- ---------------- -------------------- > c8 00 00 0d e7 36 49 00 01:23:46.872 READ DMA > c8 00 00 0d e6 36 49 00 01:23:46.871 READ DMA > c8 00 00 0d e5 36 49 00 01:23:46.871 READ DMA > c8 00 00 0d e4 36 49 00 01:23:46.870 READ DMA > c8 00 00 0d e3 36 49 00 01:23:46.853 READ DMA > > Ideas? > > This is on a SuperMicro SYS-7045-TR+ You have one or more of the following: 1. Faulty ATA cable 2. Faulty ATA port 3. Faulty ATA controller (doubtful, unless the errors are specific to one role (e.g. master or slave)) 4. A 2nd disk which is equally as bad (came from the same manufacturing batch, which is very likely if the drive is of the same vendor and model type, and manufacturing date (within a month or two)) The disk's SMART error log even confirms the DMA errors, which proves there is in fact a problem with one of the above. In this particular case, it's not FreeBSD. :-) My recommendation: * Try another disk from a different manufacturer (not Seagate) * If similar errors appear using that disk, the problem is either item 1, 2, or 3. * If no errors appear, it's item 4, in which case send the disk to Seagate for RMA; their SeaTools utility, on a full scan, should definitely return an error code which you can give to Support when filing for the RMA. -- | Jeremy Chadwick jdc 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 | From alex-goncharov at comcast.net Mon Aug 11 00:34:32 2008 From: alex-goncharov at comcast.net (Alex Goncharov) Date: Mon Aug 11 00:34:38 2008 Subject: Groff in FreeBSD Message-ID: I am trying to refresh my old groff skills, playing with it for the first time on FreeBSD -- and getting very confused with understanding groff's place and organization here. (I am writing this on FreeBSD 7.0 but I could start an 8.0 system if somebody suggested to take a look there). Let's start with the practical end of it: I wanted to find a good macro package, good by modern standards. In the past, I've tried 'mm', 'ms', 'me' -- and could never decide which one was the most practical one (well, 'mm', perhaps). These days, it seems like 'mom' is a popular package, worth a serious attention. So, I am trying to see if 'mom' is available on my system, and it is not. I do various online searches, and the only thing that comes up is: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-11/0407.html groff macro package 'mom' not installed Date: 11/24/03 (and similar entries) 'mom' is, of course, in the source tree: ls -ld /usr/src/contrib/groff/contrib/mom drwxr-xr-x 4 root wheel 512 Mar 26 19:30 /usr/src/contrib/groff/contrib/mom/ as is 'mm': ls -ld /usr/src/contrib/groff/contrib/mm drwxr-xr-x 4 root wheel 512 Mar 26 19:29 /usr/src/contrib/groff/contrib/mm/ But while the latter has "tmac" files installed: ls /usr/share/tmac/mm* 0.MT 4.MT 5.MT locale mm.tmac mmse.tmac ms.cov se_locale se_ms.cov the former does not: ls /usr/share/tmac/mom* ls: /usr/share/tmac/mom*: No such file or directory So, I try to build something relevant by hand, and nothing good comes out of it. But I notice that the '/usr/src/contrib/groff/contrib/mm' directory is not the only place for 'mm' -- there is also ls -ld /usr/src/gnu/usr.bin/groff/contrib/mm drwxr-xr-x 2 root wheel 512 Aug 10 17:48 /usr/src/gnu/usr.bin/groff/contrib/mm/ which is a built entity. At this point, I begin not care about having 'mom' -- I just want to understand the groff organization in FreeBSD. Things that puzzle me: 1. Under '/usr/obj', there is a 'tmp/legacy' directory, which has an empty 'mm' directory deep down: find tmp/legacy/usr/share/tmac/mm -ls 518462 4 drwxr-xr-x 2 root wheel 512 Aug 9 23:05 tmp/legacy/usr/share/tmac/mm What is this 'tmp/legacy'? 2. There is an odd relationship between "tmac" files under '/usr/src' and '/usr/obj': ---------------------------------------- for cmd in "ls -l" "diff -q"; do for f in pic.tmac doc.tmac; do $cmd /usr/src/contrib/groff/tmac/$f /usr/obj//usr/src/tmp/legacy/usr/share/tmac/$f; done; done -rwxr-xr-x 1 root wheel 117 Apr 17 2001 /usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/pic.tmac -rw-r--r-- 1 root wheel 117 Apr 17 2001 /usr/src/contrib/groff/tmac/pic.tmac -rwxr-xr-x 1 root wheel 73079 Aug 9 23:05 /usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/doc.tmac -rw-r--r-- 1 root wheel 148585 Oct 20 2005 /usr/src/contrib/groff/tmac/doc.tmac Files /usr/src/contrib/groff/tmac/doc.tmac and /usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/doc.tmac differ ---------------------------------------- I.e. some files under '/usr/obj' are regenerated (see "Aug 9" for 'doc.tmac'), and others are not ('pic.mac'). Some files are identical in both places, and others are not. What is the logic and mechanics here? Can anybody shed some light on this? And also, if somebody had a recommendation on the most practical choice of the macro package, it would be highly appreciated. Thank you, -- Alex -- alex-goncharov@comcast.net -- From ler at lerctr.org Mon Aug 11 01:48:24 2008 From: ler at lerctr.org (Larry Rosenman) Date: Mon Aug 11 01:48:32 2008 Subject: ICRC's In-Reply-To: <20080810234159.GA89742@eos.sc1.parodius.com> References: <20080810175934.X2427@borg> <20080810234159.GA89742@eos.sc1.parodius.com> Message-ID: <20080810204709.X4636@borg> On Sun, 10 Aug 2008, Jeremy Chadwick wrote: > On Sun, Aug 10, 2008 at 06:01:34PM -0500, Larry Rosenman wrote: > > You have one or more of the following: > > 1. Faulty ATA cable > 2. Faulty ATA port > 3. Faulty ATA controller (doubtful, unless the errors are specific > to one role (e.g. master or slave)) > 4. A 2nd disk which is equally as bad (came from the same manufacturing > batch, which is very likely if the drive is of the same vendor and > model type, and manufacturing date (within a month or two)) We have a winner. I replaced the cable, and we get a clean scrub: pool: vault state: ONLINE scrub: scrub completed with 0 errors on Sun Aug 10 20:46:37 2008 config: NAME STATE READ WRITE CKSUM vault ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad6 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 ad14 ONLINE 0 0 0 ad4s1f ONLINE 0 0 0 ad4s1e ONLINE 0 0 0 ad4s1d ONLINE 0 0 0 errors: No known data errors Much nicer. Thanks, Jeremy! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From kasahara at nc.kyushu-u.ac.jp Mon Aug 11 02:24:27 2008 From: kasahara at nc.kyushu-u.ac.jp (Yoshiaki Kasahara) Date: Mon Aug 11 02:24:34 2008 Subject: i386 vs amd64? In-Reply-To: <200808071134.41927.freebsd-stable@dino.sk> References: <1EE0EC59-C48C-4B07-B08E-77BE388BBDE1@develooper.com> <20080807090422.GA19885@eos.sc1.parodius.com> <200808071134.41927.freebsd-stable@dino.sk> Message-ID: <20080811.112425.871254896763663867.kasahara@nc.kyushu-u.ac.jp> On Thu, 7 Aug 2008 11:34:41 +0200, Milan Obuch said: > Funny observation: "r" is on LEFT keyboard side, "l" is on RIGHT keyboard > side. I for one have problem at times precisely for this reason, but I know > this is an important step and one need to act with great care. I use a different mnemonic: r)eplace and l)eave untouched (I read it in this ML a long time ago). Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp From kuuse at redantigua.com Mon Aug 11 02:31:02 2008 From: kuuse at redantigua.com (Johan Kuuse) Date: Mon Aug 11 02:31:10 2008 Subject: kernel panic Message-ID: <200808110401.49953.kuuse@redantigua.com> Hi, I am a kgdb newbie, so please be patient. I suspect (just based on the fact that this is the 4th time I edit text files on my NTFS partition through ntfs-3g, using Emacs, and getting frequent I/O error messages inside Emacs, and then a kernel panic) that this is a ntfs-3g related problem. If you ask me exactly how to reproduce it, I sorry, I can tell you exactly (but see the kgdb output below). Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 Just a suggestion for a patch (without knowing the functionality of /usr/src/sys/kern/vfs_bio.c): The line where the kernel panics: /usr/src/sys/kern/vfs_bio.c: ---------------------------------- VM_OBJECT_LOCK(bp->b_bufobj->bo_object); ... ---------------------------------- Comparing to another file, which does error checking before calling VM_OBJECT_LOCK: /usr/src/sys/kern/vfs_aio.c: ---------------------------------- if (vp->v_object != NULL) { VM_OBJECT_LOCK(vp->v_object); ... ---------------------------------- Perhaps the kernel panic could be avoided with the following patch? /usr/src/sys/kern/vfs_bio.c (suggested patch): ---------------------------------- if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { VM_OBJECT_LOCK(bp->b_bufobj->bo_object); ... ---------------------------------- Please let me know if you need more information. Regards, Johan Kuuse ----------------------------------------------------------------------------------------------------------- kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07b6de4 stack pointer = 0x28:0xe79de7c8 frame pointer = 0x28:0xe79de7e8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1214 (opera) trap number = 12 panic: page fault cpuid = 0 Uptime: 5h20m30s Physical memory: 2035 MB Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) list *0xc07b6de4 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). 1525 vfs_vmio_release(struct buf *bp) 1526 { 1527 int i; 1528 vm_page_t m; 1529 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); 1531 vm_page_lock_queues(); 1532 for (i = 0; i < bp->b_npages; i++) { 1533 m = bp->b_pages[i]; 1534 bp->b_pages[i] = NULL; (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe79de788) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) at /usr/src/sys/kern/vfs_bio.c:1530 #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable "size" is not available. ) at /usr/src/sys/kern/vfs_bio.c:1847 #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, slptimeo=0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/vfs_bio.c:2602 #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, startoffset=Variable "startoffset" is not available. ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 #11 0xc0952a85 in ffs_write (ap=0xe79debc4) at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at vnode_if.c:691 #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, auio=0xe79dec60, offset=-1, flags=0) at file.h:254 #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) at /usr/src/sys/kern/sys_generic.c:401 #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) at /usr/src/sys/kern/sys_generic.c:317 #17 0xc0a49635 in syscall (frame=0xe79ded38) at /usr/src/sys/i386/i386/trap.c:1035 #18 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ----------------------------------------------------------------------------------------------------------- From kasahara at nc.kyushu-u.ac.jp Mon Aug 11 07:01:53 2008 From: kasahara at nc.kyushu-u.ac.jp (Yoshiaki Kasahara) Date: Mon Aug 11 07:02:00 2008 Subject: lost scroll wheel of Intellimouse Explorer 4.0 on 7.0-STABLE Message-ID: <20080811.152513.183744776023472837.kasahara@nc.kyushu-u.ac.jp> Hello, Today I updated my desktop PC from FreeBSD 7.0R to 7-STABLE. After that, the scroll wheel of my Intellimouse Explorer 4.0 (USB wired) stopped working. I searched relevant information and found kern/123224 "[ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0". The symptom is quite similar. ums0: on uhub0 ums0: 5 buttons and a TILT dir. Note that there is no "Z dir" detected. No one care about that? It is hard for me to live without the mouse wheel nowadays.... I tried another mouse and Z dir was detected properly, so it might be specific to Microsoft products. ums0: on uhub0 ums0: 3 buttons and Z dir. Environment: FreeBSD elvenbow.cc.kyushu-u.ac.jp 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Aug 11 14:04:03 JST 2008 root@elvenbow.cc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/ELVENBOW amd64 Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp From tom.hurst at clara.net Mon Aug 11 07:15:39 2008 From: tom.hurst at clara.net (Thomas Hurst) Date: Mon Aug 11 07:15:50 2008 Subject: ICRC's In-Reply-To: <20080810175934.X2427@borg> References: <20080810175934.X2427@borg> Message-ID: <20080811065822.GA81972@voi.aagh.net> * Larry Rosenman (ler@lerctr.org) wrote: > I'm getting the following on a zpool scrub: > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 > > NAME STATE READ WRITE CKSUM > ad8 ONLINE 0 0 17 Having just experienced NTFS corruption in Windows thanks to a slightly kinked SATA cable (hint: *never* chkdsk/fsck/etc until you're sure the cables are fine), I would *love* to know why this causes a checksum error at ZFS level rather than a read error that any filesystem (or indeed RAID layer) will notice. What's the point in having the connection protected by a CRC if it's just going to let bogus data through anyway? -- Thomas 'Freaky' Hurst http://hur.st/ From utisoft at googlemail.com Mon Aug 11 07:17:06 2008 From: utisoft at googlemail.com (Chris Rees) Date: Mon Aug 11 07:17:15 2008 Subject: Wireless net Card Message-ID: > Date: Sun, 10 Aug 2008 14:33:54 +1000 > From: Warren Liddell > I downloaded the drivers for the chipset my belkin wireless card has, used > ndisgen to create the kernel module, which all went aok .. however when > trying to load the module it hard hangs the machine to the point of it > restarting itself .. is there something i perhaps mybe missing or am i out in > the cold in not being able to use this wireless card untill some time a > freebsd driver is done ? > Which Belkin wireless card do you have? Which arch are you running (i386/amd64)? I had horrific trouble with a Belkin on the Realtek chipset, played up with Ubuntu, FreeBSD, Fedora, even Windows! Trouble with Belkin is, you never know what you're getting. You need the revision number of the card, and then find out which chipset it is. Make sure the drivers you downloaded are for that exact revision. Hope you have more luck than I did, I tossed mine and bought a Ralink. Chris From shinjii at maydias.com Mon Aug 11 08:13:40 2008 From: shinjii at maydias.com (Warren Liddell) Date: Mon Aug 11 08:13:47 2008 Subject: Wireless net Card In-Reply-To: References: Message-ID: <200808111813.42060.shinjii@maydias.com> > Which Belkin wireless card do you have? Which arch are you running > (i386/amd64)? > > I had horrific trouble with a Belkin on the Realtek chipset, played up > with Ubuntu, FreeBSD, Fedora, even Windows! > > Trouble with Belkin is, you never know what you're getting. You need > the revision number of the card, and then find out which chipset it > is. Make sure the drivers you downloaded are for that exact revision. > > Hope you have more luck than I did, I tossed mine and bought a Ralink. > > Chris AMD64 Arch & ironically it worked beautifully for ages in windows, but i got sick of windows having been used to FreeBSD, so i re-installed FreeBSD an using the onboard LAN card atm, but am wanting to goto wireless. none1@pci0:3:5:0: class=0x020000 card=0x700f1799 chip=0x700f1799 rev=0x20 hdr=0x00 vendor = 'Belkin Research and Development Labs' class = network subclass = ethernet Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. ironically the 8180 works fine, but naturally wont do my wireless card. From BORJAMAR at SARENET.ES Mon Aug 11 09:00:38 2008 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Mon Aug 11 09:00:46 2008 Subject: umtxn and Apache 2.2 Message-ID: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> Hello, I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 with mpm/worker and threads support, and PHP 5.2.6. Everything works like a charm, but I see that Apache is leaking processes that get stuck in umtxn state. This graph shows it pretty well (I upgraded the system last Friday). Attaching gdb to one of the stray processes and doing a backtrace of the active thread, I see this: [Switching to Thread 0x8705900 (LWP 100647)] 0x382a8789 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382a8789 in _umtx_op () from /lib/libc.so.7 #1 0x3825fe0d in __error () from /lib/libthr.so.3 #2 0x084b2b80 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x38261914 in ?? () from /lib/libthr.so.3 #8 0xbe0e5ca8 in ?? () #9 0x3825b818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) and it seems all the threads in the process are stuck here. Any ideas? -------------- next part -------------- From kvs at binarysolutions.dk Mon Aug 11 09:09:05 2008 From: kvs at binarysolutions.dk (Kenneth Vestergaard Schmidt) Date: Mon Aug 11 09:09:12 2008 Subject: IPMI Console: No luck once OS is booted In-Reply-To: (Daryl Richards's message of "Sun\, 10 Aug 2008 09\:30\:02 -0400") References: <20080809195935.F4976@borg> <20080809215249.T5563@borg> <20080810082410.X1306@borg> Message-ID: Daryl Richards writes: > I have a Sun Fire X2200. I can access the LOM no problem once Linux or > Solaris is booted. But, once FreeBSD boots, it's no longer accessible > from the NIC. Serial still works fine, it's just access via web or > ssh. Try setting hw.bge.allow_asf=1 in /boot/loader.conf /Kenneth From kris at FreeBSD.org Mon Aug 11 10:31:17 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Aug 11 10:31:24 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> Message-ID: <48A014EF.2090108@FreeBSD.org> Borja Marcos wrote: > Hello, > > I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 > with mpm/worker and threads support, and PHP 5.2.6. > > Everything works like a charm, but I see that Apache is leaking > processes that get stuck in umtxn state. > > This graph shows it pretty well (I upgraded the system last Friday). > > Attaching gdb to one of the stray processes and doing a backtrace of the > active thread, I see this: > > [Switching to Thread 0x8705900 (LWP 100647)] > 0x382a8789 in _umtx_op () from /lib/libc.so.7 > (gdb) bt > #0 0x382a8789 in _umtx_op () from /lib/libc.so.7 > #1 0x3825fe0d in __error () from /lib/libthr.so.3 > #2 0x084b2b80 in ?? () > #3 0x00000005 in ?? () > #4 0x00000000 in ?? () > #5 0x00000000 in ?? () > #6 0x00000000 in ?? () > #7 0x38261914 in ?? () from /lib/libthr.so.3 > #8 0xbe0e5ca8 in ?? () > #9 0x3825b818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 > Previous frame identical to this frame (corrupt stack?) > (gdb) > > and it seems all the threads in the process are stuck here. Any ideas? This trace doesn't show anything really. You need to recompile the binaries with debugging symbols as well. Kris From BORJAMAR at SARENET.ES Mon Aug 11 10:35:42 2008 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Mon Aug 11 10:35:49 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <48A014EF.2090108@FreeBSD.org> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <48A014EF.2090108@FreeBSD.org> Message-ID: <3A8A19D6-1507-404F-8D3F-6C207BDBDA57@SARENET.ES> On Aug 11, 2008, at 12:31 PM, Kris Kennaway wrote: > Borja Marcos wrote: >> Hello, >> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache >> 2.2 with mpm/worker and threads support, and PHP 5.2.6. >> This trace doesn't show anything really. You need to recompile the >> binaries with debugging symbols as well. Thanks, sorry. I was just wondering if someone heard of a bug on libthr, that's why first I emailed to this list, perhaps the umtxn ringed a bell. I'll recompile and keep investigating. And yes, I'm using 7-STABLE because I prefer to give a try to SCHED_ULE. It's working like a charm with MySQL and Apache, except for this problem. :) Borja. From swhetzel at gmail.com Mon Aug 11 10:55:00 2008 From: swhetzel at gmail.com (Scot Hetzel) Date: Mon Aug 11 10:55:10 2008 Subject: Wireless net Card In-Reply-To: <200808111813.42060.shinjii@maydias.com> References: <200808111813.42060.shinjii@maydias.com> Message-ID: <790a9fff0808110354i446a7ee1n843ab55e1dcf6e1a@mail.gmail.com> On 8/11/08, Warren Liddell wrote: > none1@pci0:3:5:0: class=0x020000 card=0x700f1799 chip=0x700f1799 > rev=0x20 hdr=0x00 > vendor = 'Belkin Research and Development Labs' > class = network > subclass = ethernet > > > Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just > over 572kb in size. > Which Belkin Wireless card is this? (Name/Model) Could you provide a link to the driver you downloaded. When you ran ndisgen to create the kernel module, did you specify the 32bit driver or the 64bit driver? You should be using the 64bit driver on FreeBSD/amd64. When you kldloaded the kernel module, did it indicate any required NDIS functions were missing? Scot From shinjii at maydias.com Mon Aug 11 11:35:34 2008 From: shinjii at maydias.com (Warren Liddell) Date: Mon Aug 11 11:35:47 2008 Subject: Wireless net Card In-Reply-To: References: <200808051748.55133.shinjii@maydias.com> <200808101433.54554.shinjii@maydias.com> Message-ID: <200808112135.14728.shinjii@maydias.com> > Please provide more detailed informatio. Card model, at least, or the > output of > > pciconf -lv > > supposing that you have a real card, either internal or PCMCIA. If it > is a USB model, then use > > usbdevs -v none1@pci0:3:5:0: class=0x020000 card=0x700f1799 chip=0x700f1799 rev=0x20 hdr=0x00 vendor = 'Belkin Research and Development Labs' class = network subclass = ethernet Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. ironically the 8180 works fine, but naturally wont do my wireless card. From shinjii at maydias.com Mon Aug 11 11:42:13 2008 From: shinjii at maydias.com (Warren Liddell) Date: Mon Aug 11 11:42:21 2008 Subject: Wireless net Card In-Reply-To: <790a9fff0808110354i446a7ee1n843ab55e1dcf6e1a@mail.gmail.com> References: <200808111813.42060.shinjii@maydias.com> <790a9fff0808110354i446a7ee1n843ab55e1dcf6e1a@mail.gmail.com> Message-ID: <200808112141.50313.shinjii@maydias.com> > > Chipset is RT8185L an i used the ndisgen to create the .ko file, which > > is just over 572kb in size. > > Which Belkin Wireless card is this? (Name/Model) No idea what name//Model .. all i know is its Belkin and on the card itself it has RT8185L on the sticker. I dont have any of the original box etc as it was tossed quite some time ago ironically. > > Could you provide a link to the driver you downloaded. The driver i downloaded was directly from the realtek website and it was the 64bit version. below is the link to the site that has the file i d/l http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=1&PFid=1&Level=6&Conn=5&DownTypeID=3&GetDown=false&Downloads=true#RTL8185L > When you ran ndisgen to create the kernel module, did you specify the > 32bit driver or the 64bit driver? You should be using the 64bit > driver on FreeBSD/amd64. Only downloaded the 64bit version > > When you kldloaded the kernel module, did it indicate any required > NDIS functions were missing? When i did the kldload i instantly lost all functionality of the computer system untill it rebooted itself. From petefrench at ticketswitch.com Mon Aug 11 13:03:34 2008 From: petefrench at ticketswitch.com (Pete French) Date: Mon Aug 11 13:03:41 2008 Subject: should looking at an interface with 'ifconfig' trigger a change ? In-Reply-To: <20080808101831.GD38118@cdnetworks.co.kr> Message-ID: Pyun YongHyeon wrote: > Try attached patch and check whether bce(4) correctly reports link > state changes. > > After seeing 'link state changed to UP' message, unplug the cable > and see whether it reports link DOWN. The message should be printed > in a second. Also try replugging cable and you should see link UP > message within several seconds. Since auto-negotation takes more > time you may have to wait for a while. I do not have phsyical access to the machine, so I did this using a sutdown of the interface on the sitch - but yes, it works! This fixes the progem with lagg as well - it now fails over to the other interface properly. Such a simple patch - if this has no ill effects then I will deploy it on al our servers,m and hope for it to be committed soon. All new HP servers appear to come with bce interfaces, so this is an importnat fix for us, and probably a lot of other people too. Thanks. -pete. From koitsu at FreeBSD.org Mon Aug 11 13:05:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 11 13:06:02 2008 Subject: ICRC's In-Reply-To: <20080811065822.GA81972@voi.aagh.net> References: <20080810175934.X2427@borg> <20080811065822.GA81972@voi.aagh.net> Message-ID: <20080811130555.GA25024@eos.sc1.parodius.com> On Mon, Aug 11, 2008 at 07:58:22AM +0100, Thomas Hurst wrote: > * Larry Rosenman (ler@lerctr.org) wrote: > > > I'm getting the following on a zpool scrub: > > > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 > > > > NAME STATE READ WRITE CKSUM > > ad8 ONLINE 0 0 17 > > Having just experienced NTFS corruption in Windows thanks to a slightly > kinked SATA cable (hint: *never* chkdsk/fsck/etc until you're sure the > cables are fine), I would *love* to know why this causes a checksum > error at ZFS level rather than a read error that any filesystem (or > indeed RAID layer) will notice. The ad8 errors you're quoting come from the ATA subsystem in FreeBSD. That is lower-level (e.g. closer to the hardware) than ZFS's checksum method is. If Larry was using UFS, he'd also see the above errors from the kernel. FreeBSD reports the CRC errors reported by the ATA device, ZFS reports the said data as corrupted during scrubbing or standard usage (hence the CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted data. I can't explain how the repair works, but it's one of the many features of the filesystem. I believe journalling filesystems (e.g. ext3fs and gjournal) have this ability, while Standard UFS, UFS2, NTFS, FAT, and many others do not. > What's the point in having the connection protected by a CRC if it's > just going to let bogus data through anyway? A CRC (or checksum) acts as a method of differential detection, e.g. detect corruption between X and Y. CRCs are not the same thing as error correction or retransmittal; they only result in reporting data corruption, and cannot repair it. http://en.wikipedia.org/wiki/Cyclic_redundancy_check -- | Jeremy Chadwick jdc 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 | From josh at tcbug.org Mon Aug 11 13:41:06 2008 From: josh at tcbug.org (Josh Paetzel) Date: Mon Aug 11 13:41:36 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> Message-ID: <200808110819.53914.josh@tcbug.org> On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: > OK, I just got access to a machine, am going to install and see if I > can repro this > this afternoon. > > Jack For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 and neither install has this problem. I can cold boot it with the NIC unplugged, plug in a cable, I get a link light and ifconfig em0 goes to active, dhclient em0 gets an IP successfully. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080811/ae7a91b8/attachment.pgp From koitsu at FreeBSD.org Mon Aug 11 14:02:50 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 11 14:03:02 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <200808110819.53914.josh@tcbug.org> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> Message-ID: <20080811140249.GA27379@eos.sc1.parodius.com> On Mon, Aug 11, 2008 at 08:19:46AM +0000, Josh Paetzel wrote: > On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: > > OK, I just got access to a machine, am going to install and see if I > > can repro this > > this afternoon. > > > > Jack > > For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 > and neither install has this problem. I can cold boot it with the NIC > unplugged, plug in a cable, I get a link light and ifconfig em0 goes to > active, dhclient em0 gets an IP successfully. As promised, I tested said issue out on my T60p (widescreen) tonight, using both FreeBSD 7.0-STABLE and 7.0-RELEASE. I wasn't able to reproduce the issue; so my experience was the same as Josh. I can also boot it with the CAT5 inserted, dhclient fetch an IP, no LED oddities -- then yank the cable (LED and link light go off), re-insert the cable, and within a moment or so dhclient again gets an IP. I'm left wondering if maybe there's an EEPROM setting that's doing this (purely speculative on my part), or possibly some odd BIOS quirk. My T60p (widescreen) is running BIOS 1.14. It's worth noting that the non-widescreen T60p uses a different BIOS. -- | Jeremy Chadwick jdc 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 | From jhb at freebsd.org Mon Aug 11 15:44:02 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 11 15:44:09 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <20080809111637.GA1798@roadrunner.spoerlein.net> References: <20080730113449.GD407@cdnetworks.co.kr> <200808061811.28200.jhb@freebsd.org> <20080809111637.GA1798@roadrunner.spoerlein.net> Message-ID: <200808111128.50840.jhb@freebsd.org> On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: > Hi John, > > I now figured out the "who", the "why" still eludes me. > > So, after your MFC of ichss.c on June 27th the device now attaches at my > laptop. It didn't before, so it could cause no trouble. > > With ichss loaded, the kernel will panic 1-3 minutes after powerd has > been started (if I kill powerd early enough, it seems pretty stable). > > I'm now running a kernel from 2008-08-08 with > hint.ichss.0.disabled="1" Ok. Can you get a crashdump from a crash? -- John Baldwin From jhb at freebsd.org Mon Aug 11 15:44:09 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 11 15:44:19 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <20080810062726.GA3979@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <200808091717.31780.jhb@freebsd.org> <20080810062726.GA3979@svzserv.kemerovo.su> Message-ID: <200808111131.33371.jhb@freebsd.org> On Sunday 10 August 2008 02:27:26 am Eugene Grosbein wrote: > On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote: > > > In addition to my earlier message, it would probably be good to narrow down > > what breaks the loader for you. For example, does it work ok over serial and > > only break on vidconsole? Also, if you just backout sys/boot/i386/btx to > > 7.0-release and leave the rest of the sys/boot tree at 7.0-stable, do you get > > a working loader? > > I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE > leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got > working loader! Err, my patch should have failed (well, the btx.S part) if you had a 7.0-RELEASE sys/boot/i386/btx. -- John Baldwin From jfvogel at gmail.com Mon Aug 11 16:28:02 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Aug 11 16:28:09 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <20080811140249.GA27379@eos.sc1.parodius.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> Message-ID: <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> On Mon, Aug 11, 2008 at 7:02 AM, Jeremy Chadwick wrote: > On Mon, Aug 11, 2008 at 08:19:46AM +0000, Josh Paetzel wrote: >> On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: >> > OK, I just got access to a machine, am going to install and see if I >> > can repro this >> > this afternoon. >> > >> > Jack >> >> For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 >> and neither install has this problem. I can cold boot it with the NIC >> unplugged, plug in a cable, I get a link light and ifconfig em0 goes to >> active, dhclient em0 gets an IP successfully. > > As promised, I tested said issue out on my T60p (widescreen) tonight, > using both FreeBSD 7.0-STABLE and 7.0-RELEASE. > > I wasn't able to reproduce the issue; so my experience was the same as > Josh. I can also boot it with the CAT5 inserted, dhclient fetch an IP, > no LED oddities -- then yank the cable (LED and link light go off), > re-insert the cable, and within a moment or so dhclient again gets an > IP. > > I'm left wondering if maybe there's an EEPROM setting that's doing this > (purely speculative on my part), or possibly some odd BIOS quirk. My > T60p (widescreen) is running BIOS 1.14. It's worth noting that the > non-widescreen T60p uses a different BIOS. Cool, it turned out that the laptop I was told I could use was an X61 and it had an ICH8 NIC rather than 82573 anyway, they were supposed to get me one today but given the two of you have already gone thru this verification I see little point in doing the same. Seems possibly a BIOS thing, if not that bad cable, bad link partner maybe?? Jack From pluknet at gmail.com Mon Aug 11 16:35:18 2008 From: pluknet at gmail.com (pluknet) Date: Mon Aug 11 16:35:25 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <200808111128.50840.jhb@freebsd.org> References: <20080730113449.GD407@cdnetworks.co.kr> <200808061811.28200.jhb@freebsd.org> <20080809111637.GA1798@roadrunner.spoerlein.net> <200808111128.50840.jhb@freebsd.org> Message-ID: 2008/8/11 John Baldwin : > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: >> Hi John, >> >> I now figured out the "who", the "why" still eludes me. >> >> So, after your MFC of ichss.c on June 27th the device now attaches at my >> laptop. It didn't before, so it could cause no trouble. >> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has >> been started (if I kill powerd early enough, it seems pretty stable). >> >> I'm now running a kernel from 2008-08-08 with >> hint.ichss.0.disabled="1" > > Ok. Can you get a crashdump from a crash? > ehm,. I am not Ulrich Spoerlein, but I can help with this issue. my crashdump from kgdb and some debug info. (ouch, I forgot to include it in my prev. mail http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html ) wbr, pluknet Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x20:0xc056cf46 stack pointer = 0x28:0xe6592ac8 frame pointer = 0x28:0xe6592ac8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2507 (powerd) Physical memory: 1014 MB Dumping 120 MB: 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0, dummy4=0xe6592860 "0???") at /media/src-7/sys/ddb/db_command.c:516 #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0, dopager=1) at /media/src-7/sys/ddb/db_command.c:413 #3 0xc0459655 in db_command_loop () at /media/src-7/sys/ddb/db_command.c:466 #4 0xc045b17c in db_trap (type=12, code=0) at /media/src-7/sys/ddb/db_main.c:228 #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88) at /media/src-7/sys/kern/subr_kdb.c:524 #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56) at /media/src-7/sys/i386/i386/trap.c:890 #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56) at /media/src-7/sys/i386/i386/trap.c:812 #8 0xc0746d36 in trap (frame=0xe6592a88) at /media/src-7/sys/i386/i386/trap.c:490 #9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:139 #10 0xc056cf46 in device_is_attached (dev=0x0) at /media/src-7/sys/kern/subr_bus.c:2228 #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00, arg2=0, req=0xe6592ba4) at cpufreq_if.h:32 ---Type to continue, or q to quit--- #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available. ) at /media/src-7/sys/kern/kern_sysctl.c:1306 #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14, namelen=4, old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4, retval=0xe6592c10, flags=0) at /media/src-7/sys/kern/kern_sysctl.c:1401 #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc) at /media/src-7/sys/kern/kern_sysctl.c:1336 #16 0xc07466d5 in syscall (frame=0xe6592d38) at /media/src-7/sys/i386/i386/trap.c:1035 #17 0xc072fdb0 in Xint0x80_syscall () at /media/src-7/sys/i386/i386/exception.s:196 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 11 #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 332 if (!device_is_attached(set->dev)) { (kgdb) list 327 } 328 329 /* Next, set any/all relative frequencies via their drivers. */ 330 for (i = 0; i < level->rel_count; i++) { 331 set = &level->rel_set[i]; 332 if (!device_is_attached(set->dev)) { 333 error = ENXIO; 334 goto out; 335 } 336 (kgdb) p level.rel_count $1 = 1986356271 (kgdb) p i $2 = 0 (kgdb) p level.rel_set $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = { 0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, { freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fffffff, spec = { ----- and so on----- Also there are very unusual (and high) numbers in sysctl dev.cpu.0.freq_levels. From eugen at kuzbass.ru Mon Aug 11 17:06:28 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Mon Aug 11 17:06:53 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <200808111131.33371.jhb@freebsd.org> References: <20080627031233.9DC4945047@ptavv.es.net> <200808091717.31780.jhb@freebsd.org> <20080810062726.GA3979@svzserv.kemerovo.su> <200808111131.33371.jhb@freebsd.org> Message-ID: <20080811170623.GA43671@svzserv.kemerovo.su> On Mon, Aug 11, 2008 at 11:31:33AM -0400, John Baldwin wrote: > > I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE > > leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got > > working loader! > > Err, my patch should have failed (well, the btx.S part) if you had a > 7.0-RELEASE sys/boot/i386/btx. I've applied patch first, then replaced sys/boot/i386/btx with 7.0-RELEASE version. Eugene Grosbein From imb at protected-networks.net Mon Aug 11 19:16:25 2008 From: imb at protected-networks.net (Michael Butler) Date: Mon Aug 11 19:16:32 2008 Subject: -stable tar complie broken? Message-ID: <48A09000.2000609@protected-networks.net> On a box cvsupped today, I get: imb@sarah:/usr/src/usr.bin/tar> sudo make clean depend all rm -f bsdtar bsdtar.o getdate.o matching.o read.o siginfo.o subst.o tree.o util.o write.o bsdtar.1.gz bsdtar.1.cat.gz getdate.c getdate.h yacc -d -o getdate.c /usr/src/usr.bin/tar/getdate.y yacc: 8 shift/reduce conflicts rm -f .depend mkdep -f .depend -a -DBSDTAR_VERSION_STRING=\"2.5.5\" -DPLATFORM_CONFIG_H=\"config_freebsd.h\" -I/usr/src/usr.bin/tar /usr/src/usr.bin/tar/bsdtar.c getdate.c /usr/src/usr.bin/tar/matching.c /usr/src/usr.bin/tar/read.c /usr/src/usr.bin/tar/siginfo.c /usr/src/usr.bin/tar/subst.c /usr/src/usr.bin/tar/tree.c /usr/src/usr.bin/tar/util.c /usr/src/usr.bin/tar/write.c echo bsdtar: /usr/lib/libc.a /usr/lib/libarchive.a /usr/lib/libbz2.a /usr/lib/libz.a >> .depend cc -O2 -fno-strict-aliasing -pipe -march=pentium3 -DBSDTAR_VERSION_STRING=\"2.5.5\" -DPLATFORM_CONFIG_H=\"config_freebsd.h\" -I/usr/src/usr.bin/tar -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/usr.bin/tar/bsdtar.c /usr/src/usr.bin/tar/bsdtar.c: In function 'main': /usr/src/usr.bin/tar/bsdtar.c:508: error: 'ARCHIVE_EXTRACT_SPARSE' undeclared (first use in this function) /usr/src/usr.bin/tar/bsdtar.c:508: error: (Each undeclared identifier is reported only once /usr/src/usr.bin/tar/bsdtar.c:508: error: for each function it appears in.) *** Error code 1 Michael From markus at vervier.info Mon Aug 11 20:32:29 2008 From: markus at vervier.info (Markus Vervier) Date: Mon Aug 11 20:32:36 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> Message-ID: <48A0A1D9.8030601@vervier.info> Jack Vogel wrote: > Seems possibly a BIOS thing, if not that bad cable, bad link partner maybe?? > I had the problem with all sorts of switches / cables. How can I dump my EEPROM settings if that helps? -- Markus From jfvogel at gmail.com Mon Aug 11 20:40:33 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Aug 11 20:40:41 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <48A0A1D9.8030601@vervier.info> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> Message-ID: <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> On Mon, Aug 11, 2008 at 1:32 PM, Markus Vervier wrote: > Jack Vogel wrote: >> >> Seems possibly a BIOS thing, if not that bad cable, bad link partner >> maybe?? >> > > I had the problem with all sorts of switches / cables. How can I dump my > EEPROM settings if that helps? I didn't mean the NIC EEPROM, but the system BIOS, make sure you are running the version that Jeremy said he was, if that matches you might go look at settings in the BIOS that are about management. I thought you told us that when you had a back to back connection that it worked, no?? Jack From jhb at freebsd.org Mon Aug 11 21:23:43 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 11 21:23:59 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: References: <20080730113449.GD407@cdnetworks.co.kr> <200808111128.50840.jhb@freebsd.org> Message-ID: <200808111315.23879.jhb@freebsd.org> On Monday 11 August 2008 12:35:17 pm pluknet wrote: > 2008/8/11 John Baldwin : > > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: > >> Hi John, > >> > >> I now figured out the "who", the "why" still eludes me. > >> > >> So, after your MFC of ichss.c on June 27th the device now attaches at my > >> laptop. It didn't before, so it could cause no trouble. > >> > >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has > >> been started (if I kill powerd early enough, it seems pretty stable). > >> > >> I'm now running a kernel from 2008-08-08 with > >> hint.ichss.0.disabled="1" > > > > Ok. Can you get a crashdump from a crash? > > > > ehm,. I am not Ulrich Spoerlein, but I can help with this issue. > > my crashdump from kgdb and some debug info. > (ouch, I forgot to include it in my prev. mail > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html ) > > wbr, > pluknet > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x38 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc056cf46 > stack pointer = 0x28:0xe6592ac8 > frame pointer = 0x28:0xe6592ac8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2507 (powerd) > Physical memory: 1014 MB > Dumping 120 MB: 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0, > dummy4=0xe6592860 "0???") at /media/src-7/sys/ddb/db_command.c:516 > #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0, dopager=1) > at /media/src-7/sys/ddb/db_command.c:413 > #3 0xc0459655 in db_command_loop () at /media/src-7/sys/ddb/db_command.c:466 > #4 0xc045b17c in db_trap (type=12, code=0) > at /media/src-7/sys/ddb/db_main.c:228 > #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88) > at /media/src-7/sys/kern/subr_kdb.c:524 > #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56) > at /media/src-7/sys/i386/i386/trap.c:890 > #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56) > at /media/src-7/sys/i386/i386/trap.c:812 > #8 0xc0746d36 in trap (frame=0xe6592a88) > at /media/src-7/sys/i386/i386/trap.c:490 > #9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:139 > #10 0xc056cf46 in device_is_attached (dev=0x0) > at /media/src-7/sys/kern/subr_bus.c:2228 > #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, > priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 > #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00, > arg2=0, req=0xe6592ba4) at cpufreq_if.h:32 > ---Type to continue, or q to quit--- > #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available. > ) > at /media/src-7/sys/kern/kern_sysctl.c:1306 > #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14, namelen=4, > old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4, > retval=0xe6592c10, flags=0) at /media/src-7/sys/kern/kern_sysctl.c:1401 > #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc) > at /media/src-7/sys/kern/kern_sysctl.c:1336 > #16 0xc07466d5 in syscall (frame=0xe6592d38) > at /media/src-7/sys/i386/i386/trap.c:1035 > #17 0xc072fdb0 in Xint0x80_syscall () > at /media/src-7/sys/i386/i386/exception.s:196 > #18 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 11 > #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, > priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 > 332 if (!device_is_attached(set->dev)) { > (kgdb) list > 327 } > 328 > 329 /* Next, set any/all relative frequencies via their drivers. */ > 330 for (i = 0; i < level->rel_count; i++) { > 331 set = &level->rel_set[i]; > 332 if (!device_is_attached(set->dev)) { > 333 error = ENXIO; > 334 goto out; > 335 } > 336 > (kgdb) p level.rel_count > $1 = 1986356271 > (kgdb) p i > $2 = 0 > (kgdb) p level.rel_set > $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0, > 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, > 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, > 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = { > 0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, > spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, > dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, { > freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fffffff, spec = { > ----- and so on----- > > Also there are very unusual (and high) numbers in sysctl dev.cpu.0.freq_levels. Which cpufreq drivers are you using? Can you narrow down your panics (and weird frequencies in the sysctl) to being caused by a specific cpufreq driver? -- John Baldwin From jhb at freebsd.org Mon Aug 11 21:23:49 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 11 21:24:00 2008 Subject: Problem with /boot/loader [A new patch] In-Reply-To: <20080811170623.GA43671@svzserv.kemerovo.su> References: <20080627031233.9DC4945047@ptavv.es.net> <200808111131.33371.jhb@freebsd.org> <20080811170623.GA43671@svzserv.kemerovo.su> Message-ID: <200808111400.49376.jhb@freebsd.org> On Monday 11 August 2008 01:06:23 pm Eugene Grosbein wrote: > On Mon, Aug 11, 2008 at 11:31:33AM -0400, John Baldwin wrote: > > > > I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE > > > leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got > > > working loader! > > > > Err, my patch should have failed (well, the btx.S part) if you had a > > 7.0-RELEASE sys/boot/i386/btx. > > I've applied patch first, then replaced sys/boot/i386/btx with 7.0-RELEASE > version. Ok, I'm at a loss for why the new BTX doesn't work for you. Unfortunately, this sort of thing isn't easy to debug. If you have firewire (and another machine with firewire) then I have some debugging code I used with qemu to save a summary of the last request made by the loader to BTX. That can at least indicate which BIOS call is hanging. From there you can dissassemble your BIOS to try to determine if there are any spin loops and see what it is waiting on. -- John Baldwin From jhb at freebsd.org Mon Aug 11 21:24:11 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Aug 11 21:24:18 2008 Subject: kernel panic In-Reply-To: <200808110401.49953.kuuse@redantigua.com> References: <200808110401.49953.kuuse@redantigua.com> Message-ID: <200808111704.30604.jhb@freebsd.org> On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > Hi, > > I am a kgdb newbie, so please be patient. > I suspect (just based on the fact that this is the 4th time I edit text files on my NTFS partition through ntfs-3g, using Emacs, and getting frequent I/O error messages inside Emacs, and then a kernel panic) that this is a ntfs-3g related problem. > If you ask me exactly how to reproduce it, I sorry, I can tell you exactly (but see the kgdb output below). > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > > Just a suggestion for a patch (without knowing the functionality of /usr/src/sys/kern/vfs_bio.c): > > The line where the kernel panics: > /usr/src/sys/kern/vfs_bio.c: > ---------------------------------- > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > ... > ---------------------------------- > > Comparing to another file, which does error checking before calling VM_OBJECT_LOCK: > /usr/src/sys/kern/vfs_aio.c: > ---------------------------------- > if (vp->v_object != NULL) { > VM_OBJECT_LOCK(vp->v_object); > ... > ---------------------------------- > > Perhaps the kernel panic could be avoided with the following patch? > /usr/src/sys/kern/vfs_bio.c (suggested patch): > ---------------------------------- > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > ... > ---------------------------------- > > Please let me know if you need more information. > > Regards, > Johan Kuuse > > ----------------------------------------------------------------------------------------------------------- > kgdb kernel.debug /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x34 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07b6de4 > stack pointer = 0x28:0xe79de7c8 > frame pointer = 0x28:0xe79de7e8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1214 (opera) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 5h20m30s > Physical memory: 2035 MB > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > > #0 doadump () at pcpu.h:195 > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) list *0xc07b6de4 > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > 1525 vfs_vmio_release(struct buf *bp) > 1526 { > 1527 int i; > 1528 vm_page_t m; > 1529 > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > 1531 vm_page_lock_queues(); > 1532 for (i = 0; i < bp->b_npages; i++) { > 1533 m = bp->b_pages[i]; > 1534 bp->b_pages[i] = NULL; > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) at /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:812 > #5 0xc0a49c8c in trap (frame=0xe79de788) at /usr/src/sys/i386/i386/trap.c:490 > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) at /usr/src/sys/kern/vfs_bio.c:1530 > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable "size" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:1847 > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, slptimeo=0, flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:2602 > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, startoffset=Variable "startoffset" is not available. > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at vnode_if.c:691 > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) at /usr/src/sys/kern/sys_generic.c:401 > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) at /usr/src/sys/kern/sys_generic.c:317 > #17 0xc0a49635 in syscall (frame=0xe79ded38) at /usr/src/sys/i386/i386/trap.c:1035 > #18 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 > #19 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on 6.x with NFS with no clues on what causes it. You can start by going to frame 7 and doing 'p *bp'. -- John Baldwin From ivoras at freebsd.org Mon Aug 11 22:13:09 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Aug 11 22:13:17 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> Message-ID: Borja Marcos wrote: > Hello, > > I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 > with mpm/worker and threads support, and PHP 5.2.6. > > Everything works like a charm, but I see that Apache is leaking > processes that get stuck in umtxn state. I run Apache 2.2 with worker MPM but without mod_php (I use PHP as FastCGI) on many servers and I don't have such problems. Maybe it's PHP's fault? (I agree you need a trace with debugging symbols). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080811/00332671/signature.pgp From ebutusov at gmail.com Mon Aug 11 22:38:10 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Mon Aug 11 22:38:17 2008 Subject: Hardware monitoring for Intel Atom D945GCLF. Message-ID: <48A0BF40.2030607@gmail.com> Hi, Is there a way to make use of hardware monitoring on Intel 945GCLF (with Atom 230 cpu)? It is relatively new child of Intel, but maybe someone figured it out yet. pciconf -lv shows this: ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x464c8086 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus Modules ichsmb and smb are loaded, /dev/smb0 is present, but mbon and lmmon don't give any results. lmmon says: IOCTL: Device not configured mbmon prints this: No SMBus HWM available!! InitMBInfo: Unknown error: 0 Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From koitsu at FreeBSD.org Mon Aug 11 23:45:47 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 11 23:45:55 2008 Subject: Hardware monitoring for Intel Atom D945GCLF. In-Reply-To: <48A0BF40.2030607@gmail.com> References: <48A0BF40.2030607@gmail.com> Message-ID: <20080811234547.GA67278@eos.sc1.parodius.com> On Tue, Aug 12, 2008 at 12:37:52AM +0200, Eugene Butusov wrote: > Hi, > > Is there a way to make use of hardware monitoring on Intel 945GCLF > (with Atom 230 cpu)? > It is relatively new child of Intel, but maybe someone figured it out > yet. > > pciconf -lv shows this: > > ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x464c8086 chip=0x27da8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) SMBus Controller' > class = serial bus > subclass = SMBus > > Modules ichsmb and smb are loaded, /dev/smb0 is present, but mbon and > lmmon don't give any results. The board in question is here: http://www.intel.com/products/desktop/motherboards/D945GCLF/D945GCLF-overview.htm The Technical Product Specification also does not mention any H/W monitoring IC in the Block Diagram (see section 1.1.3): http://download.intel.com/support/motherboards/desktop/d945gclf/sb/e35968001us.pdf Section 1.11 mentions support for Hardware Monitoring via "WfM", and Section 1.11.1 states that such statistics are available via SMBus (which is the more important part). More on that in a moment. Secondly, re: lmmon: no surprise. It's very, very unlikely your Intel board will contain an LMxx IC; lmmon is specifically for older motherboards (read: mid-to-late 90s) which use LMxx series ICs. There are some present-day AMD boards which use dual LMxx ICs, but it's not a common thing. Thirdly, mbmon doesn't particularly use SMBus in the way you think it would, and I'm betting use of -I will either fail, report fake values, or crash your system, since I don't think any of the features are available on the ISA bus (good riddance). See my H/W monitoring project for FreeBSD: http://bsdhwmon.parodius.com/ I'm presently focusing on Supermicro boards. Regarding your board, I found this on Intel's site: http://www.intel.com/support/motherboards/desktop/sb/CS-012552.htm#sdk * Developing Applications to Read Thermal Information Intel does not offer any development kit or API for application development that will allow you to read a board.s thermal values. However, there are 3rd party tools that you may find helpful. I don't need an API, but this kind of statement makes Intel sound like they're not willing to disclose the SMBus offsets for monitoring. I might have to look at lm-sensors from Linux, but that code is very difficult to follow. I'm not sure if Intel gives this sort of information out publicly, but I sure hope so. You might be able to get CPU thermal statistics by looking at sysctl, but I know absolutely nothing about the Atom CPU (if it behaves like a Core2Duo, then the coretemp(4) driver might work with it, or might need to be modified to work with it). -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Mon Aug 11 23:54:56 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Aug 11 23:55:03 2008 Subject: Hardware monitoring for Intel Atom D945GCLF. In-Reply-To: <20080811234547.GA67278@eos.sc1.parodius.com> References: <48A0BF40.2030607@gmail.com> <20080811234547.GA67278@eos.sc1.parodius.com> Message-ID: <20080811235456.GA70635@eos.sc1.parodius.com> On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: > I don't need an API, but this kind of statement makes Intel sound like > they're not willing to disclose the SMBus offsets for monitoring. I > might have to look at lm-sensors from Linux, but that code is very > difficult to follow. I'm not sure if Intel gives this sort of > information out publicly, but I sure hope so. There's a web page mentioning this board (note: entirely Japanese) -- http://iktaka.dyndns.org/node/11 The bottom part of the page states that Linux's lm_sensors 3.0.2 can successfully monitor temperatures, voltages, and fan RPMs on that board, very likely via SMBus. Ideally I should be able to track down technical details by looking at that code. I'd feel much more comfortable asking Intel and having them provide necessary registers and offsets, though; I prefer to avoid reverse-engineering things if possible (less mistakes). -- | Jeremy Chadwick jdc 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 | From pyunyh at gmail.com Tue Aug 12 01:04:21 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Aug 12 01:04:28 2008 Subject: should looking at an interface with 'ifconfig' trigger a change ? In-Reply-To: References: <20080808101831.GD38118@cdnetworks.co.kr> Message-ID: <20080812010204.GA54362@cdnetworks.co.kr> On Mon, Aug 11, 2008 at 02:03:31PM +0100, Pete French wrote: > Pyun YongHyeon wrote: > > Try attached patch and check whether bce(4) correctly reports link > > state changes. > > > > After seeing 'link state changed to UP' message, unplug the cable > > and see whether it reports link DOWN. The message should be printed > > in a second. Also try replugging cable and you should see link UP > > message within several seconds. Since auto-negotation takes more > > time you may have to wait for a while. > > I do not have phsyical access to the machine, so I did this using > a sutdown of the interface on the sitch - but yes, it works! This fixes > the progem with lagg as well - it now fails over to the other interface > properly. > > Such a simple patch - if this has no ill effects then I will deploy it > on al our servers,m and hope for it to be committed soon. All new HP > servers appear to come with bce interfaces, so this is an importnat fix > for us, and probably a lot of other people too. Thanks. > Thanks for testing! Patch committed to HEAD with svn r181619. > -pete. -- Regards, Pyun YongHyeon From mike at sentex.net Tue Aug 12 01:27:12 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Aug 12 01:27:19 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: Message-ID: <200808120059.m7C0xvUH028011@lava.sentex.ca> At 05:21 PM 8/8/2008, Robert Watson wrote: > >http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff > >These incude the inpcb/inpcbinfo read/write locking changes >(although not yet for raw/divert sockets). Any testing, especially >with heavy UDP loads, would be much appreciated -- this are fairly >complex changes, and also quite a complex MFC. Hi Robert, So far so good with the patches. I am running them on a busy sendmail server that also does a lot of DNS locally for itself and a number of other boxes. ---Mike From eugen at kuzbass.ru Tue Aug 12 01:50:19 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Aug 12 01:50:28 2008 Subject: Problem with /boot/loader [A new patch] References: <20080627031233.9DC4945047@ptavv.es.net> <200808111131.33371.jhb@freebsd.org> <20080811170623.GA43671@svzserv.kemerovo.su> <200808111400.49376.jhb@freebsd.org> Message-ID: <48A0EC59.16D49C91@kuzbass.ru> John Baldwin wrote: > Ok, I'm at a loss for why the new BTX doesn't work for you. Unfortunately, > this sort of thing isn't easy to debug. If you have firewire (and another > machine with firewire) then I have some debugging code I used with qemu to > save a summary of the last request made by the loader to BTX. That can at > least indicate which BIOS call is hanging. From there you can dissassemble > your BIOS to try to determine if there are any spin loops and see what it is > waiting on. Thank you very much for the effort. I have firewire here but not another machine with it, but I'll try to find one. I'll contact you again when I'll find it. Eugene Grosbein From rmtodd at ichotolot.servalan.com Tue Aug 12 04:04:49 2008 From: rmtodd at ichotolot.servalan.com (Richard Todd) Date: Tue Aug 12 04:04:57 2008 Subject: ICRC's In-Reply-To: (Jeremy Chadwick's message of "Mon, 11 Aug 2008 06:05:55 -0700") References: <20080810175934.X2427@borg> <20080811065822.GA81972@voi.aagh.net> <20080811130555.GA25024@eos.sc1.parodius.com> Message-ID: Jeremy Chadwick writes: > If Larry was using UFS, he'd also see the above errors from the kernel. > FreeBSD reports the CRC errors reported by the ATA device, ZFS reports > the said data as corrupted during scrubbing or standard usage (hence the > CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted > data. I can't explain how the repair works, but it's one of the many > features of the filesystem. I believe journalling filesystems (e.g. Um, not exactly. It's one of the features of the filesystem when you're running on a ZFS pool which is mirrored or raidz. If your ZFS pool is not mirrored or raidz-ed, checksum errors *will* be unrepairable and should show up as read errors to the application. AFAIK, the "repair" is just ZFS either finding a good copy of the block from the other half of the mirror (if mirrored) or reconstructing the missing block thru parity (if raidz-ed) and rewriting it. From kuuse at redantigua.com Tue Aug 12 06:42:59 2008 From: kuuse at redantigua.com (Johan Kuuse) Date: Tue Aug 12 06:43:07 2008 Subject: kernel panic In-Reply-To: <200808111704.30604.jhb@freebsd.org> References: <200808110401.49953.kuuse@redantigua.com> <200808111704.30604.jhb@freebsd.org> Message-ID: <200808120842.52899.kuuse@redantigua.com> On Monday 11 August 2008 23:04:30 John Baldwin wrote: > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > > Hi, > > > > I am a kgdb newbie, so please be patient. > > I suspect (just based on the fact that this is the 4th time I edit text > files on my NTFS partition through ntfs-3g, using Emacs, and getting frequent > I/O error messages inside Emacs, and then a kernel panic) that this is a > ntfs-3g related problem. > > If you ask me exactly how to reproduce it, I sorry, I can tell you exactly > (but see the kgdb output below). > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > > > > Just a suggestion for a patch (without knowing the functionality > of /usr/src/sys/kern/vfs_bio.c): > > > > The line where the kernel panics: > > /usr/src/sys/kern/vfs_bio.c: > > ---------------------------------- > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > ... > > ---------------------------------- > > > > Comparing to another file, which does error checking before calling > VM_OBJECT_LOCK: > > /usr/src/sys/kern/vfs_aio.c: > > ---------------------------------- > > if (vp->v_object != NULL) { > > VM_OBJECT_LOCK(vp->v_object); > > ... > > ---------------------------------- > > > > Perhaps the kernel panic could be avoided with the following patch? > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > > ---------------------------------- > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > ... > > ---------------------------------- > > > > Please let me know if you need more information. > > > > Regards, > > Johan Kuuse > > > > ----------------------------------------------------------------------------------------------------------- > > kgdb kernel.debug /var/crash/vmcore.1 > > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-marcel-freebsd". > > > > Unread portion of the kernel message buffer: > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x34 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc07b6de4 > > stack pointer = 0x28:0xe79de7c8 > > frame pointer = 0x28:0xe79de7e8 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 1214 (opera) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > Uptime: 5h20m30s > > Physical memory: 2035 MB > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > > > > #0 doadump () at pcpu.h:195 > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > (kgdb) list *0xc07b6de4 > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > > 1525 vfs_vmio_release(struct buf *bp) > > 1526 { > > 1527 int i; > > 1528 vm_page_t m; > > 1529 > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > 1531 vm_page_lock_queues(); > > 1532 for (i = 0; i < bp->b_npages; i++) { > > 1533 m = bp->b_pages[i]; > > 1534 bp->b_pages[i] = NULL; > > (kgdb) bt > > #0 doadump () at pcpu.h:195 > > #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) > at /usr/src/sys/i386/i386/trap.c:899 > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) > at /usr/src/sys/i386/i386/trap.c:812 > > #5 0xc0a49c8c in trap (frame=0xe79de788) > at /usr/src/sys/i386/i386/trap.c:490 > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) > at /usr/src/sys/kern/vfs_bio.c:1530 > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable "size" is > not available. > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, > slptimeo=0, flags=Variable "flags" is not available. > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, > startoffset=Variable "startoffset" is not available. > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at > vnode_if.c:691 > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) > at /usr/src/sys/kern/sys_generic.c:401 > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) > at /usr/src/sys/kern/sys_generic.c:317 > > #17 0xc0a49635 in syscall (frame=0xe79ded38) > at /usr/src/sys/i386/i386/trap.c:1035 > > #18 0xc0a2fc70 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:196 > > #19 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on 6.x > with NFS with no clues on what causes it. You can start by going to frame 7 > and doing 'p *bp'. > Thanks for the hints. See below for more debug output. I recognize that the bp struct members b_data and b_kvabase both point to a chunk of memory containing the text of the Opera web page I was reading when the kernel crashed. (This is indicated above: current process = 1214 (opera)) But what is most interesting is that b_bufobj = 0x0 Obviously, then trying to access bp->b_bufobj->bo_object will cause a crash. So I think it would be a good idea to NULL-check the struct member before trying to access it. How should I proceed? Should I post this as a possible bug somewhere else, to another list? Regards, Johan Kuuse (kgdb) up 7 #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) at /usr/src/sys/kern/vfs_bio.c:1530 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); (kgdb) p *bp $1 = {b_bufobj = 0x0, b_bcount = 4156, b_caller1 = 0x0, b_data = 0xe03d9000 "TILL\201?MPNING\n- Formulera en fr\201?gest\201?llning eller arbetsuppgift.\n- L\201?s texten noga och lyft ut det som du anser \201?r ett queert l\201?ckage.\n Arbeta med mark\201?rer s\201?som genus, sexualitet och makt.\n- F"..., b_error = -1, b_iocmd = 2 '\002', b_ioflags = 0 '\0', b_iooffset = 0, b_resid = 1387, b_iodone = 0, b_blkno = 0, b_offset = 0, b_bobufs = {tqe_next = 0x0, tqe_prev = 0xc887da54}, b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = {tqe_next = 0xd9363ea8, tqe_prev = 0xc0be18e8}, b_qindex = 0, b_flags = 536879648, b_xflags = 0 '\0', b_lock = {lk_object = {lo_name = 0xc0ada5df "bufwait", lo_type = 0xc0ada5df "bufwait", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xc0bda1b8, lk_flags = 262144, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 0, lk_lockholder = 0xc583fc60, lk_newlock = 0x0}, b_bufsize = 4608, b_runningbufspace = 0, b_kvabase = 0xe03d9000 "TILL\201?MPNING\n- Formulera en fr\201?gest\201?llning eller arbetsuppgift.\n- L\201?s texten noga och lyft ut det som du anser \201?r ett queert l\201?ckage.\n Arbeta med mark\201?rer s\201?som genus, sexualitet och makt.\n- F"..., b_kvasize = 65536, b_lblkno = 0, b_vp = 0x0, b_dirtyoff = 0, b_dirtyend = 1387, b_rcred = 0x0, b_wcred = 0xc61c6300, b_saveaddr = 0xe03d9000, b_pager = {pg_reqpage = 0}, b_cluster = { cluster_head = {tqh_first = 0xd932fc48, tqh_last = 0xd9279a4c}, cluster_entry = {tqe_next = 0xd932fc48, tqe_prev = 0xd9279a4c}}, b_pages = {0xc2b53bf8, 0xc2b72090, 0x0 }, b_npages = 2, b_dep = { lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0} (kgdb) From unga888 at yahoo.com Tue Aug 12 07:28:46 2008 From: unga888 at yahoo.com (Unga) Date: Tue Aug 12 07:28:54 2008 Subject: sysinstall compilation issue In-Reply-To: <200808081336.m78DaIoV018488@lurza.secnetix.de> Message-ID: <76940.80951.qm@web57013.mail.re3.yahoo.com> --- On Fri, 8/8/08, Oliver Fromme wrote: > From: Oliver Fromme > Subject: Re: sysinstall compilation issue > To: freebsd-stable@FreeBSD.ORG, unga888@yahoo.com > Date: Friday, August 8, 2008, 9:36 PM > Unga wrote: > > This is i386 RELENG_7. > > > > Following section of the > /usr/src/usr.sbin/sysinstall/Makefile does not generate C > code properly: > > > > makedevs.c: Makefile rtermcap > > echo '#include ' > > makedevs.c > > ${RTERMCAP} ansi | \ > > file2c 'const char termcap_ansi[] > = {' ',0};' \ > > > > makedevs.c > > > > At compile time, above expands to: > > > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src > ./rtermcap ansi | file2c 'const char termcap_ansi[] = > {' ',0};' >> makedevs.c > > > > Which generates C code as follows: > > const char termcap_ansi[] = { > > > > ,0}; > > > > That is, it generates 3 lines, which results a > compilation error. > > > > I presume, intended generated code should be: > > const char termcap_ansi[] = {' ',0}; > > > > Am I right? > > No, it should generate an array containung a dump of > the "ansi" termcap entry. Please see the > file2c(1) > manpage. > > > What is wrong at my end? > > > > Note, I linked the rtermcap with ncursesw libraries, > can that be the cause? Any ideas? > > Yes, that's the cause. Why did you do that? > > FreeBSD's ncurses port contains a patch so the > tgetent() > function (which is used by rtermcap) returns the actual > termcap entry in the buffer. The original ncurses code > (which is terminfo based) doesn't do that. > > When you linked rtermcap with the wrong library, you > restored the original behaviour of tgetent(), so the > output of rtermcap was empty, so file2c produced invalid > source. > Sorry for my late reply on this. I was not well during weekend, an eye ache due to over work :( Here is the situation at my end, no matter whether I link with ncurses widec libs or non-widec libs, its still return the same code as above I mentioned. Possible causes can be: 1. The way I compile and install ncurses is not correct. 2. OR some essential files required are missing 3. OR there can be an other option I used truss as follows: TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src truss -o truss.log -f ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c The last few lines of truss.log shows: 9310: stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r-- ,inode=22613331,size= 3170304,blksize=4096}) = 0 (0x0) 9310: open("/usr/share/misc/terminfo.db",O_RDONLY,0644) = 4 (0x4) 9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) 9310: read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) = 260 (0x104) 9310: __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0 (0x0) 9310: lseek(4,0x132000,SEEK_SET) = 1253376 (0x132000) 9310: read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096) = 4096 (0x1000) 9310: lseek(4,0x26b000,SEEK_SET) = 2535424 (0x26b000) 9310: read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096) = 4096 (0x1000) 9310: close(4) = 0 (0x0) 9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0) 9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0) 9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0) 9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4) = 0 (0x0) 9310: fstat(1,{mode=p--------- ,inode=0,size=0,blksize=4096}) = 0 (0x0) 9310: process exit, rval = 0 Note, above log has no entry to open /usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src. So what can be the issue, ncurses has not been patched correctly or some essential files missing? If you guys think that ncurses has not been patched correctly, then I'll open another thread to discuss that. Best Regards Unga From doconnor at gsoft.com.au Tue Aug 12 08:04:37 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Aug 12 08:04:48 2008 Subject: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ Message-ID: <200808121734.30144.doconnor@gsoft.com.au> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/04e0e065/attachment-0001.pgp From mat at FreeBSD.org Tue Aug 12 08:13:21 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 08:13:29 2008 Subject: neighbor discovery problem Message-ID: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> Hi, Since I added IPv6 to my network, and started really using it, I'm seeing some strange things happening. For instance, I'm on machine 2a01:678:1:443::443, and I do : $ traceroute6 -n 2a01:678:100:2:: traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from 2a01:678:1:443::443, 64 hops max, 12 byte packets 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A 2a01:678:1:443:: is it's default gateway, and is also directly connected to 2a01:678:100:2::, but it does not seem to be able to contact it. If I log onto the gateway, and I : $ ping6 -c 1 2a01:678:100:2:: PING6(56=40+8+8 bytes) 2a01:678:100:: --> 2a01:678:100:2:: 16 bytes from 2a01:678:100:2::, icmp_seq=0 hlim=64 time=1.146 ms --- 2a01:678:100:2:: ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.146/1.146/1.146/0.000 ms It works, and now, I can : $ traceroute6 -n 2a01:678:100:2:: traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from 2a01:678:1:443::443, 64 hops max, 12 byte packets 1 2a01:678:1:443:: 0.647 ms 0.671 ms 0.417 ms 2 2a01:678:100:2:: 0.852 ms 0.790 ms 0.669 ms Maybe I'm doing something wrong, but, well, I can't seem to find ou what. 2a01:678:1:443::443 is a 7.0 2a01:678:1:443:: is a 6.2 2a01:678:100:2:: is a 6.0 Those are not up to date to the latest thing you can get, but they're production machines, and I'm not really willing to upgrade them unless I really need to :-) -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/8d678b07/attachment.pgp From koitsu at FreeBSD.org Tue Aug 12 08:34:04 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 12 08:34:10 2008 Subject: neighbor discovery problem In-Reply-To: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> Message-ID: <20080812083403.GA2150@eos.sc1.parodius.com> On Tue, Aug 12, 2008 at 09:45:48AM +0200, Mathieu Arnold wrote: > Since I added IPv6 to my network, and started really using it, I'm seeing > some strange things happening. > > For instance, I'm on machine 2a01:678:1:443::443, and I do : > > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > > 2a01:678:1:443:: is it's default gateway, and is also directly connected to > 2a01:678:100:2::, but it does not seem to be able to contact it. > > If I log onto the gateway, and I : > > $ ping6 -c 1 2a01:678:100:2:: > PING6(56=40+8+8 bytes) 2a01:678:100:: --> 2a01:678:100:2:: > 16 bytes from 2a01:678:100:2::, icmp_seq=0 hlim=64 time=1.146 ms > > --- 2a01:678:100:2:: ping6 statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 1.146/1.146/1.146/0.000 ms > > It works, and now, I can : > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.647 ms 0.671 ms 0.417 ms > 2 2a01:678:100:2:: 0.852 ms 0.790 ms 0.669 ms > > Maybe I'm doing something wrong, but, well, I can't seem to find ou what. > > 2a01:678:1:443::443 is a 7.0 > 2a01:678:1:443:: is a 6.2 > 2a01:678:100:2:: is a 6.0 > > Those are not up to date to the latest thing you can get, but they're > production machines, and I'm not really willing to upgrade them unless I > really need to :-) Important note: I know absolutely nothing about IPv6. Do you have ACLs on any of these machines? !A in traceroute commonly means there's an ACL blocking said packets: !A (communication with destination network administratively prohibited) A ping from the other host might cause a stateful firewall to begin allowing said traffic to/from the machine which previously wasn't working. If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend posting your problem to the freebsd-pf list instead. -- | Jeremy Chadwick jdc 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 | From pluknet at gmail.com Tue Aug 12 08:36:30 2008 From: pluknet at gmail.com (pluknet) Date: Tue Aug 12 08:36:38 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <200808111315.23879.jhb@freebsd.org> References: <20080730113449.GD407@cdnetworks.co.kr> <200808111128.50840.jhb@freebsd.org> <200808111315.23879.jhb@freebsd.org> Message-ID: 2008/8/11 John Baldwin : > On Monday 11 August 2008 12:35:17 pm pluknet wrote: >> 2008/8/11 John Baldwin : >> > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: >> >> Hi John, >> >> >> >> I now figured out the "who", the "why" still eludes me. >> >> >> >> So, after your MFC of ichss.c on June 27th the device now attaches at my >> >> laptop. It didn't before, so it could cause no trouble. >> >> >> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has >> >> been started (if I kill powerd early enough, it seems pretty stable). >> >> >> >> I'm now running a kernel from 2008-08-08 with >> >> hint.ichss.0.disabled="1" >> > >> > Ok. Can you get a crashdump from a crash? >> > >> >> ehm,. I am not Ulrich Spoerlein, but I can help with this issue. >> >> my crashdump from kgdb and some debug info. >> (ouch, I forgot to include it in my prev. mail >> http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html ) >> >> wbr, >> pluknet >> >> Unread portion of the kernel message buffer: >> >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x38 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc056cf46 >> stack pointer = 0x28:0xe6592ac8 >> frame pointer = 0x28:0xe6592ac8 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 2507 (powerd) >> Physical memory: 1014 MB >> Dumping 120 MB: 105 89 73 57 41 25 9 >> >> #0 doadump () at pcpu.h:195 >> 195 pcpu.h: No such file or directory. >> in pcpu.h >> (kgdb) bt >> #0 doadump () at pcpu.h:195 >> #1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0, >> dummy4=0xe6592860 "0???") at /media/src-7/sys/ddb/db_command.c:516 >> #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0, > dopager=1) >> at /media/src-7/sys/ddb/db_command.c:413 >> #3 0xc0459655 in db_command_loop () > at /media/src-7/sys/ddb/db_command.c:466 >> #4 0xc045b17c in db_trap (type=12, code=0) >> at /media/src-7/sys/ddb/db_main.c:228 >> #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88) >> at /media/src-7/sys/kern/subr_kdb.c:524 >> #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56) >> at /media/src-7/sys/i386/i386/trap.c:890 >> #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56) >> at /media/src-7/sys/i386/i386/trap.c:812 >> #8 0xc0746d36 in trap (frame=0xe6592a88) >> at /media/src-7/sys/i386/i386/trap.c:490 >> #9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:139 >> #10 0xc056cf46 in device_is_attached (dev=0x0) >> at /media/src-7/sys/kern/subr_bus.c:2228 >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 >> #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00, >> arg2=0, req=0xe6592ba4) at cpufreq_if.h:32 >> ---Type to continue, or q to quit--- >> #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available. >> ) >> at /media/src-7/sys/kern/kern_sysctl.c:1306 >> #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14, > namelen=4, >> old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4, >> retval=0xe6592c10, flags=0) at /media/src-7/sys/kern/kern_sysctl.c:1401 >> #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc) >> at /media/src-7/sys/kern/kern_sysctl.c:1336 >> #16 0xc07466d5 in syscall (frame=0xe6592d38) >> at /media/src-7/sys/i386/i386/trap.c:1035 >> #17 0xc072fdb0 in Xint0x80_syscall () >> at /media/src-7/sys/i386/i386/exception.s:196 >> #18 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) f 11 >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 >> 332 if (!device_is_attached(set->dev)) { >> (kgdb) list >> 327 } >> 328 >> 329 /* Next, set any/all relative frequencies via their drivers. > */ >> 330 for (i = 0; i < level->rel_count; i++) { >> 331 set = &level->rel_set[i]; >> 332 if (!device_is_attached(set->dev)) { >> 333 error = ENXIO; >> 334 goto out; >> 335 } >> 336 >> (kgdb) p level.rel_count >> $1 = 1986356271 >> (kgdb) p i >> $2 = 0 >> (kgdb) p level.rel_set >> $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0, >> 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, > 0, >> 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = > {0, >> 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = > { >> 0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, >> spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, >> dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, { >> freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fffffff, spec = > { >> ----- and so on----- >> >> Also there are very unusual (and high) numbers in sysctl > dev.cpu.0.freq_levels. > > Which cpufreq drivers are you using? Can you narrow down your panics (and > weird frequencies in the sysctl) to being caused by a specific cpufreq > driver? They are est/p4tcc/ichss. hint.ichss.0.disbled="1" helped me to avoid panics and those weired freqs in dev.cpu. Now it shows: cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 and dev.cpu.0.freq_levels are as expected (and as it was earlier before this problem): 1600/-1 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 wbr, pluknet From BORJAMAR at SARENET.ES Tue Aug 12 10:16:53 2008 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Tue Aug 12 10:17:02 2008 Subject: umtxn and Apache 2.2 In-Reply-To: References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> Message-ID: <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> On Aug 12, 2008, at 12:12 AM, Ivan Voras wrote: > Borja Marcos wrote: >> Hello, >> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache >> 2.2 with mpm/worker and threads support, and PHP 5.2.6. >> Everything works like a charm, but I see that Apache is leaking >> processes that get stuck in umtxn state. > > I run Apache 2.2 with worker MPM but without mod_php (I use PHP as > FastCGI) on many servers and I don't have such problems. Maybe it's > PHP's fault? (I agree you need a trace with debugging symbols). May me my fault. It's a system that I didn't use to administrate. I upgraded it from 6.2-REL to 7-STABLE in place, and recompiled packages. But there was a lot of litter. I'm just wondering if that could be a problem. Just in case I've done a thorough cleanup, recompiled needed ports, and included debugging support in Apache. Let's see what happens. And please accept my apologies if this has been a silly false alarm :) Thank you very much, Borja. From rwatson at FreeBSD.org Tue Aug 12 10:20:53 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Aug 12 10:21:00 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <200808120059.m7C0xvUH028011@lava.sentex.ca> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> Message-ID: On Mon, 11 Aug 2008, Mike Tancsa wrote: > At 05:21 PM 8/8/2008, Robert Watson wrote: > >> http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff >> >> These incude the inpcb/inpcbinfo read/write locking changes (although not >> yet for raw/divert sockets). Any testing, especially with heavy UDP loads, >> would be much appreciated -- this are fairly complex changes, and also >> quite a complex MFC. > > So far so good with the patches. I am running them on a busy sendmail > server that also does a lot of DNS locally for itself and a number of other > boxes. Excellent news. I have a couple of other reviews and hopefully some more testing coming in, and will commit in a few days if all continues to go well. An updated version of the patch is here: http://www.watson.org/~robert/freebsd/netperf/20080811-7stable-rwlock-inpcb.diff There are no changes from previous versions, but I was asked to regenerate the patch with function names, so have done so. Anyone out there running name servers, NFS over UDP, and other UDP workloads: your testing of this patch prior to commit would be much appreciated. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From koitsu at FreeBSD.org Tue Aug 12 10:28:56 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 12 10:29:03 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> Message-ID: <20080812102856.GA6735@eos.sc1.parodius.com> On Tue, Aug 12, 2008 at 12:17:05PM +0200, Borja Marcos wrote: > > On Aug 12, 2008, at 12:12 AM, Ivan Voras wrote: > >> Borja Marcos wrote: >>> Hello, >>> I'm running a server with FreeBSD 7-STABLE as of August 8, Apache >>> 2.2 with mpm/worker and threads support, and PHP 5.2.6. >>> Everything works like a charm, but I see that Apache is leaking >>> processes that get stuck in umtxn state. >> >> I run Apache 2.2 with worker MPM but without mod_php (I use PHP as >> FastCGI) on many servers and I don't have such problems. Maybe it's >> PHP's fault? (I agree you need a trace with debugging symbols). > > May me my fault. It's a system that I didn't use to administrate. I > upgraded it from 6.2-REL to 7-STABLE in place, and recompiled packages. > But there was a lot of litter. I'm just wondering if that could be a > problem. > > Just in case I've done a thorough cleanup, recompiled needed ports, and > included debugging support in Apache. Let's see what happens. > > And please accept my apologies if this has been a silly false alarm :) Please be sure to report back with the outcome (in a few days, or whenever suits you) -- I've seen a report of similar oddities (threads locking up) on the suPHP mailing list, when using Apache with the worker MPM. No one stated what state the process is in (re: umtxn), so I'm not sure if it's the same issue as what you've seen. -- | Jeremy Chadwick jdc 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 | From mh at kernel32.de Tue Aug 12 10:52:35 2008 From: mh at kernel32.de (Marian Hettwer) Date: Tue Aug 12 10:52:42 2008 Subject: lagg(4) and failover Message-ID: Hi Folks, I'm using lagg(4) on some of our servers and I'm just wondering how the failover is implemented. The manpage isn't quite clear: failover Sends and receives traffic only through the master port. If the master port becomes unavailable, the next active port is used. The first interface added is the master port; any interfaces added after that are used as failover devices. What is meant by "becomes unavailable"? Is it just the physical link which needs to become unavailable to trigger a failover? I do wonder, because there might be other faults where the link is still active, but the port is unusable. Think of a wrong vlan on the switch itself. When using bonding under Linux (yeah, I know, the configuration sucks ;) ), I can configure the device to check for arp respones of it's default gateway. If arp to the default gw becomes unavailable, bonding fails over to the next interface and tries it luck over there. With that kind of configuration, I could cover a misconfigured switch port and still have failover. Long Story short: How is failover in lagg(4) implemented? Thanks for any hints :) Or should I ask the OpenBSD boys, since lagg(4) seems to be a port of trunk(4)?? :) best regards, Marian From eugen at kuzbass.ru Tue Aug 12 10:55:56 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Aug 12 10:57:15 2008 Subject: lagg(4) and failover In-Reply-To: References: Message-ID: <20080812105552.GA89695@svzserv.kemerovo.su> On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > I'm using lagg(4) on some of our servers and I'm just wondering how the > failover is implemented. > The manpage isn't quite clear: > > failover Sends and receives traffic only through the master port. > If > the master port becomes unavailable, the next active port > is > used. The first interface added is the master port; any > interfaces added after that are used as failover devices. > > What is meant by "becomes unavailable"? Is it just the physical link which > needs to become unavailable to trigger a failover? Yes. It seems you need lacp protocol described later in the manual. Eugene Grosbein From thomas.e.zander at googlemail.com Tue Aug 12 11:00:51 2008 From: thomas.e.zander at googlemail.com (Thomas Zander) Date: Tue Aug 12 11:01:00 2008 Subject: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use In-Reply-To: <919383240807230637o447d2763gd1802dc5f3dd4973@mail.gmail.com> References: <919383240807230637o447d2763gd1802dc5f3dd4973@mail.gmail.com> Message-ID: <786602c60808120334h7edabf0dob804d7593113e7b2@mail.gmail.com> Hi, On Wed, Jul 23, 2008 at 21:37, Edward Ruggeri wrote: > I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g > Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I > got kernel panics while using the wireless card under 7-STABLE Do you still have this problem or did you find a workaround? Does it look something like this? : http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 I upgraded my notebook from 6.3 to 7-STABLE on the weekend and get reproducible kernel panics ~2 sec of using the ath network card. Riggs From petefrench at ticketswitch.com Tue Aug 12 11:02:44 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Aug 12 11:03:06 2008 Subject: neighbor discovery problem In-Reply-To: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> Message-ID: > Since I added IPv6 to my network, and started really using it, I'm seeing > some strange things happening. > > For instance, I'm on machine 2a01:678:1:443::443, and I do : > > $ traceroute6 -n 2a01:678:100:2:: > traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > 2a01:678:1:443::443, 64 hops max, 12 byte packets > 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > > 2a01:678:1:443:: is it's default gateway, and is also directly connected to > 2a01:678:100:2::, but it does not seem to be able to contact it. What are your prefix lengths on the various interfaces, and does 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you can show us the config on the interfaces of the three machines then we might be able to get a better idea. I am imagining how you have these three boxes connected in my head, but nothing beats an explanation plus the config :-) > Maybe I'm doing something wrong, but, well, I can't seem to find ou what. > > 2a01:678:1:443::443 is a 7.0 > 2a01:678:1:443:: is a 6.2 > 2a01:678:100:2:: is a 6.0 I've used all of those with IPv6 and they work fine, it's most likely a small config problem. I had a lot of frustrations with IPv6 when I started using it - though now it is working I wouldn't be without it. -pete. From mh at kernel32.de Tue Aug 12 11:02:53 2008 From: mh at kernel32.de (Marian Hettwer) Date: Tue Aug 12 11:03:07 2008 Subject: lagg(4) and failover In-Reply-To: <20080812105552.GA89695@svzserv.kemerovo.su> References: <20080812105552.GA89695@svzserv.kemerovo.su> Message-ID: On Tue, 12 Aug 2008 18:55:52 +0800, Eugene Grosbein wrote: > On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. >> The manpage isn't quite clear: >> >> failover Sends and receives traffic only through the master > port. >> If >> the master port becomes unavailable, the next active > port >> is >> used. The first interface added is the master port; > any >> interfaces added after that are used as failover > devices. >> >> What is meant by "becomes unavailable"? Is it just the physical link > which >> needs to become unavailable to trigger a failover? > > Yes. It seems you need lacp protocol described later in the manual. > Thanks for your answer. However, IMO lacp doesn't solve that problem. lacp is used for link aggregation, not failover. If I'm wrong over there, I should have a read about lacp... should do that anyway, I guess. The manpage states "In the event of changes in physical connectivity...". Again, does that mean, the link needs to be physically unavailable? If so, it'll be the same behaviour as in failover mode and doesn't solve my problem of a misconfigured switch... Cheers, Marian From mat at FreeBSD.org Tue Aug 12 11:18:04 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 11:18:11 2008 Subject: neighbor discovery problem In-Reply-To: <20080812083403.GA2150@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> Message-ID: <65391406E135A0EC389574BA@andromede.in.absolight.net> +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : | Important note: I know absolutely nothing about IPv6. | | Do you have ACLs on any of these machines? !A in traceroute commonly | means there's an ACL blocking said packets: | | !A (communication with destination network administratively prohibited) | | A ping from the other host might cause a stateful firewall to begin | allowing said traffic to/from the machine which previously wasn't | working. | | If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend | posting your problem to the freebsd-pf list instead. Hum, no, I've verified it already, there is pf enabled on the gateway, which is also a firewall, but only on the external interface which does not come in play here. -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/c0edd117/attachment.pgp From peterjeremy at optushome.com.au Tue Aug 12 11:24:41 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Aug 12 11:24:48 2008 Subject: lagg(4) and failover In-Reply-To: <20080812105552.GA89695@svzserv.kemerovo.su> References: <20080812105552.GA89695@svzserv.kemerovo.su> Message-ID: <20080812112430.GC64458@server.vk2pj.dyndns.org> On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein wrote: >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > >> I'm using lagg(4) on some of our servers and I'm just wondering how the >> failover is implemented. As far as I can tell, not especially well :-(. It doesn't seem to detect much short of layer 1 failure. In particular, shutting down the switch port will not trigger a failover. >> The manpage isn't quite clear: >> >> failover Sends and receives traffic only through the master port. >> If >> the master port becomes unavailable, the next active port >> is >> used. The first interface added is the master port; any >> interfaces added after that are used as failover devices. >> >> What is meant by "becomes unavailable"? Is it just the physical link which >> needs to become unavailable to trigger a failover? It seems to be, >Yes. It seems you need lacp protocol described later in the manual. Actually, lacp and failover are used differently: lacp is primarily used to increase the bandwidth between the host and the switch whilst failover is used for redundancy. With lacp, all the physical interfaces must be connected to a single switch. With failover, the physical interfaces will normally be connected to different switches (so a failure in one switch will not cause the loss of all connectivity. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/19653903/attachment.pgp From petefrench at ticketswitch.com Tue Aug 12 11:30:14 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Aug 12 11:30:22 2008 Subject: lagg(4) and failover In-Reply-To: Message-ID: > However, IMO lacp doesn't solve that problem. lacp is used for link > aggregation, not failover. It does both - if one of the links becomes unavailable then it will stop using it. We use this for failover and it works fine, the only caveat being that your LACP device at the far end needs to look like a single phsyical device (the nicer Cisco switches do this quite happily) > The manpage states "In the event of changes in physical connectivity...". > Again, does that mean, the link needs to be physically unavailable? If so, > it'll be the same behaviour as in failover mode and doesn't solve my > problem of a misconfigured switch... lagg is to handle failover at the physical layer for when one of your ether ports fails, or someone unplugs a cable. If I understand you correctly you are looking for something at the next layer up, to handle a problem where the ports work fine, but are not going to their expected destinations. lagg won't do this. -pete. From koitsu at FreeBSD.org Tue Aug 12 11:31:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 12 11:31:31 2008 Subject: neighbor discovery problem In-Reply-To: <65391406E135A0EC389574BA@andromede.in.absolight.net> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> Message-ID: <20080812113123.GA9694@eos.sc1.parodius.com> On Tue, Aug 12, 2008 at 01:17:27PM +0200, Mathieu Arnold wrote: > +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : > | Important note: I know absolutely nothing about IPv6. > | > | Do you have ACLs on any of these machines? !A in traceroute commonly > | means there's an ACL blocking said packets: > | > | !A (communication with destination network administratively prohibited) > | > | A ping from the other host might cause a stateful firewall to begin > | allowing said traffic to/from the machine which previously wasn't > | working. > | > | If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend > | posting your problem to the freebsd-pf list instead. > > Hum, no, I've verified it already, there is pf enabled on the gateway, which > is also a firewall, but only on the external interface which does not come in > play here. That depends. Are you using "set skip" on non-external interfaces, or are you using pass rules to explicitly pass all traffic? Sorry if it sounds like I'm doubting you, but !A really looks like an ACL thing. -- | Jeremy Chadwick jdc 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 | From mat at FreeBSD.org Tue Aug 12 11:35:08 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 11:35:15 2008 Subject: neighbor discovery problem In-Reply-To: <65391406E135A0EC389574BA@andromede.in.absolight.net> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> Message-ID: <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> +-le 12.08.2008 13:17:27 +0200, Mathieu Arnold a dit : | +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : || Important note: I know absolutely nothing about IPv6. || || Do you have ACLs on any of these machines? !A in traceroute commonly || means there's an ACL blocking said packets: || || !A (communication with destination network administratively prohibited) || || A ping from the other host might cause a stateful firewall to begin || allowing said traffic to/from the machine which previously wasn't || working. || || If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend || posting your problem to the freebsd-pf list instead. | | Hum, no, I've verified it already, there is pf enabled on the gateway, which | is also a firewall, but only on the external interface which does not come | in play here. There's a pass and not a skip, but all my block rules have log, and no packets show up in pflog, which tends to make me believe that, well, it's not a firewall problem. -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/8e0e5359/attachment.pgp From mat at FreeBSD.org Tue Aug 12 11:36:07 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 11:36:13 2008 Subject: neighbor discovery problem In-Reply-To: References: Message-ID: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> +-le 12.08.2008 12:02:42 +0100, Pete French a dit : |> Since I added IPv6 to my network, and started really using it, I'm seeing |> some strange things happening. |> |> For instance, I'm on machine 2a01:678:1:443::443, and I do : |> |> $ traceroute6 -n 2a01:678:100:2:: |> traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from |> 2a01:678:1:443::443, 64 hops max, 12 byte packets |> 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms |> 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A |> |> 2a01:678:1:443:: is it's default gateway, and is also directly connected to |> 2a01:678:100:2::, but it does not seem to be able to contact it. | | What are your prefix lengths on the various interfaces, and does | 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you | can show us the config on the interfaces of the three machines then | we might be able to get a better idea. I am imagining how you have these | three boxes connected in my head, but nothing beats an explanation plus | the config :-) Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both have the "same" gateway, that is, the same box, which has : inet6 2a01:678:1:443:: prefixlen 64 inet6 2a01:678:100:: prefixlen 48 The problem I'm seeing is that before I ping the machine from the gateway, all ndp -a says about this machine is : 2a01:678:100:2:: (incomplete) em0 1s I 3 when I ping it from the first host, I see : 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, 2a01:678:100:2:: to 2a01:678:100:2::, length 104 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > ff02::1:ffe1:c05f: ICMP6, neighbor solicitation, who has fe80::2b0:d0ff:fee1:c05f, length 32 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is fe80::2b0:d0ff:fee1:c05f, length 32 and when I ping it from the gateway, I see : 2a01:678:100:25:: > 2a01:678:100::: ICMP6, neighbor solicitation, who has 2a01:678:100::, length 32 2a01:678:100:: > 2a01:678:100:25::: ICMP6, neighbor advertisement, tgt is 2a01:678:100::, length 24 2a01:678:100:: > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 2a01:678:100:2:: > 2a01:678:100::: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 And I don't understand why there's a difference, and why when the packets don't come from the gateway, the neighbor solicitation goes up wrong and does not work. |> Maybe I'm doing something wrong, but, well, I can't seem to find ou what. |> |> 2a01:678:1:443::443 is a 7.0 |> 2a01:678:1:443:: is a 6.2 |> 2a01:678:100:2:: is a 6.0 | | I've used all of those with IPv6 and they work fine, it's most likely | a small config problem. I had a lot of frustrations with IPv6 when I | started using it - though now it is working I wouldn't be without it. Well, I'm certain it must be some stupid configuration problem, but, well, I can't seem to find it :-) -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/0fdd7f6a/attachment.pgp From koitsu at FreeBSD.org Tue Aug 12 11:36:57 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 12 11:37:08 2008 Subject: neighbor discovery problem In-Reply-To: <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> Message-ID: <20080812113657.GB9694@eos.sc1.parodius.com> On Tue, Aug 12, 2008 at 01:34:35PM +0200, Mathieu Arnold wrote: > > > +-le 12.08.2008 13:17:27 +0200, Mathieu Arnold a dit : > | +-le 12.08.2008 01:34:03 -0700, Jeremy Chadwick a dit : > || Important note: I know absolutely nothing about IPv6. > || > || Do you have ACLs on any of these machines? !A in traceroute commonly > || means there's an ACL blocking said packets: > || > || !A (communication with destination network administratively prohibited) > || > || A ping from the other host might cause a stateful firewall to begin > || allowing said traffic to/from the machine which previously wasn't > || working. > || > || If you use a firewall on these machines (ipfw, pf, etc.), I'd recommend > || posting your problem to the freebsd-pf list instead. > | > | Hum, no, I've verified it already, there is pf enabled on the gateway, which > | is also a firewall, but only on the external interface which does not come > | in play here. > > There's a pass and not a skip, but all my block rules have log, and no > packets show up in pflog, which tends to make me believe that, well, it's not > a firewall problem. A pass on RELENG_7 will still cause state to be kept (keep state is implicit on RELENG_7). Do you see state mismatches? pfctl -s info. -- | Jeremy Chadwick jdc 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 | From petefrench at ticketswitch.com Tue Aug 12 11:40:13 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Aug 12 11:40:19 2008 Subject: lagg(4) and failover In-Reply-To: <20080812112430.GC64458@server.vk2pj.dyndns.org> Message-ID: > As far as I can tell, not especially well :-(. It doesn't seem to detect > much short of layer 1 failure. In particular, shutting down the switch > port will not trigger a failover. Are you using bce devices as your phsyical interfaces ? Take a look at the thread from last week about ifconfig - with the patch posted a port shutdown now *does* trigger a failover quite happily. If you are using e devices then I suggest you try it. > With lacp, all the physical interfaces must be connected to a single > switch. With failover, the physical interfaces will normally be > connected to different switches (so a failure in one switch will not > cause the loss of all connectivity. This is true - with the caveat that certain pairs of switches can be made to appear as a single phsyical device for the purposes of LACP, in which case it works fine for failover. We have two farms here - an old one using a pair of Cisco 3560s and a new one using a pair of 3750-Es. The 3750s will act as a single device and we use LACP on the machines connected to those, but the 3560s appear as a pair of devices, so for those we use failover mode. LACP failover always worked fine, and with the bce patch from last week the normal failover now also works. Nore that you can enable LACP on the 3560,s and it does appear to negotiate and work, but the switches keep changing their idea of which port to use every few seconds. So the connection works, but with high rates of packet loss as a few go missing every time the switch pair flip-flops. -pete. From mat at FreeBSD.org Tue Aug 12 11:40:27 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 11:40:35 2008 Subject: neighbor discovery problem In-Reply-To: <20080812113123.GA9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <20080812113123.GA9694@eos.sc1.parodius.com> Message-ID: <10126CF1B8A265298216C20A@andromede.in.absolight.net> +-le 12.08.2008 04:31:23 -0700, Jeremy Chadwick a dit : | Sorry if it sounds like I'm doubting you, but !A really looks like an | ACL thing. Oh, and in traceroute(8), !A is "!A (communication with destination network administratively prohibited", which is just right from your point of view, but, in traceroute6(8), !A is "Destination Unreachable - Address Unreachable" Though, in traceroute6(8), !P is "Destination Unreachable - Administratively Prohibited" whereas in traceroute(8), !P is "protocol unreachable" Yes, I know, much much confusing :-) -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/b51746b2/attachment.pgp From mh at kernel32.de Tue Aug 12 11:43:31 2008 From: mh at kernel32.de (Marian Hettwer) Date: Tue Aug 12 11:43:40 2008 Subject: lagg(4) and failover In-Reply-To: References: Message-ID: Hi Pete, On Tue, 12 Aug 2008 12:30:12 +0100, Pete French wrote: >> However, IMO lacp doesn't solve that problem. lacp is used for link >> aggregation, not failover. > > It does both - if one of the links becomes unavailable then it will > stop using it. We use this for failover and it works fine, the only > caveat being that your LACP device at the far end needs to look like > a single phsyical device (the nicer Cisco switches do this quite happily) > thanks for that info. >> The manpage states "In the event of changes in physical > connectivity...". >> Again, does that mean, the link needs to be physically unavailable? If > so, >> it'll be the same behaviour as in failover mode and doesn't solve my >> problem of a misconfigured switch... > > lagg is to handle failover at the physical layer for when one of your > ether ports fails, or someone unplugs a cable. If I understand you > correctly you are looking for something at the next layer up, to handle > a problem where the ports work fine, but are not going to their expected > destinations. lagg won't do this. > Thats unfortunate... bonding in Linux is capable of doing this and solaris too. Well then. At least everythings clear now. And in the end, clarifing things was the reason for that mail thread :) Cheers, Marian From mat at FreeBSD.org Tue Aug 12 11:45:48 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 11:45:55 2008 Subject: neighbor discovery problem In-Reply-To: <20080812113657.GB9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> Message-ID: <5DD9A523E986C374C55BE804@andromede.in.absolight.net> +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : | A pass on RELENG_7 will still cause state to be kept (keep state is | implicit on RELENG_7). the gateway is a 6.2 ;-) | Do you see state mismatches? pfctl -s info. There are some, but, hum searches 408816380699 11471.5/s state-mismatch 8655467 0.2/s the box has been up more than 400 days, and the number has not been going up while I was trying my things. I bet it goes up when something goes wrong in my network, which happens :-) -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/89bb0704/attachment.pgp From nakal at web.de Tue Aug 12 11:49:21 2008 From: nakal at web.de (Martin Sugioarto) Date: Tue Aug 12 11:49:29 2008 Subject: em(4) on FreeBSD is sometimes annoying Message-ID: <1267889400@web.de> > For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 > and neither install has this problem. I can cold boot it with the NIC > unplugged, plug in a cable, I get a link light and ifconfig em0 goes to > active, dhclient em0 gets an IP successfully. > Did you try to run /etc/rc.d/netif start after you've booted your laptop unplugged? Try to do that, THEN connect the cable. The problem appears ONLY in this situation. And it's quite common, because you often use your laptop with wireless network and suddenly you decide to connect it to wired network without having to switch the laptop off. My NIC is in such a state that I am forced to switch it off, or else I don't get link signal. I don't think it's a BIOS firmware problem (I have tried every update). I can remember that Linux had this issues, too a while ago. It works there now, but FreeBSD is still the same. Please read the steps how I cause this situation. It appears ONLY when you do it like I described it. I've seen that people first boot with plugged in cable and start to play with dhclient. Both is wrong. Correct steps to reproduce is: You have to start with unhooked interface AND the line ifconfig_re0="DHCP" in /etc/rc.conf. Then wait until you can login and try to attach the cable. -- Martin _______________________________________________________________________ EINE F?R ALLE: die kostenlose WEB.DE-Plattform f?r Freunde und Deine Homepage mit eigenem Namen. Jetzt starten! http://unddu.de/?kid=kid@mf2 From petefrench at ticketswitch.com Tue Aug 12 11:50:36 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Aug 12 11:50:44 2008 Subject: neighbor discovery problem In-Reply-To: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> Message-ID: > Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both > have the "same" gateway, that is, the same box, which has : > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 O.K., that should work. My best advice here is to do what I did - which is to disable 'pf' entirely and see if it works then. When it does you know the IPv6 config is correct and can then work out which rule in 'pf' is stopping it working when enabled. Sorry, but I van't think of anything else right now, and I guess that may not be an option on a production machine. -pete. From max at love2party.net Tue Aug 12 12:00:26 2008 From: max at love2party.net (Max Laier) Date: Tue Aug 12 12:00:33 2008 Subject: lagg(4) and failover In-Reply-To: References: Message-ID: <200808121400.18440.max@love2party.net> On Tuesday 12 August 2008 13:43:29 Marian Hettwer wrote: > Hi Pete, > > On Tue, 12 Aug 2008 12:30:12 +0100, Pete French > > wrote: > >> However, IMO lacp doesn't solve that problem. lacp is used for link > >> aggregation, not failover. > > > > It does both - if one of the links becomes unavailable then it will > > stop using it. We use this for failover and it works fine, the only > > caveat being that your LACP device at the far end needs to look like > > a single phsyical device (the nicer Cisco switches do this quite happily) > > thanks for that info. > > >> The manpage states "In the event of changes in physical > > > > connectivity...". > > > >> Again, does that mean, the link needs to be physically unavailable? If > > > > so, > > > >> it'll be the same behaviour as in failover mode and doesn't solve my > >> problem of a misconfigured switch... > > > > lagg is to handle failover at the physical layer for when one of your > > ether ports fails, or someone unplugs a cable. If I understand you > > correctly you are looking for something at the next layer up, to handle > > a problem where the ports work fine, but are not going to their expected > > destinations. lagg won't do this. > > Thats unfortunate... > bonding in Linux is capable of doing this and solaris too. > Well then. At least everythings clear now. And in the end, clarifing things > was the reason for that mail thread :) You are looking for net/ifstated -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From mat at FreeBSD.org Tue Aug 12 12:02:19 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 12:02:28 2008 Subject: neighbor discovery problem In-Reply-To: <20080812113657.GB9694@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> Message-ID: +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : | A pass on RELENG_7 will still cause state to be kept (keep state is | implicit on RELENG_7). I've just tried doing pfctl -d, and not help, I *really* don't believe that it's a pf problem ;-) -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/064749fa/attachment.pgp From peterjeremy at optushome.com.au Tue Aug 12 12:03:14 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Aug 12 12:03:21 2008 Subject: lagg(4) and failover In-Reply-To: References: Message-ID: <20080812120307.GD64458@server.vk2pj.dyndns.org> On 2008-Aug-12 13:43:29 +0200, Marian Hettwer wrote: >> lagg is to handle failover at the physical layer for when one of your >> ether ports fails, or someone unplugs a cable. If I understand you >> >Thats unfortunate... I tend to agree. >bonding in Linux is capable of doing this and solaris too. It shouldn't be too difficult to create something that behaves functionally similarly to Slowaris ipmpd (and with marginally more effort, you could create something that could be configured to behave sensibly). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/4ae258bb/attachment.pgp From koitsu at FreeBSD.org Tue Aug 12 12:10:06 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 12 12:10:13 2008 Subject: neighbor discovery problem In-Reply-To: References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> Message-ID: <20080812121005.GA11194@eos.sc1.parodius.com> On Tue, Aug 12, 2008 at 02:01:45PM +0200, Mathieu Arnold wrote: > +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : > | A pass on RELENG_7 will still cause state to be kept (keep state is > | implicit on RELENG_7). > > I've just tried doing pfctl -d, and not help, I *really* don't believe that > it's a pf problem ;-) Cool -- just covering all the bases! :-) P.S. -- The high number of state-mismatches you have may be the result of PR 125261, which has been fixed (in RELENG_7 and HEAD). It's unrelated to your issue, but I thought I'd mention it anyways. http://www.freebsd.org/cgi/query-pr.cgi?pr=125261 -- | Jeremy Chadwick jdc 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 | From mat at FreeBSD.org Tue Aug 12 12:11:43 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 12:11:50 2008 Subject: neighbor discovery problem In-Reply-To: References: Message-ID: <6338C16505B9465ED4A9CA76@andromede.in.absolight.net> +-le 12.08.2008 12:50:35 +0100, Pete French a dit : |> Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both |> have the "same" gateway, that is, the same box, which has : |> inet6 2a01:678:1:443:: prefixlen 64 |> inet6 2a01:678:100:: prefixlen 48 | | O.K., that should work. My best advice here is to do what I did - which is | to disable 'pf' entirely and see if it works then. When it does you know | the IPv6 config is correct and can then work out which rule in 'pf' is | stopping it working when enabled. Sorry, but I van't think of anything else | right now, and I guess that may not be an option on a production machine. Well, stopping the firewall a few seconds can't do really bad things, and, well, pfctl -d, wait a bit, try again, still no luck... The network is pretty simple, gateway : em0: flags=8843 mtu 1500 options=b inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 inet6 2a01:678:1:443:: prefixlen 64 inet6 2a01:678:100:: prefixlen 48 first machine : bridge0: flags=8843 metric 0 mtu 1500 inet6 fe80::2d0:dead:beef:cafe%bridge0 prefixlen 64 scopeid 0x4 inet6 2a01:678:1:443::443 prefixlen 64 destination machine : fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::2b0:d0ff:fee1:c05f%fxp0 prefixlen 64 scopeid 0x1 inet6 2a01:678:100:2:: prefixlen 48 All three ports on a switch. I don't believe it's a problem in if_bridge(4) because it's the same if I try from outside my network. -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/cab7f083/attachment.pgp From mh at kernel32.de Tue Aug 12 12:13:42 2008 From: mh at kernel32.de (Marian Hettwer) Date: Tue Aug 12 12:13:50 2008 Subject: lagg(4) and failover In-Reply-To: <200808121400.18440.max@love2party.net> References: <200808121400.18440.max@love2party.net> Message-ID: <055c079fcd23c6e88e98ef0108a8fcf0@localhost> Hi Max, On Tue, 12 Aug 2008 14:00:18 +0200, Max Laier wrote: >> Thats unfortunate... >> bonding in Linux is capable of doing this and solaris too. >> Well then. At least everythings clear now. And in the end, clarifing > things >> was the reason for that mail thread :) > > You are looking for net/ifstated > at a first glance into pkg-descr. Yeah, seems like I'm looking for ifstated. Thanks for the heads up :-) Cheers, Marian From mat at FreeBSD.org Tue Aug 12 12:13:55 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 12:14:02 2008 Subject: neighbor discovery problem In-Reply-To: <20080812121005.GA11194@eos.sc1.parodius.com> References: <2D4221F0175C7261ECD00191@atuin.in.mat.cc> <20080812083403.GA2150@eos.sc1.parodius.com> <65391406E135A0EC389574BA@andromede.in.absolight.net> <7AFCCB24A4B9B391813EBBFF@andromede.in.absolight.net> <20080812113657.GB9694@eos.sc1.parodius.com> <20080812121005.GA11194@eos.sc1.parodius.com> Message-ID: +-le 12.08.2008 05:10:05 -0700, Jeremy Chadwick a dit : | On Tue, Aug 12, 2008 at 02:01:45PM +0200, Mathieu Arnold wrote: |> +-le 12.08.2008 04:36:57 -0700, Jeremy Chadwick a dit : |> | A pass on RELENG_7 will still cause state to be kept (keep state is |> | implicit on RELENG_7). |> |> I've just tried doing pfctl -d, and not help, I *really* don't believe that |> it's a pf problem ;-) | | Cool -- just covering all the bases! :-) Well, could have been, I'm getting crazy with this problem. | P.S. -- The high number of state-mismatches you have may be the result | of PR 125261, which has been fixed (in RELENG_7 and HEAD). It's | unrelated to your issue, but I thought I'd mention it anyways. | | http://www.freebsd.org/cgi/query-pr.cgi?pr=125261 I have plans to upgrade the gateway to RELENG_7, but, I'm supposed to be on vacation right now, so, it'll wait until I get back. -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/e5388c15/attachment.pgp From mh at kernel32.de Tue Aug 12 12:14:58 2008 From: mh at kernel32.de (Marian Hettwer) Date: Tue Aug 12 12:15:04 2008 Subject: lagg(4) and failover In-Reply-To: <20080812120307.GD64458@server.vk2pj.dyndns.org> References: <20080812120307.GD64458@server.vk2pj.dyndns.org> Message-ID: Hi Peter, On Tue, 12 Aug 2008 22:03:07 +1000, Peter Jeremy wrote: > On 2008-Aug-12 13:43:29 +0200, Marian Hettwer wrote: >>> lagg is to handle failover at the physical layer for when one of your >>> ether ports fails, or someone unplugs a cable. If I understand you >>> >>Thats unfortunate... > > I tend to agree. > >>bonding in Linux is capable of doing this and solaris too. > > It shouldn't be too difficult to create something that behaves > functionally similarly to Slowaris ipmpd (and with marginally more > effort, you could create something that could be configured to behave > sensibly). > har har. Yeah, you're right. But as Max pointed out, theres net/ifstated. I'll have a look into that tiny daemon :) Cheers, Marian From petefrench at ticketswitch.com Tue Aug 12 12:26:02 2008 From: petefrench at ticketswitch.com (Pete French) Date: Tue Aug 12 12:26:10 2008 Subject: neighbor discovery problem In-Reply-To: <6338C16505B9465ED4A9CA76@andromede.in.absolight.net> Message-ID: > The network is pretty simple, > > gateway : > em0: flags=8843 mtu 1500 > options=b > inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if I were you. All zeroes as a machine number is certainly a no-no in IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's actually a problem, but it gives me a bad feeling.... -pete. From smallhand at crawblog.com Tue Aug 12 12:27:08 2008 From: smallhand at crawblog.com (Edward Ruggeri) Date: Tue Aug 12 12:27:16 2008 Subject: Ath driver causes kernel panic (page fault) on 7.0-STABLE during use In-Reply-To: <786602c60808120334h7edabf0dob804d7593113e7b2@mail.gmail.com> References: <919383240807230637o447d2763gd1802dc5f3dd4973@mail.gmail.com> <786602c60808120334h7edabf0dob804d7593113e7b2@mail.gmail.com> Message-ID: <919383240808120527o5b8fcff7x1be5995a5df0abc8@mail.gmail.com> On Tue, Aug 12, 2008 at 5:34 AM, Thomas Zander wrote: > Hi, > > On Wed, Jul 23, 2008 at 21:37, Edward Ruggeri wrote: > >> I recently purchased a Lenovo ThinkPad with a ThinkPad 11a/b/g >> Wireless LAN Mini Express Adapter (based on the AR5212 chipset). I >> got kernel panics while using the wireless card under 7-STABLE > > Do you still have this problem or did you find a workaround? > Does it look something like this? : > http://www.freebsd.org/cgi/query-pr.cgi?pr=126475 > > I upgraded my notebook from 6.3 to 7-STABLE on the weekend and get > reproducible kernel panics ~2 sec of using the ath network card. I never really got an answer about this bug. I'm sorry someone else has it. The bug went away when I updated world and rebuilt the kernel maybe two weeks ago. There didn't seem to be a recent change to the ath driver at the time, so maybe it was something outside it that caused the problem. It's hard to say... I am no longer on the freebsd-stable list, so if there's anything else I can do, please feel free to write me directly. Sincerely, -- Ned Ruggeri From max at love2party.net Tue Aug 12 12:53:29 2008 From: max at love2party.net (Max Laier) Date: Tue Aug 12 12:53:42 2008 Subject: neighbor discovery problem In-Reply-To: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> References: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> Message-ID: <200808121453.24383.max@love2party.net> On Tuesday 12 August 2008 13:35:33 Mathieu Arnold wrote: > +-le 12.08.2008 12:02:42 +0100, Pete French a dit : > |> Since I added IPv6 to my network, and started really using it, I'm > |> seeing some strange things happening. > |> > |> For instance, I'm on machine 2a01:678:1:443::443, and I do : > |> > |> $ traceroute6 -n 2a01:678:100:2:: > |> traceroute6 to 2a01:678:100:2:: (2a01:678:100:2::) from > |> 2a01:678:1:443::443, 64 hops max, 12 byte packets > |> 1 2a01:678:1:443:: 0.636 ms 0.602 ms 0.525 ms > |> 2 2a01:678:1:443:: 2999.665 ms !A 2999.636 ms !A 2999.680 ms !A > |> > |> 2a01:678:1:443:: is it's default gateway, and is also directly connected > |> to 2a01:678:100:2::, but it does not seem to be able to contact it. > | > | What are your prefix lengths on the various interfaces, and does > | 2a01:678:100:2:: have a route back to 2a01:678:1:443::443 ? If you > | can show us the config on the interfaces of the three machines then > | we might be able to get a better idea. I am imagining how you have these > | three boxes connected in my head, but nothing beats an explanation plus > | the config :-) > > Hum, 2a01:678:1:443::443 is a /64, and 2a01:678:100:2:: is on a /48, both > have the "same" gateway, that is, the same box, which has : > inet6 2a01:678:1:443:: prefixlen 64 > inet6 2a01:678:100:: prefixlen 48 > > The problem I'm seeing is that before I ping the machine from the gateway, > all ndp -a says about this machine is : > > 2a01:678:100:2:: (incomplete) em0 1s I > 3 > > when I ping it from the first host, I see : > > 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length > 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, > who has 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, ^------^ There is your problem. You have all three hosts connected to the same broadcast domain? Disable redirects or separate the domains using VLAN or similar - otherwise the gateway will get smart and try to avoid work. > 2a01:678:100:2:: to 2a01:678:100:2::, length 104 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is 2a01:678:100:2::, length 32 > fe80::207:e9ff:fe0e:dead > ff02::1:ffe1:c05f: ICMP6, neighbor solicitation, > who has fe80::2b0:d0ff:fee1:c05f, length 32 > fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor > advertisement, tgt is fe80::2b0:d0ff:fee1:c05f, length 32 > > and when I ping it from the gateway, I see : > > 2a01:678:100:25:: > 2a01:678:100::: ICMP6, neighbor solicitation, who has > 2a01:678:100::, length 32 > 2a01:678:100:: > 2a01:678:100:25::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100::, length 24 > 2a01:678:100:: > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has > 2a01:678:100:2::, length 32 > 2a01:678:100:2:: > 2a01:678:100::: ICMP6, neighbor advertisement, tgt is > 2a01:678:100:2::, length 32 > > And I don't understand why there's a difference, and why when the packets > don't come from the gateway, the neighbor solicitation goes up wrong and > does not work. > > |> Maybe I'm doing something wrong, but, well, I can't seem to find ou > |> what. > |> > |> 2a01:678:1:443::443 is a 7.0 > |> 2a01:678:1:443:: is a 6.2 > |> 2a01:678:100:2:: is a 6.0 > | > | I've used all of those with IPv6 and they work fine, it's most likely > | a small config problem. I had a lot of frustrations with IPv6 when I > | started using it - though now it is working I wouldn't be without it. > > Well, I'm certain it must be some stupid configuration problem, but, well, > I can't seem to find it :-) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From mat at FreeBSD.org Tue Aug 12 12:53:35 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 12:53:43 2008 Subject: neighbor discovery problem In-Reply-To: References: Message-ID: <6BF9B03A4005DB29256F6F4A@andromede.in.absolight.net> +-le 12.08.2008 13:26:00 +0100, Pete French a dit : |> The network is pretty simple, |> |> gateway : |> em0: flags=8843 mtu 1500 |> options=b |> inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 |> inet6 2a01:678:1:443:: prefixlen 64 |> inet6 2a01:678:100:: prefixlen 48 | | Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would | configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if | I were you. All zeroes as a machine number is certainly a no-no in | IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's | actually a problem, but it gives me a bad feeling.... Well, hum, I'm pretty sure there's no network and broadcast addresses in IPv6. Routing works, ping works, only neighbor discovery does strange things, from time to time. I'm a bit reluctant to change all that the eve of my going on vacation. I just discovered that I can't ping6 ff02::1%em0 on the gateway, well, I can, there are answers comming back, but, hum, they don't seem to sink in, and ping6 don't say anything. I'll investigate. -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/29c0a19d/attachment.pgp From jhb at freebsd.org Tue Aug 12 13:08:33 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Aug 12 13:08:46 2008 Subject: kernel panic In-Reply-To: <200808120842.52899.kuuse@redantigua.com> References: <200808110401.49953.kuuse@redantigua.com> <200808111704.30604.jhb@freebsd.org> <200808120842.52899.kuuse@redantigua.com> Message-ID: <200808120905.48528.jhb@freebsd.org> On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: > On Monday 11 August 2008 23:04:30 John Baldwin wrote: > > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > > > Hi, > > > > > > I am a kgdb newbie, so please be patient. > > > I suspect (just based on the fact that this is the 4th time I edit text > > > > files on my NTFS partition through ntfs-3g, using Emacs, and getting > > frequent I/O error messages inside Emacs, and then a kernel panic) that > > this is a ntfs-3g related problem. > > > > > If you ask me exactly how to reproduce it, I sorry, I can tell you > > > exactly > > > > (but see the kgdb output below). > > > > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > > > > > > Just a suggestion for a patch (without knowing the functionality > > > > of /usr/src/sys/kern/vfs_bio.c): > > > The line where the kernel panics: > > > /usr/src/sys/kern/vfs_bio.c: > > > ---------------------------------- > > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > > ... > > > ---------------------------------- > > > > > > Comparing to another file, which does error checking before calling > > > > VM_OBJECT_LOCK: > > > /usr/src/sys/kern/vfs_aio.c: > > > ---------------------------------- > > > if (vp->v_object != NULL) { > > > VM_OBJECT_LOCK(vp->v_object); > > > ... > > > ---------------------------------- > > > > > > Perhaps the kernel panic could be avoided with the following patch? > > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > > > ---------------------------------- > > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > > ... > > > ---------------------------------- > > > > > > Please let me know if you need more information. > > > > > > Regards, > > > Johan Kuuse > > > > > > ----------------------------------------------------------------------- > > >------------------------------------ kgdb kernel.debug > > > /var/crash/vmcore.1 > > > [GDB will not be able to debug user-mode threads: > > > /usr/lib/libthread_db.so: > > > > Undefined symbol "ps_pglobal_lookup"] > > > > > GNU gdb 6.1.1 [FreeBSD] > > > Copyright 2004 Free Software Foundation, Inc. > > > GDB is free software, covered by the GNU General Public License, and > > > you are welcome to change it and/or distribute copies of it under > > > certain > > > > conditions. > > > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for > > > details. This GDB was configured as "i386-marcel-freebsd". > > > > > > Unread portion of the kernel message buffer: > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x34 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x20:0xc07b6de4 > > > stack pointer = 0x28:0xe79de7c8 > > > frame pointer = 0x28:0xe79de7e8 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 1214 (opera) > > > trap number = 12 > > > panic: page fault > > > cpuid = 0 > > > Uptime: 5h20m30s > > > Physical memory: 2035 MB > > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > > > > > > #0 doadump () at pcpu.h:195 > > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > > (kgdb) list *0xc07b6de4 > > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > > > 1525 vfs_vmio_release(struct buf *bp) > > > 1526 { > > > 1527 int i; > > > 1528 vm_page_t m; > > > 1529 > > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > > 1531 vm_page_lock_queues(); > > > 1532 for (i = 0; i < bp->b_npages; i++) { > > > 1533 m = bp->b_pages[i]; > > > 1534 bp->b_pages[i] = NULL; > > > (kgdb) bt > > > #0 doadump () at pcpu.h:195 > > > #1 0xc0754457 in boot (howto=260) at > > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic > > > (fmt=Variable "fmt" is not available. > > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) > > > > at /usr/src/sys/i386/i386/trap.c:899 > > > > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) > > > > at /usr/src/sys/i386/i386/trap.c:812 > > > > > #5 0xc0a49c8c in trap (frame=0xe79de788) > > > > at /usr/src/sys/i386/i386/trap.c:490 > > > > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) > > > > at /usr/src/sys/kern/vfs_bio.c:1530 > > > > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable > > > "size" is > > > > not available. > > > > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, > > > > slptimeo=0, flags=Variable "flags" is not available. > > > > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, > > > > startoffset=Variable "startoffset" is not available. > > > > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) > > > > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > > > > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at > > > > vnode_if.c:691 > > > > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, > > > > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > > > > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, > > > > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > > > > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) > > > > at /usr/src/sys/kern/sys_generic.c:401 > > > > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) > > > > at /usr/src/sys/kern/sys_generic.c:317 > > > > > #17 0xc0a49635 in syscall (frame=0xe79ded38) > > > > at /usr/src/sys/i386/i386/trap.c:1035 > > > > > #18 0xc0a2fc70 in Xint0x80_syscall () > > > > at /usr/src/sys/i386/i386/exception.s:196 > > > > > #19 0x00000033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on > > 6.x with NFS with no clues on what causes it. You can start by going to > > frame 7 and doing 'p *bp'. > > Thanks for the hints. > See below for more debug output. > I recognize that the bp struct members b_data and b_kvabase both point to a > chunk of memory containing the text of the Opera web page I was reading > when the kernel crashed. (This is indicated above: current process > = 1214 (opera)) > > But what is most interesting is that b_bufobj = 0x0 > Obviously, then trying to access bp->b_bufobj->bo_object will cause a > crash. So I think it would be a good idea to NULL-check the struct member > before trying to access it. How should I proceed? Should I post this as a > possible bug somewhere else, to another list? Unfortunately, it is a worse problem that b_bufobj is NULL. That means there is a bug elsewhere. I'll look at this some more. Hmm, can you reproduce this at all? If so, can you try the patch below. Hopefully it panics here which might help: Index: vfs_subr.c =================================================================== --- vfs_subr.c (revision 181629) +++ vfs_subr.c (working copy) @@ -1546,6 +1546,9 @@ CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); + if (bp->flags & B_VMIO) + panic("brelvp of B_VMIO buffer"); + /* * Delete from old vnode list, if on one. */ -- John Baldwin From mat at FreeBSD.org Tue Aug 12 13:24:31 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 13:24:38 2008 Subject: neighbor discovery problem In-Reply-To: <6BF9B03A4005DB29256F6F4A@andromede.in.absolight.net> References: <6BF9B03A4005DB29256F6F4A@andromede.in.absolight.net> Message-ID: +-le 12.08.2008 14:53:00 +0200, Mathieu Arnold a dit : | I'll investigate. Ok, I rebooted the gateway, and now, it works just as it should... Maybe once upon a time, I did something strange, which borked everything... Anyway, thanks all :-) -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/924e5b62/attachment.pgp From mat at FreeBSD.org Tue Aug 12 13:30:08 2008 From: mat at FreeBSD.org (Mathieu Arnold) Date: Tue Aug 12 13:30:15 2008 Subject: neighbor discovery problem In-Reply-To: <200808121453.24383.max@love2party.net> References: <6C5A5164866ACB760C1B37CA@andromede.in.absolight.net> <200808121453.24383.max@love2party.net> Message-ID: <9844F31DF77772473EAA9E2C@andromede.in.absolight.net> +-le 12.08.2008 14:53:24 +0200, Max Laier a dit : |> 2a01:678:1:443::443 > 2a01:678:100:2::: ICMP6, echo request, seq 0, length |> 16 fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, |> who has 2a01:678:100:2::, length 32 |> fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, | ^------^ | | There is your problem. You have all three hosts connected to the same | broadcast domain? Disable redirects or separate the domains using VLAN or | similar - otherwise the gateway will get smart and try to avoid work. Hum, yes, the same domain, but it must not have been the problem, now, it works, and I still have : fe80::207:e9ff:fe0e:dead > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has 2a01:678:100:2::, length 32 fe80::207:e9ff:fe0e:dead > 2a01:678:1:443::443: ICMP6, redirect, 2a01:678:100:2:: to 2a01:678:100:2::, length 104 fe80::2b0:d0ff:fee1:c05f > fe80::207:e9ff:fe0e:dead: ICMP6, neighbor advertisement, tgt is 2a01:678:100:2::, length 32 but it works. -- Mathieu Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/b2f5512f/attachment.pgp From jhb at freebsd.org Tue Aug 12 15:15:28 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Aug 12 15:15:35 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: References: <20080730113449.GD407@cdnetworks.co.kr> <200808111315.23879.jhb@freebsd.org> Message-ID: <200808121111.37427.jhb@freebsd.org> On Tuesday 12 August 2008 04:36:29 am pluknet wrote: > 2008/8/11 John Baldwin : > > On Monday 11 August 2008 12:35:17 pm pluknet wrote: > >> 2008/8/11 John Baldwin : > >> > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: > >> >> Hi John, > >> >> > >> >> I now figured out the "who", the "why" still eludes me. > >> >> > >> >> So, after your MFC of ichss.c on June 27th the device now attaches at my > >> >> laptop. It didn't before, so it could cause no trouble. > >> >> > >> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has > >> >> been started (if I kill powerd early enough, it seems pretty stable). > >> >> > >> >> I'm now running a kernel from 2008-08-08 with > >> >> hint.ichss.0.disabled="1" > >> > > >> > Ok. Can you get a crashdump from a crash? > >> > > >> > >> ehm,. I am not Ulrich Spoerlein, but I can help with this issue. > >> > >> my crashdump from kgdb and some debug info. > >> (ouch, I forgot to include it in my prev. mail > >> http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html ) > >> > >> wbr, > >> pluknet > >> > >> Unread portion of the kernel message buffer: > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> fault virtual address = 0x38 > >> fault code = supervisor read, page not present > >> instruction pointer = 0x20:0xc056cf46 > >> stack pointer = 0x28:0xe6592ac8 > >> frame pointer = 0x28:0xe6592ac8 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, def32 1, gran 1 > >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> current process = 2507 (powerd) > >> Physical memory: 1014 MB > >> Dumping 120 MB: 105 89 73 57 41 25 9 > >> > >> #0 doadump () at pcpu.h:195 > >> 195 pcpu.h: No such file or directory. > >> in pcpu.h > >> (kgdb) bt > >> #0 doadump () at pcpu.h:195 > >> #1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0, > >> dummy4=0xe6592860 "0???") at /media/src-7/sys/ddb/db_command.c:516 > >> #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0, > > dopager=1) > >> at /media/src-7/sys/ddb/db_command.c:413 > >> #3 0xc0459655 in db_command_loop () > > at /media/src-7/sys/ddb/db_command.c:466 > >> #4 0xc045b17c in db_trap (type=12, code=0) > >> at /media/src-7/sys/ddb/db_main.c:228 > >> #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88) > >> at /media/src-7/sys/kern/subr_kdb.c:524 > >> #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56) > >> at /media/src-7/sys/i386/i386/trap.c:890 > >> #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56) > >> at /media/src-7/sys/i386/i386/trap.c:812 > >> #8 0xc0746d36 in trap (frame=0xe6592a88) > >> at /media/src-7/sys/i386/i386/trap.c:490 > >> #9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:139 > >> #10 0xc056cf46 in device_is_attached (dev=0x0) > >> at /media/src-7/sys/kern/subr_bus.c:2228 > >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, > >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 > >> #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00, > >> arg2=0, req=0xe6592ba4) at cpufreq_if.h:32 > >> ---Type to continue, or q to quit--- > >> #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available. > >> ) > >> at /media/src-7/sys/kern/kern_sysctl.c:1306 > >> #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14, > > namelen=4, > >> old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4, > >> retval=0xe6592c10, flags=0) at /media/src-7/sys/kern/kern_sysctl.c:1401 > >> #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc) > >> at /media/src-7/sys/kern/kern_sysctl.c:1336 > >> #16 0xc07466d5 in syscall (frame=0xe6592d38) > >> at /media/src-7/sys/i386/i386/trap.c:1035 > >> #17 0xc072fdb0 in Xint0x80_syscall () > >> at /media/src-7/sys/i386/i386/exception.s:196 > >> #18 0x00000033 in ?? () > >> Previous frame inner to this frame (corrupt stack?) > >> (kgdb) f 11 > >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, > >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 > >> 332 if (!device_is_attached(set->dev)) { > >> (kgdb) list > >> 327 } > >> 328 > >> 329 /* Next, set any/all relative frequencies via their drivers. > > */ > >> 330 for (i = 0; i < level->rel_count; i++) { > >> 331 set = &level->rel_set[i]; > >> 332 if (!device_is_attached(set->dev)) { > >> 333 error = ENXIO; > >> 334 goto out; > >> 335 } > >> 336 > >> (kgdb) p level.rel_count > >> $1 = 1986356271 > >> (kgdb) p i > >> $2 = 0 > >> (kgdb) p level.rel_set > >> $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0, > >> 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, > > 0, > >> 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = > > {0, > >> 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = > > { > >> 0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, > >> spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, > >> dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, { > >> freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fffffff, spec = > > { > >> ----- and so on----- > >> > >> Also there are very unusual (and high) numbers in sysctl > > dev.cpu.0.freq_levels. > > > > Which cpufreq drivers are you using? Can you narrow down your panics (and > > weird frequencies in the sysctl) to being caused by a specific cpufreq > > driver? > > They are est/p4tcc/ichss. > hint.ichss.0.disbled="1" helped me to avoid panics and those weired > freqs in dev.cpu. > Now it shows: > cpu0: on acpi0 > est0: on cpu0 > p4tcc0: on cpu0 > and dev.cpu.0.freq_levels are as expected (and as it was earlier > before this problem): > 1600/-1 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 > 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is only supposed to be used if you don't have est0, and this patch fixes that. I'm curious if you get panics if you have disable est0 and leave ichss0 enabled or if that works ok? -- John Baldwin From thompsa at FreeBSD.org Tue Aug 12 15:46:36 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Aug 12 15:46:48 2008 Subject: lagg(4) and failover In-Reply-To: References: Message-ID: <20080812154628.GA45850@citylink.fud.org.nz> On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > Hi Folks, > > I'm using lagg(4) on some of our servers and I'm just wondering how the > failover is implemented. > The manpage isn't quite clear: > > failover Sends and receives traffic only through the master port. > If > the master port becomes unavailable, the next active port > is > used. The first interface added is the master port; any > interfaces added after that are used as failover devices. > > What is meant by "becomes unavailable"? Is it just the physical link which > needs to become unavailable to trigger a failover? > > I do wonder, because there might be other faults where the link is still > active, but the port is unusable. Think of a wrong vlan on the switch > itself. > > When using bonding under Linux (yeah, I know, the configuration sucks ;) ), > I can configure the device to check for arp respones of it's default > gateway. If arp to the default gw becomes unavailable, bonding fails over > to the next interface and tries it luck over there. > With that kind of configuration, I could cover a misconfigured switch port > and still have failover. > > Long Story short: How is failover in lagg(4) implemented? It is simply performed on the physical link state, nothing more. Adding smarter methods of detecting the link such as what Linux does are very welcome. You may want to also look at LACP mode where heatbeat frames are exchanged with the peer. Andrew From thompsa at FreeBSD.org Tue Aug 12 15:50:22 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Aug 12 15:50:28 2008 Subject: lagg(4) and failover In-Reply-To: <20080812112430.GC64458@server.vk2pj.dyndns.org> References: <20080812105552.GA89695@svzserv.kemerovo.su> <20080812112430.GC64458@server.vk2pj.dyndns.org> Message-ID: <20080812155016.GB45850@citylink.fud.org.nz> On Tue, Aug 12, 2008 at 09:24:30PM +1000, Peter Jeremy wrote: > On 2008-Aug-12 18:55:52 +0800, Eugene Grosbein wrote: > >On Tue, Aug 12, 2008 at 12:37:15PM +0200, Marian Hettwer wrote: > > > >> I'm using lagg(4) on some of our servers and I'm just wondering how the > >> failover is implemented. > > As far as I can tell, not especially well :-(. It doesn't seem to detect > much short of layer 1 failure. In particular, shutting down the switch > port will not trigger a failover. > > >> The manpage isn't quite clear: > >> > >> failover Sends and receives traffic only through the master port. > >> If > >> the master port becomes unavailable, the next active port > >> is > >> used. The first interface added is the master port; any > >> interfaces added after that are used as failover devices. > >> > >> What is meant by "becomes unavailable"? Is it just the physical link which > >> needs to become unavailable to trigger a failover? > > It seems to be, > > >Yes. It seems you need lacp protocol described later in the manual. > > Actually, lacp and failover are used differently: lacp is primarily > used to increase the bandwidth between the host and the switch whilst > failover is used for redundancy. > > With lacp, all the physical interfaces must be connected to a single > switch. With failover, the physical interfaces will normally be > connected to different switches (so a failure in one switch will not > cause the loss of all connectivity. Actually you can use lacp in failover mode by connecting interfaces to different switches. It will only bundle an aggregation to one switch at a time but if that becomes unavailable then it will automatically choose the next switch. Andrew From =?unknown-8bit?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCk?= Tue Aug 12 16:45:43 2008 From: =?unknown-8bit?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCk?= (=?unknown-8bit?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCk?=) Date: Tue Aug 12 16:45:50 2008 Subject: neighbor discovery problem In-Reply-To: References: <6338C16505B9465ED4A9CA76@andromede.in.absolight.net> Message-ID: <20080812162134.GA2652@chateau.d.lf> In , Pete French wrote: >> The network is pretty simple, >> >> gateway : >> em0: flags=8843 mtu 1500 >> options=b >> inet6 fe80::207:e9ff:fe0e:dead%em0 prefixlen 64 scopeid 0x1 >> inet6 2a01:678:1:443:: prefixlen 64 >> inet6 2a01:678:100:: prefixlen 48 > >Hmmm, are machine numbers of all zeroes legal in IPv6 ? I would >configure those as '2a01:678:1:443::1' and '2a01:678:100::1' if >I were you. All zeroes as a machine number is certainly a no-no in >IPv4, and I wouldn't use it in IPv6 either. I have no idea if it's >actually a problem, but it gives me a bad feeling.... Yes, it is legal, and such address, with subnet prefix + all zeroes in the host identifier (or interface identifier) is known as subnet-router anycast address. For further information, check out RFC 4291, Section 2.6.1[1]. References: [1] - http://tools.ietf.org/html/rfc4291#section-2.6.1 Ashish Shukla -- ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/a51c4d72/attachment.pgp From kes-kes at yandex.ru Tue Aug 12 18:00:09 2008 From: kes-kes at yandex.ru (KES) Date: Tue Aug 12 18:00:21 2008 Subject: command not found: problem with dash in filenames Message-ID: <69921218564002@webmail6.yandex.ru> NOTICE: when I run purepw it is located and runned, but when I run pure-pw (NOTICE: dash in name) I get: Command not found kes# env |grep PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin kes# env | grep PATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin kes# ls -l /usr/local/bin/pure* -r-xr-xr-x 1 root wheel 24052 12 ??? 06:24 /usr/local/bin/pure-pw -r-xr-xr-x 1 root wheel 4432 12 ??? 06:24 /usr/local/bin/pure-pwconvert -r-xr-xr-x 1 root wheel 6016 12 ??? 06:24 /usr/local/bin/pure-statsdecode kes# pure-pw pure-pw: Command not found kes# /usr/local/bin/pure-pw Usage : pure-pw useradd [-f ] -u [-g ] -D/-d [-c ] [-t ] [-T ] ......... kes# cp pure-pw purepw kes# purepw Usage : pure-pw useradd [-f ] -u [-g ] -D/-d [-c ] [-t ] [-T ] ........ From kuuse at redantigua.com Tue Aug 12 18:23:33 2008 From: kuuse at redantigua.com (Johan Kuuse) Date: Tue Aug 12 18:23:40 2008 Subject: kernel panic Message-ID: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: >> On Monday 11 August 2008 23:04:30 John Baldwin wrote: >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: >> > > Hi, >> > > >> > > I am a kgdb newbie, so please be patient. >> > > I suspect (just based on the fact that this is the 4th time I edit text >> > >> > files on my NTFS partition through ntfs-3g, using Emacs, and getting >> > frequent I/O error messages inside Emacs, and then a kernel panic) that >> > this is a ntfs-3g related problem. >> > >> > > If you ask me exactly how to reproduce it, I sorry, I can tell you >> > > exactly >> > >> > (but see the kgdb output below). >> > >> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 >> > > >> > > Just a suggestion for a patch (without knowing the functionality >> > >> > of /usr/src/sys/kern/vfs_bio.c): >> > > The line where the kernel panics: >> > > /usr/src/sys/kern/vfs_bio.c: >> > > ---------------------------------- >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); >> > > ... >> > > ---------------------------------- >> > > >> > > Comparing to another file, which does error checking before calling >> > >> > VM_OBJECT_LOCK: >> > > /usr/src/sys/kern/vfs_aio.c: >> > > ---------------------------------- >> > > if (vp->v_object != NULL) { >> > > VM_OBJECT_LOCK(vp->v_object); >> > > ... >> > > ---------------------------------- >> > > >> > > Perhaps the kernel panic could be avoided with the following patch? >> > > /usr/src/sys/kern/vfs_bio.c (suggested patch): >> > > ---------------------------------- >> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); >> > > ... >> > > ---------------------------------- >> > > >> > > Please let me know if you need more information. >> > > >> > > Regards, >> > > Johan Kuuse >> > > >> > > ----------------------------------------------------------------------- >> > >------------------------------------ kgdb kernel.debug >> > > /var/crash/vmcore.1 >> > > [GDB will not be able to debug user-mode threads: >> > > /usr/lib/libthread_db.so: >> > >> > Undefined symbol "ps_pglobal_lookup"] >> > >> > > GNU gdb 6.1.1 [FreeBSD] >> > > Copyright 2004 Free Software Foundation, Inc. >> > > GDB is free software, covered by the GNU General Public License, and >> > > you are welcome to change it and/or distribute copies of it under >> > > certain >> > >> > conditions. >> > >> > > Type "show copying" to see the conditions. >> > > There is absolutely no warranty for GDB. Type "show warranty" for >> > > details. This GDB was configured as "i386-marcel-freebsd". >> > > >> > > Unread portion of the kernel message buffer: >> > > >> > > >> > > Fatal trap 12: page fault while in kernel mode >> > > cpuid = 0; apic id = 00 >> > > fault virtual address = 0x34 >> > > fault code = supervisor read, page not present >> > > instruction pointer = 0x20:0xc07b6de4 >> > > stack pointer = 0x28:0xe79de7c8 >> > > frame pointer = 0x28:0xe79de7e8 >> > > code segment = base 0x0, limit 0xfffff, type 0x1b >> > > = DPL 0, pres 1, def32 1, gran 1 >> > > processor eflags = interrupt enabled, resume, IOPL = 0 >> > > current process = 1214 (opera) >> > > trap number = 12 >> > > panic: page fault >> > > cpuid = 0 >> > > Uptime: 5h20m30s >> > > Physical memory: 2035 MB >> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 >> > > >> > > #0 doadump () at pcpu.h:195 >> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> > > (kgdb) list *0xc07b6de4 >> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). >> > > 1525 vfs_vmio_release(struct buf *bp) >> > > 1526 { >> > > 1527 int i; >> > > 1528 vm_page_t m; >> > > 1529 >> > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); >> > > 1531 vm_page_lock_queues(); >> > > 1532 for (i = 0; i < bp->b_npages; i++) { >> > > 1533 m = bp->b_pages[i]; >> > > 1534 bp->b_pages[i] = NULL; >> > > (kgdb) bt >> > > #0 doadump () at pcpu.h:195 >> > > #1 0xc0754457 in boot (howto=260) at >> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic >> > > (fmt=Variable "fmt" is not available. >> > > ) at /usr/src/sys/kern/kern_shutdown.c:563 >> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) >> > >> > at /usr/src/sys/i386/i386/trap.c:899 >> > >> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) >> > >> > at /usr/src/sys/i386/i386/trap.c:812 >> > >> > > #5 0xc0a49c8c in trap (frame=0xe79de788) >> > >> > at /usr/src/sys/i386/i386/trap.c:490 >> > >> > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) >> > >> > at /usr/src/sys/kern/vfs_bio.c:1530 >> > >> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable >> > > "size" is >> > >> > not available. >> > >> > > ) at /usr/src/sys/kern/vfs_bio.c:1847 >> > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, >> > >> > slptimeo=0, flags=Variable "flags" is not available. >> > >> > > ) at /usr/src/sys/kern/vfs_bio.c:2602 >> > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, >> > >> > startoffset=Variable "startoffset" is not available. >> > >> > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 >> > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) >> > >> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 >> > >> > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at >> > >> > vnode_if.c:691 >> > >> > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, >> > >> > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 >> > >> > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, >> > >> > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 >> > >> > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) >> > >> > at /usr/src/sys/kern/sys_generic.c:401 >> > >> > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) >> > >> > at /usr/src/sys/kern/sys_generic.c:317 >> > >> > > #17 0xc0a49635 in syscall (frame=0xe79ded38) >> > >> > at /usr/src/sys/i386/i386/trap.c:1035 >> > >> > > #18 0xc0a2fc70 in Xint0x80_syscall () >> > >> > at /usr/src/sys/i386/i386/exception.s:196 >> > >> > > #19 0x00000033 in ?? () >> > > Previous frame inner to this frame (corrupt stack?) >> > >> > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on >> > 6.x with NFS with no clues on what causes it. You can start by going to >> > frame 7 and doing 'p *bp'. >> >> Thanks for the hints. >> See below for more debug output. >> I recognize that the bp struct members b_data and b_kvabase both point to a >> chunk of memory containing the text of the Opera web page I was reading >> when the kernel crashed. (This is indicated above: current process >> = 1214 (opera)) >> >> But what is most interesting is that b_bufobj = 0x0 >> Obviously, then trying to access bp->b_bufobj->bo_object will cause a >> crash. So I think it would be a good idea to NULL-check the struct member >> before trying to access it. How should I proceed? Should I post this as a >> possible bug somewhere else, to another list? > > Unfortunately, it is a worse problem that b_bufobj is NULL. That means there > is a bug elsewhere. I'll look at this some more. > > Hmm, can you reproduce this at all? If so, can you try the patch below. > Hopefully it panics here which might help: > > Index: vfs_subr.c > =================================================================== > --- vfs_subr.c (revision 181629) > +++ vfs_subr.c (working copy) > @@ -1546,6 +1546,9 @@ > CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); > KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); > > + if (bp->flags & B_VMIO) > + panic("brelvp of B_VMIO buffer"); > + > /* > * Delete from old vnode list, if on one. > */ > > -- > John Baldwin > Sorry, at the moment I don't know how to reproduce the crash. I mentioned ntfs-ng/fuse as I got the impression that they caused a heavy load on my box, but in the end, it was Opera which caused the crash (also causing a heavy load, however). What I can do is to apply your patch and play around with CPU-consuming apps to try if I can reproduce the crash during heavy load. Currently I'm running 7.-0-RELEASE. Do you recommend me to upgrade to STABLE before applying the patch? Regards, Johan Kuuse From jhb at freebsd.org Tue Aug 12 18:41:05 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Aug 12 18:41:12 2008 Subject: kernel panic In-Reply-To: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> References: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> Message-ID: <200808121439.48158.jhb@freebsd.org> On Tuesday 12 August 2008 02:23:30 pm Johan Kuuse wrote: > > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: > >> On Monday 11 August 2008 23:04:30 John Baldwin wrote: > >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > >> > > Hi, > >> > > > >> > > I am a kgdb newbie, so please be patient. > >> > > I suspect (just based on the fact that this is the 4th time I edit text > >> > > >> > files on my NTFS partition through ntfs-3g, using Emacs, and getting > >> > frequent I/O error messages inside Emacs, and then a kernel panic) that > >> > this is a ntfs-3g related problem. > >> > > >> > > If you ask me exactly how to reproduce it, I sorry, I can tell you > >> > > exactly > >> > > >> > (but see the kgdb output below). > >> > > >> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > >> > > > >> > > Just a suggestion for a patch (without knowing the functionality > >> > > >> > of /usr/src/sys/kern/vfs_bio.c): > >> > > The line where the kernel panics: > >> > > /usr/src/sys/kern/vfs_bio.c: > >> > > ---------------------------------- > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > >> > > ... > >> > > ---------------------------------- > >> > > > >> > > Comparing to another file, which does error checking before calling > >> > > >> > VM_OBJECT_LOCK: > >> > > /usr/src/sys/kern/vfs_aio.c: > >> > > ---------------------------------- > >> > > if (vp->v_object != NULL) { > >> > > VM_OBJECT_LOCK(vp->v_object); > >> > > ... > >> > > ---------------------------------- > >> > > > >> > > Perhaps the kernel panic could be avoided with the following patch? > >> > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > >> > > ---------------------------------- > >> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > >> > > ... > >> > > ---------------------------------- > >> > > > >> > > Please let me know if you need more information. > >> > > > >> > > Regards, > >> > > Johan Kuuse > >> > > > >> > > ----------------------------------------------------------------------- > >> > >------------------------------------ kgdb kernel.debug > >> > > /var/crash/vmcore.1 > >> > > [GDB will not be able to debug user-mode threads: > >> > > /usr/lib/libthread_db.so: > >> > > >> > Undefined symbol "ps_pglobal_lookup"] > >> > > >> > > GNU gdb 6.1.1 [FreeBSD] > >> > > Copyright 2004 Free Software Foundation, Inc. > >> > > GDB is free software, covered by the GNU General Public License, and > >> > > you are welcome to change it and/or distribute copies of it under > >> > > certain > >> > > >> > conditions. > >> > > >> > > Type "show copying" to see the conditions. > >> > > There is absolutely no warranty for GDB. Type "show warranty" for > >> > > details. This GDB was configured as "i386-marcel-freebsd". > >> > > > >> > > Unread portion of the kernel message buffer: > >> > > > >> > > > >> > > Fatal trap 12: page fault while in kernel mode > >> > > cpuid = 0; apic id = 00 > >> > > fault virtual address = 0x34 > >> > > fault code = supervisor read, page not present > >> > > instruction pointer = 0x20:0xc07b6de4 > >> > > stack pointer = 0x28:0xe79de7c8 > >> > > frame pointer = 0x28:0xe79de7e8 > >> > > code segment = base 0x0, limit 0xfffff, type 0x1b > >> > > = DPL 0, pres 1, def32 1, gran 1 > >> > > processor eflags = interrupt enabled, resume, IOPL = 0 > >> > > current process = 1214 (opera) > >> > > trap number = 12 > >> > > panic: page fault > >> > > cpuid = 0 > >> > > Uptime: 5h20m30s > >> > > Physical memory: 2035 MB > >> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > >> > > > >> > > #0 doadump () at pcpu.h:195 > >> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > >> > > (kgdb) list *0xc07b6de4 > >> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > >> > > 1525 vfs_vmio_release(struct buf *bp) > >> > > 1526 { > >> > > 1527 int i; > >> > > 1528 vm_page_t m; > >> > > 1529 > >> > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > >> > > 1531 vm_page_lock_queues(); > >> > > 1532 for (i = 0; i < bp->b_npages; i++) { > >> > > 1533 m = bp->b_pages[i]; > >> > > 1534 bp->b_pages[i] = NULL; > >> > > (kgdb) bt > >> > > #0 doadump () at pcpu.h:195 > >> > > #1 0xc0754457 in boot (howto=260) at > >> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic > >> > > (fmt=Variable "fmt" is not available. > >> > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > >> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:899 > >> > > >> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:812 > >> > > >> > > #5 0xc0a49c8c in trap (frame=0xe79de788) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:490 > >> > > >> > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) > >> > > >> > at /usr/src/sys/kern/vfs_bio.c:1530 > >> > > >> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable > >> > > "size" is > >> > > >> > not available. > >> > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > >> > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0, > >> > > >> > slptimeo=0, flags=Variable "flags" is not available. > >> > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > >> > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, > >> > > >> > startoffset=Variable "startoffset" is not available. > >> > > >> > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > >> > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) > >> > > >> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > >> > > >> > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at > >> > > >> > vnode_if.c:691 > >> > > >> > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, > >> > > >> > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > >> > > >> > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, > >> > > >> > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > >> > > >> > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) > >> > > >> > at /usr/src/sys/kern/sys_generic.c:401 > >> > > >> > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) > >> > > >> > at /usr/src/sys/kern/sys_generic.c:317 > >> > > >> > > #17 0xc0a49635 in syscall (frame=0xe79ded38) > >> > > >> > at /usr/src/sys/i386/i386/trap.c:1035 > >> > > >> > > #18 0xc0a2fc70 in Xint0x80_syscall () > >> > > >> > at /usr/src/sys/i386/i386/exception.s:196 > >> > > >> > > #19 0x00000033 in ?? () > >> > > Previous frame inner to this frame (corrupt stack?) > >> > > >> > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on > >> > 6.x with NFS with no clues on what causes it. You can start by going to > >> > frame 7 and doing 'p *bp'. > >> > >> Thanks for the hints. > >> See below for more debug output. > >> I recognize that the bp struct members b_data and b_kvabase both point to a > >> chunk of memory containing the text of the Opera web page I was reading > >> when the kernel crashed. (This is indicated above: current process > >> = 1214 (opera)) > >> > >> But what is most interesting is that b_bufobj = 0x0 > >> Obviously, then trying to access bp->b_bufobj->bo_object will cause a > >> crash. So I think it would be a good idea to NULL-check the struct member > >> before trying to access it. How should I proceed? Should I post this as a > >> possible bug somewhere else, to another list? > > > > Unfortunately, it is a worse problem that b_bufobj is NULL. That means there > > is a bug elsewhere. I'll look at this some more. > > > > Hmm, can you reproduce this at all? If so, can you try the patch below. > > Hopefully it panics here which might help: > > > > Index: vfs_subr.c > > =================================================================== > > --- vfs_subr.c (revision 181629) > > +++ vfs_subr.c (working copy) > > @@ -1546,6 +1546,9 @@ > > CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); > > KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); > > > > + if (bp->flags & B_VMIO) > > + panic("brelvp of B_VMIO buffer"); > > + > > /* > > * Delete from old vnode list, if on one. > > */ > > > > -- > > John Baldwin > > > > Sorry, at the moment I don't know how to reproduce the crash. > I mentioned ntfs-ng/fuse as I got the impression that they caused a heavy load > on my box, but in the end, it was Opera which caused the crash (also causing a > heavy load, however). > What I can do is to apply your patch and play around with CPU-consuming apps to > try if I can reproduce the crash during heavy load. Ok. > Currently I'm running 7.-0-RELEASE. > Do you recommend me to upgrade to STABLE before applying the patch? No, you can just leave it as it is. At work I've seen this occasionally on 6.x, so it's probably an older bug. -- John Baldwin From mgowda82 at gmail.com Tue Aug 12 19:26:44 2008 From: mgowda82 at gmail.com (Manjunath Ranganathaiah) Date: Tue Aug 12 19:26:51 2008 Subject: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ In-Reply-To: <200808121734.30144.doconnor@gsoft.com.au> References: <200808121734.30144.doconnor@gsoft.com.au> Message-ID: On Tue, Aug 12, 2008 at 1:04 AM, Daniel O'Connor wrote: > Hi, > I have a 6.3 (RELENG_6 a bit past 6.3 actually) system which hangs when > I try and reboot (or shutdown). It has a Supermicro C2SBA+, 2ware > 9650SE and Core2Duo CPU. > > It shuts down as normal except after printing the uptime it hangs solid. > Numlock does nothing (during the shutdown process & disk sync it > toggles OK). The disks are synced OK (comes up clean when I press the > reset switch) > > Waiting (max 60 seconds) for system process 'vnlru' to stop...done > Waiting (max 60 seconds) for system process 'bufdaemon' to stop...done > Waiting (max 60 seconds) for system process 'syncer' to stop... > Syncing disks, vnodes remaining...6 5 2 3 0 1 0 0 0 done > All buffers ynced. > Swap device da0s1b removed. > Uptime: 1m52s > > > I have tried setting hw.acpi.disable_on_reboot and hw.acpi.handle_reboot > to no effect. > > I have attached a verbose dmesg. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C can you try with debug.acpi.disabled="cpu timer" ? or booting with acpi disabled -Manjunath From brix at FreeBSD.org Tue Aug 12 19:36:01 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Tue Aug 12 19:36:08 2008 Subject: command not found: problem with dash in filenames In-Reply-To: <69921218564002@webmail6.yandex.ru> References: <69921218564002@webmail6.yandex.ru> Message-ID: <20080812193558.GA38269@tirith.brixandersen.dk> On Tue, Aug 12, 2008 at 10:00:02PM +0400, KES wrote: > NOTICE: > when I run purepw it is located and runned, but > when I run pure-pw (NOTICE: dash in name) I get: Command not found Did you by any chance just install this binary? Have you tried running 'rehash' and trying again? Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080812/a2debc1d/attachment.pgp From ebutusov at gmail.com Tue Aug 12 20:38:34 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Tue Aug 12 20:38:49 2008 Subject: Hardware monitoring for Intel Atom D945GCLF. In-Reply-To: <20080811235456.GA70635@eos.sc1.parodius.com> References: <48A0BF40.2030607@gmail.com> <20080811234547.GA67278@eos.sc1.parodius.com> <20080811235456.GA70635@eos.sc1.parodius.com> Message-ID: <48A1F4B3.3050205@gmail.com> Jeremy Chadwick pisze: > On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: >> I don't need an API, but this kind of statement makes Intel sound like >> they're not willing to disclose the SMBus offsets for monitoring. I >> might have to look at lm-sensors from Linux, but that code is very >> difficult to follow. I'm not sure if Intel gives this sort of >> information out publicly, but I sure hope so. > > There's a web page mentioning this board (note: entirely Japanese) -- > > http://iktaka.dyndns.org/node/11 > > The bottom part of the page states that Linux's lm_sensors 3.0.2 can > successfully monitor temperatures, voltages, and fan RPMs on that board, > very likely via SMBus. > > Ideally I should be able to track down technical details by looking at > that code. I'd feel much more comfortable asking Intel and having them > provide necessary registers and offsets, though; I prefer to avoid > reverse-engineering things if possible (less mistakes). > Thanks for the reply. Looks like there is no tool for FreeBSD which supports ICH7 currently. mbmon has support for ICH6, but I'm not sure is it still alive. What about your project, are you planing to release it to the public in nearest future? Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From koitsu at FreeBSD.org Tue Aug 12 21:57:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 12 21:57:31 2008 Subject: Hardware monitoring for Intel Atom D945GCLF. In-Reply-To: <48A1F4B3.3050205@gmail.com> References: <48A0BF40.2030607@gmail.com> <20080811234547.GA67278@eos.sc1.parodius.com> <20080811235456.GA70635@eos.sc1.parodius.com> <48A1F4B3.3050205@gmail.com> Message-ID: <20080812215723.GA39839@eos.sc1.parodius.com> On Tue, Aug 12, 2008 at 10:38:11PM +0200, Eugene Butusov wrote: > Jeremy Chadwick pisze: >> On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: >>> I don't need an API, but this kind of statement makes Intel sound like >>> they're not willing to disclose the SMBus offsets for monitoring. I >>> might have to look at lm-sensors from Linux, but that code is very >>> difficult to follow. I'm not sure if Intel gives this sort of >>> information out publicly, but I sure hope so. >> >> There's a web page mentioning this board (note: entirely Japanese) -- >> >> http://iktaka.dyndns.org/node/11 >> >> The bottom part of the page states that Linux's lm_sensors 3.0.2 can >> successfully monitor temperatures, voltages, and fan RPMs on that board, >> very likely via SMBus. >> >> Ideally I should be able to track down technical details by looking at >> that code. I'd feel much more comfortable asking Intel and having them >> provide necessary registers and offsets, though; I prefer to avoid >> reverse-engineering things if possible (less mistakes). >> > > Thanks for the reply. Looks like there is no tool for FreeBSD which > supports ICH7 currently. mbmon has support for ICH6, but I'm not sure is > it still alive. You have to understand, it's hard for a program to say it "supports a chipset" unless that specific chipset is doing the H/W monitoring. For example, lots of Supermicro boards use Winbond H/W monitoring ICs, but you can interface with the chip via SMBus. The chipsets on those boards are Intel ICHx (ICH7 through 9), but the ICHx doesn't do the monitoring. I'm not sure the ICHx chips can actually do monitoring natively; I haven't looked at the specifications. If they do, that may be what mbmon is talking about -- otherwise, it might just be a vague description that more or less says "works with Intel ICHx chipsets that support SMBus". Hard to explain really... > What about your project, are you planing to release it to the public > in nearest future? Once I get a couple more Supermicro boards added, yep. The code is rock solid at this point in time[1], but there's still a lot to be done before I consider it worthy of public release. Remaining items on my TODO list for bsdhwmon: * Poke individuals testing software for further updates (many have been quiet since the last tarball) * Write manpage * Update README, and INSTALL (if necessary) * Update Makefile to be FreeBSD ports-friendly, and general cleanup * Make a FreeBSD port for the software These are things I myself have to do. I'm sorry I don't have an ETR for you -- I really wish I did. [1]: No crashes/segfaults, and compiles cleanly with -Werror -Wall -Wunused -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wdisabled-optimization -Wfloat-equal -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wunreachable-code -Wwrite-strings I'm one of those "warnings should be taken seriously" individuals. :-) -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Tue Aug 12 21:58:16 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Aug 12 21:58:22 2008 Subject: Fwd: Re: command not found: problem with dash in filenames Message-ID: <20080812215815.GA40223@eos.sc1.parodius.com> ----- Forwarded message from KES ----- > From: KES > To: koitsu@freebsd.org > Date: Tue, 12 Aug 2008 23:40:08 +0400 > Subject: Re: command not found: problem with dash in filenames > > > > 12.08.08, 22:25, "Jeremy Chadwick" : > > > On Tue, Aug 12, 2008 at 10:00:02PM +0400, KES wrote: > > > NOTICE: > > > when I run purepw it is located and runned, but > > > when I run pure-pw (NOTICE: dash in name) I get: Command not found > > > kes# env |grep PATH > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > > kes# env | grep PATH > > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > > kes# ls -l /usr/local/bin/pure* > > > -r-xr-xr-x 1 root wheel 24052 12 ??? 06:24 /usr/local/bin/pure-pw > > > -r-xr-xr-x 1 root wheel 4432 12 ??? 06:24 /usr/local/bin/pure-pwconvert > > > -r-xr-xr-x 1 root wheel 6016 12 ??? 06:24 /usr/local/bin/pure-statsdecode > > > kes# pure-pw > > > pure-pw: Command not found > > > kes# /usr/local/bin/pure-pw > > > > > > Usage : > > > > > > pure-pw useradd [-f ] -u [-g ] > > > -D/-d [-c ] > > > [-t ] [-T ] > > > ......... > > > kes# cp pure-pw purepw > > > kes# purepw > > > > > > Usage : > > > > > > pure-pw useradd [-f ] -u [-g ] > > > -D/-d [-c ] > > > [-t ] [-T ] > > > ........ > > Looks like you're using csh/tcsh. Try using "rehash" and see if it > > fixes the problem for you. > > thank you very mach > problem was resolved > ----- End forwarded message ----- Individual replied to me off-list; "refresh" was indeed the answer. -- | Jeremy Chadwick jdc 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 | From unga888 at yahoo.com Wed Aug 13 04:46:18 2008 From: unga888 at yahoo.com (Unga) Date: Wed Aug 13 04:46:25 2008 Subject: sysinstall compilation issue In-Reply-To: <76940.80951.qm@web57013.mail.re3.yahoo.com> Message-ID: <268893.22415.qm@web57009.mail.re3.yahoo.com> --- On Tue, 8/12/08, Unga wrote: > From: Unga > Subject: Re: sysinstall compilation issue > To: freebsd-stable@FreeBSD.ORG > Cc: olli@lurza.secnetix.de > Date: Tuesday, August 12, 2008, 3:28 PM > --- On Fri, 8/8/08, Oliver Fromme > wrote: > > > From: Oliver Fromme > > Subject: Re: sysinstall compilation issue > > To: freebsd-stable@FreeBSD.ORG, unga888@yahoo.com > > Date: Friday, August 8, 2008, 9:36 PM > > Unga wrote: > > > This is i386 RELENG_7. > > > > > > Following section of the > > /usr/src/usr.sbin/sysinstall/Makefile does not > generate C > > code properly: > > > > > > makedevs.c: Makefile rtermcap > > > echo '#include > ' > > > makedevs.c > > > ${RTERMCAP} ansi | \ > > > file2c 'const char > termcap_ansi[] > > = {' ',0};' \ > > > > > makedevs.c > > > > > > At compile time, above expands to: > > > > > > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src > > ./rtermcap ansi | file2c 'const char > termcap_ansi[] = > > {' ',0};' >> makedevs.c > > > > > > Which generates C code as follows: > > > const char termcap_ansi[] = { > > > > > > ,0}; > > > > > > That is, it generates 3 lines, which results a > > compilation error. > > > > > > I presume, intended generated code should be: > > > const char termcap_ansi[] = {' ',0}; > > > > > > Am I right? > > > > No, it should generate an array containung a dump of > > the "ansi" termcap entry. Please see the > > file2c(1) > > manpage. > > > > > What is wrong at my end? > > > > > > Note, I linked the rtermcap with ncursesw > libraries, > > can that be the cause? Any ideas? > > > > Yes, that's the cause. Why did you do that? > > > > FreeBSD's ncurses port contains a patch so the > > tgetent() > > function (which is used by rtermcap) returns the > actual > > termcap entry in the buffer. The original ncurses > code > > (which is terminfo based) doesn't do that. > > > > When you linked rtermcap with the wrong library, you > > restored the original behaviour of tgetent(), so the > > output of rtermcap was empty, so file2c produced > invalid > > source. > > > > Sorry for my late reply on this. I was not well during > weekend, an eye ache due to over work :( > > Here is the situation at my end, no matter whether I link > with ncurses widec libs or non-widec libs, its still return > the same code as above I mentioned. > > Possible causes can be: > 1. The way I compile and install ncurses is not correct. > 2. OR some essential files required are missing > 3. OR there can be an other option > > I used truss as follows: > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src > truss -o truss.log -f ./rtermcap ansi | file2c 'const > char termcap_ansi[] = {' ',0};' >> > makedevs.c > > The last few lines of truss.log shows: > 9310: > stat("/usr/share/misc/terminfo.db",{mode=-rw-r--r-- > ,inode=22613331,size= > 3170304,blksize=4096}) = 0 (0x0) > 9310: > open("/usr/share/misc/terminfo.db",O_RDONLY,0644) > = 4 (0x4) > 9310: fcntl(4,F_SETFD,FD_CLOEXEC) = 0 (0x0) > 9310: > read(4,"\0\^F\^Ua\0\0\0\^B\0\0\^D\M-R\0"...,260) > = 260 (0x104) > 9310: > __sysctl(0xbfbfd574,0x2,0xbfbfd570,0xbfbfd57c,0x0,0x0) = 0 > (0x0) > 9310: lseek(4,0x132000,SEEK_SET) = 1253376 > (0x132000) > 9310: > read(4,"\^^\0\M-|\^O\M-T\^O\M-K\^O\M-*"...,4096) > = 4096 (0x1000) > 9310: lseek(4,0x26b000,SEEK_SET) = 2535424 > (0x26b000) > 9310: > read(4,"\n\0\M-Y\^O\^O\n\0\n\r\^D\^E\^D"...,4096) > = 4096 (0x1000) > 9310: close(4) = 0 (0x0) > 9310: ioctl(2,TIOCGETA,0xbfbfdba4) = 0 (0x0) > 9310: ioctl(2,TIOCGETA,0x81020d8) = 0 (0x0) > 9310: ioctl(2,TIOCGETA,0xbfbfdb64) = 0 (0x0) > 9310: ioctl(2,TIOCGWINSZ,0xbfbfdbc4) = 0 (0x0) > 9310: fstat(1,{mode=p--------- > ,inode=0,size=0,blksize=4096}) = 0 (0x0) > 9310: process exit, rval = 0 > > Note, above log has no entry to open > /usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src. > > So what can be the issue, ncurses has not been patched > correctly or some essential files missing? If you guys think > that ncurses has not been patched correctly, then I'll > open another thread to discuss that. > There is another update. I have tested it with ncurses and ncurses-devel ports. It seems they don't work as the ncurses in the base system. The test is as follows: cc -o rtermcap /usr/src/usr.sbin/sysinstall/rtermcap.c /usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib/libncurses.so.5.6 /usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib/libtinfo.so.5.6 export LD_LIBRARY_PATH=/usr/ports/devel/ncurses/work/ncurses-5.6/build.nowidec/lib cp -v mypath/terminfo.db /usr/local/share/misc/ TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c cat makedevs.c const char termcap_ansi[] = { ,0}; Please note above mypath/terminfo.db is from my build. Another observation is ncurses in the base system does not look for terminfo.db, where as ncurses and ncurses-devel ports look for terminfo.db. So the question is, do ncurses and ncurses-devel ports do the same thing as ncurses in base system for the following statement? TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c Any ideas? Best Regrds Unga From pluknet at gmail.com Wed Aug 13 07:33:46 2008 From: pluknet at gmail.com (pluknet) Date: Wed Aug 13 07:33:54 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: <200808121111.37427.jhb@freebsd.org> References: <20080730113449.GD407@cdnetworks.co.kr> <200808111315.23879.jhb@freebsd.org> <200808121111.37427.jhb@freebsd.org> Message-ID: 2008/8/12 John Baldwin : > On Tuesday 12 August 2008 04:36:29 am pluknet wrote: >> 2008/8/11 John Baldwin : >> > On Monday 11 August 2008 12:35:17 pm pluknet wrote: >> >> 2008/8/11 John Baldwin : >> >> > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: >> >> >> Hi John, >> >> >> >> >> >> I now figured out the "who", the "why" still eludes me. >> >> >> >> >> >> So, after your MFC of ichss.c on June 27th the device now attaches at > my >> >> >> laptop. It didn't before, so it could cause no trouble. >> >> >> >> >> >> With ichss loaded, the kernel will panic 1-3 minutes after powerd has >> >> >> been started (if I kill powerd early enough, it seems pretty stable). >> >> >> >> >> >> I'm now running a kernel from 2008-08-08 with >> >> >> hint.ichss.0.disabled="1" >> >> > >> >> > Ok. Can you get a crashdump from a crash? >> >> > >> >> >> >> ehm,. I am not Ulrich Spoerlein, but I can help with this issue. >> >> >> >> my crashdump from kgdb and some debug info. >> >> (ouch, I forgot to include it in my prev. mail >> >> > http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html ) >> >> >> >> wbr, >> >> pluknet >> >> >> >> Unread portion of the kernel message buffer: >> >> >> >> >> >> Fatal trap 12: page fault while in kernel mode >> >> fault virtual address = 0x38 >> >> fault code = supervisor read, page not present >> >> instruction pointer = 0x20:0xc056cf46 >> >> stack pointer = 0x28:0xe6592ac8 >> >> frame pointer = 0x28:0xe6592ac8 >> >> code segment = base 0x0, limit 0xfffff, type 0x1b >> >> = DPL 0, pres 1, def32 1, gran 1 >> >> processor eflags = interrupt enabled, resume, IOPL = 0 >> >> current process = 2507 (powerd) >> >> Physical memory: 1014 MB >> >> Dumping 120 MB: 105 89 73 57 41 25 9 >> >> >> >> #0 doadump () at pcpu.h:195 >> >> 195 pcpu.h: No such file or directory. >> >> in pcpu.h >> >> (kgdb) bt >> >> #0 doadump () at pcpu.h:195 >> >> #1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0, >> >> dummy4=0xe6592860 "0???") at /media/src-7/sys/ddb/db_command.c:516 >> >> #2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0, >> > dopager=1) >> >> at /media/src-7/sys/ddb/db_command.c:413 >> >> #3 0xc0459655 in db_command_loop () >> > at /media/src-7/sys/ddb/db_command.c:466 >> >> #4 0xc045b17c in db_trap (type=12, code=0) >> >> at /media/src-7/sys/ddb/db_main.c:228 >> >> #5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88) >> >> at /media/src-7/sys/kern/subr_kdb.c:524 >> >> #6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56) >> >> at /media/src-7/sys/i386/i386/trap.c:890 >> >> #7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56) >> >> at /media/src-7/sys/i386/i386/trap.c:812 >> >> #8 0xc0746d36 in trap (frame=0xe6592a88) >> >> at /media/src-7/sys/i386/i386/trap.c:490 >> >> #9 0xc072fd4b in calltrap () > at /media/src-7/sys/i386/i386/exception.s:139 >> >> #10 0xc056cf46 in device_is_attached (dev=0x0) >> >> at /media/src-7/sys/kern/subr_bus.c:2228 >> >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, >> >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 >> >> #12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00, >> >> arg2=0, req=0xe6592ba4) at cpufreq_if.h:32 >> >> ---Type to continue, or q to quit--- >> >> #13 0xc0554b67 in sysctl_root (oidp=Variable "oidp" is not available. >> >> ) >> >> at /media/src-7/sys/kern/kern_sysctl.c:1306 >> >> #14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14, >> > namelen=4, >> >> old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4, >> >> retval=0xe6592c10, flags=0) > at /media/src-7/sys/kern/kern_sysctl.c:1401 >> >> #15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc) >> >> at /media/src-7/sys/kern/kern_sysctl.c:1336 >> >> #16 0xc07466d5 in syscall (frame=0xe6592d38) >> >> at /media/src-7/sys/i386/i386/trap.c:1035 >> >> #17 0xc072fdb0 in Xint0x80_syscall () >> >> at /media/src-7/sys/i386/i386/exception.s:196 >> >> #18 0x00000033 in ?? () >> >> Previous frame inner to this frame (corrupt stack?) >> >> (kgdb) f 11 >> >> #11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4, >> >> priority=100) at /media/src-7/sys/kern/kern_cpu.c:332 >> >> 332 if (!device_is_attached(set->dev)) { >> >> (kgdb) list >> >> 327 } >> >> 328 >> >> 329 /* Next, set any/all relative frequencies via their > drivers. >> > */ >> >> 330 for (i = 0; i < level->rel_count; i++) { >> >> 331 set = &level->rel_set[i]; >> >> 332 if (!device_is_attached(set->dev)) { >> >> 333 error = ENXIO; >> >> 334 goto out; >> >> 335 } >> >> 336 >> >> (kgdb) p level.rel_count >> >> $1 = 1986356271 >> >> (kgdb) p i >> >> $2 = 0 >> >> (kgdb) p level.rel_set >> >> $3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, > 0, >> >> 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = > {0, >> > 0, >> >> 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = >> > {0, >> >> 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, > spec = >> > { >> >> 0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, >> >> spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, >> >> dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, { >> >> freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fffffff, spec > = >> > { >> >> ----- and so on----- >> >> >> >> Also there are very unusual (and high) numbers in sysctl >> > dev.cpu.0.freq_levels. >> > >> > Which cpufreq drivers are you using? Can you narrow down your panics (and >> > weird frequencies in the sysctl) to being caused by a specific cpufreq >> > driver? >> >> They are est/p4tcc/ichss. >> hint.ichss.0.disbled="1" helped me to avoid panics and those weired >> freqs in dev.cpu. >> Now it shows: >> cpu0: on acpi0 >> est0: on cpu0 >> p4tcc0: on cpu0 >> and dev.cpu.0.freq_levels are as expected (and as it was earlier >> before this problem): >> 1600/-1 1400/-1 1225/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 >> 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 [sorry, was far afk] > > Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is only > supposed to be used if you don't have est0, and this patch fixes that. I'm Works now as it should (i.e. ichss0 does not attach). > curious if you get panics if you have disable est0 and leave ichss0 enabled > or if that works ok? Yes, it works ok with hint.est.0.disabled="1" (with somewhat different freq's (and subjectively a bit slower even with max freq)): cpu0: on acpi0 ichss0: on cpu0 ichss0: enabling SpeedStep support p4tcc0: on cpu0 acpi_acad0: on acpi0 $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 795 dev.cpu.0.freq_levels: 1590/-1 1391/-1 1192/-1 993/-1 795/-1 596/-1 397/-1 198/-1 dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% Thanks, pluknet From olli at lurza.secnetix.de Wed Aug 13 09:28:54 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Aug 13 09:29:02 2008 Subject: sysinstall compilation issue In-Reply-To: <268893.22415.qm@web57009.mail.re3.yahoo.com> Message-ID: <200808130928.m7D9SPmG027548@lurza.secnetix.de> Hello, Unga wrote: > > Oliver Fromme wrote: > > > Unga wrote: > > > > [...] > > > > What is wrong at my end? > > > > > > > > Note, I linked the rtermcap with ncursesw > > > > libraries, can that be the cause? Any ideas? > > > > > > Yes, that's the cause. Why did you do that? > > > > > > FreeBSD's ncurses port contains a patch so the > > > tgetent() function (which is used by rtermcap) > > > returns the actual termcap entry in the buffer. > > > The original ncurses code (which is terminfo- > > > based) doesn't do that. > > > > > > When you linked rtermcap with the wrong library, > > > you restored the original behaviour of tgetent(), > > > so the output of rtermcap was empty, so file2c > > > produced invalid source. > > > > Sorry for my late reply on this. I was not well during > > weekend, an eye ache due to over work :( Sorry to hear that. I hope you're better now. > > Here is the situation at my end, no matter whether I link > > with ncurses widec libs or non-widec libs, its still return > > the same code as above I mentioned. > > > > Possible causes can be: > > 1. The way I compile and install ncurses is not correct. > > 2. OR some essential files required are missing > > 3. OR there can be an other option Maybe my first response wasn't clear enough. So let me explain it again: To compile sysinstall correctly you must use the standard ncurses library from the base system. Anything else WILL NOT WORK. I already explained the reason for that in detail in my previous response (quoted above). > So the question is, do ncurses and ncurses-devel ports > do the same thing as ncurses in base system for the > following statement? > TERMCAP=/usr/src/usr.sbin/sysinstall/../../share/termcap/termcap.src ./rtermcap ansi | file2c 'const char termcap_ansi[] = {' ',0};' >> makedevs.c No, they don't do the same thing. You could have saved yourself some time if you had read my first response more carefully. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable From markus at vervier.info Wed Aug 13 10:05:02 2008 From: markus at vervier.info (Markus Vervier) Date: Wed Aug 13 10:05:10 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> Message-ID: <48A2B1CB.7060303@vervier.info> Jack Vogel wrote: > > I didn't mean the NIC EEPROM, but the system BIOS, make sure you are > running the version that Jeremy said he was, if that matches you might go > look at settings in the BIOS that are about management. > I'm now running the latest BIOS for my X60 version 2.22 with the same results. Jeremy runs version 1.15 but on a T60. > I thought you told us that when you had a back to back connection that it > worked, no?? Sorry, it does not work when having a b2b connection, never said that. But I noticed another thing: It is important that the device was up without a cable connected: 1. power off completely 2. boot freebsd without a cable connected 3. in a rootshell do ifconfig em0 up 4. connect the cable 5. no link -- Markus From BORJAMAR at SARENET.ES Wed Aug 13 10:31:25 2008 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Wed Aug 13 10:31:33 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <20080812102856.GA6735@eos.sc1.parodius.com> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> Message-ID: <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> On Aug 12, 2008, at 12:28 PM, Jeremy Chadwick wrote: > Please be sure to report back with the outcome (in a few days, or > whenever suits you) -- I've seen a report of similar oddities (threads > locking up) on the suPHP mailing list, when using Apache with the > worker > MPM. No one stated what state the process is in (re: umtxn), so I'm > not > sure if it's the same issue as what you've seen. I've recompiled Apache with the debug options. Just to see if there was a difference I've tried the apr from the ports, but it's the same. However, the incidence of this problem seems to be lower. %ldd /usr/local/sbin/httpd /usr/local/sbin/httpd: libm.so.5 => /lib/libm.so.5 (0x380e1000) libaprutil-1.so.3 => /usr/local/lib/libaprutil-1.so.3 (0x380f6000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x38111000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x3813d000) libapr-1.so.3 => /usr/local/lib/libapr-1.so.3 (0x38231000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x38255000) libthr.so.3 => /lib/libthr.so.3 (0x3826e000) libc.so.7 => /lib/libc.so.7 (0x38281000) And I've hooked gdb to one of the stuck processes, %gdb -p 51845 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Attaching to process 51845 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Strange, it seems gdb is having problems with this? Anyway I go ahead. The stack seems to be corrupted. I've observed that the incidence of this problem is much lower if I lower the MaxRequestsPerChild parameter in Apache. Other than this, it's working very well, and performance is decent. I include a link to the system statistics generated with Devilator/Orca. Please don't load this link a lot, it's behind a household 384 Kbps outbound DSL :) http://212.81.200.214/orca/o_macuarium-hourly.html http://212.81.200.214/orca/o_macuarium-daily.html http://212.81.200.214/orca/o_macuarium-weekly.html ((Sorry for the long dump)) (gdb) bt #0 0x3827cfe7 in __error () from /lib/libthr.so.3 #1 0x3827cd4a in __error () from /lib/libthr.so.3 #2 0x08702120 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x08702100 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbdfe4ea8 in ?? () #9 0x3827b4fe in pthread_cond_init () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 2 [Switching to thread 2 (Thread 0x8705900 (LWP 100279))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe0e5c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 3 [Switching to thread 3 (Thread 0x8705800 (LWP 100275))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe1e6c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 4 [Switching to thread 4 (Thread 0x8705700 (LWP 100273))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe2e7c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 5 [Switching to thread 5 (Thread 0x8705600 (LWP 100266))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe3e8c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 6 [Switching to thread 6 (Thread 0x8705500 (LWP 100262))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe4e9c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 7 [Switching to thread 7 (Thread 0x8705400 (LWP 100258))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe5eac18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 8 [Switching to thread 8 (Thread 0x8705300 (LWP 100256))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe6ebc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 9 [Switching to thread 9 (Thread 0x8705200 (LWP 100255))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642100 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe7ec5c8 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 10 [Switching to thread 10 (Thread 0x8705100 (LWP 100253))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe8edc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 11 [Switching to thread 11 (Thread 0x8705000 (LWP 100252))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbe9eec18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 12 [Switching to thread 12 (Thread 0x8704f00 (LWP 100244))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbeaefc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 13 [Switching to thread 13 (Thread 0x8704e00 (LWP 100243))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbebf0c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 14 [Switching to thread 14 (Thread 0x8704d00 (LWP 100241))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbecf1c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) yjread 15 Undefined command: "yjread". Try "help". (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbecf1c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 (gdb) thread 15 [Switching to thread 15 (Thread 0x8704c00 (LWP 100239))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbedf2c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 16 [Switching to thread 16 (Thread 0x8704b00 (LWP 100238))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbeef3c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 17 [Switching to thread 17 (Thread 0x8704a00 (LWP 100237))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbeff4c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 18 [Switching to thread 18 (Thread 0x8704900 (LWP 100236))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf0f5c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 19 [Switching to thread 19 (Thread 0x8704800 (LWP 100226))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf1f6c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 20 [Switching to thread 20 (Thread 0x8704700 (LWP 100223))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf2f7c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 21 [Switching to thread 21 (Thread 0x8704600 (LWP 100222))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf3f8c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 22 [Switching to thread 22 (Thread 0x8704500 (LWP 100205))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf4f9c18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 23 [Switching to thread 23 (Thread 0x8704400 (LWP 100204))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf5fac18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 24 [Switching to thread 24 (Thread 0x8704300 (LWP 100202))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf6fbb68 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 25 [Switching to thread 25 (Thread 0x8704200 (LWP 100192))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf7fcc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 26 [Switching to thread 26 (Thread 0x8704100 (LWP 100190))]#0 0x382c578b in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382c578b in _umtx_op () from /lib/libc.so.7 #1 0x3827ce0d in __error () from /lib/libthr.so.3 #2 0x08642140 in ?? () #3 0x00000005 in ?? () #4 0x00000000 in ?? () #5 0x00000000 in ?? () #6 0x00000000 in ?? () #7 0x3827e914 in ?? () from /lib/libthr.so.3 #8 0xbf8fdc18 in ?? () #9 0x38278818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) thread 27 [Switching to thread 27 (Thread 0x8102100 (LWP 100390))]#0 0x3835c6a3 in read () from /lib/libc.so.7 (gdb) bt #0 0x3835c6a3 in read () from /lib/libc.so.7 #1 0x382736e2 in read () from /lib/libthr.so.3 #2 0x08095944 in ap_mpm_pod_check (pod=0x8289f18) at pod.c:54 #3 0x080932ab in child_main (child_num_arg=0) at worker.c:1258 #4 0x0809345e in make_child (s=0x8110f10, slot=0) at worker.c:1341 #5 0x08093981 in perform_idle_server_maintenance () at worker.c:1543 #6 0x08093bb8 in server_main_loop (remaining_children_to_start=0) at worker.c:1646 #7 0x08093f14 in ap_mpm_run (_pconf=0x810f018, plog=0x813d018, s=0x8110f10) at worker.c:1748 #8 0x08064289 in main (argc=Error accessing memory address 0x0: Bad address. ) at main.c:730 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/sbin/httpd, process 51845 From doconnor at gsoft.com.au Wed Aug 13 11:26:02 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Aug 13 11:26:10 2008 Subject: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ In-Reply-To: References: <200808121734.30144.doconnor@gsoft.com.au> Message-ID: <200808132055.56039.doconnor@gsoft.com.au> On Wed, 13 Aug 2008, Manjunath Ranganathaiah wrote: > can you try with debug.acpi.disabled="cpu timer" ? or booting with > acpi disabled I tried the former (put it in loader.conf right?) and it made no difference. I'll try disabling ACPI tomorrow (I tried it remotely so it's hung now :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080813/0d4a8d87/attachment.pgp From sebster at sebster.com Wed Aug 13 13:10:48 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Wed Aug 13 13:10:56 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080806101941.GA52952@eos.sc1.parodius.com> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> Message-ID: <48A2DD60.7090702@sebster.com> Hi, Just an update on this issue. Quick summary: I fixed the BIOS issues, the hardware monitor issues, and the rl0/rl1 watchdog timeout issues (it seems). However I'm still having problems with my SATA drives (or at least one of them). More info below. BIOS: I flashed my BIOS to the latest version about a year ago, and never noticed that there was any problem, but it turns out there was. I never reset the BIOS to default factory settings after the upgrade, and it seems the settings were corrupt. After having reset the BIOS to the "default optimized factory settings" it stopped crashing when I go into the H/W monitor and also when using healthd -d (output below): Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.14; Volt. = 3.33, 4.97, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 4.97, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 Temp.= 40.0, 36.0, 66.0; Rot.= 0, 0, 0 Vcore = 1.44, 3.12; Volt. = 3.34, 5.00, 1.95, -0.11, -1.54 This also seems to have fixed the rl0 watchdog timeout problems. I no longer see those in my logs. SATA DRIVES: I'm still having problems with the SATA drives. I tried connecting the 1TB Samsung drives to my mainboard, but then the box hangs when booting with the "Detecting IDE drives" message. The regular (PATA) IDE drives are detected first, and then it repeats the "Detecting IDE drives" message to detect the sata drives, and hangs. When I connect my 250GB SATA drives to my mainboard they detect fine, and the box boots normally. I did another rsync of my old mirror (the 250GB disks) to the new mirror (1TB disks), but again one of the disks got detached. This time there are no other messages in the log, the only thing I see is the following: Aug 13 14:35:27 piglet su: sebster to root on /dev/ttyp5 Aug 13 14:55:38 piglet kernel: ad6: FAILURE - device detached Aug 13 14:55:38 piglet kernel: subdisk6: detached Aug 13 14:55:38 piglet kernel: ad6: detached Aug 13 14:55:38 piglet kernel: GEOM_MIRROR: Device gm1: provider ad6 disconnected. Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to size>100K (unfortunate that the log file just got rotated, but in the new log file there is nothing execpt the one expected line: Aug 13 15:00:00 piglet newsyslog[1800]: logfile turned over due to size>100K So, nothing after the disconnect... The questions I have now is: 1) Could an upgrade to FreeBSD 7-STABLE fix the issue (it's a LOT of work for me, but I'll do it if there are SATA driver issues fixed). 2) What is the next step? Should I repeat the tests to see if it's always the same drive that disconnects? 3) Is there any way to get more info about what is causing the disconnect? Regards, Sebastiaan Jeremy Chadwick wrote: > On Wed, Aug 06, 2008 at 02:57:48AM -0700, Jeremy Chadwick wrote: >> vmstat -i output should help clear that up, or dmesg output. > > Sebastiaan has included vmstat -i output in another part of this thread, > as well as dmesg output for the ATA disks and controllers: > > atapci0: port 0xd200-0xd207,0xd300-0xd303,0xd400-0xd407,0xd500-0xd503,0xd600-0xd60f mem 0xf6081000-0xf60811ff irq 18 at device 10.0 on pci0 > ata2: on atapci0 > ata3: on atapci0 > atapci1: port 0xd700-0xd707,0xd800-0xd803,0xd900-0xd907,0xda00-0xda03,0xdb00-0xdb0f,0xdc00-0xdcff irq 20 at device 15.0 on pci0 > ata4: on atapci1 > ata5: on atapci1 > atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xdd00-0xdd0f at device 15.1 on pci0 > ata0: on atapci2 > ata1: on atapci2 > ad0: 286188MB at ata0-master UDMA133 > ad1: 239372MB at ata0-slave UDMA133 > acd0: DVDR at ata1-master UDMA33 > ad4: 953869MB at ata2-master SATA150 > ad6: 953869MB at ata3-master SATA150 > ad8: 239372MB at ata4-master SATA150 > ad10: 239372MB at ata5-master SATA150 > > interrupt total rate > irq6: fdc0 10 0 > irq14: ata0 645057 7 > irq15: ata1 58 0 > irq16: rl0 7168276 82 > irq17: rl1 914667 10 > irq18: atapci0 30072876 347 > irq20: atapci1 1126099 12 > irq21: uhci0 uhci* 308 0 > irq23: vr0 3265771 37 > cpu0: timer 173289011 1999 > Total 216482133 2498 > > Here's a breakdown, so no one gets confused: > > ad0 = 300GB Maxtor disk, attached to on-board VIA IDE controller > ad1 = 250GB Maxtor disk, attached to on-board VIA IDE controller > ad4 = 1TB Samsung disk, attached to Silicon Image SATA controller > ad6 = 1TB Samsung disk, attached to Silicon Image SATA controller > ad8 = 250GB Maxtor disk, attached to on-board VIA SATA controller > ad10 = 250GB Maxtor disk, attached to on-board VIA SATA controller > > IRQ 14 -- atapci2 = On-board VIA IDE controller (primary) > IRQ 15 -- atapci2 = On-board VIA IDE controller (slave) > IRQ 16 -- rl0 = Realtek NIC > IRQ 17 -- rl1 = Realtek NIC > IRQ 18 -- atapci0 = Silicon Image SATA controller > IRQ 20 -- atapci1 = On-board VIA SATA controller > > An APIC is obviously in use here. > > The problem reported is with disks ad4 and ad6, residing on the Silicon > Image controller. When the problem happens, rl1 emits watchdog > timeouts, and disks ad4 and ad6 fall off the bus. > > SMART statistics on both ad4 and ad6 show no signs of the disks being > power-cycled, sector errors, or anything that would indicate either disk > is bad. > > His PSU is 450W, brand unknown. > > Sebastiaan, do you know if the BIOS on this system has a Health monitor, > showing voltages and temperatures of things? If so, can you reboot the > system, go into that part of the BIOS, and write down (or take a photo) > of the voltages/temperatures? > > I'm wondering if maybe one of the voltages is too low or high, or > fluxuates severely with so many devices. It could be enough to cause > some of the ASICs to malfunction, possibly multiples... > > I cleared the possibility of this being a PSU problem, but that was > before I knew you were seeing watchdog timeouts on one of your NICs at > the *exact same time* as disks off the Silicon Image controller. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080813/52a5e378/smime.bin From kris at FreeBSD.org Wed Aug 13 13:18:48 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Aug 13 13:18:55 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> Message-ID: <48A2DF31.4050907@FreeBSD.org> Borja Marcos wrote: > ((Sorry for the long dump)) > (gdb) bt > #0 0x3827cfe7 in __error () from /lib/libthr.so.3 > #1 0x3827cd4a in __error () from /lib/libthr.so.3 > #2 0x08702120 in ?? () As you can see the debugging symbols are still not available. Refer to the developers handbook if you need more assistance doing this. Also, it is worth carefully checking your php configuration. For example, php is notoriously sensitive to the order in which modules are defined, and will crash or misbehave without giving any other warnings if you don't meet its expectations. That may or may not be relevant in your situation. Kris From BORJAMAR at SARENET.ES Wed Aug 13 13:28:31 2008 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Wed Aug 13 13:28:39 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <48A2DF31.4050907@FreeBSD.org> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> Message-ID: On Aug 13, 2008, at 3:18 PM, Kris Kennaway wrote: > Borja Marcos wrote: >> ((Sorry for the long dump)) >> (gdb) bt >> #0 0x3827cfe7 in __error () from /lib/libthr.so.3 >> #1 0x3827cd4a in __error () from /lib/libthr.so.3 >> #2 0x08702120 in ?? () > > As you can see the debugging symbols are still not available. Refer > to the developers handbook if you need more assistance doing this. Hmm. Weird. I compiled the port having WITH_DEBUG defined (as I saw in the Makefile) and indeed the gcc invocations has the -g flag set. What is strange is the error gdb issued, offering a coredump, etc. > Also, it is worth carefully checking your php configuration. For > example, php is notoriously sensitive to the order in which modules > are defined, and will crash or misbehave without giving any other > warnings if you don't meet its expectations. That may or may not be > relevant in your situation. Just in case I didn't change the order of the modules. I'll keep looking at it. Borja. From kris at FreeBSD.org Wed Aug 13 13:33:40 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Aug 13 13:33:47 2008 Subject: umtxn and Apache 2.2 In-Reply-To: References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> Message-ID: <48A2E2AD.8060607@FreeBSD.org> Borja Marcos wrote: > > On Aug 13, 2008, at 3:18 PM, Kris Kennaway wrote: > >> Borja Marcos wrote: >>> ((Sorry for the long dump)) >>> (gdb) bt >>> #0 0x3827cfe7 in __error () from /lib/libthr.so.3 >>> #1 0x3827cd4a in __error () from /lib/libthr.so.3 >>> #2 0x08702120 in ?? () >> >> As you can see the debugging symbols are still not available. Refer >> to the developers handbook if you need more assistance doing this. > > Hmm. Weird. I compiled the port having WITH_DEBUG defined (as I saw in > the Makefile) and indeed the gcc invocations has the -g flag set. What > is strange is the error gdb issued, offering a coredump, etc. It is likely that the binaries are stripped on install then. You can try to run gdb against the compiled versions in the port work/ directory. >> Also, it is worth carefully checking your php configuration. For >> example, php is notoriously sensitive to the order in which modules >> are defined, and will crash or misbehave without giving any other >> warnings if you don't meet its expectations. That may or may not be >> relevant in your situation. > > Just in case I didn't change the order of the modules. I'll keep looking > at it. This could be why :) Some people report that previously working configurations stopped working after an upgrade until the ordering was changed. Kris From kostikbel at gmail.com Wed Aug 13 13:42:19 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Aug 13 13:42:26 2008 Subject: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] In-Reply-To: <200808130022.m7D0MCaK082721@freefall.freebsd.org> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> Message-ID: <20080813134210.GG1803@deviant.kiev.zoral.com.ua> On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > Dear Konstantin Belousov, > > As you have requested, I would like to notify you that you have > committed a change that may be MFC'ed now, as a testing period > specified at the time of that commit is over. > > For reference purposes following is a copy of your original > commit message. > > Regards, > > Maxim "MFC Reminder" Sobolev > P.S. Please contact Maxim Sobolev if you > believe that you received this message due to an error. > > kib 2008-07-30 11:30:55 UTC > > FreeBSD src repository > > Modified files: > sys/amd64/amd64 cpu_switch.S genassym.c > sys/amd64/ia32 ia32_signal.c > sys/amd64/include pcb.h > sys/amd64/linux32 linux32_machdep.c > Log: > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > the 32bit images on amd64. > > Change the semantic of the PCB_32BIT pcb flag to request the context > switch code to operate on the segment registers. Its previous meaning > of saving or restoring the %gs base offset is assigned to the new > PCB_GS32BIT flag. > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > emulation sets PCB_32BIT | PCB_GS32BIT. > > Reviewed by: peter > MFC after: 2 weeks > > Revision Changes Path > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > 1.65 +1 -0 src/sys/amd64/include/pcb.h > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c This appeared to be a not quite trivial MFC to perform. The reason for complication is that the HEAD code for amd64 context switch was changed, in particular by the r177535 by peter@. The r177535 formally requires r177533 for the definition of the TDP_KTHREAD symbol for asm. The definition is needed for optimization of the context switch to the "pure kernel thread", introduced in r173004 that is not MFCed either, and possibly never be. I do not want to backport the code to the old context switch, that would mean a rewrite from scratch. Instead, I merged the r177535 (optimization of context switch by peter@), and commented out corresponding test in the cpu_switch.S for the TDP_KTHREAD. I would be glad to get an opinions on the approach taken, and especially for the wider testing on the RELENG_7/amd64. The problem better be solved for 7.1. The patch: http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080813/b85ccd64/attachment.pgp From BORJAMAR at SARENET.ES Wed Aug 13 14:56:15 2008 From: BORJAMAR at SARENET.ES (Borja Marcos) Date: Wed Aug 13 14:56:22 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <48A2E2AD.8060607@FreeBSD.org> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> <48A2E2AD.8060607@FreeBSD.org> Message-ID: <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> On Aug 13, 2008, at 3:33 PM, Kris Kennaway wrote: >> Hmm. Weird. I compiled the port having WITH_DEBUG defined (as I saw >> in the Makefile) and indeed the gcc invocations has the -g flag >> set. What is strange is the error gdb issued, offering a coredump, >> etc. > > It is likely that the binaries are stripped on install then. You > can try to run gdb against the compiled versions in the port work/ > directory. Doesn't seem stripped to me... %file /usr/local/sbin/httpd /usr/local/sbin/httpd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700110), dynamically linked (uses shared libs), FreeBSD-style, not stripped %gdb /usr/local/sbin/httpd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) r Starting program: /usr/local/sbin/httpd [New LWP 100152] [New Thread 0x8102100 (LWP 100152)] (48)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs Program exited with code 01. Any know bug affecting gdb on FreeBSD 7-STABLE/i386? "devilator" is mine, it's indeed compiled in debug mode, and gdb has problems to attach to it. It does it, but complains offering a core dump as well :/ %ps ax|fgrep devila 44336 p0- S 1:11.79 /usr/local/bin/devilator 67511 p0 R+ 0:00.00 fgrep devila %cd ~borjam/src/devilator-1.0a2/ %gdb -p 44336 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Attaching to process 44336 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Reading symbols from /usr/local/bin/devilator...done. Reading symbols from /lib/libkvm.so.4...done. Loaded symbols for /lib/libkvm.so.4 Reading symbols from /lib/libgeom.so.4...done. Loaded symbols for /lib/libgeom.so.4 Reading symbols from /lib/libdevstat.so.6...done. Loaded symbols for /lib/libdevstat.so.6 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libbsdxml.so.3...done. Loaded symbols for /lib/libbsdxml.so.3 Reading symbols from /lib/libsbuf.so.4...done. Loaded symbols for /lib/libsbuf.so.4 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x381510af in nanosleep () from /lib/libc.so.7 (gdb) bt #0 0x381510af in nanosleep () from /lib/libc.so.7 #1 0x3811f40a in sleep () from /lib/libc.so.7 #2 0x08048f4b in main () at devilator.c:47 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/bin/devilator, process 44336 >>> >>> Also, it is worth carefully checking your php configuration. For >>> example, php is notoriously sensitive to the order in which >>> modules are defined, and will crash or misbehave without giving >>> any other warnings if you don't meet its expectations. That may >>> or may not be relevant in your situation. >> Just in case I didn't change the order of the modules. I'll keep >> looking at it. > > This could be why :) Some people report that previously working > configurations stopped working after an upgrade until the ordering > was changed. Hmm. I see, I will check then. Thank you, Borja. From jfvogel at gmail.com Wed Aug 13 15:22:38 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Aug 13 15:22:45 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <48A2B1CB.7060303@vervier.info> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> Message-ID: <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> On Wed, Aug 13, 2008 at 3:04 AM, Markus Vervier wrote: > Jack Vogel wrote: >> >> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >> running the version that Jeremy said he was, if that matches you might go >> look at settings in the BIOS that are about management. >> > I'm now running the latest BIOS for my X60 version 2.22 with the same > results. Jeremy runs version 1.15 but on a T60. >> >> I thought you told us that when you had a back to back connection that it >> worked, no?? > > Sorry, it does not work when having a b2b connection, never said that. But I > noticed another thing: > > It is important that the device was up without a cable connected: > > 1. power off completely > 2. boot freebsd without a cable connected > 3. in a rootshell do ifconfig em0 up > 4. connect the cable > 5. no link Hmmm, well let me see if I can get ahold of an X60. Jack From tevans.uk at googlemail.com Wed Aug 13 15:50:34 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Wed Aug 13 15:50:42 2008 Subject: umtxn and Apache 2.2 In-Reply-To: <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> <48A2E2AD.8060607@FreeBSD.org> <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> Message-ID: <1218641046.70002.6.camel@localhost> On Wed, 2008-08-13 at 16:56 +0200, Borja Marcos wrote: > > Doesn't seem stripped to me... > > %file /usr/local/sbin/httpd > /usr/local/sbin/httpd: ELF 32-bit LSB executable, Intel 80386, version > 1 (FreeBSD), for FreeBSD 7.0 (700110), dynamically linked (uses shared > libs), FreeBSD-style, not stripped Ok, so thats the httpd binary - what about libapr, libapr-util, PHP and all your PHP extensions - are they compiled with debug and not stripped? :) Personally, I find PHP far too troublesome to run threaded. These days, I use an event MPM based front-end apache 2.2, which reverse proxies to either a prefork MPM apache 2.2 with mod_, or directly connect to a fastcgi instance. Serve all your static content from the front-end, and it's all quite fast - plus you can scale out much much more simply. Cheers Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080813/fa0374d4/attachment.pgp From jhb at freebsd.org Wed Aug 13 17:21:30 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Aug 13 17:21:41 2008 Subject: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.) In-Reply-To: References: <20080730113449.GD407@cdnetworks.co.kr> <200808121111.37427.jhb@freebsd.org> Message-ID: <200808131210.21755.jhb@freebsd.org> On Wednesday 13 August 2008 03:33:45 am pluknet wrote: > 2008/8/12 John Baldwin : > > Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is only > > supposed to be used if you don't have est0, and this patch fixes that. I'm > > Works now as it should (i.e. ichss0 does not attach). Ok, committed then thanks. > > curious if you get panics if you have disable est0 and leave ichss0 enabled > > or if that works ok? > > Yes, it works ok with hint.est.0.disabled="1" (with somewhat different > freq's (and subjectively a bit slower even with max freq)): > > cpu0: on acpi0 > ichss0: on cpu0 > ichss0: enabling SpeedStep support > p4tcc0: on cpu0 > acpi_acad0: on acpi0 > > $ sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 795 > dev.cpu.0.freq_levels: 1590/-1 1391/-1 1192/-1 993/-1 795/-1 596/-1 > 397/-1 198/-1 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% > > Thanks, > pluknet > -- John Baldwin From jfvogel at gmail.com Wed Aug 13 19:10:39 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Aug 13 19:10:45 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> Message-ID: <2a41acea0808131210r6371b532i93f1ae6963d1f1b9@mail.gmail.com> On Wed, Aug 13, 2008 at 8:22 AM, Jack Vogel wrote: > On Wed, Aug 13, 2008 at 3:04 AM, Markus Vervier wrote: >> Jack Vogel wrote: >>> >>> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >>> running the version that Jeremy said he was, if that matches you might go >>> look at settings in the BIOS that are about management. >>> >> I'm now running the latest BIOS for my X60 version 2.22 with the same >> results. Jeremy runs version 1.15 but on a T60. >>> >>> I thought you told us that when you had a back to back connection that it >>> worked, no?? >> >> Sorry, it does not work when having a b2b connection, never said that. But I >> noticed another thing: >> >> It is important that the device was up without a cable connected: >> >> 1. power off completely >> 2. boot freebsd without a cable connected >> 3. in a rootshell do ifconfig em0 up >> 4. connect the cable >> 5. no link > > Hmmm, well let me see if I can get ahold of an X60. > > Jack > Markus, I have reproduced the problem, you are correct. Thank you for persisting thru my doubts :) There is a flip side to the problem, once the interface is up and active, if you remove the cable it never shows inactive :( It must be some interrupt handling/media status issue, I'll be looking into a fix this afternoon. OH, I should note that as long as you put in a cable before you ifconfig up its fine so its not that hard to work around the issue. Stay tuned.... Jack From mgowda82 at gmail.com Wed Aug 13 19:12:31 2008 From: mgowda82 at gmail.com (Manjunath Ranganathaiah) Date: Wed Aug 13 19:12:40 2008 Subject: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ In-Reply-To: <200808132055.56039.doconnor@gsoft.com.au> References: <200808121734.30144.doconnor@gsoft.com.au> <200808132055.56039.doconnor@gsoft.com.au> Message-ID: > I tried the former (put it in loader.conf right?) and it made no > difference. I'll try disabling ACPI tomorrow (I tried it remotely so > it's hung now :) Yes, look at acpi man page for details. -Manjunath From koitsu at FreeBSD.org Wed Aug 13 19:43:45 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 13 19:44:00 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <48A2B1CB.7060303@vervier.info> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> Message-ID: <20080813194344.GA16905@eos.sc1.parodius.com> On Wed, Aug 13, 2008 at 12:04:59PM +0200, Markus Vervier wrote: > Jack Vogel wrote: >> >> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >> running the version that Jeremy said he was, if that matches you might go >> look at settings in the BIOS that are about management. >> > I'm now running the latest BIOS for my X60 version 2.22 with the same > results. Jeremy runs version 1.15 but on a T60. >> I thought you told us that when you had a back to back connection that it >> worked, no?? > Sorry, it does not work when having a b2b connection, never said that. > But I noticed another thing: > > It is important that the device was up without a cable connected: > > 1. power off completely > 2. boot freebsd without a cable connected > 3. in a rootshell do ifconfig em0 up > 4. connect the cable > 5. no link This wasn't the procedure I was following when I did testing on my T60p widescreen -- I was booting with the cable connected. I'll have to try the above procedure tonight, although it may be wasted effort as Jack was able to repro it on an X60. -- | Jeremy Chadwick jdc 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 | From jhb at freebsd.org Wed Aug 13 20:26:13 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Aug 13 20:26:27 2008 Subject: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] In-Reply-To: <20080813134210.GG1803@deviant.kiev.zoral.com.ua> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> Message-ID: <200808131548.37571.jhb@freebsd.org> On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > > Dear Konstantin Belousov, > > > > As you have requested, I would like to notify you that you have > > committed a change that may be MFC'ed now, as a testing period > > specified at the time of that commit is over. > > > > For reference purposes following is a copy of your original > > commit message. > > > > Regards, > > > > Maxim "MFC Reminder" Sobolev > > P.S. Please contact Maxim Sobolev if you > > believe that you received this message due to an error. > > > > kib 2008-07-30 11:30:55 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/amd64/amd64 cpu_switch.S genassym.c > > sys/amd64/ia32 ia32_signal.c > > sys/amd64/include pcb.h > > sys/amd64/linux32 linux32_machdep.c > > Log: > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > > the 32bit images on amd64. > > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > switch code to operate on the segment registers. Its previous meaning > > of saving or restoring the %gs base offset is assigned to the new > > PCB_GS32BIT flag. > > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > > Reviewed by: peter > > MFC after: 2 weeks > > > > Revision Changes Path > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > > This appeared to be a not quite trivial MFC to perform. The reason for > complication is that the HEAD code for amd64 context switch was changed, > in particular by the r177535 by peter@. > > The r177535 formally requires r177533 for the definition of the > TDP_KTHREAD symbol for asm. The definition is needed for optimization > of the context switch to the "pure kernel thread", introduced in > r173004 that is not MFCed either, and possibly never be. > > I do not want to backport the code to the old context switch, that would > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > of context switch by peter@), and commented out corresponding test in > the cpu_switch.S for the TDP_KTHREAD. > > I would be glad to get an opinions on the approach taken, and especially > for the wider testing on the RELENG_7/amd64. The problem better be > solved for 7.1. > > The patch: > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREAD replaced. -- John Baldwin From jhb at freebsd.org Wed Aug 13 20:26:13 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Aug 13 20:26:28 2008 Subject: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] In-Reply-To: <20080813134210.GG1803@deviant.kiev.zoral.com.ua> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> Message-ID: <200808131548.37571.jhb@freebsd.org> On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > > Dear Konstantin Belousov, > > > > As you have requested, I would like to notify you that you have > > committed a change that may be MFC'ed now, as a testing period > > specified at the time of that commit is over. > > > > For reference purposes following is a copy of your original > > commit message. > > > > Regards, > > > > Maxim "MFC Reminder" Sobolev > > P.S. Please contact Maxim Sobolev if you > > believe that you received this message due to an error. > > > > kib 2008-07-30 11:30:55 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/amd64/amd64 cpu_switch.S genassym.c > > sys/amd64/ia32 ia32_signal.c > > sys/amd64/include pcb.h > > sys/amd64/linux32 linux32_machdep.c > > Log: > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > > the 32bit images on amd64. > > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > switch code to operate on the segment registers. Its previous meaning > > of saving or restoring the %gs base offset is assigned to the new > > PCB_GS32BIT flag. > > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > > Reviewed by: peter > > MFC after: 2 weeks > > > > Revision Changes Path > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > > This appeared to be a not quite trivial MFC to perform. The reason for > complication is that the HEAD code for amd64 context switch was changed, > in particular by the r177535 by peter@. > > The r177535 formally requires r177533 for the definition of the > TDP_KTHREAD symbol for asm. The definition is needed for optimization > of the context switch to the "pure kernel thread", introduced in > r173004 that is not MFCed either, and possibly never be. > > I do not want to backport the code to the old context switch, that would > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > of context switch by peter@), and commented out corresponding test in > the cpu_switch.S for the TDP_KTHREAD. > > I would be glad to get an opinions on the approach taken, and especially > for the wider testing on the RELENG_7/amd64. The problem better be > solved for 7.1. > > The patch: > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREAD replaced. -- John Baldwin From mike at sentex.net Wed Aug 13 20:34:11 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Aug 13 20:34:17 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> Message-ID: <200808132034.m7DKY7wm038972@lava.sentex.ca> At 06:20 AM 8/12/2008, Robert Watson wrote: >Anyone out there running name servers, NFS over UDP, and other UDP >workloads: your testing of this patch prior to commit would be much >appreciated. Not sure if this is related or not, but I am seeing a 'boatload' of strange proxy arp issues. Odd thing is that I dont have proxy arp enabled anywhere, at least not knowingly. 0[smtp2]# sysctl -a | grep prox net.link.ether.inet.proxyall: 0 0[smtp2]# 0[smtp2]# arp -na | wc 27665 227053 1669734 0[smtp2]# ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] ? (199.212.134.2) at (incomplete) on em0 [ethernet] From rwatson at FreeBSD.org Wed Aug 13 20:41:04 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Aug 13 20:41:11 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <200808132034.m7DKY7wm038972@lava.sentex.ca> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> Message-ID: On Wed, 13 Aug 2008, Mike Tancsa wrote: > At 06:20 AM 8/12/2008, Robert Watson wrote: > >> Anyone out there running name servers, NFS over UDP, and other UDP >> workloads: your testing of this patch prior to commit would be much >> appreciated. > > Not sure if this is related or not, but I am seeing a 'boatload' of strange > proxy arp issues. Odd thing is that I dont have proxy arp enabled anywhere, > at least not knowingly. Dear Mike: Well, it shouldn't be related, but sometimes things get tricky with locking if it turns out that extra locking at one layer was masking a lack of locking at another. Let's try to diagnose this one a bit more before concluding that is the case, though. I take that the same problems don't happen if you boot a vanilla version of the same rev of the kernel? What command did you use to generate the list at the bottom of your e-mail? Robert N M Watson Computer Laboratory University of Cambridge > > 0[smtp2]# sysctl -a | grep prox > net.link.ether.inet.proxyall: 0 > 0[smtp2]# > > > 0[smtp2]# arp -na | wc > 27665 227053 1669734 > 0[smtp2]# > > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > ? (199.212.134.2) at (incomplete) on em0 [ethernet] > From mike at sentex.net Wed Aug 13 20:46:40 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Aug 13 20:46:57 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> Message-ID: <200808132046.m7DKkb47039033@lava.sentex.ca> At 04:41 PM 8/13/2008, Robert Watson wrote: >Well, it shouldn't be related, but sometimes things get tricky with >locking if it turns out that extra locking at one layer was masking >a lack of locking at another. Let's try to diagnose this one a bit >more before concluding that is the case, though. I take that the >same problems don't happen if you boot a vanilla version of the same >rev of the kernel? What command did you use to generate the list at >the bottom of your e-mail? Hi Robert, the arp messages were a snippet from just arp -na. All of those IP addresses are local to the box. I am just doing a cvsup to the same point in time and am rebuilding the kernel. Also odd, is that if I do a arp -nda it seems to want to delete more than it should. Here is a snippet 199.212.134.2 (199.212.134.2) deleted delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 delete: cannot locate 199.212.134.2 After doing arp -nda, I am back to a very large arp cache again right away 0[smtp2]# arp -na | wc 27818 228335 1679120 0[smtp2]# 0[smtp2]# netstat -na | wc 762 4920 59057 0[smtp2]# netstat -nr | wc 27853 167097 1893894 0[smtp2]# >Robert N M Watson >Computer Laboratory >University of Cambridge > >> >>0[smtp2]# sysctl -a | grep prox >>net.link.ether.inet.proxyall: 0 >>0[smtp2]# >> >> >>0[smtp2]# arp -na | wc >> 27665 227053 1669734 >>0[smtp2]# >> >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 [ethernet] >>? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] >>? (199.212.134.2) at (incomplete) on em0 [ethernet] From rwatson at FreeBSD.org Wed Aug 13 21:12:19 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Aug 13 21:12:25 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <200808132046.m7DKkb47039033@lava.sentex.ca> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <200808132046.m7DKkb47039033@lava.sentex.ca> Message-ID: On Wed, 13 Aug 2008, Mike Tancsa wrote: > At 04:41 PM 8/13/2008, Robert Watson wrote: > >> Well, it shouldn't be related, but sometimes things get tricky with locking >> if it turns out that extra locking at one layer was masking a lack of >> locking at another. Let's try to diagnose this one a bit more before >> concluding that is the case, though. I take that the same problems don't >> happen if you boot a vanilla version of the same rev of the kernel? What >> command did you use to generate the list at the bottom of your e-mail? > > the arp messages were a snippet from just arp -na. All of those IP > addresses are local to the box. I am just doing a cvsup to the same point > in time and am rebuilding the kernel. > > Also odd, is that if I do a arp -nda it seems to want to delete more than it > should. Here is a snippet It's concerning also that there is more than one entry for any particular IP address. I'll have to go reread the ARP code. Confirming that this doesn't happen with vanilla head is definitely the next step. I'll be fairly busy for the next few days with things in Cambridge; if we can't rule out the inpcb patches as the source of the problem, I'll defer committing them until next week when I have a chance to work through this more. Robert N M Watson Computer Laboratory University of Cambridge > > > 199.212.134.2 (199.212.134.2) deleted > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > delete: cannot locate 199.212.134.2 > > > After doing arp -nda, I am back to a very large arp cache again right away > > 0[smtp2]# arp -na | wc > 27818 228335 1679120 > 0[smtp2]# > > 0[smtp2]# netstat -na | wc > 762 4920 59057 > 0[smtp2]# netstat -nr | wc > 27853 167097 1893894 > 0[smtp2]# > > > > > >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >>> >>> 0[smtp2]# sysctl -a | grep prox >>> net.link.ether.inet.proxyall: 0 >>> 0[smtp2]# >>> >>> >>> 0[smtp2]# arp -na | wc >>> 27665 227053 1669734 >>> 0[smtp2]# >>> >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 published (proxy only) [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] >>> ? (199.212.134.2) at (incomplete) on em0 [ethernet] > > From mike at sentex.net Wed Aug 13 21:16:37 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Aug 13 21:16:44 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> Message-ID: <200808132116.m7DLGY1f039165@lava.sentex.ca> At 04:46 PM 8/13/2008, Mike Tancsa wrote: >At 04:41 PM 8/13/2008, Robert Watson wrote: >>Well, it shouldn't be related, but sometimes things get tricky with >>locking if it turns out that extra locking at one layer was masking >>a lack of locking at another. Let's try to diagnose this one a bit >>more before concluding that is the case, though. I take that the >>same problems don't happen if you boot a vanilla version of the >>same rev of the kernel? What command did you use to generate the >>list at the bottom of your e-mail? > > >Hi Robert, > the arp messages were a snippet from just arp -na. All of > those IP addresses are local to the box. I am just doing a cvsup > to the same point in time and am rebuilding the kernel. Actually, it looks like its unrelated to your changes. I just did a full cvsup, and am getting that strange proxy arp stuff and again, the incomplete arp messages.... % arp -na| grep inc ? (64.7.153.9) at (incomplete) on em1 [ethernet] ? (64.7.153.9) at (incomplete) on em1 [ethernet] ? (64.7.153.9) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.19) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.20) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.21) at (incomplete) on em1 [ethernet] ? (64.7.153.24) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.25) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 published (proxy only) [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.26) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (64.7.153.27) at (incomplete) on em1 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] ? (199.212.134.1) at (incomplete) on em0 [ethernet] I will try a kernel before the em changes, as thats the only other thing I can think of off the top of my head. ---Mike From koitsu at FreeBSD.org Wed Aug 13 21:25:44 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 13 21:25:51 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <200808132116.m7DLGY1f039165@lava.sentex.ca> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> Message-ID: <20080813212544.GA25915@eos.sc1.parodius.com> On Wed, Aug 13, 2008 at 05:16:27PM -0400, Mike Tancsa wrote: > At 04:46 PM 8/13/2008, Mike Tancsa wrote: >> At 04:41 PM 8/13/2008, Robert Watson wrote: >>> Well, it shouldn't be related, but sometimes things get tricky with >>> locking if it turns out that extra locking at one layer was masking >>> a lack of locking at another. Let's try to diagnose this one a bit >>> more before concluding that is the case, though. I take that the >>> same problems don't happen if you boot a vanilla version of the same >>> rev of the kernel? What command did you use to generate the list at >>> the bottom of your e-mail? >> >> >> Hi Robert, >> the arp messages were a snippet from just arp -na. All of >> those IP addresses are local to the box. I am just doing a cvsup to >> the same point in time and am rebuilding the kernel. > > Actually, it looks like its unrelated to your changes. I just did a full > cvsup, and am getting that strange proxy arp stuff and again, the > incomplete arp messages.... > > > % arp -na| grep inc > ? (64.7.153.9) at (incomplete) on em1 [ethernet] > ? (64.7.153.9) at (incomplete) on em1 [ethernet] > ? (64.7.153.9) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.19) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.20) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.21) at (incomplete) on em1 [ethernet] > ? (64.7.153.24) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.25) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 published (proxy only) [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.26) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (64.7.153.27) at (incomplete) on em1 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > ? (199.212.134.1) at (incomplete) on em0 [ethernet] > > I will try a kernel before the em changes, as thats the only other thing > I can think of off the top of my head. That almost looks like some kind of ARP storm, sans repetitive entries (that definitely looks odd). Does tcpdump on em1 show a particular machine or router demanding MACs for 64.7.153.0/24 (or whatever the block is)? Adding Jack Vogel to this, since it could be em(4)-related. -- | Jeremy Chadwick jdc 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 | From mike at sentex.net Wed Aug 13 21:35:32 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Aug 13 21:35:39 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <20080813212544.GA25915@eos.sc1.parodius.com> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> Message-ID: <200808132135.m7DLZTeK039233@lava.sentex.ca> At 05:25 PM 8/13/2008, Jeremy Chadwick wrote: > > > > I will try a kernel before the em changes, as thats the only other thing > > I can think of off the top of my head. I commented out em from the kernel and loaded up a previous version via kld, but still the same thing, although not nearly as much 0[smtp2]# arp -na | wc 89 680 5081 0[smtp2]# em0@pci0:0:4:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em1@pci0:0:5:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82541EI Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction >That almost looks like some kind of ARP storm, sans repetitive entries >(that definitely looks odd). Does tcpdump on em1 show a particular >machine or router demanding MACs for 64.7.153.0/24 (or whatever the >block is)? No, its very, very quiet. All the other machines on the 2 networks are just fine. Any suggestions on what kernel to go back to start from ? ---Mike From koitsu at FreeBSD.org Wed Aug 13 21:43:07 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 13 21:43:14 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <200808132135.m7DLZTeK039233@lava.sentex.ca> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Message-ID: <20080813214306.GA28953@eos.sc1.parodius.com> On Wed, Aug 13, 2008 at 05:35:21PM -0400, Mike Tancsa wrote: > At 05:25 PM 8/13/2008, Jeremy Chadwick wrote: >> > >> > I will try a kernel before the em changes, as thats the only other thing >> > I can think of off the top of my head. > > I commented out em from the kernel and loaded up a previous version via > kld, but still the same thing, although not nearly as much > > 0[smtp2]# arp -na | wc > 89 680 5081 > 0[smtp2]# > > em0@pci0:0:4:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > em1@pci0:0:5:0: class=0x020000 card=0x387010f1 chip=0x10768086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82541EI Gigabit Ethernet Controller' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > >> That almost looks like some kind of ARP storm, sans repetitive entries >> (that definitely looks odd). Does tcpdump on em1 show a particular >> machine or router demanding MACs for 64.7.153.0/24 (or whatever the >> block is)? > > No, its very, very quiet. All the other machines on the 2 networks are > just fine. > > Any suggestions on what kernel to go back to start from ? Seems relevant, and might give you some dates/revisions to roll back to for testing. Robert will have to confirm if some of the below commits could wreck havok -- I'm not familiar with the code, I just pay semi-close attention to the commits... :-) http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c -- | Jeremy Chadwick jdc 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 | From jfvogel at gmail.com Wed Aug 13 22:02:40 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Aug 13 22:02:47 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE Message-ID: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> There is a change that has been in the STABLE tree for a few months, but many might have missed it, its an important change to note and possibly for some prepare for with the 7.1 RELEASE. There is a new E1000 network driver, igb, which supports two family of adapters so far: the 82575 and the new 82576. In FreeBSD 7 the support for 82575 was in the em driver, however due to support issues across all the OS's we do drivers for, the decision was made to split the newer drivers off from those before. There are big differences in the register set, and in things like the descriptor format that made this expedient. I made the support for the 82575 available very early in FreeBSD, earlier even than Linux so that certain vendors could have a working driver early. At first I thought to avoid splitting the driver, but support issues are going to make that impractical. So there is a split, its been in HEAD since Febuary, and now 7.1 will release with this change. What this means is that if you have 82575 adapters in a system they are going to change from being 'emX' to being 'igbX', in the RELEASE the install kernel will have both drivers in it, but on an upgrade path, or using a set of scripts that get postinstalled you need to be ready to make this change. How can you tell if you have such a device: Simple, use pciconf, there are only 3 ID's that are effected: 0x10A7, 0x10A9, and 0x10D6. If you have questions feel free to email me. Cheers, Jack Vogel Intel Lan Access Division From rwatson at FreeBSD.org Wed Aug 13 22:22:40 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Aug 13 22:22:47 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: <200808132135.m7DLZTeK039233@lava.sentex.ca> References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Message-ID: On Wed, 13 Aug 2008, Mike Tancsa wrote: > At 05:25 PM 8/13/2008, Jeremy Chadwick wrote: >> > >> > I will try a kernel before the em changes, as thats the only other thing >> > I can think of off the top of my head. > > I commented out em from the kernel and loaded up a previous version via kld, > but still the same thing, although not nearly as much .... > No, its very, very quiet. All the other machines on the 2 networks are just > fine. > > Any suggestions on what kernel to go back to start from ? I'm concerned by the presence of multiple ARP entries for a single IP -- I'll need to reread the ARP code to refresh my memory, but in general I would expect to see at most one in-progress or complete ARP entry for any particular IP address at a time. To me, this suggests a bug -- perhaps a race condition or just a general logic bug. If rolling back fixes it, that is definitely interesting, but we can also debug this in the normal ways and see where it leads us. Robert N M Watson Computer Laboratory University of Cambridge From mike at sentex.net Wed Aug 13 22:29:55 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Aug 13 22:30:02 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Message-ID: <200808132229.m7DMTqUU039429@lava.sentex.ca> At 06:22 PM 8/13/2008, Robert Watson wrote: >>Any suggestions on what kernel to go back to start from ? > >I'm concerned by the presence of multiple ARP entries for a single >IP -- I'll need to reread the ARP code to refresh my memory, but in >general I would expect to see at most one in-progress or complete >ARP entry for any particular IP address at a time. To me, this >suggests a bug -- perhaps a race condition or just a general logic >bug. If rolling back fixes it, that is definitely interesting, but >we can also debug this in the normal ways and see where it leads us. I am just doing a full buildworld/buildkernel after doing an rm -R /usr/obj to make sure a stable from today is indeed the issue, and then I will jump back a month or so ? What can I do to track down the issue ? The incomplete addresses correspond to hosts where most traffic is directed. ---Mike From spomerg at cwu.EDU Thu Aug 14 02:04:10 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Thu Aug 14 02:04:18 2008 Subject: ssh-keygen between SuSE and FreeBSD Message-ID: <48A31B61020000900001C109@hermes.cwu.edu> I hope this isn't an invalid topic for this list. I'm on so many lists and I hate to join another one just to get help on one thing. Apologies if it's not. I am able to use ssh-keygen to generate keys so that I can ssh from my Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD systems, without having to enter my password. When I try the same thing from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen -t rsa" on the SuSE system, then copy the id_rsa.pub to my ~/.ssh/authorized_keys file on the FreeBSD system) I get the following message when ssh-ing to the FreeBSD system: Enter passphrase for key '/home/myusername/.ssh/id_rsa': ... and I have to enter my password. I've Googled, but can't seem to find the answer to my dilemma. Is it generally kind of a pain to do this between platforms? I'm finally very comfortable on FreeBSD and am starting to really get annoyed with SuSE. :( - Gavin From mike at sentex.net Thu Aug 14 02:10:23 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Aug 14 02:10:30 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Message-ID: <200808140210.m7E2AK1V040232@lava.sentex.ca> At 06:22 PM 8/13/2008, Robert Watson wrote: >I'm concerned by the presence of multiple ARP entries for a single >IP -- I'll need to reread the ARP code to refresh my memory, but in >general I would expect to see at most one in-progress or complete >ARP entry for any particular IP address at a time. To me, this >suggests a bug -- perhaps a race condition or just a general logic >bug. If rolling back fixes it, that is definitely interesting, but >we can also debug this in the normal ways and see where it leads us. I blew away /usr/src and /usr/obj and did a full buildworld, buildkernel with date=2008.07.01.00.00.00 in my cvsup file 2008-07-01, all OK 2008-07-13, all OK 2008-07-25, all OK 2008-08-01, 'blammo' So sometime between the 25th and aug1. Just going to try and narrow it down some more. ---Mike From doconnor at gsoft.com.au Thu Aug 14 02:31:01 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Aug 14 02:31:08 2008 Subject: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ In-Reply-To: References: <200808121734.30144.doconnor@gsoft.com.au> <200808132055.56039.doconnor@gsoft.com.au> Message-ID: <200808141200.56643.doconnor@gsoft.com.au> On Thu, 14 Aug 2008, Manjunath Ranganathaiah wrote: > > I tried the former (put it in loader.conf right?) and it made no > > difference. I'll try disabling ACPI tomorrow (I tried it remotely > > so it's hung now :) > > Yes, look at acpi man page for details. Yup, just double checking.. Actually there is one thing different.. It printed.. Uptime: 6m27s 1 I tried disabling ACPI altogether but the system doesn't boot :( I get a lot of.. interrupt storm detected on "irq5:"; throttling interrupt source It is interspersed with twa controller resets. FWIW I can reset it by calling cpu_reset() from withing a KLD. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080814/1367f207/attachment.pgp From pschmehl_lists at tx.rr.com Thu Aug 14 02:42:18 2008 From: pschmehl_lists at tx.rr.com (Paul Schmehl) Date: Thu Aug 14 02:42:26 2008 Subject: ssh-keygen between SuSE and FreeBSD In-Reply-To: <48A31B61020000900001C109@hermes.cwu.edu> References: <48A31B61020000900001C109@hermes.cwu.edu> Message-ID: --On August 13, 2008 5:35:29 PM -0700 Gavin Spomer wrote: > I hope this isn't an invalid topic for this list. I'm on so many lists > and I hate to join another one just to get help on one thing. Apologies > if it's not. > > I am able to use ssh-keygen to generate keys so that I can ssh from my > Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD > systems, without having to enter my password. When I try the same thing > from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen -t rsa" > on the SuSE system, then copy the id_rsa.pub to my > ~/.ssh/authorized_keys file on the FreeBSD system) I get the following > message when ssh-ing to the FreeBSD system: > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': > > ... and I have to enter my password. I've Googled, but can't seem to > find the answer to my dilemma. Is it generally kind of a pain to do this > between platforms? I'm finally very comfortable on FreeBSD and am > starting to really get annoyed with SuSE. :( > Just to be clear....you're saying that your key pass*phrase* doesn't work and you have to type your pass*word* in instead? Or did you make all your previous keys passphrase-less and add a passphrase to this one? Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ****************************************** WARNING: Check the headers before replying From mike at sentex.net Thu Aug 14 02:47:09 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Aug 14 02:47:17 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you In-Reply-To: References: <200808120059.m7C0xvUH028011@lava.sentex.ca> <200808132034.m7DKY7wm038972@lava.sentex.ca> <7.1.0.9.0.20080813164157.161ba2e8@sentex.net> <200808132116.m7DLGY1f039165@lava.sentex.ca> <20080813212544.GA25915@eos.sc1.parodius.com> <200808132135.m7DLZTeK039233@lava.sentex.ca> Message-ID: <200808140247.m7E2l5ft040358@lava.sentex.ca> At 06:22 PM 8/13/2008, Robert Watson wrote: >I'm concerned by the presence of multiple ARP entries for a single >IP -- I'll need to reread the ARP code to refresh my memory, but in >general I would expect to see at most one in-progress or complete >ARP entry for any particular IP address at a time. To me, this >suggests a bug -- perhaps a race condition or just a general logic >bug. If rolling back fixes it, that is definitely interesting, but >we can also debug this in the normal ways and see where it leads us. It seems to be on the 31st and one of the commits below that causes the problem. I am bcc'ing the people below. Original problem description at http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044373.html I originally thought it to be an issue with Robert's patch, but it appears instead to be related to one of the commits below. Updating collection src-all/cvs Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Edit src/sys/contrib/rdma/core_priv.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_addr.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_cache.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_fmr_pool.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_mad.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_marshall.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_pack.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_sa.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_smi.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_umem.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_mad.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_sa.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_user_verbs.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/ib_verbs.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/iw_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/getopt.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/getopt.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/krping.c Add delta 1.2.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/krping.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/krping/krping_dev.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_addr.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cache.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cm_ib.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_cma.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_device.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_iwcm.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_user_cm.h Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/rdma_verbs.c Add delta 1.1.2.1 2008.07.30.00.27.48 kmacy Edit src/sys/contrib/rdma/types.h Add delta 1.2.2.1 2008.07.30.00.27.48 kmacy Checkout src/sys/dev/e1000/LICENSE Checkout src/sys/dev/e1000/README Checkout src/sys/dev/e1000/e1000_80003es2lan.c Checkout src/sys/dev/e1000/e1000_80003es2lan.h Checkout src/sys/dev/e1000/e1000_82540.c Checkout src/sys/dev/e1000/e1000_82541.c Checkout src/sys/dev/e1000/e1000_82541.h Checkout src/sys/dev/e1000/e1000_82542.c Checkout src/sys/dev/e1000/e1000_82543.c Checkout src/sys/dev/e1000/e1000_82543.h Checkout src/sys/dev/e1000/e1000_82571.c Checkout src/sys/dev/e1000/e1000_82571.h Checkout src/sys/dev/e1000/e1000_82575.c Checkout src/sys/dev/e1000/e1000_82575.h Checkout src/sys/dev/e1000/e1000_api.c Checkout src/sys/dev/e1000/e1000_api.h Checkout src/sys/dev/e1000/e1000_defines.h Checkout src/sys/dev/e1000/e1000_hw.h Checkout src/sys/dev/e1000/e1000_ich8lan.c Checkout src/sys/dev/e1000/e1000_ich8lan.h Checkout src/sys/dev/e1000/e1000_mac.c Checkout src/sys/dev/e1000/e1000_mac.h Checkout src/sys/dev/e1000/e1000_manage.c Checkout src/sys/dev/e1000/e1000_manage.h Checkout src/sys/dev/e1000/e1000_nvm.c Checkout src/sys/dev/e1000/e1000_nvm.h Checkout src/sys/dev/e1000/e1000_osdep.c Checkout src/sys/dev/e1000/e1000_osdep.h Checkout src/sys/dev/e1000/e1000_phy.c Checkout src/sys/dev/e1000/e1000_phy.h Checkout src/sys/dev/e1000/e1000_regs.h Checkout src/sys/dev/e1000/if_em.c Checkout src/sys/dev/e1000/if_em.h Checkout src/sys/dev/e1000/if_igb.h Edit src/sys/kern/kern_fork.c Add delta 1.282.2.5 2008.07.30.09.44.40 kib Edit src/sys/kern/kern_synch.c Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson Edit src/sys/kern/sys_process.c Add delta 1.145.2.1 2008.07.30.19.49.10 jhb Edit src/sys/kern/vfs_aio.c Add delta 1.233.2.2 2008.07.30.13.19.50 rwatson Edit src/sys/net/bpf.c Add delta 1.181.2.7 2008.07.30.14.04.01 rwatson Edit src/sys/net/if.c Add delta 1.273.2.4 2008.07.30.17.27.10 rwatson Edit src/sys/net/if.h Add delta 1.108.2.3 2008.07.30.00.17.40 kmacy Edit src/sys/net/if_ethersubr.c Add delta 1.236.2.4 2008.07.30.17.27.10 rwatson Edit src/sys/netinet/in_pcb.h Add delta 1.100.2.3 2008.07.30.00.18.32 kmacy Edit src/sys/netinet/tcp_offload.c Add delta 1.4.2.1 2008.07.30.00.09.15 kmacy Edit src/sys/netinet/tcp_offload.h Add delta 1.5.2.1 2008.07.30.00.09.15 kmacy Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_var.h Add delta 1.157.2.4 2008.07.30.00.20.04 kmacy Edit src/sys/netinet/toedev.h Add delta 1.5.2.1 2008.07.30.00.16.37 kmacy Edit src/sys/netinet/udp_usrreq.c Add delta 1.218.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_input.c Add delta 1.95.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_var.h Add delta 1.39.2.2 2008.07.30.21.23.21 bz Edit src/sys/sys/socket.h Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy Edit src/sys/ufs/ufs/ufs_lookup.c Add delta 1.83.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.c Add delta 1.385.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.h Add delta 1.114.2.1 2008.07.30.21.43.42 jhb Edit src/sys/vm/vnode_pager.c Add delta 1.236.2.2 2008.07.30.21.43.42 jhb Edit src/usr.bin/ldd/ldd.c Add delta 1.33.24.2 2008.07.30.03.33.49 edwin From doconnor at gsoft.com.au Thu Aug 14 02:55:25 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Aug 14 02:55:32 2008 Subject: 6.3 (ish) hang on reboot w/ Supermicro C2SBA+ (fixed) In-Reply-To: <200808141200.56643.doconnor@gsoft.com.au> References: <200808121734.30144.doconnor@gsoft.com.au> <200808141200.56643.doconnor@gsoft.com.au> Message-ID: <200808141225.21321.doconnor@gsoft.com.au> On Thu, 14 Aug 2008, Daniel O'Connor wrote: > On Thu, 14 Aug 2008, Manjunath Ranganathaiah wrote: > > > I tried the former (put it in loader.conf right?) and it made no > > > difference. I'll try disabling ACPI tomorrow (I tried it remotely > > > so it's hung now :) > > > > Yes, look at acpi man page for details. > > Yup, just double checking.. > > Actually there is one thing different.. It printed.. > > Uptime: 6m27s > 1 > > I tried disabling ACPI altogether but the system doesn't boot :( > I get a lot of.. > interrupt storm detected on "irq5:"; throttling interrupt source I found that there was a recent BIOS update and that appears to have fixed the problem (as well as the ACPI spam I was getting during module probes). Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080814/5e931a06/attachment.pgp From oberman at es.net Thu Aug 14 03:40:52 2008 From: oberman at es.net (Kevin Oberman) Date: Thu Aug 14 03:40:58 2008 Subject: ssh-keygen between SuSE and FreeBSD In-Reply-To: Your message of "Wed, 13 Aug 2008 17:35:29 PDT." <48A31B61020000900001C109@hermes.cwu.edu> Message-ID: <20080814034049.CC8304500F@ptavv.es.net> Format recovered. A newline every 72-75 characters would be more polite. > Date: Wed, 13 Aug 2008 17:35:29 -0700 > From: Gavin Spomer > Sender: owner-freebsd-stable@freebsd.org > > I hope this isn't an invalid topic for this list. I'm on so many lists > and I hate to join another one just to get help on one > thing. Apologies if it's not. > > I am able to use ssh-keygen to generate keys so that I can ssh from my > Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD > systems, without having to enter my password. When I try the same > thing from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen > -t rsa" on the SuSE system, then copy the id_rsa.pub to my > ~/.ssh/authorized_keys file on the FreeBSD system) I get the following > message when ssh-ing to the FreeBSD system: > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': > > ... and I have to enter my password. I've Googled, but can't seem to > find the answer to my dilemma. Is it generally kind of a pain to do > this between platforms? I'm finally very comfortable on FreeBSD and am > starting to really get annoyed with SuSE. :( It's not asking for your password. It's asking for your passphrase to decrypt your private key. Are you running an ssh-agent on the Suse system? If this does not point you in the right direction, try running ssh -v. This MAY give us an idea of the problem, though the debug data from the server would be better. MacOS X uses the FreeBSD user environment, so it should work the same under FreeBSD as it does on the Mac. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080814/2bc6f9ab/attachment.pgp From jfvogel at gmail.com Thu Aug 14 04:35:45 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Aug 14 04:35:51 2008 Subject: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE In-Reply-To: <48A3A2DA.8030404@gtcomm.net> References: <2a41acea0808131502y39879a22u39c472bd0b810fc2@mail.gmail.com> <48A3A2DA.8030404@gtcomm.net> Message-ID: <2a41acea0808132135oe9ebc6bk9423ac19f2e9f77a@mail.gmail.com> On Wed, Aug 13, 2008 at 8:13 PM, Paul wrote: > Hi Jack. Will the em driver ever support the multiple hardware queues of > the 82571 or are we just stuck with the standard em driver? > Has there been any significant change in the em driver itself ? > I have a feeling that the 82571 should be in the igb driver but for some > reason it isn't. I am curious because we have a LOT of 4 port 82571 PCI-E > cards and they are not cheap. :] Hey Paul, You are right, quad port cards aren't cheap, Intel has sold them even back in a PCI-X based system. And the one you are talking about was released since I have been in this job, so pretty new :) However, they will never support multiple queues, the reason being that in order to do this you need multple MSI vectors, in other words, MSIX. Still, they are very handy, they do support MSI, but just one per interface. Oh, and I debated about where to make the cutoff line on the em/igb split and decided the best thing to do was to follow Linux. The biggest difference between the two drivers is that those in the igb use a different descriptor format, called 'advanced descriptors'. The split does NOT mean that em is now fixed. Quite the contrary, the em driver that was just MFC'd into STABLE has support for what I think is going to be the coolest new consumer adapter out there, called 82574, code name Hartwell, and also for ICH10. Both these two new interfaces have IEEE 1588 Precision Time Protocol support, something that is becoming important for networked multimedia applications. Oh, and Hartwell is the first adapter in the em driver that actually does multiqueue, although in a limited fashion, it does MSIX. This adapter is made at a lower cost point, but it has really nice features. I only wish the new motherboard that I bought had them rather than ICH9 but oh well :) I predict they are going to be selling like hotcakes before the end of year. I will continue to share fixes between the em and igb drivers as they are applicable. I still think a real legacy driver for the oldest adapters would be a good idea, just so they don't get broken by new development, with as many as we support regression testing is already not being done adequately. I just have not had time to think about this yet, it may be coming, it would probably be for everything that was not PCI Express. Hope the info was helpful, I'm always happy to answer questions, Jack From gerrit at pmp.uni-hannover.de Thu Aug 14 06:47:03 2008 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Aug 14 06:47:12 2008 Subject: Regression 7.0R -> 7-stable? In-Reply-To: <489B7D62.4080606@delphij.net> References: <20080807132947.061d24eb.gerrit@pmp.uni-hannover.de> <489B7D62.4080606@delphij.net> Message-ID: <20080814084637.97997c02.gerrit@pmp.uni-hannover.de> On Thu, 07 Aug 2008 15:55:30 -0700 Xin LI wrote about Re: Regression 7.0R -> 7-stable?: XL> Could you please try disabling ACPI and boot? Additionally a 'boot - XL> v' may reveal some useful information as well. Just some random XL> thoughts. Disabling ACPI does not help, either (forgot to mention that earlier, sorry). I will post a boot -v log as soon as I have a working 7.0R on the system again. cu Gerrit From css at alkar.net Thu Aug 14 07:30:06 2008 From: css at alkar.net (Sergey Chumakov) Date: Thu Aug 14 07:30:13 2008 Subject: Process size. Message-ID: <20080814093000.4842b37c@while.alkar.net> Hello, FreeBSD 7.0-RELEASE-p3 #3 $top ... PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 36032 root 2838 44 0 1917M 1493M ucond 0 406:39 3.03% CGServer ... $cat /boot/loader.conf.local ... kern.maxdsiz="1073741824" kern.maxssiz="134217728" kern.dfldsiz="1073741824" $limits Resource limits (current): ... datasize 1048576 kB stacksize 131072 kB How and why is it possible for process to grow up to 1493M and even more? I suppose, it will be able to eat all available system memory (was killed). Thank you for answers. -- Sincerely, Sergey Chumakov From eugen at kuzbass.ru Thu Aug 14 07:34:30 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu Aug 14 07:34:40 2008 Subject: Process size. In-Reply-To: <20080814093000.4842b37c@while.alkar.net> References: <20080814093000.4842b37c@while.alkar.net> Message-ID: <20080814073357.GA85637@svzserv.kemerovo.su> On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: > $limits > Resource limits (current): > ... > datasize 1048576 kB > stacksize 131072 kB > > How and why is it possible for process to grow up to 1493M and even > more? I suppose, it will be able to eat all available system memory (was > killed). Try to eslablish 'vmemoryuse' limit also. Eugene Grosbein From koitsu at FreeBSD.org Thu Aug 14 07:44:31 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 07:44:40 2008 Subject: Process size. In-Reply-To: <20080814093000.4842b37c@while.alkar.net> References: <20080814093000.4842b37c@while.alkar.net> Message-ID: <20080814074430.GA4096@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: > Hello, > > FreeBSD 7.0-RELEASE-p3 #3 > > $top > ... > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 36032 root 2838 44 0 1917M 1493M ucond 0 406:39 3.03% CGServer > ... > > $cat /boot/loader.conf.local > ... > kern.maxdsiz="1073741824" > kern.maxssiz="134217728" > kern.dfldsiz="1073741824" > > $limits > Resource limits (current): > ... > datasize 1048576 kB > stacksize 131072 kB > > How and why is it possible for process to grow up to 1493M and even > more? I suppose, it will be able to eat all available system memory (was > killed). Do resource limits apply to root? I wonder if it's an issue of calculation in top; top might be including page sizes and other VM-related things, while limits datasize and stacksize may only be specific to those allocated amounts. If this machine was running RELENG_7 (STABLE), it would have procstat, which could help discern where the "extra" memory is. Also: is this i386 or amd64? -- | Jeremy Chadwick jdc 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 | From css at alkar.net Thu Aug 14 08:00:25 2008 From: css at alkar.net (Sergey Chumakov) Date: Thu Aug 14 08:00:37 2008 Subject: Process size. In-Reply-To: <20080814074430.GA4096@eos.sc1.parodius.com> References: <20080814093000.4842b37c@while.alkar.net> <20080814074430.GA4096@eos.sc1.parodius.com> Message-ID: <20080814110022.053d117d@while.alkar.net> ?? Thu, 14 Aug 2008 00:44:30 -0700 Jeremy Chadwick ????????: > On Thu, Aug 14, 2008 at 09:30:00AM +0300, Sergey Chumakov wrote: > > Hello, > > > > FreeBSD 7.0-RELEASE-p3 #3 > > > > $top > > ... > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 36032 root 2838 44 0 1917M 1493M ucond 0 406:39 3.03% CGServer > > ... > > > > $cat /boot/loader.conf.local > > ... > > kern.maxdsiz="1073741824" > > kern.maxssiz="134217728" > > kern.dfldsiz="1073741824" > > > > $limits > > Resource limits (current): > > ... > > datasize 1048576 kB > > stacksize 131072 kB > > > > How and why is it possible for process to grow up to 1493M and even > > more? I suppose, it will be able to eat all available system memory (was > > killed). > > Do resource limits apply to root? Yes, of course. > > I wonder if it's an issue of calculation in top; top might be including > page sizes and other VM-related things, while limits datasize and stacksize > may only be specific to those allocated amounts. > > If this machine was running RELENG_7 (STABLE), it would have procstat, > which could help discern where the "extra" memory is. > > Also: is this i386 or amd64? > i386 -- Sincerely, Sergey Chumakov From freebsd-stable at pp.dyndns.biz Thu Aug 14 08:06:30 2008 From: freebsd-stable at pp.dyndns.biz (=?ISO-8859-1?Q?Morgan_Wesstr=F6m?=) Date: Thu Aug 14 08:06:39 2008 Subject: Removing /usr/lib32 on AMD64 Message-ID: <48A3E29D.3090504@pp.dyndns.biz> Hi. Looking through man src.conf I found the knob WITHOUT_LIB32 and recompiled my world with it since I have no use for 32-bit compatibility on my AMD64. After installworld I realized that /usr/lib32 was still there and still populated. Searching for information I found this bugreport: http://www.freebsd.org/cgi/query-pr.cgi?pr=117191&cat= Judging from that report and the fact that the dates on the files in /usr/lib32 wasn't updated I figured it was ok to simply remove them. I just want to make sure there's nothing else I have to do to cleanly remove 32-bit compatibility? I can see during boot that there is still some reference to 32-bit compatibility. The following message flashes by on the screen: ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/mysql 32-bit compatibility ldconfig path: I can track the last row to /etc/rc.d/ldconfig but can't figure out if that script can take any options in /etc/rc.conf to stop looking for 32-bit libraries. There are no error messages what I can see so everything is probably ok, just want to make absolutely sure. Anyone who can share some insight on this? Regards Morgan Wesstr?m From koitsu at FreeBSD.org Thu Aug 14 08:13:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 08:13:16 2008 Subject: Removing /usr/lib32 on AMD64 In-Reply-To: <48A3E29D.3090504@pp.dyndns.biz> References: <48A3E29D.3090504@pp.dyndns.biz> Message-ID: <20080814081309.GA8249@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 09:45:33AM +0200, Morgan Wesstr?m wrote: > Hi. > > Looking through man src.conf I found the knob WITHOUT_LIB32 and > recompiled my world with it since I have no use for 32-bit compatibility > on my AMD64. After installworld I realized that /usr/lib32 was still > there and still populated. Searching for information I found this > bugreport: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=117191&cat= > > Judging from that report and the fact that the dates on the files in > /usr/lib32 wasn't updated I figured it was ok to simply remove them. I > just want to make sure there's nothing else I have to do to cleanly > remove 32-bit compatibility? I can see during boot that there is still > some reference to 32-bit compatibility. The following message flashes by > on the screen: > > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib > /usr/local/lib/mysql > 32-bit compatibility ldconfig path: > > I can track the last row to /etc/rc.d/ldconfig but can't figure out if > that script can take any options in /etc/rc.conf to stop looking for > 32-bit libraries. There are no error messages what I can see so > everything is probably ok, just want to make absolutely sure. Anyone who > can share some insight on this? What you've documented above is the Correct Way(tm) to remove lib32 support. Though I advocate people not install it in the first place, unless they absolutely need it. The message from /etc/rc.d/ldconfig you see there about 32-bit compatibility ldconfig path is fine -- it shows an empty path, which is correct. Nothing to worry about there. My systems, which have never had lib32 ever, show the same: ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/mysql 32-bit compatibility ldconfig path: -- | Jeremy Chadwick jdc 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 | From freebsd-stable at pp.dyndns.biz Thu Aug 14 08:34:30 2008 From: freebsd-stable at pp.dyndns.biz (=?ISO-8859-1?Q?Morgan_Wesstr=F6m?=) Date: Thu Aug 14 08:34:37 2008 Subject: Removing /usr/lib32 on AMD64 In-Reply-To: <20080814081309.GA8249@eos.sc1.parodius.com> References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> Message-ID: <48A3EE12.7060302@pp.dyndns.biz> Thanks for your answer Jeremy :-) > What you've documented above is the Correct Way(tm) to remove lib32 > support. Though I advocate people not install it in the first place, > unless they absolutely need it. I'm not sure I was ever given the option to deselect it during sysinstall. I don't rememeber any obvious question at least and /etc/src.conf did not exist efter install. > The message from /etc/rc.d/ldconfig you see there about 32-bit > compatibility ldconfig path is fine -- it shows an empty path, which is > correct. Nothing to worry about there. There are references in ldconfig to a couple of options I find in /etc/defaults/rc.conf ldconfig32_paths="/usr/lib32" # 32-bit compatibility shared library ldconfig_local32_dirs="/usr/local/libdata/ldconfig32" Should I blank those? /usr/local/libdata/ldconfig32 is an empty folder here. There's also a /libexec/ld-elf32.so.1 left, with the same old date as the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to it. Should I leave them or remove them? They were not mentioned in the diff in the bugreport. /Morgan From koitsu at FreeBSD.org Thu Aug 14 08:51:25 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 08:51:32 2008 Subject: Removing /usr/lib32 on AMD64 In-Reply-To: <48A3EE12.7060302@pp.dyndns.biz> References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> <48A3EE12.7060302@pp.dyndns.biz> Message-ID: <20080814085125.GA12129@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 10:34:26AM +0200, Morgan Wesstr?m wrote: > Thanks for your answer Jeremy :-) > >> What you've documented above is the Correct Way(tm) to remove lib32 >> support. Though I advocate people not install it in the first place, >> unless they absolutely need it. > > I'm not sure I was ever given the option to deselect it during > sysinstall. I don't remember if 7.0-RELEASE sysinstall lists it, but I know 7.0-STABLE does. > I don't rememeber any obvious question at least and > /etc/src.conf did not exist efter install. What relevancy does this have to sysinstall? Nothing during sysinstall touches src.conf. Every FreeBSD system will be missing /etc/src.conf after an install; the same goes for /etc/make.conf. It's normal. >> The message from /etc/rc.d/ldconfig you see there about 32-bit >> compatibility ldconfig path is fine -- it shows an empty path, which is >> correct. Nothing to worry about there. > > There are references in ldconfig to a couple of options I find in > /etc/defaults/rc.conf > > ldconfig32_paths="/usr/lib32" # 32-bit compatibility shared library > ldconfig_local32_dirs="/usr/local/libdata/ldconfig32" > > Should I blank those? /usr/local/libdata/ldconfig32 is an empty folder here. No, do not blank them; they will not be used, as was shown to you by /etc/rc.d/ldconfig's output not utilising any 32-bit paths. There's no point in blanking something that won't get used, it'll just confuse someone who looks at the system or lead them astray. > There's also a /libexec/ld-elf32.so.1 left, with the same old date as > the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to it. > Should I leave them or remove them? They were not mentioned in the diff > in the bugreport. You should safely be able to remove those as well, assuming you have rebuilt/reinstalled world, and rebuilt all of your ports. Otherwise upon removal, programs utilising ld-elf32.so.1, won't have a valid ld.so loader, and will fail immediately. -- | Jeremy Chadwick jdc 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 | From freebsd-stable at pp.dyndns.biz Thu Aug 14 09:09:27 2008 From: freebsd-stable at pp.dyndns.biz (=?ISO-8859-1?Q?Morgan_Wesstr=F6m?=) Date: Thu Aug 14 09:09:34 2008 Subject: Removing /usr/lib32 on AMD64 In-Reply-To: <20080814085125.GA12129@eos.sc1.parodius.com> References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> <48A3EE12.7060302@pp.dyndns.biz> <20080814085125.GA12129@eos.sc1.parodius.com> Message-ID: <48A3F643.80508@pp.dyndns.biz> Jeremy Chadwick wrote: > I don't remember if 7.0-RELEASE sysinstall lists it, but I know > 7.0-STABLE does. Oh, that explains it. I installed RELEASE and am still on RELEASE tbh. Sorry for being on the wrong list... :-/ >> I don't rememeber any obvious question at least and >> /etc/src.conf did not exist efter install. > > What relevancy does this have to sysinstall? Nothing during sysinstall > touches src.conf. Every FreeBSD system will be missing /etc/src.conf > after an install; the same goes for /etc/make.conf. It's normal. WITHOUT_LIB32 is supposed to be in src.conf. If it's missing on STABLE, wouldn't that mean 32-bit compatibility would be added to STABLE at next world rebuild or is there another mechanism preventing this from happen? >> There are references in ldconfig to a couple of options I find in >> /etc/defaults/rc.conf >> Should I blank those? /usr/local/libdata/ldconfig32 is an empty folder here. > > No, do not blank them; they will not be used, as was shown to you by > /etc/rc.d/ldconfig's output not utilising any 32-bit paths. There's no > point in blanking something that won't get used, it'll just confuse > someone who looks at the system or lead them astray. Message received and understood. Leaving them alone. :-) >> There's also a /libexec/ld-elf32.so.1 left, with the same old date as >> the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to it. >> Should I leave them or remove them? They were not mentioned in the diff >> in the bugreport. > > You should safely be able to remove those as well, assuming you have > rebuilt/reinstalled world, and rebuilt all of your ports. Otherwise > upon removal, programs utilising ld-elf32.so.1, won't have a valid > ld.so loader, and will fail immediately. World is rebuilt but I haven't rebuilt my ports but they shouldn't have been built against the 32-bit libraries in the first place, should they? 64-bit libraries are the default choice I assume or am I missing something vital here? I'll remove them and see what happens when I reboot. It will be an exciting start of the day ;-) Thanks again for your help, It's highly appreciated. /Morgan From sebster at sebster.com Thu Aug 14 09:38:02 2008 From: sebster at sebster.com (Sebastiaan van Erk) Date: Thu Aug 14 09:38:10 2008 Subject: Stable SATA pci card for FreeBSD 6.x/7.0 In-Reply-To: <20080814090521.GB27942@groll.co.za> References: <48982B58.4000406@sebster.com> <48992532.9080503@yandex.ru> <489970CC.4000103@sebster.com> <20080806095748.GA52551@eos.sc1.parodius.com> <20080806101941.GA52952@eos.sc1.parodius.com> <48A2DD60.7090702@sebster.com> <20080814090521.GB27942@groll.co.za> Message-ID: <48A3FCF7.9030905@sebster.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3315 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080814/ee72e2b0/smime.bin From koitsu at FreeBSD.org Thu Aug 14 09:56:02 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 09:56:09 2008 Subject: Removing /usr/lib32 on AMD64 In-Reply-To: <48A3F643.80508@pp.dyndns.biz> References: <48A3E29D.3090504@pp.dyndns.biz> <20080814081309.GA8249@eos.sc1.parodius.com> <48A3EE12.7060302@pp.dyndns.biz> <20080814085125.GA12129@eos.sc1.parodius.com> <48A3F643.80508@pp.dyndns.biz> Message-ID: <20080814095559.GA15612@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 11:09:23AM +0200, Morgan Wesstr?m wrote: > Jeremy Chadwick wrote: >> I don't remember if 7.0-RELEASE sysinstall lists it, but I know >> 7.0-STABLE does. > > Oh, that explains it. I installed RELEASE and am still on RELEASE tbh. > Sorry for being on the wrong list... :-/ You're on the right list. You just need to know the difference between RELEASE and STABLE. RELEASE is more or less the "first time FreeBSD version x.y has been released to the world", and STABLE are all further updates to that version going forward. >>> I don't rememeber any obvious question at least and /etc/src.conf >>> did not exist efter install. >> >> What relevancy does this have to sysinstall? Nothing during sysinstall >> touches src.conf. Every FreeBSD system will be missing /etc/src.conf >> after an install; the same goes for /etc/make.conf. It's normal. > > WITHOUT_LIB32 is supposed to be in src.conf. If it's missing on STABLE, > wouldn't that mean 32-bit compatibility would be added to STABLE at next > world rebuild Correct. If a person unselects lib32 during sysinstall, they will need to remember to also add WITHOUT_LIB32=true to /etc/src.conf, otherwise lib32 stuff will get installed during the next world build and install. sysinstall manipulating src.conf would be a Really Nice Feature(tm), and would probably save some folks from the exact situation you're describing. > ... or is there another mechanism preventing this from happen? Nope, src.conf is the right place. >>> There's also a /libexec/ld-elf32.so.1 left, with the same old date as >>> the libs, and a symlink from /usr/libexec/ld-elf32.so.1 pointing to >>> it. Should I leave them or remove them? They were not mentioned in >>> the diff in the bugreport. >> >> You should safely be able to remove those as well, assuming you have >> rebuilt/reinstalled world, and rebuilt all of your ports. Otherwise >> upon removal, programs utilising ld-elf32.so.1, won't have a valid >> ld.so loader, and will fail immediately. > > World is rebuilt but I haven't rebuilt my ports but they shouldn't have > been built against the 32-bit libraries in the first place, should they? That depends on if the port chooses to utilise such. ldd(1) will answer that question. It can be a tedious process to go through all the binaries on one's system to see which are linked with what, however. > 64-bit libraries are the default choice I assume or am I missing > something vital here? I'll remove them and see what happens when I > reboot. It will be an exciting start of the day ;-) Chances are nothing uses them, but then again I have no idea what ports or packages you've installed -- there are some which do not work on amd64 and are explicitly for i386. > Thanks again for your help, It's highly appreciated. No problem! -- | Jeremy Chadwick jdc 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 | From viper at perm.raid.ru Thu Aug 14 10:15:23 2008 From: viper at perm.raid.ru (Vladimir Korkodinov) Date: Thu Aug 14 10:15:31 2008 Subject: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you Message-ID: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> Same thing. http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html -- Best regards Vladimir Korkodinov From kostikbel at gmail.com Thu Aug 14 11:00:12 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Aug 14 11:00:26 2008 Subject: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] In-Reply-To: <200808131548.37571.jhb@freebsd.org> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> <200808131548.37571.jhb@freebsd.org> Message-ID: <20080814103809.GK1803@deviant.kiev.zoral.com.ua> On Wed, Aug 13, 2008 at 03:48:37PM -0400, John Baldwin wrote: > On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > > > Dear Konstantin Belousov, > > > > > > As you have requested, I would like to notify you that you have > > > committed a change that may be MFC'ed now, as a testing period > > > specified at the time of that commit is over. > > > > > > For reference purposes following is a copy of your original > > > commit message. > > > > > > Regards, > > > > > > Maxim "MFC Reminder" Sobolev > > > P.S. Please contact Maxim Sobolev if you > > > believe that you received this message due to an error. > > > > > > kib 2008-07-30 11:30:55 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/amd64/amd64 cpu_switch.S genassym.c > > > sys/amd64/ia32 ia32_signal.c > > > sys/amd64/include pcb.h > > > sys/amd64/linux32 linux32_machdep.c > > > Log: > > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > > > the 32bit images on amd64. > > > > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > > switch code to operate on the segment registers. Its previous meaning > > > of saving or restoring the %gs base offset is assigned to the new > > > PCB_GS32BIT flag. > > > > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > > > > Reviewed by: peter > > > MFC after: 2 weeks > > > > > > Revision Changes Path > > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > > > > This appeared to be a not quite trivial MFC to perform. The reason for > > complication is that the HEAD code for amd64 context switch was changed, > > in particular by the r177535 by peter@. > > > > The r177535 formally requires r177533 for the definition of the > > TDP_KTHREAD symbol for asm. The definition is needed for optimization > > of the context switch to the "pure kernel thread", introduced in > > r173004 that is not MFCed either, and possibly never be. > > > > I do not want to backport the code to the old context switch, that would > > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > > of context switch by peter@), and commented out corresponding test in > > the cpu_switch.S for the TDP_KTHREAD. > > > > I would be glad to get an opinions on the approach taken, and especially > > for the wider testing on the RELENG_7/amd64. The problem better be > > solved for 7.1. > > > > The patch: > > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch > > FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREAD > replaced. Thank you for note. I updated the patch to use P_KTHREAD. http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.5.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080814/8d1bc106/attachment-0002.pgp From kostikbel at gmail.com Thu Aug 14 11:00:12 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Aug 14 11:00:28 2008 Subject: Pending MFC Reminder [cvs commit: src/sys/amd64/amd64 cpu_switch.S genassym.c src/sys/amd64/ia32 ia32_signal.c src/sys/amd64/include pcb.h src/sys/amd64/linux32 linux32_machdep.c] In-Reply-To: <200808131548.37571.jhb@freebsd.org> References: <200808130022.m7D0MCaK082721@freefall.freebsd.org> <20080813134210.GG1803@deviant.kiev.zoral.com.ua> <200808131548.37571.jhb@freebsd.org> Message-ID: <20080814103809.GK1803@deviant.kiev.zoral.com.ua> On Wed, Aug 13, 2008 at 03:48:37PM -0400, John Baldwin wrote: > On Wednesday 13 August 2008 09:42:10 am Kostik Belousov wrote: > > On Wed, Aug 13, 2008 at 12:22:12AM +0000, MFC Notification Service wrote: > > > Dear Konstantin Belousov, > > > > > > As you have requested, I would like to notify you that you have > > > committed a change that may be MFC'ed now, as a testing period > > > specified at the time of that commit is over. > > > > > > For reference purposes following is a copy of your original > > > commit message. > > > > > > Regards, > > > > > > Maxim "MFC Reminder" Sobolev > > > P.S. Please contact Maxim Sobolev if you > > > believe that you received this message due to an error. > > > > > > kib 2008-07-30 11:30:55 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/amd64/amd64 cpu_switch.S genassym.c > > > sys/amd64/ia32 ia32_signal.c > > > sys/amd64/include pcb.h > > > sys/amd64/linux32 linux32_machdep.c > > > Log: > > > SVN rev 180992 on 2008-07-30 11:30:55Z by kib > > > > > > Bring back the save/restore of the %ds, %es, %fs and %gs registers for > > > the 32bit images on amd64. > > > > > > Change the semantic of the PCB_32BIT pcb flag to request the context > > > switch code to operate on the segment registers. Its previous meaning > > > of saving or restoring the %gs base offset is assigned to the new > > > PCB_GS32BIT flag. > > > > > > FreeBSD 32bit image activator sets the PCB_32BIT flag, while Linux 32bit > > > emulation sets PCB_32BIT | PCB_GS32BIT. > > > > > > Reviewed by: peter > > > MFC after: 2 weeks > > > > > > Revision Changes Path > > > 1.162 +29 -18 src/sys/amd64/amd64/cpu_switch.S > > > 1.169 +1 -0 src/sys/amd64/amd64/genassym.c > > > 1.18 +1 -1 src/sys/amd64/ia32/ia32_signal.c > > > 1.65 +1 -0 src/sys/amd64/include/pcb.h > > > 1.47 +1 -1 src/sys/amd64/linux32/linux32_machdep.c > > > > This appeared to be a not quite trivial MFC to perform. The reason for > > complication is that the HEAD code for amd64 context switch was changed, > > in particular by the r177535 by peter@. > > > > The r177535 formally requires r177533 for the definition of the > > TDP_KTHREAD symbol for asm. The definition is needed for optimization > > of the context switch to the "pure kernel thread", introduced in > > r173004 that is not MFCed either, and possibly never be. > > > > I do not want to backport the code to the old context switch, that would > > mean a rewrite from scratch. Instead, I merged the r177535 (optimization > > of context switch by peter@), and commented out corresponding test in > > the cpu_switch.S for the TDP_KTHREAD. > > > > I would be glad to get an opinions on the approach taken, and especially > > for the wider testing on the RELENG_7/amd64. The problem better be > > solved for 7.1. > > > > The patch: > > http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.4.patch > > FYI, in 6.x and 7.x there is P_KTHREAD in p_flags that is what TDP_KTHREAD > replaced. Thank you for note. I updated the patch to use P_KTHREAD. http://people.freebsd.org/~kib/misc/amd64_ctx.releng_7.5.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080814/8d1bc106/attachment-0003.pgp From markus at vervier.info Thu Aug 14 11:33:47 2008 From: markus at vervier.info (Markus Vervier) Date: Thu Aug 14 11:33:53 2008 Subject: em(4) on FreeBSD is sometimes annoying In-Reply-To: <2a41acea0808131210r6371b532i93f1ae6963d1f1b9@mail.gmail.com> References: <489C4129.4090303@vervier.info> <489C88DB.6030000@vervier.info> <2a41acea0808081131m1eddc4caib0963c8a5443afd2@mail.gmail.com> <200808110819.53914.josh@tcbug.org> <20080811140249.GA27379@eos.sc1.parodius.com> <2a41acea0808110928h10d54441o7d49b11a60406934@mail.gmail.com> <48A0A1D9.8030601@vervier.info> <2a41acea0808111340o7b506804u9e4c95f1af22b95c@mail.gmail.com> <48A2B1CB.7060303@vervier.info> <2a41acea0808130822i5f336b1ci15099f27a3a7c13d@mail.gmail.com> <2a41acea0808131210r6371b532i93f1ae6963d1f1b9@mail.gmail.com> Message-ID: <48A41816.3040904@vervier.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jack Vogel wrote: | I have reproduced the problem, you are correct. Thank you for | persisting thru my doubts :) Always persisting to help improving FreeBSD. Another odd thing I noticed today: When dual-booting Windows on the same machine and doing a warm-reboot from Windows to FreeBSD, you _do_ get a link with the procedure I described yesterday.. So there seems to be some setting which is lost after cold-boot or some EEPROM setting which is changed somehow. | OH, I should note that as long as you put in a cable before you | ifconfig up its fine so | its not that hard to work around the issue. I completly forgot about the issue until now, after I noticed it some time ago when being overworked. :-( The situation just does not occur very often in times of wireless LAN / Docking Stations. :-) - -- Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkikGBMACgkQFhK2gHeM2QOLpACfdX4IyNSivy+TgAJBhKgZUwP2 iiIAoNrPUTE0veViP7Zklm7jD25m7Aad =DrBs -----END PGP SIGNATURE----- From caelian at gmail.com Thu Aug 14 12:54:47 2008 From: caelian at gmail.com (Pascal Hofstee) Date: Thu Aug 14 12:54:54 2008 Subject: CPUTYPE weirdness In-Reply-To: <20080814143546.5e1a6a16@nebuchadnezzar> References: <20080814143546.5e1a6a16@nebuchadnezzar> Message-ID: <20080814145441.0e6130d7@nebuchadnezzar> On Thu, 14 Aug 2008 14:35:46 +0200 Pascal Hofstee wrote: > I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to > update to RELENG_7_0. > > I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > in /usr/src now gives me the error > > "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > with ?=. > *** Error code 1 > > Anyone has any idea what i am doing wrong here ... this same mechanism > has worked flawlessly on several other systems (although they were not > RELENG_7_0) ? Ok ... minor follow up. I found one way to "resolve" this problem, which consists of besides /etc/src.conf also creating an /etc/make.conf that contains a single "CPUTYPE ?= core2". Why this seems to be necessary i don't quite understand yet though. -- Pascal Hofstee From caelian at gmail.com Thu Aug 14 13:00:47 2008 From: caelian at gmail.com (Pascal Hofstee) Date: Thu Aug 14 13:00:54 2008 Subject: CPUTYPE weirdness Message-ID: <20080814143546.5e1a6a16@nebuchadnezzar> Hi, I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update to RELENG_7_0. I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make in /usr/src now gives me the error "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set with ?=. *** Error code 1 Anyone has any idea what i am doing wrong here ... this same mechanism has worked flawlessly on several other systems (although they were not RELENG_7_0) ? -- Pascal Hofstee From koitsu at FreeBSD.org Thu Aug 14 13:09:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 13:10:03 2008 Subject: CPUTYPE weirdness In-Reply-To: <20080814143546.5e1a6a16@nebuchadnezzar> References: <20080814143546.5e1a6a16@nebuchadnezzar> Message-ID: <20080814130954.GA25304@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: > I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update > to RELENG_7_0. > > I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > in /usr/src now gives me the error > > "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > with ?=. > *** Error code 1 > > Anyone has any idea what i am doing wrong here ... this same mechanism > has worked flawlessly on several other systems (although they were not > RELENG_7_0) ? 1) Remove the space after the word "CPUTYPE", e.g.: CPUTYPE?=core2 You can put a tab after the "=" if you want, e.g.: CPUTYPE?= core2 2) According to some very old mail I have (will dig it up if you want), Core2Duo users should be using CPUTYPE?=nocona. -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Thu Aug 14 13:10:57 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 13:11:04 2008 Subject: CPUTYPE weirdness In-Reply-To: <20080814145441.0e6130d7@nebuchadnezzar> References: <20080814143546.5e1a6a16@nebuchadnezzar> <20080814145441.0e6130d7@nebuchadnezzar> Message-ID: <20080814131056.GB25304@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 02:54:41PM +0200, Pascal Hofstee wrote: > On Thu, 14 Aug 2008 14:35:46 +0200 > Pascal Hofstee wrote: > > > I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to > > update to RELENG_7_0. > > > > I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > > in /usr/src now gives me the error > > > > "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > > with ?=. > > *** Error code 1 > > > > Anyone has any idea what i am doing wrong here ... this same mechanism > > has worked flawlessly on several other systems (although they were not > > RELENG_7_0) ? > > Ok ... minor follow up. > I found one way to "resolve" this problem, which consists of > besides /etc/src.conf also creating an /etc/make.conf that contains a > single "CPUTYPE ?= core2". Another mistake: You do not declare CPUTYPE in src.conf; you put it in make.conf. Please read the src.conf(5) and make.conf(5) manpages to distinguish the difference in functionality. -- | Jeremy Chadwick jdc 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 | From stefan.lambrev at moneybookers.com Thu Aug 14 13:23:24 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu Aug 14 13:23:32 2008 Subject: CPUTYPE weirdness In-Reply-To: <20080814130954.GA25304@eos.sc1.parodius.com> References: <20080814143546.5e1a6a16@nebuchadnezzar> <20080814130954.GA25304@eos.sc1.parodius.com> Message-ID: <48A431C6.1050401@moneybookers.com> Jeremy Chadwick wrote: > On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: > >> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update >> to RELENG_7_0. >> >> I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make >> in /usr/src now gives me the error >> >> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set >> with ?=. >> *** Error code 1 >> >> Anyone has any idea what i am doing wrong here ... this same mechanism >> has worked flawlessly on several other systems (although they were not >> RELENG_7_0) ? >> > > 1) Remove the space after the word "CPUTYPE", e.g.: > > CPUTYPE?=core2 > > You can put a tab after the "=" if you want, e.g.: > > CPUTYPE?= core2 > > 2) According to some very old mail I have (will dig it up if you want), > Core2Duo users should be using CPUTYPE?=nocona. > This should be fixed long time ago. core2 is alias for nocona but the idea is users to be ready when additional optimization for core2 are added. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From k at kevinkevin.com Thu Aug 14 13:38:12 2008 From: k at kevinkevin.com (Kevin) Date: Thu Aug 14 13:38:19 2008 Subject: RTL8187 drivers for FreeBSD (usb wlan device) Message-ID: <004c01c8fe12$f2386df0$d6a949d0$@com> I'm curious about getting my RTL8187 WLAN Usb device to work under freebsd. Has anyone got a rtl8187 based wlan stick working with freebsd? As far I know ndisgen won't work because it does not support usb devices. When I install the windows drivers via ndisgen , there are kernel error messages reported. FreeBSD detects the device when I initially plug it in, but nothing more becomes of that. There are debian / linux drivers available for this device, however I know nothing about porting linux drivers to FreeBSD, nor do I really want to wipe my laptop and put debian on it ;) Any advice regarding these drivers being already available or ported somewhere, or perhaps any advice for someone to help facilitate the driver being ported would be greatly appreciated! Thanks , Kevin K. From mike at sentex.net Thu Aug 14 14:29:23 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Aug 14 14:29:30 2008 Subject: broken routing / arp (was HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you) In-Reply-To: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> References: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> Message-ID: <200808141429.m7EETFMd043323@lava.sentex.ca> At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote: >Same thing. > >http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html > Well, that narrows it down a bit since you are not running with Intel nics. It seems to be in the commits below between date=2008.07.30.18.00.00 and date=2008.07.31.00.00.00 Updating collection src-all/cvs Edit src/sys/conf/files Add delta 1.1243.2.32 2008.07.30.20.35.41 kmacy Checkout src/sys/dev/e1000/LICENSE Checkout src/sys/dev/e1000/README Checkout src/sys/dev/e1000/e1000_80003es2lan.c Checkout src/sys/dev/e1000/e1000_80003es2lan.h Checkout src/sys/dev/e1000/e1000_82540.c Checkout src/sys/dev/e1000/e1000_82541.c Checkout src/sys/dev/e1000/e1000_82541.h Checkout src/sys/dev/e1000/e1000_82542.c Checkout src/sys/dev/e1000/e1000_82543.c Checkout src/sys/dev/e1000/e1000_82543.h Checkout src/sys/dev/e1000/e1000_82571.c Checkout src/sys/dev/e1000/e1000_82571.h Checkout src/sys/dev/e1000/e1000_82575.c Checkout src/sys/dev/e1000/e1000_82575.h Checkout src/sys/dev/e1000/e1000_api.c Checkout src/sys/dev/e1000/e1000_api.h Checkout src/sys/dev/e1000/e1000_defines.h Checkout src/sys/dev/e1000/e1000_hw.h Checkout src/sys/dev/e1000/e1000_ich8lan.c Checkout src/sys/dev/e1000/e1000_ich8lan.h Checkout src/sys/dev/e1000/e1000_mac.c Checkout src/sys/dev/e1000/e1000_mac.h Checkout src/sys/dev/e1000/e1000_manage.c Checkout src/sys/dev/e1000/e1000_manage.h Checkout src/sys/dev/e1000/e1000_nvm.c Checkout src/sys/dev/e1000/e1000_nvm.h Checkout src/sys/dev/e1000/e1000_osdep.c Checkout src/sys/dev/e1000/e1000_osdep.h Checkout src/sys/dev/e1000/e1000_phy.c Checkout src/sys/dev/e1000/e1000_phy.h Checkout src/sys/dev/e1000/e1000_regs.h Checkout src/sys/dev/e1000/if_em.c Checkout src/sys/dev/e1000/if_em.h Checkout src/sys/dev/e1000/if_igb.h Edit src/sys/kern/kern_synch.c Add delta 1.302.2.3 2008.07.30.18.28.09 rwatson Edit src/sys/kern/sys_process.c Add delta 1.145.2.1 2008.07.30.19.49.10 jhb Edit src/sys/netinet/tcp_subr.c Add delta 1.300.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_syncache.c Add delta 1.130.2.9 2008.07.30.20.35.41 kmacy Add delta 1.130.2.10 2008.07.30.20.51.20 kmacy Edit src/sys/netinet/tcp_syncache.h Add delta 1.1.2.1 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/tcp_usrreq.c Add delta 1.163.2.4 2008.07.30.20.35.41 kmacy Edit src/sys/netinet/udp_usrreq.c Add delta 1.218.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_input.c Add delta 1.95.2.1 2008.07.30.21.23.21 bz Edit src/sys/netinet6/ip6_var.h Add delta 1.39.2.2 2008.07.30.21.23.21 bz Edit src/sys/sys/socket.h Add delta 1.95.2.3 2008.07.30.19.35.40 kmacy Edit src/sys/ufs/ufs/ufs_lookup.c Add delta 1.83.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.c Add delta 1.385.2.2 2008.07.30.21.43.42 jhb Edit src/sys/vm/vm_object.h Add delta 1.114.2.1 2008.07.30.21.43.42 jhb Edit src/sys/vm/vnode_pager.c Add delta 1.236.2.2 2008.07.30.21.43.42 jhb >-- >Best regards >Vladimir Korkodinov > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From Johan at double-l.nl Thu Aug 14 14:30:22 2008 From: Johan at double-l.nl (Johan Hendriks) Date: Thu Aug 14 14:30:31 2008 Subject: CPUTYPE weirdness References: <20080814143546.5e1a6a16@nebuchadnezzar><20080814130954.GA25304@eos.sc1.parodius.com> <48A431C6.1050401@moneybookers.com> Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> >Jeremy Chadwick wrote: >> On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: >> >>> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update >>> to RELENG_7_0. >>> >>> I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make >>> in /usr/src now gives me the error >>> >>> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set >>> with ?=. >>> *** Error code 1 >>> >>> Anyone has any idea what i am doing wrong here ... this same mechanism >>> has worked flawlessly on several other systems (although they were not >>> RELENG_7_0) ? >>> >> >> 1) Remove the space after the word "CPUTYPE", e.g.: >> >> CPUTYPE?=core2 >> >> You can put a tab after the "=" if you want, e.g.: >> >> CPUTYPE?= core2 >> >> 2) According to some very old mail I have (will dig it up if you want), >> Core2Duo users should be using CPUTYPE?=nocona. >> >This should be fixed long time ago. core2 is alias for nocona but the >idea is users to >be ready when additional optimization for core2 are added. If you install amd64 then you need nocona if you install i386 you will need presscot. Or use core2 and FreeBSD itself looks at the arch and use nocona or presscot. That?s what I understand from what I read on the net Regards, Johan No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.3/1611 - Release Date: 14-8-2008 6:20 From koitsu at FreeBSD.org Thu Aug 14 14:34:36 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 14:34:43 2008 Subject: broken routing / arp (was HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you) In-Reply-To: <200808141429.m7EETFMd043323@lava.sentex.ca> References: <31986.212.33.232.121.1218702457.squirrel@mail.raid.ru> <200808141429.m7EETFMd043323@lava.sentex.ca> Message-ID: <20080814143435.GA28316@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 10:29:09AM -0400, Mike Tancsa wrote: > At 04:27 AM 8/14/2008, Vladimir Korkodinov wrote: >> Same thing. >> >> http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019220.html >> > > Well, that narrows it down a bit since you are not running with Intel > nics. It seems to be in the commits below between > date=2008.07.30.18.00.00 > and > date=2008.07.31.00.00.00 You can ignore the src/sys/dev/e1000 commits, since those are specific to Intel NICs -- specifically splitting up em(4) and igb(4). -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Thu Aug 14 14:36:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 14:36:56 2008 Subject: CPUTYPE weirdness In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> References: <48A431C6.1050401@moneybookers.com> <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> Message-ID: <20080814143648.GB28316@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 04:13:51PM +0200, Johan Hendriks wrote: > >Jeremy Chadwick wrote: > >> On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: > >> > >>> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update > >>> to RELENG_7_0. > >>> > >>> I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make > >>> in /usr/src now gives me the error > >>> > >>> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set > >>> with ?=. > >>> *** Error code 1 > >>> > >>> Anyone has any idea what i am doing wrong here ... this same mechanism > >>> has worked flawlessly on several other systems (although they were not > >>> RELENG_7_0) ? > >>> > >> > >> 1) Remove the space after the word "CPUTYPE", e.g.: > >> > >> CPUTYPE?=core2 > >> > >> You can put a tab after the "=" if you want, e.g.: > >> > >> CPUTYPE?= core2 > >> > >> 2) According to some very old mail I have (will dig it up if you want), > >> Core2Duo users should be using CPUTYPE?=nocona. > >> > >This should be fixed long time ago. core2 is alias for nocona but the > >idea is users to > >be ready when additional optimization for core2 are added. > > If you install amd64 then you need nocona if you install i386 you will need presscot. > Or use core2 and FreeBSD itself looks at the arch and use nocona or presscot. > > That?s what I understand from what I read on the net 1) It's prescott, not presscot. 2) You can use nocona on both i386 and amd64 -- I speak from experience. I'm referring to RELENG_7 by the way; I don't think nocona is recognised by the base system gcc on RELENG_6. -- | Jeremy Chadwick jdc 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 | From koitsu at FreeBSD.org Thu Aug 14 14:40:13 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 14 14:40:23 2008 Subject: CPUTYPE weirdness In-Reply-To: <20080814143648.GB28316@eos.sc1.parodius.com> References: <48A431C6.1050401@moneybookers.com> <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> <20080814143648.GB28316@eos.sc1.parodius.com> Message-ID: <20080814144012.GA28665@eos.sc1.parodius.com> On Thu, Aug 14, 2008 at 07:36:48AM -0700, Jeremy Chadwick wrote: > 2) You can use nocona on both i386 and amd64 -- I speak from > experience. I'm referring to RELENG_7 by the way; I don't think > nocona is recognised by the base system gcc on RELENG_6. I stand corrected -- you can use it on RELENG_6 as well: $ egrep 'KERNCONF|CPUTYPE' /etc/make.conf KERNCONF=PDSMI_PLUS_i386 CPUTYPE?=nocona $ uname -a FreeBSD anubis.sc1.parodius.com 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Jan 17 02:09:20 PST 2008 root@anubis.sc1.parodius.com:/usr/obj/usr/src/sys/ANUBIS i386 $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 -- | Jeremy Chadwick jdc 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 | From k at kevinkevin.com Thu Aug 14 15:00:18 2008 From: k at kevinkevin.com (Kevin) Date: Thu Aug 14 15:00:25 2008 Subject: RTL8187 drivers for FreeBSD (usb wlan device) Message-ID: <005201c8fe1e$6a515c10$3ef41430$@com> I'm curious about getting my RTL8187 WLAN Usb device to work under freebsd. Has anyone got a rtl8187 based wlan stick working with freebsd? As far I know ndisgen won't work because it does not support usb devices. When I install the windows drivers via ndisgen , there are kernel error messages reported. FreeBSD detects the device when I initially plug it in, but nothing more becomes of that. There are debian / linux drivers available for this device, however I know nothing about porting linux drivers to FreeBSD, nor do I really want to wipe my laptop and put debian on it ;) Any advice regarding these drivers being already available or ported somewhere, or perhaps any advice for someone to help facilitate the driver being ported would be greatly appreciated! Thanks , Kevin K. From gavin.atkinson at ury.york.ac.uk Thu Aug 14 15:01:47 2008 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Thu Aug 14 15:01:58 2008 Subject: RTL8187 drivers for FreeBSD (usb wlan device) In-Reply-To: <004c01c8fe12$f2386df0$d6a949d0$@com> References: <004c01c8fe12$f2386df0$d6a949d0$@com> Message-ID: <20080814155037.A29502@ury.york.ac.uk> On Thu, 14 Aug 2008, Kevin wrote: > I'm curious about getting my RTL8187 WLAN Usb device to work under freebsd. > Has anyone got a rtl8187 based wlan stick working with freebsd? Be aware that the RTL8187, RTL8187B and RTL8187L are all different chipsets. I believe Linux has two drivers for them, one driver covers two chips. > As far I know ndisgen won't work because it does not support usb devices. > When I install the windows drivers via ndisgen , there are kernel error > messages reported. FreeBSD detects the device when I initially plug it in, > but nothing more becomes of that. Some work on supporting USB under NDIS has been done, it might be worth investigating just how far from completion it is. > There are debian / linux drivers available for this device, however I know > nothing about porting linux drivers to FreeBSD, nor do I really want to wipe > my laptop and put debian on it ;) Linux drivers are often hard to port, purely because they are badly documented and often use "magic" values which may need to be different under FreeBSD. I looked at the code a little while starting my own RTL8087B driver, but ended up preferring to monitor how Windows talked to the device. Note, however, that my driver is nowhere near finished (doesn't even have code to send/receive yet), so there's no point me sending it to you... Gavin From bazerka at beardz.net Thu Aug 14 15:03:09 2008 From: bazerka at beardz.net (Jase Thew) Date: Thu Aug 14 15:03:48 2008 Subject: CPUTYPE weirdness In-Reply-To: <20080814143648.GB28316@eos.sc1.parodius.com> References: <48A431C6.1050401@moneybookers.com> <57200BF94E69E54880C9BB1AF714BBCB5DE086@w2003s01.double-l.local> <20080814143648.GB28316@eos.sc1.parodius.com> Message-ID: <48A4442D.7060203@beardz.net> Jeremy Chadwick wrote: > On Thu, Aug 14, 2008 at 04:13:51PM +0200, Johan Hendriks wrote: >>> Jeremy Chadwick wrote: >>>> On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: >>>> >>>>> I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update >>>>> to RELENG_7_0. >>>>> >>>>> I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make >>>>> in /usr/src now gives me the error >>>>> >>>>> "/usr/src/Makefile.inc1", line 142: CPUTYPE global should be set >>>>> with ?=. >>>>> *** Error code 1 >>>>> >>>>> Anyone has any idea what i am doing wrong here ... this same mechanism >>>>> has worked flawlessly on several other systems (although they were not >>>>> RELENG_7_0) ? >>>>> >>>> 1) Remove the space after the word "CPUTYPE", e.g.: >>>> >>>> CPUTYPE?=core2 >>>> >>>> You can put a tab after the "=" if you want, e.g.: >>>> >>>> CPUTYPE?= core2 >>>> >>>> 2) According to some very old mail I have (will dig it up if you want), >>>> Core2Duo users should be using CPUTYPE?=nocona. >>>> >>> This should be fixed long time ago. core2 is alias for nocona but the >>> idea is users to >>> be ready when additional optimization for core2 are added. >> If you install amd64 then you need nocona if you install i386 you will need presscot. >> Or use core2 and FreeBSD itself looks at the arch and use nocona or presscot. >> >> That?s what I understand from what I read on the net > > 1) It's prescott, not presscot. > > 2) You can use nocona on both i386 and amd64 -- I speak from > experience. I'm referring to RELENG_7 by the way; I don't think > nocona is recognised by the base system gcc on RELENG_6. > nocona is definitely supported by base gcc in RELENG_6_3 and is listed in the gcc manpage : nocona Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. I have it in my /etc/make.conf for 6.3-REL/amd64 and it works a charm. Regards, Jase. From k at kevinkevin.com Thu Aug 14 15:08:06 2008 From: k at kevinkevin.com (Kevin) Date: Thu Aug 14 15:08:12 2008 Subject: RTL8187 drivers for FreeBSD (usb wlan device) In-Reply-To: <20080814155037.A29502@ury.york.ac.uk> References: <004c01c8fe12$f2386df0$d6a949d0$@com> <20080814155037.A29502@ury.york.ac.uk> Message-ID: <005501c8fe1f$80f350d0$82d9f270$@com> > Be aware that the RTL8187, RTL8187B and RTL8187L are all different > chipsets. I believe Linux has two drivers for them, one driver covers > two > chips. I believe it is the RTL8187L chipset. The actual device is an Alfa Network "AWUS036H" , product information is http://dplanet.biz/alfa.com/product_info.php?products_id=342 . > Some work on supporting USB under NDIS has been done, it might be worth > investigating just how far from completion it is. I'll look into this -- I believe ndisgen is built into freebsd by default, however I'm not sure. > Linux drivers are often hard to port, purely because they are badly > documented and often use "magic" values which may need to be different > under FreeBSD. I looked at the code a little while starting my own > RTL8087B driver, but ended up preferring to monitor how Windows talked > to > the device. Note, however, that my driver is nowhere near finished > (doesn't even have code to send/receive yet), so there's no point me > sending it to you... Ideally I'd like to utilize a stable port/driver. /usr/ports/devel/linux-kmod-compat was recommended to me (http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html) , however I don't believe this to be a viable option since it was primarily developed to "wrap" drivers for usb webcams. Thanks for your suggestions, I will look into the ndisgen progress in any case. Hopefully USB support is more defined, or will be more defined in the near future. From ip at doom.ctinet.ru Thu Aug 14 15:21:30 2008 From: ip at doom.ctinet.ru (Igor Pokrovsky) Date: Thu Aug 14 15:21:39 2008 Subject: ssh-keygen between SuSE and FreeBSD In-Reply-To: <48A31B61020000900001C109@hermes.cwu.edu> References: <48A31B61020000900001C109@hermes.cwu.edu> Message-ID: <20080814151047.GA32430@doom.ctinet.ru> On Wed, Aug 13, 2008 at 05:35:29PM -0700, Gavin Spomer wrote: > I hope this isn't an invalid topic for this list. I'm on so many lists and I hate to join another one just to get help on one thing. Apologies if it's not. > > I am able to use ssh-keygen to generate keys so that I can ssh from my Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD systems, without having to enter my password. When I try the same thing from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen -t rsa" on the SuSE system, then copy the id_rsa.pub to my ~/.ssh/authorized_keys file on the FreeBSD system) I get the following message when ssh-ing to the FreeBSD system: > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': > > ... and I have to enter my password. I've Googled, but can't seem to find the answer to my dilemma. Is it generally kind of a pain to do this between platforms? I'm finally very comfortable on FreeBSD and am starting to really get annoyed with SuSE. :( You can generate keys with empty pass phrase, so it won't be asked ;-) -ip From spomerg at cwu.EDU Thu Aug 14 15:29:35 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Thu Aug 14 15:29:43 2008 Subject: ssh-keygen between SuSE and FreeBSD Message-ID: <48A3ECE7020000900001C150@hermes.cwu.edu> >>> Lyndon Nerenberg 08/13/08 7:10 PM >>> > You need to start an ssh-agent on the machine you're connecting from and > populate it with your keychain: > > eval `ssh-agent` > ssh-add > > Add the above to your .profile, or check the Linux PAM implementation to > see if it has ssh session support. > > --lyndon Thanks. That made it possible for me to ssh from SuSE server to FreeBSD server, but now when I ssh from my Mac to SuSE server it wants a password now: Enter passphrase for /home/myusername/.ssh/id_rsa: I read the FreeBSD handbook section "14.11.7 ssh-agent and ssh-add" and don't have anything much more intelligent to say but "I don't understand". ;) Questions: 1. If the ssh-agent and ssh-add utilities load the keys into memory, they'd be wiped if I rebooted? 2. Is #1 why I'd add it to my ~/.profile? 3. How am I able to ssh (without a password) from my Mac to SuSE server or Mac to FreeBSD server when I don't have "eval `ssh-agent`" and "ssh-add" in my .profile on my Mac? From spomerg at cwu.EDU Thu Aug 14 15:30:51 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Thu Aug 14 15:30:58 2008 Subject: ssh-keygen between SuSE and FreeBSD Message-ID: <48A3ED37020000900001C154@hermes.cwu.edu> > >>> Paul Schmehl 08/13/08 7:18 PM >>> > --On August 13, 2008 5:35:29 PM -0700 Gavin Spomer wrote: > > I am able to use ssh-keygen to generate keys so that I can ssh from my > > Mac to any of my SuSE systems or ssh from my Mac to any of my FreeBSD > > systems, without having to enter my password. When I try the same thing > > from a SuSE system to a FreeBSD system, (I.E. I run "ssh-keygen -t rsa" > > on the SuSE system, then copy the id_rsa.pub to my > > ~/.ssh/authorized_keys file on the FreeBSD system) I get the following > > message when ssh-ing to the FreeBSD system: > > > > Enter passphrase for key '/home/myusername/.ssh/id_rsa': > > Just to be clear....you're saying that your key pass*phrase* doesn't work > and you have to type your pass*word* in instead? Or did you make all your > previous keys passphrase-less and add a passphrase to this one? > > Paul Schmehl Uh, not sure. Head spinning now. ;) 1. I have a Mac, SuSE server and a FreeBSD server. 2. I can ssh from my Mac to SuSE server without having to type in my password. 3. I can ssh from my Mac to FreeBSD server without having to type in my password. 4. I can do #2 and #3 above because I ran "ssh-keygen -t rsa" on my Mac and copied the id_rsa.pub to my ~/.ssh/authorized_keys files on the SuSE and FreeBSD servers. 5. I ran the same "ssh-keygen -t rsa" on the SuSE server and copied the id_rsa.pub to the FreeBSD. 6. I canNOT ssh from the SuSE server to the FreeBSD server withOUT typing in my password. 7. When I ssh from SuSE server to FreeBSD server, I get prompted: Enter passphrase for key '/home/myusername/.ssh/id_rsa': 8. I want to be able to ssh from SuSE server to FreeBSD server because I want to run scp via a cron job. I noticed you made a distinction between password and passphrase. Could you please explain the difference? - Gavin From spomerg at cwu.EDU Thu Aug 14 15:43:02 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Thu Aug 14 15:43:13 2008 Subject: ssh-keygen between SuSE and FreeBSD Message-ID: <48A3F011020000900001C162@hermes.cwu.edu> > It's not asking for your password. It's asking for your passphrase to > decrypt your private key. Are you running an ssh-agent on the Suse > system? > -- > R. Kevin Oberman Aha! Thanks, Kevin. Things are clicking in my brain and I grok now. I just remembered that when I did ssh-keygen on my mac and then ssh'd to my servers, it stored the passPHRASE (right?) in my Mac's Keychain too. Thanks everyone. For further reference, can anyone clearly define what topics are valid for this list? - Gavin From spomerg at cwu.EDU Thu Aug 14 15:44:41 2008 From: spomerg at cwu.EDU (Gavin Spomer) Date: Thu Aug 14 15:44:49 2008 Subject: ssh-keygen between SuSE and FreeBSD Message-ID: <48A3F076020000900001C166@hermes.cwu.edu> > >>> Igor Pokrovsky 08/14/08 8:22 AM >>> > > ... and I have to enter my password. I've Googled, but can't seem to find the answer to my dilemma. Is it generally kind of a pain to do this between platforms? I'm finally very comfortable on FreeBSD and am starting to really get annoyed with SuSE. :( > > You can generate keys with empty pass phrase, so it won't be asked ;-) > > -ip Yes, this works. Any security concerns with doing this? - Gavin From lists-fbsdstable at shadypond.com Thu Aug 14 16:32:19 2008 From: lists-fbsdstable at shadypond.com (Pollywog) Date: Thu Aug 14 16:32:26 2008 Subject: ssh-keygen between SuSE and FreeBSD In-Reply-To: <48A3ECE7020000900001C150@hermes.cwu.edu> References: <48A3ECE7020000900001C150@hermes.cwu.edu> Message-ID: <200808141559.49973.lists-fbsdstable@shadypond.com> On Thursday 14 August 2008 15:29:27 Gavin Spomer wrote: > >>> Lyndon Nerenberg 08/13/08 7:10 PM >>> > > > > You need to start an ssh-agent on the machine you're connecting from and > > populate it with your keychain: > > > > eval `ssh-agent` > > ssh-add > > > > Add the above to your .profile, or check the Linux PAM implementation to > > see if it has ssh session support. > > > > --lyndon > > Thanks. > > That made it possible for me to ssh from SuSE server to FreeBSD server, but > now when I ssh from my Mac to SuSE server it wants a password now: > > Enter passphrase for /home/myusername/.ssh/id_rsa: > > I read the FreeBSD handbook section "14.11.7 ssh-agent and ssh-add" and > don't have anything much more intelligent to say but "I don't understand". > ;) > > Questions: > > 1. If the ssh-agent and ssh-add utilities load the keys into memory, > they'd be wiped if I rebooted? Yes, rebooting will take the keys out of memory and you would need to use 'ssh-add' on the command line to put the keys and passphrase in memory. The 'ssh-add -D' command removes the keys when you are done but are not logging out. > > 2.