Re: [cups.bugs] tcgetattr() causes lockup in USB backend on FreeBSD6-STABLE

sts). This causes the usb backend hang. So indeed, setting use_bc = 0 solves the problem. I'm not sure why select() / read() interact like this. Peter Michael Sweet wrote: > Peter van Heusden wrote: > >> I recently upgrade CUPS on my FreeBSD 6-STABLE server to version 1.2

cups + usb + FreeBSD 6-STABLE + tcgetattr() lockup

Hi. I've got a HP LaserJet 1010 attached to my FreeBSD 6.2 machine via usb, on /dev/ulpt0. I recently upgraded CUPS, and after fixing the permissions issues on /dev/ulpt0, I found that when I printed the usb backend would just "hang", which turned out to be a block on tcgetattr() on the ulpt0. The

Re: Unexplained kernel panic on 5-STABLE (now in 6-STABLE)

Thanks, Kris. I guess its time for me to go shopping for some new hardware. Peter Kris Kennaway wrote: > On Thu, Aug 17, 2006 at 01:24:48PM -0400, John Baldwin wrote: > >> On Thursday 17 August 2006 04:20, Peter van Heusden wrote: >> >>> Thanks for the advice J

Re: Unexplained kernel panic on 5-STABLE (now in 6-STABLE)

ebsd6/src/sys/i386/i386/exception.s:208 Thanks for all the help, Peter John Baldwin wrote: > On Monday 14 August 2006 14:16, Peter van Heusden wrote: > >> Thanks. That gives the following output: >> >> #9 0xc0801295 in trap_pfault (frame=0xd1231b68, usermode=0x0, eva=

Re: Unexplained kernel panic on 5-STABLE

ut to use for all sorts of network services) is under quite heavy load. Peter John Baldwin wrote: > On Sunday 13 August 2006 03:36, Peter van Heusden wrote: > >> Hi everyone >> >> Almost every day, some time around midnight, my FreeBSD 5-STABLE kernel >> panics. I&#

Unexplained kernel panic on 5-STABLE

Hi everyone Almost every day, some time around midnight, my FreeBSD 5-STABLE kernel panics. I've attached the output of a kgdb session of the saved core file - is there any further info that would be useful to debugging? I've got no idea where to start looking for a solution to this problem, so pl

Unexplained kernel panic on 5-STABLE

Hi everyone Almost every day, some time around midnight, my FreeBSD 5-STABLE kernel panics. I've attached the output of a kgdb session of the saved core file - is there any further info that would be useful to debugging? I've got no idea where to start looking for a solution to this problem, so pl

Unexplained kernel panic on 5-STABLE

Hi everyone Almost every day, some time around midnight, my FreeBSD 5-STABLE kernel panics. I've attached the output of a kgdb session of the saved core file - is there any further info that would be useful to debugging? I've got no idea where to start looking for a solution to this problem, so pl

ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - on FreeBSD 6-STABLE

Hi After my previous email about the SETFEATURES SET TRANSFER MODE timeout on (msgid [EMAIL PROTECTED] , 17 March 14:18 GMT + 2 on freebsd-stable), I installed FreeBSD 6.1 BETA 4 and upgraded to a 6-STABLE kernel, running the box in 'safe' mode to do so. I now, however, get a slightly differe

buildkernel failure on latest -stable source

I recently re-installed a local machine with FreeBSD 6.1 BETA 4, in order to get around the SETFEATURES SET TRANSFER MODE problem I emailed the list about earlier. I'm still having problems (slightly different errors) when running with normal settings, so I've been running this box in 'safe' mode.

Re: SETFEATURES SET TRANSFER MODE semaphore timeout on FreeBSD 6.0 RELEASE

Ok, but the machine is not stable enough to run cvsup / buildworld on. I guess I need to do a binary install of one of the FreeBSD 6.1 betas. Thanks for the advice. Peter Ruslan Ermilov wrote: > On Fri, Mar 17, 2006 at 02:13:59PM +0200, Peter van Heusden wrote: > >> Hi >>

SETFEATURES SET TRANSFER MODE semaphore timeout on FreeBSD 6.0 RELEASE

Hi I have a newly installed FreeBSD 6.0 release machine on which I am getting the following error on the console: "ad4: req=0xc23bc258 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !!" This is generally associated with heightened disk activity, but it happens inevitab