Re: 8.2-PRE: hastd: Compile Error
Eugene, On Tue, Jan 18, 2011 at 4:11 PM, Eugene Grosbein wrote: On 18.01.2011 14:47, Olivier Certner wrote: > >> That's not a solution for 7->8 upgrade as new lex won't run under 7.x > >> kernel. > > > > I can confirm that compiling and installing 'lex' in advance > produces a > > working 'lex' on 7.x. > > > > My current understanding is that the procedure mentioned in a > previous mail > > uses the 8.x source but the 7.x tools and headers, so 'lex' then runs > > correctly, since it also doesn't depend on exotic kernel features found > only > > in 8.x. > > Got it, thanks. This is still workaround until real fix made, not solution. Please try attached patch. Max Makefile.inc1.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Keyboard repeat issues with Dell Optiplex 980s
On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: > > We've recently upgraded a few desktop workstations from Dell > Optiplex 960s to Optiplex 980s. We were running FreeBSD > 8.1-RELEASE. The migration was performed by simply swapping the > drives into the new systems. Immediately after switching people > over, they all began to report bizarre keyboard issues - things like > infinite key repeats (letters, numbers, "enter") for keys they did > not hold down. The key repeats continue indefinitely until another > key is pressed. Occasionally, even mouse input will trigger similar > infinite keyboard input repetition. In addition to the repeat > issue, sometimes physical key-presses are not registered by FreeBSD, > leading to typos and angry developers. > > We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these > systems, and the issue persists. Because of the observed behavior, > I'm thinking that this is due to new hardware in the 980s which > isn't timing or handling interrupts correctly under the FreeBSD > kernel. > > Looking at a 'pciconf -lvb' from each system, I noticed that the 980 > has two USB controllers which probe under ehci(4), while the 960 > (which does not exhibit this problem), enumerates six uhci(4) > controllers and two ehci(4) controllers. To cut to the chase here, > the 960 users' keyboards probe under a USB1.0 uhci(4), while the > 980s only have ehci(4) devices to attach to. > > So, I guess what I'm asking is - has anyone else seen any keyboard > repeat or other USB craziness with ehci(4) ports or otherwise Intel > PCH controllers?Any fellow Optiplex 980 users? I'd be more than > happy to provide pciconf or other output if requested. Try adding the following to /boot/loader.conf then reboot and see if the "excessive repeat" behaviour changes: hint.kbdmux.0.disabled="1" It would also help if you would state exactly what brand/model of keyboard is used. Yes, believe it or not, it matters. dmesg output would be helpful in this case. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Keyboard repeat issues with Dell Optiplex 980s
We've recently upgraded a few desktop workstations from Dell Optiplex 960s to Optiplex 980s. We were running FreeBSD 8.1-RELEASE. The migration was performed by simply swapping the drives into the new systems. Immediately after switching people over, they all began to report bizarre keyboard issues - things like infinite key repeats (letters, numbers, "enter") for keys they did not hold down. The key repeats continue indefinitely until another key is pressed. Occasionally, even mouse input will trigger similar infinite keyboard input repetition. In addition to the repeat issue, sometimes physical key-presses are not registered by FreeBSD, leading to typos and angry developers. We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these systems, and the issue persists. Because of the observed behavior, I'm thinking that this is due to new hardware in the 980s which isn't timing or handling interrupts correctly under the FreeBSD kernel. Looking at a 'pciconf -lvb' from each system, I noticed that the 980 has two USB controllers which probe under ehci(4), while the 960 (which does not exhibit this problem), enumerates six uhci(4) controllers and two ehci(4) controllers. To cut to the chase here, the 960 users' keyboards probe under a USB1.0 uhci(4), while the 980s only have ehci(4) devices to attach to. So, I guess what I'm asking is - has anyone else seen any keyboard repeat or other USB craziness with ehci(4) ports or otherwise Intel PCH controllers?Any fellow Optiplex 980 users? I'd be more than happy to provide pciconf or other output if requested. Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE/amd64 semi-regular crash with "kernel trap 12 with interrupts disabled" in "process 12 (swi4: clock)"
On Wed, Jan 19, 2011 at 12:12:48AM +0300, Lev Serebryakov wrote: > Hello, Freebsd-stable. > > One of my servers crashes about once a week, with always same > diagnostics: "kernel trap 12 with interrupts disabled" and in same > process: "swi4: clock" > > It doesn't look as memory failure, as memtest86+ can not find any > errors in 8 passes. > > Also, after this crash server refuse to auto-reboot, last message on > console is "cpu_reset: Stopping other CPUs", and it hangs. > > Kernel config, booting dmesg & results of "savecore" are attached > (bzipped). CC'ing Jack Vogel of Intel, as this looks like it could be something the em(4) driver might be tickling. I do see it in the stack trace shortly before the crash. In the interim, can you please provide output from the following command: # pciconf -lbcv And include only the entries relevant to your emX devices. As for the "the server refuses to auto-reboot": that may be a separate problem. You might try toggling the hw.acpi.disable_on_reboot and hw.acpi.handle_reboot sysctls (check what values they have on your system first) to see if there's any improvement. For Jack -- the core/stack trace, and dmesg are at the below URL as attachments (and bzip2 compressed): http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/061168.html -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RFC: Upgrade BIND version in RELENG_7 to BIND 9.6.x
On 18.12.2010 15:16, Eugene Grosbein wrote: > On 18.12.2010 11:41, Doug Barton wrote: > >> I am particularly interested in feedback from users with significant DNS >> usage that are still using 9.4, especially if you're using the version >> in the base. I would appreciate it if you could install 9.6 from the >> ports and at minimum run /usr/local/sbin/named-checkconf to see if any >> errors are generated. Of course it would be that much more helpful if >> you could also evaluate BIND 9.6 in operation in your environment. >> >> Your feedback on the issue of upgrading BIND in RELENG_7 is welcome. >> Sooner is better. :) > > I run serveral DNS servers based on FreeBSD+bind. > One of them is FreeBSD 7.3-STABLE and bind-9.4. > It's public primary server for two zones (one forward and one reverse) > and public secondary for several others; plus it's recursive caching DNS > server > for users, low-loaded. > > I've just updated ports tree and installed dns/bind96. > /usr/local/sbin/named-checkconf shows no messages at all. > > I've restarted bind using ports version. All seems OK. I'll write back if > problems arise. > About upgrading bind version in RELENG_7, I'm for it. Full month has passed, no problems noticed :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE/amd64 semi-regular crash with "kernel trap 12 with interrupts disabled" in "process 12 (swi4: clock)"
On 19.01.2011 03:12, Lev Serebryakov wrote: > Hello, Freebsd-stable. > > > One of my servers crashes about once a week, with always same > diagnostics: "kernel trap 12 with interrupts disabled" and in same > process: "swi4: clock" > > It doesn't look as memory failure, as memtest86+ can not find any > errors in 8 passes. > > Also, after this crash server refuse to auto-reboot, last message on > console is "cpu_reset: Stopping other CPUs", and it hangs. > > Kernel config, booting dmesg & results of "savecore" are attached > (bzipped). You have not mentioned what tasks does it perform. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRE: hastd: Compile Error
On Mon, 17 Jan 2011 16:38:57 -0600 (CST) Larry Rosenman wrote: > What can I do to fix this? > > csup'd around 2pm Central (US) time from cvsup5. > > cc -O2 -pipe -I/usr/src/sbin/hastd -DINET -DINET6 -DYY_NO_UNPUT > -DYY_NO_INPUT -DHAVE_CRYPTO -std=gnu99 -fstack-protector -Wsystem-headers > -Werror -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 > -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls > -Wno-pointer-sign -c token.c > cc1: warnings being treated as errors > /usr/src/sbin/hastd/token.l:456: warning: function declaration isn't a > prototype > *** Error code 1 > > Stop in /usr/src/sbin/hastd. > *** Error code 1 > > Stop in /usr/src/sbin. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > # $ "make -i" will get you past it, provided you do not need 'hastd', and provided you watch carefully for other possible errors (there appear to be no others at this time). -- Duane H. Hesser ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sis(4) broken on 8.2 [Re: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE]
On Tue, Jan 18, 2011 at 03:37:48AM +0100, Paul Schenkeveld wrote: > Hello, > > On Mon, Jan 17, 2011 at 02:26:24PM -0800, Pyun YongHyeon wrote: > > > Since you didn't post dmesg output I'm not sure what kind of > > > controller you have but I guess it would be NS8381[56]. I > > > overhauled sis(4) to make it work on all architectures so one of > > > change, probably r212119, could be cause of the issue. Due to lack > > > of SiS controllers I didn't touch multicast handling part so some > > > part of code still relies on old wrong behavior of driver. > > > Would you try attached patch and let me know whether it makes any > > > difference? > > > > > > > Hmm, unfortunately it seems the patch above may not work since NS > > data sheet says that filter function should be disabled before > > touching other bits in the register. > > Try this one instead. > > As far as I can tell, both patches work for me. Your second patch is > on my production firewalls now so if anthing comes up over the > coming days I'll keep you informed. > > I've tested carp, both failover to backup and fallback (preemption) > with IPv4 and with IPv6, all seems to work now. > Thanks for testing. Committed to HEAD(r217548). > Thannks again for your patches, hope you can get them into 8.2. > I'm afraid it's too late. :-( > Regards, > > Paul Schenkeveld ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Could MSGBUF_SIZE be made a loader tunable?
On 18 January 2011 19:19, John Baldwin wrote: > On Sunday, January 16, 2011 12:24:27 pm Sergey Kandaurov wrote: >> On 16 January 2011 06:10, wrote: >> > Anyone had a chance to look at this? >> > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060793.html >> >> To ease testing on head I have regenerated the patch >> (against r216594): >> http://plukky.net/~pluknet/patches/msgbufsize.diff > > The one hunk involving tf_rip and PS_STRINGS in amd64 looks to be unrelated. Woops, sorry. Nice catch! > Also, in subr_param.c, you can assume that MSGBUF_SIZE is always defined > and always assign it as the initial value rather than having an #ifdef. Good. > Finally, I would adjust the wording in the manpage to not say that this > modifies the MSGBUF_SIZE option, but that this tunable is the same as > adjusting MSGBUF_SIZE. Other than that I think it is fine. > Right. I think a simple s/Modifies/Overrides/ here will be enough. Thanks for your valuable comments. An updated patch is there: http://plukky.net/~pluknet/patches/msgbufsize.2.diff I'm going to commit this soon. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Could MSGBUF_SIZE be made a loader tunable?
On Sunday, January 16, 2011 12:24:27 pm Sergey Kandaurov wrote: > On 16 January 2011 06:10, wrote: > > Anyone had a chance to look at this? > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060793.html > > To ease testing on head I have regenerated the patch > (against r216594): > http://plukky.net/~pluknet/patches/msgbufsize.diff The one hunk involving tf_rip and PS_STRINGS in amd64 looks to be unrelated. Also, in subr_param.c, you can assume that MSGBUF_SIZE is always defined and always assign it as the initial value rather than having an #ifdef. Finally, I would adjust the wording in the manpage to not say that this modifies the MSGBUF_SIZE option, but that this tunable is the same as adjusting MSGBUF_SIZE. Other than that I think it is fine. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS 75 second stall
> > We're occaisionally seeing these same types of stalls (+ repeated "is > not responding" "is alive again" messages in quick succession). We're > seeing it only on our 8.1-RELEASE systems against a variety of NFS > servers (6.3-RELEASE, 7.2-RELEASE, and 8-STABLE from before the > release > of 8.1). We also see it happen with a variety of client hardware and > network adapters (em, bce, bge); the only common denominator is > 8.1-RELEASE on the clients. > I think this might be fixed by r217242 in head, which went into stable/8 as r217527. This krpc patch is also available at: http://people.freebsd.org/~rmacklem/krpc.patch Thanks go to John Gemignani for spotting this bug in the krpc code. It will not be in 8.2, so please grab the patch if you are using either NFS client in any FreeBSD8.n system, rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sis(4) broken on 8.2 [Re: Carp seems completely broken on 8.2-RC2 and 8.2-PRERELEASE]
On Mon, Jan 17, 2011 at 10:29 PM, Pyun YongHyeon wrote: >> Since Soekris hardware (net45xx, net48xx, lan16xx) is quite popular for >> firewalls and carp is quite often used together with this hardware, this >> looks like a showstopper for 8.2 :-( > > Since you didn't post dmesg output I'm not sure what kind of > controller you have but I guess it would be NS8381[56]. I > overhauled sis(4) to make it work on all architectures so one of > change, probably r212119, could be cause of the issue. Due to lack > of SiS controllers I didn't touch multicast handling part so some > part of code still relies on old wrong behavior of driver. Hi, I didn't upgrade my net4801s recently, but here's the relevant dmesg parts, just in case you nee them: sis0: port 0xe100-0xe1ff mem 0xa000-0xafff irq 10 at device 6.0 on pci0 sis0: Silicon Revision: DP83816A miibus0: on sis0 nsphyter0: PHY 0 on miibus0 nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:00:24:XX:XX:XX sis0: [ITHREAD] sis1: port 0xe200-0xe2ff mem 0xa0001000-0xa0001fff irq 10 at device 7.0 on pci0 sis1: Silicon Revision: DP83816A miibus1: on sis1 nsphyter1: PHY 0 on miibus1 nsphyter1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis1: Ethernet address: 00:00:24:XX:XX:XX sis1: [ITHREAD] sis2: port 0xe300-0xe3ff mem 0xa0002000-0xa0002fff irq 10 at device 8.0 on pci0 sis2: Silicon Revision: DP83816A miibus2: on sis2 nsphyter2: PHY 0 on miibus2 nsphyter2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis2: Ethernet address: 00:00:24:XX:XX:XX sis2: [ITHREAD] -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRE: hastd: Compile Error
On 18.01.2011 14:47, Olivier Certner wrote: >> That's not a solution for 7->8 upgrade as new lex won't run under 7.x >> kernel. > > I can confirm that compiling and installing 'lex' in advance produces a > working 'lex' on 7.x. > > My current understanding is that the procedure mentioned in a previous > mail > uses the 8.x source but the 7.x tools and headers, so 'lex' then runs > correctly, since it also doesn't depend on exotic kernel features found only > in 8.x. Got it, thanks. This is still workaround until real fix made, not solution. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRE: hastd: Compile Error
> That's not a solution for 7->8 upgrade as new lex won't run under 7.x > kernel. I can confirm that compiling and installing 'lex' in advance produces a working 'lex' on 7.x. My current understanding is that the procedure mentioned in a previous mail uses the 8.x source but the 7.x tools and headers, so 'lex' then runs correctly, since it also doesn't depend on exotic kernel features found only in 8.x. Olivier Certner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRE: hastd: Compile Error
On 18.01.2011 14:18, Olivier Certner wrote: >> I make buildworld without problems after that yesturday. > > Same here. Perhaps someone could add a small entry about that in > UPDATING? It > seems that this problem is likely to be reported over and over without such a > notice. IMO the problem should be fixed, not documented :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRE: hastd: Compile Error
> I make buildworld without problems after that yesturday. Same here. Perhaps someone could add a small entry about that in UPDATING? It seems that this problem is likely to be reported over and over without such a notice. Thanks, Olivier Certner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRE: hastd: Compile Error
On 18.01.2011 13:34, Lystopad Aleksandr wrote: > There are solution from Vsevolod Lobko: > > : just do: > : > : cd /usr/src/usr.bin/lex > : make obj > : make > : make install > : > : and buildworld works properly > > in http://www.freebsd.org/cgi/query-pr.cgi?pr=153947 > > I make buildworld without problems after that yesturday. That's not a solution for 7->8 upgrade as new lex won't run under 7.x kernel. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRE: hastd: Compile Error
On 18.01.2011 13:31, Larry Rosenman wrote: >> Someone have to fix hastd's Makefile and change WARNS level there. >> This problem breaks source upgrade. >> >> Eugene Grosbein > > Is anyone working on it? I'm trying to get a source upgrade from 8.0 to 8.2 > done. It seems, no. Also, there is PR for that: http://www.freebsd.org/cgi/query-pr.cgi?pr=153947 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
