Re: Dhclient fix for systems with media settings
Hi, > Is this going to cure the cases where using DHCP results in my network > link going dead about ~30 minutes after getting a lease? At that point > it starts spitting out timeout errors and stuff, and i have to > unplug/replug the card and re-start dhclient to get connectivity again.. Unless the lease time was ~30 minutes and you've changed networks, I doubt it. This sounds like a if_wi driver problem. Warner should be able to tell you more. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Memory modified after free / most recently used by GEOM
While trying to reproduce the "wdrain" problems ru@ reported in the "MSDOSFS
woes" thread, I kept running into this panic. I've also seen a similar one
but didn't keep the vmcore for it where a LOR is detected between Giant and
filedesc, then a page fault occurs. The backtrace for that one shows that the
fault occurred in the file desc code, and traces down to an ioctl() syscall
issued by the shell (ksh).
Kernel is trimmed down -current as of ~13:30 GMT on Aug 5 w/ obsolete drivers
(pcvt, gsc, etc.) deleted, but with no other significant changes.
Memory modified after free 0xc13f7600(252)
panic: Most recently used by GEOM
panic: from debugger
Uptime: 5m33s
Dumping 64 MB
ata0: resetting devices ..
done
16 32 48
---
#0 doadump () at /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:240
#1 0xc01a19ac in boot (howto=260) at
/home/tim/p4/freebsd/sys/kern/kern_shutdown.c:372
#2 0xc01a1d37 in panic () at
/home/tim/p4/freebsd/sys/kern/kern_shutdown.c:550
#3 0xc0127042 in db_panic () at /home/tim/p4/freebsd/sys/ddb/db_command.c:450
#4 0xc0126fa2 in db_command (last_cmdp=0xc031f780, cmd_table=0x0,
aux_cmd_tablep=0xc02fadc0, aux_cmd_tablep_end=0xc02fadc4)
at /home/tim/p4/freebsd/sys/ddb/db_command.c:346
#5 0xc01270e5 in db_command_loop () at
/home/tim/p4/freebsd/sys/ddb/db_command.c:472
#6 0xc012a0e5 in db_trap (type=3, code=0) at
/home/tim/p4/freebsd/sys/ddb/db_trap.c:73
#7 0xc02b23ec in kdb_trap (type=3, code=0, regs=0xc5f69b68) at
/home/tim/p4/freebsd/sys/i386/i386/db_interface.c:172
#8 0xc02c2eda in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1070640529,
tf_ebp = -973694028, tf_isp = -973694060, tf_ebx = 0, tf_edx = 0, tf_ecx = 32,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070913874, tf_cs = 8,
tf_eflags = 646, tf_esp = -1070632808, tf_ss = -1070709550}) at
/home/tim/p4/freebsd/sys/i386/i386/trap.c:580
#9 0xc02b3de8 in calltrap () at {standard input}:102
#10 0xc01a1cc5 in panic (fmt=0xc02f526f "Most recently used by %s\n") at
/home/tim/p4/freebsd/sys/kern/kern_shutdown.c:534
#11 0xc0292c5d in mtrash_ctor (mem=0xc13f7600, size=0, arg=0x0) at
/home/tim/p4/freebsd/sys/vm/uma_dbg.c:137
#12 0xc0291434 in uma_zalloc_arg (zone=0xc083ab60, udata=0x0, flags=2) at
/home/tim/p4/freebsd/sys/vm/uma_core.c:1385
#13 0xc0196463 in malloc (size=3229854560, type=0xc0305560, flags=2) at
/home/tim/p4/freebsd/sys/vm/uma.h:229
#14 0xc0184cea in fdcopy (fdp=0xc1218200) at
/home/tim/p4/freebsd/sys/kern/kern_descrip.c:1309
#15 0xc018de0e in fork1 (td=0xc0a0d390, flags=20, pages=0, procp=0xc5f69cd8)
at /home/tim/p4/freebsd/sys/kern/kern_fork.c:424
#16 0xc018d61b in fork (td=0xc0a0d390, uap=0xc5f69d10) at
/home/tim/p4/freebsd/sys/kern/kern_fork.c:102
#17 0xc02c37c3 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 135299072,
tf_ebp = -1077937224, tf_isp = -973693580, tf_ebx = 0, tf_edx = 135295016,
tf_ecx = -1, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134725423, tf_cs
= 31, tf_eflags = 582, tf_esp = -1077937268, tf_ss = 47}) at
/home/tim/p4/freebsd/sys/i386/i386/trap.c:1008
#18 0xc02b3e3d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: warnpassword and warnexpire in 5.1 login.conf
Sure, run cap_mkdb on every edit on login.conf The values im trying to use there are the following: :warnexpire=28d:\ :warnpassword=14d:\ And with pw i use the following to test with: (also with -e option) pw usermod user -p +10d The only thing im getting now is i warning in messages when i try to login into a locked account. Aug 5 12:14:39 marvin sshd[55256]: error: PAM: user accound has expired And the following varning when password is old: Aug 5 12:27:38 marvin sshd[55386]: error: PAM: OK Aug 5 12:27:40 marvin sshd[55390]: fatal: PAM: chauthtok not supprted with privsep Is there perhaps a better PAM way of doing this things now?? // Mats On Sun, 3 Aug 2003, David Schultz wrote: > On Sat, Aug 02, 2003, Mats Larsson wrote: > > > > Hello! > > > > Tried this question to the questions list with no response, perhaps > > current is the correct list for questions related to 5.1-RELEASE?? > > > > I am trying to use warnexpire and warnpassword in login.conf but with no > > result, are the warnexpire and warnpassword still used in 5.1 or have they > > been superseded with a PAM module in the same way as minpasswordlen and > > minpasswordcase?? > > They're part of the pam_unix PAM module now, but they should still > work. I tried them a few months ago, and I don't remember any > special steps being necessary. You ran cap_mkdb(1), right? > ___ > [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: port 0xd800-0xd80f at device7.1on pci0
It seems Doug White wrote: > On Sun, 3 Aug 2003, ryan chris wrote: > > > > > with dma enabled, a sysinstall will only work under the minimal install, > > and after a certain point, apparently using too much hard drive space > > (showed up with a tar > > -xvf ports.tar) causes a panic with anic errors > > Have you tried replacing the IDE cable(s)? I've seen panics and other > erratic behavior due to bad cables, or a defective 60 pin cable, or even a > 30 pin cable that somehow got detected as a 60 pin. Uhm, the cables are 40 vs 80 conductors :) Anyhow I'm pretty sure this problem is because of the buggy VIA 82C686B southbridge and a matching BIOS that doesn't setup the right workarounds for it to function like intended. Clearly the tweaks we install are not enough on this baby. Recommended action is to update (well sometimes downgrade) the BIOS to a version that makes things work... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: INET6 in world
At 9:37 AM -0700 2003/08/05, David O'Brien wrote: Machanism, not policy. I would also like to run with NO_INET6. IPv6 support has done nothing for me other than cause me problems. I still strongly disagree with our ordering of localhost in /etc/hosts. My system worked worlds better when I put the IPv4 localhost first. There is no IPv6 in this house, nor is there likely to be any time soon. If I can't kill IPv6 from a configuration standpoint, I'll go ripping out the freakin' code, or I'll use an OS that gives me the option. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: INET6 in world
> Date: Tue, 5 Aug 2003 20:52:50 +0200 > From: Brad Knowles <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > At 9:37 AM -0700 2003/08/05, David O'Brien wrote: > > > Machanism, not policy. I would also like to run with NO_INET6. IPv6 > > support has done nothing for me other than cause me problems. I still > > strongly disagree with our ordering of localhost in /etc/hosts. My > > system worked worlds better when I put the IPv4 localhost first. > > There is no IPv6 in this house, nor is there likely to be any > time soon. If I can't kill IPv6 from a configuration standpoint, > I'll go ripping out the freakin' code, or I'll use an OS that gives > me the option. I may have missed part of this tread as I am on travel. Why is simply not enabling ipv6 adequate? Note: I DO run IPv6 routinely when at work, so I normally do have it enabled. I'd like to get an understanding of what the issue might be. The point is clearly strongly heald be some reasonably knowledgeable people. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic every few hours, pmap related?
On Tue, 5 Aug 2003, Poul-Henning Kamp wrote: > > If you are running with version 1.64 or later of sys/geom/geom_dev.c, > try updating to you get my patches from this morning. > > If that doesn't help, try commenting out the Giant drop/pickup > around the call to strategy in fs/specfs/specfs_vnops.c I tried that, but unfortunately the problem still exists :-/ regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Specifying default alternate sound device?
On Tue, 2003-08-05 at 13:17, Mathew Kanner wrote: > With devfs, the default sound unit is tunable by a sysctl. > > tube# sysctl hw.snd.unit=0 ; ls -l dsp dsp0.0 dsp1.0 ; sysctl hw.snd.unit=1 ; ls -l > dsp dsp0.0 dsp1.0 > hw.snd.unit: 1 -> 0 > crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp > crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp0.0 > crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp1.0 > hw.snd.unit: 0 -> 1 > crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp > crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp0.0 > crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp1.0 Thanks! Is there a similar trick for specifying mixer1 instead of the default mixer? -Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic every few hours, pmap related?
If you are running with version 1.64 or later of sys/geom/geom_dev.c, try updating to you get my patches from this morning. If that doesn't help, try commenting out the Giant drop/pickup around the call to strategy in fs/specfs/specfs_vnops.c Poul-Henning In message <[EMAIL PROTECTED]>, Lukas Ertl writes: >Hi, > >since this weekend my highly loaded newsserver panics every few hours with >the following traceback. Any ideas? > >5.1-CURRENT FreeBSD 5.1-CURRENT #6: Mon Aug 4 21:54:06 CEST 2003 > > >Stopped at pmap_remove_all+0x38: xchgl %edx,0(%eax) >db> where >pmap_remove_all(c0f73de0,40,0,f,c0d5e998) at pmap_remove_all+0x38 >vfs_busy_pages(d28d1d48,1,db8a2000,e0ba7b18,c03599d9) at vfs_busy_pages+0x178 >bwrite(d28d1d48,e0ba7bc8,c0257f2e,d28d1d48,d28d1e78) at bwrite+0x380 >bawrite(d28d1d48,d28d1e78,18,c613a390,c6437b68) at bawrite+0x1c >cluster_wbuild(c6437b68,4000,1c2,0,6) at cluster_wbuild+0x90e >vfs_bio_awrite(d29fdc08,0,0,c613a390,e0ba7c78) at vfs_bio_awrite+0x25d >ffs_fsync(e0ba7cc4,20002,c613a390,c03a38c0,0) at ffs_fsync+0x382 >sched_sync(0,e0ba7d48,0,0,0) at sched_sync+0x204 >fork_exit(c02620b0,0,e0ba7d48) at fork_exit+0xb1 >fork_trampoline() at fork_trampoline+0x1a --- >trap 0x1, eip = 0, esp = 0xe0ba7d7c, ebp = 0 --- > > > >Script started on Mon Aug 4 23:57:55 2003 >[EMAIL PROTECTED] crash]# gdb -k kernel.debug vmcore.0 >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: from debugger >panic messages: >--- >Fatal trap 12: page fault while in kernel mode >cpuid = 2; lapic.id = 0600 >fault virtual address = 0xbfceea70 >fault code = supervisor write, page not present >instruction pointer= 0x8:0xc035d588 >stack pointer = 0x10:0xe0ba7a98 >frame pointer = 0x10:0xe0ba7ab0 >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= 41 (syncer) >panic: from debugger >cpuid = 2; lapic.id = 0600 > > >Fatal trap 3: breakpoint instruction fault while in kernel mode >cpuid = 2; lapic.id = 0600 >instruction pointer= 0x8:0xc0347b65 >stack pointer = 0x10:0xe0ba7800 >frame pointer = 0x10:0xe0ba780c >code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = IOPL = 0 >current process= 41 (syncer) >panic: from debugger >cpuid = 2; lapic.id = 0600 >boot() called on cpu#2 >Uptime: 1h36m33s >Dumping 1023 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 > 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 > 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 >--- >Reading symbols from >/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. >Loaded symbols for >/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug >#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 >240dumping++; >(kgdb) wher bt full >#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 >No locals. >#1 0xc0203c61 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 >No locals. >#2 0xc02040b8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 > td = (struct thread *) 0xc613a390 > bootopt = 260 > newpanic = 0 > ap = 0xe0ba7850 "\byºà\222\222\024À\210Õ5À" > buf = "from debugger", '\0' >#3 0xc0149332 in db_panic () at /usr/src/sys/ddb/db_command.c:450 >No locals. >#4 0xc0149292 in db_command (last_cmdp=0xc03e4a60, cmd_table=0xc03bb900, >aux_cmd_tablep=0xc03b5fb8, aux_cmd_tablep_end=0xc03b5fbc) >at /usr/src/sys/ddb/db_command.c:346 > cmd = (struct command *) 0xc03799dc > t = 0 > modif = "\0S>À¨\204BÀ\230xºà\r\0\0\0 pAÀ\r\0\0\0\001\0\0\0¸xºà\226Ö3À [EMAIL > PROTECTED] [EMAIL > PROTECTED]>Àx\0\0\0ÀS>À¨\204BÀÜxºàѱ\024À\f³8À\200¯\024À\0\0\0\0\020\0\0\0èxºàøxºà]¨\024À\f³8À¨\204BÀ\byºà\020\0\0" > addr = -1070213752 > count = 1 > have_addr = 0 > result = 0 >#5 0xc01493d5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472 >No locals. >#6 0xc014c3f5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73 > bkpt = 0 >#7 0xc034785c in kdb_trap (type=12, code=0, regs=0xe0ba7a58) >at /usr/src/sys/i386/i386/db_interface.c:172 > ef = 582 > ddb_mode = 1 >#8 0xc0361c16 in trap_fatal (frame=0xe0ba7a58, eva=0) >at /usr/src/sys/
Re: Specifying default alternate sound device?
On Aug 05, Adam wrote: > Is there any easy way to specify a default alternate sound device (eg, > /dev/dsp1). I have both onboard sound (/dev/dsp) and a SB Live card > (/dev/dsp1), but I don't use the onboard sound. It's really frustrating > to try to configure every single application (that uses sound) to use > /dev/dsp1 instead. > > Is there some safe/easy trick to set a general rule that all/most apps > will follow, so that they use /dev/dsp1 instead? With devfs, the default sound unit is tunable by a sysctl. tube# sysctl hw.snd.unit=0 ; ls -l dsp dsp0.0 dsp1.0 ; sysctl hw.snd.unit=1 ; ls -l dsp dsp0.0 dsp1.0 hw.snd.unit: 1 -> 0 crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp0.0 crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp1.0 hw.snd.unit: 0 -> 1 crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp crw-rw-rw- 1 root wheel 30, 3 Aug 5 11:24 dsp0.0 crw-rw-rw- 1 root wheel 30, 19 Aug 5 11:24 dsp1.0 --Mat -- sig machine broken. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
D-Link DGE-500T support
I attempted to use a D-Link DGE-500T card this weekend on 5.1-RELEASE (and -CURRENT) with no success. It is unable to probe the device and find a proper driver for it. My question is: are there any plans currently to provide support for this card? If there is already support for it (which may be the case) then which driver is it using? I tried a GENERIC kernel with all the default drivers, but it diddnt work with them. I can eventually get dmesg output again, but I'd need to bring the server down to put the card back in. Any help is more than welcome. Thank you! Regards, Nick H. [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACLS on UFS2 from FreeBSD 5.1-RELEASE install.
On 2 Aug 2003, Scott M. Likens wrote: > Has anyone noticed the ACLS being disabled? > > tunefs -p /dev/da1s1c shows that ACLS are disabled on every partition I > have, i've gone through them all. > > any reason why? Yes -- they are disabled by default because they're not required by most users, and as a new (and slightly experimental) feature, involve a slightly greater risk of problems. I believe I added support to sysinstall to enable ACLs during the partition process; if not, you can enable them later using tunefs. One of the difficulties associated with ACLs is that not all applications understand them -- while the failure mode is predictable and relatively clean, it means that you may sometimes lose ACLs on objects when they are replaced by an application without ACL support. For example, some applications will move a file out of the way and create a new copy when updating a file -- if they don't understand ACLs, they can't propagate the ACL from the old object to the new object. Also, several of the base system utilities (such as mv) don't currently propagate ACLs. I hope to fix up a number of them for 5.3, but I suspect we'll bump into such programs once in a while as we move forwards. Most of the performance loss associated with ACLs on UFS1 have been eliminated through UFS2, which is a point in favor of enabling ACLs by default. Once they've settled for some time and the feedback is all looking good, we might choose to enable them by default. Disabling by default is consistent with several other systems also supporting ACLs. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic every few hours, pmap related?
Hi,
since this weekend my highly loaded newsserver panics every few hours with
the following traceback. Any ideas?
5.1-CURRENT FreeBSD 5.1-CURRENT #6: Mon Aug 4 21:54:06 CEST 2003
Stopped at pmap_remove_all+0x38: xchgl %edx,0(%eax)
db> where
pmap_remove_all(c0f73de0,40,0,f,c0d5e998) at pmap_remove_all+0x38
vfs_busy_pages(d28d1d48,1,db8a2000,e0ba7b18,c03599d9) at vfs_busy_pages+0x178
bwrite(d28d1d48,e0ba7bc8,c0257f2e,d28d1d48,d28d1e78) at bwrite+0x380
bawrite(d28d1d48,d28d1e78,18,c613a390,c6437b68) at bawrite+0x1c
cluster_wbuild(c6437b68,4000,1c2,0,6) at cluster_wbuild+0x90e
vfs_bio_awrite(d29fdc08,0,0,c613a390,e0ba7c78) at vfs_bio_awrite+0x25d
ffs_fsync(e0ba7cc4,20002,c613a390,c03a38c0,0) at ffs_fsync+0x382
sched_sync(0,e0ba7d48,0,0,0) at sched_sync+0x204
fork_exit(c02620b0,0,e0ba7d48) at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x1a ---
trap 0x1, eip = 0, esp = 0xe0ba7d7c, ebp = 0 ---
Script started on Mon Aug 4 23:57:55 2003
[EMAIL PROTECTED] crash]# gdb -k kernel.debug vmcore.0
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: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 2; lapic.id = 0600
fault virtual address = 0xbfceea70
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc035d588
stack pointer = 0x10:0xe0ba7a98
frame pointer = 0x10:0xe0ba7ab0
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 = 41 (syncer)
panic: from debugger
cpuid = 2; lapic.id = 0600
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 2; lapic.id = 0600
instruction pointer = 0x8:0xc0347b65
stack pointer = 0x10:0xe0ba7800
frame pointer = 0x10:0xe0ba780c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 41 (syncer)
panic: from debugger
cpuid = 2; lapic.id = 0600
boot() called on cpu#2
Uptime: 1h36m33s
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
Reading symbols from
/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/NEWSCORE/modules/usr/src/sys/modules/acpi/acpi.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) wher bt full
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1 0xc0203c61 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2 0xc02040b8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc613a390
bootopt = 260
newpanic = 0
ap = 0xe0ba7850 "\byºà\222\222\024À\210Õ5À"
buf = "from debugger", '\0'
#3 0xc0149332 in db_panic () at /usr/src/sys/ddb/db_command.c:450
No locals.
#4 0xc0149292 in db_command (last_cmdp=0xc03e4a60, cmd_table=0xc03bb900,
aux_cmd_tablep=0xc03b5fb8, aux_cmd_tablep_end=0xc03b5fbc)
at /usr/src/sys/ddb/db_command.c:346
cmd = (struct command *) 0xc03799dc
t = 0
modif = "\0S>À¨\204BÀ\230xºà\r\0\0\0 pAÀ\r\0\0\0\001\0\0\0¸xºà\226Ö3À [EMAIL
PROTECTED] [EMAIL
PROTECTED]>Àx\0\0\0ÀS>À¨\204BÀÜxºàѱ\024À\f³8À\200¯\024À\0\0\0\0\020\0\0\0èxºàøxºà]¨\024À\f³8À¨\204BÀ\byºà\020\0\0"
addr = -1070213752
count = 1
have_addr = 0
result = 0
#5 0xc01493d5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
No locals.
#6 0xc014c3f5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
bkpt = 0
#7 0xc034785c in kdb_trap (type=12, code=0, regs=0xe0ba7a58)
at /usr/src/sys/i386/i386/db_interface.c:172
ef = 582
ddb_mode = 1
#8 0xc0361c16 in trap_fatal (frame=0xe0ba7a58, eva=0)
at /usr/src/sys/i386/i386/trap.c:816
code = 16
---Type to continue, or q to quit---
type = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27,
ssd_dpl = 0, ssd_p = 1, ssd_xx = 0, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1}
#9 0xc03618c2 in trap_pfault (frame=0xe0ba7a58, usermode=0, eva=3218008688)
at /usr/src/sys/i386/i386/trap.c:735
va = 32
Re: problem with nvidia graphics card and -current
On Tuesday, 05 August 2003 13:07, Glenn Johnson wrote: > On Sun, Aug 03, 2003 at 11:48:56PM -0500, wrote: > > I was setting up a system today with an nvidia Geforce4-MX 440 > > graphics card. I am not at the system at the moment but the -current > > sources were from about 2:00 PM CDT. I installed the nvidia-driver > > port (1.0.4365) trying various combinations of WITH_FREEBSD_AGP, > > FORCE_AGP_RATE, and WITH_NVIDIA_HACKS. I get the same result. The > > first time an X server is started, everything works fine, including > > glx loading. After exiting the X session and shutting down the > > server and then at some point later starting the X server again, the > > system will freeze. No messages, no panic, nothing. The only thing > > to do is hit the reset button. > > I played with this a bit more tonight. I rebuilt the kernel (fresh > cvsup) and the nvidia-driver bits. I even tried loading without glx. > I still have the same problem. At this point I do not know if this is > a problem with the nvidia-driver port, a problem with -current, or > something I am doing wrong. Does anybody have a functioning nvidia card > with FreeBSD -current at this time? Yes I do. I posted to the list a few days with a glx problem. However the problem was solved when I did an update one day ago. I didn't have to changed anything either. I didn't know what was wrong for some reason X would about with sig 10 or 11 when the glx module was loaded. have you checked out: http://www.soulwax.net/nvidia/faq.shtml They list a whole bunch of things to try. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any patch for ICMP in a jail?
On Tue, Aug 05, 2003 at 03:55:55AM -0700, Terry Lambert wrote: > Through the credential passing? I thought that wasn't reliable > for this type of thing. Specifically, the jail would be in an > untrusted protection domain; if you just accepted the credential > blindly, then anyone could be root in the jail, and you could not > trust it. > > If you didn't accept it blindly, then regular root loses existing > functionality. > > I'm pretty sure that, at least the last time I looke at it, the > credential passing code didn't pass information about jail status. [deletia] Sorry, you are right. Despite the subject line, I wasn't thinking of jails at this point, but just of removing the setuid bit from ping. 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]"
Dhclient fix for systems with media settings
Hi all,
If you used wi(4) or en(4) wavelan cards and you had problems with dhclient,
you should try this patch, which treats interfaces with media settings
differently.
http://people.freebsd.org/~mbr/patches/dhclient-interfacepolling-fixup.diff
I'll produce a more clean patch this evening, and also adapt the patch to
the ISC style, so it can be submitted again.
--- src/contrib/isc-dhcp/includes/dhcpd.h.orig Mon Aug 4 23:57:06 2003
+++ src/contrib/isc-dhcp/includes/dhcpd.h Mon Aug 4 23:57:37 2003
@@ -782,6 +782,7 @@
char name [IFNAMSIZ]; /* Its name... */
int linkstatus; /* Link status */
int ieee802;/* True if media is ieee802 */
+ int mediaflag; /* True if dhclient.conf has media settings */
int index; /* Its index. */
int rfdesc; /* Its read file descriptor. */
int wfdesc; /* Its write file descriptor, if
--- src/contrib/isc-dhcp/client/dhclient.c.orig Tue Aug 5 00:42:37 2003
+++ src/contrib/isc-dhcp/client/dhclient.c Tue Aug 5 10:01:17 2003
@@ -257,7 +257,9 @@
log_fatal ("%s: interface name too long (max %ld)",
argv [i], (long)strlen (argv [i]));
strlcpy (tmp -> name, argv [i], IFNAMSIZ);
- set_ieee802(tmp);
+#ifdef __FreeBSD__
+ set_ieee80211(tmp);
+#endif
tmp->linkstatus = interface_active(tmp);
if (interfaces) {
interface_reference (&tmp -> next,
@@ -412,7 +414,16 @@
INTERFACE_AUTOMATIC)) !=
INTERFACE_REQUESTED))
continue;
- set_ieee802(ip);
+#ifdef __FreeBSD__
+ set_ieee80211(ip);
+#endif
+#ifdef ENABLE_POLLING_MODE
+ if (ip -> client -> config -> media != NULL)
+ ip->mediaflag = 1;
+ else
+ ip->mediaflag = 0;
+#endif /* ifdef ENABLE_POLLING_MODE */
+
script_init (ip -> client,
"PREINIT", (struct string_list *)0);
if (ip -> client -> alias)
@@ -1385,9 +1396,6 @@
int interval;
int increase = 1;
- if (interface_active(client -> interface) == 0)
- return;
-
/* Figure out how long it's been since we started transmitting. */
interval = cur_time - client -> first_sending;
@@ -1427,6 +1435,9 @@
}
}
+ if (interface_active(client -> interface) == 0)
+ return;
+
/* If we're supposed to increase the interval, do so. If it's
currently zero (i.e., we haven't sent any packets yet), set
it to one; otherwise, add to it a random number between
@@ -3215,14 +3226,29 @@
if (ifmr.ifm_status & IFM_AVALID) {
if (ip->ieee802) {
if ((IFM_TYPE(ifmr.ifm_active) == IFM_IEEE80211) &&
-(ifmr.ifm_status & IFM_ACTIVE))
+(ifmr.ifm_status & IFM_ACTIVE)) {
+ if (ip->mediaflag &&
+ ip -> client -> state != S_BOUND)
+ return (2);
return (1);
+ }
} else {
- if (ifmr.ifm_status & IFM_ACTIVE)
+ if (ifmr.ifm_status & IFM_ACTIVE) {
+ if (ip->mediaflag &&
+ ip -> client -> state != S_BOUND)
+ return (2);
return (1);
+ }
}
}
+ /*
+* If dhclient.conf contains media settings, we cannot
+* abort if the interface is not set to active mode.
+*/
+ if (ip->mediaflag && ip -> client -> state != S_BOUND)
+ return (1);
+
return (0);
#else /* ifdef __FreeBSD__ */
@@ -3231,7 +3257,7 @@
}
#ifdef __FreeBSD__
-set_ieee802 (struct interface_info *ip) {
+set_ieee80211 (struct interface_info *ip) {
struct ieee80211req ireq;
u_int8_tdata[32];
@@ -3267,12 +3293,20 @@
#endif /* __FreeBSD__ */
#ifdef ENABLE_POLLING_MODE
+/* Go to background after some time */
+void state_background (cpp)
+ void *cpp;
+{
+ go_daemon ();
+}
+
/* Check the state of the NICs if we have link */
void state_link (cpp)
void *cpp;
{
struct interface_info *ip;
struct client_state *client;
+ int result;
#ifdef DEBUG
printf("Polling interface status\n");
@@ -3281,7 +3315,11 @@
if (ip->li
