linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 2.6.33-rc3
@ 2010-01-06  2:48 Linus Torvalds
  2010-01-06  4:55 ` Linux 2.6.33-rc3, rc2 regression at boot Gene Heskett
  0 siblings, 1 reply; 10+ messages in thread
From: Linus Torvalds @ 2010-01-06  2:48 UTC (permalink / raw)
  To: Linux Kernel Mailing List


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

akpm@linux-foundation.org (1):
      drivers/net/wireless/iwlwifi/iwl-tx.c: fix gcc-3.4.5 warning

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot
  2010-01-06  2:48 Linux 2.6.33-rc3 Linus Torvalds
@ 2010-01-06  4:55 ` Gene Heskett
  2010-01-06 21:02   ` Gene Heskett
  0 siblings, 1 reply; 10+ messages in thread
From: Gene Heskett @ 2010-01-06  4:55 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot
  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
  0 siblings, 1 reply; 10+ messages in thread
From: Gene Heskett @ 2010-01-06 21:02 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot
  2010-01-06 21:02   ` Gene Heskett
@ 2010-01-06 23:55     ` Jiri Kosina
  2010-01-07  0:36       ` Gene Heskett
  0 siblings, 1 reply; 10+ messages in thread
From: Jiri Kosina @ 2010-01-06 23:55 UTC (permalink / raw)
  To: Gene Heskett; +Cc: Linus Torvalds, Linux Kernel Mailing List

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot
  2010-01-06 23:55     ` Jiri Kosina
@ 2010-01-07  0:36       ` Gene Heskett
  2010-01-07 15:35         ` Gene Heskett
  0 siblings, 1 reply; 10+ messages in thread
From: Gene Heskett @ 2010-01-07  0:36 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot
  2010-01-07  0:36       ` Gene Heskett
@ 2010-01-07 15:35         ` Gene Heskett
  2010-01-07 16:25           ` Linux 2.6.33-rc3, rc2 regression at boot FIXED Gene Heskett
  0 siblings, 1 reply; 10+ messages in thread
From: Gene Heskett @ 2010-01-07 15:35 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Linux Kernel Mailing List

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot FIXED
  2010-01-07 15:35         ` Gene Heskett
@ 2010-01-07 16:25           ` Gene Heskett
  2010-01-11 23:21             ` Bill Davidsen
  0 siblings, 1 reply; 10+ messages in thread
From: Gene Heskett @ 2010-01-07 16:25 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot FIXED
  2010-01-07 16:25           ` Linux 2.6.33-rc3, rc2 regression at boot FIXED Gene Heskett
@ 2010-01-11 23:21             ` Bill Davidsen
  2010-01-12  0:22               ` Gene Heskett
  0 siblings, 1 reply; 10+ messages in thread
From: Bill Davidsen @ 2010-01-11 23:21 UTC (permalink / raw)
  To: Gene Heskett; +Cc: Jiri Kosina, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 5093 bytes --]

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@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[-- Attachment #2: boot-grep.txt --]
[-- Type: text/plain, Size: 648 bytes --]

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot FIXED
  2010-01-11 23:21             ` Bill Davidsen
@ 2010-01-12  0:22               ` Gene Heskett
  2010-01-12  5:10                 ` Bill Davidsen
  0 siblings, 1 reply; 10+ messages in thread
From: Gene Heskett @ 2010-01-12  0:22 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Jiri Kosina, Linux Kernel Mailing List

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 
<tigran@aivazian.fsnet.co.uk>, 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 <199708252256.PAA00105@wall.org>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Linux 2.6.33-rc3, rc2 regression at boot FIXED
  2010-01-12  0:22               ` Gene Heskett
@ 2010-01-12  5:10                 ` Bill Davidsen
  0 siblings, 0 replies; 10+ messages in thread
From: Bill Davidsen @ 2010-01-12  5:10 UTC (permalink / raw)
  To: Gene Heskett; +Cc: Jiri Kosina, Linux Kernel Mailing List

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 <tigran@aivazian.fsnet.co.uk>, 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 <davidsen@tmr.com>
  "We can't solve today's problems by using the same thinking we
   used in creating them." - Einstein


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2010-01-12  5:10 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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           ` Linux 2.6.33-rc3, rc2 regression at boot FIXED Gene Heskett
2010-01-11 23:21             ` Bill Davidsen
2010-01-12  0:22               ` Gene Heskett
2010-01-12  5:10                 ` Bill Davidsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).