Re: panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
On Fri, Sep 12, 2003 at 08:54:59AM +0200, Morten Rodal wrote: A little bit of history first. I am having great trouble in running any of the Mozilla web browsers under -CURRENT with libkse. (If you are really interested see the thread on threads@) When I ran Mozilla Firebird with the --debug (which lets you run Mozilla Firebird from within gdb) the machine paniced. The backtrace is rather long and I am not sure if the subject of this email is the real panic either. This computer is/was (I am currently rebuilding the kernel to todays sources) running: FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Fri Aug 22 18:06:03 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 More details are available upon request. Since the last panic I upgraded to FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 12 08:59:58 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 (both world and kernel). I am still able to reproduce this, and it is fairly simple. On a smp machine (haven't tried my laptop, and I got more important stuff there that I dont want to lose in a panic) do the following: 1) Install the mozilla-firebird port 2) Edit libmap.conf so that it uses libkse 3) Start it by running firebird --debug, this will present you with a gdb prompt. Type run here and watch your computer panic. (It takes a little while) So this brings up the question, is there a known problem with debugging multi-threaded applications (which use libkse) that can cause a panic? I will bring home my laptop, and will be able to use a serial debugger if that would help anyone willing to trace this down. -- Morten Rodal Script started on Tue Sep 16 08:25:54 2003 slurp# gdb -k kernel.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: absolutely cannot call smp_ipi_shootdown with interrupts already disabled panic messages: --- panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0100 Stack backtrace: boot() called on cpu#0 syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0100 boot() called on cpu#0 Uptime: 3d19h39m32s Dumping 447 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 --- Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /boot/kernel/snd_sb16.ko...done. Loaded symbols for /boot/kernel/snd_sb16.ko Reading symbols from /boot/kernel/snd_sbc.ko...done. Loaded symbols for /boot/kernel/snd_sbc.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.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 0xc01de9b6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc01dee08 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0320467 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2396 #4 0xc03207a9 in smp_invlpg_range (addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2527 #5 0xc0322b38 in pmap_invalidate_range (pmap=0xc03eda40, sva=3440447488, eva=3440463872) at /usr/src/sys/i386/i386/pmap.c:719 #6 0xc0323011 in pmap_qremove (sva=3440447488, count=0) at /usr/src/sys/i386/i386/pmap.c:985 #7 0xc022ba4a in vfs_vmio_release (bp=0xcca1ec60) at /usr/src/sys/kern/vfs_bio.c:1588 #8
ad4 device
I tried to install the 9/15 snapshot which looks like it now supports Adaptec SATA and Adaptec 1200A Raid controllers. Unfortuneatly on two systems I tried to install this on, both failed with the error /dev/ad4s1a no device present. Since devices are automatically created in 5.X is there any work around to this? -Derek [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI and a Toshiba Tecra 8000
Hi, I have -current on my laptop as of yesterdays sources and my suspending isnt working quite right. The first time I suspend (S3) it works and comes back to life, but the second time the laptop reboots when it resumes. I have now build a new kernel with debuging/ddb and hooked up a serial cable. When I boot to the comconsole and try to suspend it panics straight away with the following. The asl and dmesg can be found @ http://www.fud.org.nz/acpi/ Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03d7b17 stack pointer = 0x10:0xc5e7895c frame pointer = 0x10:0xc5e78978 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 = 504 (acpiconf) kernel: type 12 trap, code=0 Stopped at scsuspend+0x17: movl0(%eax),%eax db tr scsuspend(c1279d80,c1212058,c0424e74,c5e78998,0) at scsuspend+0x17 bus_generic_suspend(c1273f00,c11d4058,c0424e74,c5e789f0,c5e789e0) at bus_generic_suspend+0x5d bus_generic_suspend(c1256b00) at bus_generic_suspend+0x5d isab_suspend(c1256b00,c11f7058,c0424e74,14f,0) at isab_suspend+0x7b bus_generic_suspend(c1256b80,c1221058,c0424e74,c058ac58,c5e78a38) at bus_generic_suspend+0x5d bus_generic_suspend(c1256280,c1220058,c0424e74,0,0) at bus_generic_suspend+0x5d bus_generic_suspend(c09f2580,c122b058,c0424e74,c5e78ac3,0) at bus_generic_suspend+0x5d bus_generic_suspend(c09f1400,c120c058,c0424e74,c5e78a98,c1250740) at bus_generic_suspend+0x5d bus_generic_suspend(c09f1c80,c118e058,c0424e74,bfca02d0,74000) at bus_generic_suspend+0x5d acpi_SetSleepState(c1256a00,3,c08fe6a8,c159d124,c5e78b54) at acpi_SetSleepState+0xfb acpiioctl(c047eb40,80045003,c5e78c48,3,c09fb4c0) at acpiioctl+0xc2 spec_ioctl(c5e78b54,c5e78c00,c02b7e31,c5e78b54,c037be77) at spec_ioctl+0x16b spec_vnoperate(c5e78b54,c037be77,c1599378,80,c082b258) at spec_vnoperate+0x18 vn_ioctl(c133894c,80045003,c5e78c48,c1597080,c09fb4c0) at vn_ioctl+0x1a1 ioctl(c09fb4c0,c5e78d10,c,c,3) at ioctl+0x61f syscall(2f,2f,2f,3,bfbffc5c) at syscall+0x2b0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280bd54f, esp = 0xbfbffbdc, ebp = 0xbfbffbf8 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Mon, 15 Sep 2003, 23:48-0600, Scott Long wrote: All, I'd like to give a status report for 4.x and 5.x for the developers and users who didn't attend the DevSummit this past weekend. 4.9: The 4.9 release is likely going to be pushed back for a few weeks while the recent instability reports are tracked down. The target goal is two weeks, but hopefully things can be resolved before then. The problems appear to stem from the recent PAE import. The consensus reached at the DevSummit is that PAE is a critical feature for 4.x and that removing it isn't desirable unless the problems persist. We encourage anyone to help with this. PAE MFC brought an incredible instability to stable branch. It affects 100% of our user community especially when we issued several SAs since PAE commit. They often can't switch to RELENG_4_x security branches because even RELENG_4_8 misses several critical non-security fixes. I believe stability was a critical feature of stable branch. Not PAE or anything alse. That is why I think we have to back out all that PAE code from stable. [5.x stuff] -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to FreeBSD 5.1
On Mon, Sep 15, 2003 at 03:13:30PM -0400, Didier Rwitura wrote: I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 and i getting this error message when I run make -j4 buildworld Does it actually stop there, or does it go on to rebuild make as the message suggests it will, and as it is supposed to? Kris pgp0.pgp Description: PGP signature
Re: Upgrading to FreeBSD 5.1
Kris Kennaway wrote: On Mon, Sep 15, 2003 at 03:13:30PM -0400, Didier Rwitura wrote: I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 and i getting this error message when I run make -j4 buildworld I had the same problem. Making without the -j4 option works however. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upgrading to FreeBSD 5.1
RELENG_5_1 builds just fine, but don't mess with make's max jobs with buildworld. -Mike On Tue, 16 Sep 2003, Antoine Jacoutot wrote: Date: Tue, 16 Sep 2003 09:12:46 +0200 From: Antoine Jacoutot [EMAIL PROTECTED] To: Kris Kennaway [EMAIL PROTECTED] Cc: Didier Rwitura [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Upgrading to FreeBSD 5.1 Kris Kennaway wrote: On Mon, Sep 15, 2003 at 03:13:30PM -0400, Didier Rwitura wrote: I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 and i getting this error message when I run make -j4 buildworld I had the same problem. Making without the -j4 option works however. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable 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: ATA DVD-ROM failure
On Mon, 15 Sep 2003 11:40:07 +0200 (CEST) Soren Schmidt [EMAIL PROTECTED] wrote: Okies, you need to update as there has been changes since this that should fix the problem. Update yesterday, same symptoms :( Bye, Dario -- Dario Freni ([EMAIL PROTECTED]) - SaturNero on IRCNet, Azzurra Gruppo Utenti FreeBSD Italia (http://www.gufi.org) GPG Public key at http://www.saturnero.net/saturnero.asc pgp0.pgp Description: PGP signature
Re: Release Engineering Status Report
On Tue, 16 Sep 2003, Maxim Konovalov wrote: PAE MFC brought an incredible instability to stable branch. It affects 100% of our user community especially when we issued several SAs since PAE commit. They often can't switch to RELENG_4_x security branches because even RELENG_4_8 misses several critical non-security fixes. I merged PAE into my version of -current a bit at a time and didn't notice any problems (with PAE not actually configured) despite having some large logical inconsistencies from not having all of it. Most of the global changes had no effect since they just changed the names of some typedefs without changing the underlying types in the !PAE case. So I suspect that any instabilities in RELENG_4 in the !PAE case are indirectly related to PAE and/or localized and thus easy to find and fix. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
smp reboot with atang
The problem of not being able to reboot without a panic seems to persist on late current with ATAng and SMP. Pete Sep 16 13:16:11 rms21 reboot: rebooted by pete Sep 16 13:16:11 rms21 syslogd: exiting on signal 15 boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped W ia tFiantga l( mtarxa p6 01 :s epcroinvdisl)e gfeodr isnyssttreumc tpiroonc efsasu l`ts ywnhcielre' itno ksetronpe.l. .mode cpuid = 1; lapic.id = 0100 instruction pointer = 0x8:0xd70fbd0e stack pointer = 0x10:0xd70fbcec frame pointer = 0x10:0x8 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 = 11 (idle: cpu1) kernel: type 1 trap, code=0 Stopped at 0xd70fbd0e: ??? db trace Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc0383880 stack pointer = 0x10:0xd70fb9f0 frame pointer = 0x10:0xd70fb9f4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu1) kernel: type 12 trap, code=0 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smp reboot with atang
It seems Petri Helenius wrote: The problem of not being able to reboot without a panic seems to persist on late current with ATAng and SMP. The below doesn't say much actually, but I can reboot to my hearts content on my SMP box here with no problems. What else do you have in that kernel ? Sep 16 13:16:11 rms21 reboot: rebooted by pete Sep 16 13:16:11 rms21 syslogd: exiting on signal 15 boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped W ia tFiantga l( mtarxa p6 01 :s epcroinvdisl)e gfeodr isnyssttreumc tpiroonc efsasu l`ts ywnhcielre' itno ksetronpe.l. .mode cpuid = 1; lapic.id = 0100 instruction pointer = 0x8:0xd70fbd0e stack pointer = 0x10:0xd70fbcec frame pointer = 0x10:0x8 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 = 11 (idle: cpu1) kernel: type 1 trap, code=0 Stopped at 0xd70fbd0e: ??? db trace Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc0383880 stack pointer = 0x10:0xd70fb9f0 frame pointer = 0x10:0xd70fb9f4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu1) kernel: type 12 trap, code=0 -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smp reboot with atang
Soren Schmidt wrote: It seems Petri Helenius wrote: The problem of not being able to reboot without a panic seems to persist on late current with ATAng and SMP. The below doesn't say much actually, but I can reboot to my hearts content on my SMP box here with no problems. What else do you have in that kernel ? Removing device atapicam seems to resolve the issue. Previously I couldn´t do that but thanks to your patch I can now have a kernel without atapicam. Pete Sep 16 13:16:11 rms21 reboot: rebooted by pete Sep 16 13:16:11 rms21 syslogd: exiting on signal 15 boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped W ia tFiantga l( mtarxa p6 01 :s epcroinvdisl)e gfeodr isnyssttreumc tpiroonc efsasu l`ts ywnhcielre' itno ksetronpe.l. .mode cpuid = 1; lapic.id = 0100 instruction pointer = 0x8:0xd70fbd0e stack pointer = 0x10:0xd70fbcec frame pointer = 0x10:0x8 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 = 11 (idle: cpu1) kernel: type 1 trap, code=0 Stopped at 0xd70fbd0e: ??? db trace Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc0383880 stack pointer = 0x10:0xd70fb9f0 frame pointer = 0x10:0xd70fb9f4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu1) kernel: type 12 trap, code=0 -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0, Driver support?
Hi! On Tue, 16 Sep 2003 11:21:01 +1200 Marcos Biscaysaqu [EMAIL PROTECTED] wrote: Hi There . I have in comming a couple a Proxim 8480- pcmcia , with Atheros Chipset and 8482- pci . someone knows if this card work on Freebsd? 'man ath' has a list of supported cards. There may be more devices listed in the driver itself. 54Mbit equipment using PCMCIA would be useless since PCMCIA basicly is just ISA and only can transfer ~16Mbit/s. The manpage shows cardbus (= PCI speed) cards which work but (see BUGS) do not support any powersaving modes. Hendrik -- Hendrik Scholz - [EMAIL PROTECTED] - http://raisdorf.net/ drag me, drop me - treat me like an object ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hang on boot w/ atapicam0: timeout waiting for ATAPI ready (5.1-CURRENT, IBM T30)
Le 2003-09-15, Lee Damon écrivait : Yesterday's cvsup'd and compiled kernel hung at acd0: CDRW UJDA720 DVD/CDRW at ata1-master UDMA33 atapicam0: timeout waiting for ATAPI ready This is from the low-level ATA layer. Do you see the same message if you disable ATAPICAM? Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi_cd or atapicam crash in current.
Le 2003-09-13, Daniel Eischen écrivait : cd0 at ata1 bus 0 target 0 lun 0 cd0: HL-DT-ST RW/DVD GCC-4240N D110 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [3737169375 x 3737169374 byte records] Several others have reported similar completely bogus sector size data. I suspect a problem in the new autosense code. It would be interesting to see what the kernel says when compiled with CAMDEBUG and running with CAM_DEBUG_CDB traces enabled (camcontrol debug -c). Thomas. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tuesday, September 16, 2003, at 06:11 AM, Bruce Evans wrote: On Tue, 16 Sep 2003, Maxim Konovalov wrote: PAE MFC brought an incredible instability to stable branch. It affects 100% of our user community especially when we issued several SAs since PAE commit. They often can't switch to RELENG_4_x security branches because even RELENG_4_8 misses several critical non-security fixes. Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Perhaps someone new is needed then to manage the import of OpenSSH if that is the case, if it is re@ or other decision member's of FreeBSD wouldn't allow it, then perhaps its time to restructure that part I'm not sure what the case is as other parts of been MFC'd lately without very much testing if any, noting the panic's that have been accruing on users running stable for the past 8 months. Should that just be taken as a sign of EoL for RELENG_4 ? I merged PAE into my version of -current a bit at a time and didn't notice any problems (with PAE not actually configured) despite having some large logical inconsistencies from not having all of it. Most of the global changes had no effect since they just changed the names of some typedefs without changing the underlying types in the !PAE case. So I suspect that any instabilities in RELENG_4 in the !PAE case are indirectly related to PAE and/or localized and thus easy to find and fix. Right the fix(es) should be trivial though incredibly hard to track down. Even more so that FreeBSD no long has anyone that is qualified to do any real work on the VM system. It is ridicules that re@ has allowed PAE to stay in the STABLE branch for still long with the amount of instability that it has created. I know its just uncovering bugs in the system that have always been present. Now we have many many kernel stack trace's and should be able to track it down over the next week months. For now though, the PAE commit should be removed from the RELENG_4 tree. Anything else should be not excepted by the FreeBSD community. -DR ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, Sep 16, 2003 at 08:43:00AM -0400, David Rhodus wrote: Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Merging new versions of software into the security branches is not what I really want to do. In general, I'll just backport the fix. In the past, we *have* merged new versions, but in hindsight this was usually a mistake. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atapicam panic
Le 2003-09-06, Petri Helenius écrivait :
Should this work or is the work to port this to ATAng still undergoing?
This should work, but does not, so the work is still in progress...
panic: mutex Giant not owned at ../../../dev/ata/atapi-cam.c:117
Please try this patch.
Index: atapi-cam.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v
retrieving revision 1.22
diff -u -r1.22 atapi-cam.c
--- atapi-cam.c 11 Sep 2003 17:34:47 - 1.22
+++ atapi-cam.c 16 Sep 2003 12:51:35 -
@@ -114,13 +114,10 @@
struct cam_path *path = NULL;
int unit;
-GIANT_REQUIRED;
-
if (mtx_initialized(atapicam_softc_mtx) == 0)
mtx_init(atapicam_softc_mtx, ATAPI/CAM softc mutex, NULL, MTX_DEF);
mtx_lock(atapicam_softc_mtx);
-
LIST_FOREACH(scp, all_buses, chain) {
if (scp-ata_ch == ata_ch)
break;
@@ -130,10 +127,12 @@
if (scp != NULL)
return;
-if ((scp = malloc(sizeof(struct atapi_xpt_softc),
- M_ATACAM, M_NOWAIT | M_ZERO)) == NULL)
- goto error;
+scp = malloc(sizeof(struct atapi_xpt_softc),
+M_ATACAM, M_NOWAIT | M_ZERO));
+mtx_lock (Giant);
+if (scp == NULL)
+ goto error;
scp-ata_ch = ata_ch;
TAILQ_INIT(scp-pending_hcbs);
LIST_INSERT_HEAD(all_buses, scp, chain);
@@ -165,10 +164,12 @@
setup_async_cb(scp, AC_LOST_DEVICE);
reinit_bus(scp, cold ? BOOT_ATTACH : ATTACH);
+mtx_unlock (Giant);
return;
error:
free_softc(scp);
+mtx_unlock (Giant);
}
void
--
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: acd0 vs cd0 (ATAPICAM)
Le 2003-09-06, Guillaume écrivait : I'm running FreeBSD 5-CURRENT (Aug. 28 2003) on a P3 733MHz, 768MB ram with a LG DVD-RW/DVD-RAM burner. I would like to know why ATAPICAM is so slow with my system. Maybe because ATAPI/CAM does not actually enable DMA. Can you try the following patch? Thomas. Index: atapi-cam.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.22 diff -u -r1.22 atapi-cam.c --- atapi-cam.c 11 Sep 2003 17:34:47 - 1.22 +++ atapi-cam.c 16 Sep 2003 13:20:18 - @@ -227,6 +227,11 @@ 2 * device_get_unit(atp-channel-dev) + (atp-unit == ATA_MASTER) ? 0 : 1); atp-softc = (void *)scp; + if (atapi_dma atp-channel-dma + (atp-param-config ATA_DRQ_MASK) != ATA_DRQ_INTR) + atp-setmode(atadev, ATA_DMA_MAX); + else + atp-setmode(atadev, ATA_PIO_MAX); } } -- [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: scsi_cd or atapicam crash in current.
On Tue, 16 Sep 2003, Thomas Quinot wrote: Le 2003-09-13, Daniel Eischen écrivait : cd0 at ata1 bus 0 target 0 lun 0 cd0: HL-DT-ST RW/DVD GCC-4240N D110 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [3737169375 x 3737169374 byte records] Several others have reported similar completely bogus sector size data. I suspect a problem in the new autosense code. It would be interesting to see what the kernel says when compiled with CAMDEBUG and running with CAM_DEBUG_CDB traces enabled (camcontrol debug -c). I get this even without atapicam in the kernel. Is trying CAMDEBUG and CAM_DEBUG_CDB going to show anything interesting? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: system hang on boot w/ atapicam0: timeout waiting for ATAPI ready (5.1-CURRENT, IBM T30)
Yesterday's cvsup'd and compiled kernel hung at acd0: CDRW UJDA720 DVD/CDRW at ata1-master UDMA33 atapicam0: timeout waiting for ATAPI ready This is from the low-level ATA layer. Do you see the same message if you disable ATAPICAM? If I remove ATAPICAM from the kernel the system boots normally with no timeout messages. nomad --- - Lee nomad Damon - \ play: [EMAIL PROTECTED]or castle!nomad \ work: [EMAIL PROTECTED] \ /\ Seneschal, Castle PAUS./ \ Celebrate Diversity /\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Bruce Evans wrote: On Tue, 16 Sep 2003, Maxim Konovalov wrote: PAE MFC brought an incredible instability to stable branch. It affects 100% of our user community especially when we issued several SAs since PAE commit. They often can't switch to RELENG_4_x security branches because even RELENG_4_8 misses several critical non-security fixes. I merged PAE into my version of -current a bit at a time and didn't notice any problems (with PAE not actually configured) despite having some large logical inconsistencies from not having all of it. Most of the global changes had no effect since they just changed the names of some typedefs without changing the underlying types in the !PAE case. So I suspect that any instabilities in RELENG_4 in the !PAE case are indirectly related to PAE and/or localized and thus easy to find and fix. Bruce Agreed. PAE was merged into -stable in three steps. Backing out the third step and leaving the first two steps removes the instability. Unfortunately, it was the third step that also was the most complex. In any case, we have 2 weeks to find the resolution before the decision must be made on keeping or tossing PAE. Since PAE is a *highly* sought after feature, it would be doing a disservice to our user base to remove it without putting in some effort to fix it. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, 16 Sep 2003, Scott Long wrote: :Bruce Evans wrote: : On Tue, 16 Sep 2003, Maxim Konovalov wrote: : : :PAE MFC brought an incredible instability to stable branch. It :affects 100% of our user community especially when we issued several :SAs since PAE commit. They often can't switch to RELENG_4_x security :branches because even RELENG_4_8 misses several critical non-security :fixes. : : : I merged PAE into my version of -current a bit at a time and didn't : notice any problems (with PAE not actually configured) despite having : some large logical inconsistencies from not having all of it. Most : of the global changes had no effect since they just changed the names : of some typedefs without changing the underlying types in the !PAE : case. So I suspect that any instabilities in RELENG_4 in the !PAE : case are indirectly related to PAE and/or localized and thus easy to : find and fix. : : Bruce : : :Agreed. PAE was merged into -stable in three steps. Backing out the :third step and leaving the first two steps removes the instability. :Unfortunately, it was the third step that also was the most complex. :In any case, we have 2 weeks to find the resolution before the decision :must be made on keeping or tossing PAE. Since PAE is a *highly* :sought after feature, it would be doing a disservice to our user base :to remove it without putting in some effort to fix it. : I fully agree with the last statement here. One reason my current employer left FreeBSD 4.x and went to linux for our embedded system was due to the lack of PAE support. We were planning to implement the extensions ourself, but, unfortunately, we in engineering were affected by time and money issues. Scott, keep up the good work. Cheers, Andrew -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi_cd or atapicam crash in current.
Le 2003-09-16, Daniel Eischen écrivait :
I get this even without atapicam in the kernel. Is trying
CAMDEBUG and CAM_DEBUG_CDB going to show anything interesting?
No, indeed, probably not. Can you try the following patch:
Index: ata-lowlevel.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v
retrieving revision 1.11
diff -u -r1.11 ata-lowlevel.c
--- ata-lowlevel.c 10 Sep 2003 09:57:16 - 1.11
+++ ata-lowlevel.c 16 Sep 2003 15:00:13 -
@@ -374,6 +374,11 @@
/* ATAPI PIO commands */
case ATA_R_ATAPI:
+ if (request-status (ATA_S_ERROR | ATA_S_DWF)) {
+ request-error = ATA_IDX_INB(ch, ATA_ERROR);
+ break;
+ }
+
length = ATA_IDX_INB(ch, ATA_CYL_LSB)|(ATA_IDX_INB(ch, ATA_CYL_MSB)8);
switch ((ATA_IDX_INB(ch, ATA_IREASON) (ATA_I_CMD | ATA_I_IN)) |
@@ -446,8 +451,6 @@
case ATAPI_P_ABORT:
case ATAPI_P_DONE:
- if (request-status (ATA_S_ERROR | ATA_S_DWF))
- request-error = ATA_IDX_INB(ch, ATA_ERROR);
break;
default:
--
[EMAIL PROTECTED]
pgp0.pgp
Description: PGP signature
Re: Release Engineering Status Report
David Rhodus [EMAIL PROTECTED] writes: Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Scott Long wrote: Bruce Evans wrote: On Tue, 16 Sep 2003, Maxim Konovalov wrote: PAE MFC brought an incredible instability to stable branch. It affects 100% of our user community especially when we issued several SAs since PAE commit. They often can't switch to RELENG_4_x security branches because even RELENG_4_8 misses several critical non-security fixes. I merged PAE into my version of -current a bit at a time and didn't notice any problems (with PAE not actually configured) despite having some large logical inconsistencies from not having all of it. Most of the global changes had no effect since they just changed the names of some typedefs without changing the underlying types in the !PAE case. So I suspect that any instabilities in RELENG_4 in the !PAE case are indirectly related to PAE and/or localized and thus easy to find and fix. Bruce Agreed. PAE was merged into -stable in three steps. Backing out the third step and leaving the first two steps removes the instability. Unfortunately, it was the third step that also was the most complex. In any case, we have 2 weeks to find the resolution before the decision must be made on keeping or tossing PAE. Since PAE is a *highly* sought after feature, it would be doing a disservice to our user base to remove it without putting in some effort to fix it. If someone who was involved in this would publish the date on which that last commit was made, people who are experiencing problems, but wish to stay as close to -STABLE as possible can use cvsup to revert their trees to a date immediately prior to the commit. This will solve both problems for now: i.e. the problem of users wanting the bugfixes/new features of -STABLE will have a target they can cvsup to that is reliable, while the developers can continue to pursue their goal of having PAE in 4.9. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scsi_cd or atapicam crash in current.
On Tue, 16 Sep 2003, Thomas Quinot wrote: Le 2003-09-16, Daniel Eischen écrivait : I get this even without atapicam in the kernel. Is trying CAMDEBUG and CAM_DEBUG_CDB going to show anything interesting? No, indeed, probably not. Can you try the following patch: OK, on a different system that has similar false CD detection and with the patch and with CAMDEBUG and `camcontrol debug -c all`: # camcontrol cmd cd0 -v -c 25 0 0 0 0 0 0 0 0 0 -i 8 i4 i4 -791621424 -791621424 # tail /var/log/messages (xpt0:xpt0:0:-1:-1): debugging flags now 8 (pass0:ata1:0:0:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 atapi_action: [EMAIL PROTECTED]: 25 0 0 0 0 0 0 0 0 0 atapi_cb: [EMAIL PROTECTED] status = 00: (sk = 00) acd0: cmd 25 Note that on this system, cd0 is not detected as present when built without atapicam. With atapicam yields false detection: acd0: CDRW HL-DT-STCD-RW/DVD-ROM GCC-4240N at ata1-master UDMA33 cd0 at ata1 bus 0 target 0 lun 0 cd0: HL-DT-ST RW/DVD GCC-4240N D110 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [3737169375 x 3737169374 byte records] -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from static to dynamic root
At Thu, 11 Sep 2003 14:44:55 +0200 (CEST), Harti Brandt wrote: Hi, I just tried to upgrade one of my systems from a static root from july to an actual dynamic root. The installworld went fine 'til the place where /bin/test is installed. At that point the installation stopped with ELF interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not populated yet. Me too :( To get installworld back on track I used cp under linux emulation to copy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that make installworld completed successfully. -Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Bill Moran wrote: Scott Long wrote: Bruce Evans wrote: On Tue, 16 Sep 2003, Maxim Konovalov wrote: PAE MFC brought an incredible instability to stable branch. It affects 100% of our user community especially when we issued several SAs since PAE commit. They often can't switch to RELENG_4_x security branches because even RELENG_4_8 misses several critical non-security fixes. I merged PAE into my version of -current a bit at a time and didn't notice any problems (with PAE not actually configured) despite having some large logical inconsistencies from not having all of it. Most of the global changes had no effect since they just changed the names of some typedefs without changing the underlying types in the !PAE case. So I suspect that any instabilities in RELENG_4 in the !PAE case are indirectly related to PAE and/or localized and thus easy to find and fix. Bruce Agreed. PAE was merged into -stable in three steps. Backing out the third step and leaving the first two steps removes the instability. Unfortunately, it was the third step that also was the most complex. In any case, we have 2 weeks to find the resolution before the decision must be made on keeping or tossing PAE. Since PAE is a *highly* sought after feature, it would be doing a disservice to our user base to remove it without putting in some effort to fix it. If someone who was involved in this would publish the date on which that last commit was made, people who are experiencing problems, but wish to stay as close to -STABLE as possible can use cvsup to revert their trees to a date immediately prior to the commit. This will solve both problems for now: i.e. the problem of users wanting the bugfixes/new features of -STABLE will have a target they can cvsup to that is reliable, while the developers can continue to pursue their goal of having PAE in 4.9. Patches have been floated on the mailing list that revert PAE in its various stages. Maybe those need to be brought back up. Silby? Tor? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atheros (ath) driver bridging
Howdy list, Is the ath(4) driver, like the wi(4) driver, incapable of performing bridging? For reference, this is from the bridge(4) manpage: Bridging requires interfaces to be put in promiscuous mode, and transmit packets with Ethernet source addresses. Some interfaces (e.g. wi(4)) do not support this functionality. Also, bridging is not compatible with interfaces which use hardware loopback, because there is no way to tell locally generated packets from externally generated ones. ath(4) manpage: http://www.freebsd.org/cgi/man.cgi?query=athapropos=0sektion=0manpath=FreeBSD+5.1-currentformat=html wi(4) manpage: http://www.freebsd.org/cgi/man.cgi?query=wisektion=4apropos=0manpath=FreeBSD+5.1-current bridge(4) manpage: http://www.freebsd.org/cgi/man.cgi?query=bridgeapropos=0sektion=0manpath=FreeBSD+5.1-currentformat=html Just curious. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgrade from static to dynamic root
On Tue, 16 Sep 2003, Richard Nyberg wrote: RNAt Thu, 11 Sep 2003 14:44:55 +0200 (CEST), RNHarti Brandt wrote: RN Hi, RN RN I just tried to upgrade one of my systems from a static root from july to RN an actual dynamic root. The installworld went fine 'til the place where RN /bin/test is installed. At that point the installation stopped with ELF RN interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not RN populated yet. RN RNMe too :( RNTo get installworld back on track I used cp under linux emulation to RNcopy ld-elf.so.1. Then I also had to run ldconfig -m /lib. After that RNmake installworld completed successfully. Or you could cd into /usr/obj/usr/src/rescue/rescue and do ./rescue cp ... (as long as you have a working shell) harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Release Engineering Status Report
Apparently, yes. http://slashdot.org/articles/03/09/16/1327248.shtml?tid=126tid=172 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dag-Erling Smørgrav Sent: Tuesday, September 16, 2003 11:54 AM To: David Rhodus Cc: Maxim Konovalov; Scott Long; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Release Engineering Status Report David Rhodus [EMAIL PROTECTED] writes: Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, 16 Sep 2003, Scott Long wrote: Patches have been floated on the mailing list that revert PAE in its various stages. Maybe those need to be brought back up. Silby? Tor? Scott I believe that Tor's commit on August 30th resolved the PAE-related problems, so there is no need for a reversion. Since that time, I've seen three panics posted: 1. Some netinet/ related panic which I couldn't make heads or tails of, and I haven't any followup reports from the poster. 2. Maxim's buildworld -j64 memory kmap entry exhaustion panic, which can be fixed by increasing the number of kmap entries. (Tor has a patch for this, I will probably commit it soon.) 3. A panic caused by sending 64K-1 ping packets, which I can't reproduce. (There's also a small problem with if_xl on pentium-1 machines, but since it's my fault and I'm waiting on test results from a guy, we won't talk about it.) (Hey, anyone have a pentium-200 and a 3com 905B card? Contact me, further testing can't hurt.) So, as far as I can tell, there are no remaining problems related to PAE; I believe that most people are venting frustration that built up between August 9th and 30th. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
3. A panic caused by sending 64K-1 ping packets, which I can't reproduce. Is this a firewall induced panic? -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Mike Silbersack wrote: On Tue, 16 Sep 2003, Scott Long wrote: Patches have been floated on the mailing list that revert PAE in its various stages. Maybe those need to be brought back up. Silby? Tor? Scott I believe that Tor's commit on August 30th resolved the PAE-related problems, so there is no need for a reversion. Since that time, I've seen three panics posted: 1. Some netinet/ related panic which I couldn't make heads or tails of, and I haven't any followup reports from the poster. 2. Maxim's buildworld -j64 memory kmap entry exhaustion panic, which can be fixed by increasing the number of kmap entries. (Tor has a patch for this, I will probably commit it soon.) 3. A panic caused by sending 64K-1 ping packets, which I can't reproduce. (There's also a small problem with if_xl on pentium-1 machines, but since it's my fault and I'm waiting on test results from a guy, we won't talk about it.) (Hey, anyone have a pentium-200 and a 3com 905B card? Contact me, further testing can't hurt.) So, as far as I can tell, there are no remaining problems related to PAE; I believe that most people are venting frustration that built up between August 9th and 30th. Mike Silby Silbersack Ok, thanks for the update. Since it is 17 days after Aug 30 and people are still upset, the status was very unclear to the Release Engineering Team. So I guess we ened to solicit updates from the people who were directly experiencing problems, and ask for everyone else to test it as much as possible. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Is the ath(4) driver, like the wi(4) driver, incapable of performing bridging? Yes. Bridging happens outside the operation of the driver. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Is the ath(4) driver, like the wi(4) driver, incapable of performing bridging? Sorry, answered too quickly. ath and wi have the same restrictions. You can use bridging to hookup a wired and wireless network but not two wireless networks. I can't tell from your posting what you are trying to do. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, Sep 16, 2003 at 12:16:30PM -0400, Mike Jakubik typed: Apparently, yes. http://slashdot.org/articles/03/09/16/1327248.shtml?tid=126tid=172 Fortunately, there's allready a patch in the source tree: http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/openssh/buffer.c.diff?r1=1.1.1.6r2=1.1.1.7f=h ruben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dag-Erling Sm?rgrav Sent: Tuesday, September 16, 2003 11:54 AM To: David Rhodus Cc: Maxim Konovalov; Scott Long; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Release Engineering Status Report David Rhodus [EMAIL PROTECTED] writes: Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? DES -- Dag-Erling Sm?rgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-09-16 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-09-16 16:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-09-16 16:01:50 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-16 17:04:43 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Sep 16 17:04:43 GMT 2003 Kernel build for GENERIC completed on Tue Sep 16 17:16:35 GMT 2003 TB --- 2003-09-16 17:16:35 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-16 17:16:35 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Sep 16 17:16:35 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:405: error: `LSR_RXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:409: error: `com_data' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:440: error: `com_msr' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:442: error: `LSR_TXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:442: error: `MSR_CTS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:462: error: `com_iir' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_IMASK' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_NOPEND' undeclared (first use in this function) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-09-16 17:21:51 - /usr/bin/make returned exit code 1 TB --- 2003-09-16 17:21:51 - ERROR: failed to build lint kernel TB --- 2003-09-16 17:21:51 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
I think what he meant was that at on state was known (I don't know the current state) that as the wi could not be but in promiscuous mode it could not be used for bridging.. Bridging requires promiscuous mode (or some very tricky proxy-arp stuff). On Tue, 16 Sep 2003, Sam Leffler wrote: Is the ath(4) driver, like the wi(4) driver, incapable of performing bridging? Yes. Bridging happens outside the operation of the driver. 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]
Re: mysql-client compiler error
Hello,
On Mon, Sep 15, 2003 at 11:42:29AM +1000, Mark Sergeant wrote:
I get the same problem in the same place with current as of today.
I also noticed this issue. I just got a reply from the port maintainer
Alex Dupre as follows:
MR It won't configure. Output on my machine is as below.
I'm aware of this problem...It's due to the removal of -pthread gcc
options in -current. I'll create a patch to fix it, in the meanwhile
you may replace every instance of -pthread with ${PTHREAD_LIBS} in all
configure(s).
Marcus
Cheers,
Mark
On Sat, 2003-09-13 at 20:37, Matt wrote:
After building world as of late last night I decided to portupgrade
-rRaf, mainly due to having the libintl.so.4 missing problem when I
tried to start X. Everything compiled perfectly fine (and X is now
working fine) except for databases/mysql40-client. I get this error:
checking for C compiler default output... configure: error: C compiler
cannot create executables
configure: error: could not configure Berkeley DB
I just wish to know is this something wrong with my system in general or
is this just due to the -pthread discussions that have been occuring and
that this port is one example of those that no longer works on -current?
It is not a problem as I have the previously compiled/installed version
still on the system but I just wish to confirm if the problem is likely
to be down to the pthreads changes, and if I should report it to the
port maintainer etc?
Matt.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Mark Sergeant [EMAIL PROTECTED]
SNSOnline Technical Services
___
[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: atheros (ath) driver bridging
I think what he meant was that at on state was known (I don't know the current state) that as the wi could not be but in promiscuous mode it could not be used for bridging.. Bridging requires promiscuous mode (or some very tricky proxy-arp stuff). You can put wi (and ath) in promiscuous mode. The bridge manual page is wrong and I will fix it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
I'm not sure what I typed there but what I meant to say was At one stage the wi driver could not be put in promiscuous mode and the bridging code required that. Most people still think this is true. On Tue, 16 Sep 2003, Sam Leffler wrote: I think what he meant was that at on state was known (I don't know the current state) that as the wi could not be but in promiscuous mode it could not be used for bridging.. Bridging requires promiscuous mode (or some very tricky proxy-arp stuff). You can put wi (and ath) in promiscuous mode. The bridge manual page is wrong and I will fix it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
Scott Long wrote: Agreed. PAE was merged into -stable in three steps. Backing out the third step and leaving the first two steps removes the instability. Unfortunately, it was the third step that also was the most complex. In any case, we have 2 weeks to find the resolution before the decision must be made on keeping or tossing PAE. Since PAE is a *highly* sought after feature, it would be doing a disservice to our user base to remove it without putting in some effort to fix it. Not to be rude or anything, so please don't take it that way... Exactly why is PAE ...a *highly* sought after feature...? It's not like it increases the KVA space for the kernel itself, or UVA space for individual processes. I could maybe understand if processes were no longer mapped into KVA on trap/system call entry, since that would cause the UVA and KVA to both go to the full 4G size, at some additional copying cost, which is (relatively) low on Intel, for the benefit of a larger virtual address space that would let you map more kernel data and/or run larger application working sets for things like databases. But as it is, it's basically nothing more than L3 cache, which has always been seen as being of dubious benefit (otherwise all machines would come with L3 caches). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] workaround for kern/56869
--- /usr/src/sys/modules/Makefile.orig Tue Sep 16 10:42:38 2003 +++ /usr/src/sys/modules/Makefile Tue Sep 16 10:42:54 2003 @@ -126,7 +126,6 @@ twe \ tx \ txp \ - uart \ ubsa \ ubsec \ ucom \ -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and a Toshiba Tecra 8000
Please compile your kernel with debug symbols (config -g KERNEL) and load it into gdb to get the actual line of code that is getting that NULL deref: gdb kernel.debug l *scsuspend+0x17 That should show the offending code segment. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT
(To recap: I'm having ACPI problems on a DFI CD70-SC, with both 5.1-R and 5-CURRENT. Booting GENERIC doesn't show any problems, however, so there's a good chance it's a misconfiguration issue.) Thus spake Damian Gerow ([EMAIL PROTECTED]) [15/09/03 17:34]: It's attached. There's no APM in there. I did some more testing -- GENERIC works for the -CURRENT date I stated before, and 5.1-R. As soon as I compile my own kernel, it breaks. Okay, here's a backtrace with debugging. Unfortunately, when dropped to the debugging prompt, I don't know what to do. Attached is the kernel config I used to generate this on 5.1-R, I can re-do this on -CURRENT if need be. Here's a snippet of boot, and the stack backtrace: ... Preloaded elf kernel /boot/kernel/kernel at 0xc04b8000 Preloaded elf module /boot/kernel/acpi.ko at 0xc04b81f4 ... real memory = 536870912 (512 MB) avail memory = 516313088 (492 MB) panic: pmap_mapdev: Couldn't allocate kernel virtual memory Stack backtrace: backtrace(c035b0cc,c03baea0,c0372994,c04dabbc,100) at backtrace+0x17 panic(c0372994,c036f000,0,0,0) at panic+0x93 pmap_mapdev(1fff3000,c036ec14,c04dac48,c04dabcc,c048e880) at pmap_mapdev+0x4b AcpiOsMapMemory(1fff3000,0,c036ec14,c04dabbc,c04dabc4) atAcpiOsMapMemory+0x1e I'm almost certain your problem is defining MAXMEM to 512 MB. Remove that from your kernel config and try again. MAXMEM causes all kinds of problems. If this doesn't solve it, start with the stock GENERIC and add back in your custom kernel options until it fails. The last option you add is the faulty one. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Howdy, Sam Leffler wrote: ath and wi have the same restrictions. You can use bridging to hookup a wired and wireless network but not two wireless networks. I can't tell from your posting what you are trying to do. Sam I figured now would be a good place to chime in about WDS. I'm currious about what you folks think about the future of the ath, wi ,et'all drivers in regards to WDS bridging? Would this type of bridging (wireless to wireless) be implemented in the drivers, or hook into the BRIDGE code? I'm thinking the driver itself would take care of all that, right? The ideal situation would be similare to a net4521 board with one radio in hostap mode bridged to the wired network, the 2nd radio in WDS mode bridged to either the other radio, or the wired network. Or something like that. I asume this is all pointless until good docs are provided to us folks from the radio makers who seem on guard about their stupid firmware. bah! __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and a Toshiba Tecra 8000
Nate Lawson wrote: Please compile your kernel with debug symbols (config -g KERNEL) and load it into gdb to get the actual line of code that is getting that NULL deref: gdb kernel.debug l *scsuspend+0x17 That should show the offending code segment. Hopefully I have done this right :) (gdb) l *scsuspend+0x17 0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111). 106 int retry = 10; 107 static int dummy; 108 sc_softc_t *sc; 109 110 sc = main_softc; 111 sc_cur_scr = sc-cur_scp-index; 112 113 if (sc_no_suspend_vtswitch) 114 return (0); 115 (gdb) Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and a Toshiba Tecra 8000
On Wed, 17 Sep 2003, Andrew Thompson wrote: Nate Lawson wrote: gdb kernel.debug l *scsuspend+0x17 That should show the offending code segment. (gdb) l *scsuspend+0x17 0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111). 106 int retry = 10; 107 static int dummy; 108 sc_softc_t *sc; 109 110 sc = main_softc; 111 sc_cur_scr = sc-cur_scp-index; 112 113 if (sc_no_suspend_vtswitch) 114 return (0); 115 Ok, this shows it's not ok to unconditionally deref sc-cur_scp. Now I'll look for what cases it is NULL. I'll get back to you in a day or so. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
On Tue, Sep 16, 2003 at 11:16:54AM -0700, Julian Elischer wrote: I'm not sure what I typed there but what I meant to say was At one stage the wi driver could not be put in promiscuous mode and the bridging code required that. Most people still think this is true. I think it is still true. What you can do is bridging between ethernet and wireless if you use host-ap mode. What you can't do is bridging ethernet-wireless --- wireless-ethernet. For that you will need WDS or something similar. On Tue, 16 Sep 2003, Sam Leffler wrote: I think what he meant was that at on state was known (I don't know the current state) that as the wi could not be but in promiscuous mode it could not be used for bridging.. Bridging requires promiscuous mode (or some very tricky proxy-arp stuff). You can put wi (and ath) in promiscuous mode. The bridge manual page is wrong and I will fix it. 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]
[current tinderbox] failure on i386/i386
TB --- 2003-09-16 18:27:08 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-09-16 18:27:08 - 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-09-16 18:29:00 - 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-09-16 19:25:32 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Sep 16 19:25:32 GMT 2003 Kernel build for GENERIC completed on Tue Sep 16 19:39:43 GMT 2003 TB --- 2003-09-16 19:39:43 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-16 19:39:43 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Sep 16 19:39:43 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:405: error: `LSR_RXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:409: error: `com_data' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:440: error: `com_msr' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:442: error: `LSR_TXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:442: error: `MSR_CTS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:462: error: `com_iir' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_IMASK' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_NOPEND' undeclared (first use in this function) *** 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-09-16 19:46:27 - /usr/bin/make returned exit code 1 TB --- 2003-09-16 19:46:27 - ERROR: failed to build lint kernel TB --- 2003-09-16 19:46:27 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ath(4) stopped working
Hi, I just built a kernel with latest sources, unfortunately, my ath(4) card stopped working. The device is there, devd sets ip address, route etc., just as it did before the upgrade - the problem is that the link is dead, there's _nothing_ going over the link. It also seems to re-associate with the AP quite often. A kernel from Fri Sep 12 works correctly, with the same configuration. I guess the ath/ieee80211 commits from yesterday/today broke something. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ata-lowlevel.c and lost disk
Hello there! For versions of ata-lowlevel.c 1.9 the ad1 device isn't found. Below is working dmesg with ata-lowlevel.c 1.9. -Richard 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 #2: Tue Sep 16 20:46:17 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GROMIT Preloaded elf kernel /boot/kernel/kernel at 0xc0499000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04991f4. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 402587648 (383 MB) avail memory = 385961984 (368 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: MSISYS MS-6163W on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fd4c0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 14 INTA is routed to irq 11 pcib0: slot 16 INTA is routed to irq 12 pcib0: slot 18 INTA is routed to irq 5 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: serial bus, USB at device 7.2 (no driver attached) pci0: bridge, PCI-unknown at device 7.3 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0xe400-0xe43f mem 0xec00-0xec01,0xec021000-0xec021fff irq 11 at device 14.0 on pci0 fxp0: Ethernet address 00:02:b3:a7:68:1f miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xe800-0xe87f mem 0xec02-0xec02007f irq 12 at device 16.0 on pci0 xl0: Ethernet address: 00:50:da:dd:2f:21 miibus1: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus1 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: multimedia, audio at device 18.0 (no driver attached) fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: Option ROMs at iomem 0xc8000-0xc9fff,0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 501138255 Hz quality 800 Timecounters tick every 10.000 msec IP Filter: v3.4.31 initialized. Default = pass all, Logging = disabled acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% GEOM: create disk ad0 dp=0xc3364e70 ad0: 19574MB IBM-DPTA-372050 [39770/16/63] at ata0-master UDMA33 GEOM: create disk ad1 dp=0xc3364d70 ad1: 57241MB ST360021A [116301/16/63] at ata0-slave UDMA33 Mounting root from ufs:/dev/ad0s1a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
using tip on machine that has COMCONSOLE set to serial
This may be a dumb question, but I have a situation where machine A and B both have enabled serial console. I'm ssh'ing into A to try and debug a problem on B. I'm trying to use tip, but am getting interference from the fact that A also has a serial console. If i disable the getty, its a bit better. Is there a way to make this work reliably, or am I SOL? --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT
Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 15:00]: I'm almost certain your problem is defining MAXMEM to 512 MB. Remove that from your kernel config and try again. MAXMEM causes all kinds of problems. If this doesn't solve it, start with the stock GENERIC and add back in your custom kernel options until it fails. The last option you add is the faulty one. I was wondering the same thing myself last night actually... I just pulled that line, and it now works. Which is weird -- I have two other 5.1 machines that I have specified MAXMEM in, without any troubles. It's also strange that this would only be brought out with ACPI...? Anyhow, it's working for me now. If anyone feels like further debugging, I'm all game. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) stopped working
I just built a kernel with latest sources, unfortunately, my ath(4) card stopped working. The device is there, devd sets ip address, route etc., just as it did before the upgrade - the problem is that the link is dead, there's _nothing_ going over the link. It also seems to re-associate with the AP quite often. A kernel from Fri Sep 12 works correctly, with the same configuration. I guess the ath/ieee80211 commits from yesterday/today broke something. I need more help than this. Try supplying some information like the card type (e.g. 5212) and your setup (station, adhoc, hostap, 11a, 11b, 11g). Also try sysctl debug.ieee80211=1 and/or ifconfig ath0 debug and look at the debug messages. Obviously stuff worked for me before I committed (and I tested all types of cards). Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT [SOLVED]
On Tue, 16 Sep 2003, Damian Gerow wrote: Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 15:00]: I'm almost certain your problem is defining MAXMEM to 512 MB. Remove that from your kernel config and try again. MAXMEM causes all kinds of problems. If this doesn't solve it, start with the stock GENERIC and add back in your custom kernel options until it fails. The last option you add is the faulty one. I was wondering the same thing myself last night actually... I just pulled that line, and it now works. Which is weird -- I have two other 5.1 machines that I have specified MAXMEM in, without any troubles. It's also strange that this would only be brought out with ACPI...? Anyhow, it's working for me now. If anyone feels like further debugging, I'm all game. It probably has something to do with the virtual/physical gymnastics ACPI has to do to map its tables into memory. I have no time to track this down but the output of acpidump -t may help someone else who might be interested. You're looking for the pointers that are stored in RSD PTR. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT [SOLVED]
Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 16:24]: I have no time to track this down but the output of acpidump -t may help someone else who might be interested. You're looking for the pointers that are stored in RSD PTR. I'm still on 5.1-R, and there's no '-t' flag to acpidump. However, I've posted the dump on the web: http://www.sentex.net/~damian/acpidump so people can browse as they wish. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT [SOLVED]
On Tue, 16 Sep 2003, Damian Gerow wrote: Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 16:24]: I have no time to track this down but the output of acpidump -t may help someone else who might be interested. You're looking for the pointers that are stored in RSD PTR. I'm still on 5.1-R, and there's no '-t' flag to acpidump. However, I've posted the dump on the web: http://www.sentex.net/~damian/acpidump so people can browse as they wish. As expected, your ACPI tables are at the top of physmem: RSDT=0x1fff3000. This is only 52k from 512MB. Something in how MAXMEM affects setup of physical memory is truncating physmem by at least 64k. In short, Don't Do That. -Nate ___ [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-09-16 19:46:27 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-09-16 19:46:27 - 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-09-16 19:49:03 - 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-09-16 20:45:41 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Sep 16 20:45:41 GMT 2003 Kernel build for GENERIC completed on Tue Sep 16 20:57:28 GMT 2003 TB --- 2003-09-16 20:57:28 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-16 20:57:28 - 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 Tue Sep 16 20:57:28 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:405: error: `LSR_RXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:409: error: `com_data' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:440: error: `com_msr' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:442: error: `LSR_TXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:442: error: `MSR_CTS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:462: error: `com_iir' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_IMASK' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_NOPEND' undeclared (first use in this function) *** 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-09-16 21:02:38 - /usr/bin/make returned exit code 1 TB --- 2003-09-16 21:02:38 - ERROR: failed to build lint kernel TB --- 2003-09-16 21:02:38 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, Sep 16, 2003 at 10:30:50AM -0600, Scott Long wrote: Mike Silbersack wrote: On Tue, 16 Sep 2003, Scott Long wrote: Patches have been floated on the mailing list that revert PAE in its various stages. Maybe those need to be brought back up. Silby? Tor? Scott I believe that Tor's commit on August 30th resolved the PAE-related problems, so there is no need for a reversion. Since that time, I've seen three panics posted: 1. Some netinet/ related panic which I couldn't make heads or tails of, and I haven't any followup reports from the poster. 2. Maxim's buildworld -j64 memory kmap entry exhaustion panic, which can be fixed by increasing the number of kmap entries. (Tor has a patch for this, I will probably commit it soon.) 3. A panic caused by sending 64K-1 ping packets, which I can't reproduce. (There's also a small problem with if_xl on pentium-1 machines, but since it's my fault and I'm waiting on test results from a guy, we won't talk about it.) (Hey, anyone have a pentium-200 and a 3com 905B card? Contact me, further testing can't hurt.) So, as far as I can tell, there are no remaining problems related to PAE; I believe that most people are venting frustration that built up between August 9th and 30th. Mike Silby Silbersack Ok, thanks for the update. Since it is 17 days after Aug 30 and people are still upset, the status was very unclear to the Release Engineering Team. So I guess we ened to solicit updates from the people who were directly experiencing problems, and ask for everyone else to test it as much as possible. I was one the people who were experiencing stability problems after the PAE commit. I had several unexpected panics and could provoke panics nearly at will on systems that had previously been rock-stable. After the Aug 30 commit I have not had any panics at all and I have not experienced any other stability problems either since then. In my personal experience RELENG_4 is currently quite stable (not counting any commits made during the last 48 hours or so since I have not yet tested any of those), but it is of course possible that other people have run into bugs in components of the kernel that I don't use. (Note: I do not have PAE enabled in the kernel. I have no idea what the situation is for those who actually have enabled PAE, but any problems that may exist there is non-critical IMO since they would not affect any pre-existing configurations.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng hangs with kernel from september 15
If I start my kernel from september 15, my computer hangs after this message: atapci0: VIA 82C686B UDMA100 controller port 0xa400-0xa40f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] A kernel from september 7 works normally. A normal dmesg is attached. Anything I can try? Arjan Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #1: Sun Sep 7 01:04:52 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMD760 Preloaded elf kernel /boot/kernel.old/kernel at 0xc078. Preloaded elf module /boot/kernel.old/sbp.ko at 0xc07801f8. Preloaded elf module /boot/kernel.old/acpi.ko at 0xc07802a4. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2000+ (1668.71-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 536805376 (511 MB) avail memory = 513282048 (489 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: 761686 AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fdeb0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 5 pcib0: slot 7 INTD is routed to irq 5 pcib0: slot 8 INTA is routed to irq 5 pcib0: slot 11 INTA is routed to irq 5 pcib0: slot 13 INTA is routed to irq 11 pcib0: slot 15 INTA is routed to irq 11 agp0: AMD 761 host to AGP bridge port 0xa000-0xa003 mem 0xf600-0xf6000fff,0xf000-0xf3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci_cfgintr: 1:5 INTA BIOS irq 10 drm0: ATI Radeon QD R100 port 0x9000-0x90ff mem 0xf500-0xf507,0xe800-0xefff irq 10 at device 5.0 on pci1 info: [drm] AGP at 0xf000 64MB info: [drm] Initialized radeon 1.9.0 20020828 on minor 0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xa400-0xa40f at device 7.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 0xa800-0xa81f irq 5 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xac00-0xac1f irq 5 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: serial bus, SMBus at device 7.4 (no driver attached) fwohci0: VIA VT6306 port 0xb000-0xb07f mem 0xf6001000-0xf60017ff irq 5 at device 8.0 on pci0 fwohci0: [MPSAFE] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:e0:18:00:00:1c:f1:57 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S100, max_rec 2 bytes. fwohci0: max_rec 2 - 2048 firewire0: IEEE1394(FireWire) bus on fwohci0 if_fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:1c:f1:57 sbp0: SBP2/SCSI over firewire on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pcm0: Creative EMU10K1 port 0xb400-0xb41f irq 5 at device 11.0 on pci0 pcm0: TriTech TR28023 AC97 Codec sym0: 810a port 0xbc00-0xbcff mem 0xf6002000-0xf60020ff irq 11 at device 13.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking rl0: RealTek 8139 10/100BaseTX, rev. B port 0xc000-0xc0ff mem 0xf6003000-0xf60030ff irq 11 at device 15.0 on pci0 rl0: Ethernet address: 00:10:a7:01:65:54 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on
Re: ATAng hangs with kernel from september 15
--On Tuesday, September 16, 2003 23:09:57 +0200 Arjan van Leeuwen [EMAIL PROTECTED] wrote: If I start my kernel from september 15, my computer hangs after this message: atapci0: VIA 82C686B UDMA100 controller port 0xa400-0xa40f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] A kernel from september 7 works normally. A normal dmesg is attached. Anything I can try? Arjan Soren suggested I instrument ata-lowlevel.c (1.10 works, 1.11+ doesn't). I have the same issue with my ICH3. I'm glad I'm not the only one. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: ATAng hangs with kernel from september 15
Aloha! Arjan van Leeuwen wrote: If I start my kernel from september 15, my computer hangs after this message: atapci0: VIA 82C686B UDMA100 controller port 0xa400-0xa40f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] Did you wait a while? I just completed my system update (getting the OpenSSH patch in at the same time, thanks sec-team!). After reboot my system also stopped at the exact message above. After what felt like about a minute, the system continued to boot and is running normally. Try again and see if it is a real, solid hang, or if it just takes a while. Included is my dmesg. -- Med vänlig hälsning, Cheers! Joachim Strömbergson Joachim Strömbergson - ASIC designer, nice to *cute* animals. snail: phone: mail web: Sävenäsgatan 5A+46 31 - 27 98 47 [EMAIL PROTECTED] 416 72 Göteborg+46 733 75 97 02 www.ludd.luth.se/~watchman 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 #10: Tue Sep 2 09:44:15 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ATHLON Preloaded elf kernel /boot/kernel/kernel at 0xc0676000. Preloaded elf module /boot/kernel/linux.ko at 0xc0676244. Preloaded elf module /boot/kernel/nvidia.ko at 0xc06762f0. Preloaded elf module /boot/kernel/acpi.ko at 0xc067639c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 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=0xc040AMIE,DSP,3DNow! real memory = 536854528 (511 MB) avail memory = 514424832 (490 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V8Xon motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f1cd0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 32-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 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 9 INTA is routed to irq 10 pcib0: slot 11 INTA is routed to irq 6 pcib0: slot 15 INTA is routed to irq 10 pcib0: slot 16 INTA is routed to irq 9 pcib0: slot 16 INTB is routed to irq 9 pcib0: slot 16 INTC is routed to irq 9 pcib0: slot 16 INTD is routed to irq 9 agp0: VIA Generic host to PCI bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 11 nvidia0: GeForce2 GTS/GeForce2 Pro mem 0xf000-0xf7ff,0xee00-0xeeff irq 11 at device 0.0 on pci1 pci0: network, ethernet at device 9.0 (no driver attached) fxp0: Intel 82550 Pro/100 Ethernet port 0xd800-0xd83f mem 0xec80-0xec81,0xed00-0xed000fff irq 6 at device 11.0 on pci0 fxp0: Ethernet address 00:02:b3:97:19:f8 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xd400-0xd41f irq 10 at device 15.0 on pci0 pcm0: TriTech TR28602 AC97 Codec pci0: serial bus, USB at device 16.0 (no driver attached) pci0: serial bus, USB at device 16.1 (no driver attached) pci0: serial bus, USB at device 16.2 (no driver attached) pci0: serial bus, USB at device 16.3 (no driver attached) isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 8235 UDMA133 controller port 0xa800-0xa80f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 speaker0 port 0x61 on acpi0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 orm0: Option ROM at iomem 0xcc000-0xcd7ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 1666738177 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding
Re: ath(4) stopped working
On Tue, 16 Sep 2003, Sam Leffler wrote: A kernel from Fri Sep 12 works correctly, with the same configuration. I guess the ath/ieee80211 commits from yesterday/today broke something. I need more help than this. Try supplying some information like the card type (e.g. 5212) and your setup (station, adhoc, hostap, 11a, 11b, 11g). Yes, it's a 5212 card (a Netgear WAG511, to be more specific). I'm using it in 11g mode with a Netgear AP. Also try sysctl debug.ieee80211=1 and/or ifconfig ath0 debug and look at the debug messages. Ok, here's what I got: ---8--- Sep 16 22:40:17 korben kernel: ath0: Atheros 5212 mem 0x2000-0x2000 irq 11 at device 0.0 on cardbus1 Sep 16 22:40:17 korben kernel: ath0: [MPSAFE] Sep 16 22:40:17 korben kernel: ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Sep 16 22:40:17 korben kernel: ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Sep 16 22:40:17 korben kernel: ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Sep 16 22:40:17 korben kernel: ath0: 802.11 address: 00:09:5b:41:8d:ac Sep 16 22:40:17 korben kernel: ieee80211_newstate: INIT - SCAN Sep 16 22:40:17 korben kernel: ieee80211_next_scan: chan 1-2 Sep 16 22:40:17 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:17 korben kernel: ieee80211_newstate: SCAN - INIT Sep 16 22:40:17 korben kernel: ieee80211_newstate: INIT - SCAN Sep 16 22:40:17 korben kernel: ieee80211_next_scan: chan 2-3 Sep 16 22:40:17 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 3-4 Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 4-5 Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 5-6 Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 6-7 Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:18 korben kernel: ieee80211_next_scan: chan 7-8 Sep 16 22:40:18 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 8-9 Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 9-10 Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 10-11 Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 11-1 Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: new probe response on chan 1 (bss chan 1) LESSID from 00:09:5b:67:48:85 Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: caps 0x411 bintval 100 erp 0x0 Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: beacon on chan 1 (bss chan 1) LESSID from 00:09:5b:67:48:85 Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: caps 0x411 bintval 100 erp 0x0 Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: beacon on chan 1 (bss chan 1) LESSID from 00:09:5b:67:48:85 Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: caps 0x411 bintval 100 erp 0x0 Sep 16 22:40:19 korben kernel: ieee80211_next_scan: chan 1-2 Sep 16 22:40:19 korben kernel: ieee80211_newstate: SCAN - SCAN Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: ignore probe response on channel 2 marked for channel 1 Sep 16 22:40:19 korben kernel: ieee80211_recv_mgmt: ignore beacon on channel 2 marked for channel 1 Sep 16 22:40:20 korben kernel: ieee80211_recv_mgmt: ignore beacon on channel 2 marked for channel 1 Sep 16 22:40:20 korben kernel: ieee80211_newstate: SCAN - AUTH Sep 16 22:40:20 korben kernel: ieee80211_newstate: AUTH - ASSOC Sep 16 22:40:20 korben kernel: ieee80211_newstate: ASSOC - RUN Sep 16 22:40:36 korben kernel: ath_rate_ctl: 54M - 48M (1 ok, 9 err, 9 retr) Sep 16 22:41:09 korben kernel: ath_rate_ctl: 48M - 36M (0 ok, 1 err, 1 retr) Sep 16 22:41:10 korben kernel: ath_rate_ctl: 36M - 24M (0 ok, 1 err, 1 retr) Sep 16 22:41:11 korben kernel: ath_rate_ctl: 24M - 18M (0 ok, 1 err, 1 retr) Sep 16 22:41:12 korben kernel: ath_rate_ctl: 18M - 12M (0 ok, 1 err, 1 retr) Sep 16 22:41:13 korben kernel: ath_rate_ctl: 12M - 11M (0 ok, 1 err, 1 retr) ---8--- The rate control shift at the end starts as soon as I start pinging some hosts. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
cvsup sites are all at capacity?
I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and each site returns this message: Rejected by server: Access limit exceeded; try again later I've gotten that before but never with all of the hosts out there. Is everyone and their brother doing a make world today, are the sites down for maintenance, or is something sinister going on? Just wonderin' Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup sites are all at capacity?
On Tue, Sep 16, 2003 at 04:01:39PM -0600, Andrew Lankford wrote: I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and each site returns this message: Rejected by server: Access limit exceeded; try again later I've gotten that before but never with all of the hosts out there. Is everyone and their brother doing a make world today, Probably. There was a security advisory for OpenSSH released earlier today, so I would guess just about everybody is trying to update their systems. are the sites down for maintenance, or is something sinister going on? Just wonderin' Andrew Lankford -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Sam Leffler wrote: Is the ath(4) driver, like the wi(4) driver, incapable of performing bridging? Sorry, answered too quickly. ath and wi have the same restrictions. You can use bridging to hookup a wired and wireless network but not two wireless networks. I can't tell from your posting what you are trying to do. Yes, I was refering to bridging two wireless interfaces. I suppose that if I had a soekris 4521 box I could run a crossover between the ethernet interfaces and bridge wi-eth ... eth-wi... :) Just a tad inefficient, but it might work... -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup sites are all at capacity?
In the last episode (Sep 16), Andrew Lankford said: I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and each site returns this message: Rejected by server: Access limit exceeded; try again later I've gotten that before but never with all of the hosts out there. Is everyone and their brother doing a make world today, are the sites down for maintenance, or is something sinister going on? cvsup4, 5, 9, 10, 11, 12, 13, 14, and 16 all work for me. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup sites are all at capacity?
On Tue, Sep 16, 2003 at 05:11:02PM -0500, Dan Nelson wrote:
In the last episode (Sep 16), Andrew Lankford said:
I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and
each site returns this message:
Rejected by server: Access limit exceeded; try again later
I've gotten that before but never with all of the hosts out there.
Is everyone and their brother doing a make world today, are the sites
down for maintenance, or is something sinister going on?
cvsup4, 5, 9, 10, 11, 12, 13, 14, and 16 all work for me.
There's a port ('fastest_cvsup') that might be useful for folks.
-T
--
The envious man thinks that if his neighbor breaks a leg, he will be able
to walk better himself.
- Helmut Schoeck, _Envy: A Theory Of Social Behavior_
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Yes, I was referring to bridging two wireless interfaces. David Young (of netbsd) has plans for WDS support that should fit into the existing 802.11 layer. With his design you should be able to bridge WDS links using the standard bridge support. No ETA. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng hangs with kernel from september 15
On Tuesday 16 September 2003 23:33, Joachim Strömbergson wrote: Aloha! Arjan van Leeuwen wrote: If I start my kernel from september 15, my computer hangs after this message: atapci0: VIA 82C686B UDMA100 controller port 0xa400-0xa40f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] Did you wait a while? I just completed my system update (getting the OpenSSH patch in at the same time, thanks sec-team!). After reboot my system also stopped at the exact message above. After what felt like about a minute, the system continued to boot and is running normally. Try again and see if it is a real, solid hang, or if it just takes a while. Included is my dmesg. Thanks! I guess I'm too impatient these days... Yes, it works after waiting for about 30 seconds. So a correction, it doesn't hang, it's just slow when detecting :). Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup sites are all at capacity?
On Tue, Sep 16, 2003 at 04:01:39PM -0600, Andrew Lankford wrote: I've tried various cvsup sites (normally cvsup2 or cvsup16 ) and each site returns this message: Rejected by server: Access limit exceeded; try again later I've gotten that before but never with all of the hosts out there. Is everyone and their brother doing a make world today, are the sites down for maintenance, or is something sinister going on? Mine (cvsup12) is still below capacity (28 max clients): http://paloalto.csociety.org/mrtg-sanmateo/ (mrtg) It never got above 10 clients before today. How about a few people switch to my server for regular updates? Thanks. :) Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng hangs with kernel from september 15
Aloha! Arjan van Leeuwen wrote: On Tuesday 16 September 2003 23:33, Joachim Strömbergson wrote: Try again and see if it is a real, solid hang, or if it just takes a while. Thanks! I guess I'm too impatient these days... Yes, it works after waiting for about 30 seconds. So a correction, it doesn't hang, it's just slow when detecting :). So now the tousand dollar question becomes What in the boot contains a timeout around 30 seconds, a timout that lately has been committed/ctivated in the kernel code? -- Med vänlig hälsning, Cheers! Joachim Strömbergson Joachim Strömbergson - ASIC designer, nice to *cute* animals. snail: phone: mail web: Sävenäsgatan 5A+46 31 - 27 98 47 [EMAIL PROTECTED] 416 72 Göteborg+46 733 75 97 02 www.ludd.luth.se/~watchman ___ [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-09-16 21:02:39 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-09-16 21:02:39 - 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-09-16 21:05:41 - 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-09-16 22:08:19 - 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 Tue Sep 16 22:08:19 GMT 2003 Kernel build for GENERIC completed on Tue Sep 16 22:24:05 GMT 2003 TB --- 2003-09-16 22:24:05 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-16 22:24:05 - 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 Tue Sep 16 22:24:05 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:405: error: `LSR_RXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:409: error: `com_data' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:440: error: `com_msr' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:442: error: `LSR_TXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:442: error: `MSR_CTS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:462: error: `com_iir' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_IMASK' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_NOPEND' undeclared (first use in this function) *** 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-09-16 22:31:02 - /usr/bin/make returned exit code 1 TB --- 2003-09-16 22:31:02 - ERROR: failed to build lint kernel TB --- 2003-09-16 22:31:02 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-09-16 22:31:03 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-09-16 22:31:03 - 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-09-16 22:32:56 - 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-09-16 23:26:32 - 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 Tue Sep 16 23:26:32 GMT 2003 Kernel build for GENERIC completed on Tue Sep 16 23:35:34 GMT 2003 TB --- 2003-09-16 23:35:34 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-16 23:35:34 - 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 Tue Sep 16 23:35:34 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:405: error: `LSR_RXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:409: error: `com_data' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:440: error: `com_msr' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:442: error: `LSR_TXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:442: error: `MSR_CTS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:462: error: `com_iir' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_IMASK' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_NOPEND' undeclared (first use in this function) *** 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-09-16 23:40:06 - /usr/bin/make returned exit code 1 TB --- 2003-09-16 23:40:06 - ERROR: failed to build lint kernel TB --- 2003-09-16 23:40:06 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng panic: ATAFD re-using freed memory
On Mon, 8 Sep 2003, Soren Schmidt wrote: It seems Nate Lawson wrote: With a fresh checkout of last night's -current, I cannot boot my laptop. ATAFD panics the box by reusing freed memory. I do not have a floppy drive in the laptop and when I do, it's a legacy floppy, not atapi. Here are the messages: [normal ad0/acd0 probe message] afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready afd0: timeout waiting for ATAPI ready panic: Memory modified after free: 0xc33ed400 (252) Most recently used by AFD driver A working dmesg: http://www.root.org/~nate/acpi/ibm.dmesg From the above I can tell whats going on, please upgrade to the latest -current as I've fixed a couble of things in the probe code there. If it still panic's please include a verbose boot from a atapicam-less kernel... This has been fixed. However, ATAng is still not usable for the reasons in my next email message: Message-ID: [EMAIL PROTECTED] -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and a Toshiba Tecra 8000
Nate Lawson wrote:
On Wed, 17 Sep 2003, Andrew Thompson wrote:
(gdb) l *scsuspend+0x17
0xc03d7b17 is in scsuspend (/usr/src/sys/isa/syscons_isa.c:111).
106 int retry = 10;
107 static int dummy;
108 sc_softc_t *sc;
109
110 sc = main_softc;
111 sc_cur_scr = sc-cur_scp-index;
112
113 if (sc_no_suspend_vtswitch)
114 return (0);
115
For a temporary workaround, try changing line 111 to:
if (sc-cur_scp == NULL)
return (0);
This may not help things though.
It has helped and the laptop is able to suspend with the serial cable
attached (further than before). It now panics on the first resume with
the following (gdb output at bottom).
I think the serial cable is masking the problem as without it I can
suspend/resume once and it only panics on the second resume. I guess I
need the serail working to see that panic anyway.
tdkphy0: detached
miibus0: detached
dc0: detached
sio4: detached
wakeup from sleeping state (slept 00:00:22)
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc03aec5d
stack pointer = 0x10:0xc5e39b0c
frame pointer = 0x10:0xc5e39b18
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 = 7 (acpi_task1)
kernel: type 12 trap, code=0
Stopped at sc_bell+0x2d: movl0x4(%ecx),%eax
db tr
sc_bell(0,320,5,f0,0) at sc_bell+0x2d
sc_switch_scr(c04b8ca0,0,c5e39b74,c02677bd,c1279d80) at sc_switch_scr+0x2c5
scresume(c1279d80,c1212060,c0424e7c,c1273f00,c11d4060) at scresume+0x24
bus_generic_resume(c1273f00,c11d4060,c0424e7c,c11d1d50,4d0) at
bus_generic_resume+0x5d
bus_generic_resume(c1256b00) at bus_generic_resume+0x5d
isab_resume(c1256b00,c11f7060,c0424e7c,c1256b80,c1221060) at
isab_resume+0x6b
bus_generic_resume(c1256b80,c1221060,c0424e7c,c1256280,c1220060) at
bus_generic_resume+0x5d
bus_generic_resume(c1256280,c1257110,0,c1256280,c5e39c1c) at
bus_generic_resume+0x5d
acpi_pcib_resume(c1256280,c1257110,0,c1256280,c5e39c3c) at
acpi_pcib_resume+0x2a
acpi_pcib_acpi_resume(c1256280,c1220060,c0424e7c,c09f2580,c122b060) at
acpi_pcib_acpi_resume+0x2a
bus_generic_resume(c09f2580,c122b060,c0424e7c,c09f1400,c120c060) at
bus_generic_resume+0x5d
bus_generic_resume(c09f1400,c120c060,c0424e7c,0,c1256a00) at
bus_generic_resume+0x5d
bus_generic_resume(c09f1c80,c118e060,c0424e7c,c09f1c80,7a6bb) at
bus_generic_resume+0x5d
acpi_SetSleepState(c1256a00,3,c5e39ce0,c057f399,c1256a00) at
acpi_SetSleepState+0x246
acpi_system_eventhandler_sleep(c1256a00,3,c058af1d,99,c0561d6f) at
acpi_system_eventhandler_sleep+0x1d
acpi_lid_notify_status_changed(c11d1d10,0,c058be85,7b,0) at
acpi_lid_notify_status_changed+0xf9
acpi_task_thread(0,c5e39d48,44890142,858d0824,fb94) at
acpi_task_thread+0x105
fork_exit(c0584b80,0,c5e39d48) at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc5e39d7c, ebp = 0 ---
db
(gdb) l *sc_bell+0x2d
0xc03aec5d is in sc_bell (/usr/src/sys/dev/syscons/syscons.c:3579).
3574sc_bell(scr_stat *scp, int pitch, int duration)
3575{
3576if (cold || shutdown_in_progress || !enable_bell)
3577return;
3578
3579if (scp != scp-sc-cur_scp (scp-sc-flags SC_QUIET_BELL))
3580return;
3581
3582if (scp-sc-flags SC_VISUAL_BELL) {
3583if (scp-sc-blink_in_progress)
(gdb)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup sites are all at capacity?
I spoke too soon. Suddenly it all works. It never got above 10 clients before today. How about a few people switch to my server for regular updates? Thanks. :) Regards, -- wca Oh, alright! Andrew Lankford ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RAM Recommendations for a VIA Mainboard?
Hello all, I've been wrestling with my nice, shiny new PITA system all week long. The consensus seems to be that the RAM is suspect. I'm on my second stick of 512 MB 2700 DDRAM for this thing and this one seems to be worse than the first one I got. The first one was a Samsung and this one is some brand I've never heard of (forgot the name, too lazy to crack the case -again- and look). I have a P-IV 2.40 GHz processor on a VIA P4B 400 Mainboard. I was wondering if anyone had any recommendations on what brand is a good one to go along with VIA Mainboards? My Google searches brought up the possibility that VIA mainboards tend to be rather picky when it comes to RAM. Though I'm not sure if RAM is my problem because I'm not getting Sig 11 errors. I keep getting extremely consistent internal compiler errors pretty much whenever I try to build *anything*. I've tried to buildkernel about 16 times today and each time I get stuck here (or very near here): /usr/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_run_data_fifo': /usr/src/sys/dev/aic7xxx/aic79xx.c:787: error: unrecognizable insn: (insn 1427 1426 1433 48 0x2865be18 (parallel [ (set (reg/v:QI 4 sil [363]) (asm_operands/v:QI (inb %%dx,%0) (=a) 0 [ (reg/v:SI 1 edx [361]) ] [ (asm_input:SI (d)) ] (machine/cpufunc.h) 197)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ]) -1 (insn_list 1422 (nil)) (nil)) /usr/src/sys/dev/aic7xxx/aic79xx.c:787: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8345 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /usr/src/sys/modules/aic7xxx/ahd. *** Error code 1 Stop in /usr/src/sys/modules/aic7xxx. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/BORGES. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Same spot every time. No matter what I do to the configuration (this one was attempting to just build GENERIC with no fancy CPU optimizations and no fancy CFLAGS). It's not just the compiler because I did a fresh install last week of a Sept. 8th Snapshot of current. I'm also *trying* to add options DISABLE_PSE and options DISABLE_PG_G to my kernel, but I can't build a new kernel no matter what I do. I've also fiddled with *all* of the BIOS settings having to do with RAM and none of them made a whit of difference. In case it helps, my dmesg is attached. Any and all suggestions are welcome and encouraged. Thanks in advance, Scott 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-20030908-JPSNAP #0: Fri Sep 12 15:44:32 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BORGES Preloaded elf kernel /boot/kernel/kernel at 0xc0541000. Preloaded elf module /boot/kernel/acpi.ko at 0xc05411f4. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2405.47-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE real memory = 536805376 (511 MB) avail memory = 515637248 (491 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIAP4X AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdea0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_cpu1: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x500-0x50f,0x400-0x47f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 11 INTA is routed to irq 9 pcib0: slot 13 INTA is routed to irq 11 pcib0: slot 14 INTA is routed to irq 5 pcib0: slot 16 INTA is routed to irq 11 pcib0: slot 16 INTB is routed to irq 11 pcib0: slot 16 INTC is routed to irq 5 pcib0: slot 16 INTD is routed to irq 9 pcib0: slot 17 INTC is routed to irq 5 agp0: VIA Generic host to PCI bridge mem 0xd000-0xd7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci1: display, VGA at device 0.0 (no driver attached) rl0: RealTek 8139 10/100BaseTX, rev. B port 0xc000-0xc0ff mem 0xde00-0xdeff irq 9 at device 11.0 on pci0 rl0: Ethernet address: 00:50:fc:09:6b:a1 miibus0: MII bus on rl0
HEADSUP: more network locking commits
I just committed changes to bridge, ipfw, and dummynet. I've been running these for a while but beware. I'm aware of two LOR issues that I want to sort out later, after some more changes have gone in. Regardless, if you encounter problems let me know... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using tip on machine that has COMCONSOLE set to serial
On Tue, 16 Sep 2003, Don Bowman wrote: This may be a dumb question, but I have a situation where machine A and B both have enabled serial console. I'm ssh'ing into A to try and debug a problem on B. I'm trying to use tip, but am getting interference from the fact that A also has a serial console. If i disable the getty, its a bit better. Is there a way to make this work reliably, or am I SOL? Not completely reliably. In -current you can try switching off the serial console, but IIRC the switching code has problems in precisely this area -- it doesn't turn off the lowest levels of consoleness. Turning off getty is a good idea. cua* with getty on ttyd* may work, but it is necessary to turn off CLOCAL on the console snd maybe fiddle with carrider on the line so that getty blocks in open. CLOCAL defaults to on for serial consoles and is locked on. Speeds are also locked for consoles. Turning off anything that writes to the console (e.g., syslogd) is a good idea if you haven't turned off the console. I sometimes turn off low level writes by writing machine code in ddb. On i386's, writing byte 0xc3 at printf turns off all kernel printfs (fortunately nothing checks their return value :-). Overwriting byte 0xe8 with byte 0xb8 in calls to printf turns off individual printfs. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tuesday, September 16, 2003, at 11:54 AM, Dag-Erling Smørgrav wrote: David Rhodus [EMAIL PROTECTED] writes: Right, say if still the OpenSSH did or still comes out to be real. Ops, now thats right, we don't have 3.6.1 in STABLE, why ? It was released on April 1, does that not give one enough time to merge this in ? Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Umm, yeah, so after today are we going to get a new import into RELENG_4 before 4.9 is pushed out the door ? -DR ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAM Recommendations for a VIA Mainboard?
Scott Reese [EMAIL PROTECTED] writes: Though I'm not sure if RAM is my problem because I'm not getting Sig 11 errors. I keep getting extremely consistent internal compiler errors pretty much whenever I try to build *anything*. I've tried to buildkernel about 16 times today and each time I get stuck here (or very near here): /usr/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_run_data_fifo': /usr/src/sys/dev/aic7xxx/aic79xx.c:787: error: unrecognizable insn: [...] /usr/src/sys/dev/aic7xxx/aic79xx.c:787: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8345 An internal compiler error (ICE for short) can also be a compiler bug if it happens in the same place consistently. I recall other ICE Subject lines, but ignored the corresponding posts; the list archives may help you. If you need to be sure what it is, rsync your source code and compiler to a different computer with similar OS and hardware and try there. If it fails in the same place, it's VERY unlikely to be the RAM. If you've been running cvsup -s for a while, trying to run it once without -s might be useful in case some alteration went unnoticed by cvsup (haven't seen that so far, and it's an old recommendation, not sure if it still holds). -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acd0 vs cd0 (ATAPICAM)
Le Mar 16/09/2003 à 09:22, Thomas Quinot a écrit : Le 2003-09-06, Guillaume écrivait : I'm running FreeBSD 5-CURRENT (Aug. 28 2003) on a P3 733MHz, 768MB ram with a LG DVD-RW/DVD-RAM burner. I would like to know why ATAPICAM is so slow with my system. Maybe because ATAPI/CAM does not actually enable DMA. Can you try the following patch? I get an error when compiling kernel with this patch: cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/ata/atapi-cam.c ../../../dev/ata/atapi-cam.c: In function `setup_dev': ../../../dev/ata/atapi-cam.c:232: error: `atadev' undeclared (first use in this function) ../../../dev/ata/atapi-cam.c:232: error: (Each undeclared identifier is reported only once ../../../dev/ata/atapi-cam.c:232: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/i386/compile/GUILLAUME. Thomas. Index: atapi-cam.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cam.c,v retrieving revision 1.22 diff -u -r1.22 atapi-cam.c --- atapi-cam.c 11 Sep 2003 17:34:47 - 1.22 +++ atapi-cam.c 16 Sep 2003 13:20:18 - @@ -227,6 +227,11 @@ 2 * device_get_unit(atp-channel-dev) + (atp-unit == ATA_MASTER) ? 0 : 1); atp-softc = (void *)scp; + if (atapi_dma atp-channel-dma + (atp-param-config ATA_DRQ_MASK) != ATA_DRQ_INTR) + atp-setmode(atadev, ATA_DMA_MAX); + else + atp-setmode(atadev, ATA_PIO_MAX); } } ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Release Engineering Status Report
On Tue, Sep 16, 2003 at 09:47:44PM -0400, David Rhodus wrote: On Tuesday, September 16, 2003, at 11:54 AM, Dag-Erling Smørgrav wrote: Is there a specific problem with OpenSSH 3.5 which requires an update to 3.6.1? Or do you just want me to update it to make the numbers look pretty on your screen? Umm, yeah, so after today are we going to get a new import into RELENG_4 before 4.9 is pushed out the door ? Hell no. :-) Frankly, OpenSSH 3.7.x will require quite a bit of testing and integration before it is even fit for -CURRENT. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng hangs with kernel from september 15
--On Wednesday, September 17, 2003 00:24:06 +0200 Arjan van Leeuwen [EMAIL PROTECTED] wrote: On Tuesday 16 September 2003 23:33, Joachim Strömbergson wrote: Aloha! Arjan van Leeuwen wrote: If I start my kernel from september 15, my computer hangs after this message: atapci0: VIA 82C686B UDMA100 controller port 0xa400-0xa40f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] Did you wait a while? I just completed my system update (getting the OpenSSH patch in at the same time, thanks sec-team!). After reboot my system also stopped at the exact message above. After what felt like about a minute, the system continued to boot and is running normally. Try again and see if it is a real, solid hang, or if it just takes a while. Included is my dmesg. Thanks! I guess I'm too impatient these days... Yes, it works after waiting for about 30 seconds. So a correction, it doesn't hang, it's just slow when detecting :). same here. LER Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: atheros (ath) driver bridging
Sam Leffler wrote: Yes, I was referring to bridging two wireless interfaces. David Young (of netbsd) has plans for WDS support that should fit into the existing 802.11 layer. With his design you should be able to bridge WDS links using the standard bridge support. No ETA. I appologize for my ignorance, but when you say 'WDS', do you mean something having to do with 802.11f? I've been trying to figure out just what WDS is from this thread: http://lists.personaltelco.net/pipermail/general/2002q1/005791.html But so far I'm not getting a clear picture. Jason Luther seems to indicate that WDS is largely proprietary thus far, which makes me wonder how a NetBSD guy could do anything useful with it. I think it may be IEEE standard reading time for me: http://standards.ieee.org/getieee802/802.11.html Thanks. -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ath(4) driver problems with WEP...
I've got a Netgear WAG511 (Atheros 5212-based card) and a Netgear FWAG114 wireless router. I've been trying to get the card and the router talking under FreeBSD. (Both 802.11a and 802.11g work fine under Windows on the same machine.) I'm using -current from September 15th. Anyway, whenever I try to get the card talking to the router, which is running WEP (128 bit keys) on both the a and b/g sides, I get: ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] Here's what the ifconfig looks like: ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether [ card mac address ] media: IEEE 802.11 Wireless Ethernet autoselect mode 11a (OFDM/6Mbps) status: no carrier ssid [my ssid] 1:[my ssid] channel -1 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:128-bit wepkey 2:128-bit wepkey 3:128-bit wepkey 4:128-bit I've verified and re-verified, via cut-and-paste from the router setup screen, that the WEP key is correct. Anyway, I can't get the ath(4) driver to talk to the router when it is running WEP. I have been able to get it to talk 802.11g to the router without WEP enabled, though. I tried setting the authmode to shared via ifconfig, but from looking at ieee80211_ioctl.c: #if 0 case IEEE80211_IOC_AUTHMODE: sc-wi_authmode = ireq-i_val; break; #endif i.e. I get EINVAL back. Is WEP supposed to work in -current? In a separate issue, the ath(4) driver can't see the 802.11a side of the wireless router at all when it is running in 108Mbps turbo mode. If I drop it down to 54Mbps, it sees it. (Works fine in Windows.) Is the ath(4) driver supposed to support the 108Mbps turbo mode? Thanks, Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-09-17 04:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-09-17 04:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-09-17 04:02:11 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-09-17 05:05:12 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Sep 17 05:05:12 GMT 2003 Kernel build for GENERIC completed on Wed Sep 17 05:17:03 GMT 2003 TB --- 2003-09-17 05:17:03 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-17 05:17:03 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Sep 17 05:17:03 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:405: error: `LSR_RXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:409: error: `com_data' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:440: error: `com_msr' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:442: error: `LSR_TXRDY' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:442: error: `MSR_CTS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:462: error: `com_iir' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_IMASK' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/sound/isa/uartsio.c:462: error: `IIR_NOPEND' undeclared (first use in this function) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-09-17 05:22:21 - /usr/bin/make returned exit code 1 TB --- 2003-09-17 05:22:21 - ERROR: failed to build lint kernel TB --- 2003-09-17 05:22:21 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
