>>> 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.
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 opt
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.
> Becaus
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 abo
On Sat, 1 Dec 2012 23:46:07 +
David Holland 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 implies that
>> 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
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 larges
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
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 hardwar
>> 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
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 - regard
> 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)
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 chip
13 matches
Mail list logo
