Re: [PATCH] fixes of tcp_hostcache.c
On Tue, Dec 02, 2003 at 11:56:30AM +0900, Taku YAMAMOTO wrote: The fix is attached as a patch against tcp_hostcache.c as of revision 1.2. Looks good to me. I haven't been able to test this thoroughly, netperf/netserver don't seem to want to listen on a TCP6 port for the TCPIPV6_STREAM test. Our port appears to incorporate the necessary patches. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc scripts run double on boot?
On Tue, Nov 25, 2003 at 09:35:29AM -0800, Nate Lawson wrote: With a recent -current, I've noticed double prints for the last few rc scripts, like this: Starting cron. Local package initialization:. Local package initialization:. Additional TCP options:. Additional TCP options:. Anyone else seeing this? Looks like a couple of RC scripts were renamed/moved in more recent -CURRENT than 5.1-RELEASE. this bit me recently. The offending scripts were along the lines of /etc/rc.d/network3 if I recall. There were two. I rm'd the offending ones without thinking the other day after a grep -Hr of rc.d :-) Sorry I can't be of more help :-) BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: localhost adress
On Sun, Nov 23, 2003 at 01:33:33PM +0200, Adrian Penisoara wrote: Maybe the latest commit by 'tmm' fixes it: This appears to fix the reported issue. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote: At 5:22 PM -0800 2003/11/22, David O'Brien wrote: Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. Why? Why cut your nose off to spite your face? Even though this capability may not have existed before, why shouldn't we have it now? I think David has valid concerns here about feeping creaturism. fetch has a whole load of library dependencies which go with it, making it unsuitable for inclusion in /rescue in the base system. If you want access to fetch early on in this way, you could make a local branch and maintain the change for your own site, or you could boot from a FreeBSD live CD, or use sysinstall from the installation CD to install a package. I don't see fetch as a requirement for diskless clients. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atacontrol(8) not yielding any output
Hi all, kimchi# uname -a FreeBSD kimchi.dek.spc.org 5.2-BETA FreeBSD 5.2-BETA #4: Sun Nov 23 01:52:10 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KIMCHI i386 atacontrol doesn't report any devices. Using commands such as cap/info/list don't yield anything at all. Perhaps more worrying:- kimchi# atacontrol mode 0 atacontrol: ioctl(ATAGMODE): Device not configured The disk and cd themselves are present in dmesg during boot. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DStumbler / BSD-AirTools Error with new Wi code?
On Wed, Nov 19, 2003 at 05:32:37PM -0800, Sean Chittenden wrote: I don't know if Lucent cards are supported or not. How old is your kernel, btw? You should update to -CURRENT as there have been many wlan fixes since 5.1-RELEASE. -sc To the best of my knowledge, only PRISM2 has ever been supported by the dstumbler port we have. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote: * /rescue/vi is currently unusable if /usr is missing because the termcap database is in /usr. One possibility would be to build a couple of default termcap entries into ncurses or into vi. My suggested candidates are vt100 and cons25. The comconsole port installs an /etc/ttys entry using vt100. This is also the default terminal type for most dialup entries. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Whoops. http://damien.bergamini.free.fr/ueagle/download.html. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Fri, Nov 21, 2003 at 09:11:33AM -0800, Doug White wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. There are a number of OHCI patches at:- http://damien.bergamini.free.fr/ueagle/ BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Thu, Nov 20, 2003 at 09:29:30PM -0500, Richard Coleman wrote: But I've often wondered how frequently a production system has such problems. I've been a sysadmin for many years and can't remember this ever happening. It's much more common to blow a hard drive, or have flaky memory, etc. During my time in an investment bank, installations were usually hosed in this way by human error (systems administrators removing a file by accident, etc) or by third party package installation. The OS in question was Solaris. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
VFS deadlock suspected in -CURRENT
Hi all, Last night's -CURRENT appears to have demonstrated deadlock. My experience in this area is extremely limited so I have been trying to track down the problem with kan's help. It manifested itself as being unable to log into the machine directly (via serial console, *or* sshd) due to processes hanging in the VFS locking code, specifically vfs_lookup.c. I will let you know more when I have more hard data. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in cache_lookup()
Bleeding edge current updated around 15:00 GMT today. This was triggered whilst building GENERIC to test someone's patches... db trace cache_lookup(c2c50514,d65d9c28,d65d9c3c,c2c50514,c29fd280) at cache_lookup+0x166 vfs_cache_lookup(d65d9b70,d65d9b8c,c051ab52,d65d9b70,20002) at vfs_cache_lookup+0xc9 ufs_vnoperate(d65d9b70,20002,c29fd280,c303430c,c29fd280) at ufs_vnoperate+0x18 lookup(d65d9c14,c2a18800,400,d65d9c30,c29fd280) at lookup+0x302 namei(d65d9c14,1,c29fd280,d65d9c18,0) at namei+0x20b lstat(c29fdtat+0x52 syscall(2f,2f,2f,bfbfbc78,0) at syscall+0x309 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (190, FreeBSD ELF32, lstat), eip = 0x280be3cf, esp = 0xbfbfb26c, ebp = 0xbfbfb2f8 --- If you need any more information, contact me via email or on irc in 'all the usual places'. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in random_harvest()
I think a fix was already committed for this, but it's biting me hard
right now.
Script started on Wed Nov 19 00:09:06 2003
kimchi# gdb -k /home/bms/cvs/src/sys/i386/compile/KIMCHI vm[K[K/kernel.debig
[K[Kug vmcore.7
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: kmem_malloc: entry not found or misaligned
panic messages:
---
panic: kmem_malloc: entry not found or misaligned
Stack backtrace:
panic: from debugger
Uptime: 4m28s
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/vesa/vesa.ko.debug...done.
Loaded symbols for
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/vesa/vesa.ko.debug
Reading symbols from /boot/kernel/if_vr.ko...done.
Loaded symbols for /boot/kernel/if_vr.ko
Reading symbols from
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/usb/usb.ko.debug...done.
Loaded symbols for
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/usb/usb.ko.debug
Reading symbols from /boot/kernel/netgraph.ko...done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
#0 doadump () at ../../../kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc04c3edd in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc04c4299 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc0431bf2 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc0431b52 in db_command (last_cmdp=0xc0689af0, cmd_table=0x0,
aux_cmd_tablep=0xc0684a5c, aux_cmd_tablep_end=0xc0684a60)
at ../../../ddb/db_command.c:346
#5 0xc0431c86 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc0434b4a in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#7 0xc0620a65 in kdb_trap (type=3, code=0, regs=0xd65f1498)
at ../../../i386/i386/db_interface.c:171
#8 0xc063159c in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1066937799, tf_ebp =
-698411804, tf_isp = -698411836, tf_ebx = 0, tf_edx = 0, tf_ecx = 1021, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1067315964, tf_cs = 8, tf_eflags = 130, tf_esp =
-1066925180, tf_ss = -1067016530})
at ../../../i386/i386/trap.c:580
#9 0xc06223c8 in calltrap () at {standard input}:88
#10 0xc04c41ec in panic (
fmt=0xc067d239 kmem_malloc: entry not found or misaligned)
at ../../../kern/kern_shutdown.c:534
#11 0xc05e60bd in kmem_malloc (map=0xc0c310a0, size=4096, flags=1)
at ../../../vm/vm_kern.c:426
---Type return to continue, or q return to quit---
#12 0xc05f7e87 in page_alloc (zone=0xc0c3ba80, bytes=0, pflag=0x0, wait=0)
at ../../../vm/uma_core.c:845
#13 0xc05f7af9 in slab_zalloc (zone=0xc0c3ba80, wait=1)
at ../../../vm/uma_core.c:753
#14 0xc05f8e36 in uma_zone_slab (zone=0xc0c3ba80, flags=1)
at ../../../vm/uma_core.c:1539
#15 0xc05f908f in uma_zalloc_bucket (zone=0xc0c3ba80, flags=1)
at ../../../vm/uma_core.c:1635
#16 0xc05f8ca5 in uma_zalloc_arg (zone=0xc0c3ba80, udata=0x0, flags=1)
at ../../../vm/uma_core.c:1469
#17 0xc04b803c in malloc (size=2, type=0xc068e160, flags=1) at uma.h:234
#18 0xc046f598 in random_harvest_internal (somecounter=442778455129,
entropy=0x0, count=8, bits=0, frac=0, origin=RANDOM_INTERRUPT)
at ../../../dev/random/randomdev.c:370
#19 0xc046ed69 in random_harvest (entropy=0x0, count=0, bits=0, frac=0,
origin=RANDOM_START) at cpu.h:104
#20 0xc04ae642 in ithread_schedule (ithread=0x17a70c59, do_switch=1)
at ../../../kern/kern_intr.c:378
#21 0xc06264f9 in intr_execute_handlers (isrc=0xc06aec28, iframe=0x16)
at ../../../i386/i386/intr_machdep.c:206
#22 0xc06342d8 in atpic_handle_intr (iframe=
{if_vec = 14, if_fs = 24, if_es = 16, if_ds = 16, if_edi = -1060958048, if_esi =
-1060961344, if_ebp = -698411084, if_ebx = -1060960204, if_edx = 7, if_ec---Type
return to continue, or q return to quit---
x = 7, if_eax = -1060958048, if_eip = -1067552603, if_cs = 8, if_eflags = 582, if_esp
= -698411084, if_ss = -1067552851}) at ../../../i386/isa/atpic.c:335
#23 0xc06346ce in Xatpic_intr14 () at {standard input}:40
#24 0xc05e7499 in vm_map_insert (map=0xc0c303c0, object=0xc0c310a0,
offset=47181824, start=3267354624, end=3267358720, prot=7 '\a',
max=7 '\a', cow=0) at ../../../vm/vm_map.c:860
#25 0xc05e5c96 in kmem_malloc (map=0xc0c310a0, size=3234009248, flags=1027)
at ../../../vm/vm_kern.c:348
#26
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 16, 2003 at 11:37:47PM -0500, Bill Vermillion wrote: For those who don't build the OS but install from binaries, this makes the system potentially less rugged. One of the things I disliked about the Linux systems I've been on is libraries that change and break things - for things which I felt should have been static in the first place We've always been more frugal with library bumps and ABI changes than the other projects so I don't see any immediate danger of that happening. I certainly shared your concerns until I learned about /rescue; speaking as a long time abuser of Solaris and Linux who has experienced the problems you mention. But I don't feel the same possibility exists for catastrophic failure without recovery here. For just about everything, dynamic linking is a win. There are some scenarios where it isn't. I for one understand your concerns; if static linking is appropriate for your environment, then by all means, rebuild the components you need with static linking. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig bug
On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote: shouldn't this work? # ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \ ether 00:07:e9:0a:26:52 ifconfig: ether: bad value This is with today's -current, but this may have been around longer - I hadn't tried it before today. Using two commands to set MAC and IP addresses works fine, but it needs to be one command for rc.conf. This issue is already known about and the behaviour you are seeing is in accordance with how ifconfig should currently behave. I suggest patching rc scripts until it can be solved the right way round. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no partition entries for /dev/ad3
On Wed, Oct 08, 2003 at 11:20:16AM -0700, Andrew P. Lentvorski, Jr. wrote: I can only fix one of those things. ;) To whomever wrote the Fdisk and Label editor in sysinstall: Thanks. You did a good job, and I thank you for it. Hrm, perhaps we should rip it out and maintain it as a separate tool if libh kicks off. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel maybe borked...
On Sat, Oct 18, 2003 at 09:50:58PM +0200, Gabriel Ambuehl wrote: [snip] /usr/src/sys/dev/ep/if_ep_eisa.c:218: error: for each function it appears in.) *** Error code 1 [snip] I've just committed a fix for this: if_ep_eisa.c: $FreeBSD: src/sys/dev/ep/if_ep_eisa.c,v 1.26 2003/10/18 20:44:23 bms Exp $ BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic with cdrecord -- anybody else seeing this? [backtrace obtained]
On Mon, Oct 13, 2003 at 05:26:59AM -0700, John Reynolds wrote: Thanks. I haven't tried cdrtools-devel in a while so I probably didn't see the work-around that was committed. I will try it and report back as to if it works (to further narrow down the mlockall(2) bit). It looks like alc@ has fixed the problem in vm_fault.c rev 1.181. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to boot cvsup 20031011
On Tue, Oct 14, 2003 at 09:19:10PM -0400, Brian J. Creasy wrote: the last good cvsup i did was quite a while ago. july 13th. i got a little hung up with the semester starting back up. there isn't a way to tell cvsup a specific date to roll back to, is there? There is... please to be RTFMing... it's in the manual page. BMS pgp0.pgp Description: PGP signature
Re: [Build Error]:: pccard
On Sun, Oct 12, 2003 at 03:37:44PM +, Sebastian Yepes F. [ESN] wrote: Hi all there haves been some problems with the pccard* for like 2 weeks i have not been abel to compile the kernel. fest it was the pccardvar.h was mising this:: Did you follow all the instructions in UPDATING? I have been building GENERIC successfully from source over the past 2 weeks with a rolling cvs checkout from my local repository mirror. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_map_wire: lookup failed
On Thu, Oct 09, 2003 at 11:59:35AM +0200, John Hay wrote: The latest development source of ntpd started to use setrlimit() before using mlockall(). This combination proves fatal on -current. The code in ntpd/ntpd.c looks like this: [snip] I'll look into this. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass panic when connecting camera
On Tue, Oct 07, 2003 at 08:02:02PM +0200, John Hay wrote: Any comments from people a little more knowledgable in the umass/usb area? I don't know about USB specifically, but I thought timeout() et al were to be deprecated in favour of callout*() ? BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cannot build kernel
On Sun, Oct 05, 2003 at 12:03:33PM +0200, Matt Douhan wrote: Content-Description: signed data cvsup this morning 5th oct 12.05 PM Specify timezone please - I committed a fix for this a few hours ago. BMS pgp0.pgp Description: PGP signature
panic in rman_reserve_resource_bound
With today's -CURRENT: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x3abd4 data=0x16f8+0xe68 syms=[0x4+0x5c10+0x4+0x7a31] 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 #0: Sun Oct 5 16:11:39 BST 2003 [EMAIL PROTECTED]:/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI_DEBUG Preloaded elf kernel /boot/kernel/kernel at 0xc082a000. Preloaded elf module /boot/kernel/vesa.ko at 0xc082a1cc. Preloaded elf module /boot/kernel/if_vr.ko at 0xc082a278. Preloaded elf module /boot/kernel/usb.ko at 0xc082a324. Preloaded elf module /boot/kernel/netgraph.ko at 0xc082a3cc. Preloaded elf module /boot/kernel/acpi.ko at 0xc082a47c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) processor (1435.75-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 268369920 (255 MB) avail memory = 251154432 (239 MB) Pentium Pro MTRR support enabled VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc0799d22 (122) VESA: NVidia npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: SOYO AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00fdee0 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 9 INTA is routed to irq 10 pcib0: slot 10 INTA is routed to irq 12 pcib0: slot 12 INTA is routed to irq 11 pcib0: slot 14 INTA is routed to irq 11 pcib0: slot 17 INTD is routed to irq 5 pcib0: slot 17 INTD is routed to irq 5 pcib0: slot 18 INTA is routed to irq 11 agp0: VIA Generic host to PCI bridge mem 0xd000-0xd7ff at device 0.0 on pci0 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x181 fault code = supervisor write, page not present instruction pointer = 0x8:0xc04dfa55 stack pointer = 0x10:0xc0c21834 frame pointer = 0x10:0xc0c21878 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 = 0 (swapper) kernel: type 12 trap, code=0 Stopped at rman_reserve_resource_bound+0x3d5: movl%ecx,0x4(%eax) db trace rman_reserve_resource_bound(c071c1c0,d000,d7ff,800,0) at rman_reserve_resource_bound+0x3d5 rman_reserve_resource(c071c1c0,d000,d7ff,800,0) at rman_reserve_resource+0x3c nexus_alloc_resource(c16a5480,c2d29380,3,c0c21ae8,d000) at nexus_alloc_resource+0xed resource_list_alloc(c2d2930c,c16a6a80,c2d29380,3,c0c21ae8) at resource_list_alloc+0xdf acpi_alloc_resource(c16a6a80,c2d29380,3,c0c21ae8,d000) at acpi_alloc_resource+0x54 bus_generic_alloc_resource(c16a6480,c2d29380,3,c0c21ae8,d000) at bus_generic_alloc_resource+0xaf resource_list_alloc(c2d29304,c2d29400,c2d29380,3,c0c21ae8) at resource_list_alloc+0x1e4 pci_alloc_resource(c2d29400,c2d29380,3,c0c21ae8,0) at pci_alloc_resource+0x220 bus_alloc_resource(c2d29380,3,c0c21ae8,0,) at bus_alloc_resource+0xb2 agp_generic_attach(c2d29380,c0c21b24,c04d5349,c2d29400,c2d29380) at agp_generic_attach+0x53 agp_via_attach(c2d29380,c2ce3098,c0675adc,c07fa845,6) at agp_via_attach+0x22 device_probe_and_attach(c2d29380,0,c0c21b98,c080c0ea,c2d29400) at device_probe_an+0xb0 bus_generic_attach(c2d29400,c169f700,1,c080bea0,c2d29400) at bus_generic_attach+0x28 acpi_pci_attach(c2d29400,c2cf8098,c0675adc,612e7768,2e697063) at acpi_pci_attach+0xda device_probe_and_attach(c2d29400,c2d2ef40,c0c21bfc,c080c1cf,c16a6480) at device_probe_and_attach+0xb0 bus_generic_attach(c16a6480,c2d2ef50,0,c169f700,c2d2ef40) at bus_generic_attach+0x28 acpi_pcib_attach(c16a6480,c2d2ef50,0,c0c21c34,c04d5349) at acpi_pcib_attach+0xcf acpi_pcib_acpi_attach(c16a6480,c2d18098,c0675adc,c07fa845,c16a6580) at acpi_pcib_acpi_attach+0x1ed device_probe_and_attach(c16a6480,4,c0c21ca0,c0806294,c16a6a80) at device_probe_and_attach+0xb0 bus_generic_attach(c16a6a80,c1693720,64,c08062b0,c16a6a80) at bus_generic_attach+0x28 acpi_probe_children(c16a6a80,c0807ab0,c16a6a00,0,1a4) at acpi_probe_children+0x94 acpi_attach(c16a6a80,c2d04098,c0675adc,c0819528,c2cf7050) at acpi_attach+0x6ee device_probe_and_attach(c16a6a80,c16a5480,c0c21d2c,c0612bbc,c16a5480) at device_probe_and_attach+0xb0
LOR in schedcpu(), sched_4bsd.c
With today's CURRENT: ... GEOM: create disk ad0 dp=0xc2a3a380 ad0: 38166MB ST340016A [77545/16/63] at ata0-master UDMA100 acd0: DVDROM _NEC DV-5700B at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s1a Loading configuration files. Entropy harvesting: interrupts ethernet point_to_point. Reseed type 1 Reseed finish lock order reversal 1st 0xc06bfa20 callout_dont_sleep (callout_dont_sleep) @ kern/kern_timeout.c:223 2nd 0xc06bed80 allproc /sched_4bsd.c:253 Stack backtrace: backtrace(c06537e4,c06bed80,c065018e,c065018e,c0651c30) at backtrace+0x17 witness_lock(c06bed80,0,c0651c30,fd,c06c1e60) at witness_lock+0x697 _sx_slock(c06bed80,c0651c27,fd,8,c0651945) at _sx_slock+0xa9 schedcpu(0,0,c065193c,df,c12a8ab0) at schedcpu+0x3f softclock(0,0,c064e447,230,c12a77d0) at softclock+0x1fb ithread_loop(c129d200,cdb17d48,c064e2c1,314,c7e8) at ithread_loop+0x182 fork_exit(c04aa4a0,c129d200,cdb17d48) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdb17d7c, ebp = 0 --- Debugger(witness_lock) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db show locks exclusive sleep mutex callout_dont_sleep r = 0 (0xc06bfa20) locked @ kern/kern_timeout.c:223 db show witness Sleep locks: 0 taskqueue kthread -- last acquired @ kern/subr_taskqueue.c:253 0 g_xdown -- last acquired @ geom/geom_io.c:351 1 ATA disk bioqueue lock -- last acquired @ dev/ata/ata-disk.c:240 3 bio queue -- last acquired @ geom/geom_io.c:64 5 Malloc Stats -- last acquired @ kern/kern_malloc.c:335 3 ATA queue lock -- last acquired @ dev/ata/ata-queue.c:174 8 UMA pcpu -- last acquired @ vm/uma_core.c:1726 9 KMAP ENTRY -- last acquired @ vm/uma_core.c:1744 9 UMA zone -- last acquired @ vm/uma_core.c:1744 0 g_xup -- last acquired @ geom/geom_io.c:370 2 Giant -- last acquired @ kern/kern_timeout.c:216 3 malloc -- last acquired @ cquired @ kern/subr_eventhandler.c:213 4eventhandler list -- last acquired @ kern/kern_exit.c:210 3 vm object_list -- last acquired @ vm/vm_object.c:620 3 arc4_mtx -- last acquired @ libkern/arc4random.c:137 3 UMA lock -- last acquired @ vm/uma_core.c:802 3 filedesc structure -- last acquired @ kern/kern_descrip.c:1625 4pipe mutex -- last acquired @ kern/sys_pipe.c:481 5 sigio lock -- last acquired @ kern/kern_descrip.c:587 6 process group -- last acquired @ kern/kern_fork.c:575 7 process lock -- last acquired @ kern/kern_prot.c:1821 8struct pargs.ref -- last acquired @ kern/kern_proc.c:1077 8sigacts -- last acquired @ kern/kern_sig.c:596 8vnode interlock -- last acquired @ kern/vfs_subr.c:2176 9 Syncer mtx -- last acquired @ kern/vfs_subr.c:1663 9 vnode_free_list -- last acquired @ kern/vfs_subr.c:923 9 spechash -- last acquired @ kern/vfs_subr.c:1989 8ktrace -- last acquired @ kern/kern_fork.c:601 8session -- last acquired @ kern/kern_fork.c:584 9 uidinfo hash -- last acquired @ kern/kern_resource.c:878 10 sleep mtxpool -- last acquired @ kern/kern_prot.c:1685 10 uidinfo struct -- last acquired @ order list:0 11 allprison -- last acquired @ order list:0 3 ithread -- last acquired @ kern/kern_intr.c:265 3 GEOM orphanage -- last acquired @ geom/geom_event.c:169 3 rman head -- last acquired @ kern/subr_rman.c:110 3 sf_bufs list lock -- last acquired @ i386/i386/vm_machdep.c:577 5Malloc Stats -- (already displayed) 5system map -- last acquired @ vm/vm_map.c:2904 6 kmem object -- last acquired @ vm/vm_kern.c:437 7 vm page queue mutex -- last acquired @ vm/vm_object.c:594 8 vnode interlock -- (already displayed) 8 UMA pcpu -- (already displayed) 7 CMAPCADDR12 -- last acquired @ i386/i386/pmap.c:2475 6 vm object -- last acquired @ vm/vm_object.c:433 7 vm page queue mutex -- (already displayed) 7 CMAPCADDR12 -- (already displayed) 3 taskqueue list -- last acquired @ kern/subr_taskqueue.c:384 3 kernel linker -- last acquire/kern_linker.c:460 3 rman -- last acquired @ kern/subr_rman.c:132 5Malloc Stats -- (already displayed) 5system map -- (already displayed) 3 sellck -- last acquired @ kern/sys_generic.c:1174 3 domain list -- last acquired @ kern/uipc_domain.c:114 3 devd -- last acquired @ kern/subr_bus.c:406 3 callout_dont_sleep -- last acquired @ kern/kern_timeout.c:223 4ifnet -- last acquired @ net/if.c:1172 4tcp -- last acquired @ netinet/tcp_timer.c:141 4ipflow list head -- last acquired @ netinet/ip_flow.c:288 4ipqlock -- last acquired @ netinet/ip_input.c:1237 4mbuf PCPU list lock -- last acquired @ kern/subr_mbuf.c:926 5 mbuf subsystem general lists lock -- last acquired @ kern/subr_mbuf.c:676 3 vm86 lock -- last acquired @ i386/i386/vm86.c:606 3 ATA queue lock -- (already displayed) 3 mntvnode vfs_subr.c:1054 3 pseudofs -- last acquired @ fs/pseudofs/pseudofs_fileno.c:86 3 bpf global lock -- last acquired @ net/bpf.c:1383 3 IPFW
Re: mounting vfat at boot
On Sun, Oct 05, 2003 at 06:20:45PM +0200, Christer Solskogen wrote: /dev/ad1s1 /mnt/dmsdos rw -m 775,user /dev/ad0s2 /mnt/emsdos rw, -m 775,user ^ This should be msdosfs. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 06:14:52PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Wednesday 24 September 2003 04:18, Kris Kennaway wrote: icecast-1.3.12_1 I don't have a -CURRENT machine to test with. I don't mind the port marked BROKEN, since it's unsupported abandonware and due for deorbit anyway. I object. The Icecast team have barely even documented how to configure Icecast 2 nor have they provided a means of cleanly migrating to the new XML configuration format. SPC is one organization who make a lot of use of this particular port, I am sure there are others. If you must kill it off at least give us time to bury it properly. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng still problematic
On Sat, Sep 20, 2003 at 02:17:21AM +0200, Marius Strobl wrote: Isn't it still a kernel bug if a user process can trigger a panic? Yes, it seems to be a bug in the mlockall(2) implementation. Backing it out or hindering cdrecord to use it avoids the panic. I already wrote an email to bms@ who commited the mlockall(2) and munlockall(2) support regarding this issue. I don't think that's been conclusively established yet, so statements of the form above are a bit unhelpful. The problem may well lie elsewhere in the system, as a parameter in vm_map_copy_entry() is being unexpectedly set to NULL in the backtrace which you provided me with. If more people can exercise the same codepath as you appear to be exercising with different configurations, then I will have more to go on. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Thu, Sep 18, 2003 at 08:17:16AM +0200, Soren Schmidt wrote: The right way of doing audio graps has been to set the wanted blocksize with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of the same size), then just read from the device. Ioctl's was newer meant to be used to read/write data, its also faster to use the R/W path... I'm sure users will see it as a functional regression, though. It might not be the 'right' API for it, I agree, but it would save our user base screaming if the functionality were preserved (or at least emulated). BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devd/devctl
On Sat, Sep 13, 2003 at 06:59:21PM -0400, Brandon S. Allbery KF8NH wrote: On Sat, 2003-09-13 at 18:49, M. Warner Losh wrote: and you cannot tell dhclient that interfaces have arrived. One way for it to tell that this has happened automatically is to get it to listen on a PF_ROUTE socket and check periodically for RTM_IFINFO messages. On another note, if I can sit down and play with it I may be able to get rid of the requirement for BPF from our port/import of isc-dhcp. IP_ONESBCAST means it shouldn't need to use raw sockets or BPF to transmit an undirected broadcast datagram. IP_RECVIFADDR/IP_SENDSRCADDR means it shouldn't need a socket per interface. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question related to FreeBSD Serial Console...
On Mon, Sep 01, 2003 at 05:29:09PM -0600, Scott Long wrote: At one time I was working on patches to the loader to make the console speed configurable. At the time, at least, I didn't see any evidence that the settings were stored in the boot0 block, but maybe I was wrong. In any case, finishing this up is on my TODO list. I was trying to make the boot process 100% independent of the VGA console at one stage. To the best of my knowledge, boot0 doesn't know anything about serial, unless someone's using my boot0sio hack (which I haven't committed, btw; it was very specific - you have only 512 bytes to play with in the MBR, and I understand people had problems with jhb's 1024 byte boot0). boot2 is probably the more interesting part, it does make assumptions if BOOT_COMCONSOLE_SPEED wasn't specified in the make, and loader takes its cue from that up until it sees 'console' in loader.conf[.local]. One of the limitations here is that there can only be one console. Anything else would be something of a hack to get boot2 and loader to tee their output to two independent devices. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_mkhomedir
On Sat, Aug 30, 2003 at 10:09:14AM +0200, Antoine Jacoutot wrote: If I remember, pam_mkhomedir was in the contrib section under 4.x. Any idea why it is not part of FreeBSD anymore ? Or do you know any other way of auto-creating users homedir ? My virtual hosting setup does this through ProFTPD and doesn't use PAM. The problem with this is that you need to be running as root, or as a user or group which can create under /home, or have the sticky bit on /home. I see the source under RELENG_4 as: /src/contrib/libpam/modules/pam_mkhomedir I can't think of any major reasons why you couldn't just continue using this if it worked for you before. It would probably work from login. sshd might require you to enable UseLogin yes in sshd_config. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: USB da(4) quirks disabled for 4.9 and 5.2
On Fri, Aug 22, 2003 at 12:20:55AM -0700, Nate Lawson wrote: If you have any of the devices listed below, please test with a recent -stable or -current. They will stop working in 4.9 and 5.2 although old behavior can _temporarily_ be enabled by adding options DA_OLD_QUIRKS to your kernel config. If I don't hear from anyone, they'll be going away permanently after the releases. The Y-E 'Flashbuster' floppy is a fairly common device. It is often sold with Sony Vaio notebooks. There is legacy BIOS boot support, but how will people use a fixit floppy once the kernel has booted? BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fwcontrol -r missing a close() call
On Wed, Aug 20, 2003 at 01:11:45AM -0700, Terry Lambert wrote: I used to think this way too. Then I had to deal with some multithreaded applications that failed to pthread_join() or pthread_kill() their threads, AND with applications that had snip I'm using kqueue() instead for my current project. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Mon, Aug 11, 2003 at 11:09:44PM -0400, Adam Migus wrote: The hardware is a dual Xeon box. The kernel is SMP w/ SCHED_ULE instead of SCHED_4BSD, the options required for diskless and the following two options: options CPU_FASTER_5X86_FPU options CPU_UPGRADE_HW_CACHE Why are you using these options? they shouldn't be required for a Xeon. Are you able to break in to DDB to run a ps to inspect the process table via the debugger key or NMI? BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pci configuration
On Wed, Aug 13, 2003 at 05:51:09PM +0300, Petri Helenius wrote: True, those parameters are available, but the original question was about reporting the bus width and frequency, which are not available. How can these parameters be displayed? Generally I measure PCI bus frequency by attaching a poor man's 'bus analyzer'. There are low end ones available. The one I use is called the 'PC Geiger'. This has a CPLD capable of decoding the PCI logic and a small PIC to control the display and which reads some of the CPLD registers. I'm not aware of any chipsets which expose information about the PCI bus clock / bus width in use. A long trawl through datasheets may be in order. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildkernel hang with SCHED_ULE
On Thu, Aug 14, 2003 at 05:45:28PM -0400, Adam Migus wrote: I also do testing on a dual Althon and honestly didn't bother to research whether they'd have any affect. Could/would they be causing a problem? I'll recompile without them and try again at any rate. They are old options for enabling hardware cache on machines which have had a processor upgrade installed, or for enabling Cyrix 5x86 FPU handler options. They are documented in NOTES. I could find scant documentation on the FASTFPE bit. http://www.sandpile.org/ia32/ccr.htm#ccr4 suggests that it was only ever used on the old 486 pin-compatible Cyrix 5x86. It is possible setting these bits has an undefined effect on your more recent machines. Try compiling a kernel without them and see if your scheduler problem manifests itself. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Sat, Jul 26, 2003 at 05:32:17PM +0930, Greg 'groggy' Lehey wrote: Can anybody point me in the right direction? Where should I be looking for this? Is this memory mapped permanently, or is it only during X startup? The video BIOS is usually mapped by system BIOS into real memory to begin with, so it should be just sitting there. There are usually northbridge chipset registers for dealing with this sort of thing. The SMM mode might reuse that window, though, but generally this is hidden from non-SMM mode applications. You're in luck - been rebuilding X, so have xc tarballs handy. The XFree86 code responsible is: xc/programs/Xserver/hw/xfree86/int10 Some drivers like to call VBE via int10h, so this module acts as a bridge. It just memcpy()'s the ROM and uses various methods, depending on the compilation target, to call int10h. Is the onboard video AGP/PCI? It is possible that the device isn't reporting its memory window in the ROM BAR correctly. I've seen this happen with some low-end network cards before. Try my tools at this URL to check this: http://www.incunabulum.com/code/projects/pci/freebsd/ BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Disabling ISAPNP in -CURRENT
Hi, Is there any way to disable ISAPNP from probing in -CURRENT short of writing a patch to do so? It is causing some delay when booting Bochs. Thanks BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ThinkPad T20 with 5.0R wakes up from halt -p
I concur. My T22 also experiences the same problems:- - On transition to ACPI state S3: - LCD backlight stays on (until lid closed) - Drive spins down immediately - On transition to ACPI state S5: - Machine turns on unexpectedly (*probably* 15 minutes later) I am currently experiencing panics which appear to be related to ACPI, although I am actively hacking on the csa(4) driver to fix its suspend/resume functions. These appear to work fine under APM, however, using APM loses Ultrabay 2000 hot swap functinality. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
