Re: buildworld failure: don't know how to make thr_atfork.c
On Wed, 5 Nov 2003 17:17:05 +1030, Alex Wilkinson [EMAIL PROTECTED] wrote: CVSup'd today [Wed Nov 5 17:15:14 CST 2003] and buildworld fails. $ make buildworld . snip === lib/libpthread make: don't know how to make thr_atfork.c. Stop *** Error code 2 snip It's already fixed, Daniel has missed this file so David has committed it for him. Cheers, Mezz - aW -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-11-05 06:25:34 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-05 06:25:34 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-05 06:25:34 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-05 06:27:50 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /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 --- 2003-11-05 07:25:41 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Nov 5 07:25:41 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/txp/if_txp.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/vx/if_vx.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/vx/if_vx_pci.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/wi/if_wi.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica
SYSENTER in FreeBSD
I noticed that Jeff Roberson implement this already. Is whi will be commit? http://kerneltrap.org/node/view/1531 I google this because I found this feature is listed in the list of Kernel Improvement of WindowsXP. :-) Thanks, Jun Su ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld failure: don't know how to make thr_atfork.c
The problem was solved. See cvs-all mailing list. thr_atfork.c was forgotten to be committed. Just run cvsup again. Florian --- Alex Wilkinson [EMAIL PROTECTED] a écrit : CVSup'd today [Wed Nov 5 17:15:14 CST 2003] and buildworld fails. $ make buildworld . === lib/libpcap yacc -d -p pcapyy -o grammar.c /usr/src/lib/libpcap/../../contrib/libpcap/grammar.y ln -sf grammar.h tokdefs.h lex -t -Ppcapyy /usr/src/lib/libpcap/../../contrib/libpcap/scanner.l scanner.c sed 's/.*/char pcap_version[] = ;/' /usr/src/lib/libpcap/../../contrib/libpcap/VERSION version.c rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -Dyylval=pcapyylval -I/usr/src/lib/libpcap -I. -DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap grammar.c /usr/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /usr/src/lib/libpcap/../../contrib/libpcap/pcap.c /usr/src/lib/libpcap/../../contrib/libpcap/inet.c /usr/src/lib/libpcap/../../contrib/libpcap/gencode.c /usr/src/lib/libpcap/../../contrib/libpcap/optimize.c /usr/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c /usr/src/lib/libpcap/../../contrib/libpcap/etherent.c /usr/src/lib/libpcap/../../contrib/libpcap/savefile.c /usr/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c /usr/src/lib/libpcap/../../contrib/libpcap/bpf_image.c /usr/src/lib/libpcap/../../contrib/libpcap/bpf_dump.c scanner.c version.c === lib/libpthread make: don't know how to make thr_atfork.c. Stop *** Error code 2 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new interrupt code: panic when going multiuser
On Tue, 4 Nov 2003, John Baldwin wrote: On 04-Nov-2003 Bruce Evans wrote: - on a BP6, UP kernels without apic work except for cyintr(), but SMP kernels have problems with missing interrupts for ata devices and hang at boot time. Is this related to the ata-lowlevel commit you mentioned above? No. It looks like the interrupt is really going missing for some reason. This is without any acpica. What if you try a UP kernel with 'device apic' (i.e. no options SMP), do you still have ata problems? Is this on an SMP machine btw? Yes, 'device apic' breaks the UP case in the same way that the new interrupt code breaks the SMP case. BP6's are SMP and mine used to mostly work, though not well enough to actually be worth using in SMP mode (it works faster in UP mode with its slowest CPU overclocked 42%; mismatched CPUs and thermal problems prevent significant overclocking in SMP mode). Other bugs in the new interrupt code that I've noticed so far: - lots of pessimizations. The main one is that the PIC is now masked and unmasked for fast interrupt handlers. The masking should be done at a higher level for all interrupt handlers so that it doesn't need to be undone in some cases, and neither masking not unmasking should be done for fast interrupt handlers. This pessimization and other makes fast interrupt handlers more non-fast than before. They are now slower than normal interrupt handlers in FreeBSD-[1-4]. They still have lower latency that normal interrupt handlers in FreeBSD-[1-4], but not as low as actual fast interrupt handlers. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SYSENTER in FreeBSD
Jun Su wrote: I noticed that Jeff Roberson implement this already. Is whi will be commit? http://kerneltrap.org/node/view/1531 I google this because I found this feature is listed in the list of Kernel Improvement of WindowsXP. :-) Thanks, Jun Su I have almost done this experiment about 10 months ago. http://people.freebsd.org/~davidxu/fastsyscall/ The patch is out of date and still not complete. Also it can give you some performance improve, but I think too many things need to be changed, and this really makes user ret code very dirty, some syscalls, for example, pipe() can not use this fast syscall, becaues pipe() seems using two registers to return file handle, the performance gain is immediately lost when the assemble code becomes more complex. I don't think this hack is worth to do on IA32, I heard AMD has different way to support fast syscall, that may already in FreeBSD AMD 64 branch. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
cant compile GENERIC kernel from today source
Hi, I just cvsuped and when I do make buildkernel I get this: cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wst rict -prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -ffo rmat -extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/con trib /dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath - I/us r/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -in clud e pt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-alig n -long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/ dev/xe/if_xe.c /usr/src/sys/dev/xe/if_xe.c:1832: warning: `xe_reg_dump' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. pilkishome# ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on ia64/ia64
TB --- 2003-11-05 07:29:09 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-05 07:29:09 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-05 07:29:09 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-05 07:32:05 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /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 --- 2003-11-05 08:40:23 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Nov 5 08:40:23 GMT 2003 Kernel build for GENERIC completed on Wed Nov 5 08:56:33 GMT 2003 TB --- 2003-11-05 08:56:33 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-05 08:56:33 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Nov 5 08:56:33 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/vx/if_vx_eisa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/vx/if_vx_pci.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/wds/wd7000.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Tue, 4 Nov 2003 22:10:36 -0500 (EST), Jeff Roberson [EMAIL PROTECTED] wrote: On Wed, 5 Nov 2003, Eirik Oeverby wrote: Eirik Oeverby wrote: Just for those interested: I do *not* get any messages at all from the kernel (or elsewhere) when my mouse goes haywire. And it's an absolute truth (just tested back and forth 8 times) that it *only* happens with SCHED_ULE and *only* with old versions (~1.50) and the very latest ones (1.75 as I'm currently running). 1.69 for instance did *not* show any such problems. I will, however, update my kernel again now, to get the latest sched_ule.c (if any changes have been made since 1.75) and to test with the new interrupt handler. I have a suspicion it might be a combination of SCHED_ULE and some signal/message/interrupt handling causing messages to get lost along the way. Because that's exactly how it feels... Whee. Either the bump from sched_ule.c 1.75 to 1.77 changed something back to the old status, or the new interrupt handling has had some major influence. All I can say is - wow. My system is now more responsive than ever, I cannot (so far) reproduce any mouse jerkiness or bogus input or anything, and things seem smoother. As always I cannot guarantee that this report is not influenced by the placebo effect, but I do feel that it's a very real improvement. The fact that I can start VMWare, Firebird, Thunderbird, Gaim and gkrellm at the same time without having *one* mouse hickup speaks for itself. I couldn't even do that with ULE. So Jeff or whoever did the interrupt stuff - what did you do? This is wonderful news. I fixed a few bugs over the last couple of days. I'm not sure which one caused your problem. I'm very pleased to hear your report though. This SCHED_ULE (1.78) rocks! I don't get any mouse lag anymore in the 'cd /usr/src ; make clean ; make cleandir' and the beginner of 'portupgrade -ra'. I did the hard test; I have Gnome2, Opera 7 (linux version), several gvim, several gnome-terminal tabs, pan and even use totem to watch a movie (700mb) in full screen mode ;-).. While watching the movie and it doesn't get lag that much only while unpack the large tarballs like mozilla. While the build and clean, it only has very very little lag like one to two time(s) but the rest are pretty smooth. The mouse doesn't get any lag at all. Just let you know my experience with SCHED_ULE so far. In the command line, I can tell that I can 'feel' it's faster but I don't know about the real time (ie: benchmark). It's better than SCHED_4BSD because I will get mouse lag if I do the same thing as above with SCHED_4BSD. BTW: I don't use KSE because of Nvidia driver. Cheers, Mezz Cheers, Jeff /Eirik Greetings, /Eirik Morten Johansen wrote: On Tue, 4 Nov 2003, Sheldon Hearn wrote: On (2003/11/04 09:29), Eirik Oeverby wrote: The problem is two parts: The mouse tends to 'lock up' for brief moments when the system is under load, in particular during heavy UI operations or when doing compile jobs and such. The second part of the problem is related, and is manifested by the mouse actually making movements I never asked it to make. Wow, I just assumed it was a local problem. I'm also seeing unrequested mouse movement, as if the signals from movements are repeated or amplified. The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. Me too. Have had this problem since I got a Intellimouse PS/2 wheel-mouse. (It worked fine with previous mice (no wheel)). With any scheduler in 5-CURRENT and even more frequent in 4-STABLE, IIRC. Using moused or not doesn't make a difference. Get these messages on console: psmintr: out of sync, and the mouse freezes then goes wild for a few seconds. Can happen under load and sometimes when closing Mozilla (not often). It could be related to the psm-driver. Or maybe I have a bad mouse, I don't know. I will try another mouse, but it does work perfectly in Linux and Windogs... mj -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On (2003/11/04 15:46), Jeff Roberson wrote: The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. How long have you been seeing this? Are you using a usb mouse? Can you try with PS/2 if you are? Since my last update, Fri Oct 24 17:47:22. I am using a USB mouse, but don't have a PS/2 one. I'm also using moused, and my WM is sawfish. The problem with all these reports is that they're scattered. It's hard to pin down exactly what the common elements are. Indeed, we may be looking at combinations of elements. I don't have time to be more helpful, which is why I hadn't complained. I just wanted to include the datapoint that over-active mouse behaviour under load exists under SCHED_4BSD as well. Incidentally, this is under ATA disk load. I don't really push my CPU. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SYSENTER in FreeBSD
On Wed, 5 Nov 2003, David Xu wrote: Jun Su wrote: I noticed that Jeff Roberson implement this already. Is whi will be commit? http://kerneltrap.org/node/view/1531 I google this because I found this feature is listed in the list of Kernel Improvement of WindowsXP. :-) Thanks, Jun Su I have almost done this experiment about 10 months ago. http://people.freebsd.org/~davidxu/fastsyscall/ The patch is out of date and still not complete. Also it can give you some performance improve, but I think too many things need to be changed, and this really makes user ret code very dirty, some syscalls, for example, pipe() can not use this fast syscall, becaues pipe() seems using two registers to return file handle, the performance gain is immediately lost when the assemble code becomes more complex. I don't think this hack is worth to do on IA32, I heard AMD has different way to support fast syscall, that may already in FreeBSD AMD 64 branch. This works with every syscall. I have a patch in perforce that doesn't require any changes to userret(). The performance gain is not so substantial for most things but I feel that it is worth it. Mini is probably going to finish this up over the next week or so. Cheers, Jeff David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for WINE on -CURRENT
Hello!
On Wed, Nov 05, 2003 at 05:50:35AM +0100, Simon Barner wrote:
can you make a patch for cdparanoia as well?
cdparanoia is also broken on recent -CURRENT and testing will be easy.
There is already a PR. I will rewise my patch to use __FreeBSD__ in the
patch file instead of using ${EXTRA_PATCHES}.
do you mean __FreeBSD_version?
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/57226
please revise the patch and submit follow-up.
This one here should be closed IMHO since there is a cleaner solution
that backing out the change.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/58461
/fjoe
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-11-05 09:04:50 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-05 09:04:50 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-11-05 09:04:50 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-05 09:07:21 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /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 --- 2003-11-05 10:01:44 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Nov 5 10:01:45 GMT 2003 Kernel build for GENERIC completed on Wed Nov 5 10:10:58 GMT 2003 TB --- 2003-11-05 10:10:58 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-05 10:10:59 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Nov 5 10:10:59 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/utopia/utopia.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vx/if_vx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/vx/if_vx_pci.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin
Re: More ULE bugs fixed.
Sheldon Hearn wrote: On (2003/11/04 15:46), Jeff Roberson wrote: The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. How long have you been seeing this? Are you using a usb mouse? Can you try with PS/2 if you are? Since my last update, Fri Oct 24 17:47:22. I am using a USB mouse, but don't have a PS/2 one. I'm also using moused, and my WM is sawfish. The problem with all these reports is that they're scattered. It's hard to pin down exactly what the common elements are. Indeed, we may be looking at combinations of elements. I don't have time to be more helpful, which is why I hadn't complained. I just wanted to include the datapoint that over-active mouse behaviour under load exists under SCHED_4BSD as well. Incidentally, this is under ATA disk load. I don't really push my CPU. Though I am not a hardcore C programmer, much less a FreeBSD contributor in any way, I do have some experience in tracking down problems like this. Used to have a lot of them on some of the more obscure platforms I've been using in the past. My feeling is (and it might be completely wrong ofcourse) that we are dealing with atleast two completely separate issues here. The first has to do with mouse jerkiness, the second has to do with bogus mouse events. There is a significant difference between these two, and personally I am leaning towards concluding that the first has to do with the scheduler, and the second has to do with something entirely different - interrupt handler or something else of the sorts. The first is simply that the mouse stops for a brief moment and then continues from the point where it stopped. Perhaps this is the situation that is remedied by bypassing moused? Is moused perhaps not getting the CPU cycles it needs to process and pass on mouse messages? The second is that mouse messages are actually *lost*, or bogus ones are being generated. I guess it's the first, making moused or X misinterpret the messages it gets. Where along the chain it fails I obviously have no clue. The consequence of this is that when the mouse stops (like in #1) but then resumes from an entirely different point - be it 10 pixels away or at the other end of the screen - possibly even generating a button push (but not necessarily the corresponding button release) message. These two situations could at first sight be mistaken for being the same symptom, but I am pretty sure they are very different. One may influence the other, or they may by coincidence (or for some good reason) happen at the same time, but I believe the errors happen in different parts of the kernel. When you say you get the bogus mouse events (which I believe you are saying atleast ;) only during load, I'm immediately thinking that yes, that might make sense. But I guess that's better left to those who are in the know to decide ;) I have never seen it happen with the 4BSD scheduler, but that might have other reasons (hardware?). Why don't you try with the new interrupt handler? Helped me quite a lot.. :) /Eirik Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cant compile GENERIC kernel from today source
On Wed, Nov 05, 2003 at 11:02:02AM +0200, Putinas wrote: Hi, I just cvsuped and when I do make buildkernel I get this: Yeah, my bad :-( It's been fixed - cvsup again and all should be well. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with D-Link DWL-AG650 card under CURRENT (11/4-03)
Hi, I am running the newest version of CURRENT and have some problems with panic when I insert a D-Link DWL-AG650 (atheros) wireless card. FreeBSD pilt.xxx.xx 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Wed Nov 5 12:12:35 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 When I insert the card the OS identifies the card as a 3Com card. I have tried several changes on the GENERIC, but without luck. cardbus1: Resource not specified in CIS: id=10, size=80 cardbus1: Resource not specified in CIS: id=14, size=80 xl1: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xf4002000-0xf400207f irq 11 at device 0.0 on cardbus1 Fatal trap 19: non-maskable interrupt trap while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0x078154a stack pointer = 0x10:0xde057ba8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 7 (cbb1) kernel: type 19 trap, code = 0 Stopped at xl_eeprom_wait+0x3a:movzwl %ax,%eax The onboard NIC is a 3Com 3c905C-TX Fast Etherlink XL. According to the doc the card is supported in current, and later in 5.2. You have to compile with device ath and device ath_hal The OS panic with or without the device-setting for ath and ath_hal. Do you now way the card is identified as a 3Com card insted of a D-Link??? Regards - Erik - -- Erik Haga E-mail: [EMAIL PROTECTED] Mnemonic AS http://mnemonic.no Waldemar Thranesgt. 77 0175 Oslo, Norway +47 22 99 97 00 Fax: +47 22 99 97 01 +47 915 88 606 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On Wed, 5 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB On Tue, 4 Nov 2003, Harti Brandt wrote: HBJB HBJB HBOn Tue, 4 Nov 2003, John Baldwin wrote: HBJB HB HBJB HBJB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB HBJB HBJB Hi, HBJB HBJB HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB HBJB file has HBJB HBJB HBJB HBJB options SMP HBJB HBJB device apic HBJB HBJB options HZ=1000 HBJB HBJB HBJB HBJBOk, I can try to reproduce. HBJB HBJB HBJB HBJB Device configuration finished. HBJB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB HBJB Timecounters cpuid = 0; apic id = 00 HBJB HBJB instruction pointer = 0x8:0xc048995d HBJB HBJB stack pointer = 0x10:0xc0821bf4 HBJB HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB HBJB cpu_critical_exit. HBJB HBJB HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJB HBJBIt might be helpful to figure what type of fault you are actually getting. HBJB HB HBJB HBtf_err is 0, tf_trapno is 30 (decimal). HBJB HBJB More information: HBJB HBJB I have replaced all the reserved vectors with individual ones, that set HBJB tf_err to the index (vector number). It appears the the vector number is HBJB 39 decimal. What does that mean? HBJB HBJBIRQ 7. HBJBCan you post a verbose dmesg? Also, can you try both with and without HBJBACPI? HB HBAttached are both dmesgs. HB HBMore datapoints: HB HBI had the parallel port (irq7) and the second sio disabled in the BIOS. HBAfter enabling both I now get a panic in lapic_handle_intr: Couldn't get HBvector from ISR! After fetching the relevant docs from intel I checked the HBregisters of the apic pointed to by lapic. The interrupt taken is HBXapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How HBmay that happen? As I understand ISR are the interrupts that have been HBdelivered to the CPU so if it is interrupted a bit should be set, correct? HB HBI then have replaced the panic by a printf() followed by a return. Now the HBsystem comes to live, but I get a couple of these warnings. When the HBsystem is idle everyting seems fine, but when I start my simulation HBapplication (which normally generates between 20k and 250k interrupts/sec HBdepending on the MPSAFE setting of the ATM drivers) I get approx 1-2 of HBthese messages per second (this is with HZ=1000). HB HBA question while reading the code: what does the global lapic variable HBrefer to? As I understand every CPU has its local APIC. Does it point to HBone of those two? To which? An additional point. In the above test where I got 1-2 message per second I have now disabled a debugging printout in the ATM driver that gave 3-4 messages per second (from the interrupt handler). Now the 'Couldn't get...' messages have disappeared. So this really looks like a race somewhere. Is it possible that the bit in the ISR gets somehow cleared between the point where the interrupt is handed to the processor but before the Xapic_irq1 really runs and sees that bit? Perhaps from another Xapic_irq1 instance or whatever? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PRs for dagrab and cdparanoia reworked (was: Re: Fix for WINE on -CURRENT)
please revise the patch and submit follow-up. Done. Tested on both -STABLE and -CURRENT. I am progress of doing the same for dagrab (expect a follow-up to PR 57227 soon). Simon signature.asc Description: Digital signature
Re: New interrupt stuff breaks ASUS 2 CPU system
Another data point: I can't get my Asus A7M266-D to boot with the new interrupt code at all, perhaps because I have an Adaptec 39160. Whether acpi is on or off, whether it's in the kernel config or not, booting always hangs right after waiting 10 sec for scsi to settle and 0 scb's aborted. I've also tried it with 0,1 or 2 of the ide controllers enabled, with no change in result. Sometimes I get a spurious interrupt from ata1 message, sometimes not. Kernel from 10/27 works fine. Kernels from last couple of days fail. dmesg, config available on request, if wanted. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PRs for dagrab and cdparanoia reworked (was: Re: Fix for WINE on -CURRENT)
Hello!
On Wed, Nov 05, 2003 at 02:10:02PM +0100, Simon Barner wrote:
please revise the patch and submit follow-up.
Done. Tested on both -STABLE and -CURRENT.
I am progress of doing the same for dagrab (expect a follow-up to PR
57227 soon).
There is no need for extra-patches.
#ifdef CDIOCREADAUDIO seems to be sufficient enough.
Is using CDRIOCSETBLOCKSIZE necessary as well?
If yes it shouold be done in enable_cdda callback I think.
Moreover, is there a reason we should use CDIOCREADAUDIO on RELENG_4?
Please test attached patch. works for me on RELENG_4 and should work
on -CURRENT as well.
/fjoe
Index: Makefile
===
RCS file: /home/pcvs/ports/audio/cdparanoia/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile14 Jul 2003 02:52:55 - 1.8
+++ Makefile5 Nov 2003 14:05:27 -
@@ -7,7 +7,7 @@
PORTNAME= cdparanoia
PORTVERSION= 3.9.8
-PORTREVISION= 5
+PORTREVISION= 6
CATEGORIES=audio sysutils
MASTER_SITES= http://www.xiph.org/paranoia/download/
DISTNAME= ${PORTNAME}-${PORTVERSION:C/^3\./III-alpha/}
Index: files/patch-interface-cooked_interface.c
===
RCS file: /home/pcvs/ports/audio/cdparanoia/files/patch-interface-cooked_interface.c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-interface-cooked_interface.c
--- files/patch-interface-cooked_interface.c11 Jan 2003 09:15:00 - 1.2
+++ files/patch-interface-cooked_interface.c5 Nov 2003 14:38:09 -
@@ -1,11 +1,5 @@
-Index: interface/cooked_interface.c
-===
-RCS file: /home/cvs/cdparanoia/interface/cooked_interface.c,v
-retrieving revision 1.1.1.1
-retrieving revision 1.8
-diff -u -r1.1.1.1 -r1.8
interface/cooked_interface.c 2003/01/05 09:46:26 1.1.1.1
-+++ interface/cooked_interface.c 2003/01/11 08:58:45 1.8
+--- interface/cooked_interface.c.orig Thu Apr 20 05:41:04 2000
interface/cooked_interface.c Wed Nov 5 20:37:44 2003
@@ -1,6 +1,8 @@
/**
* CopyPolicy: GNU Public License 2 applies
@@ -23,7 +17,7 @@ diff -u -r1.1.1.1 -r1.8
static int cooked_readtoc (cdrom_drive *d){
int i;
int tracks;
-@@ -129,6 +132,128 @@
+@@ -129,6 +132,120 @@
return(sectors);
}
@@ -96,18 +90,10 @@ diff -u -r1.1.1.1 -r1.8
+cooked_read(cdrom_drive *d, void *p, long begin, long sectors)
+{
+ int retry_count = 0;
-+ struct ioc_read_audio arg;
-+
-+ if (sectors d-nsectors)
-+ sectors = d-nsectors;
-+
-+ arg.address_format = CD_LBA_FORMAT;
-+ arg.address.lba = begin;
-+ arg.buffer = p;
++ int bsize = CD_FRAMESIZE_RAW;
+
+ for (;;) {
-+ arg.nframes = sectors;
-+ if (ioctl(d-ioctl_fd, CDIOCREADAUDIO, arg) == -1) {
++ if (pread(d-ioctl_fd, p, sectors*bsize, begin*bsize) !=
sectors*bsize) {
+ if (!d-error_retry)
+ return -7;
+
@@ -152,7 +138,7 @@ diff -u -r1.1.1.1 -r1.8
/* hook */
static int Dummy (cdrom_drive *d,int Switch){
return(0);
-@@ -193,6 +318,7 @@
+@@ -193,6 +310,7 @@
int cooked_init_drive (cdrom_drive *d){
int ret;
@@ -160,7 +146,7 @@ diff -u -r1.1.1.1 -r1.8
switch(d-drive_type){
case MATSUSHITA_CDROM_MAJOR:/* sbpcd 1 */
case MATSUSHITA_CDROM2_MAJOR: /* sbpcd 2 */
-@@ -243,6 +369,9 @@
+@@ -243,6 +361,9 @@
default:
d-nsectors=40;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PRs for dagrab and cdparanoia reworked
Simon Barner wrote: please revise the patch and submit follow-up. Done. Tested on both -STABLE and -CURRENT. I am progress of doing the same for dagrab (expect a follow-up to PR 57227 soon). FWIW, the mplayer port also cannot play CDDA anymore on current. It probably needs a similar patch. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: More ULE bugs fixed.
On Wed, 5 Nov 2003, Sheldon Hearn wrote: On (2003/11/04 15:46), Jeff Roberson wrote: The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. How long have you been seeing this? Are you using a usb mouse? Can you try with PS/2 if you are? Since my last update, Fri Oct 24 17:47:22. I am using a USB mouse, but don't have a PS/2 one. I'm also using moused, and my WM is sawfish. The problem with all these reports is that they're scattered. It's hard to pin down exactly what the common elements are. Indeed, we may be looking at combinations of elements. I don't have time to be more helpful, which is why I hadn't complained. I just wanted to include the datapoint that over-active mouse behaviour under load exists under SCHED_4BSD as well. Incidentally, this is under ATA disk load. I don't really push my CPU. There's been some speculation that the PS/2 mouse problem could be due to high interrupt latency for non-fast interrupt handlers (especially ones not MPSAFE) in 5.x. I think it would make a lot of sense for us to push Giant off both the PS/2 mouse and syscons interrupt handlers in the near future. For syscons, this would also improve the reliability of dropping into the debugger from a non-serial console. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for WINE on -CURRENT
On Mon, 3 Nov 2003, Scot W. Hetzel wrote: Below is a patch to fix WINE for the new ATA driver. Thanks! (I kind of fixed it temporarily by removing the offending code, but clearly your approach is preferrable.) Could someone familar with the new ATA driver have a look at this patch to make sure it is correct. Once we have some positive confirmation, would you mind submitting a slightly adjusted version (against Wine CVS, that is, basically on top of my current patch in FreeBSD CVS, not instead that = the patch to [EMAIL PROTECTED] (Cc:ing) me)? Just, do we really need to check for the FreeBSD version? I had understood that simply reading from the device should work on 4.x, old 5.x, and -CURRENT. Søren, Kris? Gerald -- Gerald Pfeifer (Jerry) [EMAIL PROTECTED] http://www.pfeifer.com/gerald/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
DVD burning under 5.0
Bill, I found your post online when I was doing a search for burning DVD's using FreeBSD. We are about to configure an Athlon 2500 box, to use FreeBSD to act as our web, client and FTP server. We are going to need the ability to burn DVD's and so I am doing research on the topic. Have you have had any success burning DVD's using FreeBSD? Any information you can share, or web sites you might point us too? We're looking for all we can find. Thanks! Cheers, Dave -- Dave Bowers Technology Director Sparkplug Interactive www.sparkplug.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR (ffs_snapshot.c:651 vm_map.c:2258).
Hello. lock order reversal 1st 0xc66a6db0 vnode interlock (vnode interlock) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:651 2nd 0xc0c2f110 system map (system map) @ /usr/src/sys/vm/vm_map.c:2258 Stack backtrace: backtrace(c05bbfcb,c0c2f110,c05c650b,c05c650b,c05c6581) at backtrace+0x17 witness_lock(c0c2f110,8,c05c6581,8d2,c0c2f0b0) at witness_lock+0x686 _mtx_lock_flags(c0c2f110,0,c05c6581,8d2,c6aee000) at _mtx_lock_flags+0xb5 _vm_map_lock(c0c2f0b0,c05c6581,8d2,c69e61b0,0) at _vm_map_lock+0x36 vm_map_remove(c0c2f0b0,c6aee000,c6af,e1b1a7f0,c0555f99) at vm_map_remove+0x30 kmem_free(c0c2f0b0,c6aee000,2000,e1b1a80c,c05579f9) at kmem_free+0x32 page_free(c6aee000,2000,22,c060c4b8,c05e9100) at page_free+0x3a uma_large_free(c69e61b0,e1b1a83c,c0487f64,c66a6db0,2000) at uma_large_free+0xf9 free(c6aee000,c05e9100,c05c3358,28b,c25aff00) at free+0xe9 ffs_snapshot(c6522600,80c39a0,70,c04b5d36,c060d3e0) at ffs_snapshot+0x23f4 ffs_mount(c6522600,c69c4380,bfbffcc0,e1b1abf0,c6496720) at ffs_mount+0x617 vfs_mount(c6496720,c258ecd0,c69c4380,1211000,bfbffcc0) at vfs_mount+0x7d1 mount(c6496720,e1b1ad14,c05cd44e,3ee,4) at mount+0xba syscall(2f,2f,2f,0,bfbffdc0) at syscall+0x28f Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (21), eip = 0x80557bb, esp = 0xbfbffb6c, ebp = 0xbfbffd48 --- -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Wed, 2003-11-05 at 17:04, Jeremy Messenger wrote: I don't get any mouse lag anymore in the 'cd /usr/src ; make clean ; make cleandir' and the beginner of 'portupgrade -ra'. I did the hard test; I have Gnome2, Opera 7 (linux version), several gvim, several gnome-terminal tabs, pan and even use totem to watch a movie (700mb) in full screen mode ;-).. While watching the movie and it doesn't get lag that much only while unpack the large tarballs like mozilla. While the build and clean, it only has very very little lag like one to two time(s) but the rest are pretty smooth. The mouse doesn't get any lag at all. Yup.. Latest SCHED_ULE commit did it for me. My system now is fast and responsive. I ran similar tests, and everything ran quite smoothly with Gnome Desktop environment. Quite drastic change, system was practically unusable before this with SCHED_ULE. However, under higher CPU usage (90%+) and load (2) the mouse starts to feel sluggish. While still responsive enough to use, it still slows down enough to be noticeable. psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 Dual Pentium III Intel 440BX BTW: I don't use KSE because of Nvidia driver. Confirmed. It now works just fine (so far) with KSE. signature.asc Description: This is a digitally signed message part
Re: if_tun failed to register
On Tuesday 04 November 2003 15:32, Antoine Jacoutot wrote: Matteo Riondato wrote: Well, it did not change anything :( What is really strange is that tun is compiled in the kernel, but the module is started anyway ??? I had the same problem last year and solved it by removing device tun from the kernel configuration file. Yes, I though about it. But still, it is a strange bug and I cannot believe I (well, and you :) ) am the only one seeing this. It's been there for quite a while, I see that behaviour in 5.1-RELEASE, too. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
CARP (Common Address Redundancy Protocol)
You might be aware that OpenBSD has introduced a 2-clause BSD-licensed high availability and load balancing protocol called CARP: http://marc.theaimsgroup.com/?l=openbsd-miscm=106642790513590w=2 http://www.deadly.org/article.php3?sid=20031018101733 I have a working patchset to bring CARP to FreeBSD-Current and would like to hear you opinon: http://pf4freebsd.love2party.net/carp.html CARP shows itself as virtual interfaces carpX and works a bit like vlan interfaces. For comunication between the servers which share a common address it uses a multicast group. It supports both IPv4 and IPv6 common addresses and should work on ETHERNET, FDDI and TOKENRING nets - later two untested, though. Standing problems: - IPv4: * Server can't access the common address while MASTER for it. OpenBSD has a workaround for this, but we can't add host routes with virtual interfaces as gateway, so we need another fix. - IPv6: * Traffic to the common address on the server is always threated locally, even when in BACKUP state. * in6_ifattach() will error out - this seems to have no ill effects and can easily be fixed by selecting a special if_type for CARP interfaces. - Locking?!? - You tell me! Tests: Very basic tests for IPv4 and IPv6 performed with OpenBSD as a known good peer. I have very limited test environment at the moment. Code: http://pf4freebsd.love2party.net/carp.diff Perforce: branch mlaier_carp -- Best regards, Max Laiermailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On Wed, Nov 05, 2003 at 11:28:50AM +0100 I heard the voice of Eirik Oeverby, and lo! it spake thus: The second is that mouse messages are actually *lost*, or bogus ones are being generated. I guess it's the first, making moused or X misinterpret the messages it gets. Where along the chain it fails I obviously have no clue. The consequence of this is that when the mouse stops (like in #1) but then resumes from an entirely different point - be it 10 pixels away or at the other end of the screen - possibly even generating a button push (but not necessarily the corresponding button release) message. Note that I've had this to a greater or lesser extent for as long as I can remember (certainly back to 3.0-CURRENT). It corresponds with syslog'd messages on my xconsole along the lines of: Nov 3 12:46:13 mortis kernel: psmintr: out of sync (00c0 != ). Nov 3 12:46:13 mortis kernel: psmintr: discard a byte (12). It's certainly a lot more common (by orders of magnitude) on 5.x in the past... oh, I dunno, year-ish, than it was previously. I lose mouse function for maybe a second, then it squirms itself off somewhere on the screen and sends some button press events. I'm currently running 5.1-R, the traditional scheduler, a PS/2 mouse with no moused. And since I got them (much more rarely) with earlier 5-CURRENT's, and with 4-CURRENT's, etc, I can't see how it's scheduler related. When you say you get the bogus mouse events (which I believe you are saying atleast ;) only during load, I'm immediately thinking that yes, that might make sense. I don't get it only under load; sometimes from flat idle. However, it's usually when I first move the mouse, after it sitting still for a while (where 'while' can vary from a few seconds to a few days, of course); it hardly ever happens in mid-move. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PRs for dagrab and cdparanoia reworked (was: Re: Fix for WINE on -CURRENT)
I am progress of doing the same for dagrab (expect a follow-up to PR 57227 soon). There is no need for extra-patches. #ifdef CDIOCREADAUDIO seems to be sufficient enough. The version in GNATs is obsoleted, but my update did not make it there, although it appeared in freebsd-ports-bugs@ (I used the follow-up email-link in the GNATs web interface). I will prepare and test a version that used pread() like yours this night. It will be here then: http://home.leo.org/~barner/freebsd/dagrab-pread.patch Is using CDRIOCSETBLOCKSIZE necessary as well? If yes it shouold be done in enable_cdda callback I think. I don't now. I don't know how to interpret Soren's comments in http://freebsd.rambler.ru/bsdmail/freebsd-current_2003/msg15989.html regarding our situation: The right way of doing audio graps has been to set the wanted blocksize with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of the same size), then just read from the device. Ioctl's was newer meant to be used to read/write data, its also faster to use the R/W path... Can we assue that all tracks on an audio CD are of the same (block) size? What about those mixed-mode CDs (sorry, I don't know the specifications). Moreover, is there a reason we should use CDIOCREADAUDIO on RELENG_4? Please test attached patch. works for me on RELENG_4 and should work on -CURRENT as well. Yep, it works fine for me on 4.9-STABLE and 5.1-CURRENT (and complies with Soren's posting). I think the best solution would be to patch all applications to use this approach. The only question is whether we need CDRIOCSETBLOCKSIZE. Simon signature.asc Description: Digital signature
Re: More ULE bugs fixed.
Matthew D. Fuller wrote: On Wed, Nov 05, 2003 at 11:28:50AM +0100 I heard the voice of Eirik Oeverby, and lo! it spake thus: The second is that mouse messages are actually *lost*, or bogus ones are being generated. I guess it's the first, making moused or X misinterpret the messages it gets. Where along the chain it fails I obviously have no clue. The consequence of this is that when the mouse stops (like in #1) but then resumes from an entirely different point - be it 10 pixels away or at the other end of the screen - possibly even generating a button push (but not necessarily the corresponding button release) message. Note that I've had this to a greater or lesser extent for as long as I can remember (certainly back to 3.0-CURRENT). It corresponds with syslog'd messages on my xconsole along the lines of: Nov 3 12:46:13 mortis kernel: psmintr: out of sync (00c0 != ). Nov 3 12:46:13 mortis kernel: psmintr: discard a byte (12). It's certainly a lot more common (by orders of magnitude) on 5.x in the past... oh, I dunno, year-ish, than it was previously. I lose mouse function for maybe a second, then it squirms itself off somewhere on the screen and sends some button press events. I'm currently running 5.1-R, the traditional scheduler, a PS/2 mouse with no moused. And since I got them (much more rarely) with earlier 5-CURRENT's, and with 4-CURRENT's, etc, I can't see how it's scheduler related. No idea, but I never got messages like the ones you mention, and it has absolutely never happened on 4.x or with SCHED_4BSD. Weirdness. :) /Eirik When you say you get the bogus mouse events (which I believe you are saying atleast ;) only during load, I'm immediately thinking that yes, that might make sense. I don't get it only under load; sometimes from flat idle. However, it's usually when I first move the mouse, after it sitting still for a while (where 'while' can vary from a few seconds to a few days, of course); it hardly ever happens in mid-move. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Nov 4 kernel broke my 115200 console.. and fix.
My machine was hard-locking with a kernel built from yesterday. With boot -s, it freezes before you can hit return for the shell. This is a fairly generic PIII machine with ATA hdd. Booting with a keyboard and video attached works wonderfully, but is a pain in the ass with a machine that's supposed to be headless. This was working fine on the serial console before the interrupt and APIC_IO commits. It guess (*) I needed these in the kernel config, by adding options SMP deviceapic deviceacpi into my config it now boots up via serial console. *NOTE: I didn't think I had to bother with the note in UPDATING before since IO_APIC was commented out in my previous kernel config and acpi had been disabled. just a FYI for anyone else who might be lurking/searching the current list with the same problem. -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
new interrupt code? fwohci0 running wild
Hi, just made and installed today's world, and while the system boots, performance is sluggish. This is likely due to irq16/fwohci0, which seems to run wild: [EMAIL PROTECTED]: /] uptime vmstat -i 11:21AM up 9 mins, 3 users, load averages: 0.54, 0.71, 0.43 interrupt total rate irq6: fdc0 4 0 irq8: rtc 72244127 irq13: npx01 0 irq14: ata0 1868 3 irq15: ata1 97 0 irq16: fwohci0 50191801 88835 irq17: em1 24890 44 irq18: pcm0 25 0 irq19: uhci0 bktr0 4551 8 irq20: mpt0 46 0 irq21: em0 mpt1 8003 14 irq0: clk 56443 99 Total 50359973 89132 Nothing is plugged into the firewire port, if that matters. The machine is an SMP box, dmesg and pciconf output are attached. Please let me know what other information I can provide. Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute [EMAIL PROTECTED]:0:0: class=0x06 card=0x00d81028 chip=0x25318086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82860 (860) CPU to I/O Hub Bridge (Interface A)' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x25328086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '82850/850E/860 AGP Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:2:0: class=0x060400 card=0x chip=0x25338086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '82860 (860) PCI Bridge (Hub Interface B)' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:30:0: class=0x060400 card=0x chip=0x244e8086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/EB/ER (ICH2/3/4/5/5R) Hub Interface to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:31:0: class=0x060100 card=0x chip=0x24408086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA (ICH2) LPC Interface Controller' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:31:1: class=0x010180 card=0x00d81028 chip=0x244b8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA (ICH2) UltraATA/100 IDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:31:2: class=0x0c0300 card=0x00d81028 chip=0x24428086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) USB Universal Host Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:31:3: class=0x0c0500 card=0x00d81028 chip=0x24438086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) SMBus Controller' class= serial bus subclass = SMBus [EMAIL PROTECTED]:31:4: class=0x0c0300 card=0x00d81028 chip=0x24448086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) USB Universal Host Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:0:0: class=0x03 card=0x7176174b chip=0x49661002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies' device = 'RV250 Radeon 9000/9000 Pro' class= display subclass = VGA [EMAIL PROTECTED]:0:1: class=0x038000 card=0x7177174b chip=0x496e1002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies' device = 'RV250 Radeon 9000/9000 Pro - Secondary' class= display [EMAIL PROTECTED]:31:0: class=0x060400 card=0x chip=0x13608086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82806AA Hub Interface to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:0: class=0x080020 card=0x11618086 chip=0x11618086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82806AA PCI64 Hub Advanced Programmable Interrupt Controller' class= base peripheral subclass = interrupt controller [EMAIL PROTECTED]:12:0: class=0x01 card=0x10401028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:12:1: class=0x01 card=0x10401028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:13:0: class=0x02 card=0x10038086 chip=0x10018086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82543GC PRO/1000 F Gigabit Ethernet Adapter (Fiber)' class
Re: if_tun failed to register
On Wednesday 05 November 2003 18:37, you wrote: It's been there for quite a while, I see that behaviour in 5.1-RELEASE, too. Thanks, I'm happy I'm not the only one seeing this :) It looks like ppp does not get compiled in the kernel either... :( Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI related panic
I'm getting a kernel panic on the dell inspiron 5150 (3.06 ghz cpu without HT, latest bios + some patches to fix utallocate errors) I'm not sure if this is related to the latest barrage of commits that John just did, becuase i didn't have this machine running before then. This bug is reproducable: every time i unplug my ac adapter, it panic's. If i boot without the ac adapter plugged in, it panics. If i boot with acpi disabled, it works fine. my kernel config is GENERIC. I've rebuilt as of about 1pm EST today. I'm attaching my dmesg from booting without acpi, and boot -v with acpi here is the panic, followed by the trace instruction pointer= 0x8:0xc0770865 stack pointer= 0x10:0xe0418d04 frame pointer= 0x10:0xe0418d04 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process= 11(idle) kernel: type 30 trap, code = 0 Stopped at cpu_idle_default+0x5:leave. trace is cpu_idle_default(e0418d1c,c05f814d,c05f8120,c29bfb58,e0418d34) at cpu_idle_default+0x5 cpu_idle(c05f18120,c29bfb58,e0418d34,c05f7f78,0) at cpu_idle+0x1f idle_proc(0,e0418d48,0,c05f8120,0) at idle_proc+0x2d fork_exit(c05f8120,0,e0418d48) at fork_exit+0x90 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe0418d7c, ebp = 0 --- seth Copyright (c) 1992-2003 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 5.1-CURRENT #1: Wed Nov 5 14:44:11 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CWM Preloaded elf kernel /boot/kernel/kernel at 0xc09dc000. Preloaded acpi_dsdt /boot/acpi_dsdt.aml at 0xc09dc244. Calibrating clock(s) ... i8254 clock: 1193215 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3056498296 Hz CPU: Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz (3056.50-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 1073541120 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c26000 - 0x3eda9fff, 1041776640 bytes (254340 pages) avail memory = 1033379840 (985 MB) ACPI APIC Table: DELL CPi R APIC: CPU 0 has ACPI ID 0 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xcf1e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: MADT: Found IO APIC ID 1, Vector 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0: intpin 0 - ExtINT ioapic0: intpin 1 - irq 1 ioapic0: intpin 2 - irq 2 ioapic0: intpin 3 - irq 3 ioapic0: intpin 4 - irq 4 ioapic0: intpin 5 - irq 5 ioapic0: intpin 6 - irq 6 ioapic0: intpin 7 - irq 7 ioapic0: intpin 8 - irq 8 ioapic0: intpin 9 - irq 9 ioapic0: intpin 10 - irq 10 ioapic0: intpin 11 - irq 11 ioapic0: intpin 12 - irq 12 ioapic0: intpin 13 - irq 13 ioapic0: intpin 14 - irq 14 ioapic0: intpin 15 - irq 15 ioapic0: intpin 16 - irq 16 ioapic0: intpin 17 - irq 17 ioapic0: intpin 18 - irq 18 ioapic0: intpin 19 - irq 19 ioapic0: intpin 20 - irq 20 ioapic0: intpin 21 - irq 21 ioapic0: intpin 22 - irq 22 ioapic0: intpin 23 - irq 23 MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: active-hi lapic0: Routing NMI - LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-hi MADT: Ignoring local NMI routed to ACPI CPU 1 ioapic0 Version 2.0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00050014 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff wlan: 802.11 Link Layer null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled ath_hal: Atheros Hardware Access Layerversion 0.9.5.17 ACPI: DSDT was overridden. ACPI-0375: *** Info: Table [DSDT] replaced by host OS acpi0: DELL CPi R on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=35808086) pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fcb30 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded0 29A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded0 29B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded0 29
Testing new sched_ule + apic -- reverting to old stable system
Hi, i want to test the new sources and have already cvsuped. If i make a make world and after reboot there are problems, how do i switch back to the older sources for compiling again the now running system ? (I mean not only booting the kernel.old but world, too. That is a general question) Maybe that is the wrong mailing list for ask such things, sorry. bye, Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng regression: cdcontrol close not working
Bruce Evans wrote: On Thu, 30 Oct 2003, Soren Schmidt wrote: Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the close case, does it work then ? Problem is that the call to read toc might fail early, but its worth a shot.. I tried this, but it didn't change anything. (See my mail from last week.) I was mistaken in thinking that my patch fixed this. It only works for 1 drive, as does at acd^H^Htapi-cd.c rev.1.148. Is there any other patch I can try? I've just confirmed that this bug still exists with today's kernel. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
the PS/2 mouse problem
Robert Watson wrote:
There's been some speculation that the PS/2 mouse problem could be due to
high interrupt latency for non-fast interrupt handlers (especially ones
not MPSAFE) in 5.x. I think it would make a lot of sense for us to push
Giant off both the PS/2 mouse and syscons interrupt handlers in the near
future. For syscons, this would also improve the reliability of dropping
into the debugger from a non-serial console.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
Hi,
I tried pushing Giant out of psm a while ago, a patch is attached.
It did not help, but probably eases contention on Giant a bit.
psm gets a lot of interrupts.
I am still seeing occasional weirdness from the mouse.
It freezes then goes berserk (moving and triggering events) for a few
seconds.
The kernel says:
psmintr: delay too long; resetting byte count
(I was wrong about the message in a previous mail)
This actually happens more often in -stable than in -current.
moused or not does not make a difference.
The latest SCHED_ULE and interrupt changes, have not fixed this problem.
Otherwise, FreeBSD 5-current is the best OS I have ever run.
Morten Johansen
--- psm-0.c Wed Nov 5 19:30:09 2003
+++ psm.c Wed Nov 5 20:23:41 2003
@@ -129,6 +129,11 @@ __FBSDID($FreeBSD: src/sys/isa/psm.c,v
#define PSM_NBLOCKIO(dev) (minor(dev) 1)
#define PSM_MKMINOR(unit,block)(((unit) 1) | ((block) ? 0:1))
+#define PSM_MTX_INIT(_sc, name) mtx_init(_sc-psm_mtx, name, NULL, MTX_DEF)
+#define PSM_MTX_DESTROY(_sc)mtx_destroy(_sc-psm_mtx)
+#define PSM_LOCK(_sc) mtx_lock((_sc)-psm_mtx)
+#define PSM_UNLOCK(_sc) mtx_unlock((_sc)-psm_mtx)
+
/* ring buffer */
typedef struct ringbuf {
int count; /* # of valid elements in the buffer */
@@ -160,9 +165,10 @@ struct psm_softc { /* Driver status inf
int syncerrors;
struct timeval inputtimeout;
int watchdog; /* watchdog timer flag */
-struct callout_handle callout; /* watchdog timer call out */
+struct callout callout;/* watchdog timer call out */
dev_tdev;
dev_tbdev;
+struct mtx psm_mtx;
};
static devclass_t psm_devclass;
#define PSM_SOFTC(unit)((struct psm_softc*)devclass_get_softc(psm_devclass,
unit))
@@ -250,6 +256,7 @@ static int doinitialize(struct psm_softc
static int doopen(struct psm_softc *, int);
static int reinitialize(struct psm_softc *, int);
static char *model_name(int);
+static void _psmintr(void *);
static void psmintr(void *);
static void psmtimeout(void *);
@@ -769,7 +776,7 @@ doopen(struct psm_softc *sc, int command
/* start the watchdog timer */
sc-watchdog = FALSE;
-sc-callout = timeout(psmtimeout, (void *)(uintptr_t)sc, hz*2);
+callout_reset(sc-callout, hz*2, psmtimeout, (void *)(uintptr_t)sc);
return (0);
}
@@ -779,17 +786,16 @@ reinitialize(struct psm_softc *sc, int d
{
int err;
int c;
-int s;
/* don't let anybody mess with the aux device */
if (!kbdc_lock(sc-kbdc, TRUE))
return (EIO);
-s = spltty();
+PSM_LOCK(sc);
/* block our watchdog timer */
sc-watchdog = FALSE;
-untimeout(psmtimeout, (void *)(uintptr_t)sc, sc-callout);
-callout_handle_init(sc-callout);
+callout_stop(sc-callout);
+callout_init(sc-callout, CALLOUT_MPSAFE);
/* save the current controller command byte */
empty_both_buffers(sc-kbdc, 10);
@@ -804,7 +810,7 @@ reinitialize(struct psm_softc *sc, int d
KBD_DISABLE_KBD_PORT | KBD_DISABLE_KBD_INT
| KBD_ENABLE_AUX_PORT | KBD_DISABLE_AUX_INT)) {
/* CONTROLLER ERROR */
- splx(s);
+ PSM_UNLOCK(sc);
kbdc_lock(sc-kbdc, FALSE);
log(LOG_ERR, psm%d: unable to set the command byte (reinitialize).\n,
sc-unit);
@@ -834,7 +840,7 @@ reinitialize(struct psm_softc *sc, int d
err = ENXIO;
}
}
-splx(s);
+PSM_UNLOCK(sc);
/* restore the driver state */
if ((sc-state PSM_OPEN) (err == 0)) {
@@ -1225,9 +1231,10 @@ psmattach(device_t dev)
if (sc == NULL)/* shouldn't happen */
return (ENXIO);
+PSM_MTX_INIT(sc, device_get_nameunit(dev));
/* Setup initial state */
sc-state = PSM_VALID;
-callout_handle_init(sc-callout);
+callout_init(sc-callout, CALLOUT_MPSAFE);
/* Setup our interrupt handler */
rid = KBDC_RID_AUX;
@@ -1235,7 +1242,7 @@ psmattach(device_t dev)
RF_SHAREABLE | RF_ACTIVE);
if (sc-intr == NULL)
return (ENXIO);
-error = bus_setup_intr(dev, sc-intr, INTR_TYPE_TTY, psmintr, sc, sc-ih);
+error = bus_setup_intr(dev, sc-intr, INTR_TYPE_TTY | INTR_MPSAFE, psmintr, sc,
sc-ih);
if (error) {
bus_release_resource(dev, SYS_RES_IRQ, rid, sc-intr);
return (error);
@@
Re: ATAng regression: cdcontrol close not working
It seems Lars Eggert wrote: Bruce Evans wrote: On Thu, 30 Oct 2003, Soren Schmidt wrote: Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the close case, does it work then ? Problem is that the call to read toc might fail early, but its worth a shot.. I tried this, but it didn't change anything. (See my mail from last week.) Then I'm out of tricks since the close command fails then... I was mistaken in thinking that my patch fixed this. It only works for 1 drive, as does at acd^H^Htapi-cd.c rev.1.148. Is there any other patch I can try? I've just confirmed that this bug still exists with today's kernel. I cant reproduce the no matter what I try, sorry... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: Is there any other patch I can try? I've just confirmed that this bug still exists with today's kernel. I cant reproduce the no matter what I try, sorry... Would remote access to the machine in question help you? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
System hangs with ATAng
I suspect that I have a system losing interrupts from the disk. I get fairly random lock-ups where the system totally freezes and the disk access LED is on continuously until I power cycle the system. It's an IBM T30 with an IBM 40 GB disk. The only thing I have noticed is that the lock-ups only seem to occur when both ATA busses are in use. Unfortunately, it may simply be that DVD and disk activity at the same time simply are stressing the system a bit more. The DVD is using the ATAPICAM device. DMA is enabled on both the disk and the DVD. APM is in use. No ACPI. Kernel was built on Oct. 31. (Maybe it's haunted. :-) ) I have DDB in the kernel, but not WITNESS or INVARIANTS. APM is in use. No ACPI. I will attach my kernel config file and dmesg. Any suggestions on how to proceed would be appreciated. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Copyright (c) 1992-2003 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 5.1-CURRENT #46: Fri Oct 31 10:51:08 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBM-T30-D Preloaded elf kernel /boot/kernel/kernel at 0xc0823000. Preloaded userconfig_script /boot/kernel.conf at 0xc0823278. Preloaded elf module /boot/kernel/apm.ko at 0xc08232c8. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz (1798.48-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536281088 (511 MB) avail memory = 511197184 (487 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00fdeb0 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:29 INTA BIOS irq 11 pci_cfgintr: 0:29 INTB BIOS irq 11 pci_cfgintr: 0:29 INTC BIOS irq 11 pci_cfgintr: 0:31 INTB BIOS irq 11 pci_cfgintr: 0:31 INTB BIOS irq 11 pci_cfgintr: 0:31 INTB BIOS irq 11 agp0: Intel 82845 host to AGP bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci_cfgintr: 1:0 INTA BIOS irq 11 pci1: display, VGA at device 0.0 (no driver attached) uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 11 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2 uhub1: 4 ports with 4 removable, self powered uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 usb1: Intel 82801CA/CAM (ICH3) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f irq 11 at device 29.2 on pci0 usb2: Intel 82801CA/CAM (ICH3) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pcib2: PCIBIOS PCI-PCI bridge at device 30.0 on pci0 pci2: PCI bus on pcib2 pci_cfgintr: 2:0 INTA BIOS irq 11 pci_cfgintr: 2:0 INTB BIOS irq 11 pci_cfgintr: 2:2 INTA BIOS irq 11 pci_cfgintr: 2:8 INTA BIOS irq 11 cbb0: TI1520 PCI-CardBus Bridge mem 0x5000-0x5fff irq 11 at device 0.0 on pci2 start (5000) sc-membase (d020) start (5000) sc-pmembase (f000) cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb0: [MPSAFE] cbb1: TI1520 PCI-CardBus Bridge mem 0x5100-0x51000fff irq 11 at device 0.1 on pci2 start (5100) sc-membase (d020) start (5100) sc-pmembase (f000) cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 cbb1: [MPSAFE] pci2: network at device 2.0 (no driver attached) fxp0: Intel 82801CAM (ICH3) Pro/100 VE Ethernet port 0x8000-0x803f mem 0xd020-0xd0200fff irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:09:6b:50:36:29 miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: [MPSAFE] isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH3 UDMA100 controller port 0x1860-0x186f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170
Re: if_tun failed to register
On Wed, Nov 05, 2003 at 08:52:20PM +0100, Antoine Jacoutot wrote: On Wednesday 05 November 2003 18:37, you wrote: It's been there for quite a while, I see that behaviour in 5.1-RELEASE, too. Thanks, I'm happy I'm not the only one seeing this :) It looks like ppp does not get compiled in the kernel either... :( ppp(4) is in GENERIC. You just have to create the devices like: ifconfig ppp0 create -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
sysinstall issues (was Re: Toshiba Portege R100: 5.1-JPSNAP install CD hangs)
Takayama Fumihiko wrote: booting a Toshiba Portege R100 off Wednesday's 5.1-JPSNAP install CD hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. I've also attached the 4.9 dmesg - 4.9 boots fine off its install CD - in case that helps. Any ideas? R100 has problem with PnP for FreeBSD. My Toshiba Portege R100 on FreeBSD 5.1-RELEASE can boot by below process. 1) enter BIOS setup (booting with press ESC) 2) [Device Config] change to All Devices from Setup by OS Thank you very much, Fumihiko-san, that solved the booting problem! However, I was still unable to install 5.1-JPSNAP on the machine. With the BIOS settings you suggested, I managed to get to sysinstall. After specifying the desired install setting, sysinstall refuses to install, claiming it did not detect a CD/DVD drive? The drive in question is detected during boot as: umass0: NewAge International STORIX Optical Series, rev 2.00/0.01 (see http://www.isi.edu/larse/misc/DSC00909.JPG) Can sysinstall not install off of USB drives? To circumvent this issue, I copied the install CD contents onto a local FTP server, and tried a network install. After contacting the server and formatting the partition, sysinstall panic'ed died with an ffs panic. A snapshot of the traceback is here: http://www.isi.edu/larse/misc/DSC00908.JPG Any ideas on how to pull -current onto this laptop, other then installing -stable and compiling from scratch? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: System hangs with ATAng
I hate following up my own post, but I manages to get some significant information. The console (previously inaccessible after the crash) was on screen for the last event and I get the the following: FAILURE - malloc ATA request failed cannot allocate ATAPI/CAM request (cd0:ata1:0:0:0): out of memory, freezing queue. FAILURE - malloc ATA request failed ad0: FAILURE - out of memory in start (These two lines repeat 15 times) panic: kmem_malloc(4096): kmem_map too small: 216326144 total allocated Debuggger(panic) Stopped at Debugger+0x54: xchgl%ebx,in_Debugger.0 So it looks like in need to tune my kernel a bit. Will this work? options VM_KMEM_SIZE_SCALE=4 options VM_KMEM_SIZE_MAX=(1024*1024*1024) options KVA_PAGES=512 I found these suggested in a prior thread, but I am uncertain if the values are even close to appropriate to my system (no PAE, UP, 384 MB RAM). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun failed to register
On Wednesday 05 November 2003 20:52, Antoine Jacoutot wrote: On Wednesday 05 November 2003 18:37, you wrote: It's been there for quite a while, I see that behaviour in 5.1-RELEASE, too. Thanks, I'm happy I'm not the only one seeing this :) It looks like ppp does not get compiled in the kernel either... :( FWIW, tun _is_ in the kernel if you compile it in, but gets loaded a second time. The module which gets loaded isn't actually used. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: if_tun failed to register
On Wed, 05 Nov 2003 18:37 Michael Nottebrock wrote: On Tuesday 04 November 2003 15:32, Antoine Jacoutot wrote: Matteo Riondato wrote: Well, it did not change anything :( What is really strange is that tun is compiled in the kernel, but the module is started anyway ??? I had the same problem last year and solved it by removing device tun from the kernel configuration file. Yes, I though about it. But still, it is a strange bug and I cannot believe I (well, and you :) ) am the only one seeing this. It's been there for quite a while, I see that behaviour in 5.1-RELEASE, too. =2D-=20 ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org This looks like the opposite of a problem on STABLE. On CURRENT ifconfig checks for 'tun' in the kernel when you do e.g. 'ifconfig tun0' [1], but the driver is registered as 'if_tun'. At the moment I don't have any 5-* boxes, so I can't check this for sure, but it looks like ifconfig will be run at startup if you have any ifconfig_tun* lines in rc.conf. You can see if ifconfig is the culprit by booting single-user and doing ifconfig tun0 (it is only the first attempt that gives the error message in question). If so, the following (Untested!) patch would presumably fix it: Index: sys/net/if_tun.c === RCS file: /home/ncvs/src/sys/net/if_tun.c,v retrieving revision 1.129 diff -u -r1.129 if_tun.c --- sys/net/if_tun.c 31 Oct 2003 18:32:08 - 1.129 +++ sys/net/if_tun.c 5 Nov 2003 21:59:10 - @@ -200,7 +200,7 @@ 0 }; -DECLARE_MODULE(if_tun, tun_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); +DECLARE_MODULE(tun, tun_mod, SI_SUB_PSEUDO, SI_ORDER_ANY); static void tunstart(struct ifnet *ifp) === A similar change would likely work for if_ppp.c. Assuming I am right about this (hah :) a pr would seem to be in order. Brian [1] Per this commit: mdodd 2003/04/14 23:25:58 PDT FreeBSD src repository Modified files: sbin/ifconfigifconfig.c Log: Don't abuse module names to facilitate ifconfig module loading; such abuse isn't really needed. (And if we do need type information associated with a module then we should make it explicit and not use hacks.) Revision ChangesPath 1.89 +1 -1 src/sbin/ifconfig/ifconfig.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun failed to register
On Wednesday 05 November 2003 22:47, Brooks Davis wrote: Thanks, I'm happy I'm not the only one seeing this :) It looks like ppp does not get compiled in the kernel either... :( ppp(4) is in GENERIC. You just have to create the devices like: No ! Although tun and ppp are in GENERIC, they get loaded as modules anyway under 5-CURRENT... at least under my box. This is so strange. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun failed to register
On Wednesday 05 November 2003 23:07, Michael Nottebrock wrote: FWIW, tun _is_ in the kernel if you compile it in, but gets loaded a second time. The module which gets loaded isn't actually used. Hum, strange... :) Do you know if the lastest -CURRENT fixes that ? Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New PNP0303 and aPic question
On 04-Nov-2003 Alex Wilkinson wrote: On Tue, Nov 04, 2003 at 12:56:07PM -0500, John Baldwin wrote: Yes. As long as you have 'device apic' in your kernel config, APICs will be used to route interrupts even on UP machines if the machine includes an MP Table or ACPI is being used and it contains an MADT. Reading thread and not following the acronyms. Ok 2 questions: 1. what is an MP Table ? It's a table included on SMP systems built by the BIOS that lists local APICs (CPUs) and I/O APICs as well as routing information about what interrupts (both ISA and PCI) are hooked up to which interrupt pins on each of the APICs. 2. What is MADT ? ACPI's stripped down version of the MP Table called a Multiple Apic Descriptor Table. It lists local APICs and IO APICs as well as nonstandard ISA interrupt routings. It does not include information about PCI interrupts. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: New interrupt stuff breaks ASUS 2 CPU system
On 05-Nov-2003 Harti Brandt wrote: On Tue, 4 Nov 2003, John Baldwin wrote: JB JBOn 04-Nov-2003 Harti Brandt wrote: JB On Tue, 4 Nov 2003, Harti Brandt wrote: JB JB HBOn Tue, 4 Nov 2003, John Baldwin wrote: JB HB JB HBJB JB HBJBOn 04-Nov-2003 Harti Brandt wrote: JB HBJB JB HBJB Hi, JB HBJB JB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB HBJB worked until yesterday, but with the new interrupt code it doesn't boot JB HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB HBJB fault. I suspect a race condition in the interrupt handling. My config JB HBJB file has JB HBJB JB HBJB options SMP JB HBJB device apic JB HBJB options HZ=1000 JB HBJB JB HBJBOk, I can try to reproduce. JB HBJB JB HBJB Device configuration finished. JB HBJB Timecounter TSC frequency 1380009492 Hz quality -100 JB HBJB Timecounters cpuid = 0; apic id = 00 JB HBJB instruction pointer = 0x8:0xc048995d JB HBJB stack pointer = 0x10:0xc0821bf4 JB HBJB frame pointercpuid = 0; apic id = 00 JB HBJB JB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from JB HBJB cpu_critical_exit. JB HBJB JB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. JB HBJBIt might be helpful to figure what type of fault you are actually getting. JB HB JB HBtf_err is 0, tf_trapno is 30 (decimal). JB JB More information: JB JB I have replaced all the reserved vectors with individual ones, that set JB tf_err to the index (vector number). It appears the the vector number is JB 39 decimal. What does that mean? JB JBIRQ 7. JBCan you post a verbose dmesg? Also, can you try both with and without JBACPI? Attached are both dmesgs. More datapoints: I had the parallel port (irq7) and the second sio disabled in the BIOS. After enabling both I now get a panic in lapic_handle_intr: Couldn't get vector from ISR! After fetching the relevant docs from intel I checked the registers of the apic pointed to by lapic. The interrupt taken is Xapic_irq1. isr1 is zero, but irr1 is 0x100 (that was without ACPI). How may that happen? As I understand ISR are the interrupts that have been delivered to the CPU so if it is interrupted a bit should be set, correct? I figured out what is happenning I think. You are getting a spurious interrupt from the 8259A PIC (which comes in on IRQ 7). The IRR register lists pending interrupts still waiting to be serviced. Try using 'options NO_MIXED_MODE' to stop using the 8259A's for the clock and see if the spurious IRQ 7 interrupts go away. A question while reading the code: what does the global lapic variable refer to? As I understand every CPU has its local APIC. Does it point to one of those two? To which? Every CPU can get to its APIC at the same physical address. Thus, CPU A can only get to its own local APIC, and not to any other CPUs. The 'lapic' variable has a virtual address mapped to the physical address of the local APIC. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: new interrupt code? fwohci0 running wild
On 05-Nov-2003 Lars Eggert wrote: Hi, just made and installed today's world, and while the system boots, performance is sluggish. This is likely due to irq16/fwohci0, which seems to run wild: [EMAIL PROTECTED]: /] uptime vmstat -i 11:21AM up 9 mins, 3 users, load averages: 0.54, 0.71, 0.43 interrupt total rate irq6: fdc0 4 0 irq8: rtc 72244127 irq13: npx01 0 irq14: ata0 1868 3 irq15: ata1 97 0 irq16: fwohci0 50191801 88835 irq17: em1 24890 44 irq18: pcm0 25 0 irq19: uhci0 bktr0 4551 8 irq20: mpt0 46 0 irq21: em0 mpt1 8003 14 irq0: clk 56443 99 Total 50359973 89132 Nothing is plugged into the firewire port, if that matters. The machine is an SMP box, dmesg and pciconf output are attached. Please let me know what other information I can provide. What happens if you kldunload the firewire driver? Also, what happens if you boot w/o it loaded in the first place? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun failed to register
On Wednesday 05 November 2003 23:25, Brian Lynn wrote: will be run at startup if you have any ifconfig_tun* lines in rc.conf. You can see if ifconfig is the culprit by booting single-user and doing ifconfig tun0 (it is only the first attempt that gives the error message in question). If so, the following (Untested!) patch would presumably But I don't have any ifconfig_tun* in rc.conf; although I do have the ppp_enable set on. Do you think I should try your patch anyway ? Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun failed to register
On Wed, Nov 05, 2003 at 11:32:03PM +0100, Antoine Jacoutot wrote: On Wednesday 05 November 2003 22:47, Brooks Davis wrote: Thanks, I'm happy I'm not the only one seeing this :) It looks like ppp does not get compiled in the kernel either... :( ppp(4) is in GENERIC. You just have to create the devices like: No ! Although tun and ppp are in GENERIC, they get loaded as modules anyway under 5-CURRENT... at least under my box. This is so strange. It looks like there's a bug or some sort in ifmaybeload() function in ifconfig since kldstat -v shows if_ppp and if_tun modules in the kernel. Should be a fairly easy fix. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
new interrupts not working for me
I have a Tyan S1832DL w/dual pii 350s and it's not able to boot. Seems to be having trouble with my adaptec scsi controller, I get a whole bunch of output like this hand transcribed bit, it comes after waiting 15 seconds for scsi devices to settle: ahc0 timeout SCB already complete interrupts may not be functioning Infinite interrupt loop INTSTAT=0(probe3:ahc0:0:3:0): SCB 0x6 - timed out Anyone else seeing this? There are probably 100+ related lines of output, I'll have to configure serial debugging if you need to see it. Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nov 4 kernel broke my 115200 console.. and fix.
On Wed, 5 Nov 2003, othermark wrote: My machine was hard-locking with a kernel built from yesterday. With boot -s, it freezes before you can hit return for the shell. This is a fairly generic PIII machine with ATA hdd. Booting with a keyboard and video attached works wonderfully, but is a pain in the ass with a machine that's supposed to be headless. This was working fine on the serial console before the interrupt and APIC_IO commits. It guess (*) I needed these in the kernel config, by adding options SMP deviceapic deviceacpi The key here is probably 'acpi'. It is no longer built as a module, and the loader has been fooled into not loading it. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new interrupts not working for me
- Original Message - From: Peter Schultz [EMAIL PROTECTED] Newsgroups: mailing.freebsd.current Sent: Thursday, November 06, 2003 12:55 AM Subject: new interrupts not working for me I have a Tyan S1832DL w/dual pii 350s and it's not able to boot. Seems to be having trouble with my adaptec scsi controller, I get a whole bunch of output like this hand transcribed bit, it comes after waiting 15 seconds for scsi devices to settle: I have -current kernel cvsupped and compiled Tuesday night - and it boots fine with my Tiger 100. I have SCHED_ULE enabled in my kernelconfig and ACPI is disabled. I have a bulk dualchannel Adaptec 2940, and the system boots fine from SCSI drive connected to it. -Reko ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: new interrupts not working for me
On 05-Nov-2003 Peter Schultz wrote: I have a Tyan S1832DL w/dual pii 350s and it's not able to boot. Seems to be having trouble with my adaptec scsi controller, I get a whole bunch of output like this hand transcribed bit, it comes after waiting 15 seconds for scsi devices to settle: ahc0 timeout SCB already complete interrupts may not be functioning Infinite interrupt loop INTSTAT=0(probe3:ahc0:0:3:0): SCB 0x6 - timed out Anyone else seeing this? There are probably 100+ related lines of output, I'll have to configure serial debugging if you need to see it. The dmesg output excluding all the ahc0 errors would help figure out why your interrupts aren't working. However, I just committed a patch that might fix your problem. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic on startup 11/4/03 JPSNAP install
I'm trying to install 5.1-CURRENT off the current JPSNAP ISO image onto my new IBM T40. On startup, I see a list of errors (EEPROM Checksum invalid) concerning the built-in em0 GigE. After showing the ata0 and ata1 devices it prints: Memory modified after free 0xc4b1b800(2044) val=c4b58110 @ 0xc4b1bb9c panic: Most recently used by bus-sc Any suggestions? For the crash of course and also for the em checksum issue Many thanks in advance, Jeff Katcher __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new interrupt code? fwohci0 running wild
John Baldwin wrote: What happens if you kldunload the firewire driver? Also, what happens if you boot w/o it loaded in the first place? kldunload does not make a difference, it still eats irqs. Not loading it in the first place works around the issue, and returns the machine's responsiveness back to normal. It's the workaround I'm using for now. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: sysinstall issues (was Re: Toshiba Portege R100: 5.1-JPSNAP install CD hangs)
Hi, booting a Toshiba Portege R100 off Wednesday's 5.1-JPSNAP install CD hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. R100 has problem with PnP for FreeBSD. My Toshiba Portege R100 on FreeBSD 5.1-RELEASE can boot by below process. 1) enter BIOS setup (booting with press ESC) 2) [Device Config] change to All Devices from Setup by OS Thank you very much, Fumihiko-san, that solved the booting problem! However, I was still unable to install 5.1-JPSNAP on the machine. With the BIOS settings you suggested, I managed to get to sysinstall. After specifying the desired install setting, sysinstall refuses to install, f claiming it did not detect a CD/DVD drive? The drive in question is detected during boot as: umass0: NewAge International STORIX Optical Series, rev 2.00/0.01 (see http://www.isi.edu/larse/misc/DSC00909.JPG) Can sysinstall not install off of USB drives? In my case using NOVAC CD-R/RW Station for USB, very very slow data transfer (maybe using USB 1.1 but 2.0), so I actually install FreeBSD from FTP. CD-ROM installing is impractical, though possible. (http://www.novac.co.jp/products/hardware/nv-station/nv-cr340u/index.html [this page is written by Japanese]) To circumvent this issue, I copied the install CD contents onto a local FTP server, and tried a network install. After contacting the server and formatting the partition, sysinstall panic'ed died with an ffs panic. A snapshot of the traceback is here: http://www.isi.edu/larse/misc/DSC00908.JPG Umm, I got this error by update install, not clean install. Any ideas on how to pull -current onto this laptop, other then installing -stable and compiling from scratch? 5.1-RELEASE installing first, then cvsup to -current is better, I think... (My laptop works fine by this step). Thanks. -- Takayama Fumihiko [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NetScroll+ Optical ps/2 mouse worked in 4.7 but not in 5.1
My Genius NetScroll+ PS/2 optical mouse was working fine in the console, and in KDE, with FreeBSD 4.7, but is working erratically in the newly installed FreeBSD 5.1 console, and on the new KDE 3.1 Desktop. During installation of 5.1, with port as /dev/psm0, protocol as 'auto', and while testing the mouse daemon, the pointer was initially difficult to see and then, with mouse movement, appeared as if delayed by about 3 seconds, but did seem to move to a reasonable position. After successful installation of 5.1, the mouse cursor behavior is the same as during the installation's test configuration, and it's behavior on the console is similar to its behavior in KDE 3.1. While moving, the pointer disappears, and then it re-appears when the mouse is stationary. It doesn't seem to copy or paste in the console, but left-clicking in KDE does seem to work, if I can position the cursor over a button, and right-clicking does work over the KDEE desktop. Thanks for any clues. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new interrupts not working for me
John Baldwin wrote: On 05-Nov-2003 Peter Schultz wrote: I have a Tyan S1832DL w/dual pii 350s and it's not able to boot. Seems to be having trouble with my adaptec scsi controller, I get a whole bunch of output like this hand transcribed bit, it comes after waiting 15 seconds for scsi devices to settle: ahc0 timeout SCB already complete interrupts may not be functioning Infinite interrupt loop INTSTAT=0(probe3:ahc0:0:3:0): SCB 0x6 - timed out Anyone else seeing this? There are probably 100+ related lines of output, I'll have to configure serial debugging if you need to see it. The dmesg output excluding all the ahc0 errors would help figure out why your interrupts aren't working. However, I just committed a patch that might fix your problem. Now the kernel just dies and the machine reboots right in the beginning when it's setting up the ACPI/APIC stuff. Of course, with ACPI off, there's no apparent problem with the kernel. Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PRs for dagrab and cdparanoia reworked
FWIW, the mplayer port also cannot play CDDA anymore on current. It probably needs a similar patch. This works for me with a patched version of cdparanoia, which makes sense, since mplayer is linked against libcdda_paranoia.so.0. You can get the patch here: http://home.leo.org/~barner/freebsd/cdparanoia-pread.patch When I run % mplayer cdda:// the CD is played. The following output of fstat makes me believe that that cdparanoia really uses the cooked interface of the ATA driver and not the ATAPICAM interface (although I don't know how that one translates its requests into ATA'ish ones). In short: It works for me with an ATAPI CD/RW drive. Simon signature.asc Description: Digital signature
Re: PRs for dagrab and cdparanoia reworked
Simon Barner wrote: FWIW, the mplayer port also cannot play CDDA anymore on current. It probably needs a similar patch. This works for me with a patched version of cdparanoia, which makes sense, since mplayer is linked against libcdda_paranoia.so.0. You can get the patch here: http://home.leo.org/~barner/freebsd/cdparanoia-pread.patch Great. I had not tracked the issue closely enough to find the dependency on cdparanoia. Everything will be fine then once that patch is in the ports tree. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: if_tun failed to register
On Wed, 5 Nov 2003, Brooks Davis wrote: On Wed, Nov 05, 2003 at 11:32:03PM +0100, Antoine Jacoutot wrote: On Wednesday 05 November 2003 22:47, Brooks Davis wrote: Thanks, I'm happy I'm not the only one seeing this :) It looks like ppp does not get compiled in the kernel either... :( ppp(4) is in GENERIC. You just have to create the devices like: No ! Although tun and ppp are in GENERIC, they get loaded as modules anyway under 5-CURRENT... at least under my box. This is so strange. It looks like there's a bug or some sort in ifmaybeload() function in ifconfig since kldstat -v shows if_ppp and if_tun modules in the kernel. Should be a fairly easy fix. Its probably the same bug that hit the ed driver. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_tun failed to register
On Wednesday 05 November 2003 23:47, Antoine Jacoutot wrote: On Wednesday 05 November 2003 23:25, Brian Lynn wrote: will be run at startup if you have any ifconfig_tun* lines in rc.conf. You can see if ifconfig is the culprit by booting single-user and doing ifconfig tun0 (it is only the first attempt that gives the error message in question). If so, the following (Untested!) patch would presumably But I don't have any ifconfig_tun* in rc.conf; although I do have the ppp_enable set on. ppp will bring up a tun interface. Btw, what I was trying to say earlier is that this all really isn't a problem. If you compile tun into the kernel, this is what will be used and if you don't, the autoloaded module will be used. This is probably the reason nobody bothered to fix this yet. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: the PS/2 mouse problem
One thought that I had was to make psmintr() be INTR_FAST. I need to stare at the code some more to fully understand it, but it looks like it wouldn't be all that hard to do. Basically just use the interrupt handler to pull all of the data out of the hardware and into a ring buffer in memory, and then a fast taskqueue to process that ring buffer. It would at least answer the question of whether the observed problems are due to ithread latency. And if done right, no locks would be needed in psmintr(). Scott On Wed, 5 Nov 2003, Morten Johansen wrote: Robert Watson wrote: There's been some speculation that the PS/2 mouse problem could be due to high interrupt latency for non-fast interrupt handlers (especially ones not MPSAFE) in 5.x. I think it would make a lot of sense for us to push Giant off both the PS/2 mouse and syscons interrupt handlers in the near future. For syscons, this would also improve the reliability of dropping into the debugger from a non-serial console. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Hi, I tried pushing Giant out of psm a while ago, a patch is attached. It did not help, but probably eases contention on Giant a bit. psm gets a lot of interrupts. I am still seeing occasional weirdness from the mouse. It freezes then goes berserk (moving and triggering events) for a few seconds. The kernel says: psmintr: delay too long; resetting byte count (I was wrong about the message in a previous mail) This actually happens more often in -stable than in -current. moused or not does not make a difference. The latest SCHED_ULE and interrupt changes, have not fixed this problem. Otherwise, FreeBSD 5-current is the best OS I have ever run. Morten Johansen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NetScroll+ ps/2 optical mouse fixed in FreeBSD 5.1
I fixed yesterday's mouse problem, sort of, by adding the line hint.acpi.0.disabled=1 to the file /boot/device.hints I'm not sure why that worked, but the problem apparently only affects the 5.x kernel with some VIA chipsets. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
build world build kernel correct order?
hello, newbe here. i've been having nightmares building my kernel and world on a clean system: System: P4 celeron 128M freebsd5.1 standard no fluff integrated motherboard. following the handbook Chapter 21, i am led to believe that the correct order for making world is as follows: reboot edit kernel cvsup standard-supfile ports-supfile mergemaster -p shutdown now make -j4 buildworld make buildkernel KERNCONF=SERVER3 make installkernel KERNCONF=SERVER3 reboot to single user mount drives and share make installworld reboot The following outlines the frustrations i'm having. buildworld fails in single user mode build in multi user: no problem. buildkernel fails in either mode at the same point in the build. (last logfile attached) i've tried to build GENERIC but this fails also i've tried to build with or without -j4 rerunning cvsup changes the spot that the build fails in. since formatting and reinstalling; i've installed X11, cvsup and portupgrade and after running cvsup run portupgrade with mergemaster - committing all changes. any help - even directions to a new manual would be greatly appreciated. truncated logfile server3# cd /usr/src[10`make buildkernel KERNCONF=SERVER3 -- Kernel build for SERVER3 started on Tue Nov 4 19:17:13 AST 2003 -- === SERVER3 mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/i386/conf; !-- SNIP -- cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vnode_if.c touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /usr/src/sys/conf/newvers.sh SERVER3 cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror vers.c linking kernel.debug udbp.o: In function `udbp_attach': /usr/src/sys/dev/usb/udbp.c:361: undefined reference to `ng_newtype' /usr/src/sys/dev/usb/udbp.c:367: undefined reference to `ng_make_node_common' /usr/src/sys/dev/usb/udbp.c:370: undefined reference to `ng_name_node' udbp.o: In function `udbp_attach': /usr/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /usr/src/sys/netgraph/netgraph.h:457: undefined reference to `ng_unref_node' /usr/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' udbp.o: In function `udbp_detach': /usr/src/sys/dev/usb/udbp.c:435: undefined reference to `ng_rmnode_self' udbp.o: In function `udbp_detach': /usr/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /usr/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /usr/src/sys/netgraph/netgraph.h:457: undefined reference to `ng_unref_node' udbp.o: In function `udbp_in_transfer_cb': /usr/src/sys/dev/usb/udbp.c:516: undefined reference to `ng_package_data' /usr/src/sys/dev/usb/udbp.c:516: undefined reference to `ng_address_hook' /usr/src/sys/dev/usb/udbp.c:516: undefined reference to `ng_snd_item' udbp.o: In function `ng_udbp_newhook': /usr/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /usr/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' udbp.o: In function `ng_udbp_rcvmsg': /usr/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' udbp.o: In function `ng_udbp_rcvmsg': /usr/src/sys/dev/usb/udbp.c:690: undefined reference to `M_NETGRAPH_MSG' /usr/src/sys/dev/usb/udbp.c:718: undefined reference to `ng_address_ID' /usr/src/sys/dev/usb/udbp.c:718: undefined reference to `ng_snd_item' udbp.o: In function `ng_udbp_rcvmsg': /usr/src/sys/netgraph/netgraph.h:689: undefined reference to `dumpitem' udbp.o: In function `ng_udbp_rcvmsg': /usr/src/sys/dev/usb/udbp.c:718: undefined reference to `ng_free_item' /usr/src/sys/dev/usb/udbp.c:719: undefined reference to `M_NETGRAPH_MSG' udbp.o: In function `ng_udbp_rcvdata': /usr/src/sys/netgraph/netgraph.h:177: undefined reference to `dumphook' /usr/src/sys/netgraph/netgraph.h:419: undefined reference to `dumpnode' /usr/src/sys/netgraph/netgraph.h:689: undefined reference to `dumpitem' udbp.o: In function
[buildkernel fail] -Werror if_xe.c:1832: warning: `xe_reg_dump' defined but not used
CVSup'd today [Thu Nov 6 15:09:02 CST 2003]. buildkernel fails on a warning. $ make buildkernel ... cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/wi/if_wi_pci.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/xe/if_xe.c /usr/src/sys/dev/xe/if_xe.c:1832: warning: `xe_reg_dump' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Regards - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [buildkernel fail] -Werror if_xe.c:1832: warning: `xe_reg_dump' defined but not used
On Wednesday 05 November 2003 08:40 pm, Alex Wilkinson wrote: CVSup'd today [Thu Nov 6 15:09:02 CST 2003]. buildkernel fails on a warning. $ make buildkernel ... cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/wi/if_wi_pci.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/xe/if_xe.c It did what you told it to do and died on a warning (Werror). Kent /usr/src/sys/dev/xe/if_xe.c:1832: warning: `xe_reg_dump' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Regards - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [buildkernel fail] -Werror if_xe.c:1832: warning: `xe_reg_dump' defined but not used
On Thu, Nov 06, 2003 at 03:10:49PM +1030, Alex Wilkinson wrote: CVSup'd today [Thu Nov 6 15:09:02 CST 2003]. buildkernel fails on a warning. Wasn't this fixed this morning? Kris pgp0.pgp Description: PGP signature
Re: drm, irqs, etc.
On Wed, 2003-11-05 at 21:24, Mike Hoskins wrote: first, i apologize... i didn't think i'd get real answers on -questions so i'm posting this here. i realize 5.x isn't really stable yet, but i hope it's close enough to be relevant. ;) i've got XFree86 4.3.0 installed, from the X-4 meta port. that went smoothly. using the mga driver with a matrox g450 (dual head). no dri on head 2 as expected, but again no obvious problems. what i've noticed (this is 5.1-p8) is that after X has been running for awhile, trying to exit X causes a hang. at first i thought it was some program under X not exiting properly (that's what it looks like), but i've reproduced the same behavior with nothing but X running. if i start X and then exit immediately, everything is fine. this seems to only happen after X runs for a week or more. the one thing i noticed, was some interesting behavior wrt drm and it's claimed IRQ. before starting X (after a reboot), `ps ax|grep irq` shows: 19 ?? WL 0:00.00 (irq9: pcm0 acpi0) 20 ?? WL 0:00.10 (irq14: ata0) 21 ?? WL 0:00.00 (irq15: ata1) 22 ?? WL 0:00.00 (irq10: fxp0) 23 ?? WL 0:00.00 (irq6: fdc0) 24 ?? WL 0:00.01 (irq1: atkbd0) the same from within X shows, 19 ?? WL 0:00.00 (irq9: pcm0 acpi0) 20 ?? WL 0:01.05 (irq14: ata0) 21 ?? WL 0:00.00 (irq15: ata1) 22 ?? WL 0:00.02 (irq10: fxp0) 23 ?? WL 0:00.00 (irq6: fdc0) 24 ?? WL 0:00.08 (irq1: atkbd0) 25 ?? WL 0:00.09 (irq12: psm0) 690 ?? WL 0:00.12 (irq11: drm0) and once exiting X (immediately, when it exits without hanging), 19 ?? WL 0:00.00 (irq9: pcm0 acpi0) 20 ?? WL 0:01.04 (irq14: ata0) 21 ?? WL 0:00.00 (irq15: ata1) 22 ?? WL 0:00.02 (irq10: fxp0) 23 ?? WL 0:00.00 (irq6: fdc0) 24 ?? WL 0:00.07 (irq1: atkbd0) 25 ?? WL 0:00.06 (irq12: psm0) 690 ?? WL 0:00.08 (irq11:) is irq11 not being freed? or is that normal behavior? i've double checked by X config, but i may have something wrong. i've read various web pages and XFree's suggestions about configuring the g450... but, again, i may have overlooked something. this is a hard hang... ctrl-alt-bkspc, ctrl-alt-del, etc. have no effect. i've since enabled NoTrapSignals in my X config hoping to get a core dump the next time it happens. if i can manage that, i'll include it in a future report. (or any other info you think is relevant.) please CC me directly with any replies, i am not currently subscribed to -stable. 5.1 is -current, not -stable, so you should be mailing the -current list. I've reset the cc: appropriately. If you're not using up to date -current, please upgrade to -current past October 24th, which included some DRM IRQ fixes. If the problem persists, could you check that it doesn't happen with the DRI disabled in your XF86Config? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [buildkernel fail] -Werror if_xe.c:1832: warning: `xe_reg_dump' defined but not used
On Thu, Nov 06, 2003 at 03:33:25PM +1030, Kris Kennaway wrote: On Thu, Nov 06, 2003 at 03:10:49PM +1030, Alex Wilkinson wrote: CVSup'd today [Thu Nov 6 15:09:02 CST 2003]. buildkernel fails on a warning. Wasn't this fixed this morning? Yes. I didn't realise until investigation that I was missing a CTM delta. All ok now. - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FYI: Scalability update
http://bulk.fefe.de/scalability/#newdata [Nov 1 2003] I got an email suggesting that I re-check NetBSD. The results are nothing short of astonishing. In two weeks time the NetBSD team made dramatic improvements. socket: previously O(n), now O(1). bind: greatly improved, but still O(n). Much less steep, though. fork: a modest O(n) for dynamically linked programs, O(1) for statically linked. mmap: a bad O(n) before, now O(1) with a small O(n) shadow. touch after mmap: a bad strange graph in 1.6.1, a modest O(n) a week ago, now O(1). http request latency: previously O(n), now O(1). Congratulations, NetBSD! NetBSD now has better scalability than FreeBSD. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NetScroll+ ps/2 optical mouse fixed in FreeBSD 5.1
--- Lee Hinkleman [EMAIL PROTECTED] wrote: I fixed yesterday's mouse problem, sort of, by adding the line hint.acpi.0.disabled=1 to the file /boot/device.hints I'm not sure why that worked, but the problem apparently only affects the 5.x kernel with some VIA chipsets. Is your BIOS an AWARD one? If so, you may try the patch in this PR i386/55473: Mouse broken on some AWARD BIOS with ACPI enabled Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS client mount options in CURRENT/5.1-
Hey all- Perusal of the man page for mount_nfs doesn't seem to shed any light here, so can someone tell me what is wrong with this mount command (namely half of the options)? mount -tnfs -orw,rsize=8196,wsize=8196,bg,hard,intr,async sol:/export /mnt nfs: -o rsize=: option not supported Likewise for wsize and hard, although documented in mount_nfs and traditionally available NFS options...any ideas? It will mount via removing the 'offending' options properly.. I don't need help on 'why are you doing this command line' etc- am just doing some throughput tests, but could use a sanity check on whats wrong with these options...? TIA, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Silbersack wrote: | Can you try updating to 5.1-current and see if the situation changes at | all? A lot has changed since 5.1-release. If it's still broken in | 5.1-current, we can take a look into it. | | Thanks, I tried today with yesterday's -CURRENT. Same symptoms. No kernel panic, just lockup. Brane -BEGIN PGP SIGNATURE- iD8DBQE/qViTfiC/E+t8hPcRAs5BAJ4po+J7FpIkPHtYjypSI1BeC3snugCfbfJa o7jO2699XTtnauPrjNxGOd8= =qdph -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
On Wed, 5 Nov 2003, [ISO-8859-1] Branko F. Grac(nar wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Silbersack wrote: | Can you try updating to 5.1-current and see if the situation changes at | all? A lot has changed since 5.1-release. If it's still broken in | 5.1-current, we can take a look into it. | | Thanks, I tried today with yesterday's -CURRENT. Same symptoms. No kernel panic, just lockup. Brane Ok, submit a PR with clear details on how to recreate the problem, and we'll see if someone can take a look into it. I'm too busy to look at it, but at least putting it in a PR will ensure that it doesn't get too lost. Once the PR is filed, you might want to try asking on the freebsd-threads list; it sounds like the issue might be thread-related. (Note that your original e-mail might contain enough detail, I'm not certain; I just skimmed it. Filing a good PR is important either way, mailing list messages get easily lost.) Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
