[26021] in Source-Commits
Re: /svn/athena r25349 - trunk/debathena/config/auto-update/debian
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Wed Aug 3 01:21:23 2011
Date: Wed, 3 Aug 2011 01:19:41 -0400 (EDT)
From: Geoffrey Thomas <geofft@MIT.EDU>
To: Jonathan D Reed <jdreed@mit.edu>
cc: source-commits@mit.edu
In-Reply-To: <alpine.DEB.2.00.1108030017430.11210@tyger.mit.edu>
Message-ID: <alpine.DEB.2.00.1108030115130.11210@tyger.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Figured I should try the Natty installer kernel/initrd images... while
vga16fb is able to end the snow crash and get _something_ displayed, it's
less than useful. There's purple garbage in the top ~20% of my screen --
it looks like vga16fb is thinking the screen is 640x400 or so, but hasn't
managed to actually tell the graphics card to stop rendering at 1366x768.
In other words, "I don't think this does what you want on arbitrary
hardware".
Although you could argue that it's more useful than seeing nothing at all,
maybe?
--
Geoffrey Thomas
geofft@mit.edu
On Wed, 3 Aug 2011, Geoffrey Thomas wrote:
> I'm a little skeptical that this is safe on arbitrary hardware. Do we support
> athena-auto-upgrade on hardware we don't own? We've been telling people they
> can run cluster on private hardware...
>
> On my laptop (Toshiba Satellite L635, integrated Intel graphics, Debian
> Squeeze running Wheezy's 2.6.39 kernel, using inteldrmfb), running `vbetool
> post` snow crashes the display. The machine is still running, but unloading
> the framebuffer (while in X) doesn't do anything. Rebooting via kexec, with
> the current kernel loaded, works fine; the display goes black with some
> pixels in the top-left corner for a few seconds, and the framebuffer loads
> normally. However, GDM/X fails to load, and I get the following in dmesg:
>
> [ 41.251096] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> elapsed... GPU hung
> [ 41.251110] [drm] capturing error event; look for more information in
> /debug/dri/0/i915_error_state
> [ 47.703071] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> elapsed... GPU hung
> [ 47.703105] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11
> (awaiting 4 at 0, next 5)
> [ 50.619043] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer
> elapsed... GPU hung
> [ 50.619065] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11
> (awaiting 9 at 0, next 10)
> [ 50.619224] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring
> wedged!
> [ 50.619229] [drm:i915_reset] *ERROR* Failed to reset chip.
>
> and the following in Xorg's logs (/var/log/gdm/:0.log) repeated hundreds of
> times:
>
> (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or
> even a frozen display: Input/output error.
>
> and after about a minute, I get a cursor on a black screen. Logging in on
> Ctrl-Alt-F1 and restarting gdm seems to mostly get things working again.
>
>
> I'd be happier if we conditionalized this to hardware we've tested this
> transition on. Even *Optiplex*) is probably fine. (This is ultimately
> probably just cosmetic since we do a machine reboot at the end of the
> install, but I worry that, since this is a real-mode call, it might do things
> we don't anticipate.)
>
>
> It does occur to me that unloading the framebuffer is a bit irrelevant, since
> we expect this to be run while X owns the display. We could `chvt 1`
> beforehand if watching the kexec (from shutdown to the new kernel loading the
> framebuffer) is interesting.
>
> --
> Geoffrey Thomas
> geofft@mit.edu
>
> On Tue, 2 Aug 2011, Jonathan D Reed wrote:
>
>> Author: jdreed
>> Date: 2011-08-02 23:36:15 -0400 (Tue, 02 Aug 2011)
>> New Revision: 25349
>>
>> Modified:
>> trunk/debathena/config/auto-update/debian/athena-auto-upgrade
>> trunk/debathena/config/auto-update/debian/changelog
>> Log:
>> In auto-update:
>> * Always wave dead chickens
>>
>>
>> Modified: trunk/debathena/config/auto-update/debian/athena-auto-upgrade
>> ===================================================================
>> --- trunk/debathena/config/auto-update/debian/athena-auto-upgrade
>> 2011-08-02 22:20:58 UTC (rev 25348)
>> +++ trunk/debathena/config/auto-update/debian/athena-auto-upgrade
>> 2011-08-03 03:36:15 UTC (rev 25349)
>> @@ -178,15 +178,6 @@
>> # Yes, really. The actual value of product_name on the Vostro is:
>> # "Vostro 320 "
>> case "$product_name" in
>> - "Vostro 320")
>> - # This is not so much Vostro 320-specific as it is i915 specific
>> - # Known to be necessary on PCI ID 8086:2e32, rev 03
>> - debug "Waving dead chicken..."
>> - # Run the video card's POST to reset it
>> - vbetool post
>> - # Disable the framebuffer, falling back to VGA
>> - echo 0 > /sys/class/vtconsole/vtcon1/bind
>> - ;;
>> "OptiPlex 790")
>> debug "Adding 'reboot=pci' for Dell 790"
>> kargs="$kargs reboot=pci"
>> @@ -195,6 +186,14 @@
>> if [ $(echo $kargs | wc -c) -ge 512 ]; then
>> complain "kargs exceeds 512 bytes. That's not good."
>> fi
>> +# This is not so much Vostro 320-specific as it is i915 specific
>> +# Known to be necessary on PCI ID 8086:2e32, rev 03
>> +# Actually, on all hardware, because Dell sucks. Or possibly Ubuntu.
>> +debug "Waving dead chicken..."
>> +# Run the video card's POST to reset it
>> +vbetool post
>> +# Disable the framebuffer, falling back to VGA
>> +echo 0 > /sys/class/vtconsole/vtcon1/bind
>> # Don't kexec -e here, because modern Ubuntu is unable to kexec while
>> # X is running. Instead, kexec -l and let the init script take care of.
>> # Until Oneiric, when this will probably stop working if kexec-tools hasn't
>>
>> Modified: trunk/debathena/config/auto-update/debian/changelog
>> ===================================================================
>> --- trunk/debathena/config/auto-update/debian/changelog 2011-08-02
>> 22:20:58 UTC (rev 25348)
>> +++ trunk/debathena/config/auto-update/debian/changelog 2011-08-03
>> 03:36:15 UTC (rev 25349)
>> @@ -1,3 +1,9 @@
>> +debathena-auto-update (1.28) unstable; urgency=low
>> +
>> + * Always wave dead chickens
>> +
>> + -- Jonathan Reed <jdreed@mit.edu> Tue, 02 Aug 2011 23:36:10 -0400
>> +
>> debathena-auto-update (1.27) unstable; urgency=low
>>
>> [ Geoffrey Thomas ]
>>
>>
>
