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 -- something related
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
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 you
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:
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
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
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 would need to
On Wed, 3 Apr 2013 10:35:47 +0100, Thomas Sparrevohn
thomas.sparrev...@btinternet.com 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
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
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 uzi...@da3m0n8t3r.com wrote:
On Wed, 3 Apr 2013 10:35:47 +0100,
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
On 3 April 2013 11:16, maksim yevmenkin maksim.yevmen...@gmail.com 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
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
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 using a
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 initial
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 apparently
16 matches
Mail list logo
