Crash upon exit from X
Hi
This is at least third crash I've had in the last months. It's
related to exiting from X, after switching back to text console,
there's usual message waiting for X server to shut down or
somesuch and then crash follows. Sources and kernel are from Dec 5
08:19 GMT. All ports are very recently rebuilt, including
XFree86-4.
Script started on Mon Dec 9 10:25:27 2002
bash-2.05b# gdb -k /usr/src/sys/i386/compile/Myhakas-5.0-SMP/kernel.debug /usr/
crash/vmcore.3
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02424e8
stack pointer = 0x10:0xd68b6c20
frame pointer = 0x10:0xd68b6c58
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 = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 2d19h32m5s
Dumping 511 MB
[CTRL-C to abort] [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224
240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc023f4da in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc023f797 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc0289562 in bwrite (bp=0xce598490) at ../../../kern/vfs_bio.c:796
#4 0xc0289c19 in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1085
#5 0xc03506af in ffs_fsync (ap=0xd68b6a20) at ../../../ufs/ffs/ffs_vnops.c:236
#6 0xc034f8f9 in ffs_sync (mp=0xc41b1e00, waitfor=2, cred=0xc1514e80,
td=0xc0440140) at vnode_if.h:612
#7 0xc029e80b in sync (td=0xc0440140, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#8 0xc023f0bb in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9 0xc023f797 in panic () at ../../../kern/kern_shutdown.c:517
#10 0xc03befb2 in trap_fatal (frame=0xd68b6be0, eva=0)
at ../../../i386/i386/trap.c:844
#11 0xc03bec62 in trap_pfault (frame=0xd68b6be0, usermode=0, eva=0)
at ../../../i386/i386/trap.c:758
#12 0xc03be752 in trap (frame=
{tf_fs = -1071579112, tf_es = -1003159536, tf_ds = -695533552, tf_edi =
-1000705576, tf_esi = 1, tf_ebp = -695505832, tf_isp = -695505908, tf_ebx = 0, tf_edx
= 0, tf_ecx = 8192, tf_eax = 8192, tf_trapno = 12, tf_err = 0, tf_eip = -1071373080,
tf_cs = 8, tf_eflags = 66054, tf_esp = -1000705332, tf_ss = 134217742}) at
../../../i386/i386/trap.c:445
#13 0xc03a7398 in calltrap () at {standard input}:99
#14 0xc024df7c in realitexpire (arg=0xc45a71d8)
at ../../../kern/kern_time.c:544
#15 0xc024e5d5 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#16 0xc022ca74 in ithread_loop (arg=0xc1516600)
at ../../../kern/kern_intr.c:535
#17 0xc022b934 in fork_exit (callout=0xc022c8a0 ithread_loop, arg=0x0,
---Type return to continue, or q return to quit---
frame=0x0) at ../../../kern/kern_fork.c:866
(kgdb) quit
bash-2.05b# exit
exit
Script done on Mon Dec 9 10:25:49 2002
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATACD issues slowly coming back...
On Sun, Dec 08, 2002 at 07:43:48PM -0700, Cliff L. Biffle wrote: On Sunday 08 December 2002 03:28 pm, Bruce Cran wrote: I've got a A7V-266E motherboard with a KT266A chipset. The solution in my case was to tell the BIOS I didn't have any ATAPI drives. FreeBSD then found everything properly, without any problems - I think the BIOS was maybe configuring the master for UDMA33 and the slave for PIO4, whereas FreeBSD seems to prefer them both as PIO4, That just about makes sense, with the weirdnesses I've seen with this mobo in the past. I'll give that a go and let y'all know what I find. I've got the ATACD on its own channel because I've hit issues in the past with having a DMA and PIO device on the same channel with this controller, but from reading my boot messages this morning my CD drive thinks it supports UDMA 33. Go fig. I should probably also sup the machine past DP2, but it's just been so wonderfully stable...I'm so used to using -stable that this feels like pushing my luck. :-) Your CD drive should indeed support UDMA33 - my DVD drive supports UDMA33, and my CDRW supports multi-word DMA, even though my BIOS only ever configures it for PIO4, and my DVD for UDMA33. FreeBSD only ever configures them for PIO during bootup, but, using the atacontrol program, it configures them both for maximum speed, even knowing they _can_ only do UDMA33,WDMA2. -- Bruce Cran To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATACD issues slowly coming back...
Bruce Cran wrote: Your CD drive should indeed support UDMA33 - my DVD drive supports UDMA33, and my CDRW supports multi-word DMA, even though my BIOS only ever configures it for PIO4, and my DVD for UDMA33. FreeBSD only ever configures them for PIO during bootup, but, using the atacontrol program, it configures them both for maximum speed, even knowing they _can_ only do UDMA33,WDMA2. If you have a look at sysctl hw.ata tree, it'll give you the clue on how to overcome this behaviuor. In simple words, what you need is to poot hw.ata.atapi_dma=1 in your /boot/loader.conf and have the nirvana of automatic DMA detection... -- /Voland Vadim Belman http://www.lflat.org http://www.lflat.net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sshd problem
Hi, Recently I've discovered that I cannot ssh to my box. After looking at the console, I found the following messages: Dec 9 10:09:05 nostromo kernel: pid 63040 (sshd), uid 0: exited on signal 11 Dec 9 10:09:05 nostromo sshd[63038]: fatal: buffer_put_cstring: s == NULL It seems to be a bug in sshd. I havent changed the default configs, except for /etc/ssh/known_hosts. Is anybody getting the same problem? My `uname -a`: FreeBSD nostromo.astral.ntu-kpi.kiev.ua 5.0-RC FreeBSD 5.0-RC #1: Sat Dec 7 14:56:05 EET 2002 [EMAIL PROTECTED]: /usr/obj/usr/src/sys/NOSTROMO i386 sv -- [LPML-2001] [KPI-PMA] [FreeBSD] [NIN] * GPG fingerprint: 7175 B841 C13D 9FE6 BDE0 C5E3 1652 7026 0A30 1CED Mail me with subject GPG-GETKEY to get my public key. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATACD issues slowly coming back...
It seems Vadim Belman wrote: Bruce Cran wrote: Your CD drive should indeed support UDMA33 - my DVD drive supports UDMA33, and my CDRW supports multi-word DMA, even though my BIOS only ever configures it for PIO4, and my DVD for UDMA33. FreeBSD only ever configures them for PIO during bootup, but, using the atacontrol program, it configures them both for maximum speed, even knowing they _can_ only do UDMA33,WDMA2. If you have a look at sysctl hw.ata tree, it'll give you the clue on how to overcome this behaviuor. In simple words, what you need is to poot hw.ata.atapi_dma=1 in your /boot/loader.conf and have the nirvana of automatic DMA detection... And remember the warning that it does not always work as expected, ATAPI DMA is a many headed monster... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI missfucntioning on SONY VAIO Z505s with CURRENT (RC)
Hi Please help. I have already filled http://www.freebsd.org/cgi/query-pr.cgi?pr=45913 Lucent WaveLan Orinoco card (driver wi) stops working with latest current (last I have tried RC) Playing with problem I have found that WaveLan problem can be cured by turning off ACPI. Also another problem cured - with turned off ACPI I can insert and remove PCCARDs while notebook running, card successful detected. With ACPI turned on insertion/removal of PCCARD freezes machine completely. Can I help to diagnose problem ? how ? -- Vladimir B. Grebenschikov [EMAIL PROTECTED] SWsoft Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for testers: acpica-unix-20021122 (was Re: ACPI errors and then panic - fixed!)
On Thu, 28 Nov 2002 13:38:13 +0900 (JST), Mitsuru IWASAKI [EMAIL PROTECTED] said: Mitsuru The patches against today's CURRENT at: Mitsuru http://people.freebsd.org/~iwasaki/acpi/acpica-20021118-20021122-test20021128.diff Mitsuru Please try this if you have problems about ACPI interpreter or GPE Mitsuru initialization. Hi Iwasaki-San, Apologies for the delayed response as I was offline. I installed the above patch, but with no considerable change. I am still having problems with ACPI on my IBM A31p TP. Right now, I am using the world and kernel from 7th December. Is there a patch against the latest cvs ? These are the errors I get acpi0: IBMTP-1Gon motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST and this error I get when I try to suspend the TP. acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND But then, the TP shuts down properly with ACPI if I poweroff with the button. Anything else I am missing ? TIA Regards Sid -- You can't carve your way to success without cutting remarks. Sid Carter - http://khader.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: getnewvnode: free vnode isn't
I just got this on one of my alpha package machines: panic: getnewvnode: free vnode isn't db trace Debugger() at Debugger+0x34 panic() at panic+0x124 getnewvnode() at getnewvnode+0x434 ffs_vget() at ffs_vget+0xa8 ufs_lookup() at ufs_lookup+0xd68 ufs_vnoperate() at ufs_vnoperate+0x2c vfs_cache_lookup() at vfs_cache_lookup+0x398 ufs_vnoperate() at ufs_vnoperate+0x2c lookup() at lookup+0x4cc namei() at namei+0x300 lstat() at lstat+0x50 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (190, FreeBSD ELF64, lstat) --- --- user mode --- msg48404/pgp0.pgp Description: PGP signature
Re: Xircom realport rem56g problems
Hi, I just built fresh -current (NEWCARD) but it didn't work. I'm beginning to suspect that we have different cards, since the dc driver won't recognize mine. The dc driver seems to expect that vendor id is 0x115d and device id 0x0003. On my card the vendor id is 0x0105 and device id is 0x110a. On the back of the card is says realport ethernet 10/100+modem 56 and REM56G-100. Ari S. On Wednesday 04 December 2002 19:35, Sam Leffler wrote: On Tuesday 03 December 2002 18:38, Sam Leffler wrote: Try the dc driver instead of xe. I have the same card and it worked once I added the cardbus glop to read the MAC address from the CIS. I was going to use NEWCARD kernel, is it possible to use another driver with it ? I use NEWCARD and the dc driver. device miibus # MII bus support device dc # Xircom cardbus ethernet device ep # Etherlink III based cards device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. My fix to read the MAC from the CIS was committed last week so you need up to date source. Or do I have to go back to oldcard with pccardd where I can specify the driver in pccardd.conf ? No oldcard and no pccardd. I setup devd to handle card insert/remove. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RC NG, ntp and routed
I suggest that routed be specified as being BEFORE ntpd. In the absence of a route to the specified servers, ntpd has the annoying behavior of chosing the address of lo0 as the source address for ntp requests, resulting in all sorts of problems. This wouldn't happen in configurations with defaultrouter, but for those depending on dynamic routing... Of course, most dynamic routing protocols require a certain time before it goes to a stable state and install the externally received routes, but _that_ I solved with a sleep in the zebractl script (zebra being the router I use). I do see one contraindication to this behavior. Most routing protocols also react badly to time changes. Egg and chicken problem, but, personally, and running OSPF, which is one of those protocols that react badly to time changes, I find it preferably to run the router first. After all, having ntpd using 127.0.0.1 as source is useless to me. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Q: How did you get into artificial intelligence? A: Seemed logical -- I didn't have any real intelligence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD Port: fluxbox-0.1.13
Build breaks if supplied with -DWITH_REMEMBER gmake[3]: Nothing to be done for `all-am'. gmake[3]: Leaving directory `/usr/ports/x11-wm/fluxbox/work/fluxbox-0.1.13/ gmake[2]: Leaving directory `/usr/ports/x11-wm/fluxbox/work/fluxbox-0.1.13/ Making all in src gmake[2]: Entering directory `/usr/ports/x11-wm/fluxbox/work/fluxbox-0.1.13 cd .. \ false --gnu src/Makefile gmake[2]: *** [Makefile.in] Error 1 gmake[2]: Leaving directory `/usr/ports/x11-wm/fluxbox/work/fluxbox-0.1.13/ gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11-wm/fluxbox/work/fluxbox-0.1.13' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/x11-wm/fluxbox. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Port: fluxbox-0.1.13
I've adviced the maintainer a week ago, but he said that he has not encuntered the problem. A little workaround: # make AUTOMAKE=automake14 (or what's your automake's binary name) Bye, Dario msg48408/pgp0.pgp Description: PGP signature
Confused by mpd and ipnat
I run -current and decided to try kernel PPPoE. I installed mpd from ports which ran fine. After installing ipnat, I setup the following rule in ipnat.rules: map ng0 192.168.0.0/24 - 0/32 When I reboot, this line (along with ipnat stuff) got executed before mpd fiinishes PPPoE negotiation, and ipnat -l shows that the ng0 ip was 0.0.0.0/32. Is there anyway I can ensure that ipnat -f /etc/ipnat.rules get executed only after mpd has obtained proper ip settings? Thank you, JY To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Confused by mpd and ipnat
Hi, leafy schrieb: I run -current and decided to try kernel PPPoE. I installed mpd from ports which ran fine. After installing ipnat, I setup the following rule in ipnat.rules: map ng0 192.168.0.0/24 - 0/32 When I reboot, this line (along with ipnat stuff) got executed before mpd fiinishes PPPoE negotiation, and ipnat -l shows that the ng0 ip was 0.0.0.0/32. Is there anyway I can ensure that ipnat -f /etc/ipnat.rules get executed only after mpd has obtained proper ip settings? You can set this rule in an iface up-script: set iface up-script script set iface down-script script bye, -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd problem
Vasyl S. Smirnov wrote: Hi, Recently I've discovered that I cannot ssh to my box. After looking at the console, I found the following messages: Dec 9 10:09:05 nostromo kernel: pid 63040 (sshd), uid 0: exited on signal 11 Dec 9 10:09:05 nostromo sshd[63038]: fatal: buffer_put_cstring: s == NULL It seems to be a bug in sshd. I havent changed the default configs, except for /etc/ssh/known_hosts. Is anybody getting the same problem? My `uname -a`: FreeBSD nostromo.astral.ntu-kpi.kiev.ua 5.0-RC FreeBSD 5.0-RC #1: Sat Dec 7 14:56:05 EET 2002 [EMAIL PROTECTED]: /usr/obj/usr/src/sys/NOSTROMO i386 sv Can you check the core dump for backtrace and send that? Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstra?e 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI missfucntioning on SONY VAIO Z505s with CURRENT (RC)
On Monday 09 December 2002 11:55, Vladimir B. Grebenschikov wrote: Also another problem cured - with turned off ACPI I can insert and remove PCCARDs while notebook running, card successful detected. With ACPI turned on insertion/removal of PCCARD freezes machine completely. I have a similar problem; I can enable ACPI on my laptop (Fujitsu Lifebook C6175), but it'll only boot when there isn't any PC Card inserted. When my CompactFlash card w/ CompactFlash PCMCIA adapter is inserted, it crashes at boot. It works fine when I insert it after the machine has booted. Can I help to diagnose problem ? how ? Arjan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sys/file.h and POSIX
In message: [EMAIL PROTECTED] Marc Recht [EMAIL PROTECTED] writes: : Why are you specifying a standard and then using features outside its : scope? Either you want a BSD environment (in which case don't specify : The standard is specified to get the standard functions. Eg. if i specify : _POSIX_C_SOURCE=200112L then I want (for example) POSIX's flockfile, if the : OS supports POSIX. This doesn't mean that I don't want rpc. Actually, yes it does. When you specify a standard, you exclude all things not in that standard. It is a crap shoot if they work. At least that's how these _*_SOURCE macros have worked on all other systems that I've used. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sys/file.h and POSIX
In message: [EMAIL PROTECTED] Marc Recht [EMAIL PROTECTED] writes: : A conforming application cannot make use of facilities outside the : scope of the standard. This means that if you define : _POSIX_C_SOURCE=200112L you don't want RPC. : I don't said that the application is _strictly_ POSIX conforming. It only : wants to use POSIX functions and RPC. : FreeBSD's way seems to be not to define POSIX/XSI (and so) on to : _indirectly_ get it and the BSD stuff That's right. We take great care to exclude all namespace pollution when you ask for a specific standard. : Another idea would be to make a WANT_STRICT_POSIX. WANT_STRICT_POSIX is namespace pollution. : Not really. Conforming applications have no trouble (obviously), : pseudo-conforming applications only need a little work (removing bogus : POSIX keywords that specify conformance), and non-conforming BSD : applications (the majority of software) have no problems. : I had this in mind. : http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html: : : A conforming implementation shall meet all of the following criteria: : [...] : 4. The system may provide additional utilities, functions, or facilities : not required by IEEE Std 1003.1-2001. may != MUST. We do not pollute the name space. Providing additional facilities pollutes the name space, breaking strictly conforming programs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xircom realport rem56g problems
I just built fresh -current (NEWCARD) but it didn't work. I'm beginning to suspect that we have different cards, since the dc driver won't recognize mine. The dc driver seems to expect that vendor id is 0x115d and device id 0x0003. On my card the vendor id is 0x0105 and device id is 0x110a. On the back of the card is says realport ethernet 10/100+modem 56 and REM56G-100. You're correct, I have the RBEM56G-100 and it has vendor id 0x115d. Sorry. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc(4) problems
Andy, I'm aware of this problem and have it on my list of things to try to get fixed for 5.0. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: nVidia drivers revisited
On 08-Dec-2002 Peter Kostouros wrote: Hi My system was dumping core when I tried to invoke X with the recently released nVidia drivers installed (similar to Kris's problem?). Upon creating a kernel without INVARIANTS and INVARIANT_SUPPORT options, X runs well. My question is, of the X/nVidia success stories, were kernels built with or without INVARIANTS and INVARIANT_SUPPORT options? For those interested, the panics I received were: mutex vm page queue mutex not owned at .../usr/src/sys/vm/vm_page.c:1215. The source was from about 23/11. This just means the nvidia driver is buggy and could result in corrupted data and kernel crashes eventually. However, the driver is only buggy on 5.0 because 5.0 has different locking requirements than 4.x and the driver was written for 4.x. Thus, it's not nvidia's fault per se, but the driver does need updating before it will be safe on 5.x. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Do any of the 1.4.x jdks work reasonably well?
On 2002-12-07-15-29-55 James Satterfield wrote: I've tried the sun and blackdown jdk14 ports on -stable and had no success in running even the demos that come with the jdk. Is this a just me problem or do those jdks just not work? what errors did you get? if you are running the demos as user, and have linux_base-7 installed, try running the demos as root, or switch to linux_base-6 user + linux_base-7 + linux-jdk == core dump (at least for me) this patch works for me: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/40611 msg48418/pgp0.pgp Description: PGP signature
Re: backgroud fsck is still locking up system (fwd)
On Fri, Dec 06, 2002 at 05:52:38PM -0800, Kirk McKusick wrote:
Adding a two minute delay before starting background fsck
sounds like a very good idea to me. Please send me your
suggested change.
Here it is. As written it doesn't add the delay, but you can change
etc/defaults/rc.conf to do that it desired.
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
Index: etc/rc
===
RCS file: /usr/cvs/src/etc/rc,v
retrieving revision 1.323
diff -u -p -r1.323 rc
--- etc/rc 26 Nov 2002 17:51:03 - 1.323
+++ etc/rc 4 Dec 2002 23:08:41 -
@@ -982,8 +982,14 @@ esac
# Start background fsck checks if necessary
case ${background_fsck} in
[Yy][Ee][Ss])
- echo 'Starting background filesystem checks'
- nice -4 fsck -B -p 21 | logger -p daemon.notice
+ bgfsck_msg='Starting background file system checks'
+ if [ ${background_fsck_delay:=0} -gt 0 ]; then
+ bgfsck_msg=${bgfsck_msg} in ${background_fsck_delay} seconds
+ fi
+ echo ${bgfsck_msg}.
+
+ (sleep ${background_fsck_delay}; nice -4 fsck -B -p) 21 | \
+ logger -p daemon.notice
;;
esac
Index: etc/defaults/rc.conf
===
RCS file: /usr/cvs/src/etc/defaults/rc.conf,v
retrieving revision 1.164
diff -u -p -r1.164 rc.conf
--- etc/defaults/rc.conf6 Dec 2002 05:23:37 - 1.164
+++ etc/defaults/rc.conf6 Dec 2002 18:02:18 -
@@ -40,6 +40,7 @@ script_name_sep=# Change if your sta
rc_conf_files=/etc/rc.conf /etc/rc.conf.local
fsck_y_enable=NO # Set to YES to do fsck -y if the initial preen fails.
background_fsck=YES # Attempt to run fsck in the background where possible.
+background_fsck_delay=0 # Time to wait (seconds) before starting the fsck.
extra_netfs_types=NO # List of network extra filesystem types for delayed
# mount at startup (or NO).
Index: etc/rc.d/bgfsck
===
RCS file: /usr/cvs/src/etc/rc.d/bgfsck,v
retrieving revision 1.2
diff -u -p -r1.2 bgfsck
--- etc/rc.d/bgfsck 28 Jul 2002 03:38:10 - 1.2
+++ etc/rc.d/bgfsck 9 Oct 2002 23:31:45 -
@@ -11,9 +11,20 @@
name=background-fsck
rcvar=background_fsck
-start_precmd=echo 'Starting background file system checks.'
-start_cmd=nice -4 fsck -B -p 21 | logger -p daemon.notice
+start_cmd=bgfsck_start
stop_cmd=:
+
+bgfsck_start ()
+{
+ bgfsck_msg='Starting background file system checks'
+ if [ ${background_fsck_delay:=0} -gt 0 ]; then
+ bgfsck_msg=${bgfsck_msg} in ${background_fsck_delay} seconds
+ fi
+ echo ${bgfsck_msg}.
+
+ (sleep ${background_fsck_delay}; nice -4 fsck -B -p) 21 | \
+ logger -p daemon.notice
+}
load_rc_config $name
run_rc_command $1
Index: share/man/man5/rc.conf.5
===
RCS file: /usr/cvs/src/share/man/man5/rc.conf.5,v
retrieving revision 1.166
diff -u -p -r1.166 rc.conf.5
--- share/man/man5/rc.conf.529 Nov 2002 11:39:19 - 1.166
+++ share/man/man5/rc.conf.54 Dec 2002 23:11:53 -
@@ -734,6 +734,11 @@ If set to
the system will attempt to run
.Xr fsck 8
in the background where possible.
+.It Va background_fsck_delay
+.Pq Vt int
+The amount of time in seconds to sleep before starting a background fsck.
+Setting this to a non-zero number may allow large applications such as
+the X server to start before disk I/O bandwidth is monopolized by fsck.
.It Va extra_netfs_types
.Pq Vt str
If set to something other than
msg48419/pgp0.pgp
Description: PGP signature
RE: panic in ithread_loop()
On 08-Dec-2002 Dag-Erling Smorgrav wrote:
This is 100% reproducible with a top-of-tree kernel, but didn't happen
with Wednesday's sources:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc01e8d
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc045dc80
stack pointer = 0x10:0xd536dce4
frame pointer = 0x10:0xd536dd00
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 = 12 (swi6: tty:sio clock)
kernel: type 12 trap, code=0
Stopped at 0xc045dc80: movb%al,0xc01e8d
db trace
_end(0) at 0xc045dc80
ithread_loop(c152ab00,d536dd48,c1537b60,c01d3d80,0) at ithread_loop+0x11c
fork_exit(c01d3d80,c152ab00,d536dd48) at fork_exit+0x8f
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd536dd7c, ebp = 0 ---
and according to gdb:
(gdb) list _end
No line number known for _end.
(gdb) list *0xc045dc80
No source file for address 0xc045dc80.
This is where it faulted for some reason or another. It was running
a registered interrupt handler. Do you have any kernel modules in this
system?
(gdb) l *(ithread_loop + 0x11c)
0xc01d3e9c is in ithread_loop (../../../kern/kern_intr.c:536).
531 goto restart;
532 }
533 if ((ih-ih_flags IH_MPSAFE) == 0)
534 mtx_lock(Giant);
535 ih-ih_handler(ih-ih_argument);
536 if ((ih-ih_flags IH_MPSAFE) == 0)
537 mtx_unlock(Giant);
538 }
539 }
540
(gdb) l *(fork_exit+0x8f)
0xc01d326f is in fork_exit (../../../kern/kern_fork.c:872).
867
868 /*
869 * Check if a kernel thread misbehaved and returned from its main
870 * function.
871 */
872 PROC_LOCK(p);
873 if (p-p_flag P_KTHREAD) {
874 PROC_UNLOCK(p);
875 mtx_lock(Giant);
876 printf(Kernel thread \%s\ (pid %d) exited prematurely.\n,
(gdb) l *(fork_trampoline+0x1a)
0xc02db94e is at {standard input}:152.
147 {standard input}: No such file or directory.
in {standard input}
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Xircom realport rem56g problems
From: Sam Leffler [EMAIL PROTECTED] Date: Mon, 9 Dec 2002 09:35:08 -0800 Sender: [EMAIL PROTECTED] I just built fresh -current (NEWCARD) but it didn't work. I'm beginning to suspect that we have different cards, since the dc driver won't recognize mine. The dc driver seems to expect that vendor id is 0x115d and device id 0x0003. On my card the vendor id is 0x0105 and device id is 0x110a. On the back of the card is says realport ethernet 10/100+modem 56 and REM56G-100. You're correct, I have the RBEM56G-100 and it has vendor id 0x115d. Sorry. For the record, the REM56G-100 is a 16-bit card while the RBEM56G-100 is a 32-bit CardBus card with similar functionality (100 Mbps Ethernet and 56 Kbps modem). R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem with nvidia drivers and current
For some reason i can't get the nvidia drivers working with my system (had them working under 4.7-STABLE, but they refuse to wrok with 5.0-RC). Last synced with current this weekend, and nothing worthwile has been added last time i checked. Now the problem is that when I start x, everything seems normal, idesk waimea pop up, but as soon as i open an application (xchat, gaim, eterm, ...) the system locks up, requiring a hard reset. Works fine with the nv driver, but opengl performance is a bit uhm... sub par. Anyone able to give me a few ideas? Here are a few things that might help: This is all on a 1ghz athlon with a VIA 133a based motherboard (abit kt7a-raid) dmesg | grep nvidia: Preloaded elf module /boot/kernel/nvidia.ko at 0xc05f01a4. nvidia0: GeForce2 MX/MX 400 mem 0xe000-0xe7ff,0xec00- 0xecff irq 5 at device 0.0 on pci1 dmesg | grep agp: agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xe800- 0xebff at device 0.0 on pci0 kernel has as much as possible removed (splash and all are removed). make.conf: ... CPUTYPE=i686 CFLAGS= -O2 -pipe CXXFLAGS+= -fmemoize-lookups -fsave-memoized ... and a part of my XF86Config: Section Module Load dbe Load dri Load extmod Load glx Load pex5 Load record Load xie Load xtrap Load speedo Load type1 Load freetype EndSection Section Device Identifier Card0 Driver nvidia VendorName NVidia BoardName GeForce2 MX/MX 400 BusID PCI:1:0:0 EndSection I tried alot already (all things in a FAQ i found somewere, but it stays unstable/unusable), any hints are welcome, as this REALLY anoying me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd problem
On Mon, Dec 09, 2002 at 05:49:31PM +0100, Jens Rehsack wrote: Can you check the core dump for backtrace and send that? I doesn't generate a coredump. Any way to enforce it? I've just tried Protocol version 1, and everything was perfect. I'll try to figure out which part of sshd is generating the error. sv -- [LPML-2001] [KPI-PMA] [FreeBSD] [NIN] * GPG fingerprint: 7175 B841 C13D 9FE6 BDE0 C5E3 1652 7026 0A30 1CED Mail me with subject GPG-GETKEY to get my public key. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sys/file.h and POSIX
may != MUST. We do not pollute the name space. Providing additional facilities pollutes the name space, breaking strictly conforming programs. Hmm, I can't see why a __EXTENSIONS__ (like Solaris has) would break posix confirming programms. But, it would help for eg. autoconf third-party apps which set POSIX_C_SOURCE. Instead of changing other peoples code, I just could do: setenv CFLAGS -D__EXTENSIONS__=1 ./configure It would be only a little change to sys/cdefs.h and wouldn't break anything. Regards, Marc Premature optimization is the root of all evil. -- Donald E. Knuth msg48424/pgp0.pgp Description: PGP signature
Re: sshd problem
On Mon, Dec 09, 2002 at 09:30:32PM +0200, Vasyl S. Smirnov wrote: On Mon, Dec 09, 2002 at 05:49:31PM +0100, Jens Rehsack wrote: Can you check the core dump for backtrace and send that? I doesn't generate a coredump. Any way to enforce it? sysctl kern.sugid_coredump=1 sysctl kern.corefile=/tmp/%N.core (or somewhere else writable by an unprivileged user) Kris msg48425/pgp0.pgp Description: PGP signature
perl wrapper removal broke ports
Just a heads up that the removal of the perl wrapper broke a number of ports. Exactly how many I don't yet know, but they mostly appear to be using the existence of the /usr/bin/perl file as a check for whether perl support is desired. Some of them are failing during configure but don't appear to actually require perl for the build (i.e. they were building fine with the wrapper but without the perl package installed, suggesting they don't actually invoke perl). http://bento.freebsd.org/errorlogs/5-latest/cvsd-0.9.14.log http://bento.freebsd.org/errorlogs/5-latest/ruboard-1.2.1_1.log http://bento.freebsd.org/errorlogs/5-latest/autoconf213-2.13.000227_5.log These will shortly be moving to the 5-full directory (edit URL accordingly). Kris msg48426/pgp0.pgp Description: PGP signature
Re: pcm0:play:0: play interrupt timeout, channel dead
Try to dig in BIOS settings and set IRQ 5 (and DRQ 1 if such tuning possible) to ISA manually. Form a -CURRENT of yesterday: flag@newluxor$ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: SB16 DSP 4.16 (ViBRA16X) at io 0x220 irq 5 drq 1 bufsz 4096d (1p/1r/0v c hannels duplex default) flag@newluxor$ but when i try to play any song i get this msg: cm0:play:0: play interrupt timeout, channel dead any idea? mine is a sb16-vibra isa working flawless with any othe os thanks - -- Paolo Italian FreeBSD User Group: http://www.gufi.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound familiar? 5.0-RC hangs on dual athlon
Jacques A. Vidrine cc current@ I have an ASUS P2L97-DS ACPI BIOS Revision 1008 Dual cpu box FreeBSD 5.0-DP2 #0: Wed Dec 4 00:26:02 CET 2002 CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) Origin = GenuineIntel Id = 0x650 Stepping = 0 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP, MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 536858624 (511 MB) avail memory = 514600960 (490 MB) I also experienced unusable instability with 5.0-DP2 DUAL CPU kernel. it crashed with lots of different stack traces, so I didnt chase/report (lack of time, (I migh have found time if it was one thing consiustently, but no time for a variety)) Easiest way to get it to crash in minutes was do several jobs at once, EG cd /usr/src ; make -j 10 Without the j 10 it reduced to `just' a handful of crashes during make. I dropped back to a generic single CPU kernel. ( Which cancelled main reason I moved to 5.0-DP2: to get ATA bus working with dual, see my Nov. 22 Subject: 5.0-DP2: SMP+ATA OK. But 4.7 stable boot panic with ASUS P2L97-DS To: freebsd-current@ ) I'm down loading 5.0-RC1-i386-disc1.iso Julian Stacey jhs @ berklix.com Computer Systems Engineer, Unix Net Consultant, Munich. Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. Munich BSD Conference:http://berklix.org/conf/ Spam phrases triggering deletion: http://berklix.com/jhs/mail/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd problem
On Mon, Dec 09, 2002 at 11:11:28AM +0200, Vasyl S. Smirnov wrote: [...] Dec 9 10:09:05 nostromo kernel: pid 63040 (sshd), uid 0: exited on signal 11 Dec 9 10:09:05 nostromo sshd[63038]: fatal: buffer_put_cstring: s == NULL [...] Some info I didn't mention in the first post: The process of logging is goes fine until the correct password is supplied. I.e. I run ssh, get the Password: prompt; if I enter wrong password, the prompt appears again; after correct password it just drops: Connection closed by a.b.c.d sv -- [LPML-2001] [KPI-PMA] [FreeBSD] [NIN] * GPG fingerprint: 7175 B841 C13D 9FE6 BDE0 C5E3 1652 7026 0A30 1CED Mail me with subject GPG-GETKEY to get my public key. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sys/file.h and POSIX
On Mon, 09 Dec 2002 10:26:49 -0700 (MST), M. Warner Losh [EMAIL PROTECTED] said: may != MUST. We do not pollute the name space. Providing additional facilities pollutes the name space, breaking strictly conforming programs. Not necessarily. The Standard reserves certain namespaces for the implementation's use. However, none of the examples people are complaining about are subject to such reservations. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HELP: vinum and newfs on 5.0-RC1
Okay, I had a vinum RAID5 set working on 4.7. Since I didn't have any data on it yet and saw today's announcement of 5.0-RC1, I thought I'd give 5.0-RC1 a try on the box in question. Vinum sees the RAID5 set I created just fine, so I decided to use newfs to create a UFS2 filesystem on the volume. Call me an idiot, but I can't seem to figure out how to do this despite searching various FreeBSD mailing lists. It appears 5.0 no longer supports the -v option, so I assume vinum support is now built-in. Here's what I'm trying: # newfs -O 2 -U /dev/vinum/raid5vol newfs: /dev/vinum/raid5vol: 'e' partition is unavailable That's funny. After reading around a bit, I wondered if perhaps some sort of disk label is now required on the vinum volume. However, no matter how I try using disklabel, disklabel complains about my attempts. Here's my vinum setup: drive d0 device /dev/ad0s1f drive d1 device /dev/ad1s1f drive d2 device /dev/ad2s1f drive d3 device /dev/ad3s1f volume raid5vol plex name p5 org raid5 512s vol raid5vol sd name sd0 drive d0 plex p5 len 232798208s driveoffset 265s plexoffset 0s sd name sd1 drive d1 plex p5 len 232798208s driveoffset 265s plexoffset 512s sd name sd2 drive d2 plex p5 len 232798208s driveoffset 265s plexoffset 1024s sd name sd3 drive d3 plex p5 len 232798208s driveoffset 265s plexoffset 1536s DEVFS shows: /dev/vinum: control controld plex: p5 sd: sd0 sd1 sd2 sd3 raid5vol Disklabel /dev/vinum/raid5vol shows me: type: Vinum disk: vinum label: radi flags: bytes/sector: 512 sectors/track: 698394624 tracks/cylinder: 1 sectors/cylinder: 698394624 cylinders: 1 sectors/unit: 689394624 rpm: 14400 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 Partitions: #size offsetfstype [fsize bsize bps/cpg] a: 69839462404.2BSD 1024 8192 0 # (Cyl. 0 - 0) b: 6983946240 swap # (Cyl. 0 - 0) c: 6983946240unused0 0# (Cyl. 0 - 0) I tried editing it, setting a: to unused, size 0, removing b:, and creating e: just like a: as above. Of course disklabel complained about a zero size, so I completely removed a:, then disklabel complained about e: being out of range a-c, so I renamed e: as a: and it seemed happy. At least until I double checked the data and a subsequent disklabel call showed that all my changes had been silently discarded and the above showd up anew. The vinum label command also appears useless, happily executing but changing nothing. Now for the questions: How does one create a new filesystem (UFS2 in particular) on a vinum volume in 5.0? Is some sort of label required? Help! Thanks! Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 2nd ether device wont config
Dhee Reddy wrote: FWIW. i have a similar setup except that the fxp is replaced by rl. All i did wa s to change ifconfig_ed1 to ifconfig_ed0 in rc.conf. for some strange reason, when i installed(sysinstall), the ed card was detected as ed1 and not as ed0 but on subsequent boots (after i changed rc.conf) its running smooth as before. Thanks, I tried it, didnt work though, I too saw some ed0 ed1 confusuion on that box, but I think it was on 4.7, I'm downloading 5.0-RC now. Julian Stacey jhs @ berklix.com Computer Systems Engineer, Unix Net Consultant, Munich. Ihr Rauchen = mein allergischer Kopfschmerz ! Schnupftabak probieren. Munich BSD Conference:http://berklix.org/conf/ Spam phrases triggering deletion: http://berklix.com/jhs/mail/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RC1 sysinstall hang
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Having tried 5.0-DP1 before on a certain box (see below for dmesg), I tried booting a 5.0-RC1 CD on it. However, sysinstall always hangs at probing devices, although it reacts to ^C. Restarting it doesn't really help, though, it simply hangs again. I've let it run for 30 minutes, but still nothing. With -DP1, sysinstall had no problems, and that version is still running on the box, giving the following dmesg: == Copyright (c) 1992-2002 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.0-DP1 #0: Sun Apr 7 02:51:42 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc053e000. Preloaded elf module /boot/kernel/acpi.ko at 0xc053e0a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 451024348 Hz CPU: Pentium III/Pentium III Xeon/Celeron (451.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268423168 (262132K bytes) avail memory = 255545344 (249556K bytes) Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00f0d10 npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P2B-LS on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 2, max = 4, width = 3 ACPI timer looks GOOD min = 2, max = 4, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 16777187, width = 16777186 ACPI timer looks GOOD min = 2, max = 4, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks GOOD min = 2, max = 4, width = 3 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 5 at device 4.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 4.3 (no driver attached) ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xd000-0xd0ff mem 0xde80-0xde800fff irq 5 at device 6.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb81f mem 0xde00-0xde0f,0xe100-0xe1000fff irq 10 at device 7.0 on pci0 fxp0: Ethernet address 00:e0:18:90:87:b2 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: multimedia, audio at device 10.0 (no driver attached) fdc0: enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROM at iomem 0xc-0xc on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s4a da1 at ahc0 bus 0 target 1 lun 0 da1: QUANTUM XP34550W LYK8 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) da0 at ahc0 bus 0 target 0 lun 0 da0: IBM DRVS18V 0110 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 17519MB (35879135 512 byte sectors: 255H
Re: RC NG, ntp and routed
At 11:23 AM -0200 2002/12/09, Daniel C. Sobral wrote: I do see one contraindication to this behavior. Most routing protocols also react badly to time changes. Egg and chicken problem, but, personally, and running OSPF, which is one of those protocols that react badly to time changes, I find it preferably to run the router first. IIRC, ntpd should not cause large-scale changes to the time that might wreak havoc with your router. It should only be making changes in the rate at which the clock ticks, so as to speed it up or slow it down, to the point where you are more or less in sync with your reference(s). It would be ntpdate that would be the potentially dangerous one making large-scale changes to your system time. Therefore, you definitely want the router stuff before the ntpd stuff. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NFS-related panic on reboot
With today's -current, after typing reboot into tcsh: NFS append race @0:13 NFS append race @0:23 NFS append race @0:13 NFS append race @0:3 NFS append race @0:60 NFS append race @0:168 NFS append race @0:518 Stopping cron. Stopping inetd. Shutting down daemon processes:. Shutting down local daemons:. Writing entropy file:. [1] Terminated . DecConnection attempt to UDP 128.9.168.58:137 from 128.9.176.98:137 Connection attempt to UDP 128.9.168.58:137 from 128.9.176.98:137 Connection attempt to UDP 128.9.168.58:137 from 128.9.176.98:137 Connection attempt to UDP 128.9.168.58:137 from 128.9.176.98:137 DDec 9 14:39:32 Coamd[656]: call_mnountd: NFS versinon 3, mount verseion 3 ction attempt to TCP 127.0.0.1:111 from 127.0.0.1:871 DDeDDec Connection attempt to TCP 127.0.0.1:111 from 127.0.0.1:870 DConnection attempt to TCP 127.0.0.1:111 from 127.0.0.1:869 Connection attempt to TCP 127.0.0.1:111 from 127.0.0.1:868 DDConnection attempt to TCP 127.0.0.1:111 from 127.0.0.1:867 Connection attempt to TCP 127.0.0.1:111 from 127.0.0.1:866 Dboot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 18 18 done Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0200 fault virtual address = 0x168 fault code = supervisor read, page not present instruction pointer = 0x8:0xc69f8869 stack pointer = 0x10:0xdf0c09c8 frame pointer = 0x10:0xdf0c0a0c 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 = 1 (init) kernel: type 12 trap, code=0 Stopped at nfs_removerpc+0x19: movl0x168(%eax),%eax db trace nfs_removerpc(c74675dc,c6b5ce6c,c,c6b0fc00,0) at nfs_removerpc+0x19 nfs_removeit(c6b5ce60,0,c6b0fc00,c21b19a0,1) at nfs_removeit+0x30 nfs_inactive(df0c0aa4,12,c21b19a0,c21b19a0,0) at nfs_inactive+0x8d vclean(c74b65dc,8,c21b19a0,6,c74b65dc) at vclean+0x10a vgonel(c74b65dc,c21b19a0,c034603c,952,c01bcb20) at vgonel+0x5e vflush(c724f000,1,2,0,8) at vflush+0x3cc nfs_unmount(c724f000,8,c21b19a0,c21b19a0,0) at nfs_unmount+0x49 dounmount(c724f000,8,c21b19a0,,0) at dounmount+0x1a2 vfs_unmountall(c0347d1a,c033f198,ab,134,12) at vfs_unmountall+0x4e boot(0,0,c033f198,ab,df0c0d40) at boot+0x494 reboot(c21b19a0,df0c0d10,c035adc0,407,c21b0d50) at reboot+0x4a syscall(2f,2f,2f,80a265a,bfbffdf8) at syscall+0x3c6 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050777, esp = 0xbfbffc3c, ebp = 0xbfbffd08 --- db panic panic: from debugger cpuid = 1; lapic.id = 0200 Debugger(panic) [root@nik: /usr/tmp] gdb -k /usr/obj/usr/src/sys/KERNEL-1.11/kernel.debug vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0200 fault virtual address = 0x168 fault code = supervisor read, page not present instruction pointer = 0x8:0xc69f8869 stack pointer = 0x10:0xdf0c09c8 frame pointer = 0x10:0xdf0c0a0c 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 = 1 (init) panic: from debugger cpuid = 1; lapic.id = 0200 Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 1; lapic.id = 0200 instruction pointer = 0x8:0xc02eba3a stack pointer = 0x10:0xdf0c073c frame pointer = 0x10:0xdf0c0748 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 1 (init) panic: from debugger cpuid = 1; lapic.id = 0200 boot() called on cpu#1 Uptime: 4h9m47s pfs_vncache_unload(): 3 entries remaining Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233 233 dumpsys(dumper); (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:233 #1 0xc01b6fbe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364 #2 0xc01b75b7 in panic (fmt=0xc0332f43 from debugger) at
Re: sshd problem
On Mon, Dec 09, 2002 at 12:59:44PM -0800, Kris Kennaway wrote: On Mon, Dec 09, 2002 at 05:49:31PM +0100, Jens Rehsack wrote: Can you check the core dump for backtrace and send that? sysctl kern.sugid_coredump=1 sysctl kern.corefile=/tmp/%N.core (or somewhere else writable by an unprivileged user) Ok, I ran gdb sshd sshd.core, then the bt command, here is its output: (gdb) bt #0 0x282670ff in strcasecmp () from /usr/lib/libc.so.5 #1 0x284151f4 in login_access () from /usr/lib/pam_login_access.so.2 #2 0x284150e2 in login_access () from /usr/lib/pam_login_access.so.2 #3 0x28414ef6 in login_access () from /usr/lib/pam_login_access.so.2 #4 0x28414daf in login_access () from /usr/lib/pam_login_access.so.2 #5 0x28414aed in pam_sm_acct_mgmt () from /usr/lib/pam_login_access.so.2 #6 0x281d97dc in openpam_dispatch () from /usr/lib/libpam.so.2 #7 0x281d8d1e in pam_acct_mgmt () from /usr/lib/libpam.so.2 #8 0x08061e05 in tty_parse_modes () #9 0x08062012 in tty_parse_modes () #10 0x0805db3a in tty_parse_modes () #11 0x0805d23a in tty_parse_modes () #12 0x0805cf58 in tty_parse_modes () #13 0x0804e6bf in tty_parse_modes () #14 0x08050166 in tty_parse_modes () #15 0x0804db65 in tty_parse_modes () Is this enough? I'm a bit new to gdb, so I may be missing something. sv -- [LPML-2001] [KPI-PMA] [FreeBSD] [NIN] * GPG fingerprint: 7175 B841 C13D 9FE6 BDE0 C5E3 1652 7026 0A30 1CED Mail me with subject GPG-GETKEY to get my public key. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound familiar? 5.0-RC hangs on dual athlon
On Mon, Dec 09, 2002 at 10:47:24PM +0100, Julian H. Stacey wrote: I dropped back to a generic single CPU kernel. ( Which cancelled main reason I moved to 5.0-DP2: to get ATA bus working with dual, see my Nov. 22 Subject: 5.0-DP2: SMP+ATA OK. But 4.7 stable boot panic with ASUS P2L97-DS To: freebsd-current@ ) I'm down loading 5.0-RC1-i386-disc1.iso Well, I tried again, this time: = I built with DDB, INVARIANTS, INVARIANT_SUPPORT, WITNESS, and WITNESS_SKIPSPIN --- none of these were enabled previously. = I did not try to use ccd nor vinum --- I tried one and then the other previously. = I did not use UFS2 --- I formatted all large filesytems with UFS2 previously. So far things are peachy ... I've gotten along much futher than previously (restored all files from backup while building GNOME 2). Later (much later) I'll try to narrow the problem down further. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC1 sysinstall hang
Dimitry Andric wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Having tried 5.0-DP1 before on a certain box (see below for dmesg), I tried booting a 5.0-RC1 CD on it. However, sysinstall always hangs at probing devices, although it reacts to ^C. Restarting it doesn't really help, though, it simply hangs again. I've let it run for 30 minutes, but still nothing. With -DP1, sysinstall had no problems, and that version is still running on the box, giving the following dmesg: == Copyright (c) 1992-2002 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.0-DP1 #0: Sun Apr 7 02:51:42 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc053e000. Preloaded elf module /boot/kernel/acpi.ko at 0xc053e0a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 451024348 Hz CPU: Pentium III/Pentium III Xeon/Celeron (451.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x383f9ff real memory = 268423168 (262132K bytes) avail memory = 255545344 (249556K bytes) Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00f0d10 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 2, max = 4, width = 3 ACPI timer looks GOOD min = 2, max = 4, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks BAD min = 2, max = 16777187, width = 16777186 ACPI timer looks GOOD min = 2, max = 4, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 4 ACPI timer looks GOOD min = 2, max = 4, width = 3 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd400-0xd41f irq 5 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 4.3 (no driver attached) ahc0: port 0xd000-0xd0ff mem 0xde80-0xde800fff irq 5 at device 6.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: port 0xb800-0xb81f mem 0xde00-0xde0f,0xe100-0xe1000fff irq 10 at device 7.0 on pci0 fxp0: Ethernet address 00:e0:18:90:87:b2 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at device 10.0 (no driver attached) fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xc-0xc on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s4a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 17519MB (35879135 512 byte sectors: 255H 63S/T 2233C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da2: 2170MB (4445380 512 byte sectors: 255H 63S/T 276C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 16) cd1: Attempt to query device size failed: NOT READY, Medium not present cd2 at ahc0 bus 0 target 6
Re: HELP: vinum and newfs on 5.0-RC1
I have also been having a few problems with vinum on 5.0-RC1. I've been having a hard time making a striped or raid5 vinum with more than 4 disk's. On the 5th+ disk's vinum will see and says device is not configured. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HELP: vinum and newfs on 5.0-RC1
On Monday, 9 December 2002 at 20:23:44 -0500, David Rhodus wrote: I have also been having a few problems with vinum on 5.0-RC1. I've been having a hard time making a striped or raid5 vinum with more than 4 disk's. On the 5th+ disk's vinum will see and says device is not configured. That's a very different issue. I'm still investigating the one to which you replied, but in your case I'd like to see the config file and the contents of /dev. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Data corruption in soft updates?
I rebuilt my kernel with today's current + the acpica-20021122 patch and rebooted. I use ufs1, no acls or special options other than SU (installed with DP1). Everything booted fine with some errors from acpi but as booting proceeded, I started getting kernel messages of bad inode. I quickly rebooted to single user and ran fsck and got a huge set of errors. See this partial log (600KB gzipped): http://www.root.org/~nate/fsck.gz I didn't touch all those files (just booted and started getting errors) so I don't want to say yes to deleting them. Do I have to newfs/reinstall? Should I try using a superblock backup? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Confused by mpd and ipnat
On Tue, Dec 10, 2002 at 12:06:21AM +0800, leafy wrote: map ng0 192.168.0.0/24 - 0/32 When I reboot, this line (along with ipnat stuff) got executed before mpd fiinishes PPPoE negotiation, and ipnat -l shows that the ng0 ip was 0.0.0.0/32. Is there anyway I can ensure that ipnat -f /etc/ipnat.rules get executed only after mpd has obtained proper ip settings? Does mpd install a startup script in /usr/local/etc/rc.d ? Does it get started in the background? If it's script is in /usr/local/etc/rc.d then it gets run by the /etc/rc.d/local script which runs after /etc/rc.d/ipnat. In this case you can simply re-apply the rules after the negotiation is completed: /etc/rc.d/ipnat reload Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48442/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
[ cc'd some more people on this ] On Mon, Dec 09, 2002 at 11:23:58AM -0200, Daniel C. Sobral wrote: I suggest that routed be specified as being BEFORE ntpd. In the absence of a route to the specified servers, ntpd has the annoying behavior of chosing the address of lo0 as the source address for ntp requests, resulting in all sorts of problems. Yeah, makes sense. It also worked like that (correctly, that is) in rc.network. I do see one contraindication to this behavior. Most routing protocols also react badly to time changes. Egg and chicken problem, but, personally, and running OSPF, which is one of those protocols that react badly to time changes, I find it preferably to run the router first. After all, having ntpd using 127.0.0.1 as source is useless to me. The following patch should solve your problem. However, it's only a partial solution. It fixes the case for ntpd and ntpdate but not for other network daemons like rpcbind, which still get started _before_ the routing daemons. I haven't included patches for those because sorting out the dependencies is going to be a bit more involved. I'll have it done when I get a chance later this week. (A consequence of this is going to be that we will be moving *away* from NetBSD in the dependency ordering, but we can sort that out with them later). Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 Index: etc/rc.d/ntpd === RCS file: /home/ncvs/src/etc/rc.d/ntpd,v retrieving revision 1.5 diff -u -r1.5 ntpd --- etc/rc.d/ntpd 2002/10/12 10:31:31 1.5 +++ etc/rc.d/ntpd 2002/12/10 02:09:05 @@ -5,7 +5,7 @@ # # PROVIDE: ntpd -# REQUIRE: DAEMON +# REQUIRE: DAEMON routed route6d mrouted mroute6d ntpdate # BEFORE: LOGIN # KEYWORD: FreeBSD NetBSD Index: etc/rc.d/ntpdate === RCS file: /home/ncvs/src/etc/rc.d/ntpdate,v retrieving revision 1.4 diff -u -r1.4 ntpdate --- etc/rc.d/ntpdate2002/10/12 10:31:31 1.4 +++ etc/rc.d/ntpdate2002/12/10 02:09:05 @@ -5,7 +5,8 @@ # # PROVIDE: ntpdate -# REQUIRE: NETWORKING syslogd +# REQUIRE: DAEMON routed route6d mrouted mroute6d +# BEFORE: LOGIN # KEYWORD: FreeBSD NetBSD . /etc/rc.subr Index: etc/rc.d/rpcbind === RCS file: /home/ncvs/src/etc/rc.d/rpcbind,v retrieving revision 1.6 diff -u -r1.6 rpcbind --- etc/rc.d/rpcbind2002/09/06 16:18:05 1.6 +++ etc/rc.d/rpcbind2002/12/10 02:09:05 @@ -5,7 +5,7 @@ # # PROVIDE: rpcbind -# REQUIRE: NETWORKING ntpdate syslogd named ppp +# REQUIRE: NETWORKING syslogd named ppp # KEYWORD: FreeBSD NetBSD . /etc/rc.subr msg48443/pgp0.pgp Description: PGP signature
Re: Data corruption in soft updates?
Date: Mon, 9 Dec 2002 18:04:03 -0800 (PST) From: Nate Lawson [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Data corruption in soft updates? X-ASK-Info: Whitelist match I rebuilt my kernel with today's current + the acpica-20021122 patch and rebooted. I use ufs1, no acls or special options other than SU (installed with DP1). Everything booted fine with some errors from acpi but as booting proceeded, I started getting kernel messages of bad inode. I quickly rebooted to single user and ran fsck and got a huge set of errors. See this partial log (600KB gzipped): http://www.root.org/~nate/fsck.gz I didn't touch all those files (just booted and started getting errors) so I don't want to say yes to deleting them. Do I have to newfs/reinstall? Should I try using a superblock backup? -Nate It appears that you are getting all those errors (BAD block) because fsck thinks that your filesystem is smaller than it really is. If you do a dumpfs on the filesystem and check the size (about line 5), I expect that you will find that all those bad blocks exceed that size. It might be interesting to check one or more of the alternate blocks to see if they have a different size. If so, using an alternate should help. If not, then the question is why all those out of range blocks were allocated. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Confused by mpd and ipnat
On Mon, Dec 09, 2002 at 06:17:27PM -0800, Mike Makonnen wrote: Does mpd install a startup script in /usr/local/etc/rc.d ? Does it get started in the background? If it's script is in /usr/local/etc/rc.d then it gets run by the /etc/rc.d/local script which runs after /etc/rc.d/ipnat. In this case you can simply re-apply the rules after the negotiation is completed: /etc/rc.d/ipnat reload Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc I finally got over this one. The problem is that mpd needs a very long time for PPPoE negotiation, thus if we run ipnat reload before it's settled, that will be totally useless. So I moved the mpd startup script to PREFIX/etc/rc.d/000.mpd.sh and the ipnat reload in zzz.ipnat_reload.sh and VIOLA! Putting them in the same script does not work, maybe this could be improved? JY To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Confused by mpd and ipnat
On Tue, Dec 10, 2002 at 11:24:59AM +0800, leafy wrote: I finally got over this one. The problem is that mpd needs a very long time for PPPoE negotiation, thus if we run ipnat reload before it's settled, that will be totally useless. So I moved the mpd startup script to PREFIX/etc/rc.d/000.mpd.sh and the ipnat reload in zzz.ipnat_reload.sh and VIOLA! Putting them in the same script does not work, maybe this could be improved? How could this not work? Are you starting it in the background? Must be. I'm assuming that you don't want to run them serially because it would take too long to startup your system so you use some sort of mechanism (like the -background option to ppp(8)) to run it in the background. I would suggest that you do something like this: ( mpd -foreground; /etc/rc.d/ipnat reload ) ... unless it is not possible for some reason. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48446/pgp0.pgp Description: PGP signature
Re: Confused by mpd and ipnat
On Mon, 9 Dec 2002, Mike Makonnen wrote: On Tue, Dec 10, 2002 at 11:24:59AM +0800, leafy wrote: I finally got over this one. The problem is that mpd needs a very long time for PPPoE negotiation, thus if we run ipnat reload before it's settled, that That's interesting. mpd uses the same kernel module that ppp does, to do the negotiation. A tcpdump of the ethernet interface (with timing) would be instructive. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
