From: Gene Heskett <gene.heskett@verizon.net>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.33-rc3, rc2 regression at boot FIXED
Date: Thu, 07 Jan 2010 11:25:28 -0500 [thread overview]
Message-ID: <201001071125.29070.gene.heskett@verizon.net> (raw)
In-Reply-To: <201001071035.15048.gene.heskett@verizon.net>
On Thursday 07 January 2010, Gene Heskett wrote:
>On Wednesday 06 January 2010, Gene Heskett wrote:
>>On Wednesday 06 January 2010, Jiri Kosina wrote:
>>>On Wed, 6 Jan 2010, Gene Heskett wrote:
>>>> >[ 0.558368] Unpacking initramfs...
>>>> >[ 0.648644] Freeing initrd memory: 3431k freed
>>>> >[ 0.651635] platform microcode: firmware: requesting
>>>> > amd-ucode/microcode_amd.bin [ 60.646738] microcode: failed to load
>>>> > file amd-ucode/microcode_amd.bin [ 60.646858] microcode: CPU0:
>>>> > patch_level=0x1000065
>>>> >[ 60.646977] microcode: CPU1: patch_level=0x1000065
>>>> >[ 60.647099] microcode: CPU2: patch_level=0x1000065
>>>> >[ 60.647218] microcode: CPU3: patch_level=0x1000065
>>>> >
>>>> >Note the time, it kills quite close to a whole minute there, which at
>>>> > first would appear to be because there is not yet a mounted /lib
>>>> > filesystem to suck it from. I didn't build an rc1, but rc2 also
>>>> > suffers from this. 2.6.32.2 does not do this although its firmware
>>>> > request takes place at the same point. So it doesn't look like it is
>>>> > the lack of a mounted filesystem after all.
>>>> >
>>>> >FWIW, because it was a hot reboot, the patch_level reported is the
>>>> > correct level.
>>>> >
>>>> >I am also seeing some complaints about my Audigy2 sound card, but what
>>>> > I saw during the boot, never made it to the messages log. Something
>>>> > about guessing at the proper config, but I did hear kde sign on when
>>>> > x started.
>>>> >
>>>> >Thanks Linus.
>>>>
>>>> Update, I edited the .config by hand and added the full path in
>>>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
>>>> which was just 'firmware', and rebuilt. No difference. I still get
>>>> the 60 second hang. FWIW, this particular setting isn't visible in a
>>>> make xconfig.
>>>
>>>As this is already at the stage when userspace exists and init has been
>>>started, it might well be delay of some userspace stuff, not directly
>>>kernel.
>>>
>>>Does alt-sysrq-t at the time it is stuck give any clue?
>>
>>I will try that when I next reboot, thanks Jiri
>
>I just did, and ran into 2 things, 1st being an oops or crash that stopped
>the shutdown and I was forced to use the hdwe reset button. I rebooted to
>2.6.32.3 which worked nominally correct, then to 2.6.33-rc3 again, and
> played 10,000 monkeys on the keyboard while it was sitting there waiting
> for the /lib/firmware/amd-ucode/micrococode_amd.bin for 60 seconds, with
> no apparent effect.
>
>I am not convinced my wireless keyboard is alive at 0.6 seconds into the
> boot procedure. Or I was using the wrong key for 'sysreq' as susch a
> labeled key does not exist on this logitek cordless keyboard.
>
>What line in the .config file actually specifies the path it is supposed to
>be searching to find this file?
>
>>From a grep FIRM .config:
>
>CONFIG_PREVENT_FIRMWARE_BUILD is not set
>CONFIG_FIRMWARE_IN_KERNEL=y
>CONFIG_EXTRA_FIRMWARE="radeon/R100_cp.bin.ihex radeon/R200_cp.bin.ihex
>radeon/R300_cp.bin.ihex radeon/R420_cp.bin.ihex radeon/R520_cp.bin.ihex
>radeon/RS600_cp.bin.ihex radeon/RS690_cp.bin.ihex"
>CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
>CONFIG_LIBERTAS_THINFIRM=m
>CONFIG_LIBERTAS_THINFIRM_USB=m
>CONFIG_HOSTAP_FIRMWARE=y
>CONFIG_HOSTAP_FIRMWARE_NVRAM=y
>CONFIG_FIRMWARE_EDID=y
>CONFIG_FIRMWARE_MEMMAP=y
>
>Is something missing above?
>
>If I want to add the amd-ucode/microcode_amd.bin to CONFIG_EXTRA_FIRMWARE,
> I will have to do it by hand as the xconfig editing function for that line
> seems to have gone away. That list of radeon stuff hasn't been touched in
> nearly 2 years. However, I will do that and report eventually.
>
>Or did the firmware loader itself get broken?
>
>Thanks Jiri.
Update: Fixed for me.
I left that line in the .config with the amd-ucode/microcode_amd.bin added as
discussed above, but I finally grokked that the kernel trees firmware/amd-
ucode directory was not there, so I moved a copy of the microcode_amd.bin
into that directory and re-ran my makeit script. No errors during the make,
and the 1 minute stall problem at .6 seconds into the boot is now fixed.
2 Silly Q's though:
1. Can this file not be distributed as part of the kernel tarball?
2. Why did this Just Work(TM) for 2.6.32.3 and all previous kernels when the
only copy on the system was in /lib/firmware/amd-ucode, but not for 2.6.33-
rcany so far? FWIW, 2.6.32.3/firmware has no amd-ucode subdir at all!
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Anything is possible on paper.
-- Ron McAfee
next prev parent reply other threads:[~2010-01-07 16:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-06 2:48 Linux 2.6.33-rc3 Linus Torvalds
2010-01-06 4:55 ` Linux 2.6.33-rc3, rc2 regression at boot Gene Heskett
2010-01-06 21:02 ` Gene Heskett
2010-01-06 23:55 ` Jiri Kosina
2010-01-07 0:36 ` Gene Heskett
2010-01-07 15:35 ` Gene Heskett
2010-01-07 16:25 ` Gene Heskett [this message]
2010-01-11 23:21 ` Linux 2.6.33-rc3, rc2 regression at boot FIXED Bill Davidsen
2010-01-12 0:22 ` Gene Heskett
2010-01-12 5:10 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201001071125.29070.gene.heskett@verizon.net \
--to=gene.heskett@verizon.net \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®