So I said -rc6 would likely be the last -rc, and nothing happened to
change my mind. I'd always be happier if it had been an even quieter
week, but the appended Shortlog of changes since rc6 doesn't contain
anything earthshaking, and I don't think we'd have been any better off
by another rc, and waiting one more week. So 2.6.35 is out, go check
it out.
This may have been a fairly odd release cycle with my rather strict
-rc rules before -rc3, but on the whole I think I liked it, and it
seems to have worked out ok. I relaxed my extreme stance after getting
back from vacation, so the latter half of the rc series was more
normal. But even then I got the feeling that people were perhaps a bit
more aware of the whole "regression fixes only" model, which is all
good. It's a bit hard to judge, but there are some numbers to back it
up: in the 2.6.34 release, there were 3800 commits after -rc1, but in
the current 35 release cycle we had less than 2000.
Now, admittedly 34 was worse than average in that respect (3800
commits is a _lot_ of work after -rc1), but git history says that at
least going back to 2.6.24, we've never had less than 2000 commits
after -rc1 before now. They tend to be in the 2700-3200 commit range.
So I do think we really did have a lot less churn than usual
post-merge-window. And that's good.
So I'd like to try to repeat the experiment for the next release
cycle, and be pretty hardnosed about taking patches and git pull
requests after the merge window closes.
Talking about the next merge window: Andrew Morton was pretty unhappy
with the stability of linux-next at least a couple of weeks ago. It's
what he bases his -mm trees on, and so an unstable linux-next makes it
hard for Andrew to get his work done. It also makes me worried,
because a lot of people seem to think that "it's been in linux-next
for several months" means that something can and should be merged. And
if linux-next ends up being really flaky, that clearly cannot be the
case.
So guys - please don't treat linux-next as a dumping ground. Things
that go in there should be more or less ready for merging (with an
emphasis on "more"), and we need to keep that tree in working order.
If you're nervous about the stability of your work, you should just
admit that it's not ready to be merged, shouldn't go in the next
release cycle, and shouldn't be in linux-next yet and make life harder
for people like Andrew - or for the other more careful linux-next
submitters.
On a slightly happier note: one thing I do hope we can merge in the
upcoming merge window is Nick Piggin's cool VFS scalability series.
I've been using it on my own machine, and gone through all the commits
(not that I shouldn't go through some of them some more), and am
personally really excited about it. It's seldom we see major
performance improvements in core code that are quite that noticeable,
and Nick's whole RCU pathname lookup in particular just tickles me
pink.
Anything else? I'm sure there's tons of things I should say about what
went into 2.6.35, but as usual there are already better writeups about
what has changed. Things like the kernelnewbies pages etc. So head off
to
http://kernelnewbies.org/Linux_2_6_35
for some overviews of the things that changed this time around. Or
just download the kernel from the regular places, and give it a test.
Linus
---
Adam Jackson (2):
drm/i915: Make G4X-style PLL search more permissive
drm/edid: Fix the HDTV hack sync adjustment
Adam Lackorzynski (1):
x86, i8259: Only register sysdev if we have a real 8259 PIC
Alex Chiang (1):
ACPI: processor: fix processor_physically_present on UP
Alexey Shvetsov (1):
wimax/i2400m: Add PID & VID for Intel WiMAX 6250
Andre Osterhues (1):
ecryptfs: Bugfix for error related to ecryptfs_hash_buckets
Andrea Shepard (1):
net: Fix corruption of skb csum field in pskb_expand_head() of
net/core/skbuff.c
Andrej Gelenberg (1):
[CPUFREQ] revert "[CPUFREQ] remove rwsem lock from
CPUFREQ_GOV_STOP call (second call site)"
Andrew Bird (1):
USB: New PIDs for Qualcomm gobi 2000 (qcserial)
Andy Gospodarek (1):
ixgbe/igb: catch invalid VF settings
Anton Blanchard (2):
powerpc/mm: Handle hypervisor pte insert failure in __hash_page_huge
[SCSI] ibmvscsi: Fix oops when an interrupt is pending during probe
Anton Vorontsov (1):
edac: mpc85xx: fix coldplug/hotplug module autoloading
Anuj Aggarwal (1):
regulator: tps6507x: allow driver to use DEFDCDC{2,3}_HIGH register
Arnaldo Carvalho de Melo (1):
perf annotate: Fix handling of goto labels that are valid hex numbers
Avi Kivity (1):
KVM: Use kmalloc() instead of vmalloc() for KVM_[GS]ET_MSR
Axel Lin (2):
ab3100: fix off-by-one value range checking for voltage selector
wm8350-regulator: fix wm8350_register_regulator error handling
Ben Greear (1):
net: dev_forward_skb should call nf_reset
Ben Hutchings (1):
MIPS: Set io_map_base for several PCI bridges lacking it
Benjamin Herrenschmidt (4):
powerpc/mm: Move around testing of _PAGE_PRESENT in hash code
powerpc/mm: Fix bugs in huge page hashing
powerpc/mm: Add some debug output when hash insertion fails
powerpc: Fix erroneous lmb->memblock conversions
Bob Copeland (1):
USB: usb-storage: fix initializations of urb fields
Borislav Petkov (1):
[CPUFREQ] powernow-k8: Limit Pstate transition latency check
Breno Leitao (1):
s2io: fixing DBG_PRINT() macro
Brian Haley (1):
ipv6: Don't add routes to ipv6 disabled interfaces.
Bruno Randolf (1):
MIPS: MTX-1: Fix PCI on the MeshCube and related boards
Catalin Marinas (3):
ARM: 6271/1: Introduce *_relaxed() I/O accessors
ARM: 6272/1: Convert L2x0 to use the IO relaxed operations
ARM: 6273/1: Add barriers to the I/O accessors if ARM_DMA_MEM_BUFFERABLE
Chris Wilson (4):
drm/i915: Explosion following OOM in do_execbuffer.
drm/i915: Clear any existing dither mode prior to enabling
spatial dithering
drm/i915: Use the correct scanout alignment for fbcon.
drm/i915: Fix panel fitting regression since 734b4157
Christof Schmitt (2):
[SCSI] zfcp: Do not wait for SBALs on stopped queue
[SCSI] zfcp: Update status read mempool
Colin Leitner (1):
USB: ftdi_sio: support for Signalyzer tools based on FTDI chips
Conny Seidel (1):
perf tools: Fix fallback to cplus_demangle() when bfd_demangle()
is not available
Corey Minyard (1):
USB: FTDI: Add support for the RT System VX-7 radio programming cable
Dan Carpenter (1):
nfs: include space for the NUL in root path
Daniel J Blueman (3):
quiesce EDAC initialisation on desktop/mobile i7
[CPUFREQ] fix double freeing in error path of pcc-cpufreq
drm/radeon/kms: fix radeon mid power profile reporting
David Daney (3):
MIPS: "Fix" useless 'init_vdso successfully' message.
MIPS: Make init_vdso a subsys_initcall.
MIPS: Quit using undefined behavior of ADDU in 64-bit atomic operations.
David Howells (3):
CRED: Fix get_task_cred() and task_state() to not resurrect dead
credentials
CRED: Fix __task_cred()'s lockdep check and banner comment
CIFS: Remove __exit mark from cifs_exit_dns_resolver()
David S. Miller (1):
net: Fix skb_copy_expand() handling of ->csum_start
David VomLehn (1):
MIPS: PowerTV: Move register setup to before reading registers.
Dennis Jansen (1):
USB: option: Add support for AMOI Skypephone S2
Dmitry Torokhov (1):
Input: RX51 keymap - fix recent compile breakage
Eric Miao (3):
[ARM] pxa/corgi: fix MMC/SD card detection failure
[ARM] pxa: fix incorrect order of AC97 reset pin configs
[ARM] pxa: fix incorrect CONFIG_CPU_PXA27x to CONFIG_PXA27x
Eric W. Biederman (4):
Driver-core: Always create class directories for classses that
support namespaces.
sysfs: Don't allow the creation of symlinks we can't remove
sysfs: sysfs_delete_link handle symlinks from untagged to tagged
directories.
sysfs: allow creating symlinks from untagged to tagged directories
Felipe Balbi (1):
USB: musb: tusb6010: fix compile error with n8x0_defconfig
Florian Fainelli (1):
MIPS: BCM63xx: Prevent second enet registration on BCM6338
Frederic Weisbecker (1):
perf: Fix various display bugs with parent filtering
Gary King (1):
ARM: 6279/1: highmem: fix SMP preemption bug in kmap_high_l1_vipt
Greg Edwards (1):
bonding: set device in RLB ARP packet handler
Gui Jianfeng (1):
perf symbols: Fix directory descriptor leaking
Heiko Carstens (1):
[S390] Fix IRQ tracing in case of PER
Herbert Xu (1):
macvtap: Limit packet queue length
Hugh Dickins (1):
mm: fix ia64 crash when gcore reads gate area
Jason Baron (1):
dynamic debug: move ddebug_remove_module() down into free_module()
Jason Wessel (1):
x86,kgdb: Fix hw breakpoint regression
Jeremy Kerr (5):
ARM: 6258/1: arm/h720x: fix debug macro compilation failure
ARM: 6259/1: arm/ns9xxx: fix debug macro compilation failure
ARM: 6260/1: arm/plat-spear: fix debug macro compilation failure
ARM: 6261/1: arm/shark: fix debug macro compilation failure
ARM: 6262/1: arm/clps711x: fix debug macro compilation failure
Jesse Barnes (8):
drm/i915: handle shared framebuffers when flipping
drm/i915: add PANEL_UNLOCK_REGS definition
drm/i915: make sure eDP panel is turned on
drm/i915: disable FBC when more than one pipe is active
drm/i915: don't free non-existent compressed llb on ILK+
drm/i915: fix deadlock in fb teardown
drm/i915: add pipe A force quirks to i915 driver
drm/i915: make sure we shut off the panel in eDP configs
John W. Linville (1):
wireless: use netif_rx_ni in ieee80211_send_layer2_update
Jon Povey (1):
gpio: fix spurious printk when freeing a gpio
Julia Lawall (1):
SA1111: Eliminate use after free
KOSAKI Motohiro (1):
ACPI: fix unused function warning
Kumar Gala (1):
powerpc/kexec: Fix boundary case for book-e kexec memory limits
Latchesar Ionkov (1):
9p: Pass the correct end of buffer to p9stat_read
Len Brown (3):
ACPI: handle systems which asynchoronously enable ACPI mode
ACPI: skip checking BM_STS if the BIOS doesn't ask for it
ACPI: create "processor.bm_check_disable" boot param
Linus Torvalds (1):
Linux 2.6.35
Magnus Damm (1):
ARM: 6270/1: clean files in arch/arm/boot/compressed/
Marek Vasut (2):
[ARM] pxa: cpufreq-pxa2xx: fix DRI recomputation routine
[ARM] pxa: fix frequency scaling for pcmcia/pxa2xx_base
Martin Schwidefsky (1):
[S390] etr: fix clock synchronization race
Matthew Garrett (2):
[CPUFREQ] pcc driver should check for pcch method before calling _OSC
[CPUFREQ] Fix PCC driver error path
Michael S. Tsirkin (2):
tun: avoid BUG, dump packet on GSO errors
virtio: fix oops on OOM
Michal Marek (1):
kbuild: Fix make rpm
Michał Górny (1):
kbuild: Make the setlocalversion script POSIX-compliant
Ming Lei (1):
ath9k: fix dma direction for map/unmap in ath_rx_tasklet
Nik A. Melchior (1):
ACPI video: fix string mismatch for Sony SR290 laptop
Oliver Neukum (2):
USB: sisusbvga: Fix for USB 3.0
USB: add quirk for Broadcom BT dongle
Ondrej Zary (2):
cyber2000fb: fix machine hang on module load
cyber2000fb: fix console in truecolor modes
Paul Mortier (1):
USB: adds Artisman USB dongle to list of quirky devices
Peter Huewe (2):
ds2782_battery: Rename get_current to fix build failure / name conflict
serial: fix rs485 for atmel_serial on avr32
Peter Zijlstra (1):
perf, powerpc: Use perf_sample_data_init() for the FSL code
Przemo Firszt (1):
USB: Expose vendor-specific ACM channel on Nokia 5230
Rabin Vincent (1):
ARM: 6275/1: ux500: don't use writeb() in uncompress.h
Rafael J. Wysocki (1):
ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAM
Rajiv Andrade (1):
tpm_tis: fix subsequent suspend failures
Ralf Baechle (7):
VIDEO. gbefb: Fix section mismatches.
NET: declance: Fix section mismatches
VIDEO: PMAG-BA: Fix section mismatch
VIDEO: PMAGB-B: Fix section mismatch
VIDEO: Au1100fb: Fix section mismatch
SOUND: Au1000: Fix section mismatch
MIPS: N32: Define getdents64.
Robert P. J. Day (1):
ceph: Correct obvious typo of Kconfig variable "CRYPTO_AES"
Rudolf Marek (1):
drivers/rtc/rtc-rx8581.c: fix setdatetime
Russell King (3):
ARM: Fix csum_partial_copy_from_user()
ARM: Add barriers to io{read,write}{8,16,32} accessors as well
ARM: Fix Versatile/Realview/VExpress MMC card detection sense
Sage Weil (5):
ceph: avoid dcache readdir for snapdir
ceph: fix d_release dop for snapdir, snapped dentries
ceph: fix pg_mapping leak on pg_temp updates
ceph: fix leak of dentry in ceph_init_dentry() error path
ceph: fix dentry lease release
Sam Ravnborg (2):
tracing: Properly align linker defined symbols
vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)
Sarah Sharp (4):
USB: xHCI: Fix another bug in link TRB activation change.
USB: Fix USB3.0 Port Speed Downgrade after port reset
USB: xhci: Set EP0 dequeue ptr after reset of configured device.
USB: xhci: Set Mult field in endpoint context correctly.
Sekhar Nori (1):
davinci: da850/omap-l138 evm: account for DEFDCDC{2,3} being tied high
Stefano Stabellini (1):
x86: Do not try to disable hpet if it hasn't been initialized before
Stephen Boyd (1):
nconfig: Fix segfault when help contains special characters
Steven Whitehouse (1):
GFS2: Use kmalloc when possible for ->readdir()
Swen Schillig (1):
[SCSI] zfcp: Fix check whether unchained ct_els is possible
Takashi Iwai (4):
ALSA: hda - Fix pin-detection of Nvidia HDMI
ALSA: hda - Don't register beep input device when no beep is available
ALSA: hda - Assume PC-beep as default for Realtek
ALSA: hda - Add a PC-beep workaround for ASUS P5-V
Thomas Bächler (1):
gpu/drm/i915: Add a blacklist to omit modeset on LID open
Tim Gardner (1):
agp/intel: Use the correct mask to detect i830 aperture size.
Trond Myklebust (3):
NFS: kswapd must not block in nfs_release_page
NFS: Ensure that writepage respects the nonblock flag
NFS: Fix a typo in include/linux/nfs_fs.h
Uwe Kleine-König (2):
ARM: 6263/1: ns9xxx: fix FTBFS for zImage
ARM: 6265/1: kirkwood: move qnap_tsx1x_register_flash() to .init.text
Vladimir Zapolskiy (1):
USB: s3c2410_udc: be aware of connected gadget driver
Vladislav Zolotarov (3):
bnx2x: Protect a SM state change
bnx2x: Protect statistics ramrod and sequence number
bnx2x: Advance a module version
Wayne Boyer (1):
[SCSI] ipr: fix resource path display and formatting
Wim Van Sebroeck (1):
watchdog: update MAINTAINERS entry
Wolfgang Grandegger (1):
MIPS: Alchemy: Define eth platform devices in the correct order
Xiao Guangrong (1):
KVM: MMU: fix conflict access permissions in direct sp
Xiaotian Feng (1):
[CPUFREQ] fix memory leak in cpufreq_add_dev
Yehuda Sadeh (1):
ceph: use complete_all and wake_up_all
Zhang Rui (1):
ACPI battery: don't invoke power_supply_changed twice when
battery is hot-added
august huber (1):
USB: Add PID for Sierra 250U to drivers/usb/serial/sierra.c
pieterg (1):
[ARM] pxa/colibri-pxa300: fix AC97 init
stephen hemminger (1):
net sched: fix race in mirred device removal
wanzongshun (2):
ARM: 6230/1: fix nuc900 touchscreen clk definition bug
ARM: 6233/1: Delete a wrong redundant right parenthesis
Ömer Sezgin Ugurlu (1):
USB: option: add support for 1da5:4518
Hi all,
On Sun, 1 Aug 2010 16:52:42 -0700 Linus Torvalds <[email protected]> wrote:
>
> On a slightly happier note: one thing I do hope we can merge in the
> upcoming merge window is Nick Piggin's cool VFS scalability series.
> I've been using it on my own machine, and gone through all the commits
> (not that I shouldn't go through some of them some more), and am
> personally really excited about it. It's seldom we see major
> performance improvements in core code that are quite that noticeable,
> and Nick's whole RCU pathname lookup in particular just tickles me
> pink.
To that end, Nick, can you please submit that tree for inclusion in
linux-next in case there are some interactions with some of the other
stuff there? (or send it all to Al, instead (or both), I guess.)
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
2.6.35 still fails to boot for me, as first reported here:
http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
I've manually bisected it down to around May 20 between
2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
Unfortunately first time I tried was with 2.6.35-rc6 and
it failed to boot.
Failure when switching from initramfs to real /root?
Removing kernel "quiet" param appears to show several
lines listing:
usb drives/hubs? followed by
dracut switching root (when booting works)
or
usb drives/hubs? followed by
(missing dracut... line)
No root device found
Boot has failed, sleeping forever. (when it does not boot)
Grub, typical entry:
title Fedora (2.6.35)
root (hd0,0)
kernel /vmlinuz-2.6.35 ro
root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
rdblacklist=nouveau init=/sbin/bootchartd
initrd /initramfs-2.6.35.img
My boot failure seems to be different than other two reported
in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
under Bug #16173 and #16228
http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/00080.html
System is up to date Fedora 12 on Asus P5B Deluxe, Core2 6600 2.4GHz
00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH)
6 port SATA AHCI Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600
GT] (rev a1)
03:00.0 SATA controller: JMicron Technologies, Inc. 20360/20363 Serial
ATA Controller (rev 02)
Using 2.6.34.1 shows
# lsmod | grep ata
ata_generic 3427 0
pata_acpi 3227 0
pata_jmicron 2547 0
libata 157450 4 ata_generic,pata_acpi,pata_jmicron,ahci
scsi_mod 147895 5 sg,sd_mod,sr_mod,usb_storage,libata
The .config's were made from 2.6.34.1/.config using oldconfig and enter
key (defaults for any questions).
Updating BIOS from 1232 to 1238 (latest) gave no change.
Tried gcc's 4.4.4, 4.5.0, and 4.5.1 with no change.
Thanks for any help,
Don
On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
> On a slightly happier note: one thing I do hope we can merge in the
> upcoming merge window is Nick Piggin's cool VFS scalability series.
> I've been using it on my own machine, and gone through all the commits
> (not that I shouldn't go through some of them some more), and am
> personally really excited about it. It's seldom we see major
> performance improvements in core code that are quite that noticeable,
> and Nick's whole RCU pathname lookup in particular just tickles me
> pink.
There hasn't been nearly enough review or testing of this patch
series yet. Before a merge, it needs to be split up in smaller,
more digestable chunks for more comprehensive review, regression
testing and behavioural analysis.
There's probably only a handful of people who have done any testing
on the patchset so far, and given the widespread changes it needs a
lot more testing than this before we should consider merging any of
it.
I really want to see this move forward too, but it changes lots of
critical infrastructure in subtle ways and so, IMO, this is not
a patchset we should be gung-ho about.
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <[email protected]> wrote:
>
> There hasn't been nearly enough review or testing of this patch
> series yet. ?Before a merge, it needs to be split up in smaller,
> more digestable chunks for more comprehensive review, regression
> testing and behavioural analysis.
I dunno. We merge _way_ scarier things in the VM and the block layer,
for much less actual upside, and with less review.
The RCU pathname lookup has some rather impressive performance
upsides, and I agree that it would be good to get a lot of review and
testing, but the latter isn't going to happen without it being
mainlined, and the former is sadly lacking. The person I'd like most
to review it is Al, but anybody in the filesystem world should
basically see it as a #1 priority, because unlike all the masturbatory
patches like xstat() that add new functionality that nobody will
likely ever use, Nick's patchseries improves on the thing that
everybody uses heavily every day without even thinking about it.
Is it tough to review? Yes. It's core code, not just some random
addition that adds a new feature and doesn't impact any old code. But
that's also the thing that makes it meaningful, and makes me think it
should get merged _much_ more eagerly than most code we ever see.
Linus
On Sun, 01 Aug 2010 22:31:02 -0400 Donald Parsons wrote:
> 2.6.35 still fails to boot for me, as first reported here:
> http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>
> I've manually bisected it down to around May 20 between
> 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
>
> Unfortunately first time I tried was with 2.6.35-rc6 and
> it failed to boot.
>
> Failure when switching from initramfs to real /root?
> Removing kernel "quiet" param appears to show several
> lines listing:
>
> usb drives/hubs? followed by
> dracut switching root (when booting works)
> or
> usb drives/hubs? followed by
> (missing dracut... line)
> No root device found
> Boot has failed, sleeping forever. (when it does not boot)
>
> Grub, typical entry:
> title Fedora (2.6.35)
> root (hd0,0)
> kernel /vmlinuz-2.6.35 ro
> root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> rdblacklist=nouveau init=/sbin/bootchartd
> initrd /initramfs-2.6.35.img
>
>
> My boot failure seems to be different than other two reported
> in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> under Bug #16173 and #16228
> http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/00080.html
>
> System is up to date Fedora 12 on Asus P5B Deluxe, Core2 6600 2.4GHz
>
> 00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH)
> 6 port SATA AHCI Controller (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600
> GT] (rev a1)
> 03:00.0 SATA controller: JMicron Technologies, Inc. 20360/20363 Serial
> ATA Controller (rev 02)
>
> Using 2.6.34.1 shows
> # lsmod | grep ata
> ata_generic 3427 0
> pata_acpi 3227 0
> pata_jmicron 2547 0
> libata 157450 4 ata_generic,pata_acpi,pata_jmicron,ahci
> scsi_mod 147895 5 sg,sd_mod,sr_mod,usb_storage,libata
>
> The .config's were made from 2.6.34.1/.config using oldconfig and enter
> key (defaults for any questions).
Please post the 2.6.35 .config file.
> Updating BIOS from 1232 to 1238 (latest) gave no change.
> Tried gcc's 4.4.4, 4.5.0, and 4.5.1 with no change.
>
> Thanks for any help,
> Don
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> 2.6.35 still fails to boot for me, as first reported here:
> http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>
> I've manually bisected it down to around May 20 between
> 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
>
> Unfortunately first time I tried was with 2.6.35-rc6 and
> it failed to boot.
>
> Failure when switching from initramfs to real /root?
> Removing kernel "quiet" param appears to show several
> lines listing:
>
> usb drives/hubs? followed by
> dracut switching root (when booting works)
> or
> usb drives/hubs? followed by
> (missing dracut... line)
> No root device found
> Boot has failed, sleeping forever. (when it does not boot)
>
> Grub, typical entry:
> title Fedora (2.6.35)
> root (hd0,0)
> kernel /vmlinuz-2.6.35 ro
> root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> rdblacklist=nouveau init=/sbin/bootchartd
> initrd /initramfs-2.6.35.img
>
>
> My boot failure seems to be different than other two reported
> in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> under Bug #16173 and #16228
Will it boot with the "pci=nocrs" option? If so, please open a
report at https://bugzilla.kernel.org, mark it a regression, assign
it to me, and attach the complete dmesg log. And please respond to
this thread with a pointer to the bugzilla.
Otherwise, a complete console log should have a clue. The best
thing would be a log from a serial console or netconsole, with
"ignore_loglevel".
Thanks a lot for your report!
Bjorn
On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > 2.6.35 still fails to boot for me, as first reported here:
> > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> >
> > I've manually bisected it down to around May 20 between
> > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> >
> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > it failed to boot.
> >
> > Failure when switching from initramfs to real /root?
> > Removing kernel "quiet" param appears to show several
> > lines listing:
> >
> > usb drives/hubs? followed by
> > dracut switching root (when booting works)
> > or
> > usb drives/hubs? followed by
> > (missing dracut... line)
> > No root device found
> > Boot has failed, sleeping forever. (when it does not boot)
> >
> > Grub, typical entry:
> > title Fedora (2.6.35)
> > root (hd0,0)
> > kernel /vmlinuz-2.6.35 ro
> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > rdblacklist=nouveau init=/sbin/bootchartd
> > initrd /initramfs-2.6.35.img
> >
> >
> > My boot failure seems to be different than other two reported
> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > under Bug #16173 and #16228
>
> Will it boot with the "pci=nocrs" option? If so, please open a
No, I tried this on a few attempts when I saw it mentioned under
bug #16228. But it had no effect/benefit. Sorry, I should have
mentioned this.
> report at https://bugzilla.kernel.org, mark it a regression, assign
> it to me, and attach the complete dmesg log. And please respond to
> this thread with a pointer to the bugzilla.
>
> Otherwise, a complete console log should have a clue. The best
> thing would be a log from a serial console or netconsole, with
> "ignore_loglevel".
Maybe I will try netconsole tomorrow. But is Ethernet up when
this boot failure happens? I think not, since initramfs should
not need networking.
Should I try building sata driver into kernel? Oh, I am using
ext3, and fdisk -l shows:
Disk /dev/sda: 320.1 GB, 320072933376 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 50 401593+ 83 Linux (/boot)
/dev/sda2 51 7051 56235532+ 83 Linux (/)
/dev/sda3 7052 8377 10651095 82 Linux swap
/dev/sda4 8378 38913 245280420 83 Linux ()
Disk /dev/sdb: 750.2 GB, 750156374016 bytes
/dev/sdb1 1 91201 732572001 83 Linux (/home)
> Thanks a lot for your report!
>
> Bjorn
And thanks for your interest!
Don
On Sun, Aug 01, 2010 at 07:50:02PM -0700, Linus Torvalds wrote:
> On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <[email protected]> wrote:
> >
> > There hasn't been nearly enough review or testing of this patch
> > series yet. ?Before a merge, it needs to be split up in smaller,
> > more digestable chunks for more comprehensive review, regression
> > testing and behavioural analysis.
>
> I dunno. We merge _way_ scarier things in the VM and the block layer,
> for much less actual upside, and with less review.
Scary stuff outside of direct VFS/FS interfaces is generally hidden
from me by my +6 Blinkers of Blissful Ignorance. I make the
assumption that the experts involved know the risks and have weighed
them up appropriately. ;)
> The RCU pathname lookup has some rather impressive performance
> upsides, and I agree that it would be good to get a lot of review and
> testing, but the latter isn't going to happen without it being
> mainlined, and the former is sadly lacking. The person I'd like most
> to review it is Al,
Most definitely.
> but anybody in the filesystem world should
> basically see it as a #1 priority,
Agreed - I've actually looked at every patch, commented on some
of the more questionable things, got quoted by LWN for saying that
it "fell off the locking cliff", have run benchmarks on it and sent
patches fixing bugs back to Nick.
It's just really hard to digest it all in one lump and core VFS
changes on this scale scare me....
> because unlike all the masturbatory
> patches like xstat() that add new functionality that nobody will
> likely ever use, Nick's patchseries improves on the thing that
> everybody uses heavily every day without even thinking about it.
>
> Is it tough to review? Yes. It's core code, not just some random
> addition that adds a new feature and doesn't impact any old code. But
> that's also the thing that makes it meaningful, and makes me think it
> should get merged _much_ more eagerly than most code we ever see.
I agree with you for the pure locking changes.
But for the bits that change writeback, LRU ordering and reclaim
calculations the benefits are not quite so obvious, nor is the
correctness of the code/behaviour quite so provably correct. Maybe
I'm being a bit too paranoid, but generally it pays to be a bit
conservative as a filesystem developer because the cost of screwing
up can be pretty high...
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Mon, Aug 02, 2010 at 03:58:34PM +1000, Dave Chinner wrote:
> On Sun, Aug 01, 2010 at 07:50:02PM -0700, Linus Torvalds wrote:
> > On Sun, Aug 1, 2010 at 7:33 PM, Dave Chinner <[email protected]> wrote:
> > >
> > > There hasn't been nearly enough review or testing of this patch
> > > series yet. ?Before a merge, it needs to be split up in smaller,
> > > more digestable chunks for more comprehensive review, regression
> > > testing and behavioural analysis.
BTW. it has in fact had quite a bit of testing in earlier form in the
-rt tree for a long time, and several fixes come from there. And good
performance results there too.
> > I dunno. We merge _way_ scarier things in the VM and the block layer,
> > for much less actual upside, and with less review.
>
> Scary stuff outside of direct VFS/FS interfaces is generally hidden
> from me by my +6 Blinkers of Blissful Ignorance. I make the
> assumption that the experts involved know the risks and have weighed
> them up appropriately. ;)
>
> > The RCU pathname lookup has some rather impressive performance
> > upsides, and I agree that it would be good to get a lot of review and
> > testing, but the latter isn't going to happen without it being
> > mainlined, and the former is sadly lacking. The person I'd like most
> > to review it is Al,
>
> Most definitely.
I hate to say but I would like to see it mature for another release. It
should also clash a bit with Al's recent inode work that he'll want to
push.
What I can do is send some of the ground work patches this time around,
put the tree into linux-next, and put reviewers on notice.
I think it is all conceptually sound, but it will inevitably have some
bugs left to shake out, and things to be fixed on the review side. I
don't anticipate a problem that could not be fixed in the release cycle,
but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
honestly. LSF is next week too, so most of them will be busy with travel
and such. But I do hope to discuss the vfs-scale patches there.
> > but anybody in the filesystem world should
> > basically see it as a #1 priority,
>
> Agreed - I've actually looked at every patch, commented on some
> of the more questionable things, got quoted by LWN for saying that
> it "fell off the locking cliff", have run benchmarks on it and sent
> patches fixing bugs back to Nick.
>
> It's just really hard to digest it all in one lump and core VFS
> changes on this scale scare me....
For filesystems developers, the dcache and inode locking changes
should be more or less just following simple steps as shown in the
patch series. If they're not abusing dcache_lock (and most except
autofs4 are not), then it should not be a big deal.
There are a couple of locking constraints changed at the API level,
but I didn't run into any problems there yet. It should be all
documented in Documentation/filesystems/* although I need to run a
few more passes over the series to ensure I caught everything.
> > because unlike all the masturbatory
> > patches like xstat() that add new functionality that nobody will
> > likely ever use, Nick's patchseries improves on the thing that
> > everybody uses heavily every day without even thinking about it.
> >
> > Is it tough to review? Yes. It's core code, not just some random
> > addition that adds a new feature and doesn't impact any old code. But
> > that's also the thing that makes it meaningful, and makes me think it
> > should get merged _much_ more eagerly than most code we ever see.
>
> I agree with you for the pure locking changes.
>
> But for the bits that change writeback, LRU ordering and reclaim
> calculations the benefits are not quite so obvious, nor is the
> correctness of the code/behaviour quite so provably correct. Maybe
> I'm being a bit too paranoid, but generally it pays to be a bit
> conservative as a filesystem developer because the cost of screwing
> up can be pretty high...
Writeback shouldn't be changed. LRU ordering is changed for 2
reasons. Firstly, to make things per-zone instead of global. This
basically fits our whole reclaim model much better, although it
will inevitably cause some random little changes but I think it
is agreed this is a good thing (memory shortage in one zone or
node does not require global shrinkings, NUMA level parallelism
of reclaim.)
The other thing is converting the last few dcache refcounting, and
all of inode refcounting over to this "lazy LRU" model. This can
have a bigger impact, but it really reduces locking on the per-zone
lists, so it definitely helps speed and scalability of non-reclaim
fastpaths. I'm up for changing this if numbers show it hurts, it
would be rather easy to do, but in comparison to the overall
patchset, it would rate as a minor tweak :)
On Mon, Aug 02, 2010 at 10:32:04AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Sun, 1 Aug 2010 16:52:42 -0700 Linus Torvalds <[email protected]> wrote:
> >
> > On a slightly happier note: one thing I do hope we can merge in the
> > upcoming merge window is Nick Piggin's cool VFS scalability series.
> > I've been using it on my own machine, and gone through all the commits
> > (not that I shouldn't go through some of them some more), and am
> > personally really excited about it. It's seldom we see major
> > performance improvements in core code that are quite that noticeable,
> > and Nick's whole RCU pathname lookup in particular just tickles me
> > pink.
>
> To that end, Nick, can you please submit that tree for inclusion in
> linux-next in case there are some interactions with some of the other
> stuff there? (or send it all to Al, instead (or both), I guess.)
Hi Stephen,
I will work something out with Al and try to have something in
linux-next ASAP.
On Mon, Aug 02, 2010 at 05:55:37PM +1000, Nick Piggin wrote:
> I hate to say but I would like to see it mature for another release. It
> should also clash a bit with Al's recent inode work that he'll want to
> push.
>
> What I can do is send some of the ground work patches this time around,
> put the tree into linux-next, and put reviewers on notice.
>
> I think it is all conceptually sound, but it will inevitably have some
> bugs left to shake out, and things to be fixed on the review side. I
> don't anticipate a problem that could not be fixed in the release cycle,
> but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
> honestly. LSF is next week too, so most of them will be busy with travel
> and such. But I do hope to discuss the vfs-scale patches there.
What I'm most concerned bit merging everything in one go. It's a huge
series and I'd rather see it start going in in batches over multiple
kernel releases.
Things like the fs_struct spinlock and some other preparatory patches
should be ver easily to do for 2.6.36. Scaling the files and vfsmount
locks should also be easily doable, but we need to sort out the struct
file growth in the later. We really can't grow struct file by two
pointers as that would have devasting effects on various workloads.
What follows after that is the dcache_lock scaling which to seems the
most immature bit of the series, and the one that showed by far the
most problems in -RT. I'm very much dead set against merging that in
.36. I'd much rather see the inode_lock scaling or the lockless path
walk going in before, but I haven't checked how complicated the
reordering would be. The lockless path walk also is only rather
theoretically useful until we do ACL checks lockless as we're having
ACLs enabled pretty much everywhere at least in the distros.
The per-zone shrinkers are another thing that's not directly related,
I think they need a lot more discussion with the VM folks, and
integrating with Dave's work in that area.
> The per-zone shrinkers are another thing that's not directly related,
> I think they need a lot more discussion with the VM folks, and
> integrating with Dave's work in that area.
per-zone shrinkers don't cause so much impact to VM design except zone
reclaim feature. So, if FS folks think it's ok, I'm not against this at all.
btw, however, I haven't review such patch series in the detail yet. so
perhaps I might post some bug fix later.
Hi Nick,
On Mon, 2 Aug 2010 18:14:22 +1000 Nick Piggin <[email protected]> wrote:
>
> I will work something out with Al and try to have something in
> linux-next ASAP.
OK, great.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi,
(please cc me as I'm not subscribed)
updating from make 3.81 to 3.82 gets me this:
[thomas@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
[thomas@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
/mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed
implicit and normal rules. Stop.
The lines are:
182:
183: $(BOOT_TARGETS): vmlinux
184: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst
%,$(boot)/%,$@)
185:
BOOT_TARGETS are defined on line 166 as:
BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.%
cuImage.% simpleImage.%
Now it's not a regression in the kernel as the same happends with the
2.6.34 tree too.
(btw, the host I'm syncing the defconfig with is a x86_64 machine)
Now, I dont know if this is "intended breakage" by the make update, or
if the Makefile needs to be updated....
Any ideas how to fix ?
--
Thomas
On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> .36. I'd much rather see the inode_lock scaling or the lockless path
> walk going in before, but I haven't checked how complicated the
> reordering would be. The lockless path walk also is only rather
> theoretically useful until we do ACL checks lockless as we're having
> ACLs enabled pretty much everywhere at least in the distros.
>From a quick look it seems like the inode_lock splitup can easily
be moved forward, and it would help us with doing some work on the
writeback side. The problem is that it would need rebasing ontop
of both the vfs and writeback (aka block) trees.
On Mon, Aug 02, 2010 at 05:05:42AM -0400, Christoph Hellwig wrote:
> On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> > .36. I'd much rather see the inode_lock scaling or the lockless path
> > walk going in before, but I haven't checked how complicated the
> > reordering would be. The lockless path walk also is only rather
> > theoretically useful until we do ACL checks lockless as we're having
> > ACLs enabled pretty much everywhere at least in the distros.
>
> >From a quick look it seems like the inode_lock splitup can easily
> be moved forward, and it would help us with doing some work on the
> writeback side. The problem is that it would need rebasing ontop
> of both the vfs and writeback (aka block) trees.
inode_lock splitup is much simpler than dcache_lock, yes.
And I have to rebase it on the work currently queued for 2.6.35
anyway, so that's no problem. I can easily put it in front of
dcache_lock patches in the series (as I said, I've kept everything
independent and well split up).
I do want opinions on how to do the big-picture merge, though,
before I start moving things around. And obviously reviewing
each of the parts is more important at this point than exact
way to order the thing.
But even the inode_lock patches I am wary of merging in 2.6.36
without having much review or any linux-next / vfs-tree exposure.
On Mon, Aug 02, 2010 at 04:24:28AM -0400, Christoph Hellwig wrote:
> On Mon, Aug 02, 2010 at 05:55:37PM +1000, Nick Piggin wrote:
> > I hate to say but I would like to see it mature for another release. It
> > should also clash a bit with Al's recent inode work that he'll want to
> > push.
> >
> > What I can do is send some of the ground work patches this time around,
> > put the tree into linux-next, and put reviewers on notice.
> >
> > I think it is all conceptually sound, but it will inevitably have some
> > bugs left to shake out, and things to be fixed on the review side. I
> > don't anticipate a problem that could not be fixed in the release cycle,
> > but I think aiming for post 2.6.36 is a bit fairer for vfs guys,
> > honestly. LSF is next week too, so most of them will be busy with travel
> > and such. But I do hope to discuss the vfs-scale patches there.
>
> What I'm most concerned bit merging everything in one go. It's a huge
> series and I'd rather see it start going in in batches over multiple
> kernel releases.
One problem is that to win much benefit, several different aspects
must be scaled. If not, then you end up with more locks *and* still
have bouncing global cachelines. And filesystems will go through
multiple releases where locking changes are in flux. This is what
I'm concerned about.
I definitely have tried to keep everything as conceptually seperate
small chunks. But there is a real big-picture aspect that is required
to review it.
For example, you asked for just the locking split-up without any of
the per-hash-locks and per-cpu locks etc. That's fine for review, but
you cannot merge it because then you end up with N bouncing global
locks instead of 1. It also tends to be much uglier than a final
outcome because I have not applied any transformations to improve lock
orderings and reduce trylocking etc.
> Things like the fs_struct spinlock and some other preparatory patches
> should be ver easily to do for 2.6.36. Scaling the files and vfsmount
> locks should also be easily doable, but we need to sort out the struct
> file growth in the later. We really can't grow struct file by two
> pointers as that would have devasting effects on various workloads.
Strictly, it is a filesystem corruption bug-fix for the tty layer
and nothing to do with tty scaling patches.
I don't have the patience at the moment to sort through tty layer
crap, but whoever is maintaining that should. I could possibly come
back and look at it some point, but given your half-working patch
as a guide, I think someone who knows the code can fix it.
> What follows after that is the dcache_lock scaling which to seems the
> most immature bit of the series, and the one that showed by far the
> most problems in -RT. I'm very much dead set against merging that in
> .36.
That's a fair point, I agree with. It needs most review.
> I'd much rather see the inode_lock scaling or the lockless path
> walk going in before, but I haven't checked how complicated the
> reordering would be.
I would much prefer not to re-order it before either of inode or
dcache scaling patches. It would introduce a lot of churn and
locking is significantly changed.
It probably should be possible, although we would still get path
walk contention on dcache_lock, vfsmount_lock, and requires inode-RCU
(making inodes more expensive without being offset by any benefits of
inode scaling), and requires changes to filesystem dcache and inode
APIs.
I could work on re-ordering it certainly, but only if it is decided
that we definitely don't want dcache-scale or inode-scale patch sets
in the forseeable future. I think we definitely do want them, so I
find it hard to justify a big reordering.
> The lockless path walk also is only rather
> theoretically useful until we do ACL checks lockless as we're having
> ACLs enabled pretty much everywhere at least in the distros.
True, it needs a last bit of work for permission checking. The
conceptual idea and the bulk of the code I think is ready to review
though. ACLs should be just more of the same.
> The per-zone shrinkers are another thing that's not directly related,
> I think they need a lot more discussion with the VM folks, and
> integrating with Dave's work in that area.
Well I'm a VM folk :) Conceptually, there is no problems for MM
here. This is really the right way to drive reclaim from the MM
perspective (ie. per-zone). Of course I will work with Dave and
take suggestions on implementation.
It is directly related in that it is required to remove global lock and
global list scanning from vfs reclaim, which is something that we've
known and wanted for a long time.
On one hand, you might say I'm going overboard, but on another hand,
vfs really sucks on NUMA and SMP right now and it's only going to
get worse for "normal" (ie. not HPC) people.
On Sunday, August 01, 2010 10:21:16 pm Donald Parsons wrote:
> On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > 2.6.35 still fails to boot for me, as first reported here:
> > > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > >
> > > I've manually bisected it down to around May 20 between
> > > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > >
> > > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > it failed to boot.
> > >
> > > Failure when switching from initramfs to real /root?
> > > Removing kernel "quiet" param appears to show several
> > > lines listing:
> > >
> > > usb drives/hubs? followed by
> > > dracut switching root (when booting works)
> > > or
> > > usb drives/hubs? followed by
> > > (missing dracut... line)
> > > No root device found
> > > Boot has failed, sleeping forever. (when it does not boot)
> > >
> > > Grub, typical entry:
> > > title Fedora (2.6.35)
> > > root (hd0,0)
> > > kernel /vmlinuz-2.6.35 ro
> > > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > rdblacklist=nouveau init=/sbin/bootchartd
> > > initrd /initramfs-2.6.35.img
> > >
> > >
> > > My boot failure seems to be different than other two reported
> > > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > under Bug #16173 and #16228
> >
> > Will it boot with the "pci=nocrs" option? If so, please open a
>
> No, I tried this on a few attempts when I saw it mentioned under
> bug #16228. But it had no effect/benefit. Sorry, I should have
> mentioned this.
>
> > report at https://bugzilla.kernel.org, mark it a regression, assign
> > it to me, and attach the complete dmesg log. And please respond to
> > this thread with a pointer to the bugzilla.
> >
> > Otherwise, a complete console log should have a clue. The best
> > thing would be a log from a serial console or netconsole, with
> > "ignore_loglevel".
>
> Maybe I will try netconsole tomorrow. But is Ethernet up when
> this boot failure happens? I think not, since initramfs should
> not need networking.
Netconsole has special kernel support that doesn't require the normal
networking stack to be configured, so it works quite early. You
would want to build your networking driver into the kernel for the
most benefit.
If that doesn't work, you could try capturing the log on VGA with a
digital camera or video camera, possibly with "boot_delay=" to
slow things down.
> Should I try building sata driver into kernel?
I doubt that will make a difference. It seems like the problem
is that we don't find your root filesystem, probably because there's
something wrong with the HBA leading to that device. For example,
maybe the PCI core mistakenly moved or disabled the adapter, or
there's some problem with its interrupt.
Bjorn
Dracut does not include the SATA module by default. Either force
dracut to include the module in the initramfs, or use build it in the
Kernel.
Am 02.08.2010 um 15:48 schrieb Bjorn Helgaas <[email protected]>:
> On Sunday, August 01, 2010 10:21:16 pm Donald Parsons wrote:
>> On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
>>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
>>>> 2.6.35 still fails to boot for me, as first reported here:
>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>>>>
>>>> I've manually bisected it down to around May 20 between
>>>> 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
>>>> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
>>>>
>>>> Unfortunately first time I tried was with 2.6.35-rc6 and
>>>> it failed to boot.
>>>>
>>>> Failure when switching from initramfs to real /root?
>>>> Removing kernel "quiet" param appears to show several
>>>> lines listing:
>>>>
>>>> usb drives/hubs? followed by
>>>> dracut switching root (when booting works)
>>>> or
>>>> usb drives/hubs? followed by
>>>> (missing dracut... line)
>>>> No root device found
>>>> Boot has failed, sleeping forever. (when it does not boot)
>>>>
>>>> Grub, typical entry:
>>>> title Fedora (2.6.35)
>>>> root (hd0,0)
>>>> kernel /vmlinuz-2.6.35 ro
>>>> root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
>>>> SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
>>>> rdblacklist=nouveau init=/sbin/bootchartd
>>>> initrd /initramfs-2.6.35.img
>>>>
>>>>
>>>> My boot failure seems to be different than other two reported
>>>> in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
>>>> under Bug #16173 and #16228
>>>
>>> Will it boot with the "pci=nocrs" option? If so, please open a
>>
>> No, I tried this on a few attempts when I saw it mentioned under
>> bug #16228. But it had no effect/benefit. Sorry, I should have
>> mentioned this.
>>
>>> report at https://bugzilla.kernel.org, mark it a regression, assign
>>> it to me, and attach the complete dmesg log. And please respond to
>>> this thread with a pointer to the bugzilla.
>>>
>>> Otherwise, a complete console log should have a clue. The best
>>> thing would be a log from a serial console or netconsole, with
>>> "ignore_loglevel".
>>
>> Maybe I will try netconsole tomorrow. But is Ethernet up when
>> this boot failure happens? I think not, since initramfs should
>> not need networking.
>
> Netconsole has special kernel support that doesn't require the normal
> networking stack to be configured, so it works quite early. You
> would want to build your networking driver into the kernel for the
> most benefit.
>
> If that doesn't work, you could try capturing the log on VGA with a
> digital camera or video camera, possibly with "boot_delay=" to
> slow things down.
>
>> Should I try building sata driver into kernel?
>
> I doubt that will make a difference. It seems like the problem
> is that we don't find your root filesystem, probably because there's
> something wrong with the HBA leading to that device. For example,
> maybe the PCI core mistakenly moved or disabled the adapter, or
> there's some problem with its interrupt.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <[email protected]> wrote:
> On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
>> > 2.6.35 still fails to boot for me, as first reported here:
>> > ?http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>> >
>> > I've manually bisected it down to around May 20 between
>> > ? 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
>> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
>> >
>> > Unfortunately first time I tried was with 2.6.35-rc6 and
>> > it failed to boot.
>> >
>> > Failure when switching from initramfs to real /root?
>> > Removing kernel "quiet" param appears to show several
>> > lines listing:
>> >
>> > ? usb drives/hubs? followed by
>> > ? dracut switching root (when booting works)
>> > ? ? ? ? ? ? ? or
>> > ? usb drives/hubs? followed by
>> > ? ? ? ? (missing dracut... line)
>> > ? No root device found
>> > ? Boot has failed, sleeping forever. ? (when it does not boot)
>> >
>> > Grub, typical entry:
>> > title Fedora (2.6.35)
>> > ? ? root (hd0,0)
>> > ? ? kernel /vmlinuz-2.6.35 ro
>> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
>> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
>> > rdblacklist=nouveau init=/sbin/bootchartd
>> > ? ? initrd /initramfs-2.6.35.img
>> >
>> >
>> > My boot failure seems to be different than other two reported
>> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
>> > under Bug #16173 and #16228
>>
>> Will it boot with the "pci=nocrs" option? ?If so, please open a
>
> No, I tried this on a few attempts when I saw it mentioned under
> bug #16228. ?But it had no effect/benefit. ?Sorry, I should have
> mentioned this.
>
>> report at https://bugzilla.kernel.org, mark it a regression, assign
>> it to me, and attach the complete dmesg log. ?And please respond to
>> this thread with a pointer to the bugzilla.
>>
>> Otherwise, a complete console log should have a clue. ?The best
>> thing would be a log from a serial console or netconsole, with
>> "ignore_loglevel".
>
> Maybe I will try netconsole tomorrow. ?But is Ethernet up when
> this boot failure happens? ?I think not, since initramfs should
> not need networking.
>
> Should I try building sata driver into kernel? ?Oh, I am using
> ext3, and fdisk -l shows:
# dracut --add-drivers "sata" ....
or edit /etc/dracut.conf:
add_drivers+=" sata "
On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote:
> Hi,
> (please cc me as I'm not subscribed)
>
> updating from make 3.81 to 3.82 gets me this:
>
> [thomas@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
> [thomas@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
> /mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed
> implicit and normal rules. Stop.
>
> The lines are:
>
> 182:
> 183: $(BOOT_TARGETS): vmlinux
> 184: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst
> %,$(boot)/%,$@)
> 185:
>
> BOOT_TARGETS are defined on line 166 as:
> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.%
> cuImage.% simpleImage.%
>
>
> Now it's not a regression in the kernel as the same happends with the
> 2.6.34 tree too.
>
> (btw, the host I'm syncing the defconfig with is a x86_64 machine)
>
>
> Now, I dont know if this is "intended breakage" by the make update, or
> if the Makefile needs to be updated....
>
> Any ideas how to fix ?
This is in the category "intended breakage".
We had a similar issue in the top-level Makefile which Paul (IIRC)
helped me to fix long time ago.
To fix popwerpc I suggest something along these lines.
[Note: I did not test it - please do so.
Sam
[PATCH] powerpc: fix build with make 3.82
Thomas Backlund reported that the powerpc build broke with make 3.82.
It failed with the following message:
arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop.
The fix is to avoid mixing non-wildcard and wildcard targets.
Reported-by: Thomas Backlund <[email protected]>
Cc: Michal Marek <[email protected]>
Signed-off-by: Sam Ravnborg <[email protected]>
---
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 77cfe7a..ad88b21 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
all: zImage
-BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
+# With make 3.82 we cannot mix normal and wildcard targets
+BOOT_TARGETS1 := zImage zImage.initrd uImaged
+BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
-PHONY += $(BOOT_TARGETS)
+PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
boot := arch/$(ARCH)/boot
@@ -180,7 +182,9 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
zImage: relocs_check
endif
-$(BOOT_TARGETS): vmlinux
+$(BOOT_TARGETS1): vmlinux
+ $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
+$(BOOT_TARGETS2): vmlinux
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
bootwrapper_install %.dtb:
On Mon, 2010-08-02 at 07:48 -0600, Bjorn Helgaas wrote:
> Netconsole has special kernel support that doesn't require the normal
> networking stack to be configured, so it works quite early. You
> would want to build your networking driver into the kernel for the
> most benefit.
I compiled network module sky2 and netconsole into kernel 2.6.35.
Inserted into kernel line:
"debug netconsole=192.168.1.10/eth0,192.168.1.5/00:11:25:aa:79:f7"
and ran on a laptop the cmd: "nc -l -u 6666"
using all default ports if I read documentation correctly.
This failed to show any output at all.
> If that doesn't work, you could try capturing the log on VGA with a
> digital camera or video camera, possibly with "boot_delay=" to
> slow things down.
What or how much do you want shot with my digital camera? I see
maybe 3 or 4 screens fulls go by to where boot fails.
I added "boot_delay=15" for next boot.
> > Should I try building sata driver into kernel?
I think it is already in kernel, since no sata modules load
in a booting kernel (assuming sata is part of module name).
> I doubt that will make a difference. It seems like the problem
> is that we don't find your root filesystem, probably because there's
> something wrong with the HBA leading to that device. For example,
> maybe the PCI core mistakenly moved or disabled the adapter, or
> there's some problem with its interrupt.
I only see one sata compiled into kernel: CONFIG_SATA_PMP=y
and I also see no sata's loaded with lsmod in a working
kernel (2.6.34.1).
I am going to rebuild again with CONFIG_SATA_AHCI=y
instead of =m as it is Fedora's config (do not know how
it got changed). These modules are loaded in 2.6.34.1:
#lsmod | egrep "ata|ahci"
ata_generic 3427 0
pata_acpi 3227 0
pata_jmicron 2547 0
ahci 35887 4
libata 157450 4 ata_generic,pata_acpi,pata_jmicron,ahci
scsi_mod 147895 5 sg,sr_mod,usb_storage,sd_mod,libata
Thanks,
Don
>
> Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:
>
> 190: bootwrapper_install %.dtb:
> 191: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>
Obviously - dunno how I missed that.
Updated patch below.
I will do a proper submission after you
confirm that powerpc build is working with make 3.82.
Sam
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 77cfe7a..ace7a3e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
all: zImage
-BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
+# With make 3.82 we cannot mix normal and wildcard targets
+BOOT_TARGETS1 := zImage zImage.initrd uImaged
+BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
-PHONY += $(BOOT_TARGETS)
+PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
boot := arch/$(ARCH)/boot
@@ -180,10 +182,16 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
zImage: relocs_check
endif
-$(BOOT_TARGETS): vmlinux
+$(BOOT_TARGETS1): vmlinux
+ $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
+$(BOOT_TARGETS2): vmlinux
+ $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
+
+
+bootwrapper_install
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
-bootwrapper_install %.dtb:
+%.dtb:
$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
define archhelp
02.08.2010 21:28, Sam Ravnborg skrev:
> On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote:
>> Hi,
>> (please cc me as I'm not subscribed)
>>
>> updating from make 3.81 to 3.82 gets me this:
>>
>> [thomas@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
>> [thomas@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
>> /mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed
>> implicit and normal rules. Stop.
>>
>> The lines are:
>>
>> 182:
>> 183: $(BOOT_TARGETS): vmlinux
>> 184: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst
>> %,$(boot)/%,$@)
>> 185:
>>
>> BOOT_TARGETS are defined on line 166 as:
>> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.%
>> cuImage.% simpleImage.%
>>
>>
>> Now it's not a regression in the kernel as the same happends with the
>> 2.6.34 tree too.
>>
>> (btw, the host I'm syncing the defconfig with is a x86_64 machine)
>>
>>
>> Now, I dont know if this is "intended breakage" by the make update, or
>> if the Makefile needs to be updated....
>>
>> Any ideas how to fix ?
>
> This is in the category "intended breakage".
> We had a similar issue in the top-level Makefile which Paul (IIRC)
> helped me to fix long time ago.
>
> To fix popwerpc I suggest something along these lines.
> [Note: I did not test it - please do so.
>
> Sam
>
> [PATCH] powerpc: fix build with make 3.82
>
> Thomas Backlund reported that the powerpc build broke with make 3.82.
> It failed with the following message:
>
> arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop.
>
> The fix is to avoid mixing non-wildcard and wildcard targets.
>
> Reported-by: Thomas Backlund <[email protected]>
> Cc: Michal Marek <[email protected]>
> Signed-off-by: Sam Ravnborg <[email protected]>
> ---
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 77cfe7a..ad88b21 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
> # Default to zImage, override when needed
> all: zImage
>
> -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
> +# With make 3.82 we cannot mix normal and wildcard targets
> +BOOT_TARGETS1 := zImage zImage.initrd uImaged
> +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
>
> -PHONY += $(BOOT_TARGETS)
> +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
>
> boot := arch/$(ARCH)/boot
>
> @@ -180,7 +182,9 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
> zImage: relocs_check
> endif
>
> -$(BOOT_TARGETS): vmlinux
> +$(BOOT_TARGETS1): vmlinux
> + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +$(BOOT_TARGETS2): vmlinux
> $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>
> bootwrapper_install %.dtb:
Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:
190: bootwrapper_install %.dtb:
191: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
--
Thomas
Sam Ravnborg <[email protected]> writes:
> +bootwrapper_install
Missing colon.
Andreas.
--
Andreas Schwab, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
02.08.2010 23:51, Sam Ravnborg skrev:
>>
>> Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:
>>
>> 190: bootwrapper_install %.dtb:
>> 191: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>>
>
> Obviously - dunno how I missed that.
> Updated patch below.
>
> I will do a proper submission after you
> confirm that powerpc build is working with make 3.82.
>
Yeah, that was an obvious fix, thanks!
One small typo fix below...
(a missing ':')
Otherwise it works here, so:
Tested-by: Thomas Backlund <[email protected]>
> Sam
>
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 77cfe7a..ace7a3e 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
> # Default to zImage, override when needed
> all: zImage
>
> -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
> +# With make 3.82 we cannot mix normal and wildcard targets
> +BOOT_TARGETS1 := zImage zImage.initrd uImaged
> +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
>
> -PHONY += $(BOOT_TARGETS)
> +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
>
> boot := arch/$(ARCH)/boot
>
> @@ -180,10 +182,16 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
> zImage: relocs_check
> endif
>
> -$(BOOT_TARGETS): vmlinux
> +$(BOOT_TARGETS1): vmlinux
> + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +$(BOOT_TARGETS2): vmlinux
> + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +
> +
> +bootwrapper_install
bootwrapper_install:
> $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>
> -bootwrapper_install %.dtb:
> +%.dtb:
> $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>
> define archhelp
> .
>
--
Thomas
Am I missing something ?
make[2]: *** No rule to make target `firmware/radeon/R100_cp.bin', needed by `__fw_modbuild'. Stop.
Not sure if it's because I use O= during make, or because I
always patch the kernel, instead of using the tarball every
release, or something else.
In linux-2.6.35/firmware/radeon there are R100_cp.bin.ihex and
other files dated 20091122. 2.6.34 and earlier never gave such
error.
On Mon, 2 Aug 2010, Fr?d?ric L. W. Meunier wrote:
> Am I missing something ?
>
> make[2]: *** No rule to make target `firmware/radeon/R100_cp.bin', needed by
> `__fw_modbuild'. Stop.
>
> Not sure if it's because I use O= during make, or because I always patch the
> kernel, instead of using the tarball every release, or something else.
>
> In linux-2.6.35/firmware/radeon there are R100_cp.bin.ihex and other files
> dated 20091122. 2.6.34 and earlier never gave such error.
Well, I guess the problem is make 3.82. It worked with 3.81.
On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote:
> On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <[email protected]> wrote:
> > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> >> > 2.6.35 still fails to boot for me, as first reported here:
> >> > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> >> >
> >> > I've manually bisected it down to around May 20 between
> >> > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> >> >
> >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> >> > it failed to boot.
> >> >
> >> > Failure when switching from initramfs to real /root?
> >> > Removing kernel "quiet" param appears to show several
> >> > lines listing:
> >> >
> >> > usb drives/hubs? followed by
> >> > dracut switching root (when booting works)
> >> > or
> >> > usb drives/hubs? followed by
> >> > (missing dracut... line)
> >> > No root device found
> >> > Boot has failed, sleeping forever. (when it does not boot)
> >> >
> >> > Grub, typical entry:
> >> > title Fedora (2.6.35)
> >> > root (hd0,0)
> >> > kernel /vmlinuz-2.6.35 ro
> >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> >> > rdblacklist=nouveau init=/sbin/bootchartd
> >> > initrd /initramfs-2.6.35.img
> >> >
> >> >
> >> > My boot failure seems to be different than other two reported
> >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> >> > under Bug #16173 and #16228
> >>
> >> Will it boot with the "pci=nocrs" option? If so, please open a
> >
> > No, I tried this on a few attempts when I saw it mentioned under
> > bug #16228. But it had no effect/benefit. Sorry, I should have
> > mentioned this.
> >
> >> report at https://bugzilla.kernel.org, mark it a regression, assign
> >> it to me, and attach the complete dmesg log. And please respond to
> >> this thread with a pointer to the bugzilla.
> >>
> >> Otherwise, a complete console log should have a clue. The best
> >> thing would be a log from a serial console or netconsole, with
> >> "ignore_loglevel".
> >
> > Maybe I will try netconsole tomorrow. But is Ethernet up when
> > this boot failure happens? I think not, since initramfs should
> > not need networking.
> >
> > Should I try building sata driver into kernel? Oh, I am using
> > ext3, and fdisk -l shows:
>
> # dracut --add-drivers "sata" ....
>
> or edit /etc/dracut.conf:
>
> add_drivers+=" sata "
But the kernel used to boot with same identical modules before
but not after 2.6.34-git4.
--------
Using your suggestion as to where the problem lies, I investigated
more deeply and found:
I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
Make oldconfig broke at the transition where boot began failed, ie,
between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
unless CONFIG_ATA changed from m to y.
So at some point in past, make oldconfig had apparently changed
CONFIG_SATA_AHCI from y to m and system still booted. But between
2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
So make oldconfig is not 100% trustworthy in this case. I do not
know if this is a problem that should be fixed. Ask if you want
any .config diffs.
I am going to reboot with 2.6.35 to make sure it boots. Yes!
I consider this boot problem solved unless someone wants to
improve "make oldconfig" behavior.
Thanks,
Don
On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote:
> > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <[email protected]> wrote:
> > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > >> > 2.6.35 still fails to boot for me, as first reported here:
> > >> > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > >> >
> > >> > I've manually bisected it down to around May 20 between
> > >> > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > >> >
> > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > >> > it failed to boot.
> > >> >
> > >> > Failure when switching from initramfs to real /root?
> > >> > Removing kernel "quiet" param appears to show several
> > >> > lines listing:
> > >> >
> > >> > usb drives/hubs? followed by
> > >> > dracut switching root (when booting works)
> > >> > or
> > >> > usb drives/hubs? followed by
> > >> > (missing dracut... line)
> > >> > No root device found
> > >> > Boot has failed, sleeping forever. (when it does not boot)
> > >> >
> > >> > Grub, typical entry:
> > >> > title Fedora (2.6.35)
> > >> > root (hd0,0)
> > >> > kernel /vmlinuz-2.6.35 ro
> > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > >> > initrd /initramfs-2.6.35.img
> > >> >
> > >> >
> > >> > My boot failure seems to be different than other two reported
> > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > >> > under Bug #16173 and #16228
> > >>
> > >> Will it boot with the "pci=nocrs" option? If so, please open a
> > >
> > > No, I tried this on a few attempts when I saw it mentioned under
> > > bug #16228. But it had no effect/benefit. Sorry, I should have
> > > mentioned this.
> > >
> > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > >> it to me, and attach the complete dmesg log. And please respond to
> > >> this thread with a pointer to the bugzilla.
> > >>
> > >> Otherwise, a complete console log should have a clue. The best
> > >> thing would be a log from a serial console or netconsole, with
> > >> "ignore_loglevel".
> > >
> > > Maybe I will try netconsole tomorrow. But is Ethernet up when
> > > this boot failure happens? I think not, since initramfs should
> > > not need networking.
> > >
> > > Should I try building sata driver into kernel? Oh, I am using
> > > ext3, and fdisk -l shows:
> >
> > # dracut --add-drivers "sata" ....
> >
> > or edit /etc/dracut.conf:
> >
> > add_drivers+=" sata "
>
> But the kernel used to boot with same identical modules before
> but not after 2.6.34-git4.
> --------
>
> Using your suggestion as to where the problem lies, I investigated
> more deeply and found:
>
> I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
>
> Make oldconfig broke at the transition where boot began failed, ie,
> between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
> same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
> instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> unless CONFIG_ATA changed from m to y.
>
> So at some point in past, make oldconfig had apparently changed
> CONFIG_SATA_AHCI from y to m and system still booted. But between
> 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
>
> So make oldconfig is not 100% trustworthy in this case. I do not
> know if this is a problem that should be fixed. Ask if you want
> any .config diffs.
>
> I am going to reboot with 2.6.35 to make sure it boots. Yes!
>
> I consider this boot problem solved unless someone wants to
> improve "make oldconfig" behavior.
It would be good to be able to explain what you are seeing & describing,
so yes, if you can send a .config file that exhibits the problem, I'd
love to look at it.
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Tue, Aug 03, 2010 at 12:03:35AM +0300, Thomas Backlund wrote:
> 02.08.2010 23:51, Sam Ravnborg skrev:
> >>
> >> Thanks, this seems to fix the first issue, but then I get the same erro on the following line 190:
> >>
> >> 190: bootwrapper_install %.dtb:
> >> 191: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> >>
> >
> > Obviously - dunno how I missed that.
> > Updated patch below.
> >
> > I will do a proper submission after you
> > confirm that powerpc build is working with make 3.82.
> >
>
> Yeah, that was an obvious fix, thanks!
>
> One small typo fix below...
> (a missing ':')
>
> Otherwise it works here, so:
>
> Tested-by: Thomas Backlund <[email protected]>
Thanks.
I have sent a proper patch to Ben/Paul (powerpc maintainers).
Sam
Dave Chinner <[email protected]> writes:
> On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
>> On a slightly happier note: one thing I do hope we can merge in the
>> upcoming merge window is Nick Piggin's cool VFS scalability series.
>> I've been using it on my own machine, and gone through all the commits
>> (not that I shouldn't go through some of them some more), and am
>> personally really excited about it. It's seldom we see major
>> performance improvements in core code that are quite that noticeable,
>> and Nick's whole RCU pathname lookup in particular just tickles me
>> pink.
>
> There hasn't been nearly enough review or testing of this patch
> series yet. Before a merge, it needs to be split up in smaller,
> more digestable chunks for more comprehensive review, regression
> testing and behavioural analysis.
We started some testing of the VFS series on larger systems and so
far it looks all very good and the performance improvements are impressive
(but of course new bottlenecks are being exposed then)
The only snag found so far was that an ACL enabled file system
disables all the nice path walk improvements, so right now you
need to remount with noacl. I'm hoping this can be fixed
before a mainline release, otherwise I suspect it would disable
the improvements for lots of people (common distributions default
to acl on)
-Andi
--
[email protected] -- Speaking for myself only.
On Tue, Aug 03, 2010 at 10:18:30AM +0200, Andi Kleen wrote:
> Dave Chinner <[email protected]> writes:
>
> > On Sun, Aug 01, 2010 at 04:52:42PM -0700, Linus Torvalds wrote:
> >> On a slightly happier note: one thing I do hope we can merge in the
> >> upcoming merge window is Nick Piggin's cool VFS scalability series.
> >> I've been using it on my own machine, and gone through all the commits
> >> (not that I shouldn't go through some of them some more), and am
> >> personally really excited about it. It's seldom we see major
> >> performance improvements in core code that are quite that noticeable,
> >> and Nick's whole RCU pathname lookup in particular just tickles me
> >> pink.
> >
> > There hasn't been nearly enough review or testing of this patch
> > series yet. Before a merge, it needs to be split up in smaller,
> > more digestable chunks for more comprehensive review, regression
> > testing and behavioural analysis.
>
> We started some testing of the VFS series on larger systems and so
> far it looks all very good and the performance improvements are impressive
> (but of course new bottlenecks are being exposed then)
>
> The only snag found so far was that an ACL enabled file system
> disables all the nice path walk improvements, so right now you
> need to remount with noacl. I'm hoping this can be fixed
> before a mainline release, otherwise I suspect it would disable
> the improvements for lots of people (common distributions default
> to acl on)
OK, vfs-scale-working branch now has commits to enable rcu-walk aware
d_revalidate, permission, and check_acl in the filesystems, and
implements a basic rcu-walk aware scheme for generic/posix acls and
implements that for tmpfs, ext2, btrfs. It just drops out of rcu-walk
if there is an ACL on a directory, or if it is not cached. I think
that's enough to be production ready now. Pushing rcu-walk awareness
down into acl checking code would not be hard.
I was under the impression that ACLs on directories are not that common,
so maybe this is as far as we need to go for now anyway.
It does need more commenting of the new methods and explaining how they
can and can't be used by filesystems. The tree is also getting messy
with incremental changes -- I'm avoiding rebasing it so people following
it can see response to reviews and issues that arise. Obviously it will
all get cleaned up and rebased properly onto a new branch before
anything is merged.
On Tue, Aug 03, 2010 at 07:28:23PM +1000, Nick Piggin wrote:
> OK, vfs-scale-working branch now has commits to enable rcu-walk aware
> d_revalidate, permission, and check_acl in the filesystems, and
> implements a basic rcu-walk aware scheme for generic/posix acls and
Cool. I was just looking at that.
> I was under the impression that ACLs on directories are not that common,
> so maybe this is as far as we need to go for now anyway.
Yes it shouldn't be common normally. I think the common case for distros
is just a few ACLs in /dev. Of course you never know for
specific end user workloads.
-Andi
--
[email protected] -- Speaking for myself only.
Randy Dunlap wrote:
> On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
>>>>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
>>>>>> 2.6.35 still fails to boot for me, as first reported here:
>>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
>>>>>>
>>>>>> I've manually bisected it down to around May 20 between
>>>>>> 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
>>>>>> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
[...]
To recap: Donald uses ata_generic,pata_acpi,pata_jmicron,ahci for Asus
P5B Deluxe which has
00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) SATA AHCI
Controller (rev 02)
03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363
AHCI Controller (rev 02)
03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363
AHCI Controller (rev 02)
On which interface is the disk with the root filesystem?
[...]
>> Using your suggestion as to where the problem lies, I investigated
>> more deeply and found:
>>
>> I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
>>
>> Make oldconfig broke at the transition where boot began failed, ie,
>> between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
>> same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
>> instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
>> unless CONFIG_ATA changed from m to y.
>>
>> So at some point in past, make oldconfig had apparently changed
>> CONFIG_SATA_AHCI from y to m and system still booted. But between
>> 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
>>
>> So make oldconfig is not 100% trustworthy in this case. I do not
>> know if this is a problem that should be fixed. Ask if you want
>> any .config diffs.
>>
>> I am going to reboot with 2.6.35 to make sure it boots. Yes!
>>
>> I consider this boot problem solved unless someone wants to
>> improve "make oldconfig" behavior.
There was at least the following notable change in drivers/ata/Kconfig:
Commit 9a7780c9acb821fe1c2b6fc53f74cc2556ff5364 "libata-sff: make BMDMA
optional" added a new intermediary configuration option, ATA_SFF. The
option PATA_JMICRON depends on this new option now. ATA_GENERIC,
PATA_ACPI, SATA_AHCI do not depend on it.
("make oldconfig" asks for ATA_BMDMA and defaults to Y, as does the help
text recommend. Still, people who switch from 2.6.34 to 2.6.35 might be
convied that they do not need it as they already used kernels that did
not have this option with their controllers.)
Might the problem be with the order in which interfaces and disks are
discovered and hence enumerated?
> It would be good to be able to explain what you are seeing & describing,
> so yes, if you can send a .config file that exhibits the problem, I'd
> love to look at it.
Could be enlightening.
--
Stefan Richter
-=====-==-=- =--- ---==
http://arcgraph.de/sr/
On Tue, 03 Aug 2010, Nick Piggin wrote:
> I was under the impression that ACLs on directories are not that common,
> so maybe this is as far as we need to go for now anyway.
They are quite common on fileserver data areas, at least on the places where
I worked at.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Resending to all...
On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
>
> > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote:
> > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <[email protected]> wrote:
> > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > >> > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > >> >
> > > >> > I've manually bisected it down to around May 20 between
> > > >> > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > >> >
> > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > >> > it failed to boot.
> > > >> >
> > > >> > Failure when switching from initramfs to real /root?
> > > >> > Removing kernel "quiet" param appears to show several
> > > >> > lines listing:
> > > >> >
> > > >> > usb drives/hubs? followed by
> > > >> > dracut switching root (when booting works)
> > > >> > or
> > > >> > usb drives/hubs? followed by
> > > >> > (missing dracut... line)
> > > >> > No root device found
> > > >> > Boot has failed, sleeping forever. (when it does not boot)
> > > >> >
> > > >> > Grub, typical entry:
> > > >> > title Fedora (2.6.35)
> > > >> > root (hd0,0)
> > > >> > kernel /vmlinuz-2.6.35 ro
> > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > >> > initrd /initramfs-2.6.35.img
> > > >> >
> > > >> >
> > > >> > My boot failure seems to be different than other two reported
> > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > >> > under Bug #16173 and #16228
> > > >>
> > > >> Will it boot with the "pci=nocrs" option? If so, please open a
> > > >
> > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > bug #16228. But it had no effect/benefit. Sorry, I should have
> > > > mentioned this.
> > > >
> > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > >> it to me, and attach the complete dmesg log. And please respond to
> > > >> this thread with a pointer to the bugzilla.
> > > >>
> > > >> Otherwise, a complete console log should have a clue. The best
> > > >> thing would be a log from a serial console or netconsole, with
> > > >> "ignore_loglevel".
> > > >
> > > > Maybe I will try netconsole tomorrow. But is Ethernet up when
> > > > this boot failure happens? I think not, since initramfs should
> > > > not need networking.
> > > >
> > > > Should I try building sata driver into kernel? Oh, I am using
> > > > ext3, and fdisk -l shows:
> > >
> > > # dracut --add-drivers "sata" ....
> > >
> > > or edit /etc/dracut.conf:
> > >
> > > add_drivers+=" sata "
> >
> > But the kernel used to boot with same identical modules before
> > but not after 2.6.34-git4.
> > --------
> >
> > Using your suggestion as to where the problem lies, I investigated
> > more deeply and found:
> >
> > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> >
> > Make oldconfig broke at the transition where boot began failed, ie,
> > between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
> > same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
> > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > unless CONFIG_ATA changed from m to y.
> >
> > So at some point in past, make oldconfig had apparently changed
> > CONFIG_SATA_AHCI from y to m and system still booted. But between
> > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> >
> > So make oldconfig is not 100% trustworthy in this case. I do not
> > know if this is a problem that should be fixed. Ask if you want
> > any .config diffs.
> >
> > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> >
> > I consider this boot problem solved unless someone wants to
> > improve "make oldconfig" behavior.
>
> It would be good to be able to explain what you are seeing & describing,
> so yes, if you can send a .config file that exhibits the problem, I'd
> love to look at it.
>
> thanks,
> ---
> ~Randy
Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
It should be equivalent to make silentoldconfig as I made no
changes, just enter to accept defaults. The git4 boots and
git5 does not boot. (Both based off 2.6.34.1.config)
(and attached config-2.6.34-git4.gz, because .config was too
big for mail list last time.)
--- config-2.6.34-git4 2010-08-01 19:52:48.000000000 -0400
+++ config-2.6.34-git5 2010-08-01 18:10:14.000000000 -0400
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.34-git4
-# Sun Aug 1 19:52:48 2010
+# Linux kernel version: 2.6.34-git5
+# Sun Aug 1 18:10:14 2010
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
@@ -544,7 +544,7 @@
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
CONFIG_I82092=m
-CONFIG_PCCARD_NONSTATIC=m
+CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_ACPI=m
@@ -1474,7 +1474,9 @@
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=m
+# CONFIG_SATA_AHCI_PLATFORM is not set
CONFIG_SATA_SIL24=m
+CONFIG_SATA_INIC162X=m
CONFIG_ATA_SFF=y
CONFIG_SATA_SVW=m
CONFIG_ATA_PIIX=m
@@ -1489,7 +1491,6 @@
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m
-CONFIG_SATA_INIC162X=m
CONFIG_PATA_ACPI=m
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
@@ -1882,6 +1883,7 @@
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
+# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_NEWTON is not set
@@ -1944,6 +1946,7 @@
# CONFIG_TOUCHSCREEN_AD7879_I2C is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
+# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
CONFIG_TOUCHSCREEN_FUJITSU=m
CONFIG_TOUCHSCREEN_GUNZE=m
@@ -1977,6 +1980,7 @@
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
+# CONFIG_INPUT_AD714X is not set
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_APANEL=m
CONFIG_INPUT_ATLAS_BTNS=m
@@ -1988,6 +1992,7 @@
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_WINBOND_CIR is not set
+# CONFIG_INPUT_PCF8574 is not set
#
# Hardware I/O ports
@@ -2377,7 +2382,6 @@
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_WM8400 is not set
-# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_LPC_SCH is not set
# CONFIG_REGULATOR is not set
@@ -2398,6 +2402,13 @@
#
CONFIG_IR_CORE=m
CONFIG_VIDEO_IR=m
+CONFIG_RC_MAP=m
+CONFIG_IR_NEC_DECODER=m
+CONFIG_IR_RC5_DECODER=m
+CONFIG_IR_RC6_DECODER=m
+CONFIG_IR_JVC_DECODER=m
+CONFIG_IR_SONY_DECODER=m
+# CONFIG_IR_IMON is not set
# CONFIG_MEDIA_ATTACH is not set
CONFIG_MEDIA_TUNER=m
# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
@@ -2416,8 +2427,8 @@
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_IR_I2C=m
-# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_BT848 is not set
+# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_VIDEO_ZORAN is not set
@@ -2477,10 +2488,10 @@
# CONFIG_USB_ET61X251 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_ZC0301 is not set
-CONFIG_USB_PWC_INPUT_EVDEV=y
# CONFIG_USB_ZR364XX is not set
# CONFIG_USB_STKWEBCAM is not set
# CONFIG_USB_S2255 is not set
+# CONFIG_V4L_MEM2MEM_DRIVERS is not set
CONFIG_RADIO_ADAPTERS=y
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
@@ -2695,6 +2706,7 @@
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
+# CONFIG_SND_ASIHPI is not set
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
@@ -2734,6 +2746,7 @@
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
+# CONFIG_SND_ES1968_INPUT is not set
CONFIG_SND_FM801=m
# CONFIG_SND_FM801_TEA575X_BOOL is not set
CONFIG_SND_HDA_INTEL=m
@@ -2769,6 +2782,7 @@
CONFIG_SND_KORG1212=m
# CONFIG_SND_LX6464ES is not set
CONFIG_SND_MAESTRO3=m
+# CONFIG_SND_MAESTRO3_INPUT is not set
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
@@ -3148,10 +3162,6 @@
# CONFIG_UIO_SERCOS3 is not set
# CONFIG_UIO_PCI_GENERIC is not set
# CONFIG_UIO_NETX is not set
-
-#
-# TI VLYNQ
-#
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
-------------------------------------------
Can possibly duplicate problem if you have a
sata based PC from last few years.
Set CONFIG_ATA=m
and this becomes CONFIG_SATA_AHCI=m (cannot select=y)
Then 2.6.34.[01] (probably 2 also) will boot.
Make silentoldconfig with this .config and see
that 2.6.35 will not boot.
Thanks,
Don
On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:
> Resending to all...
> On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> >
> > > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote:
> > > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <[email protected]> wrote:
> > > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > > >> > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > > >> >
> > > > >> > I've manually bisected it down to around May 20 between
> > > > >> > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > > >> >
> > > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > > >> > it failed to boot.
> > > > >> >
> > > > >> > Failure when switching from initramfs to real /root?
> > > > >> > Removing kernel "quiet" param appears to show several
> > > > >> > lines listing:
> > > > >> >
> > > > >> > usb drives/hubs? followed by
> > > > >> > dracut switching root (when booting works)
> > > > >> > or
> > > > >> > usb drives/hubs? followed by
> > > > >> > (missing dracut... line)
> > > > >> > No root device found
> > > > >> > Boot has failed, sleeping forever. (when it does not boot)
> > > > >> >
> > > > >> > Grub, typical entry:
> > > > >> > title Fedora (2.6.35)
> > > > >> > root (hd0,0)
> > > > >> > kernel /vmlinuz-2.6.35 ro
> > > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > > >> > initrd /initramfs-2.6.35.img
> > > > >> >
> > > > >> >
> > > > >> > My boot failure seems to be different than other two reported
> > > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > > >> > under Bug #16173 and #16228
> > > > >>
> > > > >> Will it boot with the "pci=nocrs" option? If so, please open a
> > > > >
> > > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > > bug #16228. But it had no effect/benefit. Sorry, I should have
> > > > > mentioned this.
> > > > >
> > > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > > >> it to me, and attach the complete dmesg log. And please respond to
> > > > >> this thread with a pointer to the bugzilla.
> > > > >>
> > > > >> Otherwise, a complete console log should have a clue. The best
> > > > >> thing would be a log from a serial console or netconsole, with
> > > > >> "ignore_loglevel".
> > > > >
> > > > > Maybe I will try netconsole tomorrow. But is Ethernet up when
> > > > > this boot failure happens? I think not, since initramfs should
> > > > > not need networking.
> > > > >
> > > > > Should I try building sata driver into kernel? Oh, I am using
> > > > > ext3, and fdisk -l shows:
> > > >
> > > > # dracut --add-drivers "sata" ....
> > > >
> > > > or edit /etc/dracut.conf:
> > > >
> > > > add_drivers+=" sata "
> > >
> > > But the kernel used to boot with same identical modules before
> > > but not after 2.6.34-git4.
> > > --------
> > >
> > > Using your suggestion as to where the problem lies, I investigated
> > > more deeply and found:
> > >
> > > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> > >
> > > Make oldconfig broke at the transition where boot began failed, ie,
> > > between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
> > > same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
> > > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > > unless CONFIG_ATA changed from m to y.
> > >
> > > So at some point in past, make oldconfig had apparently changed
> > > CONFIG_SATA_AHCI from y to m and system still booted. But between
> > > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> > >
> > > So make oldconfig is not 100% trustworthy in this case. I do not
> > > know if this is a problem that should be fixed. Ask if you want
> > > any .config diffs.
> > >
> > > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> > >
> > > I consider this boot problem solved unless someone wants to
> > > improve "make oldconfig" behavior.
> >
> > It would be good to be able to explain what you are seeing & describing,
> > so yes, if you can send a .config file that exhibits the problem, I'd
> > love to look at it.
> >
> > thanks,
> > ---
> > ~Randy
>
>
> Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> It should be equivalent to make silentoldconfig as I made no
> changes, just enter to accept defaults. The git4 boots and
> git5 does not boot. (Both based off 2.6.34.1.config)
Yes, I had just generated this same diff.
The only config change that could remotely make a difference is:
> +# CONFIG_SATA_AHCI_PLATFORM is not set
and I don't see how it could matter.
> (and attached config-2.6.34-git4.gz, because .config was too
> big for mail list last time.)
Last time being recently? lkml accepts email sizes (with attachments)
up to 300 KB, IIRC.
> --- config-2.6.34-git4 2010-08-01 19:52:48.000000000 -0400
> +++ config-2.6.34-git5 2010-08-01 18:10:14.000000000 -0400
> @@ -1,7 +1,7 @@
> #
> # Automatically generated make config: don't edit
> -# Linux kernel version: 2.6.34-git4
> -# Sun Aug 1 19:52:48 2010
> +# Linux kernel version: 2.6.34-git5
> +# Sun Aug 1 18:10:14 2010
> #
> CONFIG_64BIT=y
> # CONFIG_X86_32 is not set
> @@ -544,7 +544,7 @@
> CONFIG_YENTA_TOSHIBA=y
> CONFIG_PD6729=m
> CONFIG_I82092=m
> -CONFIG_PCCARD_NONSTATIC=m
> +CONFIG_PCCARD_NONSTATIC=y
> CONFIG_HOTPLUG_PCI=y
> CONFIG_HOTPLUG_PCI_FAKE=m
> CONFIG_HOTPLUG_PCI_ACPI=m
> @@ -1474,7 +1474,9 @@
> CONFIG_ATA_ACPI=y
> CONFIG_SATA_PMP=y
> CONFIG_SATA_AHCI=m
> +# CONFIG_SATA_AHCI_PLATFORM is not set
> CONFIG_SATA_SIL24=m
> +CONFIG_SATA_INIC162X=m
> CONFIG_ATA_SFF=y
> CONFIG_SATA_SVW=m
> CONFIG_ATA_PIIX=m
> @@ -1489,7 +1491,6 @@
> CONFIG_SATA_ULI=m
> CONFIG_SATA_VIA=m
> CONFIG_SATA_VITESSE=m
> -CONFIG_SATA_INIC162X=m
> CONFIG_PATA_ACPI=m
> CONFIG_PATA_ALI=m
> CONFIG_PATA_AMD=m
> @@ -1882,6 +1883,7 @@
> CONFIG_KEYBOARD_ATKBD=y
> # CONFIG_QT2160 is not set
> # CONFIG_KEYBOARD_LKKBD is not set
> +# CONFIG_KEYBOARD_TCA6416 is not set
> # CONFIG_KEYBOARD_LM8323 is not set
> # CONFIG_KEYBOARD_MAX7359 is not set
> # CONFIG_KEYBOARD_NEWTON is not set
> @@ -1944,6 +1946,7 @@
> # CONFIG_TOUCHSCREEN_AD7879_I2C is not set
> # CONFIG_TOUCHSCREEN_AD7879 is not set
> # CONFIG_TOUCHSCREEN_DYNAPRO is not set
> +# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
> # CONFIG_TOUCHSCREEN_EETI is not set
> CONFIG_TOUCHSCREEN_FUJITSU=m
> CONFIG_TOUCHSCREEN_GUNZE=m
> @@ -1977,6 +1980,7 @@
> # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
> # CONFIG_TOUCHSCREEN_TSC2007 is not set
> CONFIG_INPUT_MISC=y
> +# CONFIG_INPUT_AD714X is not set
> CONFIG_INPUT_PCSPKR=m
> CONFIG_INPUT_APANEL=m
> CONFIG_INPUT_ATLAS_BTNS=m
> @@ -1988,6 +1992,7 @@
> # CONFIG_INPUT_CM109 is not set
> CONFIG_INPUT_UINPUT=m
> # CONFIG_INPUT_WINBOND_CIR is not set
> +# CONFIG_INPUT_PCF8574 is not set
>
> #
> # Hardware I/O ports
> @@ -2377,7 +2382,6 @@
> # CONFIG_HTC_PASIC3 is not set
> # CONFIG_MFD_TMIO is not set
> # CONFIG_MFD_WM8400 is not set
> -# CONFIG_MFD_WM8994 is not set
> # CONFIG_MFD_PCF50633 is not set
> # CONFIG_LPC_SCH is not set
> # CONFIG_REGULATOR is not set
> @@ -2398,6 +2402,13 @@
> #
> CONFIG_IR_CORE=m
> CONFIG_VIDEO_IR=m
> +CONFIG_RC_MAP=m
> +CONFIG_IR_NEC_DECODER=m
> +CONFIG_IR_RC5_DECODER=m
> +CONFIG_IR_RC6_DECODER=m
> +CONFIG_IR_JVC_DECODER=m
> +CONFIG_IR_SONY_DECODER=m
> +# CONFIG_IR_IMON is not set
> # CONFIG_MEDIA_ATTACH is not set
> CONFIG_MEDIA_TUNER=m
> # CONFIG_MEDIA_TUNER_CUSTOMISE is not set
> @@ -2416,8 +2427,8 @@
> # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
> CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
> CONFIG_VIDEO_IR_I2C=m
> -# CONFIG_VIDEO_VIVI is not set
> # CONFIG_VIDEO_BT848 is not set
> +# CONFIG_VIDEO_W9966 is not set
> # CONFIG_VIDEO_SAA5246A is not set
> # CONFIG_VIDEO_SAA5249 is not set
> # CONFIG_VIDEO_ZORAN is not set
> @@ -2477,10 +2488,10 @@
> # CONFIG_USB_ET61X251 is not set
> # CONFIG_USB_SN9C102 is not set
> # CONFIG_USB_ZC0301 is not set
> -CONFIG_USB_PWC_INPUT_EVDEV=y
> # CONFIG_USB_ZR364XX is not set
> # CONFIG_USB_STKWEBCAM is not set
> # CONFIG_USB_S2255 is not set
> +# CONFIG_V4L_MEM2MEM_DRIVERS is not set
> CONFIG_RADIO_ADAPTERS=y
> # CONFIG_RADIO_GEMTEK_PCI is not set
> # CONFIG_RADIO_MAXIRADIO is not set
> @@ -2695,6 +2706,7 @@
> CONFIG_SND_ALS300=m
> CONFIG_SND_ALS4000=m
> CONFIG_SND_ALI5451=m
> +# CONFIG_SND_ASIHPI is not set
> CONFIG_SND_ATIIXP=m
> CONFIG_SND_ATIIXP_MODEM=m
> CONFIG_SND_AU8810=m
> @@ -2734,6 +2746,7 @@
> CONFIG_SND_ENS1371=m
> CONFIG_SND_ES1938=m
> CONFIG_SND_ES1968=m
> +# CONFIG_SND_ES1968_INPUT is not set
> CONFIG_SND_FM801=m
> # CONFIG_SND_FM801_TEA575X_BOOL is not set
> CONFIG_SND_HDA_INTEL=m
> @@ -2769,6 +2782,7 @@
> CONFIG_SND_KORG1212=m
> # CONFIG_SND_LX6464ES is not set
> CONFIG_SND_MAESTRO3=m
> +# CONFIG_SND_MAESTRO3_INPUT is not set
> CONFIG_SND_MIXART=m
> CONFIG_SND_NM256=m
> CONFIG_SND_PCXHR=m
> @@ -3148,10 +3162,6 @@
> # CONFIG_UIO_SERCOS3 is not set
> # CONFIG_UIO_PCI_GENERIC is not set
> # CONFIG_UIO_NETX is not set
> -
> -#
> -# TI VLYNQ
> -#
> # CONFIG_STAGING is not set
> CONFIG_X86_PLATFORM_DEVICES=y
> # CONFIG_ACER_WMI is not set
>
> -------------------------------------------
>
> Can possibly duplicate problem if you have a
> sata based PC from last few years.
>
> Set CONFIG_ATA=m
That's already =m in this config file.
> and this becomes CONFIG_SATA_AHCI=m (cannot select=y)
That's as expected. CONFIG_ATA value controls CONFIG_SATA_AHCI
possible values.
>
> Then 2.6.34.[01] (probably 2 also) will boot.
> Make silentoldconfig with this .config and see
> that 2.6.35 will not boot.
So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
but 2.6.34-git5 fails to boot?
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Tue, 2010-08-03 at 09:40 -0700, Randy Dunlap wrote:
> On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:
>
> > Resending to all...
> > On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> > >
> > > > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote:
> > > > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <[email protected]> wrote:
> > > > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > > > >> > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > > > >> >
> > > > > >> > I've manually bisected it down to around May 20 between
> > > > > >> > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > > > >> >
> > > > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > > > >> > it failed to boot.
> > > > > >> >
> > > > > >> > Failure when switching from initramfs to real /root?
> > > > > >> > Removing kernel "quiet" param appears to show several
> > > > > >> > lines listing:
> > > > > >> >
> > > > > >> > usb drives/hubs? followed by
> > > > > >> > dracut switching root (when booting works)
> > > > > >> > or
> > > > > >> > usb drives/hubs? followed by
> > > > > >> > (missing dracut... line)
> > > > > >> > No root device found
> > > > > >> > Boot has failed, sleeping forever. (when it does not boot)
> > > > > >> >
> > > > > >> > Grub, typical entry:
> > > > > >> > title Fedora (2.6.35)
> > > > > >> > root (hd0,0)
> > > > > >> > kernel /vmlinuz-2.6.35 ro
> > > > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > > > >> > initrd /initramfs-2.6.35.img
> > > > > >> >
> > > > > >> >
> > > > > >> > My boot failure seems to be different than other two reported
> > > > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > > > >> > under Bug #16173 and #16228
> > > > > >>
> > > > > >> Will it boot with the "pci=nocrs" option? If so, please open a
> > > > > >
> > > > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > > > bug #16228. But it had no effect/benefit. Sorry, I should have
> > > > > > mentioned this.
> > > > > >
> > > > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > > > >> it to me, and attach the complete dmesg log. And please respond to
> > > > > >> this thread with a pointer to the bugzilla.
> > > > > >>
> > > > > >> Otherwise, a complete console log should have a clue. The best
> > > > > >> thing would be a log from a serial console or netconsole, with
> > > > > >> "ignore_loglevel".
> > > > > >
> > > > > > Maybe I will try netconsole tomorrow. But is Ethernet up when
> > > > > > this boot failure happens? I think not, since initramfs should
> > > > > > not need networking.
> > > > > >
> > > > > > Should I try building sata driver into kernel? Oh, I am using
> > > > > > ext3, and fdisk -l shows:
> > > > >
> > > > > # dracut --add-drivers "sata" ....
> > > > >
> > > > > or edit /etc/dracut.conf:
> > > > >
> > > > > add_drivers+=" sata "
> > > >
> > > > But the kernel used to boot with same identical modules before
> > > > but not after 2.6.34-git4.
> > > > --------
> > > >
> > > > Using your suggestion as to where the problem lies, I investigated
> > > > more deeply and found:
> > > >
> > > > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> > > >
> > > > Make oldconfig broke at the transition where boot began failed, ie,
> > > > between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
> > > > same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
> > > > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > > > unless CONFIG_ATA changed from m to y.
> > > >
> > > > So at some point in past, make oldconfig had apparently changed
> > > > CONFIG_SATA_AHCI from y to m and system still booted. But between
> > > > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> > > >
> > > > So make oldconfig is not 100% trustworthy in this case. I do not
> > > > know if this is a problem that should be fixed. Ask if you want
> > > > any .config diffs.
> > > >
> > > > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> > > >
> > > > I consider this boot problem solved unless someone wants to
> > > > improve "make oldconfig" behavior.
> > >
> > > It would be good to be able to explain what you are seeing & describing,
> > > so yes, if you can send a .config file that exhibits the problem, I'd
> > > love to look at it.
> > >
> > > thanks,
> > > ---
> > > ~Randy
> >
> >
> > Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> > It should be equivalent to make silentoldconfig as I made no
> > changes, just enter to accept defaults. The git4 boots and
> > git5 does not boot. (Both based off 2.6.34.1.config)
>
> Yes, I had just generated this same diff.
> The only config change that could remotely make a difference is:
> > +# CONFIG_SATA_AHCI_PLATFORM is not set
>
> and I don't see how it could matter.
>
> > (and attached config-2.6.34-git4.gz, because .config was too
> > big for mail list last time.)
>
> Last time being recently? lkml accepts email sizes (with attachments)
> up to 300 KB, IIRC.
Maybe http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/index.html
throws out large email but the actual lkml does not? I did not see
it show up; here is header of email that had large (56.48K) .config:
From: Donald Parsons
To: Randy Dunlap
Cc: linux-kernel <[email protected]>, Linus Torvalds
Subject: Re: Linux 2.6.35
Date: 08/01/2010 11:41:31 PM (this is EDT)
Mailer: Evolution 2.28.3 (2.28.3-1.fc12)
> > --- config-2.6.34-git4 2010-08-01 19:52:48.000000000 -0400
> > +++ config-2.6.34-git5 2010-08-01 18:10:14.000000000 -0400
> > @@ -1,7 +1,7 @@
> > #
> > # Automatically generated make config: don't edit
...deleted most lines...
> > -#
> > # CONFIG_STAGING is not set
> > CONFIG_X86_PLATFORM_DEVICES=y
> > # CONFIG_ACER_WMI is not set
> >
> > -------------------------------------------
> >
> > Can possibly duplicate problem if you have a
> > sata based PC from last few years.
> >
> > Set CONFIG_ATA=m
>
> That's already =m in this config file.
>
> > and this becomes CONFIG_SATA_AHCI=m (cannot select=y)
>
> That's as expected. CONFIG_ATA value controls CONFIG_SATA_AHCI
> possible values.
>
> >
> > Then 2.6.34.[01] (probably 2 also) will boot.
> > Make silentoldconfig with this .config and see
> > that 2.6.35 will not boot.
>
> So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
> but 2.6.34-git5 fails to boot?
Yes, that is exactly correct.
Don
On Tue, 2010-08-03 at 12:24 +0200, Stefan Richter wrote:
> Randy Dunlap wrote:
> > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> >>>>> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> >>>>>> 2.6.35 still fails to boot for me, as first reported here:
> >>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> >>>>>>
> >>>>>> I've manually bisected it down to around May 20 between
> >>>>>> 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> >>>>>> Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> [...]
>
> To recap: Donald uses ata_generic,pata_acpi,pata_jmicron,ahci for Asus
> P5B Deluxe which has
>
> 00:1f.2 SATA controller: Intel Corporation 82801HB (ICH8) SATA AHCI
> Controller (rev 02)
> 03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363
> AHCI Controller (rev 02)
> 03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363
> AHCI Controller (rev 02)
>
> On which interface is the disk with the root filesystem?
All drives hook to ICH8R, two Seagate SATA hard drives, and
a SATA CD/DVD drive. JMicron has no drives so far.
Don
On Tue, 03 Aug 2010 13:45:45 -0400 Donald Parsons wrote:
> On Tue, 2010-08-03 at 09:40 -0700, Randy Dunlap wrote:
> > On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:
> >
> > > Resending to all...
> > > On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > > > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> > > >
[snip]
> > > >
> > > > It would be good to be able to explain what you are seeing & describing,
> > > > so yes, if you can send a .config file that exhibits the problem, I'd
> > > > love to look at it.
> > > >
> > > > thanks,
> > > > ---
> > > > ~Randy
> > >
> > >
> > > Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> > > It should be equivalent to make silentoldconfig as I made no
> > > changes, just enter to accept defaults. The git4 boots and
> > > git5 does not boot. (Both based off 2.6.34.1.config)
> >
> > Yes, I had just generated this same diff.
> > The only config change that could remotely make a difference is:
> > > +# CONFIG_SATA_AHCI_PLATFORM is not set
> >
> > and I don't see how it could matter.
> >
> > > (and attached config-2.6.34-git4.gz, because .config was too
> > > big for mail list last time.)
> >
> > Last time being recently? lkml accepts email sizes (with attachments)
> > up to 300 KB, IIRC.
>
> Maybe http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/index.html
> throws out large email but the actual lkml does not? I did not see
That could be. I usually use http://marc.info/?l=linux-kernel
or http://lkml.org .
> it show up; here is header of email that had large (56.48K) .config:
I often post configs that are larger than that one.
I also checked my kernel mailbox and see several much larger emails, in
the 200KB/300KB range.
And the vger.kernel.org postmaster wrote on 13-AUG-2007:
"The posting limit is 400K for linux-kernel, netdev, and one
or two of the other lists."
so it could be something other than size that caused it to be dropped,
like html or some taboo word(s). E.g., see
http://vger.kernel.org/majordomo-info.html#taboo
> >
> From: Donald Parsons
> To: Randy Dunlap
> Cc: linux-kernel <[email protected]>, Linus Torvalds
> Subject: Re: Linux 2.6.35
> Date: 08/01/2010 11:41:31 PM (this is EDT)
> Mailer: Evolution 2.28.3 (2.28.3-1.fc12)
>
>
> > > --- config-2.6.34-git4 2010-08-01 19:52:48.000000000 -0400
> > > +++ config-2.6.34-git5 2010-08-01 18:10:14.000000000 -0400
> > > @@ -1,7 +1,7 @@
> > > #
> > > # Automatically generated make config: don't edit
> ...deleted most lines...
> > > -#
> > > # CONFIG_STAGING is not set
> > > CONFIG_X86_PLATFORM_DEVICES=y
> > > # CONFIG_ACER_WMI is not set
> > >
> > > -------------------------------------------
> > >
> > > Can possibly duplicate problem if you have a
> > > sata based PC from last few years.
> > >
> > > Set CONFIG_ATA=m
> >
> > That's already =m in this config file.
> >
> > > and this becomes CONFIG_SATA_AHCI=m (cannot select=y)
> >
> > That's as expected. CONFIG_ATA value controls CONFIG_SATA_AHCI
> > possible values.
> >
> > >
> > > Then 2.6.34.[01] (probably 2 also) will boot.
> > > Make silentoldconfig with this .config and see
> > > that 2.6.35 will not boot.
> >
> > So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
> > but 2.6.34-git5 fails to boot?
>
> Yes, that is exactly correct.
OK, I'll test that on a test machine.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Tue, 03 Aug 2010 13:45:45 -0400 Donald Parsons wrote:
> On Tue, 2010-08-03 at 09:40 -0700, Randy Dunlap wrote:
> > On Tue, 03 Aug 2010 12:26:50 -0400 Donald Parsons wrote:
> >
> > > Resending to all...
> > > On Mon, 2010-08-02 at 21:42 -0700, Randy Dunlap wrote:
> > > > On Mon, 02 Aug 2010 22:31:41 -0400 Donald Parsons wrote:
> > > >
> > > > > On Mon, 2010-08-02 at 18:08 +0200, Harald Hoyer wrote:
> > > > > > On Mon, Aug 2, 2010 at 6:21 AM, Donald Parsons <[email protected]> wrote:
> > > > > > > On Sun, 2010-08-01 at 21:38 -0600, Bjorn Helgaas wrote:
> > > > > > >> On Sunday, August 01, 2010 08:31:02 pm Donald Parsons wrote:
> > > > > > >> > 2.6.35 still fails to boot for me, as first reported here:
> > > > > > >> > http://lkml.indiana.edu/hypermail/linux/kernel/1007.3/01144.html
> > > > > > >> >
> > > > > > >> > I've manually bisected it down to around May 20 between
> > > > > > >> > 2.6.34-git4 (boots) and 2.6.34-git5 (boot fails)
> > > > > > >> > Also -git[23] boot, and -git8, -rc[126], rc6-git[136] all fail.
> > > > > > >> >
> > > > > > >> > Unfortunately first time I tried was with 2.6.35-rc6 and
> > > > > > >> > it failed to boot.
> > > > > > >> >
> > > > > > >> > Failure when switching from initramfs to real /root?
> > > > > > >> > Removing kernel "quiet" param appears to show several
> > > > > > >> > lines listing:
> > > > > > >> >
> > > > > > >> > usb drives/hubs? followed by
> > > > > > >> > dracut switching root (when booting works)
> > > > > > >> > or
> > > > > > >> > usb drives/hubs? followed by
> > > > > > >> > (missing dracut... line)
> > > > > > >> > No root device found
> > > > > > >> > Boot has failed, sleeping forever. (when it does not boot)
> > > > > > >> >
> > > > > > >> > Grub, typical entry:
> > > > > > >> > title Fedora (2.6.35)
> > > > > > >> > root (hd0,0)
> > > > > > >> > kernel /vmlinuz-2.6.35 ro
> > > > > > >> > root=UUID=686dc496-8814-4c36-8fb7-5ded2916e825 rhgb
> > > > > > >> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
> > > > > > >> > rdblacklist=nouveau init=/sbin/bootchartd
> > > > > > >> > initrd /initramfs-2.6.35.img
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > My boot failure seems to be different than other two reported
> > > > > > >> > in the thread "2.6.35-rc6-git6: Reported regressions from 2.6.34"
> > > > > > >> > under Bug #16173 and #16228
> > > > > > >>
> > > > > > >> Will it boot with the "pci=nocrs" option? If so, please open a
> > > > > > >
> > > > > > > No, I tried this on a few attempts when I saw it mentioned under
> > > > > > > bug #16228. But it had no effect/benefit. Sorry, I should have
> > > > > > > mentioned this.
> > > > > > >
> > > > > > >> report at https://bugzilla.kernel.org, mark it a regression, assign
> > > > > > >> it to me, and attach the complete dmesg log. And please respond to
> > > > > > >> this thread with a pointer to the bugzilla.
> > > > > > >>
> > > > > > >> Otherwise, a complete console log should have a clue. The best
> > > > > > >> thing would be a log from a serial console or netconsole, with
> > > > > > >> "ignore_loglevel".
> > > > > > >
> > > > > > > Maybe I will try netconsole tomorrow. But is Ethernet up when
> > > > > > > this boot failure happens? I think not, since initramfs should
> > > > > > > not need networking.
> > > > > > >
> > > > > > > Should I try building sata driver into kernel? Oh, I am using
> > > > > > > ext3, and fdisk -l shows:
> > > > > >
> > > > > > # dracut --add-drivers "sata" ....
> > > > > >
> > > > > > or edit /etc/dracut.conf:
> > > > > >
> > > > > > add_drivers+=" sata "
> > > > >
> > > > > But the kernel used to boot with same identical modules before
> > > > > but not after 2.6.34-git4.
> > > > > --------
> > > > >
> > > > > Using your suggestion as to where the problem lies, I investigated
> > > > > more deeply and found:
> > > > >
> > > > > I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
> > > > >
> > > > > Make oldconfig broke at the transition where boot began failed, ie,
> > > > > between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
> > > > > same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
> > > > > instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> > > > > unless CONFIG_ATA changed from m to y.
> > > > >
> > > > > So at some point in past, make oldconfig had apparently changed
> > > > > CONFIG_SATA_AHCI from y to m and system still booted. But between
> > > > > 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
> > > > >
> > > > > So make oldconfig is not 100% trustworthy in this case. I do not
> > > > > know if this is a problem that should be fixed. Ask if you want
> > > > > any .config diffs.
> > > > >
> > > > > I am going to reboot with 2.6.35 to make sure it boots. Yes!
> > > > >
> > > > > I consider this boot problem solved unless someone wants to
> > > > > improve "make oldconfig" behavior.
> > > >
> > > > It would be good to be able to explain what you are seeing & describing,
> > > > so yes, if you can send a .config file that exhibits the problem, I'd
> > > > love to look at it.
> > > >
> > > > thanks,
> > > > ---
> > > > ~Randy
> > >
> > >
> > > Okay, here is the diff between 2.6.34-git4 and 2.6.34-git5
> > > It should be equivalent to make silentoldconfig as I made no
> > > changes, just enter to accept defaults. The git4 boots and
> > > git5 does not boot. (Both based off 2.6.34.1.config)
> >
> > Yes, I had just generated this same diff.
> > The only config change that could remotely make a difference is:
> > > +# CONFIG_SATA_AHCI_PLATFORM is not set
> >
> > and I don't see how it could matter.
> >
> > > (and attached config-2.6.34-git4.gz, because .config was too
> > > big for mail list last time.)
> >
> > Last time being recently? lkml accepts email sizes (with attachments)
> > up to 300 KB, IIRC.
>
> Maybe http://lkml.indiana.edu/hypermail/linux/kernel/1008.0/index.html
> throws out large email but the actual lkml does not? I did not see
> it show up; here is header of email that had large (56.48K) .config:
>
> From: Donald Parsons
> To: Randy Dunlap
> Cc: linux-kernel <[email protected]>, Linus Torvalds
> Subject: Re: Linux 2.6.35
> Date: 08/01/2010 11:41:31 PM (this is EDT)
> Mailer: Evolution 2.28.3 (2.28.3-1.fc12)
>
>
> > > --- config-2.6.34-git4 2010-08-01 19:52:48.000000000 -0400
> > > +++ config-2.6.34-git5 2010-08-01 18:10:14.000000000 -0400
> > > @@ -1,7 +1,7 @@
> > > #
> > > # Automatically generated make config: don't edit
> ...deleted most lines...
> > > -#
> > > # CONFIG_STAGING is not set
> > > CONFIG_X86_PLATFORM_DEVICES=y
> > > # CONFIG_ACER_WMI is not set
> > >
> > > -------------------------------------------
> > >
> > > Can possibly duplicate problem if you have a
> > > sata based PC from last few years.
> > >
> > > Set CONFIG_ATA=m
> >
> > That's already =m in this config file.
> >
> > > and this becomes CONFIG_SATA_AHCI=m (cannot select=y)
> >
> > That's as expected. CONFIG_ATA value controls CONFIG_SATA_AHCI
> > possible values.
> >
> > >
> > > Then 2.6.34.[01] (probably 2 also) will boot.
> > > Make silentoldconfig with this .config and see
> > > that 2.6.35 will not boot.
> >
> > So with CONFIG_ATA=m and CONFIG_SATA_AHCI=m, does 2.6.34-git4 boot
> > but 2.6.34-git5 fails to boot?
>
> Yes, that is exactly correct.
OK, I built and booted 2.6.34-git4 and -git5 with your .config file
and only default changes for -git5.
They both booted successfully for me on an f11 box.
I am not using dracut, if that matters.
I don't know what to try next.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 08/02/2010 10:31 PM, Donald Parsons wrote:
> Using your suggestion as to where the problem lies, I investigated
> more deeply and found:
>
> I've now got 2.6.35-rc6-git3 to boot (and almost certainly 2.6.35 final)
>
> Make oldconfig broke at the transition where boot began failed, ie,
> between 2.6.34-git4 and 2.6.34-git5. Even though modules are the
> same, boot fails. If I use gconfig and set CONFIG_SATA_AHCI=y
> instead of CONFIG_SATA_AHCI=m it works, except cannot select =y
> unless CONFIG_ATA changed from m to y.
>
> So at some point in past, make oldconfig had apparently changed
> CONFIG_SATA_AHCI from y to m and system still booted. But between
> 2.6.34-git4 and 2.6.34-git5 the ability to boot was lost.
>
> So make oldconfig is not 100% trustworthy in this case. I do not
> know if this is a problem that should be fixed. Ask if you want
> any .config diffs.
The modules are not necessarily the same: "libahci" was introduced in
commit 365cfa1ed5a36f9bcb9f64c9f0f52155af2e9fef
Author: Anton Vorontsov <[email protected]>
Date: Sun Mar 28 00:22:14 2010 -0400
ahci: Move generic code into libahci
so there exists the possibility that the initramfs builder, or whatever
is being used to load your ATA drivers, missed this dependency. Modern
initramfs builders should be able to figure out module dependencies, so
this /shouldn't/ be an issue... but it might be.
Jeff
On Mon, 2010-08-02 at 11:51 +0300, Thomas Backlund wrote:
> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage%
> treeImage.% cuImage.% simpleImage.%
>
> Now, I dont know if this is "intended breakage" by the make update, or
> if the Makefile needs to be updated....
The change is intentional. Note, though, that this syntax was always
dodgy, even in previous versions of GNU make.
If you wrote it exactly as you did, where all the explicit targets come
first and all the implicit targets come second, then it seems to have
been interpreted correctly.
However, if you did it any other way (for example, put some explicit
targets after the first implicit target) then make would silently throw
away all the targets starting with the first implicit target.
Since the syntax used here wasn't ever described in the documentation,
rather than reworking it as a new feature I decided to follow the docs
and disallow it, and be verbose about the error.
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist