Bug 145751 - hwinfo produces empty output
Summary: hwinfo produces empty output
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Other (show other bugs)
Version: unspecified
Hardware: Other Other
: P5 - None : Normal
Target Milestone: ---
Assignee: Steffen Winterfeldt
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-26 09:30 UTC by Christian Andretzky
Modified: 2006-03-10 10:50 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Andretzky 2006-01-26 09:30:31 UTC 
As far as I could see similar problems are already reported.
I could see that 'hwinfo --framebuffer' sometimes (sorry I can not be more precise) produces empty output. I've tried this and many times entered the command (using the history keys) in series. In more than 50 percent of the tests the output from the command was empty. This is the reason for another problem: Installing a new kernel - or be more precise - creating a new initrd uses exactly this command to determine the information for the splash screen to include in the initrd. If the output is empty than no splash screen is set up in the initrd.
In a pool environment you can see then identical machines but some of them with splash screen during the boot process and some of them without. It is time consuming to fix this by hand and - may be after the next kernel update - the same procedure again.
Comment 1 Steffen Winterfeldt 2006-01-26 11:21:42 UTC 
Does 'hwprobe=+cpuemu hwinfo --framebuffer' give better results?
Comment 2 Christian Andretzky 2006-02-20 10:37:49 UTC 
Yesterday in the evening I foud another thing which could be - not the solution, but maybe the reason fro the problem: The whole thing seems to depend from the nuber of active CPUs. I've never noticed this, but I could see that yesterday the machine which over 50 percent of false attempts the day before sudenly seems to run without problems. But some minutes later I noticed (don't ask me, why this happened) that one of the two processors was disabled during the startup. hwinfo runs fine. After rebooting and now running as usual with 2 CPUs the problem happens again in the same way I described in the past.
Also - maybe it has something todo with the number of processors.
Comment 3 Steffen Winterfeldt 2006-02-20 14:37:58 UTC 
The catch is it runs fine here on smp systems. :-)
Comment 4 Christian Andretzky 2006-03-10 10:41:55 UTC 
All machines I had with this problem are either running in a production environment and no longer available for testing or I have no more access to the machines.
If you still can't reproduce the problem. I can no longer help to track it down.
Comment 5 Steffen Winterfeldt 2006-03-10 10:50:59 UTC 
Thanks for notifying.

Sorry, I still haven't seen a machine with such a problem here.