Re: vinum problems with todays current
Greg 'groggy' Lehey wrote:
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
Can you try this patch:
...
I noticed I had an older version of spec_vnops.c (1.205), so I
cvsupped again and build kernel, this gave me the same msgbuf error,
but with different values. Then I applied your patch and the error
messgae disapeared, but still my vinum doesn't come up.
Can I assume that this is related to GEOM, and not to Vinum?
Greg
--
See complete headers for address and phone numbers
After investigating a little further today, I found the config info on
the drives to be mangled.
--
# rm -f log
# for i in /dev/da0s1h /dev/da1s1h /dev/da2s1h /dev/da3s1h; do
(dd if=$i skip=8 count=6|tr -d '\000-\011\200-\377'; echo) log
done
# cat log
IN VINOx-server.debank.tvbCc3??Z${m5?
IN VINOx-server.debank.tvaC3?WPZ${m5?
--
I guess the drives can't be started again unless I have the parameters
which I used during install (please say I'm wrong).
Rob Evers
--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
vinum problems with todays current
Hi all, After cvs'upping (about 12 hours ago) and building world/kernel vinum stopped working. It does show my two disks but nothing more. I also get an error message right after the bootloader: msgbuf cksum mismatch (read a5886, calc a5efb) -- The output of vinum: vinum - list 2 drives: D b State: up /dev/ad6s1e A: 77903/77903 MB (100%) D a State: up /dev/ad4s1e A: 77903/77903 MB (100%) 0 volumes: 0 plexes: 0 subdisks: --- slopuh# uname -a FreeBSD slopuh.debank.tv 5.1-CURRENT FreeBSD 5.1-CURRENT #20: Tue Aug 5 20:13:13 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SLOPUH i386 I don't have debugging configured in the kernel, but can recompile if usefull. Anyone with the same problems and/or ideas ? Rob Evers -- It is a book about a Spanish guy called Manual. You should read it. -- Dilbert ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum problems with todays current
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Rob writes: Hi all, After cvs'upping (about 12 hours ago) and building world/kernel vinum stopped working. It does show my two disks but nothing more. I also get an error message right after the bootloader: Can you try this patch: ... I noticed I had an older version of spec_vnops.c (1.205), so I cvsupped again and build kernel, this gave me the same msgbuf error, but with different values. Then I applied your patch and the error messgae disapeared, but still my vinum doesn't come up. Can I assume that this is related to GEOM, and not to Vinum? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: vinum problems with todays current
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
Can you try this patch:
Index: spec_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/specfs/spec_vnops.c,v
retrieving revision 1.206
diff -u -r1.206 spec_vnops.c
--- spec_vnops.c5 Aug 2003 06:43:56 - 1.206
+++ spec_vnops.c5 Aug 2003 19:33:06 -
@@ -505,9 +505,9 @@
devtoname(bp-b_dev), bp));
if ((dsw-d_flags D_NOGIANT) !(bp-b_flags B_KEEPGIANT)) {
- DROP_GIANT();
+ /* DROP_GIANT(); */
DEV_STRATEGY(bp);
- PICKUP_GIANT();
+ /* PICKUP_GIANT(); */
} else
DEV_STRATEGY(bp);
Hi Poul,
I noticed I had an older version of spec_vnops.c (1.205), so I
cvsupped again and build kernel, this gave me the same msgbuf error,
but with different values. Then I applied your patch and the error
messgae disapeared, but still my vinum doesn't come up.
vinum - list
2 drives:
D b State: up /dev/ad6s1e A: 77903/77903
MB (100%)
D a State: up /dev/ad4s1e A: 77903/77903
MB (100%)
0 volumes:
0 plexes:
0 subdisks:
If you need additional info, I'll be glad to provide such.
Rob Evers
--
It is a book about a Spanish guy called Manual. You should read it.
-- Dilbert
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum problems with todays current
On Friday, 8 August 2003 at 16:04:05 +0200, Rob wrote:
Greg 'groggy' Lehey wrote:
On Tuesday, 5 August 2003 at 22:21:41 +0200, Rob wrote:
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
Can you try this patch:
I noticed I had an older version of spec_vnops.c (1.205), so I
cvsupped again and build kernel, this gave me the same msgbuf error,
but with different values. Then I applied your patch and the error
messgae disapeared, but still my vinum doesn't come up.
Can I assume that this is related to GEOM, and not to Vinum?
After investigating a little further today, I found the config info
on the drives to be mangled.
--
# rm -f log
# for i in /dev/da0s1h /dev/da1s1h /dev/da2s1h /dev/da3s1h; do
(dd if=$i skip=8 count=6|tr -d '\000-\011\200-\377'; echo) log
done
# cat log
IN VINOx-server.debank.tvbCc3??Z${m5?
IN VINOx-server.debank.tvaC3?WPZ${m5?
--
I guess the drives can't be started again unless I have the
parameters which I used during install (please say I'm wrong).
Hmm. That doesn't look good. No trace of the original config?
Greg
--
See complete headers for address and phone numbers
pgp0.pgp
Description: PGP signature
Re: vinum problems with todays current
In message [EMAIL PROTECTED], Rob writes:
Hi all,
After cvs'upping (about 12 hours ago) and building world/kernel vinum
stopped working. It does show my two disks but nothing more. I also
get an error message right after the bootloader:
Can you try this patch:
Index: spec_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/specfs/spec_vnops.c,v
retrieving revision 1.206
diff -u -r1.206 spec_vnops.c
--- spec_vnops.c5 Aug 2003 06:43:56 - 1.206
+++ spec_vnops.c5 Aug 2003 19:33:06 -
@@ -505,9 +505,9 @@
devtoname(bp-b_dev), bp));
if ((dsw-d_flags D_NOGIANT) !(bp-b_flags B_KEEPGIANT)) {
- DROP_GIANT();
+ /* DROP_GIANT(); */
DEV_STRATEGY(bp);
- PICKUP_GIANT();
+ /* PICKUP_GIANT(); */
} else
DEV_STRATEGY(bp);
--
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 problems
Bernd, This sounds very promising, but I want to make sure I do this correctly. When you say to remove the plexes, that means to use 'vinum rm' with appropriate options, correct? As far as reconfiguring, can I use the output from 'vinum printconfig' as the input configuration file? Thanks very much for your help. -Patrick Bernd Walter wrote: On Fri, Apr 12, 2002 at 05:46:29PM -0500, Patrick Hartling wrote: I suffered a system crash earlier today running -current from April 10. I have a Vinum volume set up as a mirror, and during the reboot, I had to fsck it. Everything seemed normal (at least that's what I thought), but now my volume cannot be mounted. The output from 'vinum list' is as follows: 2 drives: D a State: up /dev/da3s1e A: 0/12288 MB (0%) D b State: up /dev/da4s1e A: 0/12288 MB (0%) 1 volumes: V mirrorState: down Plexes: 2 Size: 11 GB 2 plexes: P mirror.p0 C State: faulty Subdisks: 1 Size: 11 GB P mirror.p1 C State: faulty Subdisks: 1 Size: 11 GB 2 subdisks: S mirror.p0.s0 State: crashed D: aSize: 11 GB S mirror.p1.s0 State: crashed D: bSize: 11 GB The fact that it says the drives have 0% used greatly concerns me. Before I delve into this any further, is that a sign that everything I had is just gone? Or is there some hope of recovery? There is nothing in /var/log/vinum_hitsory or /var/log/messages that gives me any insight into what went wrong. You have *both* plexes faulty which means that you either have waited too long running with only one disk left or that both failed a once. For the second point can be channel or power supply issues if they share a single resource in common. You will find it out by reading your log files. Of course you should fix the failure reason before doing anything else. I have made a bad expirience once in that if you revive one plex now you will get zeros written because there is no reference plex left. Greg: It's long ago but I forgot to tell you. Do you remember anything about such a bug got fixed? The shure way is to store the vinum printconfig output and then remove both plexes. finaly reconfigure them both beginning using the values from printconfig and start with the drive which run at last, because it has the most recent data. -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum problems
On Mon, Apr 15, 2002 at 04:08:43PM -0500, Patrick Hartling wrote: Bernd, This sounds very promising, but I want to make sure I do this correctly. When you say to remove the plexes, that means to use 'vinum rm' with appropriate options, correct? As far as reconfiguring, can I use the output from 'vinum printconfig' as the input configuration file? Thanks very much for your help. You have to reduce the printconfig output to configure only the plex with the reference data first. Once it's mountable you can add the second plex as well. And don't forget to look for the reason it failed originaly. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum problems
On Fri, Apr 12, 2002 at 05:46:29PM -0500, Patrick Hartling wrote: I suffered a system crash earlier today running -current from April 10. I have a Vinum volume set up as a mirror, and during the reboot, I had to fsck it. Everything seemed normal (at least that's what I thought), but now my volume cannot be mounted. The output from 'vinum list' is as follows: 2 drives: D a State: up /dev/da3s1e A: 0/12288 MB (0%) D b State: up /dev/da4s1e A: 0/12288 MB (0%) 1 volumes: V mirrorState: down Plexes: 2 Size: 11 GB 2 plexes: P mirror.p0 C State: faulty Subdisks: 1 Size: 11 GB P mirror.p1 C State: faulty Subdisks: 1 Size: 11 GB 2 subdisks: S mirror.p0.s0 State: crashed D: aSize: 11 GB S mirror.p1.s0 State: crashed D: bSize: 11 GB The fact that it says the drives have 0% used greatly concerns me. Before I delve into this any further, is that a sign that everything I had is just gone? Or is there some hope of recovery? There is nothing in /var/log/vinum_hitsory or /var/log/messages that gives me any insight into what went wrong. You have *both* plexes faulty which means that you either have waited too long running with only one disk left or that both failed a once. For the second point can be channel or power supply issues if they share a single resource in common. You will find it out by reading your log files. Of course you should fix the failure reason before doing anything else. I have made a bad expirience once in that if you revive one plex now you will get zeros written because there is no reference plex left. Greg: It's long ago but I forgot to tell you. Do you remember anything about such a bug got fixed? The shure way is to store the vinum printconfig output and then remove both plexes. finaly reconfigure them both beginning using the values from printconfig and start with the drive which run at last, because it has the most recent data. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Vinum problems
I suffered a system crash earlier today running -current from April 10. I have a Vinum volume set up as a mirror, and during the reboot, I had to fsck it. Everything seemed normal (at least that's what I thought), but now my volume cannot be mounted. The output from 'vinum list' is as follows: 2 drives: D a State: up /dev/da3s1e A: 0/12288 MB (0%) D b State: up /dev/da4s1e A: 0/12288 MB (0%) 1 volumes: V mirrorState: down Plexes: 2 Size: 11 GB 2 plexes: P mirror.p0 C State: faulty Subdisks: 1 Size: 11 GB P mirror.p1 C State: faulty Subdisks: 1 Size: 11 GB 2 subdisks: S mirror.p0.s0 State: crashed D: aSize: 11 GB S mirror.p1.s0 State: crashed D: bSize: 11 GB The fact that it says the drives have 0% used greatly concerns me. Before I delve into this any further, is that a sign that everything I had is just gone? Or is there some hope of recovery? There is nothing in /var/log/vinum_hitsory or /var/log/messages that gives me any insight into what went wrong. -Patrick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
Julian Elischer wrote: If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. It's not his only accomplishment. He also helped kill LFS by moving it to the attic, and killed block devices, even though we know that the Apple DVD code needed both block and character versions of a disk device to support the DVDFS and the ISO9660FS at the same time. The block device issue is a sore point, since it's now practically impossible to generate tapes with odd byte boundaries instead of full records (thus causing an implicit conv=sysnc, even if you don't want one). I seem to remember you supporting him killing block devices... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Ju lian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. Sure... -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
[Format recovered--see http://www.lemis.com/email/email-format.html] Your MUA wraps incorrectly. On Friday, 17 August 2001 at 9:16:59 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. People, could we please stop this kind of nastiness? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.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
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
Poul-Henning Kamp wrote: Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. Sure... Hardly; many of my VFS patches were designed to make the code more portable... for instance, to Windows 95, where they ran without problems starting ~1995/1996... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Fri, 17 Aug 2001, Terry Lambert wrote: Poul-Henning Kamp wrote: Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. you don't even think it was implolite? Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. Sure... Hardly; many of my VFS patches were designed to make the code more portable... for instance, to Windows 95, where they ran without problems starting ~1995/1996... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Ju lian Elischer writes: On Fri, 17 Aug 2001, Terry Lambert wrote: Poul-Henning Kamp wrote: Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. you don't even think it was implolite? The only thing I found really impolite was that the old-core left the thing hanging in the air for several years. It's OK to have things hanging in the air if it is done on purpose, but it is certainly not OK if it hangs there as function of a somebody-elses-problem field like in this case. I certainly didn't find it any more impolite than committing a barely working or even non-working prototype into the CVS tree and then abandonning it once it worked OK for my immediate needs. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg Lehey writes: On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. Uhm, have you forgotten how ls(1) works ? No. Try this then: ls -lad /dev/fd /dev/fd/[012] Hmm. Strange. Last time I looked, I thought I had /dev/fd0, /dev/fd1 and /dev/fd2. But I've booted a new kernel since that attempt. In view of the fact that this thread is about deficiencies in your devfs, this is particularly uncalled for. One of the reasons that Julian's devfs never got debugged was that you had made it very clear from the start that it would be removed. History being rewritten eh ? I spent 3+ years trying to argue his DEVFS should be made default! They must have been before I met you, then. My very vivid recollection was that I met you at USENIX in New Orleans on 19 June 1998, and the very first thing you said was What does Vinum do about DEVFS? Don't use it, it's going away. We (you, Justin Gibbs, Jonathan Bresler, and I, maybe also one other person, but not Julian, whom you wouldn't let participate) then found an empty room and we discussed the matter. It was an interesting first impression. Greg -- 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
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Greg Lehey writes: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. Uhm, have you forgotten how ls(1) works ? No. Try this then: ls -lad /dev/fd /dev/fd/[012] Hmm. Strange. Last time I looked, I thought I had /dev/fd0, /dev/fd1 and /dev/fd2. But I've booted a new kernel since that attempt. Well that must have been a very very old kernel then, at least if you intend to insist on blaiming DEVFS. See cvs logs. History being rewritten eh ? I spent 3+ years trying to argue his DEVFS should be made default! They must have been before I met you, then. My very vivid recollection was that I met you at USENIX in New Orleans on 19 June 1998, and the very first thing you said was What does Vinum do about DEVFS? Don't use it, it's going away. We (you, Justin Gibbs, Jonathan Bresler, and I, maybe also one other person, but not Julian, whom you wouldn't let participate) then found an empty room and we discussed the matter. It was an interesting first impression. A lot of people, you included, have never quite realized, or maybe just forgotten exactly just how long time Julians DEVFS sat in our tree while people bickered about things like persistence and random panics: src/sys/miscfs/devfs/devfs_vfsops.c: Revision 1.1 Thu Apr 20 03:31:31 1995 UTC (6 years, 3 months ago) by julian After 3 years I gave up on the hope that it would ever be fixed well enough to become politically acceptable. After 6 years I removed it. A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 1999 6 15 30 2000 0 16 8 2001 0 1 7 -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Greg Lehey wrote:
On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Greg Lehey writes:
In view of the fact that this thread is about deficiencies in your
devfs, this is particularly uncalled for. One of the reasons that
Julian's devfs never got debugged was that you had made it very clear
from the start that it would be removed.
History being rewritten eh ? I spent 3+ years trying to argue his
DEVFS should be made default!
They must have been before I met you, then. My very vivid
recollection was that I met you at USENIX in New Orleans on 19 June
1998, and the very first thing you said was What does Vinum do about
DEVFS? Don't use it, it's going away. We (you, Justin Gibbs,
He first sold it to me on Tue, 6 Dec 1994 15:41:55 -0800 (PST). It
seemed like a good idea at the time :-). That sure was a different
time. ref but no freefall (?)...
From [EMAIL PROTECTED] Wed Dec 7 10:45:03 1994
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by godzilla.zeta.org.au
(8.6.9/8.6.9) with ESMTP id KAA24274 for [EMAIL PROTECTED]; Wed, 7 Dec 1994 10:42:08
+1100
Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id PAA10093; Tue, 6 Dec
1994 15:41:55 -0800
From: Poul-Henning Kamp [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Subject: Re: vn.c,v
To: [EMAIL PROTECTED] (Bruce Evans)
Date: Tue, 6 Dec 1994 15:41:55 -0800 (PST)
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED] from Bruce Evans at Dec
7, 94 09:50:43 am
Content-Type: text
Content-Length: 4320
Status: RO
I really miss these functions in the kernel:
void * dev_get_private __P((dev_t));
...
I talked to Julian about his devfs and the above changes might be fallout
from that when all is said and done.
I don't see how you can access the devices without putting them in the
file system. How complete is devfs? How can it handle all the different
meanings of minor numbers? Things like ttyd0 vs cuaa0 probably should
use different majors anyway.
I'm terrible at explaning this stuff, but I will do an attempt now. If
this looks like complete rubbish to you, then I probably didn't explain it
too well, and have better try again.
I have cc'ed the arch list on this, as well as Julian, since it came out
to be quite a general description.
The devfs idea is to implement a filesystem, where the devices present
reflect what the device-drivers told us that they have found, without having
to much around with MAKEDEV,mknod,cdevsw and bdevsw.
So for instance, the fd driver probes and finds a 720 Kb 3.5 drive it would
call something like
/* /dev/???, major, minor */
devfs_register(fd0, 2, 0);
devfs_register(fd0.360, 2, 8);
devfs_register(fd0.720, 2, 7);
...
(Of course the fd0 string would need to be built dynamicly somehow, and
probably we should apply some kind of '%' escapes to help do so)
And the entries will show up in /dev because the devfs maintains a table
fd0 -- (2,0)
Pow! there goes mknod and MAKEDEV.
The devfs doesn't interpret the dev_t's it only maintains the
/dev/foo - dev_t association.
Doing it this way, the entire concept of major/minor numbers can
be dropped from the plan, because a dev_t could just as well be a void *
now.
By having the devfs take care of the registration, the cdevsw/bdevsw
got obsolete, because the device-drivers themselves know their names now,
and the major/minor was only a way to pass information from mknod to the
driver.
This means that a device-driver could register it's softc structure
directly with the devfs, instead of having to look up from the dev_t first.
To make it convenient, we would make the dev_t this instead:
typedef struct {
char*d_name;
struct driver *d_driver;
void*d_private_1;
unsigned long d_private_2;
} * dev_t;
#define dev_private1(dev) (dev-d_private_1)
#define dev_private2(dev) (dev-d_private_2)
#define dev_name(dev) (dev-d_name)
and the register would look like this in fd.c:
/sys/sys/something.h:
struct dev_driver {
char*dev_name;
int (*dev_open) __P((...));
int (*dev_close)__P((...));
int (*dev_ioctl)__P((...));
...
}
fd.c:
/* this is in global scope */
static struct dev_driver {
fd,
fd_open,
fd_close
...
} fd_driver;
/* Ha! we found a drive */
fsc = malloc (sizeof struct fd_softc, M_DEVBUF, M_WAITOK);
fsc-foo = this;
fsc-bar = that;
...
/*/dev/???, private_1, private_2 */
devfs_register(fd_driver, fd0,
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: After 3 years I gave up on the hope that it would ever be fixed well enough to become politically acceptable. After 6 years I removed it. A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- 1999 6 15 30 2000 0 16 8 2001 0 1 7 -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Ju lian Elischer writes: A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
[cc's trimmed] John, Thanks for the suggestion, I appreciate it. I did as you suggested (diff below). It paniced again, but this time savecore said dump time is unreasonable. The short panic message was: panicstr: bremfree: bp 0xcc2a1ae4 not locked Looks like the same thing to me, sorry. Any other suggestions? magpire/sys/kern;diff subr_witness.c subr_witness.c-dist 392a393 mtx_lock(all_mtx); 395d395 mtx_lock(all_mtx); magpire/sys/kern;diff -c subr_witness.c subr_witness.c-dist *** subr_witness.c Thu Aug 16 16:16:06 2001 --- subr_witness.c-dist Thu Aug 16 16:15:20 2001 *** *** 390,398 mtx_unlock_spin(w_mtx); } lock_cur_cnt--; STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); - mtx_lock(all_mtx); lock-lo_flags = ~LO_INITIALIZED; mtx_unlock(all_mtx); } --- 390,398 mtx_unlock_spin(w_mtx); } + mtx_lock(all_mtx); lock_cur_cnt--; STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); lock-lo_flags = ~LO_INITIALIZED; mtx_unlock(all_mtx); } magpire/sys/kern; On Wed, Aug 15, 2001 at 04:42:21PM -0700, John Baldwin wrote: On 15-Aug-01 Michael Lucas wrote: On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote: To help localize this problem, could you please try this same thing on a kernel without devfs? The dump you sent me did not look like a Vinum bug, as I said in my reply. Sorry, it happens on a non-devfs kernel as well. Since it doesn't appear to be a Vinum bug, I'm taking the liberty of sending the whole thing to -current. (I sent my first dump to Greg in particular, since a Vinum command triggered whatever this is.) Script started on Wed Aug 15 17:57:48 2001 magpire/var/crash;file /boot/kernel/vinum.ko /boot/kernel/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped magpire/var/crash;file kernel.debug.nodevfs kernel.debug.nodevfs: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped magpire/var/crash;gdb -k kernel.debug.nodevfs vmcore.3 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd... IdlePTD 4284416 initial pcb at 34b860 panicstr: bremfree: bp 0xcc2a1ae4 not locked Unfortunately this is the panic message from later on during the syncing disks stage, not the real panic. :( #15 0xc01f0783 in witness_destroy (lock=0xc1ec4e68) at #../../../kern/subr_witness.c:395 This is the real problem: mtx_lock(all_mtx); lock_cur_cnt--; STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); lock-lo_flags = ~LO_INITIALIZED; mtx_unlock(all_mtx); It panics in the STAILQ_REMOVE(). I've seen this a couple of times but have no idea how that list pointer is getting corrupted. My guess is that a mutex is being destroyed twice or something dumb like that; however, I'm not sure how. The LO_INITIALIZED flags and checks are supposed to catch that case. I suppose there is a chance we could preempt in between the LO_INITIALIZED check and the actual removal and then free it and get in trouble that way. Hmm. Try moving the mtx_lock of all_mtx before the check for LO_INITIALIZED and see if you can get a different panic. It may be a bug in the ucred stuff. (At least several other panics of this type have been the result of crfree's.) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
On 16-Aug-01 Michael Lucas wrote: [cc's trimmed] John, Thanks for the suggestion, I appreciate it. I did as you suggested (diff below). It paniced again, but this time savecore said dump time is unreasonable. The short panic message was: panicstr: bremfree: bp 0xcc2a1ae4 not locked Looks like the same thing to me, sorry. Any other suggestions? magpire/sys/kern;diff subr_witness.c subr_witness.c-dist 392a393 mtx_lock(all_mtx); 395d395 mtx_lock(all_mtx); magpire/sys/kern;diff -c subr_witness.c subr_witness.c-dist *** subr_witness.c Thu Aug 16 16:16:06 2001 --- subr_witness.c-dist Thu Aug 16 16:15:20 2001 *** *** 390,398 mtx_unlock_spin(w_mtx); } lock_cur_cnt--; STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); - mtx_lock(all_mtx); lock-lo_flags = ~LO_INITIALIZED; mtx_unlock(all_mtx); } --- 390,398 mtx_unlock_spin(w_mtx); } + mtx_lock(all_mtx); lock_cur_cnt--; STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); lock-lo_flags = ~LO_INITIALIZED; mtx_unlock(all_mtx); } magpire/sys/kern; No, no. :) Move the mtx_lock of all_mtx _up_ above the earlier check against LO_INITALIZED. The one that does something liek this: if ((lock-lo_flags LO_INITIALIZED) == 0) panic(); -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: A quick script run on the cvs tree paints this picture of number of commits to src/sys/miscfs/devfs per year: julian phk other 199556 3 15 199620 10 43 199721 13 16 199815 2 24 --at this point SOS and PHK delete half of devfs... Both are in core.. Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. devfs and SLICE were interdependent. By deleting SLICE you basically stopped devfs from being useful in the way I wanted it to be useful and you declared that devfs was also marked for death. In My mind SLICE and DEVFS were two parts of the same project. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thu, 16 Aug 2001, Poul-Henning Kamp wrote: Julian feels he has no avenue of recourse and gives up..-- if (!strcmp(DEVFS, SLICE)) return (ECONFUSED); Julian, you had four years, during which you didn't even manage to make half of the commits made to the DEVFS code during that period. If it is to be counted as my only achivement on -core that I timed out SLICE and DEVFS, I'll still be proud of what I did there. Umm, your timeouts are very strange - you're timed out too quickly in my case. Of course, you're talked something about that GEOM stuff will be committed in July (of 2000) and it needs devfs. But we didn't see it even now. Well, I'm don't mind about waste of my time spent on a design of new devfs. But one can make corresponding conclusions about your timeouts ... -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
+---[ Poul-Henning Kamp ]-- | In message [EMAIL PROTECTED], Andrew Kenneth Milton | writes: | +---[ Greg Lehey ]-- | | | | [snip] | | | whether it's been fixed. Basically, devfs as supplied in CURRENT had | | a 16 character limit on device names, and it didn't understand | | subdirectories: it treated the / as a part of the device name. | | The subdir part bit me about a week ago, so I'd say it's still not fixed. | | This is absolutely news to me. I'm pretty sure that you will find | that /dev/fd[012] exists on your system and that it was created using | '/' in make_dev calls... This I saw, but, I had no idea how this was done.. I've been in a flu induced coma of late, so I didn't really search too hard to be completely honest.. | | More details on this bug are most welcome. The problem turns up most violently within the XFree86 DRI Module, since it now uses make_dev, and not mknod as it used to. The DRI Module first attempts to mkdir /dev/dri/, and then for each card it supports attempts to use make_dev(9) on dri/card%d (0-whatever), I've only got one card, so for me dri/card0. Loading the DRI module causes an instant panic (which I think is actually caused by DRI, not DEVFS, it's still quite inconvenient). The same module works fine with a 'regular' /dev/ Assuming that the mkdirs were failing on /dev/ with DEVFS I made a symlink in rc.devfs for /dev/dri - /usr/dev/dri (that's how I found the bug with directory targets of symlinks being treated as symlinks...). This still caused the panic (which is sort of understandable since /usr/dev/ isn't in /dev/). I remove the mkdirs and simply use make_dev on dri_card0 instead of dri/card0, everything works like a charm. Using mknod also used to work fine with the symlink and DEVFS. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
In message [EMAIL PROTECTED], Andrew Kenneth Milton writes: The problem turns up most violently within the XFree86 DRI Module, since it now uses make_dev, and not mknod as it used to. The DRI Module first attempts to mkdir /dev/dri/, and then for each card it supports attempts to use make_dev(9) on dri/card%d (0-whatever), I've only got one card, so for me dri/card0. It should simply make_dev() dri/card%d, the directory is created by devfs on demand. You should not mkdir(/dev/dri); -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
+---[ Poul-Henning Kamp ]-- | In message [EMAIL PROTECTED], Andrew Kenneth Milton | writes: | | The problem turns up most violently within the XFree86 DRI Module, since | it now uses make_dev, and not mknod as it used to. | | The DRI Module first attempts to mkdir /dev/dri/, and then for each card | it supports attempts to use make_dev(9) on dri/card%d (0-whatever), I've | only got one card, so for me dri/card0. | | It should simply make_dev() dri/card%d, the directory is created | by devfs on demand. You should not mkdir(/dev/dri); Sure, how do you tell at run time whether a system is running DEVFS or not, and whether or not the path you want is devfs (troll mountpoints?). It's possible to run DEVFS, but, setup a jail with a standard /dev/ isn't it? There are going to be other things that assume that /dev/ is just another directory and are going to try to mkdir /dev/foo. Bear in mind this isn't my code, I just wanted it running... d8) I'll remove the mkdirs and leave the make_devs in and see how we go. Are there caveats with make_dev and DEVFS e.g. it only wants relative paths not full paths? -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
In message [EMAIL PROTECTED], Andrew Kenneth Milton writes: +---[ Poul-Henning Kamp ]-- | In message [EMAIL PROTECTED], Andrew Kenneth Milton | writes: | | The problem turns up most violently within the XFree86 DRI Module, since | it now uses make_dev, and not mknod as it used to. | | The DRI Module first attempts to mkdir /dev/dri/, and then for each card | it supports attempts to use make_dev(9) on dri/card%d (0-whatever), I've | only got one card, so for me dri/card0. | | It should simply make_dev() dri/card%d, the directory is created | by devfs on demand. You should not mkdir(/dev/dri); Sure, how do you tell at run time whether a system is running DEVFS or not, if the sysctl variable vfs.devfs.generation exists you're running DEVFS. In the kernel you check the value of the variable devfs_present. There are going to be other things that assume that /dev/ is just another directory and are going to try to mkdir /dev/foo. Just how did you do the mkdir ? From userland ? From the kernel ? I'll remove the mkdirs and leave the make_devs in and see how we go. Are there caveats with make_dev and DEVFS e.g. it only wants relative paths not full paths? relative paths, no '.' entries. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote: On Tuesday, 14 August 2001 at 19:26:09 -0400, Michael Lucas wrote: Before I start generating crash dumps etc., are there any gotchas with Vinum -current? I'm using devfs on a SMP system, upgraded 3 days ago. I get a panic whenever I stripe something. Ah, now you say devfs. Sorry, uh, it is the default these days... I will build a devfs-free kernel after work today and see what happens. Thanks! ==ml -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
+---[ Poul-Henning Kamp ]-- | In message [EMAIL PROTECTED], Andrew Kenneth Milton | writes: | +---[ Poul-Henning Kamp ]-- | | In message [EMAIL PROTECTED], Andrew Kenneth Milton | | writes: | | | | The problem turns up most violently within the XFree86 DRI Module, since | | it now uses make_dev, and not mknod as it used to. | | | | The DRI Module first attempts to mkdir /dev/dri/, and then for each card | | it supports attempts to use make_dev(9) on dri/card%d (0-whatever), I've | | only got one card, so for me dri/card0. | | | | It should simply make_dev() dri/card%d, the directory is created | | by devfs on demand. You should not mkdir(/dev/dri); | | Sure, how do you tell at run time whether a system is running DEVFS or not, | | if the sysctl variable vfs.devfs.generation exists you're running DEVFS. | | In the kernel you check the value of the variable devfs_present. | | There are going to be other things that assume that /dev/ is just another | directory and are going to try to mkdir /dev/foo. | | Just how did you do the mkdir ? From userland ? From the kernel ? In this case it's done from inside a kernel module, which is loaded by the user, i.e. not automatically loaded by XFree. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
the lack of subdirectory support is a pitty. it was a primary design goal in the previous devfs and its disappearance caught me by surprise. (the support I mean) On Wed, 15 Aug 2001, Andrew Kenneth Milton wrote: +---[ Poul-Henning Kamp ]-- | In message [EMAIL PROTECTED], Andrew Kenneth Milton | writes: | +---[ Greg Lehey ]-- | | | | [snip] | | | whether it's been fixed. Basically, devfs as supplied in CURRENT had | | a 16 character limit on device names, and it didn't understand | | subdirectories: it treated the / as a part of the device name. | | The subdir part bit me about a week ago, so I'd say it's still not fixed. | | This is absolutely news to me. I'm pretty sure that you will find | that /dev/fd[012] exists on your system and that it was created using | '/' in make_dev calls... This I saw, but, I had no idea how this was done.. I've been in a flu induced coma of late, so I didn't really search too hard to be completely honest.. | | More details on this bug are most welcome. The problem turns up most violently within the XFree86 DRI Module, since it now uses make_dev, and not mknod as it used to. The DRI Module first attempts to mkdir /dev/dri/, and then for each card it supports attempts to use make_dev(9) on dri/card%d (0-whatever), I've only got one card, so for me dri/card0. Loading the DRI module causes an instant panic (which I think is actually caused by DRI, not DEVFS, it's still quite inconvenient). The same module works fine with a 'regular' /dev/ Assuming that the mkdirs were failing on /dev/ with DEVFS I made a symlink in rc.devfs for /dev/dri - /usr/dev/dri (that's how I found the bug with directory targets of symlinks being treated as symlinks...). This still caused the panic (which is sort of understandable since /usr/dev/ isn't in /dev/). I remove the mkdirs and simply use make_dev on dri_card0 instead of dri/card0, everything works like a charm. Using mknod also used to work fine with the symlink and DEVFS. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[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: devfs and Vinum (was: any -current vinum problems?)
In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd it was a primary design goal in the previous devfs and its disappearance caught me by surprise. (the support I mean) SATIRE The ability to not panic left, right and centre was a primary design goal of this devfs and its absense in the previos devfs caught be by surprise. (The lack of support as well). /SATIRE Julian, I think it would reflect well on you to stop the official mourning at some point in the near future. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote: To help localize this problem, could you please try this same thing on a kernel without devfs? The dump you sent me did not look like a Vinum bug, as I said in my reply. Sorry, it happens on a non-devfs kernel as well. Since it doesn't appear to be a Vinum bug, I'm taking the liberty of sending the whole thing to -current. (I sent my first dump to Greg in particular, since a Vinum command triggered whatever this is.) You asked what this system was doing at the time: I've copied ps -ax output to http://www.blackhelicopters.org/~mwlucas/ps.out . The system is doing almost nothing at the time. How to reproduce the crash: magpire/etc;vinum create /etc/vinum.conf 2 drives: D alpha State: up /dev/da0s1e A: 384/3551 MB (10%) D beta State: up /dev/da1s1e A: 619/3786 MB (16%) 1 volumes: V test State: up Plexes: 1 Size: 6333 MB 1 plexes: P test.p0 S State: up Subdisks: 2 Size: 6333 MB 2 subdisks: S test.p0.s0State: up D: alphaSize: 3166 MB S test.p0.s1State: up D: beta Size: 3166 MB newfs mount on /mnt. Test via tar -czvf /mnt/src.tgz /usr/src. Works fine (although is slower than a concatenated vol, I wonder why?) Unmount /mnt. magpire/etc;vinum resetconfig WARNING! This command will completely wipe out your vinum configuration. All data will be lost. If you really want to do this, enter the text NO FUTURE Enter text - NO FUTURE Read from remote host magpire: Connection reset by peer Connection to magpire closed. pedicular~; BAM! Panic. Here's a copy of my panic trace. Script started on Wed Aug 15 17:57:48 2001 magpire/var/crash;file /boot/kernel/vinum.ko /boot/kernel/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped magpire/var/crash;file kernel.debug.nodevfs kernel.debug.nodevfs: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped magpire/var/crash;gdb -k kernel.debug.nodevfs vmcore.3 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd... IdlePTD 4284416 initial pcb at 34b860 panicstr: bremfree: bp 0xcc2a1ae4 not locked panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc01f0783 stack pointer = 0x10:0xd6146ea8 frame pointer = 0x10:0xd6146eb4 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 = 699 (vinum) trap number = 12 panic: page fault syncing disks... panic: bremfree: bp 0xcc2a1ae4 not locked Uptime: 52m9s dumping to dev #ad/0x20021, offset 1048704 dump ata2: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104
Re: devfs and Vinum (was: any -current vinum problems?)
On 15-Aug-01 Michael Lucas wrote: On Wed, Aug 15, 2001 at 10:21:39AM +0930, Greg Lehey wrote: To help localize this problem, could you please try this same thing on a kernel without devfs? The dump you sent me did not look like a Vinum bug, as I said in my reply. Sorry, it happens on a non-devfs kernel as well. Since it doesn't appear to be a Vinum bug, I'm taking the liberty of sending the whole thing to -current. (I sent my first dump to Greg in particular, since a Vinum command triggered whatever this is.) Script started on Wed Aug 15 17:57:48 2001 magpire/var/crash;file /boot/kernel/vinum.ko /boot/kernel/vinum.ko: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped magpire/var/crash;file kernel.debug.nodevfs kernel.debug.nodevfs: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), not stripped magpire/var/crash;gdb -k kernel.debug.nodevfs vmcore.3 GNU gdb 4.18 Copyright 1998 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-unknown-freebsd... IdlePTD 4284416 initial pcb at 34b860 panicstr: bremfree: bp 0xcc2a1ae4 not locked Unfortunately this is the panic message from later on during the syncing disks stage, not the real panic. :( #15 0xc01f0783 in witness_destroy (lock=0xc1ec4e68) at #../../../kern/subr_witness.c:395 This is the real problem: mtx_lock(all_mtx); lock_cur_cnt--; STAILQ_REMOVE(all_locks, lock, lock_object, lo_list); lock-lo_flags = ~LO_INITIALIZED; mtx_unlock(all_mtx); It panics in the STAILQ_REMOVE(). I've seen this a couple of times but have no idea how that list pointer is getting corrupted. My guess is that a mutex is being destroyed twice or something dumb like that; however, I'm not sure how. The LO_INITIALIZED flags and checks are supposed to catch that case. I suppose there is a chance we could preempt in between the LO_INITIALIZED check and the actual removal and then free it and get in trouble that way. Hmm. Try moving the mtx_lock of all_mtx before the check for LO_INITIALIZED and see if you can get a different panic. It may be a bug in the ucred stuff. (At least several other panics of this type have been the result of crfree's.) -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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
devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. In any case, what devfs has is support for names with / in them. It violates POLA and causes serious problems in third party software. I think that you should implement subdirectories. it was a primary design goal in the previous devfs and its disappearance caught me by surprise. (the support I mean) SATIRE The ability to not panic left, right and centre was a primary design goal of this devfs and its absense in the previos devfs caught be by surprise. (The lack of support as well). /SATIRE In view of the fact that this thread is about deficiencies in your devfs, this is particularly uncalled for. One of the reasons that Julian's devfs never got debugged was that you had made it very clear from the start that it would be removed. And in general, can we stop the high incidence of mud-slinging we've seen on the lists lately? Greg -- 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
RE: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
[snip] And in general, can we stop the high incidence of mud-slinging we've seen on the lists lately? Here, here! Brandon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
In message [EMAIL PROTECTED], Greg Lehey writes: On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. Uhm, have you forgotten how ls(1) works ? Try this then: ls -lad /dev/fd /dev/fd/[012] In view of the fact that this thread is about deficiencies in your devfs, this is particularly uncalled for. One of the reasons that Julian's devfs never got debugged was that you had made it very clear from the start that it would be removed. History being rewritten eh ? I spent 3+ years trying to argue his DEVFS should be made default! -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
any -current vinum problems?
Before I start generating crash dumps etc., are there any gotchas with Vinum -current? I'm using devfs on a SMP system, upgraded 3 days ago. I get a panic whenever I stripe something. Thanks, Michael -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
devfs and Vinum (was: any -current vinum problems?)
On Tuesday, 14 August 2001 at 19:26:09 -0400, Michael Lucas wrote: Before I start generating crash dumps etc., are there any gotchas with Vinum -current? I'm using devfs on a SMP system, upgraded 3 days ago. I get a panic whenever I stripe something. Ah, now you say devfs. There was a bug in devfs; I haven't checked whether it's been fixed. Basically, devfs as supplied in CURRENT had a 16 character limit on device names, and it didn't understand subdirectories: it treated the / as a part of the device name. Vinum device names can be much longer than 16 characters, so I changed the limit to 96 characters on my test machine, but wasn't able to get it to run reliably. I've told phk about this on IRC some months ago, but I haven't seen a commit fixing the problem. I could have missed something, of course. To help localize this problem, could you please try this same thing on a kernel without devfs? The dump you sent me did not look like a Vinum bug, as I said in my reply. Greg -- 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
Re: devfs and Vinum (was: any -current vinum problems?)
+---[ Greg Lehey ]-- | [snip] | whether it's been fixed. Basically, devfs as supplied in CURRENT had | a 16 character limit on device names, and it didn't understand | subdirectories: it treated the / as a part of the device name. The subdir part bit me about a week ago, so I'd say it's still not fixed. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
In message [EMAIL PROTECTED], Andrew Kenneth Milton writes: +---[ Greg Lehey ]-- | [snip] | whether it's been fixed. Basically, devfs as supplied in CURRENT had | a 16 character limit on device names, and it didn't understand | subdirectories: it treated the / as a part of the device name. The subdir part bit me about a week ago, so I'd say it's still not fixed. This is absolutely news to me. I'm pretty sure that you will find that /dev/fd[012] exists on your system and that it was created using '/' in make_dev calls... More details on this bug are most welcome. I'm working on the 16char limit problem as well, but I want to avoid allocating memory in incovenient circumstances if at all possible. -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
On Wednesday, 15 August 2001 at 7:16:02 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Andrew Kenneth Milton
writes:
+---[ Greg Lehey ]--
[snip]
whether it's been fixed. Basically, devfs as supplied in CURRENT had
a 16 character limit on device names, and it didn't understand
subdirectories: it treated the / as a part of the device name.
The subdir part bit me about a week ago, so I'd say it's still not fixed.
This is absolutely news to me.
Thinking about it, it is to me too. I noticed that devfs doesn't
create directory nodes when I was trying to find ways to delete
existing directory entries, but that's the only problem I've had with
it. I mentioned it here because it related to the name length limit:
the length of the name includes the complete path from the mount
point.
More details on this bug are most welcome.
I'm working on the 16char limit problem as well, but I want to avoid
allocating memory in incovenient circumstances if at all possible.
The problem is that I kept having problems with the devfs/vinum
combination even after increasing the size to 96 characters. As I
said to you on IRC quite some time ago now:
groggy phk: I've been getting a lot of panics out of zaphod.
groggy phk: I suspect a bogon or misunderstandingn with Vinum and devfs.
phk groggy: any clues/traces/pointers ?
phk wli: you're not a member of the club.
groggy phk: I'm just guessing that it's a name length problem.
groggy phk: Hmm. Could be due to incorrect header files somewhere.
groggy phk: I upped the name length to 96 chars.
groggy phk: Traceback:
groggy 1 0xc01b88c4 in panic (fmt=0xc034ce38 getnewvnode: free vnode isn't) at
../../kern/kern_shutdown.c:598
groggy #2 0xc01fb30e in getnewvnode (tag=VT_UFS, mp=0xc230d400, vops=0xc22c4600,
vpp=0xcfcdec10) at ../../kern/vfs_subr.c:552
groggy #3 0xc02c33aa in ffs_vget (mp=0xc230d400, ino=0x12099, vpp=0xcfcdec60) at
../../ufs/ffs/ffs_vfsops.c:1157
groggy #4 0xc02b409d in ffs_valloc (pvp=0xcfc9b920, mode=0x81a4, cred=0xc252db00,
vpp=0xcfcdec60)
groggy at ../../ufs/ffs/ffs_alloc.c:615
groggy #5 0xc02cc670 in ufs_makeinode (mode=0x81a4, dvp=0xcfc9b920, vpp=0xcfcdeea4,
cnp=0xcfcdeeb8)
groggy at ../../ufs/ufs/ufs_vnops.c:2215
groggy #6 0xc02c9c14 in ufs_create (ap=0xcfcdedbc) at ../../ufs/ufs/ufs_vnops.c:194
groggy #7 0xc02ccb39 in ufs_vnoperate (ap=0xcfcdedbc) at
../../ufs/ufs/ufs_vnops.c:2587
groggy #8 0xc02068a9 in vn_open (ndp=0xcfcdee90, flagp=0xcfcdee5c, cmode=0x1a4) at
vnode_if.h:90
groggy #9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
groggy #10 0xc0312445 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f,
tf_edi = 0xbfbff9b8, tf_esi = 0x8,
groggy tf_ebp = 0xbfbff820, tf_isp = 0xcfcdefd4, tf_ebx = 0x80b54a0, tf_edx =
0x80b5b80, tf_ecx = 0x10, tf_eax = 0x5,
groggy tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x8091fec, tf_cs = 0x1f,
tf_eflags = 0x293, tf_esp = 0xbfbff7f4,
groggy tf_ss = 0x2f}) at ../../i386/i386/trap.c:1176
groggy phk: I'm wondering whether to analyse, reboot and upgrade, or ignore for the
moment.
phk groggy doesn't really point to either of vinum or DEVFS if you ask me...
groggy (kgdb) f 9
groggy #9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
groggy warning: Source file is more recent than executable.
groggy 1077error = vn_open(nd, flags, cmode);
groggy (kgdb) p *uap
groggy $1 = {
groggy path = 0x80c4030 lib/username.o,
groggy path_ = 0xcfcdef84 \001\006,
groggy flags = 0x601,
groggy flags_ = 0xcfcdef88 ¶\001,
groggy mode = 0x1b6,
groggy mode_ = 0xcfcdef8c ¸ù¿¿\006
groggy }
groggy phk: Not directly. I'm suspecting some kind of corruption.
groggy phk: But nobody else has mentioned it, and there must be some reason why it
keeps happening.
groggy phk: The trouble is, I use this box for two different purposes;
groggy phk: 1: Testing Vinum.
groggy phk: 1: Testing Samba.
* groggy points at http://build.samba.org/
groggy s/1/2/
groggy phk: This only started happening since I installed devfs, and I think it only
happens if Vinum is loaded.
phk groggy: well, as far as I know we still havn't conclusive evidence that
vinum+DEVFS does the right thing, do we ?
groggy phk: Exactly.
groggy phk: I was just waiting for you to say hey, that sounds familiar.
phk groggy I'm sorry I havn't gotten further on the long-names for devices, but life
has kind of kept me busy this week, starting with a leaky water pipe last sunday...
groggy phk: No worries. I'll keep looking, maybe.
Sorry I can't give you a date on this, but I'm sure you remember.
Maybe the leaky water pipe will put a date on it :-)
Greg
--
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
Re: devfs and Vinum (was: any -current vinum problems?)
In message [EMAIL PROTECTED], Greg Lehey writes: I'm working on the 16char limit problem as well, but I want to avoid allocating memory in incovenient circumstances if at all possible. The problem is that I kept having problems with the devfs/vinum combination even after increasing the size to 96 characters. As I said to you on IRC quite some time ago now: Yeah, I remember you saying that, and that has made me even more cautious because the only explanation I could find would be stack overruns or places which knew about the 16. But trust me, you are on my list of things to do, but I'm still trying to get rid of my contractors and getting things into a general shape where I will have some spare time again... -- 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS/Vinum problems
:The thing is i'm not sure if it's vinum, I could also duplicate this on
:another machine without vinum.. except I duplicated it differently..
:
:Consider the following perl script:
:
:#!/usr/bin/perl
:for ( ; ; ) {
:system("fetch http://www.web.site/index.html");
:}
:
:Of course, replacing the site with something else, but on this one box
:(and the raid), it panic'd the box.. See if you can duplicate this on any
:4.0/5.0 boxes you have, I have tried on both and it worked, however it
:does not crash 3.x boxes..
:
:Try your luck,
:Jason DiCioccio
Ok, I'm a bit confused.
You are running this script on the NFS client while CD'd into an
NFS mount and the NFS server is crashing?
Or are you running this on the NFS server while CD'd into a local
disk mount and the NFS server is crashing?
I presume the web site you are fetching from is not crashing.
Have you tried exporting a non-raid mount from the server to the
client to see if that crashes? The only thing that happens to me
when I run the above script on an NFS client while CD'd into an NFS
server is that the client winds up with thousands of sockets
in TIME_WAIT on the client until it runs out and starts getting
'socket is not connected' errors (I was using a web server on my LAN
so the fetches were completeing very quickly). But the NFS
server didn't have any problems.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the cause of the problem (though I have never in my life seen the panic message you posted in relation to the NCR cards). If you can get the panic regularly then it may be worthwhile trying to get some more information out of it. If you compile up a kernel with the DDB option and your console is not running X, then the kernel will drop into DDB on the console when it panics and allow you to do a stack 'trace'. You may also be able to then dump the machine by typing 'panic' manually at the ddb prompt after copying down the trace information. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
Here is my dmesg output, and btw, sorry.. the perl script was not running on the NFS volume, just regularly on a regular 4.0 box, and it crashed the box (yes, I had login limits set), I was just giving another example of what seems to be some instability in 4.0 under high loads.. Here my dmesg from the raid/nfs server: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Fri Mar 31 00:03:37 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RAID Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 186006596 Hz CPU: IDT WinChip C6 (186.01-MHz 586-class CPU) Origin = "CentaurHauls" Id = 0x541 Stepping = 1 Features=0x8000b5FPU,DE,TSC,MSR,MCE,MMX real memory = 50331648 (49152K bytes) config en ed0 config po ed0 0x240 config ir ed0 5 config iom ed0 0xd8000 config f ed0 0 config q avail memory = 45297664 (44236K bytes) Preloaded elf kernel "kernel" at 0xc036f000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc036f09c. npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: DEC 21050 PCI-PCI bridge at device 3.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82375EB PCI-EISA bridge at device 4.0 on pci0 eisa0: EISA bus on isab0 mainboard0: HWPc0d1 (System Board) on eisa0 slot 0 isa0: ISA bus on isab0 ahc0: Adaptec aic7855 SCSI adapter port 0xf800-0xf8ff mem 0xfedff000-0xfed f irq 15 at device 5.0 on pci0 ahc0: Using left over BIOS settings ahc0: aic7855 Single Channel A, SCSI Id=7, 3/255 SCBs ahc1: Adaptec aic7855 SCSI adapter port 0xf400-0xf4ff mem 0xfedfe000-0xfedfeff f irq 15 at device 6.0 on pci0 ahc1: Using left over BIOS settings ahc1: aic7855 Single Channel A, SCSI Id=7, 3/255 SCBs fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3cf iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA (mono) 16 virtual consoles, flags=0x200 ed0 at port 0x240-0x25f iomem 0xd8000-0xd9fff irq 5 drq 0 on isa0 ed0: address 00:00:c0:00:dc:ba, type SMC8416T (16 bit) Waiting 15 seconds for SCSI devices to settle vinum: loaded da1 at ahc1 bus 0 target 1 lun 0 da1: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da5 at ahc1 bus 0 target 5 lun 0 da5: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da5: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da5: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da6 at ahc1 bus 0 target 6 lun 0 da6: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da6: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da6: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da4 at ahc1 bus 0 target 4 lun 0 da4: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da4: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da4: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da3 at ahc1 bus 0 target 3 lun 0 da3: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da3: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da3: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da2 at ahc1 bus 0 target 2 lun 0 da2: HP 2.13 GB 1st ### 1212 Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) Mounting root from ufs:/dev/da0s1a cd0 at ahc0 bus 0 target 5 lun 0 cd0: TOSHIBA CD-ROM XM-5301TA 1535 Removable CD-ROM SCSI-2 device cd0: 4.032MB/s transfers (4.032MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: SGI SeagateST12550N 2703 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2048MB (4195116 512 byte sectors: 64H 32S/T 2048C) WARNING: / was not properly dismounted vinum: reading configuration from /dev/da6s1e vinum: updating configuration from /dev/da5s1e vinum: updating configuration from /dev/da4s1e vinum: updating configuration from /dev/da3s1e vinum: updating configuration from /dev/da2s1e vinum: updating configuration from /dev/da1s1e I hope this helps.. and i'll setup crash dumping on raid, thanks for your time On Fri, 31 Mar 2000, Matthew Dillon wrote: ::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the
Re: NFS/Vinum problems
One more thing, here's my kernel config file just in case you need it: machine i386 cpu I586_CPU ident RAID maxusers64 makeoptions DEBUG=-g#Build kernel with gdb(1) debug options DDB_UNATTENDED options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep options NFS #Network Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options NMBCLUSTERS=10240 options VINUMDEBUG #enable Vinum debugging hooks device isa device eisa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device cd # CD device pass# Passthrough device (direct SCSI access) device mlx # Mylex DAC960 family # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device vga0at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Floating point support - do not disable. device npx0at nexus? port IO_NPX irq 13 # ISA Ethernet NICs. device ed0 at isa? port 0x240 irq 5 iomem 0xd8000 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop# Network loopback pseudo-device ether # Ethernet support pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device vinum #Vinum concat/mirror/raid driver pseudo-device snp # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter On Fri, 31 Mar 2000, Matthew Dillon wrote: ::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the cause of the problem (though I have never in my life seen the panic message you posted in relation to the NCR cards). If you can get the panic regularly then it may be worthwhile trying to get some more information out of it. If you compile up a kernel with the DDB option and your console is not running X, then the kernel will drop into DDB on the console when it panics and allow you to do a stack 'trace'. You may also be able to then dump the machine by typing 'panic' manually at the ddb prompt after copying down the trace information. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS/Vinum problems
panic: lockmgr: pid -2, exclusive lock holder 5 unlocking Syncing disks... Timedout SCB handled by another timeout Timedout handled by another timeout That is what I get when doing a 'du -k' on an NFS mount from a remote machine.. THe machine I am speaking of is the actual nfs server, i'm using freebsd's default nfsd/mountd flags as specified by rc.conf.. However, when I do lets say, a du -k on the mounted volume, I get that panic.. If this is a known bug or if anyone knows how to fix this, get back to me asap.. Thanks in advance, Jason DiCioccio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata + vinum problems
On Mar 15, Mathew Kanner wrote: On Mar 15, Greg Lehey wrote: attention yet, but I do see that your problem relates to soft updates. It's not clear that the soft updates themselves are a cause of the problem, or just a facilitator, but it would be interesting to I did try it couple of days back with and without softupdates. Softupdates only made the problems appear more quickly but I've lost track of all the combinations that's I've tried so I should try one more time without. After some more time spent with the system. It turns out it is softupdates. I can complete the script (which copies /usr/ports to a newfs'ed system) without softupdates but with, it will stall and then crash. An interesting note, with softupdates, during a stall I did a sysctl vfs.hidirtbuffers=500 and it completed, howver, if I do this before running the script, it crashes as well (but doesn't take nearly as long to do so). Included is a traceback of when it crashed witht he hibuffers at 500. --Mat Script started on Thu Mar 23 15:23:03 2000 bash-2.03# gdb -k GNU gdb 4.18 Copyright 1998 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-unknown-freebsd". (kgdb) core[Kexec-file kernel2. kernel2.: No such file or directory. (kgdb) ecxxec-file kernel.2 (kgdb) coresuymbol-file /usr/src/sys/compile/KZAZE/kernel.debug Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done. (kgdb) core-file vmcore.2 IdlePTD 4165632 initial pcb at 364ea0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc026745a stack pointer = 0x10:0xc03218e4 frame pointer = 0x10:0xc03218f0 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 = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025e10c stack pointer = 0x10:0xc032171c frame pointer = 0x10:0xc0321720 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 = Idle interrupt mask = bio trap number = 12 panic: page fault Uptime: 6m53s dumping to dev #ad/0x20001, offset 3047552 dump ata0: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0
Re: ata + vinum problems
Ok, this is NOT a softupdates *or* a vinum problem. This is a buffer cache problem. The problem is due to the large block size you are using when newfs'ing the filesystem coupled with problems in geteblk() which causes severe buffer cache KVM fragmentation. Softupdates exasperates the geteblk() problem. I thought I had fixed this problem but apparently not. Try applying my buf-cleanup-3.diff patch from: http://www.backplane.com/FreeBSD4/ Then go back to the configuration that was producing the problem before and see if it still occurs. Even with the above patch there is still a significant KVM fragmentation issue with large-block filesystems. You can guarentee 100% success by hacking the BKVASIZE define in sys/sys/param.h (AFTER applying the patch) from 16384 to 32768, but I wouldn't raise it much beyond that. This patch is only a partial fix to the problem. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata + vinum problems
Oh, addendum... I didn't see this email regarding an actual panic. There are two problems here, one of which (the nbufkv lockup) should be solved by my previous email. The second problem is this panic you are reporting, and I have no idea what is causing it so this issue remains open. It could be softupdates, it could be vinum, or it could be the ATA driver. What you need to do to help solve the panic is to gdb a debug version of the kernel image rather then the non debug version so the stack backtrace contains source line numbers and such. -Matt Matthew Dillon [EMAIL PROTECTED] : After some more time spent with the system. It turns out it :is softupdates. I can complete the script (which copies /usr/ports to :a newfs'ed system) without softupdates but with, it will stall and :then crash. An interesting note, with softupdates, during a stall I :did a sysctl vfs.hidirtbuffers=500 and it completed, howver, if I do :this before running the script, it crashes as well (but doesn't take :nearly as long to do so). : Included is a traceback of when it crashed witht he hibuffers :at 500. : : --Mat : :Script started on Thu Mar 23 15:23:03 2000 :bash-2.03# gdb -k :GNU gdb 4.18 :Copyright 1998 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-unknown-freebsd". :(kgdb) core[Kexec-file kernel2. :kernel2.: No such file or directory. :(kgdb) ecxxec-file kernel.2 :(kgdb) coresuymbol-file /usr/src/sys/compile/KZAZE/kernel.debug :Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done. :(kgdb) core-file vmcore.2 :IdlePTD 4165632 :initial pcb at 364ea0 :panicstr: page fault :panic messages: :--- :Fatal trap 12: page fault while in kernel mode :fault virtual address = 0x0 :fault code = supervisor read, page not present :instruction pointer= 0x8:0xc026745a :stack pointer = 0x10:0xc03218e4 :frame pointer = 0x10:0xc03218f0 :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= Idle :interrupt mask = bio :trap number= 12 :panic: page fault : :syncing disks... : :Fatal trap 12: page fault while in kernel mode :fault virtual address = 0x30 :fault code = supervisor read, page not present :instruction pointer= 0x8:0xc025e10c :stack pointer = 0x10:0xc032171c :frame pointer = 0x10:0xc0321720 :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= Idle :interrupt mask = bio :trap number= 12 :panic: page fault :Uptime: 6m53s : :dumping to dev #ad/0x20001, offset 3047552 :dump ata0: resetting devices .. done :511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 :494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 :477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 :460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 :443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 :426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 :409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 :392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 :375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 :358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 :341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 :324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 :307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 :290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 :273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 :256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 :239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 :222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 :205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 :188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 :171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 :154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 :137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 :120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105
Re: ata + vinum problems
On Mar 23, Matthew Dillon wrote: Oh, addendum... I didn't see this email regarding an actual panic. There are two problems here, one of which (the nbufkv lockup) should be solved by my previous email. The second problem is this panic you are reporting, and I have no idea what is causing it so this issue remains open. It could be softupdates, it could be vinum, or it could be the ATA driver. What you need to do to help solve the panic is to gdb a debug version of the kernel image rather then the non debug version so the stack backtrace contains source line numbers and such. -Matt Matthew Dillon [EMAIL PROTECTED] Included is a better backtrace. This does not include the patch that you suggested, I will do that tommorow. Thanks, --Mat Script started on Thu Mar 23 17:07:47 2000 bash-2.03# gdk b -k GNU gdb 4.18 Copyright 1998 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-unknown-freebsd". (kgdb) exec-file v kernel.3 (kgdb) c symbol-file /usr/sr/ c/sys/compile/KAZE/kernel.debug Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done. (kgdb) core-file vmcore.3 IdlePTD 4157440 initial pcb at 364ec0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x8:0xc0175f96 stack pointer = 0x10:0xc0321948 frame pointer = 0x10:0xc0321948 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 = Idle interrupt mask = bio trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025e120 stack pointer = 0x10:0xc0321780 frame pointer = 0x10:0xc0321784 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 = Idle interrupt mask = bio trap number = 12 panic: page fault Uptime: 5m27s dumping to dev #ad/0x20001, offset 3047552 dump ata0: resetting devices .. done 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 boot (howto=260) at ../../kern/kern_shutdown.c:304 304 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=260) at ../../kern/kern_shutdown.c:304
Re: ata + vinum problems
On Wednesday, 15 March 2000 at 16:29:03 -0500, Mathew Kanner wrote: On Mar 15, Mathew Kanner wrote: On Mar 15, Soren Schmidt wrote: Btw are you running the latest 4.0 or -current code ? there was a time when we had problems with the HPT and Promise controllers ? The kernel in question was cvsup'ed right at the change. I'm going to try 4.0 today. Replying to myself. By now this is probably the wrong list. I'm not sure what to do anymore. I've tried to set the bios settings back to what I've had when it worked it it doesn't seem to want to go. I've set the drives for ata/66 and ata/33. I've moved IRQ's around and even tried forcing them. Here are sets of dmesg and backtraces. This also happens with a kernel and modules compiled on sunday. The part that really bothers me is that I have a nearly identical machine, except for an extra drive in it that originally had the same problems but when I disabled the extra periphs, the problem went away. I'm a bit behind in my mail, and I don't have time to give this proper attention yet, but I do see that your problem relates to soft updates. It's not clear that the soft updates themselves are a cause of the problem, or just a facilitator, but it would be interesting to see what happens if you turn them off. Note also that there are some bogons in your config, to judge by the vinum startup messages. I'll analyse this in a day or two when I (hopefully) have more time. Greg -- Finger [EMAIL PROTECTED] for PGP public key 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
Re: ata + vinum problems
On Mar 15, Soren Schmidt wrote: It seems Mathew Kanner wrote: disks on Promise controllers. I believe that the problems lies with multiple cards on the same interupt but what do I know -- execpt that the problem goes away when I disable most devices in the BIOS. The motherboard is a abit BE6-II, I've enabled most BIOS periphs such as serial ports, printer ports, usb, vga ints but not APM. Hmm, I've seen references on the net to the BE6 having trouble with ATA PCI controllers in one of the slots if the internal controller is enabled, I dont know which slot that is unfortunately, so moving things around is my best guess. I did get hit by that, in this case it's the 5th pci slot. When there a controller in there, the system just locks completly. Btw are you running the latest 4.0 or -current code ? there was a time when we had problems with the HPT and Promise controllers ? The kernel in question was cvsup'ed right at the change. I'm going to try 4.0 today. --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata + vinum problems
It seems Mathew Kanner wrote: Hi All, I wanted to document my difficuties with Vinum and multiple disks on Promise controllers. I believe that the problems lies with multiple cards on the same interupt but what do I know -- execpt that the problem goes away when I disable most devices in the BIOS. The motherboard is a abit BE6-II, I've enabled most BIOS periphs such as serial ports, printer ports, usb, vga ints but not APM. Hmm, I've seen references on the net to the BE6 having trouble with ATA PCI controllers in one of the slots if the internal controller is enabled, I dont know which slot that is unfortunately, so moving things around is my best guess. Btw are you running the latest 4.0 or -current code ? there was a time when we had problems with the HPT and Promise controllers ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata + vinum problems
On Mar 15, Mathew Kanner wrote: On Mar 15, Soren Schmidt wrote: Btw are you running the latest 4.0 or -current code ? there was a time when we had problems with the HPT and Promise controllers ? The kernel in question was cvsup'ed right at the change. I'm going to try 4.0 today. Replying to myself. By now this is probably the wrong list. I'm not sure what to do anymore. I've tried to set the bios settings back to what I've had when it worked it it doesn't seem to want to go. I've set the drives for ata/66 and ata/33. I've moved IRQ's around and even tried forcing them. Here are sets of dmesg and backtraces. This also happens with a kernel and modules compiled on sunday. The part that really bothers me is that I have a nearly identical machine, except for an extra drive in it that originally had the same problems but when I disabled the extra periphs, the problem went away. Any suggestions? --Mat Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-STABLE #5: Tue Mar 14 22:07:49 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/KAZE Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon (551.25-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,XMM real memory = 536870912 (524288K bytes) avail memory = 516157440 (504060K bytes) Preloaded elf kernel "kernel" at 0xc03e3000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: Matrox MGA G400 AGP graphics accelerator at 0.0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 chip1: Intel 82371AB Power management controller port 0x5000-0x500f at device 7.3 on pci0 xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xa400-0xa47f mem 0xe606-0xe606007f irq 7 at device 11.0 on pci0 xl0: Ethernet address: 00:50:da:d6:6a:d0 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: supplying EUI64: 00:50:da:ff:fe:d6:6a:d0 atapci1: Promise ATA66 controller port 0xb800-0xb83f,0xb400-0xb403,0xb000-0xb007,0xac00-0xac03,0xa800-0xa807 mem 0xe600-0xe601 irq 5 at device 13.0 on pci0 ata2: at 0xa800 on atapci1 ata3: at 0xb000 on atapci1 atapci2: Promise ATA66 controller port 0xcc00-0xcc3f,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 mem 0xe604-0xe605 irq 10 at device 15.0 on pci0 ata4: at 0xbc00 on atapci2 ata5: at 0xc400 on atapci2 atapci3: Promise ATA66 controller port 0xe000-0xe03f,0xdc00-0xdc03,0xd800-0xd807,0xd400-0xd403,0xd000-0xd007 mem 0xe602-0xe603 irq 11 at device 17.0 on pci0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: parallel port not found. ad0: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata0-master using UDMA33 ad4: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata2-master using UDMA66 ad6: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata3-master using UDMA66 ad8: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata4-master using UDMA66 ad10: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata5-master using UDMA66 acd0: CD-RW MATSHITA CD-RW CW-7585 at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted vinum: loaded vinum: reading configuration from /dev/ad6s1e vinum: updating configuration from /dev/ad8s1e vinum: updating configuration from /dev/ad10s1e vinum: updating configuration from /dev/ad4s1e xl0: starting DAD for fe80:0001::0250:daff:fed6:6ad0 xl0: DAD complete for fe80:0001::0250:daff:fed6:6ad0 - no duplicates found --- #0 boot (howto=260) at ../../kern/kern_shutdown.c:304 #1 0xc017f12c in poweroff_wait (junk=0xc03167af, howto=0) at ../../kern/kern_shutdown.c:554 #2 0xc02ba019 in trap_fatal (frame=0xc031fe64, eva=48) at
Re: ata + vinum problems
On Mar 15, Greg Lehey wrote: Replying to myself. By now this is probably the wrong list. I'm not sure what to do anymore. I've tried to set the bios settings back to what I've had when it worked it it doesn't seem to want to go. I've set the drives for ata/66 and ata/33. I've moved IRQ's around and even tried forcing them. Here are sets of dmesg and backtraces. This also happens with a kernel and modules compiled on sunday. The part that really bothers me is that I have a nearly identical machine, except for an extra drive in it that originally had the same problems but when I disabled the extra periphs, the problem went away. I'm a bit behind in my mail, and I don't have time to give this proper attention yet, but I do see that your problem relates to soft updates. It's not clear that the soft updates themselves are a cause of the problem, or just a facilitator, but it would be interesting to see what happens if you turn them off. Note also that there are some bogons in your config, to judge by the vinum startup messages. I'll analyse this in a day or two when I (hopefully) have more time. The bogons me were messing me around with Vinum before I figured out that the crash had messed up one of the disklabels. This occurs occasionally after a crash. I did try it couple of days back with and without softupdates. Softupdates only made the problems appear more quickly but I've lost track of all the combinations that's I've tried so I should try one more time without. Thanks, --Mat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ata + vinum problems
Hi All,
I wanted to document my difficuties with Vinum and multiple
disks on Promise controllers. I believe that the problems lies with
multiple cards on the same interupt but what do I know -- execpt that
the problem goes away when I disable most devices in the BIOS.
The motherboard is a abit BE6-II, I've enabled most BIOS
periphs such as serial ports, printer ports, usb, vga ints but not APM.
I've included the script that causes the crash, a back-trace
and dmesg output right before the crash and the kernel config. The
raid devices where made via the vinum simplified commands (which are
*very nice*).
It should be noted that I had to control the 'tar' part of the
script because it was stuck in a "nbufkv" and disk activity ceases.
The crash happened upto 10 seconds after I get a shell prompt back.
The "nbufkv" was the sure sign that something had gone wrong in my
previous 'uncontrolled' tests.
--Mat
#!/bin/sh -x
BLOCK_SIZE=`expr 32 \* 1024`
FRAG_SIZE=`expr 8 \* 1024`
ISIZE=`expr 6 \* ${FRAG_SIZE}`
#CYL=635
CYL=200
FAKE=""
DEV="/dev/vinum/raid5"
MOUNT="/mnt1"
newfs ${FAKE} -v -b ${BLOCK_SIZE} -f ${FRAG_SIZE} -i ${ISIZE} -c ${CYL} ${DEV}
tunefs -n enable ${DEV}
mount ${DEV} ${MOUNT}
tar cf - -C /usr/ ports | tar xf - -C ${MOUNT}
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #4: Mon Mar 13 17:54:22 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/KAZE
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon (551.25-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x673 Stepping = 3
Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,XMM
real memory = 536870912 (524288K bytes)
avail memory = 516128768 (504032K bytes)
Preloaded elf kernel "kernel" at 0xc03e9000.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: Matrox MGA G400 AGP graphics accelerator at 0.0 irq 10
isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 9
chip1: Intel 82371AB Power management controller port 0x5000-0x500f at device 7.3 on
pci0
xl0: 3Com 3c905B-TX Fast Etherlink XL port 0x9400-0x947f mem 0xe706-0xe706007f
irq 9 at device 11.0 on pci0
xl0: Ethernet address: 00:50:da:d6:6a:d0
miibus0: MII bus on xl0
xlphy0: 3Com internal media interface on miibus0
xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: supplying EUI64: 00:50:da:ff:fe:d6:6a:d0
atapci1: Promise ATA66 controller port
0xa800-0xa83f,0xa400-0xa403,0xa000-0xa007,0x9c00-0x9c03,0x9800-0x9807 mem
0xe704-0xe705 irq 11 at device 13.0 on pci0
ata2: at 0x9800 on atapci1
ata3: at 0xa000 on atapci1
atapci2: Promise ATA66 controller port
0xbc00-0xbc3f,0xb800-0xb803,0xb400-0xb407,0xb000-0xb003,0xac00-0xac07 mem
0xe702-0xe703 irq 5 at device 15.0 on pci0
ata4: at 0xac00 on atapci2
ata5: at 0xb400 on atapci2
atapci3: Promise ATA66 controller port
0xd000-0xd03f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 mem
0xe700-0xe701 irq 10 at device 17.0 on pci0
atapci4: HighPoint HPT366 ATA66 controller port
0xdc00-0xdcff,0xd800-0xd803,0xd400-0xd407 irq 11 at device 19.0 on pci0
atapci5: HighPoint HPT366 ATA66 controller port
0xe800-0xe8ff,0xe400-0xe403,0xe000-0xe007 irq 11 at device 19.1 on pci0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: System console on isa0
sc0: VGA 16 virtual consoles, flags=0x200
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: cannot reserve I/O port range
ad0: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata0-master using UDMA33
ad4: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata2-master using UDMA66
ad6: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata3-master using UDMA66
ad8: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata4-master using UDMA66
ad10: 26063MB FUJITSU MPE3273AT [52953/16/63] at ata5-master using UDMA66
acd0: CD-RW MATSHITA CD-RW CW-7585 at ata1-master using PIO4
Mounting root from ufs:/dev/ad0s1a
