headers
Matthew Mondor | 1 Dec 2009 01:01

Re: ffs extended attributes status

On Mon, 30 Nov 2009 22:48:52 +0100
Peter Kelm <peter_kelm <at> yahoo.com> wrote:

> what is the status of extended attributes in NetBSD ffs. From what I  
> read ffsv2/UFS2 should support them but it seems like I cannot get  
> them to work.
> I tried to use the python version of xattr (0.4) but all I get is  
> "IOError: [Errno 45] Operation not supported: './thetestfile". Are  
> there any specific kernel or filesystem options to enable them?

I personally only remember reading about FFS1 ones, i.e. the following
manual pages:

extattr(9), rmextattr(8), extattrctl(8), extattr_get_file(2), extattr(3)

However I've never tried them, I think that space also has to be
reserved/crated to store them (possibly see the initattr command of
extattrctl)...
--

-- 
Matt
Permalink | Reply | 0 comments |
headers
FUKAUMI Naoki | 1 Dec 2009 01:03

Re: porting udl(4) from OpenBSD

At Mon, 30 Nov 2009 17:27:36 -0600,
David Young wrote:
> Neat.  Is the Mimo USB monitor
> <http://www.thinkgeek.com/computing/usb-gadgets/bfa3/> supported?

it seems Nanovision UM-7xx series. it should work.
(incomplete) product list is here

  http://www.displaylink.com/shop/
  http://www.displaylink.com/support/supported.php

--
FUKAUMI Naoki
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 2 Dec 2009 14:49

Re: panic on zero length SCSI read

On Mon, Nov 30, 2009 at 02:09:52PM +0000, Julian Coleman wrote:
> Hi,
> 
> I was reading a music CD with cdparanoia on sparc64.  The drive failed to
> read a sector from the disk and the machine paniced with:
> 
>   iommu_dvmamap_sync: segment too short 0
> 
> and the backtrace was:
> 
>   _iommu_dvmamap_sync()
>   iommu_dvmamap_sync()
>   esiop_scsipi_request()
>   scsipi_run_queue()
> 
> A fix for the panic is simple (see attached), but I wonder if instead, esiop
> should be modified to not call bus_dmamap_sync() if the length is 0?  In this
> case, it is esiop_cmd->cmd_c.dmamap_cmd->dm_mapsize at line 1608 of esiop.c
> in current sources:
> 
> 		bus_dmamap_sync(sc->sc_c.sc_dmat, esiop_cmd->cmd_c.dmamap_cmd,
> 		    0, esiop_cmd->cmd_c.dmamap_cmd->dm_mapsize,
> 		    BUS_DMASYNC_PREWRITE);
> 
> but perhaps the same applies in other cases too.

I think it's better to fix bus_dma(9) because other drivers may call sync
with a 0 len too ...

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Young | 3 Dec 2009 13:17
Picon
Favicon

replacing extent(9) with vmem(9): lessons learned

I've tried to replace the management of i386 bus space by extent(9) with
management by vmem(9).  I've found some API/implementation problems in
vmem(9) that make vmem(9) a dissatisfying replacement for extent(9).

Problem 1: vmem(9) cannot manage a region that begins at 0.

    vmem(9) reserves the address 0 for indicating errors.  For
    example, vmem_xalloc(9) returns VMEM_ADDR_NULL (0) if it cannot
    find a suitable region.

    extent(9) indicates errors "out of band" instead of reserving
    an address for error indications, so it can manage a region
    starting at 0.

    No workaround that I have found is very satisfying.

Problem 2: vmem(9) cannot manage a region that includes the maximum
    address, ~(vmem_addr_t)0.

    This is an implementation problem.  Sometimes vmem(9) will add
    the start of a region to the size of a region without checking
    for overflow.  For example, 0x1 (start) + 0xffffffff (size) ==
    0.  Every use of BT_END() needs some TLC.

Problem 3: vmem(9) uses malloc(9)/pool(9)/RUN_ONCE(9), but
    the bus space regions are initialized and used before
    malloc(9)/pool(9)/RUN_ONCE(9) are available.

    I have a rudimentary fix in my tree.  I added a new API routine,
    vmem_create_storage(..., void *storage, size_t storage_size)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christoph Egger | 3 Dec 2009 13:32
Picon
Picon

Re: replacing extent(9) with vmem(9): lessons learned

On Thursday 03 December 2009 13:17:49 David Young wrote:
> I've tried to replace the management of i386 bus space by extent(9) with
> management by vmem(9).  I've found some API/implementation problems in
> vmem(9) that make vmem(9) a dissatisfying replacement for extent(9).
>
> Problem 1: vmem(9) cannot manage a region that begins at 0.
>
>     vmem(9) reserves the address 0 for indicating errors.  For
>     example, vmem_xalloc(9) returns VMEM_ADDR_NULL (0) if it cannot
>     find a suitable region.
>
>     extent(9) indicates errors "out of band" instead of reserving
>     an address for error indications, so it can manage a region
>     starting at 0.
>
>     No workaround that I have found is very satisfying.
>
> Problem 2: vmem(9) cannot manage a region that includes the maximum
>     address, ~(vmem_addr_t)0.
>
>     This is an implementation problem.  Sometimes vmem(9) will add
>     the start of a region to the size of a region without checking
>     for overflow.  For example, 0x1 (start) + 0xffffffff (size) ==
>     0.  Every use of BT_END() needs some TLC.
>
> Problem 3: vmem(9) uses malloc(9)/pool(9)/RUN_ONCE(9), but
>     the bus space regions are initialized and used before
>     malloc(9)/pool(9)/RUN_ONCE(9) are available.
>
>     I have a rudimentary fix in my tree.  I added a new API routine,
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Young | 3 Dec 2009 13:43
Picon
Favicon

Re: replacing extent(9) with vmem(9): lessons learned

On Thu, Dec 03, 2009 at 01:32:00PM +0100, Christoph Egger wrote:
> Problem 4: vmem(9) does not allocate page aligned memory through kmem(9).
>       This is a problem e.g. for Xen where page-aligned memory is required for
>       the ring buffers. A workaround is to use uvm_km_alloc().

kmem(9) does not ask vmem(9) for page-aligned memory using
vmem_xalloc(9), although it could.  I don't see why that is a vmem(9)
problem.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933
Permalink | Reply | 0 comments |
headers
David Laight | 5 Dec 2009 14:53
Picon

Quirk WD_QUIRK_SPLIT_MOD15_WRITE

sys/dev/ata/wd.c has some very strange code for the
WD_QUIRK_SPLIT_MOD15_WRITE quirk.

The code splits in two any transfers where the 'sector_count % 15 == 1'.
It appears to do this by dividing the byte transfer size in two.
This is fine for 16 sector transfers (converts one 16k byte transfer
into two 8k transfers), but it next applies to 31 sector transfers and
I can't help thinking that the requests for 15.5 sectors aren't going
to be processed correctly!

Have I missed something?

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 2 comments |
headers
David Laight | 5 Dec 2009 15:17
Picon

Re: Quirk WD_QUIRK_SPLIT_MOD15_WRITE

On Sat, Dec 05, 2009 at 01:53:21PM +0000, David Laight wrote:
> sys/dev/ata/wd.c has some very strange code for the
> WD_QUIRK_SPLIT_MOD15_WRITE quirk.
> 
> The code splits in two any transfers where the 'sector_count % 15 == 1'.
> It appears to do this by dividing the byte transfer size in two.
> This is fine for 16 sector transfers (converts one 16k byte transfer
> into two 8k transfers), but it next applies to 31 sector transfers and
> I can't help thinking that the requests for 15.5 sectors aren't going
> to be processed correctly!
> 
> Have I missed something?

Apart for the fact that it converts an 8k transfer into two 4k ones ;-)

Perhaps it should just do the first 4k separately.

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |
headers
David Laight | 5 Dec 2009 16:06
Picon

WD_QUIRK_FORCE_LBA48

The 'wd' (aka ATA disk) driver has a load of code for the
WD_QUIRK_FORCE_LBA48 quirk.

This forces LBA48 transfers for an ever increasing number of disks.

My suspicion is that the problems only relate to transfers that
actually cross the LBA48 boundary.

So quite possibly checking:
	wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
would remove the need for the quirk.

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 78 comments |
headers
der Mouse | 5 Dec 2009 16:59

Re: WD_QUIRK_FORCE_LBA48

> The 'wd' (aka ATA disk) driver has a load of code for the
> WD_QUIRK_FORCE_LBA48 quirk.

> This forces LBA48 transfers for an ever increasing number of disks.

> My suspicion is that the problems only relate to transfers that
> actually cross the LBA48 boundary.

> So quite possibly checking:
> 	wd->sc_wdc_bio.blkno + nblks > LBA48_THRESHOLD
> would remove the need for the quirk.

In my wd.c, I actually added another quirk, one which effectively
lowers LBA48_THRESHOLD by one sector, upon finding that my "Hitachi
HDT721010SLA360" was returning errors for sector 0xfffffff:

        if ( (wd->sc_quirks & WD_QUIRK_FORCE_LBA48) ||
             ( (wd->sc_flags & WDF_LBA48) &&
               ( (wd->sc_quirks & WD_QUIRK_LOW_LBA48_THRESH) ?
                 (wd->sc_wdc_bio.blkno >= LBA48_THRESHOLD) :
                 (wd->sc_wdc_bio.blkno > LBA48_THRESHOLD) ) ) )

Looking at the comments, I suspect at least a few of the
QUIRK_FORCE_LBA48 drives could use this instead, but since I don't have
them to test, I don't know.

But, really, it's not clear to me that it's worth doing non-LBA48
transfers at all on drives capable of LBA48 - what's the cost, two more
command bytes per transfer?  Four?  And that, only for accesses below
the 128G point.
(Continue reading)

Permalink | Reply | 11 comments |

Gmane