So things have been pretty quiet, and unless something major comes up
I believe that this will be the last -rc.
There's only about a hundred commits here, and the bulk of the diffs
are to fs/hpfs which has been marked as BROKEN since early in the
merge window because of the final BKL removal. So it is a regression
fix. That said, I admittedly considered just leaving hpfs broken for
the 39 release and doing this fix series in the next merge window.
Whatever. Might as well take it now, since it has no impact outside of
hpfs, and certainly thus couldn't make things -worse-.
Outside of the hpfs patches, there really isn't all that much
interesting going on. Some hw breakpoint ptrace races, some cifs
updates, and then just random small fixes, mostly to drivers. Nothing
noticeable really stands out, it really has been pretty quiet.
But please do test, just to make sure that 39-final is good.
Linus
---
Alan Stern (1):
USB: fix regression in usbip by setting has_tt flag
Alex Deucher (2):
drm/radeon/kms: ATPX switcheroo fixes
drm/radeon/kms: add pci id to acer travelmate quirk for 5730
Alex Williamson (1):
drm/i915/lvds: Only act on lid notify when the device is on
Andiry Xu (1):
xHCI: Clear PLC in xhci_bus_resume()
Arjan van de Ven (1):
Regression: partial revert "tracing: Remove lock_depth from event entry"
Arvid Brodin (1):
usb/isp1760: Report correct urb status after unlink
Axel Lin (1):
mfd: Fix usbhs_enable error handling
B.J. Buchalter (1):
firewire: Fix for broken configrom updates in quick succession
Ben Gardiner (4):
ASoC: davinci-mcasp: correct tdm_slots limit
davinci-mcasp: use bitfield definitions for PDIR
davinci-mcasp: fix _CBM_CFS hw_params
davinci-mcasp: fix _CBM_CFS pin directions
Chris Wilson (4):
drm/i915: Release object along create user fb error path
drm/i915/dp: Be paranoid in case we disable a DP before it is attached
drm/i915: Only enable the plane after setting the fb base (pre-ILK)
drm/i915: fix intel_crtc_clock_get pipe reads after "cleanup cleanup"
Daniel Vetter (1):
drm: mm: fix debug output
Eric Paris (3):
SELinux: pass last path component in may_create
flex_array: flex_array_prealloc takes a number of elements, not an end
flex_arrays: allow zero length flex arrays
Frederic Weisbecker (6):
ptrace: Prepare to fix racy accesses on task breakpoints
x86, hw_breakpoints: Fix racy access to ptrace breakpoints
powerpc, hw_breakpoints: Fix racy access to ptrace breakpoints
arm, hw_breakpoints: Fix racy access to ptrace breakpoints
sh, hw_breakpoints: Fix racy access to ptrace breakpoints
hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case
in ptrace_set_debugreg()
Greg Ungerer (2):
arm: at91: minimal defconfig for at91x40 SoC
arm: at91: fix compiler warning for eb01 board build
Harry Wei (1):
staging: Remove a warning for drivers/staging/wlan-ng/cfg80211.c
Henry C Chang (2):
libceph: fix ceph_msg_new error path
ceph: handle ceph_osdc_new_request failure in ceph_writepages_start
Herton Ronaldo Krzesinski (1):
[media] v4l: make sure drivers supply a zeroed struct v4l2_subdev
Hugh Dickins (1):
vm: fix vm_pgoff wrap in upward expansion
Hussam Al-Tayeb (1):
[media] rc_core: avoid kernel oops when rmmod saa7134
Ilija Hadzic (1):
drm/radeon: fix order of doing things in radeon_crtc_cursor_set
James Bottomley (1):
[SCSI] fix oops in scsi_run_queue()
Jarkko Nikula (2):
usb: musb: omap2430: Fix retention idle on musb peripheral only boards
usb: musb: gadget: Fix out-of-sync runtime pm calls
Jarod Wilson (4):
[media] mceusb: add Dell transceiver ID
[media] ite-cir: modular build on ppc requires delay.h include
[media] rc: show RC_TYPE_OTHER in sysfs
[media] imon: add conditional locking in change_protocol
Jean-Christophe PLAGNIOL-VILLARD (1):
at91: Add ARCH_ID and basic cpu macros definition for 5series
chips family.
Jeff Layton (5):
cifs: change bleft in decode_unicode_ssetup back to signed type
cifs: check for bytes_remaining going to zero in CIFS_SessSetup
cifs: sanitize length checking in coalesce_t2 (try #3)
cifs: refactor mid finding loop in cifs_demultiplex_thread
cifs: handle errors from coalesce_t2
Jeff Mahoney (5):
staging: olpc: Add <linux/delay.h>
staging: gma500: Depend on X86
staging: rts_pstor: Add <linux/vmalloc.h>
staging: rts_pstor: use #ifdef instead of #if
staging: ft1000: Remove unnecessary EXPORT_SYMBOLs
Jimmy Rentz (1):
drm/nouveau: Fix a crash at card takedown for NV40 and older cards
Keshava Munegowda (1):
omap:usb: add regulator support for EHCI
Lin Ming (1):
perf tools: Makefile: Use gcc to determine ARCH
Linus Torvalds (2):
VM: skip the stack guard page lookup in get_user_pages only for mlock
Linux 2.6.39-rc7
Malcolm Priestley (1):
[media] Missing frontend config for LME DM04/QQBOX
Manoj Iyer (1):
thinkpad-acpi: module autoloading for newer Lenovo ThinkPads.
Mark Brown (2):
ASoC: Fix CODEC name in Goni
ASoC: Fix CODEC DAI names for Goni
Matthew Garrett (1):
eeepc-laptop: Use ACPI handle to identify rfkill port
Mattia Dongili (2):
sony-laptop: report failures on setting LCD brightness
sony-laptop: limit brightness range to DSDT provided ones
Max Vozeler (1):
staging: usbip: vhci: fix oops on subsequent attach
Mikulas Patocka (15):
HPFS: Make HPFS compile on preempt and SMP
HPFS: Introduce a global mutex and lock it on every callback from VFS.
HPFS: Remove remaining locks
HPFS: Remove CR/LF conversion option
HPFS: Remove mark_inode_dirty
HPFS: Use types with defined width
HPFS: When marking or clearing the dirty bit, sync the filesystem
HPFS: Restrict uid and gid to 16-bit values
HPFS: Fix a bug that filesystem was not marked dirty when remounting it
HPFS: Implement fsync for hpfs
HPFS: Fix endianity. Make hpfs work on big-endian machines
HPFS: Fix some unaligned accesses
HPFS: Move declaration up, so that there are no out-of-scope pointers
HPFS: Remove unused variable
Don't lock guardpage if the stack is growing up
Oliver Endriss (1):
[media] ngene: Fix CI data transfer regression Fix CI data
transfer regression introduced by previous cleanup.
Peter Foley (1):
staging: solo6x10: add select SND_PCM to fix build error
Peter Zijlstra (1):
perf events, x86: Fix Intel Nehalem and Westmere last level
cache event definitions
Randy Dunlap (1):
staging: intel_sst: intelmid needs delay.h
Sage Weil (3):
ceph: use ihold() when i_lock is held
libceph: fix ceph_osdc_alloc_request error checks
ceph: do not call __mark_dirty_inode under i_lock
Thomas Gleixner (1):
slub: Fix the lockless code on 32-bit platforms with no 64-bit cmpxchg
Timo Warns (1):
Validate size of EFI GUID partition entries.
Uwe Kleine-K?nig (1):
ARM: at91: AT91CAP9 has a macb device
On Mon, May 09, 2011 at 07:49:48PM -0700, Linus Torvalds wrote:
> So things have been pretty quiet, and unless something major comes up
> I believe that this will be the last -rc.
Oh no! I was hoping for an extra week!
The patch that I asked to be pulled: (a38647837a411f7df79623128421eef2118b5884)
"xen/mmu: Add workaround "x86-64, mm: Put early page table high"
does not compleltly workaround the regression that the patch from Yinghai titled
'x86-64, mm: Put early page table high" introduced wherein Linux can't boot under Xen.
The failure still encountered: https://lkml.org/lkml/2011/5/5/180, the
previous git pull request with an outline of the problem https://lkml.org/lkml/2011/5/3/99
and huge amount of details in http://marc.info/?i=1302607192-21355-2-git-send-email-stefano.stabellini@eu.citrix.com
I was hoping that the rc6 could stretch out so that by the time hpa came back from
his travels he would have had a chance to look at: https://lkml.org/lkml/2011/5/5/226
(or git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/bug-fixes-for-rc6)
which has a more precise patch and fixes the regression.
Linus, what is the right way to go about this?
On Mon, May 09, 2011 at 11:53:56PM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, May 09, 2011 at 07:49:48PM -0700, Linus Torvalds wrote:
> > So things have been pretty quiet, and unless something major comes up
> > I believe that this will be the last -rc.
>
> Oh no! I was hoping for an extra week!
>
> The patch that I asked to be pulled: (a38647837a411f7df79623128421eef2118b5884)
> "xen/mmu: Add workaround "x86-64, mm: Put early page table high"
>
> does not compleltly workaround the regression that the patch from Yinghai titled
> 'x86-64, mm: Put early page table high" introduced wherein Linux can't boot under Xen.
>
> The failure still encountered: https://lkml.org/lkml/2011/5/5/180, the
> previous git pull request with an outline of the problem https://lkml.org/lkml/2011/5/3/99
> and huge amount of details in http://marc.info/?i=1302607192-21355-2-git-send-email-stefano.stabellini@eu.citrix.com
>
> I was hoping that the rc6 could stretch out so that by the time hpa came back from
> his travels he would have had a chance to look at: https://lkml.org/lkml/2011/5/5/226
I had a chance to briefly talk on IRC with hpa and he mentioned I should
send a note to Ingo about this since hpa won't be able to do anything until Friday.
Ingo,
Not sure how familiar you are with this issue, but let me briefly explain it.
Yinghai provided a patch, which calls memblock_find_in_range(), then calls
kernel_physical_mapping_init, which populates the pagetable between pgt_buf_start
and pgt_buf_top and once it is done, calls memblock_x86_reserve_range with pgt_buf_start
and pgt_buf_end (wherein pgt_buf_end <= pgt_buf_top). The memory between pgt_buf_end
and pgt_buf_top can be re-used later on and it is by other subsystems - NUMA for
example uses it.
Under Xen, the pagetables end up being marked RO, so what ends up happening is that
some pages from pgt_buf_end through pgt_buf_top end up RO and the system crashes during
bootup as NUMA subsystem tries to write to that area. The fix is to essentially mark the
area from pgt_buf_end through pgt_buf_top to RW.
Stefano posted a patch, which was Acked by Yinghai, but not so by hpa. The concerns
were that the patch inserts a hook just for this single case and there should be a better
way of doing this - where we either don't need a hook or provide an semantic explanation
of the pagetable building and build the patch from there.
Sadly there was/is not enough time in the 2.6.39 train to actually do it properly.
So I provided another patch (which Linus merged) which crudely tries to mark the area from
pgt_buf_end through pgt_buf_top to RW and all is done within the Xen MMU code. Sadly it
does not work on all machines.
Without a resolution to this, the Linux x86_64 kernel cannot boot under Xen. There are two
options left right now:
a). Revert 4b239f458c229de044d6905c2b0f9fe16ed9e01e (x86-64, mm: Put early page table high)
b). or revert the workaround that Linus merged and pick the one that Stefano came up with.
The patches are available in
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/bug-fixes-for-rc6
They touch the generic x86 MMU code.
On 05/10/2011 04:36 PM, Konrad Rzeszutek Wilk wrote:
>>
>> I was hoping that the rc6 could stretch out so that by the time hpa came back from
>> his travels he would have had a chance to look at: https://lkml.org/lkml/2011/5/5/226
>
> I had a chance to briefly talk on IRC with hpa and he mentioned I should
> send a note to Ingo about this since hpa won't be able to do anything until Friday.
>
> Ingo,
> Not sure how familiar you are with this issue, but let me briefly explain it.
> Yinghai provided a patch, which calls memblock_find_in_range(), then calls
> kernel_physical_mapping_init, which populates the pagetable between pgt_buf_start
> and pgt_buf_top and once it is done, calls memblock_x86_reserve_range with pgt_buf_start
> and pgt_buf_end (wherein pgt_buf_end<= pgt_buf_top). The memory between pgt_buf_end
> and pgt_buf_top can be re-used later on and it is by other subsystems - NUMA for
> example uses it.
>
> Under Xen, the pagetables end up being marked RO, so what ends up happening is that
> some pages from pgt_buf_end through pgt_buf_top end up RO and the system crashes during
> bootup as NUMA subsystem tries to write to that area. The fix is to essentially mark the
> area from pgt_buf_end through pgt_buf_top to RW.
>
> Stefano posted a patch, which was Acked by Yinghai, but not so by hpa. The concerns
> were that the patch inserts a hook just for this single case and there should be a better
> way of doing this - where we either don't need a hook or provide an semantic explanation
> of the pagetable building and build the patch from there.
>
> Sadly there was/is not enough time in the 2.6.39 train to actually do it properly.
> So I provided another patch (which Linus merged) which crudely tries to mark the area from
> pgt_buf_end through pgt_buf_top to RW and all is done within the Xen MMU code. Sadly it
> does not work on all machines.
>
> Without a resolution to this, the Linux x86_64 kernel cannot boot under Xen. There are two
> options left right now:
> a). Revert 4b239f458c229de044d6905c2b0f9fe16ed9e01e (x86-64, mm: Put early page table high)
> b). or revert the workaround that Linus merged and pick the one that Stefano came up with.
> The patches are available in
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/bug-fixes-for-rc6
>
> They touch the generic x86 MMU code.
>
At this point this does indeed seem to be the only reasonable solution.
I'm not happy about either the fix nor the fact that Xen is so fragile
yet wants to piggy back on generic x86 code, but for .39 there really
isn't much opportunity to fix it any other way. Konrad has promised me
to personally drive the work to get a better fix in.
Unfortunately as mentioned I am travelling at the moment and have
limited ability to fix this; if I get a chance I'll look at it and pull
it into tip, but under the circumstances I can't promise anything.
-hpa
* Linus Torvalds -- Tuesday 10 May 2011:
> But please do test, just to make sure that 39-final is good.
> Chris Wilson (4):
> drm/i915: Only enable the plane after setting the fb base (pre-ILK)
This patch introduces a bug on my infamous "Acer Travelmate
5735Z-452G32Mnss": when KMS takes over, the frame buffer contents
get completely garbled up on screen, with colored stripes and
unreadable text (photo on request). Only when X11 is started, the
screen gets restored again. Closing and re-opening the lid partly
cures the mess, too: it makes the font readable, though horizontally
stretched.
Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
bug.
m.
drm.debug=0x02
[ 2.604831] [drm] Initialized drm 1.1.0 20060810
[ 2.648409] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 2.648415] i915 0000:00:02.0: setting latency timer to 64
[ 2.708949] [drm:intel_opregion_setup], graphic opregion physical addr: 0x7ba8c018
[ 2.708987] [drm:intel_opregion_setup], Public ACPI methods supported
[ 2.708989] [drm:intel_opregion_setup], SWSCI supported
[ 2.708991] [drm:intel_opregion_setup], ASLE supported
[ 2.709047] i915 0000:00:02.0: irq 44 for MSI/MSI-X
[ 2.709053] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 2.709054] [drm] Driver supports precise vblank timestamp query.
[ 2.735626] [drm:init_status_page], render ring hws offset: 0x00000000
[ 2.735747] [drm:init_status_page], bsd ring hws offset: 0x00021000
[ 2.735852] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT CANTIGA d
[ 2.779279] [drm:intel_panel_get_backlight], get backlight PWM = 0
[ 2.779287] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 2.779616] [drm:intel_panel_set_backlight], set backlight PWM = 0
[ 2.779619] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 2.779626] [drm:intel_opregion_asle_intr], non asle set request??
[ 3.022059] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A
[ 3.022065] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A
[ 3.074270] checking generic (80000000 3ff0000) vs hw (80000000 10000000)
[ 3.074274] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[ 3.074293] Console: switching to colour dummy device 80x25
[ 3.074806] fbcon: inteldrmfb (fb0) is primary device
[ 3.109085] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 3.109087] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[ 3.109090] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 3.109098] [drm:intel_opregion_asle_intr], non asle set request??
[ 3.109111] Console: switching to colour frame buffer device 170x48
[ 3.111779] fb0: inteldrmfb frame buffer device
[ 3.111780] drm: registered panic notifier
[ 3.158015] scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS
[ 3.413081] acpi device:07: registered as cooling_device2
[ 3.413431] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input6
[ 3.413532] ACPI: Video Device [OVGA] (multi-head: yes rom: no post: no)
[ 3.413982] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 4.059019] sd 4:0:0:0: [sdb] 15720448 512-byte logical blocks: (8.04 GB/7.49 GiB)
[ 4.059746] sd 4:0:0:0: [sdb] Write Protect is off
[ 4.059750] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
[ 4.059752] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 4.061879] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 4.066269] sdb: sdb1
[ 4.067995] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 4.068056] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[ 5.016884] md: linear personality registered for level -1
[ 94.800469] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 94.800473] [drm:intel_panel_set_backlight], set backlight PWM = 72250
[ 94.800477] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[ 94.800482] [drm:intel_opregion_asle_intr], non asle set request??
[ 94.800485] [drm:intel_opregion_asle_intr], non asle set request??
On Thu, 12 May 2011 18:49:08 +0200, Melchior FRANZ <[email protected]> wrote:
> * Linus Torvalds -- Tuesday 10 May 2011:
> > But please do test, just to make sure that 39-final is good.
>
> > Chris Wilson (4):
> > drm/i915: Only enable the plane after setting the fb base (pre-ILK)
>
> This patch introduces a bug on my infamous "Acer Travelmate
> 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents
> get completely garbled up on screen, with colored stripes and
> unreadable text (photo on request). Only when X11 is started, the
> screen gets restored again. Closing and re-opening the lid partly
> cures the mess, too: it makes the font readable, though horizontally
> stretched.
So we think that enabling the plane at this point is masking a bug in our
modeset, or that some side-effect of writing those registers or waiting
for that vblank has a vital latching or delay that we have not accounted
for.
Can you please grab intel_reg_dumper from
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools
and attach its output after passing nomodeset on your kernel boot
parameters (without starting X). That should capture the registers as they
were left by the BIOS. Alternatively, if you load i915.ko as a module, you
can run intel_reg_dumper before loading the module. Then can you attach
the output from intel_reg_dumper from the VT before starting X (whilst the
display is skewiff) and then after (when the display has recovered). That
may help, unless we are right in that it is in the timing of the register
writes.
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
* Chris Wilson -- Thursday 12 May 2011:
> So we think that enabling the plane at this point is masking a bug in our
> modeset, or that some side-effect of writing those registers or waiting
> for that vblank has a vital latching or delay that we have not accounted
> for.
Attached are the requested register dumps:
intel_reg_dump__nomodeset.gz
\___no kms -- no corruption
intel_reg_dump__bad.gz
\___with kms -- corrupted screen contents with staircase
shaped and horizontally stretched scan lines. Unreadable.
intel_reg_dump__lid.gz
\___after closing and reopening lid. The text is now readable,
but horizontally stretched. It looks like there's a dark
pixel between any pair of legitimate font pixels.
intel_reg_dump__x11.gz
\___after starting x11. Now both the x11 screen and virtual
terminals look right.
(BTW: there's also still the problem that the backlight remains off
until I press the "screen darker" key. Maybe this problem is related?
https://bugzilla.kernel.org/show_bug.cgi?id=31522).
m.
On Mon, May 09, 2011 at 07:49:48PM -0700, Linus Torvalds wrote:
> But please do test, just to make sure that 39-final is good.
I'm hitting a warn_on in the gendisk events code; happens after plugging
an ipod through usb. Adding Tejun.
[49045.176773] usb 1-3.1: new high speed USB device number 5 using ehci_hcd
[49045.287681] usb 1-3.1: New USB device found, idVendor=05ac, idProduct=1263
[49045.287697] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[49045.287707] usb 1-3.1: Product: iPod
[49045.287715] usb 1-3.1: Manufacturer: Apple Inc.
[49045.294369] scsi5 : usb-storage 1-3.1:1.0
[49046.300561] scsi 5:0:0:0: Direct-Access Apple iPod 1.62 PQ: 0 ANSI: 0
[49046.350703] sd 5:0:0:0: [sdc] 3944897 4096-byte logical blocks: (16.1 GB/15.0 GiB)
[49046.354059] sd 5:0:0:0: [sdc] Write Protect is off
[49046.354071] sd 5:0:0:0: [sdc] Mode Sense: 68 00 00 08
[49046.354078] sd 5:0:0:0: [sdc] Assuming drive cache: write through
[49046.357265] sd 5:0:0:0: [sdc] 3944897 4096-byte logical blocks: (16.1 GB/15.0 GiB)
[49046.358222] sd 5:0:0:0: [sdc] Assuming drive cache: write through
[49046.359584] sdc: sdc1
[49046.363303] sd 5:0:0:0: [sdc] 3944897 4096-byte logical blocks: (16.1 GB/15.0 GiB)
[49046.364265] sd 5:0:0:0: [sdc] Assuming drive cache: write through
[49046.364290] sd 5:0:0:0: [sdc] Attached SCSI removable disk
[49739.003924] ------------[ cut here ]------------
[49739.003946] WARNING: at block/genhd.c:1556 disk_clear_events+0xca/0x101()
[49739.003954] Hardware name: System Product Name
[49739.003961] Modules linked in: nls_iso8859_15 nls_cp437 usblp tun powernow_k8 mperf cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats freq_table binfmt_misc kvm_amd kvm fuse ipv6 vfat fat 8250_pnp 8250 edac_core serial_core ohci_hcd k10temp
[49739.004043] Pid: 11237, comm: hald-addon-stor Not tainted 2.6.39-rc7 #1
[49739.004050] Call Trace:
[49739.004067] [<ffffffff8144673e>] ? _raw_spin_unlock_irqrestore+0x38/0x69
[49739.004082] [<ffffffff810383ee>] warn_slowpath_common+0x85/0x9d
[49739.004094] [<ffffffff81038420>] warn_slowpath_null+0x1a/0x1c
[49739.004104] [<ffffffff81190b97>] disk_clear_events+0xca/0x101
[49739.004117] [<ffffffff811159b9>] check_disk_change+0x27/0x5f
[49739.004129] [<ffffffff813051e4>] sd_open+0x86/0x12d
[49739.004139] [<ffffffff81191eae>] ? disk_get_part+0x22/0x128
[49739.004150] [<ffffffff811168ce>] __blkdev_get+0xb0/0x34c
[49739.004161] [<ffffffff81116d62>] blkdev_get+0x1f8/0x32a
[49739.004172] [<ffffffff81030494>] ? sub_preempt_count+0xa3/0xb6
[49739.004182] [<ffffffff814467a4>] ? _raw_spin_unlock+0x35/0x52
[49739.004194] [<ffffffff81116f1d>] blkdev_open+0x89/0x8d
[49739.004205] [<ffffffff810e6dc9>] __dentry_open+0x250/0x37b
[49739.004216] [<ffffffff81116e94>] ? blkdev_get+0x32a/0x32a
[49739.004227] [<ffffffff810e6fbf>] nameidata_to_filp+0x60/0x67
[49739.004238] [<ffffffff810f4ff8>] do_last+0x5c4/0x6b8
[49739.004250] [<ffffffff810f6167>] path_openat+0xca/0x363
[49739.004261] [<ffffffff8105d941>] ? local_clock+0x2a/0x3b
[49739.004272] [<ffffffff81101357>] ? alloc_fd+0x1bc/0x1ce
[49739.004284] [<ffffffff810f64f9>] do_filp_open+0x3d/0x8c
[49739.004294] [<ffffffff814467a4>] ? _raw_spin_unlock+0x35/0x52
[49739.004305] [<ffffffff81101357>] ? alloc_fd+0x1bc/0x1ce
[49739.004316] [<ffffffff810e697d>] do_sys_open+0x110/0x1a9
[49739.004327] [<ffffffff810e6a49>] sys_open+0x20/0x22
[49739.004338] [<ffffffff814472eb>] system_call_fastpath+0x16/0x1b
[49739.004347] ---[ end trace 0e6e57542dc517bf ]---
--
Regards/Gruss,
Boris.
Hello,
On Sun, May 15, 2011 at 03:50:37PM +0200, Borislav Petkov wrote:
> On Mon, May 09, 2011 at 07:49:48PM -0700, Linus Torvalds wrote:
> > But please do test, just to make sure that 39-final is good.
>
> I'm hitting a warn_on in the gendisk events code; happens after plugging
> an ipod through usb. Adding Tejun.
>
> [49739.003946] WARNING: at block/genhd.c:1556 disk_clear_events+0xca/0x101()
Welcome to the party. :-)
The bug is being tracked in bug#34662.
https://bugzilla.kernel.org/show_bug.cgi?id=34662
I thought that I got it but apparently my fix didn't work. I'll get
back to it first thing tomorrow. Can you please cc yourself to the
bug?
Thank you.
--
tejun
* Melchior FRANZ -- Thursday 12 May 2011:
> > Chris Wilson (4):
> > drm/i915: Only enable the plane after setting the fb base (pre-ILK)
>
> This patch introduces a bug on my infamous "Acer Travelmate
> 5735Z-452G32Mnss": when KMS takes over, the frame buffer contents
> get completely garbled up on screen, with colored stripes and
> unreadable text (photo on request). Only when X11 is started, the
> screen gets restored again. Closing and re-opening the lid partly
> cures the mess, too: it makes the font readable, though horizontally
> stretched.
>
> Reverting 49183b2818de6899383bb82bc032f9344d6791ff fixes the
> bug.
This got fixed after my bug report, but now it's back with exactly
the same description. Bisection result to come ...
m.