Re: Protecting global lookup array
> Well, a lot of things, but the specific problem is that you can switch > the vnode ops table to point to deadfs easily enough, but then you > need to find all the processes already in the fs, kick them, and then > wait until they've all returned out. > > You see how this is similar to what you're trying to do... Honestly I was only thinking of addition this time. :) I think I assume that device setgments are never detached for now. I'll revisit this fail safe shutdown topic when I'll tackle USB stack revamp, where force detachment has to be dealt with nicely. Masao -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: Protecting global lookup array
On Mon, Feb 08, 2010 at 05:55:44PM +0900, Masao Uebayashi wrote: > > On the plus side, this is essentially the same problem as safely > > switching vnodes to deadfs after a umount -f; on the minus side, > > nobody's yet come up with a satisfactory solution for that... > > I think your problem involves much more things & more complicated. :) > Just curious, what's missing to achieve umount -f specifically? Well, a lot of things, but the specific problem is that you can switch the vnode ops table to point to deadfs easily enough, but then you need to find all the processes already in the fs, kick them, and then wait until they've all returned out. You see how this is similar to what you're trying to do... -- David A. Holland dholl...@netbsd.org
Re: unhooking lfs from ufs
On Tue, Feb 09, 2010 at 04:14:58AM +, Eduardo Horvath wrote: > I'm a bit low on disk space at the moment, but if you build me a generic > sparc64 kernel I can test it. http://www.eecs.harvard.edu/~dholland/tmp/netbsd/ now contains: SHA1 (netbsd-sparc64-GENERIC.MP.gz) = 0cd34756d2fce2f6deeaa4192a669b0619986d6c SHA1 (netbsd-sparc64-GENERIC.gz) = b80187131d38fdb1689443692ea8970dd87dfe1f Get them while they're hot :-) (They are straight from my lfs tree, which was synced with HEAD at around 2230Z on 20100206. I dunno offhand if sparc64 was expected to work then or not. Usual provisos about accepting kernels over the internet apply, although if my build machine is owned I'm in a lot of trouble...) -- David A. Holland dholl...@netbsd.org
Re: enabling uthum(4) in GENERIC
On Tue, 9 Feb 2010, David Holland wrote: On Mon, Feb 08, 2010 at 11:08:46PM +0100, Antoine Reilles wrote: > Now that we have an uthum(4) driver, for TEMPer and TEMPerHUM usb > thermometers (and hygrometer in the case of TEMPerHUM), I was wondering > if it is a good idea to enable it in GENERIC kernel configuration, and > if so, in which architectures. > So far, it has only be tested on i386 to my knowledge. > > Do you have any recommendations ? The general principle is that GENERIC should contain all drivers that are supposed to work, and should list, commented-out, drivers that might work or might be useful if they did work. So, I guess it should be added commented out to every GENERIC that includes the assorted usb devices, and uncommented where it's been tested... Plus, for i386, it should be in ALL (uncommented) if it compiles. :) - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: unhooking lfs from ufs
On Tue, 9 Feb 2010, David Holland wrote: > On Tue, Feb 09, 2010 at 03:55:59AM +, Eduardo Horvath wrote: > > > What magic sauce do you have? Please share it - lfs has been broken > > > for everyone else. > > > > Dunno. Although I do disable fsck_lfs. It usually causes more problems > > than it solves. It needs a complete overhaul. It tries to act like > > fsck_ffs instead of validating segment checksums and regenerating the > > ifile. > > ...except that it also apparently can't actually repair most problems > it finds, which isn't very helpful of it. > > > A also haven't updated my sources for a while so I don't have to worry > > about DEV_BSIZE breakage. > > Do you feel up to testing my patch? It works for me for basic stuff, > although I didn't try pounding on it because it wasn't expected to work. I'm a bit low on disk space at the moment, but if you build me a generic sparc64 kernel I can test it. Eduardo
Re: unhooking lfs from ufs
On Tue, Feb 09, 2010 at 03:55:59AM +, Eduardo Horvath wrote: > > What magic sauce do you have? Please share it - lfs has been broken > > for everyone else. > > Dunno. Although I do disable fsck_lfs. It usually causes more problems > than it solves. It needs a complete overhaul. It tries to act like > fsck_ffs instead of validating segment checksums and regenerating the > ifile. ...except that it also apparently can't actually repair most problems it finds, which isn't very helpful of it. > A also haven't updated my sources for a while so I don't have to worry > about DEV_BSIZE breakage. Do you feel up to testing my patch? It works for me for basic stuff, although I didn't try pounding on it because it wasn't expected to work. -- David A. Holland dholl...@netbsd.org
Re: enabling uthum(4) in GENERIC
On Mon, Feb 08, 2010 at 11:08:46PM +0100, Antoine Reilles wrote: > Now that we have an uthum(4) driver, for TEMPer and TEMPerHUM usb > thermometers (and hygrometer in the case of TEMPerHUM), I was wondering > if it is a good idea to enable it in GENERIC kernel configuration, and > if so, in which architectures. > So far, it has only be tested on i386 to my knowledge. > > Do you have any recommendations ? The general principle is that GENERIC should contain all drivers that are supposed to work, and should list, commented-out, drivers that might work or might be useful if they did work. So, I guess it should be added commented out to every GENERIC that includes the assorted usb devices, and uncommented where it's been tested... -- David A. Holland dholl...@netbsd.org
Re: unhooking lfs from ufs
On Tue, 9 Feb 2010, David Holland wrote: > On Mon, Feb 08, 2010 at 09:50:22PM +, Eduardo Horvath wrote: > > NetBSD nonplus 5.99.23 NetBSD 5.99.23 (GENERIC.MP) #0: Fri Dec 25 01:58:51 > > PST 2009 > > eh29...@nonplus:/export/home/work/src/sys/arch/sparc64/compile/GENERIC.MP > > sparc64 > > What magic sauce do you have? Please share it - lfs has been broken > for everyone else. Dunno. Although I do disable fsck_lfs. It usually causes more problems than it solves. It needs a complete overhaul. It tries to act like fsck_ffs instead of validating segment checksums and regenerating the ifile. A also haven't updated my sources for a while so I don't have to worry about DEV_BSIZE breakage. Eduardo
Re: mutexes, IPL, tty locking
On Tue, Feb 09, 2010 at 12:20:48AM +, YAMAMOTO Takashi wrote: > > I'm not suggesting that we use this as such (and it would take quite a > > bit of work to merge it) but I think the general approach is worth > > considering. > > i don't think it's worth to do at this point because > - much complexity for little gain. > - it involves more frequent change of the effective IPL, which might > be expensive. Well, there's the other point, which I admittedly didn't make very prominent, which is that all that code is MI and the MD code is reduced to just a single cpu_setipl() function. It can easily (much more easily than deploying it in the first place) be made to take the same shortcut we currently do, that is, never lowering the ipl except to 0. -- David A. Holland dholl...@netbsd.org
Re: unhooking lfs from ufs
On Mon, Feb 08, 2010 at 09:18:05PM +0100, Adam Hamsik wrote: > Make LFS not compilable is the way to make it disappear very soon. Did you read what I wrote? :-) > I think that these changes should happen in separate branch and > should be committed back to main branch only when it will be at > least compilable again. That's already been done, except with a local/private branch on my end. -- David A. Holland dholl...@netbsd.org
Re: unhooking lfs from ufs
On Mon, Feb 08, 2010 at 09:50:22PM +, Eduardo Horvath wrote: > NetBSD nonplus 5.99.23 NetBSD 5.99.23 (GENERIC.MP) #0: Fri Dec 25 01:58:51 > PST 2009 > eh29...@nonplus:/export/home/work/src/sys/arch/sparc64/compile/GENERIC.MP > sparc64 What magic sauce do you have? Please share it - lfs has been broken for everyone else. -- David A. Holland dholl...@netbsd.org
Re: solved ? [Re: need help with kern/35704 (UBC-related)]
hi, > Anyone has commnts about this ? I'd still like to hear some from > UVM/UBC experts ... your analyses sound correct to me. (i currently have no time to read this complicated patch/code, sorry) YAMAMOTO Takashi
Re: mutexes, IPL, tty locking
hi, > On Thu, Oct 22, 2009 at 12:32:12PM +0100, Mindaugas Rasiukevicius wrote: > > IPL is only being raised and that works in reference counting principle. > > Therefore IPL is lowered (and only to IPL_NONE) after the last release, > > see ci_mtx_oldspl and ci_mtx_count. Which means that order of releases > > does not matter. Gradual IPL lowering would unnecessary complicate the > > implementation or interface. > > Not that much. Here's some strawman code based on what's in one of my > kernels, adapted partly for NetBSD. It isn't tested (and doesn't > compile) but the original form does of course compile, run, and work > in its own environment. > > I'm not suggesting that we use this as such (and it would take quite a > bit of work to merge it) but I think the general approach is worth > considering. i don't think it's worth to do at this point because - much complexity for little gain. - it involves more frequent change of the effective IPL, which might be expensive. otoh, given that we have multi levels of hw interrupts, spin locks can be nested even for not-so-poor code. it might be worth to reinvestigate at some point later. (when more interrupt handlers get mp-safe.) however, even if it turns out to be a problem, my bet is that moving more work from hw interrupt to softint is a better solution. YAMAMOTO Takashi
Re: NFS hangs - now always last 5-6 minutes
On Mon, Feb 08, 2010 at 06:33:28PM -0500, Brian Marcotte wrote: > I have more on our NFS hangs. When it happens lately, it almost always > lasts 5-6 minutes, and ends with this kernel message: > > short receive (548/16512) from nfs server trantor3:/users/u The server is presently a NetApp, or a Solaris box? Thor
NFS hangs - now always last 5-6 minutes
I have more on our NFS hangs. When it happens lately, it almost always lasts 5-6 minutes, and ends with this kernel message: short receive (548/16512) from nfs server trantor3:/users/u The mount comes back right at that moment. I find it very interesting that it almost always lasts 5-6 minutes. It looks like there is something timing out, but I can't find what it is. -- I've grabbed a couple of NFS patches from netbsd-5/-current which looked like they might help this problem, but it's still happening. nfs_socket.c 1.185 and 1.181: nfs_request: fix races which break congestion window and make nfs client stuck. If send fails with EMSGSIZE for whatever reason, it's unlikely to succeed no matter how hard we retry. So just fail the request. Thanks. -- - Brian
enabling uthum(4) in GENERIC
Hi, Now that we have an uthum(4) driver, for TEMPer and TEMPerHUM usb thermometers (and hygrometer in the case of TEMPerHUM), I was wondering if it is a good idea to enable it in GENERIC kernel configuration, and if so, in which architectures. So far, it has only be tested on i386 to my knowledge. Do you have any recommendations ? Best regards, antoine pgp4yJfbnumsj.pgp Description: PGP signature
Re: unhooking lfs from ufs
On Mon, 8 Feb 2010, Adam Hamsik wrote: > On Feb,Monday 8 2010, at 10:37 PM, Eduardo Horvath wrote: > > > On Mon, 8 Feb 2010, Adam Hamsik wrote: > > > >> On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote: > >> > >>> On Mon, 8 Feb 2010, Adam Hamsik wrote: > >>> > Are you sure that you can really finish this ? Currently you are working > on namei, ufs_lookup and many other issues. Make LFS not compilable is > the way to make it disappear very soon. I think that these changes > should happen in separate branch and should be committed back to main > branch only when it will be at least compilable again. > >>> > >>> s/compilable/reasonably solid/ > >>> > >>> I'll be rather upset if my lfs partitions suddenly stop working. > >> > >> LFS is not solid for a long time, now. > > > > The only problems I've been having with it resently are media errors. > > What version of NetBSD are you using ? LFS is known to be broken after > vmlocking2 merge, because it heavily depended on kernel big lock model used > before. NetBSD nonplus 5.99.23 NetBSD 5.99.23 (GENERIC.MP) #0: Fri Dec 25 01:58:51 PST 2009 eh29...@nonplus:/export/home/work/src/sys/arch/sparc64/compile/GENERIC.MP sparc64
Re: uticom(4)
srecord is no longer required to build the firmware: ftp://ftp.NetBSD.org/pub/NetBSD/misc/yhardy/uticom20100208.tar.bz2 -- Kind regards, Yorick Hardy
Re: unhooking lfs from ufs
On Feb,Monday 8 2010, at 10:37 PM, Eduardo Horvath wrote: > On Mon, 8 Feb 2010, Adam Hamsik wrote: > >> On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote: >> >>> On Mon, 8 Feb 2010, Adam Hamsik wrote: >>> Are you sure that you can really finish this ? Currently you are working on namei, ufs_lookup and many other issues. Make LFS not compilable is the way to make it disappear very soon. I think that these changes should happen in separate branch and should be committed back to main branch only when it will be at least compilable again. >>> >>> s/compilable/reasonably solid/ >>> >>> I'll be rather upset if my lfs partitions suddenly stop working. >> >> LFS is not solid for a long time, now. > > The only problems I've been having with it resently are media errors. What version of NetBSD are you using ? LFS is known to be broken after vmlocking2 merge, because it heavily depended on kernel big lock model used before. Regards Adam.
Re: unhooking lfs from ufs
On Mon, 8 Feb 2010, Adam Hamsik wrote: > On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote: > > > On Mon, 8 Feb 2010, Adam Hamsik wrote: > > > >> Are you sure that you can really finish this ? Currently you are working > >> on namei, ufs_lookup and many other issues. Make LFS not compilable is the > >> way to make it disappear very soon. I think that these changes should > >> happen in separate branch and should be committed back to main branch only > >> when it will be at least compilable again. > > > > s/compilable/reasonably solid/ > > > > I'll be rather upset if my lfs partitions suddenly stop working. > > LFS is not solid for a long time, now. The only problems I've been having with it resently are media errors. Eduardo
Re: unhooking lfs from ufs
On Mon, 8 Feb 2010, Thor Lancelot Simon wrote: > On Mon, Feb 08, 2010 at 08:33:28PM +, Eduardo Horvath wrote: > > > > I'll be rather upset if my lfs partitions suddenly stop working. > > Personally, I'd be rather astonished if the ones I used to use > suddenly _started_ working. I have to say if LFS is working for you > right now you are probably in a very small minority of those who have > tried to use it since the vmlocking2 merge. > > Are you perchance on a uniprocessor? No. Both CPUs are running. Eduardo
Re: unhooking lfs from ufs
On Feb,Monday 8 2010, at 9:33 PM, Eduardo Horvath wrote: > On Mon, 8 Feb 2010, Adam Hamsik wrote: > >> Are you sure that you can really finish this ? Currently you are working on >> namei, ufs_lookup and many other issues. Make LFS not compilable is the way >> to make it disappear very soon. I think that these changes should happen in >> separate branch and should be committed back to main branch only when it >> will be at least compilable again. > > s/compilable/reasonably solid/ > > I'll be rather upset if my lfs partitions suddenly stop working. LFS is not solid for a long time, now. Regards Adam.
Re: unhooking lfs from ufs
On Mon, Feb 08, 2010 at 08:33:28PM +, Eduardo Horvath wrote: > > I'll be rather upset if my lfs partitions suddenly stop working. Personally, I'd be rather astonished if the ones I used to use suddenly _started_ working. I have to say if LFS is working for you right now you are probably in a very small minority of those who have tried to use it since the vmlocking2 merge. Are you perchance on a uniprocessor? -- Thor Lancelot Simont...@rek.tjls.com "All of my opinions are consistent, but I cannot present them all at once."-Jean-Jacques Rousseau, On The Social Contract
Re: unhooking lfs from ufs
On Mon, 8 Feb 2010, Adam Hamsik wrote: > Are you sure that you can really finish this ? Currently you are working on > namei, ufs_lookup and many other issues. Make LFS not compilable is the way > to make it disappear very soon. I think that these changes should happen in > separate branch and should be committed back to main branch only when it will > be at least compilable again. s/compilable/reasonably solid/ I'll be rather upset if my lfs partitions suddenly stop working. Eduardo
Re: Kernel loadable modules and missing symbols
On Monday 08 February 2010 21:04:36 Matthias Drochner wrote: > hsela...@c2i.net said: > > It would be nice if missing symbols could be printed to dmesg when > > loading modules under NetBSD 5.x. This helps debugging problems. > > I don't have a 5.x tree -- how far do you get if you try > to pull in rev. 1.28 of subr_kobj.c? > I agree that without getting the offending symbol named > it is tedious to find. > > best regards > Matthias Hi, Thanks for your suggestion. I found the missing symbols by adding some prints myself and build a new NetBSD kernel. --HPS
Re: unhooking lfs from ufs
Hi David, > > > The copy involves 18 files from sys/ufs/ufs (out of 21; the ones > excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain > 9067 lines of code. That gives the following statistics: > > 14988 size of lfs currently >+ 9067 size of copypasted ufs > 24055 size of resulting uncompilable lfs >- 401 result of making it compilable > 23654 size of new lfs > > This is the size of the code in sys/ufs/lfs; the userlevel tools need > patching but don't change size significantly. > > My guess/estimate is that after several rounds of consolidation the > total size will drop to around 18000-19000 lines. Maybe less, even, > but I wouldn't count on that. I'll be keeping an eye on the total size > going forward. > > Anyway, I have done this much and it's ready to go. I will be > committing it tonight, I think, unless there are sudden howls of > protest. > > The diff (from HEAD of a couple hours ago to the new compilable lfs) > is posted here: > > http://www.eecs.harvard.edu/~dholland/netbsd/lfs-ufs-20100207.diff > > I will probably commit the pasted-only uncompilable form first, and > maybe some of the intermediate steps as well, for the historical > record and to make future merges easier. This may make the tree > temporarily unbuildable, but hopefully not for very long. Are you sure that you can really finish this ? Currently you are working on namei, ufs_lookup and many other issues. Make LFS not compilable is the way to make it disappear very soon. I think that these changes should happen in separate branch and should be committed back to main branch only when it will be at least compilable again. Regards Adam.
Re: Kernel loadable modules and missing symbols
hsela...@c2i.net said: > It would be nice if missing symbols could be printed to dmesg when > loading modules under NetBSD 5.x. This helps debugging problems. I don't have a 5.x tree -- how far do you get if you try to pull in rev. 1.28 of subr_kobj.c? I agree that without getting the offending symbol named it is tedious to find. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: Cannot list a particular directory through NFS with UDP
> I have seen NFS fail (with the old 8K packets) on a network that was > badly terminated (back in the 10base2 days) because the back-to-back > packets self-collided while single packets with some spacing made it > fine. I recall I once had an NFS problem that exhibited itself as failures reading files of certain sizes. Turned out that the reader had problems receiving packets smaller than a certain size at the Ethernet level. UDP and NFS overhead meant that every packet was larger than that, but if the file size was right, the last data packet got fragmented and the last frag got lost thanks to this. As I recall, the sender padded to 60 octets but the receiver required 64 - but the exact values are rather fuzzy; this was decades ago. Mounting with rsize=1024 hid the problem, because then no NFS packet got hit with IP-layer fragmentation. A TCP mount would doubtless have worked just as well, if reliable TCP mounts had existed at the time (I don't think they did). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Protecting global lookup array
On Mon, Feb 08, 2010 at 11:40:50AM +0900, Masao Uebayashi wrote: > The update process is very rare, and expected. Administrators carefully > connects a device when the machine is not running some important task. So > what I need here is to protect such a data adding no run-time performance > loss. > > Do we have any standard way to do this? I don't think there is a standard way. Does the tc_detach() approach work for the vm_physseg list? BTW, a similar problem is to make sure all threads have exited a device_t/softc before detaching it, with the least changes to the code and the least expensive synchronization mechanism. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: unhooking lfs from ufs
Hmmm... Eduardo Horvath wrote: On Sun, 7 Feb 2010, David Holland wrote: Anyhow, it seems to me that isolating it from changes to ffs is likely to result in less breakage over time, not more. Can you expand on your reasoning some? The most significant parts that are shared are the directory ops and the read/write routeines. The directory ops are essentially FFS code with an LFS wrapper around it. Right now any ffs bugfixes for those used directly by LFS. The read/write routines also share about 80% of the code. I suppose there is a better case for separating these out if it makes code maintenance easier. If we were to separate them out then every time someone fixes a problem with FFS, the same changes would be required to be made for LFS. Historically this has not happened. When you look at UVM or UBC integration, there were long periods of time when LFS was unusable because that filesystem has been considered of secondary importance. So, the fact that the code was shared did indeed *not* make FFS fixes also flow over into LFS? (I assume that FFS was fixed for those things in short order.) That would, in my eyes, mean that this argument isn't valid. LFS has a rather small user base since it's historically been considered experimental and most machines can't boot from it. Few people use it and fewer still work on it. Indeed. I tried LFS a few times many years ago, but had some problems with it, along with the "experimenal" status of it, which made me stop trying. I would love to hear someone allay my fears, but I think segregating the LFS code from the FFS code will accelerate the bitrot and the final result will be removal of the LFS code. I can't alleviate your fears, however, it appears to me that the assumption that LFS benefits from sharing code with FFS is wrong, or atleast exaggerated. Looking at how the LFS code have had problems for extended periods, even with shared code with FFS suggests that LFS have not really gained much from that sharing. Having the code split, and then possibly getting it leaner and cleaner, looks like a potential gain atleast. Johnny
Re: kthread with kpause or callout
On Mon, Feb 08, 2010 at 03:36:07PM +0100, Martin Husemann wrote: > On Mon, Feb 08, 2010 at 03:35:35PM +0100, Frank Wille wrote: > > IMHO that would allow my callout to sleep on acquiring the mutex? > > A softint can sleep, a callout can not. s/can/should/ Joerg
Re: unhooking lfs from ufs
Perhaps not a very meaningful voice, but I think it makes sense to split them. Johnny David Holland wrote: On Mon, Feb 08, 2010 at 11:03:44AM +0900, Masao Uebayashi wrote: > This thread? > > http://mail-index.netbsd.org/tech-kern/2009/07/21/msg005526.html That was later - that's about what happens to quotas afterwards. But I can't find the original thread, which as I recall was moderately lengthy, so maybe it wasn't on tech-kern? Anyway, I want to hear the rest of what eeh@ has to say, which means I'm not going ahead tonight, which means nothing will be happening for a few days at least anyhow. So if anyone wants to object or hash through this in detail now, go right ahead.
Re: kthread with kpause or callout
On Mon, Feb 08, 2010 at 03:35:35PM +0100, Frank Wille wrote: > IMHO that would allow my callout to sleep on acquiring the mutex? A softint can sleep, a callout can not. Martin
Re: kthread with kpause or callout
On Mon, 8 Feb 2010 15:12:10 +0100 Martin Husemann wrote: > On Mon, Feb 08, 2010 at 03:09:55PM +0100, Martin Husemann wrote: > > The wording is not explicit, but a softint is not allowed to block > > on > > s/softint/callout/ of course, sorry for the confusion. *Now* you confused me! :) A callout is executed as a softint, isn't it? -- Frank Wille
Re: kthread with kpause or callout
On Mon, 8 Feb 2010 15:09:55 +0100 Martin Husemann wrote: > On Mon, Feb 08, 2010 at 03:04:07PM +0100, Frank Wille wrote: > > [...] May I acquire this mutex during a callout (which is a > > softint, as I understand)? Will the softint sleep or busy-wait? > > Depends on the mutex type, from mutex(9): > [...] > Adaptive mutexes cannot be acquired from a hardware > interrupt handler. > [...] > The wording is not explicit, but a softint is not allowed to block on > an adaptive mutex, Yes, this is what I thought as well, but the man page only mentions hardware interrupts. Are you sure about it? Hmmm... from softint(9): [...] Unlike hardware interrupts, software interrupts do have thread context. They may block on synchro- nization objects, sleep, and resume execution at a later time. [...] IMHO that would allow my callout to sleep on acquiring the mutex? -- Frank Wille
Re: kthread with kpause or callout
On Mon, Feb 08, 2010 at 03:09:55PM +0100, Martin Husemann wrote: > The wording is not explicit, but a softint is not allowed to block on s/softint/callout/ of course, sorry for the confusion. Martin
Re: kthread with kpause or callout
On Mon, Feb 08, 2010 at 03:04:07PM +0100, Frank Wille wrote: > I'm just unsure about using mutexes during the callout. I have an > IPL_NONE-kmutex which locks register access (my chip supports several > register banks, so I need to make sure they are not switched). May I > acquire this mutex during a callout (which is a softint, as I understand)? > Will the softint sleep or busy-wait? Depends on the mutex type, from mutex(9): IPL_NONE, or one of the IPL_SOFT* constants An adaptive mutex will be returned. Adaptive mutexes provide mutual exclusion between LWPs, and between LWPs and soft interrupt handlers. Adaptive mutexes cannot be acquired from a hardware interrupt handler. An LWP may either sleep or busy-wait when attempt- ing to acquire an adaptive mutex that is already held. IPL_VM, IPL_SCHED, IPL_HIGH A spin mutex will be returned. Spin mutexes provide mutual exclusion between LWPs, and between LWPs and interrupt han- dlers. The wording is not explicit, but a softint is not allowed to block on an adaptive mutex, you need a spin mutex for that (usually such mutexes are used by interrupt handlers, so you have a "natural" IPL to use here). A caller will always busy wait trying to aquire a spin mutex, but it might fall back to sleep on an adaptive mutex. Martin
Re: kthread with kpause or callout
On Mon, 8 Feb 2010 11:29:51 +0100 Martin Husemann wrote: > On Mon, Feb 08, 2010 at 11:11:04AM +0100, Frank Wille wrote: > > - Running a kthread and calling kpause() between the polls. > > - Using a callout which reschedules itself after the poll. > > The thread is quite a bit more heavyweight, but you have full freedom > to do what you want. The callout is pretty lightweight but you are > still subject of "interrupt context" rules. Ok, thanks. Then the callout should be fine for me. I'm just unsure about using mutexes during the callout. I have an IPL_NONE-kmutex which locks register access (my chip supports several register banks, so I need to make sure they are not switched). May I acquire this mutex during a callout (which is a softint, as I understand)? Will the softint sleep or busy-wait? -- Frank Wille
Re: need help with kern/42758 - correctly initialize W83627HF hwmon
On Mon, 8 Feb 2010, Michael Stapelberg wrote: Hi Paul, Excerpts from Paul Goyette's message of Mo Feb 08 00:14:44 +0100 2010: Can you try the attached diff, and set 'flags 1' in your config file? The patch works fine. I would suggest to use flag 2, however, to be consistent with the linux driver. The Linux driver seems to do something a little bit strange... From http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/hwmon/w83781d?annotate=1.1 The W83782D and W83783S temperature conversion machine understands about several kinds of temperature probes. You can program the so-called beta value in the sensor files. '1' is the PII/Celeron diode, '2' is the TN3904 transistor, and 3435 the default thermistor value. Other values are (not yet) supported. The datasheet for the sensor says Reg. 0x59 bits [654] Temperature sensor diode [321]. Set to 1, select Pentium II compatible Diode. Set to 0 to select 2N3904 Bipolar mode. Power-On default is 1. Reg. 0x5d bits [321] Temperature sensor [321]. Set to 1, select bipolar sensor. Set to 0, select thermistor sensor. Power-On default is 0. So, from the datasheet, there seem to be only two sensor types, with Pentium II Diode being the default, while the Linux docs claim three sensor types and a default of some non-Pentium thermistor. Rather confusing. For now, I'm inclined to do things according to the datasheet. :) Unless anyone objects, I'll commit my patch later today. (And I'll add comments on the flag value in all of the config files that contain the lm(4) device.) - | Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: unhooking lfs from ufs
On Sun, Feb 7, 2010 at 9:56 PM, David Holland wrote: > On Mon, Feb 08, 2010 at 03:37:37AM +, Eduardo Horvath wrote: > > I would love to hear someone allay my fears, but I think segregating the > > LFS code from the FFS code will accelerate the bitrot and the final result > > will be removal of the LFS code. > > Well. lfs is currently pretty broken and without a substantial > rototill it's going to stay broken. And if it stays broken, it's > certainly going to end up removed. Certain people have already been > agitating to remove it. > > It seems to me that unhooking lfs from ufs is the necessary first step > towards any substantial overhaul of lfs. This is why I'm proposing it. > > There are some people who would like this unhook done so that lfs > stops complicating ufs; they will doubtless be happy to ignore lfs > afterwards, but my goal is to make it work. if lfs can be made to work comparable to or better than anything we currently have, this will be a win. my perspective tells me that lfs is more or less obsolete at this point and ripping it out and letting it die is its ultimate destiny. -- --*greywolf; /* relayer @t gmail d0t com */ /* ^ spam decoy ^ */
Re: kthread with kpause or callout
On Mon, Feb 08, 2010 at 11:11:04AM +0100, Frank Wille wrote: > - Running a kthread and calling kpause() between the polls. > - Using a callout which reschedules itself after the poll. The thread is quite a bit more heavyweight, but you have full freedom to do what you want. The callout is pretty lightweight but you are still subject of "interrupt context" rules. I ran into a similar case recently where I didn't want full thread context but needed it sometimes - I ended up using a a rescheduled callout plus sometimes adding a job to the sysmon workqueue (sysmon_task_queue_sched(), this task was in envsys scope, so it was an easy way out). Martin
kthread with kpause or callout
Hi, I'm writing a keyboard driver which doesn't support interrupts in some revisions, so I have to poll its status from time to time. What would be better suited for that task: - Running a kthread and calling kpause() between the polls. - Using a callout which reschedules itself after the poll. Or is there something even better suited, which I'm missing? -- Frank Wille
Re: Protecting global lookup array
> On the plus side, this is essentially the same problem as safely > switching vnodes to deadfs after a umount -f; on the minus side, > nobody's yet come up with a satisfactory solution for that... I think your problem involves much more things & more complicated. :) Just curious, what's missing to achieve umount -f specifically? Masao -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
