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 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?))
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?))
[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?))
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?))
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?))
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 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:
> 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 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 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 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 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?))
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_
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 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: >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
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
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) > > > 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). > 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 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
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 10
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) 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). 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?)
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?)
+---[ 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?)
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?)
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?)
+---[ 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:
>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: | >+---[ 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]>, 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: 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:
phk: I've been getting a lot of panics out of zaphod.
phk: I suspect a bogon or misunderstandingn with Vinum and devfs.
groggy: any clues/traces/pointers ?
wli: you're not a member of the club.
phk: I'm just guessing that it's a name length problem.
phk: Hmm. Could be due to incorrect header files somewhere.
phk: I upped the name length to 96 chars.
phk: Traceback:
1 0xc01b88c4 in panic (fmt=0xc034ce38 "getnewvnode: free vnode isn't") at
../../kern/kern_shutdown.c:598
#2 0xc01fb30e in getnewvnode (tag=VT_UFS, mp=0xc230d400, vops=0xc22c4600,
vpp=0xcfcdec10) at ../../kern/vfs_subr.c:552
#3 0xc02c33aa in ffs_vget (mp=0xc230d400, ino=0x12099, vpp=0xcfcdec60) at
../../ufs/ffs/ffs_vfsops.c:1157
#4 0xc02b409d in ffs_valloc (pvp=0xcfc9b920, mode=0x81a4, cred=0xc252db00,
vpp=0xcfcdec60)
at ../../ufs/ffs/ffs_alloc.c:615
#5 0xc02cc670 in ufs_makeinode (mode=0x81a4, dvp=0xcfc9b920, vpp=0xcfcdeea4,
cnp=0xcfcdeeb8)
at ../../ufs/ufs/ufs_vnops.c:2215
#6 0xc02c9c14 in ufs_create (ap=0xcfcdedbc) at ../../ufs/ufs/ufs_vnops.c:194
#7 0xc02ccb39 in ufs_vnoperate (ap=0xcfcdedbc) at
../../ufs/ufs/ufs_vnops.c:2587
#8 0xc02068a9 in vn_open (ndp=0xcfcdee90, flagp=0xcfcdee5c, cmode=0x1a4) at
vnode_if.h:90
#9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
#10 0xc0312445 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f,
tf_edi = 0xbfbff9b8, tf_esi = 0x8,
tf_ebp = 0xbfbff820, tf_isp = 0xcfcdefd4, tf_ebx = 0x80b54a0, tf_edx =
0x80b5b80, tf_ecx = 0x10, tf_eax = 0x5,
tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x8091fec, tf_cs = 0x1f,
tf_eflags = 0x293, tf_esp = 0xbfbff7f4,
tf_ss = 0x2f}) at ../../i386/i386/trap.c:1176
phk: I'm wondering whether to analyse, reboot and upgrade, or ignore for the
moment.
groggy doesn't really point to either of vinum or DEVFS if you ask me...
(kgdb) f 9
#9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
warning: Source file is more recent than executable.
1077error = vn_open(&nd, &flags, cmode);
(kgdb) p *uap
$1 = {
path = 0x80c4030 "lib/username.o",
path_ = 0xcfcdef84 "\001\006",
flags = 0x601,
flags_ = 0xcfcdef88 "¶\001",
mode = 0x1b6,
mode_ = 0xcfcdef8c "¸ù¿¿\006"
}
phk: Not directly. I'm suspecting some kind of corruption.
phk: But nobody else has mentioned it, and there must be some reason why it
keeps happening.
phk: The trouble is, I use this box for two different purposes;
phk: 1: Testing Vinum.
phk: 1: Testing Samba.
* groggy points at http://build.samba.org/
s/1/2/
phk: This only started happening since I installed devfs, and I think it only
happens if Vinum is loaded.
groggy: well, as far as I know we still havn't conclusive evidence that
vinum+DEVFS does the right thing, do we ?
phk: Exactly.
phk: I was just waiting for you to say "hey, that sounds familiar".
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...
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]>, 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?)
+---[ 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
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
