Date: Tue, 5 Jan 2016 09:39:15 +0800 (PHT)
From: Paul Goyette
On Tue, 5 Jan 2016, Taylor R Campbell wrote:
> So I think DIAGNOSTIC condition is wrong. I think the right condition
> is probably uio->uio_vmspace == vmspace_kernel().
Yes, this make a lot of sense. I will fix it
On Tue, 5 Jan 2016, Taylor R Campbell wrote:
Date: Tue, 5 Jan 2016 09:13:01 +0800 (PHT)
From: Paul Goyette
Note: from the kernel map, 0x805e3120 is the address of
vmspace0, as would be expected from the above initialization code. The
map doesn't have anything that correspond
Date: Tue, 5 Jan 2016 09:13:01 +0800 (PHT)
From: Paul Goyette
Note: from the kernel map, 0x805e3120 is the address of
vmspace0, as would be expected from the above initialization code. The
map doesn't have anything that corresponds to 0x805dea80 - the
closest
Looking into another problem (with filemon(4) if it matters), I ran into
the following DIAGNOSTIC code in miscfs/specfs/spec_vnops.c:
#ifdef DIAGNOSTIC
if (uio->uio_rw != UIO_WRITE)
panic("spec_write mode");
if (&uio->uio_vmspace->vm_map != kernel_map &&
uio-
Date: Mon, 4 Jan 2016 13:46:40 -0500
From: Gabriel Rosenkoetter
On 02 Jan, 2016, at 12:01 EST, Taylor R Campbell
wrote:
> In that case, why not make cpu_rng_init tell the caller whether or not
> there is a CPU RNG? It seems to me the CPU feature bits should
> determine the pr
stephan...@googlemail.com (Stephan) writes:
>There is even one second in the process without a single xfer. Can
>this be caused by the SD card itself, or may there be something
>improvable in the kernel?
This can be because of the filesystem. Lots of writes are delayed
to be able to sort or combi
There is another issue with the Pi which I recognized when /etc/daily
runs. The "find / -" jobs causes certain threads to hang
for a long time. That´s easily reproducable by issuing "find / >
/dev/null &". In the test I just made, I issued "ps" while the job
ran.
rpi/root> time ps
PID TTY STAT
While I was already sure that changing the I/O scheduler from disksort
to fcfs on the Pi increases sequential write speed from nearly 10MB/s
to 15 MB/s on average, it turned out that´s not true.
In fact, the writes speed varies for no recognizable reason. An
example of a "good" case:
rpi/root> dd
Can you pullup the polling-related corrections to usbdi.c to netbsd-7,
so ddb(4) will work in the next bugfix release?
Thanks and regards,
Stephan
2015-10-04 12:55 GMT+02:00 Nick Hudson :
> On 10/02/15 12:30, Stephan wrote:
>>
>> Hmm, I grabbed a recent HEAD kernel from nyftp.netbsd.org, but I
os...@cs.usask.ca (Greg Oster) writes:
>Have these changes, especially those to raiddump(), been extensively
>tested?
The regular operation has been tested extensively, in particular with
different component drivers and the autoconfig, but raiddump() not.
> RF_PROTECTED_SECTORS used to be req
cherry@ wrote:
> > "tsutsui" == Izumi Tsutsui writes:
>
> tsutsui> cherry@ wrote:
> >> Please find below a patch to remove .avail_(start|end) from
> >> struct vm_physseg
>
> tsutsui> What's advantage of these changes?
>
> tsutsui> Changing MD APIs could often cause botc
I'm trying to debug a reported problem with filemon(4), and to make
things a bit easier I tried to pass STDOUT_FILENO as the place where
filemon should write its output. Running this on a "console terminal"
within qemu, the code in filemon_output() sets up a struct iovec and
initializes a stru
12 matches
Mail list logo
