Bug#594845: Acknowledgement (linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p/..../fs/sysfs/file.c:539)
The problem disappears in linux-image-2.6.35-trunk-amd64_2.6.35-1~experimental.2. -- 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/1283153685.4366.2.ca...@russell-laptop
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Sun, 2010-08-29 at 21:22 +0100, Ben Hutchings wrote: On Fri, Aug 27, 2010 at 10:51:10AM +0100, Ian Campbell wrote: [...] BTW, should I port my lintian fixes over from trunk? Yes please. Done. Thanks, Ian. -- Ian Campbell How much of their influence on you is a result of your influence on them? -- 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/1283157940.6575.1.ca...@cthulhu.hellion.org.uk
Bug#570844: marked as done (System with AMD Turion m540 hangs while loading APIC)
Your message dated Sun, 29 Aug 2010 22:16:10 +0200 with message-id 20100829201610.ga2...@galadriel.inutil.org and subject line Re: Bug#570844: System with AMD Turion m540 hangs while loading APIC has caused the Debian Bug report #570844, regarding System with AMD Turion m540 hangs while loading APIC 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.) -- 570844: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570844 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.30-2-amd64 Subject: linux-image-2.6.30-2-amd64: System with AMD Turion m540 hangs while loading APIC Version: 2.6.30-8squeeze1 Justification: breaks the whole system Severity: critical *** Please type your report below this line *** My brand new notebook HP Pavillion dv7-3129er based on AMD Turion II Mobile m540 hands while the kernel is loading APIC. The system boots well if I pass noapic kernel option. The same problem happens with linux-image-2.6.32-trunk-amd64. The linux-image-2.6.26 has no such problem. Ubuntu's linux-image-2.6.31 works well too. I've installed Debian Lenny 5.04 then made dist-upgrade to Squeeze. Here is my /proc/cpuinfo (I hope it's useful): processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Dual-Core Mobile M540 stepping: 2 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 4788.32 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Dual-Core Mobile M540 stepping: 2 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt bogomips: 4788.05 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate -- Package-specific info: ** Version: Linux version 2.6.30-2-amd64 (Debian 2.6.30-8squeeze1) (da...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-5) ) #1 SMP Mon Dec 7 05:21:45 UTC 2009 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.30-2-amd64 root=UUID=eb55aa86-1b55-4f73-8bdf- a5f40f194690 ro quiet ** PCI devices: 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge Alternate Subsystem: Hewlett-Packard Company Device 363a Flags: bus master, 66MHz, medium devsel, latency 0 Capabilities: [c4] HyperTransport: Slave or Primary Interface Capabilities: [54] HyperTransport: UnitID Clumping Capabilities: [40] HyperTransport: Retry Mode Capabilities: [9c] HyperTransport: #1a Capabilities: [f8] HyperTransport: #1c 00:02.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext gfx port 0) Flags: bus master, fast devsel, latency 0 Bus: primary=00,
Re: [RFC] Process for maintaining stable updates for drm for Lucid
On 08/30/2010 02:27 AM, Ben Hutchings wrote: On Sun, 2010-08-29 at 16:26 -0700, Brad Figg wrote: On 08/29/2010 02:17 PM, Ben Hutchings wrote: On Thu, Aug 26, 2010 at 10:04:16AM -0500, Steve Conklin wrote: The Lucid kernel consists of the 2.6.32 kernel plus the DRM tree from 2.6.33. Now that GregKH has announced the end of stable updates for the 2.6.33 kernel, the Ubuntu kernel stable maintenance team has been discussing the best way to continue to maintain a set of stable updates for the 2.6.33 DRM. I have prepared a wiki page based on our discussions, and would now like to open discussion to the Ubuntu kernel team mailing list. I'm interested in cooperating in this. I have prepared a git branch with drm changes from 2.6.34.3 up to 2.6.34.6 as a basis for Debian kernel updates. I can make that public and post the patches for review if you want to consider pulling that. Ben. Ben, What are your thoughts on taking drm patches once the 2.6.34 stable tree closes? I think we should keep taking applicable patches from the oldest active stable series after 2.6.33, possibly adding intermediate patches that they depend on (example: da7be68, backported to 2.6.34.6, depends on c414a11, not present in 2.6.33.y). The Debian kernel update policy is: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines. Ben. We surely are interested in looking through 2.6.34.y drm patches to see which ones we think look good. If you already got a tree prepared there, lets have a look together. Our policies for patches are close there and also close to what upstream stable has. While 2.6.33.y existed we chose to require people to submit it to upstream stable as this ensured at least that subsystem maintainers would be involved in the review and could intervene if things would not be applicable. And sending patches to upstream stable also ensures fixes would go upstream (if still being applicable). So the big question is how we go forward now that .33 and .34 have gone out of support upstream? Some thoughts I have here are: - patches need to be tested to fix the reported issues - we should prefer patches from upstream - if backports are required or the patch only is relevant to .33, we should require/ask for an ack from a subsystem maintainer. - we probably should require (as upstream stable does) that patches are self contained and small. Otherwise someone will come up with a giant backport just because it fixes and issue. - maybe some sort of review mechanism like Greg does would be useful We had been talking about the idea of looking at upstream stable patches for drm in general. Though our feeling was that the more into the future we go, the less applicable are patches there in general. And even if they apply, they might depend on changes not present and thus break things. So we basically need a way to proceed in a manner that allows us to get fixes while trying to keep regressions out. Ideally we would have subsystem maintainers support by having them add comments about .33 compliance when submitting to upstream stable. But I guess that is too much to ask for. I think we (Debian and Ubuntu) can gain a lot from working together on this. And Ben, feel free to bring up anything that you think won't work for Debian or things you think would be better. We basically want to have an upstream stable LTS for drm in .33 while not having the benefit of having the same upstream support as Greg does (maybe yet). Stefan -- 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/4c7b7f4a.6060...@canonical.com
Obsolete support for old-style xen and kernel-package types in debian/ dir
I noticed that debian/templates/ contains a bunch of what I think is
obsolete support for old-style Xen split-modules packaging as well as
the kernel-package image type. Is it worth cleaning that up in trunk
and/or sid? Specifically I think the following could be removed:
debian/templates/control.image.type-kernel-package.in
debian/templates/control.image.type-modulesextra.in
debian/templates/control.image.type-modulesinline.in
debian/templates/image.xen.postinst.in
debian/templates/image.xen.postrm.in
debian/templates/image.xen.prerm.in
and debian/bin/gencontrol.py:do_flavour_packages could be simplified by
switching uses of type: plain-s390-tape to type: standalone allowing
removal of the special casing in favour of something like:
+image = self.templates[control.image.type-%s %
config_entry_image['type']]
+build_modules = config_entry_image['type'] != 'standalone'
(or maybe a separate 'modules' boolean in the config entries)
I'm not sure that the provides: linux-modules-xxx in image.type-plain
is still useful if the modulesextra variant is removed, I suspect that
could also be dropped.
The patch at the bottom illustrates what I think could be dropped if
desired.
(I suspect there is also scope for similar cleanups in linux-latest-2.6)
I also noticed that control.image.type-standalone.in and
debian/templates/control.image.type-plain.in differ in that the former
does not depend on module-init-tools (which is certainly deliberate) but
it also does not recommend firmware-linux-free or depend on linux-base
+debconf (which I'm not sure about).
I happened to notice all of this while investigating a warning from the
build process:
dpkg-gencontrol: warning: Depends field of package ...: unknown
substitution variable ${shlibs:Depends}
I suspect shlibs:Depends can be removed from the depends in
templates/control.image.*.in since a linux-image package is unlikely to
contain binaries with shlibs dependencies IMHO.
Ian
diff --git a/linux-2.6/debian/bin/gencontrol.py
b/linux-2.6/debian/bin/gencontrol.py
index 389660a..fa1a47e 100755
--- a/linux-2.6/debian/bin/gencontrol.py
+++ b/linux-2.6/debian/bin/gencontrol.py
@@ -155,29 +155,8 @@ class Gencontrol(Base):
packages_dummy = []
packages_own = []
-if config_entry_image['type'] == 'plain-s390-tape':
-image = self.templates[control.image.type-standalone]
-build_modules = False
-elif config_entry_image['type'] == 'plain-xen':
-raise RuntimeError
-image = self.templates[control.image.type-modulesextra]
-build_modules = True
-config_entry_xen = self.config.merge('xen', arch, featureset,
flavour)
-if config_entry_xen.get('dom0-support', True):
-p =
self.process_packages(self.templates['control.xen-linux-system'], vars)
-l = PackageRelationGroup()
-xen_versions = []
-for xen_flavour in config_entry_xen['flavours']:
-for version in config_entry_xen['versions']:
-l.append(xen-hypervisor-%s-%s % (version,
xen_flavour))
-xen_versions.append('%s-%s' % (version, xen_flavour))
-makeflags['XEN_VERSIONS'] = ' '.join(xen_versions)
-p[0]['Depends'].append(l)
-packages_dummy.extend(p)
-else:
-build_modules = True
-image = self.templates[control.image.type-%s %
config_entry_image['type']]
-#image = self.templates[control.image.type-modulesinline]
+image = self.templates[control.image.type-%s %
config_entry_image['type']]
+build_modules = config_entry_image['type'] != 'standalone'
config_entry_xen = self.config.merge('xen', arch, featureset, flavour)
if config_entry_xen.get('dom0-support', False):
@@ -207,11 +186,6 @@ class Gencontrol(Base):
self.merge_packages(packages, packages_own + packages_dummy, arch)
-if config_entry_image['type'] == 'plain-xen':
-for i in ('postinst', 'postrm', 'prerm'):
-j = self.substitute(self.templates[image.xen.%s % i], vars)
-file(debian/%s.%s % (packages_own[0]['Package'], i),
'w').write(j)
-
def get_config(*entry_name):
entry_real = ('image',) + entry_name
entry = self.config.get(entry_real, None)
diff --git a/linux-2.6/debian/config/s390/defines
b/linux-2.6/debian/config/s390/defines
index 8f58399..8f29ab7 100644
--- a/linux-2.6/debian/config/s390/defines
+++ b/linux-2.6/debian/config/s390/defines
@@ -28,7 +28,7 @@ parts: tape
[s390-tape_image]
initramfs: false
override-localversion: s390
-type: plain-s390-tape
+type: standalone
[s390x_description]
hardware: IBM zSeries
@@ -44,5 +44,5 @@ parts: tape
[s390x-tape_image]
initramfs: false
override-localversion: s390x
-type:
Re: Bug#594623: xserver-xorg-video-intel: after upgrade to 2.12.0+legacy1-1 X freeze on gdm start
On Mon, Aug 30, 2010 at 00:52:40 +0300, Kamen Naydenov wrote:
If I run glxgears X crashes badly - black screen or screen shot and
only SysRq commands works (can't test network access).
OK, I can reproduce a crash when running glxgears.
Program received signal SIGSEGV, Segmentation fault.
0xb760d91e in ?? () from /lib/i686/cmov/libc.so.6
(gdb) bt full
#0 0xb760d91e in ?? () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#1 0xb76107fc in ?? () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#2 0xb7610d2d in realloc () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#3 0x080a9cf3 in Xrealloc (ptr=0xb76e43a0, amount=3077456856)
at ../../os/utils.c:1122
No locals.
#4 0x080a107e in miRectAlloc (pRgn=0x94a2494, n=20) at ../../mi/miregion.c:392
data = value optimized out
#5 0x080a2890 in miAppendNonO (badreg=0xbffbe398, pOverlap=0xbffbe3bc)
at ../../mi/miregion.c:530
pNextRect = value optimized out
#6 miRegionOp (badreg=0xbffbe398, pOverlap=0xbffbe3bc)
at ../../mi/miregion.c:793
bot = value optimized out
numRects = value optimized out
ytop = value optimized out
newSize = value optimized out
prevBand = 10
top = value optimized out
ybot = value optimized out
curBand = 0
r2y1 = value optimized out
oldData = value optimized out
r1y1 = value optimized out
#7 miRegionValidate (badreg=0xbffbe398, pOverlap=0xbffbe3bc)
at ../../mi/miregion.c:1377
half = 1
numRects = 10
ri = 0x94a2480
numRI = 3
sizeRI = value optimized out
i = value optimized out
rit = value optimized out
box = 0x94a2494
riBox = value optimized out
ret = 1
#8 0x0815eafc in miValidateTree (pParent=0x9160e30, pChild=0x93c6210,
kind=VTMap) at ../../mi/mivaltree.c:741
totalClip = {extents = {x1 = 0, y1 = 25, x2 = 1024, y2 = 600},
data = 0x0}
childClip = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0},
data = 0x81effb8}
childUnion = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 600},
data = 0x956a650}
exposed = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0},
data = 0x81effb8}
pScreen = 0x91223a0
pWin = 0x93c6210
overlap = 1
viewvals = value optimized out
forward = -1074011240
#9 0x080992f5 in MapWindow (pWin=0x93c6210, client=0x9393990)
at ../../dix/window.c:2671
event = {u = {u = {type = 19 '\023', detail = 0 '\000',
sequenceNumber = 983}, keyButtonPointer = {pad00 = 64421907,
time = 242, root = 14681649, event = 0, child = 0, rootX = 0,
rootY = 0, eventX = 0, eventY = 0, state = 0,
sameScreen = 0 '\000', pad1 = 0 '\000'}, enterLeave = {
pad00 = 64421907, time = 242, root = 14681649, event = 0,
child = 0, rootX = 0, rootY = 0, eventX = 0, eventY = 0,
state = 0, mode = 0 '\000', flags = 0 '\000'}, focus = {
pad00 = 64421907, window = 242, mode = 49 '1', pad1 = 6 '\006',
pad2 = 224 '\340', pad3 = 0 '\000'}, expose = {pad00 = 64421907,
window = 242, x = 1585, y = 224, width = 0, height = 0,
count = 0, pad2 = 0}, graphicsExposure = {pad00 = 64421907,
drawable = 242, x = 1585, y = 224, width = 0, height = 0,
minorEvent = 0, count = 0, majorEvent = 0 '\000',
pad1 = 0 '\000', pad2 = 0 '\000', pad3 = 0 '\000'},
noExposure = {pad00 = 64421907, drawable = 242, minorEvent = 1585,
majorEvent = 224 '\340', bpad = 0 '\000'}, visibility = {
pad00 = 64421907, window = 242, state = 49 '1', pad1 = 6 '\006',
pad2 = 224 '\340', pad3 = 0 '\000'}, createNotify = {
pad00 = 64421907, parent = 242, window = 14681649, x = 0, y = 0,
width = 0, height = 0, borderWidth = 0, override = 0 '\000',
bpad = 0 '\000'}, destroyNotify = {pad00 = 64421907,
event = 242, window = 14681649}, unmapNotify = {
pad00 = 64421907, event = 242, window = 14681649,
fromConfigure = 0 '\000', pad1 = 0 '\000', pad2 = 0 '\000',
pad3 = 0 '\000'}, mapNotify = {pad00 = 64421907, event = 242,
window = 14681649, override = 0 '\000', pad1 = 0 '\000',
pad2 = 0 '\000', pad3 = 0 '\000'}, mapRequest = {
pad00 = 64421907, parent = 242, window = 14681649}, reparent = {
pad00 = 64421907, event = 242, window = 14681649, parent = 0,
x = 0, y = 0, override = 0 '\000', pad1 = 0 '\000',
pad2 = 0 '\000', pad3 = 0 '\000'}, configureNotify = {
pad00 = 64421907, event = 242, window = 14681649,
aboveSibling = 0, x = 0, y = 0, width = 0, height = 0,
borderWidth = 0, override
Bug#594845: linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p/..../fs/sysfs/file.c:539
On Mon, 2010-08-30 at 13:39 +1000, Russell Stuart wrote: Package: linux-2.6 Version: 2.6.32-20 Severity: normal A 32 bit Sarge image running in an lxc container triggered this kernel BUG when it attempted to start an openvpn server. [...] Any net device outside of the initial network namespace does not appear in sysfs. (I believe this was finally fixed in 2.6.35.) The tun driver attempts to register additional device attributes that appear in sysfs, and it hits this BUG because the net device itself doesn't appear in sysfs. We should be able to avoid the crash, but since the tun device will not be visible in sysfs it might not work completely. 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#594845: Acknowledgement (linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p/..../fs/sysfs/file.c:539)
On Mon, 2010-08-30 at 17:34 +1000, Russell Stuart wrote: The problem disappears in linux-image-2.6.35-trunk-amd64_2.6.35-1~experimental.2. Yes, as I expected. Can you please test the attached patch against the version in unstable? Directions for rebuilding an official kernel package are at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. From e5e7a7a14da22681abd96a305753e8cdcf898d40 Mon Sep 17 00:00:00 2001 From: Ben Hutchings b...@decadent.org.uk Date: Mon, 30 Aug 2010 14:38:14 +0100 Subject: [PATCH] tun: Don't add sysfs attributes to devices without sysfs directories Prior to Linux 2.6.35, net devices outside the initial net namespace did not have sysfs directories. Attempting to add attributes to them will trigger a BUG(). Reported-by: Russell Stuart russell-deb...@stuart.id.au Signed-off-by: Ben Hutchings b...@decadent.org.uk --- drivers/net/tun.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 4fdfa2a..0f77aca 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1006,7 +1006,8 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) if (err 0) goto err_free_sk; - if (device_create_file(tun-dev-dev, dev_attr_tun_flags) || + if (!net_eq(dev_net(tun-dev), init_net) || + device_create_file(tun-dev-dev, dev_attr_tun_flags) || device_create_file(tun-dev-dev, dev_attr_owner) || device_create_file(tun-dev-dev, dev_attr_group)) printk(KERN_ERR Failed to create tun sysfs files\n); -- 1.7.1 signature.asc Description: This is a digitally signed message part
Bug#594886: linux-image-2.6.32-5-amd64: Computer freeze on network traffic
On Mon, 2010-08-30 at 14:16 +0200, Marcos García Ochoa wrote: Subject: linux-image-2.6.32-5-amd64: Computer freeze on network traffic Package: linux-2.6 Version: 2.6.32-20 Severity: important *** Please type your report below this line *** On my Targa Traveller 826 WS, any kernel from 2.6.26 on will freeze sooner or later (usually in less than two minutes if transfers achieve over 50KB/s) when network traffic is allowed. Typical system failures happen before half a minute has passed after obtaining IP address through DHCP, and many times _during_ DHCP negotiation. It doesn't seem to be a NIC related problem as it fails when using the integrated 8139 or a PCMCIA FA410TX card. I haven't tested wifi cards, though. If the IP is configured by hand, the system stays alive a bit longer, but it will quickly die if high speed transfers (over 50-60KB/s in this case) are started (typically, apt-get update or apt-get upgrade will bring the system down). AFAICS, it's such a total freeze I need to cold-boot the computer to keep working. I'm making do currently with a custom 2.6.28.10 kernel (latest version that allows me not to use the tickless option, IIRC). This sounds like a hardware problem, not a kernel bug. 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 594845
Processing commands for cont...@bugs.debian.org: tags 594845 + patch Bug #594845 [linux-2.6] linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p//fs/sysfs/file.c:539 Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 594845: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594845 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.12831761563391.transcr...@bugs.debian.org
Processed: tagging 594845
Processing commands for cont...@bugs.debian.org: tags 594845 + moreinfo Bug #594845 [linux-2.6] linux-image-2.6.32-5-amd64: kernel BUG at /build/buildd-linux-2.6_2.6.32-20-amd64-lNUT1p//fs/sysfs/file.c:539 Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 594845: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594845 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.12831761563378.transcr...@bugs.debian.org
Bug#592187: [stable] Bug#576838: virtio network crashes again
On Thu, 2010-08-26 at 09:32 +0200, Lukas Kolbe wrote: Hi, I was finally able to identify the patch series that introduced the fix (they were introduced to -stable in 2.6.33.2): cb63112 net: add __must_check to sk_add_backlog a12a9a2 net: backlog functions rename 51c5db4 x25: use limited socket backlog c531ab2 tipc: use limited socket backlog 37d60aa sctp: use limited socket backlog 9b3d968 llc: use limited socket backlog 230401e udp: use limited socket backlog 20a92ec tcp: use limited socket backlog ab9dd05 net: add limit for socket backlog After applying these to 2.6.32.17, I wasn't able to trigger the failure anymore. What failure? 230401e didn't apply cleanly with git cherry-pick on top of 2.6.32.17, so there might be some additional work needed. @Greg: would it be possible to have these fixes in the next 2.6.32? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592187#69 for details: they fix a guest network crash during heavy nfs-io using virtio. These are a lot of patches, looking like they are adding a new feature. I would need to get the ack of the network maintainer before I can add them. David? I don't mean to nag (hm well, maybe I do) and I know you were busy preparing the guard-page fixes, but what's the status of this? In the meantime, we triggered this bug also on barebone hardware using nfs over tcp with default [rw]sizes of about 1MiB. On the real hardware, the kernel oopsed, not only the network stack ... With these patches applied, everything works smoothly. I'd really love to see a stable 2.6.32 ... Is there anything I can do to help reaching a decision with this issue? Regards, Lukas -- 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/1283176797.5722.13.ca...@quux.techfak.uni-bielefeld.de
mlock/guard page/xen-tools lenny
hey Ian, I haven't seen any reports of xen problems w/ the latest lenny DSA that added the guard page code. I looked at backporting the 3 patches from Linus - but the mlock patch touches code that didn't exist in .26, so I'm wondering if that patch is just not needed. -- dann frazier -- 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/20100830142223.ga23...@lackof.org
Bug#594886: linux-image-2.6.32-5-amd64: Computer freeze on network traffic
El 30/08/2010 15:51, Ben Hutchings escribió: This sounds like a hardware problem, not a kernel bug. Ben. It might be a hardware problem. But I find it interesting that it didn't happen on 2.6.18 on AMD64, it happens on 2.6.26 stable and not on my custom compiled version, and so on... and it doesn't happen either with Ubuntu kernels. Not that I'm too knowledgeable about the Linux kernel, but either the kernel highlighted a hidden hardware fault or it was the other way around. Frankly, being able to work with different kernel configurations except the Debian stock kernels would point to those kernels having the problem, wouldn't it? -- Ta otro mail... Marcos (cualquier parecido con la coincidencia es pura realidad) -- 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/4c7bc4ea.9060...@bigfoot.com
Bug#592187: [stable] Bug#576838: virtio network crashes again
On Mon, Aug 30, 2010 at 03:59:57PM +0200, Lukas Kolbe wrote: On Thu, 2010-08-26 at 09:32 +0200, Lukas Kolbe wrote: Hi, I was finally able to identify the patch series that introduced the fix (they were introduced to -stable in 2.6.33.2): cb63112 net: add __must_check to sk_add_backlog a12a9a2 net: backlog functions rename 51c5db4 x25: use limited socket backlog c531ab2 tipc: use limited socket backlog 37d60aa sctp: use limited socket backlog 9b3d968 llc: use limited socket backlog 230401e udp: use limited socket backlog 20a92ec tcp: use limited socket backlog ab9dd05 net: add limit for socket backlog After applying these to 2.6.32.17, I wasn't able to trigger the failure anymore. What failure? 230401e didn't apply cleanly with git cherry-pick on top of 2.6.32.17, so there might be some additional work needed. @Greg: would it be possible to have these fixes in the next 2.6.32? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592187#69 for details: they fix a guest network crash during heavy nfs-io using virtio. These are a lot of patches, looking like they are adding a new feature. I would need to get the ack of the network maintainer before I can add them. David? I don't mean to nag (hm well, maybe I do) and I know you were busy preparing the guard-page fixes, but what's the status of this? In the meantime, we triggered this bug also on barebone hardware using nfs over tcp with default [rw]sizes of about 1MiB. On the real hardware, the kernel oopsed, not only the network stack ... With these patches applied, everything works smoothly. I'd really love to see a stable 2.6.32 ... Is there anything I can do to help reaching a decision with this issue? As I stated above, I need the ACK from David to be able to add these patches. David? thanks, greg k-h -- 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/20100830145017.ga8...@kroah.com
Processed: tagging 594886
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 594886 + moreinfo Bug #594886 [linux-2.6] linux-image-2.6.32-5-amd64: Computer freeze on network traffic Added tag(s) moreinfo. End of message, stopping processing here. Please contact me if you need assistance. -- 594886: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594886 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.12831848433848.transcr...@bugs.debian.org
Bug#594886: linux-image-2.6.32-5-amd64: Computer freeze on network traffic
On Mon, 2010-08-30 at 16:49 +0200, Marcos García Ochoa wrote: El 30/08/2010 15:51, Ben Hutchings escribió: This sounds like a hardware problem, not a kernel bug. Ben. It might be a hardware problem. But I find it interesting that it didn't happen on 2.6.18 on AMD64, it happens on 2.6.26 stable and not on my custom compiled version, and so on... and it doesn't happen either with Ubuntu kernels. Not that I'm too knowledgeable about the Linux kernel, but either the kernel highlighted a hidden hardware fault or it was the other way around. Frankly, being able to work with different kernel configurations except the Debian stock kernels would point to those kernels having the problem, wouldn't it? Yes, this is a good point. Can you test with our kernel version 2.6.35, available from experimental? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: Digital signature
Re: [RFC] Process for maintaining stable updates for drm for Lucid
On Mon, Aug 30, 2010 at 11:52:10AM +0200, Stefan Bader wrote: On 08/30/2010 02:27 AM, Ben Hutchings wrote: On Sun, 2010-08-29 at 16:26 -0700, Brad Figg wrote: On 08/29/2010 02:17 PM, Ben Hutchings wrote: [...] I'm interested in cooperating in this. I have prepared a git branch with drm changes from 2.6.34.3 up to 2.6.34.6 as a basis for Debian kernel updates. I can make that public and post the patches for review if you want to consider pulling that. [...] We surely are interested in looking through 2.6.34.y drm patches to see which ones we think look good. If you already got a tree prepared there, lets have a look together. I have pushed my branch to: git://git.debian.org/kernel/linux-2.6.git#linux-2.6.32-drm33 (gitweb: http://git.debian.org/?p=kernel/linux-2.6.git;a=shortlog;h=refs/heads/linux-2.6.32-drm33) [...] - patches need to be tested to fix the reported issues - we should prefer patches from upstream - if backports are required or the patch only is relevant to .33, we should require/ask for an ack from a subsystem maintainer. - we probably should require (as upstream stable does) that patches are self contained and small. Otherwise someone will come up with a giant backport just because it fixes and issue. - maybe some sort of review mechanism like Greg does would be useful [...] I agree with all of the above. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: Digital signature
Processed: tagging 593679
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 593679 fixed-upstream Bug #593679 [linux-2.6] OCFS2: 2 node cluster, kernel BUG at fs/ocfs2/dlm/dlmthread.c:169! Added tag(s) fixed-upstream. End of message, stopping processing here. Please contact me if you need assistance. -- 593679: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593679 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.128318685619570.transcr...@bugs.debian.org
[bts-link] source package linux-2.6
# # bts-link upstream status pull for source package linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #594149 (http://bugs.debian.org/594149) # * http://bugzilla.kernel.org/show_bug.cgi?id=17081 # * remote status changed: (?) - NEW usertags 594149 + status-NEW # remote status report for #588782 (http://bugs.debian.org/588782) # * http://bugzilla.openvz.org/show_bug.cgi?id=1509 # * remote status changed: (?) - NEW usertags 588782 + status-NEW # remote status report for #588782 (http://bugs.debian.org/588782) # * http://bugzilla.openvz.org/show_bug.cgi?id=1509 # * remote status changed: (?) - NEW usertags 588782 + status-NEW # remote status report for #594125 (http://bugs.debian.org/594125) # * https://bugs.freedesktop.org/show_bug.cgi?id=29406 # * remote status changed: (?) - NEW usertags 594125 + status-NEW thanks -- 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/20100830163605.1154.33978.btsl...@merkel.debian.org
RFP: kernel handbook
Package: wnpp - Forwarded message from songbird ctx02...@centurytel.net - From: songbird ctx02...@centurytel.net To: b...@decadent.org.uk Subject: wishlist item auto package alioth kernel handbook when changes committed Date: Wed, 18 Aug 2010 21:21:05 -0400 hello, i'm still figuring much out and not sure if this wishlist item is already out there or not (i tried to look at the BTS but my phone line is very slow and i didn't see it). while testing the upgrade from Lenny to Squeeze on my machine the Kernel Handbook would have been very helpful, if i could have downloaded it via a *.deb and installed it. could this could be triggered as an automatic upload to unstable when the text is updated in the alioth repository? and more generally i think this should be a normal thing for documents hosted on alioth so that they do get current versions available in sid/testing and eventually to stable release (so that people like me at the other end of a slow line or using sneakernet and DVD images have more docs). i think some debian wiki sites should do this too as they contain a lot of helpful information. if you do add this as an actual wishlist item and want to add an e-mail address for me to use as tracking/notifier, please use a...@anthive.com (i've already got that one in the BTS). thanks for your efforts and consideration, and yes, i've gotten to a working 2.6.32 kernel so i have no bugs to report at the moment! :) thank you again, :) beni - End forwarded message - signature.asc Description: Digital signature
Processed: severity of 593549 is wishlist, tagging 593549
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 severity 593549 wishlist Bug #593549 [linux-2.6] linux-image-2.6-686: Missing driver to SD card for toshiba m30 Severity set to 'wishlist' from 'normal' tags 593549 upstream Bug #593549 [linux-2.6] linux-image-2.6-686: Missing driver to SD card for toshiba m30 Added tag(s) upstream. End of message, stopping processing here. Please contact me if you need assistance. -- 593549: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593549 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.128318832431799.transcr...@bugs.debian.org
Bug#593549: linux-image-2.6-686: Missing driver to SD card for toshiba m30
On Thu, 2010-08-19 at 09:59 +0200, yellowprotoss wrote: Package: linux-image-2.6-686 Version: 2.6.32+28 Severity: normal Dear Sir, I would like to affect a notice regarding a missing driver for the computer toshiba m30. The driver for SD card is unfortunately not seen by debian. Visibly dmesg returns nothign once one try to slot in/out the SD card into the SD reader. I can provide you these specifications: http://www.uni-koblenz.de/~tenshi/tosh/ As displayed it is said that LINUX has not yet managed to find out the item. I can provide you some more info anytime. Please if the bug is not suited to linux-image, please affect it to the right package into the collection of deb that exist for linux, you certainly have an amazing experience with linux to know how these are bound to the kernel. [...] This is not quite the right package (it is a meta package) but I have reassigned it appropriately. However, Debian does not carry out driver development, so you should contact the SD/MMC developers at linux-...@vger.kernel.org. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: Digital signature
Re: [RFC] Process for maintaining stable updates for drm for Lucid
One thing that I would like to point out is that, there are some infrastructural changes that have gone into drm since 2.6.33. Many/Most of the recent patches reference that new infrastructure. OEMs prefers to base on lucid, and they have products that are scheduled to be released based on newer intel chipsets. The patches that go into upstream for these chipsets will need to be backported from .35 to lucid, and also any reference to new infrastructure changed to use the old one. I am concerned this might lead to other problems. My suggestion if a patch has a dependency, we should try to pull in the dependency as well instead of backporting to .32. Cheers --- manjo On Mon, 30 Aug 2010, Stefan Bader wrote: On 08/30/2010 02:27 AM, Ben Hutchings wrote: On Sun, 2010-08-29 at 16:26 -0700, Brad Figg wrote: On 08/29/2010 02:17 PM, Ben Hutchings wrote: On Thu, Aug 26, 2010 at 10:04:16AM -0500, Steve Conklin wrote: The Lucid kernel consists of the 2.6.32 kernel plus the DRM tree from 2.6.33. Now that GregKH has announced the end of stable updates for the 2.6.33 kernel, the Ubuntu kernel stable maintenance team has been discussing the best way to continue to maintain a set of stable updates for the 2.6.33 DRM. I have prepared a wiki page based on our discussions, and would now like to open discussion to the Ubuntu kernel team mailing list. I'm interested in cooperating in this. I have prepared a git branch with drm changes from 2.6.34.3 up to 2.6.34.6 as a basis for Debian kernel updates. I can make that public and post the patches for review if you want to consider pulling that. Ben. Ben, What are your thoughts on taking drm patches once the 2.6.34 stable tree closes? I think we should keep taking applicable patches from the oldest active stable series after 2.6.33, possibly adding intermediate patches that they depend on (example: da7be68, backported to 2.6.34.6, depends on c414a11, not present in 2.6.33.y). The Debian kernel update policy is: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines. Ben. We surely are interested in looking through 2.6.34.y drm patches to see which ones we think look good. If you already got a tree prepared there, lets have a look together. Our policies for patches are close there and also close to what upstream stable has. While 2.6.33.y existed we chose to require people to submit it to upstream stable as this ensured at least that subsystem maintainers would be involved in the review and could intervene if things would not be applicable. And sending patches to upstream stable also ensures fixes would go upstream (if still being applicable). So the big question is how we go forward now that .33 and .34 have gone out of support upstream? Some thoughts I have here are: - patches need to be tested to fix the reported issues - we should prefer patches from upstream - if backports are required or the patch only is relevant to .33, we should require/ask for an ack from a subsystem maintainer. - we probably should require (as upstream stable does) that patches are self contained and small. Otherwise someone will come up with a giant backport just because it fixes and issue. - maybe some sort of review mechanism like Greg does would be useful We had been talking about the idea of looking at upstream stable patches for drm in general. Though our feeling was that the more into the future we go, the less applicable are patches there in general. And even if they apply, they might depend on changes not present and thus break things. So we basically need a way to proceed in a manner that allows us to get fixes while trying to keep regressions out. Ideally we would have subsystem maintainers support by having them add comments about .33 compliance when submitting to upstream stable. But I guess that is too much to ask for. I think we (Debian and Ubuntu) can gain a lot from working together on this. And Ben, feel free to bring up anything that you think won't work for Debian or things you think would be better. We basically want to have an upstream stable LTS for drm in .33 while not having the benefit of having the same upstream support as Greg does (maybe yet). Stefan -- kernel-team mailing list kernel-t...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kernel-team -- 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.00.1008301155370.25...@hungry
Re: [RFC] Process for maintaining stable updates for drm for Lucid
On Mon, Aug 30, 2010 at 12:08:08PM -0500, manoj.i...@canonical.com wrote: One thing that I would like to point out is that, there are some infrastructural changes that have gone into drm since 2.6.33. Many/Most of the recent patches reference that new infrastructure. OEMs prefers to base on lucid, and they have products that are scheduled to be released based on newer intel chipsets. The patches that go into upstream for these chipsets will need to be backported from .35 to lucid, and also any reference to new infrastructure changed to use the old one. I am concerned this might lead to other problems. My suggestion if a patch has a dependency, we should try to pull in the dependency as well instead of backporting to .32. [...] Debian generally tries to avoid ABI breakage in stable updates, though adding new exported symbols is fine. So long as you don't include patches that remove symbols, we can probably fudge the rest for ABI compatibility. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus signature.asc Description: Digital signature
Bug#592187: [stable] Bug#576838: virtio network crashes again
On Mon, Aug 30, 2010 at 09:46:36AM -0700, David Miller wrote: From: Greg KH g...@kroah.com Date: Mon, 30 Aug 2010 07:50:17 -0700 As I stated above, I need the ACK from David to be able to add these patches. David? I believe there were some regressions caused by these changes that were fixed later, a bit after those commites went into the tree. I'm only confortable ACK'ing this if someone does due diligence and checks for any such follow-on fixes to that series. It's a pretty non-trivial set of patches and has the potential to kill performance which would be a very serious regression. Fair enough. Who's done the checks to find out any problems with these patches? And what is keeping you from moving to the .35 kernel tree instead? thanks, greg k-h -- 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/20100830172107.ga10...@kroah.com
Processed: Re: Bug#594812: noflushd: Noflushd causes flush- processes to eat all CPU
Processing commands for cont...@bugs.debian.org: clone 594812 -1 Bug#594812: noflushd: Noflushd causes flush- processes to eat all CPU Bug 594812 cloned as bug 594923. block 594812 by -1 Bug #594812 [noflushd] noflushd: Noflushd causes flush- processes to eat all CPU Was not blocked by any bugs. Added blocking bug(s) of 594812: 594923 retitle -1 Zero writeback interval sends flush processes into busy loop Bug #594923 [noflushd] noflushd: Noflushd causes flush- processes to eat all CPU Changed Bug title to 'Zero writeback interval sends flush processes into busy loop' from 'noflushd: Noflushd causes flush- processes to eat all CPU' reassign -1 linux-image-2.6.32-5-amd64 Bug #594923 [noflushd] Zero writeback interval sends flush processes into busy loop Bug reassigned from package 'noflushd' to 'linux-image-2.6.32-5-amd64'. Bug No longer marked as found in versions noflushd/2.8-1. thanks Stopping processing here. Please contact me if you need assistance. -- 594923: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594923 594812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594812 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 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.128319537527603.transcr...@bugs.debian.org
Bug#586967: (no subject)
On Fri, 2010-08-06 at 22:24 +0200, Jens Schüßler wrote: I believe that this changes in 3c59x made my squeeze sytem unusuable since yesterdays upgrade from 2.6.32.5-15 to -18. I use a 3com card with this driver for years, and after booting the new kernel my system completely freezed reproducable after seconds online on the net. Unfortunately I wasn't able to find the deb of -15 anymore, and I got the same problen with another 3com card, so I had to change the network card to a DLink model and now everything workes fine. There were absolutely nothing in the logs, machine feezed completely, no keyboard response, so no SysReq worked, only power button saved me. What is the exact model you have (use lspci -nn -d 10b7:)? 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#586967: (no subject)
On Mon, 2010-08-30 at 20:52 +0100, Ben Hutchings wrote: On Fri, 2010-08-06 at 22:24 +0200, Jens Schüßler wrote: I believe that this changes in 3c59x made my squeeze sytem unusuable since yesterdays upgrade from 2.6.32.5-15 to -18. I use a 3com card with this driver for years, and after booting the new kernel my system completely freezed reproducable after seconds online on the net. Unfortunately I wasn't able to find the deb of -15 anymore, and I got the same problen with another 3com card, so I had to change the network card to a DLink model and now everything workes fine. There were absolutely nothing in the logs, machine feezed completely, no keyboard response, so no SysReq worked, only power button saved me. What is the exact model you have (use lspci -nn -d 10b7:)? Also can you try enabling some debug logging: rmmod 3c59x modprobe 3c59x debug=3 Then run dmesg to get the logged messages, and send them back. 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#594933: Manpage idmapd.conf.5 not shipped
Package: nfs-common Version: 1:1.2.2-4 Severity: normal Hi, It seems the manpage for /etc/idmapd.conf is not shipped (anymore?) by any package. I'm reporting this against nfs-common as this package is the one shipping the daemon. I've seen though that the man page is present in the sources for libnfsidmap, so maybe it's the library that should ship it (please reassign then). Without the man page, finding information about the static or ldap transports is… dificult :) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35.3-ruru0 (SMP w/4 CPU cores) Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.112 add and remove users and groups ii initscripts 2.88dsf-12 scripts for initializing and shutt ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcap2 1:2.19-3 support for getting/setting POSIX. ii libcomerr21.41.12-2 common error description library ii libevent-1.4-21.4.13-stable-1An asynchronous event notification ii libgssapi-krb5-2 1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - k ii libgssglue1 0.1-4 mechanism-switch gssapi library ii libk5crypto3 1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries ii libnfsidmap2 0.23-2 An nfs idmapping library ii librpcsecgss3 0.19-2 allows secure rpc communication us ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip ii netbase 4.42 Basic TCP/IP networking system ii portmap 6.0.0-2RPC port mapper ii ucf 3.0025 Update Configuration File: preserv nfs-common recommends no packages. nfs-common suggests no packages. -- no debconf information -- 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/20100830205059.6400.63292.report...@ruru.hq.k1024.org
Bug#594938: linux-image-2.6.32-5-686: Microsoft InteliMouse (PS/2) wheel broken
Package: linux-2.6 Version: 2.6.32-21 Severity: normal Tags: sid Hi, My mouse's (MS Intelimouse, PS/2 with a wheel) wheel stopped working since the last upgrade: pressing or scrolling the wheel does nothing, at all. xev does not see the event, but I cannot see it either with cat /dev/psaux or cat /dev/input/mouse0, while both show fancy characters when pressing the other buttons. Rebooting and chosing older kernel versions (2.6.30 or even 2.6.32-trunk-686) solves the problem. Thanks, -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-21) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Wed Aug 25 14:28:12 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=777ca468-3cbc-461a-8ee6-424a3f1ee7f0 ro quiet ** Not tainted ** Kernel log: [1.975417] usb 2-1: Product: DeskJet 920C [1.975419] usb 2-1: Manufacturer: Hewlett-Packard [1.975422] usb 2-1: SerialNumber: HU19T6R0HKBI [1.975512] usb 2-1: configuration #1 chosen from 1 choice [3.341478] udev: starting version 161 [3.726324] input: PC Speaker as /devices/platform/pcspkr/input/input1 [3.879776] ACPI: SSDT bf5ed720 0022A (v01 PmRef Cpu0Ist 3000 INTL 20040311) [3.880090] processor LNXCPU:00: registered as cooling_device0 [3.880249] ACPI: SSDT bf5edbe0 00152 (v01 PmRef Cpu1Ist 3000 INTL 20040311) [3.880281] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2 [3.880317] ACPI: Power Button [PWRB] [3.880849] processor LNXCPU:01: registered as cooling_device1 [3.880897] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [3.880922] ACPI: Power Button [PWRF] [4.223091] psmouse.c: bad data from KBC - timeout [4.274107] i801_smbus :00:1f.3: PCI INT B - GSI 19 (level, low) - IRQ 19 [4.353127] psmouse.c: bad data from KBC - timeout [4.353742] [drm] Initialized drm 1.1.0 20060810 [4.381799] psmouse.c: bad data from KBC - timeout [4.410469] psmouse.c: bad data from KBC - timeout [4.439139] psmouse.c: bad data from KBC - timeout [4.467807] psmouse.c: bad data from KBC - timeout [4.496476] psmouse.c: bad data from KBC - timeout [4.525148] psmouse.c: bad data from KBC - timeout [4.553818] psmouse.c: bad data from KBC - timeout [4.578212] intel_rng: FWH not detected [4.582487] psmouse.c: bad data from KBC - timeout [4.587386] parport_pc 00:09: reported by Plug and Play ACPI [4.587426] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE] [4.612366] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input4 [4.638691] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [4.638696] i915 :00:02.0: setting latency timer to 64 [4.642336] mtrr: type mismatch for d000,1000 old: write-back new: write-combining [4.642339] [drm] MTRR allocation failed. Graphics performance may suffer. [4.642386] i915 :00:02.0: irq 26 for MSI/MSI-X [4.642391] [drm] set up 7M of stolen space [4.642642] [drm] initialized overlay support [4.706408] Linux video capture interface: v2.00 [4.849898] bttv: driver version 0.9.18 loaded [4.849900] bttv: using 8 buffers with 2080k (520 pages) each for capture [4.849929] bttv: Bt8xx card found (0). [4.849938] bttv :03:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [4.849946] bttv0: Bt848 (rev 18) at :03:01.0, irq: 19, latency: 32, mmio: 0xe020 [4.852522] bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected] [4.852524] IRQ 19/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs [4.852547] bttv0: gpio: en=, out= in=00ff27ff [init] [4.853279] tveeprom 2-0050: Huh, no eeprom present (err=-6)? [4.853280] bttv0: tuner type unset [4.853337] bttv0: registered device video0 [4.853380] bttv0: registered device vbi0 [4.907665] Console: switching to colour frame buffer device 200x75 [4.915303] fb0: inteldrmfb frame buffer device [4.915305] registered panic notifier [4.915329] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [5.242261] usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x1504 [5.242282] usbcore: registered new interface driver usblp [5.391884] HDA Intel :00:1b.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [5.391908] HDA Intel :00:1b.0: setting latency timer to 64 [5.472707] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input5 [6.264324] Adding 1951888k swap on /dev/sdb2. Priority:-1 extents:1 across:1951888k [6.536163] usb-storage: device scan complete [6.536658] scsi 4:0:0:0: Direct-Access Generic USB SD Reader1.00 PQ: 0 ANSI: 0 [6.537161] scsi 4:0:0:1: Direct-Access Generic USB CF Reader1.01 PQ: 0 ANSI: 0 [6.537690] scsi 4:0:0:2: Direct-Access Generic USB SM Reader1.02 PQ: 0 ANSI: 0 [
Bug#594886: linux-image-2.6.32-5-amd64: Computer freeze on network traffic
El 30/08/2010 18:15, Ben Hutchings escribió: Yes, this is a good point. Can you test with our kernel version 2.6.35, available from experimental? Ben. Downloading. will probably try in ten hours from now or so, if I get enough free time at work :) I'm downloading dbg too, but I won't install it until told to. -- Ta otro mail... Marcos (cualquier parecido con la coincidencia es pura realidad) -- 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/4c7c2f99.4000...@bigfoot.com
Bug#586967: (no subject)
* Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2010-08-30 at 20:52 +0100, Ben Hutchings wrote: On Fri, 2010-08-06 at 22:24 +0200, Jens Schüßler wrote: I believe that this changes in 3c59x made my squeeze sytem unusuable since yesterdays upgrade from 2.6.32.5-15 to -18. I use a 3com card with this driver for years, and after booting the new kernel my system completely freezed reproducable after seconds online on the net. Unfortunately I wasn't able to find the deb of -15 anymore, and I got the same problen with another 3com card, so I had to change the network card to a DLink model and now everything workes fine. There were absolutely nothing in the logs, machine feezed completely, no keyboard response, so no SysReq worked, only power button saved me. What is the exact model you have (use lspci -nn -d 10b7:)? Also can you try enabling some debug logging: rmmod 3c59x modprobe 3c59x debug=3 Then run dmesg to get the logged messages, and send them back. Okay, I can do this tomorrow, have to change the cards back first. I hope that the debug output occurs in the syslog, as I said, the system freezed complete immediately. Jens -- 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/20100830230146.gb7...@sge.kicks-ass.org
Re: mlock/guard page/xen-tools lenny
On Mon, Aug 30, 2010 at 08:22:23AM -0600, dann frazier wrote: hey Ian, I haven't seen any reports of xen problems w/ the latest lenny DSA that added the guard page code. I looked at backporting the 3 patches from Linus - but the mlock patch touches code that didn't exist in .26, so I'm wondering if that patch is just not needed. fyi, I setup a Xen/lenny system and didn't have any problems w/ save/restore, so we're good afaict :) -- dann frazier -- 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/20100831045717.gd23...@lackof.org
