Bug#648754: bug report created upstream
https://bugzilla.kernel.org/show_bug.cgi?id=57231 -- 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/517cda35.7040...@gmail.com
Bug#700333: Stack trace
When you do a suspend/resume cycle. OK, yes, I've found it there. The bug says The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. so I'm guessing with Thomas' patch it suspends fine now? Yeah, now I'm using a patched kernel and it's OK. So, does it mean the problem is fixed by this patch or it's just confirmed and should be fixed by another one? -- 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/925b81fa055e645546ae9d237eeb2...@yourcmc.ru
Problem booting 3.8 with root on raid on lvm
I decided to upgrade a machine to a 3.8 kernel. At the time the machine was running a mostly squeeze system. The machine failed to mount the root filesystem. At first I thought this was related to the use of uuid for the root filesystem, so I changed that to directly specifying /dev/md0 and it made no difference. I also tried a rootdelay but that also made no difference. Everything seems to happen long before the system drops me at a shell. I then tried upgrading the system to wheezy, this installed a wheezy 3.2 kernel which booted fine, however the experimental 3.8 kernel still fails to boot. Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premoun[3.531519] device-mapper: uevent: version 1.0.3 t ... done. Beg[3.536742] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-de...@redhat.com in: Mounting root file system ... Begin: Running /scripts/local-top ... Begin: Assembling all MD arrays ... mdadm: No devices listed in conf file were found. Failure: failed to assemble all arrays. done. done. Begin: Waiting for root file system ... [3.833233] ata7: SATA link down (SStatus 0 SControl 300) [3.838715] ata8: SATA link down (SStatus 0 SControl 300) [3.844202] ata5: SATA link down (SStatus 0 SControl 300) [3.849668] ata6: SATA link down (SStatus 0 SControl 300) [4.017172] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [4.024566] ata3.00: ATA-8: ST31000524AS, JC4B, max UDMA/133 [4.030258] ata3.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.037083] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [4.044454] ata3.00: configured for UDMA/133 [4.048805] ata4.00: ATA-8: ST31000524AS, JC4B, max UDMA/133 [4.048936] scsi 2:0:0:0: Direct-Access ATA ST31000524AS JC4B PQ: 0 ANSI: 5 [4.062661] ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.070007] sd 2:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [4.077757] sd 2:0:0:0: [sda] Write Protect is off [4.082628] ata4.00: configured for UDMA/133 [4.082629] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [4.092613] sda: sda1 sda2 [4.092825] sd 2:0:0:0: [sda] Attached SCSI disk [4.103593] scsi 3:0:0:0: Direct-Access ATA ST31000524AS JC4B PQ: 0 ANSI: 5 [4.111876] sd 3:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [4.119595] sd 3:0:0:0: [sdb] Write Protect is off [4.124448] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [4.133627] sd 2:0:0:0: Attached scsi generic sg0 type 0 [4.139031] sd 3:0:0:0: Attached scsi generic sg1 type 0 [4.144436] sdb: sdb1 sdb2 [4.147526] sd 3:0:0:0: [sdb] Attached SCSI disk done. Gave up waiting for root device. Common problem[ 33.682545] uhci_hcd: USB Universal Host Controller Interface driver s: - Boot args (cat /proc/cmdline) - Check[ 33.691883] usbcore: registered new interface driver usbhid rootdelay= (did[ 33.698855] usbhid: USB HID core driver the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/md1 does not exist. Dropping to a shell! BusyBox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) It appears to me that it is trying and failing to detect the raid array before the hard drives have been found then not re-trying to detect the raid array afterwards. -- 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/517d3703.4070...@p10link.net
Re: Problem booting 3.8 with root on raid
Sorry there is no lvm involved just raid. I had a brainfart when writing the topic. peter green wrote: I decided to upgrade a machine to a 3.8 kernel. At the time the machine was running a mostly squeeze system. The machine failed to mount the root filesystem. At first I thought this was related to the use of uuid for the root filesystem, so I changed that to directly specifying /dev/md0 and it made no difference. I also tried a rootdelay but that also made no difference. Everything seems to happen long before the system drops me at a shell. I then tried upgrading the system to wheezy, this installed a wheezy 3.2 kernel which booted fine, however the experimental 3.8 kernel still fails to boot. Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premoun[3.531519] device-mapper: uevent: version 1.0.3 t ... done. Beg[3.536742] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-de...@redhat.com in: Mounting root file system ... Begin: Running /scripts/local-top ... Begin: Assembling all MD arrays ... mdadm: No devices listed in conf file were found. Failure: failed to assemble all arrays. done. done. Begin: Waiting for root file system ... [3.833233] ata7: SATA link down (SStatus 0 SControl 300) [3.838715] ata8: SATA link down (SStatus 0 SControl 300) [3.844202] ata5: SATA link down (SStatus 0 SControl 300) [3.849668] ata6: SATA link down (SStatus 0 SControl 300) [4.017172] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [4.024566] ata3.00: ATA-8: ST31000524AS, JC4B, max UDMA/133 [4.030258] ata3.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.037083] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [4.044454] ata3.00: configured for UDMA/133 [4.048805] ata4.00: ATA-8: ST31000524AS, JC4B, max UDMA/133 [4.048936] scsi 2:0:0:0: Direct-Access ATA ST31000524AS JC4B PQ: 0 ANSI: 5 [4.062661] ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.070007] sd 2:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [4.077757] sd 2:0:0:0: [sda] Write Protect is off [4.082628] ata4.00: configured for UDMA/133 [4.082629] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [4.092613] sda: sda1 sda2 [4.092825] sd 2:0:0:0: [sda] Attached SCSI disk [4.103593] scsi 3:0:0:0: Direct-Access ATA ST31000524AS JC4B PQ: 0 ANSI: 5 [4.111876] sd 3:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) [4.119595] sd 3:0:0:0: [sdb] Write Protect is off [4.124448] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [4.133627] sd 2:0:0:0: Attached scsi generic sg0 type 0 [4.139031] sd 3:0:0:0: Attached scsi generic sg1 type 0 [4.144436] sdb: sdb1 sdb2 [4.147526] sd 3:0:0:0: [sdb] Attached SCSI disk done. Gave up waiting for root device. Common problem[ 33.682545] uhci_hcd: USB Universal Host Controller Interface driver s: - Boot args (cat /proc/cmdline) - Check[ 33.691883] usbcore: registered new interface driver usbhid rootdelay= (did[ 33.698855] usbhid: USB HID core driver the system wait long enough?) - Check root= (did the system wait for the right device?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/md1 does not exist. Dropping to a shell! BusyBox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off (initramfs) It appears to me that it is trying and failing to detect the raid array before the hard drives have been found then not re-trying to detect the raid array afterwards. -- 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/517d3d51.2050...@p10link.net
Re: Problem booting 3.8 with root on raid on lvm
On Sun, 2013-04-28 at 15:49 +0100, peter green wrote: I decided to upgrade a machine to a 3.8 kernel. At the time the machine was running a mostly squeeze system. The machine failed to mount the root filesystem. At first I thought this was related to the use of uuid for the root filesystem, so I changed that to directly specifying /dev/md0 and it made no difference. I also tried a rootdelay but that also made no difference. Everything seems to happen long before the system drops me at a shell. I then tried upgrading the system to wheezy, this installed a wheezy 3.2 kernel which booted fine, however the experimental 3.8 kernel still fails to boot. Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premoun[3.531519] device-mapper: uevent: version 1.0.3 t ... done. Beg[3.536742] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-de...@redhat.com in: Mounting root file system ... Begin: Running /scripts/local-top ... Begin: Assembling all MD arrays ... mdadm: No devices listed in conf file were found. Failure: failed to assemble all arrays. [...] scsi_wait_scan no longer exists, so rootdelay is the only thing to stop mdadm and other such hooks from running too early. rootdelay really is the only way to work around this at present, and you'll have to increase it until it works. It looks like about 5 seconds should do, though the late messages from uhci_hcd are odd. I think we're going to have to reintroduce scsi_wait_scan in the kernel as a temporary measure, but this is really unsustainable. mdadm (and lvm2) should be triggered by udev hooks, and initramfs-tools needs to support this rather than trying force a synchronous process. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Bug#706254: linux-image-3.2.0-4-amd64: Wheezy crashes occasionally
I've tested 3.8.5 from experimental for a day now leaving computer on always when I've left and I haven't experienced those crashes. So it's possible it's fixed on that kernel but I'll report if those happen still later.. -- 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/517d642a.5050...@netikka.fi
Processed: tagging 704933
Processing commands for cont...@bugs.debian.org: tags 704933 + pending Bug #704933 [linux-image-3.2.0-4-amd64] linux-image-3.2.0-4-amd64:amd64: system hangs when initializing primary video card (3.2.39-2 - 3.2.41-2 regression) Ignoring request to alter tags of bug #704933 to the same tags previously set thanks Stopping processing here. Please contact me if you need assistance. -- 704933: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704933 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.136717388425945.transcr...@bugs.debian.org
Bug#706355: linux-image-3.2.0-4-amd64: Kernel Panic with the new kernel during booting
Package: src:linux Version: 3.2.41-2 Severity: grave Justification: renders package unusable -- I have upgraded today from Squeeze to Debian-7.0. However, while booting in the last 3 occasions, the machine hanged twice with kernel Panic. In both the occasions, the kernel waited unusually long to load the initrd, and then complained about it and then asked to touch any key to continue. Once I touched something, it panicked. What surprises me is that if it is a initrd problem, why did it boot in 2 other occasions ? Moreover, I have been using 'vmlinuz-3.2.0-0.bpo.2-amd64' taken from backport while using Squeeze, and the machine never hanged in the last 6 months. The messages were captured with a camera and I am writing down most of it as was visible in the last screen. --- No filesystem could mount root. tried: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0, 0) Pid: 1, comm: swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.41-2 Call Trace: ... ? panic+0x95/0x1a2 ... ... ... ? gs_change+0x13/0x13 -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.41-2 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=56da2c0c-5a03-4b11-b6f3-6e15ebcb7782 ro verbose resume=/dev/sda4 ** Not tainted ** Kernel log: [1.885842] usb 2-1.5: Manufacturer: Logitech [2.200896] ata5: SATA link down (SStatus 0 SControl 300) [2.520295] ata6: SATA link down (SStatus 0 SControl 300) [2.523950] sd 0:0:0:0: [sda] 78242976 512-byte logical blocks: (40.0 GB/37.3 GiB) [2.524064] sd 0:0:0:0: [sda] Write Protect is off [2.524128] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [2.524146] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [2.524629] input: Logitech USB Optical Mouse as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/input/input1 [2.524836] generic-usb 0003:046D:C06A.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-:00:1d.0-1.5/input0 [2.524936] usbcore: registered new interface driver usbhid [2.525001] usbhid: USB HID core driver [2.530135] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray [2.530227] cdrom: Uniform CD-ROM driver Revision: 3.20 [2.530429] sr 1:0:0:0: Attached scsi CD-ROM sr0 [2.564825] sda: sda1 sda2 sda3 sda4 [2.565453] sd 0:0:0:0: [sda] Attached SCSI disk [2.567646] sd 0:0:0:0: Attached scsi generic sg0 type 0 [2.567772] sr 1:0:0:0: Attached scsi generic sg1 type 5 [3.364096] Btrfs loaded [3.488917] PM: Starting manual resume from disk [3.488982] PM: Hibernation image partition 8:4 present [3.488984] PM: Looking for hibernation image. [3.504857] PM: Image not found (code -22) [3.504859] PM: Hibernation image not present or could not be loaded. [3.544870] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [5.666963] udevd[358]: starting version 175 [6.078839] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2 [6.078927] ACPI: Power Button [PWRB] [6.079040] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [6.079119] ACPI: Power Button [PWRF] [6.266960] ACPI: Requesting acpi_cpufreq [6.376480] input: PC Speaker as /devices/platform/pcspkr/input/input4 [6.535696] parport_pc 00:08: reported by Plug and Play ACPI [6.535812] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] [6.699277] iTCO_vendor_support: vendor-support=0 [6.719670] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07 [6.719797] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS [6.873779] [drm] Initialized drm 1.1.0 20060810 [6.960195] i915 :00:02.0: setting latency timer to 64 [6.979763] mtrr: type mismatch for e000,1000 old: write-back new: write-combining [6.979845] [drm] MTRR allocation failed. Graphics performance may suffer. [6.980052] i915 :00:02.0: irq 41 for MSI/MSI-X [6.980057] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [6.980122] [drm] Driver supports precise vblank timestamp query. [6.980215] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [7.029261] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [7.353414] fbcon: inteldrmfb (fb0) is primary device [7.475416] udevd[506]: renamed network interface eth0 to eth5 [7.646037] Console: switching to colour frame buffer device 240x67 [7.653630] fb0: inteldrmfb frame buffer device [7.653657] drm: registered panic notifier [7.653718] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [7.653859] snd_hda_intel :00:1b.0: irq 42 for MSI/MSI-X [
Bug#700333: Stack trace
On Sun, Apr 28, 2013 at 05:26:07PM +0400, vita...@yourcmc.ru wrote: When you do a suspend/resume cycle. OK, yes, I've found it there. The bug says The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. so I'm guessing with Thomas' patch it suspends fine now? Yeah, now I'm using a patched kernel and it's OK. So, does it mean the problem is fixed by this patch or it's just confirmed and should be fixed by another one? Well, it makes sense to me, at least: we remove the handler on suspend so that the HPET interrupt doesn't fire. If, when the box comes up again, the pending interrupt is cleared, then all is fine - we can safely register the handler again and everyone goes about their merry way. But don't worry, if Thomas has an idea, it is almost guaranteed you'll get a proper fix soon. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/20130428190541.ga2...@pd.tnic
Processed: severity of 706355 is important
Processing commands for cont...@bugs.debian.org: severity 706355 important Bug #706355 [src:linux] linux-image-3.2.0-4-amd64: Kernel Panic with the new kernel during booting Severity set to 'important' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 706355: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706355 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.136717629512912.transcr...@bugs.debian.org
Bug#706355: linux-image-3.2.0-4-amd64: Kernel Panic with the new kernel during booting
Control: severity -1 important Control: tag -1 moreinfo On Mon, 2013-04-29 at 00:36 +0530, S. Roy wrote: Package: src:linux Version: 3.2.41-2 Severity: grave Justification: renders package unusable -- I have upgraded today from Squeeze to Debian-7.0. However, while booting in the last 3 occasions, the machine hanged twice with kernel Panic. In both the occasions, the kernel waited unusually long to load the initrd, and then complained about it and then asked to touch any key to continue. Once I touched something, it panicked. What surprises me is that if it is a initrd problem, why did it boot in 2 other occasions ? Moreover, I have been using 'vmlinuz-3.2.0-0.bpo.2-amd64' taken from backport while using Squeeze, and the machine never hanged in the last 6 months. The messages were captured with a camera and I am writing down most of it as was visible in the last screen. --- No filesystem could mount root. tried: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0, 0) [...] This panic is expected if the root filesystem could not be mounted. So the question is, why did that fail? Is the root device a simple partition or logical volume? Is the physical device attached by SATA, USB, or other means? Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#706355: linux-image-3.2.0-4-amd64: Kernel Panic with the new kernel during booting
Processing control commands: severity -1 important Bug #706355 [src:linux] linux-image-3.2.0-4-amd64: Kernel Panic with the new kernel during booting Ignoring request to change severity of Bug 706355 to the same value. tag -1 moreinfo Bug #706355 [src:linux] linux-image-3.2.0-4-amd64: Kernel Panic with the new kernel during booting Added tag(s) moreinfo. -- 706355: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706355 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.b706355.136717660414966.transcr...@bugs.debian.org
Bug#700333: Stack trace
On Sun, 28 Apr 2013, Borislav Petkov wrote: On Sun, Apr 28, 2013 at 05:26:07PM +0400, vita...@yourcmc.ru wrote: When you do a suspend/resume cycle. OK, yes, I've found it there. The bug says The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while resuming the non-boot CPUs. so I'm guessing with Thomas' patch it suspends fine now? Yeah, now I'm using a patched kernel and it's OK. So, does it mean the problem is fixed by this patch or it's just confirmed and should be fixed by another one? Well, it makes sense to me, at least: we remove the handler on suspend so that the HPET interrupt doesn't fire. If, when the box comes up again, the pending interrupt is cleared, then all is fine - we can safely register the handler again and everyone goes about their merry way. But don't worry, if Thomas has an idea, it is almost guaranteed you'll get a proper fix soon. :-) I merged a slightly better fix, you all were on cc. It's going into 3.10 and it's tagged stable, so it will show up in stable kernels soon. Thanks, tglx -- 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.LFD.2.02.1304282152220.21884@ionos
Re: Donation of a Calxeda Highbank node
On Sat, Apr 27, 2013 at 09:32:59AM +0200, Peter Palfrader wrote: On Fri, 26 Apr 2013, Steve Langasek wrote: On Fri, Apr 26, 2013 at 02:49:05PM +0200, Hector Oron wrote: Thanks, that is a very kind offer and with ARM hat on, we cannot reject the offer, it makes it very interesting as a playground machine. However, let me make some points here: * ARM porters hat: It is very interesting machine, and very useful to start experimenting with it as Debian is seeking for a full Calxeda chassis. * DSA hat: The machine shall not be a debian.org machine, so DSA could export accounts if requested. Why in the world not? I'm sure there's no requirement for debian.org machines to be hardware owned by Debian. The s390 porter machines/buildds certainly aren't; I don't see why this machine would necessarily *not* be a d.o machine managed by DSA. Of course if it's going to be DSA-administered, I'm sure DSA would want exclusive admin rights on the machine; but that's just common sense, and AIUI not excluded by the offer. The impression I got during the brief from the arm porters is that it is so far unclear how well Debian will run on this nice shiney thing. So for now it's just a test box/early porting box, and the policies and procedures that come with DSAing a machine would be more a hindrance than an asset during that stage. That's fair, though I think the explicit goal should be to get it supported by Debian *so that* it can be used as a buildd. FWIW, Ubuntu 13.04 ships with support for Highbank using (AIUI) an unmodified upstream kernel. So while there may be some porting work to be done before Debian runs out of the box on it, there's prior art and I don't imagine the porting work required will be huge. Also, if it were a d.o system, it would be /either/ a porterbox /or/ a buildd, not both. Yes, understood; and I propose that buildd is the best use for it in the long term. Whereas, as long as it's a test/play system run by the porters presumably, they can stress test is at needed, maybe run a (non-official?) buildd, while also providing porter chroots. Once we have Debian running properly on this kind of HW, I wouldn't mind taking over the machine. Though, to be really useful, we probably will try to get more than one instance, one for a porterbox, and two - ideally in different locations - for autobuilding packages. That would obviously be a pretty awesome end state. But it also obviously depends on the generosity of other donors. In the meantime, I hope we don't let the perfect be the enemy of the good here, because having even just one of these nodes available is already VERY good for us - provided we don't let it go to waste. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Donation of a Calxeda Highbank node
On Sun, 2013-04-28 at 10:30 -0700, Steve Langasek wrote: On Sat, Apr 27, 2013 at 09:32:59AM +0200, Peter Palfrader wrote: On Fri, 26 Apr 2013, Steve Langasek wrote: On Fri, Apr 26, 2013 at 02:49:05PM +0200, Hector Oron wrote: Thanks, that is a very kind offer and with ARM hat on, we cannot reject the offer, it makes it very interesting as a playground machine. However, let me make some points here: * ARM porters hat: It is very interesting machine, and very useful to start experimenting with it as Debian is seeking for a full Calxeda chassis. * DSA hat: The machine shall not be a debian.org machine, so DSA could export accounts if requested. Why in the world not? I'm sure there's no requirement for debian.org machines to be hardware owned by Debian. The s390 porter machines/buildds certainly aren't; I don't see why this machine would necessarily *not* be a d.o machine managed by DSA. Of course if it's going to be DSA-administered, I'm sure DSA would want exclusive admin rights on the machine; but that's just common sense, and AIUI not excluded by the offer. The impression I got during the brief from the arm porters is that it is so far unclear how well Debian will run on this nice shiney thing. So for now it's just a test box/early porting box, and the policies and procedures that come with DSAing a machine would be more a hindrance than an asset during that stage. That's fair, though I think the explicit goal should be to get it supported by Debian *so that* it can be used as a buildd. FWIW, Ubuntu 13.04 ships with support for Highbank using (AIUI) an unmodified upstream kernel. So while there may be some porting work to be done before Debian runs out of the box on it, there's prior art and I don't imagine the porting work required will be huge. [...] The plan of record for Debian armhf kernel support is to introduce a multi-platform 'armmp' flavour starting with Linux 3.9. So far as I know, it would be fairly easy to include Highbank support in that. Boot loader support is presumably going to require more work. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Re: Auto-loading lxfb on OLPC XO systems
Hi, Adam D. Barratt a...@adam-barratt.org.uk (20/04/2013): On Sat, 2013-04-20 at 03:28 +0100, Ben Hutchings wrote: [x86 XO systems need a framebuffer driver which udev blacklists] This will result in a regression when upgrading one of these systems from squeeze. (Although I don't think Debian kernel images have ever had complete support for them.) I've opened bug #705784 for this against udev, and Marco has said he's willing for me to NMU it. Alternately, in the kernel, I can revert the change to a module, or rename the module to evade the blacklist, but neither of those is particularly nice. But I think any kernel changes now are going to be too disruptive to the installer. A udev change might still be considered too disruptive in any case; CCing Cyril to see if he has any strong opinions. if that's just about updating debian/patches/extra_modprobeconf to remove the “blacklist lxfb” line, please go ahead with a udev NMU, and subsequent unblock/unblock-udeb/urgent. I'd rather avoid having to deal with a linux upload if that can be avoided, as Ben correctly guessed. Mraw, KiBi. signature.asc Description: Digital signature
Re: Firmware versions for Intel Wireless 6005/6205
Hi all, Adam D. Barratt a...@adam-barratt.org.uk (20/04/2013): On Sat, 2013-04-20 at 14:33 +0100, Ben Hutchings wrote: On Sat, 2013-04-20 at 14:24 +0100, Adam D. Barratt wrote: On Thu, 2013-04-18 at 04:29 +0100, Ben Hutchings wrote: (b Change the driver to request firmware ABI 5 then 4. Trivial code change, and only has a negative effect for users that installed firmware-iwlwifi from experimental. [...] Is this a significant enough issue to not consider (at least) one of (d) Postponing the fix to r1 (e) Documenting the issue [...] Presumably (b) implies a new kernel upload and therefore d-i respin? Yes. I've made the change in svn, but I'm happy to release-note this for r0. Thanks. Avoiding a respin at this stage would definitely be preferable. yeah, as noted in my lfxb reply, avoiding a respin = good. (Just confirming by mail what was discussed with Adam on IRC.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Auto-loading lxfb on OLPC XO systems
On Sun, 2013-04-28 at 22:51 +0200, Cyril Brulebois wrote: Hi, Adam D. Barratt a...@adam-barratt.org.uk (20/04/2013): On Sat, 2013-04-20 at 03:28 +0100, Ben Hutchings wrote: [x86 XO systems need a framebuffer driver which udev blacklists] This will result in a regression when upgrading one of these systems from squeeze. (Although I don't think Debian kernel images have ever had complete support for them.) I've opened bug #705784 for this against udev, and Marco has said he's willing for me to NMU it. Alternately, in the kernel, I can revert the change to a module, or rename the module to evade the blacklist, but neither of those is particularly nice. But I think any kernel changes now are going to be too disruptive to the installer. A udev change might still be considered too disruptive in any case; CCing Cyril to see if he has any strong opinions. if that's just about updating debian/patches/extra_modprobeconf to remove the “blacklist lxfb” line, please go ahead with a udev NMU, and subsequent unblock/unblock-udeb/urgent. I'd rather avoid having to deal with a linux upload if that can be avoided, as Ben correctly guessed. I've uploaded and opened an unblock bug (#706367). I didn't remember to set urgency=high, so please overide that. Do I need to do anything more? Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
i915 gen 6 GPU hangs - possible fix
Various people have reported GPU hangs on i915 gen 6 (found in Intel's 'Sandy Bridge' desktop/mobile CPUs introduced in 2011) since 3.2.39-1. This was the first version with the DRM subsystem backported from 3.4. However it also has some changes that were cc'd to stable and which I backported into 3.2.y but Greg didn't include 3.4.y. In Ubuntu, one such change has been reverted, as below. Would anyone suffering from this bug like to test this? Also, if someone could pick out those bug reports and send this to the bug reporters to test, that would be very helpful. (For reference the upstream commit being reverted was f05bb0c7b624 and in our package it's applied as the patch bugfix/x86/drm-i915-GFX_MODE-Flush-TLB-Invalidate-Mode-must-be-.patch. The bug report motivating the upstream change was https://bugzilla.kernel.org/show_bug.cgi?id=52311 and was for a post-3.7 regression, so it was very likely a mistake to apply it.) Ben. Forwarded Message From: Steve Conklin sconk...@canonical.com To: kernel-t...@lists.ubuntu.com Subject: [PATCH] Revert drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits Date: Mon, 22 Apr 2013 16:23:17 -0500 This reverts commit 30ae292ec68402c773ddc8c80f83f7cd84289a39. This has been shown to cause GPU hangs --- drivers/gpu/drm/i915/intel_ringbuffer.c |5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index c3654ff..fbaa785 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -422,11 +422,6 @@ static int init_render_ring(struct intel_ring_buffer *ring) if (INTEL_INFO(dev)-gen = 6) I915_WRITE(MI_MODE, GFX_MODE_ENABLE(ASYNC_FLIP_PERF_DISABLE)); - /* Required for the hardware to program scanline values for waiting */ - if (INTEL_INFO(dev)-gen == 6) - I915_WRITE(GFX_MODE, - GFX_MODE_ENABLE(GFX_TLB_INVALIDATE_ALWAYS)); - if (IS_GEN7(dev)) I915_WRITE(GFX_MODE_GEN7, GFX_MODE_DISABLE(GFX_TLB_INVALIDATE_ALWAYS) | -- 1.7.9.5 -- kernel-team mailing list kernel-t...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kernel-team -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#659033: Fixed in the 3.9 kernel source
Package: src:linux Hi, This long standing bug, present in the original kernel source from version 3.2 to version 3.8, has been finally fixed in kernel 3.9. Regards, -- Manolo Díaz -- 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/20130429072212.26b0b...@gmail.com
