Re: ip_output panics on recent -CURRENT
On Mon, Nov 03, 2003 at 01:38:56PM -0800, Sam Leffler wrote: The problem appears to be caused by someone reclaming routing table entries while they are in use. This would likely be a reference counting problem. You didn't provide any information about system kernel config or hardware config. Both are important. Aye, I'm quite aware of that; I just wanted to probe whether you knew about it and whether more debugging on my part was necessary. Problem is, I'm tracking down some more problems at the moment, so time for FreeBSD activity is a bit scarce. I'll do what I can. You don't indicate when last sunday is; is that 11/02? Did you get my recent commit to in_rmx.c that was last night and fixed a reference counting problem (but which would probably not affect you)? Are you running with WITNESS and INVARIANT? If not, do so. Have you tried to identify something that makes the panic happen? (e.g. ping as opposed to using ssh, as opposed to NFS over UDP, etc.) Have you tried setting debug.mpsafenet=0? Sources where from 11/02 indeed, I'm attaching my kernel config. Relevant hardware is 1xPIII 192MB RAM, one ep (not used at time of panic) one wi. I'm not sure at all about in_rmx.c, but very possibly no (you didn't say when last night is ;-) joking, I saw in_rmx.c 1.48). Panics happened when I only had background traffic going on - which for my laptop means ntpd, the occasional fetchmail, postfix on localhost - not much more. Again, I'll try to restrict. I see now WITNESS and INVARIANT were off - oops, I forgot turning them off at times when -CURRENT was more stable to do performance tests. I'll get back to you when I have time to update to recent sources and get more data points. Bye, Andrea -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APM not working on Dell Latitude D600
On Mon, Nov 03, 2003 at 06:37:26PM +0100, Andreas Klemm wrote: Cc'd to Stijn [EMAIL PROTECTED]. Many thanks Stijn, for making that patch available! No problem, but I'd like it if you also thank Mark Santcroos for making that patch in the first place -- I'm just the messenger here... So now I can happily confirm that this procedure works for: - Dell Latitude D600 (BIOS Revision A06) Added, along with about a dozen other submissions in my queue. Thanks to all submitters for reporting! --Stijn -- Coca-Cola is solely responsible for ensuring that people - too stupid to know not to tip half-ton machines on themselves - are safe. Forget parenting - the blame is entirely on the corporation for designing machines that look so innocent and yet are so deadly. -- http://www.kuro5hin.org/?op=displaystory;sid=2001/10/28/212418/42 pgp0.pgp Description: PGP signature
Re: HEADSUP: Committing new interrupt code, tree will be broken
John Baldwin wrote: I'm committing the new i386 interrupt and SMP code, so buckle your seat belts. :) I'll be intentionally breaking the kernel build at the start and re-enable it with the last commit when I am done. Is this *only* for SMP systems, or will the interrupt code also affect UNIprocessor boxes (like my laptop)? I'm suspecting some interrupt loss here, so I might give this new code a spin around the block. /Eirik ___ [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.
Jeff Roberson wrote: On Mon, 3 Nov 2003, Eirik Oeverby wrote: Hi, Just recompiled yesterday, running sched_ule.c 1.75. It seems to have re-introduced the bogus mouse events I talked about earlier, after a period of having no problems with it. The change happened between 1.69 and 1.75, and there's also the occational glitch in keyboard input. How unfortunate, it seems to have fixed other problems. Can you describe the mouse problem? Is it jittery constantly or only under load? Or are you having other problems? Have you tried reverting to SCHED_4BSD? What window manager do you run? 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. It's almost as if messages passed from the mouse (PS/2 type) through the kernel are being corrupted or lost - moving the mouse slowly in one direction will suddenly make it jump half across the screen and continue. Also it will quite often produce bogus clicks and drags, i.e. I'll be moving the mouse across the screen and suddenly it grabs something and doesn't let go - as if it got a MouseRightDown event but no MouseRightRelease event (or whatever they are called in the world you are in - I'm coming from OS/2 and other obscure platforms ;). The second problem usually follows the first - it's more likely to happen when the system is under some kind of load. Heavy window repainting/updating (Mozilla Thunderbird is a prime example, but other apps can be just as guilty), compile jobs, VMWare going crazy with the CPU, heavy disk/network I/O .. Anything that places load on the system/kernel can cause this. Running with SCHED_4BSD completely solves these problems, and the bogus mouse event problems did NOT appear with sched_ule 1.69 (which is the last one I tried before 1.75). It did appear with ~1.50 and thereabouts though (as reported earlier in this thread). I'm currently running WindowMaker as window manager, but the problem also exists in Gnome and xfce4. Gnome is more likely to exhibit the problem even during low system loads, given that it's more violent UI-wise. You are right though, the later sched_ule revisions DO seem to be better in many other respects - overall performance 'feels' better (atleast in console mode). The mouse issues makes X kinda hard to use though. Btw you might be interested in knowing that the keyboard from time to time shows what I think is bogus input aswell - I have a consistently higher rate of failure when typing with sched_ule 1.75 than I had with 1.69, and it definitely feels as if keystrokes are getting lost or repeated when they shouldn't be. Not often, had two or three 'suspicious' typos while writing this message, and I am reluctant to say it's a definite kernel issue, because I'm nowhere near a perfect typist - but it is nevertheless worth noting and might even be worth looking into. Might there be a connection between this and the mouse issues? Thanks, /Eirik Thanks for the report. Cheers, Jeff If you need me to do anything to track this down, let me know. I am, and have always been, running with moused, on a uniprocessor box (ThinkPad T21 1ghz p3). Best regards, /Eirik Jeff Roberson wrote: On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote: Jeff Roberson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2003, Jeff Roberson wrote: On Thu, 30 Oct 2003, Bruce Evans wrote: Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with/usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys
Re: NULL td passed to propagate_priority() when using xmms...
On Mon, 3 Nov 2003, John Baldwin wrote:
On 01-Nov-2003 Soren Schmidt wrote:
It seems Sean Chittenden wrote:
Howdy. I'm not sure if this is a ULE bug or a KSE bug, or both, but,
for those interested (this is using ule 1.67, rebuilding world now),
here's my stack. I couldn't figure out where td was being set to
NULL. :( Oh! Where is TD_SET_LOCK defined? egrep -r didn't turn up
anything. -sc
Its not ULE, I'm running 4BSD and has gotten this on boot for over a
week now, rendering -current totally useless...
Having a kernel panic with INVARIANTS on would really help narrow down
where the bug is.
I found something that causes this bug fairly reliably:
- configure ddb so that db_print_backtrace() is called on panics.
- break the fd driver so that the panic() in fdstrategy() is called on
floppy accesses.
- attempt to access a floppy so that fdstrategy() is called.
- db_print_backtrace() then does bad things. It never completes here,
though it works in other contexts. Usually it prints only the first
line or two. Then quite often ddb is called for a null pointer panic
in propagate_priority().
More details about the null pointer panic: This seems to have nothing
to do with scheduling. propagate_priority() is not called with a null
td of course, but it sometimes follows a null m:
%%%
/*
* Pick up the mutex that td is blocked on.
*/
m = td-td_blocked;
MPASS(m != NULL);
/*
* Check if the thread needs to be moved up on
* the blocked chain
*/
if (td == TAILQ_FIRST(m-mtx_blocked)) {
continue;
}
%%%
I don't have invariants enabled, so MPASS(m != NULL) doesn't do anything,
but m is null so attempting to load m-mtx_blocked causes a panic.
For the backtrace context, propagate_priority() gets called for attempting
to aquire a lock in softclock(). Tasks like the softclock task get
scheduled despite the system being in panic(). ps seemed to show that the
user process doing the floppy access no longer existed. I don't know how
that could happen, since the panic() is done in the context of the that
process.
More details about bugs in db_print_backtrace(): Maybe the stack is
messed up. Attempting to access invalid stack offsets can cause
problems. My version of db_print_backtrace() has extra code to attempt
not to access invalid offsets, but there is normally no problem since
ddb's trap handler fixes up the problem. But backtrace() bogusly calls
db_print_backtrace() in non-ddb context and then the longjmp in the trap
handler goes to hyperspace if anywhere.
Bugs tripped over while debugging this: Putting a breakpoint in fdopen()
didn't work, because fd.c:fdopen() conflicts with kern_descrip.c:fdopen().
This was broken in fd.c 1.259. There are hundreds of similar conflicts
in GENERIC, some for obviously broken things like the same malloc type
being static in several files.
Bruce
___
[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/i386
TB --- 2003-11-04 07:40:27 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-04 07:40:27 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-04 07:40:27 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-04 07:42:16 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/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-04 08:43:49 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Nov 4 08:43:49 GMT 2003 Kernel build for GENERIC completed on Tue Nov 4 08:58:31 GMT 2003 TB --- 2003-11-04 08:58:31 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-11-04 08:58:32 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Nov 4 08:58:32 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 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/isa/gsc.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 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/isa/if_cx.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 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/isa/if_el.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 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd
if_tun failed to register
Hi :) I just migrated a 4.8 server to -CURRENT and I have one question. At boot time I get the following message: module_register: module if_tun already exists! Module if_tun failed to register: 17 can't re-use a leaf (if_tun_debug)! Then I can see a if_tun.ko in my loaded modules. What is this module ? I guess this has to do with the fact that I connect to the internet using ppp, but this module did not appear under 4.8. Is there a kernel option I missed ? I already have device tun in my kernel config file. Thanks in advance. -- Antoine Jacoutot [EMAIL PROTECTED] http://www.lphp.org PGP/GnuPG key: http://www.lphp.org/ressources/ajacoutot.asc ___ [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-04 09:10:17 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-04 09:10:17 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-11-04 09:10:17 - 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-04 09:12:53 - 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-04 10:10:43 - 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 Tue Nov 4 10:10:43 GMT 2003 [...] cc -O -pipe -nostdinc -I/usr/include -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm -o aicasm aicasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll cd /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC; MAKEOBJDIRPREFIX=/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98 MACHINE_ARCH=i386 MACHINE=pc98 CPUTYPE= GROFF_BIN_PATH=/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/bin GROFF_FONT_PATH=/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/share/tmac DESTDIR=/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386 _SHLIBDIRPREFIX=/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386 INSTALL=sh /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/tools/install.sh PATH=/home/des/tinderbox/CU! RRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/sbin:/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/bin:/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/games:/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/sbin:/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/bin:/home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /home/des/tinderbox/CURRENT/i386/pc98/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/make.i386/make KERNEL=kernel depend -DNO_MODULES_OBJ rm -f ./machine ; ln -s /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i386/include ./machine rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi /home/des/tinderbox/CURRENT/i386/pc98/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/make.i386/make _kernel-depend 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 -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/genassym.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/i386/i386/genassym.c:42:22: opt_apic.h: No such file or directory *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-11-04 10:11:08 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-04
new interrupt code: panic when going multiuser
Hi, I've yet to find out if I can get a good vmcore + backtrace, but I'm having a machine that panics when going from singleuser to multiuser on boot with a new kernel from today. The panicking process is 'idle', the trap number is 30, and it says unknown/reserved trap. More info is coming as soon as I get a good backtrace. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
xl0 watchdog timeout
After cvsup and make world, I could't use xl0 and kernel said kernel: xl0: watchdog timeout. # dmesg [snip] xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea 02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [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, Lukas Ertl wrote: I've yet to find out if I can get a good vmcore + backtrace, but I'm having a machine that panics when going from singleuser to multiuser on boot with a new kernel from today. The panicking process is 'idle', the trap number is 30, and it says unknown/reserved trap. More info is coming as soon as I get a good backtrace. I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [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, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0 watchdog timeout
On Tue, 4 Nov 2003, Shin-ichi Yoshimoto wrote: After cvsup and make world, I could't use xl0 and kernel said kernel: xl0: watchdog timeout. # dmesg [snip] xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea 02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I had this last week and two people convinced me to exchange my NIC . I haven't seen this anymore since. Regards, Uli. -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] +---+ |Peter Ulrich Kruppa| | Wuppertal | | Germany | +---+ ___ [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
Hello Antoine, Tuesday, November 4, 2003, 10:55:22 AM, you wrote: AJ I just migrated a 4.8 server to -CURRENT and I have one question. AJ At boot time I get the following message: AJ AJ module_register: module if_tun already exists! AJ Module if_tun failed to register: 17 AJ can't re-use a leaf (if_tun_debug)! AJ AJ Then I can see a if_tun.ko in my loaded modules. What is this AJ module ? I guess this has to do with the fact that I connect to AJ the internet using ppp, but this module did not appear under 4.8. AJ Is there a kernel option I missed ? I already have device tun in AJ my kernel config file. This might be due to missing/incomplete mergemaster after installworld? Try to remove your rc.d related stuff from etc before running mergemaster -i. The scripts should not try to kldload if_tun if you allready have tun interfaces (built in). -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
New interrupt stuff breaks ASUS 2 CPU system
Hi, I have an ASUS system with 2 CPUs that I need to run at HZ=1. This worked until yesterday, but with the new interrupt code it doesn't boot anymore. It works for the standard HZ, but if I set HZ=1000 I get a double fault. I suspect a race condition in the interrupt handling. My config file has options SMP device apic options HZ=1000 I have commented out acpi, but that doesn't change anything. A verbose boot looks like: OK boot -v SMAP type=01 base= len=0009f800 SMAP type=02 base=0009f800 len=0800 SMAP type=02 base=000f len=0001 SMAP type=01 base=0010 len=1feec000 SMAP type=03 base=1ffec000 len=3000 SMAP type=02 base=1ffef000 len=0001 SMAP type=04 base=1000 len=1000 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base= len=0001 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 #29: Tue Nov 4 13:50:23 CET 2003 [EMAIL PROTECTED]:/opt/obj/usr/src/sys/MARIPOSA Preloaded elf kernel /boot/kernel/kernel at 0xc069b000. Preloaded elf module /boot/kernel/random.ko at 0xc069b278. Calibrating clock(s) ... i8254 clock: 1193132 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1380009492 Hz CPU: AMD Athlon(TM) MP 1800+ (1380.01-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536788992 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00829000 - 0x1f6c5fff, 518639616 bytes (126621 pages) avail memory = 516005888 (492 MB) MPTable: ASUS PROD APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f2560 bios32: Entry = 0xf1d20 (c00f1d20) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x1f20 pnpbios: Found PnP BIOS data at 0xc00fc5e0 pnpbios: Entry = f:c610 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: ioapic0: Assuming intbase of 0 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 ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: active-lo ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: active-lo ioapic0: intpin 19 trigger: level ioapic0: intpin 19 polarity: active-lo ioapic0: intpin 18 trigger: level ioapic0: intpin 18 polarity: active-lo ioapic0: intpin 17 trigger: level ioapic0: intpin 17 polarity: active-lo ioapic0: intpin 19 trigger: level ioapic0: intpin 19 polarity: active-lo ioapic0: intpin 1 trigger: edge ioapic0: intpin 1 polarity: active-hi ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi ioapic0: intpin 4 trigger: edge ioapic0: intpin 4 polarity: active-hi ioapic0: intpin 5 trigger: edge ioapic0: intpin 5 polarity: active-hi ioapic0: intpin 6 trigger: edge ioapic0: intpin 6 polarity: active-hi ioapic0: intpin 7 trigger: edge ioapic0: intpin 7 polarity: active-hi ioapic0: intpin 8 trigger: edge ioapic0: intpin 8 polarity: active-hi ioapic0: intpin 9 trigger: edge ioapic0: intpin 9 polarity: active-hi ioapic0: intpin 13 trigger: edge ioapic0: intpin 13 polarity: active-hi ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: active-hi ioapic0: intpin 15 trigger: edge ioapic0: intpin 15 polarity: active-hi lapic: Routing ExtINT - LINT0 lapic: LINT0 trigger: edge lapic: LINT0
Re: if_tun failed to register
Max Laier wrote: AJ AJ module_register: module if_tun already exists! AJ Module if_tun failed to register: 17 AJ can't re-use a leaf (if_tun_debug)! AJ AJ Is there a kernel option I missed ? I already have device tun in AJ my kernel config file. This might be due to missing/incomplete mergemaster after installworld? Try to remove your rc.d related stuff from etc before running mergemaster -i. The scripts should not try to kldload if_tun if you allready have tun interfaces (built in). Well, it did not change anything :( What is really strange is that tun is compiled in the kernel, but the module is started anyway ??? $ kldstat Id Refs AddressSize Name 16 0xc040 35aef8 kernel 21 0xc075b000 4cd10acpi.ko 31 0xc463d000 4000 logo_saver.ko 41 0xc46e2000 4000 if_tun.ko Here is a part of my kernel configuration: device miibus device fxp device random device loop device ether device ppp device tun device pty device bpf options ETGRAPH options NETGRAPH_ETHER options NETGRAPH_PPPOE options NETGRAPH_SOCKET options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPDIVERT options CPU_ENABLE_SSE options IPSTEALTH options RANDOM_IP_ID options SC_DISABLE_REBOOT I thank you very much for your answer. Regards. Antoine ___ [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
Hi. I have an ASUS system with 2 CPUs that I need to run at HZ=1. This worked until yesterday, but with the new interrupt code it doesn't boot anymore. It works for the standard HZ, but if I set HZ=1000 I get a double Compiled a new kernel with source from Nov. 3'rd where SMP and APIC had to be enabled to use SMP. A make kernel would complete in 10 min's. So I cvsupped to test the 'interrupt stuff' and recompiled. Upon boot it seemed that it only saw one of my two Xeons at 2.4 Ghz. Hypert. was enabled as default. So I reverted to the source the day before. I also have an ASUS motherboard with an Intel 875P chipset. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [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
Il Mar, 2003-11-04 alle 14:17, Antoine Jacoutot ha scritto: Max Laier wrote: AJ AJ module_register: module if_tun already exists! AJ Module if_tun failed to register: 17 AJ can't re-use a leaf (if_tun_debug)! AJ AJ Is there a kernel option I missed ? I already have device tun in AJ my kernel config file. This might be due to missing/incomplete mergemaster after installworld? Try to remove your rc.d related stuff from etc before running mergemaster -i. The scripts should not try to kldload if_tun if you allready have tun interfaces (built in). 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. Best regards -- Rionda aka Matteo Riondato G.U.F.I Staff Member (http://www.gufi.org) BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda) GPG key at: http://www.riondabsd.net/riondagpg.asc Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: if_tun failed to register
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. Thanks for the feedback Antoine ___ [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 04-Nov-2003 Claus Guttesen wrote: Hi. I have an ASUS system with 2 CPUs that I need to run at HZ=1. This worked until yesterday, but with the new interrupt code it doesn't boot anymore. It works for the standard HZ, but if I set HZ=1000 I get a double Compiled a new kernel with source from Nov. 3'rd where SMP and APIC had to be enabled to use SMP. A make kernel would complete in 10 min's. So I cvsupped to test the 'interrupt stuff' and recompiled. Upon boot it seemed that it only saw one of my two Xeons at 2.4 Ghz. Hypert. was enabled as default. So I reverted to the source the day before. I also have an ASUS motherboard with an Intel 875P chipset. Can you post a dmesg? Note that if you want hyperthreading, you need to enable it in your BIOS. The ACPI (and soon the MPTable) drivers will not use HT CPUs unless HT is enabled in the BIOS. My test machines with HT used the 865 chipset. -- 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: More ULE bugs fixed.
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. Ciao, Sheldon. ___ [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 04-Nov-2003 Harti Brandt wrote: Hi, I have an ASUS system with 2 CPUs that I need to run at HZ=1. This worked until yesterday, but with the new interrupt code it doesn't boot anymore. It works for the standard HZ, but if I set HZ=1000 I get a double fault. I suspect a race condition in the interrupt handling. My config file has options SMP device apic options HZ=1000 Ok, I can try to reproduce. Device configuration finished. Timecounter TSC frequency 1380009492 Hz quality -100 Timecounters cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc048995d stack pointer = 0x10:0xc0821bf4 frame pointercpuid = 0; apic id = 00 0xc048995d is in critical_exit. It is the jmp after the popf from cpu_critical_exit. This is where interrupts are re-enabled, so you are getting an interrupt. It might be helpful to figure what type of fault you are actually getting. -- 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: panic when going multiuser
On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. -- 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: xl0 watchdog timeout
On 04-Nov-2003 Shin-ichi Yoshimoto wrote: After cvsup and make world, I could't use xl0 and kernel said kernel: xl0: watchdog timeout. # dmesg [snip] xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea 02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Can you please provide a full dmesg? -- 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]
Kernel Panic
For the past few weeks my -CURRENT system has been locking up. With a recent kernel (from 11/2) the following appears: Fault trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc049d0db stack pointer = 0x10:0xe009cc88 frame pointer = 0x10:0xe009cc9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 23 (irq10: dc0) trap number = 12 panic: page fault syncing disks, buffers remaining... 6800 6800 That bit about the current process and 'dc0' kind of makes me believe it was a dc driver issue? I may replace that card (with an ethernet card that doesn't use dc) and see if the problem goes away. Am I correct in believing this is a dc issue? If so, hope the above helps in diagnosing the problem. Otherwise... any other pointers? -Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: if_xname changes incoming
On (2003/11/03 13:38), Brooks Davis wrote: I've sent mail to both his FreeBSD address and the one on the IPFilter homepage. If anyone knows a reliable way to communicate with him, that would be useful. The latter address works, but he's terrible with email, by his own admission. If you don't get an answer in a couple of days, send a nag mail; he's okay with that. :-) Ciao, Sheldon. ___ [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 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. Sorry for the noise, I think I found the problem: I had to put options SMP and device apic into the kernel, now everythings seems to run fine. I thought they were only needed for SMP kernels, that's at least what the comment in GENERIC says... If you still want the dmesg, I can send it to you. sorry, regards. le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [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 Tue, 4 Nov 2003, John Baldwin wrote: JB JBOn 04-Nov-2003 Harti Brandt wrote: JB JB Hi, JB JB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This JB worked until yesterday, but with the new interrupt code it doesn't boot JB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double JB fault. I suspect a race condition in the interrupt handling. My config JB file has JB JB options SMP JB device apic JB options HZ=1000 JB JBOk, I can try to reproduce. JB JB Device configuration finished. JB Timecounter TSC frequency 1380009492 Hz quality -100 JB Timecounters cpuid = 0; apic id = 00 JB instruction pointer = 0x8:0xc048995d JB stack pointer = 0x10:0xc0821bf4 JB frame pointercpuid = 0; apic id = 00 JB JB 0xc048995d is in critical_exit. It is the jmp after the popf from JB cpu_critical_exit. JB JBThis is where interrupts are re-enabled, so you are getting an interrupt. JBIt might be helpful to figure what type of fault you are actually getting. tf_err is 0, tf_trapno is 30 (decimal). 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]
RE: xl0 watchdog timeout
Subject: RE: xl0 watchdog timeout, On Tue, 04 Nov 2003 10:39:44 -0500 (EST), John Baldwin wrote: Can you please provide a full dmesg? yes. 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 #7: Tue Nov 4 19:11:26 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAEMON Preloaded elf kernel /boot/kernel/kernel at 0xc0793000. Preloaded elf module /boot/kernel/linux.ko at 0xc07931f4. Preloaded elf module /boot/kernel/ipfw.ko at 0xc07932a0. Preloaded elf module /boot/kernel/mga.ko at 0xc079334c. ACPI APIC Table: VIA694 AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III CPU family 1266MHz (1267.16-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1023 MB) avail memory = 1037688832 (989 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2 irqs 0-23 on motherboard Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdc80 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_tz0: Thermal Zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pcib0: could not get PCI interrupt routing table for \\_SB_.PCI0 - AE_BAD_DATA pci0: ACPI PCI bus on pcib0 agp0: VIA Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 drm0: Matrox G400/G450 (AGP) mem 0xe700-0xe77f,0xe600-0xe6003fff,0xe400-0xe5ff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xe000 64MB info: [drm] Initialized mga 3.1.0 20021029 on minor 0 atapci0: Promise PDC20267 UDMA100 controller port 0xd000-0xd03f,0xcc00-0xcc03,0x1800-0x1807,0xc400-0xc403,0x1000-0x1007 mem 0xea00-0xea01 irq 19 at device 8.0 on pci0 atapci0: [MPSAFE] ata2: at 0x1000 on atapci0 ata2: [MPSAFE] ata3: at 0x1800 on atapci0 ata3: [MPSAFE] isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci1: VIA 8233C UDMA100 controller port 0xd400-0xd40f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xd800-0xd81f irq 11 at device 17.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 11 at device 17.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xe000-0xe01f irq 11 at device 17.4 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROMs at iomem 0xd4000-0xdc7ff,0xcc000-0xd3fff,0xc-0xc8fff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 5000 packets/entry by default acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% acd0: DVDROM Pioneer DVD-ROM ATAPIModel DVD-120 at ata1-master UDMA66 GEOM: create disk ad4 dp=0xc66ceb70 ad4: 117246MB Maxtor
New PNP0303 and aPic question
Hi all, with today's -current (with the new irq stuff) I get the following messages wich I haven't had before: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) Timecounter TSC frequency 1095821276 Hz quality 800 See attached the complete dmesg. Then I have a question regarding the aPic: I know that my hardware has such a aPic and under WinXP there were irqs assigned up to ~23. Is it possible to support that apic without SMP? Thanks, -Harry pgp0.pgp Description: signature
RE: New interrupt stuff breaks ASUS 2 CPU system
On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). Hmm, this seems to be the trapno that is set for all otherwise unused vectors, correct? There seems to be no info in the trapframe that shows me where this trap came from. How can I find this out? 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]
Re: New PNP0303 and aPic question
On Tuesday 04 November 2003 17:10, Harald Schmalzbauer wrote: Hi all, with today's -current (with the new irq stuff) I get the following messages wich I haven't had before: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) Timecounter TSC frequency 1095821276 Hz quality 800 Mist, now it really is attached. Sorry See attached the complete dmesg. Then I have a question regarding the aPic: I know that my hardware has such a aPic and under WinXP there were irqs assigned up to ~23. Is it possible to support that apic without SMP? Thanks, -Harry and installed have the same CVS Id, deleting Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 14 14 done Uptime: 4h56m24s Shutting down ACPI Rebooting... 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 #27: Tue Nov 4 16:37:45 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel /boot/kernel/kernel at 0xc0974000. Preloaded elf module /boot/kernel/linux.ko at 0xc0974244. Preloaded elf module /boot/kernel/nvidia.ko at 0xc09742f0. Timecounter i8254 frequency 1183580 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268173312 (255 MB) avail memory = 250789888 (239 MB) Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc0720ae2 (122) VESA: NVIDIA npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 pcib0: Intel 82815 (i815 GMCH) Host To Hub bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:31 INTD BIOS irq 7 pci_cfgintr: 0:31 INTB BIOS irq 9 pci_cfgintr: 0:31 INTC BIOS irq 10 pci_cfgintr: 0:31 INTB BIOS irq 9 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci2: PCI bus on pcib1 pci_cfgintr: 0:1 INTA routed to irq 4 pcib1: slot 0 INTA is routed to irq 4 nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff irq 4 at device 0.0 on pci2 pcib2: PCIBIOS PCI-PCI bridge at device 30.0 on pci0 pci1: PCI bus on pcib2 pci_cfgintr: 1:8 INTA BIOS irq 11 fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 7 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) 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 ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0xefa0-0xefaf irq 9 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 10 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2 uhub2: 4 ports with 4 removable, self powered ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01, addr 4 uhub3: 2 ports with 2 removable, bus powered pcm0: Intel ICH2 (82801BA) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device 31.5 on pci0 pcm0: Analog Devices AD1885 AC97 Codec orm0: Option ROMs at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0
Re: Kernel Panic
Steve Ames [EMAIL PROTECTED] wrote: For the past few weeks my -CURRENT system has been locking up. With a recent kernel (from 11/2) the following appears: Fault trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc049d0db stack pointer = 0x10:0xe009cc88 frame pointer = 0x10:0xe009cc9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 23 (irq10: dc0) trap number = 12 panic: page fault syncing disks, buffers remaining... 6800 6800 That bit about the current process and 'dc0' kind of makes me believe it was a dc driver issue? I may replace that card (with an ethernet card that doesn't use dc) and see if the problem goes away. Am I correct in believing this is a dc issue? If so, hope the above helps in diagnosing the problem. Otherwise... any other pointers? instruction pointer = 0x8:0xc049d0db That will tell you exactly where the problem is... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [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 Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). More information: I have replaced all the reserved vectors with individual ones, that set tf_err to the index (vector number). It appears the the vector number is 39 decimal. What does that mean? 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]
Re: new interrupt code: panic when going multiuser
On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. Sorry for the noise, I think I found the problem: I had to put options SMP and device apic into the kernel, now everythings seems to run fine. I thought they were only needed for SMP kernels, that's at least what the comment in GENERIC says... If you still want the dmesg, I can send it to you. Well, a kernel without SMP and just 'device apic' should work fine, and a kernel with both SMP and 'device apic' should also work fine. -- 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: xl0 watchdog timeout
On 04-Nov-2003 Shin-ichi Yoshimoto wrote: Subject: RE: xl0 watchdog timeout, On Tue, 04 Nov 2003 10:39:44 -0500 (EST), John Baldwin wrote: Can you please provide a full dmesg? yes. Try disabling ACPI. ACPI is unable to route any of your PCI interrupts, so all your PCI interrupts are hosed. You can try to talk with the folks on acpi-jp@ to figure out if your AML can be patched. pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pcib0: could not get PCI interrupt routing table for \\_SB_.PCI0 - AE_BAD_DATA pci0: ACPI PCI bus on pcib0 -- 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 04-Nov-2003 Harti Brandt wrote: On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). Hmm, this seems to be the trapno that is set for all otherwise unused vectors, correct? There seems to be no info in the trapframe that shows me where this trap came from. How can I find this out? You can't easily. If you have an APIC, you can try looking at the ISR registers. You need to add some code to local_apic.c that dumps the ISR contents and then call that from trap() prehaps. -- 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
Hi. I also have an ASUS motherboard with an Intel 875P chipset. Can you post a dmesg? Note that if you want hyperthreading, you need to enable it in your BIOS. The ACPI (and soon the MPTable) drivers will not use HT CPUs unless HT is enabled in the BIOS. My test machines with HT used the 865 chipset. Upon boot the screen says that it's a dual Xeon with HT. I downgraded the server before I read this thread, so it's running the previous days src. I guess that a dmesg won't help from that. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
Ah okay... that makes more sense and the results definately show more data that I'm sure will help pinpoint the problem. Here is the paste from the bootup. FreeBSD/i386 boot Default: 0:fd(0,a)/boot/loader boot: Uncompressing ... done Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 633kB/4061120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Tue Nov 4 09:12:55 GMT 2003) include /boot/device.hints set hint.fdc.0.at=isa set hint.fdc.0.port=0x3F0 set hint.fdc.0.irq=6 set hint.fdc.0.drq=2 set hint.fd.0.at=fdc0 set hint.fd.0.drive=0 set hint.fd.1.at=fdc0 set hint.fd.1.drive=1 set hint.ata.0.at=isa set hint.ata.0.port=0x1F0 set hint.ata.0.irq=14 set hint.ata.1.at=isa set hint.ata.1.port=0x170 set hint.ata.1.irq=15 set hint.adv.0.at=isa set hint.adv.0.disabled=1 set hint.bt.0.at=isa set hint.bt.0.disabled=1 set hint.aha.0.at=isa set hint.aha.0.disabled=1 set hint.aic.0.at=isa set hint.aic.0.disabled=1 set hint.atkbdc.0.at=isa set hint.atkbdc.0.port=0x060 set hint.atkbd.0.at=atkbdc set hint.atkbd.0.irq=1 set hint.atkbd.0.flags=0x1 set hint.psm.0.at=atkbdc set hint.psm.0.irq=12 set hint.vga.0.at=isa set hint.sc.0.at=isa set hint.sc.0.flags=0x100 set hint.vt.0.at=isa set hint.vt.0.disabled=1 set hint.apm.0.disabled=1 set hint.apm.0.flags=0x20 set hint.pcic.0.at=isa set hint.pcic.0.port=0x3e0 set hint.pcic.0.maddr=0xd set hint.pcic.1.at=isa set hint.pcic.1.irq=11 set hint.pcic.1.port=0x3e2 set hint.pcic.1.maddr=0xd4000 set hint.pcic.1.disabled=1 set hint.sio.0.at=isa set hint.sio.0.port=0x3F8 set hint.sio.0.flags=0x10 set hint.sio.0.irq=4 set hint.sio.1.at=isa set hint.sio.1.port=0x2F8 set hint.sio.1.irq=3 set hint.sio.2.at=isa set hint.sio.2.disabled=1 set hint.sio.2.port=0x3E8 set hint.sio.2.irq=5 set hint.sio.3.at=isa set hint.sio.3.disabled=1 set hint.sio.3.port=0x2E8 set hint.sio.3.irq=9 set hint.ppc.0.at=isa set hint.ppc.0.irq=7 set hint.ed.0.at=isa set hint.ed.0.disabled=1 set hint.ed.0.port=0x280 set hint.ed.0.irq=10 set hint.ed.0.maddr=0xd8000 set hint.cs.0.at=isa set hint.cs.0.disabled=1 set hint.cs.0.port=0x300 set hint.sn.0.at=isa set hint.sn.0.disabled=1 set hint.sn.0.port=0x300 set hint.sn.0.irq=10 set hint.ie.0.at=isa set hint.ie.0.disabled=1 set hint.ie.0.port=0x300 set hint.ie.0.irq=10 set hint.ie.0.maddr=0xd set hint.fe.0.at=isa set hint.fe.0.disabled=1 set hint.fe.0.port=0x300 set hint.le.0.at=isa set hint.le.0.disabled=1 set hint.le.0.port=0x300 set hint.le.0.irq=5 set hint.le.0.maddr=0xd set hint.lnc.0.at=isa set hint.lnc.0.disabled=1 set hint.lnc.0.port=0x280 set hint.lnc.0.irq=10 set hint.lnc.0.drq=0 load /kernel /kernel text=0x23bf5c data=0x2efa4+0x4bebc - echo \007\007 echo Please insert MFS root floppy and press enter: Please insert MFS root floppy and press enter: read load -t mfs_root /mfsroot set hint.acpi.0.disabled=1 set driver_floppy=YES set module_path=/modules;/dist echo \007\007 autoboot 10 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/kernel] in 7 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -v SMAP type=01 base= len=0009e400 SMAP type=02 base=0009e400 len=1c00 SMAP type=02 base=000dc000 len=00024000 SMAP type=01 base=0010 len=f7df SMAP type=03 base=f7ef len=c000 SMAP type=04 base=f7efc000 len=4000 SMAP type=01 base=f7f0 len=0008 SMAP type=02 base=f7f8 len=0008 SMAP type=02 base=fec0 len=0001 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=ff80 len=0040 SMAP type=02 base=fff0 len=0010 SMAP type=01 base=0001 len=0800 131072K of memory above 4GB ignored 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-20031104-JPSNAP #0: Tue Nov 4 09:31:14 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOOTMFS Preloaded elf kernel /kernel at 0xc0af1000. Preloaded mfs_root /mfsroot at 0xc0af12cc. Calibrating clock(s) ... i8254 clock: 1193298 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2399327592 Hz CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf25 Stepping = 5 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 Hyperthreading: 2 logical CPUs real memory = 4160225280 (3967 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0010 - 0x003f, 3145728 bytes (768
[Tillman: Upgraded to latest -current today, boot hangs on ata3: resetting devices]
It occurs to me that this is likely related to the new interrupt code. that tends to imply that the fix is wait a few days and re-cvsup, but I thought folks here would be interested in seeing Sparc64 feedback. -T -- [It] contains vegetable stabilizer which sounds ominous. How unstable are vegetables? - A.S.R. quote (Jeff Zahn) ---BeginMessage--- The serial console shows this: atapci0: CMD 646 WDMA2 controller port 0xc00020-0xc0002f,0xc00018-0xc0001b,0xc00010-0xc00017,0xc8-0xcb,0xc0-0xc7 at device 3.0 on pci1 atapci0: [MPSAFE] ata2: at 0xc0 on atapci0 ata2: [MPSAFE] ata3: at 0xc00010 on atapci0 ata3: [MPSAFE] pcib2: APB PCI-PCI bridge at device 1.0 on pci0 pci2: OFW PCI bus on pcib2 pcib3: OFW PCI-PCI bridge at device 3.0 on pci2 pci3: OFW PCI bus on pcib3 pci3: bridge, PCI-unknown at device 0.0 (no driver attached) hme1: Sun HME 10/100 Ethernet mem 0x280-0x2807fff at device 0.1 on pci3 pcib3: slot 0 INTB is routed to irq 25 hme1: Ethernet address: 08:00:20:c6:7f:c7 miibus1: MII bus on hme1 ukphy0: Generic IEEE 802.3u media interface on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci3: bridge, PCI-unknown at device 1.0 (no driver attached) hme2: Sun HME 10/100 Ethernet mem 0x480-0x4807fff at device 1.1 on pci3 pcib3: slot 1 INTB is routed to irq 26 hme2: Ethernet address: 08:00:20:c6:7f:c7 miibus2: MII bus on hme2 ukphy1: Generic IEEE 802.3u media interface on miibus2 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci3: bridge, PCI-unknown at device 2.0 (no driver attached) hme3: Sun HME 10/100 Ethernet mem 0x680-0x6807fff at device 2.1 on pci3 pcib3: slot 2 INTB is routed to irq 27 hme3: Ethernet address: 08:00:20:c6:7f:c7 miibus3: MII bus on hme3 ukphy2: Generic IEEE 802.3u media interface on miibus3 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci3: bridge, PCI-unknown at device 3.0 (no driver attached) hme4: Sun HME 10/100 Ethernet mem 0x880-0x8807fff at device 3.1 on pci3 pcib3: slot 3 INTB is routed to irq 24 hme4: Ethernet address: 08:00:20:c6:7f:c7 miibus4: MII bus on hme4 ukphy3: Generic IEEE 802.3u media interface on miibus4 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Timecounters tick every 0.976 msec IPsec: Initialized Security Association Processing. IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt ad0: WARNING - SET_MULTI recovered from missing interrupt ad0: WARNING - SETFEATURES recovered from missing interrupt GEOM: create disk ad0 dp=0xf8001087a6c0 ad0: 8223MB ST38410A [16708/16/63] at ata2-master WDMA2 acd0: WARNING - MODE_SENSE_BIG recovered from missing interrupt ata3: resetting devices .. It's an Ultra 5 with an IDE drive. I was previously running -current from after the 09/23 entry in UPDATING. Entries since then don't show anything particularly relevent. I ran cvsup before beginning the compile about 8:00am CST. Are there any known issues like this? Are there known solutions? Even a wait until foo is committed then re-cvsp would be great to hear ;-) I've tried load /boot/kernel.old/kernel from the boot loader to recover at least a booting system. This worked, though naturally my userland no longer matches my kernel. Should I be able to re-install a new kernel userland from this point safely? -T -- I'm getting a new desk soon! Desk goes up. Desk goes down. Desk goes up. Desk goes down. Desk goes up. Desk goes down. Desk goes up. Desk goes down. Desk goes up. Desk goes down. Desk goes up. Desk goes down. Lunch. Productivity is in the eyes of the beholder. - A.S.R. quote (Lars Balker Rasmussen) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 To unsubscribe, send any mail to [EMAIL PROTECTED] ---End Message--- ___ [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 Tuesday 04 November 2003 18:19, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. Sorry for the noise, I think I found the problem: I had to put options SMP and device apic into the kernel, now everythings seems to run fine. I thought they were only needed for SMP kernels, that's at least what the comment in GENERIC says... If you still want the dmesg, I can send it to you. Well, a kernel without SMP and just 'device apic' should work fine, and a kernel with both SMP and 'device apic' should also work fine. Hmm, I think this answer should be for New PNP0303 and aPic question? Well I tired to build one (with -curr some weeks ago) with device apic only which didn't work, I had to add options smp arrrgghhh. Had a look in my file and saw I did the following: #options SMP #options APIC_IO Seems I didn't use device apic (perhaps I didn't recognize) But regardless, when I built a SMP kernel it didn't run on my UP machine. Thanks a lot, -Harry pgp0.pgp Description: signature
Re: new interrupt code: panic when going multiuser
On Tue, 4 Nov 2003, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. I have noticed the following problems with the new interrupt code so far: - it conflicts with a few thousand lines of local changes. - yesterday's backup kernels which I preserved to run benchmarks with all hang at boot time while probing atapicam devices. Backing out rev.1.23 of ata-lowlevel.c fixes the hang, but I didn't back up yesterday's sources so it will take some work to regenerate working versions of yesterday's kernels. The following is without the local changes: - cyintr(int unit) panics becauase it is passed a pointer to somewhere. I think all compat_isa devices are broken for unit 0 because unit 0 is represented by a null pointer. - 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. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Page fault
Hi all, I've got the following trying to debug FreeBSD current ( Mon Oct 27 16:34:36 CET 2003) on a serial terminal. Hardware: Supermicro x5da8 dual xeon 2.66Ghz 2GB ecc ddr ram Tekram 390u2we (system on a 36GB disc) promise sx6000 ( home on 6 WD1200JB (raid 5)) Intel(R) PRO/1000 (on motherboard) Intel 82558 Pro/100 I've disabled softupdates because of a panic(softdep_move_dependencies: need merge code); Could someone take a look at this? pst: timeout mfa=0x0032d5d0 cmd=0x02 pst: timeout mfa=0x00336390 cmd=0x02 pst: timeout mfa=0x0034cdd0 cmd=0x02 cut pst: timeout mfa=0x003b7ab0 cmd=0x02 pst: timeout mfa=0x00396db0 cmd=0x02 pst: timeout mfa=0x003a3530 cmd=0x02 pst: timeout mfa=0x00376890 cmd=0x02 ufs_access(): Error retrieving ACL on object (5). cut ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0xae18c0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc066a566 stack pointer = 0x10:0xea3a78cc frame pointer = 0x10:0xea3a7900 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 76932 (smbd) kernel: type 12 trap, code=0 Stopped at generic_bcopy+0x1a: repe movsl (%esi),%es:(%edi) db trace generic_bcopy(cf6b,1a8,2,c06bd12c,0) at generic_bcopy+0x1a ffs_getextattr(ea3a7960,ea3a795c,c05159ad,d0346200,184) at ffs_getextattr+0xe0 vn_extattr_get(cb1a8c8c,8,2,c06bd12c,ea3a79d0) at vn_extattr_get+0xaa ufs_getacl(ea3a7a14,ea3a7a40,c061560b,ea3a7a14,c06df280) at ufs_getacl+0x99 ufs_vnoperate(ea3a7a14,c06df280,2,a6,c853cd10) at ufs_vnoperate+0x18 ufs_access(ea3a7a6c,ea3a7b28,c057dcc9,ea3a7a6c,c0716cc8) at ufs_access+0xca ufs_vnoperate(ea3a7a6c,c0716cc8,c0716cc8,c853cd10,cb1a8c8c) at ufs_vnoperate+0x1 8 vn_open_cred(ea3a7bdc,ea3a7cdc,1a4,d0bb7800,22) at vn_open_cred+0x359 vn_open(ea3a7bdc,ea3a7cdc,1a4,22,c3ee0fb4) at vn_open+0x30 kern_open(c853cd10,bfbff130,0,1,1a4) at kern_open+0x143 open(c853cd10,ea3a7d14,c06c44d0,3ed,3) at open+0x30 syscall(bfbf002f,82b002f,bfbf002f,bfbffd70,82b3724) at syscall+0x28f Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x662b5233, esp = 0xbfbff07c, ebp = 0xbfbff098 --- db show locks exclusive sleep mutex Giant r = 0 (0xc07115c0) locked @ /usr/src/sys/vm/vm_fault .c:223 regards, Andreas ___ [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: Well, a kernel without SMP and just 'device apic' should work fine, and a kernel with both SMP and 'device apic' should also work fine. But 'device apic' is necessary nowadays? Maybe that should be noted somewhere. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [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 Harald Schmalzbauer wrote: Hi all, with today's -current (with the new irq stuff) I get the following messages wich I haven't had before: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) Timecounter TSC frequency 1095821276 Hz quality 800 You probably had ACPI as a module before. You need to compile acpi into your kernel if you wish to use it still. These messages are from the PnP BIOS probe that happens when ACPI is not used. See attached the complete dmesg. Then I have a question regarding the aPic: I know that my hardware has such a aPic and under WinXP there were irqs assigned up to ~23. Is it possible to support that apic without SMP? 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. -- 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: Kernel Panic
On 04-Nov-2003 Brian F. Feldman wrote: Steve Ames [EMAIL PROTECTED] wrote: For the past few weeks my -CURRENT system has been locking up. With a recent kernel (from 11/2) the following appears: Fault trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc049d0db stack pointer = 0x10:0xe009cc88 frame pointer = 0x10:0xe009cc9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 23 (irq10: dc0) trap number = 12 panic: page fault syncing disks, buffers remaining... 6800 6800 That bit about the current process and 'dc0' kind of makes me believe it was a dc driver issue? I may replace that card (with an ethernet card that doesn't use dc) and see if the problem goes away. Am I correct in believing this is a dc issue? If so, hope the above helps in diagnosing the problem. Otherwise... any other pointers? instruction pointer = 0x8:0xc049d0db That will tell you exactly where the problem is... Specifically, reproduce this panic using a kernel built with debug symbols, then do 'gdb -k kernel.debug' in the kernel build directory and then 'l *0xc049d0db' (or whatever the instruction pointer address is) to get the source and line of the panic. -- 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 04-Nov-2003 Harti Brandt wrote: On Tue, 4 Nov 2003, Harti Brandt wrote: HBOn Tue, 4 Nov 2003, John Baldwin wrote: HB HBJB HBJBOn 04-Nov-2003 Harti Brandt wrote: HBJB HBJB Hi, HBJB HBJB I have an ASUS system with 2 CPUs that I need to run at HZ=1. This HBJB worked until yesterday, but with the new interrupt code it doesn't boot HBJB anymore. It works for the standard HZ, but if I set HZ=1000 I get a double HBJB fault. I suspect a race condition in the interrupt handling. My config HBJB file has HBJB HBJB options SMP HBJB device apic HBJB options HZ=1000 HBJB HBJBOk, I can try to reproduce. HBJB HBJB Device configuration finished. HBJB Timecounter TSC frequency 1380009492 Hz quality -100 HBJB Timecounters cpuid = 0; apic id = 00 HBJB instruction pointer = 0x8:0xc048995d HBJB stack pointer = 0x10:0xc0821bf4 HBJB frame pointercpuid = 0; apic id = 00 HBJB HBJB 0xc048995d is in critical_exit. It is the jmp after the popf from HBJB cpu_critical_exit. HBJB HBJBThis is where interrupts are re-enabled, so you are getting an interrupt. HBJBIt might be helpful to figure what type of fault you are actually getting. HB HBtf_err is 0, tf_trapno is 30 (decimal). More information: I have replaced all the reserved vectors with individual ones, that set tf_err to the index (vector number). It appears the the vector number is 39 decimal. What does that mean? IRQ 7. Can you post a verbose dmesg? Also, can you try both with and without ACPI? -- 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 Tue, Nov 04, 2003 at 02:17:35PM +0100, Antoine Jacoutot wrote: What is really strange is that tun is compiled in the kernel, but the module is started anyway ??? $ kldstat Id Refs AddressSize Name 16 0xc040 35aef8 kernel 21 0xc075b000 4cd10acpi.ko 31 0xc463d000 4000 logo_saver.ko 41 0xc46e2000 4000 if_tun.ko This looks similar to: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/48759 demon's patch was not integrated I suppose. Of course You have to track down, why something is trying to load if_tun even if tun is compiled in. -- Pawe Maachowski ___ [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 04-Nov-2003 Harald Schmalzbauer wrote: On Tuesday 04 November 2003 18:19, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. Sorry for the noise, I think I found the problem: I had to put options SMP and device apic into the kernel, now everythings seems to run fine. I thought they were only needed for SMP kernels, that's at least what the comment in GENERIC says... If you still want the dmesg, I can send it to you. Well, a kernel without SMP and just 'device apic' should work fine, and a kernel with both SMP and 'device apic' should also work fine. Hmm, I think this answer should be for New PNP0303 and aPic question? Well I tired to build one (with -curr some weeks ago) with device apic only which didn't work, I had to add options smp arrrgghhh. Had a look in my file and saw I did the following: #options SMP #options APIC_IO Seems I didn't use device apic (perhaps I didn't recognize) But regardless, when I built a SMP kernel it didn't run on my UP machine. Thanks a lot, I just committed a bunch of changes to the interrupt and SMP code. When you update to those changes, you should be able to build a UP kernel with 'device apic' and have it work, and you should be able to build an SMP kernel and have it run on your machine. -- 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: panic when going multiuser
On Tuesday 04 November 2003 19:38, John Baldwin wrote: On 04-Nov-2003 Harald Schmalzbauer wrote: On Tuesday 04 November 2003 18:19, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. Sorry for the noise, I think I found the problem: I had to put options SMP and device apic into the kernel, now everythings seems to run fine. I thought they were only needed for SMP kernels, that's at least what the comment in GENERIC says... If you still want the dmesg, I can send it to you. Well, a kernel without SMP and just 'device apic' should work fine, and a kernel with both SMP and 'device apic' should also work fine. Hmm, I think this answer should be for New PNP0303 and aPic question? Well I tired to build one (with -curr some weeks ago) with device apic only which didn't work, I had to add options smp arrrgghhh. Had a look in my file and saw I did the following: #options SMP #options APIC_IO Seems I didn't use device apic (perhaps I didn't recognize) But regardless, when I built a SMP kernel it didn't run on my UP machine. Thanks a lot, I just committed a bunch of changes to the interrupt and SMP code. When you update to those changes, you should be able to build a UP kernel with 'device apic' and have it work, and you should be able to build an SMP kernel and have it run on your machine. Oh, great! Thanks a lot and sorry for the former nonses-reply. I read your first answer which was correct for my subject but I hadn't carefully read this thread. After jdk14 is finished I'll recvsup and build a new kernel. I already built world today so I hope kernel only is okay. Best regards, -Harry pgp0.pgp Description: signature
Re: new interrupt code: panic when going multiuser
On 04-Nov-2003 Bruce Evans wrote: On Tue, 4 Nov 2003, John Baldwin wrote: On 04-Nov-2003 Lukas Ertl wrote: On Tue, 4 Nov 2003, Lukas Ertl wrote: I somehow can't get at a good vmcore :-(. But I found out that the machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned off. Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine. Could there be some issue with ATAng + new interrupt code? Can you provide a dmesg please? There may be a weird issue with some PPro's for example that I haven't been able to test. I have noticed the following problems with the new interrupt code so far: - it conflicts with a few thousand lines of local changes. - yesterday's backup kernels which I preserved to run benchmarks with all hang at boot time while probing atapicam devices. Backing out rev.1.23 of ata-lowlevel.c fixes the hang, but I didn't back up yesterday's sources so it will take some work to regenerate working versions of yesterday's kernels. The following is without the local changes: - cyintr(int unit) panics becauase it is passed a pointer to somewhere. I think all compat_isa devices are broken for unit 0 because unit 0 is represented by a null pointer. Ah, ok. Yes, this is a semantic change. To try and support clock interrupts, a fast handler that passes a NULL argument will get a pointer to the intrframe as its argument. I got the idea via sparc64 from [EMAIL PROTECTED] Perhaps something can be faked up in the compat_isa shims to fix this. Please try http://www.FreeBSD.org/~jhb/patches/isa_compat.patch - 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? -- 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: panic when going multiuser
The following is without the local changes: - cyintr(int unit) panics becauase it is passed a pointer to somewhere. I think all compat_isa devices are broken for unit 0 because unit 0 is represented by a null pointer. Ah, ok. Yes, this is a semantic change. To try and support clock interrupts, a fast handler that passes a NULL argument will get a pointer to the intrframe as its argument. I got the idea via sparc64 from [EMAIL PROTECTED] Perhaps something can be faked up in the compat_isa shims to fix this. Clock interrupt handlers have always been a nasty special case. Please try http://www.FreeBSD.org/~jhb/patches/isa_compat.patch Will try later today. It should work, but adds yet more overhead. - 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. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault
On Tue, 4 Nov 2003, Nils Andreas Hakansson wrote: I've disabled softupdates because of a panic(softdep_move_dependencies: need merge code); Can't comment on this bit. Might want to send e-mail to Kirk directly. Could someone take a look at this? pst: timeout mfa=0x0032d5d0 cmd=0x02 pst: timeout mfa=0x00336390 cmd=0x02 pst: timeout mfa=0x0034cdd0 cmd=0x02 cut pst: timeout mfa=0x003b7ab0 cmd=0x02 pst: timeout mfa=0x00396db0 cmd=0x02 pst: timeout mfa=0x003a3530 cmd=0x02 pst: timeout mfa=0x00376890 cmd=0x02 This is your storage device getting unhappy, but I'm not really informed enough on pst to say how or why. I don't know if it is because the requests are bad, or because the controller/chain/device is unable to service the request. ufs_access(): Error retrieving ACL on object (5). cut ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). ufs_access(): Error retrieving ACL on object (5). This is the UFS ACL code failing closed: it's unable to read the ACLs from disk due to EIO (I/O failure). This is a correct response to that scenario. Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0xae18c0de fault code = supervisor read, page not present instruction pointer = 0x8:0xc066a566 stack pointer = 0x10:0xea3a78cc frame pointer = 0x10:0xea3a7900 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 76932 (smbd) kernel: type 12 trap, code=0 Stopped at generic_bcopy+0x1a: repe movsl (%esi),%es:(%edi) db trace generic_bcopy(cf6b,1a8,2,c06bd12c,0) at generic_bcopy+0x1a ffs_getextattr(ea3a7960,ea3a795c,c05159ad,d0346200,184) at ffs_getextattr+0xe0 This appears to be a bug in UFS2's handling of corrupted EA data on disk. We have some changes in the TrustedBSD development trees to improve resilience to on-disk corruption, but haven't merged them yet. Just to confirm, could you use gdb -k on a copy of your kernel with debugging symbols to see where *ffs_getextattr+0xe0 is? For me, it turns up in ffs_vnops.c:1616, which is a variable assignment. There's a bcopy not far above there, which seems the likely candidate. vn_extattr_get(cb1a8c8c,8,2,c06bd12c,ea3a79d0) at vn_extattr_get+0xaa ufs_getacl(ea3a7a14,ea3a7a40,c061560b,ea3a7a14,c06df280) at ufs_getacl+0x99 ufs_vnoperate(ea3a7a14,c06df280,2,a6,c853cd10) at ufs_vnoperate+0x18 ufs_access(ea3a7a6c,ea3a7b28,c057dcc9,ea3a7a6c,c0716cc8) at ufs_access+0xca ufs_vnoperate(ea3a7a6c,c0716cc8,c0716cc8,c853cd10,cb1a8c8c) at ufs_vnoperate+0x1 8 vn_open_cred(ea3a7bdc,ea3a7cdc,1a4,d0bb7800,22) at vn_open_cred+0x359 vn_open(ea3a7bdc,ea3a7cdc,1a4,22,c3ee0fb4) at vn_open+0x30 kern_open(c853cd10,bfbff130,0,1,1a4) at kern_open+0x143 open(c853cd10,ea3a7d14,c06c44d0,3ed,3) at open+0x30 syscall(bfbf002f,82b002f,bfbf002f,bfbffd70,82b3724) at syscall+0x28f Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x662b5233, esp = 0xbfbff07c, ebp = 0xbfbff098 --- db show locks exclusive sleep mutex Giant r = 0 (0xc07115c0) locked @ /usr/src/sys/vm/vm_fault .c:223 Holding Giant here is good. So to summarize: This could be the result of a disk read failure. The UFS code appears to be intolerant of said failure. The ACL code failed closed properly, although perhaps not so usefully. 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: [Tillman: Upgraded to latest -current today, boot hangs on ata3: resetting devices]
On 04-Nov-2003 Tillman Hodgson wrote: It occurs to me that this is likely related to the new interrupt code. that tends to imply that the fix is wait a few days and re-cvsup, but I thought folks here would be interested in seeing Sparc64 feedback. The new interrupt code did not affect sparc64, but only i386. -- 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: panic when going multiuser
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? -- 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]
sed behaving badly?
I got this nonsensical error from sed while trying to update python: /usr/bin/sed -i.bak -e 's,/usr/doc/python-docs-,/usr/local/share/doc/python,g' /usr/ports/lang/python/work/Python-2.3.2/Lib/pydoc.py sed: /usr/ports/lang/python/work/Python-2.3.2/Lib/pydoc.py: No such file or directory But the file DOES exist, and furthermore the same port compiles just fine on -CURRENT from November 1. I think the recent changes to sed may have broken something, but I don't know how, exactly. Anyone else seeing this problem? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Floppy drive not found by RELENG_5_1
Ok,
to get back a working and floppydrive detection on FreeBSD/alpha:
What's about the attached patch?
I moved in fd_probe()
if (fd-type == FDT_NONE (fd-fdu == 0 || fd-fdu == 1)) {
out of the
#if defined(__i386__) || defined(__amd64__)
block and created an #else section (like it was in RELENG_4) where the
fd-type is set to 144 by force.
Why not just re-create the #else block? Why moving the if statement out of
the #ifdef block? Doing it that way, it's still possible to set
hint.fd.0.flags for example to 3 (720KB Floppy), and only set the 1.44M
type as a fallback when flags is NULL (FDT_NONE) which means in that case,
hint.fd.0.flags isn't defined. (Because we don't query the BIOS as we do
it for x86 to get the info what kind of floppy is attached to fdc.)
Greetings, Oliver
--
Oliver Lehmann
@home: [EMAIL PROTECTED]
@office: [EMAIL PROTECTED]
@www: http://www.pofo.de/ | http://wishlist.ans-netz.de/
src::sys::isa::fd.c
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: xl0 watchdog timeout
Subject: RE: xl0 watchdog timeout, On Tue, 04 Nov 2003 12:23:19 -0500 (EST), John Baldwin wrote: Try disabling ACPI. ACPI is unable to route any of your PCI interrupts, I tried disabling ACPI. It works fine. Thanks John. so all your PCI interrupts are hosed. You can try to talk with the folks on acpi-jp@ to figure out if your AML can be patched. OK. I will try to talk with the folks on acpi-jp. -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DRM error messages - easy way to turn them off?
I've gone ahead and made it a debug message again in -current. It's Worked. I now get kernel: info: [drm] Initialized rdeon 1.9.0 20020828 on minor 0 kernel: drm0: [MPSAFE] Thanks! Mike Squires SM P6DGH/AiW 7200 ___ [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 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. How long have you been seeing this? Are you using a usb mouse? Can you try with PS/2 if you are? Thanks, Jeff Ciao, Sheldon. ___ [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: [Tillman: Upgraded to latest -current today, boot hangs on ata3: resetting devices]
On Tue, Nov 04, 2003 at 02:20:19PM -0500, John Baldwin wrote: On 04-Nov-2003 Tillman Hodgson wrote: It occurs to me that this is likely related to the new interrupt code. that tends to imply that the fix is wait a few days and re-cvsup, but I thought folks here would be interested in seeing Sparc64 feedback. The new interrupt code did not affect sparc64, but only i386. Noted, I'll take this back to [EMAIL PROTECTED] Thanks for the info, -T -- Page 12: Unix is a set of tools for smart people. - Harley Hahn, _The Unix Companion_ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bug: nmount(2) lacks parameter checking.
Hi,
Looking over the code for nmount(), I think I noticed a few bugs.
(tried send-pr, but the lack of a web-front-end at freebsd.org,
and a decent mail system locally means that's not a runner)
nmount() calls vfs_nmount() pretty much directly after copying in
the io vector from userland.
vfs_nmount() then calls vfs_buildopts() as the first thing it does.
There's a couple of problems here. Firstly, there's no check up to
this point that the user passing the options in is indeed root. So,
all the bugs mentioned can be tickled by a non-root user.
vfs_buildopts doesn't ensure that the option's name is a null
terminated string, but, it later calls vfs_sanitizeopts(), which
assumes this. By passing in strings just at and just over the
pagesize, a non-root user can cause a crash in vfs_buildopts
reasonably reliably when strcmp to hit an unmappped page. (Program
available on request)
vfs_buildopts also leaks memory if it jumps to bad: anything in
the current option is lost to the woods.
There's also no checking on how much memory is actually aquired by
vfs_buildopts(): it can be passed up to MAX_IOVCOUNT (1024) elements
in the iovec, and each of these can be up to 64K in size. That's
64M of memory, plus some overhead for option structures, which would
be a lot to start chewing up in the kernel.
The source I based these observations on is from today, while my
kernel is a few weeks old, and I no longer have source for it.
Given the traffic on the list recently, I figure now is Not A Good
Time to install a fresh kernel, so the patch attached is tested to
the point that it compiles, but I think something like it is
required.
Index: kern/vfs_mount.c
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/kern/vfs_mount.c,v
retrieving revision 1.111
diff -u -r1.111 vfs_mount.c
--- kern/vfs_mount.c26 Sep 2003 09:07:27 - 1.111
+++ kern/vfs_mount.c4 Nov 2003 21:46:44 -
@@ -246,6 +246,8 @@
struct vfsopt *opt;
unsigned int i, iovcnt;
int error, namelen, optlen;
+ size_t memTotal = 0;
+ static const size_t maxMemTotal = 1024 * 64;
iovcnt = auio-uio_iovcnt;
opts = malloc(sizeof(struct vfsoptlist), M_MOUNT, M_WAITOK);
@@ -256,6 +258,26 @@
optlen = auio-uio_iov[i + 1].iov_len;
opt-name = malloc(namelen, M_MOUNT, M_WAITOK);
opt-value = NULL;
+ opt-len = optlen;
+
+ /*
+* Do this early, so jumps to bad will free the current
+* option
+*/
+ TAILQ_INSERT_TAIL(opts, opt, link);
+ memTotal += sizeof (struct vfsopt) + optlen + namelen;
+
+ /*
+* Avoid consuming too much memory, and attempts to overflow
+* memTotal
+*/
+ if (memTotal maxMemTotal ||
+ optlen maxMemTotal ||
+ namelen maxMemTotal) {
+ error = EINVAL;
+ goto bad;
+ }
+
if (auio-uio_segflg == UIO_SYSSPACE) {
bcopy(auio-uio_iov[i].iov_base, opt-name, namelen);
} else {
@@ -264,7 +286,11 @@
if (error)
goto bad;
}
- opt-len = optlen;
+ /* Ensure names are null-terminated strings */
+ if (opt-name[namelen - 1] != '\0') {
+ error = EINVAL;
+ goto bad;
+ }
if (optlen != 0) {
opt-value = malloc(optlen, M_MOUNT, M_WAITOK);
if (auio-uio_segflg == UIO_SYSSPACE) {
@@ -277,7 +303,6 @@
goto bad;
}
}
- TAILQ_INSERT_TAIL(opts, opt, link);
}
vfs_sanitizeopts(opts);
*options = opts;
___
[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 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 ? 2. What is MADT ? Thanks - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
hw.ata.atapi_dma problem
Salve, with today's -current (~21:30 UTC) I get hw.ata.atapi_dma listed again. But it's said to be 1 so dma should be enabled I think. dmesg says: Timecounters tick every 1.000 msec GEOM: create disk ad0 dp=0xc2d97570 ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100 acd0: CDROM SONY CDU4811 at ata1-master PIO4 pcm0: measured ac97 link rate at 55928 Hz So dma is NOT enabled although the sysctl is 1 atacontrol mode 1 also tells PIO4 After atacontrol mode 1 udma33 udma33 I get udma33 returned. So whats's the truth? I think my cd-rom should be able to work in dma mode. Mode tells me no dma is used and sysctl the opposite. Of course I have the sysctl enabled in loader.conf! Thanks, -Harry pgp0.pgp Description: signature
Re: hw.ata.atapi_dma problem
On Tue, 4 Nov 2003, Harald Schmalzbauer wrote: ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100 acd0: CDROM SONY CDU4811 at ata1-master PIO4 So dma is NOT enabled although the sysctl is 1 For ATAPI devices you need hw.ata.atapi_dma=1. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Was: More ULE bugs fixed. Is: Mouse problem?
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hw.ata.atapi_dma problem
On Tuesday 04 November 2003 23:11, Lukas Ertl wrote: On Tue, 4 Nov 2003, Harald Schmalzbauer wrote: ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100 acd0: CDROM SONY CDU4811 at ata1-master PIO4 So dma is NOT enabled although the sysctl is 1 For ATAPI devices you need hw.ata.atapi_dma=1. That's exactly what one line shows in my loader.conf And sysctl hw.ata.atapi_dma returns 1. But atacontrol mode 1 tells me PIO4 And also dmesg tells me PIO4! That's the problem! -Harry regards, le pgp0.pgp Description: signature
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Tue, Nov 04, 2003 at 11:13:26PM +0100, Morten Johansen wrote: 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... Yes, I have had this problem for a while now also. I have sent mail to current@ a while ago. Date: Thu, 2 Oct 2003 18:31:36 +0930 From: Alex Wilkinson [EMAIL PROTECTED] Subject: sec:u kernel: psmintr: out of sync To: [EMAIL PROTECTED] Hi all, I am switching between several OS's with a Cybex KVW switch. I now seem to have a problem with my mouse (after build world/kernel). FreeBSD 5.1-CURRENT #2: Wed Aug 20 13:28:54 CST 2003 I am getting these messages on the console when I move my mouse, the cursor moves in a very choppy motion (painfully slow). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (2). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: discard a byte (3). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: re-enable the mouse. Oct 1 09:46:18 squirm kernel: psm: DISABLE_DEV return code:00fa Oct 1 09:46:18 squirm kernel: psm: ENABLE_DEV return code:00fa Oct 1 09:46:20 squirm kernel: psmintr: out of sync ( != 0008). moused is running with the following: moused -p /dev/psm0 -t auto The mouse is a Microsoft IntelliMouse connected to the KVM via a USB-PS/2 adapter. If I boot the same machine into -STABLE this does *not* happen. I have tryed running moused with different protocols without any luck. Can anyone help me solve this problem ? I have to run -STABLE if I can't solve this problem, so any help would be appreciated. Thanks - aW p.s the mouse works fine with: FreeBSD -STABLE, RH Linux, Irix 6.5.20, Tru64, and WinXP. ___ [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-04 22:43:43 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-04 22:43:43 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-11-04 22:43:43 - 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-04 22:45:49 - 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 [...] yacc -d -p pcapyy -o grammar.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/grammar.y ln -sf grammar.h tokdefs.h lex -t -Ppcapyy /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/scanner.l scanner.c sed 's/.*/char pcap_version[] = ;/' /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/VERSION version.c rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -Dyylval=pcapyylval -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap -I. -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap grammar.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/pcap.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/inet.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/gencode.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/optimize.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/etherent.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/lib! pcap/savefile.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libpcap/../../contrib/libpcap/bpf_image.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/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 /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-11-04 23:13:13 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-04 23:13:13 - TB --- ERROR: failed to build world TB --- 2003-11-04 23:13:13 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
I've had this problem on my laptop since I bought it last year and started running -current. It's annoying, but luckily doesn't happen very often. My gut feeling here is that the psm driver isn't servicing its interrupts fast enough and characters are being dropped out of the FIFO. Maybe it's time to take the psm driver to task and figure out how to make it fast. Scott On Wed, 5 Nov 2003, Alex Wilkinson wrote: On Tue, Nov 04, 2003 at 11:13:26PM +0100, Morten Johansen wrote: 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... Yes, I have had this problem for a while now also. I have sent mail to current@ a while ago. Date: Thu, 2 Oct 2003 18:31:36 +0930 From: Alex Wilkinson [EMAIL PROTECTED] Subject: sec:u kernel: psmintr: out of sync To: [EMAIL PROTECTED] Hi all, I am switching between several OS's with a Cybex KVW switch. I now seem to have a problem with my mouse (after build world/kernel). FreeBSD 5.1-CURRENT #2: Wed Aug 20 13:28:54 CST 2003 I am getting these messages on the console when I move my mouse, the cursor moves in a very choppy motion (painfully slow). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (1). Oct 1 09:46:17 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:17 squirm kernel: psmintr: discard a byte (2). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: discard a byte (3). Oct 1 09:46:18 squirm kernel: psmintr: out of sync ( != 0008). Oct 1 09:46:18 squirm kernel: psmintr: re-enable the mouse. Oct 1 09:46:18 squirm kernel: psm: DISABLE_DEV return code:00fa Oct 1 09:46:18 squirm kernel: psm: ENABLE_DEV return code:00fa Oct 1 09:46:20 squirm kernel: psmintr: out of sync ( != 0008). moused is running with the following: moused -p /dev/psm0 -t auto The mouse is a Microsoft IntelliMouse connected to the KVM via a USB-PS/2 adapter. If I boot the same machine into -STABLE this does *not* happen. I have tryed running moused with different protocols without any luck. Can anyone help me solve this problem ? I have to run -STABLE if I can't solve this problem, so any help would be appreciated. Thanks - aW p.s the mouse works fine with: FreeBSD -STABLE, RH Linux, Irix 6.5.20, Tru64, and WinXP. ___ [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: More ULE bugs fixed.
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. That is indeed interesting. When I return to 4BSD, everything works very nicely. Perhaps this is some interrupt issue or something? I'll recompile tonight and try with a new kernel (new interrupt stuff for i386 has been checked in recently) and report back. Sorry about the (possibly) false alarm! /Eirik Ciao, Sheldon. ___ [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: Was: More ULE bugs fixed. Is: Mouse problem?
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... 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 ___ [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: Was: More ULE bugs fixed. Is: Mouse problem?
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? /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 ___ [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] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
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? Oh and just to add to the goods/bads: A make -j 16 buildworld still makes the box sluggish when it gets to the crypto stuff, but not anywhere close to what it was like before. I'd say it probably matches or beats ULE now. And one *major* thing: I can now play sound again! Without clicks or pops like I've had since 5.1-RELEASE .. I can play sound for real! *meep* *meep* what a relief! This upped my QOL (quality-of-life) quite significantly, given that I haven't been able to play music (wihout being annoyed beyond what is good for me or anyone else near) since, what, spring? *phew* Thanks, to whomever of you guys made this possible... /Eirik /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 ___ [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] ___ [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: Was: More ULE bugs fixed. Is: Mouse problem?
On Wed, Nov 05, 2003 at 12:27:04AM +0100, 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... Question: How can I find out what verion of SCHED_ULE I am running ? - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Was: More ULE bugs fixed. Is: Mouse problem?
Alex Wilkinson wrote: On Wed, Nov 05, 2003 at 12:27:04AM +0100, 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... Question: How can I find out what verion of SCHED_ULE I am running ? I asked the same recently, and here's what I know: - check /usr/src/sys/kern/sched_ule.c - a page or so down there's a line with the revision - ident /boot/kernel/kernel | grep sched_ule /Eirik - aW ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic with today's -current
Sorry, all I have are these lines from messages. I returned and saw that the machine had rebooted. Nothing more: Nov 5 02:46:42 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 5 02:46:42 cale kernel: instruction pointer= 0x8:0xc054c85d Nov 5 02:46:42 cale kernel: stack pointer = 0x10:0xcdc9dbe0 Nov 5 02:46:42 cale kernel: frame pointer = 0x10:0xcdc9dbe4 Nov 5 02:46:42 cale kernel: code segment = base 0x0, limit 0xf, type 0x1b Nov 5 02:46:42 cale kernel: = DPL 0, pres 1, def32 1, gran 1 Nov 5 02:46:42 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 02:46:42 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 02:46:42 cale kernel: trap number= 30 Nov 5 02:46:42 cale kernel: panic: unknown/reserved trap Nov 5 02:46:42 cale kernel: Nov 5 02:46:42 cale kernel: syncing disks, buffers remaining... 2202 2202 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 Nov 5 02:46:42 cale kernel: giving up on 1066 buffers Nov 5 02:46:42 cale kernel: Uptime: 3h15m57s Nov 5 02:46:42 cale kernel: Shutting down ACPI Nov 5 02:46:42 cale kernel: stray irq9 Nov 5 02:46:42 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 02:46:42 cale kernel: Rebooting... pgp0.pgp Description: signature
Re: Was: More ULE bugs fixed. Is: Mouse problem?
On Wed, 5 Nov 2003, Eirik Oeverby wrote: Alex Wilkinson wrote: On Wed, Nov 05, 2003 at 12:27:04AM +0100, 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... Question: How can I find out what verion of SCHED_ULE I am running ? I asked the same recently, and here's what I know: - check /usr/src/sys/kern/sched_ule.c - a page or so down there's a line with the revision - ident /boot/kernel/kernel | grep sched_ule Ident also works on source files. Cheers, Jeff /Eirik - aW ___ [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: Was: More ULE bugs fixed. Is: Mouse problem?
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. 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 ___ [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] ___ [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]
Best Way To Get to current -CURRENT
I have a new system (IBM ThinkPad T40 (gorgeous, too :)). In order to use the WiFi card (ath) I need to install -current. What's the accepted best way? 1) Install 5.1-RELEASE and cvsup from there. 2) Install 5-1-CURRENT snapshot and cvsup to real current. 3) Something else I haven't thought of. 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: Fix for WINE on -CURRENT
Hello! On Mon, Nov 03, 2003 at 11:14:03PM -0600, Scot W. Hetzel wrote: Below is a patch to fix WINE for the new ATA driver. I created this patch based on the ideals from a previous user who had patched 3 other ports to work with -CURRENT's new ATA driver. Could someone familar with the new ATA driver have a look at this patch to make sure it is correct. can you make a patch for cdparanoia as well? cdparanoia is also broken on recent -CURRENT and testing will be easy. /fjoe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best Way To Get to current -CURRENT
On 2003-11-04 19:51 -0800, Jeffrey Katcher wrote: I have a new system (IBM ThinkPad T40 (gorgeous, too :)). In order to use the WiFi card (ath) I need to install -current. What's the accepted best way? 1) Install 5.1-RELEASE and cvsup from there. 2) Install 5-1-CURRENT snapshot and cvsup to real current. 3) Something else I haven't thought of. Though there is no real best practice, I prefer to install a recent JPSNAP and take it from there. -- Munish Chopra ___ [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
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}.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/57226
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
Simon
signature.asc
Description: Digital signature
[current tinderbox] failure on alpha/alpha
TB --- 2003-11-05 05:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-05 05:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-11-05 05:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-05 05:03:31 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/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 [...] yacc -d -p pcapyy -o grammar.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/grammar.y ln -sf grammar.h tokdefs.h lex -t -Ppcapyy /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/scanner.l scanner.c sed 's/.*/char pcap_version[] = ;/' /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/VERSION version.c rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -Dyylval=pcapyylval -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap -I. -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap grammar.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/pcap.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/inet.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/gencode.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/optimize.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/etherent.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpc! ap/../../contrib/libpcap/savefile.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/libpcap/../../contrib/libpcap/bpf_image.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/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 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-11-05 05:30:00 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-05 05:30:00 - TB --- ERROR: failed to build world TB --- 2003-11-05 05:30:00 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on amd64/amd64
TB --- 2003-11-05 05:30:02 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-05 05:30:02 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-11-05 05:30:02 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-05 05:31:59 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/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 [...] yacc -d -p pcapyy -o grammar.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/grammar.y ln -sf grammar.h tokdefs.h lex -t -Ppcapyy /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/scanner.l scanner.c sed 's/.*/char pcap_version[] = ;/' /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/VERSION version.c rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -Dyylval=pcapyylval -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap -I. -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap grammar.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/pcap.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/inet.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/gencode.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/optimize.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/etherent.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpc! ap/../../contrib/libpcap/savefile.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libpcap/../../contrib/libpcap/bpf_image.c /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/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 /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src. TB --- 2003-11-05 05:58:19 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-05 05:58:19 - TB --- ERROR: failed to build world TB --- 2003-11-05 05:58:19 - tinderbox aborted ___ [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/i386
TB --- 2003-11-05 05:58:20 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-11-05 05:58:20 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-11-05 05:58:20 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-11-05 06:00:21 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/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 [...] yacc -d -p pcapyy -o grammar.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/grammar.y ln -sf grammar.h tokdefs.h lex -t -Ppcapyy /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/scanner.l scanner.c sed 's/.*/char pcap_version[] = ;/' /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/VERSION version.c rm -f .depend mkdep -f .depend -a-DHAVE_CONFIG_H -Dyylval=pcapyylval -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap -I. -DINET6 -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap grammar.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/pcap-bpf.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/pcap.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/inet.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/gencode.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/optimize.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/etherent.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/lib! pcap/savefile.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/bpf/net/bpf_filter.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/libpcap/../../contrib/libpcap/bpf_image.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/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 /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-11-05 06:25:33 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-11-05 06:25:33 - TB --- ERROR: failed to build world TB --- 2003-11-05 06:25:33 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
buildworld failure: don't know how to make thr_atfork.c
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]
Re: HELP: ServerWorks data corruption after 350 MB with BerkeleyD B 4.0?
It seems Anshuman Kanwar wrote: Ehem, this machine is NOT ServerWorks based, its Intel... rack2-102.nyc# pciconf -l [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x254c8086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x060400 card=0x chip=0x25438086 rev=0x01 hdr=0x01 [EMAIL PROTECTED]:3:0: class=0x060400 card=0x chip=0x25458086 rev=0x01 hdr=0x01 [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x24808086 chip=0x24828086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 rev=0x42 hdr=0x01 [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24808086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:31:1: class=0x01018a card=0x24808086 chip=0x248b8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:31:3:class=0x0c0500 card=0x24808086 chip=0x24838086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:28:0:class=0x080020 card=0x14618086 chip=0x14618086 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:29:0:class=0x060400 card=0x0050 chip=0x14608086 rev=0x04 hdr=0x01 [EMAIL PROTECTED]:30:0:class=0x080020 card=0x14618086 chip=0x14618086 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:31:0:class=0x060400 card=0x0050 chip=0x14608086 rev=0x04 hdr=0x01 [EMAIL PROTECTED]:1:0: class=0x02 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:1:1: class=0x02 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:28:0:class=0x080020 card=0x14618086 chip=0x14618086 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:29:0:class=0x060400 card=0x0050 chip=0x14608086 rev=0x04 hdr=0x01 [EMAIL PROTECTED]:30:0:class=0x080020 card=0x14618086 chip=0x14618086 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:31:0:class=0x060400 card=0x0050 chip=0x14608086 rev=0x04 hdr=0x01 [EMAIL PROTECTED]:1:0: class=0x02 card=0x10408086 chip=0x12298086 rev=0x10 hdr=0x00 [EMAIL PROTECTED]:2:0: class=0x03 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
