On 2020/03/20 07:21, Nick Hudson wrote:
>
>
> On 19/03/2020 09:19, sc.dy...@gmail.com wrote:
>> On 2020/03/19 07:10, Nick Hudson wrote:
>>> On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
On 2020/02/17 21:33, Nick Hudson wrote:
>>>
>>> [snip]
>>>
> xhci could do better and support
On 19/03/2020 09:19, sc.dy...@gmail.com wrote:
On 2020/03/19 07:10, Nick Hudson wrote:
On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
On 2020/02/17 21:33, Nick Hudson wrote:
[snip]
xhci could do better and support multiple DMA segments, but uvm could
also help.
To access each DMA
On 2020/03/19 07:10, Nick Hudson wrote:
> On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
>> On 2020/02/17 21:33, Nick Hudson wrote:
>
> [snip]
>
>>> xhci could do better and support multiple DMA segments, but uvm could
>>> also help.
>>
>> To access each DMA segment in usb_dma_t *dma, should it
On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
> On 2020/02/17 21:33, Nick Hudson wrote:
[snip]
>> xhci could do better and support multiple DMA segments, but uvm could
>> also help.
>
> To access each DMA segment in usb_dma_t *dma, should it be processed
> like this?
>
> for (i = 0; i <
On 2020/02/17 21:33, Nick Hudson wrote:
> On 17/02/2020 16:23, Paul Goyette wrote:
> [...]
>
>>> More info...
>>>
>>> First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM.
>>>
>>> On IRC it was suggested (thanks, maya!) that the error message might be
>>> related to memory
w...@netbsd.org (Thomas Klausner) writes:
>umass0: using SCSI over Bulk-Only
>scsibus0 at umass0: 2 targets, 1 lun per target
>sd0 at scsibus0 target 0 lun 0: disk fixed
>sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00
>SENSE KEY: Not Ready
> ASC/ASCQ: Logical Unit Is
While we're talking about annoyances (sorry for hijacking the thread)
I often see something like:
umass0 at uhub4 port 3 configuration 1 interface 0
umass0: Samsung (0x4e8) D3 Station (0x6125), rev 3.00/2.02, addr 1
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
p...@whooppee.com (Paul Goyette) writes:
>> other data structures in KVA space and that helps. Something that almost
>> always helps is to reduce the value of the kernel variable desiredvnodes
>> (you may restore it a few seconds later).
>Would that be ``sysctl kern.maxvnodes'' or some other
On Tue, 18 Feb 2020 at 09:33, Chavdar Ivanov wrote:
>
> On Tue, 18 Feb 2020 at 03:15, Paul Goyette wrote:
> >
> > On Mon, 17 Feb 2020, Michael van Elst wrote:
> >
> > > p...@whooppee.com (Paul Goyette) writes:
> > >
> > >> So, sounds like "something somewhere isn't quite right (tm)". I would
>
On Tue, 18 Feb 2020 at 03:15, Paul Goyette wrote:
>
> On Mon, 17 Feb 2020, Michael van Elst wrote:
>
> > p...@whooppee.com (Paul Goyette) writes:
> >
> >> So, sounds like "something somewhere isn't quite right (tm)". I would
> >> have expected a memory allocation failure to automatically trigger
On Mon, 17 Feb 2020, Michael van Elst wrote:
p...@whooppee.com (Paul Goyette) writes:
So, sounds like "something somewhere isn't quite right (tm)". I would
have expected a memory allocation failure to automatically trigger some
mechanism to reclaim some of the file cache...
It's not the
mlel...@serpens.de (Michael van Elst) writes:
> g...@lexort.com (Greg Troxel) writes:
>
>>My impression is that something, perhaps more umass than *hci, needs a
>>very large chunk of memory.
>
> umass allocates two 64k (MAXPHYS sized) DMA buffers and a few smaller ones.
> For all drivers but ehci
g...@lexort.com (Greg Troxel) writes:
>My impression is that something, perhaps more umass than *hci, needs a
>very large chunk of memory.
umass allocates two 64k (MAXPHYS sized) DMA buffers and a few smaller ones.
For all drivers but ehci each buffer must use contigous physical pages.
ehci
p...@whooppee.com (Paul Goyette) writes:
>available. The concensus on IRC is that this is a bug in the xhci(4)
>driver.
xhci could support scatter/gather transfers to multiple smaller buffers
to mitigate the problem, so far only ehci(4) does this. But some hardware
wouldn't support it unless
p...@whooppee.com (Paul Goyette) writes:
>So, sounds like "something somewhere isn't quite right (tm)". I would
>have expected a memory allocation failure to automatically trigger some
>mechanism to reclaim some of the file cache...
It's not the file cache. Freeing the file cache however also
On 17/02/2020 16:23, Paul Goyette wrote:
[...]
More info...
First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM.
On IRC it was suggested (thanks, maya!) that the error message might be
related to memory fragmentation. I didn't believe it (given how much
RAM I have), but a
Paul Goyette writes:
> First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM.
>
> On IRC it was suggested (thanks, maya!) that the error message might be
> related to memory fragmentation. I didn't believe it (given how much
> RAM I have), but a quick check with top(1) showed
This is now PR kern/54997
On Mon, 17 Feb 2020, Paul Goyette wrote:
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC
I get the following errors when plugging in a USB hard drive:
umass0 at uhub1 port 2 configuration 1 interface 0
umass0: Western Digital (0x1058) Ext HDD
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC
I get the following errors when plugging in a USB hard drive:
umass0 at uhub1 port 2 configuration 1 interface 0
umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02,
addr 32
umass0: using SCSI over
On Mon, 17 Feb 2020, Paul Goyette wrote:
On Mon, 17 Feb 2020, Paul Goyette wrote:
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC
I get the following errors when plugging in a USB hard drive:
umass0 at uhub1 port 2 configuration 1 interface 0
umass0: Western Digital
On Mon, 17 Feb 2020, Paul Goyette wrote:
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC
I get the following errors when plugging in a USB hard drive:
umass0 at uhub1 port 2 configuration 1 interface 0
umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC
I get the following errors when plugging in a USB hard drive:
umass0 at uhub1 port 2 configuration 1 interface 0
umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32
umass0: using SCSI over
22 matches
Mail list logo
