i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Fri Jul 26 22:27:32 PDT 2002 -- Kernel build for GENERIC completed on Fri Jul 26 23:27:37 PDT 2002 -- Kernel build for LINT started on Fri Jul 26 23:27:37 PDT 2002 -- === LINT /local0/scratch/des/src/sys/i386/conf/LINT: unknown option PCI_ENABLE_IO_MODES *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel crash when rebooting old kernel
karl agee wrote: Ok, I tried rebooting to my old orig kernel (5.0-DP1) to see if it helped my printing issue. well, this happened when I rebooted: Panic: Malloc type lacks magic Debugger (panic) stopped at Debugger+0x40 xorl%eax, %eax ? You need to wave a dead chicken over the keyboard. The first time after it boots up, make sure that you correctly enter your name, password, and the entrails of a goat. If that doesn't work, then try renaming your kernel module directory so that you don't ket modules which are out of date with your kernel. But, FWIW, I really think the problem is the non-waving of the dead chicken. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Jul 27 11:45:42 GMT 2002 -- === GENERIC /usr/home/des/tinderbox/sparc64/src/sys/sparc64/conf/GENERIC: unknown option PCI_ENABLE_IO_MODES *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
system hangs/reboots
With -current of today the system resets (without syncing discs) when mozilla is started. This happens everytime when mozilla is started. Other X apps like Sylpheed or mplayer seem to work correctly. zero copy sockets are not turned on and it didn't happen with -current as of a week ago. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About the recent kernel crashes.
On Fri, Jul 26, 2002 at 08:18:27PM -0700, walt wrote: A small observation which I hope will be useful: I started getting unexpected lockups during mozilla sessions after remaking world kernel on the evening of July 25. The screen would freeze completely, followed a few seconds later by a spontaneous reboot. After this happened twice I deleted the new kernel and went back to using the kernel I compiled on the morning of the same day, July 25, and the crashes disappeared. I've cvsup'd and remade the world twice since then (but not the kernel) and I remain crash-free. Seems to implicate kernel code committed on July 25, sometime after about 1430 GMT. For the kernel that works, what version of src/sys/kern/subr_mbuf.c did you build it from? I just want to make sure that I didn't break it with any of the changes I've made. My last change was on 2002/07/24 15:11:23 so I don't think it's that, but just to make sure... -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Kernel build for GENERIC started on Sat Jul 27 11:45:42 GMT 2002 -- === GENERIC /usr/home/des/tinderbox/sparc64/src/sys/sparc64/conf/GENERIC: unknown option PCI_ENABLE_IO_MODES *** Error code 1 I just committed a fix for this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About the recent kernel crashes.
Bosko Milekic wrote: On Fri, Jul 26, 2002 at 08:18:27PM -0700, walt wrote: . . . Seems to implicate kernel code committed on July 25, sometime after about 1430 GMT. For the kernel that works, what version of src/sys/kern/subr_mbuf.c did you build it from?... My source tree has been updated daily since then, so I can't tell from looking at the sources. Is there a way to get that info directly from the kernel? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: system hangs/reboots
On Sat, Jul 27, 2002 at 02:15:15PM +0200, Marc Recht wrote: With -current of today the system resets (without syncing discs) when mozilla is started. This happens everytime when mozilla is started. Other X apps like Sylpheed or mplayer seem to work correctly. zero copy sockets are not turned on and it didn't happen with -current as of a week ago. Do you have java installed and does mozilla load it? I rebuilt world and a kernel yesterday afternoon, and everything appears fine. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Kernel build for LINT started on Fri Jul 26 23:27:37 PDT 2002 -- === LINT /local0/scratch/des/src/sys/i386/conf/LINT: unknown option PCI_ENABLE_IO_MODES *** Error code 1 I just committed a fix for this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sat Jul 27 09:36:26 PDT 2002 -- Kernel build for GENERIC completed on Sat Jul 27 10:17:17 PDT 2002 -- Kernel build for LINT started on Sat Jul 27 10:17:17 PDT 2002 -- === LINT /local0/scratch/des/src/sys/i386/conf/LINT: unknown option PCI_ENABLE_IO_MODES *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About the recent kernel crashes.
I started getting unexpected lockups during mozilla sessions after remaking world kernel on the evening of July 25. The screen would freeze completely, followed a few seconds later by a spontaneous reboot. After this happened twice I deleted the new kernel and went back to using the kernel I compiled on the morning of the same day, July 25, and the crashes disappeared. I've cvsup'd and remade the world twice since then (but not the kernel) and I remain crash-free. For the kernel that works, what version of src/sys/kern/subr_mbuf.c did you build it from? I just want to make sure that I didn't break it with any of the changes I've made. My last change was on 2002/07/24 15:11:23 so I don't think it's that, but just to make sure... I've exactly the same problems. My subr_mbuf.c is: * $FreeBSD: src/sys/kern/subr_mbuf.c,v 1.23 2002/07/24 15:11:23 bmilekic Exp $ (cvsup'ed today) Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About the recent kernel crashes.
On Sat, Jul 27, 2002 at 07:27:11PM +0200, Marc Recht wrote: I started getting unexpected lockups during mozilla sessions after remaking world kernel on the evening of July 25. The screen would freeze completely, followed a few seconds later by a spontaneous reboot. After this happened twice I deleted the new kernel and went back to using the kernel I compiled on the morning of the same day, July 25, and the crashes disappeared. I've cvsup'd and remade the world twice since then (but not the kernel) and I remain crash-free. For the kernel that works, what version of src/sys/kern/subr_mbuf.c did you build it from? I just want to make sure that I didn't break it with any of the changes I've made. My last change was on 2002/07/24 15:11:23 so I don't think it's that, but just to make sure... I've exactly the same problems. My subr_mbuf.c is: * $FreeBSD: src/sys/kern/subr_mbuf.c,v 1.23 2002/07/24 15:11:23 bmilekic Exp $ (cvsup'ed today) Marc That's not what I was asking for. He mentionned he had a kernel from the 25th that was working and I wanted the version of subr_mbuf.c that he had used to build _that_ kernel. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: About the recent kernel crashes.
That's not what I was asking for. He mentionned he had a kernel from the 25th that was working and I wanted the version of subr_mbuf.c that he had used to build _that_ kernel. Oh, sorry. IIRC then (for me) everything worked just fine with r1.22. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
QUIT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
close PR bin/37795
Can someone close PR bin/37795? I am the originator of the PR, and it no longer applies to current version xinstall. -- Steve http://troutmask.apl.washington.edu/~kargl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: close PR bin/37795
On 27-Jul-2002 Steven G. Kargl wrote: Can someone close PR bin/37795? I am the originator of the PR, and it no longer applies to current version xinstall. Closed. Note that several people (including myself) actually want -d -C to not be an error. Still, the PR should be closed. -- 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: cvs commit: src/release/i386 drivers.conf
Terry Lambert wrote: M. Warner Losh wrote: : Think CDROM install. Dude, what crack are you smoking? How many times to we have to tell you. We have a boot loader that knows how to read the kernel from the cdrom or scsi or whatever. IT is a tiny increment to also load additional modules at that time that support those devices. What's the real issue? So, given that the install from a CDROM boots from a floppy image that's faked up by the CDROM drive BIOS, and the image doesn't include the full boot loader, how exactly is it that the partial boot loader code acts like the full bootloader code for accessing the CDROM to load the modules necessary to access the CDROM? Not true anymore. release/i386/mkisoimages.sh: bootable=-b boot/cdboot -no-emul-boot -r-xr-xr-x 1 root wheel 1136 Jul 5 02:20 /boot/cdboot* I believe we still use the old way on RELENG_4, but the support all got MFC'ed. Several release candidates used cdboot for better testing exposure. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
Terry Lambert wrote: M. Warner Losh wrote: I've noticed that some of the older cam drivers are about all that is in the way of making CAM truly loadable. By that I mean having a kernel with all supported devices that aren't loadable forces CAM to be in the kernel because some of the SCSI devices aren't (yet) loadable. However, that's relatively easy to fix. I've noticed that the fact that I boot from a CDROM or a SCSI hard drive is in the way of making CAM loadable. 8-) 8-). Anything in the boot path needs to be static, by definition, or you face the Catch-22 of needing to load the driver in order to be able to load the driver. Nope, it just needs to be loaded before the kernel takes over. This is what the preload mechanism is for. ...This wouldn't be a problem, if VM86 supported disk I/O, and you could replace drivers on the fly... I know this is a long favorite axe of yours, but I'd love to see code for this. Considering that loader *does* use VM86 do do disk IO calls, it can be done - loader runs in a 32 bit paged environment with a vm86 executive for doing all the bios calls, including disk IO. You dont feel like writing one for freebsd, do you? A vm86disk driver would solve a number of problems. If you do one that is respectable, I'll commit it for you myself. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic with -current
This is with the GENERIC kernel. Known problem ? How can I get a -current kernel that boots to multiuser so that I can tinker around with it ? Are there any magic config files that suppress these panics ? db trace _mtx_lock_flags(7069307e,0,c03ff2e0,530) at _mtx_lock_flags+0x3e securelevel_ge(bfbffe00,3,c0291194,c04b0e60,c04b0ca8) at securelevel_ge+0x3c ip_fw_ctl(cad2fcc0,c026213c,0,c2075410,cad2fcac) at ip_fw_ctl+0x30 rip_ctloutput(c2075410,cad2fcc0,cad2fd14,c0d6c540,cad2fcec) at rip_ctloutput+0xe sosetopt(c2075410,cad2fcc0,c2075410,1,0) at sosetopt+0x2c setsockopt(c0d6c540,cad2fd14,5,0,213) at setsockopt+0x8e syscall(2f,2f,2f,8093879,bfbffe73) at syscall+0x233 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
On 25-Jul-2002 Terry Lambert wrote: M. Warner Losh wrote: : Think CDROM install. Dude, what crack are you smoking? How many times to we have to tell you. We have a boot loader that knows how to read the kernel from the cdrom or scsi or whatever. IT is a tiny increment to also load additional modules at that time that support those devices. What's the real issue? So, given that the install from a CDROM boots from a floppy image that's faked up by the CDROM drive BIOS, and the image doesn't include the full boot loader, how exactly is it that the partial boot loader code acts like the full bootloader code for accessing the CDROM to load the modules necessary to access the CDROM? Actually, we do use the full bootloader for floppies. For CD-ROM it would be a bit tricky to load drivers off another floppy due to i386 BIOS, but we have that problem on other arch's anyways (e.g. alpha SRM). However, you can always do that later once the MFS root is up and running. CD-ROM's are completely different from floppies anyways. On all of our arch's we now boot a loader directly off the CD that has access to the entire CD's contents. (On i386 we use cdboot to do this via the El Torito no emulation mode.) The only place this isn't currently true is that 4.x releases don't use cdboot on i386. (IMO we should have starting with 4.6.) Alpha has since at least 4.5 IIRC. Thus, the only people who even need modules in the mfsroot or on a driver floppy are those doing an install booting from floppies (such as FTP installs). -- 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: panic with -current
On 27-Jul-2002 Arun Sharma wrote: This is with the GENERIC kernel. Known problem ? How can I get a -current kernel that boots to multiuser so that I can tinker around with it ? Are there any magic config files that suppress these panics ? db trace _mtx_lock_flags(7069307e,0,c03ff2e0,530) at _mtx_lock_flags+0x3e securelevel_ge(bfbffe00,3,c0291194,c04b0e60,c04b0ca8) at securelevel_ge+0x3c ip_fw_ctl(cad2fcc0,c026213c,0,c2075410,cad2fcac) at ip_fw_ctl+0x30 rip_ctloutput(c2075410,cad2fcc0,cad2fd14,c0d6c540,cad2fcec) at rip_ctloutput+0xe sosetopt(c2075410,cad2fcc0,c2075410,1,0) at sosetopt+0x2c setsockopt(c0d6c540,cad2fd14,5,0,213) at setsockopt+0x8e syscall(2f,2f,2f,8093879,bfbffe73) at syscall+0x233 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b Knowing the actual panic message would help. :) -- 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: panic with -current
On Sat, Jul 27, 2002 at 05:15:08PM -0400, John Baldwin wrote: Knowing the actual panic message would help. :) My bad. I was loading the wrong version of a kernel module (ipfw). -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
Peter Wemm wrote: So, given that the install from a CDROM boots from a floppy image that's faked up by the CDROM drive BIOS, and the image doesn't include the full boot loader, how exactly is it that the partial boot loader code acts like the full bootloader code for accessing the CDROM to load the modules necessary to access the CDROM? Not true anymore. release/i386/mkisoimages.sh: bootable=-b boot/cdboot -no-emul-boot -r-xr-xr-x 1 root wheel 1136 Jul 5 02:20 /boot/cdboot* I believe we still use the old way on RELENG_4, but the support all got MFC'ed. Several release candidates used cdboot for better testing exposure. Doesn't this require newer hardware/BIOS/firmware than most equipment has these days? I'm pretty sure that my ASUS box with a Toshiba 3401B won't boot from one of these, except on my really old AHA1742, which can't tell it's not just another hard drive... Is this going to be the default for distribution, or is the fake floppy boot CDROM still going to be disc #1? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/release/i386 drivers.conf
On 27-Jul-2002 Terry Lambert wrote: Peter Wemm wrote: So, given that the install from a CDROM boots from a floppy image that's faked up by the CDROM drive BIOS, and the image doesn't include the full boot loader, how exactly is it that the partial boot loader code acts like the full bootloader code for accessing the CDROM to load the modules necessary to access the CDROM? Not true anymore. release/i386/mkisoimages.sh: bootable=-b boot/cdboot -no-emul-boot -r-xr-xr-x 1 root wheel 1136 Jul 5 02:20 /boot/cdboot* I believe we still use the old way on RELENG_4, but the support all got MFC'ed. Several release candidates used cdboot for better testing exposure. Doesn't this require newer hardware/BIOS/firmware than most equipment has these days? Can your box install NT4? Supporting no emulation mode was required as part of the NT4 logo program so all but very ancient hardware supports this. When we tested this for 4.5 release candidates, we had on the order of about 3 or 4 boxes that didn't work and many, many boxes that it did work fine on. IOW, this is how all the bootable Windows CD's work (NT4, ME, 2000, XP, etc.). I'm pretty sure that my ASUS box with a Toshiba 3401B won't boot from one of these, except on my really old AHA1742, which can't tell it's not just another hard drive... It's not the drive it's the BIOS. Is this going to be the default for distribution, or is the fake floppy boot CDROM still going to be disc #1? Hopefully for 4.7 if not 4.6.1. :) Still, it's up to the vendors the current CD layout is setup to handle either way, it's simply changing the flags to mkisofs that determine which method is used. -- 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
panic: KSE: not on run queue
hi, FreeBSD epsilon.ury.york.ac.uk 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Fri Jul 26 13:32:52 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPSILON i386 Had this panic twice with current -current on an uniprocessor machine and kernel. Dumps still don't work... Both occurances, i had an ssh running, a portupgrade in progress, and the dnetc client running in the background. panic: KSE not on run queue panic: from debugger Uptime: 1d1h26m12s Dumping 127 MB ata0: resetting devices .. panic: mi_switch: switch in a critical section Uptime: 1d1h26m12s panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized Uptime: 1d1h26m12s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 1d1h26m12s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 1d1h26m12s ...etc... traceback from ddb is: panic runq_remove remrunqueue schedcpu softclock thread_loop forkexit forktrampoline Thanks Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
I didn't send dozens of QUIT emails
There was either a glitch at Verio's mta or possibly on Linux-Netscape in -current. I sent one message and it never went through. Sorry for the spam. It was an error message- get it? Rob. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I didn't send dozens of QUIT emails
Rob wrote: There was either a glitch at Verio's mta or possibly on Linux-Netscape in -current. I sent one message and it never went through. Sorry for the spam. It was an error message- get it? In the future, you might want to consider using the unsubscribe documented in both the message headers: |List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-current And the fotters attached to each message: |To Unsubscribe: send mail to [EMAIL PROTECTED] |with unsubscribe freebsd-current in the body of the message -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: KSE: not on run queue
On Sun, 28 Jul 2002, Gavin Atkinson wrote: hi, FreeBSD epsilon.ury.york.ac.uk 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Fri Jul 26 13:32:52 BST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/EPSILON i386 Had this panic twice with current -current on an uniprocessor machine and kernel. Dumps still don't work... Both occurances, i had an ssh running, a portupgrade in progress, and the dnetc client running in the background. how new is the kernel? When you created it did you make sure you deleted all .o files first? panic: KSE not on run queue panic: from debugger Uptime: 1d1h26m12s Dumping 127 MB ata0: resetting devices .. panic: mi_switch: switch in a critical section Uptime: 1d1h26m12s panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized Uptime: 1d1h26m12s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 1d1h26m12s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 1d1h26m12s ...etc... traceback from ddb is: panic runq_remove remrunqueue schedcpu softclock thread_loop forkexit forktrampoline I'll check it in a while but the fact that only you cave sen thid does suggest that maybe you have some mixed versions or something Thanks Gavin 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
One more -CURRENT panic for collection
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc02297ba in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc022996d in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc025db3b in bwrite (bp=0xcd233954) at /usr/src/sys/kern/vfs_bio.c:797
#4 0xc025ee8d in vfs_bio_awrite (bp=0xcd233954)
at /usr/src/sys/kern/vfs_bio.c:1637
#5 0xc01ff734 in spec_fsync (ap=0xd4a5fb20)
at /usr/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc01ff323 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc032ab9d in ffs_sync (mp=0xc2d26a00, waitfor=2, cred=0xc1591e80,
td=0xc0433440) at vnode_if.h:463
#8 0xc026cdfc in sync (td=0xc0433440, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:127
#9 0xc0229479 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#10 0xc022996d in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#11 0xc037d527 in trap_fatal (frame=0xd4a5fc5c, eva=36)
at /usr/src/sys/i386/i386/trap.c:846
#12 0xc037d26b in trap_pfault (frame=0xd4a5fc5c, usermode=0, eva=36)
at /usr/src/sys/i386/i386/trap.c:760
#13 0xc037cdad in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1070892264, tf_esi = 36, tf_ebp =
-727319384, tf_isp = -727319416, tf_ebx = -1023440640, tf_edx = -1069680824, tf_ecx =
0, tf_eax = 36, tf_trapno = 12, tf_err = 0, tf_eip = -1071509409, tf_cs = 8, tf_eflags
= 66195, tf_esp = -1051034432, tf_ss = -1069269556})
at /usr/src/sys/i386/i386/trap.c:446
#14 0xc03704e8 in calltrap () at {standard input}:98
#15 0xc02212b5 in _mtx_lock_sleep (m=0x24, opts=0, file=0x0, line=0)
at /usr/src/sys/kern/kern_mutex.c:598
#16 0xc02b7b4d in tcp_timer_2msl (xtp=0xc31ee590)
at /usr/src/sys/netinet/tcp_timer.c:212
#17 0xc023338b in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:187
#18 0xc02198fc in ithread_loop (arg=0xc1593900)
at /usr/src/sys/kern/kern_intr.c:535
#19 0xc0218e1d in fork_exit (callout=0xc0219788 ithread_loop,
arg=0xc1593900, frame=0xd4a5fd48) at /usr/src/sys/kern/kern_fork.c:861
--
Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: system crashes; reboots when printing
On Sat, 2002-07-27 at 00:21, David Wolfskill wrote: From: karl agee [EMAIL PROTECTED] Date: 26 Jul 2002 20:44:24 -0700 If this is a networked printer, then you'll probably want to use lpr but skip apsfilter. Excuse my newbie ignorance, but, how to do print a file bypassing lpr and apsfilter For a directly-connected (i.e., attached via parallel or serial port) printer, just use cp to copy the file to the device (special file, such as /dev/lpt). David: Yes, this printer is directly connected parallel port. It worked 8-) I was able to print a simple ps file directly to the printer w/o crashing!!! Ok, so now_what..?? --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: system crashes; reboots when printing
Quoting karl agee [EMAIL PROTECTED]: | | Excuse my newbie ignorance, but, how to do print a file bypassing lpr | and apsfilter How about # cat file_to_print.ps /dev/lpt0 or # cp file_to_pring.ps /dev/lpt0 ed - http://worldinternet.org - Mergence of Business and Technology To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: system crashes; reboots when printing
On Sat, 2002-07-27 at 09:25, karl agee wrote to recap: system: FreeBSD enterprise.workgroup 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Jul 23 16:07:44 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWKERNEL i386 trying to print to a post script laser printer which works fine in the past. setup using apsfilter. When I attempt to print any file from any program the desktop locks up then the system reboots. why? I havent found any log messages when this happens. If I copy a .ps file directly to the printer it prints ok. I've updated ghostscript and that didnt work. I tried running apsfilter again and when I tried printing the test page it crashed. So the problem apsfilter? I recently (last week) upgraded apsfilterdidnt have this problem, should I drop back to the older version any other ideas --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: system crashes; reboots when printing
Here's the salient section of my printcap made up by apsfilter; what should I edit here?? # APS1_BEGIN:printer1 # - don't delete start label for apsfilter printer1 # - no other printer defines between BEGIN and END LABEL lp|ljet2p;r=600x600;q=high;c=gray;p=letter;m=auto:\ :lp=/dev/lpt0:\ :if=/usr/local/etc/apsfilter/basedir/bin/apsfilter:\ :sd=/var/spool/lpd/lp:\ :lf=/var/spool/lpd/lp/log:\ :af=/var/spool/lpd/lp/acct:\ :mx#0:\ :sh: # APS1_END - don't delete this To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
printing woes: PROBLEM IDENTIFIED
I've located the source of my printing problems: It's the kernel. I was able to boot into my orig 5.0-DP1 kernel, I redid the printer config using apsfilter and I can print w/o problems to my hearts content. If I boot into my new kernel (source installed last monday nite) and attempt to print it crashes instantly. So there's a problem with the -current kernel. Anyone else seen this?? (I've contributed somewhat to freebsd development...I'm so proud..) --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
