panic: don't do that, in ugen(4)
Running `quickcam' twice from: http://people.freebsd.org/~jmallett/qce-freebsd.tgz Yields the following loveliness: %%% Script started on Tue May 27 17:59:35 2003 ([EMAIL PROTECTED]:~)1% gdb -k /boot/kernel/kernel 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... (no debugging symbols found)... panic: bremfree: removing a buffer not on a queue panic messages: --- panic: don't do that syncing disks, buffers remaining... 1806 panic: bremfree: removing a buffer not on a queue Uptime: 6m34s Dumping 191 MB ata0: resetting devices .. ata0: pre reset mask=03 ostat0=50 ostat2=00 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0: devices=01 ad0: success setting BIOSPIO on Intel PIIX4 chip done ad0: timeout waiting for DRQata0: resetting devices .. ata0: pre reset mask=03 ostat0=d0 ostat2=d0 ad0: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: after reset mask=03 stat0=50 stat1=00 ad0: ATA 01 a5 ata0-slave: ATA 01 a5 ata0: devices=03 ata0-slave: timeout waiting for cmd=ec s=00 e=00 ata0-slave: ATA identify failed ad0: success setting BIOSPIO on Intel PIIX4 chip done 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /boot/kernel/acpi.ko...(no debugging symbols found)... done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/logo_saver.ko... (no debugging symbols found)...done. Loaded symbols for /boot/kernel/logo_saver.ko #0 0xc030d6eb in doadump () (kgdb) bt #0 0xc030d6eb in doadump () #1 0xc030dd13 in boot () #2 0xc030e05b in panic () #3 0xc0351e12 in bremfreel () #4 0xc0351cf5 in bremfree () #5 0xc0355397 in getblk () #6 0xc0351ef2 in breadn () #7 0xc0351e9c in bread () #8 0xc04273d2 in ffs_update () #9 0xc043bc5f in ffs_fsync () #10 0xc043acfe in ffs_sync () #11 0xc03677fb in sync () #12 0xc030d92d in boot () #13 0xc030e05b in panic () #14 0xc02ede12 in destroy_dev () #15 0xc02a369f in ugen_destroy_devnodes () #16 0xc02a48db in ugen_set_interface () #17 0xc02a4e2c in ugen_do_ioctl () #18 0xc02a5367 in ugenioctl () #19 0xc02d538e in spec_ioctl () #20 0xc02d4ac8 in spec_vnoperate () #21 0xc036fbe1 in vn_ioctl () #22 0xc0334098 in ioctl () #23 0xc049a27e in syscall () ---Type return to continue, or q return to quit--- #24 0xc04896ed in Xint0x80_syscall () ---Can't read userspace from dump, or kernel process--- ([EMAIL PROTECTED]:~)2% uname -a FreeBSD big-lizard.backyard.newgold.net 5.1-BETA-20030522-JPSNAP FreeBSD 5.1-BETA-20030522-JPSNAP #0: Thu May 22 00:15:14 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Script done on Tue May 27 18:01:06 2003 %%% Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: don't do that, in ugen(4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 28 May 2003 00:06 am, Juli Mallett wrote: Running `quickcam' twice from: http://people.freebsd.org/~jmallett/qce-freebsd.tgz Yields the following loveliness: [..] This is the same issue another person (Mark Blackman) is seeing with the Speedtouch software. I submitted a patch to the kernel recently which alleviated the problem for me (and others), but Mark is still having problems (albeit slightly different since the patch) with ugen_set_interface panicing inside /sys/dev/usb/ugen.c. I'll be looking into this either tomorrow or the next day, to try to work out how it's still occurring and fix it. If anyone else decides to take a look, it may help to see the patch recently committed to ugen.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/ugen.c.diff?r1=1.69r2=1.70f=h It's related to the way ugen treats device nodes since; since devfs was introduced into the kernel, there have been stricter rules on how the kernel can manipulate device nodes, and ugen.c is (apparently) still breaking these rules. Cheers, Jay - -- http://www.evilrealms.net/ - Systems Administrator Developer http://www.ic.ac.uk/ - Imperial College, 2nd year CS student -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+1AgffJLn3O/2GbERAjlrAKCxOMROjqZdSKHmYoywNt/85JQW4gCbBAQO OT6Z2VJGht+J1gctuWLZqN4= =M6D7 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: panic: don't do that ?]
On Wed, Feb 12, 2003 at 12:23:53AM +0100, David Vidal Rodr?guez wrote:
Hi,
1)
If they aren't loaded (I forgot them on the 1st try by mistake), the
kernel panics if I try to change hw.snd.maxautovchans (that odd bwrite:
buffer is not busy??? message again!). That shouldn't happen: if I
don't have any soundcards, this oid shouldn't _exist_ either!
I'm afraid I don't know anything about that. The oid doesn't exist for
me if I don't load the kernel module.
2)
If they're loaded, an attempt to unload snd_via82c686.ko results in a
panic with the funny message in the subject. But: Aren't modules
supposed to be unloadable? What's the fun with modules then?
I believe it has been fixed on -CURRENT. You may try this patch :
http://people.FreeBSD.org/~cognet/sound.c.diff
Any hints on solving this?
My attempt to load modules instead of the monolithic solution (which
always works) comes due to an odd behaviour of pcm0 (multiplexed with
hw.snd.pcm0.vchans=8) telling that some /dev/dsp{W,}0.[0-7] devices are
busy after their first usage. I wanted to address it by unloading the
affected module and loading it again, but... that'll panic the system.
AFAIK, The device being busy issue is fixed by Brian Feldman's recent commit.
You can find the patch here :
http://people.FreeBSD.org/~cognet/dsp.c.diff
Cheers,
Olivier Houchard
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [Fwd: panic: don't do that ?]
Olivier Houchard wrote: I'm afraid I don't know anything about that. The oid doesn't exist for me if I don't load the kernel module. That's my fault for being imprecise. I forgot to mention that I had snd_pcm.ko loaded, but nothing else. I believe it has been fixed on -CURRENT. You may try this patch : http://people.FreeBSD.org/~cognet/sound.c.diff Thanks for the patch, I'll try it. AFAIK, The device being busy issue is fixed by Brian Feldman's recent commit. You can find the patch here : http://people.FreeBSD.org/~cognet/dsp.c.diff Thanks for this one also, will test both. CU, David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Fwd: panic: don't do that ?]
Olivier Houchard wrote: Ooops sorry. They have to be applied in /sys/dev/sound/pcm. My bad, next time I'll make them against /usr/src :) Thanks! That did the trick. Where I have to keep an eye is to the device busy problem, since it doesn't appear immediately. CU, David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Fwd: panic: don't do that ?]
Hi!
I've sent this post to comp.unix.bsd.freebsd, and I've been told that I
should report the problem to this list, so...
Original Message
Hi folks!
I was trying to modularize the sound in my 5.0R machine, which has two
sound cards:
$ dmesg | grep pcm.:
pcm0: VIA VT82C686A port 0xb000-0xb003,0xb400-0xb403,0xb800-0xb8ff irq
9 at device 4.5 on pci0
pcm1: AudioPCI ES1373-B port 0xa000-0xa03f irq 9 at device 10.0 on pci0
In order for them to work properly as modules, the files
snd_{pcm,via82c686,es137x}.ko have to be loaded in the beginning AFAIK.
Or else they won't be recognized and will be given as PCI devices with
no driver attached.
Well, two issues:
1)
If they aren't loaded (I forgot them on the 1st try by mistake), the
kernel panics if I try to change hw.snd.maxautovchans (that odd bwrite:
buffer is not busy??? message again!). That shouldn't happen: if I
don't have any soundcards, this oid shouldn't _exist_ either!
2)
If they're loaded, an attempt to unload snd_via82c686.ko results in a
panic with the funny message in the subject. But: Aren't modules
supposed to be unloadable? What's the fun with modules then?
Any hints on solving this?
My attempt to load modules instead of the monolithic solution (which
always works) comes due to an odd behaviour of pcm0 (multiplexed with
hw.snd.pcm0.vchans=8) telling that some /dev/dsp{W,}0.[0-7] devices are
busy after their first usage. I wanted to address it by unloading the
affected module and loading it again, but... that'll panic the system.
Has someone had something similar?
Thanks in advance,
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
panic: don't do that
Hi, After a migration of a complete / Filesystem with dump - restore. I made the mistake to already have a small new system on the new disk. So I decided to do a # cd / # restore urf root.dump I got at the end: /dev/ad0d: cannot create special file: File exists WARNING: Driver mistake: repeat make_dev(ad0s1) panic: don't do that Debugger(panic) Is this really a Driver mistake ? Or am I mistaken ? I guess we should do a # chflags nodump /dev during the install on CURRENT. Why has been /dev dumped anyway ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: don't do that
On Tue, 8 Jan 2002, Martin Blapp wrote: ... during the install on CURRENT. Why has been /dev dumped anyway ? I bet you have old /dev entries as a fallback left which got backed up. What do you see on a unmounted /dev? Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: don't do that
Hi, during the install on CURRENT. Why has been /dev dumped anyway ? I bet you have old /dev entries as a fallback left which got backed up. I guess no. This was a fresh CURRENT installation from November 2001. What do you see on a unmounted /dev? devfs cannot be unmounted as I know. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
