radeon_cp_texture: page fault with non-sleepable locks held
I use FreeSBD head and KDE 4 with all the bells and whistles enabled. Apparently recent KDE update has enabled even more of them, because I started to have panics with a kernel that has INVARIANTS and WITNESS enabled. The panic: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xff0001b968a0) locked @ /usr/src/sys/dev/drm/drm_drv.c:791 KDB: stack backtrace: db_trace_self_wrapper() at 0x801b8afa = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x803a7afa = kdb_backtrace+0x3a _witness_debugger() at 0x803bd49c = _witness_debugger+0x2c witness_warn() at 0x803bed32 = witness_warn+0x322 trap() at 0x8054639f = trap+0x39f calltrap() at 0x80530688 = calltrap+0x8 --- trap 0xc, rip = 0x8054411d, rsp = 0xff81241917f0, rbp = 0xff8124191870 --- copyin() at 0x8054411d = copyin+0x3d radeon_cp_texture() at 0x8022fcc7 = radeon_cp_texture+0x167 drm_ioctl() at 0x8020fa78 = drm_ioctl+0x318 devfs_ioctl_f() at 0x802dd739 = devfs_ioctl_f+0x109 kern_ioctl() at 0x803c1197 = kern_ioctl+0x1f7 ioctl() at 0x803c1358 = ioctl+0x168 syscallenter() at 0x803b584e = syscallenter+0x26e syscall() at 0x80545f12 = syscall+0x42 Xfast_syscall() at 0x80530962 = Xfast_syscall+0xe2 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x801f96a1c, rsp = 0x7fffe7a8, rbp = 0xc020644e --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x832372000 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8054411d stack pointer = 0x28:0xff81241917f0 frame pointer = 0x28:0xff8124191870 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 3 current process = 3439 (initial thread) trap number = 12 panic: page fault cpuid = 0 The panic is quite obvious: drmdev mutex is taken and held in drm_ioctl() and radeon_cp_texture() can perform copyin and/or copyout, so it's a matter of a chance (or proper workload) to hit a page fault there. What's not obvious is how to properly fix this. Any ideas? Probably less important is what started to trigger the problem. Because the code hasn't been changed in ages and I have never seen this issue before. But, d'oh, it seems that this issue has been already reported: http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg67757.html I will appreciate any help. Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
utmpx (was: Re: 9-CURRENT: ports/net/kdenetwork3 does not compile)
Hello, I found another port lacking utmpx support: # cd /usr/ports/security/chkrootkit # make === chkrootkit-0.49 is marked as broken: fails to build with new utmpx. *** Error code 1 matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: processes stuck on a vnode lock
on 04/11/2010 16:45 Andriy Gapon said the following: on 04/11/2010 09:49 Andriy Gapon said the following: I see a few processes stuck on the same vnode, trying to take or to upgrade to an exclusive lock on it, while the lock data suggests that it is already shared-locked. The vnode is a root vnode of one of ZFS filesystems (it's not a global root). I couldn't find any (other) threads that could actually hold the vnode lock, but lock shared count is suspiciously or coincidentally the same as number of threads in zfs_root call. BTW, I still have the system alive and online, so if anyone has ideas I can try them. The kernel is not live now, but I have saved it and vmcore of the system. Kostik, just a pure guesswork here - could r214049 have something to do with this? I looked at the change and it looks completely correct - I don't think that a vnode lock can be leaked by that code. But, OTOH, it has some special handling for VV_ROOT, it's in NFS code and and it's in a right time-frame, so just asking. Here's a link to the start of this report thread: http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/10659/focus=128893 -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Patch] libfetch - closing the cached FTP connection
Mark,
My 2 cents: Isn't it more appropriate to set FD_CLOEXEC on the fd?
fcntl(fd, F_SETFD, FD_CLOEXEC);
It doesn't sound like you ever want to have a cached connection be copied into
the child. Mum and child calling daddy using the same phone line isn't going to
make the conversation any easier for daddy.
Cheers,
Nick
On 25 Oct 2010, at 01:16, Mark Johnston wrote:
Hello,
We've run into problems with pkg_add because of some caching behaviour
in libfetch. Specifically, after an FTP transfer, a connection to the
FTP server is held open by the cached_connection pointer in ftp.c. Thus,
if one requests a file with fetchGetFTP() and later closes the
connection with fclose(), a socket is still held open, and the
descriptor is copied to any child processes.
What was apparently happening was that we were using pkg_add to install
a package whose install script started a daemon, which consequently kept
open a connection to our FTP server. This is fixed in our tree with a
closefrom(2) in pkg_install at an appropriate point, but I thought that
libfetch should provide some way of forcing a close on the cached
connection so that the above hack isn't necessary.
My solution is provided in a patch below. It's not particularly elegant,
but I can't see a better way to go about it. I was hoping to get some
feedback and to see if anyone can come up with a better approach. I'll
also update the libfetch man page if the patch below is acceptable.
Thanks,
-Mark
diff --git a/lib/libfetch/fetch.h b/lib/libfetch/fetch.h
index 11a3f77..d379e63 100644
--- a/lib/libfetch/fetch.h
+++ b/lib/libfetch/fetch.h
@@ -109,6 +109,7 @@ FILE *fetchGetFTP(struct url *, const char
*);
FILE *fetchPutFTP(struct url *, const char *);
intfetchStatFTP(struct url *, struct url_stat *, const char *);
struct url_ent*fetchListFTP(struct url *, const char *);
+void fetchCloseCachedFTP();
/* Generic functions */
FILE *fetchXGetURL(const char *, struct url_stat *, const char *);
diff --git a/lib/libfetch/ftp.c b/lib/libfetch/ftp.c
index 0983a76..746ad54 100644
--- a/lib/libfetch/ftp.c
+++ b/lib/libfetch/ftp.c
@@ -1204,3 +1204,12 @@ fetchListFTP(struct url *url __unused, const char
*flags __unused)
warnx(fetchListFTP(): not implemented);
return (NULL);
}
+
+/*
+ * Force close the cached connection.
+ */
+void
+fetchCloseCachedFTP()
+{
+ ftp_disconnect(cached_connection);
+}
diff --git a/usr.sbin/pkg_install/lib/url.c b/usr.sbin/pkg_install/lib/url.c
index 914ce39..68f31bb 100644
--- a/usr.sbin/pkg_install/lib/url.c
+++ b/usr.sbin/pkg_install/lib/url.c
@@ -163,5 +163,6 @@ fileGetURL(const char *base, const char *spec, int
keep_package)
printf(tar command returns %d status\n, WEXITSTATUS(pstat));
if (rp (isatty(0) || Verbose))
printf( Done.\n);
+fetchCloseCachedFTP();
return rp;
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Patch] libfetch - closing the cached FTP connection
On Fri, Nov 5, 2010 at 1:38 AM, Nick Hibma n...@van-laarhoven.org wrote:
Mark,
My 2 cents: Isn't it more appropriate to set FD_CLOEXEC on the fd?
fcntl(fd, F_SETFD, FD_CLOEXEC);
It doesn't sound like you ever want to have a cached connection be copied
into the child. Mum and child calling daddy using the same phone line isn't
going to make the conversation any easier for daddy.
Cheers,
Nick
On 25 Oct 2010, at 01:16, Mark Johnston wrote:
Hello,
We've run into problems with pkg_add because of some caching behaviour
in libfetch. Specifically, after an FTP transfer, a connection to the
FTP server is held open by the cached_connection pointer in ftp.c. Thus,
if one requests a file with fetchGetFTP() and later closes the
connection with fclose(), a socket is still held open, and the
descriptor is copied to any child processes.
What was apparently happening was that we were using pkg_add to install
a package whose install script started a daemon, which consequently kept
open a connection to our FTP server. This is fixed in our tree with a
closefrom(2) in pkg_install at an appropriate point, but I thought that
libfetch should provide some way of forcing a close on the cached
connection so that the above hack isn't necessary.
My solution is provided in a patch below. It's not particularly elegant,
but I can't see a better way to go about it. I was hoping to get some
feedback and to see if anyone can come up with a better approach. I'll
also update the libfetch man page if the patch below is acceptable.
Thanks,
-Mark
diff --git a/lib/libfetch/fetch.h b/lib/libfetch/fetch.h
index 11a3f77..d379e63 100644
--- a/lib/libfetch/fetch.h
+++ b/lib/libfetch/fetch.h
@@ -109,6 +109,7 @@ FILE *fetchGetFTP(struct url *, const char
*);
FILE *fetchPutFTP(struct url *, const char *);
int fetchStatFTP(struct url *, struct url_stat *, const char *);
struct url_ent *fetchListFTP(struct url *, const char *);
+void fetchCloseCachedFTP();
/* Generic functions */
FILE *fetchXGetURL(const char *, struct url_stat *, const char *);
diff --git a/lib/libfetch/ftp.c b/lib/libfetch/ftp.c
index 0983a76..746ad54 100644
--- a/lib/libfetch/ftp.c
+++ b/lib/libfetch/ftp.c
@@ -1204,3 +1204,12 @@ fetchListFTP(struct url *url __unused, const char
*flags __unused)
warnx(fetchListFTP(): not implemented);
return (NULL);
}
+
+/*
+ * Force close the cached connection.
+ */
+void
+fetchCloseCachedFTP()
+{
+ ftp_disconnect(cached_connection);
+}
diff --git a/usr.sbin/pkg_install/lib/url.c b/usr.sbin/pkg_install/lib/url.c
index 914ce39..68f31bb 100644
--- a/usr.sbin/pkg_install/lib/url.c
+++ b/usr.sbin/pkg_install/lib/url.c
@@ -163,5 +163,6 @@ fileGetURL(const char *base, const char *spec, int
keep_package)
printf(tar command returns %d status\n, WEXITSTATUS(pstat));
if (rp (isatty(0) || Verbose))
printf( Done.\n);
+ fetchCloseCachedFTP();
return rp;
}
There are a lot of corner cases not caught with libpkg and pkg_install
that should be due to the fact that ports and pkg_install are
spaghetti code. That being said, small patches submitted to portmgr
via send-pr are more than welcome as anything that would help improve
binary packages is more than welcome.
I do agree with Nick though... it's better that the issue be `fixed'
in libpkg/pkg_install, not libfetch in this case.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: laptop Acer Aspire One D250 / snd_hda(4) internal mic not recording
El día Friday, November 05, 2010 a las 12:46:50AM +0200, Alexander Motin escribió: Matthias Apitz wrote: ... Btw II: Is there some test recording software that let me just record from /dev/dspX and play it back (to not use Skype for such tests)? dd? :) Also audio/rawrec. Indeed, a # dd if=/dev/dsp0.0 file records and # cat file /dev/dsp0.0 plays fine the recorded voice... but only from Jack :-( matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: utmpx
Matthias Apitz g...@unixarea.de writes: I found another port lacking utmpx support: # cd /usr/ports/security/chkrootkit # make === chkrootkit-0.49 is marked as broken: fails to build with new utmpx. *** Error code 1 There are more, see ports listed under utmpx.h in http://wiki.freebsd.org/PortsBrokenOnCurrent ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: utmpx
* Anonymous swel...@gmail.com, 20101105 12:58: There are more, see ports listed under utmpx.h in http://wiki.freebsd.org/PortsBrokenOnCurrent It should be noted that that list is a bit pessimistic, since various ports have been fixed in the mean time. Greetings, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpXvvDd3DgZl.pgp Description: PGP signature
Re: utmpx
On Fri, Nov 05, 2010 at 01:09:06PM +0100, Ed Schouten wrote: It should be noted that that list is a bit pessimistic, since various ports have been fixed in the mean time. Updates welcomed :-) mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); If that works ok (I think it does), I would rather have taskqueue_cancel() always be non-blocking. Even though there is a race where the task could be rescheduled by another thread in between cancel and drain, the race still exists since if the task could be scheduled between the two, it could also be scheduled just before the call to taskqueue_cancel() (in which case a taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it matching the taskqueue_drain() above). The caller still always has to provide synchronization for preventing a task's execution outright via their own locking. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: utmpx
On Fri, Nov 5, 2010 at 10:09 AM, Ed Schouten e...@80386.nl wrote: * Anonymous swel...@gmail.com, 20101105 12:58: There are more, see ports listed under utmpx.h in http://wiki.freebsd.org/PortsBrokenOnCurrent It should be noted that that list is a bit pessimistic, since various ports have been fixed in the mean time. Ed, I've made a patch for chkrootkit [1], it's building, but i didn't test if it's working. Could you take a look at it? [1] http://people.freebsd.org/~garga/patches/chkrootkit-utmpx.diff Regards -- Renato Botelho ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
stuck in cam with bad optical media
[I am probably just having an unlucky day.] I tried to burn (with growisofs) a DVD+RW disk which seems to have developed some problems. First, the burning process got stuck at the same percentage and the drive started to make unusual sounds. Then, the following messages appeared in system log: kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc:2,0 (No seek complete) kernel: ahcich5: Timeout on slot 7 kernel: ahcich5: is cs 0180 ss rs 0180 tfd 58 serr kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back After that growisofs either remained or became stuck in the following state: 42433 100119 growisofsinitial thread mi_switch+0x1de sleepq_switch+0xdb sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0x68 passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallenter+0x3be syscall+0x41 Xfast_syscall+0xe2 Any commands that tried to access the device (cdcontrol eject, camcontrol reset 5:0:0) also got stuck. Only reboot helped to recover the device. I understand that bad media is bad, but it happens. I think that cam and ahci typically recover from errors/timeouts, so somehting must have gone wrong in this case. P.S. I have already thrown out the bad disk - irritation won over reason when that happened, unfortunately :( -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success ( 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about this. Thanks, matthew If that works ok (I think it does), I would rather have taskqueue_cancel() always be non-blocking. Even though there is a race where the task could be rescheduled by another thread in between cancel and drain, the race still exists since if the task could be scheduled between the two, it could also be scheduled just before the call to taskqueue_cancel() (in which case a taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it matching the taskqueue_drain() above). The caller still always has to provide synchronization for preventing a task's execution outright via their own locking. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: utmpx
* Renato Botelho rbga...@gmail.com, 20101105 13:49: I've made a patch for chkrootkit [1], it's building, but i didn't test if it's working. Could you take a look at it? [1] http://people.freebsd.org/~garga/patches/chkrootkit-utmpx.diff Well, files cannot be accessed without the utmpx API. I looked at these tools and I don't think they have very little use with utmpx. Can't we just disable all utmp related tools? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpdkBkdF8yTY.pgp Description: PGP signature
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success ( 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. Hmm, I hadn't considered if callers would want to know the pending count of the cancelled task. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about this. In that case, would you be fine with dropping the blocking functionality from taskqueue_cancel() completely and requiring code that wants the blocking semantics to use a cancel followed by a drain? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
(no subject)
Hi everybody,
The following commands lead the 9.0-CURRENT kernel to crash:
[r...@freebsd /usr/home/int0dh]# ngctl
Available commands:
config get or set configuration of node at path
connectConnects hook peerhook of the node at relpath to hook
debug Get/set debugging verbosity level
dotProduce a GraphViz (.dot) of the entire netgraph.
help Show command summary or get more help on a specific command
list Show information about all nodes
mkpeer Create and connect a new node to the node at path
msgSend a netgraph control message to the node at path
name Assign name name to the node at path
read Read and execute commands from a file
rmhook Disconnect hook hook of the node at path
show Show information about the node at path
shutdown Shutdown the node at path
status Get human readable status information from the node at path
types Show information about all installed node types
write Send a data packet down the hook named by hook.
quit Exit program
+ mkpeer ksocket myhook inet/stream/tcp
+ msg .:myhook connect inet/127.0.0.1:22
After last command the kernel panics.
Any listening TCP port can be used instead of 22.
The panic occurs here (sys/kern/uipc_sockbuf.c):
int
sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa,
struct mbuf *m0, struct mbuf *control)
{
struct mbuf *m, *n, *nlast;
int space = asa-sa_len;
SOCKBUF_LOCK_ASSERT(sb);
if (m0 (m0-m_flags M_PKTHDR) == 0)
{
panic(sbappendaddr_locked);
}
I`ve tried with the custom kernel only, but I think that issue can be
reproduced with GENERIC too.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ngctl can crash the kernel
Hi everybody,
The following commands lead the 9.0-CURRENT kernel to crash:
[r...@freebsd /usr/home/int0dh]# ngctl
Available commands:
config get or set configuration of node at path
connect Connects hook peerhook of the node at relpath to hook
debug Get/set debugging verbosity level
dot Produce a GraphViz (.dot) of the entire netgraph.
help Show command summary or get more help on a specific command
list Show information about all nodes
mkpeer Create and connect a new node to the node at path
msg Send a netgraph control message to the node at path
name Assign name name to the node at path
read Read and execute commands from a file
rmhook Disconnect hook hook of the node at path
show Show information about the node at path
shutdown Shutdown the node at path
status Get human readable status information from the node at path
types Show information about all installed node types
write Send a data packet down the hook named by hook.
quit Exit program
+ mkpeer ksocket myhook inet/stream/tcp
+ msg .:myhook connect inet/127.0.0.1:22
After last command the kernel panics.
Any listening TCP port can be used instead of 22.
The panic occurs here (sys/kern/uipc_sockbuf.c):
int
sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa,
struct mbuf *m0, struct mbuf *control)
{
struct mbuf *m, *n, *nlast;
int space = asa-sa_len;
SOCKBUF_LOCK_ASSERT(sb);
if (m0 (m0-m_flags M_PKTHDR) == 0)
{
panic(sbappendaddr_locked ;
}
I`ve tried with the custom kernel only, but I think that issue can be
reproduced with GENERIC too.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Patch] libfetch - closing the cached FTP connection
On Fri, Nov 05, 2010 at 09:38:24AM +0100, Nick Hibma wrote: Mark, My 2 cents: Isn't it more appropriate to set FD_CLOEXEC on the fd? fcntl(fd, F_SETFD, FD_CLOEXEC); It doesn't sound like you ever want to have a cached connection be copied into the child. Mum and child calling daddy using the same phone line isn't going to make the conversation any easier for daddy. Cheers, Nick The problem is that libfetch's ftp functions use an interface set up by funopen(3), so functions like fetchGetURL return a FILE*. However, I can't use something like fileno(3) to get the descriptor to pass to fcntl, because libfetch's FILE * is actually a struct ftpio *, which is only in ftp.c, i.e. not in the headers. I think using fcntl is nicer than having a close the cached connection function, but I don't think I can get around this problem without changing something in libfetch. Thanks, -Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
man(1) no longer understands manpages like .so man3/printf.3
A few examples from ports tree
devel/automake111: automake-1.11(1)
devel/gettext: dcgettext(3), dcngettext(3), dgettext(3), dngettext(3)
devel/nasm: rdf2com(1), rdf2ihx(1), rdf2ith(1), rdf2srec(1)
textproc/gnugrep: egrep(1), fgrep(1)
www/neon29: ne_get_{request,session}_flag(3), ne_set_connect_timeout(3)
x11/libX11: BlackPixel(3), XArc(3), etc
x11/libXext: XShmAttach(3), XmbufDisplayBuffers(3), etc
[+ more x11 libs]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: stuck in cam with bad optical media
On Fri, Nov 5, 2010 at 6:48 AM, Andriy Gapon a...@icyb.net.ua wrote: [I am probably just having an unlucky day.] I tried to burn (with growisofs) a DVD+RW disk which seems to have developed some problems. First, the burning process got stuck at the same percentage and the drive started to make unusual sounds. Then, the following messages appeared in system log: kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc:2,0 (No seek complete) kernel: ahcich5: Timeout on slot 7 kernel: ahcich5: is cs 0180 ss rs 0180 tfd 58 serr kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back After that growisofs either remained or became stuck in the following state: 42433 100119 growisofs initial thread mi_switch+0x1de sleepq_switch+0xdb sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0x68 passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallenter+0x3be syscall+0x41 Xfast_syscall+0xe2 Any commands that tried to access the device (cdcontrol eject, camcontrol reset 5:0:0) also got stuck. Only reboot helped to recover the device. I understand that bad media is bad, but it happens. I think that cam and ahci typically recover from errors/timeouts, so somehting must have gone wrong in this case. P.S. I have already thrown out the bad disk - irritation won over reason when that happened, unfortunately :( I think we are in the same boat (I've run into this problem on two different machines with my revisions of CURRENT) :(... I resorted to using an external DVD writer to write media (which is in and of itself a PITA): $ camcontrol devlist; uname -a ATAPI iHAS124 Y BL0V at scbus1 target 0 lun 0 (cd0,pass0) Hitachi HDS721010CLA332 JP4OA39C at scbus2 target 0 lun 0 (pass1,ada0) FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r214347M: Mon Oct 25 04:38:54 PDT 2010 root@:/usr/obj/usr/src/sys/BAYONETTA amd64 Have you tried non-rewritable CDs and DVDs yet (something that I need to try too)? HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: stuck in cam with bad optical media
on 05/11/2010 18:06 Garrett Cooper said the following: On Fri, Nov 5, 2010 at 6:48 AM, Andriy Gapon a...@icyb.net.ua wrote: [I am probably just having an unlucky day.] I tried to burn (with growisofs) a DVD+RW disk which seems to have developed some problems. First, the burning process got stuck at the same percentage and the drive started to make unusual sounds. Then, the following messages appeared in system log: kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: MEDIUM ERROR asc:2,0 (No seek complete) kernel: (cd0:ahcich5:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 kernel: (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error kernel: (cd0:ahcich5:0:0:0): SCSI status: Check Condition kernel: (cd0:ahcich5:0:0:0): SCSI sense: Deferred error: MEDIUM ERROR asc:2,0 (No seek complete) kernel: ahcich5: Timeout on slot 7 kernel: ahcich5: is cs 0180 ss rs 0180 tfd 58 serr kernel: (cd0:ahcich5:0:0:0): cddone: got error 0x5 back After that growisofs either remained or became stuck in the following state: 42433 100119 growisofsinitial thread mi_switch+0x1de sleepq_switch+0xdb sleepq_wait+0x45 _sleep+0x295 cam_periph_ccbwait+0x40 cam_periph_runccb+0x68 passioctl+0x260 devfs_ioctl_f+0xf8 kern_ioctl+0x262 ioctl+0x168 syscallenter+0x3be syscall+0x41 Xfast_syscall+0xe2 Any commands that tried to access the device (cdcontrol eject, camcontrol reset 5:0:0) also got stuck. Only reboot helped to recover the device. I understand that bad media is bad, but it happens. I think that cam and ahci typically recover from errors/timeouts, so somehting must have gone wrong in this case. P.S. I have already thrown out the bad disk - irritation won over reason when that happened, unfortunately :( I think we are in the same boat (I've run into this problem on two different machines with my revisions of CURRENT) :(... I resorted to using an external DVD writer to write media (which is in and of itself a PITA): $ camcontrol devlist; uname -a ATAPI iHAS124 Y BL0V at scbus1 target 0 lun 0 (cd0,pass0) Hitachi HDS721010CLA332 JP4OA39C at scbus2 target 0 lun 0 (pass1,ada0) FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r214347M: Mon Oct 25 04:38:54 PDT 2010 root@:/usr/obj/usr/src/sys/BAYONETTA amd64 Have you tried non-rewritable CDs and DVDs yet (something that I need to try too)? Not sure if you refer to exactly the same problem. I regularly successfully burn various media (re-writable and write-once). This time this was definitely a bad (degraded) disk. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote: On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success ( 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. Hmm, I hadn't considered if callers would want to know the pending count of the cancelled task. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about this. In that case, would you be fine with dropping the blocking functionality from taskqueue_cancel() completely and requiring code that wants the blocking semantics to use a cancel followed by a drain? New patch is at http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-a-task-from-a.patch I'll try to set up something to test it today too. Thanks, matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote:
I think that if a task is currently executing, then there should
be a drain method for that. I.E. two methods: One to stop and one
to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API if
you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert the
return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store the
old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not entirely
sure that's a good thing, since I am not generally fond of Linux's use
of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above hasn't
convinced you.
Hmm, I hadn't considered if callers would want to know the pending count
of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we just
have two functions that pass an internal boolean to the real routine
(callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs mirror
each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking functionality
from taskqueue_cancel() completely and requiring code that wants the
blocking semantics to use a cancel followed by a drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-
a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
check needs to be omitted. Else you block the possibility of enqueue and
cancel a task while it is actually executing/running ??
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote:
I think that if a task is currently executing, then there should
be a drain method for that. I.E. two methods: One to stop and one
to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API if
you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert the
return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store the
old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not entirely
sure that's a good thing, since I am not generally fond of Linux's use
of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above hasn't
convinced you.
Hmm, I hadn't considered if callers would want to know the pending count
of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we just
have two functions that pass an internal boolean to the real routine
(callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs mirror
each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking functionality
from taskqueue_cancel() completely and requiring code that wants the
blocking semantics to use a cancel followed by a drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-
a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
check needs to be omitted. Else you block the possibility of enqueue and
cancel a task while it is actually executing/running ??
Huh? If the task is currently running, there's nothing to do except
return failure. Task running means it can't be canceled, because...
it's running.
Thanks,
matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Patch] libfetch - closing the cached FTP connection
I think using fcntl is nicer than having a close the cached connection function, but I don't think I can get around this problem without changing something in libfetch. I think libfetch should set the Close-On-Exec flag. It's wrong to have these files propagate to children. Nick___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
Hi,
In the patch attached to this e-mail I included Matthew Fleming's patch
aswell.
1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles
the words of the callout and USB API's terminology for doing the same.
2) I turns out I need to have code in subr_taskqueue.c to be able to make the
operations atomic.
3) I did not update the manpage in this patch. Will do that before a commit.
4) My patch implements separate state keeping in struct task_pair, which
avoids having to change any KPI's for now, like suggested by John Baldwin I
think.
5) In my implementation I hard-coded the priority argument to zero, so that
enqueuing is fast.
Comments are welcome!
--HPS
=== kern/subr_taskqueue.c
==
--- kern/subr_taskqueue.c (revision 214796)
+++ kern/subr_taskqueue.c (local)
@@ -275,6 +275,25 @@
return (0);
}
+int
+taskqueue_stop(struct taskqueue *queue, struct task *task)
+{
+ int retval = 0;
+
+ TQ_LOCK(queue);
+
+ if (task-ta_pending != 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (task_is_running(queue, task))
+ retval = EBUSY;
+
+ TQ_UNLOCK(queue);
+
+ return (retval);
+}
+
void
taskqueue_drain(struct taskqueue *queue, struct task *task)
{
@@ -288,6 +307,113 @@
TQ_UNLOCK(queue);
}
+
+int
+taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp)
+{
+ struct task *task;
+ int retval;
+ int j;
+
+ TQ_LOCK(queue);
+
+ j = 0;
+ if (tp-tp_task[0].ta_pending 0)
+ j |= 1;
+ if (tp-tp_task[1].ta_pending 0)
+ j |= 2;
+
+ if (j == 0) {
+ /* No entries are queued. Just pick a last task. */
+ tp-tp_last = 0;
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[0];
+ } else if (j == 1) {
+ /* There is only one task pending and the other becomes last. */
+ tp-tp_last = 1;
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[1];
+ } else if (j == 2) {
+ /* There is only one task pending and the other becomes last. */
+ tp-tp_last = 0;
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[0];
+ } else {
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[tp-tp_last];
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ }
+
+ STAILQ_INSERT_TAIL(queue-tq_queue, task, ta_link);
+
+ retval = tp-tp_last + 1;
+ /* store the actual order in the pending count */
+ task-ta_pending = retval;
+
+ if ((queue-tq_flags TQ_FLAGS_BLOCKED) == 0)
+ queue-tq_enqueue(queue-tq_context);
+ else
+ queue-tq_flags |= TQ_FLAGS_PENDING;
+
+ TQ_UNLOCK(queue);
+
+ return (retval);
+}
+
+int
+taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp)
+{
+ struct task *task;
+ int retval = 0;
+
+ TQ_LOCK(queue);
+
+ task = tp-tp_task[0];
+ if (task-ta_pending != 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (task_is_running(queue, task))
+ retval = EBUSY;
+
+ task = tp-tp_task[1];
+ if (task-ta_pending != 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (task_is_running(queue, task))
+ retval = EBUSY;
+
+ TQ_UNLOCK(queue);
+
+ return (retval);
+}
+
+void
+taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp)
+{
+ struct task *task;
+
+ if (!queue-tq_spin)
+ WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__);
+
+ TQ_LOCK(queue);
+top:
+ task = tp-tp_task[0];
+ if (task-ta_pending != 0 || task_is_running(queue, task)) {
+ TQ_SLEEP(queue, task, queue-tq_mutex, PWAIT, -, 0);
+ goto top;
+ }
+
+ task = tp-tp_task[1];
+ if (task-ta_pending != 0 || task_is_running(queue, task)) {
+ TQ_SLEEP(queue, task, queue-tq_mutex, PWAIT, -, 0);
+ goto top;
+ }
+
+ TQ_UNLOCK(queue);
+}
+
static void
taskqueue_swi_enqueue(void *context)
{
=== sys/_task.h
==
--- sys/_task.h (revision 214796)
+++ sys/_task.h (local)
@@ -51,4 +51,9 @@
void *ta_context; /* (c) argument for handler */
};
+struct task_pair {
+ struct task tp_task[2];
+ int tp_last; /* (q) index of last queued task */
+};
+
#endif /* !_SYS__TASK_H_ */
=== sys/taskqueue.h
==
--- sys/taskqueue.h (revision 214796)
+++ sys/taskqueue.h (local)
@@ -53,7 +53,11 @@
void *context);
int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri,
const char *name, ...) __printflike(4, 5);
+int taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp);
+int taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp);
+void taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp);
int taskqueue_enqueue(struct taskqueue *queue, struct task *task);
+int taskqueue_stop(struct taskqueue *queue, struct task *task);
void taskqueue_drain(struct taskqueue *queue, struct task *task);
void taskqueue_free(struct taskqueue *queue);
void taskqueue_run(struct taskqueue *queue);
@@ -78,6 +82,15 @@
} while (0)
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 19:13:08 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky hsela...@c2i.net
wrote:
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org
wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky
wrote:
I think that if a task is currently executing, then there
should be a drain method for that. I.E. two methods: One to
stop and one to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API
if you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert
the return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store
the old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not
entirely sure that's a good thing, since I am not generally fond of
Linux's use of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above
hasn't convinced you.
Hmm, I hadn't considered if callers would want to know the pending
count of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we
just have two functions that pass an internal boolean to the real
routine (callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs
mirror each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking
functionality from taskqueue_cancel() completely and requiring code
that wants the blocking semantics to use a cancel followed by a
drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc
el- a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
If it is running, it is dequeued from the the taskqueue, right? And while it
is running it can be queued again, which your initial code didn't handle?
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 11:35 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Friday 05 November 2010 19:13:08 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky hsela...@c2i.net
wrote:
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org
wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky
wrote:
I think that if a task is currently executing, then there
should be a drain method for that. I.E. two methods: One to
stop and one to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API
if you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert
the return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store
the old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not
entirely sure that's a good thing, since I am not generally fond of
Linux's use of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above
hasn't convinced you.
Hmm, I hadn't considered if callers would want to know the pending
count of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we
just have two functions that pass an internal boolean to the real
routine (callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs
mirror each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking
functionality from taskqueue_cancel() completely and requiring code
that wants the blocking semantics to use a cancel followed by a
drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc
el- a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
If it is running, it is dequeued from the the taskqueue, right? And while it
is running it can be queued again, which your initial code didn't handle?
True, but no taskqueue(9) code can handle that. Only the caller can
prevent a task from becoming enqueued again. The same issue exists
with taskqueue_drain().
BTW, I planned to commit the patch I sent today after testing,
assuming jhb@ has no more issues.
Thanks,
matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Thanks, matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Sense fetching [Was: cdrtools /devel ...]
Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't because it only checks pending if !running() :-) ?? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Patch] libfetch - closing the cached FTP connection
On Fri, Nov 05, 2010 at 07:27:43PM +0100, Nick Hibma wrote: I think using fcntl is nicer than having a close the cached connection function, but I don't think I can get around this problem without changing something in libfetch. I think libfetch should set the Close-On-Exec flag. It's wrong to have these files propagate to children. Nick___ Oh I see, I thought you were talking about changing pkg_add alone. I'll post an alternative patch to the PR I opened (bin/151866). Thanks, -Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't because it only checks pending if !running() :-) ?? You can't close that race in taskqueue_cancel(). You have to manage that race yourself in your task handler. For the callout(9) API we are only able to close that race if you use callout_init_mtx() so that the code managing the callout wheel can make use of your lock to resolve the races. If you use callout_init() you have to explicitly manage these races in your callout handler. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote: Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Please don't commit this to the port directly but let it loop back via upstream (CC'ed) instead, otherwise we would need to obey the following, which is undesirable, especially if these really are mostly cosmetic issues: /* * Warning: you may change this source, but if you do that * you need to change the _scg_version and _scg_auth* string below. * You may not return schily for an SCG_AUTHOR request anymore. * Choose your name instead of schily and make clear that the version * string is related to a modified source. */ Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Files under src/ not used for building world
Hey folks, not sure why, but I had a stab at looking which files were
actually read during building world.
Method went something like this:
(turn on atime)
# find . -exec touch {} +
# sleep 2; touch timestamp
# make buildworld buildkernel installworld installkernel (this is on amd64)
# make universe
# make distribution DESTDIR=/foo
# mergemaster (I think this is redundant)
# find . -name .svn -prune -or -not -anewer timestamp
Please note that I skipped 'make release' as I don't know all the
parameters off-hand.
The list of files (tools/ removed) can be seen at
https://www.spoerlein.net/pub/untouched_files
Here are some curiosities (cddl/, gnu/, contrib/, and crypto/ skipped):
bin/sh/bltin/echo.1
etc/periodic/security/610.ipf6denied
include/hesiod.h
include/rpcsvc/pmap_prot.x
lib/libarchive/archive_crc32.h
lib/libarchive/libarchive_internals.3
lib/libautofs/Makefile
lib/libautofs/libautofs.3
lib/libautofs/libautofs.c
lib/libautofs/libautofs.h
lib/libc/sys/kse.2
lib/libc/xdr/xdr_sizeof.c
lib/libc_r/* # we can remove that from head, right?
lib/libkse/* # dito
lib/libmd/mddriver.c
lib/libmd/rmddriver.c
lib/libmd/shadriver.c
lib/msun/src/s_fabs.c
lib/msun/src/s_modf.c
sbin/bsdlabel/bsdlabel.5 # eh?
sbin/mount/getmntopts.3
sbin/mount_autofs/Makefile
sbin/mount_autofs/mount_autofs.8
sbin/mount_autofs/mount_autofs.c
sbin/mount_ext2fs/Makefile
sbin/mount_ext2fs/mount_ext2fs.8
sbin/mount_ext2fs/mount_ext2fs.c
sbin/mount_hpfs/Makefile
sbin/mount_hpfs/mount_hpfs.8
sbin/mount_hpfs/mount_hpfs.c
sbin/mount_reiserfs/Makefile
sbin/mount_reiserfs/mount_reiserfs.8
sbin/mount_reiserfs/mount_reiserfs.c
sbin/mount_std/Makefile
sbin/mount_std/mount_std.8
sbin/mount_std/mount_std.c
usr.bin/cpio/test/* # move to tools/regression?
usr.bin/csup/fattr_posix.h
usr.bin/ftp/config.h
usr.bin/hesinfo/Makefile
usr.bin/hesinfo/hesinfo.1
usr.bin/hesinfo/hesinfo.c
usr.bin/objformat/Makefile
usr.bin/objformat/objformat.sh # delete?
usr.bin/setchannel/Makefile
usr.bin/setchannel/setchannel.1
usr.bin/setchannel/setchannel.c
usr.sbin/cxgbtool/*
usr.sbin/gpioctl# wtf? my system has MK_GPIO=no set?
usr.sbin/kernbb
usr.sbin/route6d/misc/chkrt
usr.sbin/route6d/misc/cksum.c
usr.sbin/usbdevs/* # delete? does it work with new stack?
I haven't looked too closely (ie., not at all) at these cases. Please
discuss and happy browsing the list!
The Janitor
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Files under src/ not used for building world
On Fri, Nov 05, 2010 at 09:25:36PM +0100, Ulrich Sp??rlein wrote: lib/msun/src/s_fabs.c lib/msun/src/s_modf.c These are explicitly ignored by msun/Makefile. # FreeBSD's C library supplies these functions: #COMMON_SRCS+= s_fabs.c s_frexp.c s_isnan.c s_ldexp.c s_modf.c -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: processes stuck on a vnode lock
on 04/11/2010 16:45 Andriy Gapon said the following: on 04/11/2010 09:49 Andriy Gapon said the following: I see a few processes stuck on the same vnode, trying to take or to upgrade to an exclusive lock on it, while the lock data suggests that it is already shared-locked. The vnode is a root vnode of one of ZFS filesystems (it's not a global root). I couldn't find any (other) threads that could actually hold the vnode lock, but lock shared count is suspiciously or coincidentally the same as number of threads in zfs_root call. BTW, I still have the system alive and online, so if anyone has ideas I can try them. The kernel is not live now, but I have saved it and vmcore of the system. Kostik, just a pure guesswork here - could r214049 have something to do with this? I looked at the change and it looks completely correct - I don't think that a vnode lock can be leaked by that code. But, OTOH, it has some special handling for VV_ROOT, it's in NFS code and and it's in a right time-frame, so just asking. You could try the attached patch which seems to have worked for Josh Carroll, who had a similar problem with stable/8. rick --- nfs_serv.c.sav 2010-11-05 08:15:57.0 -0400 +++ nfs_serv.c 2010-11-05 08:18:40.0 -0400 @@ -3252,7 +3252,7 @@ nfhp-fh_fsid = nvp-v_mount-mnt_stat.f_fsid; if ((error1 = VOP_VPTOFH(nvp, nfhp-fh_fid)) == 0) error1 = VOP_GETATTR(nvp, vap, cred); - if (vp == nvp) + if (usevget == 0 vp == nvp) vunref(nvp); else vput(nvp); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Files under src/ not used for building world
On Friday, November 05, 2010 4:25:36 pm Ulrich Spörlein wrote:
Hey folks, not sure why, but I had a stab at looking which files were
actually read during building world.
Method went something like this:
(turn on atime)
# find . -exec touch {} +
# sleep 2; touch timestamp
# make buildworld buildkernel installworld installkernel (this is on amd64)
# make universe
# make distribution DESTDIR=/foo
# mergemaster (I think this is redundant)
# find . -name .svn -prune -or -not -anewer timestamp
Please note that I skipped 'make release' as I don't know all the
parameters off-hand.
The list of files (tools/ removed) can be seen at
https://www.spoerlein.net/pub/untouched_files
Here are some curiosities (cddl/, gnu/, contrib/, and crypto/ skipped):
etc/periodic/security/610.ipf6denied
I wonder if this is stale due to ip6fw being removed?
usr.bin/objformat/Makefile
usr.bin/objformat/objformat.sh # delete?
This can definitely go.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: issue with options DDB
On Sat, 30.10.2010 at 23:22:44 +, Alexander Best wrote: hi there, with options DDB in my kernel conf i run into the following issue with my kernel modules: link_elf_lookup_symbol: missing symbol hash table KLD file snd_hda.ko is missing dependencies KLD file sound.ko is missing dependencies KLD file nvidia.ko is missing dependencies KLD file linux.ko is missing dependencies KLD file ng_ubt.ko is missing dependencies KLD file ng_hci.ko is missing dependencies KLD file ng_bluetooth.ko is missing dependencies KLD file netgraph.ko is missing dependencies link_elf_lookup_symbol: missing symbol hash table removing the option solves the issue. any advice? cheers. alex ps: i'm running HEAD (r214542; amd64). You failed to mention the command that you run. I assume 'buildkernel'? Please note that you need and update-to-date buildworld for the kernel tools to be there, so please try the following (with options DDB): cd /usr/src make clean; make cleandir; make clean make buildworld make buildkernel KERNCONF=YOURKERNEL If it fails again, try env __MAKE_CONF=/dev/null make buildkernel KERNCONF=YOURKERNEL Oh, and the actual kernel config might help as well. hth Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] top(1) inverse display of table header
On 10/25/2010 20:42, Xin LI wrote: Hi, Here is a patch that makes top(1) to inverse its table header (PID USERNAME THR, etc). Cheers, Pretty neato fix for a long-standing annoyance. -- jhell,v ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: re(4) driver dropping packets when reading NFS files
On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote: If the counter was not wrapped, it seem you lost more than 10% out of total RX frames. This is a lot loss and there should be a way to mitigate it. I've attached a patch (to the if_re.c in head, not your patched variant) that works a lot better (about 5Mbytes/sec read rate). To get that, I had to disable msi and not clear the RL_IMR register in re_intr(). I suspect that a packet would be received between when the bits in RL_IMR were cleared and when they were set at the end of re_int_task() and those were getting lost. This patch doesn't completely fix the problem. (I added your stats collecting stuff to the if_re.c in head and attached the result, which still shows some lost packets. One thought is clearing the bits in RL_ISR in re_intr() instead of re_int_task(), but then I can't see a good way to pass the old value of the status reg. through to re_int_task()? Hmm, I still don't understand how the patch mitigates the issue. :-( The patch does not disable interrupts in interrupt handler so taskqueue runs with interrupt enabled. This may ensure not loosing interrupts but it may also generate many interrupts. By chance, did you check number of interrupts generated with/without your patch? I agree. I think all it did was create more interrupts so that re_rxeof() got called more frequently. (see below) The only guess I have at the moment is the writing RL_IMR in interrupt handler at the end of taskqueue might be not immediately reflected so controller can loose interrupts for the time window. Would you try attach patch and let me know it makes any difference? Nope, it didn't make any difference. I've added a counter of how many times re_rxeof() gets called, but then returns without handling any received packets (I think because RL_RDESC_STAT_OWN is set on the first entry it looks at in the rcv. ring.) This count comes out as almost the same as the # of missed frames (see rxe did 0: in the attached stats). So, I think what is happenning about 10% of the time is that re_rxeof() is looking at the ring descriptor before it has been updated and then returns without handling the packet and then it doesn't get called again because the RL_ISR bit has been cleared. When options DEVICE_POLLING is specified, it works ok, because it calls re_rxeof() fairly frequently and it doesn't pay any attention to the RL_ISR bits. Now, I don't know if this is a hardware flaw on this machine or something that can be fixed in software? I know diddly about the current driver setup, but I assume something like this has to happen? - chip (or PCIe handler) forces the DMA of the descriptor change to RAM - then posts the interrupt - and the driver must read the up to date descriptor from RAM -- I notice that volatile isn't used anywhere in the driver. Wouldn't the descriptor ring memory have to be defined volatile somehow? (I don't know how to do this correctly?) So, if you can think of anything that will ensure that re_rxeof() reads up to date descriptor ring entries, please let me know. Otherwise, I can live with options DEVICE_POLLING. Thanks for your help, rick re0 statistics: Transmit good frames : 101346 Receive good frames : 133390 Tx errors : 0 Rx errors : 0 Rx missed frames : 14394 Rx frame alignment errs : 0 Tx single collisions : 0 Tx multiple collisions : 0 Rx unicast frames : 133378 Rx broadcast frames : 0 Rx multicast frames : 12 Tx aborts : 0 Tx underruns : 0 rxe did 0: 14359 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ngctl can crash the kernel
Same panic here...
Also the MPD2 port is broken, I'm guessing a netgraph problem too.
2010/11/5 sdfsdf rwerwer freebsd-tracker-int...@mail.ru:
Hi everybody,
The following commands lead the 9.0-CURRENT kernel to crash:
[r...@freebsd /usr/home/int0dh]# ngctl
Available commands:
config get or set configuration of node at path
connect Connects hook peerhook of the node at relpath to hook
debug Get/set debugging verbosity level
dot Produce a GraphViz (.dot) of the entire netgraph.
help Show command summary or get more help on a specific command
list Show information about all nodes
mkpeer Create and connect a new node to the node at path
msg Send a netgraph control message to the node at path
name Assign name name to the node at path
read Read and execute commands from a file
rmhook Disconnect hook hook of the node at path
show Show information about the node at path
shutdown Shutdown the node at path
status Get human readable status information from the node at path
types Show information about all installed node types
write Send a data packet down the hook named by hook.
quit Exit program
+ mkpeer ksocket myhook inet/stream/tcp
+ msg .:myhook connect inet/127.0.0.1:22
After last command the kernel panics.
Any listening TCP port can be used instead of 22.
The panic occurs here (sys/kern/uipc_sockbuf.c):
int
sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa,
struct mbuf *m0, struct mbuf *control)
{
struct mbuf *m, *n, *nlast;
int space = asa-sa_len;
SOCKBUF_LOCK_ASSERT(sb);
if (m0 (m0-m_flags M_PKTHDR) == 0)
{
panic(sbappendaddr_locked ;
}
I`ve tried with the custom kernel only, but I think that issue can be
reproduced with GENERIC too.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: re(4) driver dropping packets when reading NFS files
On Fri, Nov 05, 2010 at 07:44:56PM -0400, Rick Macklem wrote: On Thu, Nov 04, 2010 at 09:31:30PM -0400, Rick Macklem wrote: If the counter was not wrapped, it seem you lost more than 10% out of total RX frames. This is a lot loss and there should be a way to mitigate it. I've attached a patch (to the if_re.c in head, not your patched variant) that works a lot better (about 5Mbytes/sec read rate). To get that, I had to disable msi and not clear the RL_IMR register in re_intr(). I suspect that a packet would be received between when the bits in RL_IMR were cleared and when they were set at the end of re_int_task() and those were getting lost. This patch doesn't completely fix the problem. (I added your stats collecting stuff to the if_re.c in head and attached the result, which still shows some lost packets. One thought is clearing the bits in RL_ISR in re_intr() instead of re_int_task(), but then I can't see a good way to pass the old value of the status reg. through to re_int_task()? Hmm, I still don't understand how the patch mitigates the issue. :-( The patch does not disable interrupts in interrupt handler so taskqueue runs with interrupt enabled. This may ensure not loosing interrupts but it may also generate many interrupts. By chance, did you check number of interrupts generated with/without your patch? I agree. I think all it did was create more interrupts so that re_rxeof() got called more frequently. (see below) The only guess I have at the moment is the writing RL_IMR in interrupt handler at the end of taskqueue might be not immediately reflected so controller can loose interrupts for the time window. Would you try attach patch and let me know it makes any difference? Nope, it didn't make any difference. I've added a counter of how many times re_rxeof() gets called, but then returns without handling any received packets (I think because RL_RDESC_STAT_OWN is set on the first entry it looks at in the rcv. ring.) This count comes out as almost the same as the # of missed frames (see rxe did 0: in the attached stats). So, I think what is happenning about 10% of the time is that re_rxeof() is looking at the ring descriptor before it has been updated and then returns without handling the packet and then it doesn't get called again because the RL_ISR bit has been cleared. When options DEVICE_POLLING is specified, it works ok, because it calls re_rxeof() fairly frequently and it doesn't pay any attention to the RL_ISR bits. That's one of possible theory. See below for another theory. Now, I don't know if this is a hardware flaw on this machine or something that can be fixed in software? I know diddly about the current driver I highly doubt it could be hardware issue. setup, but I assume something like this has to happen? - chip (or PCIe handler) forces the DMA of the descriptor change to RAM - then posts the interrupt - and the driver must read the up to date descriptor from RAM -- I notice that volatile isn't used anywhere in the driver. Wouldn't the descriptor ring memory have to be defined volatile somehow? (I don't know how to do this correctly?) Because driver check different descriptor location in each loop, adding volatile keyword wouldn't help. You can verify that whether that makes any difference though. Another possibility I have in mind is the controller would have reported RL_ISR_RX_OVERRUN but re(4) didn't check that condition. The old data sheet I have does not clearly mention when it is set and what other bits of RL_ISR register is affected from the bit. If RL_ISR_RX_OVERRUN bit is set when there are no more free RX descriptors available to controller and RL_ISR_RX_ERR is not set when RL_ISR_RX_OVERRUN is set, re(4) have ignored that event. Because driver ignored that error interrupt, the next error interrupt would be RL_ISR_FIFO_OFLOW error and this time it would be served in re_rxeof() and will refill RX buffers. However driver would have lost lots of frames received between the time window RL_ISR_RX_OVERRUN error and RL_ISR_FIFO_OFLOW error. If this theory is correct, the attached patch may mitigate the issue. So, if you can think of anything that will ensure that re_rxeof() reads up to date descriptor ring entries, please let me know. It's job of bus_dma(9) and I don't think barrier instructions would be helpful here as I don't see out-of-order execution in RX handler. Otherwise, I can live with options DEVICE_POLLING. Sorry, I can't live with DEVICE_POLLING on re(4). :-( Let's kill driver bug. No one reported this kind of issue so far and I guess most users took it granted for the poor performance because they are using low end consumer grade controller. Thanks for your help, rick re0 statistics: Transmit good frames : 101346 Receive good frames : 133390 Tx errors : 0 Rx errors : 0 Rx missed frames
Re: re(4) driver dropping packets when reading NFS files
On Fri, Nov 05, 2010 at 07:33:45PM -0700, Pyun YongHyeon wrote:
[...]
If this theory is correct, the attached patch may mitigate the
issue.
Oops, I incorrectly used old code.
Please use this one.
Index: sys/pci/if_rlreg.h
===
--- sys/pci/if_rlreg.h (revision 214844)
+++ sys/pci/if_rlreg.h (working copy)
@@ -873,9 +873,7 @@
int rl_twist_row;
int rl_twist_col;
int suspended; /* 0 = normal 1 = suspended */
-#ifdef DEVICE_POLLING
int rxcycles;
-#endif
struct task rl_txtask;
struct task rl_inttask;
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 214844)
+++ sys/dev/re/if_re.c (working copy)
@@ -1860,7 +1860,7 @@
int i, total_len;
struct rl_desc *cur_rx;
u_int32_t rxstat, rxvlan;
- int maxpkt = 16, rx_npkts = 0;
+ int rx_npkts = 0;
RL_LOCK_ASSERT(sc);
@@ -1872,7 +1872,7 @@
sc-rl_ldata.rl_rx_list_map,
BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE);
- for (i = sc-rl_ldata.rl_rx_prodidx; maxpkt 0;
+ for (i = sc-rl_ldata.rl_rx_prodidx; sc-rxcycles 0;
i = RL_RX_DESC_NXT(sc, i)) {
if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0)
break;
@@ -2036,7 +2036,7 @@
}
}
}
- maxpkt--;
+ sc-rxcycles--;
if (rxvlan RL_RDESC_VLANCTL_TAG) {
m-m_pkthdr.ether_vtag =
bswap16((rxvlan RL_RDESC_VLANCTL_DATA));
@@ -2058,10 +2058,10 @@
if (rx_npktsp != NULL)
*rx_npktsp = rx_npkts;
- if (maxpkt)
- return (EAGAIN);
+ if (sc-rxcycles)
+ return (0);
- return (0);
+ return (EAGAIN);
}
static void
@@ -2258,8 +2258,11 @@
}
#endif
- if (status (RL_ISR_RX_OK|RL_ISR_RX_ERR|RL_ISR_FIFO_OFLOW))
+ if (status (RL_ISR_RX_OK | RL_ISR_RX_ERR | RL_ISR_FIFO_OFLOW |
+ RL_ISR_RX_OVERRUN)) {
+ sc-rxcycles = sc-rl_ldata.rl_rx_desc_cnt / 2;
rval = re_rxeof(sc, NULL);
+ }
/*
* Some chips will ignore a second TX request issued
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Files under src/ not used for building world
On Fri, Nov 5, 2010 at 1:25 PM, Ulrich Spörlein u...@spoerlein.net wrote:
Hey folks, not sure why, but I had a stab at looking which files were
actually read during building world.
Method went something like this:
(turn on atime)
# find . -exec touch {} +
# sleep 2; touch timestamp
# make buildworld buildkernel installworld installkernel (this is on amd64)
# make universe
# make distribution DESTDIR=/foo
# mergemaster (I think this is redundant)
# find . -name .svn -prune -or -not -anewer timestamp
Please note that I skipped 'make release' as I don't know all the
parameters off-hand.
The list of files (tools/ removed) can be seen at
https://www.spoerlein.net/pub/untouched_files
Here are some curiosities (cddl/, gnu/, contrib/, and crypto/ skipped):
bin/sh/bltin/echo.1
I'd talk to jilles@ (weird thing is that this is installed on my machine).
...
lib/libarchive/archive_crc32.h
lib/libarchive/libarchive_internals.3
I'd talk to kient...@.
lib/libautofs/Makefile
lib/libautofs/libautofs.3
lib/libautofs/libautofs.c
lib/libautofs/libautofs.h
Missing from lib/Makefile (hmmm...).
lib/libc/sys/kse.2
Shouldn't kse be yanked?
...
lib/libkse/* # dito
Same as above.
...
sbin/bsdlabel/bsdlabel.5 # eh?
Not sure why but this was commented out (see the Makefile).
sbin/mount/getmntopts.3
It would be nice if this was installed too.
sbin/mount_autofs/Makefile
sbin/mount_autofs/mount_autofs.8
sbin/mount_autofs/mount_autofs.c
sbin/mount_ext2fs/Makefile
sbin/mount_ext2fs/mount_ext2fs.8
sbin/mount_ext2fs/mount_ext2fs.c
sbin/mount_hpfs/Makefile
sbin/mount_hpfs/mount_hpfs.8
sbin/mount_hpfs/mount_hpfs.c
sbin/mount_reiserfs/Makefile
sbin/mount_reiserfs/mount_reiserfs.8
sbin/mount_reiserfs/mount_reiserfs.c
sbin/mount_std/Makefile
sbin/mount_std/mount_std.8
sbin/mount_std/mount_std.c
Not sure about the above items.
usr.bin/cpio/test/* # move to tools/regression?
Seems like a legitimate request.
...
usr.bin/setchannel/Makefile
usr.bin/setchannel/setchannel.1
usr.bin/setchannel/setchannel.c
Not included in usr.bin/Makefile .
...
usr.sbin/gpioctl # wtf? my system has MK_GPIO=no set?
Unless you say WITH_GPIO, it defaults to WITHOUT_GPIO (according to
what I'm reading from bsd.own.mk).
...
I haven't looked too closely (ie., not at all) at these cases. Please
discuss and happy browsing the list!
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Files under src/ not used for building world
Hi,
On Fri, 5 Nov 2010 17:16:47 -0400
John Baldwin j...@freebsd.org said:
etc/periodic/security/610.ipf6denied
jhb I wonder if this is stale due to ip6fw being removed?
No, it seems to me that it is not related to ip6fw, and it calls
ipfstat. Perhaps, some work for IPv6 support of IP Filter?
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
