Processed: Re: Bug#625820: Please let the user know when fsck'ing while booting - machine looks dead
Processing commands for cont...@bugs.debian.org: reassign 625820 linux-2.6 Bug #625820 [initscripts] Please let the user know when fsck'ing while booting - machine looks dead Bug reassigned from package 'initscripts' to 'linux-2.6'. Bug No longer marked as found in versions sysvinit/2.88dsf-13.1. thanks Stopping processing here. Please contact me if you need assistance. -- 625820: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625820 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.130475683213218.transcr...@bugs.debian.org
Bug#625922: SATA devices get reset without real hardware failure
Package: linux-image
Version: 2.6.38-8-amd64
Severity: critical
While running stock Debian's sid linux 2.6.38-8-amd64 kernel I'm getting random
fails on SATA devices.
I have a RAID5 system with 5 disks and 3 of them showed the same exact failure,
one each 48 hours.
On reboot, the devices work perfectly, and badblocks runs through them without
a single failure.
Kernel exact failure is:
[255352.928063] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[255352.928071] ata4.00: failed command: FLUSH CACHE EXT
[255352.928080] ata4.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[255352.928082] res 40/00:01:09:4f:c2/00:00:00:00:00/00 Emask 0x4
(timeout)
[255352.928087] ata4.00: status: { DRDY }
[255352.928096] ata4: hard resetting link
[255362.932028] ata4: softreset failed (1st FIS failed)
[255362.932036] ata4: hard resetting link
[255372.932018] ata4: softreset failed (1st FIS failed)
[255372.932026] ata4: hard resetting link
[255407.932029] ata4: softreset failed (1st FIS failed)
[255407.932038] ata4: limiting SATA link speed to 1.5 Gbps
[255407.932042] ata4: hard resetting link
[255413.120028] ata4: softreset failed (device not ready)
[255413.120035] ata4: reset failed, giving up
[255413.120040] ata4.00: disabled
[255413.120060] ata4: EH complete
[255413.120131] sd 4:0:0:0: [sdc] Unhandled error code
[255413.120134] sd 4:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[255413.120139] sd 4:0:0:0: [sdc] CDB: Read(10): 28 00 a5 ec 28 24 00 00 f8 00
[255413.120149] end_request: I/O error, dev sdc, sector 2783717412
[255413.120162] sd 4:0:0:0: [sdc] Unhandled error code
[255413.120165] sd 4:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[255413.120169] sd 4:0:0:0: [sdc] CDB: Read(10): 28 00 a5 ec 29 1c 00 00 10 00
[255413.120178] end_request: I/O error, dev sdc, sector 2783717660
[255413.120186] sd 4:0:0:0: [sdc] Unhandled error code
[255413.120188] sd 4:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[255413.120192] sd 4:0:0:0: [sdc] CDB: Write(10): 2a 00 00 00 00 2e 00 00 08 00
[255413.120201] end_request: I/O error, dev sdc, sector 46
[255413.120209] end_request: I/O error, dev sdc, sector 46
[255413.120212] md: super_written gets error=-5, uptodate=0
[255413.120218] md/raid:md0: Disk failure on sdc1, disabling device.
[255413.120219] md/raid:md0: Operation continuing on 4 devices.
[255413.332414] RAID conf printout:
[255413.332420] --- level:5 rd:5 wd:4
[255413.332425] disk 0, o:1, dev:sdb1
[255413.332428] disk 1, o:0, dev:sdc1
[255413.332432] disk 2, o:1, dev:sdd1
[255413.332435] disk 3, o:1, dev:sde1
[255413.332438] disk 4, o:1, dev:sdf1
[255413.352039] RAID conf printout:
[255413.352045] --- level:5 rd:5 wd:4
[255413.352049] disk 0, o:1, dev:sdb1
[255413.352052] disk 2, o:1, dev:sdd1
[255413.352055] disk 3, o:1, dev:sde1
[255413.352058] disk 4, o:1, dev:sdf1
Devices are in different SATA ports (first failed ata2, then ata5, then ata4)
and are all Seagate ST2000DL003-9VT166.
Same exact hardware has been running on Linux 2.6.32-gentoo for weeks without a
single failure.
lspci output:
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller (rev 02)
Subsystem: Giga-byte Technology Device 5000
Flags: bus master, fast devsel, latency 0
Capabilities: access denied
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express
Root Port (rev 02) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: a000-afff
Memory behind bridge: f400-f5ff
Prefetchable memory behind bridge: e000-efff
Capabilities: access denied
Kernel driver in use: pcieport
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Giga-byte Technology Device 5004
Flags: bus master, medium devsel, latency 0, IRQ 16
I/O ports at e000 [size=32]
Capabilities: access denied
Kernel driver in use: uhci_hcd
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #5 (rev 02) (prog-if 00 [UHCI])
Subsystem: Giga-byte Technology Device 5004
Flags: bus master, medium devsel, latency 0, IRQ 21
I/O ports at e100 [size=32]
Capabilities: access denied
Kernel driver in use: uhci_hcd
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #6 (rev 02) (prog-if 00 [UHCI])
Subsystem: Giga-byte Technology Device 5004
Flags: bus master, medium devsel, latency 0, IRQ 18
I/O ports at e500 [size=32]
Capabilities: access denied
Kernel driver in use: uhci_hcd
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #2 (rev 02) (prog-if 20
Processed: Re: Bug#625922: SATA devices get reset without real hardware failure
Processing commands for cont...@bugs.debian.org: reassign 625922 linux-2.6 2.6.38-8-amd64 Bug #625922 [linux-image] SATA devices get reset without real hardware failure Warning: Unknown package 'linux-image' Bug reassigned from package 'linux-image' to 'linux-2.6'. Bug No longer marked as found in versions 2.6.38-8-amd64. Bug #625922 [linux-2.6] SATA devices get reset without real hardware failure There is no source info for the package 'linux-2.6' at version '2.6.38-8-amd64' with architecture '' Unable to make a source version for version '2.6.38-8-amd64' Bug Marked as found in versions 2.6.38-8-amd64. -- Stopping processing here. Please contact me if you need assistance. -- 625922: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625922 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.130475867918698.transcr...@bugs.debian.org
Bug#624343: Possible workaround?
I've hit this bug from a different scenario - I have one SATA disk and one external USB disk in a root on RAID1+LVM setup. During boot it seems the USB device often doesn't settle before the md device gets to being assembled, with the net result that it boots degraded, with the USB device missing. No big deal I figured, I can always re-add the USB disk later and let it re-sync as required. Until I saw the discussion on this bug report I'd assumed that it was only a performance warning and not a potential data loss scenario though. If I've understood this correctly one possible workaround for this (for the time being) would be to add a boot parameter that lets you artificially limit max_hw_sectors? In this case it seems forcing all md devices down from 248 to 240 would probably avoid potential data loss issues without large performance degradation or big intrusive changes. Is that sane? Alan -- 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/banlktintmejpux5j+e19sxdtg+e7ss5...@mail.gmail.com
Bug#621773: Any sign of a fix??
This is still broken in the latest versions. Switching to rpcbind does NOT make any difference. -- Mike Ricketts m...@earth.li -- 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/pine.lnx.4.64.1105071113370.10...@heaven.on.earth.li
Processed: reassign 625922 to linux-2.6, severity of 625922 is important
Processing commands for cont...@bugs.debian.org: reassign 625922 linux-2.6 Bug #625922 [linux-2.6] SATA devices get reset without real hardware failure Ignoring request to reassign bug #625922 to the same package severity 625922 important Bug #625922 [linux-2.6] SATA devices get reset without real hardware failure Severity set to 'important' from 'critical' thanks Stopping processing here. Please contact me if you need assistance. -- 625922: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625922 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.1304763726787.transcr...@bugs.debian.org
Bug#625953: linux-2.6: orinoco_pci module is no longer present
Package: linux-2.6 Version: 2.6.38-2 Severity: critical Justification: breaks the whole system As per subject, the orinoco_pci module is missing from 2.6.38 kernel images, so my router can no longer connect to the network. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20110507103107.3576.18188.report...@wibble.chf
Bug#621773: Any sign of a fix??
On 05/07/2011 12:15 PM, Mike Ricketts wrote: This is still broken in the latest versions. Switching to rpcbind does NOT make any difference. You are not using IPv6 and the suggestion of another user to add IPv6 addresses to /etc/hosts did not solve the issue? You are using NFS with Kerberos and have NEED_GSSD=yes in your configuration? You are using AD authentication and do not have libtirpc 0.2.2 (unfortunatley seems to not be packaged yet) installed? Cheers Luk -- 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/4dc5356f.90...@debian.org
Bug#621773: Any sign of a fix??
On Sat, 7 May 2011, Luk Claes wrote: You are not using IPv6 and the suggestion of another user to add IPv6 addresses to /etc/hosts did not solve the issue? I am not using IPv6, but I do already have the IPv6 addresses suggested in /etc/hosts (I did not add them, they were already there) You are using NFS with Kerberos and have NEED_GSSD=yes in your configuration? I am not using Kerberos. I do not think I have NEED_GSSD=yes in my configuration - but just to check, where would it be? You are using AD authentication and do not have libtirpc 0.2.2 (unfortunatley seems to not be packaged yet) installed? I am not using AD authentication. I have libtirpc 0.2.1-1 Thanks for the suggestions -- Mike Ricketts m...@earth.li -- 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/pine.lnx.4.64.1105071447080.32...@heaven.on.earth.li
Bug#625953: linux-2.6: orinoco_pci module is no longer present
Hi Mike, On Sat, May 07, 2011 at 11:31:07AM +0100, Mike wrote: As per subject, the orinoco_pci module is missing from 2.6.38 kernel images, so my router can no longer connect to the network. Prism 2/2.5/3 support in the orinoco driver (HERMES_PRISM) is disabled by default as of Linux 2.6.35 [1]. As PCI_HERMES depends on HERMES_PRISM, this module was not built. The hostap driver provides better support for Prism 2/2.5/3-based PCI devices, including firmware downloading and WPA support. Consider using the available hostap_pci module. Geoff [1] http://git.kernel.org/linus/484b4dd582867c6cfec3a1feb128d60af21c4978 -- 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/20110507142643.gc2...@chmmr.gsimmons.org
Bug#622218: Also in Version 2.6.38-4
found 2.6.38-4 -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#625804: rtc/mc13xxx: don't call rtc_device_register with the lock held
On Fri, May 06, 2011 at 11:57:47AM +0200, Uwe Kleine-König wrote:
diff --git a/drivers/rtc/rtc-mc13xxx.c b/drivers/rtc/rtc-mc13xxx.c
index c5ac037..a1a278b 100644
--- a/drivers/rtc/rtc-mc13xxx.c
+++ b/drivers/rtc/rtc-mc13xxx.c
@@ -349,11 +349,15 @@ static int __devinit mc13xxx_rtc_probe(struct
platform_device *pdev)
if (ret)
goto err_alarm_irq_request;
+ mc13xxx_unlock(mc13xxx);
+
priv-rtc = rtc_device_register(pdev-name,
pdev-dev, mc13xxx_rtc_ops, THIS_MODULE);
if (IS_ERR(priv-rtc)) {
ret = PTR_ERR(priv-rtc);
+ mc13xxx_lock(mc13xxx);
+
mc13xxx_irq_free(mc13xxx, MC13XXX_IRQ_TODA, priv);
err_alarm_irq_request:
@@ -365,12 +369,12 @@ err_reset_irq_status:
mc13xxx_irq_free(mc13xxx, MC13XXX_IRQ_RTCRST, priv);
err_reset_irq_request:
+ mc13xxx_unlock(mc13xxx);
+
platform_set_drvdata(pdev, NULL);
kfree(priv);
}
- mc13xxx_unlock(mc13xxx);
-
return ret;
}
http://patchwork.ozlabs.org/patch/94354/
thanks! i just tested and confirmed that this patch also resolves the issue.
live well,
vagrant
--
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/20110507201648.GD9959@talon.fglan
Bug#625811: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#625811: please don't drop support for Wheezy)
Hi Ben, Sorry, probably I missed the note about dropping Vserver. It seemed to be in wide use and under active development. Pretty disappointing for the Vserver folks, I would guess. Of course I can give lxc a try, but I am a little bit concerned that it might get dropped, too, as soon as the next lightweight virtualization scheme appears on the horizon. Regards Harri -- 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/4dc5c0c4.50...@aixigo.de
Bug#625953: marked as done (linux-2.6: orinoco_pci module is no longer present)
Your message dated Sat, 07 May 2011 23:40:19 +0100 with message-id 1304808019.3203.149.camel@localhost and subject line Re: Bug#625953: linux-2.6: orinoco_pci module is no longer present has caused the Debian Bug report #625953, regarding linux-2.6: orinoco_pci module is no longer present to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 625953: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625953 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-2.6 Version: 2.6.38-2 Severity: critical Justification: breaks the whole system As per subject, the orinoco_pci module is missing from 2.6.38 kernel images, so my router can no longer connect to the network. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash ---End Message--- ---BeginMessage--- On Sun, 2011-05-08 at 00:26 +1000, Geoff Simmons wrote: Hi Mike, On Sat, May 07, 2011 at 11:31:07AM +0100, Mike wrote: As per subject, the orinoco_pci module is missing from 2.6.38 kernel images, so my router can no longer connect to the network. Prism 2/2.5/3 support in the orinoco driver (HERMES_PRISM) is disabled by default as of Linux 2.6.35 [1]. As PCI_HERMES depends on HERMES_PRISM, this module was not built. The hostap driver provides better support for Prism 2/2.5/3-based PCI devices, including firmware downloading and WPA support. Consider using the available hostap_pci module. Right. According to http://wireless.kernel.org/en/users/Drivers/orinoco, 'support for Intersil (Prism) devices is being disabled from v2.6.35. The hostap driver should be more capable for these cards.' Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part ---End Message---
Bug#625811: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#625811: please don't drop support for Wheezy)
On Sat, 2011-05-07 at 23:59 +0200, Harald Dunkel wrote: Hi Ben, Sorry, probably I missed the note about dropping Vserver. It seemed to be in wide use and under active development. Pretty disappointing for the Vserver folks, I would guess. Of course I can give lxc a try, but I am a little bit concerned that it might get dropped, too, as soon as the next lightweight virtualization scheme appears on the horizon. LXC is based on the cgroups and namespace mechanisms in mainline Linux. It doesn't require out-of-tree patches. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#604013: marked as done (base: ls -al on armel inside loopback mounted ISO image failes with -1 ENOMEM)
Your message dated Sat, 7 May 2011 23:49:16 +0100
with message-id 20110507224916.GA22261@enorme.TCLDOMAIN.OFFICE
and subject line Re: Bug#604013: base: ls -al on armel inside loopback
mounted ISO image failes with -1 ENOMEM
has caused the Debian Bug report #604013,
regarding base: ls -al on armel inside loopback mounted ISO image failes with
-1 ENOMEM
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
604013: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604013
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: base
Severity: normal
** Please type your report below this line ***
I'm running Debian on Seagate Dockstar (Kirkwood platform). When I mount a ISO
image via loopback (mount -o loop myfile.iso /mnt) a ls inside this mounted
tree (ls -al /mnt/) failes with Cannot allocate memory.
This is a test on the Kirkwood machine:
root@dockstar:/srv/tftp# md5sum systemrescuecd-x86-1.6.2.iso
b7662eb44b530d62c487dd367f2036ed systemrescuecd-x86-1.6.2.iso
root@dockstar:/srv/tftp# uname -a
Linux dockstar.lab.elconas.de 2.6.32-5-kirkwood #1 Sat Sep 18 15:20:08 UTC 2010
armv5tel GNU/Linux
root@dockstar:/srv/tftp# mount -o loop systemrescuecd-x86-1.6.2.iso sysrescuecd
root@dockstar:/srv/tftp# ls -al sysrescuecd
ls: cannot access sysrescuecd/bootdisk: Cannot allocate memory
ls: cannot access sysrescuecd/bootprog: Cannot allocate memory
ls: cannot access sysrescuecd/isolinux: Cannot allocate memory
ls: cannot access sysrescuecd/ntpasswd: Cannot allocate memory
ls: cannot access sysrescuecd/sysrcd.dat: Cannot allocate memory
ls: cannot access sysrescuecd/sysrcd.md5: Cannot allocate memory
ls: cannot access sysrescuecd/usb_inst: Cannot allocate memory
ls: cannot access sysrescuecd/usb_inst.sh: Cannot allocate memory
ls: cannot access sysrescuecd/usbstick.htm: Cannot allocate memory
ls: cannot access sysrescuecd/version: Cannot allocate memory
total 6
dr-xr-xr-x 1 root root2048 Oct 11 20:09 .
drwxr-xr-x 22 tftp nogroup 4096 Nov 19 11:38 ..
?? ? ?? ?? bootdisk
?? ? ?? ?? bootprog
?? ? ?? ?? isolinux
?? ? ?? ?? ntpasswd
?? ? ?? ?? sysrcd.dat
?? ? ?? ?? sysrcd.md5
?? ? ?? ?? usb_inst
?? ? ?? ?? usb_inst.sh
?? ? ?? ?? usbstick.htm
?? ? ?? ?? version
dmesg ...
[49412.581257] ISO 9660 Extensions: Microsoft Joliet Level 3
[49412.581340] ISOFS: changing to secondary root
root@dockstar:/srv/tftp# ldd /bin/ls
libselinux.so.1 = /lib/libselinux.so.1 (0x40005000)
librt.so.1 = /lib/librt.so.1 (0x40026000)
libacl.so.1 = /lib/libacl.so.1 (0x40036000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40044000)
libc.so.6 = /lib/libc.so.6 (0x40058000)
libdl.so.2 = /lib/libdl.so.2 (0x40188000)
/lib/ld-linux.so.3 (0x2a00)
libpthread.so.0 = /lib/libpthread.so.0 (0x40193000)
libattr.so.1 = /lib/libattr.so.1 (0x401b3000)
root@dockstar:/srv/tftp# file /bin/ls
/bin/ls: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.18, stripped
root@dockstar:/srv/tftp# strace ls -al sysrescuecd/ntpasswd
.
open(/proc/filesystems, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4001e000
read(3, nodev\tsysfs\nnodev\trootfs\nnodev\tb..., 1024) = 286
read(3, , 1024) = 0
close(3)= 0
munmap(0x4001e000, 4096)= 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=57, ws_col=190, ws_xpixel=0, ws_ypixel=0}) = 0
lstat64(sysrescuecd/ntpasswd, 0x280b0) = -1 ENOMEM (Cannot allocate memory)
write(2, ls: , 4ls: ) = 4
write(2, cannot access sysrescuecd/ntpass..., 34cannot access
sysrescuecd/ntpasswd) = 34
write(2, : Cannot allocate memory, 24: Cannot allocate memory) = 24
write(2, \n, 1
) = 1
close(1)= 0
close(2)= 0
exit_group(2) = ?
-
When I do the same thing on normal x86_64 everything is ok:
debian:/# md5sum systemrescuecd-x86-1.6.2.iso
b7662eb44b530d62c487dd367f2036ed
Re: New maintainer for ARM
Hi, 2011/5/5 Arnaud Patard arnaud.pat...@rtp-net.org: Martin Michlmayr t...@cyrius.com writes: Here are some outstanding bugs/tasks regarding the ARM kernels: #604013 base: ls -al on armel inside loopback mounted ISO image failes with -1 ENOMEM Nobody has been able to reproduce and the submitter doesn't respond. Maybe ping the submitter again, close if no reply. Looks like ownership problem, already closed. #622325 linux-image-2.6.38-2-orion5x: Problem With I2C Forward upstream, bisect. I am unable to test this one. I got no hardware. As a side note: The code that introduces that message is found at http://lxr.linux.no/linux+v2.6.38/drivers/i2c/busses/i2c-mv64xxx.c#L370 On DNS323 m41t80 is an i2c device at 0x68, but I fail to see what can be going wrong, maybe it ring some bell on your side. #614593 Please add new armel kernel flavour for the Marvell DB-78x00-BP Development Board I still believe this is a bad idea since it will make kernel builds slower for very little gain (there are no users of this board outside of our buildd infrastructure). A similar problem exists on MIPS and I think Ben wanted to look into the possibility of adding configs without enabling them by default but providing an easy way to compile the image. I can't comment on that one but at least, the solution of adding support but not enabling it by default may be a solution. I think that would be helpful. Steve is taking the burden of building those kernels, I have carbon copied him to check his input about it. If it is fine, I can try to prepare a patch for Arnaud suggestion, which it is fine with me too. squashfs: #613658 There are some options that may have to be selected on ARM. hmm... I didn't notice this bug. The ARM options are enabled by default like the other options. I don't know if it can have some side effects at run time. I guess it should be fine otherwise some Kconfig patching will be needed (I'm thinking of the ARMTHUMB decoder option) This bug has first to be fixed in common code, which has happen on SVN trunk. We need to enable on armel/armhf common file: (sounds about right?) CONFIG_XZ_DEC=m CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y Would it be sensible to add ... ? #. Additional option for memory-constrained systems CONFIG_SQUASHFS_EMBEDDED=y I think it would be interesting to have one armel/armhf common config, but I have not yet looked into that. Also: look through open bugs to see if there are other ARM related issues. I have just sent a patch that applies on current trunk for Bug#625804: rtc/mc13xxx: don't call rtc_device_register with the lock held Best regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.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/BANLkTi=3m-6yg7vwntxghchp0fgrnvj...@mail.gmail.com
Bug#625804: linux-2.6: fix rtc lockups on armhf
Hello,
Here is a proposed patch against trunk for fixing this bug.
Patch was written initial by Arnaud Patard, later changed
by Uwe Kleine-König.
Best regards
Index: debian/patches/bugfix/arm/rtc_mutex_lockup.patch
===
--- debian/patches/bugfix/arm/rtc_mutex_lockup.patch(revision 0)
+++ debian/patches/bugfix/arm/rtc_mutex_lockup.patch(revision 0)
@@ -0,0 +1,80 @@
+Fix rtc-mc13xxx lockup
+
+Fix this lock up :
+
+
+[ 240.159703] INFO: task swapper:1 blocked for more than 120 seconds.
+[ 240.166030] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
+[ 240.173976] swapper D c03e688c 0 1 0 0x
+[ 240.180483] Backtrace:
+[ 240.183066] [c03e65d0] (schedule+0x0/0x2f0) from [c03e72f8]
(__mutex_lock_slowpath+0x88/0xb4)
+[ 240.192086] [c03e7270] (__mutex_lock_slowpath+0x0/0xb4) from [c03e7588]
(mutex_lock+0x30/0x34)
+[ 240.201151] r8:0001 r7:df83fd8c r6: r5:df83fd8c r4:dfbd1204
+[ 240.208091] [c03e7558] (mutex_lock+0x0/0x34) from [c0206644]
(mc13xxx_lock+0x28/0x2c)
+[ 240.216403] r4:dfbd1204 r3:
+[ 240.220181] [c020661c] (mc13xxx_lock+0x0/0x2c) from [c0284d08]
(mc13xxx_rtc_read_time+0x24/0xf4)
+[ 240.229377] r4:dfbabc40 r3:c0284ce4
+[ 240.233127] [c0284ce4] (mc13xxx_rtc_read_time+0x0/0xf4) from [c0282bd4]
(__rtc_read_time+0x50/0x5c)
+[ 240.243441] r6: r5:df83fd8c r4:dfb46c00
+[ 240.248211] [c0282b84] (__rtc_read_time+0x0/0x5c) from [c0282ebc]
(rtc_read_time+0x34/0x48)
+[ 240.257020] r5:dfb46c00 r4:dfb46ce0
+[ 240.260763] [c0282e88] (rtc_read_time+0x0/0x48) from [c0283090]
(__rtc_read_alarm+0x24/0x27c)
+[ 240.269740] r7:dfb46c00 r6:dfbdcbd8 r5:dfb46c00 r4:df83fdec
+[ 240.275582] [c028306c] (__rtc_read_alarm+0x0/0x27c) from [c0282994]
(rtc_device_register+0x160/0x284)
+[ 240.285320] [c0282834] (rtc_device_register+0x0/0x284) from [c03e54a8]
(mc13xxx_rtc_probe+0x104/0x18c)
+[ 240.295150] [c03e53a4] (mc13xxx_rtc_probe+0x0/0x18c) from [c01fd7d4]
(platform_drv_probe+0x1c/0x20)
+[ 240.304651] r8: r7:c0540db4 r6:c0540db4 r5:dfbdcb08 r4:dfbdcb08
+[ 240.311620] [c01fd7b8] (platform_drv_probe+0x0/0x20) from [c01fc388]
(really_probe+0xa0/0x150)
+[ 240.320730] [c01fc2e8] (really_probe+0x0/0x150) from [c01fc5d0]
(driver_probe_device+0x28/0x34)
+[ 240.329878] r7: r6:c0540db4 r5:dfbdcb3c r4:dfbdcb08
+[ 240.335725] [c01fc5a8] (driver_probe_device+0x0/0x34) from [c01fc644]
(__driver_attach+0x68/0x8c)
+[ 240.345907] [c01fc5dc] (__driver_attach+0x0/0x8c) from [c01fb708]
(bus_for_each_dev+0x58/0x88)
+[ 240.354976] r6:c01fc5dc r5:df83fee0 r4:c0540db4 r3:df80d4b4
+[ 240.360870] [c01fb6b0] (bus_for_each_dev+0x0/0x88) from [c01fc1dc]
(driver_attach+0x20/0x28)
+[ 240.369758] r7: r6:c0539c20 r5:dfba9180 r4:c0540db4
+[ 240.375604] [c01fc1bc] (driver_attach+0x0/0x28) from [c01fbe0c]
(bus_add_driver+0xb4/0x230)
+[ 240.384453] [c01fbd58] (bus_add_driver+0x0/0x230) from [c01fcbc8]
(driver_register+0xa8/0x128)
+[ 240.393568] [c01fcb20] (driver_register+0x0/0x128) from [c01fdc48]
(platform_driver_register+0x4c/0x60)
+[ 240.403469] [c01fdbfc] (platform_driver_register+0x0/0x60) from
[c01fdc7c] (platform_driver_probe+0x20/0x70)
+[ 240.413816] [c01fdc5c] (platform_driver_probe+0x0/0x70) from [c001b458]
(mc13xxx_rtc_init+0x18/0x24)
+[ 240.423406] r5:c002691c r4:c00267e4
+[ 240.427110] [c001b440] (mc13xxx_rtc_init+0x0/0x24) from [c00304c0]
(do_one_initcall+0xa4/0x174)
+[ 240.436302] [c003041c] (do_one_initcall+0x0/0x174) from [c00089d4]
(kernel_init+0xa4/0x154)
+[ 240.445916] [c0008930] (kernel_init+0x0/0x154) from [c0049c74]
(do_exit+0x0/0x250)
+[ 240.453936] r5:c0008930 r4:
+
+Signed-off-by: Arnaud Patard arnaud.pat...@rtp-net.org
+Index: source/drivers/rtc/rtc-mc13xxx.c
+===
+--- source.orig/drivers/rtc/rtc-mc13xxx.c 2011-05-07 16:44:37.0
+
source/drivers/rtc/rtc-mc13xxx.c 2011-05-07 17:15:24.0 +
+@@ -358,9 +358,14 @@
+
+ priv-rtc = rtc_device_register(pdev-name,
+ pdev-dev, mc13xxx_rtc_ops, THIS_MODULE);
++
++ mc13xxx_lock(mc13xxx);
++
+ if (IS_ERR(priv-rtc)) {
+ ret = PTR_ERR(priv-rtc);
+
++ mc13xxx_unlock(mc13xxx);
++
+ mc13xxx_irq_free(mc13xxx, MC13XXX_IRQ_TODA, priv);
+ err_alarm_irq_request:
+
+@@ -372,12 +377,12 @@
+ mc13xxx_irq_free(mc13xxx, MC13XXX_IRQ_RTCRST, priv);
+ err_reset_irq_request:
+
++ mc13xxx_unlock(mc13xxx);
++
+ platform_set_drvdata(pdev, NULL);
+ kfree(priv);
+ }
+
+- mc13xxx_unlock(mc13xxx);
+-
+ return ret;
+ }
+
Index: debian/patches/series/base
===
--- debian/patches/series/base (revision 17314)
+++ debian/patches/series/base (working copy)
@@
Re: New maintainer for ARM
On Sun, 2011-05-08 at 02:14 +0200, Hector Oron wrote: Hi, 2011/5/5 Arnaud Patard arnaud.pat...@rtp-net.org: [...] hmm... I didn't notice this bug. The ARM options are enabled by default like the other options. I don't know if it can have some side effects at run time. I guess it should be fine otherwise some Kconfig patching will be needed (I'm thinking of the ARMTHUMB decoder option) This bug has first to be fixed in common code, which has happen on SVN trunk. We need to enable on armel/armhf common file: (sounds about right?) CONFIG_XZ_DEC=m CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y Would it be sensible to add ... ? #. Additional option for memory-constrained systems CONFIG_SQUASHFS_EMBEDDED=y I think it would be interesting to have one armel/armhf common config, but I have not yet looked into that. [...] We do. The Kconfig files for armhf are armel/config, armhf/config. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#626021: linux-image-2.6.38-2-686: icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine
Package: linux-2.6 Version: 2.6.38-3 Severity: normal This is a bug in the kernel itself, there have been a few patches to the kernel, but it seems at least one patch is not in the vanilla kernel. Some other distributions are including this patch. See https://bugzilla.kernel.org/show_bug.cgi?id=16315 and http://bugs.winehq.org/show_bug.cgi?id=23323 for more info. -- Package-specific info: ** Version: Linux version 2.6.38-2-686 (Debian 2.6.38-3) (b...@decadent.org.uk) (gcc version 4.4.5 (Debian 4.4.5-15) ) #1 SMP Thu Apr 7 05:24:21 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-2-686 root=UUID=fc173ee2-9266-4bce-b5c3-ff468730f225 ro quiet ** Not tainted ** Kernel log: [0.664763] 00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [0.664919] Linux agpgart interface v0.103 [0.665034] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [0.665505] serio: i8042 KBD port at 0x60,0x64 irq 1 [0.665516] serio: i8042 AUX port at 0x60,0x64 irq 12 [0.665606] mousedev: PS/2 mouse device common for all mice [0.665792] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 [0.665965] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0 [0.666036] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs [0.666047] cpuidle: using governor ladder [0.666048] cpuidle: using governor menu [0.666192] TCP cubic registered [0.666292] NET: Registered protocol family 10 [0.666726] Mobile IPv6 [0.666730] NET: Registered protocol family 17 [0.666735] Registering the dns_resolver key type [0.666751] Using IPI No-Shortcut mode [0.666819] PM: Hibernation image not present or could not be loaded. [0.666826] registered taskstats version 1 [0.666928] rtc_cmos 00:01: setting system clock to 2011-05-06 19:42:14 UTC (1304710934) [0.666944] Initalizing network drop monitor service [0.666997] Freeing unused kernel memory: 392k freed [0.667098] Write protecting the kernel text: 2648k [0.667109] Write protecting the kernel read-only data: 1000k [0.679883] 30udev[45]: starting version 167 [0.695518] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) [0.695633] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 [0.695654] 8139cp :00:03.0: PCI INT A - Link[LNKC] - GSI 11 (level, high) - IRQ 11 [0.744936] FDC 0 is a S82078B [0.745467] 8139cp :00:03.0: eth0: RTL-8139C+ at 0xc8806000, 52:54:00:12:34:56, IRQ 11 [0.745490] 8139cp :00:03.0: setting latency timer to 64 [0.747229] 8139too: 8139too Fast Ethernet driver 0.9.28 [0.748483] SCSI subsystem initialized [0.759932] libata version 3.00 loaded. [0.761768] ata_piix :00:01.1: version 2.13 [0.761824] ata_piix :00:01.1: setting latency timer to 64 [0.762212] scsi0 : ata_piix [0.762298] scsi1 : ata_piix [0.762328] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14 [0.762330] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15 [0.916539] ata1.01: NODEV after polling detection [0.916751] ata2.01: NODEV after polling detection [0.916959] ata1.00: ATA-7: QEMU HARDDISK, 0.13.0, max UDMA/100 [0.916961] ata1.00: 20971520 sectors, multi 16: LBA48 [0.917096] ata2.00: ATAPI: QEMU DVD-ROM, 0.13.0, max UDMA/100 [0.917408] ata1.00: configured for MWDMA2 [0.917492] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK0.13 PQ: 0 ANSI: 5 [0.917864] ata2.00: configured for MWDMA2 [0.918137] scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 0.13 PQ: 0 ANSI: 5 [0.928603] sd 0:0:0:0: [sda] 20971520 512-byte logical blocks: (10.7 GB/10.0 GiB) [0.928628] sd 0:0:0:0: [sda] Write Protect is off [0.928630] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [0.928641] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [0.929229] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray [0.929231] cdrom: Uniform CD-ROM driver Revision: 3.20 [0.929407] sda: sda1 sda2 sda5 [0.929622] sd 0:0:0:0: [sda] Attached SCSI disk [0.929692] sr 1:0:0:0: Attached scsi CD-ROM sr0 [0.937670] sd 0:0:0:0: Attached scsi generic sg0 type 0 [0.937936] sr 1:0:0:0: Attached scsi generic sg1 type 5 [1.081266] PM: Starting manual resume from disk [1.081268] PM: Hibernation image partition 8:5 present [1.081269] PM: Looking for hibernation image. [1.081464] PM: Image not found (code -22) [1.081466] PM: Hibernation image not present or could not be loaded. [1.098886] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [1.256117] Refined TSC clocksource calibration: 3208.200 MHz. [2.327907] 30udev[221]: starting version 167 [2.866819] input: PC Speaker as /devices/platform/pcspkr/input/input1 [2.875538] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [2.875595] ACPI: Power Button
Re: New maintainer for ARM
Hi Ben,
2011/5/8 Ben Hutchings b...@decadent.org.uk:
I think it would be interesting to have one armel/armhf common config,
but I have not yet looked into that.
We do. The Kconfig files for armhf are armel/config, armhf/config.
Yes, I was thinking on something like a toplevel arm[el,hf] config. We
could have
config/arm/{config, armel/config, armhf/config}, but that might
complicate things.
OTOH, armel packages could also be built on armhf platforms and the
other way around.
I am not sure if it is worth the burden to merge a bit more armhf and armel.
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us.
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.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/banlktimle9y_eimrius6lmvgdgi3g6p...@mail.gmail.com
Bug#626022: linux-2.6: Attempting to reboot on [U]EFI systems causes kernel hang
Package: linux-2.6 Version: attempting to reboot on UEFI systems causes kernel hang Severity: important Tags: upstream When attempting to reboot my my UEFI enabled system, the system hangs when calling reboot requiring me to manually reset the system via the reset switch. Screenshot: http://twitgoo.com/29bq1c As you can see this is on a P8P67 Motherboard. It seems as if this has recently been reported at Ubuntu's Launchpad as well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/721576 Which also suggests a workaround of adding reboot=a,w to the kernel command line, I shall try this later on this evening. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110508022929.4825.2577.report...@jarvis-pc.priorityonline.net
Bug#626021: linux-image-2.6.38-2-686: icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine
On Sat, 2011-05-07 at 19:50 -0500, Austin English wrote: Package: linux-2.6 Version: 2.6.38-3 Severity: normal This is a bug in the kernel itself, there have been a few patches to the kernel, but it seems at least one patch is not in the vanilla kernel. Some other distributions are including this patch. See https://bugzilla.kernel.org/show_bug.cgi?id=16315 and http://bugs.winehq.org/show_bug.cgi?id=23323 for more info. A different version of that patch has been applied as: commit 89e45aac42d40426c97e6901811309bf49c4993f Author: Frederic Weisbecker fweis...@gmail.com Date: Fri Sep 17 03:24:13 2010 +0200 x86: Fix instruction breakpoint encoding Please identify any further changes you believe are required. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: tagging 626021
Processing commands for cont...@bugs.debian.org: tags 626021 + moreinfo Bug #626021 [linux-2.6] linux-image-2.6.38-2-686: icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 626021: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626021 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.130482071816241.transcr...@bugs.debian.org
Bug#626021: linux-image-2.6.38-2-686: icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine
On Sat, May 7, 2011 at 21:11, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2011-05-07 at 19:50 -0500, Austin English wrote: Package: linux-2.6 Version: 2.6.38-3 Severity: normal This is a bug in the kernel itself, there have been a few patches to the kernel, but it seems at least one patch is not in the vanilla kernel. Some other distributions are including this patch. See https://bugzilla.kernel.org/show_bug.cgi?id=16315 and http://bugs.winehq.org/show_bug.cgi?id=23323 for more info. A different version of that patch has been applied as: commit 89e45aac42d40426c97e6901811309bf49c4993f Author: Frederic Weisbecker fweis...@gmail.com Date: Fri Sep 17 03:24:13 2010 +0200 x86: Fix instruction breakpoint encoding Please identify any further changes you believe are required. Looking at the Wine bug, appears the relevant commits are: 1. Commit 08d6832 breaks the login 2. Commit a1e80fa fixes commit 08d6832 (this is in 2.6.35) 3. Commit f7809da also breaks the login (this is in 2.6.36-rc1 and later) 4. Frederick's new patch fixes commit f7809da (this hasn't been checked in) from http://bugs.winehq.org/show_bug.cgi?id=23323#c181 in any case, a regression test was added to wine to check for this, which fails on this kernel: ../../../tools/runtest -q -P wine -M ntdll.dll -T ../../.. -p ntdll_test.exe.so exception.c touch exception.ok exception.c:399: Test failed: 42: Wrong exception address 0x33/0x330001 wine: Unhandled exception 0x8004 at address 0x33 (thread 0009), starting debugger... 0x0033: icebp ... Backtrace: =0 0x0033 (0x0032fcb8) 1 0x684c2d44 func_exception+0x283() [/home/austin/wine-git/dlls/ntdll/tests/exception.c:465] in ntdll_test (0x0032fd38) 2 0x684f17fe run_test+0x14d(name=exception.c) [/home/austin/wine-git/dlls/ntdll/tests/../../../include/wine/test.h:556] in ntdll_test (0x0032fd88) 3 0x684f22c7 main+0x156(argc=*** Invalid address 0x *** , argv=*** Invalid address 0x0004 *** Internal symbol error: unable to access memory location 0x4) [/home/austin/wine-git/dlls/ntdll/tests/../../../include/wine/test.h:624] in ntdll_test (0x0032fe48) 4 0x684f249c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/austin/wine-git/dlls/winecrt0/exe_entry.c:36] in ntdll_test (0x0032fe90) 5 0x7b8593ac call_process_entry+0xb() in kernel32 (0x0032fea8) 6 0x7b859fdf start_process+0x5e(peb=0x7ffdf000) [/home/austin/wine-git/dlls/kernel32/process.c:1086] in kernel32 (0x0032fee8) 7 0x7bc70e58 call_thread_func+0xb() in ntdll (0x0032fef8) 8 0x7bc744fe call_thread_entry_point+0x6d(entry=0x7b859f80, arg=0x7ffdf000) [/home/austin/wine-git/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 9 0x7bc49f1e start_process+0x1d(kernel_start=0x7b859f80) [/home/austin/wine-git/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 10 0x6802899d wine_call_on_stack+0x1c() in libwine.so.1 (0x) exception.c:399: Test failed: 42: Wrong exception address 0x33/0x330001 exception.c:399: Test failed: 42: Wrong exception address 0x33/0x330001 -- -Austin -- 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/BANLkTiniMwnbZf6kjAk11q=fkubfyk+...@mail.gmail.com
Processed: tagging 626021, tagging 626021
Processing commands for cont...@bugs.debian.org: tags 626021 - moreinfo Bug #626021 [linux-2.6] linux-image-2.6.38-2-686: icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine Removed tag(s) moreinfo. tags 626021 + upstream Bug #626021 [linux-2.6] linux-image-2.6.38-2-686: icebp (opcode 0xf1) no longer causing a SIGTRAP, breaks Wine Added tag(s) upstream. thanks Stopping processing here. Please contact me if you need assistance. -- 626021: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626021 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.130482580029700.transcr...@bugs.debian.org
Incomplete upload found in Debian upload queue
Probably you are the uploader of the following file(s) in the Debian upload queue directory: linux-2.6_2.6.38-5.diff.gz linux-2.6_2.6.38-5.dsc This looks like an upload, but a .changes file is missing, so the job cannot be processed. If no .changes file arrives within 23:29:35, the files will be deleted. If you didn't upload those files, please just ignore this message. Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1qivlm-0001ur...@franck.debian.org
Processing of linux-2.6_2.6.38-5_multi.changes
linux-2.6_2.6.38-5_multi.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.38-5.dsc linux-2.6_2.6.38-5.diff.gz linux-patch-debian-2.6.38_2.6.38-5_all.deb linux-support-2.6.38-2_2.6.38-5_all.deb linux-source-2.6.38_2.6.38-5_all.deb linux-doc-2.6.38_2.6.38-5_all.deb linux-manual-2.6.38_2.6.38-5_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1qivqd-0001jd...@franck.debian.org
Processing of linux-latest-2.6_34_multi.changes
linux-latest-2.6_34_multi.changes uploaded successfully to localhost along with the files: linux-latest-2.6_34.dsc linux-latest-2.6_34.tar.gz linux-doc-2.6_2.6.38+34_all.deb linux-image-486_2.6.38+34_i386.deb linux-image-2.6-486_2.6.38+34_i386.deb linux-headers-2.6-486_2.6.38+34_i386.deb linux-source-2.6_2.6.38+34_all.deb linux-tools-2.6_2.6.38+34_all.deb linux-image-686_2.6.38+34_i386.deb linux-image-2.6-686_2.6.38+34_i386.deb linux-headers-2.6-686_2.6.38+34_i386.deb linux-image-686-bigmem_2.6.38+34_i386.deb linux-image-2.6-686-bigmem_2.6.38+34_i386.deb linux-headers-2.6-686-bigmem_2.6.38+34_i386.deb linux-image-amd64_2.6.38+34_i386.deb linux-image-2.6-amd64_2.6.38+34_i386.deb linux-headers-2.6-amd64_2.6.38+34_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1qivvu-0001wx...@franck.debian.org
Bug#622333: Debian Squeeze hangs with kernel 2.6.32-5-xen-686
On Saturday, 23 April 2011 19:09:30 -0300, Daniel Bareiro wrote: Here I found a thread [1] with a problem quite like this (although in my case the hardware is different: A8V-MX motherboard and AMD Athlon 64 Processor 3500+) in the xen-users mailing list. And another thread [2] which is derived from the above. I'll try using cpuidle=off or max_cstate=1 at xen cmdline in /boot/grub/grub.conf. It's probably worth trying cpuidle=off but it looks like the max_cstate=1 thing is Intel specific. It's not clear to me in either case if the root cause of the issue this fixes is a h/w or s/w issue. Using cpuidle=off and xen-hypervisor-4.0-amd64 package had no effect. After an uptime of 20:26:44, everything became frozen again. Now I'm trying with the max_cstate=1 option. This time there was no visual evidence in the disk activity LED when the problem occurred, but I do not see revealing information in system logs. Do you have irqbalanced installed/running? No, I'm not using irqbalance. This is a uniprocessor system (AMD Athlon(tm) 64 Processor 3500+ with A8V-MX motherdoard). Using max_cstate=1 it did not have effect either. What I observed on several occasions is that when making a rsync or scp of several Gigabytes, the computer froze. The loss of network connection made me think that it might be a problem with the network card, but from the moment the screen also stops responding if I connect a monitor to the computer, this makes me think that perhaps there is some other problem. But it seems the problem could be linked to high network transfer rate. Regards, Daniel -- Daniel Bareiro - GNU/Linux registered user #188.598 Proudly running Debian GNU/Linux with uptime: 01:59:15 up 15 days, 11:55, 10 users, load average: 0.08, 0.04, 0.00 signature.asc Description: Digital signature
