installworld - /usr/share/info/dir problems
Hello, I'm having diffculties performing an installworld of the newest sources. *** === lib/libcom_err/doc install-info --quiet --defsection=Programming development tools. --defentry=* libcom_err: (com_err).A Common Error Description Library for UNIX. com_err.info /usr/share/info/dir install-info: /usr/share/info/dir: empty file *** Error code 1 *** After some minor investigation I can complete an installworld if I put some junk into the /usr/share/info/dir file. I may have lost the contents of the file because of a power cut the other day, but I can't seem to find a new one in the src-tree, nor anywhere else. Thanks! Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Please commit syscons fix (Was: Re: syscons in rcng ? - SOLVED)
With the latest changes (1.8, 5th of Sep) to /etc/rc.d/syscons, syscons doesn't get initialized on my 5.0-CURRENT. Have I missed some new configuration options? Very simple: /usr/src/etc/rc.d/syscons misses line run_rc_command $1 Would someone please commit this? Sincerely, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
syscons in rcng ?
Hello, With the latest changes (1.8, 5th of Sep) to /etc/rc.d/syscons, syscons doesn't get initialized on my 5.0-CURRENT. Have I missed some new configuration options? Sincerely, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panics during boot with recent sources
Hello, For the last two days I haven't been able to boot unless I specify an older kernel. I've tried cvsup'ing a few times but now I thought I should post it here. I'm running 5.0-CURRENT as of 10 hours ago, on a Dell 4100 Inspiron. I've been running current on it for half a year or so. I've scratched the panic message down by hand, so some minor inperfections can occur. Stopped at Debugger+0x45 :xchgl %ebx,in_Debugger.0 db trace panic(c0328280c) at panic+0x75 resource_list_release(c25ffd84,c25ffc00,c25fea00,3,10) at \ resource_list_release+0xb3 bus_generic_rl_release(c25ffc00,c25fea00,3,10,c25fc140) at \ bus_generic_rl_release+0x5d bus_release_resource pcbb_attach device_probe_and_attach bus_generic_attach device_probe_and_attach bus_generic_attach pcib_attach ... If you need the stack pointers for the last entries I can provide them as well as the problem is easily reproduceable. Thank you! Sincerely, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at boot in ffs_valloc
I'm also suddenly having a panics - every 5 minutes actually, since my latest cvsup a few hours ago. They seem to be related to some ufs and ffs calls.. I'm not able to read my core dumps for some reason (gdb says kernel symbol 'cpuhead' not found.) and I don't have the time to scratch a backtrace down by hand just now. The panicstring is: bremfree: bp 0xc77e8670 not locked Sincerely, Rasmus Skaasrup On Wed, 3 Jul 2002, Andrew R. Reiter wrote: :I cvsup'd and built world+kernel a few hours ago and was happy to see :KDE working again, but I got a spontaneous reboot while trying to track :down a segfault in a mozilla build component. I boot -v'ed and as :soon as the login prompt came up I hit a panic. I'm guessing the :backgorund fsck had something to do with it. I'll hand-copy the trace :here; any debugging info needed while my box is stuck at the debugger, :lemme know: I don't have the output to show people since I was trying to reproduce but couldnt, but i got essentially the same panic, but it came only from a syscall to open() that called ufs_create() - ufs_makeinode - ffs_valloc() - panic. I can try and reproduce (tho, mine occured when just running cscope) and get a dump. Cheers, Andrew :FreeBSD/i386 (foo) (ttyv0) : :login: mode = 041777, inum = 12871, fs = /usr :panic: ffs_valloc: dup alloc :cpuid = 0; lapic.id = :Debugger(panic) :Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 :db trace :Debugger(c02d9eda) at Debugger+0x46 :panic(c02e9a21,c02e9a00,43ff,3247,c41c58d4) at panic+0xd6 :ffs_valloc(c4284100,8100,c159a180,d6afd6f0) at ffs_valloc+0x141 :ufs_makeinode(8100,c4284100,d6afda20,d6afda34) at ufs_makeinode+0x58 :ufs_create(d6afd94c,d6afda68,c0248a68,d6afd94c,c0346b78) at ufs_create+0x26 :ufs_vnoperate(d6afd94c) at ufs_vnoperate+0x13 :ffs_snapshot(c41b7600,80b2ba0,d6afda94,c41db700,c0346bf0) at :ffs_snapshot+0x2a0 :ffs_mount(c41b7600,c4421200,bfbffcc0,d6afdbf8,c159f300) at ffs_mount+0x48 :vfs_mount(c159f300,c41b2eb0,c4421200,1211000,bfbffcc0) at ffs_mount+0x6dc :mount(c159f300,d6afdd14,4,1,202) at mount+0x6a :syscall(2f,2f,2f,0,bfbffde0) at syscall+0x23c :syscall_with_err_pushed() at syscall_with_err_pushed+0x1b :--- syscall (21, FreeBSD ELF, mount), eip = 0x80549d7, esp = 0xbfbffbdc, :ebp = 0xbfbffd48 --- :db : :-- :Anthony Jenkins :http://www.mindspring.com/~abjenkins/ : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Messages from WITNESS [Sun May 26 kernel]
I have several different types of could sleep with messages. The following appear during boot-up. /usr/src/sys/vm/uma_core.c:1324: could sleep with eventhandler locked from /usr/src/sys/kern/subr_eventhandler.c:162 /usr/src/sys/vm/uma_core.c:1324: could sleep with sf_bufs list lock locked from /usr/src/sys/kern/uipc_syscalls.c:1578 /usr/src/sys/vm/uma_core.c:1324: could sleep with xl0 locked from /usr/src/sys/pci/if_xl.c:1260 /usr/src/sys/vm/uma_core.c:1324: could sleep with rman locked from /usr/src/sys/kern/subr_rman.c:194 If I enable debug.witness_ddb in loader.conf and type trace everytime a could sleep with message appears, it doesn't appear in /var/log/messages and I don't feel like writing all the information down by hand.. Unless it is /really/ necessary. But the following appears when the system is up, and a copy/paste works fine. /usr/src/sys/vm/uma_core.c:1324: could sleep with xl0 locked from /usr/src/sys /pci/if_xl.c:2974 Debugger(witness_sleep) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db trace Debugger(c0335740) at Debugger+0x45 witness_sleep(1,0,c034ba71,52c) at witness_sleep+0xf8 uma_zalloc_arg(c082a780,0,0) at uma_zalloc_arg+0x3e vm_map_entry_create(c0822ef4,0,cf1f1ea8,707da90,13ba000) at vm_map_entry_create+ 0x2b vm_map_insert(c0822ef4,c03fb260,13ba000,0,c12b9000) at vm_map_insert+0x1dc kmem_malloc(c0822ef4,1000,1,c0333f9e,263) at kmem_malloc+0x129 mb_pop_cont(c03d4c20,1,c76c7ca0,c03d4c60,0) at mb_pop_cont+0x8e mb_alloc(c03d4c20,1,0,c0e41c00,cf2adb68) at mb_alloc+0x147 m_clget(c0e41c00,1,22,cd2de188,cddfe000) at m_clget+0x16 xl_newbuf(cd2de000,cd2de320) at xl_newbuf+0x2c xl_list_rx_init(cd2de000) at xl_list_rx_init+0x3d xl_init(cd2de000,0,cf2adc60,80206910,cf2adc60) at xl_init+0x13d xl_ioctl(cd2de000,80206910,cf2adc60) at xl_ioctl+0x19c ifhwioctl(80206910,cd2de000,cf2adc60,cf28b728) at ifhwioctl+0x289 ifioctl(cf1c23d8,80206910,cf2adc60,cf28b728,0) at ifioctl+0xb2 soo_ioctl(cf106078,80206910,cf2adc60,cf28b728) at soo_ioctl+0x197 ioctl(cf28b728,cf2add14,3,0,296) at ioctl+0x353 syscall(2f,2f,2f,3,1) at syscall+0x205 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (54, FreeBSD ELF, ioctl), eip = 0x804d577, esp = 0xbfbffb9c, ebp = 0 xbfbffbe8 --- and another one: /usr/src/sys/vm/uma_core.c:1324: could sleep with process l ock locked from /usr/src/sys/kern/kern_prot.c:613 Debugger(witness_sleep) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db trace Debugger(c0335740) at Debugger+0x45 witness_sleep(1,0,c034ba71,52c) at witness_sleep+0xf8 uma_zalloc_arg(c082ac80,0,4) at uma_zalloc_arg+0x3e malloc(20,c0398880,4,c03d3d00,0) at malloc+0x68 uifind(1,c76c7d60,cf3a9f00,1,cf2b1cec) at uifind+0x56 change_euid(cf1d3600,1,cf28b4f0,0,cf1d3600) at change_euid+0x1c seteuid(cf28b414,cf2b1d14,1,1,282) at seteuid+0xbf syscall(2f,2f,2f,bfbffceb,804a226) at syscall+0x205 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (183, FreeBSD ELF, seteuid), eip = 0x280a3eeb, esp = 0xbfbffc8c, ebp = 0xbfbffd64 --- and another process lock: /usr/src/sys/vm/uma_core.c:1324: could sleep with process lock locked from /us r/src/sys/kern/kern_prot.c:511 Debugger(witness_sleep) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db trace Debugger(c0335740) at Debugger+0x45 witness_sleep(1,0,c034ba71,52c) at witness_sleep+0xf8 uma_zalloc_arg(c082ac80,0,4) at uma_zalloc_arg+0x3e malloc(20,c0398880,4,c03d3d00,0) at malloc+0x68 uifind(2,c76c7d60,c76c7d60,,0) at uifind+0x56 change_ruid(cf1d3600,2,cf28cb18,0,cf1d3600) at change_ruid+0x28 setuid(cf28ca3c,cf406d14,1,0,296) at setuid+0xc2 syscall(2f,2f,2f,8056050,12) at syscall+0x205 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (23, FreeBSD ELF, setuid), eip = 0x280b3a0b, esp = 0xbfbff71c, ebp = 0xbfbff748 --- Best regards Rasmus Skaarup On Sun, 26 May 2002, Alfred Perlstein wrote: * Jun Kuriyama [EMAIL PROTECTED] [020526 19:09] wrote: At Sun, 26 May 2002 22:19:58 + (UTC), Alfred Perlstein wrote: Uh, why don't you guys enable 'debug.witness_ddb' and get us some tracebacks? :) Could this help you? Yes. Index: feeder.c === RCS file: /home/ncvs/src/sys/dev/sound/pcm/feeder.c,v retrieving revision 1.23 diff -u -r1.23 feeder.c --- feeder.c 25 May 2002 11:18:03 - 1.23 +++ feeder.c 27 May 2002 03:07:30 - @@ -137,7 +137,8 @@ struct pcm_feeder *f; int err; - f = (struct pcm_feeder *)kobj_create((kobj_class_t)fc, M_FEEDER, M_WAITOK | M_ZERO); + f = (struct pcm_feeder *)kobj_create((kobj_class_t)fc, M_FEEDER, + M_NOWAIT | M_ZERO); if (f == NULL) return NULL; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam_unix.so error and lock order reversal
On Sat, 13 Apr 2002, Terry Lambert wrote: Rasmus Skaarup wrote: 2) When logged in as root, and su'd to a non-root user, I cannot ssh to a 4.5-STABLE machine.. It just hangs. But when logged in as non-root, it works fine. Is this somekind of security feature? :-) Pretty much. The user it attempts to log you in as is still root, because that's still your identity, even if it's not your current credential. [...] You might want to try using su - instead of su, in order to actually *become* the other person. I am. Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: swi_net: unregistered isr number: 18
I'm getting the same message a lot when using 'dhclient'. Best regards, Rasmus Skaarup On Sat, 13 Apr 2002, Steve Kargl wrote: cvsup and make world sequence from this morning (0841 PDT) yields the following warning at boot swi_net: unregistered isr number: 18. System appears to be running fine. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pam_unix.so error and lock order reversal
Hello, I have three issues. 1) When logging in, the following appears in messages: Apr 13 12:18:37 laptop login: in openpam_dispatch(): pam_unix.so: no pam_sm_open_session() Apr 13 12:18:38 laptop login: in openpam_dispatch(): pam_unix.so: no pam_sm_close_session() 2) When logged in as root, and su'd to a non-root user, I cannot ssh to a 4.5-STABLE machine.. It just hangs. But when logged in as non-root, it works fine. Is this somekind of security feature? :-) 3) lock order reversal when for instance doing a cvsup Apr 13 12:16:58 laptop kernel: lock order reversal Apr 13 12:16:58 laptop kernel: 1st 0xcc5928e4 KNOTE (UMA zone) @ /usr/src/sys/vm/uma_core.c:491 Apr 13 12:16:58 laptop kernel: 2nd 0xc082a724 PCPU KMAP ENTRY (UMA cpu) @ /usr/src/sys/vm/uma_core.c:1264 I'm running 5.0-CURRENT two hours old. Thanks! Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Apache core dumps
Hello, Since a cvsup not long ago (I can't remember the date, just that it's under two weeks ago), my apache-1.3.24/mod_perl-1.26 installation core dumps every time I start it. The console message is: kernel: pid (1212), uid 0: exited on signal 6 (core dumped) And the only thing httpd-error.log says is: httpd in free(): error: junk pointer, too high to make sense I've tried downgrading to apache-1.3.23 but as soon as mod_perl is added I can't start it up. What is wrong? Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM code ready for testing
On Thu, 14 Mar 2002, Doug White wrote: On Tue, 12 Mar 2002, Rasmus Skaarup wrote: Hmm, but I'm not sure all kinds of storage devices have serialnumbers that could be fetched (tape devices for instance?) and can we rely on the hardware manufacturers to provide unique serialnumbers? Although it's an isolated case, you do have globally unique identifiers in FibreChannel. :-) Yes, on hosts and controllers, but not on the storage devices themselves. Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM code ready for testing
On Tue, 12 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Carl Makin writes: On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote: The GEOM code is now ready for early testing: Would GEOM support accessing a device via multiple paths? (ie could we write a method that would do that?) Yes, that would be possible. Have you given any thought to how that might be implemented? If somekind of ID is required to identify the same disk via multiple paths, in which part of GEOM will this be implemented? I can't figure out from your documentation whether you have somekind of Master GEOM instance that initiates the device recognition, or otherwise how is this initiated? Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM code ready for testing
On Tue, 12 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Rasmus Skaarup writes: On Tue, 12 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Carl Makin writes: Would GEOM support accessing a device via multiple paths? (ie could we write a method that would do that?) Yes, that would be possible. Have you given any thought to how that might be implemented? If somekind of ID is required to identify the same disk via multiple paths, in which part of GEOM will this be implemented? Basically when a new g_provider is created it is offered to each method in turn and if that method likes it, it can stick g_geom on top of it. Ahh.. But do you rule out the possibility that two methods could apply to a g_provider? Or is this even a problem? How you would recognize the same disk on thre different paths is a good question. We could implement (if we don't already have it) an ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice and you could query that. Hmm, but I'm not sure all kinds of storage devices have serialnumbers that could be fetched (tape devices for instance?) and can we rely on the hardware manufacturers to provide unique serialnumbers? Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM code ready for testing
On Tue, 12 Mar 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Rasmus Skaarup writes: How you would recognize the same disk on thre different paths is a good question. We could implement (if we don't already have it) an ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice and you could query that. Hmm, but I'm not sure all kinds of storage devices have serialnumbers that could be fetched (tape devices for instance?) and can we rely on the hardware manufacturers to provide unique serialnumbers? Well, the recognition/configuration issue is not one GEOM magically can solve for you, but GEOM promises that if you can recognize it and configure it, GEOM will not get in your way for doing what you want. But what if the name of the device somehow depended on the ID on the device? So you could recognize the same disk on multiple hosts, and having the same name for the device on each host. But this should maybe be left up to the method to assign? Best regards, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
On 7 Mar 2002, Michael D. Harnois wrote: On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev [EMAIL PROTECTED] said: Maxim Hi, Looks like source upgrade path is broken due to PAM. My Maxim system is -CURRENT compiled on 19 February. Please fix. Could this have anything to do with the fact that, since I built world yesterday, I can't log in as root? I can't login as root either, I can only gain root access if I boot into single-user. The login process just eats up all cpu-ressources and the login times out after 300 seconds. A su doesn't work either, of course. Sincerely, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4.0-RELEASE boot.flp fails to boot on K6/2
Jordan K. Hubbard said: Good idea, terrible name. Can't you guys some up with something better? :) kern.flp- start.flp mfsroot.flp - install.flp boot.flp- bigstart.flp bigdisk.flp ? I thought we could rename kern.flp and mfsroot.flp aswell, since they their names don't make much sense to anyone other than the one compiling the darn disks :-) Best regards Rasmus Skaarup On Tue, Mar 21, 2000 at 04:32:35PM -0800, Doug White wrote: I would be in favor of renaming the boot.flp to something obviously different, like 288boot.flp, to untrain us 2.x heads that got used to the Great idea. Would you be able to make the changes locally and test a `make release'? Then all we need to do is pass the patch pass JKH. (harder to say "NO" to working code) -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world: install-info: unrecognized option
Hiya, I just cvsupped a couple of hours ago, after a successful build, the install phase fails: ** snip snip ** === lib/libcom_err/doc install-info --quiet --defsection="Programming development tools." --defentry="* libcom_err: (com_err).A Common Error Description Library for UNIX." com_err.info /usr/share/info/dir install-info: unrecognized option `--defsection=Programming development tools.' Try `install-info --help' for a complete list of options. *** Error code 1 Stop. ** snip snip ** I'm running 3.4-STABLE, trying to cvsup to cvs-tag RELENG_4. Regards Rasmus To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
