Hello,
Last week I reported a complete hang with PenumbraOverture on kernel
2.6.35 and 2.6.36-rc3. This week I tried 2.6.36-rc4, and I still get a
complete hang after playing PenumbraOverture for about a minute. I'm not
using any xorg.conf, I'm using KMS. I also tried without KMS, and then I
On Thursday 16 September 2010 20:32:36 Jens Axboe wrote:
> On 2010-09-16 16:49, Steven Rostedt wrote:
> > Git blame shows this to be your code (copied from block/blktrace.c from
> > years past).
> >
> > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9)
>
> It isn't, it can
Hi
Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a
couple of times a day:
[ 2869.618504] [ cut here ]
[ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153!
[ 2869.618560] invalid opcode: [#1] PREEMPT SMP
[ 2869.618600] last
On my system, every 10 seconds drm_edid_block_valid() gets called 4
times by radeon_dvi_detect(). This results in 4 instances of a
multi-line hex dump of the same EDID (non-)data being logged every 10
seconds.
Silence the hex dump from drm_edid_block_valid() unless a drm_debug
module parameter
I'll try to come up with something for ncpfs.
Trivial lock replacement will open deadlock possibility when someone reads to
page which is also mmaped from the same filesystem (like grep likes to do). BKL
with its automated release on sleep helped (or papered over) a lot here.
Petr
"Arnd
We find there is another device id set for B43 chipset. After adding the device
id 4E90/4E92 beside 4E40/4E42, the machine works fine with the same
modification in xserver-xorg-video-intel.
Signed-off-by: Ike Panhc
---
drivers/gpu/drm/i915/i915_drv.c |1 +
1 files changed, 1 insertions(+),
We find there is another device id set for B43 chipset. After adding the device
id 4E90/4E92 beside 4E40/4E42, the machine works fine with the same
modification in xserver-xorg-video-intel.
Signed-off-by: Ike Panhc
---
drivers/char/agp/intel-agp.c |7 +--
drivers/char/agp/intel-agp.h |
There is another device id for Intel B43 chip. Since there is already an id
sets for B43 in intel-agp and i915. We tried to modify the kernel and
xserver-xorg-video-intel and they work fine on 8086:2E90/2E92 chipsets. I
believe this id sets is valid[1], and another patches has been sent to bug
idia support.
Thanks, pushed to the nouveau tree.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20100917/9056e4ec/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #5 from Michel D?nzer 2010-09-17 03:11:18
PDT ---
(In reply to comment #4)
> This happens with radeon.agpmode=-1 on the kernel boot command line. Without
> it, the kernel doesn't boot (it freeze, without eth connection and monitor
>
https://bugs.freedesktop.org/show_bug.cgi?id=28294
--- Comment #29 from Pavel Ondra?ka 2010-09-17 02:39:42
PDT ---
Created an attachment (id=38758)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38758)
screenshot with current mesa git (dab2a7660a407364a7327743b56ea9701d9b)
--
https://bugs.freedesktop.org/show_bug.cgi?id=28294
--- Comment #28 from Pavel Ondra?ka 2010-09-17 02:38:12
PDT ---
Created an attachment (id=38757)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38757)
screenshot with mesa 9021c56a5738815777f27c39b63637b5975270c6
--
Configure bugmail:
https://bugs.freedesktop.org/show_bug.cgi?id=28294
Pavel Ondra?ka changed:
What|Removed |Added
Attachment #35900|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=28294
Pavel Ondra?ka changed:
What|Removed |Added
CC||benjamin.segovia at intel.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=29787
--- Comment #9 from Arno Schuring 2010-09-17
02:19:58 PDT ---
While I still can't reproduce this at will, both the EDID errors and xrandr
resets seem related to system load. When the system is idle, or I'm simply
browsing or text-editing, the
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware to test. Can probably be
marked CONFIG_BROKEN_ON_SMP if
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
kernel/trace/blktrace.c:
Should be easy. Ingo? Steven?
Jens,
Git blame shows this to be your
From: Alan Cox a...@lxorguk.ukuu.org.uk
Date: Thu, 16 Sep 2010 16:07:59 +0100
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
IPX and Appletalk both have active users. They also look
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
...
fs/ncpfs:
Should be fixable if Petr still cares about it. Otherwise suggest
moving to
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
IPX and Appletalk both have active users. They also look fairly fixable
as the lock_kernel just maps to a stack private mutex, or in
On 2010-09-16 16:32:59, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
fs/qnx4:
Should be easy to fix, there are only a few places in the code that
use the BKL. Anders?
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
I'll take care of the IrDA part.
Cheers,
Samuel.
On 2010-09-16 16:49, Steven Rostedt wrote:
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
kernel/trace/blktrace.c:
Should be easy. Ingo?
From: Samuel Ortiz sam...@sortiz.org
Date: Thu, 16 Sep 2010 18:57:56 +0200
On Thu, 2010-09-16 at 16:32 +0200, Arnd Bergmann wrote:
net/appletalk:
net/ipx/af_ipx.c:
net/irda/af_irda.c:
Can probably be saved from retirement in drivers/staging if the
maintainers still care.
I'll
On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
This changes *all* instances of struct file_operations in
the kernel to have a .llseek operation and then changes
the default to no_llseek, which returns -ESPIPE, which
is what we had decided some time ago in a discussion
with Christoph
Hi,
On 16 Sep 2010, at 16:04, Jan Kara wrote:
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
...
fs/ncpfs:
Should be fixable if Petr still cares about
There is another device id for Intel B43 chip. Since there is already an id
sets for B43 in intel-agp and i915. We tried to modify the kernel and
xserver-xorg-video-intel and they work fine on 8086:2E90/2E92 chipsets. I
believe this id sets is valid[1], and another patches has been sent to bug
We find there is another device id set for B43 chipset. After adding the device
id 4E90/4E92 beside 4E40/4E42, the machine works fine with the same
modification in xserver-xorg-video-intel.
Signed-off-by: Ike Panhc ike@canonical.com
---
drivers/char/agp/intel-agp.c |7 +--
We find there is another device id set for B43 chipset. After adding the device
id 4E90/4E92 beside 4E40/4E42, the machine works fine with the same
modification in xserver-xorg-video-intel.
Signed-off-by: Ike Panhc ike@canonical.com
---
drivers/gpu/drm/i915/i915_drv.c |1 +
1 files
https://bugs.freedesktop.org/show_bug.cgi?id=29787
--- Comment #9 from Arno Schuring aelschur...@hotmail.com 2010-09-17 02:19:58
PDT ---
While I still can't reproduce this at will, both the EDID errors and xrandr
resets seem related to system load. When the system is idle, or I'm simply
browsing
https://bugs.freedesktop.org/show_bug.cgi?id=28294
Pavel Ondračka dra...@centrum.cz changed:
What|Removed |Added
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=28294
Pavel Ondračka dra...@centrum.cz changed:
What|Removed |Added
Attachment #35900|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=28294
--- Comment #28 from Pavel Ondračka dra...@centrum.cz 2010-09-17 02:38:12 PDT
---
Created an attachment (id=38757)
-- (https://bugs.freedesktop.org/attachment.cgi?id=38757)
screenshot with mesa 9021c56a5738815777f27c39b63637b5975270c6
--
https://bugs.freedesktop.org/show_bug.cgi?id=28294
--- Comment #29 from Pavel Ondračka dra...@centrum.cz 2010-09-17 02:39:42 PDT
---
Created an attachment (id=38758)
-- (https://bugs.freedesktop.org/attachment.cgi?id=38758)
screenshot with current mesa git (
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #5 from Michel Dänzer mic...@daenzer.net 2010-09-17 03:11:18 PDT
---
(In reply to comment #4)
This happens with radeon.agpmode=-1 on the kernel boot command line. Without
it, the kernel doesn't boot (it freeze, without eth
Hi
Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a
couple of times a day:
[ 2869.618504] [ cut here ]
[ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153!
[ 2869.618560] invalid opcode: [#1] PREEMPT SMP
[ 2869.618600] last
On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote:
Hi
Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a
couple of times a day:
[ 2869.618504] [ cut here ]
[ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153!
[
37 matches
Mail list logo
