Re: More ULE bugs fixed.
On Wed, 15 Oct 2003, Jeff Roberson wrote: I fixed two bugs that were exposed due to more of the kernel running outside of Giant. ULE had some issues with priority propagation that stopped it from working very well. Things should be much improved. Feedback, as always, is welcome. I'd like to look into making this the default scheduler for 5.2 if things start looking up. I hope that scares you all into using it more. :-) How would one test if it was an improvement on the 4BSD scheduler? It is not even competitive in my simple tests. 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 130.51 real60.97 user34.63 sys 390.68 real 310.78 user60.55 sys Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. It apparently misses many oppurtunities to actually run useful processes. This may be related to /usr being nfs mounted. There is lots of idling waiting for nfs even in the SCHED_4BSD case. The system times are smaller for SCHED_ULE, but this might not be significant. E.g., zeroing pages can account for several percent of the system time in buildworld, but on unbalanced systems that have too much idle time most page zero gets done in idle time and doesn't show up in the system time. Test 1 for fair scheduling related to niceness: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 do nice -$i sh -c while :; do echo -n;done done top -o time [Output deleted]. This shows only a vague correlation between niceness and runtime for SCHED_ULE. However, top -o cpu shows a strong correlation between %CPU and niceness. Apparently, %CPU is very innacurate and/or not enough history is kept for long-term scheduling to be fair. Test 5 for fair scheduling related to niceness: for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 do nice -$i sh -c while :; do echo -n;done done time top -o cpu With SCHED_ULE, this now hangs the system, but it worked yesterday. Today it doesn't get as far as running top and it stops the nfs server responding. To unhang the system and see what the above does, run a shell at rtprio 0 and start top before the above, and use top to kill processes (I normally use killall sh to kill all the shells generated by tests 1-5, but killall doesn't work if it is on nfs when the nfs server is not responding). Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
DRM SMPng locking for review
I've been working on locking of the DRM, based off of the work that was already done for linux and ported to BSD. I think the current locking was wrong, including that it used lockmgr and simplelocks on -stable when as far as I know it was unnecessary. Also, I had marked the IRQ handlers MPSAFE without understanding the issue really, so IRQs could get missed. Here's a patch, which I hope someone can review because I don't trust myself at all. http://people.freebsd.org/~anholt/dri/files/drm-locking-2.diff It's against DRI CVS, as I haven't merged to FreeBSD in a while. You can get it using the instructions at: http://dri.sourceforge.net/cgi-bin/moin.cgi/CVS If you don't want to build the whole tree, you can just: cd xc patch -p0 ~/drm-locking-2.diff cd programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel ln -s ../../../shared/drm/kernel/*.[ch] ./ Quick question: If open returns an error, close doesn't get called, does it? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On Fri, 17 Oct 2003, Bruce Evans wrote: How would one test if it was an improvement on the 4BSD scheduler? It is not even competitive in my simple tests. [scripts results deleted] Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. It apparently misses many oppurtunities to actually run useful processes. This may be related to /usr being nfs mounted. There is lots of idling waiting for nfs even in the SCHED_4BSD case. The system times are smaller for SCHED_ULE, but this might not be significant. E.g., zeroing pages can account for several percent of the system time in buildworld, but on unbalanced systems that have too much idle time most page zero gets done in idle time and doesn't show up in the system time. At one point ULE was at least as fast as 4BSD and in most cases faster. This is a regression. I'll sort it out soon. Test 1 for fair scheduling related to niceness: for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 do nice -$i sh -c while :; do echo -n;done done top -o time [Output deleted]. This shows only a vague correlation between niceness and runtime for SCHED_ULE. However, top -o cpu shows a strong correlation between %CPU and niceness. Apparently, %CPU is very innacurate and/or not enough history is kept for long-term scheduling to be fair. Test 5 for fair scheduling related to niceness: for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 do nice -$i sh -c while :; do echo -n;done done time top -o cpu With SCHED_ULE, this now hangs the system, but it worked yesterday. Today it doesn't get as far as running top and it stops the nfs server responding. To unhang the system and see what the above does, run a shell at rtprio 0 and start top before the above, and use top to kill processes (I normally use killall sh to kill all the shells generated by tests 1-5, but killall doesn't work if it is on nfs when the nfs server is not responding). 661 root 112 -20 900K 608K RUN 0:24 27.80% 27.64% sh 662 root 114 -16 900K 608K RUN 0:19 12.43% 12.35% sh 663 root 114 -12 900K 608K RUN 0:15 10.66% 10.60% sh 664 root 114 -8 900K 608K RUN 0:11 9.38% 9.33% sh 665 root 115 -4 900K 608K RUN 0:10 7.91% 7.86% sh 666 root 1150 900K 608K RUN 0:07 6.83% 6.79% sh 667 root 1154 900K 608K RUN 0:06 5.01% 4.98% sh 668 root 1158 900K 608K RUN 0:04 3.83% 3.81% sh 669 root 115 12 900K 608K RUN 0:02 2.21% 2.20% sh 670 root 115 16 900K 608K RUN 0:01 0.93% 0.93% sh I think you cvsup'd at a bad time. I fixed a bug that would have caused the system to lock up in this case late last night. On my system it freezes for a few seconds and then returns. I can stop that by turning down the interactivity threshold. Thanks, Jeff Bruce ___ [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: hiding e-mail adresses needed badly
[This may get duplicated if my outgoing work e-mail gets fixed] On 2003-Oct-16 11:29:36 -0700, Terry Lambert [EMAIL PROTECTED] wrote: Earthlink often sucks in terms of customer service. If they would just designate a couple of common markers as known SPAM, the problem would have gone away There's a fine line between 'blocking a couple of common markers' and arbitrarily blocking domains, IP addresses and all mails containing specific words - which some large ISPs do. What's needed is a filter system that allows users to control what they receive - not one where the ISP gets to decide what is/isn't delivered. When W32.Swen first hit, I was getting mailbox near quota messages if I didn't empty my home mailbox for about 8 hours. I asked my ISP when they would be implementing something to let me control what was delivered into my mailbox and eventually managed to get a we're looking into the problem response. I started running fetchmail as a work-around (which stops the quota DOS but does nothing to help my download bandwidth). AFAIK, they still haven't done anything. And Australia's biggest ISP (Telstra BigPond) is currently getting unfavourable mentions in Parliament and the media because it's e-mail system can't cope - users are claiming e-mails are being delayed a week or more, or just aren't arriving. people forced to use Earthlink (forced, because no matter where I go, Earthlink buys up my damn ISP -- no one talks about *that* monocoluture being a threat). Mumble years ago, I heard a talk on this phenomenom. They problem boils down to ISP interconnect agreements - they generally wind up meaning the small ISP has to pay the big ISP (or Internet wholesaler) whatever the big ISP asks because their customers need to exchange packets with IP addresses owned by the big ISP and the big ISP doesn't have as much incentive to route packets to the smaller ISP. This is a positive feedback loop with the bigger ISP absorbing all the smaller ones. This is an inherent flaw in a store-with-quota+pickup-transiently model, which is what any POP3/IMAP4 forces their users into, and that means *any* ISP, even ones that give you full time connections, when they refuse to let you run your own mail server, either by explicitly disallowing it, or by not providing you a static IP. Optus Internet (my home ISP) state that they block incoming traffic to TCP/25 to prevent them being being black-listed for allowing people to run promiscuous SMTP relays. This is probably at least partly true. A non-quotaed maildrop would fix it. How do you stop the weenies never deleting e-mail so their mailboxes grow indefinitely? A better solution would be a soft-quota'd maildrop. As long as you get to it every few days you don't get DOS'd but if you never delete your mail you get bitten. Of course, from an ISP perspective, there's the problem of several thousand mailboxes each receiving several hundred 200KB mails each day - that's an awful lot of maildrop disk space to have to find in a hurry. Can you imagine if someone wrote one of these things to *actively* target an ISP with a stupid network topology like Earthlink? Do you know of any ISPs that do a better job of upstream filtering? You could drive the company out of business by chasing all their subscribers away by denying them the ability to receive communications from almost anyone else on the Internet. I'm really surprised these idiots are unwilling to do anything about saving their business model from extinction. The problem is that it doesn't really hurt the ISP - they (typically) charge for downlink usage, so they're making more money by not blocking SPAM. The customers have to put up with it because they know the competing ISPs aren't any better. Death of USENET predicted ... Film at 11 can probably be updated. Peter ___ [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 Fri, 17 Oct 2003, Bruce Evans wrote: On Fri, 17 Oct 2003, Jeff Roberson wrote: On Fri, 17 Oct 2003, Bruce Evans wrote: How would one test if it was an improvement on the 4BSD scheduler? It is not even competitive in my simple tests. ... At one point ULE was at least as fast as 4BSD and in most cases faster. This is a regression. I'll sort it out soon. How much faster? Apache benchmarked at 30% greater throughput due the cpu affinity some time ago. I haven't done more recent tests with apache. buildworld is the most degenerate case for per cpu run queues because cpu affinity doesn't help much and load imbalances hurt a lot. On my machine the compiler hardly ever wants to run for more than a few slices before doing a msleep() so it's not bouncing around between CPUs so much with 4BSD. Test 5 for fair scheduling related to niceness: for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 do nice -$i sh -c while :; do echo -n;done done time top -o cpu With SCHED_ULE, this now hangs the system, but it worked yesterday. Today it doesn't get as far as running top and it stops the nfs server responding. 661 root 112 -20 900K 608K RUN 0:24 27.80% 27.64% sh 662 root 114 -16 900K 608K RUN 0:19 12.43% 12.35% sh 663 root 114 -12 900K 608K RUN 0:15 10.66% 10.60% sh 664 root 114 -8 900K 608K RUN 0:11 9.38% 9.33% sh 665 root 115 -4 900K 608K RUN 0:10 7.91% 7.86% sh 666 root 1150 900K 608K RUN 0:07 6.83% 6.79% sh 667 root 1154 900K 608K RUN 0:06 5.01% 4.98% sh 668 root 1158 900K 608K RUN 0:04 3.83% 3.81% sh 669 root 115 12 900K 608K RUN 0:02 2.21% 2.20% sh 670 root 115 16 900K 608K RUN 0:01 0.93% 0.93% sh Perhaps the bug only affects SMP. The above is for UP (no CPU column). That is likely, I don't use my SMP machine much anymore. I should setup some automated tests. I see a large difference from the above, at least under SMP: %CPU tapers off to 0 at nice 0. BTW, I just noticed that SCHED_4BSD never really worked for the SMP case. sched_clock() is called for each CPU, and for N CPU's this has the same effect as calling sched_clock() N times too often for 1 CPU. Calling sched_clock() too often was fixed for the UP case in kern_synch.c 1.83 by introducing a scale factor. The scale factor is fixed so it doesn't help for SMP. Wait.. why are we calling sched_clock() too frequently on UP? I think you cvsup'd at a bad time. I fixed a bug that would have caused the system to lock up in this case late last night. On my system it freezes for a few seconds and then returns. I can stop that by turning down the interactivity threshold. No, I tested with an up to date kernel (sched_ule.c 1.65). Curious. ULE seems to have suffered from bitrot. These things were all tested and working when I did my paper for BSDCon. I have largely neglected FreeBSD since. I can't fix it this weekend, but I'm sure I'll sort it out next weekend. Cheers, Jeff Bruce ___ [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.
I think you cvsup'd at a bad time. I fixed a bug that would have caused the system to lock up in this case late last night. On my system it freezes for a few seconds and then returns. I can stop that by turning down the interactivity threshold. Hrm, I must concur that while ULE seems a tad snappier on the responsiveness end, it seems to be lacking in terms of real world performance compared to 4BSD. Fresh CVSup (~midnight 2003-10-17) and build with a benchmark from before and after. I was benchmarking a chump calc program using bison vs. lemon earlier today under 4BSD (http://groups.yahoo.com/group/sqlite/message/5506) and figured I'd throw my hat in on the subject with some relative numbers. System time is down for ULE, but user and real are up. Under ULE: Running a dry run with bison calc...done. Running 1st run with bison calc... 52.11 real 45.63 user 0.56 sys Running 2nd run with bison calc... 52.16 real 45.52 user 0.69 sys Running 3rd run with bison calc... 51.80 real 45.32 user 0.87 sys Running a dry run with lemon calc...done. Running 1st run with lemon calc... 129.69 real 117.91 user 1.10 sys Running 2nd run with lemon calc... 130.26 real 117.88 user 1.13 sys Running 3rd run with lemon calc... 130.76 real 117.90 user 1.10 sys Time spent in user mode (CPU seconds) : 654.049s Time spent in kernel mode (CPU seconds) : 7.047s Total time : 12:19.06s CPU utilization (percentage): 89.4% Times the process was swapped : 0 Times of major page faults : 34 Times of minor page faults : 2361 And under 4BSD: Running a dry run with bison calc...done. Running 1st run with bison calc... 44.22 real 37.94 user 0.85 sys Running 2nd run with bison calc... 46.21 real 37.98 user 0.85 sys Running 3rd run with bison calc... 45.32 real 38.13 user 0.67 sys Running a dry run with lemon calc...done. Running 1st run with lemon calc... 116.53 real 100.10 user 1.13 sys Running 2nd run with lemon calc... 112.61 real 100.35 user 0.86 sys Running 3rd run with lemon calc... 114.16 real 100.19 user 1.04 sys Time spent in user mode (CPU seconds) : 553.392s Time spent in kernel mode (CPU seconds) : 6.978s Total time : 10:40.80s CPU utilization (percentage) : 87.4% Times the process was swapped : 223 Times of major page faults : 50 Times of minor page faults : 2750 Just a heads up, it does indeed look as thought hings have gone backwards in terms of performance. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_map_wire: lookup failed
On Thu, 16 Oct 2003 22:54:43 +0200 John Hay [EMAIL PROTECTED] wrote: The latest development source of ntpd started to use setrlimit() before using mlockall(). This combination proves fatal on -current. The code in ntpd/ntpd.c looks like this: Ok, I found an easier way to provoke the panic. Just compile the following program like this: if (mlockall(MCL_CURRENT|MCL_FUTURE) 0) perror(mlockall()); Did you tested it on a recent -current? It is supposed to be fixed (since a day or two, I think). Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [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 Fri, 17 Oct 2003, Sean Chittenden wrote: I think you cvsup'd at a bad time. I fixed a bug that would have caused the system to lock up in this case late last night. On my system it freezes for a few seconds and then returns. I can stop that by turning down the interactivity threshold. Hrm, I must concur that while ULE seems a tad snappier on the responsiveness end, it seems to be lacking in terms of real world performance compared to 4BSD. Thanks for the stats. Is this on SMP or UP? Fresh CVSup (~midnight 2003-10-17) and build with a benchmark from before and after. I was benchmarking a chump calc program using bison vs. lemon earlier today under 4BSD (http://groups.yahoo.com/group/sqlite/message/5506) and figured I'd throw my hat in on the subject with some relative numbers. System time is down for ULE, but user and real are up. Under ULE: Running a dry run with bison calc...done. Running 1st run with bison calc... 52.11 real 45.63 user 0.56 sys Running 2nd run with bison calc... 52.16 real 45.52 user 0.69 sys Running 3rd run with bison calc... 51.80 real 45.32 user 0.87 sys Running a dry run with lemon calc...done. Running 1st run with lemon calc... 129.69 real 117.91 user 1.10 sys Running 2nd run with lemon calc... 130.26 real 117.88 user 1.13 sys Running 3rd run with lemon calc... 130.76 real 117.90 user 1.10 sys Time spent in user mode (CPU seconds) : 654.049s Time spent in kernel mode (CPU seconds) : 7.047s Total time : 12:19.06s CPU utilization (percentage): 89.4% Times the process was swapped : 0 Times of major page faults : 34 Times of minor page faults : 2361 And under 4BSD: Running a dry run with bison calc...done. Running 1st run with bison calc... 44.22 real 37.94 user 0.85 sys Running 2nd run with bison calc... 46.21 real 37.98 user 0.85 sys Running 3rd run with bison calc... 45.32 real 38.13 user 0.67 sys Running a dry run with lemon calc...done. Running 1st run with lemon calc... 116.53 real 100.10 user 1.13 sys Running 2nd run with lemon calc... 112.61 real 100.35 user 0.86 sys Running 3rd run with lemon calc... 114.16 real 100.19 user 1.04 sys Time spent in user mode (CPU seconds) : 553.392s Time spent in kernel mode (CPU seconds) : 6.978s Total time : 10:40.80s CPU utilization (percentage) : 87.4% Times the process was swapped : 223 Times of major page faults : 50 Times of minor page faults : 2750 Just a heads up, it does indeed look as thought hings have gone backwards in terms of performance. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: pmap_enter: attempted pmap_enter on 4MB page
Hello,
Yesterday our 5-CURRENT box panicked with panic: pmap_enter: attempted
pmap_enter on 4MB page.
uname -a:
FreeBSD turtle.stack.nl 5.1-CURRENT FreeBSD 5.1-CURRENT #15: Thu Oct 9 11:43:55 CEST
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TURTLE i386
This kernel includes a patch from Sam Leffler to
/usr/src/sys/netinet6/nd6.c to prevent panics which has been committed
now.
Beginning of dmesg:
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 #15: Thu Oct 9 11:43:55 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/TURTLE
Preloaded elf kernel /boot/kernel/kernel at 0xc07e6000.
Preloaded elf module /boot/kernel/acpi.ko at 0xc07e6294.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) MP 2000+ (1666.74-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!
real memory = 1073217536 (1023 MB)
avail memory = 1037123584 (989 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): apic id: 1, version: 0x00040010, at 0xfee0
cpu1 (AP): apic id: 0, version: 0x00040010, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Pentium Pro MTRR support enabled
...
gdb output:
Script started on Fri Oct 17 11:56:23 2003
# gdb -k kernel.debug.13 vmcore.13
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: pmap_enter: attempted pmap_enter on 4MB page
panic messages:
---
panic: pmap_enter: attempted pmap_enter on 4MB page
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks, buffers remaining... 6552 6552 6552 6552 6552 6552 6552 6552 6552 6552
6552 6552 6552 6552 6552 6552 6552 6552 6552 6552
giving up on 374 buffers
Uptime: 3d12h22m57s
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
Reading symbols from
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/fdescfs/fdescfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/fdescfs/fdescfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/TURTLE/modules/usr/src/sys/modules/linux/linux.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04d7041 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04d7498 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0652014 in pmap_enter (pmap=0xc6d6e98c, va=689672192, m=0xc1a33ba0,
prot=5 '\005', wired=0) at /usr/src/sys/i386/i386/pmap.c:1897
#4 0xc0601482 in vm_fault (map=0xc6d6e8dc, vaddr=689672192,
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:903
#5 0xc0655af5 in trap_pfault (frame=0xe6215d48, usermode=1, eva=689675199)
at /usr/src/sys/i386/i386/trap.c:709
#6 0xc0655694 in trap (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134522240, tf_esi = 690202368,
tf_ebp = -1077942584, tf_isp = -434021004, tf_ebx = 689329844, tf_edx = 1, tf_ecx = 0,
tf_eax = 0, tf_trapno = 12, tf_err = 4, tf_eip = 689675199, tf_cs = 31, tf_eflags =
66050, tf_esp = -1077942628, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:317
#7 0xc063d938 in calltrap () at {standard input}:103
---Can't read userspace from dump, or kernel process---
(kgdb) frame 3
#3 0xc0652014 in pmap_enter (pmap=0xc6d6e98c, va=689672192, m=0xc1a33ba0,
prot=5 '\005', wired=0) at /usr/src/sys/i386/i386/pmap.c:1897
1897panic(pmap_enter: invalid page directory pdir=%#jx, va=%#x\n,
(kgdb) l
1892
1893/*
1894 * Page Directory table entry not valid, we need a new PT page
1895 */
1896if (pte == NULL) {
1897panic(pmap_enter: invalid page directory pdir=%#jx, va=%#x\n,
1898
AES is broken.
Hello. After recent changes to AES, GBDE is borken. How to repeat: # mdconfig -a -t malloc -s 16M # gbde init /dev/md0 -L /etc/md0.lock # gbde attach md0 -l /etc/md0.lock # newfs -O2 /dev/md0.bde || echo BROKEN -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: panic: vm_map_wire: lookup failed
The latest development source of ntpd started to use setrlimit() before using mlockall(). This combination proves fatal on -current. The code in ntpd/ntpd.c looks like this: Ok, I found an easier way to provoke the panic. Just compile the following program like this: if (mlockall(MCL_CURRENT|MCL_FUTURE) 0) perror(mlockall()); Did you tested it on a recent -current? It is supposed to be fixed (since a day or two, I think). Nope it is still not fixed. I have tried again just now and it still throw a panic on both UP and SMP. Try for yourself if you are brave. :-))) John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
vinum, ,GEOM, ATANG, or bad disk?
Hi, I'm trying to setup vinum on 2 identical 30G HD's. The MB I'm using has a built in Raid 0 controller, so i have 6 ATA Slots. My Main HD is hooked up to the primary non-raid. and the other 2 are hooked up to primary 1 and primary 2 on the raid. I can get vinum up and running, but when i force a disk failure to see if it can recover, I start to get errors. Here are the steps i'm going through: copy /usr/src to the vinum vol stop mp3s.p1 (2 plex's - p0, p1) delete the contents start mp3s.p1 It starts to recover, then I start getting the following errors: Oct 16 23:00:34 mp3 kernel: ad6: TIMEOUT - WRITE_DMA retrying (2 retries left) Oct 16 23:00:34 mp3 kernel: ata3: resetting devices .. Oct 16 23:00:34 mp3 kernel: done Oct 16 23:00:44 mp3 kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) Oct 16 23:00:44 mp3 kernel: ata3: resetting devices .. Oct 16 23:00:44 mp3 kernel: done Oct 16 23:00:54 mp3 kernel: ata3: resetting devices .. Oct 16 23:00:54 mp3 kernel: done Oct 16 23:00:54 mp3 kernel: ad6: FAILURE - WRITE_DMA timed out Oct 16 23:00:54 mp3 kernel: ad6: FAILURE - WRITE_DMA status=1ERROR error=0 Oct 16 23:00:54 mp3 vinum[517]: can't revive mp3s.p1.s0: Input/output error Oct 16 23:04:18 mp3 kernel: vinum: mp3s.p1.s0 is down by force Oct 16 23:04:18 mp3 kernel: vinum: mp3s.p1 is faulty Oct 16 23:04:28 mp3 kernel: ad6: TIMEOUT - WRITE_DMA retrying (2 retries left) Oct 16 23:04:28 mp3 kernel: ata3: resetting devices .. Oct 16 23:04:28 mp3 kernel: done Oct 16 23:04:38 mp3 kernel: ad6: TIMEOUT - WRITE_DMA retrying (1 retry left) Oct 16 23:04:38 mp3 kernel: ata3: resetting devices .. Oct 16 23:04:38 mp3 kernel: done Oct 16 23:04:48 mp3 kernel: ata3: resetting devices .. Oct 16 23:04:48 mp3 kernel: done Oct 16 23:04:48 mp3 kernel: ad6: FAILURE - WRITE_DMA timed out Oct 16 23:04:48 mp3 kernel: ad6: FAILURE - WRITE_DMA status=1ERROR error=0 Oct 16 23:04:48 mp3 kernel: vinum: Can't write config to /dev/ad6s1d, error 5 Oct 16 23:04:48 mp3 kernel: vinum: drive drive2 is down ad6 is the volume trying to get restored. I'm going to re-setup the volume once I get done zeroing the drives out (incase that could help) and see if I can still reproduce the problem. I believe (one of the things I'll document when i get it set back up), when i type [vinum] info, it identifies the ad4 slice correctly, but comes back as unknown for the ad6 slice (which should be /dev/ad6s1d). FreeBSD 5.1-CURRENT #0: Tue Oct 14 00:33:48 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MP3 I've attached my dmesg. vinum.cfg is below (where i run create -f file) drive drive1 device /dev/ad4s1d drive drive2 device /dev/ad6s1d volume mp3s setupstate plex org concat sd length 0 drive drive1 plex org concat sd length 0 drive drive2 __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.comCopyright (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 #0: Tue Oct 14 00:33:48 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MP3 Preloaded elf kernel /boot/kernel/kernel at 0xc0a0b000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0a0b21c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1311.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x644 Stepping = 4 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 268353536 (255 MB) avail memory = 251019264 (239 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00f1750 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 12 pcib0: slot 4 INTD is routed to irq 12 pcib0: slot 9 INTA is routed to irq 12 pcib0: slot 12 INTA is routed to irq 11 pcib0: slot 17 INTA is routed to irq 10 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 12 at device 4.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,
Re: ata problem with latest current
Hi, Current ATA code is still unusable unstable. We cvsupped latest source yesterday and tried our standard stress test copy between two vinum volumes. Once we even got 12 hour uptime but today it won't take longer than couple minutes before system freezes. Situation is even worse if we replace single port 3com-905-xl0 with znyx-quad-dc0. With this card system won't stay up even a minute. Tomppa clip clip *** Oct 17 10:20:29 tiikeli kernel: smb_iod_recvall: drop resp with mid 10121 Oct 17 13:03:35 tiikeli kernel: ad5: TIMEOUT - READ_DMA retrying (2 retries left) Oct 17 13:03:35 tiikeli kernel: ata2: resetting devices .. Oct 17 13:03:35 tiikeli kernel: ata2: reset tp1 mask=03 ostat0=80 ostat1=80 Oct 17 13:03:35 tiikeli kernel: ad4: stat=0x80 err=0x80 lsb=0x80 msb=0x80 Oct 17 13:03:35 tiikeli kernel: ad5: stat=0x90 err=0x90 lsb=0x90 msb=0x90 Oct 17 13:03:35 tiikeli kernel: ad4: stat=0x90 err=0x90 lsb=0x90 msb=0x90 Oct 17 13:03:35 tiikeli kernel: ad5: stat=0x90 err=0x90 lsb=0x90 msb=0x90 Oct 17 13:03:35 tiikeli kernel: ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 Oct 17 13:03:35 tiikeli kernel: ad5: stat=0x50 err=0x01 lsb=0x00 msb=0x00 Oct 17 13:03:36 tiikeli kernel: ata2: reset tp2 mask=03 stat0=50 stat1=50 devices=0x3ATA_SLAVE,ATA_MASTER Oct 17 13:03:36 tiikeli kernel: ata2: reset tp3 devices=0x3ATA_SLAVE,ATA_MASTER Oct 17 13:03:36 tiikeli kernel: ad5: pio=0x0c wdma=0x22 udma=0x45 cable=80pin Oct 17 13:03:45 tiikeli reboot: rebooted by ramppa clip clip *** Oct 17 16:02:36 tiikeli kernel: WARNING: /v was not properly dismounted Oct 17 16:02:51 tiikeli kernel: /v: superblock summary recomputed Oct 17 16:03:15 tiikeli kernel: WARNING: /mnt was not properly dismounted Oct 17 16:03:36 tiikeli kernel: /mnt: superblock summary recomputed Oct 17 16:20:43 tiikeli kernel: ad6: WARNING - READ_DMA recovered from missing interrupt Oct 17 16:20:50 tiikeli kernel: ad4: WARNING - READ_DMA recovered from missing interrupt Oct 17 16:20:53 tiikeli kernel: ad6: WARNING - READ_DMA recovered from missing interrupt Oct 17 16:21:00 tiikeli kernel: ad4: WARNING - READ_DMA recovered from missing interrupt Oct 17 16:21:03 tiikeli kernel: ad7: WARNING - READ_DMA recovered from missing interrupt Oct 17 16:21:03 tiikeli kernel: ad6: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=4ABORTED Oct 17 16:22:17 tiikeli kernel: ad5: TIMEOUT - READ_DMA retrying (2 retries left) Oct 17 16:22:17 tiikeli kernel: ata2: resetting devices .. Oct 17 16:22:17 tiikeli kernel: ata2: reset tp1 mask=03 ostat0=80 ostat1=80 Oct 17 16:22:17 tiikeli kernel: ad4: stat=0x80 err=0x80 lsb=0x80 msb=0x80 Oct 17 16:22:17 tiikeli kernel: ad5: stat=0x90 err=0x90 lsb=0x90 msb=0x90 Oct 17 16:22:17 tiikeli kernel: ad4: stat=0x90 err=0x90 lsb=0x90 msb=0x90 Oct 17 16:22:17 tiikeli kernel: ad5: stat=0x90 err=0x90 lsb=0x90 msb=0x90 Oct 17 16:22:17 tiikeli kernel: ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 Oct 17 16:22:17 tiikeli kernel: ad5: stat=0x50 err=0x01 lsb=0x00 msb=0x00 Oct 17 16:22:17 tiikeli kernel: ata2: reset tp2 mask=03 stat0=50 stat1=50 devices=0x3ATA_SLAVE,ATA_MASTER Oct 17 16:22:17 tiikeli kernel: ata2: reset tp3 devices=0x3ATA_SLAVE,ATA_MASTER Oct 17 16:22:17 tiikeli kernel: ad5: pio=0x0c wdma=0x22 udma=0x45 cable=80pin Oct 17 16:25:34 tiikeli syslogd: kernel boot file is /boot/kernel/kernel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Darwin/OSX Bluetooth code
On Thu, Oct 16, 2003 at 09:00:02PM -0700, Maksim Yevmenkin wrote: [snip] I'm currently thinking about un-Netgraph'ing FreeBSD code to make it portable to other BSD style systems. I'm trying to look at other implementations and learn as much as i can. In particular i'm trying to figure out how to minimize OS dependent code and what is the right abstractions levels. When I saw your BlueTooth entry in the recent status report, I thought I'd comment on that, but then got distracted :) You've done some great work on BlueTooth. IMHO, it would be a mistake to try to un-NetGraph it; there have been lots of rumours about people porting the NetGraph framework to other OS's, and if BlueTooth support will provide yet one more reason for the need to do this, so be it :) NetGraph is a wonderful framework for writing drivers, and not limited to network drivers, either - as you have no doubt discovered so far - there should be no need to give up its advantages if it's possible to retain them and even gain much in portability for the writing of future drivers (should NetGraph run on more OS's). G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. pgp0.pgp Description: PGP signature
Re: More ULE bugs fixed.
I think you cvsup'd at a bad time. I fixed a bug that would have caused the system to lock up in this case late last night. On my system it freezes for a few seconds and then returns. I can stop that by turning down the interactivity threshold. Hrm, I must concur that while ULE seems a tad snappier on the responsiveness end, it seems to be lacking in terms of real world performance compared to 4BSD. Thanks for the stats. Is this on SMP or UP? UP. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE/KSE deadlock
Hi, first the good news: sched_ule 1.65 seems to perform smoother under load for me, almost no mouse sluggishness anymore. Unfortunately I'm unable to use kse since the buildworld 2 hours ago. As soon as nautilus starts during gnome startup the system completely freezes. Using libc_r everything seems normal. Regards, Riggs P.S. cvsupped ~15:00 CEST, FreeBSD 5.1-CURRENT #0: Fri Oct 17 17:01:12 CEST 2003 -- - Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit| - -- --- Denn per Infrarot seh ich| just to fit your --- Die Nacht ist wirklich widerlich. | primitive screen. pgp0.pgp Description: PGP signature
Re: ULE/KSE deadlock
On Friday 17 October 2003 18:24, Thomas E. Zander wrote: Hi, first the good news: sched_ule 1.65 seems to perform smoother under load for me, almost no mouse sluggishness anymore. Unfortunately I'm unable to use kse since the buildworld 2 hours ago. As soon as nautilus starts during gnome startup the system completely freezes. Using libc_r everything seems normal. Regards, Riggs Ah, this seems to be the same problem that I'm facing. I can start KDE and other X programs without any problems, but GTK2 programs like GNOME and Mozilla-Firebird give a page fault. Arjan P.S. cvsupped ~15:00 CEST, FreeBSD 5.1-CURRENT #0: Fri Oct 17 17:01:12 CEST 2003 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: pmap_enter: attempted pmap_enter on 4MB page
Jilles Tjoelker wrote: Hello, Yesterday our 5-CURRENT box panicked with panic: pmap_enter: attempted pmap_enter on 4MB page. [..] (kgdb) p va $1 = 689672192 (kgdb) p pte $2 = (pt_entry_t *) 0xbfca46e4 (kgdb) p origpte $3 = 3503345872 (kgdb) p (void *)va $4 = (void *) 0x291b9000 (kgdb) p (void *)origpte $5 = (void *) 0xd0d0d0d0 (kgdb) # AHA! origpte being 0xd0d0d0d0 means that something really came unstuck because that is the fill pattern that userland malloc(3) uses. The 4MB page thing is a red herring, it just happens that PG_PS (0x80) is a set bit in the fill pattern. Now to find the source. :-( Are you getting this repeatably? If somebody is able to (relatively) easily provoke this, there are a few things I'd like to try (shotgun diagnostics, but its better than nothing). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Darwin/OSX Bluetooth code
Peter, I'm currently thinking about un-Netgraph'ing FreeBSD code to make it portable to other BSD style systems. I'm trying to look at other implementations and learn as much as i can. In particular i'm trying to figure out how to minimize OS dependent code and what is the right abstractions levels. When I saw your BlueTooth entry in the recent status report, I thought I'd comment on that, but then got distracted :) You've done some great work on BlueTooth. IMHO, it would be a mistake Thank you. to try to un-NetGraph it; there have been lots of rumours about people porting the NetGraph framework to other OS's, and if BlueTooth support will provide yet one more reason for the need to do this, so be it :) I'm not so sure about these rumors. To me it looks like NetBSD and OpenBSD folks are reluctant to adopt/port Netgraph. Also, when i started this project, few people have pointed out that it would much better if other BSDs could share the code. NetGraph is a wonderful framework for writing drivers, and not limited to network drivers, either - as you have no doubt discovered so far - there should be no need to give up its advantages if it's possible to retain them and even gain much in portability for the writing of future drivers (should NetGraph run on more OS's). I could not agree more. Netgraph is extremely flexible and when it comes to a rapid prototype development it is a number one choice. However, the fact is Netgraph is FreeBSD only framework (at least for now). So i think all BSDs would benefit from the common code (and as an extra bonus FreeBSD could have Netgraph support :) thanks, max __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FYI, I've switched my primary desktop to AMD64.
I finally worked up the nerve to commit to eating my own dogfood. :-) I've actually been doing my primary development on amd64 boxes for a while, and now that the consumer products have been officially launched, I figured it was about time. Most of the key components are in place. I've upgraded my home machine to an Asus SK8N + Athlon64 FX-51 (niiice!). My i386 box is in pieces, there is no going back now. For some strange reason I've had to pay attention to some of the sharp edges I'd been putting off for a while. I'm using an older nvidia geforce4 ti4200 for the video, so I had to fix a misconfiguration in the Xserver (I forgot to have it open /dev/io). The previous cards I'd used were all matrox which were solely mmio driven and didn't run into this problem. I've been working on getting mozilla-firebird up and running but that is easier said than done because the core infrastructure (nspr, xpcom etc) haven't got official support for amd64 yet. There are patches in the bugzilla database though. If all else fails, I'll use remote X from my laptop or something evil like that. Or finish off the 32 bit i386 binary support (I need to do that anyway - I haven't even tried to see if a FreeBSD/i386 binary of mozilla works, it might already work) Anyway, the 24 hours later status is: Thumbs up! And now to do the same thing to my work desktop. I'm planning to use an Asus K8V + Athlon64 3200+ there. Anyway, in case anybody is interested, the dmesg of my home box looks like this: 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 #3: Thu Oct 16 11:37:26 PDT 2003 [EMAIL PROTECTED]:/home/src/sys/amd64/compile/OVERCEE Preloaded elf kernel /boot/kernel/kernel at 0x806ef000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 FX-51 Processor (2200.01-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf58 Stepping = 8 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe050NX,MMX+,LM,3DNow!+,3DNow! real memory = 1072955392 (1023 MB) avail memory = 1011191808 (964 MB) Pentium Pro MTRR support enabled acpi0: A M I OEMXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_cpu0: CPU port 0x530-0x537 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: serial bus, SMBus at device 1.1 (no driver attached) ohci0: nVidia nForce3 USB Controller mem 0xfebfd000-0xfebfdfff irq 11 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: nVidia nForce3 USB Controller on ohci0 usb0: USB revision 1.0 uhub0: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: nVidia nForce3 USB Controller mem 0xfebfe000-0xfebfefff irq 5 at device 2.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: nVidia nForce3 USB Controller on ohci1 usb1: USB revision 1.0 uhub1: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xfebffc00-0xfebffcff irq 10 at device 2.2 on pci0 ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: EHCI (generic) USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: (0x10de) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered pcm0: Nvidia nForce3 port 0xec00-0xec7f,0xe800-0xe8ff mem 0xfebfb000-0xfebfbfff irq 11 at device 6.0 on pci0 pcm0: Avance Logic ALC650 AC97 Codec atapci0: nVidia nForce3 UDMA133 controller port 0xffa0-0xffaf at device 8.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pcib1: ACPI PCI-PCI bridge at device 10.0 on pci0 pci1: ACPI PCI bus on pcib1 ahc0: Adaptec 2940 SCSI adapter port 0xd800-0xd8ff mem 0xfc9ff000-0xfc9f irq 5 at device 4.0 on pci1 aic7870: Single Channel A, SCSI Id=7, 16/253 SCBs fxp0: Intel 82559 Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xfc80-0xfc8f,0xfc9fe000-0xfc9fefff irq 11 at device 5.0 on pci1 fxp0: Ethernet address 00:d0:b7:21:31:94 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto puc0: Dolphin Peripherals 4036 port 0xdfe0-0xdfe7,0xdff0-0xdff7,0xdf80-0xdf9f irq 11 at device 6.0 on pci1 sio4: Dolphin Peripherals 4036 on puc0 sio4: type 16550A sio4: unable to activate interrupt in fast mode - using normal mode sio5: Dolphin Peripherals 4036 on puc0 sio5: type 16550A sio5: unable to activate interrupt in
Re: [acpi-jp 2745] ACPI, USB, and the tangled web
On Thu, 16 Oct 2003, Anish Mistry wrote: -BEGIN PGP SIGNED MESSAGE- Um, that's great. :) First off, if you've been following my dabbling in fixing the USB resume problem on my laptop you know that I have been plauged by the infamous restart on second suspend with a usb device being accessed during the second suspend (ie. wiggling mouse). Yesterday after finally updating to a current that boots my system after a couple of weeks without it I suspended the system and resumed it to check some ACPI issues had been fixed, but that's for another time. After resume I realized I needed my mouse, so I plugged it in, dynamically loaded the kernel module and the mouse worked (normal/ previous). Then I suspend the laptop and was wiggling the mouse while it was suspending (bad habit from testing) and the system REBOOTED, and my patches weren't even applied! The problem is USB although ACPI magnifies it. USB devices can generate wake events. In my current testing of a new acpi_cpu driver, I've found that just having the USB bus enabled in the kernel (with no devices attached) causes it to generate a steady stream of bm_sts sets even though the laptop is completely idle. Try disabling usb in your kernel config and see if it helps your laptop not wake up. If that works, we've narrowed it down a little. You can also try setting debug.acpi.avoid to USB_ to try to get it to avoid evaluating that namespace. I'll probably get around to looking at the USB issue at some point. There's a lot of work needed there: suspend/resume for *hci, possibly avoiding setting acpi wake events on usb, etc. There seems to be some ACPI problem, since I just tested the same procedure on with ACPI disabled and there was no reboot. How were you able to test that with it disabled? Were you suspending with apm instead? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FYI, I've switched my primary desktop to AMD64.
On Fri, 2003-10-17 at 13:17, Peter Wemm wrote: [snip] I've been working on getting mozilla-firebird up and running but that is easier said than done because the core infrastructure (nspr, xpcom etc) haven't got official support for amd64 yet. There are patches in the bugzilla database though. If all else fails, I'll use remote X from my laptop or something evil like that. Or finish off the 32 bit i386 binary support (I need to do that anyway - I haven't even tried to see if a FreeBSD/i386 binary of mozilla works, it might already work) Please let me know when you have the nspr and xpcom patches, and I'll make sure they get committed to out repo. I'm not sure how helpful it will be, but Marcel has done most of the work on the ia64 side for Mozilla, and those patches are already in our tree. Thanks. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: [acpi-jp 2746] Re: ACPI, USB, and the tangled web
On Oct 17, 2003, at 10:25 AM, Nate Lawson wrote: The problem is USB although ACPI magnifies it. USB devices can generate wake events. In my current testing of a new acpi_cpu driver, I've found that just having the USB bus enabled in the kernel (with no devices attached) causes it to generate a steady stream of bm_sts sets even though the laptop is completely idle. This is normal; USB polls for new devices. You'll need to quiesce the USB controller somehow. = Mike -- there is no reliable algorithm for ensuring efficient memory usage, and none is possible [Wilson95] ___ [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.
Il Mer, 2003-10-15 alle 09:51, Jeff Roberson ha scritto: I fixed two bugs that were exposed due to more of the kernel running outside of Giant. ULE had some issues with priority propagation that stopped it from working very well. Things should be much improved. On my Athlon XP 2000+ the situation is much better. No mouse jerkiness whatever the load of the sistem is. The system respond better in any situation. I'm using libc_r, so no problem with any Gnome app caused (probably) by KSE. 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: Seeing system-lockups on recent current
At 11:52 PM +0200 10/10/03, Dag-Erling Smørgrav wrote: Doug White [EMAIL PROTECTED] writes: On Fri, 10 Oct 2003, Garance A Drosihn wrote: For the past week or so, I have been having a frustrating time with my freebsd-current/i386 system. It is a dual Athlon system. [...] It would be useful to isolate exactly what day the problem started occuring. I experienced similar problems on a dual Athlon system (MSI K7D Master-L motherboard, AMD 760MPX chipset, dual Athlon MP 2200+) which is barely a couple of months old. I ended up reverting to RELENG_5_1. With -CURRENT, both UP and SMP kernels will crash with symptoms which suggest hardware trouble. With RELENG_5_1, UP is rock solid (knock on wood) while SMP crashes within minutes of booting. Just to follow up on this... My symptoms were different, in that I have problems with both UP and SMP (although UP did seem more stable). I also tried a clean install of 5.1-RELEASE (right off the CD's), and that would also hang up. Since I *know* this machine had been running fine back at the time of 5.1-release, this was pretty significant. I took the PC back to the place I got it from, and they ran some kind of diagnostics on it and said the motherboard is bad. They're replacing the motherboard. So, unless I have something more to say when I get that back, it looks pretty likely that my headaches were hardware-related. (my machine also has a different components than des's machine) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atacontrol
I have a new motherboard, ASUS A7V600, which replaced an ASU CUSL. Everythin else is as it was on the original. With a CURRENT from last Sunday, FreeBSD lorne.arm.org 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Sun Oct 12 10:00:41 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LORNE i386 when I atacontrol info 0 I get Master: ad0 WDC WD400BB-00AUA1/18.20D18 ATA/ATAPI rev 5 Slave: no device present and when I atacontrol mode 0 I get Master = ??? Slave = BIOSPIO If I atacontrol mode 0 UDMA2 BIOSPIO I get Master = ??? Slave = BIOSPIO I also get lots of ad0: WARNING - WRITE_MUL write data underrun 81926144 In the log. How do I shoot this problem? -- Derek Tattersall[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AES is broken.
I seem to be able to confirm this. You can use the following sequence to run regression test on GBDE cd /usr/src/sbin/gbde make test For stuff like AES we should _really_ have a standalone regression test. Anyone out there willing to make one from the official AES test-vectors from NIST ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [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-10-17 18:36:44 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-17 18:36:44 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-10-17 18:36:44 - 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-10-17 18:39:49 - 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: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-17 19:35:58 - 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 Fri Oct 17 19:35:58 GMT 2003 Kernel build for GENERIC completed on Fri Oct 17 19:50:07 GMT 2003 TB --- 2003-10-17 19:50:07 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-17 19:50:07 - 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 Fri Oct 17 19:50:07 GMT 2003 [...] touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/conf/newvers.sh LINT 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 -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 vers.c linking kernel ip_fil.o: In function `ipfr_fastroute6': ip_fil.o(.text+0x275e): undefined reference to `nd_ifinfo' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** 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-10-17 20:02:21 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-17 20:02:21 - TB --- ERROR: failed to build lint kernel TB --- 2003-10-17 20:02:21 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AES is broken.
Poul-Henning Kamp writes: For stuff like AES we should _really_ have a standalone regression test. Anyone out there willing to make one from the official AES test-vectors from NIST ? Yeah. I can do this. Gimme a day or three. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2746] Re: ACPI, USB, and the tangled web
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 17 October 2003 01:25 pm, Nate Lawson wrote: The problem is USB although ACPI magnifies it. USB devices can generate wake events. In my current testing of a new acpi_cpu driver, I've found that just having the USB bus enabled in the kernel (with no devices attached) causes it to generate a steady stream of bm_sts sets even though the laptop is completely idle. Try disabling usb in your kernel config and see if it helps your laptop not wake up. If that works, we've narrowed it down a little. You can also try setting debug.acpi.avoid to USB_ to try to get it to avoid evaluating that namespace. USB isn't enabled in the kernel config, it was load via module. This problem only happens after the first suspend and only when the USB module is loaded, but a similar to my sleep_delay (http://www.freebsd.org/cgi/ query-pr.cgi?pr=56394) problem, the system always suspends once ok, but subsequent with both USB(only when being accessed) and sleep_delay cause reboots. Setting debug.acpi.avoid to USB_ didn't make any difference. When I was trying to debug these issues a month ago I remember it rebooting always sometime after the AcpiEnterSleepStatePrep. I'll probably get around to looking at the USB issue at some point. There's a lot of work needed there: suspend/resume for *hci, possibly avoiding setting acpi wake events on usb, etc. There seems to be some ACPI problem, since I just tested the same procedure on with ACPI disabled and there was no reboot. How were you able to test that with it disabled? Were you suspending with apm instead? Yes. -Nate - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/kFSZxqA5ziudZT0RAp33AKC4zp6RDIXWa7uUZD+KnSQiYhChDwCfY2ZY CloieAgGIx3HAin+ntTsxX0= =Fjb0 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: pmap_enter: attempted pmap_enter on 4MB page
On Fri, Oct 17, 2003 at 09:51:57AM -0700, Peter Wemm wrote: AHA! origpte being 0xd0d0d0d0 means that something really came unstuck because that is the fill pattern that userland malloc(3) uses. The 4MB page thing is a red herring, it just happens that PG_PS (0x80) is a set bit in the fill pattern. Now to find the source. :-( Are you getting this repeatably? If somebody is able to (relatively) easily provoke this, there are a few things I'd like to try (shotgun diagnostics, but its better than nothing). I also have a dual-athlon system that gets this panic on current. The problem shows up first as sig 10 11 on builds (world/kernel/ports) and eventual panic on pmap_enter on 4mb page. I KNOW it's not hardware, because a -current kernel from 9/24/03 is rock-solid (hours of port builds, make -j16 buildworld) and so is RELENG_5_1. The current kernel from yesterday did not even get through installworld without a sig11. I'm pretty sure it's not ata, because my system has scsi disks, and only an idle ata cdrom. I have pentiumpro as my cputype, because I also use this system to build for my laptop - is that a conceivable clue? But for experiments we can set it to anything. It's not in production, so if you want to try stuff, I'm willing to give you a login or take direction. Right now it's running RELENG_5_1 but I also have yesterday's -head on there and a local cvs on another system updated twice a day. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-10-17 20:02:22 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-17 20:02:22 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-10-17 20:02:22 - 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-10-17 20:04:26 - 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: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-17 21:00:45 - 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 Fri Oct 17 21:00:45 GMT 2003 Kernel build for GENERIC completed on Fri Oct 17 21:12:36 GMT 2003 TB --- 2003-10-17 21:12:36 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-17 21:12:36 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Oct 17 21:12:36 GMT 2003 [...] touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/conf/newvers.sh LINT 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/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 -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 vers.c linking kernel ip_fil.o: In function `ipfr_fastroute6': ip_fil.o(.text+0x275e): undefined reference to `nd_ifinfo' *** 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/LINT. *** 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-10-17 21:22:56 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-17 21:22:56 - TB --- ERROR: failed to build lint kernel TB --- 2003-10-17 21:22:56 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: cvs commit: src/sys/net80211 ieee80211_output.c ieee80211_var.h
This fixes adhoc mode for wi devices. Adhoc mode is still not working correctly for ath devices. No eta on fixing it. Sam ---BeginMessage--- sam 2003/10/17 14:54:59 PDT FreeBSD src repository Modified files: sys/net80211 ieee80211_output.c ieee80211_var.h Log: o add capability to indicate if device receives all management frames o use recv mgmt capability to decide if outbound frames should be discarded if no node table entry is present Revision ChangesPath 1.7 +17 -6 src/sys/net80211/ieee80211_output.c http://cvsweb.FreeBSD.org/src/sys/net80211/ieee80211_output.c.diff?r1=1.6r2=1.7 1.8 +1 -0 src/sys/net80211/ieee80211_var.h http://cvsweb.FreeBSD.org/src/sys/net80211/ieee80211_var.h.diff?r1=1.7r2=1.8 ---End Message--- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/net80211 ieee80211_output.c ieee80211_var.h
Hi Sam, thanks. But we made e throughput tets in the Hostap mode and the AP crash after 4 min of traffic. We try with differents card but still the same thanks Marcos - Original Message - From: Sam Leffler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, October 18, 2003 11:02 AM Subject: Fwd: cvs commit: src/sys/net80211 ieee80211_output.c ieee80211_var.h This fixes adhoc mode for wi devices. Adhoc mode is still not working correctly for ath devices. No eta on fixing it. Sam ___ [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]
conexant 878a hauppauge card
Dear sirs, I located a hauppauge card that had a conexant 878a chipset on it. This is an video capture card which should supposedly work under the brooktree driver. The reason I say this is that I found a success story of somone using the pinnacle branded card of the same chipset under freebsd 4-x. The following modules are loaded: 22 0xc086a000 36d4 iicbus.ko 32 0xc086e000 41d4 iicbb.ko 43 0xc0873000 3720 smbus.ko 51 0xc0877000 3080 smb.ko 61 0xc087b000 43b4 viapm.ko 72 0xc088 1f3c bktr_mem.ko 151 0xc44c5000 e000 bktr.ko The relevant lines in dmesg on the other hand states that the driver isn't appropriate... viapropm0: SMBus I/O base at 0x6000 viapropm0: VIA VT82C686A Power Management Unit port 0x6000-0x600f at device 7. 4 on pci0 viapropm0: SMBus revision code 0x0 smbus0: System Management Bus on viapropm0 smb0: SMBus generic I/O on smbus0 pci0: multimedia, video at device 9.0 (no driver attached) pci0: multimedia at device 9.1 (no driver attached) And of course, the /dev/bktr* devices weren't created, but I've done everything that I think I was suppose to do in the man page, I've emailed [EMAIL PROTECTED] asking about the driver, is there anything I'm seemingly missing ? At any rate, thank you for your time and attention, I don't know where else to look... Bertrand ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Darwin/OSX Bluetooth code
Peter Pentchev wrote: You've done some great work on BlueTooth. IMHO, it would be a mistake to try to un-NetGraph it; there have been lots of rumours about people porting the NetGraph framework to other OS's, and if BlueTooth support will provide yet one more reason for the need to do this, so be it :) I doubt it I came across NetGraph by trying to get my USB-USB link going under FreeBSD. It is extremely cumbersome to be used and seems to be *too low level* as interface design. ___ [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-10-17 21:22:57 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-17 21:22:57 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-10-17 21:22:57 - 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-10-17 21:25:09 - 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: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-17 22:28:28 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Oct 17 22:28:28 GMT 2003 Kernel build for GENERIC completed on Fri Oct 17 22:44:12 GMT 2003 TB --- 2003-10-17 22:44:12 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-17 22:44:12 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Fri Oct 17 22:44:12 GMT 2003 [...] touch hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/conf/newvers.sh LINT cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror vers.c linking kernel ip_fil.o: In function `ipfr_fastroute6': ip_fil.o(.text+0x54e2): undefined reference to `nd_ifinfo' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/LINT. *** 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-10-17 22:57:29 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-17 22:57:29 - TB --- ERROR: failed to build lint kernel TB --- 2003-10-17 22:57:29 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
see you all in 7 weeks
I'm off for 7 weeks in Hungary and Australia.. I've just turned off delivery for my list subscriptions but I'll still be looking at emails sent directly to me.. see you all in December! Julian ___ [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.
I think you cvsup'd at a bad time. I fixed a bug that would have caused the system to lock up in this case late last night. On my system it freezes for a few seconds and then returns. I can stop that by turning down the interactivity threshold. Hrm, I must concur that while ULE seems a tad snappier on the responsiveness end, it seems to be lacking in terms of real world performance compared to 4BSD. Thanks for the stats. Is this on SMP or UP? UP. -sc The commit to src/sys/kern/kern_switch.c:1.62, would it fix the following crash (can't find my kernel with debugging symbols): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor write, page not present instruction pointer = 0x8:0xc054699f stack pointer = 0x10:0xd6713b20 frame pointer = 0x10:0xd6713b2c 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 = 3 (g_up) trap number = 12 panic: page fault syncing disks, buffers remaining... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0536771 stack pointer = 0x10:0xdb7d4bb4 frame pointer = 0x10:0xdb7d4bc0 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 = 45 (syncer) trap number = 12 panic: page fault #0 0xc052eeeb in doadump () #1 0xc052f579 in boot () #2 0xc052f958 in panic () #3 0xc06e5536 in trap_fatal () #4 0xc06e4b73 in trap () #5 0xc06d53d8 in calltrap () #6 0xc05460bb in sched_switch () #7 0xc05384eb in mi_switch () #8 0xc0537b9f in msleep () #9 0xc058eca3 in sched_sync () #10 0xc0518321 in fork_exit () -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-10-17 22:57:30 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-17 22:57:30 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-10-17 22:57:30 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-17 22:59:40 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-17 23:52:47 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Oct 17 23:52:48 GMT 2003 Kernel build for GENERIC completed on Sat Oct 18 00:01:54 GMT 2003 TB --- 2003-10-18 00:01:54 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-18 00:01:54 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Oct 18 00:01:54 GMT 2003 [...] cc -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/conf/newvers.sh LINT cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror vers.c linking kernel ip_fil.o: In function `ipfr_fastroute6': ip_fil.o(.text+0x26b4): undefined reference to `nd_ifinfo' ip_fil.o(.text+0x26b8): undefined reference to `nd_ifinfo' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-10-18 00:10:40 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-10-18 00:10:40 - TB --- ERROR: failed to build lint kernel TB --- 2003-10-18 00:10:40 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: conexant 878a hauppauge card
Please wrap your lines. Thanks. On Fri, 17 Oct 2003, bertrand kotewall wrote: I located a hauppauge card that had a conexant 878a chipset on it. This is an video capture card which should supposedly work under the brooktree driver. The reason I say this is that I found a success story of somone using the pinnacle branded card of the same chipset under freebsd 4-x. The following modules are loaded: [...] viapropm0: SMBus I/O base at 0x6000 viapropm0: VIA VT82C686A Power Management Unit port 0x6000-0x600f at device 7. 4 on pci0 viapropm0: SMBus revision code 0x0 smbus0: System Management Bus on viapropm0 smb0: SMBus generic I/O on smbus0 pci0: multimedia, video at device 9.0 (no driver attached) pci0: multimedia at device 9.1 (no driver attached) Looks like the IDs just need to be added for your card. Can you post the output of pciconf -lv so we can add them? Thanks! -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Darwin/OSX Bluetooth code
Peter Pentchev [EMAIL PROTECTED] wrote: You've done some great work on BlueTooth. IMHO, it would be a mistake to try to un-NetGraph it; there have been lots of rumours about people porting the NetGraph framework to other OS's, and if BlueTooth support will provide yet one more reason for the need to do this, so be it :) FWIW, I'm not aware of any such work for OpenBSD, and I estimate the chances of such work being integrated into OpenBSD as approximately nil. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
samba-libsmbclient
Is anyone able to successfully compile the newest /usr/ports/net/samba-libsmbclient under CURRENT? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: samba-libsmbclient
On Fri, Oct 17, 2003 at 06:19:55PM -0700, Janet Sullivan wrote: Is anyone able to successfully compile the newest /usr/ports/net/samba-libsmbclient under CURRENT? http://bento.freebsd.org says yes. Kris pgp0.pgp Description: PGP signature
ip stack broken?
When I use a current kernel, my system will obtain an ip address via dhclient, but thereafter, it cannot see the network. I have tried switching ethernet cards. (used both a dc0 and an fxp0) Am currently using a 5.1-RELEASE kernel to have network access. Advice? BOOT MESSAGES: Oct 17 18:37:07 duron kernel: Copyright (c) 1992-2003 The FreeBSD Project. Oct 17 18:37:07 duron kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 17 18:37:07 duron kernel: The Regents of the University of California. All rights reserved. Oct 17 18:37:07 duron kernel: FreeBSD 5.1-CURRENT #1: Fri Oct 17 15:31:54 EDT 2003 Oct 17 18:37:07 duron kernel: [EMAIL PROTECTED]:/usr/src/sys/i386/compile/athlon Oct 17 18:37:07 duron kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc0a8a000. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/vesa.ko at 0xc0a8a1f4. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/snd_sb16.ko at 0xc0a8a2a0. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/snd_sbc.ko at 0xc0a8a350. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0a8a3fc. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/bktr.ko at 0xc0a8a4a8. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/bktr_mem.ko at 0xc0a8a554. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/aio.ko at 0xc0a8a604. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/r128.ko at 0xc0a8a6ac. Oct 17 18:37:07 duron kernel: Preloaded elf module /boot/kernel/acpi.ko at 0xc0a8a758. Oct 17 18:37:07 duron kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Oct 17 18:37:07 duron kernel: CPU: AMD Athlon(tm) processor (1200.05-MHz 686-class CPU) Oct 17 18:37:07 duron kernel: Origin = AuthenticAMD Id = 0x642 Stepping = 2 Oct 17 18:37:07 duron kernel: Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR Oct 17 18:37:07 duron kernel: AMD Features=0xc044RSVD,AMIE,DSP,3DNow! Oct 17 18:37:07 duron kernel: real memory = 402587648 (383 MB) Oct 17 18:37:07 duron kernel: avail memory = 381362176 (363 MB) Oct 17 18:37:07 duron kernel: bktr_mem: memory holder loaded Oct 17 18:37:07 duron kernel: Pentium Pro MTRR support enabled Oct 17 18:37:07 duron kernel: VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc09c6a02 (122) Oct 17 18:37:07 duron kernel: VESA: ATI RAGE128 Oct 17 18:37:07 duron kernel: npx0: [FAST] Oct 17 18:37:07 duron kernel: npx0: math processor on motherboard Oct 17 18:37:07 duron kernel: npx0: INT 16 interface Oct 17 18:37:07 duron kernel: acpi0: VIA694 AWRDACPI on motherboard Oct 17 18:37:07 duron kernel: pcibios: BIOS version 2.10 Oct 17 18:37:07 duron kernel: Using $PIR table, 7 entries at 0xc00fdd50 Oct 17 18:37:07 duron kernel: acpi0: Power Button (fixed) Oct 17 18:37:07 duron kernel: Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Oct 17 18:37:07 duron kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 Oct 17 18:37:07 duron kernel: acpi_cpu0: CPU on acpi0 Oct 17 18:37:07 duron kernel: acpi_button0: Power Button on acpi0 Oct 17 18:37:07 duron kernel: acpi_button1: Sleep Button on acpi0 Oct 17 18:37:07 duron kernel: pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 Oct 17 18:37:07 duron kernel: pci0: ACPI PCI bus on pcib0 Oct 17 18:37:07 duron kernel: pcib0: slot 7 INTD is routed to irq 10 Oct 17 18:37:07 duron kernel: pcib0: slot 7 INTD is routed to irq 10 Oct 17 18:37:07 duron kernel: pcib0: slot 11 INTA is routed to irq 9 Oct 17 18:37:07 duron kernel: pcib0: slot 11 INTA is routed to irq 9 Oct 17 18:37:07 duron kernel: pcib0: slot 18 INTA is routed to irq 11 Oct 17 18:37:07 duron kernel: pcib0: slot 20 INTA is routed to irq 10 Oct 17 18:37:07 duron kernel: agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 Oct 17 18:37:07 duron kernel: pcib1: PCI-PCI bridge at device 1.0 on pci0 Oct 17 18:37:07 duron kernel: pci1: PCI bus on pcib1 Oct 17 18:37:07 duron kernel: pcib0: slot 1 INTA is routed to irq 12 Oct 17 18:37:07 duron kernel: pcib1: slot 0 INTA is routed to irq 12 Oct 17 18:37:07 duron kernel: drm0: ATI Rage 128 Pro Ultra TF (AGP) port 0x9000-0x90ff mem 0xd900-0xd9003fff,0xd400-0xd7ff irq 12 at device 0.0 on pci1 Oct 17 18:37:07 duron kernel: info: [drm] AGP at 0xd000 64MB Oct 17 18:37:07 duron kernel: info: [drm] Initialized r128 2.5.0 20030725 on minor 0 Oct 17 18:37:07 duron kernel: isab0: PCI-ISA bridge at device 7.0 on pci0 Oct 17 18:37:07 duron kernel: isa0: ISA bus on isab0 Oct 17 18:37:07 duron kernel: atapci0: VIA 82C686B UDMA100 controller port 0xa000-0xa00f at device 7.1 on pci0 Oct 17 18:37:07 duron kernel: atapci0: Correcting VIA config for southbridge data corruption bug Oct 17 18:37:07 duron kernel: ata0: at 0x1f0 irq 14 on atapci0 Oct 17 18:37:07 duron
Re: conexant 878a hauppauge card
On Fri, Oct 17, 2003 at 05:18:33PM -0700, Doug White wrote: Please wrap your lines. Thanks. Looks like the IDs just need to be added for your card. Can you post the output of pciconf -lv so we can add them? Thanks! Sorry about the unwrapped lines... Here are the pertinent lines to the from pciconf -lv [EMAIL PROTECTED]:9:0: class=0x04 card=0xfd70 chip=0x016c109e rev=0x11 hdr=0x00 vendor = 'Brooktree Corporation' class= multimedia subclass = video [EMAIL PROTECTED]:9:1: class=0x048000 card=0xfd70 chip=0x0878109e rev=0x11 hdr=0x00 vendor = 'Brooktree Corporation' device = 'Bt878 Video Capture (Audio Section)' class= multimedia Much much much obliged. Bertrand Kotewall ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ip_divert.c lock order reversal
Hi, I just cvsup'd and noticed the following: Starting sshd. lock order reversal 1st 0xc2ee3998 inp (inp) @ /usr/src/sys/netinet/udp_usrreq.c:1042 2nd 0xc094876c div (div) @ /usr/src/sys/netinet/ip_divert.c:225 Stack backtrace: backtrace(c08643de,c094876c,c087b2de,c087b2de,c086b1c6) at backtrace+0x17 witness_lock(c094876c,8,c086b1c6,e1,0) at witness_lock+0x672 _mtx_lock_flags(c094876c,0,c086b1c6,e1,c16db200) at _mtx_lock_flags+0xba divert_packet(c16db200,0,21dc,32,c06832f3) at divert_packet+0x133 ip_output(c16db200,0,c2ee3924,0,0) at ip_output+0x851 udp_output(c2ee38e8,c16db200,0,0,c16cc4c0) at udp_output+0x403 udp_send(c2f1c000,0,c16db200,0,0) at udp_send+0xb7 sosend(c2f1c000,0,cdd10c48,c16db200,0) at sosend+0x44d kern_sendit(c16cc4c0,4,cdd10cc0,0,0) at kern_sendit+0x17c sendit(c16cc4c0,4,cdd10cc0,0,bfbfd2f8) at sendit+0x16e sendto(c16cc4c0,cdd10d10,c087d03a,3ed,6) at sendto+0x5b syscall(2f,2f,2f,8106000,28) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (133), eip = 0x282a810f, esp = 0xbfbfcf9c, ebp = 0xbfbfcfc8 --- Initial i386 initialization:. -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros Throughput TEST!
At 5:30 PM +1300 2003/10/17, Marcos Biscaysaqu wrote: We made a Throughput test with 2 different wireless card DLINK and NETGEAR , with a ftp traffic in both ways with no diference between the DLINK and NETGEAR card, Very good speed but the Freebsd AP crash after 4 min. Try pathrate and pathload. They're much better tools for getting down into the nitty-gritty details of true network throughput and bottleneck identification. Try using application-layer tools like ftp at a later stage in the testing. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_divert.c lock order reversal
Hi,
I am seeing an occasional kernel panic. I think it
is related to natd and ip_divert
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc07e6c24
stack pointer = 0x10:0xce7026c4
frame pointer = 0x10:0xce7026d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 273 (natd)
Reading symbols from
/usr/obj/usr/src/sys/MYKERNEL1/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/MYKERNEL1/modules/usr/src/sys/modules/acpi/acpi.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc065c29c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc065c627 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0467692 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc04675f2 in db_command (last_cmdp=0xc08f7d80, cmd_table=0x0,
aux_cmd_tablep=0xc0882788, aux_cmd_tablep_end=0xc08827a0)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0467735 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc046a735 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc07e696c in kdb_trap (type=12, code=0, regs=0xce702904)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc07f7d96 in trap_fatal (frame=0xce702904, eva=0)
at /usr/src/sys/i386/i386/trap.c:815
#9 0xc07f7a62 in trap_pfault (frame=0xce702904, usermode=0, eva=3735929054)
at /usr/src/sys/i386/i386/trap.c:734
#10 0xc07f761d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -831520752, tf_edi = -1064957451, tf_esi =
-559038242, tf_ebp = -831510204, tf_isp = -831510224, tf_ebx = -831509976, tf_edx =
-559038242, tf_ecx = 0, tf_eax = -559038242, tf_trapno = 12, tf_err = 0, tf_eip =
-1066647656, tf_cs = 8, tf_eflags = 66118, tf_esp = -831510004, tf_ss = -1066938255})
at /usr/src/sys/i386/i386/trap.c:419
#11 0xc07e8358 in calltrap () at {standard input}:102
#12 0xc067d071 in kvprintf (fmt=0xc08609f5 @ %s:%d,
func=0xc067ca10 snprintf_func, arg=0xce702a28, radix=10,
ap=0xce702a74 \004É\206À\n\001) at /usr/src/sys/kern/subr_prf.c:669
#13 0xc067c98e in vsnprintf (str=0xc09214e0 mtx_lock() of spin mutex ,
size=0, format=0x0, ap=0x0) at /usr/src/sys/kern/subr_prf.c:414
#14 0xc065c541 in panic (fmt=0xc08609da mtx_lock() of spin mutex %s @ %s:%d)
at /usr/src/sys/kern/kern_shutdown.c:511
#15 0xc0652646 in _mtx_lock_flags (m=0xc2f37d90, opts=0,
file=0xc086c904 /usr/src/sys/netinet/ip_output.c, line=266)
at /usr/src/sys/kern/kern_mutex.c:332
#16 0xc06f50c7 in ip_output (m0=0xc2f37d90, opt=0x10a, ro=0xc086c904,
flags=34, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:266
#17 0xc06e9021 in div_output (so=0xc2ee2000, m=0xc16e2f00, sin=0xc2ecb240,
control=0x0) at /usr/src/sys/netinet/ip_divert.c:320
#18 0xc06e94fd in div_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0,
td=0xc2d40720) at /usr/src/sys/netinet/ip_divert.c:476
#19 0xc0699ecd in sosend (so=0xc2ee2000, addr=0xc2ecb240, uio=0xce702c48,
top=0xc16e2f00, control=0x0, flags=0, td=0xc2d40720)
at /usr/src/sys/kern/uipc_socket.c:714
#20 0xc069e48c in kern_sendit (td=0xc2d40720, s=3, mp=0xce702cc0, flags=0,
control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:723
#21 0xc069e2de in sendit (td=0x0, s=0, mp=0xce702cc0, flags=0)
at /usr/src/sys/kern/uipc_syscalls.c:663
#22 0xc069e61b in sendto (td=0x0, uap=0x0)
at /usr/src/sys/kern/uipc_syscalls.c:784
#23 0xc07f8100 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = -1078002688, tf_esi = 2,
tf_ebp = -1077937128, tf_isp = -831509132, tf_ebx = 482, tf_edx = 26852, tf_ecx =
1148159575, tf_eax = 133, tf_trapno = 0, tf_err = 2, tf_eip = 134558627, tf_cs = 31,
tf_eflags = 582, tf_esp = -1078002836, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1009
#24 0xc07e83ad in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb) quit
--
Craig Rodrigues
http://crodrigues.org
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros Throughput TEST!
we made it, we made lots of test, but the wireless card keep crashing every 4 min check this out: http://202.49.92.224/atheros/TESTFAst.html - Original Message - From: Brad Knowles [EMAIL PROTECTED] To: Marcos Biscaysaqu [EMAIL PROTECTED] Cc: Marcos Biscaysaqu [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, October 18, 2003 3:32 PM Subject: Re: Atheros Throughput TEST! At 5:30 PM +1300 2003/10/17, Marcos Biscaysaqu wrote: We made a Throughput test with 2 different wireless card DLINK and NETGEAR , with a ftp traffic in both ways with no diference between the DLINK and NETGEAR card, Very good speed but the Freebsd AP crash after 4 min. Try pathrate and pathload. They're much better tools for getting down into the nitty-gritty details of true network throughput and bottleneck identification. Try using application-layer tools like ftp at a later stage in the testing. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
[ On Wednesday, October 15, Bruce M Simpson wrote: ] On Mon, Oct 13, 2003 at 05:26:59AM -0700, John Reynolds wrote: Thanks. I haven't tried cdrtools-devel in a while so I probably didn't see the work-around that was committed. I will try it and report back as to if it works (to further narrow down the mlockall(2) bit). It looks like alc@ has fixed the problem in vm_fault.c rev 1.181. BMS I can definitely confirm this too! With the unpatched cdrecord (in the non-devel port) and this versio of vm_fault.c there was no panic! Awesome! Thanks! -Jr -- John Jennifer Reynolds johnjen at reynoldsnet.orgwww.reynoldsnet.org Structural / Physical Design - ICG/PNG SCD jreynold at sedona.ch.intel.com Running FreeBSD since 2.1.5-RELEASE. FreeBSD: The Power to Serve! Unix is user friendly, it's just particular about the friends it chooses. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Help saving my system
Hi Guys, here's the scenario: 1. Had FreeBSD 5.1 system running. 2. Did a cvsup get of stable (that's right, stable, so 4.9) 3. Compiled make buildworld, then did a make build world, and re-compiled with generic kernel 4. Booted into a system which could not mount the file system (expected since its 4.9) So now I am trying to save the system and here's where I've gotten to: 1. Booted disc 2 of 5.1 cd into fixme mode. 2. Mounted live cdrom filesystem and then mounted my root drive to /mnt 3. Did a chroot to /mnt so that I would emulate my live system environment 4. Re-did a cvsup of the branch current. 5. Ran make buildworld from /usr/src Here is what happens when I do that: /dev/null, line 1: Need an operator /dev/null, line 1: Need an operator /dev/null, line 1: Need an operator /dev/null, line 1: Need an operator /dev/null, line 1: Need an operator /dev/null, line 1: Need an operator /dev/null, line 1: Need an operator make: fatal errors encountered -- cannot continue /usr/src/Makefile.inc1, line 156: warning: /usr/obj/usr/src/make.i386/make -f /dev/null -m /usr/src/share/mk CPUTYPE=dummy -V CPUTYPE returned non-zero status /usr/src/Makefile.inc1, line 158: CPUTYPE global should be set with ?=. *** Error code 1 Help! -Jason This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 current make buildworld fails consistently on crtstuff.c- Help?
On Mon, Oct 13, 2003 at 07:52:34PM -0400, Scott W wrote: cc -O -pipe -DSMP -DAPIC_IO -march=pentiumpro -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings -march=pentiumpro -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-omit-frame-pointer It looks like you have highly non-standard CFLAGS. Kris pgp0.pgp Description: PGP signature
