On 02.08.2012 18:56, Marcin Slusarz wrote:
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
I have managed to turn the crash into a WARN_ON, by adding this to the
begin of nouveau_software_vblank():
if (!psw) {
WARN_ON(1);
return
To me this looks like an issue with swap. Can you try without swap
(swapoff)?
Ortwin
--
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
On 08.11.2012 14:28, Luming Yu wrote:
As I just noticed that I couldn't quit from mutt due to tmpfs is full.
That's also pointing towards high memory pressure.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 08.11.2012 15:14, Luming Yu wrote:
hmmmake sens? maybe we can't use tmp-on-tmpfs feature in f18
but why not having disk to backup tmpfs under memory pressure?
It should. tmpfs should use all available RAM+swap. But then I guess you
have no swap, and the kernel simply is desperately
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
has not been applied (yet?).
After applying your patch, it still
On 29.07.2012 22:15, Marcin Slusarz wrote:
No, the real problem is: with noaccel we don't register software engine,
but vblank ISR relies on its existance and happily derefences NULL pointer.
Now, this patch should fix it for real...
Unfortunately I am still seeing the crash. Without noaccel
Yes, as far as I can tell. I didn't do anything different this time. The date
on the kernel file looks ok. Just did a fresh make make install again, and
got the same behaviour. When is that number after the hash sign upped?
Marcin Slusarz marcin.slus...@gmail.com wrote:
Are you sure you boot
NB: still broken in 3.5 as well.
Signed-off-by: Ortwin Glück o...@odi.ch
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
The LMS daemon expects a /sys/modules/mei/version file with, a four
digit version number.
see
http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
Signed-off-by: Ortwin Glück o...@odi.ch
---
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
On 07/10/2012 05:28 PM, Alan Cox wrote:
On Tue, 10 Jul 2012 12:10:27 +0200
Ortwin Glücko...@odi.ch wrote:
The LMS daemon expects a /sys/modules/mei/version file with, a four
digit version number.
see
http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
Hi,
My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with
3.4. Bisected to the following commit:
20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit
commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e
Author: Ben Skeggs bske...@redhat.com
Date: Mon Apr 30 11:33:43
On 24.07.2012 19:00, Marcin Slusarz wrote:
Please post the crash log.
Sorry, I was not precise: it boots until drm performs modesetting (so it
seems). The screen goes black and the machine is dead. So there is
nothing I could post here, unfortunately.
This is a video of 3.5 booting:
Does it work if you boot without X and modprobe nouveau manually? If it does,
can you disable page flipping in xorg.conf (Option PageFlip 0 in nouveau
device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
Does it work if you disable acceleration
Support battery capacity on another Apple wireless
keyboard.
NB: most likely all other APPLE_ALU_WIRELESS_*
keyboards should be added as well.
Signed-off-by: Ortwin Glück o...@odi.ch
---
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5301006..b2ae097 100644
--- a/drivers
Support battery capacity on another Apple wireless
keyboard.
NB: most likely all other APPLE_ALU_WIRELESS_*
keyboards should be added as well.
Cc: stable at kernel.org
Signed-off-by: Ortwin Glück o...@odi.ch
---
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5301006
Work around a crash during boot if noaccel is set.
NB: still broken in 3.5 as well, used to work in 3.4. Why are people
ignoring this? It's a regression!
Signed-off-by: Ortwin Glück o...@odi.ch
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
Hi,
My Samsung ultrabook hangs when suspending to RAM since this commit (bisected).
Disabling wifi before suspend works around the issue. All works fine with 3.9.y.
12e7f517029dad819c45eca9ca01fdb9ba57616b
Author: Stanislaw Gruszka sgrus...@redhat.com
Date: Thu Feb 28 10:55:26 2013
On 16.07.2013 08:56, Stanislaw Gruszka wrote:
Apparently this commit changed suspend procedure on mac80211, but it's
not obvious for me why it hangs :-(
Hangs are hard :-) It just sits there with a black screen and a white
cursor in the top left corner...
What is your user space
Without NetworkManager, no X, on console and with plain jane wpa_supplicant I do
echo mem /sys/power state
After that, it still responds to keyboard events: I can switch VT and type on
the consoles, but I can not login on a different VT (pressing Enter after the
username doesn't return). So I
On 19.07.2013 14:08, Stanislaw Gruszka wrote:
Does crash happen on any suspend or on second one ?
The crash always happens on the first suspend.
Thanks for the patch, I will send results tonight.
Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On 02/13/2014 01:01 AM, Hannes Frederic Sowa wrote:
Could you try either dropwatch or perf script net_dropmonitor and flood the
network with the problematic packets. From the traces we could see where the
packets get dropped without notification in the kernel.
Not much to see, unfortunately.
Hi,
I am using Openswan to configure an IPSec VPN (using the xfrm/netkey
backend). Large HTTP POST requests from the client seem to get stuck,
because the outgoing packets are 1530 bytes (before being wrapped into
ESP packets). The problem goes away by setting sysctl
On 02/11/2014 03:32 AM, Hannes Frederic Sowa wrote:
net.ipv4.ip_no_pmtu_disc=1.
This setting will shrink the path mtu to min_pmtu when a frag needed icmp is
received.
The UDP+ESP encapsulation adds 60 bytes to the original packet size.
ifconfig wla0 shows an mtu of 1500.
The size of the
The next commit on that file:
3a768d04639307db Merge branch 'spear/multiplatform' into next/multiplatform
easy to see with this:
gitk v3.13 arch/arm/Kconfig
Cheers,
Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 03/22/2014 06:01 PM, Christian König wrote:
Hi Ortwin,
unfortunately the iMacs are notorious problematic and it's likely that something
didn't worked before and you never noticed it because the kernel didn't
complained. Have you ever tried to use UVD on that system?
3.12 says:
[
On 07/22/2013 01:22 PM, Stanislaw Gruszka wrote:
We remove interface that we do not add in the driver. I think I found
reason of that - I removed below code in bad commit:
list_for_each_entry(sdata, local-interfaces, list) {
[snip]
- switch (sdata-vif.type) {
-
Hi,
I think the bug is already fixed in this commit:
f3ed0a17f0292300b3caca32d823ecd32554a667
Thermal: x86 package temp thermal crash
Thanks,
Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
Mikael Pettersson mi...@it.uu.se I can see that patch in git, it's NOT
present in
either
the linux-3.11-rc2.tar.xz or the patch-3.11-rc2.xz files. Which is
strange
since the patch was committed 8 days ago, and -rc2 was released 2 days
ago.
It was merged only after rc2. Only in the tree that
Hi,
I am seeing a GPU lockup since v3.13:
[ 55.762710] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[ 55.762715] radeon :01:00.0: GPU lockup (waiting for 0x0004
last fence id 0x000 on ring 5)
[ 55.762717] [drm:uvd_v1_0_ib_test] *ERROR*
Hi,
My little son triggered the following Oops by hitting the Bluetooth keyboard
like a little monkey:
Linux gandalf 3.12.3 #2 SMP PREEMPT Wed Dec 4 23:04:27 CET 2013 x86_64 Intel(R)
Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux
Dec 12 18:04:11 gandalf kernel: input: gandalf kbd as
On 03.04.2014 15:50, Eric Dumazet wrote:
If bug is in tun.c you have this list of changes you could bisect
from :
# git log --oneline v3.13..v3.14 drivers/net/tun.c
6671b2240c54 tun: remove bogus hardware vlan acceleration flags from
vlan_features
99932d4fc03a netdevice: add queue
On 03.04.2014 15:50, Eric Dumazet wrote:
On Thu, 2014-04-03 at 06:19 -0700, Eric Dumazet wrote:
It seems TSO support is broken.
I finally found time to bisect this:
53d6471cef17262d3ad1c7ce8982a234244f68ec is the first bad commit
commit 53d6471cef17262d3ad1c7ce8982a234244f68ec
Author: Vlad
On 20.04.2014 18:31, Eric Dumazet wrote: On Sat, 2014-04-19 at 22:13
+0200, Ortwin Glück wrote:
On 03.04.2014 15:50, Eric Dumazet wrote:
I finally found time to bisect this:
commit 53d6471cef17262d3ad1c7ce8982a234244f68ec
Author: Vlad Yasevich vyase...@redhat.com
Date: Thu Mar 27 17:26
Hi,
Since 3.14 the openconnect VPN tunnel becomes unusable for me because
packets appear on the tun device at a horribly low rate. 3.12 and 3.13
do not exhibt the problem.
Here is an strace of openconnect trying to read from its fd
7 - /dev/net/tun
15:07:33.130640 read(7, 0x1e05e58, 1280) =
Hi,
I was hitting a BUG while running a couple of qemu 2.0 on a 3.15.0 kernel. KSM
was running. This box uses NUMA with two E5 6-core Xeons.
Linux toaster 3.15.0 #1 SMP PREEMPT Thu Jun 12 14:05:12 CEST 2014 x86_64
Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz GenuineIntel GNU/Linux
Jun 17
On 06/19/2014 06:52 PM, Kirill A. Shutemov wrote:
http://marc.info/?l=linux-kernelm=140319579508104w=2
Yes, those symptoms look very familiar. The patch should really go in stable
3.15.y.
Thanks.
Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Lv,
These two patches introduce a regression for Samsung notebooks and they no
longer get ACPI interrupts for plugging the power adapter or LID switches.
Multiple people have verified that reverting these patches makes the regression
go away.
Please see new comments in:
This happened right after boot when launching Firefox. There is plenty of RAM,
but no swap with vm.overcommit_memory=0:
$ free -m
total used free sharedbuffers cached
Mem: 3569656 2912128 16258
-/+
On 18.09.2014 16:58, Ilia Mirkin wrote:
This has been reported a few times already -- probably the same thing
as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550
Ah, thanks. I would like to try with that commit reverted, but unfortunately it
no longer reverts
cleanly, and my attempts
On 19.09.2014 17:58, Ilia Mirkin wrote:
git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^
Thanks again. I confirm that Bugzilla 83550 is the same issue. I have attached
the captured logs
there for reference.
Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 09/19/2014 07:01 PM, Ilia Mirkin wrote:
Thanks! Hopefully you still have those kernels handy, as your logs got
cut off.
Yeah, I noticed and hoped it wouldn't matter as it is mostly the boot log that's
been cut off until syslog came up (it's from /var/log/messages). So
suspend/resume cycle
On 19.09.2014 19:01, Ilia Mirkin wrote:
Try booting with log_buf_len=100M
Done and the slightly lengthy files attached to the Bugzilla entry.
Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi,
Since 3.16 an external monitor stays dark after resume from sleep. I didn't
manage to activate it
again with xrand. According to xrandr it is connected and configured with a
mode, but I get no signal.
Happens since 3.16 and is still broken with 3.17-rc5.
Hardware:
HP EliteBook 8540w
I have tried and reverted these commits but to no avail.
028791bb7d6 drm/nouveau/kms: restore fbcon after display has been resumed
456b0579fb0 drm/nouveau: use connector events for HPD instead of GPIO watching
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi,
Since 3.18-rc1 backlight is dark after resume from suspend. This is on a Samsung
laptop with i5 IvyBridge
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
I have bisected this problem to the following commit:
Fixes: 622582786c9e (net: filter: x86: internal BPF JIT)
Hi, I confirm that this fixes my kernel panic when using nmap as root on 3.17.
Ortwin
--
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
Hi Ben,
Since 3.19 the NV BIOS can no longer be loaded via ACPI. This breaks my HP
laptop.
Looking at the recent changes (ad4a3626 split out shadow methods) in the bios shadow code, I think
this happens:
- nvbios_shadow loops over all possible bios sources
- shadow_method
- shadow_score
-
Hi,
I got a series of (same) Oopses on a fresh 4.1.5 on KDE startup:
Aug 14 08:45:38 gandalf kernel: PGD 0
Aug 14 08:45:38 gandalf kernel: Oops: [#1] PREEMPT SMP
Aug 14 08:45:38 gandalf kernel: Modules linked in: radeon cfbfillrect cfbimgblt cfbcopyarea fbcon
i2c_algo_bit bit
blit
> I would like to see Linux support multiple root devices
You can do that completely in user space from an initramfs.
From your init script you can do what you want. You may even parse /proc/cmdline and use the root=
parameter as you propose. Then mount whatever root device you want by
> [2.481399] EXT4-fs (sda2): couldn't mount as ext3 due to feature
incompatibilities
> [2.482426] EXT4-fs (sda2): couldn't mount as ext2 due to feature
incompatibilities
As the kernel doesn't know which FS your root is, it tries the whole list of filesystems
(init/do_mounts.c
If you have physical access then the machine is yours to do with as you please.
Thinking of ATMs or voting machines that is a bold statement :-)
Thinking of mobile phones it depends on your jurisdiction.
Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On 17.09.2015 20:28, Drew DeVault wrote:
I don't think this is a strong argument against this feature. The
implementation of this feature
will be pretty straightfoward - only a small part of the code has to actually
change its behavior
and it can do without changing the interfaces it already
On 12/19/2017 07:09 PM, Wei Wang wrote:
Would you give more details under what circumstances it happened?
Circumstances are unknown as I can't correlate that log line to anything else.
If I have to guess, then it has to do with ipsec events. These tunnel tend to go
up and down a lot and
Hi,
On 4.14.6 I just got this (on a busy firewall):
[Tue Dec 19 11:15:59 2017] dst_release: dst:9bb7aca0d6c0 refcnt:-1
Are you sure the refcounting is now correct?
Ortwin
Hi,
I saw this WARN_ON splat on ath9k in hostap mode. The code triggering the warning says it's a driver
bug.
Thanks for checking.
Ortwin
[Tue Nov 21 06:00:36 2017] [ cut here ]
[Tue Nov 21 06:00:36 2017] WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:629
Possibly this recent patch in master fixes it:
d2950278d2 (xfrm: put policies when reusing pcpu xdst entry)
Hi,
Stable kernel has stability problems on r8169 that were not present in 4.17.3:
[0.00] Linux version 4.18.8 (kbuild@lofw) (gcc version 7.3.0 (Gentoo 7.3.0-r3 p1.4)) #70 SMP
PREEMPT Mon Sep 17 17:56:57 CEST 2018
[0.00] Command line: BOOT_IMAGE=/boot/linux-4.18.8
On 25.09.18 23:03, Heiner Kallweit wrote:
It seems that all chip versions from 34 (= RTL8168E-VL) with the
exception of version 39 (= RTL8106E, first sub-version) need
bit TXCFG_AUTO_FIFO.
And indeed, due to reordering of calls this bit is overwritten.
Following patch moves setting the bit from
Hi,
My Samsung ultrabook hangs when suspending to RAM since this commit (bisected).
Disabling wifi before suspend works around the issue. All works fine with 3.9.y.
12e7f517029dad819c45eca9ca01fdb9ba57616b
Author: Stanislaw Gruszka
Date: Thu Feb 28 10:55:26 2013 +0100
mac80211:
On 16.07.2013 08:56, Stanislaw Gruszka wrote:
Apparently this commit changed suspend procedure on mac80211, but it's
not obvious for me why it hangs :-(
Hangs are hard :-) It just sits there with a black screen and a white
cursor in the top left corner...
What is your user space
Without NetworkManager, no X, on console and with plain jane wpa_supplicant I do
echo mem > /sys/power state
After that, it still responds to keyboard events: I can switch VT and type on
the consoles, but I can not login on a different VT (pressing Enter after the
username doesn't return). So
Hi,
My little son triggered the following Oops by hitting the Bluetooth keyboard
like a little monkey:
Linux gandalf 3.12.3 #2 SMP PREEMPT Wed Dec 4 23:04:27 CET 2013 x86_64 Intel(R)
Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux
Dec 12 18:04:11 gandalf kernel: input: gandalf kbd as
On 02/11/2014 03:32 AM, Hannes Frederic Sowa wrote:
net.ipv4.ip_no_pmtu_disc=1.
This setting will shrink the path mtu to min_pmtu when a frag needed icmp is
received.
The UDP+ESP encapsulation adds 60 bytes to the original packet size.
ifconfig wla0 shows an mtu of 1500.
The size of the
The next commit on that file:
3a768d04639307db Merge branch 'spear/multiplatform' into next/multiplatform
easy to see with this:
gitk v3.13 arch/arm/Kconfig
Cheers,
Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 02/13/2014 01:01 AM, Hannes Frederic Sowa wrote:
Could you try either dropwatch or perf script net_dropmonitor and flood the
network with the problematic packets. From the traces we could see where the
packets get dropped without notification in the kernel.
Not much to see, unfortunately.
Hi,
I am using Openswan to configure an IPSec VPN (using the xfrm/netkey
backend). Large HTTP POST requests from the client seem to get stuck,
because the outgoing packets are 1530 bytes (before being wrapped into
ESP packets). The problem goes away by setting sysctl
On 19.07.2013 14:08, Stanislaw Gruszka wrote:
Does crash happen on any suspend or on second one ?
The crash always happens on the first suspend.
Thanks for the patch, I will send results tonight.
Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 07/22/2013 01:22 PM, Stanislaw Gruszka wrote:
We remove interface that we do not add in the driver. I think I found
reason of that - I removed below code in bad commit:
list_for_each_entry(sdata, >interfaces, list) {
[snip]
- switch (sdata->vif.type) {
-
Hi,
I think the bug is already fixed in this commit:
f3ed0a17f0292300b3caca32d823ecd32554a667
Thermal: x86 package temp thermal crash
Thanks,
Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Mikael Pettersson >I can see that patch in git, it's NOT
present in
>either
>the linux-3.11-rc2.tar.xz or the patch-3.11-rc2.xz files. Which is
>strange
>since the patch was committed 8 days ago, and -rc2 was released 2 days
>ago.
It was merged only after rc2. Only in the tree that it was
Hi,
I am seeing a GPU lockup since v3.13:
[ 55.762710] radeon :01:00.0: GPU lockup CP stall for more than 1msec
[ 55.762715] radeon :01:00.0: GPU lockup (waiting for 0x0004
last fence id 0x000 on ring 5)
[ 55.762717] [drm:uvd_v1_0_ib_test] *ERROR*
Hi,
Since 3.14 the openconnect VPN tunnel becomes unusable for me because
packets appear on the tun device at a horribly low rate. 3.12 and 3.13
do not exhibt the problem.
Here is an strace of openconnect trying to read from its fd
7 -> /dev/net/tun
15:07:33.130640 read(7, 0x1e05e58, 1280) =
On 03.04.2014 15:50, Eric Dumazet wrote:
> If bug is in tun.c you have this list of changes you could bisect
> from :
>
> # git log --oneline v3.13..v3.14 drivers/net/tun.c
> 6671b2240c54 tun: remove bogus hardware vlan acceleration flags from
> vlan_features
> 99932d4fc03a netdevice: add
On 03/22/2014 06:01 PM, Christian König wrote:
Hi Ortwin,
unfortunately the iMacs are notorious problematic and it's likely that something
didn't worked before and you never noticed it because the kernel didn't
complained. Have you ever tried to use UVD on that system?
3.12 says:
[
On 03.04.2014 15:50, Eric Dumazet wrote:
> On Thu, 2014-04-03 at 06:19 -0700, Eric Dumazet wrote:
>
>> It seems TSO support is broken.
I finally found time to bisect this:
53d6471cef17262d3ad1c7ce8982a234244f68ec is the first bad commit
commit 53d6471cef17262d3ad1c7ce8982a234244f68ec
Author:
On 20.04.2014 18:31, Eric Dumazet wrote:> On Sat, 2014-04-19 at 22:13
+0200, Ortwin Glück wrote:
>> On 03.04.2014 15:50, Eric Dumazet wrote:
>>
>> I finally found time to bisect this:
>>
>> commit 53d6471cef17262d3ad1c7ce8982a234244f68ec
>> Author: Vlad Y
Hi,
I was hitting a BUG while running a couple of qemu 2.0 on a 3.15.0 kernel. KSM
was running. This box uses NUMA with two E5 6-core Xeons.
Linux toaster 3.15.0 #1 SMP PREEMPT Thu Jun 12 14:05:12 CEST 2014 x86_64
Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz GenuineIntel GNU/Linux
Jun 17
On 06/19/2014 06:52 PM, Kirill A. Shutemov wrote:
http://marc.info/?l=linux-kernel=140319579508104=2
Yes, those symptoms look very familiar. The patch should really go in stable
3.15.y.
Thanks.
Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hi,
On 4.14.6 I just got this (on a busy firewall):
[Tue Dec 19 11:15:59 2017] dst_release: dst:9bb7aca0d6c0 refcnt:-1
Are you sure the refcounting is now correct?
Ortwin
On 12/19/2017 07:09 PM, Wei Wang wrote:
Would you give more details under what circumstances it happened?
Circumstances are unknown as I can't correlate that log line to anything else.
If I have to guess, then it has to do with ipsec events. These tunnel tend to go
up and down a lot and
Possibly this recent patch in master fixes it:
d2950278d2 (xfrm: put policies when reusing pcpu xdst entry)
Hi,
I saw this WARN_ON splat on ath9k in hostap mode. The code triggering the warning says it's a driver
bug.
Thanks for checking.
Ortwin
[Tue Nov 21 06:00:36 2017] [ cut here ]
[Tue Nov 21 06:00:36 2017] WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:629
On 02.08.2012 18:56, Marcin Slusarz wrote:
On Thu, Aug 02, 2012 at 01:26:55PM +0200, Ortwin Glück wrote:
I have managed to turn the crash into a WARN_ON, by adding this to the
begin of nouveau_software_vblank():
if (!psw) {
WARN_ON(1);
return
The LMS daemon expects a /sys/modules/mei/version file with, a four
digit version number.
see
http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index
On 07/10/2012 05:28 PM, Alan Cox wrote:
On Tue, 10 Jul 2012 12:10:27 +0200
Ortwin Glück wrote:
The LMS daemon expects a /sys/modules/mei/version file with, a four
digit version number.
see
http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
Just get
Hi,
My HP Elitebook 8540w now crashes on boot with 3.5. All works fine with
3.4. Bisected to the following commit:
20abd1634a6e2eedb84ca977adea56b8aa06cc3e is the first bad commit
commit 20abd1634a6e2eedb84ca977adea56b8aa06cc3e
Author: Ben Skeggs
Date: Mon Apr 30 11:33:43 2012 -0500
Support battery capacity on another Apple wireless
keyboard.
NB: most likely all other APPLE_ALU_WIRELESS_*
keyboards should be added as well.
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5301006..b2ae097 100644
--- a/drivers/hid/hid
Support battery capacity on another Apple wireless
keyboard.
NB: most likely all other APPLE_ALU_WIRELESS_*
keyboards should be added as well.
Cc: stable kernel.org
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5301006..b2ae097 100644
To me this looks like an issue with swap. Can you try without swap
(swapoff)?
Ortwin
--
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
On 08.11.2012 14:28, Luming Yu wrote:
As I just noticed that I couldn't quit from mutt due to tmpfs is full.
That's also pointing towards high memory pressure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On 08.11.2012 15:14, Luming Yu wrote:
hmmmake sens? maybe we can't use tmp-on-tmpfs feature in f18
but why not having disk to backup tmpfs under memory pressure?
It should. tmpfs should use all available RAM+swap. But then I guess you
have no swap, and the kernel simply is desperately
NB: still broken in 3.5 as well.
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6
On 24.07.2012 19:00, Marcin Slusarz wrote:
Please post the crash log.
Sorry, I was not precise: it boots until drm performs modesetting (so it
seems). The screen goes black and the machine is dead. So there is
nothing I could post here, unfortunately.
This is a video of 3.5 booting:
Does it work if you boot without X and modprobe nouveau manually? If it does,
can you disable page flipping in xorg.conf (Option "PageFlip" "0" in nouveau
device section) and recheck with X?
It happens long before X, when the nouveau module is loaded.
Does it work if you disable acceleration
On 25.07.2012 20:42, Marcin Slusarz wrote:
Good, below patch should fix this panic.
Note that you can hit an oops in drm_handle_vblank because patch from
http://lists.freedesktop.org/archives/dri-devel/2012-May/023498.html
has not been applied (yet?).
After applying your patch, it still
On 29.07.2012 22:15, Marcin Slusarz wrote:
No, the real problem is: with "noaccel" we don't register "software engine",
but vblank ISR relies on its existance and happily derefences NULL pointer.
Now, this patch should fix it for real...
Unfortunately I am still seeing the crash. Without
Yes, as far as I can tell. I didn't do anything different this time. The date
on the kernel file looks ok. Just did a fresh make && make install again, and
got the same behaviour. When is that number after the hash sign upped?
Marcin Slusarz wrote:
>Are you sure you boot the correct kernel?
Work around a crash during boot if noaccel is set.
NB: still broken in 3.5 as well, used to work in 3.4. Why are people
ignoring this? It's a regression!
Signed-off-by: Ortwin Glück
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index
Hi,
Stable kernel has stability problems on r8169 that were not present in 4.17.3:
[0.00] Linux version 4.18.8 (kbuild@lofw) (gcc version 7.3.0 (Gentoo 7.3.0-r3 p1.4)) #70 SMP
PREEMPT Mon Sep 17 17:56:57 CEST 2018
[0.00] Command line: BOOT_IMAGE=/boot/linux-4.18.8
On 25.09.18 23:03, Heiner Kallweit wrote:
It seems that all chip versions from 34 (= RTL8168E-VL) with the
exception of version 39 (= RTL8106E, first sub-version) need
bit TXCFG_AUTO_FIFO.
And indeed, due to reordering of calls this bit is overwritten.
Following patch moves setting the bit from
1 - 100 of 116 matches
Mail list logo
