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(+), 0
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
trac
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 car
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 Chris
From: Samuel Ortiz
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 take care
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. In
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: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
> 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 se
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 drive
From: Alan Cox
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 fairly fixable
>
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
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 nobody
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 car
Phil Turmel writes:
> Build breakage:
>
> drivers/built-in.o: In function `nouveau_acpi_edid':
> (.text+0x13404e): undefined reference to `acpi_video_get_edid'
> make: *** [.tmp_vmlinux1] Error 1
>
> Introduced by:
>
> a6ed76d7ffc62ffa474b41d31b011b6853c5de32 is the first bad commit
> commit a6ed
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. In
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: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 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 drive
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 nobody
> 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 se
Rely on monitor's audio capability to turn on audio output for HDMI.
Tested-by: Wu Fengguang
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/intel_hdmi.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/
This will turn on DP audio output by checking monitor's audio
capability.
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/intel_dp.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 208a4ec..4a
To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: Wu Fengguang
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/drm_edid.c | 85 +
DIN: S-video?
Clearly your working monitor (DVI) is on output DVI-0.
What is the actual card you have? (manufacturer, model)
List all of the connectors that it actually (physically) has.
I can think of a few possibilities:
1) That the DVI and HDMI plugs are wired into the same place,
2) That the
From: Alan Cox
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 fairly fixable
>
From: Samuel Ortiz
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 take care
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #4 from DaNiMoTh 2010-09-16 12:00:25 PDT ---
(In reply to comment #3)
> Does radeon.agpmode=1 or radeon.agpmode=-1 help?
This happens with radeon.agpmode=-1 on the kernel boot command line. Without
it, the kernel doesn't boot (it fre
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #4 from DaNiMoTh 2010-09-16 12:00:25 PDT ---
(In reply to comment #3)
> Does radeon.agpmode=1 or radeon.agpmode=-1 help?
This happens with radeon.agpmode=-1 on the kernel boot command line. Without
it, the kernel doesn't boot (it fre
https://bugs.freedesktop.org/show_bug.cgi?id=29901
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29901
Marek Ol??k changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=29901
--- Comment #11 from Tom Stellard 2010-09-16 11:05:32 PDT
---
(In reply to comment #8)
> Created an attachment (id=38727)
View: https://bugs.freedesktop.org/attachment.cgi?id=38727
Review: https://bugs.freedesktop.org/review?bug=29901&attachme
https://bugs.freedesktop.org/show_bug.cgi?id=29901
--- Comment #11 from Tom Stellard 2010-09-16 11:05:32
PDT ---
(In reply to comment #8)
> Created an attachment (id=38727)
View: https://bugs.freedesktop.org/attachment.cgi?id=38727
Review: https://bugs.freedesktop.org/review?bug=29901&attachme
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
https://bugs.freedesktop.org/show_bug.cgi?id=29095
--- Comment #9 from Tom Stellard 2010-09-16 10:14:01 PDT
---
Created an attachment (id=38748)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38748)
dmesg with pci=noacpi from linus' tree HEAD 9c03f16
--
Configure bugmail: https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=29095
--- Comment #9 from Tom Stellard 2010-09-16 10:14:01
PDT ---
Created an attachment (id=38748)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38748)
dmesg with pci=noacpi from linus' tree HEAD 9c03f16
--
Configure bugmail: https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=29095
--- Comment #8 from Tom Stellard 2010-09-16 10:13:10 PDT
---
Created an attachment (id=38747)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38747)
dmesg without pci=noacpi from linus' tree HEAD 9c03f16
--
Configure bugmail: https://bugs
https://bugs.freedesktop.org/show_bug.cgi?id=29095
--- Comment #8 from Tom Stellard 2010-09-16 10:13:10
PDT ---
Created an attachment (id=38747)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38747)
dmesg without pci=noacpi from linus' tree HEAD 9c03f16
--
Configure bugmail: https://bugs
https://bugs.freedesktop.org/show_bug.cgi?id=29095
Tom Stellard changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=29095
Tom Stellard changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #3 from Michel Dänzer 2010-09-16 08:42:31 PDT
---
Does radeon.agpmode=1 or radeon.agpmode=-1 help?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #3 from Michel D?nzer 2010-09-16 08:42:31
PDT ---
Does radeon.agpmode=1 or radeon.agpmode=-1 help?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
https://bugs.freedesktop.org/show_bug.cgi?id=30227
Michel Dänzer changed:
What|Removed |Added
Attachment #38744|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30227
Michel Dänzer changed:
What|Removed |Added
Attachment #38743|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30227
Michel D?nzer changed:
What|Removed |Added
Attachment #38744|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30227
Michel D?nzer changed:
What|Removed |Added
Attachment #38743|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=30180
--- Comment #3 from DH 2010-09-16 07:49:57 PDT ---
>From your Xorg.0.log:
(II) RADEON(0): Output DIN disconnected
(II) RADEON(0): Output VGA-0 disconnected
(II) RADEON(0): Output DP disconnected
(II) RADEON(0): Output DVI-0 connected
DIN: S-vide
https://bugs.freedesktop.org/show_bug.cgi?id=30180
--- Comment #3 from DH 2010-09-16 07:49:57 PDT ---
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #69 from Da Fox 2010-09-16 07:10:38 PDT
---
(In reply to comment #68)
> I have two questions:
>
> 1) Now since we established that the vmembase at zero patch fixes or works
> around the problem - while the patch to align vram from c
https://bugs.freedesktop.org/show_bug.cgi?id=28402
--- Comment #69 from Da Fox 2010-09-16 07:10:38
PDT ---
(In reply to comment #68)
> I have two questions:
>
> 1) Now since we established that the vmembase at zero patch fixes or works
> around the problem - while the patch to align vram from c
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #2 from DaNiMoTh 2010-09-16 06:17:19 PDT ---
Created an attachment (id=38744)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38744)
Xorg log after GPU lock
It re-happens, so I saved also Xorg.log.
--
Configure bugmail: https:
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #2 from DaNiMoTh 2010-09-16 06:17:19 PDT ---
Created an attachment (id=38744)
--> (https://bugs.freedesktop.org/attachment.cgi?id=38744)
Xorg log after GPU lock
It re-happens, so I saved also Xorg.log.
--
Configure bugmail: https:
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #1 from DaNiMoTh 2010-09-16 05:59:13 PDT ---
I forgot system spec:
Kernel: 2.6.35.4
X.org-server: 1.9.0
xf86-video-ati: 6.13.1
PowerPC 7447A, PowerBook G4.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=30227
--- Comment #1 from DaNiMoTh 2010-09-16 05:59:13 PDT ---
I forgot system spec:
Kernel: 2.6.35.4
X.org-server: 1.9.0
xf86-video-ati: 6.13.1
PowerPC 7447A, PowerBook G4.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=30227
Summary: Radom X.org freeze by a GPU lockup
Product: DRI
Version: XOrg CVS
Platform: PowerPC
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=30227
Summary: Radom X.org freeze by a GPU lockup
Product: DRI
Version: XOrg CVS
Platform: PowerPC
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=29901
--- Comment #10 from Marek Olšák 2010-09-16 03:01:08 PDT ---
We have 2 options for 7.9. Either I'll commit this patch but I must be sure
there are no regressions, or I'll revert all swtcl fixes and the Dave's commit
(in 7.9, not in master), and w
https://bugs.freedesktop.org/show_bug.cgi?id=29901
--- Comment #10 from Marek Ol??k 2010-09-16 03:01:08 PDT
---
We have 2 options for 7.9. Either I'll commit this patch but I must be sure
there are no regressions, or I'll revert all swtcl fixes and the Dave's commit
(in 7.9, not in master), and
59 matches
Mail list logo