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
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 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
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 3 April 2013 11:16, maksim yevmenkin wrote:
> Hi Adrian !
>
> Thank you for your work. I briefly looked at it and it seems fine to me. I'm
> not able to give it a proper review as I'm traveling internationally
> currently. Having said all that, I think it would be reasonable to commit it
>
Hi Adrian !
Thank you for your work. I briefly looked at it and it seems fine to me. I'm
not able to give it a proper review as I'm traveling internationally currently.
Having said all that, I think it would be reasonable to commit it as is into
head.
Thanks,
Max
On Apr 3, 2013, at 10:52 A
Hi,
can you guys please ensure a PR is filed with all the information
you've just included?
the clang team would likely love to have this much information in a bug report.
Thanks!
adrian
On 3 April 2013 10:50, Waitman Gobble wrote:
> On Wed, 3 Apr 2013 10:35:47 +0100, "Thomas Sparrevohn"
Hi,
Here you go:
http://people.freebsd.org/~adrian/ath/20130401-ath-bluetooth.diff
The ath3k driver in linux does a fair bit more than ath3kfw:
* if it's a subset of chips that needs firmware, it squirts ath3k-1.fw onto it
* there's a subset of chips that get ROM/RAM patches; so if it's one
of
On Wed, 3 Apr 2013 10:35:47 +0100, "Thomas Sparrevohn"
wrote:
>
>I have had the same problem - it seems like a "sysctl" call provokes a
>overrun in a strlen call. It is not reproducible with a GENERIC kernel with
>debugging in my case. However a simple workaround is to compile
>nvidia-driver wit
On Tue, Apr 02, 2013 at 11:06:06PM +0200, m...@kernel32.de wrote:
> Hi again,
>
> Am 2013-04-02 21:52, schrieb Konstantin Belousov:
> > On Tue, Apr 02, 2013 at 08:23:20PM +0200, m...@kernel32.de wrote:
> >
> > Try breaking into the debugger and see where it progresses. To do
> > this,
> > you wou
On 03.04.2013 14:21, Alexander Motin wrote:
On 03.04.2013 12:32, Alexander Motin wrote:
On 03.04.2013 02:15, deeptech71 wrote:
As of r248872, my system, when ordered to power off, stalls at the
"Uptime: [...]" message. Before that revision, the "Uptime" message
would be followed by several addi
On 03.04.2013 12:32, Alexander Motin wrote:
On 03.04.2013 02:15, deeptech71 wrote:
As of r248872, my system, when ordered to power off, stalls at the
"Uptime: [...]" message. Before that revision, the "Uptime" message
would be followed by several additional messages -- something related to
"usb
I have had the same problem - it seems like a "sysctl" call provokes a
overrun in a strlen call. It is not reproducible with a GENERIC kernel with
debugging in my case. However a simple workaround is to compile
nvidia-driver with gcc.
-Original Message-
From: owner-freebsd-curr...@freebs
On 03.04.2013 02:15, deeptech71 wrote:
As of r248872, my system, when ordered to power off, stalls at the
"Uptime: [...]" message. Before that revision, the "Uptime" message
would be followed by several additional messages -- something related to
"usb controllers" -- before powering off.
Could
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
On 2013-04-03, Andriy Gapon wrote:
> on 03/04/2013 02:15 deeptech71 said the following:
> > As of r248872, my system, when ordered to power off, stalls at the "Uptime:
> > [...]" message. Before that revision, the "Uptime" message would be
> > followed by
> > several additional messages -- somethi
16 matches
Mail list logo
