Another week, another -rc. This should be the last for the 37 series,
so I still expect the merge window to open early January when people
are hopefully back to working order after having eaten (and drunk) too
much.
The -rc8 release shouldn't be all that exciting. The most noticeable
is probably the fact that hopefully the "blank screen" problem with
intel graphics is fixed. But on the whole, it's all just a collection
of random fixes all over.
The diffstat doesn't look very interesting, and the appended shortlog
probably does give about as much information as you'd want.
Go wild, and ring in the new year with a new kernel.
Linus
---
Aaro Koskinen (1):
gpiolib: gpio_request_one(): add missing gpio_free()
Ahmed S. Darwish (1):
RAMOOPS: Don't overflow over non-allocated regions
Alex Deucher (7):
drm/radeon/kms: disable ss fixed ref divide
drm/radeon/kms: disable the r600 cb offset checker for linear surfaces
drm/radeon/kms/evergreen: flush hdp cache when flushing gart tlb
drm/radeon/kms: fix evergreen asic reset
drm/radeon/kms/evergreen: reset the grbm blocks at resume and init
drm/radeon/kms: reorder display resume to avoid problems
drm/radeon/kms: fix bug in r600_gpu_is_lockup
Andreas Mohr (1):
net: Add USB PID for new MOSCHIP USB ethernet controller MCS7832 variant
Andres Salomon (3):
MAINTAINERS: update geode entry
cs5535-gpio: don't apply errata #36 to edge detect GPIOs
cs5535-gpio: handle GPIO regs where higher (clear) bits are set
Andrey Vagin (1):
ipv6: delete expired route in ip6_pmtu_deliver
Arnaldo Carvalho de Melo (1):
perf buildid-list: Fix error return for success
Arnaud Ebalard (1):
asix: add USB ID for Logitec LAN-GTJ U2A
Axel Lin (1):
backlight: cr_bllcd.c: fix a memory leak
Baruch Siach (1):
[media] mx2_camera: fix pixel clock polarity configuration
Ben Hutchings (4):
bonding/vlan: Remove redundant VLAN tag insertion logic
bonding: Change active slave quietly when bond is down
bonding/vlan: Fix mangled NAs on slaves without VLAN tag insertion
tehuti: Firmware filename is tehuti/bdx.bin
Benjamin Herrenschmidt (1):
drm/radeon: Add early unregister of firmware fb's
Changli Gao (1):
net_sched: always clone skbs
Chris Wilson (5):
drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD
drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
agp/intel: Fix missed cached memory flags setting in i965_write_entry()
drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
drm: Include the connector name in the output_poll_execute() debug message
Christian Lamparter (1):
p54usb: add 5 more USBIDs
Dan Carpenter (4):
[media] lirc_dev: stray unlock in lirc_dev_fop_poll()
[media] lirc_dev: fixes in lirc_dev_fop_read()
typhoon: memory corruption in typhoon_get_drvinfo()
USB: mcs7830: return negative if auto negotiate fails
Dan Rosenberg (1):
irda: prevent integer underflow in IRLMP_ENUMDEVICES
Dave Airlie (3):
drm/radeon: use aperture size not vram size for overlap tests
Revert "drm: Don't try and disable an encoder that was never enabled"
fb: fix overlapping test off-by-one.
David Daney (1):
of/i2c: Fix request module by alias
David Flynn (1):
drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to
DVI converter
David Henningsson (1):
ALSA: HDA: Add auto-mute for Thinkpad SL410/SL510
David Howells (1):
KEYS: Don't call up_write() if __key_link_begin() returns an error
David S. Miller (2):
net: Fix range checks in tcf_valid_offset().
Revert "ipv4: Allow configuring subnets as local addresses"
David Sharp (1):
ring_buffer: Off-by-one and duplicate events in ring_buffer_read_page
David Stevens (2):
bridge: fix IPv6 queries for bridge multicast snooping
ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed.
Dmitry V. Levin (1):
netlink: fix gcc -Wconversion compilation warning
Don Fry (1):
MAINTAINERS: email address change
Eduardo Costa (1):
p54usb: New USB ID for Gemtek WUBI-100GW
Eric Dumazet (3):
net_sched: sch_sfq: fix allot handling
tcp: fix listening_get_next()
ipv4: dont create routes on down devices
Fabio Estevam (1):
video: imxfb: Fix the maximum value for yres
Florian Fainelli (2):
gpio: Fix null pointer dereference while accessing rdc321x platform_data
watchdog: Fix null pointer dereference while accessing rdc321x
platform_data
Franck Bui-Huu (3):
perf probe: Fix use of kernel image path given by 'k' option
perf symbols: Stop using vmlinux files with no symbols
perf buildid-cache: Fix symbolic link handling
Guennadi Liakhovetski (5):
[media] soc-camera: fix static build of the sh_mobile_csi2.c driver
fbdev: sh-mobile: restore display size configuration
fbdev: sh-mobile: retrieve and propagate display sizes from EDID
[media] v4l: soc-camera: fix multiple simultaneous user case
fbdev: sh_mobile_lcdc: increase maximum framebuffer size to support 1080p
H. Peter Anvin (1):
x86, kexec: Limit the crashkernel address appropriately
Herton Ronaldo Krzesinski (1):
mac80211: avoid calling ieee80211_work_work unconditionally
Hillf Danton (1):
bonding: Fix slave selection bug.
Imre Kaloz (1):
ARM: fix IXP4xx build failure
Ivan Vecera (1):
be2net: use mutex instead of spin lock for mbox_lock
James Bottomley (1):
[SCSI] fix up documentation for change in ->queuecommand to
lockless calling
Jarek Poplawski (2):
sundance: Fix oopses with corrupted skb_shared_info
epic100: hamachi: yellowfin: Fix skb allocation size
Jarod Wilson (10):
[media] mceusb: add support for Conexant Hybrid TV RDU253S
[media] nuvoton-cir: improve buffer parsing responsiveness
[media] mceusb: fix up reporting of trailing space
[media] mceusb: buffer parsing fixups for 1st-gen device
[media] IR: add tv power scancode to rc6 mce keymap
[media] mceusb: fix keybouce issue after parser simplification
[media] streamzap: merge timeout space with trailing space
[media] mceusb: add another Fintek device ID
[media] mceusb: fix inverted mask inversion logic
[media] mceusb: set a default rx timeout
Jeff Garzik (1):
pata_cs5536: avoid implicit MSR API inclusion on x86-64
Jeff Mahoney (1):
taskstats: pad taskstats netlink response for aligment issues on ia64
Jesper Juhl (2):
ALSA: pcm: remember to always call va_end() on stuff that we va_start()
x86/microcode: Fix double vfree() and remove redundant pointer
checks before vfree()
Jing Huang (1):
[SCSI] bfa: rename log_level to bfa_log_level
Johan Hedberg (1):
Bluetooth: Fix initial RFCOMM DLC security level
Johannes Berg (3):
iwlagn: rename enhanced txpower fields
mac80211: fix mesh forwarding
led_class: fix typo in blink API
Johannes Stezenbach (1):
mac80211/rt2x00: add ieee80211_tx_status_ni()
Jun Nie (1):
Bluetooth: add NULL pointer check in HCI
Kailang Yang (2):
ALSA: hda - Add fix-up for Sony VAIO with ALC275 codecs
ALSA: hda - Don't apply ALC269-specific initialization to ALC275
Ken Kawasaki (1):
axnet_cs: move id (0x1bf, 0x2328) to axnet_cs
Len Brown (1):
Revert "ACPI battery: update status upon sysfs query"
Linus Torvalds (1):
Linux 2.6.37-rc8
Mark Brown (2):
mfd: Supply IRQ base for WM832x devices
mfd: Support additional parent IDs for wm831x
Masami Hiramatsu (2):
perf tools: Fix lazy wildcard matching
perf probe: Fix to support libdwfl older than 0.148
Mattias Wallin (1):
mfd: Fix ab8500-core interrupt ffs bit bug
Meelis Roos (1):
hostap: remove netif_stop_queue from init
Mel Gorman (1):
mm: vmscan: tracepoint: account for scanned pages similarly for
both ftrace and vmstat
Michal Nazarewicz (1):
mm/migrate.c: fix compilation error
Michał Mirosław (1):
net/veth: Fix packet checksumming
Minchan Kim (1):
mm/compaction.c: avoid double mem_cgroup_del_lru()
Mingkai Hu (2):
spi/fsl_espi: change the read behaviour of the SPIRF
spi/fsl_espi: fix wrong setting of the address in the command buffer
Nicolas Ferre (1):
mmc: atmel-mci: fix multiblock SDIO transfers
Octavian Purdila (1):
net: fix nulls list corruptions in sk_prot_alloc
Paul Bender (1):
[media] rc: fix sysfs entry for mceusb and streamzap
Paul Mundt (6):
sh: Fix up SH4-202 clkfwk build.
sh: mach-se: Fix up SE7206 build.
nommu: Fix up vmalloc_node() symbol export regression.
nommu: Provide stubbed alloc/free_vm_area() implementation.
sh: Fix up SH7201 clkfwk build.
sh: intc: Initialize radix tree gfp mask explicitly.
Prasad Joshi (2):
logfs: fix deadlock in logfs_get_wblocks, hold and wait on
super->s_write_mutex
logfs: fix "Kernel BUG at readwrite.c:1193"
Rafael J. Wysocki (4):
ACPI: Execute _PRW for devices reported as inactive or not present
atl1c: Do not use legacy PCI power management
PCI hotplug: Fix unexpected driver unregister in pciehp_acpi.c
ACPI / ACPICA: Disable GPEs during initialization
Sebastian Andrzej Siewior (1):
drivers/spi/spi.c: don't release the spi device twice
Sunil Mushran (2):
ocfs2/dlm: Migrate lockres with no locks if it has a reference
ocfs2: Adjust masklog flag values
Sven Neumann (1):
libertas: fix potential NULL-pointer dereference
Sylwester Nawrocki (6):
[media] s5p-fimc: BKL lock removal - compilation fix
[media] s5p-fimc: Fix vidioc_g_crop/cropcap on camera sensor
[media] s5p-fimc: Explicitly add required header file
[media] s5p-fimc: Convert m2m driver to unlocked_ioctl
[media] s5p-fimc: Use correct fourcc code for 32-bit RGB format
[media] s5p-fimc: Fix output DMA handling in S5PV310 IP revisions
Takashi Iwai (4):
mmc: Fix re-probing with PM_POST_RESTORE notification
ALSA: hda - Fix conflict of d-mic capture volume controls
ALSA: hda - Try to find an empty control index when it's occupied
ALSA: hda - Fix GPIO2-fixup for Sony laptops
Tao Ma (2):
ocfs2: Hold ip_lock when set/clear flags for indexed dir.
ocfs2: Fix system inodes cache overflow.
Tejun Heo (4):
percpu: print out alloc information with KERN_DEBUG instead of KERN_INFO
libata-sff: fix HSM_ST_ERR handling in __ata_sff_port_intr()
libata: no special completion processing for EH commands
libata: issue DIPM enable commands with LPM state updated
Theodore Ts'o (1):
ext4: fix on-line resizing regression
Tim Harvey (1):
mac80211: Fix NULL-pointer deference on ibss merge when not ready
Tristan Ye (1):
Ocfs2: Teach 'coherency=full' O_DIRECT writes to correctly
up_read i_alloc_sem.
Wei Yongjun (1):
sctp: fix the return value of getting the sctp partial delivery point
Wey-Yi Guy (1):
iwlagn: implement layout-agnostic EEPROM reading
Will Newton (1):
include/linux/unaligned: pack the whole struct rather than just the field
Wolfram Sang (4):
rtc: rs5c372: fix buffer size
powerpc/mpc5200: include fs.h in mpc52xx_gpt.c
spi/mpc52xx-spi: fix annotation for remove()-pointer
pata_mpc52xx: driver needs BMDMA
Wu Fengguang (1):
writeback: do uninterruptible sleep in balance_dirty_pages()
Wu Zhangjin (1):
pata_cs5536: Add support for non-X86_32 platforms
Yauhen Kharuzhy (1):
mmc: at91_mci: fix multiblock SDIO transfers
Yong Zhang (1):
kthread_work: make lockdep happy
stephen hemminger (1):
ipv6: don't flush routes when setting loopback down
On Wed, Dec 29, 2010 at 9:18 AM, Linus Torvalds
<[email protected]> wrote:
> The -rc8 release shouldn't be all that exciting. The most noticeable
> is probably the fact that hopefully the "blank screen" problem with
> intel graphics is fixed. But on the whole, it's all just a collection
> of random fixes all over.
> Chris Wilson (5):
> drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
For some reason, this does not work on my Lenovo X201s. Reverting the
commit solves the "blank screen" problem.
# lspci -v
00:02.0 0300: 8086:0046 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device 215a
Flags: bus master, fast devsel, latency 0, IRQ 42
Memory at f2000000 (64-bit, non-prefetchable) [size=4M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915
# dmesg
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
i915 0000:00:02.0: irq 42 for MSI/MSI-X
vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
Console: switching to colour frame buffer device 180x56
fb0: inteldrmfb frame buffer device
drm: registered panic notifier
acpi device:02: registered as cooling_device4
input: Video Bus as
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input7
ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
commit 448f53a1ede54eb854d036abf54573281412d650
Author: Chris Wilson <[email protected]>
Date: Tue Dec 14 20:06:20 2010 +0000
drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
Fixes the lack of output on the LVDS panel of the Lenovo U160.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31596
Reported-and-tested-by: Dirk Gouders <[email protected]>
Cc: [email protected]
Signed-off-by: Chris Wilson <[email protected]>
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
index b0b1200..2b20786 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -270,7 +270,7 @@ parse_general_features(struct drm_i915_private *dev_priv,
general->ssc_freq ? 66 : 48;
else if (IS_GEN5(dev) || IS_GEN6(dev))
dev_priv->lvds_ssc_freq =
- general->ssc_freq ? 100 : 120;
+ general->ssc_freq ? 120 : 100;
else
dev_priv->lvds_ssc_freq =
general->ssc_freq ? 100 : 96;
Thanks,
Jeff
On Wed, Dec 29, 2010 at 07:51, Jeff Chua <[email protected]> wrote:
> On Wed, Dec 29, 2010 at 9:18 AM, Linus Torvalds
> <[email protected]> wrote:
>>
>> The -rc8 release shouldn't be all that exciting. The most noticeable
>> is probably the fact that hopefully the "blank screen" problem with
>> intel graphics is fixed. But on the whole, it's all just a collection
>> of random fixes all over.
>
>> Chris Wilson (5):
>> drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>
>
> For some reason, this does not work on my Lenovo X201s. Reverting the commit
> solves the "blank screen" problem.
>
-rc8 does not fix the problem for this Dell XPS M1330 (GM965/GL960) too.
> # lspci -v
00:02.0 VGA compatible controller: Intel Corporation Mobile
GM965/GL960 Integrated Graphics Controller (rev 0c)
Subsystem: Dell Device 0209
Flags: bus master, fast devsel, latency 0, IRQ 40
Memory at f6e00000 (64-bit, non-prefetchable) [size=1M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at eff8 [size=8]
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)
Subsystem: Dell Device 0209
Flags: bus master, fast devsel, latency 0
Memory at f6f00000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [d0] Power Management version 3
> # dmesg
I afraid mine is not as full as Jeff's, but here it is:
[ 0.376455] Linux agpgart interface v0.103
[ 0.376717] agpgart-intel 0000:00:00.0: Intel 965GM Chipset
[ 0.376960] agpgart-intel 0000:00:00.0: detected gtt size: 524288K
total, 262144K mappable
[ 0.377981] agpgart-intel 0000:00:00.0: detected 8192K stolen memory
[ 0.381891] ACPI: Battery Slot [BAT0] (battery present)
[ 0.385140] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000
[ 0.385283] [drm] Initialized drm 1.1.0 20060810
[ 0.385328] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.385358] i915 0000:00:02.0: setting latency timer to 64
[ 0.414146] i915 0000:00:02.0: irq 40 for MSI/MSI-X
[ 0.630199] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 0.630554] [drm] initialized overlay support
[ 0.914282] Console: switching to colour frame buffer device 160x50
[ 0.916905] fb0: inteldrmfb frame buffer device
[ 0.916928] drm: registered panic notifier
[ 0.929874] acpi device:35: registered as cooling_device2
[ 0.930341] input: Video Bus as
/devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:01/input/input3
[ 0.930395] ACPI: Video Device [VID1] (multi-head: yes rom: no post: no)
[ 0.930446] [Firmware Bug]: Duplicate ACPI video bus devices for
the same VGA controller, please try module parameter
"video.allow_duplicates=1"if the current driver doesn't work.
[ 0.930573] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
> commit 448f53a1ede54eb854d036abf54573281412d650
> Author: Chris Wilson <[email protected]>
> Date: Tue Dec 14 20:06:20 2010 +0000
>
> drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
Reverting this commit does not change anything on the laptop.
Still blank (well, no backlight) after DPMS suspend. I use this
line to test:
$ xset dpms force standby; sleep 1; xset dpms force on
The screen is always back on in 2.6.35 and always comes back with
backlight off in 2.6.36.
On Tue, Dec 28, 2010 at 05:18:12PM -0800, Linus Torvalds wrote:
> Another week, another -rc. This should be the last for the 37 series,
There's also the issue with oopsing when physically removing the battery
from the system. I have a proposed fix but no acks/nacks from ACPI guys
yet:
https://patchwork.kernel.org/patch/418751/
--
Regards/Gruss,
Boris.
On Wednesday, December 29, 2010, Borislav Petkov wrote:
> On Tue, Dec 28, 2010 at 05:18:12PM -0800, Linus Torvalds wrote:
> > Another week, another -rc. This should be the last for the 37 series,
>
> There's also the issue with oopsing when physically removing the battery
> from the system. I have a proposed fix but no acks/nacks from ACPI guys
> yet:
>
> https://patchwork.kernel.org/patch/418751/
The commit causing this problem has been reverted:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cde44d1740bcb3dcfecbf792a71826431e61686e
Which means that the problem it attepmted to address is back.
Thanks,
Rafael
On Tue, 28 Dec 2010 17:18:12 -0800 Linus Torvalds wrote:
> Another week, another -rc. This should be the last for the 37 series,
> so I still expect the merge window to open early January when people
> are hopefully back to working order after having eaten (and drunk) too
> much.
>
> The -rc8 release shouldn't be all that exciting. The most noticeable
> is probably the fact that hopefully the "blank screen" problem with
> intel graphics is fixed. But on the whole, it's all just a collection
> of random fixes all over.
I booted -rc8 and found that my video worked for only a few seconds,
then it goes blank. -rc7 and -rc6 do the same. -rc5 is OK.
The only significant difference that I can see in the kernel message log
is this:
from 2.6.37-rc5:
[drm] initialized overlay support
i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
i2c i2c-3: master_xfer[1] R, addr=0x50, len=1
i2c i2c-3: master_xfer[0] W, addr=0x50, len=1
i2c i2c-3: master_xfer[1] R, addr=0x50, len=128
fbcon: inteldrmfb (fb0) is primary device
Console: switching to colour frame buffer device 160x64
fb0: inteldrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
and from 2.6.37-rc6:
[drm] initialized overlay support
No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
fbcon: inteldrmfb (fb0) is primary device
Console: switching to colour frame buffer device 128x48
fb0: inteldrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Full kernel boot logs are in http://www.xenotime.net/linux/logs/
(2637-rc5.notimes and 2637-rc6.notimes).
The 2.6.37-rc5 kernel config file is attached. It is close to an
allmodconfig.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/
On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap <[email protected]> wrote:
>
> The only significant difference that I can see in the kernel message log
> is this:
Hmm. I suspect that difference should have gone away with commit
92971021c6328 (Revert "drm: Don't try and disable an encoder that was
never enabled"), but clearly that didn't fix your blank screen.
Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
you? It does for some people..
Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
we please just disable spread-spectrum entirely? Or perhaps only if we
notice that it was enabled already? Or something?
Linus
On Wed, 29 Dec 2010 11:40:04 -0800
Linus Torvalds <[email protected]> wrote:
> On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap <[email protected]> wrote:
> >
> > The only significant difference that I can see in the kernel message log
> > is this:
>
> Hmm. I suspect that difference should have gone away with commit
> 92971021c6328 (Revert "drm: Don't try and disable an encoder that was
> never enabled"), but clearly that didn't fix your blank screen.
>
> Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
> ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
> you? It does for some people..
>
> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> we please just disable spread-spectrum entirely? Or perhaps only if we
> notice that it was enabled already? Or something?
Randy, Jeff and Alex, does the below help at all? If so, it may be the
minimal fix we want for 2.6.37.
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
index 2b20786..d27d016 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
dev_priv->int_tv_support = general->int_tv_support;
dev_priv->int_crt_support = general->int_crt_support;
dev_priv->lvds_use_ssc = general->enable_ssc;
+ /* force disable until we can parse this correctly */
+ if (IS_GEN5(dev) || IS_GEN6(dev))
+ dev_priv->lvds_use_ssc = 0;
if (dev_priv->lvds_use_ssc) {
if (IS_I85X(dev))
--
Jesse Barnes, Intel Open Source Technology Center
Le 29/12/10 21:16, Jesse Barnes a ?crit :
> On Wed, 29 Dec 2010 11:40:04 -0800
> Linus Torvalds <[email protected]> wrote:
>
>> On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap <[email protected]> wrote:
>>>
>>> The only significant difference that I can see in the kernel message log
>>> is this:
>>
>> Hmm. I suspect that difference should have gone away with commit
>> 92971021c6328 (Revert "drm: Don't try and disable an encoder that was
>> never enabled"), but clearly that didn't fix your blank screen.
>>
>> Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
>> ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
>> you? It does for some people..
>>
>> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
>> we please just disable spread-spectrum entirely? Or perhaps only if we
>> notice that it was enabled already? Or something?
>
> Randy, Jeff and Alex, does the below help at all? If so, it may be the
> minimal fix we want for 2.6.37.
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
> index 2b20786..d27d016 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
> dev_priv->int_tv_support = general->int_tv_support;
> dev_priv->int_crt_support = general->int_crt_support;
> dev_priv->lvds_use_ssc = general->enable_ssc;
> + /* force disable until we can parse this correctly */
> + if (IS_GEN5(dev) || IS_GEN6(dev))
> + dev_priv->lvds_use_ssc = 0;
>
> if (dev_priv->lvds_use_ssc) {
> if (IS_I85X(dev))
>
>
I also encountered the black screen problem after commit 448f53a1. I can
confirm that the above patch solves the problem.
Fran?ois Valenduc
On Wed, Dec 29, 2010 at 21:16, Jesse Barnes <[email protected]> wrote:
> On Wed, 29 Dec 2010 11:40:04 -0800
> Linus Torvalds <[email protected]> wrote:
>> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
>> we please just disable spread-spectrum entirely? Or perhaps only if we
>> notice that it was enabled already? Or something?
>
> Randy, Jeff and Alex, does the below help at all? If so, it may be the
> minimal fix we want for 2.6.37.
Something broke your patch: whitespace instead of tabs.
> diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
> index 2b20786..d27d016 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
> dev_priv->int_tv_support = general->int_tv_support;
> dev_priv->int_crt_support = general->int_crt_support;
> dev_priv->lvds_use_ssc = general->enable_ssc;
> + /* force disable until we can parse this correctly */
This comment seems to imply that SSC wasn't used at all until recently, right?
> + if (IS_GEN5(dev) || IS_GEN6(dev))
> + dev_priv->lvds_use_ssc = 0;
Doesn't change anything here. Display stays blank.
On Wed, 29 Dec 2010 22:11:09 +0100
Alex Riesen <[email protected]> wrote:
> On Wed, Dec 29, 2010 at 21:16, Jesse Barnes <[email protected]> wrote:
> > On Wed, 29 Dec 2010 11:40:04 -0800
> > Linus Torvalds <[email protected]> wrote:
> >> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> >> we please just disable spread-spectrum entirely? Or perhaps only if we
> >> notice that it was enabled already? Or something?
> >
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Something broke your patch: whitespace instead of tabs.
Yeah, just copy & pasted, sorry.
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
> > index 2b20786..d27d016 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
> > dev_priv->int_tv_support = general->int_tv_support;
> > dev_priv->int_crt_support = general->int_crt_support;
> > dev_priv->lvds_use_ssc = general->enable_ssc;
> > + /* force disable until we can parse this correctly */
>
> This comment seems to imply that SSC wasn't used at all until recently, right?
No, we enabled it previously, but it apparently doesn't work on all
platforms, probably because we're either looking in the wrong place for
the bit that tells us to enable it or not, or we're getting the wrong
frequency on some platforms. Probably both (the VBIOS guys work
closely with the Windows driver team that consumes this data, and don't
always tell us when they make incompatible changes).
> > + if (IS_GEN5(dev) || IS_GEN6(dev))
> > + dev_priv->lvds_use_ssc = 0;
>
> Doesn't change anything here. Display stays blank.
Sounds like your problem is separate from SSC then, more likely related
to panel power or backlight control. Have you tried bisecting for the
problem between 2.6.35 and 2.6.36?
--
Jesse Barnes, Intel Open Source Technology Center
> > Doesn't change anything here. Display stays blank.
>
> Sounds like your problem is separate from SSC then, more likely related
> to panel power or backlight control. Have you tried bisecting for the
> problem between 2.6.35 and 2.6.36?
Nevermind, I just checked out the bug, looks like it is panel power
related. Can you try this patch?
If it doesn't work, can you send me the output of intel_reg_dumper from
before you turn off the display and after you try to turn it back on?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index aa23070..830e3b0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -82,8 +82,6 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
lvds_reg = LVDS;
}
- I915_WRITE(lvds_reg, I915_READ(lvds_reg) | LVDS_PORT_EN);
-
if (intel_lvds->pfit_dirty) {
/*
* Enable automatic panel scaling so that non-native modes
@@ -104,7 +102,7 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
}
I915_WRITE(ctl_reg, I915_READ(ctl_reg) | POWER_TARGET_ON);
- POSTING_READ(lvds_reg);
+ POSTING_READ(ctl_reg);
intel_panel_set_backlight(dev, dev_priv->backlight_level);
}
@@ -136,8 +134,7 @@ static void intel_lvds_disable(struct intel_lvds *intel_lvds)
intel_lvds->pfit_dirty = true;
}
- I915_WRITE(lvds_reg, I915_READ(lvds_reg) & ~LVDS_PORT_EN);
- POSTING_READ(lvds_reg);
+ POSTING_READ(ctl_reg);
}
static void intel_lvds_dpms(struct drm_encoder *encoder, int mode)
On Wed, Dec 29, 2010 at 22:18, Jesse Barnes <[email protected]> wrote:
>> > + if (IS_GEN5(dev) || IS_GEN6(dev))
>> > + dev_priv->lvds_use_ssc = 0;
>>
>> Doesn't change anything here. Display stays blank.
>
> Sounds like your problem is separate from SSC then, more likely related
> to panel power or backlight control. Have you tried bisecting for the
> problem between 2.6.35 and 2.6.36?
No. I assumed the bisection in the bug
https://bugzilla.kernel.org/show_bug.cgi?id=22672
was for the same problem as mine. It probably is not...
I'm running a bisect right now.
On Wed, 29 Dec 2010 12:16:01 -0800 Jesse Barnes wrote:
> On Wed, 29 Dec 2010 11:40:04 -0800
> Linus Torvalds <[email protected]> wrote:
>
> > On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap <[email protected]> wrote:
> > >
> > > The only significant difference that I can see in the kernel message log
> > > is this:
> >
> > Hmm. I suspect that difference should have gone away with commit
> > 92971021c6328 (Revert "drm: Don't try and disable an encoder that was
> > never enabled"), but clearly that didn't fix your blank screen.
> >
> > Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
> > ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
> > you? It does for some people..
> >
> > Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> > we please just disable spread-spectrum entirely? Or perhaps only if we
> > notice that it was enabled already? Or something?
>
> Randy, Jeff and Alex, does the below help at all? If so, it may be the
> minimal fix we want for 2.6.37.
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
> index 2b20786..d27d016 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
> dev_priv->int_tv_support = general->int_tv_support;
> dev_priv->int_crt_support = general->int_crt_support;
> dev_priv->lvds_use_ssc = general->enable_ssc;
> + /* force disable until we can parse this correctly */
> + if (IS_GEN5(dev) || IS_GEN6(dev))
> + dev_priv->lvds_use_ssc = 0;
>
> if (dev_priv->lvds_use_ssc) {
> if (IS_I85X(dev))
>
>
> --
Ugh, looks like I have confused things horribly. Sorry about this.
2.6.37-rc8 with no patches works for me. My original report was incorrect --
I was using -rc7 when I thought I was using -rc8. :(
Regrets,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
> > index 2b20786..d27d016 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
> > dev_priv->int_tv_support = general->int_tv_support;
> > dev_priv->int_crt_support = general->int_crt_support;
> > dev_priv->lvds_use_ssc = general->enable_ssc;
> > + /* force disable until we can parse this correctly */
> > + if (IS_GEN5(dev) || IS_GEN6(dev))
> > + dev_priv->lvds_use_ssc = 0;
> >
> > if (dev_priv->lvds_use_ssc) {
> > if (IS_I85X(dev))
> >
> >
> > --
>
> Ugh, looks like I have confused things horribly. Sorry about this.
>
> 2.6.37-rc8 with no patches works for me. My original report was incorrect --
> I was using -rc7 when I thought I was using -rc8. :(
Can you confirm that the above doesn't break your setup just in case we
need to apply it?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes <[email protected]> wrote:
>> > Doesn't change anything here. Display stays blank.
>>
>> Sounds like your problem is separate from SSC then, more likely related
>> to panel power or backlight control. Have you tried bisecting for the
>> problem between 2.6.35 and 2.6.36?
>
> Nevermind, I just checked out the bug, looks like it is panel power
> related. Can you try this patch?
Tried. Does not work.
> If it doesn't work, can you send me the output of intel_reg_dumper from
> before you turn off the display and after you try to turn it back on?
See the links below (sorry, they files are a bit large):
Before running "xset dpms force standby":
http://vin-soft.org/~raa/public/test/intel_gpu_dump-before
After running "sleep 3"
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend
After running "xset dpms force on"
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on
After closing and opening the lid (displays backlight is back)
http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
On Thu, 30 Dec 2010 00:09:56 +0100
Alex Riesen <[email protected]> wrote:
> On Wed, Dec 29, 2010 at 22:53, Jesse Barnes <[email protected]> wrote:
> >> > Doesn't change anything here. Display stays blank.
> >>
> >> Sounds like your problem is separate from SSC then, more likely related
> >> to panel power or backlight control. Have you tried bisecting for the
> >> problem between 2.6.35 and 2.6.36?
> >
> > Nevermind, I just checked out the bug, looks like it is panel power
> > related. Can you try this patch?
>
> Tried. Does not work.
>
> > If it doesn't work, can you send me the output of intel_reg_dumper from
> > before you turn off the display and after you try to turn it back on?
>
> See the links below (sorry, they files are a bit large):
>
> Before running "xset dpms force standby":
>
> http://vin-soft.org/~raa/public/test/intel_gpu_dump-before
>
> After running "sleep 3"
>
> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend
>
> After running "xset dpms force on"
>
> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on
>
> After closing and opening the lid (displays backlight is back)
>
> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
I need the intel_reg_dumper output, not intel_gpu_dump. :)
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes <[email protected]> wrote:
>> After closing and opening the lid (displays backlight is back)
>>
>> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
>
> I need the intel_reg_dumper output, not intel_gpu_dump. :)
>
Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is
the latest on http://xorg.freedesktop.org/archive/individual/app/,
so I assumed you just mistyped the name. Is it in git only? ...
Yeah, look like it is in git only, which I have problems to compile
(I have a bit of obsoleted system).
On Thu, Dec 30, 2010 at 00:20, Alex Riesen <[email protected]> wrote:
> On Thu, Dec 30, 2010 at 00:13, Jesse Barnes <[email protected]> wrote:
>>> After closing and opening the lid (displays backlight is back)
>>>
>>> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
>>
>> I need the intel_reg_dumper output, not intel_gpu_dump. :)
>>
>
> Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is
> the latest on http://xorg.freedesktop.org/archive/individual/app/,
> so I assumed you just mistyped the name. Is it in git only? ...
> Yeah, look like it is in git only, which I have problems to compile
> (I have a bit of obsoleted system).
>
Is there any other way to get at the dump? Because it looks like
it is plainly impossible to build the tools. A lot of dependencies,
all really hard to get at on Ubuntu Jaunty.
On Wed, 29 Dec 2010 14:46:14 -0800 Jesse Barnes wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios
> > > index 2b20786..d27d016 100644
> > > --- a/drivers/gpu/drm/i915/intel_bios.c
> > > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > > @@ -263,6 +263,9 @@ parse_general_features(struct drm_i915_private *dev_priv,
> > > dev_priv->int_tv_support = general->int_tv_support;
> > > dev_priv->int_crt_support = general->int_crt_support;
> > > dev_priv->lvds_use_ssc = general->enable_ssc;
> > > + /* force disable until we can parse this correctly */
> > > + if (IS_GEN5(dev) || IS_GEN6(dev))
> > > + dev_priv->lvds_use_ssc = 0;
> > >
> > > if (dev_priv->lvds_use_ssc) {
> > > if (IS_I85X(dev))
> > >
> > >
> > > --
> >
> > Ugh, looks like I have confused things horribly. Sorry about this.
> >
> > 2.6.37-rc8 with no patches works for me. My original report was incorrect --
> > I was using -rc7 when I thought I was using -rc8. :(
>
> Can you confirm that the above doesn't break your setup just in case we
> need to apply it?
Yes, confirmed, my test platform still works with this patch applied.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/
On Thu, 30 Dec 2010 00:35:15 +0100
Alex Riesen <[email protected]> wrote:
> On Thu, Dec 30, 2010 at 00:20, Alex Riesen <[email protected]> wrote:
> > On Thu, Dec 30, 2010 at 00:13, Jesse Barnes <[email protected]> wrote:
> >>> After closing and opening the lid (displays backlight is back)
> >>>
> >>> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
> >>
> >> I need the intel_reg_dumper output, not intel_gpu_dump. :)
> >>
> >
> > Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is
> > the latest on http://xorg.freedesktop.org/archive/individual/app/,
> > so I assumed you just mistyped the name. Is it in git only? ...
> > Yeah, look like it is in git only, which I have problems to compile
> > (I have a bit of obsoleted system).
> >
>
> Is there any other way to get at the dump? Because it looks like
> it is plainly impossible to build the tools. A lot of dependencies,
> all really hard to get at on Ubuntu Jaunty.
That's the easiest way; I think there are existing packages available
as well, but you may have to check Karmic or newer.
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, Dec 30, 2010 at 01:02, Jesse Barnes <[email protected]> wrote:
> That's the easiest way; I think there are existing packages available
> as well, but you may have to check Karmic or newer.
Never mind. I'm lazy (that's not to say someone is too).
I redid the test:
Before running "xset dpms force standby":
http://vin-soft.org/~raa/public/test/intel_reg_dumper-before
After running "sleep 3"
http://vin-soft.org/~raa/public/test/intel_reg_dumper-suspend
After running "xset dpms force on; sleep 3"
http://vin-soft.org/~raa/public/test/intel_reg_dumper-xset-on
After closing and opening the lid (displays backlight is back)
http://vin-soft.org/~raa/public/test/intel_reg_dumper-lid
On Wed, 2010-12-29 at 20:08 +0800, Rafael J. Wysocki wrote:
> On Wednesday, December 29, 2010, Borislav Petkov wrote:
> > On Tue, Dec 28, 2010 at 05:18:12PM -0800, Linus Torvalds wrote:
> > > Another week, another -rc. This should be the last for the 37 series,
> >
> > There's also the issue with oopsing when physically removing the battery
> > from the system. I have a proposed fix but no acks/nacks from ACPI guys
> > yet:
> >
> > https://patchwork.kernel.org/patch/418751/
>
> The commit causing this problem has been reverted:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cde44d1740bcb3dcfecbf792a71826431e61686e
>
> Which means that the problem it attepmted to address is back.
>
Right.
After discussion with Len, we agreed that the real problem is that we
should not probe/unprobe power_supply class device in
acpi_battery_update.
And we also agreed on reverting that commit for now, and rewriting the
battery driver, sometime in Q1 2011, with the problem fixed.
Sorry that I didn't update this in the mailing list.
thanks,
rui
> Thanks,
> Rafael
> --
> 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/
Hello,
I wonder if the nfs-stuff is considered to be solved, because I still
see strange things.
During boot my machine sometimes (approx one out of two times) hangs with
the output pasted below on Sysctl-l. The irq
I'm not 100% sure it's related, but at least it seems to hang in
nfs_readdir. (When the serial irq happend that triggered the sysrq the
program counter was at 0xc014601c, which is fs/nfs/dir.c:647 for me.)
This is on 2.6.37-rc8 plus some patches for machine support on an ARM
machine.
Best regards
Uwe
[ 2700.100000] SysRq : Show State
[ 2700.100000] task PC stack pid father
[ 2700.100000] init S c0285d80 0 1 0 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c004f268>] (do_wait+0x1a4/0x20c)
[ 2700.100000] [<c004f0c4>] (do_wait+0x0/0x20c) from [<c004f378>] (sys_wait4+0xa8/0xc0)
[ 2700.100000] [<c004f2d0>] (sys_wait4+0x0/0xc0) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
[ 2700.100000] r8:c0034088 r7:00000072 r6:00000001 r5:0000001b r4:0140b228
[ 2700.100000] kthreadd S c0285d80 0 2 0 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006a30c>] (kthreadd+0x70/0xfc)
[ 2700.100000] [<c006a29c>] (kthreadd+0x0/0xfc) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] ksoftirqd/0 S c0285d80 0 3 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c0052714>] (run_ksoftirqd+0x5c/0x110)
[ 2700.100000] [<c00526b8>] (run_ksoftirqd+0x0/0x110) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] r8:00000000 r7:c00526b8 r6:00000000 r5:c7843f1c r4:c7859fac
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f1c
[ 2700.100000] kworker/0:0 S c0285d80 0 4 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
[ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
[ 2700.100000] kworker/u:0 S c0285d80 0 5 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
[ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
[ 2700.100000] watchdog/0 S c0285d80 0 6 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c008b418>] (watchdog+0xc0/0x110)
[ 2700.100000] [<c008b358>] (watchdog+0x0/0x110) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] r6:00000000 r5:c7843efc r4:c785ffac
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843efc
[ 2700.100000] khelper S c0285d80 0 7 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
[ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f1c
[ 2700.100000] sync_supers S c0285d80 0 8 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00cd114>] (bdi_sync_supers+0x38/0x50)
[ 2700.100000] [<c00cd0dc>] (bdi_sync_supers+0x0/0x50) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] r5:c7843f2c r4:c7895fac
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f2c
[ 2700.100000] bdi-default S c0285d80 0 9 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c02864b4>] (schedule_timeout+0x22c/0x27c)
[ 2700.100000] [<c0286288>] (schedule_timeout+0x0/0x27c) from [<c00ce014>] (bdi_forker_thread+0x3a8/0x41c)
[ 2700.100000] r8:c0363f80 r7:00000000 r6:00000000 r5:c03641e8 r4:00000000
[ 2700.100000] [<c00cdc6c>] (bdi_forker_thread+0x0/0x41c) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843efc
[ 2700.100000] kintegrityd S c0285d80 0 10 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
[ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843e9c
[ 2700.100000] kblockd S c0285d80 0 11 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
[ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843ec4
[ 2700.100000] rpciod S c0285d80 0 12 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
[ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843ebc
[ 2700.100000] kworker/0:1 S c0285d80 0 13 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
[ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c785be94
[ 2700.100000] khungtaskd S c0285d80 0 14 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c02864b4>] (schedule_timeout+0x22c/0x27c)
[ 2700.100000] [<c0286288>] (schedule_timeout+0x0/0x27c) from [<c0286584>] (schedule_timeout_interruptible+0x28/0x2c)
[ 2700.100000] r8:00000078 r7:00007fe9 r6:000003e9 r5:c034eef0 r4:00000064
[ 2700.100000] [<c028655c>] (schedule_timeout_interruptible+0x0/0x2c) from [<c008ada8>] (watchdog+0x54/0x2e8)
[ 2700.100000] [<c008ad54>] (watchdog+0x0/0x2e8) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f2c
[ 2700.100000] kswapd0 S c0285d80 0 15 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00c5ea4>] (kswapd+0x210/0x74c)
[ 2700.100000] [<c00c5c94>] (kswapd+0x0/0x74c) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f1c
[ 2700.100000] fsnotify_mark S c0285d80 0 16 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c011f884>] (fsnotify_mark_destroy+0x11c/0x144)
[ 2700.100000] [<c011f768>] (fsnotify_mark_destroy+0x0/0x144) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f34
[ 2700.100000] aio S c0285d80 0 17 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
[ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
[ 2700.100000] nfsiod S c0285d80 0 18 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
[ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
[ 2700.100000] crypto S c0285d80 0 19 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
[ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843ee4
[ 2700.100000] kworker/u:1 S c0285d80 0 24 2 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
[ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
[ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
[ 2700.100000] r7:00000013 r6:c004f4d8 r5:c006a208 r4:c785de94
[ 2700.100000] rcS S c0285d80 0 27 1 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c004f268>] (do_wait+0x1a4/0x20c)
[ 2700.100000] [<c004f0c4>] (do_wait+0x0/0x20c) from [<c004f378>] (sys_wait4+0xa8/0xc0)
[ 2700.100000] [<c004f2d0>] (sys_wait4+0x0/0xc0) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
[ 2700.100000] r8:c0034088 r7:00000072 r6:ffffffff r5:bee7880c r4:00000000
[ 2700.100000] run-parts S c0285d80 0 35 27 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c004f268>] (do_wait+0x1a4/0x20c)
[ 2700.100000] [<c004f0c4>] (do_wait+0x0/0x20c) from [<c004f378>] (sys_wait4+0xa8/0xc0)
[ 2700.100000] [<c004f2d0>] (sys_wait4+0x0/0xc0) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
[ 2700.100000] r8:c0034088 r7:00000072 r6:00000024 r5:bef7dcc4 r4:00000000
[ 2700.100000] S00splashutil R running 0 36 35 0x00000000
[ 2700.100000] Backtrace:
[ 2700.100000] [<c0037b54>] (dump_backtrace+0x0/0x110) from [<c0037c80>] (show_stack+0x1c/0x20)
[ 2700.100000] r7:c79cfd64 r6:00000000 r5:c7954600 r4:00000000
[ 2700.100000] [<c0037c64>] (show_stack+0x0/0x20) from [<c0046b78>] (sched_show_task+0xb0/0xcc)
[ 2700.100000] [<c0046ac8>] (sched_show_task+0x0/0xcc) from [<c0046bf0>] (show_state_filter+0x5c/0xc8)
[ 2700.100000] r5:c7954600 r4:c7954600
[ 2700.100000] [<c0046b94>] (show_state_filter+0x0/0xc8) from [<c01c5c40>] (sysrq_handle_showstate+0x18/0x1c)
[ 2700.100000] r8:20000093 r7:00000007 r6:00000001 r5:00000074 r4:c036ec5c
[ 2700.100000] [<c01c5c28>] (sysrq_handle_showstate+0x0/0x1c) from [<c01c6040>] (__handle_sysrq+0xe0/0x190)
[ 2700.100000] [<c01c5f60>] (__handle_sysrq+0x0/0x190) from [<c01c62d8>] (handle_sysrq+0x38/0x44)
[ 2700.100000] r8:c7999000 r7:00000100 r6:c7973640 r5:00010074 r4:c7864300
[ 2700.100000] [<c01c62a0>] (handle_sysrq+0x0/0x44) from [<c01da100>] (pl011_int+0x18c/0x5a4)
[ 2700.100000] [<c01d9f74>] (pl011_int+0x0/0x5a4) from [<c008b8b0>] (handle_IRQ_event+0x7c/0x1a8)
[ 2700.100000] [<c008b834>] (handle_IRQ_event+0x0/0x1a8) from [<c008de5c>] (handle_level_irq+0xc8/0x148)
[ 2700.100000] [<c008dd94>] (handle_level_irq+0x0/0x148) from [<c002d080>] (asm_do_IRQ+0x80/0xa4)
[ 2700.100000] r7:c74a05a4 r6:c74a0508 r5:00000000 r4:0000002f
[ 2700.100000] [<c002d000>] (asm_do_IRQ+0x0/0xa4) from [<c0033ab8>] (__irq_svc+0x38/0x80)
[ 2700.100000] Exception stack(0xc79cfe88 to 0xc79cfed0)
[ 2700.100000] fe80: c74a0508 00000000 c0145d24 c7487e60 00000000 c79cfee8
[ 2700.100000] fea0: c74a0508 c74a05a4 c7487e60 c79cfee8 c74a0508 c79cff4c c79ce000 c79cfed0
[ 2700.100000] fec0: c016ff10 c014601c 60000013 ffffffff
[ 2700.100000] r5:f5000000 r4:ffffffff
[ 2700.100000] [<c0145f0c>] (nfs_readdir+0x0/0x458) from [<c00fa298>] (vfs_readdir+0x7c/0xb0)
[ 2700.100000] [<c00fa21c>] (vfs_readdir+0x0/0xb0) from [<c00fa3fc>] (sys_getdents+0x70/0xb8)
[ 2700.100000] [<c00fa38c>] (sys_getdents+0x0/0xb8) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
[ 2700.100000] r7:0000008d r6:00000000 r5:402ed00c r4:402ed020
[ 2700.100000] Sched Debug Version: v0.09, 2.6.37-rc8-00065-g1cd48e3-dirty #35
[ 2700.100000] now at 2701202.749966 msecs
[ 2700.100000] .jiffies : 240010
[ 2700.100000] .sysctl_sched_latency : 6.000000
[ 2700.100000] .sysctl_sched_min_granularity : 0.750000
[ 2700.100000] .sysctl_sched_wakeup_granularity : 1.000000
[ 2700.100000] .sysctl_sched_child_runs_first : 0
[ 2700.100000] .sysctl_sched_features : 31855
[ 2700.100000] .sysctl_sched_tunable_scaling : 1 (logaritmic)
[ 2700.100000]
[ 2700.100000] cpu#0
[ 2700.100000] .nr_running : 1
[ 2700.100000] .load : 1024
[ 2700.100000] .nr_switches : 11875
[ 2700.100000] .nr_load_updates : 269696
[ 2700.100000] .nr_uninterruptible : 0
[ 2700.100000] .next_balance : 0.000000
[ 2700.100000] .curr->pid : 36
[ 2700.100000] .clock : 2700100.000000
[ 2700.100000] .cpu_load[0] : 1024
[ 2700.100000] .cpu_load[1] : 1024
[ 2700.100000] .cpu_load[2] : 1024
[ 2700.100000] .cpu_load[3] : 1024
[ 2700.100000] .cpu_load[4] : 1024
[ 2700.100000]
[ 2700.100000] cfs_rq[0]:
[ 2700.100000] .exec_clock : 0.000000
[ 2700.100000] .MIN_vruntime : 0.000001
[ 2700.100000] .min_vruntime : 2695651.938408
[ 2700.100000] .max_vruntime : 0.000001
[ 2700.100000] .spread : 0.000000
[ 2700.100000] .spread0 : 0.000000
[ 2700.100000] .nr_running : 1
[ 2700.100000] .load : 1024
[ 2700.100000] .nr_spread_over : 0
[ 2700.100000]
[ 2700.100000] rt_rq[0]:
[ 2700.100000] .rt_nr_running : 0
[ 2700.100000] .rt_throttled : 0
[ 2700.100000] .rt_time : 0.000000
[ 2700.100000] .rt_runtime : 950.000000
[ 2700.100000]
[ 2700.100000] runnable tasks:
[ 2700.100000] task PID tree-key switches prio exec-runtime sum-exec sum-sleep
[ 2700.100000] ----------------------------------------------------------------------------------------------------------
[ 2700.100000] R S00splashutils 36 2695651.938408 5397 120 0 0 0.000000 0.000000 0.000000
[ 2700.100000]
[ 2700.100000]
[ 2700.100000] Showing all locks held in the system:
[ 2700.100000] 4 locks held by S00splashutils/36:
[ 2700.100000] #0: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<c00fa268>] vfs_readdir+0x4c/0xb0
[ 2700.100000] #1: (&port_lock_key){-.-...}, at: [<c01d9f94>] pl011_int+0x20/0x5a4
[ 2700.100000] #2: (sysrq_key_table_lock){-.....}, at: [<c01c5f84>] __handle_sysrq+0x24/0x190
[ 2700.100000] #3: (tasklist_lock){.?.+..}, at: [<c007c404>] debug_show_all_locks+0x40/0x1a4
[ 2700.100000]
[ 2700.100000] =============================================
[ 2700.100000]
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Please cc the poor hapless NFS people too, who probably otherwise
wouldn't see it. And Arnd just in case it might be locking-related.
Trond, any ideas? The sysrq thing does imply that it's stuck in some
busy-loop in fs/nfs/dir.c, and line 647 is get_cache_page(), which in
turn implies that the endless loop is either the loop in
readdir_search_pagecache() _or_ in a caller. In particular, the
EBADCOOKIE case in the caller (nfs_readdir) looks suspicious. What
protects us from endless streams of EBADCOOKIE and a successful
uncached_readdir?
Linus
2010/12/30 Uwe Kleine-K?nig <[email protected]>:
> Hello,
>
> I wonder if the nfs-stuff is considered to be solved, because I still
> see strange things.
>
> During boot my machine sometimes (approx one out of two times) hangs with
> the output pasted below on Sysctl-l. ?The irq
>
> I'm not 100% sure it's related, but at least it seems to hang in
> nfs_readdir. ?(When the serial irq happend that triggered the sysrq the
> program counter was at 0xc014601c, which is fs/nfs/dir.c:647 for me.)
>
> This is on 2.6.37-rc8 plus some patches for machine support on an ARM
> machine.
>
> Best regards
> Uwe
>
> [ 2700.100000] SysRq : Show State
> [ 2700.100000] ? task ? ? ? ? ? ? ? ?PC stack ? pid father
> [ 2700.100000] init ? ? ? ? ?S c0285d80 ? ? 0 ? ? 1 ? ? ?0 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c004f268>] (do_wait+0x1a4/0x20c)
> [ 2700.100000] [<c004f0c4>] (do_wait+0x0/0x20c) from [<c004f378>] (sys_wait4+0xa8/0xc0)
> [ 2700.100000] [<c004f2d0>] (sys_wait4+0x0/0xc0) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
> [ 2700.100000] ?r8:c0034088 r7:00000072 r6:00000001 r5:0000001b r4:0140b228
> [ 2700.100000] kthreadd ? ? ?S c0285d80 ? ? 0 ? ? 2 ? ? ?0 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006a30c>] (kthreadd+0x70/0xfc)
> [ 2700.100000] [<c006a29c>] (kthreadd+0x0/0xfc) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ksoftirqd/0 ? S c0285d80 ? ? 0 ? ? 3 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c0052714>] (run_ksoftirqd+0x5c/0x110)
> [ 2700.100000] [<c00526b8>] (run_ksoftirqd+0x0/0x110) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] ?r8:00000000 r7:c00526b8 r6:00000000 r5:c7843f1c r4:c7859fac
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f1c
> [ 2700.100000] kworker/0:0 ? S c0285d80 ? ? 0 ? ? 4 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
> [ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
> [ 2700.100000] kworker/u:0 ? S c0285d80 ? ? 0 ? ? 5 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
> [ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
> [ 2700.100000] watchdog/0 ? ?S c0285d80 ? ? 0 ? ? 6 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c008b418>] (watchdog+0xc0/0x110)
> [ 2700.100000] [<c008b358>] (watchdog+0x0/0x110) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] ?r6:00000000 r5:c7843efc r4:c785ffac
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843efc
> [ 2700.100000] khelper ? ? ? S c0285d80 ? ? 0 ? ? 7 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
> [ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f1c
> [ 2700.100000] sync_supers ? S c0285d80 ? ? 0 ? ? 8 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00cd114>] (bdi_sync_supers+0x38/0x50)
> [ 2700.100000] [<c00cd0dc>] (bdi_sync_supers+0x0/0x50) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] ?r5:c7843f2c r4:c7895fac
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f2c
> [ 2700.100000] bdi-default ? S c0285d80 ? ? 0 ? ? 9 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c02864b4>] (schedule_timeout+0x22c/0x27c)
> [ 2700.100000] [<c0286288>] (schedule_timeout+0x0/0x27c) from [<c00ce014>] (bdi_forker_thread+0x3a8/0x41c)
> [ 2700.100000] ?r8:c0363f80 r7:00000000 r6:00000000 r5:c03641e8 r4:00000000
> [ 2700.100000] [<c00cdc6c>] (bdi_forker_thread+0x0/0x41c) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843efc
> [ 2700.100000] kintegrityd ? S c0285d80 ? ? 0 ? ?10 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
> [ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843e9c
> [ 2700.100000] kblockd ? ? ? S c0285d80 ? ? 0 ? ?11 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
> [ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843ec4
> [ 2700.100000] rpciod ? ? ? ?S c0285d80 ? ? 0 ? ?12 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
> [ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843ebc
> [ 2700.100000] kworker/0:1 ? S c0285d80 ? ? 0 ? ?13 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
> [ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c785be94
> [ 2700.100000] khungtaskd ? ?S c0285d80 ? ? 0 ? ?14 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c02864b4>] (schedule_timeout+0x22c/0x27c)
> [ 2700.100000] [<c0286288>] (schedule_timeout+0x0/0x27c) from [<c0286584>] (schedule_timeout_interruptible+0x28/0x2c)
> [ 2700.100000] ?r8:00000078 r7:00007fe9 r6:000003e9 r5:c034eef0 r4:00000064
> [ 2700.100000] [<c028655c>] (schedule_timeout_interruptible+0x0/0x2c) from [<c008ada8>] (watchdog+0x54/0x2e8)
> [ 2700.100000] [<c008ad54>] (watchdog+0x0/0x2e8) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f2c
> [ 2700.100000] kswapd0 ? ? ? S c0285d80 ? ? 0 ? ?15 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00c5ea4>] (kswapd+0x210/0x74c)
> [ 2700.100000] [<c00c5c94>] (kswapd+0x0/0x74c) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f1c
> [ 2700.100000] fsnotify_mark S c0285d80 ? ? 0 ? ?16 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c011f884>] (fsnotify_mark_destroy+0x11c/0x144)
> [ 2700.100000] [<c011f768>] (fsnotify_mark_destroy+0x0/0x144) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843f34
> [ 2700.100000] aio ? ? ? ? ? S c0285d80 ? ? 0 ? ?17 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
> [ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
> [ 2700.100000] nfsiod ? ? ? ?S c0285d80 ? ? 0 ? ?18 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
> [ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843edc
> [ 2700.100000] crypto ? ? ? ?S c0285d80 ? ? 0 ? ?19 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c00657d4>] (rescuer_thread+0x1b8/0x1c4)
> [ 2700.100000] [<c006561c>] (rescuer_thread+0x0/0x1c4) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c7843ee4
> [ 2700.100000] kworker/u:1 ? S c0285d80 ? ? 0 ? ?24 ? ? ?2 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c006480c>] (worker_thread+0x41c/0x444)
> [ 2700.100000] [<c00643f0>] (worker_thread+0x0/0x444) from [<c006a294>] (kthread+0x8c/0x94)
> [ 2700.100000] [<c006a208>] (kthread+0x0/0x94) from [<c004f4d8>] (do_exit+0x0/0x658)
> [ 2700.100000] ?r7:00000013 r6:c004f4d8 r5:c006a208 r4:c785de94
> [ 2700.100000] rcS ? ? ? ? ? S c0285d80 ? ? 0 ? ?27 ? ? ?1 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c004f268>] (do_wait+0x1a4/0x20c)
> [ 2700.100000] [<c004f0c4>] (do_wait+0x0/0x20c) from [<c004f378>] (sys_wait4+0xa8/0xc0)
> [ 2700.100000] [<c004f2d0>] (sys_wait4+0x0/0xc0) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
> [ 2700.100000] ?r8:c0034088 r7:00000072 r6:ffffffff r5:bee7880c r4:00000000
> [ 2700.100000] run-parts ? ? S c0285d80 ? ? 0 ? ?35 ? ? 27 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c02858c8>] (schedule+0x0/0x534) from [<c004f268>] (do_wait+0x1a4/0x20c)
> [ 2700.100000] [<c004f0c4>] (do_wait+0x0/0x20c) from [<c004f378>] (sys_wait4+0xa8/0xc0)
> [ 2700.100000] [<c004f2d0>] (sys_wait4+0x0/0xc0) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
> [ 2700.100000] ?r8:c0034088 r7:00000072 r6:00000024 r5:bef7dcc4 r4:00000000
> [ 2700.100000] S00splashutil R running ? ? ?0 ? ?36 ? ? 35 0x00000000
> [ 2700.100000] Backtrace:
> [ 2700.100000] [<c0037b54>] (dump_backtrace+0x0/0x110) from [<c0037c80>] (show_stack+0x1c/0x20)
> [ 2700.100000] ?r7:c79cfd64 r6:00000000 r5:c7954600 r4:00000000
> [ 2700.100000] [<c0037c64>] (show_stack+0x0/0x20) from [<c0046b78>] (sched_show_task+0xb0/0xcc)
> [ 2700.100000] [<c0046ac8>] (sched_show_task+0x0/0xcc) from [<c0046bf0>] (show_state_filter+0x5c/0xc8)
> [ 2700.100000] ?r5:c7954600 r4:c7954600
> [ 2700.100000] [<c0046b94>] (show_state_filter+0x0/0xc8) from [<c01c5c40>] (sysrq_handle_showstate+0x18/0x1c)
> [ 2700.100000] ?r8:20000093 r7:00000007 r6:00000001 r5:00000074 r4:c036ec5c
> [ 2700.100000] [<c01c5c28>] (sysrq_handle_showstate+0x0/0x1c) from [<c01c6040>] (__handle_sysrq+0xe0/0x190)
> [ 2700.100000] [<c01c5f60>] (__handle_sysrq+0x0/0x190) from [<c01c62d8>] (handle_sysrq+0x38/0x44)
> [ 2700.100000] ?r8:c7999000 r7:00000100 r6:c7973640 r5:00010074 r4:c7864300
> [ 2700.100000] [<c01c62a0>] (handle_sysrq+0x0/0x44) from [<c01da100>] (pl011_int+0x18c/0x5a4)
> [ 2700.100000] [<c01d9f74>] (pl011_int+0x0/0x5a4) from [<c008b8b0>] (handle_IRQ_event+0x7c/0x1a8)
> [ 2700.100000] [<c008b834>] (handle_IRQ_event+0x0/0x1a8) from [<c008de5c>] (handle_level_irq+0xc8/0x148)
> [ 2700.100000] [<c008dd94>] (handle_level_irq+0x0/0x148) from [<c002d080>] (asm_do_IRQ+0x80/0xa4)
> [ 2700.100000] ?r7:c74a05a4 r6:c74a0508 r5:00000000 r4:0000002f
> [ 2700.100000] [<c002d000>] (asm_do_IRQ+0x0/0xa4) from [<c0033ab8>] (__irq_svc+0x38/0x80)
> [ 2700.100000] Exception stack(0xc79cfe88 to 0xc79cfed0)
> [ 2700.100000] fe80: ? ? ? ? ? ? ? ? ? c74a0508 00000000 c0145d24 c7487e60 00000000 c79cfee8
> [ 2700.100000] fea0: c74a0508 c74a05a4 c7487e60 c79cfee8 c74a0508 c79cff4c c79ce000 c79cfed0
> [ 2700.100000] fec0: c016ff10 c014601c 60000013 ffffffff
> [ 2700.100000] ?r5:f5000000 r4:ffffffff
> [ 2700.100000] [<c0145f0c>] (nfs_readdir+0x0/0x458) from [<c00fa298>] (vfs_readdir+0x7c/0xb0)
> [ 2700.100000] [<c00fa21c>] (vfs_readdir+0x0/0xb0) from [<c00fa3fc>] (sys_getdents+0x70/0xb8)
> [ 2700.100000] [<c00fa38c>] (sys_getdents+0x0/0xb8) from [<c0033e80>] (ret_fast_syscall+0x0/0x38)
> [ 2700.100000] ?r7:0000008d r6:00000000 r5:402ed00c r4:402ed020
> [ 2700.100000] Sched Debug Version: v0.09, 2.6.37-rc8-00065-g1cd48e3-dirty #35
> [ 2700.100000] now at 2701202.749966 msecs
> [ 2700.100000] ? .jiffies ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? : 240010
> [ 2700.100000] ? .sysctl_sched_latency ? ? ? ? ? ? ? ? ? ?: 6.000000
> [ 2700.100000] ? .sysctl_sched_min_granularity ? ? ? ? ? ?: 0.750000
> [ 2700.100000] ? .sysctl_sched_wakeup_granularity ? ? ? ? : 1.000000
> [ 2700.100000] ? .sysctl_sched_child_runs_first ? ? ? ? ? : 0
> [ 2700.100000] ? .sysctl_sched_features ? ? ? ? ? ? ? ? ? : 31855
> [ 2700.100000] ? .sysctl_sched_tunable_scaling ? ? ? ? ? ?: 1 (logaritmic)
> [ 2700.100000]
> [ 2700.100000] cpu#0
> [ 2700.100000] ? .nr_running ? ? ? ? ? ? ? ? ? ?: 1
> [ 2700.100000] ? .load ? ? ? ? ? ? ? ? ? ? ? ? ?: 1024
> [ 2700.100000] ? .nr_switches ? ? ? ? ? ? ? ? ? : 11875
> [ 2700.100000] ? .nr_load_updates ? ? ? ? ? ? ? : 269696
> [ 2700.100000] ? .nr_uninterruptible ? ? ? ? ? ?: 0
> [ 2700.100000] ? .next_balance ? ? ? ? ? ? ? ? ?: 0.000000
> [ 2700.100000] ? .curr->pid ? ? ? ? ? ? ? ? ? ? : 36
> [ 2700.100000] ? .clock ? ? ? ? ? ? ? ? ? ? ? ? : 2700100.000000
> [ 2700.100000] ? .cpu_load[0] ? ? ? ? ? ? ? ? ? : 1024
> [ 2700.100000] ? .cpu_load[1] ? ? ? ? ? ? ? ? ? : 1024
> [ 2700.100000] ? .cpu_load[2] ? ? ? ? ? ? ? ? ? : 1024
> [ 2700.100000] ? .cpu_load[3] ? ? ? ? ? ? ? ? ? : 1024
> [ 2700.100000] ? .cpu_load[4] ? ? ? ? ? ? ? ? ? : 1024
> [ 2700.100000]
> [ 2700.100000] cfs_rq[0]:
> [ 2700.100000] ? .exec_clock ? ? ? ? ? ? ? ? ? ?: 0.000000
> [ 2700.100000] ? .MIN_vruntime ? ? ? ? ? ? ? ? ?: 0.000001
> [ 2700.100000] ? .min_vruntime ? ? ? ? ? ? ? ? ?: 2695651.938408
> [ 2700.100000] ? .max_vruntime ? ? ? ? ? ? ? ? ?: 0.000001
> [ 2700.100000] ? .spread ? ? ? ? ? ? ? ? ? ? ? ?: 0.000000
> [ 2700.100000] ? .spread0 ? ? ? ? ? ? ? ? ? ? ? : 0.000000
> [ 2700.100000] ? .nr_running ? ? ? ? ? ? ? ? ? ?: 1
> [ 2700.100000] ? .load ? ? ? ? ? ? ? ? ? ? ? ? ?: 1024
> [ 2700.100000] ? .nr_spread_over ? ? ? ? ? ? ? ?: 0
> [ 2700.100000]
> [ 2700.100000] rt_rq[0]:
> [ 2700.100000] ? .rt_nr_running ? ? ? ? ? ? ? ? : 0
> [ 2700.100000] ? .rt_throttled ? ? ? ? ? ? ? ? ?: 0
> [ 2700.100000] ? .rt_time ? ? ? ? ? ? ? ? ? ? ? : 0.000000
> [ 2700.100000] ? .rt_runtime ? ? ? ? ? ? ? ? ? ?: 950.000000
> [ 2700.100000]
> [ 2700.100000] runnable tasks:
> [ 2700.100000] ? ? ? ? ? ? task ? PID ? ? ? ? tree-key ?switches ?prio ? ? exec-runtime ? ? ? ? sum-exec ? ? ? ?sum-sleep
> [ 2700.100000] ----------------------------------------------------------------------------------------------------------
> [ 2700.100000] R S00splashutils ? ?36 ? 2695651.938408 ? ? ?5397 ? 120 ? ? ? ? ? ? ? 0 ? ? ? ? ? ? ? 0 ? ? ? ? ? ? ? 0.000000 ? ? ? ? ? ? ? 0.000000 ? ? ? ? ? ? ? 0.000000
> [ 2700.100000]
> [ 2700.100000]
> [ 2700.100000] Showing all locks held in the system:
> [ 2700.100000] 4 locks held by S00splashutils/36:
> [ 2700.100000] ?#0: ?(&sb->s_type->i_mutex_key#8){+.+.+.}, at: [<c00fa268>] vfs_readdir+0x4c/0xb0
> [ 2700.100000] ?#1: ?(&port_lock_key){-.-...}, at: [<c01d9f94>] pl011_int+0x20/0x5a4
> [ 2700.100000] ?#2: ?(sysrq_key_table_lock){-.....}, at: [<c01c5f84>] __handle_sysrq+0x24/0x190
> [ 2700.100000] ?#3: ?(tasklist_lock){.?.+..}, at: [<c007c404>] debug_show_all_locks+0x40/0x1a4
> [ 2700.100000]
> [ 2700.100000] =============================================
> [ 2700.100000]
>
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Uwe Kleine-K?nig ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
On Thu, 2010-12-30 at 18:14 +0100, Uwe Kleine-König wrote:
> Hello,
>
> I wonder if the nfs-stuff is considered to be solved, because I still
> see strange things.
>
> During boot my machine sometimes (approx one out of two times) hangs with
> the output pasted below on Sysctl-l. The irq
>
> I'm not 100% sure it's related, but at least it seems to hang in
> nfs_readdir. (When the serial irq happend that triggered the sysrq the
> program counter was at 0xc014601c, which is fs/nfs/dir.c:647 for me.)
>
> This is on 2.6.37-rc8 plus some patches for machine support on an ARM
> machine.
Ccing [email protected]
What filesystem are you exporting on the server? What is the NFS
version? Is this nfsroot, autofs or an ordinary nfs mount?
In short, how can we reproduce this?
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Thu, 2010-12-30 at 09:57 -0800, Linus Torvalds wrote:
> Please cc the poor hapless NFS people too, who probably otherwise
> wouldn't see it. And Arnd just in case it might be locking-related.
>
> Trond, any ideas? The sysrq thing does imply that it's stuck in some
> busy-loop in fs/nfs/dir.c, and line 647 is get_cache_page(), which in
> turn implies that the endless loop is either the loop in
> readdir_search_pagecache() _or_ in a caller. In particular, the
> EBADCOOKIE case in the caller (nfs_readdir) looks suspicious. What
> protects us from endless streams of EBADCOOKIE and a successful
> uncached_readdir?
There is nothing we can do to protect ourselves against an infinite loop
if the server (or underlying filesystem) is breaking the rules w.r.t.
cookie generation. It should be possible to recover from all other
situations.
IOW: if the server generates non-unique cookies, then we're screwed.
Fixing that particular problem is impossible since it is basically a
variant of the halting problem.
That was why I asked which filesystem is being exported in my previous
reply.
The point of 'uncached_readdir' is to resolve a cookie that was
previously valid, but has since been invalidated; usually that is due to
the file having been unlinked. If it succeeds, it should result in a new
set of valid entries being posted to the 'filldir' callback, and a new
cookie being set in the filp->private (i.e. we should have made
progress). If it fails, we exit, as you can see.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Wed, 29 Dec 2010 11:40:04 -0800, Linus Torvalds <[email protected]> wrote:
> On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap <[email protected]> wrote:
> >
> > The only significant difference that I can see in the kernel message log
> > is this:
>
> Hmm. I suspect that difference should have gone away with commit
> 92971021c6328 (Revert "drm: Don't try and disable an encoder that was
> never enabled"), but clearly that didn't fix your blank screen.
>
> Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
> ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
> you? It does for some people..
>
> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> we please just disable spread-spectrum entirely? Or perhaps only if we
> notice that it was enabled already? Or something?
It appeared to be the easiest fix for the machines I had to hand and was
confirmed by several people with identical machines. However, it
definitely caused a regression for working panels and therefore it will
be reverted.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Dec 30, 2010 at 10:24 AM, Trond Myklebust
<[email protected]> wrote:
>
> There is nothing we can do to protect ourselves against an infinite loop
> if the server (or underlying filesystem) is breaking the rules w.r.t.
> cookie generation. It should be possible to recover from all other
> situations.
Umm. Sure there is. Just make sure that you return the uncached entry
to user space, rather than loop forever.
Looping forever in kernel space is a bad idea. How about just changing
the "continue" into a "break" for the "uncached readdir returned
success".
No halting problems, no excuses. There is absolutely _no_ excuse for
an endless loop in kernel mode. Certainly not "the other end is
incompetent".
EVERYBODY is incompetent sometimes. That just means that you must
never trust the other end too much. You can't say "we require the
server to be sane in order not to lock up".
Linus
Hi Trond,
On Thu, Dec 30, 2010 at 12:59:52PM -0500, Trond Myklebust wrote:
> On Thu, 2010-12-30 at 18:14 +0100, Uwe Kleine-K?nig wrote:
> > I wonder if the nfs-stuff is considered to be solved, because I still
> > see strange things.
> >
> > During boot my machine sometimes (approx one out of two times) hangs with
> > the output pasted below on Sysctl-l. The irq
> >
> > I'm not 100% sure it's related, but at least it seems to hang in
> > nfs_readdir. (When the serial irq happend that triggered the sysrq the
> > program counter was at 0xc014601c, which is fs/nfs/dir.c:647 for me.)
> >
> > This is on 2.6.37-rc8 plus some patches for machine support on an ARM
> > machine.
>
> Ccing [email protected]
Yeah, good idea. I had that ~2min after sending my report during
dinner, sorry :-\
> What filesystem are you exporting on the server? What is the NFS
> version? Is this nfsroot, autofs or an ordinary nfs mount?
This is an nfsroot of /home/ukl/nfsroot/tx28 which is a symlink to a
directory on a different partition. I don't know the filesystem of my
homedir as it resides on a server I have no access to, but I asked the
admin, so I can follow up with this info later (I'd suspect ext3, too).
The real root directory is on ext3 (rw,noatime).
The serving nfs-server is Debian's nfs-kernel-server 1:1.2.2-1.
nfs-related kernel parameters are
ip=dhcp root=/dev/nfs nfsroot=192.168.23.2:/home/ukl/nfsroot/tx28,v3,tcp
I hope this answers your questions. If not, please ask.
I tried without the symlink and saw some different errors, e.g.
starting splashutils daemon.../etc/rc.d/S00splashutils: line 50: //sbin/fbsplashd.static: Unknown error 521
(this is the init script that hung before) and
[ 6.160000] NFS: server 192.168.23.2 error: fileid changed
[ 6.160000] fsid 0:c: expected fileid 0x33590a4, got 0x4d11bedc
but no hang as before. So maybe it's related to the symlink? I don't
know if testing that further would help or just waste of my time, so
please let me know if I can help you and how.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Thu, 2010-12-30 at 10:50 -0800, Linus Torvalds wrote:
> On Thu, Dec 30, 2010 at 10:24 AM, Trond Myklebust
> <[email protected]> wrote:
> >
> > There is nothing we can do to protect ourselves against an infinite loop
> > if the server (or underlying filesystem) is breaking the rules w.r.t.
> > cookie generation. It should be possible to recover from all other
> > situations.
>
> Umm. Sure there is. Just make sure that you return the uncached entry
> to user space, rather than loop forever.
>
> Looping forever in kernel space is a bad idea. How about just changing
> the "continue" into a "break" for the "uncached readdir returned
> success".
uncached_readdir is not really a problem. The real problem is
filesystems that generate "infinite directories" by producing looping
combinations of cookies.
IOW: I've seen servers that generate cookies in a sequence of a form
vaguely resembling
1 2 3 4 5 6 7 8 9 10 11 12 3...
(with possibly a thousand or so entries between the first and second
copy of '3')
The kernel won't loop forever with something like that (because
eventually filldir() will declare it is out of buffer space), but
userland has a halting problem: it needs to detect that every
sys_getdents() call it is making is generating another copy of the
sequence associated with '4 5 6 7 8 9 10 11 12 3'...
> No halting problems, no excuses. There is absolutely _no_ excuse for
> an endless loop in kernel mode. Certainly not "the other end is
> incompetent".
We should never get an endless loop in _kernel mode_ with the current
scheme, and I can't see that anyone has demonstrated that yet.
> EVERYBODY is incompetent sometimes. That just means that you must
> never trust the other end too much. You can't say "we require the
> server to be sane in order not to lock up".
Unfortunately we must. Call it an NFS protocol failure, but it really
boils down to the fact that POSIX readdir() generates a data stream with
no well-defined concept of an offset. As a result, each and every
filesystem has their own interesting ways of generating cookies to
represent that 'offset'.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Thu, Dec 30, 2010 at 11:25 AM, Trond Myklebust
<[email protected]> wrote:
>
> uncached_readdir is not really a problem. The real problem is
> filesystems that generate "infinite directories" by producing looping
> combinations of cookies.
But if we don't have any lseek's, the readdir cache should trivially
take care of this by just incrementing the page_index, and we should
return to user space the (eventually ending) sequence, even if there
are duplicate numbers.
(Also, I suspect that "page_index" should not be a page index, but a
position, and then you the "search_for_pos()" should use that instead
of the file_pos/current_index thing, but that's a detail that would
show up only when you have duplicate cookies within one page worth of
directory caches)
And if the server really sends us an infinite stream of entries, then
that's fine - at least we give to user space the infinite entries that
were given to us, instead of _generating_ an infinite stream from what
was a finite - but broken - stream).
So it seems wrong that the directory caching code resets page_index to
the start when it then does an uncached readdir. That seems wrong.
I'm sure there's some reason for it, but wouldn't it be nice if the
rule for page_index was that it starts off at zero, and only gets
reset by lseek?
> IOW: I've seen servers that generate cookies in a sequence of a form
> vaguely resembling
>
> 1 2 3 4 5 6 7 8 9 10 11 12 3...
>
> (with possibly a thousand or so entries between the first and second
> copy of '3')
Ok, so that' obviously broken, but it's then _doubly_ broken to turn
that long broken sequence into an _endless_ broken sequence.
And I agree that when user space sees such an endless broken sequence,
it's a real stopping problem for user space. But in the absense of
lseek, it should _never_ be a problem for the kernel itself, afaik.
The kernel should happily return just the broken sequence. No?
So then perhaps the solution is to just remove the resetting of
page_index in the uncached_readdir() function? Make sure that the
page_index is monotonically increasing for any readdir(), and you
protect against turning a bad sequence into an endless sequence.
Of course, lseek() will have to reset page_index to zero, and if
somebody does an lseek() on the directory, then the duplicate '3"
entry in the cookie sequence will inevitably be ambiguous, but that
really is unavoidable. And rare. People who use lseek() on directories
are odd and we know they'll break on other filesystems too under
certain circumstances.
Linus
> Uncached_readdir is not really a problem. The real problem is
> filesystems that generate "infinite directories" by producing looping
> combinations of cookies.
>
> IOW: I've seen servers that generate cookies in a sequence of a form
> vaguely resembling
>
> 1 2 3 4 5 6 7 8 9 10 11 12 3...
>
> (with possibly a thousand or so entries between the first and second
> copy of '3')
>
> The kernel won't loop forever with something like that (because
> eventually filldir() will declare it is out of buffer space), but
> userland has a halting problem: it needs to detect that every
> sys_getdents() call it is making is generating another copy of the
> sequence associated with '4 5 6 7 8 9 10 11 12 3'...
Huh? This is not only an easy problem, it's a well-known problem.
http://en.wikipedia.org/wiki/Cycle_detection
Here's Brent's algorithm:
n = 0;
saved_cookie = <invalid>
For each cookie {
if (n && cookie == saved_cookie)
die("Loop detected!");
if (++n is a power of 2)
saved_cookie = cookie;
}
You can tweak the performance with other exponentially-growing
functions, saving k > 1 old cookies for comparison, etc., but the
above will work very well.
On Thu, 2010-12-30 at 22:17 -0500, George Spelvin wrote:
> > Uncached_readdir is not really a problem. The real problem is
> > filesystems that generate "infinite directories" by producing looping
> > combinations of cookies.
> >
> > IOW: I've seen servers that generate cookies in a sequence of a form
> > vaguely resembling
> >
> > 1 2 3 4 5 6 7 8 9 10 11 12 3...
> >
> > (with possibly a thousand or so entries between the first and second
> > copy of '3')
> >
> > The kernel won't loop forever with something like that (because
> > eventually filldir() will declare it is out of buffer space), but
> > userland has a halting problem: it needs to detect that every
> > sys_getdents() call it is making is generating another copy of the
> > sequence associated with '4 5 6 7 8 9 10 11 12 3'...
>
> Huh? This is not only an easy problem, it's a well-known problem.
> http://en.wikipedia.org/wiki/Cycle_detection
>
> Here's Brent's algorithm:
>
> n = 0;
> saved_cookie = <invalid>
> For each cookie {
> if (n && cookie == saved_cookie)
> die("Loop detected!");
> if (++n is a power of 2)
> saved_cookie = cookie;
> }
>
> You can tweak the performance with other exponentially-growing
> functions, saving k > 1 old cookies for comparison, etc., but the
> above will work very well.
...and your point would be that an exponentially increasing addition to
the existing number of tests is an acceptable tradeoff in a situation
where the >99.999999999999999% case is that of sane servers with no
looping? I don't think so...
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
> ...and your point would be that an exponentially increasing addition to
> the existing number of tests is an acceptable tradeoff in a situation
> where the >99.999999999999999% case is that of sane servers with no
> looping? I don't think so...
1) Look again; it's O(1) work per entry, or O(n) work for an n-entry
directory. And O(1) space. With very small constant factors, and
very little code. The only thing exponentially increasing is the
interval at which you save the current cookie for future comparison.
2) You said it *was* a problem, so it seemed worth presenting a
practical solution. If you don't think it's worth it, I'm not
going to disagree. But it's not impossible, or even difficult.
On Fri, 2010-12-31 at 20:03 -0500, George Spelvin wrote:
> > ...and your point would be that an exponentially increasing addition to
> > the existing number of tests is an acceptable tradeoff in a situation
> > where the >99.999999999999999% case is that of sane servers with no
> > looping? I don't think so...
>
> 1) Look again; it's O(1) work per entry, or O(n) work for an n-entry
> directory. And O(1) space. With very small constant factors, and
> very little code. The only thing exponentially increasing is the
> interval at which you save the current cookie for future comparison.
> 2) You said it *was* a problem, so it seemed worth presenting a
> practical solution. If you don't think it's worth it, I'm not
> going to disagree. But it's not impossible, or even difficult.
Yes. I was thinking about it this morning (after coffee).
One variant on those algorithms that might make sense here is to save
the current cookie each time we see that the result of a cookie search
is a filp->f_pos offset < the current filp->f_pos offset. That means we
will in general only detect the loop after going through an entire
cycle, but that should be sufficient...
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com