2010-02-01 02:20:39

by Dave Airlie

Subject: [git pull] drm fixes

Hi Linus,

Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus

Major change is to move the radeon KMS enable out of staging and into
normal Kconfig land, its not perfect but its as good as userspace was for
most people.

others:
drm core: just a bogus comment removal
ttm: a few changes one fixes an error printf in reserve_ram_pages_type,
radeon: Displayport fixes, tested on all the displayport machines I own
(i.e. 2) but they both now work, r600 blit mutex, AGP warning fix.

vmwgfx: 3 patches for older version of vmware workstation, I think vmware
have one more patch but since this driver is staging it can wait until
merge window anyways.

Dave.

drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/radeon/atombios_dp.c | 27 ++---
drivers/gpu/drm/radeon/r600.c | 54 +++++-----
drivers/gpu/drm/radeon/r600_blit_kms.c | 7 +-
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_agp.c | 18 ++--
drivers/gpu/drm/radeon/radeon_encoders.c | 165 ++++++++++++++++-------------
drivers/gpu/drm/radeon/radeon_mode.h | 2 +-
drivers/gpu/drm/radeon/rv770.c | 31 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 9 +--
drivers/gpu/drm/ttm/ttm_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c | 23 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 +
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 19 ++++
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 ++
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++-
drivers/staging/Kconfig | 2 -
include/drm/drm_mode.h | 2 +-
20 files changed, 244 insertions(+), 164 deletions(-)

commit f71d0187987e691516cd10c2702f002c0e2f0edc
Author: Dave Airlie <[email protected]>
Date: Mon Feb 1 11:35:47 2010 +1000

drm/radeon/kms: move radeon KMS on/off switch out of staging.

We are happy enough that the KMS driver is stable enough for enough people
for the kms enable/disable to leave staging. Distros can now contemplate
turning this on.

Signed-off-by: Dave Airlie <[email protected]>

commit ff82f052d2a187dd0fa0e431ba70eb457c71a40e
Author: Jerome Glisse <[email protected]>
Date: Fri Jan 22 15:19:00 2010 +0100

drm/radeon/kms: Bailout of blit if error happen & protect with mutex V3

If an error happen in r600_blit_prepare_copy report it rather
than WARNING and keeping execution. For instance if ib allocation
failed we did just warn about but then latter tried to access
NULL ib ptr causing oops. This patch also protect r600_copy_blit
with a mutex as otherwise one process might overwrite blit temporary
data with new one possibly leading to GPU lockup.

Should partialy or totaly fix:
https://bugzilla.redhat.com/show_bug.cgi?id=553279

V2 failing blit initialization is not fatal, fallback to memcpy when
this happen
V3 init blit before startup as we pin in startup, remove duplicate
code (this one was actualy tested unlike V2)

Signed-off-by: Jerome Glisse <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit 5ffdb658f605cbc420944e7c7eeec9fbb8a73772
Author: Jakob Bornecrantz <[email protected]>
Date: Sat Jan 30 03:38:08 2010 +0000

drm/vmwgfx: Don't send bad flags to the host

Signed-off-by: Jakob Bornecrantz <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit c188660f6dbb0df9febe1b841a16c66c28353c15
Author: Peter Hanzel <[email protected]>
Date: Sat Jan 30 03:38:07 2010 +0000

drm/vmwgfx: Request SVGA version 2 and bail if not found

This fixes the driver not loading on older versions of VMware.

Signed-off-by: Peter Hanzel <[email protected]>
Signed-off-by: Jakob Bornecrantz <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit 8e19a951774a16cf2626292ae06fd2b62630e67e
Author: Jakob Bornecrantz <[email protected]>
Date: Sat Jan 30 03:38:06 2010 +0000

drm/vmwgfx: Correctly detect 3D

Signed-off-by: Jakob Bornecrantz <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit 110b20c3ddcfa98cc932aef3af2d59b4e0841f08
Author: Austin Yuan <[email protected]>
Date: Thu Jan 21 13:45:40 2010 +0800

drm/ttm: remove unnecessary save_flags and ttm_flag_masked in ttm_bo_util.c

Signed-off-by: Austin Yuan <[email protected]>
Acked-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit fa5829b36539067f3c675f5d437531dedcfc4ad8
Author: Marcin Kościelnicki <[email protected]>
Date: Sat Jan 23 10:25:28 2010 +1000

drm/kms: Remove incorrect comment in struct drm_mode_modeinfo

Signed-off-by: Dave Airlie <[email protected]>

commit dd5fde6041d7ea30fcfedcc159a4cec8b01f73b2
Author: Richard Kennedy <[email protected]>
Date: Tue Jan 26 17:10:48 2010 +0000

drm/ttm: remove padding from ttm_ref_object on 64bit builds

Re-order structure ttm_ref_object to remove 8 bytes of alignment padding
on 64 bit builds, so shrinking its size from 72 to 64 bytes allowing it
to fit into a smaller slab.

Signed-off-by: Richard Kennedy <[email protected]>
Acked-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit 4b866288be6ffaefaad9cec212cb09e3258a68ee
Author: Dave Airlie <[email protected]>
Date: Mon Feb 1 11:22:10 2010 +1000

drm/radeon/kms: release agp on error.

if we get an error, release the AGP if we've acquired it already.

Signed-off-by: Dave Airlie <[email protected]>

commit 2dea2e29b9fad48c759aa406b5ea426bff4339af
Author: John Kacur <[email protected]>
Date: Sun Jan 31 20:38:03 2010 +0100

drm/kms/radeon/agp: Move the check of the aper_size after drm_acp_acquire and drm_agp_info

First call drm_agp_acquire to check if agp has been acquired.
Second call drm_agp_info to fill in the info data struct, including aper_size.
Finally do the check to see if the aper_size makes sense.

Signed-off-by: John Kacur <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit cdb6e375c3c84558ed2c13c5461b22e8f7b7980e
Author: John Kacur <[email protected]>
Date: Sun Jan 31 20:38:02 2010 +0100

drm/kms/radeon/agp: Fix warning, format ‘%d’ expects type ‘int’, but argument 4 has type ‘size_t’

- Fix warning by using %zu instead of %d for size_t
- Fix spelling mistake, "to" should be "too".

Signed-off-by: John Kacur <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit db78e27de7e29a6db6be7caf607cf803d84094aa
Author: Francisco Jerez <[email protected]>
Date: Tue Jan 12 18:49:43 2010 +0100

drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching.

Fixes errors like:
> reserve_ram_pages_type failed 0x15b7a000-0x15b7b000, track 0x8, req 0x10
when a BO is moved between WC and UC areas.

Reported-by: Xavier Chantry <[email protected]>
Signed-off-by: Francisco Jerez <[email protected]>
Acked-by: Thomas Hellstrom <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

commit f28cf33945cc112f8ee835512b7440905dc29ad2
Author: Dave Airlie <[email protected]>
Date: Thu Jan 28 17:15:25 2010 +1000

drm/kms/radeon: pick digitial encoders smarter. (v3)

booting a Lenovo W500 with LVDS + DP outputs showed up a TODO we had
on our list, to pick a correct digital encoder block. The LVTMA
encoder requires the second digital encoder, all others can use any
encoder at all.

This fixes the digital encoder selection logic to enable LVDS/DP combos
to work okay.

V2: fix silly addition of connector dig_block and cleanup the other
places in the code that pick the encoder.

V3: rename to dig_encoder and clean up further - also fix
the picking algorithm.

tested on Lenovo W500 + desktop 3650 cards.

Signed-off-by: Dave Airlie <[email protected]>

commit 43c33ed87d0f1b900a6a3014db556ecc7f4a989b
Author: Dave Airlie <[email protected]>
Date: Fri Jan 29 15:55:30 2010 +1000

drm/radeon/kms: use active device to pick connector for encoder

On the W500 we have UNIPHY routed to both DVI and DP, this seems
to always pick the DVI connector which means link training fails.

Switch to using active device to pick the connector, this seems
like it should be safe from a code review, and it fixes things
a bit more here.

Signed-off-by: Dave Airlie <[email protected]>

commit 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0
Author: Dave Airlie <[email protected]>
Date: Fri Jan 29 15:31:47 2010 +1000

drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.

This makes displayport work again here.

Signed-off-by: Dave Airlie <[email protected]>

2010-02-01 02:54:14

by Dave Airlie

Subject: Re: [git pull] drm fixes

> Hi Linus,
>
> Please pull the 'drm-linus' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>

I've also added an oops fix I seem to lose off my radar to this tree.

commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
Author: Michel Dänzer <[email protected]>
Date: Fri Jan 22 09:20:00 2010 +0100

drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.

If radeon_cs_parser_init() fails, radeon_cs_ioctl() calls
radeon_cs_parser_fini() with the non-zero error value. The latter
dereferenc
parser->ib which hasn't been initialized yet -> boom. Add a test for
parser-
being non-NULL before dereferencing it.

Signed-off-by: Michel Dänzer <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>


> Major change is to move the radeon KMS enable out of staging and into
> normal Kconfig land, its not perfect but its as good as userspace was for
> most people.
>
> others:
> drm core: just a bogus comment removal
> ttm: a few changes one fixes an error printf in reserve_ram_pages_type,
> radeon: Displayport fixes, tested on all the displayport machines I own
> (i.e. 2) but they both now work, r600 blit mutex, AGP warning fix.
>
> vmwgfx: 3 patches for older version of vmware workstation, I think vmware
> have one more patch but since this driver is staging it can wait until
> merge window anyways.
>
> Dave.
>
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/radeon/atombios_dp.c | 27 ++---
> drivers/gpu/drm/radeon/r600.c | 54 +++++-----
> drivers/gpu/drm/radeon/r600_blit_kms.c | 7 +-
> drivers/gpu/drm/radeon/radeon.h | 1 +
> drivers/gpu/drm/radeon/radeon_agp.c | 18 ++--
> drivers/gpu/drm/radeon/radeon_encoders.c | 165 ++++++++++++++++-------------
> drivers/gpu/drm/radeon/radeon_mode.h | 2 +-
> drivers/gpu/drm/radeon/rv770.c | 31 +++---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 9 +--
> drivers/gpu/drm/ttm/ttm_object.c | 2 +-
> drivers/gpu/drm/ttm/ttm_tt.c | 23 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 +
> drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 19 ++++
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++-
> drivers/staging/Kconfig | 2 -
> include/drm/drm_mode.h | 2 +-
> 20 files changed, 244 insertions(+), 164 deletions(-)
>
> commit f71d0187987e691516cd10c2702f002c0e2f0edc
> Author: Dave Airlie <[email protected]>
> Date: Mon Feb 1 11:35:47 2010 +1000
>
> drm/radeon/kms: move radeon KMS on/off switch out of staging.
>
> We are happy enough that the KMS driver is stable enough for enough people
> for the kms enable/disable to leave staging. Distros can now contemplate
> turning this on.
>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit ff82f052d2a187dd0fa0e431ba70eb457c71a40e
> Author: Jerome Glisse <[email protected]>
> Date: Fri Jan 22 15:19:00 2010 +0100
>
> drm/radeon/kms: Bailout of blit if error happen & protect with mutex V3
>
> If an error happen in r600_blit_prepare_copy report it rather
> than WARNING and keeping execution. For instance if ib allocation
> failed we did just warn about but then latter tried to access
> NULL ib ptr causing oops. This patch also protect r600_copy_blit
> with a mutex as otherwise one process might overwrite blit temporary
> data with new one possibly leading to GPU lockup.
>
> Should partialy or totaly fix:
> https://bugzilla.redhat.com/show_bug.cgi?id=553279
>
> V2 failing blit initialization is not fatal, fallback to memcpy when
> this happen
> V3 init blit before startup as we pin in startup, remove duplicate
> code (this one was actualy tested unlike V2)
>
> Signed-off-by: Jerome Glisse <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit 5ffdb658f605cbc420944e7c7eeec9fbb8a73772
> Author: Jakob Bornecrantz <[email protected]>
> Date: Sat Jan 30 03:38:08 2010 +0000
>
> drm/vmwgfx: Don't send bad flags to the host
>
> Signed-off-by: Jakob Bornecrantz <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit c188660f6dbb0df9febe1b841a16c66c28353c15
> Author: Peter Hanzel <[email protected]>
> Date: Sat Jan 30 03:38:07 2010 +0000
>
> drm/vmwgfx: Request SVGA version 2 and bail if not found
>
> This fixes the driver not loading on older versions of VMware.
>
> Signed-off-by: Peter Hanzel <[email protected]>
> Signed-off-by: Jakob Bornecrantz <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit 8e19a951774a16cf2626292ae06fd2b62630e67e
> Author: Jakob Bornecrantz <[email protected]>
> Date: Sat Jan 30 03:38:06 2010 +0000
>
> drm/vmwgfx: Correctly detect 3D
>
> Signed-off-by: Jakob Bornecrantz <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit 110b20c3ddcfa98cc932aef3af2d59b4e0841f08
> Author: Austin Yuan <[email protected]>
> Date: Thu Jan 21 13:45:40 2010 +0800
>
> drm/ttm: remove unnecessary save_flags and ttm_flag_masked in ttm_bo_util.c
>
> Signed-off-by: Austin Yuan <[email protected]>
> Acked-by: Thomas Hellstrom <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit fa5829b36539067f3c675f5d437531dedcfc4ad8
> Author: Marcin Kościelnicki <[email protected]>
> Date: Sat Jan 23 10:25:28 2010 +1000
>
> drm/kms: Remove incorrect comment in struct drm_mode_modeinfo
>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit dd5fde6041d7ea30fcfedcc159a4cec8b01f73b2
> Author: Richard Kennedy <[email protected]>
> Date: Tue Jan 26 17:10:48 2010 +0000
>
> drm/ttm: remove padding from ttm_ref_object on 64bit builds
>
> Re-order structure ttm_ref_object to remove 8 bytes of alignment padding
> on 64 bit builds, so shrinking its size from 72 to 64 bytes allowing it
> to fit into a smaller slab.
>
> Signed-off-by: Richard Kennedy <[email protected]>
> Acked-by: Thomas Hellstrom <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit 4b866288be6ffaefaad9cec212cb09e3258a68ee
> Author: Dave Airlie <[email protected]>
> Date: Mon Feb 1 11:22:10 2010 +1000
>
> drm/radeon/kms: release agp on error.
>
> if we get an error, release the AGP if we've acquired it already.
>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit 2dea2e29b9fad48c759aa406b5ea426bff4339af
> Author: John Kacur <[email protected]>
> Date: Sun Jan 31 20:38:03 2010 +0100
>
> drm/kms/radeon/agp: Move the check of the aper_size after drm_acp_acquire and drm_agp_info
>
> First call drm_agp_acquire to check if agp has been acquired.
> Second call drm_agp_info to fill in the info data struct, including aper_size.
> Finally do the check to see if the aper_size makes sense.
>
> Signed-off-by: John Kacur <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit cdb6e375c3c84558ed2c13c5461b22e8f7b7980e
> Author: John Kacur <[email protected]>
> Date: Sun Jan 31 20:38:02 2010 +0100
>
> drm/kms/radeon/agp: Fix warning, format ‘%d’ expects type ‘int’, but argument 4 has type ‘size_t’
>
> - Fix warning by using %zu instead of %d for size_t
> - Fix spelling mistake, "to" should be "too".
>
> Signed-off-by: John Kacur <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit db78e27de7e29a6db6be7caf607cf803d84094aa
> Author: Francisco Jerez <[email protected]>
> Date: Tue Jan 12 18:49:43 2010 +0100
>
> drm/ttm: Avoid conflicting reserve_memtype during ttm_tt_set_page_caching.
>
> Fixes errors like:
> > reserve_ram_pages_type failed 0x15b7a000-0x15b7b000, track 0x8, req 0x10
> when a BO is moved between WC and UC areas.
>
> Reported-by: Xavier Chantry <[email protected]>
> Signed-off-by: Francisco Jerez <[email protected]>
> Acked-by: Thomas Hellstrom <[email protected]>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit f28cf33945cc112f8ee835512b7440905dc29ad2
> Author: Dave Airlie <[email protected]>
> Date: Thu Jan 28 17:15:25 2010 +1000
>
> drm/kms/radeon: pick digitial encoders smarter. (v3)
>
> booting a Lenovo W500 with LVDS + DP outputs showed up a TODO we had
> on our list, to pick a correct digital encoder block. The LVTMA
> encoder requires the second digital encoder, all others can use any
> encoder at all.
>
> This fixes the digital encoder selection logic to enable LVDS/DP combos
> to work okay.
>
> V2: fix silly addition of connector dig_block and cleanup the other
> places in the code that pick the encoder.
>
> V3: rename to dig_encoder and clean up further - also fix
> the picking algorithm.
>
> tested on Lenovo W500 + desktop 3650 cards.
>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit 43c33ed87d0f1b900a6a3014db556ecc7f4a989b
> Author: Dave Airlie <[email protected]>
> Date: Fri Jan 29 15:55:30 2010 +1000
>
> drm/radeon/kms: use active device to pick connector for encoder
>
> On the W500 we have UNIPHY routed to both DVI and DP, this seems
> to always pick the DVI connector which means link training fails.
>
> Switch to using active device to pick the connector, this seems
> like it should be safe from a code review, and it fixes things
> a bit more here.
>
> Signed-off-by: Dave Airlie <[email protected]>
>
> commit 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0
> Author: Dave Airlie <[email protected]>
> Date: Fri Jan 29 15:31:47 2010 +1000
>
> drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.
>
> This makes displayport work again here.
>
> Signed-off-by: Dave Airlie <[email protected]>

2010-02-02 08:17:54

by Ingo Molnar

Subject: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> > Hi Linus,
> >
> > Please pull the 'drm-linus' branch from
> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> >
>
> I've also added an oops fix I seem to lose off my radar to this tree.
>
> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> Author: Michel D??nzer <[email protected]>
> Date: Fri Jan 22 09:20:00 2010 +0100
>
> drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.

FYI, this drm pull into mainline has triggered quick boot crashes in -tip
testing (even with the above fix applied), on an Athlon64 whitebox PC with:

01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]

the crash is:

[ 7.111003] radeon 0000:01:00.0: Disabling GPU acceleration
[ 7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen.
[ 7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
[ 7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen.
[ 7.599306] BUG: unable to handle kernel paging request at f8380000
[ 7.599999] IP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c
[ 7.599999] *pde = 36d44067 *pte = 00000000
[ 7.599999] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[ 7.599999] last sysfs file:

i have bisected it back to:

| 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0 is the first bad commit
| commit 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0
| Author: Dave Airlie <[email protected]>
| Date: Fri Jan 29 15:31:47 2010 +1000
|
| drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.
|
| This makes displayport work again here.

Unfortunately even with that patch reverted it still crashes. Config and
bootlog attached.

It's the moving of radeom KMS out of staging after -rc6 that causes it,
because it brought it into the scope of my testing:

f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.

So at least on this box it's clearly not ready for mainline enablement yet.
I've attached the revert patch further below.

Ingo

-------------------->
[ 6.864061] IOAPIC[0]: Set routing entry (2-5 -> 0x35 -> IRQ 5 Mode:1 Active:1)
[ 6.871010] radeon 0000:01:00.0: PCI->APIC IRQ transform: INT A -> IRQ 5
[ 6.878014] radeon 0000:01:00.0: setting latency timer to 64
[ 6.885950] device: 'controlD64': device_add
[ 6.890221] device: 'card0': device_add
[ 6.894100] [drm] radeon: Initializing kernel modesetting.
[ 6.900042] radeon 0000:01:00.0: using 40bit DMA mask
[ 6.905018] [drm] register mmio base: 0xD9000000
[ 6.910004] [drm] register mmio size: 65536
[ 6.916147] [drm] GPU reset succeed (RBBM_STATUS=0x00000140)
[ 6.917049] [drm] Generation 2 PCI interface, using max accessible memory
[ 6.918004] [drm] radeon: VRAM 128M
[ 6.919003] [drm] radeon: VRAM from 0x00000000 to 0x07FFFFFF
[ 6.920005] [drm] radeon: GTT 512M
[ 6.921003] [drm] radeon: GTT from 0x20000000 to 0x3FFFFFFF
[ 6.922241] alloc irq_desc for 24 on node -1
[ 6.922999] alloc kstat_irqs on node -1
[ 6.923036] radeon 0000:01:00.0: irq 24 for MSI/MSI-X
[ 6.924028] [drm] radeon: using MSI.
[ 6.925133] [drm] radeon: irq initialized.
[ 6.926009] [drm] Detected VRAM RAM=128M, BAR=128M
[ 6.927003] [drm] RAM width 64bits DDR
[ 6.929249] [TTM] Zone kernel: Available graphics memory: 434560 kiB.
[ 6.930010] [TTM] Zone highmem: Available graphics memory: 506212 kiB.
[ 6.931200] [drm] radeon: 128M of VRAM memory ready
[ 6.932005] [drm] radeon: 512M of GTT memory ready.
[ 6.933094] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 6.935508] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
[ 6.936033] [drm] PCIE GART of 512M enabled (table at 0x00040000).
[ 6.937068] [drm] radeon: cp idle (0x10000C03)
[ 6.938011] Registering platform device 'radeon_cp.0'. Parent at platform
[ 6.939005] device: 'radeon_cp.0': device_add
[ 6.940018] bus: 'platform': add device radeon_cp.0
[ 6.941122] [drm] Loading R300 Microcode
[ 6.942009] platform radeon_cp.0: firmware: using built-in firmware radeon/R300_cp.bin
[ 6.943023] bus: 'platform': remove device radeon_cp.0
[ 6.945161] [drm] radeon: ring at 0x0000000020000000
[ 7.108115] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
[ 7.109004] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[ 7.110003] radeon 0000:01:00.0: failled initializing CP (-22).
[ 7.111003] radeon 0000:01:00.0: Disabling GPU acceleration
[ 7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen.
[ 7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
[ 7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen.
[ 7.599306] BUG: unable to handle kernel paging request at f8380000
[ 7.599999] IP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c
[ 7.599999] *pde = 36d44067 *pte = 00000000
[ 7.599999] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[ 7.599999] last sysfs file:
[ 7.599999]
[ 7.599999] Pid: 1, comm: swapper Not tainted 2.6.33-rc6-00066-g9ce9290-dirty #14391 A8N-E/System Product Name
[ 7.599999] EIP: 0060:[<c149f0de>] EFLAGS: 00010206 CPU: 0
[ 7.599999] EIP is at rv370_pcie_gart_set_page+0x2d/0x3c
[ 7.599999] EAX: 0000000c EBX: 00000000 ECX: f8380000 EDX: f8380000
[ 7.599999] ESI: 00000000 EDI: 00000001 EBP: f6c33d68 ESP: f6c33d60
[ 7.599999] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 7.599999] Process swapper (pid: 1, ti=f6c32000 task=f6c30000 task.ti=f6c32000)
[ 7.599999] Stack:
[ 7.599999] f6a1f004 00000000 f6c33d90 c14899fb 00000000 00000000 00000100 00000000
[ 7.599999] <0> 00000000 f6a06538 00000000 00000002 f6c33d9c c1488467 f6a06500 f6c33da8
[ 7.599999] <0> c14628ad f6a12af0 f6c33dd0 c146413a 00000000 c20d0d00 f6a1f364 f6a1f364
[ 7.599999] Call Trace:
[ 7.599999] [<c14899fb>] ? radeon_gart_unbind+0xb7/0xdf
[ 7.599999] [<c1488467>] ? radeon_ttm_backend_unbind+0x14/0x1d
[ 7.599999] [<c14628ad>] ? ttm_tt_unbind+0x15/0x27
[ 7.599999] [<c146413a>] ? ttm_bo_cleanup_refs+0xe0/0x1e8
[ 7.599999] [<c1465717>] ? ttm_bo_release+0x4c/0x65
[ 7.599999] [<c14656cb>] ? ttm_bo_release+0x0/0x65
[ 7.599999] [<c13bbda5>] ? kref_put+0x39/0x42
[ 7.599999] [<c1464357>] ? ttm_bo_unref+0x27/0x32
[ 7.599999] [<c148947f>] ? radeon_bo_unref+0x1d/0x2d
[ 7.599999] [<c1495fd6>] ? radeon_ring_fini+0x55/0x74
[ 7.599999] [<c149d70d>] ? r100_cp_fini+0x5d/0x82
[ 7.599999] [<c14a1a03>] ? r300_init+0x1c5/0x20f
[ 7.599999] [<c147d680>] ? radeon_device_init+0x227/0x29f
[ 7.599999] [<c147df0a>] ? radeon_driver_load_kms+0x9d/0xff
[ 7.599999] [<c145aa62>] ? drm_get_dev+0x28a/0x364
[ 7.599999] [<c1aabbe0>] ? radeon_pci_probe+0xd/0xf
[ 7.599999] [<c13dc6a6>] ? local_pci_probe+0xe/0x10
[ 7.599999] [<c13dc86f>] ? pci_device_probe+0x43/0x66
[ 7.599999] [<c14cdaf8>] ? driver_probe_device+0xae/0x13e
[ 7.599999] [<c14cdbcb>] ? __driver_attach+0x43/0x5f
[ 7.599999] [<c14cd46e>] ? bus_for_each_dev+0x3d/0x67
[ 7.599999] [<c14cd954>] ? driver_attach+0x14/0x16
[ 7.599999] [<c14cdb88>] ? __driver_attach+0x0/0x5f
[ 7.599999] [<c14cceb7>] ? bus_add_driver+0xab/0x1d1
[ 7.599999] [<c14cddf7>] ? driver_register+0x79/0xe0
[ 7.599999] [<c13ced32>] ? __raw_spin_lock_init+0x28/0x4e
[ 7.599999] [<c13dca4a>] ? __pci_register_driver+0x4c/0xa9
[ 7.599999] [<c14570ad>] ? drm_init+0x5a/0xb2
[ 7.599999] [<c217d557>] ? radeon_init+0x0/0xae
[ 7.599999] [<c217d603>] ? radeon_init+0xac/0xae
[ 7.599999] [<c1001051>] ? do_one_initcall+0x4c/0x159
[ 7.599999] [<c215830a>] ? kernel_init+0x112/0x163
[ 7.599999] [<c21581f8>] ? kernel_init+0x0/0x163
[ 7.599999] [<c10210ba>] ? kernel_thread_helper+0x6/0x10
[ 7.599999] Code: d2 89 e5 56 8b 75 08 53 8b 5d 0c 8b 88 48 02 00 00 78 1e 3b 90 38 02 00 00 77 16 89 f0 c1 e8 08 83 c8 0c c1 e3 18 09 d8 8d 14 91 <89> 02 31 c0 eb 05 b8 ea ff ff ff 5b 5e 5d c3 83 78 50 09 55 89
[ 7.599999] EIP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c SS:ESP 0068:f6c33d60
[ 7.599999] CR2: 00000000f8380000
[ 7.599999] ---[ end trace 012a361324455360 ]---
[ 7.599999] Kernel panic - not syncing: Fatal exception
[ 7.599999] Pid: 1, comm: swapper Tainted: G D 2.6.33-rc6-00066-g9ce9290-dirty #14391

>From 2f73a756d3603067c0dc618683f8515ef2fbae34 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Tue, 2 Feb 2010 09:06:04 +0100
Subject: [PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

This reverts commit f71d0187987e691516cd10c2702f002c0e2f0edc.

Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/gpu/drm/Kconfig | 2 --
drivers/staging/Kconfig | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 305c590..96eddd1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -66,8 +66,6 @@ config DRM_RADEON

If M is selected, the module will be called radeon.

-source "drivers/gpu/drm/radeon/Kconfig"
-
config DRM_I810
tristate "Intel I810"
depends on DRM && AGP && AGP_INTEL
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index fc2e963..94eb863 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -99,6 +99,8 @@ source "drivers/staging/line6/Kconfig"

source "drivers/gpu/drm/vmwgfx/Kconfig"

+source "drivers/gpu/drm/radeon/Kconfig"
+
source "drivers/gpu/drm/nouveau/Kconfig"

source "drivers/staging/octeon/Kconfig"

Attachments:

2010-02-02 08:26:08

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

>
>
> It's the moving of radeom KMS out of staging after -rc6 that causes it,
> because it brought it into the scope of my testing:
>
> f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
>
> So at least on this box it's clearly not ready for mainline enablement yet.
> I've attached the revert patch further below.
>

Its not enabled by default so reverting this doesn't make much sense.

We can just treat this as a normal driver bugreport.

Dave.

> Ingo
>
> -------------------->
> [ 6.864061] IOAPIC[0]: Set routing entry (2-5 -> 0x35 -> IRQ 5 Mode:1 Active:1)
> [ 6.871010] radeon 0000:01:00.0: PCI->APIC IRQ transform: INT A -> IRQ 5
> [ 6.878014] radeon 0000:01:00.0: setting latency timer to 64
> [ 6.885950] device: 'controlD64': device_add
> [ 6.890221] device: 'card0': device_add
> [ 6.894100] [drm] radeon: Initializing kernel modesetting.
> [ 6.900042] radeon 0000:01:00.0: using 40bit DMA mask
> [ 6.905018] [drm] register mmio base: 0xD9000000
> [ 6.910004] [drm] register mmio size: 65536
> [ 6.916147] [drm] GPU reset succeed (RBBM_STATUS=0x00000140)
> [ 6.917049] [drm] Generation 2 PCI interface, using max accessible memory
> [ 6.918004] [drm] radeon: VRAM 128M
> [ 6.919003] [drm] radeon: VRAM from 0x00000000 to 0x07FFFFFF
> [ 6.920005] [drm] radeon: GTT 512M
> [ 6.921003] [drm] radeon: GTT from 0x20000000 to 0x3FFFFFFF
> [ 6.922241] alloc irq_desc for 24 on node -1
> [ 6.922999] alloc kstat_irqs on node -1
> [ 6.923036] radeon 0000:01:00.0: irq 24 for MSI/MSI-X
> [ 6.924028] [drm] radeon: using MSI.
> [ 6.925133] [drm] radeon: irq initialized.
> [ 6.926009] [drm] Detected VRAM RAM=128M, BAR=128M
> [ 6.927003] [drm] RAM width 64bits DDR
> [ 6.929249] [TTM] Zone kernel: Available graphics memory: 434560 kiB.
> [ 6.930010] [TTM] Zone highmem: Available graphics memory: 506212 kiB.
> [ 6.931200] [drm] radeon: 128M of VRAM memory ready
> [ 6.932005] [drm] radeon: 512M of GTT memory ready.
> [ 6.933094] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [ 6.935508] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
> [ 6.936033] [drm] PCIE GART of 512M enabled (table at 0x00040000).
> [ 6.937068] [drm] radeon: cp idle (0x10000C03)
> [ 6.938011] Registering platform device 'radeon_cp.0'. Parent at platform
> [ 6.939005] device: 'radeon_cp.0': device_add
> [ 6.940018] bus: 'platform': add device radeon_cp.0
> [ 6.941122] [drm] Loading R300 Microcode
> [ 6.942009] platform radeon_cp.0: firmware: using built-in firmware radeon/R300_cp.bin
> [ 6.943023] bus: 'platform': remove device radeon_cp.0
> [ 6.945161] [drm] radeon: ring at 0x0000000020000000
> [ 7.108115] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
> [ 7.109004] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> [ 7.110003] radeon 0000:01:00.0: failled initializing CP (-22).
> [ 7.111003] radeon 0000:01:00.0: Disabling GPU acceleration
> [ 7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen.
> [ 7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
> [ 7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen.
> [ 7.599306] BUG: unable to handle kernel paging request at f8380000
> [ 7.599999] IP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c
> [ 7.599999] *pde = 36d44067 *pte = 00000000
> [ 7.599999] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
> [ 7.599999] last sysfs file:
> [ 7.599999]
> [ 7.599999] Pid: 1, comm: swapper Not tainted 2.6.33-rc6-00066-g9ce9290-dirty #14391 A8N-E/System Product Name
> [ 7.599999] EIP: 0060:[<c149f0de>] EFLAGS: 00010206 CPU: 0
> [ 7.599999] EIP is at rv370_pcie_gart_set_page+0x2d/0x3c
> [ 7.599999] EAX: 0000000c EBX: 00000000 ECX: f8380000 EDX: f8380000
> [ 7.599999] ESI: 00000000 EDI: 00000001 EBP: f6c33d68 ESP: f6c33d60
> [ 7.599999] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> [ 7.599999] Process swapper (pid: 1, ti=f6c32000 task=f6c30000 task.ti=f6c32000)
> [ 7.599999] Stack:
> [ 7.599999] f6a1f004 00000000 f6c33d90 c14899fb 00000000 00000000 00000100 00000000
> [ 7.599999] <0> 00000000 f6a06538 00000000 00000002 f6c33d9c c1488467 f6a06500 f6c33da8
> [ 7.599999] <0> c14628ad f6a12af0 f6c33dd0 c146413a 00000000 c20d0d00 f6a1f364 f6a1f364
> [ 7.599999] Call Trace:
> [ 7.599999] [<c14899fb>] ? radeon_gart_unbind+0xb7/0xdf
> [ 7.599999] [<c1488467>] ? radeon_ttm_backend_unbind+0x14/0x1d
> [ 7.599999] [<c14628ad>] ? ttm_tt_unbind+0x15/0x27
> [ 7.599999] [<c146413a>] ? ttm_bo_cleanup_refs+0xe0/0x1e8
> [ 7.599999] [<c1465717>] ? ttm_bo_release+0x4c/0x65
> [ 7.599999] [<c14656cb>] ? ttm_bo_release+0x0/0x65
> [ 7.599999] [<c13bbda5>] ? kref_put+0x39/0x42
> [ 7.599999] [<c1464357>] ? ttm_bo_unref+0x27/0x32
> [ 7.599999] [<c148947f>] ? radeon_bo_unref+0x1d/0x2d
> [ 7.599999] [<c1495fd6>] ? radeon_ring_fini+0x55/0x74
> [ 7.599999] [<c149d70d>] ? r100_cp_fini+0x5d/0x82
> [ 7.599999] [<c14a1a03>] ? r300_init+0x1c5/0x20f
> [ 7.599999] [<c147d680>] ? radeon_device_init+0x227/0x29f
> [ 7.599999] [<c147df0a>] ? radeon_driver_load_kms+0x9d/0xff
> [ 7.599999] [<c145aa62>] ? drm_get_dev+0x28a/0x364
> [ 7.599999] [<c1aabbe0>] ? radeon_pci_probe+0xd/0xf
> [ 7.599999] [<c13dc6a6>] ? local_pci_probe+0xe/0x10
> [ 7.599999] [<c13dc86f>] ? pci_device_probe+0x43/0x66
> [ 7.599999] [<c14cdaf8>] ? driver_probe_device+0xae/0x13e
> [ 7.599999] [<c14cdbcb>] ? __driver_attach+0x43/0x5f
> [ 7.599999] [<c14cd46e>] ? bus_for_each_dev+0x3d/0x67
> [ 7.599999] [<c14cd954>] ? driver_attach+0x14/0x16
> [ 7.599999] [<c14cdb88>] ? __driver_attach+0x0/0x5f
> [ 7.599999] [<c14cceb7>] ? bus_add_driver+0xab/0x1d1
> [ 7.599999] [<c14cddf7>] ? driver_register+0x79/0xe0
> [ 7.599999] [<c13ced32>] ? __raw_spin_lock_init+0x28/0x4e
> [ 7.599999] [<c13dca4a>] ? __pci_register_driver+0x4c/0xa9
> [ 7.599999] [<c14570ad>] ? drm_init+0x5a/0xb2
> [ 7.599999] [<c217d557>] ? radeon_init+0x0/0xae
> [ 7.599999] [<c217d603>] ? radeon_init+0xac/0xae
> [ 7.599999] [<c1001051>] ? do_one_initcall+0x4c/0x159
> [ 7.599999] [<c215830a>] ? kernel_init+0x112/0x163
> [ 7.599999] [<c21581f8>] ? kernel_init+0x0/0x163
> [ 7.599999] [<c10210ba>] ? kernel_thread_helper+0x6/0x10
> [ 7.599999] Code: d2 89 e5 56 8b 75 08 53 8b 5d 0c 8b 88 48 02 00 00 78 1e 3b 90 38 02 00 00 77 16 89 f0 c1 e8 08 83 c8 0c c1 e3 18 09 d8 8d 14 91 <89> 02 31 c0 eb 05 b8 ea ff ff ff 5b 5e 5d c3 83 78 50 09 55 89
> [ 7.599999] EIP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c SS:ESP 0068:f6c33d60
> [ 7.599999] CR2: 00000000f8380000
> [ 7.599999] ---[ end trace 012a361324455360 ]---
> [ 7.599999] Kernel panic - not syncing: Fatal exception
> [ 7.599999] Pid: 1, comm: swapper Tainted: G D 2.6.33-rc6-00066-g9ce9290-dirty #14391
>
> >From 2f73a756d3603067c0dc618683f8515ef2fbae34 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <[email protected]>
> Date: Tue, 2 Feb 2010 09:06:04 +0100
> Subject: [PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."
>
> This reverts commit f71d0187987e691516cd10c2702f002c0e2f0edc.
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> drivers/gpu/drm/Kconfig | 2 --
> drivers/staging/Kconfig | 2 ++
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 305c590..96eddd1 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -66,8 +66,6 @@ config DRM_RADEON
>
> If M is selected, the module will be called radeon.
>
> -source "drivers/gpu/drm/radeon/Kconfig"
> -
> config DRM_I810
> tristate "Intel I810"
> depends on DRM && AGP && AGP_INTEL
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index fc2e963..94eb863 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -99,6 +99,8 @@ source "drivers/staging/line6/Kconfig"
>
> source "drivers/gpu/drm/vmwgfx/Kconfig"
>
> +source "drivers/gpu/drm/radeon/Kconfig"
> +
> source "drivers/gpu/drm/nouveau/Kconfig"
>
> source "drivers/staging/octeon/Kconfig"
>

2010-02-02 08:35:51

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
>> > Hi Linus,
>> >
>> > Please pull the 'drm-linus' branch from
>> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>> >
>>
>> I've also added an oops fix I seem to lose off my radar to this tree.
>>
>> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
>> Author: Michel D??nzer <[email protected]>
>> Date: ? Fri Jan 22 09:20:00 2010 +0100
>>
>> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
>

Wierd this suggests something else is wrong on that machine can you get me
the whole dmesg? I'm guessing some iommu or swiotlb issue.

I've asked Jerome to fix the oops, but really anyone with an old
.config won't get
hit by this, and we've booted this on quite a lot of machines at this point.

Dave.

2010-02-02 08:37:41

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Tue, Feb 2, 2010 at 6:35 PM, Dave Airlie <[email protected]> wrote:
> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
>>
>> * Dave Airlie <[email protected]> wrote:
>>
>>> > Hi Linus,
>>> >
>>> > Please pull the 'drm-linus' branch from
>>> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>>> >
>>>
>>> I've also added an oops fix I seem to lose off my radar to this tree.
>>>
>>> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
>>> Author: Michel D??nzer <[email protected]>
>>> Date: ? Fri Jan 22 09:20:00 2010 +0100
>>>
>>> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
>>
>
> Wierd this suggests something else is wrong on that machine can you get me
> the whole dmesg? I'm guessing some iommu or swiotlb issue.
>
> I've asked Jerome to fix the oops, but really anyone with an old
> .config won't get
> hit by this, and we've booted this on quite a lot of machines at this point.
>

Ideas keep flooding in here, did you softboot from the old UMS driver? or
coldboot? does coldbooting help?

Dave.

2010-02-02 08:58:29

by Domenico Andreoli

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Tue, Feb 02, 2010 at 09:17:27AM +0100, Ingo Molnar wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
> > > Hi Linus,
> > >
> > > Please pull the 'drm-linus' branch from
> > > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> > >
>
> FYI, this drm pull into mainline has triggered quick boot crashes in -tip
> testing (even with the above fix applied), on an Athlon64 whitebox PC with:

boot broke also here where unfortunately i have not a serial line
to see what's happening. anyway disabling KMS restores a working
2.6.33-rc6-00072-gab65832 kernel. here is the broken config.

in the next days i should be able to test it with a RV770.

> 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
> 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]

01:00.0 VGA compatible controller: ATI Technologies Inc RV515 [Radeon X1300]
01:00.1 Display controller: ATI Technologies Inc RV515 [Radeon X1300] (Secondary)


#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.33-rc6
# Mon Feb 1 23:08:06 2010
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_TINY_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
# CONFIG_CGROUPS is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_EVENT_PROFILE is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_OPROFILE=m
# CONFIG_OPROFILE_IBS is not set
# CONFIG_OPROFILE_EVENT_MULTIPLEX is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_SLOW_WORK is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
# CONFIG_INLINE_SPIN_UNLOCK is not set
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
# CONFIG_INLINE_READ_UNLOCK is not set
# CONFIG_INLINE_READ_UNLOCK_BH is not set
# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
# CONFIG_INLINE_WRITE_UNLOCK is not set
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
# CONFIG_SPARSE_IRQ is not set
# CONFIG_X86_MPPARSE is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_MATOM is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_P6_NOP=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=4
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
# CONFIG_NUMA is not set
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
# CONFIG_PM_RUNTIME is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_POWER_METER is not set
CONFIG_ACPI_SYSFS_POWER=y
# CONFIG_ACPI_PROC_EVENT is not set
CONFIG_ACPI_AC=y
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
# CONFIG_INTR_REMAP is not set
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_PCI_IOAPIC=y
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_ATA_VERBOSE_ERROR is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_PMP is not set
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
CONFIG_PATA_JMICRON=y
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_SCH is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# You can enable one or both FireWire driver stacks.
#

#
# The newer stack is recommended.
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
CONFIG_SKY2=y
# CONFIG_SKY2_DEBUG is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=y
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO expanders:
#

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_ADP5588 is not set

#
# PCI GPIO expanders:
#
# CONFIG_GPIO_CS5535 is not set
# CONFIG_GPIO_LANGWELL is not set

#
# SPI GPIO expanders:
#

#
# AC97 GPIO expanders:
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_CORETEMP=y
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_LIS3_I2C is not set
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
CONFIG_SENSORS_ATK0110=y
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TPS65010 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_AB3100_CORE is not set
# CONFIG_MFD_88PM8607 is not set
# CONFIG_REGULATOR is not set
CONFIG_MEDIA_SUPPORT=y

#
# Multimedia core support
#
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2_COMMON=y
# CONFIG_VIDEO_ALLOW_V4L1 is not set
CONFIG_VIDEO_V4L1_COMPAT=y
# CONFIG_DVB_CORE is not set
CONFIG_VIDEO_MEDIA=y

#
# Multimedia drivers
#
CONFIG_IR_CORE=y
CONFIG_VIDEO_IR=y
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=y
# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
CONFIG_MEDIA_TUNER_SIMPLE=y
CONFIG_MEDIA_TUNER_TDA8290=y
CONFIG_MEDIA_TUNER_TDA9887=y
CONFIG_MEDIA_TUNER_TEA5761=y
CONFIG_MEDIA_TUNER_TEA5767=y
CONFIG_MEDIA_TUNER_MT20XX=y
CONFIG_MEDIA_TUNER_XC2028=y
CONFIG_MEDIA_TUNER_XC5000=y
CONFIG_MEDIA_TUNER_MC44S803=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_IR_I2C=y
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_SAA6588=m
CONFIG_VIDEO_MT9V011=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VIVI=m
CONFIG_VIDEO_BT848=m
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_IVTV is not set
# CONFIG_VIDEO_CAFE_CCIC is not set
# CONFIG_SOC_CAMERA is not set
CONFIG_V4L_USB_DRIVERS=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
# CONFIG_USB_GSPCA is not set
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_HDPVR is not set
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_EM28XX_ALSA=m
# CONFIG_VIDEO_CX231XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC_INPUT_EVDEV is not set
# CONFIG_USB_ZR364XX is not set
# CONFIG_USB_STKWEBCAM is not set
# CONFIG_USB_S2255 is not set
# CONFIG_RADIO_ADAPTERS is not set
# CONFIG_DAB is not set

#
# Graphics support
#
# CONFIG_AGP is not set
CONFIG_VGA_ARB=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_TTM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=y
CONFIG_DRM_RADEON_KMS=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
CONFIG_SOUND=y
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_HRTIMER is not set
CONFIG_SND_RTCTIMER=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
# CONFIG_SND_DRIVERS is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
# CONFIG_SND_HDA_HWDEP is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
# CONFIG_SND_HDA_INPUT_JACK is not set
# CONFIG_SND_HDA_PATCH_LOADER is not set
# CONFIG_SND_HDA_CODEC_REALTEK is not set
CONFIG_SND_HDA_CODEC_ANALOG=y
# CONFIG_SND_HDA_CODEC_SIGMATEL is not set
# CONFIG_SND_HDA_CODEC_VIA is not set
# CONFIG_SND_HDA_CODEC_ATIHDMI is not set
# CONFIG_SND_HDA_CODEC_NVHDMI is not set
# CONFIG_SND_HDA_CODEC_INTELHDMI is not set
# CONFIG_SND_HDA_CODEC_CIRRUS is not set
# CONFIG_SND_HDA_CODEC_CONEXANT is not set
# CONFIG_SND_HDA_CODEC_CA0110 is not set
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
# CONFIG_SND_HDA_GENERIC is not set
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_USB is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=y
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_TWINHAN=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
CONFIG_HID_GREENASIA=y
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_SMARTJOYPLUS=y
# CONFIG_SMARTJOYPLUS_FF is not set
CONFIG_HID_TOPSEED=y
CONFIG_HID_THRUSTMASTER=y
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_HID_ZEROPLUS=y
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=y
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
# CONFIG_USB_EZUSB is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
CONFIG_USB_SERIAL_FTDI_SIO=y
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_MOTOROLA is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_SYMBOL is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_OPTICON is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set

#
# TI VLYNQ
#
# CONFIG_STAGING is not set
# CONFIG_X86_PLATFORM_DEVICES is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_EXT4_FS=y
# CONFIG_EXT4_FS_XATTR is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=m
# CONFIG_CUSE is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=4096
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_STACKTRACE=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
# CONFIG_FRAME_POINTER is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_OPTIMIZE_INLINING is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
# CONFIG_DEFAULT_SECURITY_SMACK is not set
# CONFIG_DEFAULT_SECURITY_TOMOYO is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y


-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

2010-02-02 12:00:43

by Jerome Glisse

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Tue, Feb 02, 2010 at 09:17:27AM +0100, Ingo Molnar wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
> > > Hi Linus,
> > >
> > > Please pull the 'drm-linus' branch from
> > > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> > >
> >
> > I've also added an oops fix I seem to lose off my radar to this tree.
> >
> > commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> > Author: Michel D??nzer <[email protected]>
> > Date: Fri Jan 22 09:20:00 2010 +0100
> >
> > drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
>
> FYI, this drm pull into mainline has triggered quick boot crashes in -tip
> testing (even with the above fix applied), on an Athlon64 whitebox PC with:
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
> 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
>
> the crash is:
>
> [ 7.111003] radeon 0000:01:00.0: Disabling GPU acceleration
> [ 7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen.
> [ 7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
> [ 7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen.
> [ 7.599306] BUG: unable to handle kernel paging request at f8380000
> [ 7.599999] IP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c
> [ 7.599999] *pde = 36d44067 *pte = 00000000
> [ 7.599999] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
> [ 7.599999] last sysfs file:
>
> i have bisected it back to:
>
> | 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0 is the first bad commit
> | commit 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0
> | Author: Dave Airlie <[email protected]>
> | Date: Fri Jan 29 15:31:47 2010 +1000
> |
> | drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.
> |
> | This makes displayport work again here.
>
> Unfortunately even with that patch reverted it still crashes. Config and
> bootlog attached.
>
> It's the moving of radeom KMS out of staging after -rc6 that causes it,
> because it brought it into the scope of my testing:
>
> f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
>
> So at least on this box it's clearly not ready for mainline enablement yet.
> I've attached the revert patch further below.
>
> Ingo
>

Attached is a patch which will fix the oops, still it's strange that
CP fails to init on your config. Do you have IOMMU enabled ? I haven't
played with iommu stuff thus i wonder if we are missing somethings in
this area.

Anyway the root issue of the oops made me wonder if we shouldn't explore
some kind of stack based GPU block initialization, when we init a GPU
block we push and when we want to deinit we pop the stack thus block
should be deinited in right order. We are having a lot of different
path in the driver and the failure path are not as well tested as
they might be. Anyway such change is more a long term idea that might
be good to look into (maybe for 2.6.35).

Cheers,
Jerome

Attachments:

2010-02-02 12:03:34

by Jerome Glisse

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Tue, Feb 02, 2010 at 09:58:20AM +0100, Domenico Andreoli wrote:
> On Tue, Feb 02, 2010 at 09:17:27AM +0100, Ingo Molnar wrote:
> >
> > * Dave Airlie <[email protected]> wrote:
> >
> > > > Hi Linus,
> > > >
> > > > Please pull the 'drm-linus' branch from
> > > > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> > > >
> >
> > FYI, this drm pull into mainline has triggered quick boot crashes in -tip
> > testing (even with the above fix applied), on an Athlon64 whitebox PC with:
>
> boot broke also here where unfortunately i have not a serial line
> to see what's happening. anyway disabling KMS restores a working
> 2.6.33-rc6-00072-gab65832 kernel. here is the broken config.
>
> in the next days i should be able to test it with a RV770.
>
> > 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
> > 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
>
> 01:00.0 VGA compatible controller: ATI Technologies Inc RV515 [Radeon X1300]
> 01:00.1 Display controller: ATI Technologies Inc RV515 [Radeon X1300] (Secondary)
>
>

Can you boot in runlevel 3 and with radeon.modeset=0. Then modprobe radeon modeset=1
(you might need to rmmod first), this should allow you capture dmesg log with the failure.
(Do the modprobe/rmmod through ssh as you won't have a console in the process).

Note that here RV515 works like a charm :)

Cheers,
Jerome

2010-02-02 15:12:07

by Domenico Andreoli

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Tue, Feb 02, 2010 at 12:59:13PM +0100, Jerome Glisse wrote:
> On Tue, Feb 02, 2010 at 09:58:20AM +0100, Domenico Andreoli wrote:
> >
> > boot broke also here where unfortunately i have not a serial line
> > to see what's happening. anyway disabling KMS restores a working
> > 2.6.33-rc6-00072-gab65832 kernel. here is the broken config.
>
> Can you boot in runlevel 3 and with radeon.modeset=0. Then modprobe radeon modeset=1
> (you might need to rmmod first), this should allow you capture dmesg log with the failure.
> (Do the modprobe/rmmod through ssh as you won't have a console in the process).

good, this is what I was missing to dig further into it.

> Note that here RV515 works like a charm :)

indeed it works also here :)

given that, I returned to my initial config, with radeon module built-in,
and re-enabled KMS. kernel was actually trying to load firmware blob
radeon/R520_cp.bin which no filesystem was ready to provide, idling for
60 long seconds and making me reporting a false bug. thank you for the
quick response.

[ 113.133716] [drm] radeon kernel modesetting enabled.
[ 113.133799] radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 113.133842] radeon 0000:01:00.0: setting latency timer to 64
[ 113.135000] [drm] radeon: Initializing kernel modesetting.
[ 113.136538] [drm] register mmio base: 0xFE8E0000
[ 113.136578] [drm] register mmio size: 65536
[ 113.136659] ATOM BIOS: RV515LE
[ 113.136906] [drm] GPU reset succeed (RBBM_STATUS=0x10000140)
[ 113.136953] [drm] Generation 2 PCI interface, using max accessible memory
[ 113.136993] [drm] radeon: VRAM 128M
[ 113.137032] [drm] radeon: VRAM from 0x00000000 to 0x07FFFFFF
[ 113.137071] [drm] radeon: GTT 512M
[ 113.137109] [drm] radeon: GTT from 0x20000000 to 0x3FFFFFFF
[ 113.137186] radeon 0000:01:00.0: irq 31 for MSI/MSI-X
[ 113.137190] [drm] radeon: using MSI.
[ 113.137246] [drm] radeon: irq initialized.
[ 113.138965] [drm] Detected VRAM RAM=128M, BAR=256M
[ 113.139007] [drm] RAM width 64bits DDR
[ 113.139087] [TTM] Zone kernel: Available graphics memory: 1028586 kiB.
[ 113.139137] [drm] radeon: 128M of VRAM memory ready
[ 113.139176] [drm] radeon: 512M of GTT memory ready.
[ 113.139227] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 113.141872] [drm] RB2D reset succeed (RBBM_STATUS=0x10000140)
[ 113.141927] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[ 113.142003] [drm] PCIE GART of 512M enabled (table at 0x00040000).
[ 113.142050] [drm] radeon: cp idle (0x10000C03)
[ 113.142115] [drm] Loading R500 Microcode
[ 113.142158] platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin
[ 113.152774] [drm] radeon: ring at 0x0000000020000000
[ 113.152846] [drm] ring test succeeded in 10 usecs
[ 113.153249] [drm] radeon: ib pool ready.
[ 113.153380] [drm] ib test succeeded in 0 usecs
[ 113.153515] [drm] Default TV standard: PAL
[ 113.153620] [drm] Radeon Display Connectors
[ 113.153659] [drm] Connector 0:
[ 113.153697] [drm] VGA
[ 113.153735] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[ 113.153787] [drm] Encoders:
[ 113.153824] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 113.153863] [drm] Connector 1:
[ 113.153900] [drm] S-video
[ 113.153938] [drm] Encoders:
[ 113.153975] [drm] TV1: INTERNAL_KLDSCP_DAC2
[ 113.154014] [drm] Connector 2:
[ 113.154051] [drm] DVI-I
[ 113.154088] [drm] HPD2
[ 113.154126] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[ 113.154179] [drm] Encoders:
[ 113.154216] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[ 113.154254] [drm] DFP3: INTERNAL_LVTM1
[ 113.204918] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.204968] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.205005] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.205006] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.205008] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.205009] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.205010] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.205012] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.205013] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.205014] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.205015]
[ 113.255375] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.255425] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.255461] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.255462] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.255464] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.255465] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.255466] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.255467] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.255469] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.255470] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.255471]
[ 113.305843] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.305892] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.305929] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.305930] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.305931] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.305933] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.305934] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.305935] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.305936] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.305938] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.305939]
[ 113.356292] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.356342] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.356378] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.356379] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.356381] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.356382] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.356383] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.356385] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.356386] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.356387] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.356388]
[ 113.356423] radeon 0000:01:00.0: VGA-1: EDID invalid.
[ 113.421077] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.421127] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.421163] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.421164] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.421166] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.421167] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.421168] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.421170] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.421171] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.421172] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.421173]
[ 113.471540] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.471589] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.471626] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.471627] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.471628] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.471629] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.471631] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.471632] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.471633] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.471634] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.471635]
[ 113.521994] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.522044] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.522081] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.522082] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.522083] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.522084] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.522086] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.522087] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.522088] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.522090] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.522090]
[ 113.572455] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.572514] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.572550] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.572552] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.572553] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.572554] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.572555] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.572557] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.572558] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.572559] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.572560]
[ 113.572595] radeon 0000:01:00.0: VGA-1: EDID invalid.
[ 113.572637] [drm:radeon_vga_detect] *ERROR* VGA-1: probed a monitor but no|invalid EDID
[ 113.623019] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.623068] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.623105] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.623106] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.623107] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.623109] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.623110] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.623111] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.623113] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.623114] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.623115]
[ 113.673495] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.673544] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.673581] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.673582] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.673583] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.673585] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.673586] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.673587] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.673588] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.673590] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.673591]
[ 113.723964] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.724014] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.724050] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.724051] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.724053] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.724054] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.724055] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.724056] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.724058] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.724059] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.724060]
[ 113.774428] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 58
[ 113.774477] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 113.774513] <3>00 ff ff ff ff ff ff 00 04 72 29 ad b5 04 20 45 .........r)... E
[ 113.774515] <3>34 0e 01 03 68 26 1e 6b 2a c3 15 a4 59 4b a0 24 4...h&.k*...YK.$
[ 113.774516] <3>14 4f 54 bf ef 00 81 8f 81 80 71 4f 71 40 61 4f .OT.......qOq@aO
[ 113.774517] <3>61 40 45 4f 45 40 30 2a 00 98 51 00 2a 40 30 70 a@EOE@0*..Q.*@0p
[ 113.774518] <3>13 00 78 2d 11 00 00 1e 00 00 00 ff 00 45 54 4c ..x-.........ETL
[ 113.774520] <3>32 39 30 38 a0 00 31 0a 20 20 00 00 00 fd 00 37 2908..1. .....7
[ 113.774521] <3>4b 1e 53 0e 00 0a 20 20 20 20 20 20 00 00 00 fc K.S... ....
[ 113.774522] <3>00 41 63 65 72 20 41 4c 31 39 31 32 0a 20 00 31 .Acer AL1912. .1
[ 113.774523]
[ 113.774558] radeon 0000:01:00.0: VGA-1: EDID invalid.
[ 113.893751] [drm] fb mappable at 0xD00C0000
[ 113.893790] [drm] vram apper at 0xD0000000
[ 113.893828] [drm] size 3145728
[ 113.893866] [drm] fb depth is 24
[ 113.893903] [drm] pitch is 4096
[ 113.926724] Console: switching to colour frame buffer device 128x48
[ 113.928980] fb0: radeondrmfb frame buffer device
[ 113.929004] registered panic notifier
[ 113.929024] [drm] Initialized radeon 2.0.0 20080528 for 0000:01:00.0 on minor 0

cheers,
Domenico

-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

2010-02-02 15:42:41

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Jerome Glisse <[email protected]> wrote:

> On Tue, Feb 02, 2010 at 09:17:27AM +0100, Ingo Molnar wrote:
> >
> > * Dave Airlie <[email protected]> wrote:
> >
> > > > Hi Linus,
> > > >
> > > > Please pull the 'drm-linus' branch from
> > > > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> > > >
> > >
> > > I've also added an oops fix I seem to lose off my radar to this tree.
> > >
> > > commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> > > Author: Michel D??nzer <[email protected]>
> > > Date: Fri Jan 22 09:20:00 2010 +0100
> > >
> > > drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> >
> > FYI, this drm pull into mainline has triggered quick boot crashes in -tip
> > testing (even with the above fix applied), on an Athlon64 whitebox PC with:
> >
> > 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
> > 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
> >
> > the crash is:
> >
> > [ 7.111003] radeon 0000:01:00.0: Disabling GPU acceleration
> > [ 7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen.
> > [ 7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
> > [ 7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen.
> > [ 7.599306] BUG: unable to handle kernel paging request at f8380000
> > [ 7.599999] IP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c
> > [ 7.599999] *pde = 36d44067 *pte = 00000000
> > [ 7.599999] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
> > [ 7.599999] last sysfs file:
> >
> > i have bisected it back to:
> >
> > | 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0 is the first bad commit
> > | commit 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0
> > | Author: Dave Airlie <[email protected]>
> > | Date: Fri Jan 29 15:31:47 2010 +1000
> > |
> > | drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.
> > |
> > | This makes displayport work again here.
> >
> > Unfortunately even with that patch reverted it still crashes. Config and
> > bootlog attached.
> >
> > It's the moving of radeom KMS out of staging after -rc6 that causes it,
> > because it brought it into the scope of my testing:
> >
> > f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
> >
> > So at least on this box it's clearly not ready for mainline enablement yet.
> > I've attached the revert patch further below.
> >
> > Ingo
> >
>
> Attached is a patch which will fix the oops, still it's strange that CP
> fails to init on your config. [...]

Thanks, that fixes the crash here!

Tested-by: Ingo Molnar <[email protected]>

> [...] Do you have IOMMU enabled ? I haven't played with iommu stuff thus i
> wonder if we are missing somethings in this area.

No IOMMU here - this is a 5 years old box. (beyond GART that is)

Your patch fixes a bona-fide illegal-access bug in the DRM code, that's more
than enough to crash the box ;-)

Btw., there's a new warning in the DRM code

drivers/gpu/drm/ati_pcigart.c: In function ‘drm_ati_pcigart_init’:
drivers/gpu/drm/ati_pcigart.c:115: warning: format ‘%Lx’ expects type ‘long long unsigned int’, but argument 3 has type ‘dma_addr_t’

Please fix that too, the kernel build is noisy enough as-is.

Thanks,

Ingo

2010-02-02 15:42:59

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> On Tue, Feb 2, 2010 at 6:35 PM, Dave Airlie <[email protected]> wrote:
> > On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
> >>
> >> * Dave Airlie <[email protected]> wrote:
> >>
> >>> > Hi Linus,
> >>> >
> >>> > Please pull the 'drm-linus' branch from
> >>> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> >>> >
> >>>
> >>> I've also added an oops fix I seem to lose off my radar to this tree.
> >>>
> >>> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> >>> Author: Michel D??nzer <[email protected]>
> >>> Date: ? Fri Jan 22 09:20:00 2010 +0100
> >>>
> >>> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> >>
> >
> > Wierd this suggests something else is wrong on that machine can you get me
> > the whole dmesg? I'm guessing some iommu or swiotlb issue.
> >
> > I've asked Jerome to fix the oops, but really anyone with an old .config
> > won't get hit by this, and we've booted this on quite a lot of machines
> > at this point.
>
> Ideas keep flooding in here, did you softboot from the old UMS driver? or
> coldboot? does coldbooting help?

Btw., i have cold booted it after full poweroff, and it crashed in the same
way.

Ingo

2010-02-02 15:45:09

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> > It's the moving of radeom KMS out of staging after -rc6 that causes it,
> > because it brought it into the scope of my testing:
> >
> > f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
> >
> > So at least on this box it's clearly not ready for mainline enablement
> > yet. I've attached the revert patch further below.
>
> Its not enabled by default so reverting this doesn't make much sense.

I boot allyesconfig kernels regularly, which testing method works fine with
another 2000+ upstream drivers. (including the dozens of drivers which match
to active hardware components on that box)

> We can just treat this as a normal driver bugreport.

Commit f71d0187 is post-rc6, so i'm not sure it fits your "this is business
as usual, lets move on" characterisation.

Thanks,

Ingo

2010-02-02 15:47:34

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Dave Airlie <[email protected]> wrote:
> >
> >> > Hi Linus,
> >> >
> >> > Please pull the 'drm-linus' branch from
> >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> >> >
> >>
> >> I've also added an oops fix I seem to lose off my radar to this tree.
> >>
> >> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> >> Author: Michel D??nzer <[email protected]>
> >> Date: ? Fri Jan 22 09:20:00 2010 +0100
> >>
> >> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> >
>
> Wierd this suggests something else is wrong on that machine can you get me
> the whole dmesg? I'm guessing some iommu or swiotlb issue.

This box has no known hardware or software problems, just this week it booted
in excess of 1000 kernels so i'd exclude that angle for now.

I have bisected the crash back to the DRM tree and the crash went away with
the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted
my config and i posted the relevant boot log as well. Find below the full
bootlog as well with vanilla -git (ab65832) and the config. (i dont think it
matters)

> I've asked Jerome to fix the oops, but really anyone with an old .config
> won't get hit by this, and we've booted this on quite a lot of machines at
> this point.

I dont see the commit in yesterday's linux-next. It has very fresh
timestamps:

commit f71d0187987e691516cd10c2702f002c0e2f0edc
Author: Dave Airlie <[email protected]>
AuthorDate: Mon Feb 1 11:35:47 2010 +1000
Commit: Dave Airlie <[email protected]>
CommitDate: Mon Feb 1 11:35:47 2010 +1000

What kind of widespread testing could this commit have gotten in the less
than 24 hours before it hit mainline?

Thanks,

Ingo

Attachments:

2010-02-02 20:34:55

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar <[email protected]> wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
>> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
>> >
>> > * Dave Airlie <[email protected]> wrote:
>> >
>> >> > Hi Linus,
>> >> >
>> >> > Please pull the 'drm-linus' branch from
>> >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>> >> >
>> >>
>> >> I've also added an oops fix I seem to lose off my radar to this tree.
>> >>
>> >> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
>> >> Author: Michel D??nzer <[email protected]>
>> >> Date: ? Fri Jan 22 09:20:00 2010 +0100
>> >>
>> >> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
>> >
>>
>> Wierd this suggests something else is wrong on that machine can you get me
>> the whole dmesg? I'm guessing some iommu or swiotlb issue.
>
> This box has no known hardware or software problems, just this week it booted
> in excess of 1000 kernels so i'd exclude that angle for now.
>
> I have bisected the crash back to the DRM tree and the crash went away with
> the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted
> my config and i posted the relevant boot log as well. Find below the full
> bootlog as well with vanilla -git (ab65832) and the config. (i dont think it
> matters)
>
>> I've asked Jerome to fix the oops, but really anyone with an old .config
>> won't get hit by this, and we've booted this on quite a lot of machines at
>> this point.
>
> I dont see the commit in yesterday's linux-next. It has very fresh
> timestamps:
>
> ?commit f71d0187987e691516cd10c2702f002c0e2f0edc
> ?Author: ? ? Dave Airlie <[email protected]>
> ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000
> ?Commit: ? ? Dave Airlie <[email protected]>
> ?CommitDate: Mon Feb 1 11:35:47 2010 +1000
>
> What kind of widespread testing could this commit have gotten in the less
> than 24 hours before it hit mainline?
>

Its shipping in a major distro by default, its planned to be shipped in an even
more major distro. Its been boot tested on 1000s of machines by 1000s of ppl.

Your bug isn't anything to do with this commit, its a completely separate issue,
that nobody else has reported before now and Jerome has provided a patch for.

Dave.

2010-02-02 23:19:24

by Jerome Glisse

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Tue, Feb 02, 2010 at 04:42:21PM +0100, Ingo Molnar wrote:
>
> * Jerome Glisse <[email protected]> wrote:
>
> > On Tue, Feb 02, 2010 at 09:17:27AM +0100, Ingo Molnar wrote:
> > >
> > > * Dave Airlie <[email protected]> wrote:
> > >
> > > > > Hi Linus,
> > > > >
> > > > > Please pull the 'drm-linus' branch from
> > > > > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> > > > >
> > > >
> > > > I've also added an oops fix I seem to lose off my radar to this tree.
> > > >
> > > > commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> > > > Author: Michel D??nzer <[email protected]>
> > > > Date: Fri Jan 22 09:20:00 2010 +0100
> > > >
> > > > drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> > >
> > > FYI, this drm pull into mainline has triggered quick boot crashes in -tip
> > > testing (even with the above fix applied), on an Athlon64 whitebox PC with:
> > >
> > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
> > > 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
> > >
> > > the crash is:
> > >
> > > [ 7.111003] radeon 0000:01:00.0: Disabling GPU acceleration
> > > [ 7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen.
> > > [ 7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
> > > [ 7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen.
> > > [ 7.599306] BUG: unable to handle kernel paging request at f8380000
> > > [ 7.599999] IP: [<c149f0de>] rv370_pcie_gart_set_page+0x2d/0x3c
> > > [ 7.599999] *pde = 36d44067 *pte = 00000000
> > > [ 7.599999] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
> > > [ 7.599999] last sysfs file:
> > >
> > > i have bisected it back to:
> > >
> > > | 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0 is the first bad commit
> > > | commit 97b94ccb9aa1b82ed7a9a045d0ae5b32c99b84a0
> > > | Author: Dave Airlie <[email protected]>
> > > | Date: Fri Jan 29 15:31:47 2010 +1000
> > > |
> > > | drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.
> > > |
> > > | This makes displayport work again here.
> > >
> > > Unfortunately even with that patch reverted it still crashes. Config and
> > > bootlog attached.
> > >
> > > It's the moving of radeom KMS out of staging after -rc6 that causes it,
> > > because it brought it into the scope of my testing:
> > >
> > > f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
> > >
> > > So at least on this box it's clearly not ready for mainline enablement yet.
> > > I've attached the revert patch further below.
> > >
> > > Ingo
> > >
> >
> > Attached is a patch which will fix the oops, still it's strange that CP
> > fails to init on your config. [...]
>
> Thanks, that fixes the crash here!
>
> Tested-by: Ingo Molnar <[email protected]>
>
> > [...] Do you have IOMMU enabled ? I haven't played with iommu stuff thus i
> > wonder if we are missing somethings in this area.
>
> No IOMMU here - this is a 5 years old box. (beyond GART that is)
>
> Your patch fixes a bona-fide illegal-access bug in the DRM code, that's more
> than enough to crash the box ;-)
>
> Btw., there's a new warning in the DRM code
>
> drivers/gpu/drm/ati_pcigart.c: In function ‘drm_ati_pcigart_init’:
> drivers/gpu/drm/ati_pcigart.c:115: warning: format ‘%Lx’ expects type ‘long long unsigned int’, but argument 3 has type ‘dma_addr_t’
>
> Please fix that too, the kernel build is noisy enough as-is.
>
> Thanks,
>
> Ingo

I think i saw a patch for this, it's often a nice thing to let people do their first
patch on this kind of thing, but i try to fix such thing when i run into it, thought
i haven't always been a well behaving kid in the % format area.

Cheers,
Jerome

2010-02-04 06:26:32

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar <[email protected]> wrote:
> >
> > * Dave Airlie <[email protected]> wrote:
> >
> >> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
> >> >
> >> > * Dave Airlie <[email protected]> wrote:
> >> >
> >> >> > Hi Linus,
> >> >> >
> >> >> > Please pull the 'drm-linus' branch from
> >> >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> >> >> >
> >> >>
> >> >> I've also added an oops fix I seem to lose off my radar to this tree.
> >> >>
> >> >> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> >> >> Author: Michel D??nzer <[email protected]>
> >> >> Date: ? Fri Jan 22 09:20:00 2010 +0100
> >> >>
> >> >> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> >> >
> >>
> >> Wierd this suggests something else is wrong on that machine can you get me
> >> the whole dmesg? I'm guessing some iommu or swiotlb issue.
> >
> > This box has no known hardware or software problems, just this week it booted
> > in excess of 1000 kernels so i'd exclude that angle for now.
> >
> > I have bisected the crash back to the DRM tree and the crash went away with
> > the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted
> > my config and i posted the relevant boot log as well. Find below the full
> > bootlog as well with vanilla -git (ab65832) and the config. (i dont think it
> > matters)
> >
> >> I've asked Jerome to fix the oops, but really anyone with an old .config
> >> won't get hit by this, and we've booted this on quite a lot of machines at
> >> this point.
> >
> > I dont see the commit in yesterday's linux-next. It has very fresh
> > timestamps:
> >
> > ?commit f71d0187987e691516cd10c2702f002c0e2f0edc
> > ?Author: ? ? Dave Airlie <[email protected]>
> > ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000
> > ?Commit: ? ? Dave Airlie <[email protected]>
> > ?CommitDate: Mon Feb 1 11:35:47 2010 +1000
> >
> > What kind of widespread testing could this commit have gotten in the less
> > than 24 hours before it hit mainline?
> >
>
> Its shipping in a major distro by default, its planned to be shipped in an
> even more major distro. Its been boot tested on 1000s of machines by 1000s
> of ppl.

Well but that's not the precise tree you sent to Linus, is it?

Ingo

2010-02-04 06:39:42

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

>> On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar <[email protected]> wrote:
>> >
>> > * Dave Airlie <[email protected]> wrote:
>> >
>> >> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
>> >> >
>> >> > * Dave Airlie <[email protected]> wrote:
>> >> >
>> >> >> > Hi Linus,
>> >> >> >
>> >> >> > Please pull the 'drm-linus' branch from
>> >> >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>> >> >> >
>> >> >>
>> >> >> I've also added an oops fix I seem to lose off my radar to this tree.
>> >> >>
>> >> >> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
>> >> >> Author: Michel D??nzer <[email protected]>
>> >> >> Date: ? Fri Jan 22 09:20:00 2010 +0100
>> >> >>
>> >> >> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
>> >> >
>> >>
>> >> Wierd this suggests something else is wrong on that machine can you get me
>> >> the whole dmesg? I'm guessing some iommu or swiotlb issue.
>> >
>> > This box has no known hardware or software problems, just this week it booted
>> > in excess of 1000 kernels so i'd exclude that angle for now.
>> >
>> > I have bisected the crash back to the DRM tree and the crash went away with
>> > the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted
>> > my config and i posted the relevant boot log as well. Find below the full
>> > bootlog as well with vanilla -git (ab65832) and the config. (i dont think it
>> > matters)
>> >
>> >> I've asked Jerome to fix the oops, but really anyone with an old .config
>> >> won't get hit by this, and we've booted this on quite a lot of machines at
>> >> this point.
>> >
>> > I dont see the commit in yesterday's linux-next. It has very fresh
>> > timestamps:
>> >
>> > ?commit f71d0187987e691516cd10c2702f002c0e2f0edc
>> > ?Author: ? ? Dave Airlie <[email protected]>
>> > ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000
>> > ?Commit: ? ? Dave Airlie <[email protected]>
>> > ?CommitDate: Mon Feb 1 11:35:47 2010 +1000
>> >
>> > What kind of widespread testing could this commit have gotten in the less
>> > than 24 hours before it hit mainline?
>> >
>>
>> Its shipping in a major distro by default, its planned to be shipped in an
>> even more major distro. Its been boot tested on 1000s of machines by 1000s
>> of ppl.
>
> Well but that's not the precise tree you sent to Linus, is it?

It pretty much is. If I could blame your crash on any of the recent
patches I would
but its something new and unfun. Most of the fixes in the Linus tree
are directly
from fixes to Fedora/Ubuntu bug reports.

even after reviewing the dmesg I can't see why its failing on that system,

If you could build 2.6.32 on that machine with the staging flag
enabled and see if
it works it would at least tell us if it is something in recent times
or just something
thats always been there.

Unless some other option in make allyesconfig is conflicting and we've never hit
it before. Fedora is close to allyesconfig but not pathalogical like
allyesconfig is.

Dave.

2010-02-04 07:18:59

by Ingo Molnar

Subject: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Ingo Molnar <[email protected]> wrote:

> * Dave Airlie <[email protected]> wrote:
>
> > On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar <[email protected]> wrote:
> > >
> > > * Dave Airlie <[email protected]> wrote:
> > >
> > >> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
> > >> >
> > >> > * Dave Airlie <[email protected]> wrote:
> > >> >
> > >> >> > Hi Linus,
> > >> >> >
> > >> >> > Please pull the 'drm-linus' branch from
> > >> >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> > >> >> >
> > >> >>
> > >> >> I've also added an oops fix I seem to lose off my radar to this tree.
> > >> >>
> > >> >> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> > >> >> Author: Michel D??nzer <[email protected]>
> > >> >> Date: ? Fri Jan 22 09:20:00 2010 +0100
> > >> >>
> > >> >> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> > >> >
> > >>
> > >> Wierd this suggests something else is wrong on that machine can you get me
> > >> the whole dmesg? I'm guessing some iommu or swiotlb issue.
> > >
> > > This box has no known hardware or software problems, just this week it booted
> > > in excess of 1000 kernels so i'd exclude that angle for now.
> > >
> > > I have bisected the crash back to the DRM tree and the crash went away with
> > > the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted
> > > my config and i posted the relevant boot log as well. Find below the full
> > > bootlog as well with vanilla -git (ab65832) and the config. (i dont think it
> > > matters)
> > >
> > >> I've asked Jerome to fix the oops, but really anyone with an old .config
> > >> won't get hit by this, and we've booted this on quite a lot of machines at
> > >> this point.
> > >
> > > I dont see the commit in yesterday's linux-next. It has very fresh
> > > timestamps:
> > >
> > > ?commit f71d0187987e691516cd10c2702f002c0e2f0edc
> > > ?Author: ? ? Dave Airlie <[email protected]>
> > > ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000
> > > ?Commit: ? ? Dave Airlie <[email protected]>
> > > ?CommitDate: Mon Feb 1 11:35:47 2010 +1000
> > >
> > > What kind of widespread testing could this commit have gotten in the less
> > > than 24 hours before it hit mainline?
> > >
> >
> > Its shipping in a major distro by default, its planned to be shipped in an
> > even more major distro. Its been boot tested on 1000s of machines by 1000s
> > of ppl.
>
> Well but that's not the precise tree you sent to Linus, is it?

btw., i just found another bug activated via this same commit, a boot hang
after DRM init:

[ 9.858352] [drm] Connector 1:
[ 9.861417] [drm] DVI-I
[ 9.864031] [drm] HPD1
[ 9.866562] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[ 9.872579] [drm] Encoders:
[ 9.875540] [drm] CRT2: INTERNAL_DAC2
[ 9.879541] [drm] DFP1: INTERNAL_TMDS1
[ 9.883646] [drm] Connector 2:
[ 9.886695] [drm] S-video
[ 9.889483] [drm] Encoders:
[ 9.892463] [drm] TV1: INTERNAL_DAC2
[ 9.896392] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1
[ 9.901796] i2c i2c-0: master_xfer[1] R, addr=0x50, len=128
[ 9.909246] i2c i2c-0: NAK from device addr 0x50 msg #0
[ 9.914564] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
[ 9.919957] i2c i2c-1: master_xfer[1] R, addr=0x50, len=128
[ 9.927413] i2c i2c-1: NAK from device addr 0x50 msg #0

(i power cycled the box after 45 minutes of waiting.)

The hang goes away if i revert commit f71d0187987e6 via the patch below, the
boot sequence becomes:

[ 9.068911] calling drm_core_init+0x0/0x137 @ 1
[ 9.073617] [drm] Initialized drm 1.1.0 20060810
[ 9.078232] initcall drm_core_init+0x0/0x137 returned 0 after 4586 usecs
[ 9.120162] [drm] radeon defaulting to userspace modesetting.
[ 9.154295] [drm] Initialized radeon 1.31.0 20080528 for 0000:01:00.0 on minor 0

Config and bootlog attached.

Ingo

------------->
>From 8b607af1a03d526aef14461e84de9f427b45d64f Mon Sep 17 00:00:00 2001
From: Ingo Molnar <[email protected]>
Date: Tue, 2 Feb 2010 09:06:04 +0100
Subject: [PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

This reverts commit f71d0187987e691516cd10c2702f002c0e2f0edc.

Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/gpu/drm/Kconfig | 2 --
drivers/staging/Kconfig | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 305c590..96eddd1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -66,8 +66,6 @@ config DRM_RADEON

If M is selected, the module will be called radeon.

-source "drivers/gpu/drm/radeon/Kconfig"
-
config DRM_I810
tristate "Intel I810"
depends on DRM && AGP && AGP_INTEL
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index fc2e963..94eb863 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -99,6 +99,8 @@ source "drivers/staging/line6/Kconfig"

source "drivers/gpu/drm/vmwgfx/Kconfig"

+source "drivers/gpu/drm/radeon/Kconfig"
+
source "drivers/gpu/drm/nouveau/Kconfig"

source "drivers/staging/octeon/Kconfig"

Attachments:

2010-02-04 07:37:00

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> >> On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar <[email protected]> wrote:
> >> >
> >> > * Dave Airlie <[email protected]> wrote:
> >> >
> >> >> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
> >> >> >
> >> >> > * Dave Airlie <[email protected]> wrote:
> >> >> >
> >> >> >> > Hi Linus,
> >> >> >> >
> >> >> >> > Please pull the 'drm-linus' branch from
> >> >> >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
> >> >> >> >
> >> >> >>
> >> >> >> I've also added an oops fix I seem to lose off my radar to this tree.
> >> >> >>
> >> >> >> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
> >> >> >> Author: Michel D??nzer <[email protected]>
> >> >> >> Date: ? Fri Jan 22 09:20:00 2010 +0100
> >> >> >>
> >> >> >> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
> >> >> >
> >> >>
> >> >> Wierd this suggests something else is wrong on that machine can you get me
> >> >> the whole dmesg? I'm guessing some iommu or swiotlb issue.
> >> >
> >> > This box has no known hardware or software problems, just this week it booted
> >> > in excess of 1000 kernels so i'd exclude that angle for now.
> >> >
> >> > I have bisected the crash back to the DRM tree and the crash went away with
> >> > the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted
> >> > my config and i posted the relevant boot log as well. Find below the full
> >> > bootlog as well with vanilla -git (ab65832) and the config. (i dont think it
> >> > matters)
> >> >
> >> >> I've asked Jerome to fix the oops, but really anyone with an old .config
> >> >> won't get hit by this, and we've booted this on quite a lot of machines at
> >> >> this point.
> >> >
> >> > I dont see the commit in yesterday's linux-next. It has very fresh
> >> > timestamps:
> >> >
> >> > ?commit f71d0187987e691516cd10c2702f002c0e2f0edc
> >> > ?Author: ? ? Dave Airlie <[email protected]>
> >> > ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000
> >> > ?Commit: ? ? Dave Airlie <[email protected]>
> >> > ?CommitDate: Mon Feb 1 11:35:47 2010 +1000
> >> >
> >> > What kind of widespread testing could this commit have gotten in the less
> >> > than 24 hours before it hit mainline?
> >> >
> >>
> >> Its shipping in a major distro by default, its planned to be shipped in an
> >> even more major distro. Its been boot tested on 1000s of machines by 1000s
> >> of ppl.
> >
> > Well but that's not the precise tree you sent to Linus, is it?
>
> It pretty much is. If I could blame your crash on any of the recent patches
> I would but its something new and unfun. [...]

You dont seem to realize the plain and simple fact that the bug (and some
other bug) was obscure before because this particular KMS aspect of the
radeon driver was in drivers/staging/, and it became more prominent via this
post-rc6 commit:

| From f71d0187987e691516cd10c2702f002c0e2f0edc Mon Sep 17 00:00:00 2001
| From: Dave Airlie <[email protected]>
| Date: Mon, 1 Feb 2010 11:35:47 +1000
| Subject: [PATCH] drm/radeon/kms: move radeon KMS on/off switch out of staging.
|
| We are happy enough that the KMS driver is stable enough for enough people
| for the kms enable/disable to leave staging. Distros can now contemplate
| turning this on.
|
| Signed-off-by: Dave Airlie <[email protected]>
| ---
| drivers/gpu/drm/Kconfig | 2 ++
| drivers/staging/Kconfig | 2 --
| 2 files changed, 2 insertions(+), 2 deletions(-)

I never claimed (and still dont claim) that the bug is 'new' per se, so why
do you keep beating down on that straw man argument? I said it in my very
first mail that this bug got brought upon us by the Kconfig commit above:

> > It's the moving of radeom KMS out of staging after -rc6 that causes it,
> > because it brought it into the scope of my testing:
> >
> > f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
> >
> > So at least on this box it's clearly not ready for mainline enablement
> > yet.

I dont mind reporting bugs and testing patches (as i did), all i said is that
from a QA angle it's somewhat late to do that in -rc7. (It's not even a
completely new driver either, which people would know to stay away from -
it's a new config option of an existing driver, so i'd expect many people to
turn it on when they see it in the oldconfig - even though it's default-off.)

You made the bug more prominent by moving it into the driver proper, after
-rc6, and while i dont mind reporting and working on bugs, your constant
denial is somewhat counter-productive, as (beyond the waste of time on these
emails) it suggests that we might see repeat incidents of this kind in the
future.

Anyway, with two bugs in a row this commit is clearly too problematic for me
so i have reverted f71d018 from -tip.

Thanks,

Ingo

2010-02-04 07:49:11

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 4, 2010 at 5:36 PM, Ingo Molnar <[email protected]> wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
>> >> On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar <[email protected]> wrote:
>> >> >
>> >> > * Dave Airlie <[email protected]> wrote:
>> >> >
>> >> >> On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar <[email protected]> wrote:
>> >> >> >
>> >> >> > * Dave Airlie <[email protected]> wrote:
>> >> >> >
>> >> >> >> > Hi Linus,
>> >> >> >> >
>> >> >> >> > Please pull the 'drm-linus' branch from
>> >> >> >> > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>> >> >> >> >
>> >> >> >>
>> >> >> >> I've also added an oops fix I seem to lose off my radar to this tree.
>> >> >> >>
>> >> >> >> commit 17aafccab4352b422aa01fa6ebf82daff693a5b3
>> >> >> >> Author: Michel D??nzer <[email protected]>
>> >> >> >> Date: ? Fri Jan 22 09:20:00 2010 +0100
>> >> >> >>
>> >> >> >> ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure.
>> >> >> >
>> >> >>
>> >> >> Wierd this suggests something else is wrong on that machine can you get me
>> >> >> the whole dmesg? I'm guessing some iommu or swiotlb issue.
>> >> >
>> >> > This box has no known hardware or software problems, just this week it booted
>> >> > in excess of 1000 kernels so i'd exclude that angle for now.
>> >> >
>> >> > I have bisected the crash back to the DRM tree and the crash went away with
>> >> > the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted
>> >> > my config and i posted the relevant boot log as well. Find below the full
>> >> > bootlog as well with vanilla -git (ab65832) and the config. (i dont think it
>> >> > matters)
>> >> >
>> >> >> I've asked Jerome to fix the oops, but really anyone with an old .config
>> >> >> won't get hit by this, and we've booted this on quite a lot of machines at
>> >> >> this point.
>> >> >
>> >> > I dont see the commit in yesterday's linux-next. It has very fresh
>> >> > timestamps:
>> >> >
>> >> > ?commit f71d0187987e691516cd10c2702f002c0e2f0edc
>> >> > ?Author: ? ? Dave Airlie <[email protected]>
>> >> > ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000
>> >> > ?Commit: ? ? Dave Airlie <[email protected]>
>> >> > ?CommitDate: Mon Feb 1 11:35:47 2010 +1000
>> >> >
>> >> > What kind of widespread testing could this commit have gotten in the less
>> >> > than 24 hours before it hit mainline?
>> >> >
>> >>
>> >> Its shipping in a major distro by default, its planned to be shipped in an
>> >> even more major distro. Its been boot tested on 1000s of machines by 1000s
>> >> of ppl.
>> >
>> > Well but that's not the precise tree you sent to Linus, is it?
>>
>> It pretty much is. If I could blame your crash on any of the recent patches
>> I would but its something new and unfun. [...]
>
> You dont seem to realize the plain and simple fact that the bug (and some
> other bug) was obscure before because this particular KMS aspect of the
> radeon driver was in drivers/staging/, and it became more prominent via this
> post-rc6 commit:
>
> ?| From f71d0187987e691516cd10c2702f002c0e2f0edc Mon Sep 17 00:00:00 2001
> ?| From: Dave Airlie <[email protected]>
> ?| Date: Mon, 1 Feb 2010 11:35:47 +1000
> ?| Subject: [PATCH] drm/radeon/kms: move radeon KMS on/off switch out of staging.
> ?|
> ?| We are happy enough that the KMS driver is stable enough for enough people
> ?| for the kms enable/disable to leave staging. Distros can now contemplate
> ?| turning this on.
> ?|
> ?| Signed-off-by: Dave Airlie <[email protected]>
> ?| ---
> ?| ?drivers/gpu/drm/Kconfig | ? ?2 ++
> ?| ?drivers/staging/Kconfig | ? ?2 --
> ?| ?2 files changed, 2 insertions(+), 2 deletions(-)
>
> I never claimed (and still dont claim) that the bug is 'new' per se, so why
> do you keep beating down on that straw man argument? I said it in my very
> first mail that this bug got brought upon us by the Kconfig commit above:
>
>> > It's the moving of radeom KMS out of staging after -rc6 that causes it,
>> > because it brought it into the scope of my testing:
>> >
>> > ? f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
>> >
>> > So at least on this box it's clearly not ready for mainline enablement
>> > yet.
>
> I dont mind reporting bugs and testing patches (as i did), all i said is that
> from a QA angle it's somewhat late to do that in -rc7. (It's not even a
> completely new driver either, which people would know to stay away from -
> it's a new config option of an existing driver, so i'd expect many people to
> turn it on when they see it in the oldconfig - even though it's default-off.)
>
> You made the bug more prominent by moving it into the driver proper, after
> -rc6, and while i dont mind reporting and working on bugs, your constant
> denial is somewhat counter-productive, as (beyond the waste of time on these
> emails) it suggests that we might see repeat incidents of this kind in the
> future.
>
> Anyway, with two bugs in a row this commit is clearly too problematic for me
> so i have reverted f71d018 from -tip.
>

I haven't denied anything, I'm merely stating one bug on one machine isn't
the end of the known world.

the Kconfig clearly states you need to review your userspace to use this code,
so if people are turning things on blindly they are going to get problems. This
is true for all KMS drivers and will remain true. allytesconfig isn't something
that anyone runs in a non-test configuration. The only place you can get the
correct userspace is via a distro like F12 or Ubuntu in which case you've
already booted their kernel and not seen the problems, or have built all
the userspace anyways.

Jerome's patch fixes the oops part of the problem doesn't it? I'll be
pushing that out as soon
as I get some time to review it and fix the warning you saw. Look x86 has
broken a lot more shit at later rc times so please step down from that
high horse
please already.

Dave.

2010-02-04 16:49:17

by Matthew Garrett

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 08:17:05AM +0100, Ingo Molnar wrote:

> btw., i just found another bug activated via this same commit, a boot hang
> after DRM init:

The commit in question didn't cause the hang, so reverting it isn't the
appropriate fix.

--
Matthew Garrett | [email protected]

2010-02-04 17:08:45

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Matthew Garrett <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 08:17:05AM +0100, Ingo Molnar wrote:
>
> > btw., i just found another bug activated via this same commit, a boot
> > hang after DRM init:
>
> The commit in question didn't cause the hang, so reverting it isn't the
> appropriate fix.

Well, once i applied the revert i got no more hangs or crashes today, in lots
of bootups. This is fully repeatable - if i re-apply that commit with the
config i sent the hang happens again.

Ingo

2010-02-04 17:15:44

by Linus Torvalds

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, 4 Feb 2010, Ingo Molnar wrote:
>
> Well, once i applied the revert i got no more hangs or crashes today, in lots
> of bootups. This is fully repeatable - if i re-apply that commit with the
> config i sent the hang happens again.

But that's just because when it was in staging, you'd never enable it,
right? Because your config generator always turns off staging stuff. IOW,
it's not the code - it's more an interaction with how your test-bed works.

Linus

2010-02-04 17:36:36

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Linus Torvalds <[email protected]> wrote:

> On Thu, 4 Feb 2010, Ingo Molnar wrote:
>
> > Well, once i applied the revert i got no more hangs or crashes today, in
> > lots of bootups. This is fully repeatable - if i re-apply that commit
> > with the config i sent the hang happens again.
>
> But that's just because when it was in staging, you'd never enable it,
> right? Because your config generator always turns off staging stuff. IOW,
> it's not the code - it's more an interaction with how your test-bed works.

Correct. Staging drivers can crash and there's no guarantee of quick
regression fixes (although fixes are generally quick so this isnt a
complaint), so i exclude them from boot testing.

Anyway, i've essentially moved it back to staging as far as my testing goes,
that solves the problem too.

Thanks,

Ingo

2010-02-04 17:36:56

by Matthew Garrett

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 06:08:26PM +0100, Ingo Molnar wrote:

> Well, once i applied the revert i got no more hangs or crashes today, in lots
> of bootups. This is fully repeatable - if i re-apply that commit with the
> config i sent the hang happens again.

If you leave the commit applied, use that config and then enable Radeon
KMS under staging, do you get the hang?

--
Matthew Garrett | [email protected]

2010-02-04 17:55:18

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Matthew Garrett <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 06:08:26PM +0100, Ingo Molnar wrote:
>
> > Well, once i applied the revert i got no more hangs or crashes today, in
> > lots of bootups. This is fully repeatable - if i re-apply that commit
> > with the config i sent the hang happens again.
>
> If you leave the commit applied, use that config and then enable Radeon KMS
> under staging, do you get the hang?

drivers/staging/ is generally an exception from all sorts of regression (and
ABI compatibility, etc.) policies so i dont auto-test it. (because simpy i
cannot do it in a sane way)

I do test the other thousands of regular mainline drivers though - more than
a hundred of which get activated for real on my various test-systems.

So if you move a driver (or a piece of a driver) from drivers/staging to
drivers/ in the -rc6 timeframe, and it causes trouble, i see it as a new
regression.

But you could claim that it's not a regression because 1) technically the
code got introduced in drivers/staging/, and staging drivers are not on the
regression list 2) the Kconfig value is default-off so it can only harm those
who got lured by a new Kconfig value popping up in -rc7 in a well working
driver they already have enabled.

So the moving of driver functionality from drivers/staging/ to drivers/ is a
grey area it appears. Wouldnt it have been better to do this in the next
merge window, as all other drivers do? It's not new hardware enablement
either, it's feature enablement for an existing driver.

Thanks,

Ingo

2010-02-04 17:59:41

by Matthew Garrett

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:

> But you could claim that it's not a regression because 1) technically the
> code got introduced in drivers/staging/, and staging drivers are not on the
> regression list 2) the Kconfig value is default-off so it can only harm those
> who got lured by a new Kconfig value popping up in -rc7 in a well working
> driver they already have enabled.
>
> So the moving of driver functionality from drivers/staging/ to drivers/ is a
> grey area it appears. Wouldnt it have been better to do this in the next
> merge window, as all other drivers do? It's not new hardware enablement
> either, it's feature enablement for an existing driver.

The reason the option was in staging (as has been mentioned before) was
because the ABI wasn't felt to be stable enough. Upstream is now willing
to commit to that stability, so now seems as good a time to move it as
any. There's no code change and there's no default configuration change,
so I really can't see any way that it can be classed as a regression.

--
Matthew Garrett | [email protected]

2010-02-04 18:12:41

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Matthew Garrett <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:
>
> > But you could claim that it's not a regression because 1) technically the
> > code got introduced in drivers/staging/, and staging drivers are not on
> > the regression list 2) the Kconfig value is default-off so it can only
> > harm those who got lured by a new Kconfig value popping up in -rc7 in a
> > well working driver they already have enabled.
> >
> > So the moving of driver functionality from drivers/staging/ to drivers/
> > is a grey area it appears. Wouldnt it have been better to do this in the
> > next merge window, as all other drivers do? It's not new hardware
> > enablement either, it's feature enablement for an existing driver.
>
> The reason the option was in staging (as has been mentioned before) was
> because the ABI wasn't felt to be stable enough. Upstream is now willing to
> commit to that stability, so now seems as good a time to move it as any.
> There's no code change and there's no default configuration change, so I
> really can't see any way that it can be classed as a regression.

But that argument in essence renders the regression policy meaningless for
such code: just about any new driver feature under the sun could be shaped as
a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
activated via a twoliner commit in a later -rc.

IMHO the point of tracking regressions is to reduce the bugginess of the
kernel and thus to help users, not to give ground for legalistic arguments.

There _are_ common-sense exceptions from the regression rules, such as the
introduction of a new piece of hardware that was previously unsupported
(hence there's no expectation of stability) - but the tweaking of an
existing, widely used driver (even if the new opion is default-off) hardly
seems to qualify for that.

I dont mind making useful exceptions from rules, as long as we are honest
about having done it.

Anyway, i've bisected it back to that Kconfig change and i am able to work
the crashes around by reverting that, so my immediate problems are solved.

Thanks,

Ingo

2010-02-04 18:15:50

by Matthew Garrett

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 07:12:18PM +0100, Ingo Molnar wrote:
>
> * Matthew Garrett <[email protected]> wrote:
> > The reason the option was in staging (as has been mentioned before) was
> > because the ABI wasn't felt to be stable enough. Upstream is now willing to
> > commit to that stability, so now seems as good a time to move it as any.
> > There's no code change and there's no default configuration change, so I
> > really can't see any way that it can be classed as a regression.
>
> But that argument in essence renders the regression policy meaningless for
> such code: just about any new driver feature under the sun could be shaped as
> a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
> activated via a twoliner commit in a later -rc.

Before this patch, CONFIG_DRM_RADEON_KMS=y would crash your system on
boot. After this patch, CONFIG_DRM_RADEON_KMS=y still crashes your
system. There's certainly the argument that this means it's premature to
make that change, but given that the same configuration behaves in the
same way, it's clearly not a regression.

--
Matthew Garrett | [email protected]

2010-02-04 18:30:43

by Alex Deucher

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 4, 2010 at 1:12 PM, Ingo Molnar <[email protected]> wrote:
>
> * Matthew Garrett <[email protected]> wrote:
>
>> On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:
>>
>> > But you could claim that it's not a regression because 1) technically the
>> > code got introduced in drivers/staging/, and staging drivers are not on
>> > the regression list 2) the Kconfig value is default-off so it can only
>> > harm those who got lured by a new Kconfig value popping up in -rc7 in a
>> > well working driver they already have enabled.
>> >
>> > So the moving of driver functionality from drivers/staging/ to drivers/
>> > is a grey area it appears. Wouldnt it have been better to do this in the
>> > next merge window, as all other drivers do? It's not new hardware
>> > enablement either, it's feature enablement for an existing driver.
>>
>> The reason the option was in staging (as has been mentioned before) was
>> because the ABI wasn't felt to be stable enough. Upstream is now willing to
>> commit to that stability, so now seems as good a time to move it as any.
>> There's no code change and there's no default configuration change, so I
>> really can't see any way that it can be classed as a regression.
>
> But that argument in essence renders the regression policy meaningless for
> such code: just about any new driver feature under the sun could be shaped as
> a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
> activated via a twoliner commit in a later -rc.
>
> IMHO the point of tracking regressions is to reduce the bugginess of the
> kernel and thus to help users, not to give ground for legalistic arguments.
>
> There _are_ common-sense exceptions from the regression rules, such as the
> introduction of a new piece of hardware that was previously unsupported
> (hence there's no expectation of stability) - but the tweaking of an
> existing, widely used driver (even if the new opion is default-off) hardly
> seems to qualify for that.
>

This is a completely new driver. It's only part of the existing drm
for compatibility reasons. It requires an entirely different graphics
stack above it and works very differently from the old drm stack.

Alex

> I dont mind making useful exceptions from rules, as long as we are honest
> about having done it.
>
> Anyway, i've bisected it back to that Kconfig change and i am able to work
> the crashes around by reverting that, so my immediate problems are solved.
>
> Thanks,
>
> ? ? ? ?Ingo
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

2010-02-04 18:57:37

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Matthew Garrett <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 07:12:18PM +0100, Ingo Molnar wrote:
> >
> > * Matthew Garrett <[email protected]> wrote:
> > > The reason the option was in staging (as has been mentioned before) was
> > > because the ABI wasn't felt to be stable enough. Upstream is now willing to
> > > commit to that stability, so now seems as good a time to move it as any.
> > > There's no code change and there's no default configuration change, so I
> > > really can't see any way that it can be classed as a regression.
> >
> > But that argument in essence renders the regression policy meaningless for
> > such code: just about any new driver feature under the sun could be shaped as
> > a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
> > activated via a twoliner commit in a later -rc.
>
> Before this patch, CONFIG_DRM_RADEON_KMS=y would crash your system on boot.
> [...]

Hm, in what way does that observation address the concerns i've outlined?

Before this patch i could enable CONFIG_DRM_RADEON_KMS=y only if i enabled
CONFIG_STAGING, which i dont, because doing so would taint my kernel with
TAINT_CRAP, and the kernel log would contain:

"%s: module is from the staging directory, the quality is unknown, you have been warned.",

> [...] After this patch, CONFIG_DRM_RADEON_KMS=y still crashes your system.
> [...]

After this patch i suddenly get a new body of code with a default-off option
that would only show up before if i had CONFIG_STAGING=y enabled before.

Do you see my argument why any user who is hit by this would categorize this
as a kernel regression in an existing driver?

Moving driver functionality from drivers/staging/ to drivers/ might be
justified, it might be pragmatic, but you dont try to justify it and you dont
try to outline the pragmatic reasons - from all i can see you seem to argue
that this is all perfectly fine in late -rc's, which has me worried somewhat.

[ And if that is really fine i'd like to hear Linus's amen on that as well,
because i'm sure others would like to use that mechanism too to enable
new functionality in late -rc's. ]

Thanks,

Ingo

2010-02-04 19:00:24

by Matthew Garrett

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 07:56:03PM +0100, Ingo Molnar wrote:

> Do you see my argument why any user who is hit by this would categorize this
> as a kernel regression in an existing driver?

No. If a user changes configuration and gets a hang, that's a bug but
not a regression.

--
Matthew Garrett | [email protected]

2010-02-04 19:07:06

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Alex Deucher <[email protected]> wrote:

> On Thu, Feb 4, 2010 at 1:12 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Matthew Garrett <[email protected]> wrote:
> >
> >> On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:
> >>
> >> > But you could claim that it's not a regression because 1) technically the
> >> > code got introduced in drivers/staging/, and staging drivers are not on
> >> > the regression list 2) the Kconfig value is default-off so it can only
> >> > harm those who got lured by a new Kconfig value popping up in -rc7 in a
> >> > well working driver they already have enabled.
> >> >
> >> > So the moving of driver functionality from drivers/staging/ to drivers/
> >> > is a grey area it appears. Wouldnt it have been better to do this in the
> >> > next merge window, as all other drivers do? It's not new hardware
> >> > enablement either, it's feature enablement for an existing driver.
> >>
> >> The reason the option was in staging (as has been mentioned before) was
> >> because the ABI wasn't felt to be stable enough. Upstream is now willing to
> >> commit to that stability, so now seems as good a time to move it as any.
> >> There's no code change and there's no default configuration change, so I
> >> really can't see any way that it can be classed as a regression.
> >
> > But that argument in essence renders the regression policy meaningless for
> > such code: just about any new driver feature under the sun could be shaped as
> > a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
> > activated via a twoliner commit in a later -rc.
> >
> > IMHO the point of tracking regressions is to reduce the bugginess of the
> > kernel and thus to help users, not to give ground for legalistic arguments.
> >
> > There _are_ common-sense exceptions from the regression rules, such as the
> > introduction of a new piece of hardware that was previously unsupported
> > (hence there's no expectation of stability) - but the tweaking of an
> > existing, widely used driver (even if the new opion is default-off) hardly
> > seems to qualify for that.
> >
>
> This is a completely new driver. It's only part of the existing drm for
> compatibility reasons. It requires an entirely different graphics stack
> above it and works very differently from the old drm stack.

Will the user know? IMHO what matters in the end is user expectation.

Lets walk through what a current kernel tester of the drm/radeon driver sees
when he types 'make oldconfig' after installing the (to-be-released) .33-rc7
kernel. Firstly, the user with a brand-new distro already has this enabled:

CONFIG_DRM_RADEON=y

and knows the driver, and it performs adequately. Then in -rc7 he gets a new
option:

ATI Radeon (DRM_RADEON) [Y/n/?] y
Enable modesetting on radeon by default (DRM_RADEON_KMS) [N/y/?] (NEW)

The user might easily go: "Hey this is a driver i already have, and there's a
new sub-option for this well-working driver. Sure, enable it, these kernel
folks know what they are doing and i rarely see any crashes past -rc2
kernels."

Does this new option tell him what you just told me, that:

> This is a completely new driver. It's only part of the existing drm for
> compatibility reasons. It requires an entirely different graphics stack
> above it and works very differently from the old drm stack.

?

it doesnt. Even if he types '?', it tells:

CONFIG_DRM_RADEON_KMS:

Choose this option if you want kernel modesetting enabled by default,
and you have a new enough userspace to support this. Running old
userspaces with this enabled will cause pain.

The user will likely go "cool I have a fresh distro with recent Xorg, lets
try it".

If this is really a brand new driver essentially fresh out of
drivers/staging/ in -rc7 you should be abundantly clear about that in the
Kconfig help text - that it's a brand new driver and that it might crash on
bootup, etc.

Thanks,

Ingo

2010-02-04 19:18:24

by Alex Deucher

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 4, 2010 at 2:06 PM, Ingo Molnar <[email protected]> wrote:
>
> * Alex Deucher <[email protected]> wrote:
>
>> On Thu, Feb 4, 2010 at 1:12 PM, Ingo Molnar <[email protected]> wrote:
>> >
>> > * Matthew Garrett <[email protected]> wrote:
>> >
>> >> On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:
>> >>
>> >> > But you could claim that it's not a regression because 1) technically the
>> >> > code got introduced in drivers/staging/, and staging drivers are not on
>> >> > the regression list 2) the Kconfig value is default-off so it can only
>> >> > harm those who got lured by a new Kconfig value popping up in -rc7 in a
>> >> > well working driver they already have enabled.
>> >> >
>> >> > So the moving of driver functionality from drivers/staging/ to drivers/
>> >> > is a grey area it appears. Wouldnt it have been better to do this in the
>> >> > next merge window, as all other drivers do? It's not new hardware
>> >> > enablement either, it's feature enablement for an existing driver.
>> >>
>> >> The reason the option was in staging (as has been mentioned before) was
>> >> because the ABI wasn't felt to be stable enough. Upstream is now willing to
>> >> commit to that stability, so now seems as good a time to move it as any.
>> >> There's no code change and there's no default configuration change, so I
>> >> really can't see any way that it can be classed as a regression.
>> >
>> > But that argument in essence renders the regression policy meaningless for
>> > such code: just about any new driver feature under the sun could be shaped as
>> > a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
>> > activated via a twoliner commit in a later -rc.
>> >
>> > IMHO the point of tracking regressions is to reduce the bugginess of the
>> > kernel and thus to help users, not to give ground for legalistic arguments.
>> >
>> > There _are_ common-sense exceptions from the regression rules, such as the
>> > introduction of a new piece of hardware that was previously unsupported
>> > (hence there's no expectation of stability) - but the tweaking of an
>> > existing, widely used driver (even if the new opion is default-off) hardly
>> > seems to qualify for that.
>> >
>>
>> This is a completely new driver. ?It's only part of the existing drm for
>> compatibility reasons. ?It requires an entirely different graphics stack
>> above it and works very differently from the old drm stack.
>
> Will the user know? IMHO what matters in the end is user expectation.
>
> Lets walk through what a current kernel tester of the drm/radeon driver sees
> when he types 'make oldconfig' after installing the (to-be-released) .33-rc7
> kernel. Firstly, the user with a brand-new distro already has this enabled:
>
> ?CONFIG_DRM_RADEON=y
>
> and knows the driver, and it performs adequately. Then in -rc7 he gets a new
> option:
>
> ?ATI Radeon (DRM_RADEON) [Y/n/?] y
> ? ?Enable modesetting on radeon by default (DRM_RADEON_KMS) [N/y/?] (NEW)
>
> The user might easily go: "Hey this is a driver i already have, and there's a
> new sub-option for this well-working driver. Sure, enable it, these kernel
> folks know what they are doing and i rarely see any crashes past -rc2
> kernels."
>
> Does this new option tell him what you just told me, that:
>
> ?> This is a completely new driver. ?It's only part of the existing drm for
> ?> compatibility reasons. ?It requires an entirely different graphics stack
> ?> above it and works very differently from the old drm stack.
>
> ?
>
> it doesnt. Even if he types '?', it tells:
>
> ?CONFIG_DRM_RADEON_KMS:
>
> ?Choose this option if you want kernel modesetting enabled by default,
> ?and you have a new enough userspace to support this. Running old
> ?userspaces with this enabled will cause pain.
>
> The user will likely go "cool I have a fresh distro with recent Xorg, lets
> try it".
>

And if it crashes, he'll report a bug and we'll fix it.

Alex

> If this is really a brand new driver essentially fresh out of
> drivers/staging/ in -rc7 you should be abundantly clear about that in the
> Kconfig help text - that it's a brand new driver and that it might crash on
> bootup, etc.
>
> Thanks,
>
> ? ? ? ?Ingo
>
>

2010-02-04 19:19:54

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Matthew Garrett <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 07:56:03PM +0100, Ingo Molnar wrote:
>
> > Do you see my argument why any user who is hit by this would categorize
> > this as a kernel regression in an existing driver?
>
> No. If a user changes configuration and gets a hang, that's a bug but not a
> regression.

Only if it's some brand-new driver or a brand-new kernel feature for which
no-one can have any prior expectations of stability. Especially if it's added
in the merge window when many new drivers are added.

But isnt it a regression to a user if it's shipped in -rc7 appearing as a new
sub-option of an existing driver?

I'd wager that most main-street Linux users would consider that a regression.

As i see it is that you are trying to have it both ways: claim it's a new
driver when it comes to handling regressions, but also try to have the
benefits (and adoption flux) of an old driver when it comes to facing it to
users.

Some info about that in the Kconfig would be helpful IMO - so that people are
less surprised if it happens to break while the radeon driver worked fine for
them before.

Thanks,

Ingo

2010-02-04 19:25:13

by Linus Torvalds

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, 4 Feb 2010, Alex Deucher wrote:
>
> And if it crashes, he'll report a bug and we'll fix it.

Ok, you have a bug-report. See earlier in the thread:

> btw., i just found another bug activated via this same commit, a boot hang
> after DRM init:
>
> [ 9.858352] [drm] Connector 1:
> [ 9.861417] [drm] DVI-I
> [ 9.864031] [drm] HPD1
> [ 9.866562] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
> [ 9.872579] [drm] Encoders:
> [ 9.875540] [drm] CRT2: INTERNAL_DAC2
> [ 9.879541] [drm] DFP1: INTERNAL_TMDS1
> [ 9.883646] [drm] Connector 2:
> [ 9.886695] [drm] S-video
> [ 9.889483] [drm] Encoders:
> [ 9.892463] [drm] TV1: INTERNAL_DAC2
> [ 9.896392] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1
> [ 9.901796] i2c i2c-0: master_xfer[1] R, addr=0x50, len=128
> [ 9.909246] i2c i2c-0: NAK from device addr 0x50 msg #0
> [ 9.914564] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
> [ 9.919957] i2c i2c-1: master_xfer[1] R, addr=0x50, len=128
> [ 9.927413] i2c i2c-1: NAK from device addr 0x50 msg #0

So can we get it fixed, please?

Linus

2010-02-04 19:32:34

by Jerome Glisse

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 08:19:35PM +0100, Ingo Molnar wrote:
>
> * Matthew Garrett <[email protected]> wrote:
>
> > On Thu, Feb 04, 2010 at 07:56:03PM +0100, Ingo Molnar wrote:
> >
> > > Do you see my argument why any user who is hit by this would categorize
> > > this as a kernel regression in an existing driver?
> >
> > No. If a user changes configuration and gets a hang, that's a bug but not a
> > regression.
>
> Only if it's some brand-new driver or a brand-new kernel feature for which
> no-one can have any prior expectations of stability. Especially if it's added
> in the merge window when many new drivers are added.
>
> But isnt it a regression to a user if it's shipped in -rc7 appearing as a new
> sub-option of an existing driver?
>
> I'd wager that most main-street Linux users would consider that a regression.
>
> As i see it is that you are trying to have it both ways: claim it's a new
> driver when it comes to handling regressions, but also try to have the
> benefits (and adoption flux) of an old driver when it comes to facing it to
> users.

We have been treating KMS regression as regression, i fixed numerous regressions
since it was first merged as an staging driver, and i keep doing so, i try to be
as much reactive as i can. I am sorry you have a bad experience about it. I just
wanted to add that we planed to move KMS out of staging in 2.6.33 long time ago
and yes maybe we should have done it earlier, but no matter when we do the change
you will still face this bug until we fix it.

So on fixing the issue front, one question do you also enable radeonfb ? if so
then its likely the root issue of this bug, i think kconfig should forbid having
both radeon kms + radeonfb but i am not sure how allyesconfig behave in respect
of such constraint.

> Some info about that in the Kconfig would be helpful IMO - so that people are
> less surprised if it happens to break while the radeon driver worked fine for
> them before.
>
> Thanks,
>
> Ingo

I think make menuconfig has a more explicit message iirc.

Cheers,
Jerome

2010-02-04 19:32:59

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Alex Deucher <[email protected]> wrote:

> On Thu, Feb 4, 2010 at 2:06 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Alex Deucher <[email protected]> wrote:
> >
> >> On Thu, Feb 4, 2010 at 1:12 PM, Ingo Molnar <[email protected]> wrote:
> >> >
> >> > * Matthew Garrett <[email protected]> wrote:
> >> >
> >> >> On Thu, Feb 04, 2010 at 06:54:45PM +0100, Ingo Molnar wrote:
> >> >>
> >> >> > But you could claim that it's not a regression because 1) technically the
> >> >> > code got introduced in drivers/staging/, and staging drivers are not on
> >> >> > the regression list 2) the Kconfig value is default-off so it can only
> >> >> > harm those who got lured by a new Kconfig value popping up in -rc7 in a
> >> >> > well working driver they already have enabled.
> >> >> >
> >> >> > So the moving of driver functionality from drivers/staging/ to drivers/
> >> >> > is a grey area it appears. Wouldnt it have been better to do this in the
> >> >> > next merge window, as all other drivers do? It's not new hardware
> >> >> > enablement either, it's feature enablement for an existing driver.
> >> >>
> >> >> The reason the option was in staging (as has been mentioned before) was
> >> >> because the ABI wasn't felt to be stable enough. Upstream is now willing to
> >> >> commit to that stability, so now seems as good a time to move it as any.
> >> >> There's no code change and there's no default configuration change, so I
> >> >> really can't see any way that it can be classed as a regression.
> >> >
> >> > But that argument in essence renders the regression policy meaningless for
> >> > such code: just about any new driver feature under the sun could be shaped as
> >> > a Kconfig option, introduced via a drivers/staging Kconfig entry, and then
> >> > activated via a twoliner commit in a later -rc.
> >> >
> >> > IMHO the point of tracking regressions is to reduce the bugginess of the
> >> > kernel and thus to help users, not to give ground for legalistic arguments.
> >> >
> >> > There _are_ common-sense exceptions from the regression rules, such as the
> >> > introduction of a new piece of hardware that was previously unsupported
> >> > (hence there's no expectation of stability) - but the tweaking of an
> >> > existing, widely used driver (even if the new opion is default-off) hardly
> >> > seems to qualify for that.
> >> >
> >>
> >> This is a completely new driver. ?It's only part of the existing drm for
> >> compatibility reasons. ?It requires an entirely different graphics stack
> >> above it and works very differently from the old drm stack.
> >
> > Will the user know? IMHO what matters in the end is user expectation.
> >
> > Lets walk through what a current kernel tester of the drm/radeon driver sees
> > when he types 'make oldconfig' after installing the (to-be-released) .33-rc7
> > kernel. Firstly, the user with a brand-new distro already has this enabled:
> >
> > ?CONFIG_DRM_RADEON=y
> >
> > and knows the driver, and it performs adequately. Then in -rc7 he gets a new
> > option:
> >
> > ?ATI Radeon (DRM_RADEON) [Y/n/?] y
> > ? ?Enable modesetting on radeon by default (DRM_RADEON_KMS) [N/y/?] (NEW)
> >
> > The user might easily go: "Hey this is a driver i already have, and there's a
> > new sub-option for this well-working driver. Sure, enable it, these kernel
> > folks know what they are doing and i rarely see any crashes past -rc2
> > kernels."
> >
> > Does this new option tell him what you just told me, that:
> >
> > ?> This is a completely new driver. ?It's only part of the existing drm for
> > ?> compatibility reasons. ?It requires an entirely different graphics stack
> > ?> above it and works very differently from the old drm stack.
> >
> > ?
> >
> > it doesnt. Even if he types '?', it tells:
> >
> > ?CONFIG_DRM_RADEON_KMS:
> >
> > ?Choose this option if you want kernel modesetting enabled by default,
> > ?and you have a new enough userspace to support this. Running old
> > ?userspaces with this enabled will cause pain.
> >
> > The user will likely go "cool I have a fresh distro with recent Xorg, lets
> > try it".
> >
>
> And if it crashes, he'll report a bug and we'll fix it.

Nobody has reacted to my related boot hang bugreport yet - and it's detailed
and fully reproducible (so i can test any proposed fixes as well in short
order). I.e. my limited testing has triggered two separate bugs in the same
driver - and this will show up in -rc7.

It might be all OK and no-one else will see trouble. Or past patterns might
repeat themselves and i might simply be an early bird for trouble to come.

My (oft repeated) point is that adding new sub-features to existing drivers
is not what we do in late -rc's: there's simply not enough time to shake out
bugs/regressions in them.

We introduce new functionality to existing drivers in the merge window - in
the two weeks following a stable kernel's release.

In late -rc's we only try to fix regressions. Sometimes we make exceptions
for pragmatic reasons, but then we are straightforward about those reasons
and try to warn users about our zeal to help them with cool, new,
not-to-be-missed GPU functionality ;-)

Thanks,

Ingo

2010-02-04 19:35:01

by Dave Airlie

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Fri, Feb 5, 2010 at 5:24 AM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Thu, 4 Feb 2010, Alex Deucher wrote:
>>
>> And if it crashes, he'll report a bug and we'll fix it.
>
> Ok, you have a bug-report. See earlier in the thread:
>
>> btw., i just found another bug activated via this same commit, a boot hang
>> after DRM init:
>>
>> [ ? ?9.858352] [drm] Connector 1:
>> [ ? ?9.861417] [drm] ? DVI-I
>> [ ? ?9.864031] [drm] ? HPD1
>> [ ? ?9.866562] [drm] ? DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
>> [ ? ?9.872579] [drm] ? Encoders:
>> [ ? ?9.875540] [drm] ? ? CRT2: INTERNAL_DAC2
>> [ ? ?9.879541] [drm] ? ? DFP1: INTERNAL_TMDS1
>> [ ? ?9.883646] [drm] Connector 2:
>> [ ? ?9.886695] [drm] ? S-video
>> [ ? ?9.889483] [drm] ? Encoders:
>> [ ? ?9.892463] [drm] ? ? TV1: INTERNAL_DAC2
>> [ ? ?9.896392] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1
>> [ ? ?9.901796] i2c i2c-0: master_xfer[1] R, addr=0x50, len=128
>> [ ? ?9.909246] i2c i2c-0: NAK from device addr 0x50 msg #0
>> [ ? ?9.914564] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
>> [ ? ?9.919957] i2c i2c-1: master_xfer[1] R, addr=0x50, len=128
>> [ ? ?9.927413] i2c i2c-1: NAK from device addr 0x50 msg #0
>
> So can we get it fixed, please?

Ingo,

got the full dmesg? and lspci -vvnn

the bug reporting needs work, this snippet hasn't the useful info in it.

Dave.

>
> ? ? ? ? ? ? ? ?Linus
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> --
> _______________________________________________
> Dri-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

2010-02-04 19:59:40

by Jesse Barnes

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, 4 Feb 2010 20:32:32 +0100
Ingo Molnar <[email protected]> wrote:
> Nobody has reacted to my related boot hang bugreport yet - and it's
> detailed and fully reproducible (so i can test any proposed fixes as
> well in short order). I.e. my limited testing has triggered two
> separate bugs in the same driver - and this will show up in -rc7.
>
> It might be all OK and no-one else will see trouble. Or past patterns
> might repeat themselves and i might simply be an early bird for
> trouble to come.
>
> My (oft repeated) point is that adding new sub-features to existing
> drivers is not what we do in late -rc's: there's simply not enough
> time to shake out bugs/regressions in them.
>
> We introduce new functionality to existing drivers in the merge
> window - in the two weeks following a stable kernel's release.

This is the .config issue right? It doesn't sound like the bug is new,
you're just seeing now it because of the way you run tests. It
shouldn't affect any more or fewer users than it did before, and
reverting the "move radeon KMS out of staging" won't fix the bug at all
or prevent anyone from seeing it. People using KMS will still use KMS
and people without it won't, because no one actually uses allyes
configs, and the option defaults to N anyway.

> In late -rc's we only try to fix regressions. Sometimes we make
> exceptions for pragmatic reasons, but then we are straightforward
> about those reasons and try to warn users about our zeal to help them
> with cool, new, not-to-be-missed GPU functionality ;-)

Agree, I just don't think this is a regression or an exception.

--
Jesse Barnes, Intel Open Source Technology Center

2010-02-04 20:23:31

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Jesse Barnes <[email protected]> wrote:

> On Thu, 4 Feb 2010 20:32:32 +0100
> Ingo Molnar <[email protected]> wrote:
> > Nobody has reacted to my related boot hang bugreport yet - and it's
> > detailed and fully reproducible (so i can test any proposed fixes as
> > well in short order). I.e. my limited testing has triggered two
> > separate bugs in the same driver - and this will show up in -rc7.
> >
> > It might be all OK and no-one else will see trouble. Or past patterns
> > might repeat themselves and i might simply be an early bird for
> > trouble to come.
> >
> > My (oft repeated) point is that adding new sub-features to existing
> > drivers is not what we do in late -rc's: there's simply not enough
> > time to shake out bugs/regressions in them.
> >
> > We introduce new functionality to existing drivers in the merge
> > window - in the two weeks following a stable kernel's release.
>
> This is the .config issue right? It doesn't sound like the bug is new,
> you're just seeing now it because of the way you run tests. It shouldn't
> affect any more or fewer users than it did before, and reverting the "move
> radeon KMS out of staging" won't fix the bug at all or prevent anyone from
> seeing it. People using KMS will still use KMS and people without it
> won't, [...]

I think you are missing my point. My point is very simple: existing non-KMS
users of CONFIG_DRM_RADON=y (a pre-existing driver) might turn on the new
sub-feature (CONFIG_DRM_RADEON_KMS=y), in the expectation that this is a safe
addition to his currently well-working driver.

( I have to confess i do that all the time for drivers that work well for me,
and if it pops up in a late -rc i sure expect it to be safe to enable. I
dont even read the help text most of the time - if the single-line summary
sounds useful i enable it. Especially if the Kconfig help entry says it's
safe with a new distro, it's not CONFIG_EXPERIMENTAL, it's not marked
CONFIG_BROKEN, it's not in CONFIG_STAGING, etc. )

That action might hang or crash his kernel, and if that user then reports:

" Hey, -rc7 just hung on me after enabling this new .config option it
offered for the radeon driver i am using, please add this to the list of
regressions. "

is this really the right kind of reply:

" Since we moved it from drivers/staging/ to drivers/ this hang you are
seeing is technically not a regression, we might or might not fix it. "

?

I doubt the user would be overly enthusiastic about that kind of reply ;-)

Guys, you should really _think_ about it a minute and realize what the
purpose of a regression policy is.

It's not to be a PITA to subsystem maintainers, it's not an annoyance just to
keep you from doing cool stuff. It's not something which you should try to
lawyer your way out of via an as narrow interpretation as you can.

A regression policy is something that generally helps the quality of Linux,
so it's worth interpreting broadly and generously in spirit not just in
letter. If there's a single most prominent complaint i hear about the
upstream kernel is that it breaks too often. (right after 'it doesnt support
my graphics hardware' - so i sure can relate to the pragmatic reasons of
pushing KMS strongly!)

If i run into a crash and a hang, you can bet that others will as well.

Ingo

2010-02-04 20:27:48

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> On Fri, Feb 5, 2010 at 5:24 AM, Linus Torvalds
> <[email protected]> wrote:
> >
> >
> > On Thu, 4 Feb 2010, Alex Deucher wrote:
> >>
> >> And if it crashes, he'll report a bug and we'll fix it.
> >
> > Ok, you have a bug-report. See earlier in the thread:
> >
> >> btw., i just found another bug activated via this same commit, a boot hang
> >> after DRM init:
> >>
> >> [ ? ?9.858352] [drm] Connector 1:
> >> [ ? ?9.861417] [drm] ? DVI-I
> >> [ ? ?9.864031] [drm] ? HPD1
> >> [ ? ?9.866562] [drm] ? DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
> >> [ ? ?9.872579] [drm] ? Encoders:
> >> [ ? ?9.875540] [drm] ? ? CRT2: INTERNAL_DAC2
> >> [ ? ?9.879541] [drm] ? ? DFP1: INTERNAL_TMDS1
> >> [ ? ?9.883646] [drm] Connector 2:
> >> [ ? ?9.886695] [drm] ? S-video
> >> [ ? ?9.889483] [drm] ? Encoders:
> >> [ ? ?9.892463] [drm] ? ? TV1: INTERNAL_DAC2
> >> [ ? ?9.896392] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1
> >> [ ? ?9.901796] i2c i2c-0: master_xfer[1] R, addr=0x50, len=128
> >> [ ? ?9.909246] i2c i2c-0: NAK from device addr 0x50 msg #0
> >> [ ? ?9.914564] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1
> >> [ ? ?9.919957] i2c i2c-1: master_xfer[1] R, addr=0x50, len=128
> >> [ ? ?9.927413] i2c i2c-1: NAK from device addr 0x50 msg #0
> >
> > So can we get it fixed, please?
>
> Ingo,
>
> got the full dmesg?

Yes, see my report in this thread. Full bootlog up to the hang (serial
captured) was attached, alongside the kernel config.

> and lspci -vvnn

Attached below.

> the bug reporting needs work, this snippet hasn't the useful info in it.

Linus quoted only the relevant portion of my full bugreport. All the other
info is in the full mail he quoted.

Ingo

------------------>

00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3)
Subsystem: ASUSTeK Computer Inc. A8N-E Mainboard [1043:815a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: <access denied>

00:01.0 ISA bridge [0601]: nVidia Corporation CK804 ISA Bridge [10de:0050] (rev a3)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0

00:01.1 SMBus [0c05]: nVidia Corporation CK804 SMBus [10de:0052] (rev a2)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at dc00 [size=32]
Region 4: I/O ports at 4c00 [size=64]
Region 5: I/O ports at 4c40 [size=64]
Capabilities: <access denied>

00:02.0 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005a] (rev a2) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: Memory at da102000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>

00:02.1 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005b] (rev a3) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin B routed to IRQ 0
Region 0: Memory at feb00000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>

00:04.0 Multimedia audio controller [0401]: nVidia Corporation CK804 AC'97 Audio Controller [10de:0059] (rev a2)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:812a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 3
Region 0: I/O ports at d400 [size=256]
Region 1: I/O ports at d800 [size=256]
Region 2: Memory at da101000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>

00:06.0 IDE interface [0101]: nVidia Corporation CK804 IDE [10de:0053] (rev f2) (prog-if 8a [Master SecP PriP])
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:815a]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
Region 4: I/O ports at f000 [size=16]
Capabilities: <access denied>

00:09.0 PCI bridge [0604]: nVidia Corporation CK804 PCI Bridge [10de:005c] (rev a2) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=05, subordinate=05, sec-latency=128
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: da000000-da0fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:0a.0 Bridge [0680]: nVidia Corporation CK804 Ethernet Controller [10de:0057] (rev a3)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard [1043:8141]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at da100000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at d000 [size=8]
Capabilities: <access denied>

00:0b.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <access denied>

00:0c.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <access denied>

00:0d.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: <access denied>

00:0e.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: d8000000-d9ffffff
Prefetchable memory behind bridge: 00000000d0000000-00000000d7ffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
Capabilities: <access denied>

00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Capabilities: <access denied>

00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60] (prog-if 00 [VGA])
Subsystem: PC Partner Limited Unknown device [174b:0500]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 5
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at b000 [size=256]
Region 2: Memory at d9000000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at d8000000 [disabled] [size=128K]
Capabilities: <access denied>

01:00.1 Display controller [0380]: ATI Technologies Inc RV370 [Radeon X300SE] [1002:5b70]
Subsystem: PC Partner Limited Unknown device [174b:0501]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Region 0: Memory at d9010000 (32-bit, non-prefetchable) [disabled] [size=64K]
Capabilities: <access denied>

05:07.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139 [10ec:8139]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at c000 [size=256]
Region 1: Memory at da000000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>

2010-02-04 20:28:09

by David Lang

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, 4 Feb 2010, Ingo Molnar wrote:

> * Jesse Barnes <[email protected]> wrote:
>
>> On Thu, 4 Feb 2010 20:32:32 +0100
>> Ingo Molnar <[email protected]> wrote:
>>> Nobody has reacted to my related boot hang bugreport yet - and it's
>>> detailed and fully reproducible (so i can test any proposed fixes as
>>> well in short order). I.e. my limited testing has triggered two
>>> separate bugs in the same driver - and this will show up in -rc7.
>>>
>>> It might be all OK and no-one else will see trouble. Or past patterns
>>> might repeat themselves and i might simply be an early bird for
>>> trouble to come.
>>>
>>> My (oft repeated) point is that adding new sub-features to existing
>>> drivers is not what we do in late -rc's: there's simply not enough
>>> time to shake out bugs/regressions in them.
>>>
>>> We introduce new functionality to existing drivers in the merge
>>> window - in the two weeks following a stable kernel's release.
>>
>> This is the .config issue right? It doesn't sound like the bug is new,
>> you're just seeing now it because of the way you run tests. It shouldn't
>> affect any more or fewer users than it did before, and reverting the "move
>> radeon KMS out of staging" won't fix the bug at all or prevent anyone from
>> seeing it. People using KMS will still use KMS and people without it
>> won't, [...]
>
> I think you are missing my point. My point is very simple: existing non-KMS
> users of CONFIG_DRM_RADON=y (a pre-existing driver) might turn on the new
> sub-feature (CONFIG_DRM_RADEON_KMS=y), in the expectation that this is a safe
> addition to his currently well-working driver.
>
> ( I have to confess i do that all the time for drivers that work well for me,
> and if it pops up in a late -rc i sure expect it to be safe to enable. I
> dont even read the help text most of the time - if the single-line summary
> sounds useful i enable it. Especially if the Kconfig help entry says it's
> safe with a new distro, it's not CONFIG_EXPERIMENTAL, it's not marked
> CONFIG_BROKEN, it's not in CONFIG_STAGING, etc. )

forget the people testing the rc kernels, what about people who will see
this in the released kernel?

David Lang

2010-02-04 20:33:50

by Jesse Barnes

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, 4 Feb 2010 21:22:54 +0100
Ingo Molnar <[email protected]> wrote:
> > This is the .config issue right? It doesn't sound like the bug is
> > new, you're just seeing now it because of the way you run tests.
> > It shouldn't affect any more or fewer users than it did before, and
> > reverting the "move radeon KMS out of staging" won't fix the bug at
> > all or prevent anyone from seeing it. People using KMS will still
> > use KMS and people without it won't, [...]
>
> I think you are missing my point. My point is very simple: existing
> non-KMS users of CONFIG_DRM_RADON=y (a pre-existing driver) might
> turn on the new sub-feature (CONFIG_DRM_RADEON_KMS=y), in the
> expectation that this is a safe addition to his currently
> well-working driver.

Oh I thought it was you who was missing the point, thus my
explanation. :)

Enabling KMS support is documented in Kconfig and doesn't default to
'y', so I don't know how valid your concern is, even though I
understand it.

> ( I have to confess i do that all the time for drivers that work well
> for me, and if it pops up in a late -rc i sure expect it to be safe
> to enable. I dont even read the help text most of the time - if the
> single-line summary sounds useful i enable it. Especially if the
> Kconfig help entry says it's safe with a new distro, it's not
> CONFIG_EXPERIMENTAL, it's not marked CONFIG_BROKEN, it's not in
> CONFIG_STAGING, etc. )
>
> That action might hang or crash his kernel, and if that user then
> reports:
>
> " Hey, -rc7 just hung on me after enabling this new .config option
> it offered for the radeon driver i am using, please add this to the
> list of regressions. "
>
> is this really the right kind of reply:
>
> " Since we moved it from drivers/staging/ to drivers/ this hang you
> are seeing is technically not a regression, we might or might not fix
> it. "
>
> ?
>
> I doubt the user would be overly enthusiastic about that kind of
> reply ;-)

Whether or not it's a regression is mostly irrelevant, it's a real bug
and the radeon guys are working on fixing it. I really don't think
they'll be flooded with reports of this issue with the removal of the
staging dependency, but that's just my guess.

> Guys, you should really _think_ about it a minute and realize what
> the purpose of a regression policy is.

Everyone understands it, but really:
- this is *not* a driver regression, the code is the same, you just
don't need to enable staging to get it anymore
- using allyesconfig or enabling non-default options requires thought
and preferably reading the Kconfig text, so making this option more
available should be generally safe (that doesn't mean it's bug free
as you've discovered though).

> It's not to be a PITA to subsystem maintainers, it's not an annoyance
> just to keep you from doing cool stuff. It's not something which you
> should try to lawyer your way out of via an as narrow interpretation
> as you can.

I'm certainly not trying to split hairs here, I just think you're
overreacting to this issue by labeling it a regression and implying
that the commit should be reverted.

> A regression policy is something that generally helps the quality of
> Linux, so it's worth interpreting broadly and generously in spirit
> not just in letter. If there's a single most prominent complaint i
> hear about the upstream kernel is that it breaks too often. (right
> after 'it doesnt support my graphics hardware' - so i sure can relate
> to the pragmatic reasons of pushing KMS strongly!)

No one's going to say we shouldn't shoot for high quality, but hiding
things under a config option doesn't fix regressions, and making config
options easier to enable doesn't introduce them, this is still
ultimately a .config issue, not a new code regression.

But we've made too big a deal of this already; my interest in this bug
is purely academic. I think it should be solved, and preferably not by
hiding the config option again, since that's totally irrelevant to the
real issue.

--
Jesse Barnes, Intel Open Source Technology Center

2010-02-04 20:35:18

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Jerome Glisse <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 08:19:35PM +0100, Ingo Molnar wrote:
> >
> > * Matthew Garrett <[email protected]> wrote:
> >
> > > On Thu, Feb 04, 2010 at 07:56:03PM +0100, Ingo Molnar wrote:
> > >
> > > > Do you see my argument why any user who is hit by this would categorize
> > > > this as a kernel regression in an existing driver?
> > >
> > > No. If a user changes configuration and gets a hang, that's a bug but not a
> > > regression.
> >
> > Only if it's some brand-new driver or a brand-new kernel feature for which
> > no-one can have any prior expectations of stability. Especially if it's added
> > in the merge window when many new drivers are added.
> >
> > But isnt it a regression to a user if it's shipped in -rc7 appearing as a new
> > sub-option of an existing driver?
> >
> > I'd wager that most main-street Linux users would consider that a regression.
> >
> > As i see it is that you are trying to have it both ways: claim it's a new
> > driver when it comes to handling regressions, but also try to have the
> > benefits (and adoption flux) of an old driver when it comes to facing it to
> > users.
>
> We have been treating KMS regression as regression, [...]

Great!

> [...] i fixed numerous regressions since it was first merged as an staging
> driver, and i keep doing so, i try to be as much reactive as i can. I am
> sorry you have a bad experience about it. I just wanted to add that we
> planed to move KMS out of staging in 2.6.33 long time ago and yes maybe we
> should have done it earlier, but no matter when we do the change you will
> still face this bug until we fix it.

I dont think you'll ever see my complain about a bug. I dont, and i introduce
far too many of them to have any moral basis for complaint in any case ;-)

I only questioned the validity of this initial reaction by Dave Arlie:

| Its not enabled by default so reverting this doesn't make much sense.
|
| We can just treat this as a normal driver bugreport.

> So on fixing the issue front, one question do you also enable radeonfb ? if
> so then its likely the root issue of this bug, i think kconfig should
> forbid having both radeon kms + radeonfb but i am not sure how allyesconfig
> behave in respect of such constraint.

Please see the bugreprt i made in this thread, under the following subject:

hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

It has all that info and more. (i've bounced it to you privately as well)

Ingo

2010-02-04 20:39:52

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Wed, Feb 3, 2010 at 1:44 AM, Ingo Molnar <[email protected]> wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
>> > It's the moving of radeom KMS out of staging after -rc6 that causes it,
>> > because it brought it into the scope of my testing:
>> >
>> > ?f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
>> >
>> > So at least on this box it's clearly not ready for mainline enablement
>> > yet. I've attached the revert patch further below.
>>
>> Its not enabled by default so reverting this doesn't make much sense.
>
> I boot allyesconfig kernels regularly, which testing method works fine with
> another 2000+ upstream drivers. (including the dozens of drivers which match
> to active hardware components on that box)

Okay this was something I wondered about, since these are *not* allyesconfig
.configs, I've generated some and CONFIG_FB_RADEON is always on here, and
you seem to not have that enabled (not that enabling it is a good idea
it is in fact
a really bad idea).

So do you have something you are running after allyesconfig to fix things? or
have you just got a config that is close enough to allyesconfig.

I'm building kernels with your .config now and boot testing them on
the full range of
hardware I have/

Dave.

2010-02-04 20:47:11

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> On Wed, Feb 3, 2010 at 1:44 AM, Ingo Molnar <[email protected]> wrote:
> >
> > * Dave Airlie <[email protected]> wrote:
> >
> >> > It's the moving of radeom KMS out of staging after -rc6 that causes it,
> >> > because it brought it into the scope of my testing:
> >> >
> >> > ?f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
> >> >
> >> > So at least on this box it's clearly not ready for mainline enablement
> >> > yet. I've attached the revert patch further below.
> >>
> >> Its not enabled by default so reverting this doesn't make much sense.
> >
> > I boot allyesconfig kernels regularly, which testing method works fine
> > with another 2000+ upstream drivers. (including the dozens of drivers
> > which match to active hardware components on that box)
>
> Okay this was something I wondered about, since these are *not*
> allyesconfig .configs, I've generated some and CONFIG_FB_RADEON is always
> on here, and you seem to not have that enabled (not that enabling it is a
> good idea it is in fact a really bad idea).

These were random configs - the size doesnt match an allyesconfig, those are
way bigger. My above comment related to the first crash, and to my argument
that all other drivers are fine during bootup - and there's a lot of them.

> So do you have something you are running after allyesconfig to fix things?
> or have you just got a config that is close enough to allyesconfig.
>
> I'm building kernels with your .config now and boot testing them on the
> full range of hardware I have/

Thanks. Is there something i can enable to get a better log for you to find
out where (and why) it's hanging? It's still early during bootup so the box
is not particularly debuggable - so i'm not sure i can get a task list dump,
etc., unfortunately.

Ingo

2010-02-04 20:48:40

by Matthew Garrett

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote:

> " Hey, -rc7 just hung on me after enabling this new .config option it
> offered for the radeon driver i am using, please add this to the list of
> regressions. "

If the same configuration options hang on both an old kernel and a new
kernel, how is that in any plausible way a regression? What's regressed?

--
Matthew Garrett | [email protected]

2010-02-04 20:57:51

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Jesse Barnes <[email protected]> wrote:

[...]
> > That action might hang or crash his kernel, and if that user then
> > reports:
> >
> > " Hey, -rc7 just hung on me after enabling this new .config option
> > it offered for the radeon driver i am using, please add this to the
> > list of regressions. "
> >
> > is this really the right kind of reply:
> >
> > " Since we moved it from drivers/staging/ to drivers/ this hang you
> > are seeing is technically not a regression, we might or might not fix
> > it. "
> >
> > ?
> >
> > I doubt the user would be overly enthusiastic about that kind of
> > reply ;-)
>
> Whether or not it's a regression is mostly irrelevant, it's a real bug and
> the radeon guys are working on fixing it. [...]

Fortunately it's being worked on.

I beg to differ with your argument about it not mattering whether a bug is
categorized as a regression: Rafael's regression list is far more prominent
and the bugs listed there get fixed with a high likelhood.

Note that there's clear evidence of that in this very thread: the hang bug
was ignored as a "plain" DRM non-regression bugreport, _despite_ the prior
scrutiny in the thread, up to the moment Linus pointed it out and turned it
into a de-facto regression ...

There's also another purpose of categorizing bugs as regressions: tester
timeliness. We tend to treat bugs as 'plain bugs' when they are reported too
late after a few kernel releases of the bug having been in the wild. We do
this to encourage testers to test earlier -rc's as well, as there's a real
tangible benefit of the 'we dont do regressions' policy: bugs get fixed and
testers feel involved, and it's also the stage were we _can_ fix bugs with a
lower cost to all parties involved.

But what 'timeliness of testing' can there be if new features are added in a
late -rc and bugs are explicitly categorized as 'not a regression'?

Ingo

2010-02-04 21:06:19

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Matthew Garrett <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote:
>
> > " Hey, -rc7 just hung on me after enabling this new .config option it
> > offered for the radeon driver i am using, please add this to the list of
> > regressions. "
>
> If the same configuration options hang on both an old kernel and a new
> kernel, how is that in any plausible way a regression? What's regressed?

Regressions are not limited to 'same config' kernels, last i checked. If that
has changed (or if i'm misunderstanding it) then it would be nice to hear a
clarification about that from Linus.

The way i understand it is that there are narrow exceptions from the
regression rules, such as completely new drivers for which there can be no
prior expectation of stability by users. (but for even them we are generally
on the safer side to list bugs in them as regressions as well - especially if
we expect many users to enable it.)

AFAIK there's no exception for new sub-features of existing facilities or
drivers, even if it's default-disabled.

This issue materially affects quite a few bugs i'm handling as a maintainer.
Many of them are under default-off config options - most new aspects to
existing code are introduced in such a way. It would remove quite a bit of
urgent-workload from my workflow if i could strike them from Rafael's list
and could deprioritize them as "plain bugs", to be fixed as time permits.

IMHO it would be rather counter-productive to kernel quality if we did that
kind of regression-lawyering though.

Ingo

2010-02-04 21:10:00

by Matthew Garrett

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 04, 2010 at 10:05:59PM +0100, Ingo Molnar wrote:

> Regressions are not limited to 'same config' kernels, last i checked. If that
> has changed (or if i'm misunderstanding it) then it would be nice to hear a
> clarification about that from Linus.

If an option has *never* worked on a given configuration, then it's not
a regression. That's not a matter of taste, it's a matter of language.
We prioritise regressions because they mean that someone's previously
working configuration no longer works. Tying the word "regression" to
other bugs just to get someone to look at them faster is
counterproductive.

--
Matthew Garrett | [email protected]

2010-02-04 21:14:41

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Fri, Feb 5, 2010 at 6:46 AM, Ingo Molnar <[email protected]> wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
>> On Wed, Feb 3, 2010 at 1:44 AM, Ingo Molnar <[email protected]> wrote:
>> >
>> > * Dave Airlie <[email protected]> wrote:
>> >
>> >> > It's the moving of radeom KMS out of staging after -rc6 that causes it,
>> >> > because it brought it into the scope of my testing:
>> >> >
>> >> > ?f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging.
>> >> >
>> >> > So at least on this box it's clearly not ready for mainline enablement
>> >> > yet. I've attached the revert patch further below.
>> >>
>> >> Its not enabled by default so reverting this doesn't make much sense.
>> >
>> > I boot allyesconfig kernels regularly, which testing method works fine
>> > with another 2000+ upstream drivers. (including the dozens of drivers
>> > which match to active hardware components on that box)
>>
>> Okay this was something I wondered about, since these are *not*
>> allyesconfig .configs, I've generated some and CONFIG_FB_RADEON is always
>> on here, and you seem to not have that enabled (not that enabling it is a
>> good idea it is in fact a really bad idea).
>
> These were random configs - the size doesnt match an allyesconfig, those are
> way bigger. My above comment related to the first crash, and to my argument
> that all other drivers are fine during bootup - and there's a lot of them.
>
>> So do you have something you are running after allyesconfig to fix things?
>> or have you just got a config that is close enough to allyesconfig.
>>
>> I'm building kernels with your .config now and boot testing them on the
>> full range of hardware I have/
>
> Thanks. Is there something i can enable to get a better log for you to find
> out where (and why) it's hanging? It's still early during bootup so the box
> is not particularly debuggable - so i'm not sure i can get a task list dump,
> etc., unfortunately.
>

Do you have NMI watchdog enabled? (does it work that early)

a backtrace of where it hangs would be nice,

Also a dmesg from booting with drm.debug=15 might help narrow it down
also.

Dave.

> ? ? ? ?Ingo
>

2010-02-04 21:24:24

by Andrew Morton

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, 4 Feb 2010 22:05:59 +0100
Ingo Molnar <[email protected]> wrote:

>
> * Matthew Garrett <[email protected]> wrote:
>
> > On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote:
> >
> > > " Hey, -rc7 just hung on me after enabling this new .config option it
> > > offered for the radeon driver i am using, please add this to the list of
> > > regressions. "
> >
> > If the same configuration options hang on both an old kernel and a new
> > kernel, how is that in any plausible way a regression? What's regressed?
>
> Regressions are not limited to 'same config' kernels, last i checked. If that
> has changed (or if i'm misunderstanding it) then it would be nice to hear a
> clarification about that from Linus.
>
> The way i understand it is that there are narrow exceptions from the
> regression rules, such as completely new drivers for which there can be no
> prior expectation of stability by users. (but for even them we are generally
> on the safer side to list bugs in them as regressions as well - especially if
> we expect many users to enable it.)
>
> AFAIK there's no exception for new sub-features of existing facilities or
> drivers, even if it's default-disabled.
>
> This issue materially affects quite a few bugs i'm handling as a maintainer.
> Many of them are under default-off config options - most new aspects to
> existing code are introduced in such a way. It would remove quite a bit of
> urgent-workload from my workflow if i could strike them from Rafael's list
> and could deprioritize them as "plain bugs", to be fixed as time permits.
>
> IMHO it would be rather counter-productive to kernel quality if we did that
> kind of regression-lawyering though.
>

Yes, it's mainly semantics.

>From the user's point of view

kernel N: boots, works, plays nethack
kernel N+1: goes splat

That kernel regressed for that user. He'll shrug and will go back to
kernel N and we lost an N+1 tester. And the distros who ship N+1 get a
lot of hack work to do.

If the feature is this buggy, it was wrong to make it accessible in Kconfig.


Anyway. The number of DRI regressions which have come in over the past
few weeks is really quite extraordinary. We're now showing 31 open
DRI regressions in bugzilla, but a lot of those are presumably
defunct.

It's been bad ever since the KMS stuff went in. That's understandable
given the magnitude of the change, I guess, but the wheels really seem
to have falled off in 2.6.32 and 2.6.33.

2010-02-04 21:35:01

by Jesse Barnes

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, 4 Feb 2010 13:23:46 -0800
Andrew Morton <[email protected]> wrote:

> On Thu, 4 Feb 2010 22:05:59 +0100
> Ingo Molnar <[email protected]> wrote:
>
> >
> > * Matthew Garrett <[email protected]> wrote:
> >
> > > On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote:
> > >
> > > > " Hey, -rc7 just hung on me after enabling this new .config
> > > > option it offered for the radeon driver i am using, please add
> > > > this to the list of regressions. "
> > >
> > > If the same configuration options hang on both an old kernel and
> > > a new kernel, how is that in any plausible way a regression?
> > > What's regressed?
> >
> > Regressions are not limited to 'same config' kernels, last i
> > checked. If that has changed (or if i'm misunderstanding it) then
> > it would be nice to hear a clarification about that from Linus.
> >
> > The way i understand it is that there are narrow exceptions from
> > the regression rules, such as completely new drivers for which
> > there can be no prior expectation of stability by users. (but for
> > even them we are generally on the safer side to list bugs in them
> > as regressions as well - especially if we expect many users to
> > enable it.)
> >
> > AFAIK there's no exception for new sub-features of existing
> > facilities or drivers, even if it's default-disabled.
> >
> > This issue materially affects quite a few bugs i'm handling as a
> > maintainer. Many of them are under default-off config options -
> > most new aspects to existing code are introduced in such a way. It
> > would remove quite a bit of urgent-workload from my workflow if i
> > could strike them from Rafael's list and could deprioritize them as
> > "plain bugs", to be fixed as time permits.
> >
> > IMHO it would be rather counter-productive to kernel quality if we
> > did that kind of regression-lawyering though.
> >
>
> Yes, it's mainly semantics.
>
> >From the user's point of view
>
> kernel N: boots, works, plays nethack
> kernel N+1: goes splat
>
> That kernel regressed for that user. He'll shrug and will go back to
> kernel N and we lost an N+1 tester. And the distros who ship N+1 get
> a lot of hack work to do.
>
> If the feature is this buggy, it was wrong to make it accessible in
> Kconfig.
>
>
> Anyway. The number of DRI regressions which have come in over the
> past few weeks is really quite extraordinary. We're now showing 31
> open DRI regressions in bugzilla, but a lot of those are presumably
> defunct.
>
> It's been bad ever since the KMS stuff went in. That's understandable
> given the magnitude of the change, I guess, but the wheels really seem
> to have falled off in 2.6.32 and 2.6.33.

Yeah the number of regressions we have is out of hand. I expected a
lot of bugs when moving all this code into the kernel though; after all
we've just shifted many of the problems from one code base to another.
We've eliminated whole classes of bugs with the KMS and memory
management architecture in general, but fundamentally display
management is a complex problem, there are a ton of configs to worry
about so it's really hard to fix things or add features without
breaking anything.

Not that this excuses our big regression list... I'll make some time
for tracking these things better and getting them assigned.

--
Jesse Barnes, Intel Open Source Technology Center

2010-02-04 21:35:38

by Dave Airlie

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Fri, Feb 5, 2010 at 7:23 AM, Andrew Morton <[email protected]> wrote:
> On Thu, 4 Feb 2010 22:05:59 +0100
> Ingo Molnar <[email protected]> wrote:
>
>>
>> * Matthew Garrett <[email protected]> wrote:
>>
>> > On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote:
>> >
>> > > ? " Hey, -rc7 just hung on me after enabling this new .config option it
>> > > ? ? offered for the radeon driver i am using, please add this to the list of
>> > > ? ? regressions. "
>> >
>> > If the same configuration options hang on both an old kernel and a new
>> > kernel, how is that in any plausible way a regression? What's regressed?
>>
>> Regressions are not limited to 'same config' kernels, last i checked. If that
>> has changed (or if i'm misunderstanding it) then it would be nice to hear a
>> clarification about that from Linus.
>>
>> The way i understand it is that there are narrow exceptions from the
>> regression rules, such as completely new drivers for which there can be no
>> prior expectation of stability by users. (but for even them we are generally
>> on the safer side to list bugs in them as regressions as well - especially if
>> we expect many users to enable it.)
>>
>> AFAIK there's no exception for new sub-features of existing facilities or
>> drivers, even if it's default-disabled.
>>
>> This issue materially affects quite a few bugs i'm handling as a maintainer.
>> Many of them are under default-off config options - most new aspects to
>> existing code are introduced in such a way. It would remove quite a bit of
>> urgent-workload from my workflow if i could strike them from Rafael's list
>> and could deprioritize them as "plain bugs", to be fixed as time permits.
>>
>> IMHO it would be rather counter-productive to kernel quality if we did that
>> kind of regression-lawyering though.
>>
>
> Yes, it's mainly semantics.
>
> From the user's point of view
>
> kernel N: boots, works, plays nethack
> kernel N+1: goes splat
>
> That kernel regressed for that user. ?He'll shrug and will go back to
> kernel N and we lost an N+1 tester. ?And the distros who ship N+1 get a
> lot of hack work to do.

If they used the same .config and it breaks then its a regression
if not its not. both then intel and radeon KMS enable is also quite
clear on the fact that'll it
break your userspace, so I'd hope ppl are reading it.

>
> If the feature is this buggy, it was wrong to make it accessible in Kconfig.

The bug was identified after we enabled the option, we have no record
of a similiar
problem occuring in Fedora or Ubuntu bug trackers, and my future sight
is broken.

>
> Anyway. ?The number of DRI regressions which have come in over the past
> few weeks is really quite extraordinary. ?We're now showing 31 open
> DRI regressions in bugzilla, but a lot of those are presumably
> defunct.
>
> It's been bad ever since the KMS stuff went in. ?That's understandable
> given the magnitude of the change, I guess, but the wheels really seem
> to have falled off in 2.6.32 and 2.6.33.
>

Its not unsurprising, also Intel vs Radeon KMS is an big distinction,
the core KMS
code hasn't seen much in the way of problems its driver related.

The problem is the kernel is now exposed to the sort of things for
years we've had in
userspace, graphics drivers are hard. Add the interactions with ACPI,
crazy BIOS writers,
SMMs, suspend/resume, power management and it just is really really messy.

I know in the Intel driver we've been backing out a lot of the new
features as soon
as we can identify if the hw or sw is at fault and I've been pushing
the Intel guys
to keep on top of the regession list better, hopefully they are doing so.

Also things like the idr change that just bounced in/out broke all of
the GEM drivers
along with AGP changes in the x86 tree that broke shit.

Dave.

2010-02-05 00:43:58

by Dave Airlie

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

>>
>> These were random configs - the size doesnt match an allyesconfig, those are
>> way bigger. My above comment related to the first crash, and to my argument
>> that all other drivers are fine during bootup - and there's a lot of them.
>>
>>> So do you have something you are running after allyesconfig to fix things?
>>> or have you just got a config that is close enough to allyesconfig.
>>>
>>> I'm building kernels with your .config now and boot testing them on the
>>> full range of hardware I have/
>>
>> Thanks. Is there something i can enable to get a better log for you to find
>> out where (and why) it's hanging? It's still early during bootup so the box
>> is not particularly debuggable - so i'm not sure i can get a task list dump,
>> etc., unfortunately.
>>
> Do you have NMI watchdog enabled? (does it work that early)
>
> a backtrace of where it hangs would be nice,
>
> Also a dmesg from booting with drm.debug=15 might help narrow it down
> also.
>

Okay I've booted this on the rv370 + rv380 machines I have, I've no old Athlon's
though so I'm trying to get RHTS to give me access to one or two internally,

Another question, that came to mind, what is there any monitors plugged in?
or a KVM or something? if yes can you try without and if no can you try with?

Also can you add CONFIG_FRAMEBUFFER_CONSOLE as well since I
don't think we test often without it.

Dave.

2010-02-05 07:32:45

by Ingo Molnar

Subject: Re: [crash, PATCH] Revert "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> >>
> >> These were random configs - the size doesnt match an allyesconfig, those are
> >> way bigger. My above comment related to the first crash, and to my argument
> >> that all other drivers are fine during bootup - and there's a lot of them.
> >>
> >>> So do you have something you are running after allyesconfig to fix things?
> >>> or have you just got a config that is close enough to allyesconfig.
> >>>
> >>> I'm building kernels with your .config now and boot testing them on the
> >>> full range of hardware I have/
> >>
> >> Thanks. Is there something i can enable to get a better log for you to find
> >> out where (and why) it's hanging? It's still early during bootup so the box
> >> is not particularly debuggable - so i'm not sure i can get a task list dump,
> >> etc., unfortunately.
> >>
> > Do you have NMI watchdog enabled? (does it work that early)
> >
> > a backtrace of where it hangs would be nice,
> >
> > Also a dmesg from booting with drm.debug=15 might help narrow it down
> > also.
> >
>
> Okay I've booted this on the rv370 + rv380 machines I have, I've no old
> Athlon's though so I'm trying to get RHTS to give me access to one or two
> internally,
>
> Another question, that came to mind, what is there any monitors plugged in?
> or a KVM or something? if yes can you try without and if no can you try
> with?
>
> Also can you add CONFIG_FRAMEBUFFER_CONSOLE as well since I don't think we
> test often without it.

ok - i'll try your suggestions and send an update - will probably have to
wait until next week. Feel free to deprioritize the bug until then (i have my
revert as a short-term band-aid), unless others report similar problems too.

Thanks,

Ingo

2010-02-05 07:57:12

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Matthew Garrett <[email protected]> wrote:

> On Thu, Feb 04, 2010 at 10:05:59PM +0100, Ingo Molnar wrote:
>
> > Regressions are not limited to 'same config' kernels, last i checked. If that
> > has changed (or if i'm misunderstanding it) then it would be nice to hear a
> > clarification about that from Linus.
>
> If an option has *never* worked on a given configuration, then it's not a
> regression. [...]

The *main driver* (CONFIG_DRM_RADEON=y, as far as the user is concerned) is
many years old and it certainly worked just fine for tens of thousands of
test iterations on this box, up until that commit.

That box alone has done in excess of half a million boot iterations in the
past 2+ years. About 28% of the tests had CONFIG_DRM_RADEON=y, so the number
of successful bootups with CONFIG_DRM_RADEON=y is in excess of one hundred
thousand. There was not a single failed bootup in those two years due to the
CONFIG_DRM_RADEON driver that i can remember.

If it now does not boot up if all its sub-options are enabled, even of some
of those sub-options are new, does that count as a driver regression? Sure it
does to me ...

IMHO you are trying to put a narrow technical distinction into it which does
not exist for users. You argue that it's a new default-off sub-option of an
existing driver, hence it cannot be a regression. The option shows up as a
sub-option to an existing driver in make oldconfig, with a fairly innocious
sounding help text, so to a user it certainly looks as if it's one unit and
that it is the radeon driver that regressed.

*If* we make a driver feature available in a popular driver and make it
Kconfig visible without obvious warnings (i.e. lure the user to enable it
with the notion that it's just one coherent unit with a trusted, existing
driver), we should also hold up the other side of the deal and treat the
*bugs* as a coherent unit as well.

I.e. treat the driver as a coherent whole not only when it's convenient to
us, but also when it's somewhat inconvenient to do. We cannot have it both
ways.

Ingo

2010-02-05 08:34:36

by Dave Airlie

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

> If it now does not boot up if all its sub-options are enabled, even of some
> of those sub-options are new, does that count as a driver regression? Sure it
> does to me ...

But it doesn't to anyone else under any reasonable meaning of the word
regression.

The config option states
"Choose this option if you want kernel modesetting enabled by default,
and you have a new enough userspace to support this. Running old
userspaces with this enabled will cause pain."

Will cause pain sounds painful to me, I can make it seem much worse if
you'd like.

Dave.

2010-02-05 09:00:35

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

>
> > If it now does not boot up if all its sub-options are enabled, even of some
> > of those sub-options are new, does that count as a driver regression? Sure it
> > does to me ...
>
> But it doesn't to anyone else under any reasonable meaning of the word
> regression.

There are reactions in this thread that contradict your 'anyone else' point.

> The config option states
> "Choose this option if you want kernel modesetting enabled by default,
> and you have a new enough userspace to support this. Running old
> userspaces with this enabled will cause pain."
>
> Will cause pain sounds painful to me, I can make it seem much worse if
> you'd like.

Except you are missing that the hang (and the first crash as well) happens on
brand-new user-space just as much - not just on 'old userspaces'.

The bugs i've triggered are independent of any user-space component - it
happens with a fresh distro just as much.

As i suggested before, at least the text should be updated to include what
has been written about CONFIG_DRM_RADEON_KMS in this thread before:

> This is a completely new driver. It's only part of the existing drm for
> compatibility reasons. It requires an entirely different graphics stack
> above it and works very differently from the old drm stack.

Thanks,

Ingo

2010-02-05 09:19:05

by Dave Airlie

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Fri, Feb 5, 2010 at 7:00 PM, Ingo Molnar <[email protected]> wrote:
>
> * Dave Airlie <[email protected]> wrote:
>
>>
>> > If it now does not boot up if all its sub-options are enabled, even of some
>> > of those sub-options are new, does that count as a driver regression? Sure it
>> > does to me ...
>>
>> But it doesn't to anyone else under any reasonable meaning of the word
>> regression.
>
> There are reactions in this thread that contradict your 'anyone else' point.
>
>> The config option states
>> "Choose this option if you want kernel modesetting enabled by default,
>> ? ? ? ? ? and you have a new enough userspace to support this. Running old
>> ? ? ? ? ? userspaces with this enabled will cause pain."
>>
>> Will cause pain sounds painful to me, I can make it seem much worse if
>> you'd like.
>
> Except you are missing that the hang (and the first crash as well) happens on
> brand-new user-space just as much - not just on 'old userspaces'.
>
> The bugs i've triggered are independent of any user-space component - it
> happens with a fresh distro just as much.
>
> As i suggested before, at least the text should be updated to include what
> has been written about CONFIG_DRM_RADEON_KMS in this thread before:
>
> ?> This is a completely new driver. ?It's only part of the existing drm for
> ?> compatibility reasons. ?It requires an entirely different graphics stack
> ?> above it and works very differently from the old drm stack.
>

Okay I've attached a patch with a revised Kconfig in it.

Does this sound more like reality?

Dave.

Attachments:

2010-02-05 10:48:20

by Ingo Molnar

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

* Dave Airlie <[email protected]> wrote:

> On Fri, Feb 5, 2010 at 7:00 PM, Ingo Molnar <[email protected]> wrote:
> >
> > * Dave Airlie <[email protected]> wrote:
> >
> >>
> >> > If it now does not boot up if all its sub-options are enabled, even of some
> >> > of those sub-options are new, does that count as a driver regression? Sure it
> >> > does to me ...
> >>
> >> But it doesn't to anyone else under any reasonable meaning of the word
> >> regression.
> >
> > There are reactions in this thread that contradict your 'anyone else' point.
> >
> >> The config option states
> >> "Choose this option if you want kernel modesetting enabled by default,
> >> ? ? ? ? ? and you have a new enough userspace to support this. Running old
> >> ? ? ? ? ? userspaces with this enabled will cause pain."
> >>
> >> Will cause pain sounds painful to me, I can make it seem much worse if
> >> you'd like.
> >
> > Except you are missing that the hang (and the first crash as well) happens on
> > brand-new user-space just as much - not just on 'old userspaces'.
> >
> > The bugs i've triggered are independent of any user-space component - it
> > happens with a fresh distro just as much.
> >
> > As i suggested before, at least the text should be updated to include what
> > has been written about CONFIG_DRM_RADEON_KMS in this thread before:
> >
> > ?> This is a completely new driver. ?It's only part of the existing drm for
> > ?> compatibility reasons. ?It requires an entirely different graphics stack
> > ?> above it and works very differently from the old drm stack.
> >
>
> Okay I've attached a patch with a revised Kconfig in it.
>
> Does this sound more like reality?

Looks perfect to me!

Acked-by: Ingo Molnar <[email protected]>

Ingo

2010-02-06 11:15:10

by Felipe Contreras

Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

On Thu, Feb 4, 2010 at 11:23 PM, Andrew Morton
<[email protected]> wrote:
> On Thu, 4 Feb 2010 22:05:59 +0100
> Ingo Molnar <[email protected]> wrote:
>> Regressions are not limited to 'same config' kernels, last i checked. If that
>> has changed (or if i'm misunderstanding it) then it would be nice to hear a
>> clarification about that from Linus.
>>
>> The way i understand it is that there are narrow exceptions from the
>> regression rules, such as completely new drivers for which there can be no
>> prior expectation of stability by users. (but for even them we are generally
>> on the safer side to list bugs in them as regressions as well - especially if
>> we expect many users to enable it.)
>>
>> AFAIK there's no exception for new sub-features of existing facilities or
>> drivers, even if it's default-disabled.
>>
>> This issue materially affects quite a few bugs i'm handling as a maintainer.
>> Many of them are under default-off config options - most new aspects to
>> existing code are introduced in such a way. It would remove quite a bit of
>> urgent-workload from my workflow if i could strike them from Rafael's list
>> and could deprioritize them as "plain bugs", to be fixed as time permits.
>>
>> IMHO it would be rather counter-productive to kernel quality if we did that
>> kind of regression-lawyering though.
>
> Yes, it's mainly semantics.
>
> From the user's point of view
>
> kernel N: boots, works, plays nethack
> kernel N+1: goes splat
>
> That kernel regressed for that user.  He'll shrug and will go back to
> kernel N and we lost an N+1 tester.  And the distros who ship N+1 get a
> lot of hack work to do.
>
> If the feature is this buggy, it was wrong to make it accessible in Kconfig.

That's why some features are marked as _experimental_ and disabled by
default. If the feature is not marked as such, then yeah, I would
consider it a regression.

--
Felipe Contreras