It's been quiet due to the holidays, so -rc3 is reasonably small despite
being a few days over the normal one-week mark. And most of the changes
are pretty trivial, although both ext4 and reiserfs had some trouble in
-rc2, hopefully all fixed now.
The bulk of the patches are some SH defconfig updates (40%), but ignoring
those we have the normal "half drivers, half everything else" pattern. On
the driver front, the perhaps most notable change is not so much a code
change, but the small change of marking the "new" firewire stack as being
the recommended one.
Wireless drivers, regular network drivers, filesystems, input layer..
And here's to hoping one reason it's been quiet is that it's actually been
fairly stable. Give it a try,
Linus
---
Alan Cox (2):
i2o: propogate the BKL down into the ioctl method
tosh: Use non bkl ioctl
Alexander Duyck (4):
igb: do not force pcs link when in KX mode
igb: do not force retry count to 1 on 82580 phy
igb: correctly offset 82575 flow control watermarks by 16 bytes
igb: check both function bits in status register in wol exception
Alexander Graf (1):
KVM: powerpc: Fix mtsrin in book3s_64 mmu
Andrew Morton (3):
aoe: switch to the new bio_flush_dcache_pages() interface
ext4: fix unsigned long long printk warning in super.c
jbd2: don't use __GFP_NOFAIL in journal_init_common()
Andrey Borzenkov (1):
orinoco: fix GFP_KERNEL in orinoco_set_key with interrupts disabled
Aneesh Kumar K.V (1):
ext4: Ensure zeroout blocks have no dirty metadata
Anton Vorontsov (3):
ucc_geth: Fix empty TX queue processing
ucc_geth: Fix netdev watchdog triggering on link changes
ucc_geth: Don't needlessly change MAC settings in adjust_link()
Arnaldo Carvalho de Melo (3):
perf diff: Fix usage array, it must end with a NULL entry
perf record: We should fork only if a program was specified to run
perf tools: Add missing header files to LIB_H Makefile variable
Arnaud Patard (2):
ARM: S3C24XX: touchscreen device definition
ARM: S3C24XX: touchscreen device definition
Ben Dooks (3):
ARM: mach-osiris: add NAND_SCAN_SILENT_NODEV to optional devices
ARM: mach-bast: add NAND_SCAN_SILENT_NODEV to optional devices
ARM: S3C: Fix NAND device registration by s3c_nand_set_platdata().
Ben Hutchings (3):
sfc: Include XGXS in XMAC link status check except in XGMII loopback
sfc: QT2025C: Add error message for suspected bad SFP+ cables
sfc: Disable TX descriptor prefetch watchdog
Benjamin Herrenschmidt (2):
PCI/cardbus: Add a fixup hook and fix powerpc
ps3_gelic_wireless: Fix build failure due to missing WEXT_PRIV
Benoit Papillault (1):
ath9k: Last fix for TX software padding.
Bob Copeland (1):
ath5k: fix SWI calibration interrupt storm
Carlos Corbacho (1):
ACPI: WMI: Survive BIOS with duplicate GUIDs
Clemens Ladisch (1):
firewire: fix use of multiple AV/C devices, allow multiple FCP listeners
Csaba Henk (1):
PCI: Handle case when no pci device can provide cache line size hint
Daisuke HATAYAMA (1):
binfmt_elf_fdpic: Fix build breakage introduced by coredump changes.
Dan Carpenter (2):
bond_3ad.c avoid possible null deref
wl1271_cmd.c: cleanup char => u8
Dan Williams (4):
ioat3: fix p-disabled q-continuation
async_tx: expand async raid6 test to cover ioatdma corner case
ioat2,3: put channel hardware in known state at init
md: make recovery started by do_md_run() visible via sync_action
Daniel Drake (1):
Fix MAC address access in 3c507, ibmlana, pcnet32 and libertas
Daniel Mack (1):
Libertas: fix buffer overflow in lbs_get_essid()
David Howells (1):
ext4: Don't ask about supporting ext2/3 in ext4 if ext4 is not configured
David S. Miller (3):
bbc_envctrl: Clean up properly if kthread_run() fails.
sparc64: Fix NMI programming when perf events are active.
sparc64: Fix Niagara2 perf event handling.
Denis Kirjanov (1):
vxge: use DMA_BIT_MASK instead of plain values.
Detlef Riekenberg (1):
vgaarbiter: fix a typo in the vgaarbiter Documentation
Dexuan Cui (3):
PCI: support device-specific reset methods
PCI: add Intel USB specific reset method
PCI: add Intel 82599 Virtual Function specific reset method
Dmitry Torokhov (8):
Input: speed up suspend/shutdown for PS/2 mice and keyboards
Input: serio - do not mark kseriod freezable anymore
Input: ff-memless - another fix for signed to unsigned overflow
Input: iforce - fix oops on device disconnect
Input: matrix-keypad - handle cases when GPIOs can't be wakeup sources
Input: lifebook - add CONFIG_DMI dependency
dell-wmi - fix condition to abort driver loading
Input: iforce - wait for command completion when closing the device
Don Skidmore (1):
ixgbe: fix Need to call pci_save_state after pci_restore_state
Emese Revfy (1):
drbd: Constify struct file_operations
Eric Sandeen (2):
fs-writeback: Add helper function to start writeback if idle
ext4: flush delalloc blocks when space is low
Eric W. Biederman (1):
sysfs: Add lockdep annotations for the sysfs active reference
FUJITA Tomonori (2):
block: remove Documentation/block/as-iosched.txt
x86/agp: Fix agp_amd64_init() initialization with CONFIG_GART_IOMMU enabled
Fang Wenqi (1):
ext4: Update documentation to correct the inode_readahead_blks option name
Felipe Balbi (2):
Input: twl4030_keypad - switch to using threaded IRQ
Input: twl4030-pwrbutton - switch to using threaded IRQ
Felix Fietkau (2):
mac80211: fix ibss join with fixed-bssid
ath9k: fix missed error codes in the tx status check
Frederic Weisbecker (14):
reiserfs: Fix possible recursive lock
reiserfs: Fix reiserfs lock and journal lock inversion dependency
reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion
reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion
perf: Pass appropriate frame pointer to dump_trace()
reiserfs: Fix reiserfs lock <-> i_xattr_sem dependency inversion
reiserfs: Warn on lock relax if taken recursively
reiserfs: Fix reiserfs lock <-> i_mutex dependency inversion on xattr
reiserfs: Relax reiserfs lock while freeing the journal
reiserfs: Relax lock before open xattr dir in reiserfs_xattr_set_handle()
reiserfs: Fix unwanted recursive reiserfs lock in reiserfs_unlink()
reiserfs: Fix journal mutex <-> inode mutex lock inversion
reiserfs: Safely acquire i_mutex from reiserfs_for_each_xattr
reiserfs: Safely acquire i_mutex from xattr_rmdir
Gertjan van Wingerde (5):
rt2x00: Fix rt2800usb detection in rt2800lib.
mac80211: Add define for TX headroom reserved by mac80211 itself.
rt2x00: Disable powersaving for rt61pci and rt2800pci.
rt2x00: Fix calculation of rt2800 iveiv entry offset.
rt2x00: Add USB ID for Linksys WUSB 600N rev 2.
Guennadi Liakhovetski (3):
sh: fix DMA driver's descriptor chaining and cookie assignment
ASoC: fix params_rate() macro use in several codecs
ALSA: Fix indentation in pcm_native.c
Gui Jianfeng (1):
block: blk_rq_err_sectors cleanup
H Hartley Sweeten (3):
drivers/block/mg_disk.c: use resource_size()
Documentation: fix ioremap return type
DocBook: fix ioremap return type
H. Peter Anvin (1):
x86, compress: Force i386 instructions for the decompressor
Heiko Carstens (2):
KVM: get rid of kvm_create_vm() unused label warning on s390
kprobes: Fix distinct type warning
Henrique de Moraes Holschuh (5):
thinkpad-acpi: don't take the first ALSA slot by default
thinkpad-acpi: don't fail to load the entire module due to ALSA problems
thinkpad-acpi: make volume subdriver optional
thinkpad-acpi: update volume subdriver documentation
thinkpad-acpi: improve Kconfig help text
Herbert Xu (1):
hwrng: core - Fix double unlock in rng_dev_read
Huang Weiyi (3):
ext4: remove unused #include <linux/version.h>
drbd: remove duplicated #include
drbd: remove unused #include <linux/version.h>
Hugh Dickins (1):
mm: move sys_mmap_pgoff from util.c
Ingo Molnar (2):
ACPI: fix ACPI=n allmodconfig build
dma-debug: Fix bug causing build warning
Jamal Hadi Salim (1):
net: restore ip source validation
James Bottomley (1):
libsrp: fix compile failure
Jan Glauber (1):
[S390] qdio: convert global statistics to per-device stats
Jan Kiszka (1):
KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates
Jarek Poplawski (1):
net/via-rhine: Fix scheduling while atomic bugs
Jari Vanhala (2):
Input: ff-memless - start playing FF effects immediately
Input: ff-memless - add notion of direction to for rumble effects
Jaswinder Singh Rajput (1):
writeback: add missing kernel-doc notation
Jeff Layton (1):
cifs: NULL out tcon, pSesInfo, and srvTcp pointers when chasing DFS referrals
Jiri Slaby (4):
PCI: fix section mismatch on update_res()
SECURITY: selinux, fix update_rlimit_cpu parameter
resource: move kernel function inside __KERNEL__
resource: add helpers for fetching rlimits
Jiro SEKIBA (1):
nilfs2: trivial coding style fix
Joerg Roedel (1):
x86/amd-iommu: Fix initialization failure panic
Johannes Berg (7):
iwlwifi: fix EEPROM/OTP reading endian annotations and a bug
iwlwifi: fix more eeprom endian bugs
mac80211: fix peer HT capabilities
mac80211: fix WMM AP settings application
wireless: remove remaining qual code
cfg80211: fix race between deauth and assoc response
cfg80211: fix error path in cfg80211_wext_siwscan
John Fastabend (1):
pktgen: ndo_start_xmit can return NET_XMIT_xxx values
John Kacur (1):
sony_pi: Remove the BKL from open and ioctl
John W. Linville (1):
Revert "b43: Enforce DMA descriptor memory constraints"
Julia Lawall (5):
drivers/net/wireless: Correct code taking the size of a pointer
drivers/block/DAC960.c: use DAC960_V2_Controller
drivers/dma: drop unnecesary memset
drivers/dma: Correct use after free
ext4: Eliminate potential double free on error path
Kuninori Morimoto (1):
ASoC: fsi-ak4642: Remove ak4642_add_i2c_device
Kusanagi Kouichi (1):
Documentation: Rename Documentation/DMA-mapping.txt
Lai Jiangshan (3):
tracing/kprobe: Show sign of fields in trace_kprobe format files
tracing/syscalls: Fix typo in SYSCALL_DEFINE0
tracing: Fix sign fields in ftrace_define_fields_##call()
Len Brown (4):
dell-wmi: sys_init_module: 'dell_wmi'->init suspiciously returned 21, it should follow 0/-E convention
ACPI: hp-wmi, msi-wmi: clarify that wmi_install_notify_handler() returns an acpi_status
dell-wmi, hp-wmi, msi-wmi: check wmi_get_event_data() return value
dell-wmi: sys_init_module: 'dell_wmi'->init suspiciously returned 21, it should follow 0/-E convention
Li Zefan (4):
ksym_tracer: Fix to make the tracer work
ksym_tracer: Fix to allow writing newline to ksym_trace_filter
ksym_tracer: Fix race when incrementing count
ksym_tracer: Remove trace_stat
Linus Torvalds (3):
pci: avoid compiler warning in quirks.c
twl4030-irq.c: fix compiler warning due to raw-spinlock conversion
Linux 2.6.33-rc3
Luis R. Rodriguez (4):
ath9k: wake hardware for interface IBSS/AP/Mesh removal
ath9k: wake hardware during AMPDU TX actions
mac80211: fix race with suspend and dynamic_ps_disable_work
mac80211: fix propagation of failed hardware reconfigurations
Manuel Lauss (1):
ASoC: fixup oops in generic AC97 codec glue
Marcelo Tosatti (2):
KVM: MMU: remove prefault from invlpg handler
KVM: LAPIC: make sure IRR bitmap is scanned after vm load
Martin K. Petersen (2):
block: Fix topology stacking for data and discard alignment
block: Fix incorrect alignment offset reporting and update documentation
Martin Schwidefsky (1):
[S390] Update default configuration.
Masami Hiramatsu (1):
x86: Fix objdump version check in chkobjdump.awk for different formats.
Masanari Iida (1):
ALSA: Fix a typo in Procfile.txt
Matthew Slattery (3):
sfc: QT2025C: Work around PHY bug
sfc: QT2025C: Switch into self-configure mode when not in loopback
sfc: QT2025C: Work around PHY firmware initialisation bug
Michael Chan (1):
bnx2x: Initialize cnic status block during chip reset
Mike Travis (2):
x86: SGI UV: Fix writes to led registers on remote uv hubs
x86_64 SGI UV: Fix writes to led registers on remote uv hubs.
Neil Turton (1):
sfc: Fix DMA mapping cleanup in case of an error in TSO
NeilBrown (4):
md: Fix unfortunate interaction with evms
md: fix small irregularity with start_ro module parameter
md: remove unnecessary code from do_md_run
md: allow a resync that is waiting for other resync to complete, to be aborted.
Nicolas Ferre (1):
dma: at_hdmac: correct incompatible type for argument 1 of 'spin_lock_bh'
OGAWA Hirofumi (1):
block: Honor the gfp_mask for alloc_page() in blkdev_issue_discard()
Paul Mundt (4):
sh: Only provide a PCLK definition for legacy CPG CPUs.
sh: Disable PMB for SH4AL-DSP CPUs.
sh: Don't default enable PMB support.
sh: update defconfigs.
Paul Rolland (2):
wmi: check find_guid() return value to prevent oops
wmi: check find_guid() return value to prevent oops
Pekka Enberg (3):
x86: Use KERN_DEFAULT log-level in __show_regs()
x86, kmemcheck: Use KERN_WARNING for error reporting
SLAB: Fix lockdep annotation breakage
Peter Huewe (1):
ALSA: sound/arm: Fix build failure caused by missing struct aaci definition
Peter Zijlstra (1):
perf: Fix NULL deref in inheritance code
Rafael J. Wysocki (2):
PCI/PM: Propagate wake-up enable for PCIe devices too
PCI: Fix build if quirks are not enabled
Rakib Mullick (1):
Input: wistron - fix test for CONFIG_PM
Ralf Baechle (1):
NET: XFRM: Fix spelling of neighbour.
Randy Dunlap (4):
Documentation: Update mmiotrace.txt
Documentation: Update tracepoint-analysis.txt
Documentation: Update ftrace-design.txt
tracing: Kconfig spelling fixes and cleanups
Reinette Chatre (4):
iwlwifi: power up all devices for EEPROM read
iwl3945: disable power save
iwlwifi: initialize spinlock before use
iwlwifi: fix 40MHz operation setting on cards that do not allow it
Ren? Bolldorf (1):
Input: psmouse - fix compile warning in hgpk module
Richard Kennedy (1):
ext4: return correct wbc.nr_to_write in ext4_da_writepages
Robert P. J. Day (1):
[S390] Have param.h simply include <asm-generic/param.h>.
Roel Kluin (4):
drbd: fix test of unsigned in _drbd_fault_random()
drbd: Fix test of unsigned in _drbd_fault_random()
iwmc3200wifi: Fix test of unsigned in iwm_ntf_stop_resume_tx()
wl1251: timeout one too soon in wl1251_boot_run_firmware()
Rolf Eike Beer (1):
kfifo: Fix typo in comment
Rusty Russell (2):
lguest: fix bug in setting guest GDT entry
Revert "x86: Side-step lguest problem by only building cmpxchg8b_emu for pre-Pentium"
Ryusuke Konishi (1):
nilfs2: update mailing list address
Samuel Ortiz (1):
libertas: Remove carrier signaling from the scan code
Sandeep Gopalpet (1):
gianfar: Fix gianfar select_queue bogosity
Sarveshwar Bandi (3):
be2net: Bug fix to avoid soft lockup in loopback test.
be2net: Bug fix to config NIC appropriately before loopback test
be2net: Bug fix to return correct values in ethtool get_settings.
Serge E. Hallyn (1):
generic_permission: MAY_OPEN is not write access
Shaohua Li (1):
cfq-iosched: don't regard requests with long distance as close
Shaun Ruffell (1):
dma-debug: Do not add notifier when dma debugging is disabled.
Sheng Yang (1):
KVM: Fix possible circular locking in kvm_vm_ioctl_assign_device()
Stefan Assmann (2):
PCI: change PCI nomenclature in drivers/pci/ (comment changes)
PCI: change PCI nomenclature in drivers/pci/ (non-comment changes)
Stefan Richter (4):
firewire: cdev: fix another memory leak in an error path
firewire: ohci: always use packet-per-buffer mode for isochronous reception
firewire, ieee1394: update MAINTAINERS entries
firewire, ieee1394: update Kconfig help
Steve French (1):
[CIFS] Enable mmap on forcedirectio mounts
Steve Hodgson (1):
sfc: Move PHY software state initialisation from init() into probe()
Steven Rostedt (1):
tracing: Fix setting tracer specific options
Sujith (4):
ath9k: Fix bug in assigning sequence number
ath9k: Fix TX queue draining
ath9k: Stop ANI when doing a reset
ath9k: fix suspend by waking device prior to stop
Surbhi Palande (1):
ext4: replace BUG() with return -EIO in ext4_ext_get_blocks
Takashi Iwai (4):
ALSA: hda - Disable tigger at pin-sensing on AD codecs
ALSA: hda - use snd_hda_jack_detect() again in patch_sigmatel.c
ALSA: hda - Don't cache beep controls
ALSA: hda - Fix Oops at reloading beep devices
Tao Ma (1):
ocfs2: Handle O_DIRECT when writing to a refcounted cluster.
Theodore Ts'o (5):
ext4: add module aliases for ext2 and ext3
ext4, jbd2: Add barriers for file systems with exernal journals
ext4: Patch up how we claim metadata blocks for quota purposes
ext4: Fix accounting of reserved metadata blocks
ext4: Calculate metadata requirements more accurately
Tim Blechmann (1):
perf: Rename perf_event_hw_event in design document
Tobias Klauser (3):
nilfs2: Storage class should be before const qualifier
ath9k: Storage class should be before const qualifier
iwlwifi: Storage class should be before const qualifier
Tony Luck (1):
KVM: ia64: fix build breakage due to host spinlock change
Vitaliy Gusev (1):
tun: use tun_sk instead container_of
Vivek Goyal (3):
cfq-iosched: Remove the check for same cfq group from allow_merge
cfq-iosched: Get rid of nr_groups
cfq-iosched: Remove prio_change logic for workload selection
Wenji Huang (1):
perf kmem: Fix statistics typo
Wey-Yi Guy (1):
iwlwifi: fix syslog message for event log dump size
Williams, Mitch A (1):
igbvf: Make igbvf error message more informative
Wu Fengguang (1):
ALSA: hda - HDMI sticky stream tag support
Zhang Rui (3):
ACPI video: no warning message if "acpi_backlight=vendor" is used
ACPI video: correct error-handling code
ACPI: introduce kernel parameter acpi_sleep=sci_force_enable
Zhu Yi (3):
iwlwifi: allocated rx page accounting cleanup
iwl3945: fix panic in iwl3945 driver
iwmc3200wifi: fix array out-of-boundary access
[email protected] (1):
drivers/net/wireless/iwlwifi/iwl-tx.c: fix gcc-3.4.5 warning
On Tuesday 05 January 2010, Linus Torvalds wrote:
>It's been quiet due to the holidays, so -rc3 is reasonably small despite
>being a few days over the normal one-week mark. And most of the changes
>are pretty trivial, although both ext4 and reiserfs had some trouble in
>-rc2, hopefully all fixed now.
>
>The bulk of the patches are some SH defconfig updates (40%), but ignoring
>those we have the normal "half drivers, half everything else" pattern. On
>the driver front, the perhaps most notable change is not so much a code
>change, but the small change of marking the "new" firewire stack as being
>the recommended one.
>
>Wireless drivers, regular network drivers, filesystems, input layer..
>
>And here's to hoping one reason it's been quiet is that it's actually been
>fairly stable. Give it a try,
>
> Linus
[...]
I didn't see anything here, but on looking at the ChangeLog for rc1, I see a
lot of stuff fiddling with firmware. On my phenom x4, I get this very early in
the boot:
[ 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.
--
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)
Insomnia isn't anything to lose sleep over.
On Tuesday 05 January 2010, Gene Heskett wrote:
Ping?
>On Tuesday 05 January 2010, Linus Torvalds wrote:
>>It's been quiet due to the holidays, so -rc3 is reasonably small despite
>>being a few days over the normal one-week mark. And most of the changes
>>are pretty trivial, although both ext4 and reiserfs had some trouble in
>>-rc2, hopefully all fixed now.
>>
>>The bulk of the patches are some SH defconfig updates (40%), but ignoring
>>those we have the normal "half drivers, half everything else" pattern. On
>>the driver front, the perhaps most notable change is not so much a code
>>change, but the small change of marking the "new" firewire stack as being
>>the recommended one.
>>
>>Wireless drivers, regular network drivers, filesystems, input layer..
>>
>>And here's to hoping one reason it's been quiet is that it's actually been
>>fairly stable. Give it a try,
>>
>> Linus
>
>[...]
>
>I didn't see anything here, but on looking at the ChangeLog for rc1, I see
> a lot of stuff fiddling with firmware. On my phenom x4, I get this very
> early in the boot:
>[ 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.
--
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)
Far duller than a serpent's tooth it is to spend a quiet youth.
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?
--
Jiri Kosina
SUSE Labs, Novell Inc.
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
--
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)
"Just the facts, Ma'am"
-- Joe Friday
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.
--
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)
Good day for a change of scene. Repaper the bedroom wall.
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
Jan 6 13:37:23 roadwarrior3 kernel: dracut: dracut-002-13.4.git8f397a9b.fc12
Jan 6 13:37:23 roadwarrior3 kernel: platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
Jan 6 13:37:23 roadwarrior3 kernel: dracut: Starting plymouth daemon
Jan 6 13:37:23 roadwarrior3 kernel: dracut: Mounted root filesystem /dev/sda6
Jan 6 13:37:23 roadwarrior3 kernel: dracut: Loading SELinux policy
Jan 6 13:37:23 roadwarrior3 kernel: dracut: Switching root
Jan 6 13:37:23 roadwarrior3 kernel: ipw2200 0000:02:04.0: firmware: requesting ipw2200-bss.fw
Jan 6 13:37:23 roadwarrior3 kernel: platform microcode: firmware: requesting intel-ucode/06-0d-06
On Monday 11 January 2010, Bill Davidsen wrote:
>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?
I believe, since your snip has syslog timestamps, that you are looking at a
considerably later event that obviously has to do with an ATI radeon video
facility. Those reports I see at about the 40 second point in my dmesg.
This lockup occurs at .64 to .65 seconds in the dmesg as displayed on the
console (I never run 'quiet' here).
Perhaps I have what one could call a broken partitioning setup here, but when
the original drive failed, and I copied everything I could get from the old
one onto a freshly partitioned drive, partitioned to suit me, I now may have
something mussed up, but the system is now at least 3x faster and has stayed
that way compared to before the drive failure. Here is my current
partitioning for the physical drive containing this F10 install on a
terrabyte drive:
/dev/sda3 on / type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
/dev/sda5 on /opt type ext3 (rw)
/dev/sda6 on /home type ext3 (rw)
/dev/sda7 on /root type ext3 (rw)
/dev/sda8 on /var type ext3 (rw)
/dev/sda9 on /tmp type ext3 (rw)
/dev/sda10 on /usr type ext3 (rw)
/dev/sda2 is swap, which I always put at an outside, faster location on the
drive _if_ the choice is mine.
Which is a far cry from the drive mapping and partition size limits that the
fedora installer forces on the hapless user. 199 megs max for /boot? What ARE
they smoking?
I have serious doubts that /dev/sda3, where /lib/firmware lives, has been
mounted and is accessible .65 seconds after dmesg's timekeeping starts.
10+ seconds maybe, but .65 seconds? Nuh uh. The first mention of anything
related to sata is:
[ 0.685767] sata_nv 0000:00:05.0: version 3.5
A good .03 seconds after the microcode is found and applied in this sequence:
[ 0.651404] platform microcode: firmware: using built-in firmware amd-
ucode/microcode_amd.bin
[ 0.651623] microcode: CPU0: patch_level=0x1000065
[ 0.651743] microcode: CPU1: patch_level=0x1000065
[ 0.651866] microcode: CPU2: patch_level=0x1000065
[ 0.651986] microcode: CPU3: patch_level=0x1000065
[ 0.652139] microcode: Microcode Update Driver: v2.00
<[email protected]>, Peter Oruba
Note it says using built in, if it is not built in, there is a 60 second hang
there in post 2.6.32.3 kernels apparently because it can't find
/lib/firmware.
But I'll repeat, kernels up to 2.6.32.2 at least, have no problems with that
code module not being built into the kernel's bzImage, it finds it on the
drive and applies it instantly at that same .65 seconds from starting the
clock time to counting.
I have fixed my buildit26 script to copy that code module to the kernel trees
own firmware tree, and have included it in the list of firmware in the
.config file to be included in the kernel, although make xconfig is now
broken for editing that and I have to do that by hand with vim. But I
believe it works as shown above.
When -rc4 is out, I'll comment those lines out of that script and test it,
but I expect I'll have to un-comment them and rebuild the tree again.
No biggie to me, but its a niggle a new user might find as a good excuse to
go back to (spit) vista. So IMO it needs to be addressed, but I'm not _that_
good at code carving on these bigger machines at 75 yo , sorry. My day was
15-30 years ago on kit boards, color computers running os9 and amiga's.
I do play the canary in the coal mine reasonably well though, exactly the
part I'm playing right now. ;-)
Thanks Bill & Jiri.
--
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)
Perl has a long tradition of working around compilers.
-- Larry Wall in <[email protected]>
Gene Heskett wrote:
> On Monday 11 January 2010, Bill Davidsen wrote:
> > 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?
>
> I believe, since your snip has syslog timestamps, that you are
> looking at a considerably later event that obviously has to do with
> an ATI radeon video facility. Those reports I see at about the 40
> second point in my dmesg.
>
It is clearly later, but why? That is, I looked at every single line
related to mount or firmware and those are all I found. Not just the
last I found, but all, everything. So why does your system look for
firmware early? I checked my dual core Athlon boot, and although that's
not the boot I attached, I see the same thing, firmware after pivot root.
I think if we understand that other things will become clear.
> This lockup occurs at .64 to .65 seconds in the dmesg as displayed on
> the console (I never run 'quiet' here).
>
> Perhaps I have what one could call a broken partitioning setup here,
> but when the original drive failed, and I copied everything I could
> get from the old one onto a freshly partitioned drive, partitioned to
> suit me, I now may have something mussed up, but the system is now at
> least 3x faster and has stayed that way compared to before the drive
> failure. Here is my current partitioning for the physical drive
> containing this F10 install on a terrabyte drive:
>
> /dev/sda3 on / type ext3 (rw) /dev/sda1 on /boot type ext3 (rw)
> /dev/sda5 on /opt type ext3 (rw) /dev/sda6 on /home type ext3 (rw)
> /dev/sda7 on /root type ext3 (rw) /dev/sda8 on /var type ext3 (rw)
> /dev/sda9 on /tmp type ext3 (rw) /dev/sda10 on /usr type ext3 (rw)
>
> /dev/sda2 is swap, which I always put at an outside, faster location
> on the drive _if_ the choice is mine.
>
> Which is a far cry from the drive mapping and partition size limits
> that the fedora installer forces on the hapless user. 199 megs max
> for /boot? What ARE they smoking?
>
> I have serious doubts that /dev/sda3, where /lib/firmware lives, has
> been mounted and is accessible .65 seconds after dmesg's timekeeping
> starts. 10+ seconds maybe, but .65 seconds? Nuh uh. The first
> mention of anything related to sata is: [ 0.685767] sata_nv
> 0000:00:05.0: version 3.5
>
> A good .03 seconds after the microcode is found and applied in this
> sequence:
>
> [ 0.651404] platform microcode: firmware: using built-in firmware
> amd- ucode/microcode_amd.bin [ 0.651623] microcode: CPU0:
> patch_level=0x1000065 [ 0.651743] microcode: CPU1:
> patch_level=0x1000065 [ 0.651866] microcode: CPU2:
> patch_level=0x1000065 [ 0.651986] microcode: CPU3:
> patch_level=0x1000065 [ 0.652139] microcode: Microcode Update
> Driver: v2.00 <[email protected]>, Peter Oruba
>
> Note it says using built in, if it is not built in, there is a 60
> second hang there in post 2.6.32.3 kernels apparently because it
> can't find /lib/firmware.
>
> But I'll repeat, kernels up to 2.6.32.2 at least, have no problems
> with that code module not being built into the kernel's bzImage, it
> finds it on the drive and applies it instantly at that same .65
> seconds from starting the clock time to counting.
>
> I have fixed my buildit26 script to copy that code module to the
> kernel trees own firmware tree, and have included it in the list of
> firmware in the .config file to be included in the kernel, although
> make xconfig is now broken for editing that and I have to do that by
> hand with vim. But I believe it works as shown above.
>
I confess when I have had a problem like that I have unpacked the
initrd, fixed it and repacked. That may not be possible currently, I
haven't had to do it since 2.5.xx days, but it has the advantage of
lending itself to a script. ;-)
> When -rc4 is out, I'll comment those lines out of that script and
> test it, but I expect I'll have to un-comment them and rebuild the
> tree again.
>
> No biggie to me, but its a niggle a new user might find as a good
> excuse to go back to (spit) vista. So IMO it needs to be addressed,
> but I'm not _that_ good at code carving on these bigger machines at
> 75 yo , sorry. My day was 15-30 years ago on kit boards, color
> computers running os9 and amiga's.
>
> I do play the canary in the coal mine reasonably well though, exactly
> the part I'm playing right now. ;-)
>
On the off chance I'll see something I'll look at the other laptop boot
again. With the kernels which did work, was the firmware loaded that
early, or has something been changed to cause that early load? Like
someone diddling the kernel compile options, maybe?
--
Bill Davidsen <[email protected]>
"We can't solve today's problems by using the same thinking we
used in creating them." - Einstein