Dag-Erling Smørgrav wrote:
Sven Hazejager <[EMAIL PROTECTED]> writes:
No, camcontrol does not support this over USB. Windows XP demonstrates
it is technically possible, and I do not believe it is fully safe to
disconnect the drive (even when unmounted), as the drive then is not
able to park its
On Wed, Aug 15, 2007 at 02:27:56PM +0800, Nex Mon wrote:
> Hello All,
>
> Can someone point me out or explain the technical details of this kernel
> panic:
>
> sleeping thread (tid 100093, pid 2676) owns nonsleepable lock
> panic: sleeping thread
it just says that some thread owns a nonsleepable
thanks for your reply.
i didn't use WITNESS. it is disabled.
is their a list a list of which locks are sleepable and non-sleepable
in FreeBSD6.2? is sleeping triggered by a call to "sleep", IO operation
or a result of context switching by kernel?
thanks
On 8/15/07, Roman Divacky <[EMAIL PROTECT
Simon 'corecode' Schubert <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> > All modern disks (since at least the early 1990s) automatically park
> > their heads when they lose power. There is no need to do it in
> > software.
> So it seems that windows is switching
Has anyone noted that the Australian cvs repository seems to be so
hopelessly out of sink that you cannot do a clean build using a clean cvsup.
I have just tried to cvsup from cvsup.au.FreeBSD.org after deleting all
of the src tree and also any cvs log/check files so that it was
basically a cl
On Wed, Aug 15, 2007 at 05:10:48PM +0800, Nex Mon wrote:
> thanks for your reply.
>
> i didn't use WITNESS. it is disabled.
>
> is their a list a list of which locks are sleepable and non-sleepable
> in FreeBSD6.2? is sleeping triggered by a call to "sleep", IO operation
> or a result of context
On Saturday 11 August 2007 12:11:21 pm Mario Lobo wrote:
> after a long,long search, I found that chip id 0x53371106 belongs to SATA150
> controller, not PATA !! Then I enabled all mass storage controllers on the
> board ( although no SATA drives present ), then two more ids showed up:
>
> chip=
On Tuesday 14 August 2007 19:33, John Baldwin wrote:
> On Saturday 11 August 2007 12:11:21 pm Mario Lobo wrote:
> > after a long,long search, I found that chip id 0x53371106 belongs to
> > SATA150 controller, not PATA !! Then I enabled all mass storage
> > controllers on the board ( although no SAT
On Wednesday 15 August 2007 02:27:56 am Nex Mon wrote:
> Hello All,
>
> Can someone point me out or explain the technical details of this kernel
> panic:
>
> sleeping thread (tid 100093, pid 2676) owns nonsleepable lock
> panic: sleeping thread
> --
> --
>
>
> Is this caused by incorrect use of
On Wednesday 15 August 2007 16:07, Mario Lobo wrote:
> Besides, the VIA8237A SATA150 controllers ids itself as 0x5337, which is
> not even in the data base at http://pci-ids.ucw.cz/iii/?i=1106
>
> So I added a new id to ata-pci.h:
> #define ATA_VIA8237AS 0x53371106
>
> and added this line to ata-c
Hi,
Robert McKenzie wrote:
> Has anyone noted that the Australian cvs repository seems to
> be so
> hopelessly out of sink that you cannot do a clean build using
> a clean cvsup.
Yes, I've noticed this too. I'm using mirror.pacific.net.au at the
moment, and it seems fine. Pacific Internet is ou
this is getting to be a serious problem in freebsd. i'm also encountering
the same panic problem. my box runs on freebsd 6.1 with ipfw, pf,
forwarding/routing enabled and several network-based applications. the panic
occurs when the system is subjected to a very high traffic load and some
applicat
What is the easiest way to play with modifying data in-transit within an
ethernet bridge?
For instance, say I have something like this:
[BOX 1] <> [ BOX 2 ] <> [ BOX 3 ]
And BOX 2 is a FreeBSD box with bridging enabled between two ethernet
interfaces, how can I parse/modify the ethern
Max Laier wrote:
On Thursday 16 August 2007, you wrote:
rrs 2007-08-16 01:51:22 UTC
FreeBSD src repository
Modified files:
sys/netinet sctp_asconf.c sctp_input.c sctp_output.c
sctp_pcb.c sctp_timer.c sctp_usrreq.c
sctputil.
Ronnel P. Maglasang wrote:
this is getting to be a serious problem in freebsd. i'm also encountering
the same panic problem. my box runs on freebsd 6.1 with ipfw, pf,
forwarding/routing enabled and several network-based applications. the
panic
occurs when the system is subjected to a very high
15 matches
Mail list logo
