Re: Using ipfw in current branch
Hello again, Please disregard the email below, I realized I wasn't using that kernconf file. So I re-added the following lines to the latest GENRIC kernconf file: # JD options IPFILTER# ipfilter or something options IPDIVERT# enable nat options IPFILTER_LOG# something else too options IPFILTER_DEFAULT_BLOCK # Block all packets by default [snip] Ideas? Here is the updated kernconf link: http://www.dictos.com/AHAB Thanks, -Jason Try reading /usr/src/UPDATING (its near the top, but read the whole thing anyway - it'll be good for you). Also, ipfw and ipfilter are not the same thing. Brian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
new -current panic
Just got this one (using bsd scheduler): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04b8f3b stack pointer = 0x10:0xcd619bc4 frame pointer = 0x10:0xcd619bd8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 3 (g_up) kernel: type 12 trap, code=0 Stopped at propagate_priority+0x8b:cmpl0x24(%ebx),%ecx db trace propagate_priority(c0ebfe40,c25983c0,c2512400,cd619c14,c04cc9d1) at propagate_pr iority+0x8b _mtx_lock_sleep(c069c340,0,0,0,c0698700) at _mtx_lock_sleep+0x249 bufdonebio(c7675b68,cd619c44,c048d612,c084c540,c259f990) at bufdonebio+0x47 biodone(c7675b68,c06411ba,c259f990,c7675b68,0) at biodone+0xbc g_dev_done(c259f990,c0ebfe40,1,0,4) at g_dev_done+0x8a biodone(c259f990,0,24c,c0640b45,a) at biodone+0xbc g_io_schedule_up(c0ebfe40,c0ebe1e4,cd619d34,c04acae1,0) at g_io_schedule_up+0xb8 g_up_procbody(0,cd619d48,0,0,0) at g_up_procbody+0x28 fork_exit(c048df60,0,cd619d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcd619d7c, ebp = 0 --- db -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help saving my system
Scott M. Likens writes: Ah, such a strong comment from such a strong member. I would have thought you were to high to stoop that low? But I guess it's good to be flamed for being honest? is it not? Please don't encourage flames and flamers by responding to them. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DISCUSSION: /dev/fd%d.%d and /dev/{a}cd%d[ac] to be discontinued ?
In message [EMAIL PROTECTED], Andrew Gallatin writes: Poul-Henning Kamp writes: As soon as these uses of cloning code has been removed, I will move the floppy and CD drivers under GEOM, paving the way for the significant changes to the buf/VM system which some of you have already heard rumours about. (more will emerge after BSDcon'03) And now comes the bit which I would like to offer for discussion: Should we do this for 5.2 instead ? I think this sounds good. Can you give a hint as to what you mean by the significant buf/VM system changes? Are you talking about removing the vnode detour for drivers and giving drivers who want it access to the struct file? ... and all that stuff yes. It's been discussed in various emails in the past. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Random signals in {build,install}world recently?
Hi It seems to be a recent problem. The hardware is OK, both Windows XP (which I use very seldom) and Gentoo Linux do not exhibit any problems. Basically one will get random signals as I have got in build- and installworld. It's impossible to complete make -j2 buildworld on my machine, but sometimes non-parallel buildworld will do, only to die later in installworld. This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and 1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it matters. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, 20 Oct 2003, Vallo Kallaste wrote: VKHi VK VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. 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: __fpclassifyd problem
Steve Kargl wrote: On Sun, Oct 19, 2003 at 03:48:58PM -0700, Kris Kennaway wrote: On Sun, Oct 19, 2003 at 03:13:41PM -0700, Steve Kargl wrote: I sent in an email *along time ago* about this type of problem. See the fallout due to revision 1.24 of lib/libc/stdio/findfp.c. IMHO, all shared libraries versions should have been bumped in going from 4.x to 5.0. You don't want to do it before you have to, because this creates more pain for people when you make a change that breaks backwards compat (given the policy/preference of only bumping once per major release). I'm working on a script that will detect the kind of backwards compatibility breakage we're seeing here by comparing the symbols in 4.x and 5.x versions of libraries with the same major revision. We can then run this once a day/week/whatever somewhere to catch these problems as soon as they occur in future. You and I participated in the first go around in the library versioning problem. For one of my attempts to discuss this problem, see http://www.freebsd.org/cgi/getmsg.cgi?fetch=1981830+1986079+/usr/local/www/db/text/2002/freebsd-current/20021103.freebsd-current Are there any hints how to solve my problem, I'm willing to give it a shot ;) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Mon, Oct 20, 2003 at 10:51:50AM +0200, John Angelmo wrote: Are there any hints how to solve my problem, I'm willing to give it a shot ;) We're discussing it, please be patient. kris pgp0.pgp Description: PGP signature
802.11g PCMCIA card mode
Hi, I have Proxim Orinoco 802.11b/g card, Atheros 5212. I need set ad-hoc mode (ifconfig ath0 mode 11g mediaopt adhoc), but it doesn't work. Is it supported this mode? Tin Hugo Boss - Boss Intense Nov vn pro eny. Zkus ji! http://www.email.cz/hugoboss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : We need to resolve this before 5.2 in some fashion. It looks like the : easiest thing to do is bump libm. Is this advisable? The problem with bumping libm is that we also need, strictly speaking, to bump all libarires that depend on libm, and that can be very ugly. This moves the bump the major version from the trivial fix class to something that we have to think real hard about. In general one cannot bump the major version of 'base' libaries like this w/o careful thought and planning. While we've done that in the past with libc, I think we were wrong to do so in some classes of symbol tampering. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
In message: [EMAIL PROTECTED] Steve Kargl [EMAIL PROTECTED] writes: : I sent in an email *along time ago* about this type : of problem. See the fallout due to revision 1.24 : of lib/libc/stdio/findfp.c. IMHO, all shared libraries : versions should have been bumped in going from 4.x to : 5.0. I tend to agree due to some weirdness that forced the libc bump. However, this would then have to includ all ports libraries too. Bumping all ports libraries and having a viable ports system that built on both 4.x and 5.x would then become nightmarish because you'd not want to bump them on 4.x. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
Hi, have severe problems accessing usb devices as non-root user. In this case a Canon Powershot G5 camera. I want to download pics from my digicam using digikam application as user andreas. The devices that are being used by digikam: [EMAIL PROTECTED] ~ lsof | grep digikam | grep /dev digikam 1755root0u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root1u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root2u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root 15u VCHR 114,16 0t0 128 /dev/ugen1 digikam 1755root 16r VCHR 114,17 0t7817 131 /dev/ugen1.1 digikam 1755root 17r VCHR 114,190t16 133 /dev/ugen1.3 Running digikam with SUID root bit turned on doesn't work. [EMAIL PROTECTED] ~ digikam The KDE libraries are not designed to run with suid privileges. Changing the permissions on /dev/ugen1* doesn't work either since - even _if_ the devices are present after turning camera on and - even _if_ permissions of /dev/ugen1 /dev/ugen1.1 ... 1.3 are being changed successfully to 666 the devices seems to be on the 1st access dynamically recreated, since the permissions suddenly are *re-set* to root 644 automagically after the 1st access of the digikam application as user. To sum up: as normal user I'm unable to connect to the USB camera. Is there a more generic approach to be able to use USB devices as non-root user, that I overlooked up to now ? Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic with unloading nvidia.ko
I just got a kernel panic after making /usr/ports/x11/nvidia-driver. I did a make, make reinstall. Then I did a kldunload nvidia.ko and got: nvidia0: detached panic: malloc(9)/free(9) confusion. Probably freeing with wrong type, but maybe not here. Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx, in_Debugger.0 trace shows: Debugger panic free os_free __nvsym00022 __nvsym00638 __nvsym00678 __nvsym00723 rm_shutdown_rm nvidia_modevent driver_module_handler module_unload linker_file_unload kld_unload syscall Xint0x80 -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
On Mon, Oct 20, 2003 at 12:19:46PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm wri tes: Hi, have severe problems accessing usb devices as non-root user. In this case a Canon Powershot G5 camera. I want to download pics from my digicam using digikam application as user andreas. Use the devfs(8) command to request changes the owner or modes to suit your needs. This works a bit like firewall rules and when the device is created the modes/owner is set. Good idea. But no success and inexpected results. Well now I use both /etc/devfs.conf and devfs rule add in /etc/rc.local. It was 1st unclear to me after reading the devfs(8) manpage, that the devfs rule add - command 1st needs a command like devfs ruleset 100 So now I have 1) /etc/devfs.conf with: permugen1 0666 permugen1.1 0666 permugen1.2 0666 permugen1.3 0666 and 2) devfs rule show 100 path ugen mode 666 I halted system, turned camera off and on Booted FreeBSD. 1. Step, check permissions without having started any camersa application ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-rw-rw- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-rw-rw- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-rw-rw- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 You see the camera is on, therefore the ugen1 devices have been created. Good so far. A bit strange is, that ugen0 (USB printer) still has mode 644, this is the printer... I would expect, that the devfs rule 100 would have been applied by the system and it should be active for this device as well ! Note: And later we see, that even the permission of the ugen1 interface change again to 644 after the 1st access or whatever ! Well lets repeat, the machine is freshly restarted, camera was on and ugen1 devices have 0666. 2. step: start digikam as user [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-rw-rw- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-rw-rw- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-rw-rw- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 The startup itself is harmless nothing happens and no access to camera. The digikam application has a config files and presents the camera found in the last session (from config file). 3. step, try to access camera by klick on the Canon PowerShot G5 line in digikam failed to initialize the camera [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. Note: I think the lpd daemon accesses the printer on startup. Therefore the ugen0 device already had the new permission 644 which I observed in the previous step ! Any idea how to resolve this ? And BTW, shouldn't the devfs(8) manpage have a reference to devfs.conf ? I understand, that /etc/devfs.conf is only used by the /etc/rc.d/devfs startup script, to setup permissions via chmod commands and such so no real relationship to the devfs command. But I'd find it useful to have a reference to it. Or ... something like a devfs.conf(5) manpage is missing and a SEE ALSO devfs.conf(5) in devfs(8) is missing, what would probably be better ... Or what do you think ? -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
In message [EMAIL PROTECTED], Andreas Klemm writ es: 1) /etc/devfs.conf with: permugen1 0666 permugen1.1 0666 permugen1.2 0666 permugen1.3 0666 I would probably just use a wildcard: permugen* 0666 1st needs a command like devfs ruleset 100 This makes the rules only apply to devices arriving in the future, you also need: devfs rule applyset to make them apply to currently available devices. 3. step, try to access camera by klick on the Canon PowerShot G5 line in digikam failed to initialize the camera [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. And BTW, shouldn't the devfs(8) manpage have a reference to devfs.conf ? I understand, that /etc/devfs.conf is only used by the /etc/rc.d/devfs startup script, to setup permissions via chmod commands and such so no real relationship to the devfs command. Yes, probably a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
Poul-Henning, many thanks for you kind guidance to the wonderful world of devfs (which I never had to tweak in the past) ;-) On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: I would probably just use a wildcard: permugen* 0666 The wildcard feature is really fine ! Thanks for pointing me into that direction. This makes the rules only apply to devices arriving in the future, you also need: devfs rule applyset to make them apply to currently available devices. Good hint ! Thanks ! Well and now things work like expected. I put these devfs commands now into /etc/rc.local. But since /etc/rc.local officially has gone, I think this is not the best place ... After a longer examination of /etc/devfs, /etc/rc.subr /etc/defaults/devfs.rules and /etc/defaults/rc.conf I got the clue, that I can put the statements into /etc/devfs.rules. Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
In message [EMAIL PROTECTED], Andreas Klemm writ es: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) I personally end up less(1)'ing /etc/rc.d/* every time I want to do something... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ad0: WARNING - WRITE_MUL write data underrun 81922048
I got this message while copying some files from my windows box (via samba) to my FreeBSD box. The files were going to ad4/ad6 (vinum raid). All I did was cvsup src and ports during the copy and also, after the cvsup was done, installed apache2. uname: FreeBSD mp3.earthlink.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Oct 14 00:33:48 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MP3 i386 the only difference between GENERIC and my config is I removed all cpu except for I686 and changed the ident. I attached my dmesg and config. I also have another problem with my ad4 and ad6 drives (the ones that are part of the vinum raid). If I leave DMA on, i can only copy about 30-50M of data before i get timeouts and the machine locks up and I have to do a reset. Let me know if you need anymore info (boot -v), or you need access to the machine. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.comCopyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Oct 14 00:33:48 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MP3 Preloaded elf kernel /boot/kernel/kernel at 0xc0a0b000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0a0b21c. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1311.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x644 Stepping = 4 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 268353536 (255 MB) avail memory = 251019264 (239 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V on motherboard pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00f1750 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 4 INTD is routed to irq 12 pcib0: slot 4 INTD is routed to irq 12 pcib0: slot 9 INTA is routed to irq 12 pcib0: slot 12 INTA is routed to irq 11 pcib0: slot 17 INTA is routed to irq 10 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xe400-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 12 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 12 at device 4.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: bridge, PCI-unknown at device 4.4 (no driver attached) dc0: 82c169 PNIC 10/100BaseTX port 0xa400-0xa4ff mem 0xe300-0xe3ff irq 12 at device 9.0 on pci0 dc0: Ethernet address: 00:a0:cc:53:6e:57 miibus0: MII bus on dc0 bmtphy0: BCM5201 10/100baseTX PHY on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: display, VGA at device 12.0 (no driver attached) atapci1: Promise PDC20265 UDMA100 controller port 0x8800-0x883f,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 mem 0xdb80-0xdb81 irq 10 at device 17.0 on pci0 atapci1: [MPSAFE] ata2: at 0xa000 on atapci1 ata2: [MPSAFE] ata3: at 0x9400 on atapci1 ata3: [MPSAFE] 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 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-0xca7ff,0xc-0xc7fff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 1311691616 Hz quality 800 Timecounters tick every 10.000 msec acpi_cpu: throttling
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: On Mon, 20 Oct 2003, Vallo Kallaste wrote: VKHi VK VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. Couldn't the following be of help here? options DISABLE_PSE options DISABLE_PG_G Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Mon, 20 Oct 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : We need to resolve this before 5.2 in some fashion. It looks like the : easiest thing to do is bump libm. Is this advisable? The problem with bumping libm is that we also need, strictly speaking, to bump all libarires that depend on libm, and that can be very ugly. This moves the bump the major version from the trivial fix class to something that we have to think real hard about. In general one cannot bump the major version of 'base' libaries like this w/o careful thought and planning. While we've done that in the past with libc, I think we were wrong to do so in some classes of symbol tampering. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] If it's just __fpclassifyd(), can you just add a compatability hack to libm so it works with both libc 4.0 and 5.x? You can make __fpclassifyd a weak definition to the hack in libm. I suppose you could also add __fpclassfyd() to libc 4.0. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, 20 Oct 2003, Mark Santcroos wrote: MSOn Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: MS On Mon, 20 Oct 2003, Vallo Kallaste wrote: MS MS VKHi MS VK MS VKIt seems to be a recent problem. The hardware is OK, both Windows XP MS VK(which I use very seldom) and Gentoo Linux do not exhibit any MS VKproblems. MS VKBasically one will get random signals as I have got in build- and MS VKinstallworld. It's impossible to complete make -j2 buildworld on my MS VKmachine, but sometimes non-parallel buildworld will do, only to die MS VKlater in installworld. MS VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and MS VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it MS VKmatters. MS MS I have the same MB just with 1800+ processors. I had to reduce the CPU MS frequency by about 10% in the BIOS setup to get the machine stable. I MS assume the problem is actually the memory. MS MSCouldn't the following be of help here? MS MSoptions DISABLE_PSE MSoptions DISABLE_PG_G Is the processor bug that these options seem to circumvent dependend on the actual operating frequency of the processor? 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: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 03:29:04PM +0200, Harti Brandt wrote: MS I have the same MB just with 1800+ processors. I had to reduce the CPU MS frequency by about 10% in the BIOS setup to get the machine stable. I MS assume the problem is actually the memory. MS MSCouldn't the following be of help here? MS MSoptions DISABLE_PSE MSoptions DISABLE_PG_G Is the processor bug that these options seem to circumvent dependend on the actual operating frequency of the processor? That won't surprise me, as afaik it's a timing thing. Note that due to all vagueness around this issue I could be wrong, but it's worth a try I guess. Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt [EMAIL PROTECTED] wrote: VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. I'm in doubt in this matter, because it's been absolutely stable so far and is as stable as before under Linux and XP. Also, my problems very much coincidence with some list traffic about the same problem, follow the thread: Subject: Seeing system-lockups on recent current Message-ID: [EMAIL PROTECTED] I also managed to panic the system after repeated attempts to get through the installworld (which all failed). The panic string is panic: pmap_enter: attempted pmap_enter on 4MB page and is also described by the message: Subject: panic: pmap_enter: attempted pmap_enter on 4MB page Message-ID: [EMAIL PROTECTED] I have debug kernel, but the system locked up after the message and I had to drive home and reset the system. All those problematic systems seem to be AMD based. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote: On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: On Mon, 20 Oct 2003, Vallo Kallaste wrote: VKHi VK VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. Couldn't the following be of help here? options DISABLE_PSE options DISABLE_PG_G I don't think so. I tried that on my A7M266D with no effect. I believe something in recent pmap code doesn't like this mobo, or maybe dual athlons in general. I can run RELENG_5_1 rock solid, and -current from 9/24/03 rock solid, but -current from 10/3 or later gets random sigs and eventually panics. I have scsi disks so it's not ata. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
On Mon, Oct 20, 2003 at 02:40:00PM +0200, Poul-Henning Kamp wrote: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) That's not the right attitude for something that is 100% your baby. You've added a completely new subsystem to FreeBSD, one that people have no choice but to deal with when they move from 4.x to 5.x since you made devfs mandatory. It is YOUR responsibility to document it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: this /rescue thing
On Mon, Oct 20, 2003 at 11:55:57AM +0200, C. Kukulies wrote: === rescue/rescue install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot.sh install: /rescue/nextboot.sh: Not a directory *** Error code 71 Stop in /u/src/rescue/rescue. *** Error code 1 Looking into / I see that /rescue is a file. There was some pilot error in the order in which you updated your system after we added 'rescue'. You need to 'rm -rf /rescue ; mkdir /rescue' and then rebuild and install it. What is the safe method to put /rescue elsewhere (in an area with enough space). It also seems that it is being deleted by make world, at least I seem to remember that putting a soft link into /rescue into / didn't help either. You're missing the point of /rescue. It MUST be in / to be of any use. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote: On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote: On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: On Mon, 20 Oct 2003, Vallo Kallaste wrote: VKHi VK VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. Couldn't the following be of help here? options DISABLE_PSE options DISABLE_PG_G I don't think so. I tried that on my A7M266D with no effect. I believe something in recent pmap code doesn't like this mobo, or maybe dual athlons in general. I can run RELENG_5_1 rock solid, and -current from 9/24/03 rock solid, but -current from 10/3 or later gets random sigs and eventually panics. I have scsi disks so it's not ata. I have the same experiences. Also AMD A7M-266D with two 1800+ Athlons here. Used to work fine, but got random signals with my latest builds. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: Random signals in {build,install}world recently?
On Mon, 20 Oct 2003, Christian Brueffer wrote: CBOn Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote: CB On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote: CB On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: CB On Mon, 20 Oct 2003, Vallo Kallaste wrote: CB CB VKHi CB VK CB VKIt seems to be a recent problem. The hardware is OK, both Windows XP CB VK(which I use very seldom) and Gentoo Linux do not exhibit any CB VKproblems. CB VKBasically one will get random signals as I have got in build- and CB VKinstallworld. It's impossible to complete make -j2 buildworld on my CB VKmachine, but sometimes non-parallel buildworld will do, only to die CB VKlater in installworld. CB VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and CB VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it CB VKmatters. CB CB I have the same MB just with 1800+ processors. I had to reduce the CPU CB frequency by about 10% in the BIOS setup to get the machine stable. I CB assume the problem is actually the memory. CB CB Couldn't the following be of help here? CB CB options DISABLE_PSE CB options DISABLE_PG_G CB CB I don't think so. I tried that on my A7M266D with no effect. I believe CB something in recent pmap code doesn't like this mobo, or maybe dual CB athlons in general. I can run RELENG_5_1 rock solid, and -current from CB 9/24/03 rock solid, but -current from 10/3 or later gets random sigs CB and eventually panics. I have scsi disks so it's not ata. CB CB CBI have the same experiences. Also AMD A7M-266D with two 1800+ Athlons here. CBUsed to work fine, but got random signals with my latest builds. I have no problems with the -current, but, as I've said, I have tuned speed down. If I remember correctly they running slower than their nominal speed. Dmesg shows 1380.01MHz, although they're 1800+. This is tuneable in the BIOS. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new -current panic
On Mon, Oct 20, 2003 at 09:09:47AM +0200, Soren Schmidt wrote: Just got this one (using bsd scheduler): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04b8f3b stack pointer = 0x10:0xcd619bc4 frame pointer = 0x10:0xcd619bd8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 3 (g_up) kernel: type 12 trap, code=0 Stopped at propagate_priority+0x8b:cmpl0x24(%ebx),%ecx db trace propagate_priority(c0ebfe40,c25983c0,c2512400,cd619c14,c04cc9d1) at propagate_pr iority+0x8b _mtx_lock_sleep(c069c340,0,0,0,c0698700) at _mtx_lock_sleep+0x249 bufdonebio(c7675b68,cd619c44,c048d612,c084c540,c259f990) at bufdonebio+0x47 biodone(c7675b68,c06411ba,c259f990,c7675b68,0) at biodone+0xbc g_dev_done(c259f990,c0ebfe40,1,0,4) at g_dev_done+0x8a biodone(c259f990,0,24c,c0640b45,a) at biodone+0xbc g_io_schedule_up(c0ebfe40,c0ebe1e4,cd619d34,c04acae1,0) at g_io_schedule_up+0xb8 g_up_procbody(0,cd619d48,0,0,0) at g_up_procbody+0x28 fork_exit(c048df60,0,cd619d48) at fork_exit+0xb1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcd619d7c, ebp = 0 --- db I can remember having seen a similar panic several month ago - maybe even in jan or feb. -- B.Walter BWCThttp://www.bwct.de [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: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm writ es: [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. An USB device can be switched between several alternative configurations. If such a change is requested (USB_SET_CONFIG) the devicenode for everything but the control channel is recreated. -- B.Walter BWCThttp://www.bwct.de [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: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
In message [EMAIL PROTECTED], Bernd Walter writes: On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm writ es: [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. An USB device can be switched between several alternative configurations. If such a change is requested (USB_SET_CONFIG) the devicenode for everything but the control channel is recreated. But the devfs rules should still set the mode when it is recreated... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ethercons: ethernet console driver for 5-current
I had a fair amount of time over the last week running in disconnected
operation, and realized I had too many cables under my desk, so I spent a
bit of time exploring the FreeBSD console code. After reading a FREENIX
paper this summer on a Linux ethernet console driver, I took a pass at
implementing ethernet console support for FreeBSD. This driver is similar
to the Linux driver, although not binary-compatible on the wire, as this
driver supports both input and output, while the Linux driver supports
only output monitoring (and the protocol can't represent bi-directional
communication well). There are some potential work-arounds for this,
which I'll explore at some point. In general, the wire protocol is
probably the weakest part of the endeavor, but I'm having trouble finding
documentation for a decent wire console protocol that doesn't come with an
entire network stack attached.
As with the Linux driver, communication happens at the ethernet link
layer, using protocol number 0x0666 (entertaining choice). The contents
consist of a little meta-data (not found in Linux), and a nul-terminated
string, although the kernel code currently generates only single
characters due to the nature of the console code. ethercons implements
both a low level putc() console interface, and a high-level pseudo-tty
appropriate for /dev/console redirection and getty/login. Unlike the
other low-level console drivers, ethercons does not implement low-level
input checkc/getc, as ethercons is interrupt driven, and that interface is
a polled interface that conflicts with the tty code. I'm considering
adopting a timeout-driven model as done in ofw_console, but haven't
convinced myself that is entirely desirable. In addition, the ethercons
device is not available for I/O when in the debugger context, due to its
use of the network stack. To support this, I recently added a flags field
to the console definition, and a NODEBUGGER flag.
To enable support for ethercons, add options ETHERCONS to your kernel
configuration. A series of tunables and sysctls is available to tune the
behavior of ethercons:
kern.ethercons.ifnet_raise ifconfig up the interface prior to
reaching init so that ethercons may be
used in single usermode. Otherwise,
ethercons only becomes available when the
interface is brought up later by
dhclient/ifconfig/... Alternatively, for
network booted environments, the interface
may already be up.
kern.ethercons.interface_preference Interface name preference, if any.
Otherwise, the default is the first
ethernet interface. The most
recently used interface is
available read-only via
kern.ethercons.interface.
kern.ethercons.target Target ethernet address for the console target.
Otherwise, the default is ff:ff:ff:ff:ff:ff.
The ethercons client uses bpf; it's a fairly limited tool in its current
form. It has several modes of operation:
log Follow the console output of all ethernet consoles,
logging the output to various log files, named by the
source ethernet address of the messages (specified by
interface).
minitermA minimalist interactive terminal program to be pointed
at a specific ethernet interface and hardware address.
sendSend a string to a remote console as input (specified
by interface, target address).
sendcr Send a string to the remote console as input, along
with a carriage return (specified by interface, target
address).
tailFollow the console output of a particular ethernet console
(specified by interface and source address).
tailall Follow the console output of all ethernet consoles, even
though the results are potentially messy (specified by
interface).
It should be possible to create a more complete client for easier
interactive use; alternatively, the firewire console code binds a socket
for use with a telnet client, which could be done for ethercons, which
might be a better approach than writing more interactive code of that
sort.
You can set up a getty/login session on /dev/ethercons using /etc/ttys:
ethercons /usr/libexec/getty Pc xterm on secure
The changes consist of three parts: two new kernel files
(src/sys/dev/{ethercons.c, ethercons.h}), a kernel patch (ethercons.diff),
and a userland tool for monitoring/logging/communicating with the ethernet
console
Re: bug in NSS ?
From:[EMAIL PROTECTED] I have a problem with nss_ldap on FreeBSD. After tranfer users from /etc/passwd to ldap directories my users cannot send a mail via /usr/bin/mail | /usr/sbin/sendmail program: : Any ideas ? What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file? Is pwcheck_method set to saslauthd, or sasldb? If it is set to saslauthd, what flags do you use for it (-a pam or -a ldap)? Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sata + vinum + Asus p4p800 = :(
Greg 'groggy' Lehey schrieb: Provide a dump? Analyse the problem yourself? This *is* -CURRENT, after all. I can reproduce this here (same MB). I don't think it's a vinum problem, but vinum seems to be a good way to reproduce the bug. I set up a stripe over 2 SATA disks, newfs it, run iozone -a and BOOM. Using just one disk without vinum doesn't result in a panic, but with a verbose boot I see a lot of spurious interrupt messages while running iozone on one disk. The panic is: panic: ata_dmasetup: transfer active on this disk. Backtrace: ata_dmastart ata_pci_dmastart ata_transaction ata_start g_disk_start g_io_schedule_down g_down_procbody fork_exit fork_trampoline Trying to write a dump results in a hard hang of the system. The backtrace is with todays kernel source: ata-lowlevel 1.20 ata-pci.c 1.69 ata-queue.c 1.11 atapi-cd.c 1.149 Verbose dmesg attached (booted with an oct 17 kernel, if it's not enough, I rebuild the kernel with a larger message buffer). Greg, I don't know if the following is ATA related: I'm able to fdisk and disklabel the disks without any prolems, and the label survives a reboot, but rebooting after setting up the stripe results in a lost configuration, only the names of the drives show up with vinum l, everything else is clean (0 volumes, 0 plexes, 0 subdisks). The config is: ---snip--- drive SATA1 device /dev/ad1s1a drive SATA2 device /dev/ad2s1a volume space setupstate plex org striped 279k sd length 0 drive SATA1 sd length 0 drive SATA2 ---snip--- S/oren, one additional datapoint: With the oct 17 kernel I've seen the following output with a verbose boot before it hunged hard (I had DDB_UNATTENDED in the oct 17 kernel): - spurious interrupt messages for ata 0 and 2 - WARNING FLUSHCASHE for ad0 - WARNING WRITE_DMA recovered from missing int for ad1 - TIMEOUT WRITE_DMA retrying for ad2 - ata3 reset tp1 mask=03 ostat0=d0 ostat1=00 ---snip--- Feel free to use me as an testing-ape, I also can provide a root login to this machine if needed (just tell me and I grab the ssh key from freefall). Bye, Alexander. ngnt=0x00 (0 ns), maxlat=0x00 (0 ns) found- vendor=0x8086, dev=0x2571, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base ef00, size 5, enabled pcib0: matched entry for 0.29.INTA (source \\_SB_.LNKA) pcib0: slot 29 INTA is routed to irq 10 found- vendor=0x8086, dev=0x24d2, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type 4, range 32, base ef20, size 5, enabled pcib0: matched entry for 0.29.INTB (source \\_SB_.LNKD) pcib0: slot 29 INTB is routed to irq 5 found- vendor=0x8086, dev=0x24d4, revid=0x02 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[20]: type 4, range 32, base ef40, size 5, enabled pcib0: matched entry for 0.29.INTC (source \\_SB_.LNKC) pcib0: slot 29 INTC is routed to irq 5 found- vendor=0x8086, dev=0x24d7, revid=0x02 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[20]: type 4, range 32, base ef80, size 5, enabled pcib0: matched entry for 0.29.INTA (source \\_SB_.LNKA) pcib0: slot 29 INTA is routed to irq 10 found- vendor=0x8086, dev=0x24de, revid=0x02 bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 1, range 32, base febff800, size 10, enabled pcib0: matched entry for 0.29.INTD (source \\_SB_.LNKH) pcib0: slot 29 INTD is routed to irq 11 found- vendor=0x8086, dev=0x24dd, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 found- vendor=0x8086, dev=0x244e, revid=0xc2 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found- vendor=0x8086, dev=0x24d0, revid=0x02 bus=0, slot=31, func=0
Re: ethercons: ethernet console driver for 5-current
On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: I had a fair amount of time over the last week running in disconnected operation, and realized I had too many cables under my desk, so I spent a bit of time exploring the FreeBSD console code. After reading a FREENIX paper this summer on a Linux ethernet console driver, I took a pass at implementing ethernet console support for FreeBSD. Robert, This looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? -- Steve ___ [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-10-20 16:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-20 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-10-20 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-10-20 16:01:56 - 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-10-20 17:04:33 - 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 Mon Oct 20 17:04:33 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr_cam.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr_disk.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr_pci.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath
pcm exclusive sleep mutex with Oct19 CURRENT
from my dmesg: [snip] pcm0: ESS Technology Allegro-1 port 0xb800-0xb8ff irq 5 at device 1.0 on pci2 pcm0: failed to enable memory mapping! pcm0: ESS Technology ES1988 AC97 Codec malloc() of 64 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of 64 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 [snip] and later today i got even this: acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 Stack backtrace: with no backtrace at all. [EMAIL PROTECTED] flag]$ uname -a FreeBSD southcross.skynet.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 19 12:07:09 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOUTHCROSS i386 [EMAIL PROTECTED] flag]$ -- Paolo Italian FreeBSD User Group: http://www.gufi.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sata + vinum + Asus p4p800 = :(
On Monday, Oct 20, 2003, at 19:02 Europe/Budapest, Alexander Leidinger wrote: Greg 'groggy' Lehey schrieb: Provide a dump? Analyse the problem yourself? This *is* -CURRENT, after all. I can reproduce this here (same MB). I don't think it's a vinum problem, but vinum seems to be a good way to reproduce the bug. I set up a stripe over 2 SATA disks, newfs it, run iozone -a and BOOM. Well, my /etc dir is gone, and I have no other bootable device. Tomorrow my hardware guy will bring me a new be7s motherboard... Sorry guys, the rest is in your hands. -- jul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in NSS ?
I have a problem with nss_ldap on FreeBSD. After tranfer users from /etc/passwd to ldap directories my users cannot send a mail via /usr/bin/mail | /usr/sbin/sendmail program: What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file? Is pwcheck_method set to saslauthd, or sasldb? If it is set to saslauthd, what flags do you use for it (-a pam or -a ldap)? my /usr/local/lib/sasl2/Sendmail.conf: pwcheck_method: auxprop auxprop_plugin: sasldb Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm exclusive sleep mutex with Oct19 CURRENT
On Mon, Oct 20, 2003 at 07:15:19PM +0200, Paolo Pisati wrote: from my dmesg: [snip] pcm0: ESS Technology Allegro-1 port 0xb800-0xb8ff irq 5 at device 1.0 on pci2 pcm0: failed to enable memory mapping! pcm0: ESS Technology ES1988 AC97 Codec malloc() of 64 with the following non-sleepable locks held: exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ /usr/src/sys/dev/sound/pcm/mixer.c:322 Unfortunately none of the sound developers have been interested in looking at the locking problems in the code. acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 Stack backtrace: with no backtrace at all. FWIW, the backtrace would have been reported on the system console. Kris pgp0.pgp Description: PGP signature
Re: ethercons: ethernet console driver for 5-current
On Mon, Oct 20, 2003 at 10:03:52AM -0700, Steve Kargl wrote: On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: I had a fair amount of time over the last week running in disconnected operation, and realized I had too many cables under my desk, so I spent a bit of time exploring the FreeBSD console code. After reading a FREENIX paper this summer on a Linux ethernet console driver, I took a pass at implementing ethernet console support for FreeBSD. Robert, This looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? No..that was addressd in Robert's mail. Kris pgp0.pgp Description: PGP signature
Re: ethercons: ethernet console driver for 5-current
On Mon, 20 Oct 2003, Steve Kargl wrote: On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: I had a fair amount of time over the last week running in disconnected operation, and realized I had too many cables under my desk, so I spent a bit of time exploring the FreeBSD console code. After reading a FREENIX paper this summer on a Linux ethernet console driver, I took a pass at implementing ethernet console support for FreeBSD. This looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? Not currently. In the current implementation, the ethernet console picks up its input, and generates output, using the ethernet layer of the network stack. Since the debugger suspends scheduling, this means interrupt threads, netisrs, etc, aren't running, so for now, ethercons is disabled when in the debugger (db_active != 0). This permits other console devices, such as serial console, to be used for the debugger, however, at the same time. To support ethernet debugging, the debugger would need to be able to drive polling of the network interface in an interrupt-thread-free environment, and reproduce more of the lower level network code (i.e., not use mbufs, etc). This is feasible to do, but would probably require adding new interfaces to the ethernet driver, and supporting only ethernet cards that had these additional debugging interfaces. Compared to serial console, you'd also have a lot more situations where the driver/hardware state would be sufficiently inconsistent as to make debugging network-related crashes difficult. On the other hand, Darwin runs quite well with a network debugger; I believe they have a fairly complex UDP/IP implementation in the network debugger, although I haven't inspected it. Apple has the advantage, though, of providing very few ethernet drivers. So I'm happy to look at it, but the level of time investment to get to network debugging from the current (and pretty simple) ethercons device will be fairly high. I know Jonathan Lemon was looking at network console and debugging code previously, but I don't have copies of his patches. If I had to guess, I'd assume he had modified the if_fxp driver, and perhaps others, to provide an appropriate polled interface for use with a debugger, but I don't know for sure. If someone has copies of these patches, I'd be happy to take a look at them. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: this /rescue thing
On Mon, Oct 20, 2003 at 08:06:10AM -0700, David O'Brien wrote: On Mon, Oct 20, 2003 at 11:55:57AM +0200, C. Kukulies wrote: === rescue/rescue install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot.sh install: /rescue/nextboot.sh: Not a directory *** Error code 71 Stop in /u/src/rescue/rescue. *** Error code 1 Looking into / I see that /rescue is a file. There was some pilot error in the order in which you updated your system after we added 'rescue'. You need to 'rm -rf /rescue ; mkdir /rescue' and then rebuild and install it. What is the safe method to put /rescue elsewhere (in an area with enough space). It also seems that it is being deleted by make world, at least I seem to remember that putting a soft link into /rescue into / didn't help either. You're missing the point of /rescue. It MUST be in / to be of any use. Yeah, but what do if the partition overflows? Actually I never had the need for it in the past. What would be the correct use of /rescue? The most cumbersome issue in the past was the ever growing root FS in FreeBSD. I wish back the days of a 40 MB root FS. Is it possible to switch it off? Or to circumvent it somehow? -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Asus A7V8X-X USB problems
On Sat, 18 Oct 2003, Greg J. wrote: On Sat, 18 Oct 2003 15:55:52 -0700 (PDT) Doug White [EMAIL PROTECTED] wrote: On Wed, 15 Oct 2003, Doug White wrote: Anyone else having these errors? Is there a way to fix it? What's attached to the ports? Nothing.. if I plug anything in (like a mouse) it freezes my system. Interesting .. which VIA chipset is it? I have a KT400 at home that hasn't built current in a while but worked as of a few weeks ago. I'll have to try a fresh build. Incidentally I built -current and no issues. Unforutnately I snipped the dmesg so I couldn't see if the chips match up. This is what my soyo is detecting as: usb0: VIA 83C572 USB controller on uhci0 ehci0: EHCI (generic) USB 2.0 controller mem 0xe410-0xe41000ff irq 10 at device 16.3 on pci0 Same.. except my ehci has: mem 0xe480-0xe48000ff irq 6 I updated again yesterday (10/17/2003) the problem disappeared.. maybe it didn't update one of the usb source files last time? Thanks for your help. Cool .. no worries. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: this /rescue thing
C. Kukulies wrote: /rescue is always causing trouble with me here. make world falls over with: === rescue/rescue install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot.sh install: /rescue/nextboot.sh: Not a directory *** Error code 71 Stop in /u/src/rescue/rescue. *** Error code 1 Looking into / I see that /rescue is a file. Why is this /rescue being created in /? It used to blow up and overflow the / filesystem (there were times when a 40 MB root FS was sufficient). What is the safe method to put /rescue elsewhere (in an area with enough space). It also seems that it is being deleted by make world, at least I seem to remember that putting a soft link into /rescue into / didn't help either. Symlinking /rescue - / will cause exactly the problem you're seeing. (Because there is a file called /rescue/rescue, which will then get installed on top of the symlink. Boom!) Don't do that. You could probably symlink /rescue - /usr/rescue, but that sort of defeats the purpose. /rescue is part of a plan to reduce the size of the / partition, though it's a somewhat involved process. There are two key pieces: 1) Building /bin and /sbin dynamically. This is a big space savings, but comes at a cost. Namely, it's a lot easier to trash a dynamic /bin than the old static one. 2) /rescue contains a compact set of statically-linked executables (about 3MB total) that are provided to help in system recovery if /bin or /sbin gets damaged. The catch, of course, is that step #2 needs to be finished first, temporarily increasing the / partition size until #1 is done. You have several options: * Disable /rescue. Define NO_RESCUE to suppress it from being built and installed, e.g., make -DNO_RESCUE buildworld make -DNO_RESCUE installworld Or add it to /etc/make.conf * Take the plunge and compile /bin dynamically. Define WITH_DYNAMICROOT in /etc/make.conf. * Get a bigger hard disk. ;-) Hope this helps, Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pcm exclusive sleep mutex with Oct19 CURRENT
On Mon, Oct 20, 2003 at 10:37:00AM -0700, Kris Kennaway wrote: Unfortunately none of the sound developers have been interested in looking at the locking problems in the code. =( acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195 Stack backtrace: with no backtrace at all. FWIW, the backtrace would have been reported on the system console. righty right kris, here we go: backtrace(c0836d0c,c2d41754,c0a257d1,c3,246) at backtrace+0x17 witness_lock(c2d347c0,8,c0a257d1,c3,c2d34500) at witness_lock+0x672 _mtx_lock_flags(c2d347c0,0,c0a257d1,c3,3) at _mtx_lock_flags+0xba pcm_chnalloc(c2d1f400,1,9e7c,,8) at pcm_chnalloc+0x56 dsp_open(c08f10f0,803,2000,c340d130,c06947a2) at dsp_open+0x19f spec_open(cf175a68,cf175b24,c069c6b2,cf175a68,0) at spec_open+0x30b spec_vnoperate(cf175a68,0,c08fe0e0,c340d130,c392b248) at spec_vnoperate+0x18 vn_open_cred(cf175bd8,cf175cd8,0,c3ef6880,20) at vn_open_cred+0x432 vn_open(cf175bd8,cf175cd8,0,20,c08f7b30) at vn_open+0x30 kern_open(c340d130,8ae2050,0,803,0) at kern_open+0x140 open(c340d130,cf175d10,c084f404,3ed,3) at open+0x30 syscall(1002f,893002f,bfbf002f,29a975b5,8ae2058) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5), eip = 0x2853ed3f, esp = 0xbfbfb4fc, ebp = 0xbfbfb518 --- and backtrace(c0836dc3,c102f110,c08497be,c08497be,c0849659) at backtrace+0x17 witness_lock(c102f110,8,c0849659,148,0) at witness_lock+0x672 _mtx_lock_flags(c102f110,0,c0849659,148,3) at _mtx_lock_flags+0xba _vm_map_lock(c102f0b0,c0849659,148,c08f5de0,2b4) at _vm_map_lock+0x36 kmem_malloc(c102f0b0,1000,101,ce70a810,c07996f7) at kmem_malloc+0x3a page_alloc(c103a3c0,1000,ce70a803,101,c083326a) at page_alloc+0x27 slab_zalloc(c103a3c0,1,8,c084afa2,68c) at slab_zalloc+0xb7 uma_zone_slab(c103a3c0,1,c084afa2,68c,0) at uma_zone_slab+0xe6 uma_zalloc_internal(c103a3c0,0,1,0,c101f470) at uma_zalloc_internal+0x3e bucket_alloc(44,1,c084afa2,70b,0) at bucket_alloc+0x5e uma_zfree_arg(c101f3c0,ce77ae04,0,778,0) at uma_zfree_arg+0x2c6 swp_pager_meta_free_all(c30e5cb8,c0848f76,c0848edb,21a) at swp_pager_meta_free_a ll+0xf2 swap_pager_dealloc(c30e5cb8,1,c084af06,104,0) at swap_pager_dealloc+0x11a vm_pager_deallocate(c30e5cb8,0,c084a0eb,260,c084afa2) at vm_pager_deallocate+0x3 d vm_object_terminate(c30e5cb8,0,c084a0eb,207,c062d650) at vm_object_terminate+0x2 03 vm_object_deallocate(c30e5cb8,c2ee8d98,c30e5cb8,c2ee8d98,ce70a9c8) at vm_object_ deallocate+0x371 vm_map_entry_delete(c16d59d8,c2ee8d98,c0849834,8b6,0) at vm_map_entry_delete+0x3 b vm_map_delete(c16d59d8,0,bfc0,c16d59d8,c16d59d8) at vm_map_delete+0x383 vm_map_remove(c16d59d8,0,bfc0,356,804f2c4) at vm_map_remove+0x55 exec_new_vmspace(ce70ab88,c08c7ac0,c0830c69,296,0) at exec_new_vmspace+0x235 exec_elf32_imgact(ce70ab88,0,c08318b5,ff,c08f77e8) at exec_elf32_imgact+0x1b0 kern_execve(c2d38980,8051080,bfbffd1c,804f2c0,0) at kern_execve+0x38c execve(c2d38980,ce70ad10,c084f404,3ed,3) at execve+0x30 syscall(2f,2f,2f,1,bfbffd1c) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (59), eip = 0x280d683f, esp = 0xbfbffd0c, ebp = 0xbfbffd38 --- hope this helps. -- Paolo Italian FreeBSD User Group: http://www.gufi.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PCVT in 5.1-CURRENT
Does FreeBSD 5.1-Current actually work with the PCVT driver. I've been unable to get any output to the console after the loader starts the kernel load with PCVT. If anyone's got a working configuration with PCVT I'd love to get a copy of their kernel configuration... I've moved up to 5.1-Current from 4.8-STABLE and I'm quite pleased with the performance and reliability on my rather low-end hardware, but I can't seem to get PCVT working. Bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 05:08:26PM +0200, Christian Brueffer wrote: On Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote: On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote: On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: On Mon, 20 Oct 2003, Vallo Kallaste wrote: VKHi VK VKIt seems to be a recent problem. The hardware is OK, both Windows XP VK(which I use very seldom) and Gentoo Linux do not exhibit any VKproblems. VKBasically one will get random signals as I have got in build- and VKinstallworld. It's impossible to complete make -j2 buildworld on my VKmachine, but sometimes non-parallel buildworld will do, only to die VKlater in installworld. VKThis is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and VK1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it VKmatters. I have the same MB just with 1800+ processors. I had to reduce the CPU frequency by about 10% in the BIOS setup to get the machine stable. I assume the problem is actually the memory. Couldn't the following be of help here? options DISABLE_PSE options DISABLE_PG_G I don't think so. I tried that on my A7M266D with no effect. I believe something in recent pmap code doesn't like this mobo, or maybe dual athlons in general. I can run RELENG_5_1 rock solid, and -current from 9/24/03 rock solid, but -current from 10/3 or later gets random sigs and eventually panics. I have scsi disks so it's not ata. I have the same experiences. Also AMD A7M-266D with two 1800+ Athlons here. Used to work fine, but got random signals with my latest builds. Here, too. However, on a Tyan Thunder K7 with MP 1200 and a Tyan Tiger MPX with MP 1600+. Additionally to random signals I also get ICEs from GCC at random places and freezes with `make -jX buildworld` but no panics. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCVT in 5.1-CURRENT
William Pechter wrote: Does FreeBSD 5.1-Current actually work with the PCVT driver. I've been unable to get any output to the console after the loader starts the kernel load with PCVT. If anyone's got a working configuration with PCVT I'd love to get a copy of their kernel configuration... I've moved up to 5.1-Current from 4.8-STABLE and I'm quite pleased with the performance and reliability on my rather low-end hardware, but I can't seem to get PCVT working. I have it working at FreeBSD bert.int.kts.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Oct 6 15:38:22 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BERT i386 as usual with no special tweaks (kernel config in private mail). hellmuth -- Hellmuth Michaelis Hamburg, Europe hm\at\kts\dot\org www.kts.org a duck is like a bicycle because they both have two wheels except the duck (tl) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
GEOM gbde broken?
Hi, i updated my -current box yesterday from cvs to FreeBSD 5.1-CURRENT #6: Sun Oct 19 17:40:10 CEST 2003. Now i'm not able to attach gbde encrypted filesystems - regardless if it's a disk image created with mdconfig, or a partition on harddisk. gdbe attach works without any error message, but when i try fsck the partition / disk it fails. I'm also not able to mount this thing. I moved the image files to another -current box (Sep 25 14:51:13 CEST 2003) and i was able to attach, fsck and mount the gdbe-disks. After gdbe attach it's possible to grep for cleartext data in /dev/$disk.bde but you're not able to fsck it: # /sbin/fsck -t ffs -p /dev/md0c.bde Cannot find file system superblock /dev/md0c.bde: CAN'T CHECK FILE SYSTEM. /dev/md0c.bde: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. /dev/md0c.bde: CANNOT SEEK BLK: -1 /dev/md0c.bde: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. # /sbin/fsck -t ffs /dev/md0c.bde ** /dev/md0c.bde Cannot find file system superblock ioctl (GCINFO): Inappropriate ioctl for device fsck_ffs: /dev/md0c.bde: can't read disk label And its also not possible to create a new gbde-device. After gdbe init and gbde attach of a newly created memory disk (-t vnode) i tried to newfs it and: # newfs -U -O2 /dev/md0c.bde /dev/md0c.bde: 4.8MB (9728 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 1.20MB, 77 blks, 192 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 2624, 5088, 7552 cg 0: bad magic number What's wrong? Greetings, Thorsten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM gbde broken?
Thorsten Schroeder wrote: Hi, i updated my -current box yesterday from cvs to FreeBSD 5.1-CURRENT #6: Sun Oct 19 17:40:10 CEST 2003. Now i'm not able to attach gbde encrypted filesystems - regardless if it's a disk image created with mdconfig, or a partition on harddisk. [...] update your sources again and everything should be fine. I think this was fixed yesterday. regards, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM gbde broken?
In message [EMAIL PROTECTED], Thorsten Schroeder writes: Hi, i updated my -current box yesterday from cvs to FreeBSD 5.1-CURRENT #6: Sun Oct 19 17:40:10 CEST 2003. Now i'm not able to attach gbde encrypted filesystems - regardless if it's a disk image created with mdconfig, or a partition on harddisk. There was a problem with an updated version of the kernels AES/Rijndael routines, this was fixed some hours later than you CVSup'ed yesterday. Pull in -current now, then it will work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/i386
TB --- 2003-10-20 18:12:23 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-10-20 18:12:23 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-10-20 18:12:23 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-10-20 18:14:50 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-10-20 19:11:06 - 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 Mon Oct 20 19:11:06 GMT 2003 Kernel build for GENERIC completed on Mon Oct 20 19:25:21 GMT 2003 TB --- 2003-10-20 19:25:21 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-10-20 19:25:21 - 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 Mon Oct 20 19:25:21 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/vm/vnode_pager.c uudecode /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/fla/i386/msysosak.o.uu uudecode /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/oltr/i386-elf.trlld.o.uu uudecode /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd/i386-elf.hal.o.uu cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/compat/linux/linux_file.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/compat/linux/linux_getcwd.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica
Re: acpi on fujitsu-siemens
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.LNKU._CRS] (Node 0xc40e49c0), AE_AML_UNINITIALIZED_LOCAL ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.LNKU._CRS] (Node 0xc40e49c0), AE_AML_UNINITIALIZED_LOCAL This means your AML is lousy. Try some of the hints on this page: http://www.cpqlinux.com/acpi-howto.html Please also post a link to your ASL, produced by: acpidump -t -d fujitsu.asl -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kuku@kukulies.org
Christoph P. Kukulies wrote: [ stuff removed ] You're missing the point of /rescue. It MUST be in / to be of any use. Yeah, but what do if the partition overflows? Plan ahead next time. Maybe take a backup, and remove redundancies or unnecessary files. You could simply resize your slices in a more appropriate way. Actually I never had the need for it in the past. What would be the correct use of /rescue? Yes that is likely. You don't normally use a fire hose until you have a fire to put out. Removing the /rescue is considered foot-shooting. The most cumbersome issue in the past was the ever growing root FS in FreeBSD. I wish back the days of a 40 MB root FS. Those conditions still exist. You could enable the WITH_DYNAMICROOT make.conf option to reduce the size of your root filesystem by approx 30Mb. Alternatively you could alter the fstab to mount your root area as read-only to prevent whatever it is you have done to exceed its capacity. One idea is to simply not login as root to do your stuff, which might involve activity that saves large files in your /root homedir area. Here is my root details with the dynamic binaries: buda# cd / buda# du -xhc -d1 512B./dev 4.0K./tmp 2.0K./usr 2.0K./var 2.4M./stand 1.5M./etc 2.0K./cdrom 940K./bin 17M./boot 2.0K./mnt 2.0K./proc 11M./root 4.1M./sbin 3.7M./rescue 3.1M./lib 262K./libexec 43M. 43Mtotal As you can see the /boot and /root areas are bulky. Regarding the /boot area, you could reduce the kernel modules to items you actually use with make.conf options, or simply make a suitable static monolith kernel and forget the idea of loadable kernel modules. Regarding the /root area, this just shows I've been a bad boy and shouldn't login as root so much. Is it possible to switch it off? Or to circumvent it somehow? You could alter the makefiles to provide a NO_RESCUE if that doesn't already exist. But I think the init program and/or the kernel would need to change so that /rescue/init isn't spawned in the situation of your corrupt /bin /sbin. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [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]
PC Card Ethernet attach fails in -CURRENT (FA410TX on ThinkPad 240X)
I happily installed 5.1 on this laptop over the network using my NETGEAR FA410TX PCMCIA card, but on updating to -CURRENT the attach fails. Verbose boots from both 5.1-RELEASE and -CURRENT are appended, but the vital difference is this: ed1: NETGEAR FA410TX at port 0x100-0x11f irq 11 function 0 config 32 on pccard0 -ed1: bpf attached -ed1: address 00:48:54:c0:99:7b, type Linksys (16 bit) -miibus0: MII bus on ed1 -ukphy0: Generic IEEE 802.3u media interface on miibus0 -ukphy0: OUI 0x080017, model 0x0002, rev. 0 -ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto +device_probe_and_attach: ed1 attach returned 6 The card had also been working happily with various 4.x releases. Any ideas? Cheers, Mark. 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-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc06d4000. Preloaded elf module /boot/kernel/acpi.ko at 0xc06d41f4. Calibrating clock(s) ... i8254 clock: 1193161 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 497838412 Hz Timecounter TSC frequency 497838412 Hz CPU: Intel Pentium III (497.84-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 201261056 (191 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x006fb000 - 0x0bc69fff, 190246912 bytes (46447 pages) avail memory = 188096512 (179 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6cf0 bios32: Entry = 0xfd8b0 (c00fd8b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd8b0+0x12f pnpbios: Found PnP BIOS data at 0xc00f6d20 pnpbios: Entry = f:ac81 Rev = 1.0 Other BIOS signatures found: wlan: 802.11 Link Layer null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71948086) pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00fdf60 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded07A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded07B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded07C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded07D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded0 10A 0x61 3 4 5 7 9 10 11 15 embedded0 11A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded0 12A 0x63 3 4 5 7 9 10 11 15 embedded00A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded00B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded00C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded00D 0x63 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 7 func 0 AcpiOsDerivePciId: bus 0 dev 10 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 4, width = 2 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter ACPI-fast frequency 3579545 Hz AcpiOsDerivePciId: bus 0 dev 0 func 0 can't fetch resources for \\_SB_.PCI0.ISA_.FIR_ - AE_AML_INVALID_RESOURCE_TYPE acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKD irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.3 \\_SB_.PCI0.ISA_.LNKB irq 11: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.10.0 \\_SB_.PCI0.ISA_.LNKC irq 5: [ 3 4 5 6 7 10 11 14 15] low,level,sharable 0.11.0 \\_SB_.PCI0.ISA_.LNKD irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.12.0 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.PCI0.ISA_.LNKD irq 11: [ 3 4 5 6 7 9 10 11 14 15] low,level,sharable 0.7.3 \\_SB_.PCI0.ISA_.LNKB irq 11:
Buildworld fails in 5.1-CURRENT in wall
Fails on usr.bin/wall as follows, cvsup'ed as of ~8pm EST: -- stage 2.1: cleaning up the object tree -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= .. .. .. === usr.bin/vi rm -f nex nvi cl_bsd.o cl_funcs.o cl_main.o cl_read.o cl_screen.o cl_term.o cut.o delete.o exf.o key.o line.o log.o main.o mark.o msg.o options.o options_f.o put.o screen.o search.o seq.o recover.o util.o ex.o ex_abbrev.o ex_append.o ex_args.o ex_argv.o ex_at.o ex_bang.o ex_cd.o ex_cmd.o ex_cscope.o ex_delete.o ex_display.o ex_edit.o ex_equal.o ex_file.o ex_filter.o ex_global.o ex_init.o ex_join.o ex_map.o ex_mark.o ex_mkexrc.o ex_move.o ex_open.o ex_preserve.o ex_print.o ex_put.o ex_quit.o ex_read.o ex_screen.o ex_script.o ex_set.o ex_shell.o ex_shift.o ex_source.o ex_stop.o ex_subst.o ex_tag.o ex_txt.o ex_undo.o ex_usage.o ex_util.o ex_version.o ex_visual.o ex_write.o ex_yank.o ex_z.o ex_tcl.o ex_perl.o getc.o v_at.o v_ch.o v_cmd.o v_delete.o v_ex.o v_increment.o v_init.o v_itxt.o v_left.o v_mark.o v_match.o v_paragraph.o v_put.o v_redraw.o v_replace.o v_right.o v_screen.o v_scroll.o v_search.o v_section.o v_sentence.o v_status.o v_txt.o v_ulcase.o v_undo.o v_util.o v_word.o v_xchar.o v_yank.o v_z.o v_zexit.o vi.o vs_line.o vs_msg.o vs_refresh.o vs_relative.o vs_smap.o vs_split.o vi.1.gz vi.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === usr.bin/vis rm -f vis vis.o foldit.o vis.1.gz vis.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === usr.bin/vmstat rm -f vmstat vmstat.o vmstat.8.gz vmstat.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === usr.bin/w rm -f w fmt.o pr_time.o proc_compare.o w.o w.1.gz uptime.1.gz w.1.cat.gz uptime.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === usr.bin/wall .depend, line 2: Need an operator .depend, line 4: Need an operator .depend, line 5: Need an operator .depend, line 6: Need an operator .depend, line 7: Need an operator .depend, line 8: Need an operator .depend, line 9: Need an operator .depend, line 10: Need an operator .depend, line 11: Need an operator .depend, line 12: Need an operator .depend, line 13: Need an operator .depend, line 14: Need an operator .depend, line 16: Need an operator .depend, line 17: Need an operator .depend, line 18: Need an operator .depend, line 19: Need an operator .depend, line 20: Need an operator .depend, line 22: Need an operator .depend, line 24: Need an operator .depend, line 27: Need an operator .depend, line 30: Need an operator .depend, line 32: Need an operator .depend, line 34: Need an operator .depend, line 36: Need an operator .depend, line 37: Need an operator .depend, line 38: Need an operator .depend, line 39: Need an operator .depend, line 40: Need an operator .depend, line 41: Need an operator .depend, line 42: Need an operator .depend, line 44: Need an operator .depend, line 45: Need an operator .depend, line 47: Need an operator .depend, line 49: Need an operator .depend, line 51: Need an operator .depend, line 53: Need an operator .depend, line 54: Need an operator .depend, line 55: Need an operator .depend, line 56: Need an operator .depend, line 57: Need an operator .depend, line 58: Need an operator .depend, line 59: Need an operator .depend, line 60: Need an operator .depend, line 61: Need an operator .depend, line 63: Need an operator .depend, line 65: Need an operator .depend, line 67: Need an operator .depend, line 70: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Script done on Mon Oct 20 17:54:49 2003 Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in NSS ?
From: Alex Deiter [EMAIL PROTECTED] I have a problem with nss_ldap on FreeBSD. After tranfer users from /etc/passwd to ldap directories my users cannot send a mail via /usr/bin/mail | /usr/sbin/sendmail program: What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file? Is pwcheck_method set to saslauthd, or sasldb? If it is set to saslauthd, what flags do you use for it (-a pam or -a ldap)? my /usr/local/lib/sasl2/Sendmail.conf: pwcheck_method: auxprop auxprop_plugin: sasldb Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8 system? How is saslauthd started on both systems (-a pam, -a sasldb, -a ldap)? Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
DVD+R burning flakey after ATAng.
First of all, as someone noted with disk-at-once, DVD+R (which is always disk-at-once) doesn't entirely burn properly. I havn't been able to nail it down, but certain ISO images work and certain ones don't. This all started screwing up with ATAng. At first, ATAng didn't support atapicam, but that was rectified. Now the dvd+rw port (growisofs) doesn't work at all ... it finishes with an error that I'm loathe to coaster another (expensive) DVD to find out. burncd will successfully burn some images and not others. I havn't found the pattern yet. Has anyone with knowledge in these areas looked at DVD burning? Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in NSS ?
From: Scot W. Hetzel [EMAIL PROTECTED] From: Alex Deiter [EMAIL PROTECTED] I have a problem with nss_ldap on FreeBSD. After tranfer users from /etc/passwd to ldap directories my users cannot send a mail via /usr/bin/mail | /usr/sbin/sendmail program: What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file? Is pwcheck_method set to saslauthd, or sasldb? If it is set to saslauthd, what flags do you use for it (-a pam or -a ldap)? my /usr/local/lib/sasl2/Sendmail.conf: pwcheck_method: auxprop auxprop_plugin: sasldb Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8 system? Does sasldblistusers2 on the Solaris 8 system list the test user in the sasldb file? If it does, is their a test user in the FreeBSD sasldb file? How is saslauthd started on both systems (-a pam, -a sasldb, -a ldap)? Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: panic with unloading nvidia.ko
Happens to me too :(. I've been trying to get that darn nvidia module to load in the latest current branch without hosing my system. I'm not sure what the magic formula is, but it was working before I recompiled the kernel for ipfilter support. Currently the nvidia module loads ok, but when I try to start X the system usually just hard locks up with a blank screen. On reboot, if I unload the nvidia module, another crash occurs. Where's that radeon card when you need it. -Jason -Original Message- From: C. Kukulies To: [EMAIL PROTECTED] Sent: 10/20/2003 4:12 AM Subject: panic with unloading nvidia.ko I just got a kernel panic after making /usr/ports/x11/nvidia-driver. I did a make, make reinstall. Then I did a kldunload nvidia.ko and got: nvidia0: detached panic: malloc(9)/free(9) confusion. Probably freeing with wrong type, but maybe not here. Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx, in_Debugger.0 trace shows: Debugger panic free os_free __nvsym00022 __nvsym00638 __nvsym00678 __nvsym00723 rm_shutdown_rm nvidia_modevent driver_module_handler module_unload linker_file_unload kld_unload syscall Xint0x80 -- Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
atapicam doesn't work anymore: WAS: DVD+R burning flakey after ATAng.
atapicam seems to have ceased being functional as well. Performing OPC... /usr/local/bin/cdrecord: Input/output error. send opc: scsi sendcmd: retryable error CDB: 54 01 00 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) David Gilbert wrote: First of all, as someone noted with disk-at-once, DVD+R (which is always disk-at-once) doesn't entirely burn properly. I havn't been able to nail it down, but certain ISO images work and certain ones don't. This all started screwing up with ATAng. At first, ATAng didn't support atapicam, but that was rectified. Now the dvd+rw port (growisofs) doesn't work at all ... it finishes with an error that I'm loathe to coaster another (expensive) DVD to find out. burncd will successfully burn some images and not others. I havn't found the pattern yet. Has anyone with knowledge in these areas looked at DVD burning? Dave. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Keyboard questions
On Mon, 20 Oct 2003, Peter wrote: I have been reading that page and I have the keyboard working, but I fail to see how this will help a user that only has a USB Keyboard that wants to use FreeBSD5.1 and is unable to install it due to the lack of USB support from the start. Some BIOSes offer a USB legacy support option which allows the use of a usb keyboard as if it were a PS2 keyboard during system startup. And I still would like to know if its my keyboard that is out of sync with the USB spec since it will add letters when I write like . This should read like this but can end up like Thisi should reaed likek this Does this keyboard exhibit the same behavior when it's plugged into a Windows machine? It's a little early to speculate what the issue could be, as there are a number of links in this chain but it's very possible that you simply have a wonky keyboard on your hands. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCcards not working (5.1)
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : On Thu, Oct 16, 2003 at 09:32:55AM -0600, M. Warner Losh wrote: : ... : : You should use devd instead of pccardd in -current. : : See devd(8) and devd.conf(8). : : That's one problem, but not the problem. The problem that he's : hitting is that he can't get memory to read the card's CIS. That's : usually solved with setting hw.cbb.start_memory to a good value. : : Hi Warner et al, : : What would be a good value? Some value than the amount of RAM you have. Make sure that no other devices on the bus conflict with it. I'm working on some changes to help prevent accidental multiple assignments that can happen with the current code, but haven't pulled it all together yet. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PC Card Ethernet attach fails in -CURRENT (FA410TX on ThinkPad 240X)
In message: [EMAIL PROTECTED] Mark Valentine [EMAIL PROTECTED] writes: : ed1: NETGEAR FA410TX at port 0x100-0x11f irq 11 function 0 config 32 on pccard0 : -ed1: bpf attached : -ed1: address 00:48:54:c0:99:7b, type Linksys (16 bit) : -miibus0: MII bus on ed1 : -ukphy0: Generic IEEE 802.3u media interface on miibus0 : -ukphy0: OUI 0x080017, model 0x0002, rev. 0 : -ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto : +device_probe_and_attach: ed1 attach returned 6 : : The card had also been working happily with various 4.x releases. : : Any ideas? it worked for me sometime before 5.1, but I had two people at bsdcon trip me about this. something weird has happened to the if_ed driver to screw this up. I'm not sure what it is :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1-CURRENT in wall
I'd remove all the .depend files and try again. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1-CURRENT in wall
M. Warner Losh wrote: I'd remove all the .depend files and try again. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] I've tried that one- I'm not familiar with freeBSD's build environment, but 'find /usr/src -name .depend shows the only .depend files are in the kernel tree /usr/src/sus/i386/compile/ , so I'm assuming it's generating them as part of the build process itself, or dumping them outside of the /usr/src heirarchy. Tried again from cvsup ~11pm with same results...any other ideas? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1-CURRENT in wall
In message: [EMAIL PROTECTED] Scott W [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : I'd remove all the .depend files and try again. : : Warner : ___ : [EMAIL PROTECTED] mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-current : To unsubscribe, send any mail to [EMAIL PROTECTED] : : : : I've tried that one- I'm not familiar with freeBSD's build environment, : but 'find /usr/src -name .depend shows the only .depend files are in : the kernel tree /usr/src/sus/i386/compile/ , so I'm assuming it's : generating them as part of the build process itself, or dumping them : outside of the /usr/src heirarchy. Tried again from cvsup ~11pm with : same results...any other ideas? find /usr/obj -name .depend or better yet rm -rf /usr/obj/* Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld fails in 5.1-CURRENT in wall
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott W [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : I'd remove all the .depend files and try again. : : Warner : ___ : [EMAIL PROTECTED] mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-current : To unsubscribe, send any mail to [EMAIL PROTECTED] : : : : I've tried that one- I'm not familiar with freeBSD's build environment, : but 'find /usr/src -name .depend shows the only .depend files are in : the kernel tree /usr/src/sus/i386/compile/ , so I'm assuming it's : generating them as part of the build process itself, or dumping them : outside of the /usr/src heirarchy. Tried again from cvsup ~11pm with : same results...any other ideas? find /usr/obj -name .depend or better yet rm -rf /usr/obj/* Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] D'oh! Got it, trying now.. thanks! :-) Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
