Bug#691064: [3.0->3.1.y regression] Blank screen between earliest boot messages and X.
Hi Boris, Boris Barbour wrote: > When booting 3.5-trunk-amd64 and 3.1.0-1-amd64 but not 3.0.0-1-amd64 > the boot messages disappear early on (at switch to graphics > console?), roughly after udev gets started. There is just a blank > screen until X starts, after which everything works. Please report this upstream following instructions from [1] and let us know the bug number so we can track it. Thanks and hope that helps, Jonathan [1] http://intellinuxgraphics.org/how_to_report_bug.html -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121021060657.GA26243@elie.Belkin
Bug#681280: kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out
Jonathan Nieder wrote:
> Julian Gilbey wrote [regarding sky2 tx stalls]:
>> I think this may be a hardware fault: I have now identified what
>> appears to be the physical situation under which this bug manifests
>> itself: it reliably occurs when I attempt to connect to an ethernet
>> without my power supply connected (i.e., running from the battery),
>> and never seems to occur when I am on main power.
>
> Weird. How reproducible is this? Does passing sky2.legacy_pme=1 on
> the kernel command line help?
Scratch that. The legacy_pme setting should only affect wake-on-LAN.
The only interesting recent sky2 patch I can find upstream is
v3.6-rc1~125^2~264 (sky2: Fix for interrupt handler, 2012-07-03). How
does a kernel with that patch applied behave?
A 3.6.y kernel should be hitting experimental this weekend, or
if you'd like to try the patch before then, see [1].
Thanks again for your help and sorry for the slow reply.
Sincerely,
Jonathan
[1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2
From: Mirko Lindner
Date: Tue, 3 Jul 2012 23:38:46 +
Subject: sky2: Fix for interrupt handler
commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream.
Re-enable interrupts if it is not our interrupt
Signed-off-by: Mirko Lindner
Signed-off-by: David S. Miller
Signed-off-by: Jonathan Nieder
---
drivers/net/ethernet/marvell/sky2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c
b/drivers/net/ethernet/marvell/sky2.c
index 11ddd8383315..69fc888c09e9 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -3060,8 +3060,10 @@ static irqreturn_t sky2_intr(int irq, void *dev_id)
/* Reading this mask interrupts as side effect */
status = sky2_read32(hw, B0_Y2_SP_ISRC2);
- if (status == 0 || status == ~0)
+ if (status == 0 || status == ~0) {
+ sky2_write32(hw, B0_Y2_SP_ICR, 2);
return IRQ_NONE;
+ }
prefetch(&hw->st_le[hw->st_idx]);
--
1.8.0.rc3
Processed: Re: kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out
Processing commands for cont...@bugs.debian.org: > tags 687791 - unreproducible Bug #687791 [src:linux] sky2: TX watchdog timeout on Yukon-2 FE+ Removed tag(s) unreproducible. > forcemerge 681280 687791 Bug #681280 [src:linux] kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out Bug #681280 [src:linux] kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out Marked as found in versions linux/3.2.23-1. Bug #687791 [src:linux] sky2: TX watchdog timeout on Yukon-2 FE+ Severity set to 'important' from 'normal' Marked as found in versions linux/3.2.21-3. Merged 681280 687791 > End of message, stopping processing here. Please contact me if you need assistance. -- 681280: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681280 687791: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687791 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13507972581156.transcr...@bugs.debian.org
Bug#681280: kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out
Hi, Julian Gilbey wrote [regarding sky2 tx stalls]: > I think this may be a hardware fault: I have now identified what > appears to be the physical situation under which this bug manifests > itself: it reliably occurs when I attempt to connect to an ethernet > without my power supply connected (i.e., running from the battery), > and never seems to occur when I am on main power. Weird. How reproducible is this? Does passing sky2.legacy_pme=1 on the kernel command line help? Curious, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121021052211.GA25624@elie.Belkin
Re: Adding armhf vexpress udebs
On Fri, 2012-10-19 at 16:52 +0200, Aurelien Jarno wrote: > Hi all, > > I have recently realized that the vexpress flavour of the armhf kernel > has been added without providing the corresponding udebs. Hence it means > that we support this platform (I guess mainly because it's a QEMU > emulated board) at the kernel level, but we don't provide any way to > install it. > > The patch below fixes this issue, and as you can see it is almost > trivial. It's based on the mx5 flavour, with some minor tweaks at the > USB level (this platform don't provide USB support) Sure it has USB (or can have it). Maybe QEMU doesn't emulate that properly. > and at the NIC > level (to provide a udeb containing the default NIC). Then it should be > quite easy to add debian-installer support for this flavour. > > Is such a patch acceptable, despite the freeze? If yes please tell me > when it can be committed. I would expect this to be acceptable, but will await approval from the release team. [...] > Index: installer/armhf/modules/armhf-vexpress/reiserfs-modules > === > --- installer/armhf/modules/armhf-vexpress/reiserfs-modules > +++ installer/armhf/modules/armhf-vexpress/reiserfs-modules > @@ -0,0 +1 @@ > +#include [...] > Index: installer/armhf/modules/armhf-vexpress/minix-modules > === > --- installer/armhf/modules/armhf-vexpress/minix-modules > +++ installer/armhf/modules/armhf-vexpress/minix-modules > @@ -0,0 +1 @@ > +#include [...] Let's stop adding crap like this to new architectures/flavours. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
Per Foreby wrote: > Next thing to try is to blacklist the i915 module, but it doesn't seem to > work. This is what I did: > > # echo "blacklist i915" > /etc/modprobe.d/i915-blacklist.conf > # depmod -ae -F /boot/System.map-3.2.0-3-amd64 > # update-initramfs -u -k all > > Module still loads. Does the i915 module still load if you boot in recovery mode (kernel 'single' or 'text')? If so, please attach lsmod output and output from "grep . /etc/modprobe.d/*". Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121021024821.GA24782@elie.Belkin
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
New freeze after a few hours (vanilla kernel, 64 MB GPU Memory). Next thing to try is to blacklist the i915 module, but it doesn't seem to work. This is what I did: # echo "blacklist i915" > /etc/modprobe.d/i915-blacklist.conf # depmod -ae -F /boot/System.map-3.2.0-3-amd64 # update-initramfs -u -k all Module still loads. Tried adding modprobe.blacklist=i915 to the kernel command line, but still no success. What am I doing wrong here? /Pre -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50835b12.4010...@foreby.se
Bug#681280: kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out
On Tue, Jul 17, 2012 at 08:12:10AM +0100, Julian Gilbey wrote: > On Wed, Jul 11, 2012 at 11:16:39PM +0100, Julian Gilbey wrote: > > I've had numerous occasions in at least the last month (from kernel > > 3.2.19-1 or earlier - that's as far back as my logs go) when my > > machine has given a kernel error when trying to connect to a > > Windows-driven ethernet. (I hadn't realised that it was a kernel > > issue until very recently.) Below is a typical kernel log from boot > > until the "crash" occurred; my machine was connected to the ethernet > > during this process. It is sporadic - it sometimes works fine and > > othertimes not at all, and it sometimes works and then stops working. > > A followup on this bug. I've started noticing it on my home network > with no Windows machine involved - it can occur within minutes of > booting. The only machines present on the local network are two linux > boxes and a Netgear router. I think this may be a hardware fault: I have now identified what appears to be the physical situation under which this bug manifests itself: it reliably occurs when I attempt to connect to an ethernet without my power supply connected (i.e., running from the battery), and never seems to occur when I am on main power. So that is why I think this is a hardware fault - I guess the bug should then be closed? Julian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121020213655.ga32...@d-and-j.net
Bug#691064: linux-image-3.5-trunk-amd64: Blank screen between earliest boot messages and X.
Package: src:linux Version: 3.5.2-1~experimental.1 Severity: normal Hi, When booting 3.5-trunk-amd64 and 3.1.0-1-amd64 but not 3.0.0-1-amd64 the boot messages disappear early on (at switch to graphics console?), roughly after udev gets started. There is just a blank screen until X starts, after which everything works. The timing and problem seem rather like #681743, but adjusting the brightness controls don't make any boot messages appear for me. -- Package-specific info: ** Version: Linux version 3.5-trunk-amd64 (Debian 3.5.2-1~experimental.1) (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Mon Aug 20 04:17:46 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.5-trunk-amd64 root=UUID=59d895fb-43e5-417b-bf49-c2824431a9ed ro quiet ** Not tainted ** Kernel log: [3.475787] intel_rng: FWH not detected [3.486791] Bluetooth: Core ver 2.16 [3.486822] NET: Registered protocol family 31 [3.486825] Bluetooth: HCI device and connection manager initialized [3.486829] Bluetooth: HCI socket layer initialized [3.486832] Bluetooth: L2CAP socket layer initialized [3.486840] Bluetooth: SCO socket layer initialized [3.500337] input: PC Speaker as /devices/platform/pcspkr/input/input5 [3.502533] usbcore: registered new interface driver btusb [3.510832] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2) [3.513526] ACPI Warning: 0xf400b410-0xf400b414 SystemMemory conflicts with Region \RCRB 1 (20120320/utaddress-251) [3.513540] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [3.513544] lpc_ich: Resource conflict(s) found affecting iTCO_wdt [3.515124] microcode: CPU0 sig=0x6f2, pf=0x20, revision=0x57 [3.538282] yenta_cardbus :02:01.0: CardBus bridge found [1028:0201] [3.561817] kvm: disabled by bios [3.604965] coretemp coretemp.0: Using relative temperature scale! [3.604994] coretemp coretemp.0: Using relative temperature scale! [3.621520] input: Dell WMI hotkeys as /devices/virtual/input/input6 [3.634000] leds_ss4200: no LED devices found [3.634301] cfg80211: Calling CRDA to update world regulatory domain [3.659526] [drm] Initialized drm 1.1.0 20060810 [3.665016] yenta_cardbus :02:01.0: ISA IRQ mask 0x0cb8, PCI irq 19 [3.665026] yenta_cardbus :02:01.0: Socket status: 3006 [3.665034] pci_bus :02: Raising subordinate bus# of parent bus (#02) from #03 to #06 [3.665051] yenta_cardbus :02:01.0: pcmcia: parent PCI bridge window: [io 0x5000-0x5fff] [3.665057] yenta_cardbus :02:01.0: pcmcia: parent PCI bridge window: [mem 0xefb0-0xefbf] [3.665063] pcmcia_socket pcmcia_socket0: cs: memory probe 0xefb0-0xefbf: [3.665087] excluding 0xefbf-0xefbf [3.665096] yenta_cardbus :02:01.0: pcmcia: parent PCI bridge window: [mem 0x8000-0x83ff pref] [3.665101] pcmcia_socket pcmcia_socket0: cs: memory probe 0x8000-0x83ff: [3.665127] excluding 0x8000-0x83ff [3.706768] microcode: CPU1 sig=0x6f2, pf=0x20, revision=0x57 [3.726361] microcode: Microcode Update Driver: v2.00 , Peter Oruba [3.728409] kvm: disabled by bios [3.749869] i915 :00:02.0: setting latency timer to 64 [3.753079] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:s [3.753084] iwl3945: Copyright(c) 2003-2011 Intel Corporation [3.774163] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [3.774167] [drm] Driver supports precise vblank timestamp query. [3.774288] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [3.809727] iwl3945 :0c:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels [3.809735] iwl3945 :0c:00.0: Detected Intel Wireless WiFi Link 3945ABG [3.809903] iwl3945 :0c:00.0: irq 43 for MSI/MSI-X [3.810207] Registered led device: phy0-led [3.818061] ieee80211 phy0: Selected rate control algorithm 'iwl-3945-rs' [3.826271] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f: [3.826288] excluding 0xc-0xc 0xe-0xf [3.826343] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa000-0xa0ff: [3.826373] clean. [3.826401] pcmcia_socket pcmcia_socket0: cs: memory probe 0x6000-0x60ff: [3.826434] excluding 0x6000-0x60ff [3.945089] cfg80211: World regulatory domain updated: [3.945095] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [3.945100] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) [3.945105] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [3.945109] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) [3.945113] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (30
Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze
On 2012-10-20 00:39, Per Foreby wrote: I noticed something strange with allocation of GPU RAM. In the old BIOS, the default was 64 MB, but in the new bios, "Auto" was default. So I set it explicitly to 64 MB. However, this is what the OS reports: # lspci -vv ... 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) ... Region 0: Memory at f780 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] ... # dmesg | grep aperture [0.00] Checking aperture... [1.644376] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000 # grep -i mem /var/log/Xorg.0.log [18.557] (--) PCI:*(0:0:2:0) 8086:0162:1043:84ca rev 9, Mem @ 0xf780/4194304, 0xe000/268435456, I/O @ 0xf000/64 (268435456 is 256*1024*1024.) I changed the "iGPU memory" setting to 64 MB once more, and rebooted with the 3.5.5 kernel to see how much memory was reported. No change from 3.2.0 - everything still says 256 MB. Could this be the problem? As Ingo reported, his problem disappeared with 256 MB GPU memory, and for me it took much longer for the next crash to occur, so maybe it not entirely correct when using 256 MB, but enough to make the freeze very rare? And for my success (for 11 days) with the 3.5.5 kernel, maybe memory allocation works differently so it never (or more seldom) tries to access GPU memory that doesn't exist. Haven't tried 3.5.5 with 64 MB though. Back on 3.2.0 with 64 MB now to test this theory. /Per -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508306cf.8060...@foreby.se
Bug#595920: lxc-attach: upstream kernel namespace patches
I don't know how releated this patchset is, however it was pulled into Linus' current tree: https://github.com/mirrors/linux-2.6/commit/437589a74b6a590d175f86cf9f7b2efcee7765e7 Maybe there's someone who can have a look at this and/or do some tests with it. *t -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.DEB.2.02.1210201640430.5717@localhost
