i got my hands on a spare DDR1 module, so now this old box has 1.5 gigs of ram. everything seems to work like a charm - with one exception: the overlay window shows nothing but the colorkey; at some point i also had a hard lockup of the machine. when i reboot with mem=1g on the kernel command line, everything is back to normal. now i wonder whether this is an address calculation messup (possibly 32-bit related) or whether the overlay hardware has only 30 address lines and needs memory zoning to be properly supported ... fwiw, the problem happens both with KMS from current git and with the well over two years old xserver + UMS driver.
Can you please try to reproduce this with the latest kernel, preferebly with the drm-intel-next branch from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel (using kms). Otherwise a recent mainline kernel snapshot is good enough. If it still crashes please append your dmesg (before crashing your box), lspci -nn and xrandr ouput. Thanks, Daniel
hmm, i suppose 2.6.35 is not good enough? because that is FAIL. still want the info or should i try intel-next first?
> --- Comment #2 from Oswald Buddenhagen <ossi@kde.org> 2010-08-04 14:52:18 PDT --- > hmm, i suppose 2.6.35 is not good enough? because that is FAIL. still want the > info or should i try intel-next first? 2.6.35 is recent enough for the time being. There are (not yet) any new overlay patches in the kernel.
Created attachment 37669 [details] [review] report overlay reg file addr This kernel patch reports the overlay reg file addr in the dmesg. Can you apply this and attach your dmesg _when_ the overlay doesn't work correctly (in case it ever works by accident). Thanks, Daniel
now, that wasn't too successful: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 80184 at 80183) this usually doesn't happen when i try to play video (recently, not in all, in fact), so i suppose the machine is simply too slow for the printk at this place => the hangcheck timer needs adjustment as well. btw, the right printf format would be %#x or some such - gcc moans about the %p here.
[luckily %p and %x is about the same on 32bit ;) ] Please retry. i8xx hw support is rather decently broken, you seem to be one of the few lucky ones where it does _not_ hang all the time. The printk runs when initizaling the driver, hence can't be responsible for a crash when starting a video. If these crashes persist, please upgrade to latest drm-intel-next (contains new crashdump support for the overlay that's not yet merged) and attach /sys/kernel/debug/dri/0/i915_error_state to this bug. And don't forget to add your full dmesg in any case.
Created attachment 37775 [details] kernel messages uhm, you're right, seems to have been more or less coincidence. so after all, the thing is still unstable despite the apparent stability recently. 00:00.0 Host bridge [0600]: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface [8086:2560] (rev 03) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 03) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 82) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge [8086:24c0] (rev 02) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DB (ICH4) IDE Controller [8086:24cb] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] (rev 02) 02:05.0 Ethernet controller [0200]: Broadcom Corporation BCM4401 100Base-T [14e4:4401] (rev 01) 02:0a.0 Ethernet controller [0200]: 3Com Corporation 3c905C-TX/TX-M [Tornado] [10b7:9200] (rev 78) 02:0b.0 Multimedia audio controller [0401]: Ensoniq ES1371 [AudioPCI-97] [1274:1371] (rev 06) Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048 VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 360mm x 270mm 1280x1024 94.5*+ 75.0.. 1600x1200 75.0 70.0 60.0.. 1152x864 75.0.. 1024x768 75.1 70.1 60.0.. 832x624 74.6.. 800x600 72.2 75.0 60.3.. 640x480 72.8 75.0 66.7 60.0.. i have applied all the patches i posted here and sent to you directly. they don't seem to make things worse ...
for comparison, if i boot with mem=1g, the flip address is 331a0000
So it looks like the overlay hw can't handle memory addresses above 1G. Out of curiosity, can you also attach your .config? 'Cause on my machine I never get an address above 1G (about 20 boot-ups so far ...) and I have an idea what's the difference.
Created attachment 37779 [details] kernel config
Created attachment 37825 [details] [review] adjust coherent dma mask Please test this patch.
yup, PASS :)
Patch submitted for inclusion.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.