A long, strange FC3 problem

[Robert L Cochran]

Yep, the x86 Release Notes mention this too. I should be clearer about 
what I'm suggesting: I think you can edit grub.conf to use the 'nofb' 
option as a kernel parameter. That might help you fix the locking issue. 
For example

kernel /vmlinuz-2.6.9-1.681_FC3 ro root=/dev/VolGroup00/LogVol00 nofb


Bob

Robert L Cochran wrote:

> This advice is taken from the Release Notes for the x86_64 arch. I 
> don't know if it is also in the Release Notes for x86. But it looks to 
> me like your system qualifies here:
>
>
> Installation-Related Issues
>
> *
>
> Certain hardware configurations (particularly those with LCD
> displays) may experience problems while starting the Fedora Core
> installation program. In these instances, restart the
> installation, and add the "*nofb*" option to the boot command line.
>
> NOTE: Chinese, Japanese, and Korean graphical installations
> started using the "*nofb*" option will start in English, and then
> switch to the appropriate language once the graphical phase of the
> installation process begins.
>
> *
>
> Serial mice are known to be inoperative during installation.
> However, there are indications that serial mice work properly in X
> after the installation has completed. Refer to bug 119474 for more
> information:
>
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119474
>
>
>
>
> Summer Brooks wrote:
>
>> Bear with me... this is a long explanation of a strange problem
>> with my home machine.
>>
>> I have an issue with FC3 with my monitor locking up. Actually,
>> there are two separate issues, but while the first is one I can
>> work around, the other one isn't.
>>
>> System: generic Intel P4 2.4GHz
>> Monitor: Viewsonic VX900-2 19" LCD
>> Graphics card: nVidia GeForce 440 MX
>> using the SVGA interface on the monitor, since this card doesn't
>> have DVI output
>>
>> First issue is my monitor locks up when switching from text
>> mode to graphical mode during boot up. Locks up to the point
>> where none of the buttons work, not even the power button...
>> I have to unplug it to reset it. It happens once when switching
>> from text to the graphical startup screen, then again when it
>> switches from that screen to the login panel. Once it's plugged
>> back in, the login panel is there, waiting for me, and I can login
>> just like normal.
>>
>> This never happened during the year-plus it was running RH9...
>> has anyone else seen behavior like this?
>>
>> The other problem is harder to pin down, but similar in symptoms.
>> Initially, I'd just done an upgrade from RH9 to FC3, and afterwards,
>> applied all the updates available at the time. Within about 30
>> minutes of setting up my desktop, firing up a browser or 3 and
>> my favorite email client, exmh, my desktop locked up.
>>
>> The mouse could still move across the screen, but I couldn't select
>> a terminal window or application and work in it. At first, I thought
>> it was a problem with Firefox, since I'd been playing on a WordPress
>> data entry screen for a blog I help out with, so I switched back to
>> Mozilla after a hard reboot.
>>
>> The problem didn't happen within that first half-hour, but I also
>> hadn't fired up exmh that session. Nothing happened for a while,
>> and I chalked it up to being a Firefox glitch.
>>
>> The next morning, when I turned the monitor on to continue working,
>> it was locked up in the middle of a screensaver design, and I started
>> the process all over again, with the lock-ups happening so frequently
>> while actually working that I did a fresh install of FC3 and waited
>> to see what would happen. I even changed xscreensaver to do a single
>> non-3D, non-GL pattern, just to be on the safe side.
>>
>> To make a long debugging story short, for two days, the system didn't
>> lock up while I used Firefox or Mozilla. I added a RH9 rpm of
>> nmh-1.0.4-20 and used the terminal commands to do email for a day,
>> and that was fine.
>>
>> Tuesday, I added exmh-2.7.0 from it's tarball, and used it in
>> conjunction with Firefox, and had no problems over the course of a
>> few hours, including repeating things I'd been doing in Firefox before
>> when I'd experienced a lockup. I thought "problem solved"...
>>
>> On Wednesday, I added the RH9 rpms sharutils-4.2.1-14 and 
>> metamail-2.7-28
>> (only after failing to get an FC3 rpm built from metamail-2.7-28.src.rpm
>> or metamail-2.7-29.src.rpm), to get the full MIME related functionality
>> in exmh. Within an hour of adding those rpms, I started to experience
>> the desktop lockups again, even when not running exmh.
>>
>> What makes things worse is that I did the exact same procedure -- an
>> upgrade from RH9 to FC3 -- on my system at work, and everything still
>> worked fine, the exmh and everything. The system at work is a 2.8GHz
>> Dell Precision, with 17" LCD, but it's using the DVI connector from
>> whatever video card is in there (I think it's a newer nVidia, but I'm
>> not 100% sure right now).
>>
>> So color me stumped. Right now, I've removed the metamail rpm from
>> my home machine to see if that resolves the lockups, but if it does,
>> that makes exmh crippled, which makes me an irked camper.
>>
>> I'm open to suggestions here. I'd be happy to get metamail built
>> from source and see if it locks things up again even with a native
>> build, but the source rpm build vomits, and I haven't been able to
>> find sourcecode source for the current version.
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> Summer Brooks, WildHorse.com Staff I will choose a Path that's clear
>> brooksj at wildhorse dot com I will choose Free Will
>>
>>
>>
>