lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:  <4B4BB25D.7010507@tmr.com>
Date:	Mon, 11 Jan 2010 18:21:01 -0500
From:	Bill Davidsen <davidsen@....com>
To:	linux-kernel@...r.kernel.org
Cc:	Jiri Kosina <jkosina@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject:  Re: Linux 2.6.33-rc3, rc2 regression at boot FIXED

Gene Heskett wrote:
> 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!
> 
I spent some time looking at this, and on my systems the real root has been 
mounted before the system looks for the CPU microcode, so I really can't see why 
on yours it is asking early.

Turning off my "quiet" boot option and egrepping for "dracut|firmware" I get the 
attached. Does your not show the switch (pviot root) before the CPU firmware?


-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

View attachment "boot-grep.txt" of type "text/plain" (649 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ