NetBSD Problem Report #49758

From www@NetBSD.org  Wed Mar 18 21:45:19 2015
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C9A36A65BA
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 18 Mar 2015 21:45:19 +0000 (UTC)
Message-Id: <20150318214517.D5C3EA65D1@mollari.NetBSD.org>
Date: Wed, 18 Mar 2015 21:45:17 +0000 (UTC)
From: jdbaker@mylinuxisp.com
Reply-To: jdbaker@consolidated.net
To: gnats-bugs@NetBSD.org
Subject: i386 radeondrmkms hangs machine on attachment
X-Send-Pr-Version: www-1.0

>Number:         49758
>Notify-List:    jdbaker@consolidated.net
>Category:       kern
>Synopsis:       i386 radeondrmkms hangs machine on attachment
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 18 21:50:00 +0000 2015
>Last-Modified:  Tue Jan 29 06:31:49 +0000 2019
>Originator:     John D. Baker
>Release:        NetBSD/i386-7.0_BETA (and 7.99.6+)
>Organization:
>Environment:
NetBSD slab.technoskunk.fur 7.0_BETA NetBSD 7.0_BETA (SLAB) #3: Wed Mar 18 12:20:54 CDT 2015  sysop@verthandi.technoskunk.fur:/d0/build/netbsd-7/obj/i386/sys/arch/i386/compile/SLAB i386

>Description:
With recent -current and netbsd-7 (as of 18 March 2015), radeondrmkms
on i386 still hangs my ThinkPad A31p on about 3 out of 4 boot attempts.

At the point when radeondrmkmsfb attaches, the screen will either be
completely black, or tiled with green hash (that would have been
kernel messages).

It will also do this when using serial console.  In all cases, the
machine is wedged hard and the only way to regain control is to
power-cycle the machine and try again.

Following successfull boot, relevant dmesg items:

NetBSD 7.0_BETA (SLAB) #3: Wed Mar 18 12:20:54 CDT 2015
	sysop@verthandi.technoskunk.fur:/d0/build/netbsd-7/obj/i386/sys/arch/i386/compile/SLAB
[...]
IBM 2653H4U (Not Available)
[...]
acpivga0 at acpi0 (VID): ACPI Display Adapter
acpiout0 at acpivga0 (LCD0, 0x0110): ACPI Display Output Device
acpiout1 at acpivga0 (CRT0, 0x0100): ACPI Display Output Device
acpiout2 at acpivga0 (TV0, 0x0200): ACPI Display Output Device
acpiout3 at acpivga0 (DVI0, 0x0210): ACPI Display Output Device
acpivga0: connected output devices:
acpivga0:   0x0110 (acpiout0): LCD Panel, head 0
acpivga0:   0x0100 (acpiout1): Ext. Monitor, head 0
acpivga0:   0x0200 (acpiout2): TV, head 0
acpivga0:   0x0210 (acpiout3): Unknown Output Device, head 0
[...]
pchb0 at pci0 dev 0 function 0: Intel 82845 Host (rev. 0x04)
agp0 at pchb0: aperture at 0xe0000000, size 0x4000000
ppb0 at pci0 dev 1 function 0: Intel 82845 AGP (rev. 0x04)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
radeon0 at pci1 dev 0 function 0: ATI Technologies FireGL Mobility 7800 M7 LX (rev. 0x00)
radeon0: unable to reserve VGA registers for i386 radeondrmkms hack
[...]
drm: initializing kernel modesetting (RV200 0x1002:0x4C58 0x1014:0x0518).
drm: register mmio base: 0xd0100000
drm: register mmio size: 65536
radeon0: info: GTT: 64M 0xE0000000 - 0xE3FFFFFF
radeon0: info: VRAM: 128M 0x00000000E8000000 - 0x00000000EFFFFFFF (64M used)
drm: Detected VRAM RAM=80M, BAR=128M
drm: RAM width 128bits DDR
Zone  kernel: Available graphics memory: 802208 kiB
drm: radeon: 64M of VRAM memory ready
drm: radeon: 64M of GTT memory ready.
radeon0: info: WB disabled
radeon0: info: fence driver on ring 0 use gpu addr 0x00000000e0000000 and cpu addr 0x0xdb3e9000
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
radeon0: interrupting at irq 9 (radeon)
drm: radeon: irq initialized.
drm: Loading R100 Microcode
drm: radeon: ring at 0x00000000E0001000
drm: ring test succeeded in 0 usecs
drm: ib test succeeded in 0 usecs
drm: Panel ID String: 1600x1200               
drm: Panel Size 1600x1200
drm: No TV DAC info found in BIOS
drm: Radeon Display Connectors
drm: Connector 0:
drm:   VGA-1
drm:   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
drm:   Encoders:
drm:     CRT1: INTERNAL_DAC1
drm: Connector 1:
drm:   DVI-D-1
drm:   HPD1
drm:   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
drm:   Encoders:
drm:     DFP1: INTERNAL_TMDS1
drm: Connector 2:
drm:   LVDS-1
drm:   Encoders:
drm:     LCD1: INTERNAL_LVDS
drm: Connector 3:
drm:   SVIDEO-1
drm:   Encoders:
drm:     TV1: INTERNAL_DAC2
radeondrmkmsfb0 at radeon0
radeon0: info: registered panic notifier
radeondrmkmsfb0: framebuffer at 0xdb5f0000, size 1600x1200, depth 32, stride 6400
wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0


The message about "radeon0: unable to reserve VGA registers for i386
radeondrmkms hack" had me worried that I'd left an outdated local patch
in place, but a quick check revealed that I had not.
>How-To-Repeat:
With netbsd-7 or -current i386 GENERIC (or kernel derived therefrom)
attempt to boot a machine which attaches radeondrmkms and friends.
>Fix:

>Release-Note:

>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: kern/49758: i386 radeondrmkms hangs machine on attachment
Date: Thu, 19 Mar 2015 11:43:15 +1100

 > radeon0: unable to reserve VGA registers for i386 radeondrmkms hack
 > [...]
 > The message about "radeon0: unable to reserve VGA registers for i386
 > radeondrmkms hack" had me worried that I'd left an outdated local patch

 this hack only works for serial.  i should probably remove it now
 that i've commited a much stronger ... if uglier fix :-).  it's
 harmless, anyway.  (ie, should not be related to this problem.)


 .mrg.

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: re: kern/49758: i386 radeondrmkms hangs machine on attachment
Date: Sun, 26 Apr 2015 07:52:07 +1000

 > NetBSD 7.0_BETA (SLAB) #3: Wed Mar 18 12:20:54 CDT 2015
 > 	sysop@verthandi.technoskunk.fur:/d0/build/netbsd-7/obj/i386/sys/arch/i386/compile/SLAB

 does this kernel have LOCKDEBUG?  if not, can you try with that?

 i noticed that one of my systems with i386 kernels it sometimes is able
 to boot and sometimes it has a kernel lock spinout while vscons is drawing
 the text console at radeondrmkms attach time, and i wonder if perhaps you
 are seeing something similar that isn't caught, but just keeps spinning?


 .mrg.

From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org
Subject: re: kern/49758: i386 radeondrmkms hangs machine on attachment
Date: Sun, 26 Apr 2015 08:21:50 -0500 (CDT)

 On Sat, 25 Apr 2015, matthew green wrote:

 >  > NetBSD 7.0_BETA (SLAB) #3: Wed Mar 18 12:20:54 CDT 2015
 >  > 	sysop@verthandi.technoskunk.fur:/d0/build/netbsd-7/obj/i386/sys/arch/i386/compile/SLAB
 >  
 >  does this kernel have LOCKDEBUG?  if not, can you try with that?

 No.  I'll update, add that, and try again.

 >  i noticed that one of my systems with i386 kernels it sometimes is able
 >  to boot and sometimes it has a kernel lock spinout while vscons is drawing
 >  the text console at radeondrmkms attach time, and i wonder if perhaps you
 >  are seeing something similar that isn't caught, but just keeps spinning?

 Lately, I can pretty reliably boot netbsd-7, but -current is problematic.
 When it hangs this way, power-cycle is the only way to regain control.

 Most recently (see kern/49710), rebooting a -current kernel after running
 a netbsd-7 kernel hung the machine at radeondrmkms attach time displaying
 a series of pairs of vertical green lines (which obviously should have
 been kernel message text).  Upon power-cycle, the next boot attempt was
 successful.

 (Actually, the first attempt panicked probing the IEEE1394 devices I
 had plugged in at the time (PR to follow).  I unplugged them and rebooted
 and then it hung with the green lines.  After power cycling, I was able
 to boot the -current kernel successfully a few times in succession while
 observing results for kern/49710.)

 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

>Unformatted:

Home	PR Database Search