Re: ZFS Panic on USB SCSI Device
If anyone is curious it seems this is a somewhat random occurrence. I think its unrelated to ZFS probably so nevermind. It works flawlessly now :-) On 6/4/07, Ali Mashtizadeh [EMAIL PROTECTED] wrote: I have been using ZFS on my laptop with a ZFS root works flawlessly. The problem is that I put a ZFS filesystem on my external usb harddrive which shows up as da0 so it looks like a scsi device. And I keep getting CAM errors saying logical block address out of range. Am I doing something wrong is there some special thing I need to do? The errors are okay at first but after a couple of them it PANICs. In case your wondering its ONLY ZFS, UFS and the MSDOS partitions work fine on the same drive. My build of current is about a week old. -- Ali Mashtizadeh علی مشتی زاده -- Ali Mashtizadeh علی مشتی زاده ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kern.ngroups question
Hello all, Can someone explain to me the rationale behind having ngroups_max set to 16 by default? I came across this issue originally when working on our Samba implementation (samba-3 out of ports, running on 6-STABLE). We have some users that belong to a number of groups, some of whom need to belong to more groups than the defined hard limit. On doing a little research, I did come across the PR detailed in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108552, and continued reading the linked thread from March 2003, however this really doesn't explain why the limit is set to 16. Can one adjust the value in syslimits.h on a system and then rebuild world/ports with the expectation this will work, or is the issue more involved then that? Is (or has) there any discussion on raising that number to a larger value? Thanks in advance (doubly so if this is a lame question) Reuben -- Reuben A. Popp Systems Administrator Information Technology Department East Central College 1+ 636 583 5195 x2480 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern.ngroups question
On Tue, 05-Jun-2007 at 11:49:44 -0500, Reuben A. Popp wrote: Hello all, Can someone explain to me the rationale behind having ngroups_max set to 16 by default? I came across this issue originally when working on our Samba implementation (samba-3 out of ports, running on 6-STABLE). We have some users that belong to a number of groups, some of whom need to belong to more groups than the defined hard limit. On doing a little research, I did come across the PR detailed in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108552, and continued reading the linked thread from March 2003, however this really doesn't explain why the limit is set to 16. Can one adjust the value in syslimits.h on a system and then rebuild world/ports with the expectation this will work, or is the issue more involved then that? Is (or has) there any discussion on raising that number to a larger value? About 2 years ago I changed it to 64 (all over the place) and recompiled world, kernels, ports and every programme on the boxes in question. Things worked well but NFS went mad (IIRC, NFS4 will do better here but I am not sure). Since I needed the groups in question to control file access, I reverted the change and switched to ACLs which is not so intrusive :-). -Andre Thanks in advance (doubly so if this is a lame question) Reuben -- Reuben A. Popp Systems Administrator Information Technology Department East Central College 1+ 636 583 5195 x2480 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- ech`echo xiun | tr nu oc | sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern.ngroups question
Reuben A. Popp wrote: Hello all, Can someone explain to me the rationale behind having ngroups_max set to 16 by default? NFS only supports this much by default (from memory). Samba (in the guise of Jeremy Allison) has asked us to follow Linux's lead and support an arbitrary number of Groups but it hasn't happened yet, Partly due to the question of what to do about NFS and partly just due to ENOTIME. I came across this issue originally when working on our Samba implementation (samba-3 out of ports, running on 6-STABLE). We have some users that belong to a number of groups, some of whom need to belong to more groups than the defined hard limit. On doing a little research, I did come across the PR detailed in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108552, and continued reading the linked thread from March 2003, however this really doesn't explain why the limit is set to 16. Can one adjust the value in syslimits.h on a system and then rebuild world/ports with the expectation this will work, or is the issue more involved then that? Is (or has) there any discussion on raising that number to a larger value? Thanks in advance (doubly so if this is a lame question) Reuben ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Writing a plain text file to disk from kernel space
On Thursday 24 May 2007 11:26:58 pm Lawrence Stewart wrote: Comments inline... Dag-Erling Smørgrav wrote: Lawrence Stewart [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Since you are writing kernel code, I assume you have KDB/DDB in your kernel and know how to use it. I don't know how to use them really. Thus far I haven't had a need for really low level debugging tools... seems that may have changed though! Any good tutorials/pointers on how to get started with kernel debugging? The handbook and FAQ have information on debugging panics. Greg Lehey (grog@) does a tutorial on kernel debugging, you can probably find slides online (or just ask him) For reference, I found what looks to be a very comprehensive kernel debugging reference here: http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf Greg certainly knows the ins and outs of kernel debugging! kio_write probably blocks waiting for the write to complete. You can't do that while holding a non-sleepable lock. So this is where my knowledge/understanding gets very hazy... When a thread blocks waiting for some operation to complete or event to happen, the thread effectively goes to sleep, correct? It depends on the type of lock used, but mostly, yes. Looking at the kio_write code in subr_kernio.c, I'm guessing the lock that is causing the trouble is related to the vn_lock function call? What matters is that kio_write() may sleep and therefore can't be called while holding a non-sleepable lock. I don't understand though why the vnode lock would be set up in such a way that when the write blocks whilst waiting for the underlying filesystem to signal everything is ok, it causes the kernel to panic! You cannot sleep while holding a non-sleepable lock. You need to find out which locks are held at the point where you call kio_write(), and figure out a way to delay the kio_write() call until those locks are released. How do I make the lock sleepable or make sure the thread doesn't try go to sleep whilst holding the lock? You can't make an unsleepable lock sleepable. You might be able to replace it with a sleepable lock, but you would have to go through every part of the kernel that uses the lock and make sure that it works correctly with a sleepable lock. Most likely, it won't. Thanks for the explanations. I'm starting to get a better picture of what's actually going on. So it seems that there is no way I can call kio_write from within the function that is acting as a pfil output hook, because it blocks at some point whilst doing the disk write, which makes the kernel unhappy because pfil code is holding a non-sleepable mutex somewhere. If you read my other message from yesterday, I still can't figure out why this only happens with outbound TCP traffic, but anyways... I'll have a bit more of a think about it and get back to the list shortly... Use a task to defer the kio_write() to a taskqueue. You have to malloc state (using M_NOWAIT, which can fail) to do this properly. If you are doing this for every packet, you are probably better off using malloc() to throw items into a queue and having a global task that drains the queue on each execution doing kio_write()'s for each object. Regarding sleepable vs. non-sleepable locks. Getting preempted by an interrupt is not considered sleeping. Sleeping means voluntarily yielding the CPU to wait for an event such as via msleep() or a condition variable. Note that interrupt handlers can acquire non-sleepable locks. If you sleep while holding a non-sleepable lock, you may have an interrupt handler that can't run while it waits for some async event (like disk I/O) to complete. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stopping callouts
On Monday 04 June 2007 05:39:32 am Artis Caune wrote:
Sam Leffler wrote:
If you use callout_init_mtx then use callout_stop while holding my_mtx;
if the callout is blocked waiting for my_mtx the request will be
discarded.
callout_drain should not be called while holding my_mtx because it can
sleep.
Thanks,
than I will use:
MTX_LOCK;
...
callout_stop();
MTX_UNLOCK;
During module unload (or device detach) you should still do a callout_drain()
before destroying the mutex, to make sure softclock() doesn't race with the
mtx_destroy().
Thus:
foo_detach()
{
FOO_LOCK(sc);
foo_stop(sc);
callout_stop(sc-callout);
FOO_UNLOCK(sc);
bus_teardown_intr(...)
bus_release_resources(...);
callout_drain(sc-callout);
mtx_destroy(sc-lock);
}
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Writing a plain text file to disk from kernel space
Hi John, Thanks for the reply and additional information on locks. The solution I've just completed working on is designed exactly as you describe. We're about to begin testing and evaluating the module, and we'll be releasing the code and 2 technical reports related to it within the coming weeks with any luck. The first report describes the module and its performance characteristics... only interesting to people doing TCP related research with FreeBSD. The other report is a sort of intro to FreeBSD kernel hacking paper, which is a brain dump of all the useful lessons we've learnt throughout the process. This report is mostly for our benefit so we remember the lessons we learnt for next time, but we're hoping it will also be something useful for the community to point noob kernel hackers at for some introductory information. I'll be posting to this list as soon as the code and reports are available, as it has been indicated by people following this thread that having some sort of tutorial/reference information would be useful. Cheers, Lawrence John Baldwin wrote: Use a task to defer the kio_write() to a taskqueue. You have to malloc state (using M_NOWAIT, which can fail) to do this properly. If you are doing this for every packet, you are probably better off using malloc() to throw items into a queue and having a global task that drains the queue on each execution doing kio_write()'s for each object. Regarding sleepable vs. non-sleepable locks. Getting preempted by an interrupt is not considered sleeping. Sleeping means voluntarily yielding the CPU to wait for an event such as via msleep() or a condition variable. Note that interrupt handlers can acquire non-sleepable locks. If you sleep while holding a non-sleepable lock, you may have an interrupt handler that can't run while it waits for some async event (like disk I/O) to complete. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
