Re: drm/nouveau: crash regression in 3.5
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 crashes, although with a slightly different stack trace. I then also applied the second patch, but that doesn't make any difference. New log attached. Looks like interrupt occurs before nouveau_software_context_new() is called? Shouldn't the initialization be done from nouveau_irq_preinstall() so it is available when the irq occurs? Again, I am not an expert here. Just guessing... Thanks, Ortwin Initializing cgroup subsys cpu Linux version 3.5.0 (root@ortwin-hp) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #3 SMP PREEMPT Thu Jul 26 14:42:43 CEST 2012 Command line: root=/dev/sda5 rootfstype=ext4 pciehp_force=1 nouveau.modeset=1 nouveau.noaccel=1 netconsole=@10.11.1.234/eth0,@10.11.1.19/00:1a:64:89:71:b8 drm.debug=1 e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e-0x000f] reserved BIOS-e820: [mem 0x0010-0xbefc1fff] usable BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable BIOS-e820: [mem 0xbf80-0xbfff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved BIOS-e820: [mem 0xfec0-0xfec00fff] reserved BIOS-e820: [mem 0xfed1-0xfed13fff] reserved BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved BIOS-e820: [mem 0xfed1b000-0xfed1] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xffd0-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023bff] usable NX (Execute Disable) protection: active DMI 2.6 present. No AGP bridge found e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 init_memory_mapping: [mem 0x-0xbf7f] init_memory_mapping: [mem 0x1-0x23bff] ACPI: RSDP 000fddc0 00024 (v02 HPQOEM) ACPI: XSDT bf7fe120 00094 (v01 HPQOEM SLIC-MPC 000F 0113) ACPI: FACP bf7fc000 000F4 (v03 HPQOEM 1521 000F HP 0001) ACPI: DSDT bf7da000 1C77F (v02 HPQOEM 1521 0001 INTL 20060912) ACPI: FACS bf76 00040 ACPI: HPET bf7fb000 00038 (v01 HPQOEM 1521 0001 HP 0001) ACPI: APIC bf7fa000 000BC (v01 HPQOEM 1521 0001 HP 0001) ACPI: MCFG bf7f9000 0003C (v01 HPQOEM 1521 0001 HP 0001) ACPI: TCPA bf7f7000 00032 (v02 HPQOEM 1521 HP 0001) ACPI: SSDT bf7d7000 00135 (v01 HPQOEM SataAhci 1000 INTL 20060912) ACPI: SSDT bf7d6000 00314 (v01 HPQOEM PtidDevc 1000 INTL 20060912) ACPI: SLIC bf7d5000 00176 (v01 HPQOEM SLIC-MPC 0001 HP 0001) ACPI: SSDT bf7d1000 02576 (v01 HPQOEM NVIDIAGF 0001 INTL 20060912) ACPI: DMAR bf7d 00080 (v01 INTEL CP_DALE 0001 INTL 0001) ACPI: SSDT bf7cf000 00A10 (v01 PmRefCpuPm 3000 INTL 20060912) ACPI: SSDT bf7ce000 00288 (v01 PmRef Cpu0Tst 3000 INTL 20060912) ACPI: SSDT bf7cd000 00225 (v01 PmRefApTst 3000 INTL 20060912) ACPI: ASF! bf7f8000 000A0 (v32 HPQOEM 1521 0001 HP 0001) Zone ranges: DMA [mem 0x0001-0x00ff] DMA32[mem 0x0100-0x] Normal [mem 0x1-0x23bff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0001-0x0009efff] node 0: [mem 0x0010-0xbefc1fff] node 0: [mem 0xbf7ff000-0xbf7f] node 0: [mem 0x1-0x1fbff] node 0: [mem 0x2-0x23bff] ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_
Re: drm/nouveau: crash regression in 3.5
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" it works though (until X crashes the machine, but that is a different thing). Thanks, Ortwin Initializing cgroup subsys cpu Linux version 3.5.0 (root@ortwin-hp) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #3 SMP PREEMPT Thu Jul 26 14:42:43 CEST 2012 Command line: root=/dev/sda5 rootfstype=ext4 pciehp_force=1 nouveau.modeset=1 nouveau.noaccel=1 netconsole=@10.11.1.234/eth0,@10.11.1.19/00:17:f2:c7:5f:06 drm.debug=15 e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e-0x000f] reserved BIOS-e820: [mem 0x0010-0xbefc1fff] usable BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable BIOS-e820: [mem 0xbf80-0xbfff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved BIOS-e820: [mem 0xfec0-0xfec00fff] reserved BIOS-e820: [mem 0xfed1-0xfed13fff] reserved BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved BIOS-e820: [mem 0xfed1b000-0xfed1] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xffd0-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023bff] usable NX (Execute Disable) protection: active DMI 2.6 present. No AGP bridge found e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 init_memory_mapping: [mem 0x-0xbf7f] init_memory_mapping: [mem 0x1-0x23bff] ACPI: RSDP 000fddc0 00024 (v02 HPQOEM) ACPI: XSDT bf7fe120 00094 (v01 HPQOEM SLIC-MPC 000F 0113) ACPI: FACP bf7fc000 000F4 (v03 HPQOEM 1521 000F HP 0001) ACPI: DSDT bf7da000 1C77F (v02 HPQOEM 1521 0001 INTL 20060912) ACPI: FACS bf76 00040 ACPI: HPET bf7fb000 00038 (v01 HPQOEM 1521 0001 HP 0001) ACPI: APIC bf7fa000 000BC (v01 HPQOEM 1521 0001 HP 0001) ACPI: MCFG bf7f9000 0003C (v01 HPQOEM 1521 0001 HP 0001) ACPI: TCPA bf7f7000 00032 (v02 HPQOEM 1521 HP 0001) ACPI: SSDT bf7d7000 00135 (v01 HPQOEM SataAhci 1000 INTL 20060912) ACPI: SSDT bf7d6000 00314 (v01 HPQOEM PtidDevc 1000 INTL 20060912) ACPI: SLIC bf7d5000 00176 (v01 HPQOEM SLIC-MPC 0001 HP 0001) ACPI: SSDT bf7d1000 02576 (v01 HPQOEM NVIDIAGF 0001 INTL 20060912) ACPI: DMAR bf7d 00080 (v01 INTEL CP_DALE 0001 INTL 0001) ACPI: SSDT bf7cf000 00A10 (v01 PmRefCpuPm 3000 INTL 20060912) ACPI: SSDT bf7ce000 00288 (v01 PmRef Cpu0Tst 3000 INTL 20060912) ACPI: SSDT bf7cd000 00225 (v01 PmRefApTst 3000 INTL 20060912) ACPI: ASF! bf7f8000 000A0 (v32 HPQOEM 1521 0001 HP 0001) Zone ranges: DMA [mem 0x0001-0x00ff] DMA32[mem 0x0100-0x] Normal [mem 0x1-0x23bff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0001-0x0009efff] node 0: [mem 0x0010-0xbefc1fff] node 0: [mem 0xbf7ff000-0xbf7f] node 0: [mem 0x1-0x1fbff] node 0: [mem 0x2-0x23bff] ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC
Re: drm/nouveau: crash regression in 3.5
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? I'm asking because your panic >says its >version is "3.5.0 #3" - exactly the same as in previous crash log. > >Marcin -- 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: drm/nouveau: crash regression in 3.5
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;
}
Yes, I know about it, but this change fixes only a symptom. We should not get
into this code at all without enabling vblank.
I was wondering if that is ever going to be fixed in stable. Nouveau is
broken due to this bug in 3.5 and 3.6 on HP laptops -- not terribly
exotic hardware, is it? Is there any reason why this should not be
submitted to stable?
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 FAQ at http://www.tux.org/lkml/
Re: [headache] 3.7.0-rc2 can't handle mutt (with 3.7G mail file) +FF (4 tabs) on a 4G memory+4 core system ?
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 FAQ at http://www.tux.org/lkml/
Re: [headache] 3.7.0-rc2 can't handle mutt (with 3.7G mail file) +FF (4 tabs) on a 4G memory+4 core system ?
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 majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [headache] 3.7.0-rc2 can't handle mutt (with 3.7G mail file) +FF (4 tabs) on a 4G memory+4 core system ?
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 trying to find memory for a slab/slub or whatever. OOM killer can't help because the temp file uses the space, not a process. -- 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/
[BUG] 3.10 regression: hang on suspend
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: cleanup generic suspend/resume procedures Since now we disconnect before suspend, various code which save connection state can now be removed from suspend and resume procedure. Cleanup on resume side is smaller as ieee80211_reconfig() is also used for H/W restart. Signed-off-by: Stanislaw Gruszka Signed-off-by: Johannes Berg Hardware: 01:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24) Sorry for not noticing this earlier. 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 FAQ at http://www.tux.org/lkml/
Re: [BUG] 3.10 regression: hang on suspend
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 configuration (are you using NM or other software or maybe just wpa_supplicant)? Are you using wowlan? If you do add no_console_suspend boot parameter does it print some diagnostic messages during suspend before the hang ? Yes, I am using NM under KDE, with KDE triggered suspend. No wowlan AFAIK. The last thing I see in the log is something from NetworkManager that sees the device switching off. I can try again tonight and give you the exact message. I will also try without NM and bare wpa_supplicant and a plain suspend through sysfs. Any debug options you want me to enable? Netconsole won't work however... 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 FAQ at http://www.tux.org/lkml/
Re: [BUG] 3.10 regression: hang on suspend
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 guess tasks have been frozen, but it hangs in stopping devices. settings for pm_test: devices: same behviour as above freezer: works as expected (stops tasks; sleeps; resumes tasks) Nothing in the logs. How can I enable more log? 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 FAQ at http://www.tux.org/lkml/
Re: [BUG] 3.10 regression: hang on suspend
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 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] 3.10 regression: hang on suspend
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) {
- case NL80211_IFTYPE_AP_VLAN:
- case NL80211_IFTYPE_MONITOR:
- /* skip these */
- continue;
Oh yes, that makes a lot of sense! I have an extra monitoring interface
configured. If I remove that before suspend, the crash does not occur.
And your patch does fix the problem. Very nice!
Thank you,
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 FAQ at http://www.tux.org/lkml/
Re: CONFIG_X86_PKG_TEMP_THERMAL causes #GP fault on Core i7-740QM breaking boot
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 info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_X86_PKG_TEMP_THERMAL causes #GP fault on Core i7-740QM breaking boot
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 merged from it was commited before rc2. See gitk v3.11-rc2.. 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 FAQ at http://www.tux.org/lkml/
drm/nouveau: Work around a crash during boot if noaccel is set.
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 +650,12 @@ nv50_display_vblank_crtc_handler(struct drm_device
*dev, int crtc)
struct nouveau_software_priv *psw = nv_engine(dev, NVOBJ_ENGINE_SW);
struct nouveau_software_chan *pch, *tmp;
+if (!psw) {
+WARN_ON_ONCE(1);
+printk(KERN_ERR "NULL software engine\n");
+return;
+}
+
list_for_each_entry_safe(pch, tmp, &psw->vblank, vblank.list) {
if (pch->vblank.head != crtc)
continue;
--
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/
drm/nouveau: crash regression in 3.5
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 drm/nouveau: create real execution engine for software object class Just a cleanup more or less, and to remove the need for special handling of software objects. This removes a heap of documentation on dma/graph object formats. The info is very out of date with our current understanding, and is far better documented in rnndb in envytools git. Signed-off-by: Ben Skeggs lspci: 01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [Quadro FX 1800M] (rev a2) kernel output from a working 3.4: Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Detected an NV50 generation card (0x0a3e00a2) Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Checking PRAMIN for VBIOS Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: ... appears to be valid Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Using VBIOS from PRAMIN Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: BIT BIOS found Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Bios version 70.15.43.00 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: TMDS table version 2.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: MXM: BIOS version 3.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: MXM: MXMS Version 3.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB version 4.0 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 00: 01000313 00010034 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 03: 080153d6 0f220020 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 04: 08015392 00020020 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 05: 080143c6 0f220010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 06: 08014382 00020010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 08: 040383b6 0f230014 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 10: 020273a6 0f220010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 11: 02027362 00020010 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB outp 13: 02049300 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 00: 0040 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 01: 1161 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 02: 1231 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 03: 01000331 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 04: 01000446 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 05: 02000546 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 06: 00010631 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 07: 00010746 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 08: 00020847 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: DCB conn 09: 0900 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0x7AE4 Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 0x7E6B: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 0x7E6F: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0x809A Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0x951E Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0x955C Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0x97CA Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Parsing VBIOS init table at offset 0x982F Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 0x982F: Condition still not met after 20ms, skipping follow ing opcodes Jul 23 19:49:57 localhost kernel: [TTM] Zone kernel: Available graphics memory: 4008772 kiB Jul 23 19:49:57 localhost kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB Jul 23 19:49:57 localhost kernel: [TTM] Initializing pool allocator Jul 23 19:49:57 localhost kernel: [TTM] Initializing DMA pool allocator Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: Detected 1024MiB VRAM (GDDR5) Jul 23 19:49:57 localhost kernel: [drm] nouveau :01:00.0: 512 MiB GART (aperture) Jul 23 19:49:57 localhost kernel: [drm]
Re: drm/nouveau: crash regression in 3.5
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: http://www.odi.ch/VIDEO0010.3gp Don't worry about the external monitor: same behaviour with the built-in panel. 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 info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/nouveau: crash regression in 3.5
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 (nouveau.noaccel=1 in kernel command line)? nouveau.noaccel=1 is already on my cmdline as running X with accel enabled never worked anyway. > Is there anything saved in /var/log/ from previous boot? Can you ssh into and check dmesg? Can you use netconsole and catch full log? Thanks for the netconsole tip. I have attached the log. I am not an expert but it looks like a crash in the inlined nouveau_software_vblank(). Is the vblank.list already initialized at this point? Thanks, Ortwin Initializing cgroup subsys cpu Linux version 3.5.0 (root@ortwin-hp) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #2 SMP PREEMPT Wed Jul 25 09:39:45 CEST 2012 Command line: root=/dev/sda5 rootfstype=ext4 pciehp_force=1 nouveau.modeset=1 nouveau.noaccel=1 netconsole=@10.11.1.234/eth0,@10.11.1.19/00:1a:64:89:71:b8 e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e-0x000f] reserved BIOS-e820: [mem 0x0010-0xbefc1fff] usable BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable BIOS-e820: [mem 0xbf80-0xbfff] reserved BIOS-e820: [mem 0xe000-0xefff] reserved BIOS-e820: [mem 0xfec0-0xfec00fff] reserved BIOS-e820: [mem 0xfed1-0xfed13fff] reserved BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved BIOS-e820: [mem 0xfed1b000-0xfed1] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xffd0-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023bff] usable NX (Execute Disable) protection: active DMI 2.6 present. No AGP bridge found e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 init_memory_mapping: [mem 0x-0xbf7f] init_memory_mapping: [mem 0x1-0x23bff] ACPI: RSDP 000fddc0 00024 (v02 HPQOEM) ACPI: XSDT bf7fe120 00094 (v01 HPQOEM SLIC-MPC 000F 0113) ACPI: FACP bf7fc000 000F4 (v03 HPQOEM 1521 000F HP 0001) ACPI: DSDT bf7da000 1C77F (v02 HPQOEM 1521 0001 INTL 20060912) ACPI: FACS bf76 00040 ACPI: HPET bf7fb000 00038 (v01 HPQOEM 1521 0001 HP 0001) ACPI: APIC bf7fa000 000BC (v01 HPQOEM 1521 0001 HP 0001) ACPI: MCFG bf7f9000 0003C (v01 HPQOEM 1521 0001 HP 0001) ACPI: TCPA bf7f7000 00032 (v02 HPQOEM 1521 HP 0001) ACPI: SSDT bf7d7000 00135 (v01 HPQOEM SataAhci 1000 INTL 20060912) ACPI: SSDT bf7d6000 00314 (v01 HPQOEM PtidDevc 1000 INTL 20060912) ACPI: SLIC bf7d5000 00176 (v01 HPQOEM SLIC-MPC 0001 HP 0001) ACPI: SSDT bf7d1000 02576 (v01 HPQOEM NVIDIAGF 0001 INTL 20060912) ACPI: DMAR bf7d 00080 (v01 INTEL CP_DALE 0001 INTL 0001) ACPI: SSDT bf7cf000 00A10 (v01 PmRefCpuPm 3000 INTL 20060912) ACPI: SSDT bf7ce000 00288 (v01 PmRef Cpu0Tst 3000 INTL 20060912) ACPI: SSDT bf7cd000 00225 (v01 PmRefApTst 3000 INTL 20060912) ACPI: ASF! bf7f8000 000A0 (v32 HPQOEM 1521 0001 HP 0001) Zone ranges: DMA [mem 0x0001-0x00ff] DMA32[mem 0x0100-0x] Normal [mem 0x1-0x23bff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0001-0x0009efff] node 0: [mem 0x0010-0xbefc1fff] node 0: [mem 0xbf7ff000-0xbf7f] node 0: [mem 0x1-0x1fbff] node 0: [mem 0x2-0x23bff] ACPI: PM-Timer IO Port: 0x408 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge
[PATCH] mei: module version
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 7de1389..cee72bd 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -1229,3 +1229,4 @@ module_exit(mei_exit_module);
MODULE_AUTHOR("Intel Corporation");
MODULE_DESCRIPTION("Intel(R) Management Engine Interface");
MODULE_LICENSE("GPL v2");
+MODULE_VERSION("1.0.0.0");
--
1.7.8.6
--
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] mei: module version
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 them to fix the userspace. I thought the latest one had this dealt with ? You are right of course. I thought the code at that URL is the latest one. At least the URL claims to be :-) Admitted, the code doesn't even build without a minor include fix. Has anyone got pointers to more recent code? We are trying to get it into Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=425658 and I woud like to have the patches upstream. -- 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/
[PATCH] HID: hid-input: battery quirk for Apple keyboard
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-input.c
+++ b/drivers/hid/hid-input.c
@@ -299,6 +299,9 @@ static enum power_supply_property hidinput_battery_props[]
= {
static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
+ USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
+ HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI),
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
--
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/
[PATCH] HID: hid-input: battery quirk for Apple keyboard
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
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -299,6 +299,9 @@ static enum power_supply_property
hidinput_battery_props[] = {
static const struct hid_device_id hid_battery_quirks[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
+ USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
+ HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI),
HID_BATTERY_QUIRK_PERCENT | HID_BATTERY_QUIRK_FEATURE },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
--
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/
[PATCH] drm/nouveau: fix crash regression
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 b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,12 @@ nv50_display_vblank_crtc_handler(struct drm_device
*dev, int crtc)
struct nouveau_software_priv *psw = nv_engine(dev, NVOBJ_ENGINE_SW);
struct nouveau_software_chan *pch, *tmp;
+if (!psw) {
+WARN_ON_ONCE(1);
+printk(KERN_ERR "NULL software engine\n");
+return;
+}
+
list_for_each_entry_safe(pch, tmp, &psw->vblank, vblank.list) {
if (pch->vblank.head != crtc)
continue;
--
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: kernel 4.18.5 Realtek 8111G network adapter stops responding under high system load
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 the chip-specific hw_start function to rtl_set_tx_config_registers(). Whoever is hit by the issue and has the option to build a kernel, could you please test whether the patch fixes the issue for you? Hi, Looks good so far! No problems for almost 24 hours. This is on a router/firewall that links various sites via IPSec and other VPNs and has >10 network interfaces, 5 of which are Realtek ones. Thanks, Ortwin # uname -a Linux lofw 4.18.10+ #72 SMP PREEMPT Wed Sep 26 17:07:07 CEST 2018 x86_64 Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz GenuineIntel GNU/Linux # uptime 17:42:37 up 22:54, 1 user, load average: 0.48, 0.38, 0.30 # ifconfig wan wan: flags=4163 mtu 1500 inet 81.7.230.226 netmask 255.255.255.248 broadcast 81.7.230.231 inet6 fe80::529a:4cff:fe2e:92be prefixlen 64 scopeid 0x20 ether 50:9a:4c:2e:92:be txqueuelen 100 (Ethernet) RX packets 56342905 bytes 40589502599 (37.8 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 54032328 bytes 44607761646 (41.5 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 # ifconfig lan lan: flags=4163 mtu 1500 inet 10.11.1.1 netmask 255.255.255.0 broadcast 10.11.1.255 inet6 fe80::20a:cdff:fe31:6022 prefixlen 64 scopeid 0x20 ether 00:0a:cd:31:60:22 txqueuelen 100 (Ethernet) RX packets 54799469 bytes 43111097607 (40.1 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 55158558 bytes 35746992802 (33.2 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Re: xfrm: is pmtu broken with ESP tunneling?
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 first big packet on the interface:
net.ipv4.ip_no_pmtu_disc=1: packet length is 1300
net.ipv4.ip_no_pmtu_disc=0: packet length is 1500
Length is without the ESP wrapper and UDP encapsulation. The packets are so big
that they can't even leave the wireless interface and never show up on the
router. So no ICMP packets are received. PMTU can't work with initial packets of
that size.
dump question: which layer discard these packets? qdisc? why no notification to
the sender?
When I increase the mtu of the interface to 2000 with ifconfig, then I start
seeing ICMP fragmentation needed from the next hop, indicating 1500 as the mtu
as response to a 1560 byte UDP[ESP] packet.
The next UDP[ESP] packet is shorter: 1360 bytes. It gets hard to see what's
going on after that, but the connection is still not working.
So, instead of somehow losing these packets on the way out of the interface
should the kernel not start with a lower mtu in the first place? Now it seems it
is trying with the maximum of the interface and expecting to scale down with
pmtu - which can ever happen.
Can you send a ip route get to the problematic target to see how
far off the calculated value is?
That command doesn't return anything useful. No hint on the mtu here.
BTW, instead of disabling pmtu, setting mtu explicitly also helps:
ip route add 10.6.6.0/24 via ${localip} mtu 1300
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 info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What commit dropped config PLAT_SPEAR_SINGLE?
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 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/
drm/radeon bisected 3.13 regression: GPU lockup
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* radeon: fence wait failed (-35). [ 55.762720] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). Hardware is an iMac 11,2 with a Radeon 4670 M96XT (RV730), 256MB GDDR3. Bisected to this commit: commit f9eaf9ae782d6480f179850e27e6f4911ac10227 Author: Christian König Date: Tue Oct 29 20:14:47 2013 +0100 drm/radeon: rework and fix reset detection v2 Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT. Consolidate the two wait sequence implementations into just one function. Activate all waiters and remember if the reset was already done instead of trying to reset from only one thread. v2: clear reset flag earlier to avoid timeout in IB test Unfortunately this patch no longer cleanly unapplies on v3.13. -- 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.14 regression: huge latency in read/select on tun
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) = -1 EAGAIN (Resource
temporarily unavailable)
===> should return available data already
15:07:33.130745 select(8, [3 6 7], [], [6], {30, 0}) = 1 (in [7], left
{29, 783272})
===> HUGE 217ms delay here
15:07:33.347681 read(6, 0x1dfc973, 5) = -1 EAGAIN (Resource
temporarily unavailable)
15:07:33.347806 read(7,
"E\10\5\0b\343@\0@\6\17~\n\363X\236\n\271UE\222:\0\26\37O\7\342\315\21q\33"...,
1280) = 1280
The send queue of the socket being routed via the tun device has a lot
of outstanding data (here an scp/ssh upload):
tcp0 29788 local:46577 remote:22 ESTABLISHED
(IPs replaced for privacy)
toggling TCP autocorking has no influence.
Any ideas what could be the culprit?
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 FAQ at http://www.tux.org/lkml/
Re: 3.14 regression: huge latency in read/select on tun
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 selection fallback handler for > ndo_select_queue > 93e14b6d776e tun: add device name(iff) field to proc fdinfo entry > fa35864e0bb7 tuntap: Fix for a race in accessing numqueues > 0a379e21c503 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > fbe4d4565bad tun, rfs: fix the incorrect hash value > 9bc8893937c8 tun: Add support for RFS on tun flows > 143c90549494 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > 3958afa1b272 net: Change skb_get_rxhash to skb_get_hash > 42404c091510 Revert "tun: remove useless codes in tun_chr_aio_read() and > tun_recvmsg()" > 73713357ab58 tun: remove useless codes in tun_chr_aio_read() and tun_recvmsg() > 34f9f437104b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > f96eb74c84eb tun: remove unused parameter in tun_do_read() > 92d4ea6e412a tun: spelling fixes That list doesn't look too promising. I'd rather look in net/ipv4 which does have TSO/GSO related changes. I tried to bisect that but the system hangs on boot when net devices are enabled. So it may prove difficult to pin down. I may try again during the weekend. -- 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.12.3: Oops while hitting keyboard
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 /devices/pci:00/:00:1a.7/usb1/1-1/1-1. 1/1-1.1.1/1-1.1.1:1.0/bluetooth/hci0/hci0:12/input45 Dec 12 18:04:11 gandalf kernel: apple 0005:05AC:023A.0025: input,hidraw2: BLUETOOTH HID v0.50 Keyboa rd [gandalf kbd] on 7c:6d:62:9f:db:2d Dec 12 18:04:28 gandalf kernel: BUG: unable to handle kernel paging request at 82450968 Dec 12 18:04:28 gandalf kernel: IP: [] kbd_event+0x1d7/0x740 Dec 12 18:04:28 gandalf kernel: PGD 1c0c067 PUD 1c0d063 PMD 0 Dec 12 18:04:28 gandalf kernel: PGD 1c0c067 PUD 1c0d063 PMD 0 Dec 12 18:04:28 gandalf kernel: Oops: [#1] PREEMPT SMP Dec 12 18:04:28 gandalf kernel: Modules linked in: fbcon radeon cfbfillrect cfbimgblt bitblit cfbcop yarea softcursor font i2c_algo_bit drm_kms_helper ttm drm fb fbdev Dec 12 18:04:28 gandalf kernel: CPU: 2 PID: 9153 Comm: khidpd_05ac023a Not tainted 3.12.3 #2 Dec 12 18:04:28 gandalf kernel: Hardware name: Apple Inc. iMac11,2/Mac-F2238AC8, BIOSIM112.88Z.0057.B00.1005031455 05/03/10 Dec 12 18:04:28 gandalf kernel: task: 8800327e8000 ti: 880030858000 task.ti: 880030858000 Dec 12 18:04:28 gandalf kernel: RIP: 0010:[] [] kbd_event+0x1d7/0x740 Dec 12 18:04:28 gandalf kernel: RSP: 0018:880030859ba8 EFLAGS: 00010046 Dec 12 18:04:28 gandalf kernel: RAX: 001d RBX: 0038 RCX: 81e6cbde Dec 12 18:04:28 gandalf kernel: RDX: 880030859bc0 RSI: 0001 RDI: 81e6cba0 Dec 12 18:04:28 gandalf kernel: RBP: R08: 0001 R09: Dec 12 18:04:28 gandalf kernel: R10: R11: 0001 R12: 8800ba829800 Dec 12 18:04:28 gandalf kernel: R13: 001d R14: 880030b10500 R15: 0038 Dec 12 18:04:28 gandalf kernel: FS: () GS:88013bc8() knlGS: Dec 12 18:04:28 gandalf kernel: CS: 0010 DS: ES: CR0: 8005003b Dec 12 18:04:28 gandalf kernel: CR2: 82450968 CR3: 01c0b000 CR4: 07e0 Dec 12 18:04:28 gandalf kernel: CR2: 82450968 CR3: 01c0b000 CR4: 07e0 Dec 12 18:04:28 gandalf kernel: Stack: Dec 12 18:04:28 gandalf kernel: 819db59b 8106e1b3 0081 8800ba829800 Dec 12 18:04:28 gandalf kernel: 001d 0038 0096 0003 Dec 12 18:04:28 gandalf kernel: 880030b103d8 81c4e5e0 880030b103d8 880030b105a0 Dec 12 18:04:28 gandalf kernel: Call Trace: Dec 12 18:04:28 gandalf kernel: [] ? __wake_up+0x43/0x70 Dec 12 18:04:28 gandalf kernel: [] ? input_to_handler+0xd3/0xf0 Dec 12 18:04:28 gandalf kernel: [] ? input_pass_values.part.8+0x162/0x170 Dec 12 18:04:28 gandalf kernel: [] ? input_handle_event+0x12d/0x550 Dec 12 18:04:28 gandalf kernel: [] ? input_event+0x5e/0xa0 Dec 12 18:04:28 gandalf kernel: [] ? hidinput_report_event+0x37/0x50 Dec 12 18:04:28 gandalf kernel: [] ? hid_report_raw_event+0x285/0x460 Dec 12 18:04:28 gandalf kernel: [] ? hid_input_report+0x11d/0x1b0 Dec 12 18:04:28 gandalf kernel: [] ? hidp_session_thread+0x5eb/0x640 Dec 12 18:04:28 gandalf kernel: [] ? try_to_wake_up+0x2a0/0x2a0 Dec 12 18:04:28 gandalf kernel: [] ? try_to_wake_up+0x2a0/0x2a0 Dec 12 18:04:28 gandalf kernel: [] ? hidp_input_report.isra.9+0x2e0/0x2e0 Dec 12 18:04:28 gandalf kernel: [] ? kthread+0xb3/0xc0 Dec 12 18:04:28 gandalf kernel: [] ? get_group+0x20/0x80 Dec 12 18:04:28 gandalf kernel: [] ? kthread_freezable_should_stop+0x60/0x60 Dec 12 18:04:28 gandalf kernel: [] ? kthread_freezable_should_stop+0x60/0x60 Dec 12 18:04:28 gandalf kernel: [] ? kthread_freezable_should_stop+0x60/0x60 Dec 12 18:04:28 gandalf kernel: [] ? ret_from_fork+0x7c/0xb0 Dec 12 18:04:28 gandalf kernel: [] ? ret_from_fork+0x7c/0xb0 Dec 12 18:04:28 gandalf kernel: [] ? kthread_freezable_should_stop+0x60/0x60 Dec 12 18:04:28 gandalf kernel: Code: e6 81 44 0f b6 68 01 44 0b 2d b6 7c b2 00 41 31 d5 44 89 6c 24 24 48 8d 54 24 18 0f b6 40 02 d0 e8 83 e0 0f 89 44 24 28 49 63 c5 <48> 8b 0c c5 00 09 c5 81 48 89 4c 24 08 e8 c7 59 d2 ff 48 8b 4c Dec 12 18:04:28 gandalf kernel: RIP [] kbd_event+0x1d7/0x740 Dec 12 18:04:28 gandalf kernel: RSP Dec 12 18:04:28 gandalf kernel: CR2: 82450968 Dec 12 18:04:28 gandalf kernel: ---[ end trace edcf19cf8c005260 ]--- 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 info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] nouveau regression: ext monitor dead after resume
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 01:00.0 VGA compatible controller: NVIDIA Corporation GT215GLM [Quadro FX 1800M] (rev a2) 0 External Monitor connected via DVI on the docking station. XRandR before amd after suspend looks the same: $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm 1920x1080 59.9*+ 60.0 1680x1050 60.0 1400x1050 60.0 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x60059.9 640x48059.4 720x40059.6 640x40060.0 640x35059.8 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) eDP-1 disconnected (normal left inverted right x axis y axis) DP-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 75.0 60.0 1440x900 75.0 59.9 1024x768 75.1 60.0 800x60075.0 60.3 640x48075.0 72.8 66.7 60.0 720x40070.1 VGA-1 disconnected (normal left inverted right x axis y axis) dmesg output of a suspend/resume cycle attached. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.17.0-rc5 (root@ortwin-hp) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.3, pie-0.5.5) ) #2 SMP PREEMPT Thu Sep 18 12:27:26 CEST 2014 [0.00] Command line: BOOT_IMAGE=/boot/linux-3.17.0-rc5 root=/dev/sda1 rootfstype=ext4 nouveau.noaccel=1 net.ifnames=0 pcie_aspm=force [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbefc1fff] usable [0.00] BIOS-e820: [mem 0xbefc2000-0xbf6c1fff] reserved [0.00] BIOS-e820: [mem 0xbf6c2000-0xbf7c1fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbf7c2000-0xbf7fefff] ACPI data [0.00] BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable [0.00] BIOS-e820: [mem 0xbf80-0xbfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed13fff] reserved [0.00] BIOS-e820: [mem 0xfed19000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1b000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffd0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x0001fbff] usable [0.00] BIOS-e820: [mem 0x0001fc00-0x0001] reserved [0.00] BIOS-e820: [mem 0x0002-0x00023bff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: Hewlett-Packard HP EliteBook 8540w/1521, BIOS 68CVD Ver. F.0E 11/25/2010 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x23c000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0FFC0 mask FFFC0 write-protect [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 08000 mask FC000 write-back [0.00] 3 base 1 mask F write-back [0.00] 4 base 2 mask FC000 write-back [0.00] 5 base 23C00 mask FFC00 uncachable [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: last_pfn = 0xbf800 max_arch_pfn = 0x4 [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x02371000, 0x02371fff] PGTABLE [0.00] BRK [0x02372000, 0x02372fff] PGTABLE [0.00]
Re: [BUG] nouveau regression: ext monitor dead after resume
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 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] nouveau regression: ext monitor dead after resume
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 to make a sensible merge were futile. If you can send me a patch that reverts the changes on 3.17-rc5 or 3.16 I am glad to try it out and give you the requested feedback. 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 FAQ at http://www.tux.org/lkml/
Re: [BUG] nouveau regression: ext monitor dead after resume
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" 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] nouveau regression: ext monitor dead after resume
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 should be complete. But I can give it another try on Monday when I'm back in the office. 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 FAQ at http://www.tux.org/lkml/
Re: [BUG] nouveau regression: ext monitor dead after resume
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 info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xfrm: is pmtu broken with ESP tunneling?
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. The COUNT doesn't reflect the number packets that I am missing. LOCATIONOFFSET COUNT ieee80211_iface_work 208 1 Strange that the problem disappears if you enable no_pmtu_disc then. It seems with PMTU the initial mtu is the one of the device (1500). So the original packet will have that size, but is subsequently wrapped into ESP and UDP, which add to that size. And the final packet is then larger than the device MTU... I know nothing about the ip / xfrm kernel code, so it's hard for me to verify if that theory is real. 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 info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bisected] drm/radeon: fences regression
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: [7.719140] [drm] UVD initialized successfully. Video playback was never a problem. I can use mplayer with the vdpau backend, or VLC with the VA-API backend to play H.264 videos with no problem. I don't know exactly if that uses UVD. No idea how to verify. On the other hand the failed UVD init shouldn't affect the rest of the system (3D should work fine), so there is really something odd here. My guess is, the UVD init failure is not the cause, but the result of fences code or reset detection not working properly any more. The text output (console fb) is still fine. But when it starts Xorg the login screen is mostly black with some colored squares where the widgets of the login screen are, and a properly rendered and working mouse cursor sprite. Also there are delays when starting up Xorg during which the screen goes black - I think it's waiting for fences. When I login (KDE with compositing) the screen goes black and the monitor makes a sound like not properly sync'ing. Then it looks like the kernel hangs. Please open up a bug report on https://bugs.freedesktop.org/enter_bug.cgi?product=DRI component DRM/Radeon and attach at least the full dmesg output of 3.13 as well as 3.12. https://bugs.freedesktop.org/show_bug.cgi?id=76501 -- 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/
BUG at mm/memory.c
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 16:59:47 toaster kernel: [ cut here ] Jun 17 16:59:47 toaster kernel: kernel BUG at mm/memory.c:3924! Jun 17 16:59:47 toaster kernel: invalid opcode: [#1] PREEMPT SMP Jun 17 16:59:47 toaster kernel: Modules linked in: iTCO_wdt iTCO_vendor_support Jun 17 16:59:47 toaster kernel: CPU: 14 PID: 13058 Comm: qemu-system-x86 Not tainted 3.15.0 #1 Jun 17 16:59:47 toaster kernel: Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014 Jun 17 16:59:47 toaster kernel: task: 880ffcef8000 ti: 88065873c000 task.ti: 88065873c000 Jun 17 16:59:47 toaster kernel: RIP: 0010:[] [] handle_mm_fault+0xc92/0xdb0 Jun 17 16:59:47 toaster kernel: RSP: 0018:88065873f968 EFLAGS: 00010246 Jun 17 16:59:47 toaster kernel: RAX: 80092e0001e6 RBX: 7fa0d2c2 RCX: 88065873f6f0 Jun 17 16:59:47 toaster kernel: RDX: 0100 RSI: 0009 RDI: 004352da Jun 17 16:59:47 toaster kernel: RBP: 88065873f9f8 R08: R09: 0d88 Jun 17 16:59:47 toaster kernel: R10: 0019 R11: R12: 880179943140 Jun 17 16:59:47 toaster kernel: R13: 0800 R14: 88069ac9d4b0 R15: 88109a7a8a80 Jun 17 16:59:47 toaster kernel: FS: 7fa1ad61c700() GS:88089fd0() knlGS: Jun 17 16:59:47 toaster kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 17 16:59:47 toaster kernel: CR2: 7f6a20743000 CR3: 0009582aa000 CR4: 001427e0 Jun 17 16:59:47 toaster kernel: Stack: Jun 17 16:59:47 toaster kernel: 8808df251b88 88049543a540 0f08 7fa0d33e1000 Jun 17 16:59:47 toaster kernel: 88065873f9f8 0019 8003076fd067 880958268418 Jun 17 16:59:47 toaster kernel: d33e1fff 0f08 88069ac9d4b0 0001d2c2 Jun 17 16:59:47 toaster kernel: Call Trace: Jun 17 16:59:47 toaster kernel: [] __get_user_pages+0x156/0x5f0 Jun 17 16:59:47 toaster kernel: [] __gfn_to_pfn_memslot+0x15c/0x3e0 Jun 17 16:59:47 toaster kernel: [] ? emulator_read_write+0x110/0x180 Jun 17 16:59:47 toaster kernel: [] __gfn_to_pfn+0x60/0x70 Jun 17 16:59:47 toaster kernel: [] gfn_to_pfn_async+0x1a/0x20 Jun 17 16:59:47 toaster kernel: [] try_async_pf+0x4a/0x230 Jun 17 16:59:47 toaster kernel: [] tdp_page_fault+0x103/0x1f0 Jun 17 16:59:47 toaster kernel: [] kvm_mmu_page_fault+0x31/0x100 Jun 17 16:59:47 toaster kernel: [] handle_ept_violation+0x96/0x180 Jun 17 16:59:47 toaster kernel: [] vmx_handle_exit+0xb5/0xa30 Jun 17 16:59:47 toaster kernel: [] ? vmx_handle_external_intr+0x66/0x70 Jun 17 16:59:47 toaster kernel: [] ? vmx_invpcid_supported+0x20/0x20 Jun 17 16:59:47 toaster kernel: [] kvm_arch_vcpu_ioctl_run+0xc45/0x1120 Jun 17 16:59:47 toaster kernel: [] ? kvm_arch_vcpu_load+0x4e/0x1e0 Jun 17 16:59:47 toaster kernel: [] kvm_vcpu_ioctl+0x2f4/0x580 Jun 17 16:59:47 toaster kernel: [] ? fsnotify+0x22c/0x2f0 Jun 17 16:59:47 toaster kernel: [] do_vfs_ioctl+0x83/0x510 Jun 17 16:59:47 toaster kernel: [] ? __fget+0x79/0xb0 Jun 17 16:59:47 toaster kernel: [] SyS_ioctl+0x4c/0x90 Jun 17 16:59:47 toaster kernel: [] system_call_fastpath+0x16/0x1b Jun 17 16:59:47 toaster kernel: Code: 49 8b 55 00 e9 1c f4 ff ff 48 89 c7 e8 58 26 fe ff e9 51 f6 ff ff f6 42 51 01 0f 85 c9 fc ff ff 41 bd 02 00 00 00 e9 47 f6 ff ff <0f> 0b 48 89 d9 4c 89 f2 4c 89 e6 4c 89 ff 44 89 55 98 e8 07 b7 Jun 17 16:59:47 toaster kernel: RIP [] handle_mm_fault+0xc92/0xdb0 Jun 17 16:59:47 toaster kernel: RSP Jun 17 16:59:47 toaster kernel: kernel BUG at arch/x86/mm/pageattr.c:216! Jun 17 16:59:47 toaster kernel: invalid opcode: [#2] PREEMPT SMP Jun 17 16:59:47 toaster kernel: Modules linked in: iTCO_wdt iTCO_vendor_support Jun 17 16:59:47 toaster kernel: CPU: 14 PID: 13058 Comm: qemu-system-x86 Not tainted 3.15.0 #1 Jun 17 16:59:47 toaster kernel: Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014 Jun 17 16:59:47 toaster kernel: task: 880ffcef8000 ti: 88065873c000 task.ti: 88065873c000 Jun 17 16:59:47 toaster kernel: RIP: 0010:[] [] change_page_attr_set_clr+0x469/0x470 Jun 17 16:59:47 toaster kernel: RSP: 0018:88065873ec68 EFLAGS: 00010046 Jun 17 16:59:47 toaster kernel: RAX: 0046 RBX: RCX: 0005 Jun 17 16:59:47 toaster kernel: RDX: RSI: RDI: 8000 Jun 17 16:59:47 toaster kernel: RBP: 88065873ed18 R08: 8000 R09: Jun 17 16:59:47 toaster kernel: R10: 88016d95a000 R11: 0001 R12: Jun 17 16:59:47 toaster kernel: R13: R14:
Re: BUG at mm/memory.c
On 06/19/2014 06:52 PM, Kirill A. Shutemov wrote: http://marc.info/?l=linux-kernel&m=140319579508104&w=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 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.14 regression: huge latency in read/select on tun
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 Yasevich Date: Thu Mar 27 17:26:18 2014 -0400 net: Account for all vlan headers in skb_mac_gso_segment skb_network_protocol() already accounts for multiple vlan headers that may be present in the skb. However, skb_mac_gso_segment() doesn't know anything about it and assumes that skb->mac_len is set correctly to skip all mac headers. That may not always be the case. If we are simply forwarding the packet (via bridge or macvtap), all vlan headers may not be accounted for. A simple solution is to allow skb_network_protocol to return the vlan depth it has calculated. This way skb_mac_gso_segment will correctly skip all mac headers. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller :04 04 6066ee76dd70dde2f4675155579e550d29ba0216 2196ebff4f9a8b909617dd57beeaa76cbafc8525 M include :04 04 20fdfb5efc1ada562b7899d0d58998914b1c2ff1 c398988f31e1b1b6ee56cb20b1a7becbdf782a17 M net -- 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.14 regression: huge latency in read/select on tun
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
>> Date: Thu Mar 27 17:26:18 2014 -0400
>>
>> net: Account for all vlan headers in skb_mac_gso_segment
>
> Hmm.. probably already solved by commit
> 1e785f48d29a09b6cf96db7b49b6320dada332e1
> ("net: Start with correct mac_len in skb_network_protocol")
Indeed that fixes it. I have cherry picked that onto 3.14 and it works.
That means 1e785f48 should be applied to stable 3.13.y and 3.14.y too.
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 info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
xfrm: is pmtu broken with ESP tunneling?
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
net.ipv4.ip_no_pmtu_disc=1.
May have something to do with it:
The tunneled network is 10.6.6.6/32 and I am SNAT'ing some destinations
to that IP, so they get routed through the tunnel. Any other networks
are not to go through the tunnel.
iptables -t nat -A POSTROUTING -d "${R}" -j SNAT --to-source 10.6.6.6
It seems quite clear to me that xfrm is doing something wrong here.
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 FAQ at http://www.tux.org/lkml/
[drm] 3.18 regression: backlight dark after resume
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: 73580fb764c4213d305c0d36bd8f856ae631eb42 is the first bad commit commit 73580fb764c4213d305c0d36bd8f856ae631eb42 Author: Jani Nikula Date: Tue Aug 12 17:11:41 2014 +0300 drm/i915/dp: make backlight bl_power control power sequencer backlight This lets the userspace switch off the backlight using the backlight class sysfs bl_power file. The switch is done using the power sequencer; the backlight PWM, and everything else, remains enabled. The display backlight won't draw power, but for maximum power savings the encoder needs to be switched off. Signed-off-by: Jani Nikula Reviewed_by: Clinton Taylor Tested_by: Clinton Taylor Signed-off-by: Daniel Vetter 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 info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.18-rc2 sudden strike of OOM killer
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 -/+ buffers/cache:382 3187 Swap:0 0 0 [ 97.290091] Purging GPU memory, 0 bytes freed, 12468224 bytes still pinned. [ 97.290195] X invoked oom-killer: gfp_mask=0x0, order=0, oom_score_adj=0 [ 97.290198] CPU: 2 PID: 1383 Comm: X Not tainted 3.18.0-rc2 #2 [ 97.290199] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 900X3C/900X3D/900X4C/900X4D/NP900X3D-A03CH, BIOS P02ABK 09/19/2012 [ 97.290200] 8800c48b96f8 8800bfb93c18 8192e82e [ 97.290203] 8800c48b9080 8800bfb93cb8 8192c5be 8800bfb93c88 [ 97.290205] 8148e9ee 880055aad840 8800bfb93ca8 [ 97.290207] Call Trace: [ 97.290214] [] dump_stack+0x4e/0x71 [ 97.290216] [] dump_header.isra.12+0x6e/0x1f0 [ 97.290221] [] ? i915_gem_shrinker_oom+0x18e/0x200 [ 97.290225] [] ? ___ratelimit+0x96/0x110 [ 97.290229] [] oom_kill_process+0x222/0x3b0 [ 97.290232] [] ? has_capability_noaudit+0x17/0x20 [ 97.290234] [] out_of_memory+0x2af/0x320 [ 97.290237] [] pagefault_out_of_memory+0x30/0x50 [ 97.290239] [] mm_fault_error+0xb8/0x160 [ 97.290241] [] __do_page_fault+0x441/0x4d0 [ 97.290245] [] ? rcu_eqs_enter+0x73/0xa0 [ 97.290249] [] ? acct_account_cputime+0x1c/0x20 [ 97.290252] [] ? account_user_time+0x8b/0xa0 [ 97.290254] [] ? vtime_account_user+0x5d/0x70 [ 97.290255] [] do_page_fault+0x5b/0x80 [ 97.290259] [] page_fault+0x22/0x30 [ 97.290260] Mem-Info: [ 97.290261] DMA per-cpu: [ 97.290262] CPU0: hi:0, btch: 1 usd: 0 [ 97.290263] CPU1: hi:0, btch: 1 usd: 0 [ 97.290263] CPU2: hi:0, btch: 1 usd: 0 [ 97.290264] CPU3: hi:0, btch: 1 usd: 0 [ 97.290265] DMA32 per-cpu: [ 97.290265] CPU0: hi: 186, btch: 31 usd: 0 [ 97.290266] CPU1: hi: 186, btch: 31 usd: 0 [ 97.290267] CPU2: hi: 186, btch: 31 usd: 41 [ 97.290268] CPU3: hi: 186, btch: 31 usd: 0 [ 97.290268] Normal per-cpu: [ 97.290269] CPU0: hi: 186, btch: 31 usd: 0 [ 97.290270] CPU1: hi: 186, btch: 31 usd: 0 [ 97.290271] CPU2: hi: 186, btch: 31 usd: 0 [ 97.290271] CPU3: hi: 186, btch: 31 usd: 0 [ 97.290274] active_anon:147835 inactive_anon:719262 isolated_anon:0 active_file:1533 inactive_file:1728 isolated_file:64 unevictable:0 dirty:1654 writeback:0 unstable:0 free:20872 slab_reclaimable:5177 slab_unreclaimable:4623 mapped:11728 shmem:722103 pagetables:5799 bounce:0 free_cma:0 [ 97.290278] DMA free:14492kB min:292kB low:364kB high:436kB active_anon:272kB inactive_anon:852kB active_file:12kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15984kB managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:868kB slab_reclaimable:32kB slab_unreclaimable:24kB kernel_stack:48kB pagetables:16kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no [ 97.290279] lowmem_reserve[]: 0 3118 3551 3551 [ 97.290285] DMA32 free:60892kB min:59092kB low:73864kB high:88636kB active_anon:521180kB inactive_anon:2533616kB active_file:5248kB inactive_file:5492kB unevictable:0kB isolated(anon):0kB isolated(file):256kB present:3276724kB managed:3196196kB mlocked:0kB dirty:5332kB writeback:0kB mapped:43348kB shmem:2543532kB slab_reclaimable:17536kB slab_unreclaimable:13132kB kernel_stack:3904kB pagetables:19656kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:1916 all_unreclaimable? no [ 97.290285] lowmem_reserve[]: 0 0 432 432 [ 97.290290] Normal free:8104kB min:8192kB low:10240kB high:12288kB active_anon:69888kB inactive_anon:342580kB active_file:872kB inactive_file:1408kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:514048kB managed:442908kB mlocked:0kB dirty:1284kB writeback:0kB mapped:3560kB shmem:344012kB slab_reclaimable:3140kB slab_unreclaimable:5336kB kernel_stack:1552kB pagetables:3524kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:852 all_unreclaimable? no [ 97.290291] lowmem_reserve[]: 0 0 0 0 [ 97.290293] DMA: 15*4kB (M) 17*8kB (UEM) 8*16kB (EM) 5*32kB (EM) 7*64kB (UEM) 0*128kB 1*256kB (U) 0*512kB 3*1024kB (UEM) 3*2048kB (EMR) 1*4096kB (M) = 14500kB [ 97.290302] DMA32: 2454*4kB (UEM) 1333*8kB (UEM) 816*16kB (UEM) 464*32kB (UEM) 103*64kB (M) 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB (R) 1*4096kB (R) = 61120kB [ 97.290309] Normal: 499*4kB (UEM) 172*8kB (UEM) 91*16kB (UEM) 4*32kB (EM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB (R) = 9052kB [ 97.290317] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [
[PATCH v2 net] x86: bpf_jit: fix two bugs in eBPF JIT compiler
> 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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ACPI regression: New Acer workarounds break Samsung NP900X
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: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c184 From 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Thu, 21 Aug 2014 14:41:13 +0800 Subject: [PATCH] ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set From 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Thu, 21 Aug 2014 14:41:26 +0800 Subject: [PATCH] ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC 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 info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
4.1.5 oops in alloc_skb_with_frags
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 softcursor font drm_kms_helper ttm drm fb fbdev Aug 14 08:45:38 gandalf kernel: CPU: 2 PID: 2726 Comm: X Not tainted 4.1.5 #1 Aug 14 08:45:38 gandalf kernel: Hardware name: Apple Inc. iMac11,2/Mac-F2238AC8, BIOS IM112.88Z.0057.B00.100503 1455 05/03/10 Aug 14 08:45:38 gandalf kernel: task: 880092e8b020 ti: 880135248000 task.ti: 880135248000 Aug 14 08:45:38 gandalf kernel: RIP: 0010:[] [] __kmalloc_track_caller+0x76/0 x190 Aug 14 08:45:38 gandalf kernel: RSP: 0018:88013524ba88 EFLAGS: 00010202 Aug 14 08:45:38 gandalf kernel: RAX: RBX: 8800812e2f00 RCX: 9042 Aug 14 08:45:38 gandalf kernel: RDX: 903a RSI: 903a RDI: 02bf Aug 14 08:45:38 gandalf kernel: RBP: 88013524bac8 R08: 00018d80 R09: 0003 Aug 14 08:45:38 gandalf kernel: R10: 7000 R11: 0160 R12: 02c0 Aug 14 08:45:38 gandalf kernel: R13: 000106d0 R14: 01d6800b R15: 880137001780 Aug 14 08:45:38 gandalf kernel: FS: 7f5233ea1880() GS:88013bc8() knlGS: Aug 14 08:45:38 gandalf kernel: CS: 0010 DS: ES: CR0: 80050033 Aug 14 08:45:38 gandalf kernel: CR2: 01d6800b CR3: 00013528b000 CR4: 06e0 Aug 14 08:45:38 gandalf kernel: Stack: Aug 14 08:45:38 gandalf kernel: 8801 8164defd 88013524bae8 8800812e2f00 Aug 14 08:45:38 gandalf kernel: 88013524bb27 04d0 02c0 Aug 14 08:45:38 gandalf kernel: 88013524bb08 8164de3c 880136799300 8800812e2f00 Aug 14 08:45:38 gandalf kernel: Call Trace: Aug 14 08:45:38 gandalf kernel: [] ? __alloc_skb+0x6d/0x1c0 Aug 14 08:45:38 gandalf kernel: [] __kmalloc_reserve.isra.43+0x2c/0x80 Aug 14 08:45:38 gandalf kernel: [] __alloc_skb+0x6d/0x1c0 Aug 14 08:45:38 gandalf kernel: [] alloc_skb_with_frags+0x57/0x200 Aug 14 08:45:38 gandalf kernel: [] ? sock_wfree+0x53/0x60 Aug 14 08:45:38 gandalf kernel: [] sock_alloc_send_pskb+0x196/0x240 Aug 14 08:45:38 gandalf kernel: [] ? skb_copy_datagram_from_iter+0x4f/0x1f0 Aug 14 08:45:38 gandalf kernel: [] unix_stream_sendmsg+0x25a/0x3a0 Aug 14 08:45:38 gandalf kernel: [] sock_sendmsg+0x12/0x20 Aug 14 08:45:38 gandalf kernel: [] sock_write_iter+0x73/0xd0 Aug 14 08:45:38 gandalf kernel: [] do_iter_readv_writev+0x54/0x70 Aug 14 08:45:38 gandalf kernel: [] do_readv_writev+0x196/0x230 Aug 14 08:45:38 gandalf kernel: [] ? __fget_light+0x20/0x70 Aug 14 08:45:38 gandalf kernel: [] ? __fget+0x6d/0xa0 Aug 14 08:45:38 gandalf kernel: [] vfs_writev+0x34/0x50 Aug 14 08:45:38 gandalf kernel: [] SyS_writev+0x45/0xd0 Aug 14 08:45:38 gandalf kernel: [] system_call_fastpath+0x12/0x6a Aug 14 08:45:38 gandalf kernel: Code: 48 89 c8 65 48 03 05 8a 5f e5 7e 48 8b 70 08 48 39 f2 75 e7 4c 8b 30 4d 85 f6 0f 84 bc 00 00 00 49 63 47 20 48 8d 4a 08 4d 8b 07 <49> 8b 1c 06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 ba 49 63 Aug 14 08:45:38 gandalf kernel: RSP Aug 14 08:45:38 gandalf kernel: CR2: 01d6800b Aug 14 08:45:38 gandalf kernel: ---[ end trace 3cf0da471519df5e ]--- -- 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/
[RESEND] nouveau regression 3.19: unable to load BIOS from ACPI
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 - shadow_image tries to validate the image contents *before* loading it via ACPI calls - nvbios_imagen calls nv_ro16 on the bios object which tries to read 16 bytes directly from memory. Before the change, the code was: - mthd->shadow(bios); - which for ACPI calls nouveau_bios_shadow_acpi which doesn't try to validate the image mthd->score = nouveau_bios_score(bios, mthd->rw); which validates the image So shadowing always happened *before* trying to look at the bios data. The relevant log is below. Ortwin 3.18: Feb 15 11:28:50 localhost kernel: nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0e63c0a1 Feb 15 11:28:50 localhost kernel: nouveau [ DEVICE][:01:00.0] Chipset: GK106 (NVE6) Feb 15 11:28:50 localhost kernel: nouveau [ DEVICE][:01:00.0] Family : NVE0 Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] ... signature not found Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PROM for image... Feb 15 11:28:50 localhost kernel: fbcon: inteldrmfb (fb0) is primary device Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] ... signature not found Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] checking ACPI for image... Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] ... appears to be valid Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] using image from ACPI Feb 15 11:28:50 localhost kernel: nouveau [ VBIOS][:01:00.0] BIT signature found 3.19: Feb 15 11:30:40 localhost kernel: VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEGP.DGFX handle Feb 15 11:30:40 localhost kernel: nouveau :01:00.0: enabling device (0004 -> 0007) Feb 15 11:30:40 localhost kernel: nouveau [ DEVICE][:01:00.0] BOOT0 : 0x0e63c0a1 Feb 15 11:30:40 localhost kernel: nouveau [ DEVICE][:01:00.0] Chipset: GK106 (NVE6) Feb 15 11:30:40 localhost kernel: nouveau [ DEVICE][:01:00.0] Family : NVE0 Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau E[ VBIOS][:01:00.0] ACPI invalid Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking (null) for image... Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying PRAMIN... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] ... not enabled Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PROM for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying PROM... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : ROM signature () unknown Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] image 0 invalid Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking ACPI for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking ACPI for image... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] trying ACPI... Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : type 00, 65536 bytes Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] : fetch failed Feb 15 11:30:40 localhost kernel: nouveau D[ VBIOS][:01:00.0] scored 0 Feb 15 11:30:40 localhost kernel: nouveau [ VBIOS][:01:00.0] checking PCIROM for image... Feb 15 11:30:40 loca
r8169 hang on 4.18
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 root=LABEL=ROOT ro rootfstype=ext4 net.ifnames=0 pci=nomsi [1.772849] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [1.772852] r8169 :07:00.0: can't disable ASPM; OS doesn't have ASPM control [1.784948] r8169 :07:00.0 eth4: RTL8168h/8111h, 50:9a:4c:2e:92:be, XID 54100800, IRQ 16 [1.784949] r8169 :07:00.0 eth4: jumbo features [frames: 9200 bytes, tx checksumming: ko] We saw the interface unresponsive twice during the last 3 days with: [Mon Sep 24 11:35:56 2018] [ cut here ] [Mon Sep 24 11:35:56 2018] NETDEV WATCHDOG: wan (r8169): transmit queue 0 timed out [Mon Sep 24 11:35:56 2018] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x215/0x220 [Mon Sep 24 11:35:56 2018] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.18.8 #70 [Mon Sep 24 11:35:56 2018] Hardware name: Dell Inc. OptiPlex 3050/0W0CHX, BIOS 1.6.5 09/09/2017 [Mon Sep 24 11:35:56 2018] RIP: 0010:dev_watchdog+0x215/0x220 [Mon Sep 24 11:35:56 2018] Code: 49 63 4c 24 e8 eb 8c 4c 89 ef c6 05 1a 19 ca 00 01 e8 5f 52 fd ff 89 d9 4c 89 ee 48 c7 c7 78 ab 67 89 48 89 c2 e8 1b 2b 49 ff <0f> 0b eb be 0f 1f 80 00 00 00 00 41 57 45 89 cf 41 56 49 89 d6 41 [Mon Sep 24 11:35:56 2018] RSP: 0018:96f05dd03e98 EFLAGS: 00010282 [Mon Sep 24 11:35:56 2018] RAX: RBX: RCX: 0006 [Mon Sep 24 11:35:56 2018] RDX: 0007 RSI: 0096 RDI: 96f05dd15350 [Mon Sep 24 11:35:56 2018] RBP: 96f0462ee41c R08: 0001 R09: 133d [Mon Sep 24 11:35:56 2018] R10: 0202 R11: R12: 96f0462ee438 [Mon Sep 24 11:35:56 2018] R13: 96f0462ee000 R14: 0001 R15: 96f0455eaa80 [Mon Sep 24 11:35:56 2018] FS: () GS:96f05dd0() knlGS: [Mon Sep 24 11:35:56 2018] CS: 0010 DS: ES: CR0: 80050033 [Mon Sep 24 11:35:56 2018] CR2: 55c9498766e0 CR3: bb80a006 CR4: 003606e0 [Mon Sep 24 11:35:56 2018] DR0: DR1: DR2: [Mon Sep 24 11:35:56 2018] DR3: DR6: fffe0ff0 DR7: 0400 [Mon Sep 24 11:35:56 2018] Call Trace: [Mon Sep 24 11:35:56 2018] [Mon Sep 24 11:35:56 2018] ? pfifo_fast_reset+0x130/0x130 [Mon Sep 24 11:35:56 2018] ? pfifo_fast_reset+0x130/0x130 [Mon Sep 24 11:35:56 2018] call_timer_fn+0x11/0x70 [Mon Sep 24 11:35:56 2018] expire_timers+0x8e/0xa0 [Mon Sep 24 11:35:56 2018] run_timer_softirq+0xb9/0x160 [Mon Sep 24 11:35:56 2018] ? __hrtimer_run_queues+0x135/0x1a0 [Mon Sep 24 11:35:56 2018] ? hw_breakpoint_pmu_read+0x10/0x10 [Mon Sep 24 11:35:56 2018] ? ktime_get+0x39/0x90 [Mon Sep 24 11:35:56 2018] ? lapic_next_event+0x20/0x20 [Mon Sep 24 11:35:56 2018] __do_softirq+0xcb/0x1f8 [Mon Sep 24 11:35:56 2018] irq_exit+0xa9/0xb0 [Mon Sep 24 11:35:56 2018] smp_apic_timer_interrupt+0x59/0x90 [Mon Sep 24 11:35:56 2018] apic_timer_interrupt+0xf/0x20 [Mon Sep 24 11:35:56 2018] [Mon Sep 24 11:35:56 2018] RIP: 0010:cpuidle_enter_state+0x129/0x200 [Mon Sep 24 11:35:56 2018] Code: 45 00 89 c3 e8 d8 3b 55 ff 65 8b 3d b1 eb 45 77 e8 8c 3a 55 ff 31 ff 49 89 c4 e8 72 43 55 ff fb 48 ba cf f7 53 e3 a5 9b c4 20 <4c> 89 e1 4c 29 e9 48 89 c8 48 c1 f9 3f 48 f7 ea b8 ff ff ff 7f 48 [Mon Sep 24 11:35:56 2018] RSP: 0018:9a93c06e7ea8 EFLAGS: 0286 ORIG_RAX: ff13 [Mon Sep 24 11:35:56 2018] RAX: 96f05dd1f800 RBX: 0003 RCX: 001f [Mon Sep 24 11:35:56 2018] RDX: 20c49ba5e353f7cf RSI: 258f0602 RDI: [Mon Sep 24 11:35:56 2018] RBP: 96f05dd25ee0 R08: 02b4 R09: [Mon Sep 24 11:35:56 2018] R10: 9a93c06e7e90 R11: 0142 R12: 00012ec849a182b9 [Mon Sep 24 11:35:56 2018] R13: 00012ec8499ddf88 R14: 0003 R15: [Mon Sep 24 11:35:56 2018] ? cpuidle_enter_state+0x11e/0x200 [Mon Sep 24 11:35:56 2018] do_idle+0x1c0/0x200 [Mon Sep 24 11:35:56 2018] cpu_startup_entry+0x6a/0x70 [Mon Sep 24 11:35:56 2018] start_secondary+0x18a/0x1c0 [Mon Sep 24 11:35:56 2018] secondary_startup_64+0xa5/0xb0 [Mon Sep 24 11:35:56 2018] ---[ end trace 327bd9c035abe307 ]--- This is the built-in ethernet port on a Dell main board: 07:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15) Subsystem: Dell RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1028:07a3] Flags: bus master, fast devsel, latency 0, IRQ 16 I/O ports at e000 [size=256] Memory at f7404000 (64-bit, non-prefetchable) [size=4K]
Re: Failover root devices
> 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 whatever method you like and finally exec switch_root /mnt/root /sbin/init "$@" See here for example scripts for initramfs: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html Above script actually makes it easy by supporting disk labels: root=LABEL=ROOT will boot the first available partition that is labelled ROOT. It is independent of the device name and works nice when you switch hardware vs. virtual machines for instance. 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 FAQ at http://www.tux.org/lkml/
Re: Failover root devices
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 relies on. On top of that, I don't think it can be done "nicely" in userspace anyway. I personally think this is opening a can of worms. Now it's just a list of alternative root devices. But the kernel knows absolutely nothing about these. When is it fine to try an alternative? Why did the first one not work? Did we just not wait long enough? Or is it a failed RAID device? Or is it an encrypted disk that needs setup? Or is it on NFS and the network is not available (or we are lacking driver firmware)? It could actually introduce security problems: if I know that a device will fallback to an alternative root (under my control), I can try and DOS the primary root. In short: if a simple root device doesn't work for you, you should *really* use an initramfs. One could even argue to remove the boot= parameter altogether and always use initramfs :-) 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 FAQ at http://www.tux.org/lkml/
Re: Failover root devices
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 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: EXT4: new warnings from 4.3.0-rc2
> [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 mount_block_root()). Since the removal of ext3, now the ext4 code is responsbile for mounting ext3. Since your FS is ext4 and not ext3, the probe for ext3 fails. That's what the message tells you. You get these even in previous kernels if you say N to ext3 during config. If it bugs you, you can add a hint to your kernel command line: rootfstype=ext4 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 FAQ at http://www.tux.org/lkml/
dst refcount is -1
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
Re: dst refcount is -1
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 there is steady traffic on most of them. What kind of traffic is running? IPv4? IPv6? Or Both? Do you use xfrm? The machine has 10 IPv4 interfaces (via usb) and runs about 30 ipsec VPNs with total maybe 200 tunnels (xfrm). No real IPv6 traffic, just the usual link-local stuff that you see on any network. Ortwin
Re: dst refcount is -1
Possibly this recent patch in master fixes it: d2950278d2 (xfrm: put policies when reusing pcpu xdst entry)
ath9k: insufficient skb len
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
ieee80211_rx_napi+0x814/0x9a0
[Tue Nov 21 06:00:36 2017] Modules linked in: radeon ttm
[Tue Nov 21 06:00:36 2017] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0 #1
[Tue Nov 21 06:00:36 2017] Hardware name: Apple Inc. iMac11,2/Mac-F2238AC8, BIOS
IM112.88Z.0057.B00.1005031455 05/03/10
[Tue Nov 21 06:00:36 2017] task: a8e0f4c0 task.stack: a8e0
[Tue Nov 21 06:00:36 2017] RIP: 0010:ieee80211_rx_napi+0x814/0x9a0
[Tue Nov 21 06:00:36 2017] RSP: 0018:915efbc03d68 EFLAGS: 00010246
[Tue Nov 21 06:00:36 2017] RAX: 0001 RBX: 915eec76e100 RCX:
[Tue Nov 21 06:00:36 2017] RDX: 0004 RSI: 0001 RDI:
915ee9d94740
[Tue Nov 21 06:00:36 2017] RBP: 915ee9d94740 R08: R09:
[Tue Nov 21 06:00:36 2017] R10: 000b R11: 0001 R12:
[Tue Nov 21 06:00:36 2017] R13: R14: 915eec76e100 R15:
915ee9d95500
[Tue Nov 21 06:00:36 2017] FS: ()
GS:915efbc0() knlGS:
[Tue Nov 21 06:00:36 2017] CS: 0010 DS: ES: CR0: 80050033
[Tue Nov 21 06:00:36 2017] CR2: 0170b208 CR3: 51e0a003 CR4:
000206f0
[Tue Nov 21 06:00:36 2017] Call Trace:
[Tue Nov 21 06:00:36 2017]
[Tue Nov 21 06:00:36 2017] ? __build_skb+0x20/0xe0
[Tue Nov 21 06:00:36 2017] ? __netdev_alloc_skb+0x9d/0xd0
[Tue Nov 21 06:00:36 2017] ? ath9k_cmn_rx_skb_postprocess+0x44/0x120
[Tue Nov 21 06:00:36 2017] ath_rx_tasklet+0x9f9/0xe50
[Tue Nov 21 06:00:36 2017] ath9k_tasklet+0x1d0/0x230
[Tue Nov 21 06:00:36 2017] tasklet_action+0x8c/0xa0
[Tue Nov 21 06:00:36 2017] __do_softirq+0xcf/0x1c3
[Tue Nov 21 06:00:36 2017] irq_exit+0xa3/0xb0
[Tue Nov 21 06:00:36 2017] do_IRQ+0x45/0xc0
[Tue Nov 21 06:00:36 2017] common_interrupt+0x89/0x89
[Tue Nov 21 06:00:36 2017]
[Tue Nov 21 06:00:36 2017] RIP: 0010:cpuidle_enter_state+0x15d/0x1f0
[Tue Nov 21 06:00:36 2017] RSP: 0018:a8e03e90 EFLAGS: 0282
ORIG_RAX: ff2e
[Tue Nov 21 06:00:36 2017] RAX: 915efbc18880 RBX: 915efbc1eee8 RCX:
001f
[Tue Nov 21 06:00:36 2017] RDX: 20c49ba5e353f7cf RSI: 29d8003a RDI:
[Tue Nov 21 06:00:36 2017] RBP: 299aa6ed0d94 R08: 915efbc15a84 R09:
0018
[Tue Nov 21 06:00:36 2017] R10: 14a6 R11: 0a11 R12:
0004
[Tue Nov 21 06:00:36 2017] R13: 299aa6c473ad R14: 0004 R15:
a8e56518
[Tue Nov 21 06:00:36 2017] do_idle+0xd6/0x170
[Tue Nov 21 06:00:36 2017] cpu_startup_entry+0x6a/0x70
[Tue Nov 21 06:00:36 2017] start_kernel+0x47e/0x49e
[Tue Nov 21 06:00:36 2017] secondary_startup_64+0xa5/0xa5
[Tue Nov 21 06:00:36 2017] Code: 48 85 c0 0f 84 77 fb ff ff 48 8b 54 24 38 4c 8b bb d0 00 00 00 4c
8b 82 d0 00 00 00 e9 5d fa ff ff 44 8b 64 24 24 e9 62 fe ff ff <0f> ff 48 89 df e8 52 c4 e0 ff e9 4e
fb ff ff 0f ff e9 b0 f8 ff
[Tue Nov 21 06:00:36 2017] ---[ end trace 023f67413980a151 ]---
rx.c:
if (ieee80211_hw_check(&local->hw, RX_INCLUDES_FCS)) {
if (unlikely(origskb->len <= FCS_LEN)) {
/* driver bug */
WARN_ON(1);
dev_kfree_skb(origskb);
return NULL;
}
present_fcs_len = FCS_LEN;
}
