Date: Sun, 13 Mar 2005 21:20:05 GMT From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-usb@FreeBSD.org Subject: Re: usb/78208: ulpt page fault Message-ID: <200503132120.j2DLK5j0066478@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR usb/78208; it has been noted by GNATS. From: Ian Dowse <iedowse@maths.tcd.ie> To: Jan-Espen Pettersen <sigsegv@leakingmemory.org> Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: usb/78208: ulpt page fault Date: Sun, 13 Mar 2005 21:14:58 +0000 In message <200502281829.j1SIT6sb003645@endeavour.localnet.radiotube.org>, Jan- Espen Pettersen writes: >>Description: >I got this page fault trap just after printing via ulpt. The pages came out ju >st fine, which is why I think this problem is about handling EOF or close of t >ransaction with /dev/ulpt0. To me this looks like a timer (as the name *_tick) > which probably was not stopped in time, and therefore didn't have a valid xfe >r pointer to pass to the setup routine. These crashes has been going on for a >while, but I haven't been able to get crashdumps before recently when I starte >d to press Ctrl+Alt+F1 shortly after starting the print jobs. This looks like it could be caused by a known race condition in kernel timers. Is the problem easy to reproduce for you? If so, could you try the patch at http://people.freebsd.org/~iedowse/releng_5_callout.diff and see if it helps? Remove your patch to ulpt.c first. The above patch is a partial backport of some changes that went in to -CURRENT that fix some race conditions with Giant-locked kernel timers. Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503132120.j2DLK5j0066478>