I still don't know what the root cause for the ,,Phy x: Link Status
Unknown'' events is
Just for the record: The root cause is probably a ``self initiated reset''
of the Hitachi (HGST) disk due to a bug in the A100 firmware (HGST calls
that ``microcode'').
Fortunately, the update process is
On Jan 14, 2014, at 5:12 PM, J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote:
On Jan 14, 2014, at 5:54 AM, David Holland dholland-t...@netbsd.org wrote:
On Mon, Jan 13, 2014 at 04:06:02PM +0100, J. Hannken-Illjes wrote:
snip
Even though it looks like we don't need creation ops to return
Hi,
Attached is a patch to genfb to make it possible to have serial console
but still have genfb enabled. I'm slightly worried this will break
genfb console on non-x86 machines however, so I'd like some testing.
At the very least a list of machines that need testing would be useful.
On Wed, Jan 15, 2014 at 11:08:41AM -0600, Jonathan A. Kollasch wrote:
Hi,
Attached is a patch to genfb to make it possible to have serial console
but still have genfb enabled. I'm slightly worried this will break
genfb console on non-x86 machines however, so I'd like some testing.
At the
jakllsch@ wrote:
Attached is a patch to genfb to make it possible to have serial console
but still have genfb enabled. I'm slightly worried this will break
genfb console on non-x86 machines however, so I'd like some testing.
At the very least a list of machines that need testing would be
Date: Mon, 13 Jan 2014 16:06:02 +0100
From: J. Hannken-Illjes hann...@eis.cs.tu-bs.de
On Jan 13, 2014, at 8:39 AM, David Holland dholland-t...@netbsd.org wrote:
On Tue, Jan 07, 2014 at 11:30:40AM +0100, J. Hannken-Illjes wrote:
(also, while this is minor I think I'd rather have
Date: Wed, 15 Jan 2014 16:08:04 +
From: Taylor R Campbell campbell+netbsd-tech-k...@mumble.net
As is, existing code calling, e.g., VOP_MKDIR will still compile. Is
there a reason the versioning doesn't rename it to VOP_MKDIR_V2?
For that matter, why new machinery for this
On Wed, 15 Jan 2014, Taylor R Campbell wrote:
For that matter, why new machinery for this versioning stuff at all?
Why not just rename the vop from mkdir to mkdir_v2? That would take
care of both struct vop_mkdir_v2_args and VOP_MKDIR_V2. Am I missing
something?
That would the calling code
On Thu, Jan 16, 2014 at 02:21:11AM +0900, Izumi Tsutsui wrote:
Probably it's rather better to fix sys/arch/x86/pci/pci_machdep.c
http://nxr.netbsd.org/xref/src/sys/arch/x86/pci/pci_machdep.c?r=1.63#940
not to set the is_console device property unconditionally.
(should check
I am writing a driver for an arm random number generator accelerator to provide
a source of random bits to rnd_pool.
How does one know at what rate to supply random bits to the pool using
rnd_add_data()? Assume for a moment that more bits/sec can be generated than
are needed, what criteria
On Wed, Jan 15, 2014 at 05:26:34PM -0600, Frank Zerangue wrote:
I am writing a driver for an arm random number generator accelerator to
provide a source of random bits to rnd_pool.
How does one know at what rate to supply random bits to the pool using
rnd_add_data()? Assume for a moment
On Wed, Jan 15, 2014 at 05:31:56PM +, Taylor R Campbell wrote:
As is, existing code calling, e.g., VOP_MKDIR will still compile. Is
there a reason the versioning doesn't rename it to VOP_MKDIR_V2?
For that matter, why new machinery for this versioning stuff at all?
Why not
On Wed, Jan 15, 2014 at 04:31:07PM +0100, J. Hannken-Illjes wrote:
I put a diff to http://www.netbsd.org/~hannken/vnode-pass2a-3.diff that
changes the vnode creation operations to keep the dvp locked.
Any objections or OK to commit?
I don't understand where all of the zfs changes arise
13 matches
Mail list logo
