Hi,
I was testing a NH-230/231 NAS (running sandpoint) and wondered why
the PPCBoot firmware and the previously installed Linux used a different
MAC address than NetBSD does.
I found out that NetBSD's re(4) driver is reading the MAC from EEPROM
while PPCBoot and Linux are reading it from the
I found out that NetBSD's re(4) driver is reading the MAC from EEPROM
while PPCBoot and Linux are reading it from the chip's ID-registers
(RTK_IDRn).
What is correct? This is a Realtek 8169S:
Probably it's defined by hardware vendors, not chip.
The old RTL8139 (RTL8169 has compat mode)
On Fri, Nov 30, 2012 at 12:00:52PM +, David Laight wrote:
On Fri, Nov 30, 2012 at 08:00:51AM +, Michael van Elst wrote:
da...@l8s.co.uk (David Laight) writes:
I must look at how to determine that disks have 4k sectors and to
ensure filesystesm have 4k fragments - regardless of
These disks lie about their actual sector size.
These disks just follow their specification.
That's as meaningless as...on, to pick an unreasonably extreme example,
a hitman saying I was just following orders.
They also report the true sector size.
Not according to the documentation, at
Izumi Tsutsui wrote:
On 02.12.12 00:40:44 you wrote:
I found out that NetBSD's re(4) driver is reading the MAC from EEPROM
while PPCBoot and Linux are reading it from the chip's ID-registers
(RTK_IDRn).
What is correct? This is a Realtek 8169S:
Probably it's defined by hardware vendors,
Frank Wille wrote:
Probably it's defined by hardware vendors, not chip.
The old RTL8139 (RTL8169 has compat mode) seems to read MAC address
from EEPROM and those values are stored into RTK_IDRn registers.
Who writes it into the IDRn registers? The firmware? The driver? Or the chip
On Sat, Dec 01, 2012 at 04:27:14PM -0500, Mouse wrote:
Neither. The sector size claimed to the host should equal both the
sector size on the media and the granularity of the interface.
As a consumer of block devices, I don't care about either of these
things. What I care about is the largest
Neither. The sector size claimed to the host should equal both the
sector size on the media and the granularity of the interface.
As a consumer of block devices, I don't care about either of these
things. What I care about is the largest size sector that will (in
the ordinary course of
On Sat, 1 Dec 2012 23:46:07 +
David Holland dholland-t...@netbsd.org wrote:
I don't care about the block granularity of the interface. (Unless I
suppose it's larger than the atomic write size; but that would be
weird.)
If it's smaller than the atomic write size that's equally weird.
On Sat, Dec 01, 2012 at 07:07:36PM -0500, Mouse wrote:
Neither. The sector size claimed to the host should equal both the
sector size on the media and the granularity of the interface.
As a consumer of block devices, I don't care about either of these
things. What I care about is the
On Sun, Dec 02, 2012 at 01:32:17AM +, Julian Yon wrote:
I don't care about the block granularity of the interface. (Unless I
suppose it's larger than the atomic write size; but that would be
weird.)
If it's smaller than the atomic write size that's equally weird.
Because that
On Thu, Nov 29, 2012 at 06:19:37PM +0100, J. Hannken-Illjes wrote:
In short the attached diff:
- Adds a new kernel-internal errno ERESTARTVOP and changes VCALL() to
restart a vnode operation once it returns ERESTARTVOP.
- Changes fstrans_start() to take an optional `hint
things. What I care about is the largest size sector that will (in
^^^
the ordinary course of things anyway) be written atomically.
Then those are 512-byte-sector drives [...]
No; because I can do 4K atomic writes, I want to know about that.
And,
13 matches
Mail list logo
