Am 20.04.2013 23:29, schrieb Jeremy Chadwick:
>> My feeling is that the stalls are mostly from the error handler and the
>> overall time the drive is "frozen" gets shorter. If it had not _felt_
>> faster, I'd not have left that in sysctl.conf in the first place.
>
> Your understanding of what tha
ATA controller drivers are delaying conflicting commands, avoiding
conflicts in device.
21.04.2013 14:32 пользователь "Jeremy Chadwick" написал:
> On Sun, Apr 21, 2013 at 02:11:04PM +0300, Alexander Motin wrote:
> > On 21.04.2013 00:29, Jeremy Chadwick wrote:
> > >- The ATA commands which lead up
On Sun, Apr 21, 2013 at 02:11:04PM +0300, Alexander Motin wrote:
> On 21.04.2013 00:29, Jeremy Chadwick wrote:
> >- The ATA commands which lead up to the error also vary. Many are for
> > write requests, and from some entries I can see that the OS was doing
> > NCQ writes (WRITE FPDMA QUEUED)
On 21.04.2013 00:29, Jeremy Chadwick wrote:
- The ATA commands which lead up to the error also vary. Many are for
write requests, and from some entries I can see that the OS was doing
NCQ writes (WRITE FPDMA QUEUED) and then suddenly decided to do a
classic 28-bit LBA write (WRITE DMA).
On 04/04/2013 09:00, Matthias Andree wrote:
Any good "concurrent write" exercise tools for Unix that I could run
on the Linux ext4 partition that you would propose?
benchmarks/fio is good for that.
--
Bruce Cran
___
freebsd-stable@freebsd.org mailin
On Thu, Apr 04, 2013 at 10:00:18AM +0200, Matthias Andree wrote:
> Am 04.04.2013 03:05, schrieb Jeremy Chadwick:
>
> { snipping stuff I have no comment on. reference thread: }
> { > http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073036.html }
>
> > One piece of evidence that refute
On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote:
> I have just sent more information to the PR at
> http://www.freebsd.org/cgi/query-pr.cgi?pr=157397
>
> The short summary (more info in the PR) is:
>
> - limiting tags to 31 does not help
>
> - disabling NCQ appears to help in ini
Am 04.04.2013 03:05, schrieb Jeremy Chadwick:
>>> Please provide "gpart show -p ada1" output, both here and in the PR,
>>> if you could.
>>
>> =>63 1953525105ada1 MBR (931G)
>> 63 209714337 ada1s1 freebsd [active] (100G)
>>209714400 800 - free -
On Thu, Apr 04, 2013 at 02:19:16AM +0200, Matthias Andree wrote:
> Am 04.04.2013 01:38, schrieb Jeremy Chadwick:
>
> ...
>
> > While skimming Linux libata code and commits in the past, the only
> > glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the
> > hardware revision apparentl
Am 04.04.2013 01:38, schrieb Jeremy Chadwick:
...
> While skimming Linux libata code and commits in the past, the only
> glaringly obvious bug/issue I see is with SB600/SB700 chipsets (the
> hardware revision apparently matters) and port multiplier (PMP) support
> and soft resets.
>
> Are you us
On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote:
> I have just sent more information to the PR at
> http://www.freebsd.org/cgi/query-pr.cgi?pr=157397
>
> The short summary (more info in the PR) is:
>
> - limiting tags to 31 does not help
>
> - disabling NCQ appears to help in ini
I have just sent more information to the PR at
http://www.freebsd.org/cgi/query-pr.cgi?pr=157397
The short summary (more info in the PR) is:
- limiting tags to 31 does not help
- disabling NCQ appears to help in initial testing, but warrants more
testing
- error happens during WRITE_FPDMA_QUEUE
On 02.04.2013 21:39, Matthias Andree wrote:
Am 31.03.2013 23:02, schrieb Scott Long:
So what I hear you and Matthias saying, I believe, is that it should be easier
to
force disks to fall back to non-NCQ mode, and/or have a more responsive
black-list for problematic controllers. Would this hel
Am 01.04.2013 17:07, schrieb Stefan Esser:
> Am 01.04.2013 15:14, schrieb Victor Balada Diaz:
>> Being able to configure quirks from loader.conf for disks AND controllers
>> would be great
>> and is not hard to do. If you want i can do a patch in two weeks and send it
>> to you. That
>> way it's
Am 31.03.2013 23:02, schrieb Scott Long:
> So what I hear you and Matthias saying, I believe, is that it should be
> easier to
> force disks to fall back to non-NCQ mode, and/or have a more responsive
> black-list for problematic controllers. Would this help the situation? It's
> hard to
> jus
On Mon, Apr 01, 2013 at 05:07:20PM +0200, Stefan Esser wrote:
> Am 01.04.2013 15:14, schrieb Victor Balada Diaz:
> > Being able to configure quirks from loader.conf for disks AND controllers
> > would be great
> > and is not hard to do. If you want i can do a patch in two weeks and send
> > it to
Am 01.04.2013 15:14, schrieb Victor Balada Diaz:
> Being able to configure quirks from loader.conf for disks AND controllers
> would be great
> and is not hard to do. If you want i can do a patch in two weeks and send it
> to you. That
> way it's easy to test disabling NCQ and/or other things in
On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote:
>
> On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote:
>
> > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> >> Hi.
> >>
> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> >> stack, us
On Sun, Mar 31, 2013 at 03:02:09PM -0600, Scott Long wrote:
> On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote:
> > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> >> Hi.
> >>
> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> >> stack, using on
On Mar 31, 2013, at 7:04 AM, Victor Balada Diaz wrote:
> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
>> Hi.
>>
>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
>> stack, using only some controller drivers of old ata(4) by having
>> `options ATA_CA
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> Hi.
>
> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> stack, using only some controller drivers of old ata(4) by having
> `options ATA_CAM` enabled in all kernels by default. I have a wish to
> drop no
Am 31.03.2013 06:00, schrieb Peter Wemm:
> We're talking about 10.x, so if you want it fixed, you need update
> with 10.x information.
>
> Please put 10.x diagnostics in the PR.
I will not. The PR was filed four months before 10-CURRENT branched;
I have no reason to assume it were to be no long
On 31.03.2013 08:13, Ian Smith wrote:
On Sat, 30 Mar 2013 21:00:24 -0700, Peter Wemm wrote:
> On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree
wrote:
> > Am 27.03.2013 22:22, schrieb Alexander Motin:
> >> Hi.
> >>
> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based
On Sat, 30 Mar 2013 21:00:24 -0700, Peter Wemm wrote:
> On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree wrote:
> > Am 27.03.2013 22:22, schrieb Alexander Motin:
> >> Hi.
> >>
> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> >> stack, using only some controller d
On Sat, Mar 30, 2013 at 4:29 PM, Matthias Andree wrote:
> Am 27.03.2013 22:22, schrieb Alexander Motin:
>> Hi.
>>
>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
>> stack, using only some controller drivers of old ata(4) by having
>> `options ATA_CAM` enabled in all kerne
Am 28.03.2013 16:31, schrieb Scott Long:
>
> On Mar 28, 2013, at 8:00 AM, Ian Lepore wrote:
>
>> On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
>>> On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big c
Am 27.03.2013 22:22, schrieb Alexander Motin:
> Hi.
>
> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> stack, using only some controller drivers of old ata(4) by having
> `options ATA_CAM` enabled in all kernels by default. I have a wish to
> drop non-ATA_CAM ata(4) code,
On 28 March 2013 10:26, Poul-Henning Kamp wrote:
> Isn't there some kernel compile-time option to eliminate the huge
> tables used for errormessages etc ?
Yup. It doesn't save all that much in the grand scheme of things.
Doubly so since my secondary size constraint is an 896k partition that
I lz
On Thu, 28 Mar 2013, Ian Lepore wrote:
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim dow
In message
, Adrian
Chadd wri
tes:
>On 28 March 2013 09:05, Lev Serebryakov wrote:
>adrian@freefall:~/public_html/ath$ cat AP121-nodebug.txt | egrep
>'(cam_|umass|scsi_)' | awk '{a+=$4} END {print a}'
>190904
>
>It doesn't seem like a lot, but it does add up..
Isn't there some kernel compile-t
.. and before you ask - yes, there are embedded boards with limited
RAM that also have ATA ports. :-)
Adrian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd
On 28 March 2013 09:05, Lev Serebryakov wrote:
> Yes: USB UMASS. It uses CAM too, and useful for very small systems,
> like 4MiB FLASH and 16MiB RAM (yes, whole system image, kernel and
> all, should be packed to 4MiB).
>
> Please note, Adrian speaks about CAM, not only CAM + ATA.
And I
Hello, Aleksandr.
You wrote 28 марта 2013 г., 18:09:53:
>> It'd be nice if we could slim down the CAM stack a bit first; it makes
>> embedding it on the smaller devices really freaking painful.
AR> /me never seen embedded devices with ATA/SATA and less than 64MB of RAM.
AR> (i386/i486 old machine
On Mar 28, 2013, at 8:00 AM, Ian Lepore wrote:
> On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
>> On 28.03.2013 02:43, Adrian Chadd wrote:
>>> My main concern with the new stuff is that it requires CAM and that's
>>> reasonably big compared to the standalone ATA code.
>>>
>>> It'd b
On Mar 27, 2013, at 6:43 PM, Adrian Chadd wrote:
> My main concern with the new stuff is that it requires CAM and that's
> reasonably big compared to the standalone ATA code.
>
>From a code execution standpoint? No, it's not.
> It'd be nice if we could slim down the CAM stack a bit first; it
On Wed, 27 Mar 2013 17:43:07 -0700
Adrian Chadd wrote:
> My main concern with the new stuff is that it requires CAM and that's
> reasonably big compared to the standalone ATA code.
>
> It'd be nice if we could slim down the CAM stack a bit first; it makes
> embedding it on the smaller devices re
On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
> On 28.03.2013 02:43, Adrian Chadd wrote:
> > My main concern with the new stuff is that it requires CAM and that's
> > reasonably big compared to the standalone ATA code.
> >
> > It'd be nice if we could slim down the CAM stack a bit first
Alexander Motin wrote this message on Thu, Mar 28, 2013 at 09:17 +0200:
> On 28.03.2013 02:43, Adrian Chadd wrote:
> >My main concern with the new stuff is that it requires CAM and that's
> >reasonably big compared to the standalone ATA code.
> >
> >It'd be nice if we could slim down the CAM stack
On 28.03.2013 02:43, Adrian Chadd wrote:
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the smaller devices really freaking painful.
My main concern with the new stuff is that it requires CAM and that's
reasonably big compared to the standalone ATA code.
It'd be nice if we could slim down the CAM stack a bit first; it makes
embedding it on the smaller devices really freaking painful.
Thanks,
adrian
_
On Thu, Mar 28, 2013 at 12:22:11AM +0200, Alexander Motin wrote:
> On 28.03.2013 00:05, Steve Kargl wrote:
> >
> > Last time I tested the new one, and this was several months
> > ago, the system (a Dell Latitude D530 laptop) would not boot.
>
> Probably we should just fix that. Any more info?
>
On 28.03.2013 00:05, Steve Kargl wrote:
On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote:
On 27.03.2013 23:32, Steve Kargl wrote:
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
Hi.
Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
stack, u
On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote:
> On 27.03.2013 23:32, Steve Kargl wrote:
> > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> >> Hi.
> >>
> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> >> stack, using only some contr
On Wed, Mar 27, 2013 at 2:32 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> > Hi.
> >
> > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> > stack, using only some controller drivers of old at
On 27.03.2013 23:32, Steve Kargl wrote:
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
Hi.
Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
stack, using only some controller drivers of old ata(4) by having
`options ATA_CAM` enabled in all kernels by defau
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:
> Hi.
>
> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
> stack, using only some controller drivers of old ata(4) by having
> `options ATA_CAM` enabled in all kernels by default. I have a wish to
> drop no
Hi.
Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA
stack, using only some controller drivers of old ata(4) by having
`options ATA_CAM` enabled in all kernels by default. I have a wish to
drop non-ATA_CAM ata(4) code, unused since that time from the head
branch to allow
47 matches
Mail list logo
