Re: GEOM/vinum compatibility (was: vinum lock panic at startup-current)
On Sat, Aug 09, 2003 at 06:38:51AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: and it seems that vinum does not respect the D_NOGIANT flag which GEOM recently started setting. Probably because it didn't know about it. As I've said before, it would be nice to be informed about the changes you're making, particularly given your stated intention of doing no work on Vinum. I had the choice between supporting sos@ effort to de-Giantize ATA or wait for the non-maintainer of vinum to possibly react to his email Come on.. a bit of politeness goes a long way.. so I chose the former as being more beneficial to the project. W/ -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum lock panic at startup -current
On Thursday, 7 August 2003 at 18:23:10 -0600, Aaron Wohl wrote: I just cvsuped -current this afternoon to get about 1 weeks updates. After that the kernel panics booting starting vinum. I removed the one vinum volume (reformated as UFS2) I had for testing. And it still panics. I changed the /etc/rc.conf start_vinum=YES to NO and can start ok now. Anyone else seeing this? Is there a fix for it? This panic actually happens in GEOM. I believe there were some questions about GEOM recently, but I haven't had any reply yet from phk to my last question on the issue. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: vinum lock panic at startup -current
On Fri, Aug 08, 2003 at 10:22:06AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Aaron Wohl writes: I just cvsuped -current this afternoon to get about 1 weeks updates. After that the kernel panics booting starting vinum. I removed the one vinum volume (reformated as UFS2) I had for testing. And it still panics. I changed the /etc/rc.conf start_vinum=YES to NO and can start ok now. What was the actual panic message ? Would http://people.freebsd.org/~erwin/koala.trace2 be related ? This happens after a couple of hours of activity, things are fine again after reboot (for a while) on 5-1-RELEASE. -- _._ _,-'`-._ Erwin Lansing (,-.`._,'( |\`-/|[EMAIL PROTECTED] http://droso.org `-.-' \ )-`( , o o)[EMAIL PROTECTED] -bf- `-\`_`'- pgp0.pgp Description: PGP signature
vinum lock panic at startup -current
I just cvsuped -current this afternoon to get about 1 weeks updates.
After that the kernel panics booting starting vinum. I removed the one
vinum volume (reformated as UFS2) I had for testing. And it still panics.
I changed the /etc/rc.conf
start_vinum=YES to NO and can start ok now.
Anyone else seeing this? Is there a fix for it?
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc030e4d2 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc030e828 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc030535c in _mtx_assert (m=0xc05f5820, what=0, file=0xc052eb22
/usr/src/sys/geom/geom_dev.c, line=198)
at /usr/src/sys/kern/kern_mutex.c:855
#4 0xc02d613f in g_dev_open (dev=0xc6, flags=-1068307678, fmt=0, td=0x0)
at /usr/src/sys/geom/geom_dev.c:198
#5 0xc763d3b6 in open_drive (drive=0xc05f5820, td=0xc75f85f0, verbose=0)
at /usr/src/sys/dev/vinum/vinumio.c:69
#6 0xc763d61b in init_drive (drive=0xc6, verbose=-1068307678) at
/usr/src/sys/dev/vinum/vinumio.c:138
#7 0xc763da62 in read_drive_label (drive=0xc6, verbose=0) at
/usr/src/sys/dev/vinum/vinumio.c:291
#8 0xc763dbf4 in check_drive (devicename=0x0) at
/usr/src/sys/dev/vinum/vinumio.c:341
#9 0xc763e8d6 in vinum_scandisk (devicename=0xc75ea2f0 ad2 ad1 ad0) at
/usr/src/sys/dev/vinum/vinumio.c:787
#10 0xc763f58e in vinum_super_ioctl (dev=0xc7614700, cmd=0,
data=0xc73f8000 ) at /usr/src/sys/dev/vinum/vinumioctl.c:309
#11 0xc763eef6 in vinumioctl (dev=0x0, cmd=3288352331, data=0xc73f8000
, flag=3, td=0xc75f85f0)
at /usr/src/sys/dev/vinum/vinumioctl.c:80
#12 0xc02d404e in spec_ioctl (ap=0xc73f8000) at
/usr/src/sys/fs/specfs/spec_vnops.c:346
#13 0xc02d3698 in spec_vnoperate (ap=0x0) at
/usr/src/sys/fs/specfs/spec_vnops.c:122
#14 0xc0375fe1 in vn_ioctl (fp=0xc760c198, com=3288352331,
data=0xc73f8000, active_cred=0xc21cc280, td=0xc75f85f0)
at vnode_if.h:503
#15 0xc0335f05 in ioctl (td=0xc75f85f0, uap=0xe4cd5d10) at
/usr/src/sys/sys/file.h:261
#16 0xc04d4f73 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 1, tf_ebp
= -1077938088, tf_isp = -456303244, tf_ebx = -1077938032, tf_edx =
135189408, tf_ecx = 11, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134704511, tf_cs = 31, tf_eflags = 582, tf_esp =
-1077939172, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1008
#17 0xc04c535d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum lock panic at startup -current
In message [EMAIL PROTECTED], Aaron Wohl writes: Panicstring: mutex Giant owned at /usr/src/sys/geom/geom_dev.c:198 Ok, then I think I know what it is. Vinum appearantly does not go through SPECFS but rather calls into the disk device drivers directly. That is a pretty wrong thing to do, and it seems that vinum does not respect the D_NOGIANT flag which GEOM recently started setting. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum lock panic at startup -current
Its wierd though that it works on intel/p4 but gets taht panic: Giant on amd... My 2 amd systems panic with vinum start but the P4 works ok built from the same sources. All with no vinum volumes, just trying vinum start t test for this bug. - Original message - From: Poul-Henning Kamp [EMAIL PROTECTED] To: Aaron Wohl [EMAIL PROTECTED] Date: Fri, 08 Aug 2003 15:24:09 +0200 Subject: Re: vinum lock panic at startup -current In message [EMAIL PROTECTED], Aaron Wohl writes: Panicstring: mutex Giant owned at /usr/src/sys/geom/geom_dev.c:198 Ok, then I think I know what it is. Vinum appearantly does not go through SPECFS but rather calls into the disk device drivers directly. That is a pretty wrong thing to do, and it seems that vinum does not respect the D_NOGIANT flag which GEOM recently started setting. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum lock panic at startup -current
In message [EMAIL PROTECTED], Aaron Wohl writes: I just cvsuped -current this afternoon to get about 1 weeks updates. After that the kernel panics booting starting vinum. I removed the one vinum volume (reformated as UFS2) I had for testing. And it still panics. I changed the /etc/rc.conf start_vinum=YES to NO and can start ok now. What was the actual panic message ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
GEOM/vinum compatibility (was: vinum lock panic at startup -current)
On Friday, 8 August 2003 at 15:24:09 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Aaron Wohl writes: Panicstring: mutex Giant owned at /usr/src/sys/geom/geom_dev.c:198 Ok, then I think I know what it is. Vinum appearantly does not go through SPECFS but rather calls into the disk device drivers directly. That is a pretty wrong thing to do, It used to be the standard. What's the issue? and it seems that vinum does not respect the D_NOGIANT flag which GEOM recently started setting. Probably because it didn't know about it. As I've said before, it would be nice to be informed about the changes you're making, particularly given your stated intention of doing no work on Vinum. Could you please give details (privately if you want, but I think this could be of interest to other people too). Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: vinum lock panic at startup -current
I tried it this morning on different systems. So far the two AMD systems panic with vinum start and the intel/p4 works ok. All systems have no vinum volumes currently. Good dump found on device /dev/ad0s1b Architecture: i386 Architecture version: 1 Dump length: 1073676288B (1023 MB) Blocksize: 512 Dumptime: Fri Aug 8 05:28:09 2003 Hostname: [edited] Versionstring: FreeBSD 5.1-CURRENT #0: Thu Aug 7 12:02:25 MDT 2003 [EMAIL PROTECTED] out]:/usr/obj/usr/src/sys/ROUTER5 Panicstring: mutex Giant owned at /usr/src/sys/geom/geom_dev.c:198 Bounds: 3 On Fri, 08 Aug 2003 10:22:06 +0200, Poul-Henning Kamp [EMAIL PROTECTED] said: In message [EMAIL PROTECTED], Aaron Wohl writes: I just cvsuped -current this afternoon to get about 1 weeks updates. After that the kernel panics booting starting vinum. I removed the one vinum volume (reformated as UFS2) I had for testing. And it still panics. I changed the /etc/rc.conf start_vinum=YES to NO and can start ok now. What was the actual panic message ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM/vinum compatibility (was: vinum lock panic at startup-current)
In message [EMAIL PROTECTED], Greg 'groggy' Lehey writes: and it seems that vinum does not respect the D_NOGIANT flag which GEOM recently started setting. Probably because it didn't know about it. As I've said before, it would be nice to be informed about the changes you're making, particularly given your stated intention of doing no work on Vinum. I had the choice between supporting sos@ effort to de-Giantize ATA or wait for the non-maintainer of vinum to possibly react to his email so I chose the former as being more beneficial to the project. Could you please give details (privately if you want, but I think this could be of interest to other people too). See sys/fs/specfs/specfs_vnops.c, that is probably faster. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum lock panic at startup -current
On Friday, 8 August 2003 at 10:27:31 +0200, Erwin Lansing wrote: On Fri, Aug 08, 2003 at 10:22:06AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Aaron Wohl writes: I just cvsuped -current this afternoon to get about 1 weeks updates. After that the kernel panics booting starting vinum. I removed the one vinum volume (reformated as UFS2) I had for testing. And it still panics. I changed the /etc/rc.conf start_vinum=YES to NO and can start ok now. What was the actual panic message ? Would http://people.freebsd.org/~erwin/koala.trace2 be related ? Hmm. I haven't seen this one before. This happens after a couple of hours of activity, things are fine again after reboot (for a while) on 5-1-RELEASE. This is a very different backtrace from the last one you showed me. Can I take a look at the dump? The easiest way would be to access it on your system, if that's possible. I have a horrible feeling it's going to be a memory corruption bug. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
