Re: [BISECTED] Kernel 5.11.x breaks pulseaudio

[Heinz Diehl]

On 28.02.2021, Takashi Iwai wrote: 

> The fix I merged today can also work around your problem.
> Please give it a try.
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=5f5e6a3e8b1df52f79122e447855cffbf1710540

Applied on top of 5.11.2 - now pulseaudio works perfectly again, many
thanks!

Heinz

Re: [BISECTED] Kernel 5.11.x breaks pulseaudio

[Heinz Diehl]

On 25.02.2021, Takashi Iwai wrote: 

> Check which streams are running when you get the unexpected sample
> rate by inspecting /proc/asound/card*/pcm* entries.

I see, thanks for explaining! Pulseaudio no longer works properly for me, but
after configuring my audio player to use ALSA directly, all is fine so
far and all audio files are played with the correct sample rate and
without any resampling, just as they should.

Thanks, Heinz.

Re: [BISECTED] Kernel 5.11.x breaks pulseaudio

[Heinz Diehl]

On 25.02.2021, Takashi Iwai wrote:

> It's no regression but the right behavior.  This indicates that you're
> trying a stream in 44.1kHz in one side of the full duplex stream while
> 48kHz in another rate, and this cannot work properly with the implicit
> feedback devices.
[]

Well, I'm by no means an audio or recording professional, but if what you 
describe
is the correct behavior, it means that absolutely all audio files played on
my machine always will be resampled to 44.1kHz. Youtube from native 48kHz,
highres audio 24/96, virtually anything I play. Could that be correct? And
what can I do to be able to listen to highres audio again?

Thanks,
 Heinz

[BISECTED] Kernel 5.11.x breaks pulseaudio

[Heinz Diehl]

Hi,

from kernel 5.11 on, pulseaudio always resamples audio to the sample
rate specified by default-sample-rate, despite "avoid-resampling =
true". Audio that matches alternate-sample-rate is resampled in the same way.
This means that both "alternate-sample-rate" and
"avoid-resampling=true" are no longer working.

Steps to Reproduce:
1. Set "avoid-resampling = true" in daemon.conf
2. Set default-sample-rate = 44100 in daemon.conf
3. Set alternate-sample-rate 48000 in daemon.conf
4. Restart pulseaudio
5. Play a 48000 (or any other) audio file

Actual results:
File is played as 44100 audio. Pacmd list-sink-inputs shows that
resampling is happening. Play an audio file with any other sample
rate, and it will be resampled to 44100.

Expected results:
Audio file plays at 48000. Any other file is played in its own sample rate.

In my case, this affects USB audio. Tried both a Dragonfly Red, a
Fostex HP-A4 and an unknown Soundblaster USB audio dac/amp, and all of
them show the same behaviour as described here. Most probably, the
regression affects all USB audio devices.

All kernels from the 5.10 series are fine. Here's the offending patch
that introduced the regression. Reverting it on top of kernel 5.11 /
5.11.1 resolves the problem:

[root@chiara linux-stable]# git bisect good
e4ea77f8e53f9accb9371fba34c189d0447ecce0 is the first bad commit
commit e4ea77f8e53f9accb9371fba34c189d0447ecce0
Author: Takashi Iwai 
Date:   Mon Jan 11 09:16:11 2021 +0100

ALSA: usb-audio: Always apply the hw constraints for implicit fb sync

Since the commit 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for
implicit fb sync"), we apply the hw constraints for the implicit
feedback sync to make the secondary open aligned with the already
opened stream setup.  This change assumed that the secondary open is
performed after the first stream has been already set up, and adds the
hw constraints to sync with the first stream's parameters only when
the EP setup for the first stream was confirmed at the open time.
However, most of applications handling the full-duplex operations do
open both playback and capture streams at first, then set up both
streams.  This results in skipping the additional hw constraints since
the counter-part stream hasn't been set up yet at the open of the
second stream, and it eventually leads to "incompatible EP" error in
the end.

This patch corrects the behavior by always applying the hw constraints
for the implicit fb sync.  The hw constraint rules are defined so that
they check the sync EP dynamically at each invocation, instead.  This
covers the concurrent stream setups better and lets the hw refine
calls resolving to the right configuration.

Also this patch corrects a minor error that has existed in the debug
print that isn't built as default.

Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb 
sync")
Link: https://lore.kernel.org/r/20210111081611.12790-1-ti...@suse.de
Signed-off-by: Takashi Iwai 

 sound/usb/pcm.c | 171 +++-
 1 file changed, 108 insertions(+), 63 deletions(-)
[root@chiara linux-stable]#

Feel free to contact me if you think I can help.

Thanks, Heinz.

Re: [PATCH V3 00/16] Introduce the BFQ I/O scheduler

[Heinz Diehl]

On 11.04.2017, Paolo Valente wrote: 

> new patch series, addressing (both) issues raised by Bart [1].

I'm doing a lot of automatic video transcoding in order to get my
collection of homemade videos down to an acceptable size (mainly
landscapes and boats all over the Norwegian west coast, taken with an old
cam that only produces uncompressed files). This process
involves heavy permanent writing to disk, often over a period of 10
min and more. When this happens, the whole system is kind of
unresponsive. I'm running Fedora 25, but with a self-customised kernel
that is fully low-latency, and the machine is a quadcore Intel Xeon
which should have enough power (Intel(R) Xeon(R) CPU E3-1241 v3 @
3.50GHz).

Using plain blk-mq, the system is very sluggish when there is heavy
disk writing, and it can take up to several minutes (up to the point
where the disk writing actually finishes) to start programs like gimp
or Libreoffice. In fact, when I click on the "applications" button
within XFCE, it can take a long time before the window even opens.
I played with deadline-mq too, and the situation remains the same
unless I do some heavy tuning like this:

echo "mq-deadline" > /sys/block/nvme0n1/queue/scheduler
echo "1" > /sys/block/nvme0n1/queue/iosched/fifo_batch
echo "4" > /sys/block/nvme0n1/queue/iosched/writes_starved
echo "100" > /sys/block/nvme0n1/queue/iosched/read_expire
echo "2000" > /sys/block/nvme0n1/queue/iosched/write_expire

With deadline-mq tuned like this, overall responsiveness is a little bit
better, but not nearly as good as when using bfq. With plain bfq, no
tuning is needed. The system is no longer sluggish. Any program starts
within seconds, and all is very much responsive. Max throughput isn't
important to me, the nvme "harddisk" is fast enough that some MB/s
more or less do not really matter.

[root@chiara ~]# lspci -v | grep -i nvme
01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe
SSD Controller SM951/PM951 (rev 01) (prog-if 02 [NVM Express])
Kernel driver in use: nvme
Kernel modules: nvme

As an end-user with no relevant programming skills to be able to
contribute, I would wish that developers would combine their forces and
help Paolo to get bfq into the kernel and to make bfq even better.

Thanks,
 Heinz
 

Re: [PATCH V3 00/16] Introduce the BFQ I/O scheduler

[Heinz Diehl]

On 11.04.2017, Paolo Valente wrote: 

> new patch series, addressing (both) issues raised by Bart [1].

I'm doing a lot of automatic video transcoding in order to get my
collection of homemade videos down to an acceptable size (mainly
landscapes and boats all over the Norwegian west coast, taken with an old
cam that only produces uncompressed files). This process
involves heavy permanent writing to disk, often over a period of 10
min and more. When this happens, the whole system is kind of
unresponsive. I'm running Fedora 25, but with a self-customised kernel
that is fully low-latency, and the machine is a quadcore Intel Xeon
which should have enough power (Intel(R) Xeon(R) CPU E3-1241 v3 @
3.50GHz).

Using plain blk-mq, the system is very sluggish when there is heavy
disk writing, and it can take up to several minutes (up to the point
where the disk writing actually finishes) to start programs like gimp
or Libreoffice. In fact, when I click on the "applications" button
within XFCE, it can take a long time before the window even opens.
I played with deadline-mq too, and the situation remains the same
unless I do some heavy tuning like this:

echo "mq-deadline" > /sys/block/nvme0n1/queue/scheduler
echo "1" > /sys/block/nvme0n1/queue/iosched/fifo_batch
echo "4" > /sys/block/nvme0n1/queue/iosched/writes_starved
echo "100" > /sys/block/nvme0n1/queue/iosched/read_expire
echo "2000" > /sys/block/nvme0n1/queue/iosched/write_expire

With deadline-mq tuned like this, overall responsiveness is a little bit
better, but not nearly as good as when using bfq. With plain bfq, no
tuning is needed. The system is no longer sluggish. Any program starts
within seconds, and all is very much responsive. Max throughput isn't
important to me, the nvme "harddisk" is fast enough that some MB/s
more or less do not really matter.

[root@chiara ~]# lspci -v | grep -i nvme
01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe
SSD Controller SM951/PM951 (rev 01) (prog-if 02 [NVM Express])
Kernel driver in use: nvme
Kernel modules: nvme

As an end-user with no relevant programming skills to be able to
contribute, I would wish that developers would combine their forces and
help Paolo to get bfq into the kernel and to make bfq even better.

Thanks,
 Heinz
 

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[Heinz Diehl]

On 27.10.2016, Grozdan wrote: 

> So in the end, I'm here to support the inclusion of BFQ. Paolo has put
> too much energy, time, and sleepless nights into this so people like
> me can have a working, responsive system during heavy disk operations.
> From a normal user's perspective, I do not want BFQ to be dismissed
> and all the effort/time/etc thrown out the window. From my
> perspective, Paolo deserves more support from the guys in charge of
> the block layer in Linux.

I really  want to second that!

Just take a bog-standard desktop PC with an SSD and a reasonably fast
CPU (an 8-core Xeon in my case) and do the following:

1. dd if=/dev/zero of=deleteme bs=1M count=5
2. Start oowriter (Libreoffice Writer)

Using both cfq, deadline or noop, oowriter does not load until dd'ing
the 50 gigs is finished. Using bfq, oowriter loads nearly immediately.

Not to mention that both cfq, deadline and noop are a nightmare on
Android in terms of latency.

I'm (obviously) neither a kernel nor a bfq developer, but I really
want you to reconsider, with the overall greatness of bfq in mind, if
it really is totally impossible to include it at least as a scheduler
option, alongside the other three already existing ones.

Thanks,
 Heinz
 

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[Heinz Diehl]

On 27.10.2016, Grozdan wrote: 

> So in the end, I'm here to support the inclusion of BFQ. Paolo has put
> too much energy, time, and sleepless nights into this so people like
> me can have a working, responsive system during heavy disk operations.
> From a normal user's perspective, I do not want BFQ to be dismissed
> and all the effort/time/etc thrown out the window. From my
> perspective, Paolo deserves more support from the guys in charge of
> the block layer in Linux.

I really  want to second that!

Just take a bog-standard desktop PC with an SSD and a reasonably fast
CPU (an 8-core Xeon in my case) and do the following:

1. dd if=/dev/zero of=deleteme bs=1M count=5
2. Start oowriter (Libreoffice Writer)

Using both cfq, deadline or noop, oowriter does not load until dd'ing
the 50 gigs is finished. Using bfq, oowriter loads nearly immediately.

Not to mention that both cfq, deadline and noop are a nightmare on
Android in terms of latency.

I'm (obviously) neither a kernel nor a bfq developer, but I really
want you to reconsider, with the overall greatness of bfq in mind, if
it really is totally impossible to include it at least as a scheduler
option, alongside the other three already existing ones.

Thanks,
 Heinz
 

Re: [PATCH V3 00/11] block-throttle: add .high limit

[Heinz Diehl]

On 06.10.2016, Linus Walleij wrote: 

> Not just desktops, also Android phones.
 
> So why not have BFQ as a separate scheduling policy upstream,
> alongside CFQ, deadline and noop?

Please, just do it! CFQ and deadline perform horribly on Android, and
the same is true for desktop systems based on SSD drives.

What e.g. this test shows is true for all of my machines:
https://www.youtube.com/watch?v=1cjZeaCXIyM

I've been using BFQ nearly right from its inception, and it improves
all of my systems noticeably, in fact in such a positive way that I
don't update to a newer kernel unless there is a BFQ patch ready for
it.

Re: [PATCH V3 00/11] block-throttle: add .high limit

[Heinz Diehl]

On 06.10.2016, Linus Walleij wrote: 

> Not just desktops, also Android phones.
 
> So why not have BFQ as a separate scheduling policy upstream,
> alongside CFQ, deadline and noop?

Please, just do it! CFQ and deadline perform horribly on Android, and
the same is true for desktop systems based on SSD drives.

What e.g. this test shows is true for all of my machines:
https://www.youtube.com/watch?v=1cjZeaCXIyM

I've been using BFQ nearly right from its inception, and it improves
all of my systems noticeably, in fact in such a positive way that I
don't update to a newer kernel unless there is a BFQ patch ready for
it.

Re: [PATCH 4.6 00/31] 4.6.4-stable review

[Heinz Diehl]

On 07.07.2016, Greg Kroah-Hartman wrote: 

> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.6.4-rc1.gz

I get an 404 error:
The requested URL /pub/linux/kernel/v4.x/stable-review/patch-4.6.4-rc1.gz was 
not found
on this server.

Re: [PATCH 4.6 00/31] 4.6.4-stable review

[Heinz Diehl]

On 07.07.2016, Greg Kroah-Hartman wrote: 

> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.6.4-rc1.gz

I get an 404 error:
The requested URL /pub/linux/kernel/v4.x/stable-review/patch-4.6.4-rc1.gz was 
not found
on this server.

Re: Where is nilfs2 fsck

[Heinz Diehl]

On 08.02.2016, David Niklas wrote: 

> Alas, my beautiful fs has become damaged and fsck does nothing, I think
> it's a nop.
> What is wrong, something in the btree, the original message was in
> syslog but it seems to have rotated, I could tell you but I'd have to
> cause my kernel to remount my home dir RO, which is not acceptable at
> this time.
> I'm not interested in the files that can't be accessed, I was trying to
> delete them when I found the error so even an experimental fsck would do.
> I do have nilfs2-utils installed but I can't find anything useful in
> there.
> Do I need to backup and reformat the partition?

There is no fsck.nilfs or similar, so yes. Nilfs2 automatically recovers most
of the time, though, so there may be underlying hardware failure. I've
been using it extensively in the last 2 years, and never seen a single
fs damage which didn't get recovered immediately.

Re: Where is nilfs2 fsck

[Heinz Diehl]

On 08.02.2016, David Niklas wrote: 

> Alas, my beautiful fs has become damaged and fsck does nothing, I think
> it's a nop.
> What is wrong, something in the btree, the original message was in
> syslog but it seems to have rotated, I could tell you but I'd have to
> cause my kernel to remount my home dir RO, which is not acceptable at
> this time.
> I'm not interested in the files that can't be accessed, I was trying to
> delete them when I found the error so even an experimental fsck would do.
> I do have nilfs2-utils installed but I can't find anything useful in
> there.
> Do I need to backup and reformat the partition?

There is no fsck.nilfs or similar, so yes. Nilfs2 automatically recovers most
of the time, though, so there may be underlying hardware failure. I've
been using it extensively in the last 2 years, and never seen a single
fs damage which didn't get recovered immediately.

Re: Linux 4.5-rc2

[Heinz Diehl]

On 01.02.2016, Linus Torvalds wrote: 

> Heinz? Did you actually test rc2 or something else?

You're right, my bad! In fact, I tested 4.4.1-rc1 and 4.5-rc1.
Sorry for the noise!

Re: Linux 4.5-rc2

[Heinz Diehl]

Hi,

On 01.02.2016, Linus Torvalds wrote: 

> Go forth and test,
> 
>  Linus

Still, some Asus laptops are hanging at boot-time, both with latest
-stable and 4.5-rc1/rc2:

[4.056862] asus_laptop:model detected
[4.058731] BUG: unable to handle kernel NULL pointer dereference at 
0e20
[4.060018] IP: [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.061346] PGD 0
[4.062629] Oops:  [#1] PREEMPT SMP
[4.063960] Modules linked in: wmi asus_laptop(+) input_polldev 
sparse_keymap rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc 
sch_fq_codel tcp_westwood xfs libcrc32c
+hid_logitech_dj crc32c_intel serio_raw atl1c i915 i2c_algo_bit drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm i2c_core video
[4.067026] CPU: 1 PID: 536 Comm: systemd-udevd Not tainted 4.4.0 #1
[4.068515] Hardware name: ASUSTeK Computer Inc. U45JC/U45JC, BIOS 
U45JC.208 02/24/2011
[4.070023] task: 88003645b680 ti: 8800a4a0c000 task.ti: 
8800a4a0c000
[4.071568] RIP: 0010:[]  [] 
asus_sysfs_is_visible+0x13/0x1d0 [asus_laptop]
[4.073188] RSP: :8800a4a0faf8  EFLAGS: 00010282
[4.074820] RAX:  RBX:  RCX: 
[4.076462] RDX:  RSI: c03d63c0 RDI: 88003675b420
[4.078109] RBP: 8800a4a0fb08 R08: 8801428940c8 R09: 0124
[4.079777] R10: 88014348d100 R11: 0014 R12: c03d4940
[4.081470] R13:  R14: 8801418af000 R15: c03d6220
[4.083156] FS:  7f58ba6dd8c0() GS:880147c4() 
knlGS:
[4.084885] CS:  0010 DS:  ES:  CR0: 80050033
[4.086611] CR2: 0e20 CR3: a49f3000 CR4: 06e0
[4.088351] Stack:
[4.090066]   c03d4940 8800a4a0fb50 
8122d12b
[4.091838]   88003675b420 880141327000 

[4.093606]   880036b42498 0001 
8800a4a0fb60
[4.095386] Call Trace:
[4.097151]  [] internal_create_group+0xbb/0x310
[4.098943]  [] sysfs_create_group+0x13/0x20
[4.100748]  [] asus_acpi_add+0x3bb/0xea0 [asus_laptop]
[4.102583]  [] acpi_device_probe+0x4f/0xf5
[4.104415]  [] driver_probe_device+0x167/0x490
[4.106254]  [] __driver_attach+0x84/0x90
[4.108087]  [] ? driver_probe_device+0x490/0x490
[4.109931]  [] bus_for_each_dev+0x64/0xa0
[4.111724]  [] driver_attach+0x1e/0x20
[4.113509]  [] bus_add_driver+0x1eb/0x280
[4.115273]  [] ? 0xc03da000
[4.117032]  [] driver_register+0x60/0xe0
[4.118818]  [] acpi_bus_register_driver+0x38/0x40
[4.120619]  [] asus_laptop_init+0x2a/0x1000 [asus_laptop]
[4.122433]  [] do_one_initcall+0xab/0x1c0
[4.124276]  [] do_init_module+0x5f/0x1e5
[4.126114]  [] load_module+0x1f3f/0x2530
[4.127943]  [] ? __symbol_put+0x50/0x50
[4.129786]  [] ? copy_module_from_fd.isra.50+0xdb/0x130
[4.131653]  [] SyS_finit_module+0x9a/0xc0
[4.133521]  [] entry_SYSCALL_64_fastpath+0x12/0x6a
[4.135378] Code: c7 80 48 3d c0 e8 11 7e d7 c0 4c 89 f7 e8 66 3c e5 ff e9 
27 ff ff ff 90 66 66 66 66 90 55 48 89 e5 41 54 53 48 8b 8790 00 00 00 <4c> 8b 
a0 20 0e 00 00 0f b6 80 95 0d 00 00 84 c0 74 1a 48 81 fe
[4.139719] RIP  [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.141788]  RSP 
[4.143809] CR2: 0e20
[4.145867] ---[ end trace 7d8d7d572a3e9126 ]---

The bug is also reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=110751

This patch fixes the problem (both for me and others):

From: Martin Wilck 

Since b8b2c7d845d5, platform_drv_probe() is called for all platform
devices. If drv->probe is NULL, and dev_pm_domain_attach() fails,
platform_drv_probe() will return the error code from dev_pm_domain_attach().

This causes real_probe() to enter the "probe_failed" path and set
dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume
success if both dev->bus->probe and drv->probe were missing. As a result,
a device and driver could be "bound" together just by matching their names;
this doesn't work any more after b8b2c7d845d5.

This change broke the assumptions of certain drivers; for example, the TPM
code has long assumed that platform driver and device with matching name
could be bound in this way. That assumption may cause such drivers to
fail with Oops during initialization after applying this change. Failure
in suspend/resume tests under qemu has also been reported.

This patch restores the previous (4.3.0 and earlier) behavior of
platform_drv_probe() in the case when the associated platform driver has
no "probe" function.

Fixes: b8b2c7d845d5 ("base/platform: assert that dev_pm_domain callbacks are 
called unconditionally")
Signed-off-by: Martin Wilck 
---
 v2: fixed style issues, rephrased commit message.
 v3: rephrased commit message 

Re: Linux 4.5-rc2

[Heinz Diehl]

Hi,

On 01.02.2016, Linus Torvalds wrote: 

> Go forth and test,
> 
>  Linus

Still, some Asus laptops are hanging at boot-time, both with latest
-stable and 4.5-rc1/rc2:

[4.056862] asus_laptop:model detected
[4.058731] BUG: unable to handle kernel NULL pointer dereference at 
0e20
[4.060018] IP: [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.061346] PGD 0
[4.062629] Oops:  [#1] PREEMPT SMP
[4.063960] Modules linked in: wmi asus_laptop(+) input_polldev 
sparse_keymap rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc 
sch_fq_codel tcp_westwood xfs libcrc32c
+hid_logitech_dj crc32c_intel serio_raw atl1c i915 i2c_algo_bit drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm i2c_core video
[4.067026] CPU: 1 PID: 536 Comm: systemd-udevd Not tainted 4.4.0 #1
[4.068515] Hardware name: ASUSTeK Computer Inc. U45JC/U45JC, BIOS 
U45JC.208 02/24/2011
[4.070023] task: 88003645b680 ti: 8800a4a0c000 task.ti: 
8800a4a0c000
[4.071568] RIP: 0010:[]  [] 
asus_sysfs_is_visible+0x13/0x1d0 [asus_laptop]
[4.073188] RSP: :8800a4a0faf8  EFLAGS: 00010282
[4.074820] RAX:  RBX:  RCX: 
[4.076462] RDX:  RSI: c03d63c0 RDI: 88003675b420
[4.078109] RBP: 8800a4a0fb08 R08: 8801428940c8 R09: 0124
[4.079777] R10: 88014348d100 R11: 0014 R12: c03d4940
[4.081470] R13:  R14: 8801418af000 R15: c03d6220
[4.083156] FS:  7f58ba6dd8c0() GS:880147c4() 
knlGS:
[4.084885] CS:  0010 DS:  ES:  CR0: 80050033
[4.086611] CR2: 0e20 CR3: a49f3000 CR4: 06e0
[4.088351] Stack:
[4.090066]   c03d4940 8800a4a0fb50 
8122d12b
[4.091838]   88003675b420 880141327000 

[4.093606]   880036b42498 0001 
8800a4a0fb60
[4.095386] Call Trace:
[4.097151]  [] internal_create_group+0xbb/0x310
[4.098943]  [] sysfs_create_group+0x13/0x20
[4.100748]  [] asus_acpi_add+0x3bb/0xea0 [asus_laptop]
[4.102583]  [] acpi_device_probe+0x4f/0xf5
[4.104415]  [] driver_probe_device+0x167/0x490
[4.106254]  [] __driver_attach+0x84/0x90
[4.108087]  [] ? driver_probe_device+0x490/0x490
[4.109931]  [] bus_for_each_dev+0x64/0xa0
[4.111724]  [] driver_attach+0x1e/0x20
[4.113509]  [] bus_add_driver+0x1eb/0x280
[4.115273]  [] ? 0xc03da000
[4.117032]  [] driver_register+0x60/0xe0
[4.118818]  [] acpi_bus_register_driver+0x38/0x40
[4.120619]  [] asus_laptop_init+0x2a/0x1000 [asus_laptop]
[4.122433]  [] do_one_initcall+0xab/0x1c0
[4.124276]  [] do_init_module+0x5f/0x1e5
[4.126114]  [] load_module+0x1f3f/0x2530
[4.127943]  [] ? __symbol_put+0x50/0x50
[4.129786]  [] ? copy_module_from_fd.isra.50+0xdb/0x130
[4.131653]  [] SyS_finit_module+0x9a/0xc0
[4.133521]  [] entry_SYSCALL_64_fastpath+0x12/0x6a
[4.135378] Code: c7 80 48 3d c0 e8 11 7e d7 c0 4c 89 f7 e8 66 3c e5 ff e9 
27 ff ff ff 90 66 66 66 66 90 55 48 89 e5 41 54 53 48 8b 8790 00 00 00 <4c> 8b 
a0 20 0e 00 00 0f b6 80 95 0d 00 00 84 c0 74 1a 48 81 fe
[4.139719] RIP  [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.141788]  RSP 
[4.143809] CR2: 0e20
[4.145867] ---[ end trace 7d8d7d572a3e9126 ]---

The bug is also reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=110751

This patch fixes the problem (both for me and others):

From: Martin Wilck 

Since b8b2c7d845d5, platform_drv_probe() is called for all platform
devices. If drv->probe is NULL, and dev_pm_domain_attach() fails,
platform_drv_probe() will return the error code from dev_pm_domain_attach().

This causes real_probe() to enter the "probe_failed" path and set
dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume
success if both dev->bus->probe and drv->probe were missing. As a result,
a device and driver could be "bound" together just by matching their names;
this doesn't work any more after b8b2c7d845d5.

This change broke the assumptions of certain drivers; for example, the TPM
code has long assumed that platform driver and device with matching name
could be bound in this way. That assumption may cause such drivers to
fail with Oops during initialization after applying this change. Failure
in suspend/resume tests under qemu has also been reported.

This patch restores the previous (4.3.0 and earlier) behavior of
platform_drv_probe() in the case when the associated platform driver has
no "probe" function.

Fixes: b8b2c7d845d5 ("base/platform: assert that dev_pm_domain callbacks are 
called unconditionally")
Signed-off-by: Martin Wilck 
---
 v2: fixed style 

Re: Linux 4.5-rc2

[Heinz Diehl]

On 01.02.2016, Linus Torvalds wrote: 

> Heinz? Did you actually test rc2 or something else?

You're right, my bad! In fact, I tested 4.4.1-rc1 and 4.5-rc1.
Sorry for the noise!

Re: BUG: Asus laptop, null pointer dereference

[Heinz Diehl]

On 25.01.2016, Heinz Diehl wrote: 

> [4.056862] asus_laptop:model detected
> [4.058731] BUG: unable to handle kernel NULL pointer dereference at 
> 0e20
> [4.060018] IP: [] asus_sysfs_is_visible+0x13/0x1d0 
> [asus_laptop]
> [4.061346] PGD 0 
> [4.062629] Oops:  [#1] PREEMPT SMP 
> [4.063960] Modules linked in: wmi asus_laptop(+) input_polldev 
> sparse_keymap rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc 
> sch_fq_codel tcp_westwood xfs libcrc32c hid_logitech_dj crc32c_intel 
> serio_raw atl1c i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect 
> sysimgblt fb_sys_fops drm i2c_core video
> [4.067026] CPU: 1 PID: 536 Comm: systemd-udevd Not tainted 4.4.0 #1
> [4.068515] Hardware name: ASUSTeK Computer Inc. U45JC/U45JC, BIOS 
> U45JC.208 02/24/2011
[]

Ok, I see, this is already reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=110751

Thanks,
 Heinz
 

BUG: Asus laptop, null pointer dereference

[Heinz Diehl]

Hi,

I'm hitting the following bug when starting my Asus U45JC laptop. This
happens with both 4.4.0 and 4.5-rc1. 4.3.x (and any older kernel) is
fine.

[4.056862] asus_laptop:model detected
[4.058731] BUG: unable to handle kernel NULL pointer dereference at 
0e20
[4.060018] IP: [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.061346] PGD 0 
[4.062629] Oops:  [#1] PREEMPT SMP 
[4.063960] Modules linked in: wmi asus_laptop(+) input_polldev 
sparse_keymap rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc 
sch_fq_codel tcp_westwood xfs libcrc32c hid_logitech_dj crc32c_intel serio_raw 
atl1c i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops drm i2c_core video
[4.067026] CPU: 1 PID: 536 Comm: systemd-udevd Not tainted 4.4.0 #1
[4.068515] Hardware name: ASUSTeK Computer Inc. U45JC/U45JC, BIOS 
U45JC.208 02/24/2011
[4.070023] task: 88003645b680 ti: 8800a4a0c000 task.ti: 
8800a4a0c000
[4.071568] RIP: 0010:[]  [] 
asus_sysfs_is_visible+0x13/0x1d0 [asus_laptop]
[4.073188] RSP: :8800a4a0faf8  EFLAGS: 00010282
[4.074820] RAX:  RBX:  RCX: 
[4.076462] RDX:  RSI: c03d63c0 RDI: 88003675b420
[4.078109] RBP: 8800a4a0fb08 R08: 8801428940c8 R09: 0124
[4.079777] R10: 88014348d100 R11: 0014 R12: c03d4940
[4.081470] R13:  R14: 8801418af000 R15: c03d6220
[4.083156] FS:  7f58ba6dd8c0() GS:880147c4() 
knlGS:
[4.084885] CS:  0010 DS:  ES:  CR0: 80050033
[4.086611] CR2: 0e20 CR3: a49f3000 CR4: 06e0
[4.088351] Stack:
[4.090066]   c03d4940 8800a4a0fb50 
8122d12b
[4.091838]   88003675b420 880141327000 

[4.093606]   880036b42498 0001 
8800a4a0fb60
[4.095386] Call Trace:
[4.097151]  [] internal_create_group+0xbb/0x310
[4.098943]  [] sysfs_create_group+0x13/0x20
[4.100748]  [] asus_acpi_add+0x3bb/0xea0 [asus_laptop]
[4.102583]  [] acpi_device_probe+0x4f/0xf5
[4.104415]  [] driver_probe_device+0x167/0x490
[4.106254]  [] __driver_attach+0x84/0x90
[4.108087]  [] ? driver_probe_device+0x490/0x490
[4.109931]  [] bus_for_each_dev+0x64/0xa0
[4.111724]  [] driver_attach+0x1e/0x20
[4.113509]  [] bus_add_driver+0x1eb/0x280
[4.115273]  [] ? 0xc03da000
[4.117032]  [] driver_register+0x60/0xe0
[4.118818]  [] acpi_bus_register_driver+0x38/0x40
[4.120619]  [] asus_laptop_init+0x2a/0x1000 [asus_laptop]
[4.122433]  [] do_one_initcall+0xab/0x1c0
[4.124276]  [] do_init_module+0x5f/0x1e5
[4.126114]  [] load_module+0x1f3f/0x2530
[4.127943]  [] ? __symbol_put+0x50/0x50
[4.129786]  [] ? copy_module_from_fd.isra.50+0xdb/0x130
[4.131653]  [] SyS_finit_module+0x9a/0xc0
[4.133521]  [] entry_SYSCALL_64_fastpath+0x12/0x6a
[4.135378] Code: c7 80 48 3d c0 e8 11 7e d7 c0 4c 89 f7 e8 66 3c e5 ff e9 
27 ff ff ff 90 66 66 66 66 90 55 48 89 e5 41 54 53 48 8b 87 90 00 00 00 <4c> 8b 
a0 20 0e 00 00 0f b6 80 95 0d 00 00 84 c0 74 1a 48 81 fe 
[4.139719] RIP  [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.141788]  RSP 
[4.143809] CR2: 0e20
[4.145867] ---[ end trace 7d8d7d572a3e9126 ]---


Thanks, Heinz.

BUG: Asus laptop, null pointer dereference

[Heinz Diehl]

Hi,

I'm hitting the following bug when starting my Asus U45JC laptop. This
happens with both 4.4.0 and 4.5-rc1. 4.3.x (and any older kernel) is
fine.

[4.056862] asus_laptop:model detected
[4.058731] BUG: unable to handle kernel NULL pointer dereference at 
0e20
[4.060018] IP: [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.061346] PGD 0 
[4.062629] Oops:  [#1] PREEMPT SMP 
[4.063960] Modules linked in: wmi asus_laptop(+) input_polldev 
sparse_keymap rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc 
sch_fq_codel tcp_westwood xfs libcrc32c hid_logitech_dj crc32c_intel serio_raw 
atl1c i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops drm i2c_core video
[4.067026] CPU: 1 PID: 536 Comm: systemd-udevd Not tainted 4.4.0 #1
[4.068515] Hardware name: ASUSTeK Computer Inc. U45JC/U45JC, BIOS 
U45JC.208 02/24/2011
[4.070023] task: 88003645b680 ti: 8800a4a0c000 task.ti: 
8800a4a0c000
[4.071568] RIP: 0010:[]  [] 
asus_sysfs_is_visible+0x13/0x1d0 [asus_laptop]
[4.073188] RSP: :8800a4a0faf8  EFLAGS: 00010282
[4.074820] RAX:  RBX:  RCX: 
[4.076462] RDX:  RSI: c03d63c0 RDI: 88003675b420
[4.078109] RBP: 8800a4a0fb08 R08: 8801428940c8 R09: 0124
[4.079777] R10: 88014348d100 R11: 0014 R12: c03d4940
[4.081470] R13:  R14: 8801418af000 R15: c03d6220
[4.083156] FS:  7f58ba6dd8c0() GS:880147c4() 
knlGS:
[4.084885] CS:  0010 DS:  ES:  CR0: 80050033
[4.086611] CR2: 0e20 CR3: a49f3000 CR4: 06e0
[4.088351] Stack:
[4.090066]   c03d4940 8800a4a0fb50 
8122d12b
[4.091838]   88003675b420 880141327000 

[4.093606]   880036b42498 0001 
8800a4a0fb60
[4.095386] Call Trace:
[4.097151]  [] internal_create_group+0xbb/0x310
[4.098943]  [] sysfs_create_group+0x13/0x20
[4.100748]  [] asus_acpi_add+0x3bb/0xea0 [asus_laptop]
[4.102583]  [] acpi_device_probe+0x4f/0xf5
[4.104415]  [] driver_probe_device+0x167/0x490
[4.106254]  [] __driver_attach+0x84/0x90
[4.108087]  [] ? driver_probe_device+0x490/0x490
[4.109931]  [] bus_for_each_dev+0x64/0xa0
[4.111724]  [] driver_attach+0x1e/0x20
[4.113509]  [] bus_add_driver+0x1eb/0x280
[4.115273]  [] ? 0xc03da000
[4.117032]  [] driver_register+0x60/0xe0
[4.118818]  [] acpi_bus_register_driver+0x38/0x40
[4.120619]  [] asus_laptop_init+0x2a/0x1000 [asus_laptop]
[4.122433]  [] do_one_initcall+0xab/0x1c0
[4.124276]  [] do_init_module+0x5f/0x1e5
[4.126114]  [] load_module+0x1f3f/0x2530
[4.127943]  [] ? __symbol_put+0x50/0x50
[4.129786]  [] ? copy_module_from_fd.isra.50+0xdb/0x130
[4.131653]  [] SyS_finit_module+0x9a/0xc0
[4.133521]  [] entry_SYSCALL_64_fastpath+0x12/0x6a
[4.135378] Code: c7 80 48 3d c0 e8 11 7e d7 c0 4c 89 f7 e8 66 3c e5 ff e9 
27 ff ff ff 90 66 66 66 66 90 55 48 89 e5 41 54 53 48 8b 87 90 00 00 00 <4c> 8b 
a0 20 0e 00 00 0f b6 80 95 0d 00 00 84 c0 74 1a 48 81 fe 
[4.139719] RIP  [] asus_sysfs_is_visible+0x13/0x1d0 
[asus_laptop]
[4.141788]  RSP 
[4.143809] CR2: 0e20
[4.145867] ---[ end trace 7d8d7d572a3e9126 ]---


Thanks, Heinz.

Re: BUG: Asus laptop, null pointer dereference

[Heinz Diehl]

On 25.01.2016, Heinz Diehl wrote: 

> [4.056862] asus_laptop:model detected
> [4.058731] BUG: unable to handle kernel NULL pointer dereference at 
> 0e20
> [4.060018] IP: [] asus_sysfs_is_visible+0x13/0x1d0 
> [asus_laptop]
> [4.061346] PGD 0 
> [4.062629] Oops:  [#1] PREEMPT SMP 
> [4.063960] Modules linked in: wmi asus_laptop(+) input_polldev 
> sparse_keymap rfkill nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc 
> sch_fq_codel tcp_westwood xfs libcrc32c hid_logitech_dj crc32c_intel 
> serio_raw atl1c i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect 
> sysimgblt fb_sys_fops drm i2c_core video
> [4.067026] CPU: 1 PID: 536 Comm: systemd-udevd Not tainted 4.4.0 #1
> [4.068515] Hardware name: ASUSTeK Computer Inc. U45JC/U45JC, BIOS 
> U45JC.208 02/24/2011
[]

Ok, I see, this is already reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=110751

Thanks,
 Heinz
 

Re: [PATCH 4.0 000/105] 4.0.6-stable review

[Heinz Diehl]

On 20.06.2015, Greg Kroah-Hartman wrote: 

> I need some kind of hint as to _what_ patch that is in mainline.  What's
> the git id of it in Linus's tree?

Sorry! It's commit 00425bb181c204c8f250fec122e2817a930e0286.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00425bb181c204c8f250fec122e2817a930e0286

-- 
OpenPGP Fingerprint: 531E 8E75 4395 ED38 CEC2  FD75 A1EB 6944 60F4 A92C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.0 000/105] 4.0.6-stable review

[Heinz Diehl]

On 19.06.2015, Greg Kroah-Hartman wrote: 

> This is the start of the stable review cycle for the 4.0.6 release.
> There are 105 patches in this series

Since a few -stable releases I'm missing this one (it's already in
mainline):

https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg14118.html

Thanks,
 Heinz
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.0 000/105] 4.0.6-stable review

[Heinz Diehl]

On 19.06.2015, Greg Kroah-Hartman wrote: 

 This is the start of the stable review cycle for the 4.0.6 release.
 There are 105 patches in this series

Since a few -stable releases I'm missing this one (it's already in
mainline):

https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg14118.html

Thanks,
 Heinz
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.0 000/105] 4.0.6-stable review

[Heinz Diehl]

On 20.06.2015, Greg Kroah-Hartman wrote: 

 I need some kind of hint as to _what_ patch that is in mainline.  What's
 the git id of it in Linus's tree?

Sorry! It's commit 00425bb181c204c8f250fec122e2817a930e0286.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00425bb181c204c8f250fec122e2817a930e0286

-- 
OpenPGP Fingerprint: 531E 8E75 4395 ED38 CEC2  FD75 A1EB 6944 60F4 A92C
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Heinz Diehl]

On 13.06.2015, Christoph Fritz wrote: 

>  - add kernel parameter "idle=halt" -> system runs fine
>  - disable CONFIG_HIGH_RES_TIMERS -> system runs fine
>  - change motherboard and disable C1E -> system runs fine
>  - change CPU to AMD Phenom II X6 Processor -> system runs fine

I encountered quite some C1E related problems with different Gigabyte
mainboards in the last few years. Try booting with
acpi_skip_timer_override, it fixed most of those problems for me.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lockup when C1E and high-resolution timers enabled

[Heinz Diehl]

On 13.06.2015, Christoph Fritz wrote: 

  - add kernel parameter idle=halt - system runs fine
  - disable CONFIG_HIGH_RES_TIMERS - system runs fine
  - change motherboard and disable C1E - system runs fine
  - change CPU to AMD Phenom II X6 Processor - system runs fine

I encountered quite some C1E related problems with different Gigabyte
mainboards in the last few years. Try booting with
acpi_skip_timer_override, it fixed most of those problems for me.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 09.06.2015, Karel Zak wrote: 

> Yeah, fixed:
[]

Thanks a lot to both of you! Tried both solutions and can confirm that
they work both.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 09.06.2015, Karel Zak wrote: 

 Yeah, fixed:
[]

Thanks a lot to both of you! Tried both solutions and can confirm that
they work both.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

> > This change has been applied between v2.24 and v2.24.1 of util-linux,
> > and not yet fixed in the mainline.
 
> Ok, I'll try to identify and revert this commit in the meantime.

The patch doesn't revert cleanly. Is there a workaround I could use
until the problem is properly fixed?

Thanks,
Heinz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Ryusuke Konishi wrote: 

> I succeeded to reproduce this issue on Fedora 20, 21, 22 and Debian
> jessie.  Also, I could narrow down the issue.

Thanks a lot for your effort!

> Here, the backup super block of /dev/sdb1 got detected also for
> /dev/sdb by the commit 5f77ce6f3269.

Just in case this matters, there is also a report from the util-linux
mailing list pointing to this particular commit:

http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/10766

> This change has been applied between v2.24 and v2.24.1 of util-linux,
> and not yet fixed in the mainline.

Ok, I'll try to identify and revert this commit in the meantime.

Thanks, Heinz.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

> Now, the newly formatted drive is registered in fstab to be
> automatically mounted on boot:
> 
> UUID=ff17dda9-fcae-42e7-a438-9087de58902e /USBDRIVE   nilfs2  
> defaults0   0

Sorry for the noise, but it's quite difficult to sum up all these
uuids when cop doesn't work: the above uuid is wrong, but it's a
simple copy error by me. So just assume it is correct. Sorry again!

The point is that the doube uuid occurs after booting, when trying to
mount from fstab.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

To be more precise, here's what works and what don't, in detail
(and after a fresh install of Arch):

The USB memory is xfs formatted and works fine:

[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda   
`-sda1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /


Now, it's nilfs2 formatted:

[root@alarmpi /]# mkfs.nilfs2 /dev/sda1
WARNING: Device /dev/sda1 appears to contain an existing xfs superblock.
WARNING: All data will be lost after format!

DO YOU REALLY WANT TO FORMAT DEVICE /dev/sda1?

Continue? [y/N] y
mkfs.nilfs2 (nilfs-utils 2.2.3)
Start writing file system initial data to the device
   Blocksize:4096  Device:/dev/sda1  Device Size:32026656768
File system initialization succeeded !! 

After that, all seems to be ok. lsblk shown no double uuid:

[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda   
`-sda1  nilfs2   98da384c-392e-4551-98c0-d076524f5d8b 
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /
[root@alarmpi /]# 


Now the USB drive gets manually mounted, all is ok:

[root@alarmpi /]# mount /dev/sda1 /USBDRIVE
[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda   
`-sda1  nilfs2   98da384c-392e-4551-98c0-d076524f5d8b /USBDRIVE
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /


Now, the newly formatted drive is registered in fstab to be
automatically mounted on boot:

UUID=ff17dda9-fcae-42e7-a438-9087de58902e   /USBDRIVE   nilfs2  
defaults0   0

After rebooting the machine, nothing is mounted, and lsblk shows the
double uuid:

[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda  98da384c-392e-4551-98c0-d076524f5d8b 
`-sda1  nilfs2   98da384c-392e-4551-98c0-d076524f5d8b
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /

The logs say:

Jun 08 11:23:47 alarmpi mount: mount.nilfs2: Error while mounting /dev/sda on 
/USBDRIVE: Device or resource busy
Jun 08 11:23:47 alarmpi systemd: Failed to mount /USBDRIVE.

Here it becomes clear what happens: the system wants to mount /dev/sda
rather than /dev/sda1, and thus fails.

Out of curiosity, I tried both xfs, ext4 and btrfs, and all of them
just work.

Thanks,
Heinz.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Ryusuke Konishi wrote: 

> Could you tell us the version information of distro,
> lsblk, libblkid, nilfs-utils, and kernel you are using ?

It happens on two different systems:

The first one is bog-standard Fedora 21:

[htd@chiara ~]$ rpm -qa | egrep 'lsblk|libblkid|nilfs'
libblkid-devel-2.25.2-3.fc21.x86_64
libblkid-2.25.2-3.fc21.x86_64
nilfs-utils-2.2.3-1.fc21.x86_64

[htd@chiara ~]$ lscp -V
lscp (nilfs-utils 2.2.3)

[htd@chiara ~]$ lsblk --version
lsblk from util-linux 2.25.2

[htd@chiara ~]$ uname -a
Linux chiara.fritha.org 4.0.5-rc1 #1 SMP PREEMPT Wed Jun 3 20:41:46 CEST 2015 
x86_64 x86_64 x86_64 GNU/Linux


The second one is Arch Linux on a Raspberry Pi:

[root@keera ~]# pacman -Q | egrep 'libutil|nilfs'
libutil-linux 2.26.2-1
nilfs-utils 2.2.3-1

[root@keera ~]# lsblk --version
lsblk from util-linux 2.26.2

[root@keera ~]# lscp -V
lscp (nilfs-utils 2.2.3)

[root@keera ~]# uname -a
Linux keera 3.18.14-2-ARCH #1 SMP PREEMPT Thu May 28 07:19:33 MDT 2015 armv7l 
GNU/Linux

Tried to re-format the home partition on a Fedora 21 laptop with
nilfs2 and ran into the same problem as with USB memory as a samba
share on the Pi: the system tried to mount the block device rather
than the partition due to the uuid as shown in my previous email.

Thanks, Heinz.

-- 
OpenPGP Fingerprint: 531E 8E75 4395 ED38 CEC2  FD75 A1EB 6944 60F4 A92C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

> [root@keera ~]# lsblk -f
> NAMEFSTYPE LABEL UUID MOUNTPOINT
> sdb  ff17dda9-fcae-42e7-a438-9087de58902e 
>  
> `-sdb1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 

Copy error: replace xfs with nilfs2. Sorry!



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

NILFS2: double uuid

[Heinz Diehl]

Hi,

a nilfs2 formatted disk fails to mount via fstab due to double uuid's.
See lsblk output below. The logs indicate that the system attempts to
mount /dev/sdb rather than /dev/sdb1, which of course fails. In
addition, /dev/sdb should not have any uuid at all. Don't know why
that happens.

The phenomenon is easily reproducible: format a partition with nilfs2,
register it with the proper uuid in fstab and reboot. Tried both with
USB memory and real HDD.

[root@keera ~]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sdb  ff17dda9-fcae-42e7-a438-9087de58902e   
   
`-sdb1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 

Thanks,
 Heinz
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Ryusuke Konishi wrote: 

 I succeeded to reproduce this issue on Fedora 20, 21, 22 and Debian
 jessie.  Also, I could narrow down the issue.

Thanks a lot for your effort!

 Here, the backup super block of /dev/sdb1 got detected also for
 /dev/sdb by the commit 5f77ce6f3269.

Just in case this matters, there is also a report from the util-linux
mailing list pointing to this particular commit:

http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/10766

 This change has been applied between v2.24 and v2.24.1 of util-linux,
 and not yet fixed in the mainline.

Ok, I'll try to identify and revert this commit in the meantime.

Thanks, Heinz.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

  This change has been applied between v2.24 and v2.24.1 of util-linux,
  and not yet fixed in the mainline.
 
 Ok, I'll try to identify and revert this commit in the meantime.

The patch doesn't revert cleanly. Is there a workaround I could use
until the problem is properly fixed?

Thanks,
Heinz

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

NILFS2: double uuid

[Heinz Diehl]

Hi,

a nilfs2 formatted disk fails to mount via fstab due to double uuid's.
See lsblk output below. The logs indicate that the system attempts to
mount /dev/sdb rather than /dev/sdb1, which of course fails. In
addition, /dev/sdb should not have any uuid at all. Don't know why
that happens.

The phenomenon is easily reproducible: format a partition with nilfs2,
register it with the proper uuid in fstab and reboot. Tried both with
USB memory and real HDD.

[root@keera ~]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sdb  ff17dda9-fcae-42e7-a438-9087de58902e   
   
`-sdb1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 

Thanks,
 Heinz
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

 [root@keera ~]# lsblk -f
 NAMEFSTYPE LABEL UUID MOUNTPOINT
 sdb  ff17dda9-fcae-42e7-a438-9087de58902e 
  
 `-sdb1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 

Copy error: replace xfs with nilfs2. Sorry!



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Ryusuke Konishi wrote: 

 Could you tell us the version information of distro,
 lsblk, libblkid, nilfs-utils, and kernel you are using ?

It happens on two different systems:

The first one is bog-standard Fedora 21:

[htd@chiara ~]$ rpm -qa | egrep 'lsblk|libblkid|nilfs'
libblkid-devel-2.25.2-3.fc21.x86_64
libblkid-2.25.2-3.fc21.x86_64
nilfs-utils-2.2.3-1.fc21.x86_64

[htd@chiara ~]$ lscp -V
lscp (nilfs-utils 2.2.3)

[htd@chiara ~]$ lsblk --version
lsblk from util-linux 2.25.2

[htd@chiara ~]$ uname -a
Linux chiara.fritha.org 4.0.5-rc1 #1 SMP PREEMPT Wed Jun 3 20:41:46 CEST 2015 
x86_64 x86_64 x86_64 GNU/Linux


The second one is Arch Linux on a Raspberry Pi:

[root@keera ~]# pacman -Q | egrep 'libutil|nilfs'
libutil-linux 2.26.2-1
nilfs-utils 2.2.3-1

[root@keera ~]# lsblk --version
lsblk from util-linux 2.26.2

[root@keera ~]# lscp -V
lscp (nilfs-utils 2.2.3)

[root@keera ~]# uname -a
Linux keera 3.18.14-2-ARCH #1 SMP PREEMPT Thu May 28 07:19:33 MDT 2015 armv7l 
GNU/Linux

Tried to re-format the home partition on a Fedora 21 laptop with
nilfs2 and ran into the same problem as with USB memory as a samba
share on the Pi: the system tried to mount the block device rather
than the partition due to the uuid as shown in my previous email.

Thanks, Heinz.

-- 
OpenPGP Fingerprint: 531E 8E75 4395 ED38 CEC2  FD75 A1EB 6944 60F4 A92C
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

To be more precise, here's what works and what don't, in detail
(and after a fresh install of Arch):

The USB memory is xfs formatted and works fine:

[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda   
`-sda1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /


Now, it's nilfs2 formatted:

[root@alarmpi /]# mkfs.nilfs2 /dev/sda1
WARNING: Device /dev/sda1 appears to contain an existing xfs superblock.
WARNING: All data will be lost after format!

DO YOU REALLY WANT TO FORMAT DEVICE /dev/sda1?

Continue? [y/N] y
mkfs.nilfs2 (nilfs-utils 2.2.3)
Start writing file system initial data to the device
   Blocksize:4096  Device:/dev/sda1  Device Size:32026656768
File system initialization succeeded !! 

After that, all seems to be ok. lsblk shown no double uuid:

[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda   
`-sda1  nilfs2   98da384c-392e-4551-98c0-d076524f5d8b 
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /
[root@alarmpi /]# 


Now the USB drive gets manually mounted, all is ok:

[root@alarmpi /]# mount /dev/sda1 /USBDRIVE
[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda   
`-sda1  nilfs2   98da384c-392e-4551-98c0-d076524f5d8b /USBDRIVE
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /


Now, the newly formatted drive is registered in fstab to be
automatically mounted on boot:

UUID=ff17dda9-fcae-42e7-a438-9087de58902e   /USBDRIVE   nilfs2  
defaults0   0

After rebooting the machine, nothing is mounted, and lsblk shows the
double uuid:

[root@alarmpi /]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda  98da384c-392e-4551-98c0-d076524f5d8b 
`-sda1  nilfs2   98da384c-392e-4551-98c0-d076524f5d8b
mmcblk0   
|-mmcblk0p1 vfat EA5B-4477/boot
`-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 /

The logs say:

Jun 08 11:23:47 alarmpi mount: mount.nilfs2: Error while mounting /dev/sda on 
/USBDRIVE: Device or resource busy
Jun 08 11:23:47 alarmpi systemd: Failed to mount /USBDRIVE.

Here it becomes clear what happens: the system wants to mount /dev/sda
rather than /dev/sda1, and thus fails.

Out of curiosity, I tried both xfs, ext4 and btrfs, and all of them
just work.

Thanks,
Heinz.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

 Now, the newly formatted drive is registered in fstab to be
 automatically mounted on boot:
 
 UUID=ff17dda9-fcae-42e7-a438-9087de58902e /USBDRIVE   nilfs2  
 defaults0   0

Sorry for the noise, but it's quite difficult to sum up all these
uuids when coppaste doesn't work: the above uuid is wrong, but it's a
simple copy error by me. So just assume it is correct. Sorry again!

The point is that the doube uuid occurs after booting, when trying to
mount from fstab.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.18.3

[Heinz Diehl]

On 17.01.2015, Heinz Diehl wrote: 

> Since 3.18, machines with Ironlake Intel Graphics are left with a
> black screen when booting into X. I reported the bug here:
> 
> https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330

Here's a bit more explanation and the recommendation of/link to the
fix (in the last reply):

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=86679

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.18.3

[Heinz Diehl]

On 16.01.2015, Greg KH wrote: 

> I'm announcing the release of the 3.18.3 kernel.

Since 3.18, machines with Ironlake Intel Graphics are left with a
black screen when booting into X. I reported the bug here:

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330

And there are several reports of the same bug in the Bugzilla.
The problem is fixed in current mainline, but still present in
3.18.3. The patch which fixes the problem is attached, maybe it should
be applied to -stable as well?

Thanks,
 Heinz.

>From d472fcc8379c062bd56a3876fc6ef22258f14a91 Mon Sep 17 00:00:00 2001
From: Daniel Vetter 
Date: Mon, 24 Nov 2014 11:12:42 +0100
Subject: drm/i915: Disallow pin ioctl completely for kms drivers

The problem here is that SNA pins batchbuffers to etch out a bit more
performance. Iirc it started out as a w/a for i830M (which we've
implemented in the kernel since a long time already). The problem is
that the pin ioctl wasn't added in

commit d23db88c3ab233daed18709e3a24d6c95344117f
Author: Chris Wilson 
Date:   Fri May 23 08:48:08 2014 +0200

drm/i915: Prevent negative relocation deltas from wrapping

Fix this by simply disallowing pinning from userspace so that the
kernel is in full control of batch placement again. Especially since
distros are moving towards running X as non-root, so most users won't
even be able to see any benefits.

UMS support is dead now, but we need this minimal patch for
backporting. Follow-up patch will remove the pin ioctl code
completely.

Note to backporters: You must have both

commit b45305fce5bb1abec263fcff9d81ebecd6306ede
Author: Daniel Vetter 
Date:   Mon Dec 17 16:21:27 2012 +0100

drm/i915: Implement workaround for broken CS tlb on i830/845

which laned in 3.8 and

commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
Author: Chris Wilson 
Date:   Mon Sep 8 14:25:41 2014 +0100

drm/i915: Evict CS TLBs between batches

which is also marked cc: stable. Otherwise this could introduce a
regression by disabling the userspace w/a without the kernel w/a being
fully functional on i830/45.

References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116
Cc: sta...@vger.kernel.org # requires c4d69da167fa967749a and v3.8
Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fd17cca..97b86a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4263,7 +4263,7 @@ i915_gem_pin_ioctl(struct drm_device *dev, void *data,
struct drm_i915_gem_object *obj;
int ret;
 
-   if (INTEL_INFO(dev)->gen >= 6)
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
return -ENODEV;
 
ret = i915_mutex_lock_interruptible(dev);
@@ -4319,6 +4319,9 @@ i915_gem_unpin_ioctl(struct drm_device *dev, void *data,
struct drm_i915_gem_object *obj;
int ret;
 
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   return -ENODEV;
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
return ret;
-- 
cgit v0.10.2

Re: Linux 3.18.3

[Heinz Diehl]

On 16.01.2015, Greg KH wrote: 

 I'm announcing the release of the 3.18.3 kernel.

Since 3.18, machines with Ironlake Intel Graphics are left with a
black screen when booting into X. I reported the bug here:

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330

And there are several reports of the same bug in the Bugzilla.
The problem is fixed in current mainline, but still present in
3.18.3. The patch which fixes the problem is attached, maybe it should
be applied to -stable as well?

Thanks,
 Heinz.

From d472fcc8379c062bd56a3876fc6ef22258f14a91 Mon Sep 17 00:00:00 2001
From: Daniel Vetter daniel.vet...@ffwll.ch
Date: Mon, 24 Nov 2014 11:12:42 +0100
Subject: drm/i915: Disallow pin ioctl completely for kms drivers

The problem here is that SNA pins batchbuffers to etch out a bit more
performance. Iirc it started out as a w/a for i830M (which we've
implemented in the kernel since a long time already). The problem is
that the pin ioctl wasn't added in

commit d23db88c3ab233daed18709e3a24d6c95344117f
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Fri May 23 08:48:08 2014 +0200

drm/i915: Prevent negative relocation deltas from wrapping

Fix this by simply disallowing pinning from userspace so that the
kernel is in full control of batch placement again. Especially since
distros are moving towards running X as non-root, so most users won't
even be able to see any benefits.

UMS support is dead now, but we need this minimal patch for
backporting. Follow-up patch will remove the pin ioctl code
completely.

Note to backporters: You must have both

commit b45305fce5bb1abec263fcff9d81ebecd6306ede
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Mon Dec 17 16:21:27 2012 +0100

drm/i915: Implement workaround for broken CS tlb on i830/845

which laned in 3.8 and

commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Mon Sep 8 14:25:41 2014 +0100

drm/i915: Evict CS TLBs between batches

which is also marked cc: stable. Otherwise this could introduce a
regression by disabling the userspace w/a without the kernel w/a being
fully functional on i830/45.

References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116
Cc: sta...@vger.kernel.org # requires c4d69da167fa967749a and v3.8
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@intel.com

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fd17cca..97b86a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4263,7 +4263,7 @@ i915_gem_pin_ioctl(struct drm_device *dev, void *data,
struct drm_i915_gem_object *obj;
int ret;
 
-   if (INTEL_INFO(dev)-gen = 6)
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
return -ENODEV;
 
ret = i915_mutex_lock_interruptible(dev);
@@ -4319,6 +4319,9 @@ i915_gem_unpin_ioctl(struct drm_device *dev, void *data,
struct drm_i915_gem_object *obj;
int ret;
 
+   if (drm_core_check_feature(dev, DRIVER_MODESET))
+   return -ENODEV;
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
return ret;
-- 
cgit v0.10.2

Re: Linux 3.18.3

[Heinz Diehl]

On 17.01.2015, Heinz Diehl wrote: 

 Since 3.18, machines with Ironlake Intel Graphics are left with a
 black screen when booting into X. I reported the bug here:
 
 https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330

Here's a bit more explanation and the recommendation of/link to the
fix (in the last reply):

https://www.libreoffice.org/bugzilla/show_bug.cgi?id=86679

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Regression] 83f45fc turns machine's screen off

[Heinz Diehl]

On 14.12.2014, Emmanuel Benisty wrote: 

> >>> The following commit permanently turns my screen off when x server is
> >>> started (i3 330M Ironlake):
> >>>
> >>> [83f45fc360c8e16a330474860ebda872d1384c8c] drm: Don't grab an fb
> >>> reference for the idr
> >>>
> >>> Reverting this commit fixed the issue.

Haven't seen your mail until now. Seems to be the same bug that I'm 
encountering.

https://bugs.freedesktop.org/show_bug.cgi?id=87330
https://lkml.org/lkml/2014/12/14/26

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Regression] 3.18 black screen after boot (bisected)

[Heinz Diehl]

On 15.12.2014, Daniel Vetter wrote: 

> Can you please boot with drm.debug=0xf on both good and bad kernels and
> then grab dmesg from each?

The output is attached. The dmesg log stops after runlevel 3 for the
3.18 kernel, because I'm not able to do anything in runlevel 5 with a
black screen.

> To make sure we don't forget this please file the above summary plus dmesg
> files as a new bug against dri -> drm(intel) on bugs.freedesktop.org.
> Please add "[ilk bisected]" to the bug summary so it shows up in all the
> right searches for us.

Will do.



dmesg-3.17.6.good.txt.xz
Description: Binary data


dmesg-3.18.bad.txt.xz
Description: Binary data

Re: [Regression] 3.18 black screen after boot (bisected)

[Heinz Diehl]

On 15.12.2014, Daniel Vetter wrote: 

 Can you please boot with drm.debug=0xf on both good and bad kernels and
 then grab dmesg from each?

The output is attached. The dmesg log stops after runlevel 3 for the
3.18 kernel, because I'm not able to do anything in runlevel 5 with a
black screen.

 To make sure we don't forget this please file the above summary plus dmesg
 files as a new bug against dri - drm(intel) on bugs.freedesktop.org.
 Please add [ilk bisected] to the bug summary so it shows up in all the
 right searches for us.

Will do.



dmesg-3.17.6.good.txt.xz
Description: Binary data


dmesg-3.18.bad.txt.xz
Description: Binary data

Re: [Regression] 83f45fc turns machine's screen off

[Heinz Diehl]

On 14.12.2014, Emmanuel Benisty wrote: 

  The following commit permanently turns my screen off when x server is
  started (i3 330M Ironlake):
 
  [83f45fc360c8e16a330474860ebda872d1384c8c] drm: Don't grab an fb
  reference for the idr
 
  Reverting this commit fixed the issue.

Haven't seen your mail until now. Seems to be the same bug that I'm 
encountering.

https://bugs.freedesktop.org/show_bug.cgi?id=87330
https://lkml.org/lkml/2014/12/14/26

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Regression] 3.18 black screen after boot (bisected)

[Heinz Diehl]

Hi,

since kernel 3.18 I'm no longer able to run X on my machine. While
3.17.6 is fine, 3.18 leaves me with a black screen when starting
X. Booting into runlevel 1/3 is fine.

I did a "git bisect", and the offending commit is this one:

[root@kiera linux-git]# git bisect bad
83f45fc360c8e16a330474860ebda872d1384c8c is the first bad commit
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter 
Date:   Wed Aug 6 09:10:18 2014 +0200

drm: Don't grab an fb reference for the idr

[]

I double-checked, and 3.18 is fine with this commit reverted.

My machine is an Asus U45JC laptop, and the CPU is an Intel i450M
(Ironlake). Please contact me if I can help in any way (I'm subscribed
to lkml, but not to other X or kernel related lists).

Thanks,
 Heinz.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Regression] 3.18 black screen after boot (bisected)

[Heinz Diehl]

Hi,

since kernel 3.18 I'm no longer able to run X on my machine. While
3.17.6 is fine, 3.18 leaves me with a black screen when starting
X. Booting into runlevel 1/3 is fine.

I did a git bisect, and the offending commit is this one:

[root@kiera linux-git]# git bisect bad
83f45fc360c8e16a330474860ebda872d1384c8c is the first bad commit
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Wed Aug 6 09:10:18 2014 +0200

drm: Don't grab an fb reference for the idr

[]

I double-checked, and 3.18 is fine with this commit reverted.

My machine is an Asus U45JC laptop, and the CPU is an Intel i450M
(Ironlake). Please contact me if I can help in any way (I'm subscribed
to lkml, but not to other X or kernel related lists).

Thanks,
 Heinz.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new GPG key

[Heinz Diehl]

On 18.10.2014, Paolo Bonzini wrote: 

> 5) Get a smartcard or a Yubikey NEO and put the subkeys on it; replace
> subkeys with stubs on your usual working machines, especially laptops. It
> gives you two factor authentication for free, and can also be used for
> SSH if you add a third subkey.

AFAICS, a lot of the lkml people use the mutt MUA, which does not have
any password encryption natively. In this case, the smartcard
has another advantage: you can have your email password encrypted 
and use it without having to enter a long and complicated passphrase.
In case your laptop gets stolen while travelling, the password to your
email is protected.

Here's what I did:

1. Generate a password file and assign the password to a variable.

touch .my-pw
echo "set my_pw_imap = \"your-long-and-random-password\"" > .my-pw

2. Encrypt this file to your own public key and shred the unencrypted textfile
3. Source the password file into .muttrc and set the imap password
   variable by writing something like this into your .muttrc:

 source "gpg2 -dq $HOME/.my-pw.asc |"
 set imap_pass=$my_pw_imap

Now, if you start mutt and it connects to your IMAP server, you'll be
prompted for your smartcards PIN, and that's it. In case your
laptop gets stolen while you're travelling and you don't have access
to the net (because all the other things in your bag like your mobile 
also got stolen), it will spare you the situation where the thief 
already had logged into your email and changed your password when 
you finally managed to connect to the net again.

Sorry for being OT, but I have encountered such a situation before and
it got me into serious trouble, so I dared to share this with you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new GPG key

[Heinz Diehl]

On 18.10.2014, Paolo Bonzini wrote: 

 5) Get a smartcard or a Yubikey NEO and put the subkeys on it; replace
 subkeys with stubs on your usual working machines, especially laptops. It
 gives you two factor authentication for free, and can also be used for
 SSH if you add a third subkey.

AFAICS, a lot of the lkml people use the mutt MUA, which does not have
any password encryption natively. In this case, the smartcard
has another advantage: you can have your email password encrypted 
and use it without having to enter a long and complicated passphrase.
In case your laptop gets stolen while travelling, the password to your
email is protected.

Here's what I did:

1. Generate a password file and assign the password to a variable.

touch .my-pw
echo set my_pw_imap = \your-long-and-random-password\  .my-pw

2. Encrypt this file to your own public key and shred the unencrypted textfile
3. Source the password file into .muttrc and set the imap password
   variable by writing something like this into your .muttrc:

 source gpg2 -dq $HOME/.my-pw.asc |
 set imap_pass=$my_pw_imap

Now, if you start mutt and it connects to your IMAP server, you'll be
prompted for your smartcards PIN, and that's it. In case your
laptop gets stolen while you're travelling and you don't have access
to the net (because all the other things in your bag like your mobile 
also got stolen), it will spare you the situation where the thief 
already had logged into your email and changed your password when 
you finally managed to connect to the net again.

Sorry for being OT, but I have encountered such a situation before and
it got me into serious trouble, so I dared to share this with you.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nick Krause, Alias: [...]? [joke]

[Heinz Diehl]

On 08.08.2014, el_es wrote: 

> [cut conjecture & indices to B since the person in question denies]

AFAIK, you can claim to be King-Kong in any received line, but you
can't fake the IP in the square brackets, because it gets added by the
mail server *after* you sent the mail.

Feel free to correct me if I'm wrong.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nick Krause, Alias: [...]? [joke]

[Heinz Diehl]

On 08.08.2014, el_es wrote: 

 [cut conjecture  indices to B since the person in question denies]

AFAIK, you can claim to be King-Kong in any received line, but you
can't fake the IP in the square brackets, because it gets added by the
mail server *after* you sent the mail.

Feel free to correct me if I'm wrong.



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Heinz Diehl]

On 06.08.2014, Nick Krause wrote: 

> I am going to have to ask a few questions first, what distribution is
> and is this a vanilla kernel?

Read his mail. He's on Debian, and it's a Debian kernel.

> If it's not just send the report to the distribution developers.

His mail is quite sure a copy from the data entered into the Debian
bugtracker.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: [x86] Running ptpd2 using an Intel 82572EI (e1000e) leads to a kernel oops (3.12.26)

[Heinz Diehl]

On 06.08.2014, Nick Krause wrote: 

 I am going to have to ask a few questions first, what distribution is
 and is this a vanilla kernel?

Read his mail. He's on Debian, and it's a Debian kernel.

 If it's not just send the report to the distribution developers.

His mail is quite sure a copy from the data entered into the Debian
bugtracker.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug on Kernel 3.16 r6: Sound and Buffering in Clementine with Files are Transferring to Music Directory

[Heinz Diehl]

On 28.07.2014, Nick Krause wrote: 

> Then explain to me why this is only happening on recent rc kernels and not
> the Ubuntu distro kernels I was using before. Seems weird that only
> recent rc kernels are triggering this.

The, if you actually can reproduce it with a vanilla kernel (non-
distro) and you're still convinced it must be a bug, you could
consider bisecting the offending patch. Here is how it works:

http://tinyurl.com/yo533k

Good luck!



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug on Kernel 3.16 r6: Sound and Buffering in Clementine with Files are Transferring to Music Directory

[Heinz Diehl]

First: my email you are quoting here was sent to you directly, off-list,
because it only contains common stuff and has nothing to do with
kernel development. In other words to avoid annoying lkml people. 
In addition, I placed an "Reply-to" header pointing back to me. 
Despite, you *manually* redirected your answer to my private mail 
back to the list, thus annoying people and breaking the informational
flow of this thread.


On 27.07.2014, Nick Krause wrote: 

> I am transferring into the same directory for the music 
> I am listening to.

So you produce a lot of disk I/O by writing/reading from the same disk
at the same time, and as you encounter stalls, you take this for a
kernel bug (which clearly is not). These stalls are most probably
caused by fsync() flushing your data/buffers, which is blocking.

So moving the music data you are listening to to another disk would
make things a lot easier.

> In addition , my cpu usage when doing this is half of my older

DMA transfer is mostly done be the controller itself, and not the CPU.

Btw, EOT for me.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug on Kernel 3.16 r6: Sound and Buffering in Clementine with Files are Transferring to Music Directory

[Heinz Diehl]

First: my email you are quoting here was sent to you directly, off-list,
because it only contains common stuff and has nothing to do with
kernel development. In other words to avoid annoying lkml people. 
In addition, I placed an Reply-to header pointing back to me. 
Despite, you *manually* redirected your answer to my private mail 
back to the list, thus annoying people and breaking the informational
flow of this thread.


On 27.07.2014, Nick Krause wrote: 

 I am transferring into the same directory for the music 
 I am listening to.

So you produce a lot of disk I/O by writing/reading from the same disk
at the same time, and as you encounter stalls, you take this for a
kernel bug (which clearly is not). These stalls are most probably
caused by fsync() flushing your data/buffers, which is blocking.

So moving the music data you are listening to to another disk would
make things a lot easier.

 In addition , my cpu usage when doing this is half of my older

DMA transfer is mostly done be the controller itself, and not the CPU.

Btw, EOT for me.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug on Kernel 3.16 r6: Sound and Buffering in Clementine with Files are Transferring to Music Directory

[Heinz Diehl]

On 28.07.2014, Nick Krause wrote: 

 Then explain to me why this is only happening on recent rc kernels and not
 the Ubuntu distro kernels I was using before. Seems weird that only
 recent rc kernels are triggering this.

The, if you actually can reproduce it with a vanilla kernel (non-
distro) and you're still convinced it must be a bug, you could
consider bisecting the offending patch. Here is how it works:

http://tinyurl.com/yo533k

Good luck!



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to disable Lazy Preempt in the kernel

[Heinz Diehl]

On 19.06.2014, tdjames wrote: 

> How do I disable lazy preempt?

echo NO_PREEMPT_LAZY >/sys/kernel/debug/sched_features

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to disable Lazy Preempt in the kernel

[Heinz Diehl]

On 19.06.2014, tdjames wrote: 

 How do I disable lazy preempt?

echo NO_PREEMPT_LAZY /sys/kernel/debug/sched_features

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with cpufreq and i5 since post 3.9.0

[Heinz Diehl]

On 27.12.2013, David Woodfall wrote: 

> But any of the newer kernel versions I've tested only give me
> performance and powersave.

I don't use any Fedora kernel, so I can't tell which governors are
enabled in those. You should check the value of "CONFIG_CPU_FREQ_GOV"
in the respective .config file for your installed kernel.

In short: It seems that only "performance" and "powersave" are
compiled in.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with cpufreq and i5 since post 3.9.0

[Heinz Diehl]

On 27.12.2013, David Woodfall wrote: 

 But any of the newer kernel versions I've tested only give me
 performance and powersave.

I don't use any Fedora kernel, so I can't tell which governors are
enabled in those. You should check the value of CONFIG_CPU_FREQ_GOV
in the respective .config file for your installed kernel.

In short: It seems that only performance and powersave are
compiled in.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in xhci_free_dev

[Heinz Diehl]

On 26.07.2013, Sarah Sharp wrote: 

> Heinz and Frantisek,
> I believe your issue should be fixed by this patch:
> 
> http://marc.info/?l=linux-usb=137476546506888=2
> 
> Please let me know if it doesn't.

Thanks a lot, it does fix it for me.

Heinz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in xhci_free_dev

[Heinz Diehl]

On 26.07.2013, Sarah Sharp wrote: 

 Heinz and Frantisek,
 I believe your issue should be fixed by this patch:
 
 http://marc.info/?l=linux-usbm=137476546506888w=2
 
 Please let me know if it doesn't.

Thanks a lot, it does fix it for me.

Heinz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10.0: Full dynticks = high load

[Heinz Diehl]

On 11.07.2013, Dâniel Fraga wrote: 

>   I upgraded to kernel 3.10.0 and decided to try the new "Full
> dynticks system (tickless)" option, but now the system load is always
> at 1 or above.
> 
>   Using the previous "Idle dynticks system (tickless idle)" solves
> the problem, so it seems the new Full dynticks code is causing this.
> 

This describes exactly what I have encountered, and "tickless idle"
fixed it for me, too. So I'll second that.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10.0: Full dynticks = high load

[Heinz Diehl]

On 11.07.2013, Dâniel Fraga wrote: 

   I upgraded to kernel 3.10.0 and decided to try the new Full
 dynticks system (tickless) option, but now the system load is always
 at 1 or above.
 
   Using the previous Idle dynticks system (tickless idle) solves
 the problem, so it seems the new Full dynticks code is causing this.
 

This describes exactly what I have encountered, and tickless idle
fixed it for me, too. So I'll second that.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in xhci_free_dev

[Heinz Diehl]

On 11.05.2013, Frantisek Hrbata wrote: 

> I haven't tried to reproduce. I was asked to help with Fedora's bugs triage 
> and
> these come up. The goal was just to contact the right people and bring this to
> their attention. If you have a patch for this, I guess we can try to ask 
> Heinz,
> or other people reporting this problem, to help with testing.

I'm willing to help, of course. I'll try to install latest 3.9 on the
machine this bug occurs and see if I manage to reproduce it. As far as
I remember, it happened when I changed some USB 2.0 devices on an USB
3 port. The machine is re-installed and runs F18 now.
 
> Heinz: Sorry I forgot to add you to CC in the first mail, but Sarah fixed it.

Never mind, I'm subscribed to lkml and saw the thread there ;-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NULL pointer dereference in xhci_free_dev

[Heinz Diehl]

On 11.05.2013, Frantisek Hrbata wrote: 

 I haven't tried to reproduce. I was asked to help with Fedora's bugs triage 
 and
 these come up. The goal was just to contact the right people and bring this to
 their attention. If you have a patch for this, I guess we can try to ask 
 Heinz,
 or other people reporting this problem, to help with testing.

I'm willing to help, of course. I'll try to install latest 3.9 on the
machine this bug occurs and see if I manage to reproduce it. As far as
I remember, it happened when I changed some USB 2.0 devices on an USB
3 port. The machine is re-installed and runs F18 now.
 
 Heinz: Sorry I forgot to add you to CC in the first mail, but Sarah fixed it.

Never mind, I'm subscribed to lkml and saw the thread there ;-)

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm intel fixes

[Heinz Diehl]

On 11.01.2013, Dave Airlie wrote: 

> Just intel fixes, including getting the Ironlake systems back to the state 
> they were in for 3.6.

>   drm/i915: Revert shrinker changes from "Track unbound pages"

I guess it's this one which fixes the ILK hang. Would it be enough for
3.7 to just appy this patch to get the problem fixed?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm intel fixes

[Heinz Diehl]

On 11.01.2013, Dave Airlie wrote: 

 Just intel fixes, including getting the Ironlake systems back to the state 
 they were in for 3.6.

   drm/i915: Revert shrinker changes from Track unbound pages

I guess it's this one which fixes the ILK hang. Would it be enough for
3.7 to just appy this patch to get the problem fixed?

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915: GPU hang

[Heinz Diehl]

On 30.12.2012, Guennadi Liakhovetski wrote: 

> Did that and it did work for a while, longer than the average with 3.5. I 
> was already about to write a success report, but then it hung again 
> yesterday. I'm not using this laptop very intensively, so, it is hard to 
> collect statistics.

You could try to reproduce the error by writing a big file e.g.

 dd if=/dev/zero of=deleteme bs=1M count=8

or similar and watching high definition video on Youtube (1080p) or running a 
few
instances of glxgears. That triggers a gpu hang in my case after
just a couple of seconds.

In my case, the hang doesn't occur when using SNA (or a kernel < 3.7,
which isn't the case with your bug). I have this in my
xorg.conf:

Section "Device"
   Identifier "Card0"
   Driver "intel"
   Option "AccelMethod" "SNA"
EndSection

Without this, every 3.7 kernel produces a gpu hang within max. 1 min.

 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915: GPU hang

[Heinz Diehl]

On 30.12.2012, Guennadi Liakhovetski wrote: 

 Did that and it did work for a while, longer than the average with 3.5. I 
 was already about to write a success report, but then it hung again 
 yesterday. I'm not using this laptop very intensively, so, it is hard to 
 collect statistics.

You could try to reproduce the error by writing a big file e.g.

 dd if=/dev/zero of=deleteme bs=1M count=8

or similar and watching high definition video on Youtube (1080p) or running a 
few
instances of glxgears. That triggers a gpu hang in my case after
just a couple of seconds.

In my case, the hang doesn't occur when using SNA (or a kernel  3.7,
which isn't the case with your bug). I have this in my
xorg.conf:

Section Device
   Identifier Card0
   Driver intel
   Option AccelMethod SNA
EndSection

Without this, every 3.7 kernel produces a gpu hang within max. 1 min.

 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf/x86: Enable Intel Lincroft/Penwell/Cloverview Atom support

[Heinz Diehl]

On 28.12.2012, shuox@intel.com wrote: 

>   case 54: /* Cedariew */
 ^
Just a typo, but while you're at it..

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf/x86: Enable Intel Lincroft/Penwell/Cloverview Atom support

[Heinz Diehl]

On 28.12.2012, shuox@intel.com wrote: 

   case 54: /* Cedariew */
 ^
Just a typo, but while you're at it..

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915: GPU hang

[Heinz Diehl]

On 17.12.2012, Guennadi Liakhovetski wrote: 

> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm] capturing error event; look for more information in 
> /debug/dri/0/i915_error_state
> [drm:i915_reset] *ERROR* Failed to reset chip.

I have the same problem, are able to reproduce it and have bisected
it, but the commit which git --bisect identified seems not to be the
cause.

root@wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson 
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages


This is a quite nasty (3.7) regression. I have it on all of my three
machines and it drives me mad (3.6.x hangs my USB 3.0 port and 3.7 my
intel graphics).

Try to boot with "i915.i915_enable_rc6=0" and switch to SNA in your
Xorg.conf:

Section "Device"
   Identifier "Card0"
   Driver "intel"
   Option "AccelMethod" "SNA"
EndSection

There are tons of this "GPU hangcheck timer elapsed"
messages on the net...

Good luck!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915: GPU hang

[Heinz Diehl]

On 17.12.2012, Guennadi Liakhovetski wrote: 

 [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
 [drm] capturing error event; look for more information in 
 /debug/dri/0/i915_error_state
 [drm:i915_reset] *ERROR* Failed to reset chip.

I have the same problem, are able to reproduce it and have bisected
it, but the commit which git --bisect identified seems not to be the
cause.

root@wildsau linux-git]# git bisect good
6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit
commit 6c085a728cf000ac1865d66f8c9b52935558b328
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages


This is a quite nasty (3.7) regression. I have it on all of my three
machines and it drives me mad (3.6.x hangs my USB 3.0 port and 3.7 my
intel graphics).

Try to boot with i915.i915_enable_rc6=0 and switch to SNA in your
Xorg.conf:

Section Device
   Identifier Card0
   Driver intel
   Option AccelMethod SNA
EndSection

There are tons of this GPU hangcheck timer elapsed
messages on the net...

Good luck!

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[3.6.10] Null pointer dereference (xhci)

[Heinz Diehl]

Hi,

I'm getting this regularly with 3.6.10. The machine is new installed,
so I don't know if any version before 3.6.10 worked allright. 

Dec 14 22:39:03 nala kernel: [ 1388.792044] xhci_hcd :03:00.0: Timeout 
while waiting for address device command
Dec 14 22:39:03 nala kernel: [ 1399.776824] usb 3-1: Device not responding to 
set address.
Dec 14 22:39:04 nala kernel: [ 1399.977529] usb 3-1: device not accepting 
address 2, error -71
Dec 14 22:39:25 nala kernel: [ 1404.971070] xhci_hcd :03:00.0: Timeout 
while waiting for a slot
Dec 14 22:39:25 nala kernel: [ 1419.875430] [ cut here
]
Dec 14 22:39:25 nala kernel: [ 1419.875438] WARNING: at kernel/watchdog.c:242 
watchdog_overflow_callback+0x9a/0xc0()
Dec 14 22:39:25 nala kernel: [ 1419.875439] Hardware name: K53E
Dec 14 22:39:25 nala kernel: [ 1419.875440] Watchdog detected hard LOCKUP on 
cpu 0
Dec 14 22:39:25 nala kernel: [ 1419.875441] Modules linked in: rfcomm
fuse lockd sunrpc bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
nf_conntrack snd_hda_codec_hdmi snd_hda_codec_realtek arc4 iwldvm
mac80211 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core
videodev media coretemp snd_hda_intel kvm_intel iTCO_wdt
iTCO_vendor_support tcp_veno asus_nb_wmi asus_wmi sparse_keymap
snd_hda_codec btusb kvm crc32c_intel ghash_clmulni_intel microcode
joydev snd_hwdep serio_raw pcspkr bluetooth snd_seq i2c_i801 lpc_ich
mfd_core snd_seq_device iwlwifi snd_pcm atl1c snd_page_alloc snd_timer
cfg80211 snd uinput soundcore rfkill mei wmi xfs usb_storage i915
video i2c_algo_bit drm_kms_helper drm i2c_core
Dec 14 22:39:25 nala kernel: [ 1419.875484] Pid: 41, comm: khubd Not tainted 
3.6.10 #1
Dec 14 22:39:25 nala kernel: [ 1419.875485] Call Trace:
Dec 14 22:39:25 nala kernel: [ 1419.875486]   [] 
warn_slowpath_common+0x7f/0xc0
Dec 14 22:39:25 nala kernel: [ 1419.875493]  [] 
warn_slowpath_fmt+0x46/0x50
Dec 14 22:39:25 nala kernel: [ 1419.875496]  [] ? 
touch_nmi_watchdog+0x80/0x80
Dec 14 22:39:25 nala kernel: [ 1419.875498]  [] 
watchdog_overflow_callback+0x9a/0xc0
Dec 14 22:39:25 nala kernel: [ 1419.875501]  [] 
__perf_event_overflow+0x9d/0x230
Dec 14 22:39:25 nala kernel: [ 1419.875505]  [] 
?x86_perf_event_set_period+0xd7/0x160Dec 14 22:39:25  nala kernel:  
1419.875507]  []
perf_event_overflow+0x14/0x20 
Dec 14 22:39:25 nala kernel: [ 1419.875509]  [] 
intel_pmu_handle_irq+0x193/0x310
Dec 14 22:39:25 nala kernel: [ 1419.875513]  [] 
perf_event_nmi_handler+0x1d/0x20
Dec 14 22:39:25 nala kernel: [ 1419.875515]  [] 
nmi_handle.isra.1+0x59/0x90
Dec 14 22:39:25 nala kernel: [ 1419.875518]  [] 
do_nmi+0x169/0x350
Dec 14 22:39:25 nala kernel: [ 1419.875520]  [] 
end_repeat_nmi+0x1e/0x2e
Dec 14 22:39:25 nala kernel: [ 1419.875523]  [] ? 
handshake+0x24/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875525]  [] ? 
handshake+0x24/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875528]  [] ? 
handshake+0x24/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875529]  <> [] 
xhci_cancel_cmd+0x13b/0x1d0
Dec 14 22:39:25 nala kernel: [ 1419.875533]  [] 
xhci_alloc_dev+0x19b/0x1f0
Dec 14 22:39:25 nala kernel: [ 1419.875536]  [] 
usb_alloc_dev+0x7c/0x320
Dec 14 22:39:25 nala kernel: [ 1419.875539]  [] ? 
kobject_put+0x2b/0x60
Dec 14 22:39:25 nala kernel: [ 1419.875542]  [] 
hub_thread+0x783/0x16d0
Dec 14 22:39:25 nala kernel: [ 1419.875545]  [] ? 
wake_up_bit+0x40/0x40
Dec 14 22:39:25 nala kernel: [ 1419.875547]  [] ? 
usb_remote_wakeup+0x70/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875549]  [] 
kthread+0x93/0xa0
Dec 14 22:39:25 nala kernel: [ 1419.875552]  [] 
kernel_thread_helper+0x4/0x10
Dec 14 22:39:25 nala kernel: [ 1419.875554]  [] ? 
kthread_create_on_node+0x120/0x120
Dec 14 22:39:25 nala kernel: [ 1419.875556]  [] ? 
gs_change+0x13/0x13
Dec 14 22:39:25 nala kernel: [ 1419.875557] ---[ end trace 6ca2082d20e938b5 ]---
Dec 14 22:39:25 nala kernel: [ 1421.139050] xhci_hcd :03:00.0: Stopped the 
command ring failed, maybe the host is dead
Dec 14 22:39:25 nala kernel: [ 1421.139068] xhci_hcd :03:00.0: Abort 
command ring failed
Dec 14 22:39:25 nala kernel: [ 1421.139477] xhci_hcd :03:00.0: HC died; 
cleaning up
Dec 14 22:39:25 nala kernel: [ 1421.139489] hub 3-0:1.0: cannot reset port 1 
(err = -19)
Dec 14 22:39:25 nala kernel: [ 1421.139492] hub 3-0:1.0: cannot disable port 1 
(err = -19)
Dec 14 22:39:25 nala kernel: [ 1421.139507] BUG: unable to handle kernel NULL 
pointer dereference at 0040
Dec 14 22:39:25 nala kernel: [ 1421.140733] IP: [] 
xhci_free_dev+0x63/0x160
Dec 14 22:39:25 nala kernel: [ 1421.141276] PGD 1e7665067 PUD 1e7664067 PMD 0 
Dec 14 22:39:25 nala kernel: [ 1421.141801] Oops: 0002 [#1] PREEMPT SMP 
Dec 14 22:39:25 nala kernel: [ 1421.142346] Modules linked in: rfcomm
fuse lockd sunrpc bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
nf_conntrack snd_hda_codec_hdmi snd_hda_codec_realtek 

[3.6.10] Null pointer dereference (xhci)

[Heinz Diehl]

Hi,

I'm getting this regularly with 3.6.10. The machine is new installed,
so I don't know if any version before 3.6.10 worked allright. 

Dec 14 22:39:03 nala kernel: [ 1388.792044] xhci_hcd :03:00.0: Timeout 
while waiting for address device command
Dec 14 22:39:03 nala kernel: [ 1399.776824] usb 3-1: Device not responding to 
set address.
Dec 14 22:39:04 nala kernel: [ 1399.977529] usb 3-1: device not accepting 
address 2, error -71
Dec 14 22:39:25 nala kernel: [ 1404.971070] xhci_hcd :03:00.0: Timeout 
while waiting for a slot
Dec 14 22:39:25 nala kernel: [ 1419.875430] [ cut here
]
Dec 14 22:39:25 nala kernel: [ 1419.875438] WARNING: at kernel/watchdog.c:242 
watchdog_overflow_callback+0x9a/0xc0()
Dec 14 22:39:25 nala kernel: [ 1419.875439] Hardware name: K53E
Dec 14 22:39:25 nala kernel: [ 1419.875440] Watchdog detected hard LOCKUP on 
cpu 0
Dec 14 22:39:25 nala kernel: [ 1419.875441] Modules linked in: rfcomm
fuse lockd sunrpc bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
nf_conntrack snd_hda_codec_hdmi snd_hda_codec_realtek arc4 iwldvm
mac80211 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core
videodev media coretemp snd_hda_intel kvm_intel iTCO_wdt
iTCO_vendor_support tcp_veno asus_nb_wmi asus_wmi sparse_keymap
snd_hda_codec btusb kvm crc32c_intel ghash_clmulni_intel microcode
joydev snd_hwdep serio_raw pcspkr bluetooth snd_seq i2c_i801 lpc_ich
mfd_core snd_seq_device iwlwifi snd_pcm atl1c snd_page_alloc snd_timer
cfg80211 snd uinput soundcore rfkill mei wmi xfs usb_storage i915
video i2c_algo_bit drm_kms_helper drm i2c_core
Dec 14 22:39:25 nala kernel: [ 1419.875484] Pid: 41, comm: khubd Not tainted 
3.6.10 #1
Dec 14 22:39:25 nala kernel: [ 1419.875485] Call Trace:
Dec 14 22:39:25 nala kernel: [ 1419.875486]  NMI [8105e60f] 
warn_slowpath_common+0x7f/0xc0
Dec 14 22:39:25 nala kernel: [ 1419.875493]  [8105e706] 
warn_slowpath_fmt+0x46/0x50
Dec 14 22:39:25 nala kernel: [ 1419.875496]  [810eb450] ? 
touch_nmi_watchdog+0x80/0x80
Dec 14 22:39:25 nala kernel: [ 1419.875498]  [810eb4ea] 
watchdog_overflow_callback+0x9a/0xc0
Dec 14 22:39:25 nala kernel: [ 1419.875501]  [8112868d] 
__perf_event_overflow+0x9d/0x230
Dec 14 22:39:25 nala kernel: [ 1419.875505]  [81026867] 
?x86_perf_event_set_period+0xd7/0x160Dec 14 22:39:25  nala kernel:  
1419.875507]  [81129344]
perf_event_overflow+0x14/0x20 
Dec 14 22:39:25 nala kernel: [ 1419.875509]  [8102be53] 
intel_pmu_handle_irq+0x193/0x310
Dec 14 22:39:25 nala kernel: [ 1419.875513]  [81633b6d] 
perf_event_nmi_handler+0x1d/0x20
Dec 14 22:39:25 nala kernel: [ 1419.875515]  [816332b9] 
nmi_handle.isra.1+0x59/0x90
Dec 14 22:39:25 nala kernel: [ 1419.875518]  [81633459] 
do_nmi+0x169/0x350
Dec 14 22:39:25 nala kernel: [ 1419.875520]  [816328c0] 
end_repeat_nmi+0x1e/0x2e
Dec 14 22:39:25 nala kernel: [ 1419.875523]  [8146ca14] ? 
handshake+0x24/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875525]  [8146ca14] ? 
handshake+0x24/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875528]  [8146ca14] ? 
handshake+0x24/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875529]  EOE [8147641b] 
xhci_cancel_cmd+0x13b/0x1d0
Dec 14 22:39:25 nala kernel: [ 1419.875533]  [8147036b] 
xhci_alloc_dev+0x19b/0x1f0
Dec 14 22:39:25 nala kernel: [ 1419.875536]  [8143acdc] 
usb_alloc_dev+0x7c/0x320
Dec 14 22:39:25 nala kernel: [ 1419.875539]  [812e5e6b] ? 
kobject_put+0x2b/0x60
Dec 14 22:39:25 nala kernel: [ 1419.875542]  [81441433] 
hub_thread+0x783/0x16d0
Dec 14 22:39:25 nala kernel: [ 1419.875545]  [81082dd0] ? 
wake_up_bit+0x40/0x40
Dec 14 22:39:25 nala kernel: [ 1419.875547]  [81440cb0] ? 
usb_remote_wakeup+0x70/0x70
Dec 14 22:39:25 nala kernel: [ 1419.875549]  [810828e3] 
kthread+0x93/0xa0
Dec 14 22:39:25 nala kernel: [ 1419.875552]  [8163a1c4] 
kernel_thread_helper+0x4/0x10
Dec 14 22:39:25 nala kernel: [ 1419.875554]  [81082850] ? 
kthread_create_on_node+0x120/0x120
Dec 14 22:39:25 nala kernel: [ 1419.875556]  [8163a1c0] ? 
gs_change+0x13/0x13
Dec 14 22:39:25 nala kernel: [ 1419.875557] ---[ end trace 6ca2082d20e938b5 ]---
Dec 14 22:39:25 nala kernel: [ 1421.139050] xhci_hcd :03:00.0: Stopped the 
command ring failed, maybe the host is dead
Dec 14 22:39:25 nala kernel: [ 1421.139068] xhci_hcd :03:00.0: Abort 
command ring failed
Dec 14 22:39:25 nala kernel: [ 1421.139477] xhci_hcd :03:00.0: HC died; 
cleaning up
Dec 14 22:39:25 nala kernel: [ 1421.139489] hub 3-0:1.0: cannot reset port 1 
(err = -19)
Dec 14 22:39:25 nala kernel: [ 1421.139492] hub 3-0:1.0: cannot disable port 1 
(err = -19)
Dec 14 22:39:25 nala kernel: [ 1421.139507] BUG: unable to handle kernel NULL 
pointer dereference at 0040
Dec 14 22:39:25 nala kernel: [ 1421.140733] IP: [81470c13] 

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 06.12.2012, Heinz Diehl wrote: 

[]

Ok, the last one for today. After extensive testing with heavy load
and I/O while watching HD videos, I can almost safely conclude with 
the following:

1.) The hang does *never* occur with 3.6.9 vanilla 

2.) The hang does *always* occur with 3.7-rc8+ / latest git

3.) The hang doesn't occur with 3.7/latest git when 

 Driver "Intel"
 Options "NoAccel" "True" 

in Xorg.xonf is set (with all the drawbacks this introduces). Maybe
this rings a bell for someone..

In all cases, the machine is booted with "i915.i915_enable_rc6=0".

Please contact me if you think I can help to debug this further.

Thanks,
Heinz.






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 06.12.2012, Heinz Diehl wrote: 

[]

Here are some more error-logs, inkl. dmesg after booting with drm
debug options turned on:

http://www.fritha.org/i915/gpu-hang.tar.bz2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 04.12.2012, Daniel Vetter wrote: 

> Yeah, if anyone can somewhat reliably reproduce this

While writing a big file with dd and watching high resolution videos
on youtube, I've managed to reproduce the hang. Unfortunately, it
doesn't occur within seconds. Some playing around is neccessary, and
it takes between 30 sec. and 20 min.

> > Btw: which kernel is known to be the "last good one"?

> If it's the ilk one we only know that 3.6.x series seems to be solid, and
> something in 3.7-rc (probably before -rc1) broke stuff. So not too useful.

I tried 3.6.9 several times over a few hours and could not trigger the
hang, which clearly adds evidence to this statement. I don't want to
scream out too loud, but 3.6.9 seems not to be affected. Will try
some more hours to get a 3.6.9 box to hang, though.. Just in case..

Heinz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 05.12.2012, Daniel Vetter wrote:

> Nope, we could only reproduce quickly with rc6 enabled :(

Could reproduce it today this way:

 dd if=/dev/zero of=deleteme bs=1M count=5

while watching several HD videos on Youtube. Just tried once, so I'm
not shure if this will work all the way. Will try again now.

My "i915_error_state" is here:

http://www.fritha.org/i915/error-01.tar.bz2

Heinz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 05.12.2012, Daniel Vetter wrote:

 Nope, we could only reproduce quickly with rc6 enabled :(

Could reproduce it today this way:

 dd if=/dev/zero of=deleteme bs=1M count=5

while watching several HD videos on Youtube. Just tried once, so I'm
not shure if this will work all the way. Will try again now.

My i915_error_state is here:

http://www.fritha.org/i915/error-01.tar.bz2

Heinz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 04.12.2012, Daniel Vetter wrote: 

 Yeah, if anyone can somewhat reliably reproduce this

While writing a big file with dd and watching high resolution videos
on youtube, I've managed to reproduce the hang. Unfortunately, it
doesn't occur within seconds. Some playing around is neccessary, and
it takes between 30 sec. and 20 min.

  Btw: which kernel is known to be the last good one?

 If it's the ilk one we only know that 3.6.x series seems to be solid, and
 something in 3.7-rc (probably before -rc1) broke stuff. So not too useful.

I tried 3.6.9 several times over a few hours and could not trigger the
hang, which clearly adds evidence to this statement. I don't want to
scream out too loud, but 3.6.9 seems not to be affected. Will try
some more hours to get a 3.6.9 box to hang, though.. Just in case..

Heinz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 06.12.2012, Heinz Diehl wrote: 

[]

Here are some more error-logs, inkl. dmesg after booting with drm
debug options turned on:

http://www.fritha.org/i915/gpu-hang.tar.bz2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 06.12.2012, Heinz Diehl wrote: 

[]

Ok, the last one for today. After extensive testing with heavy load
and I/O while watching HD videos, I can almost safely conclude with 
the following:

1.) The hang does *never* occur with 3.6.9 vanilla 

2.) The hang does *always* occur with 3.7-rc8+ / latest git

3.) The hang doesn't occur with 3.7/latest git when 

 Driver Intel
 Options NoAccel True 

in Xorg.xonf is set (with all the drawbacks this introduces). Maybe
this rings a bell for someone..

In all cases, the machine is booted with i915.i915_enable_rc6=0.

Please contact me if you think I can help to debug this further.

Thanks,
Heinz.






--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 05.12.2012, Lekensteyn wrote:

> > I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
> > compositor. Now I'm trying to hit the bug again...

> Do you have a reliable reproduce method? As you can see in the linked bug it
> was caused by relatively low memory pressure combined with high I/O (caching?
> delays? Who knows).

No, unfortunately not. I will do my very best to find out how to
trigger it. For   now, I'm trying with a script which produces
max. I/O. Will also try by replaying a lot of high resolution videos and
similar.

> It is unlikely that Optimus has anything to do with this.

Ok.

Heinz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 04.12.2012, Daniel Vetter wrote: 

> The important part is to not enable rc6 (on ironlake at least) when
> bisecting.

A shot in the dark: could it be that all the machines wich encounter
this hang have nvidia's optimus? Mine has. Could that somehow be
related? (I'm by no means a programmer or a kernel hacker..).




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 04.12.2012, Lekensteyn wrote: 

> As mentioned in the linked bug [1], I bisected it to:
> 
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson 
> Date:   Thu Aug 23 13:12:52 2012 +0100
> 
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable

Ok, but in comment 11 in the same thread you mention that reverting
this patch didn't fix the issue for you:

"Reverting that commit on top of 3.7-rc4 did not fix the hang issue."

> i5-420M is not SB, but ILK. i5-2xxx is SB. I have a i5-460M myself. 

Yes, you're right, my bad! Don't know what I was thinking as I wrote that. I
don't have any i5-420M either, but an i5-450M. It was clearly not my
day..

[htd@wildsau ~]$ cat /proc/cpuinfo | grep model
model: 37
model name   : Intel(R) Core(TM) i5 CPU   M 450  @ 2.40GHz
[]

> i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you 
> probably hit another bug.

I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
compositor. Now I'm trying to hit the bug again...

Heinz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 04.12.2012, Daniel Vetter wrote: 

> Yeah, if anyone can somewhat reliably reproduce this

Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing absolutely nothing.

I'll try around a little bit and see if I can find something that
triggers this hang. 

Btw: which kernel is known to be the "last good one"?

> (you need to disable rc6 on ilk to not hit another issue which seems much 
> easier to
> hit) 

Ilk? If this stands for "Ironlake": I'm on Sandybridge.

> and bisect it, this would be _very_ much appreciated - we've
> pretty much tested all possible "disable stuff" and "revert random
> patch" we could thing of, and we can't reproduce these hangs no matter
> how hard we bang our heads against this.

Bisecting will be a pain without being able to reproduce
the hang reliably.

> Atm we're trying to come up with ways to dump more debug
> information, >but with no clue whatsoever what's going on that's slow-going.

Is there anything at the moment I can do to help you to get a grip on
this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus
U45-JC). 

Heinz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 03.12.2012, devendra.aaru wrote: 

> Add more CC's

Thanks!

This is a real showstopper for me, it occurs in every session now. 
Booting with "i915.i915_enable_rc6=0" doesn't help either..

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 03.12.2012, devendra.aaru wrote: 

 Add more CC's

Thanks!

This is a real showstopper for me, it occurs in every session now. 
Booting with i915.i915_enable_rc6=0 doesn't help either..

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 04.12.2012, Daniel Vetter wrote: 

 Yeah, if anyone can somewhat reliably reproduce this

Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing absolutely nothing.

I'll try around a little bit and see if I can find something that
triggers this hang. 

Btw: which kernel is known to be the last good one?

 (you need to disable rc6 on ilk to not hit another issue which seems much 
 easier to
 hit) 

Ilk? If this stands for Ironlake: I'm on Sandybridge.

 and bisect it, this would be _very_ much appreciated - we've
 pretty much tested all possible disable stuff and revert random
 patch we could thing of, and we can't reproduce these hangs no matter
 how hard we bang our heads against this.

Bisecting will be a pain without being able to reproduce
the hang reliably.

 Atm we're trying to come up with ways to dump more debug
 information, but with no clue whatsoever what's going on that's slow-going.

Is there anything at the moment I can do to help you to get a grip on
this problem? My machine is a Core i5-420M laptop with 4GB RAM (Asus
U45-JC). 

Heinz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 freakout with latest 3.7 git

[Heinz Diehl]

On 04.12.2012, Lekensteyn wrote: 

 As mentioned in the linked bug [1], I bisected it to:
 
 commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Thu Aug 23 13:12:52 2012 +0100
 
 drm/i915: Use cpu relocations if the object is in the GTT but not mappable

Ok, but in comment 11 in the same thread you mention that reverting
this patch didn't fix the issue for you:

Reverting that commit on top of 3.7-rc4 did not fix the hang issue.

 i5-420M is not SB, but ILK. i5-2xxx is SB. I have a i5-460M myself. 

Yes, you're right, my bad! Don't know what I was thinking as I wrote that. I
don't have any i5-420M either, but an i5-450M. It was clearly not my
day..

[htd@wildsau ~]$ cat /proc/cpuinfo | grep model
model: 37
model name   : Intel(R) Core(TM) i5 CPU   M 450  @ 2.40GHz
[]

 i915.i915_enable_rc6=0 worked for me, if it does not work for you, then you 
 probably hit another bug.

I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
compositor. Now I'm trying to hit the bug again...

Heinz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/