Re: Bug#605009: serious performance regression with ext4
On Sat, 27 Nov 2010, Jonathan Nieder wrote: c) extract(a.dpkg-new); extract(b.dpkg-new); extract(c.dpkg-new); fsync(a.dpkg-new); fsync(b.dpkg-new); fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); (c) will perform the best for most file systems, including ext4. [...] I am guessing you are doing (a) today --- am I right? (c) or (d) would be best. We are doing (c) today. Actually we are doing this: extract(a.dpkg-new); extract(b.dpkg-new); extract(c.dpkg-new); fsync(a.dpkg-new); rename(a.dpkg-new, a); fsync(b.dpkg-new); rename(b.dpkg-new, b); fsync(c.dpkg-new); rename(c.dpkg-new, c); But as I said, I tried (c) and it's not performing noticably better than the above. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101127085346.gd14...@rivendell.home.ouaza.com
Bug#605083: linux-2.6: MacBookAir3,* support: USB fixes
Package: linux-2.6 Severity: wishlist Hi, Following the previous set of patches, attached is another patch needed for proper support of the new MacBook Air machines. USB seems troublesome and doesn't work properly without this patch. Thanks, JB. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35 (SMP w/2 CPU cores) Locale: LANG=C, lc_ctype=fr...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Tested on MacBookAir3,1. Without this, we get EPROTO errors when fetching device config descriptors. Signed-off-by: Brian Tarricone br...@tarricone.org Reported-by: Benoit Gschwind gschw...@gnu-log.net Tested-by: Edgar Hucek gi...@dark-green.com Cc: Greg Kroah-Hartman g...@kroah.com --- drivers/usb/host/ehci-pci.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c index a1e8d27..8d24d1c 100644 --- a/drivers/usb/host/ehci-pci.c +++ b/drivers/usb/host/ehci-pci.c @@ -148,6 +148,18 @@ static int ehci_pci_setup(struct usb_hcd *hcd) if (pdev-revision 0xa4) ehci-no_selective_suspend = 1; break; + + /* MCP89 chips on the MacBookAir3,1 give EPROTO when + * fetching device descriptors unless LPM is disabled. + * There are also intermittent problems enumerating + * devices with PPCD enabled. + */ + case 0x0d9d: + ehci_info(ehci, disable lpm/ppcd for nvidia mcp89); + ehci-has_lpm = 0; + ehci-has_ppcd = 0; + ehci-command = ~CMD_PPCEE; + break; } break; case PCI_VENDOR_ID_VIA: -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#605009: serious performance regression with ext4
Hi! On Fri, 2010-11-26 at 16:52:54 -0500, Ted Ts'o wrote: On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote: Just to sum up what dpkg --unpack does in 1.15.8.6: 1/ set the package status as half-installed/reinst-required 2/ extract all the new files as *.dpkg-new 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by rename(foo.dpkg-new, foo) What are you doing? We already had this conversation some time ago in https://bugzilla.kernel.org/show_bug.cgi?id=15910. 1) Suppose package contains files a, b, and c. Which are you doing? [...] Anyway, dpkg is currently doing the variation on c that Raphaël posted, including making backups so that it can rollback the entire package if something goes wrong. (c) will perform the best for most file systems, including ext4. Well it does not, and that's also what was mentioned in the bug report. Something we've found out recently (as Raphaël mentioned too) is that with nodelalloc the performance issues *and* the zero-length issues disappear, which seems like a clear win to me, and so IMO changing the default file system mount option to nodelalloc seems to be the way to go. As a further optimization, if b and c does not exist, of course it would be better to extract into b and c directly, and skip the rename, i.e.: d) extract(a.dpkg-new); extract(b); # assuming the file b does not yet exist extract(c); # assuming the file c does not yet exist fsync(a.dpkg-new); fsync(b); fsync(c); rename(a.dpkg-new, a); ... and then set the package status as unpacked. That would make possible for partial files to appear on their final path and thus available for external use while they are being extracted. I don't think that's a good idea. regards, guillem -- 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/20101127094018.ga14...@gaara.hadrons.org
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
Ben, I'm running 4 days now without any disk errors anymore. As stated in my previous message this is with the RedHat patch applied. If I compair the patches I see that the patch you grabed upstream does not deal with t-limits.max_sectors Thanks for a reply Wouter -- 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/22752968add47840a7d404102c7563b005a82de...@vasco-be-exch2.vasco.com
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
dmesg output [ 861.86] WARNING: at /build/buildd-linux-2.6_2.6.32-27-i386-c5N4Hf/linux-2.6-2.6.32/debian/build/source_i386_none/net/sched/sch_generic.c:261 dev_watchdog+0xdb/0x170() [ 861.000115] NETDEV WATCHDOG: eth1 (via-rhine): transmit queue 0 timed out [ 861.000129] Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables tun rfcomm sco bridge stp bnep l2cap crc16 fuse arc4 ath5k mac80211 ath cfg80211 led_class hwmon_vid loop snd_cs5535audio snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq ecb snd_timer snd_seq_device aes_i586 aes_generic snd btusb geode_aes bluetooth soundcore rfkill evdev cdc_acm ac geode_rng processor button pcspkr snd_page_alloc rng_core cs5535_gpio usbhid hid usb_storage ext3 jbd mbcache nbd sd_mod crc_t10dif ata_generic pata_cs5536 ohci_hcd pata_amd ehci_hcd libata via_rhine thermal usbcore thermal_sys mii scsi_mod nls_base [last unloaded: scsi_wait_scan] [ 861.000473] Pid: 0, comm: swapper Not tainted 2.6.32-5-486 #1 [ 861.000487] Call Trace: [ 861.000515] [c1022479] ? warn_slowpath_common+0x5e/0x8a [ 861.000539] [c11cc5c7] ? dev_watchdog+0x0/0x170 [ 861.000563] [c10224d7] ? warn_slowpath_fmt+0x26/0x2a [ 861.000587] [c11cc6a2] ? dev_watchdog+0xdb/0x170 [ 861.000619] [c10064fa] ? pit_next_event+0x18/0x1c [ 861.000645] [c103c995] ? clockevents_program_event+0xbd/0xcb [ 861.000672] [c103d5f0] ? tick_dev_program_event+0x1e/0x80 [ 861.000703] [c102b3fe] ? run_timer_softirq+0x156/0x1cd [ 861.000735] [c10269fb] ? __do_softirq+0x8e/0x130 [ 861.000761] [c1026acd] ? do_softirq+0x30/0x3b [ 861.000785] [c1026b8c] ? irq_exit+0x25/0x53 [ 861.000808] [c1004211] ? do_IRQ+0x66/0x76 [ 861.000832] [c1003790] ? common_interrupt+0x30/0x40 [ 861.000858] [c1013d28] ? native_safe_halt+0x2/0x3 [ 861.000881] [c1007758] ? default_idle+0x37/0x55 [ 861.000903] [c1002363] ? cpu_idle+0x6a/0x83 [ 861.000927] [c1366714] ? start_kernel+0x2ea/0x2ef [ 861.000943] ---[ end trace 30d26edd26f93a3c ]--- [ 861.001106] eth1: Transmit timed out, status , PHY status 786d, resetting... [ 861.001924] eth1: link up, 100Mbps, full-duplex, lpa 0x4DE1 Looks like Ubuntu has the same issue: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454747 Bug seems to exist for a long time now. Should be fixed before Squeeze gets out officially! -- 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/4cf11d31.1010...@gmx.net
Re: Bug#605009: serious performance regression with ext4
On Fri, Nov 26, 2010 at 10:52 PM, Ted Ts'o ty...@mit.edu wrote: I am guessing you are doing (a) today --- am I right? (c) or (d) would be best. Are there any plans to provide an API for atomic (non-durable) file updates, not involving fsync? Would be simpler (for apps), faster and more general (because it makes less assumptions). Olaf -- 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/aanlkti=r39buhjzl+_-1go9gy0abyo6jcqr+wpbnp...@mail.gmail.com
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
Marcel Langner marcel.lang...@gmx.net writes: Bug seems to exist for a long time now. Should be fixed before Squeeze gets out officially! 1) Are the scheduling while atomic and transmit timed out different bugs? 2) Have you tried if this occurs with mainline kernel from kernel.org? I have a geode box with $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 498.106 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow bogomips: 996.21 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: and via-rhine $ dpkg-query -W linux-image-2.6.32-5-486 linux-image-2.6.32-5-4862.6.32-27 that sometimes goes to an odd state. Under lenny: fomalhaut:~$ ping -i 0.2 garfield 64 bytes from garfield.lan (10.7.3.37): icmp_seq=15 ttl=64 time=0.366 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=1 ttl=64 time=2914 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=2 ttl=64 time=2705 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=3 ttl=64 time=2497 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=4 ttl=64 time=2289 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=5 ttl=64 time=2081 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=6 ttl=64 time=1874 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=7 ttl=64 time=1666 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=8 ttl=64 time=1458 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=9 ttl=64 time=1250 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=10 ttl=64 time=1042 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=11 ttl=64 time=834 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=12 ttl=64 time=626 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=13 ttl=64 time=418 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=14 ttl=64 time=210 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=16 ttl=64 time=9344 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=17 ttl=64 time=9137 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=18 ttl=64 time=8929 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=19 ttl=64 time=8721 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=20 ttl=64 time=8513 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=21 ttl=64 time=8305 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=22 ttl=64 time=8098 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=23 ttl=64 time=7890 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=24 ttl=64 time=7681 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=25 ttl=64 time=7474 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=26 ttl=64 time=7266 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=27 ttl=64 time=7058 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=28 ttl=64 time=6850 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=29 ttl=64 time=6642 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=30 ttl=64 time=6434 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=31 ttl=64 time=6226 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=32 ttl=64 time=6018 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=33 ttl=64 time=5811 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=34 ttl=64 time=5603 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=35 ttl=64 time=5395 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=36 ttl=64 time=5186 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=37 ttl=64 time=4979 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=38 ttl=64 time=4771 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=39 ttl=64 time=4563 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=40 ttl=64 time=4355 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=41 ttl=64 time=4147 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=42 ttl=64 time=3939 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=43 ttl=64 time=3732 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=44 ttl=64 time=3524 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=45 ttl=64 time=3316 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=46 ttl=64 time=3108 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=47 ttl=64 time=2900 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=48 ttl=64 time=2692 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=49 ttl=64 time=2484 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=50 ttl=64 time=2276 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=51 ttl=64 time=2068 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=52 ttl=64 time=1860 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=53 ttl=64 time=1652 ms 64 bytes from garfield.lan (10.7.3.37): icmp_seq=54
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
Marcel Langner marcel.lang...@gmx.net writes: Does a report exists for this transmit timeout problem already? I don't know. I have hit the issue only twice and it is difficult to debug so I did not report it yet. No I have not. Do you think it makes sense to try it? It's a long time since I compiled my own kernel. I think that is needed. If it works with mainline kernel then we can start looking for the patch that fixed it. If it doesn't work then you can report the bug upstream. btw, always keep 575...@bugs.debian.org in Cc so that the bug discussion is not lost. -- 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/847hfyn49g@sauna.l.org
Bug#584314: lspci
here is the output of lspci -vv $ lspci -vv 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Acer Incorporated [ALI] Device 0090 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Device 0090 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at d020 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at 1800 [size=8] Region 2: Memory at c000 (32-bit, prefetchable) [size=256M] Region 3: Memory at d030 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Subsystem: Acer Incorporated [ALI] Device 0090 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Region 0: Memory at d028 (32-bit, non-prefetchable) [size=512K] Capabilities: access denied 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) Subsystem: Acer Incorporated [ALI] Device 0090 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at d034 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: HDA Intel 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: 8400-841f Prefetchable memory behind bridge: 8420-843f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 3000-3fff Memory behind bridge: 8440-845f Prefetchable memory behind bridge: 8460-847f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: 4000-4fff Memory behind bridge: 8480-849f Prefetchable memory behind bridge:
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
I think that is needed. If it works with mainline kernel then we can start looking for the patch that fixed it. If it doesn't work then you can report the bug upstream. I guess I will then. Thanks for sharing. Nice to know, there are others with the same rare issues. Marcel -- 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/4cf12eec.7080...@gmx.net
Bug#575833: problem still exists and should be fixed for embedded systems like the ALIX
Network just crashed again. I will compile/install the new kernel first and try copying again. -- 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/4cf13f71.2030...@gmx.net
Bug#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
Neil, would you mind looking at this: On Sat, 2010-11-27 at 10:49 +0100, Wouter D'Haeseleer wrote: Ben, I'm running 4 days now without any disk errors anymore. As stated in my previous message this is with the RedHat patch applied. If I compair the patches I see that the patch you grabed upstream does not deal with t-limits.max_sectors I've tried backporting your commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 to Linux 2.6.26 in Debian stable but it doesn't seem to fix the problem there. My version is http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=57;filename=0002-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch;att=1;bug=604457 and RH's very different patch for RHEL 5 is https://bugzilla.redhat.com/attachment.cgi?id=342638action=diffcontext=patchcollapsed=headers=1format=raw Our bug log is at http://bugs.debian.org/604457. Ben. -- Ben Hutchings, Debian Developer and kernel team member signature.asc Description: This is a digitally signed message part
Bug#605083: linux-2.6: MacBookAir3,* support: USB fixes
On Sat, 2010-11-27 at 10:31 +0100, Julien BLACHE wrote: Package: linux-2.6 Severity: wishlist Hi, Following the previous set of patches, attached is another patch needed for proper support of the new MacBook Air machines. USB seems troublesome and doesn't work properly without this patch. This is not yet accepted upstream. Please ping this bug when it is, giving the commit hash as a reference if possible. 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#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888
On Fri, 2010-11-26 at 15:38 +0100, Bjørn Mork wrote: Ivan Sergio Borgonovo i...@webthatworks.it writes: I've just tested 2.6.32-28 from latest iso and it still doesn't work. The version of this driver included in experimental is reported to work on other distribution (0.17). If you'd point me to some RTFM to help you test something that could give some more chance to add support to these controller in the upcoming stable I'd try to help. A start would be to use the reportbug tool so that the kernel team got all the relevant data in the bug report, in particular the lspci listing. Took me a while to finally find a PCI device id to verify which devices you're after. Finally found it in http://launchpadlibrarian.net/51569322/Lspci.txt: 01:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 9240 [1000:0073] (rev 02) which was added to the driver between v2.6.32..v2.6.33. commit 879111224d in Linus' tree is the one that actually added the device to the module alias list. I've included it below. You could try and see if this is enough, or if the whole driver needs to be updated to the 2.6.33 version (which is LSI megasas version 00.00.04.12-rc1). I've cherry-picked these two as dependencies: commit c35188377f12e5e0a74f18c3dfdd67baf88db514 Author: Yang, Bo bo.y...@lsi.com Date: Tue Oct 6 14:18:02 2009 -0600 [SCSI] megaraid_sas: Add poll mechanism to megaraid sas driver commit 72c4fd36dc7f755a5245ef2495fe27d5084d776d Author: Yang, Bo bo.y...@lsi.com Date: Tue Oct 6 14:20:59 2009 -0600 [SCSI] megaraid_sas: add sysfs for AEN polling and these as necessary fixes to the added code: commit 7bebf5c79cb62766c76c6c1b9c77b86496fd363e Author: Yang, Bo bo.y...@lsi.com Date: Tue Oct 6 14:40:58 2009 -0600 [SCSI] megaraid_sas: allocate the application cmds to sas2 controller commit 0c79e681eef10810a5ed41a2eb1dce244ab1c37d Author: Yang, Bo bo.y...@lsi.com Date: Tue Oct 6 14:47:35 2009 -0600 [SCSI] megaraid_sas: Fix the fix for fw hang caused by megaraid sas application 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#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Sat, 27 Nov 2010 19:53:54 + Ben Hutchings b...@debian.org wrote: Neil, would you mind looking at this: On Sat, 2010-11-27 at 10:49 +0100, Wouter D'Haeseleer wrote: Ben, I'm running 4 days now without any disk errors anymore. As stated in my previous message this is with the RedHat patch applied. If I compair the patches I see that the patch you grabed upstream does not deal with t-limits.max_sectors I've tried backporting your commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 to Linux 2.6.26 in Debian stable but it doesn't seem to fix the problem there. My version is http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=57;filename=0002-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch;att=1;bug=604457 and RH's very different patch for RHEL 5 is https://bugzilla.redhat.com/attachment.cgi?id=342638action=diffcontext=patchcollapsed=headers=1format=raw Our bug log is at http://bugs.debian.org/604457. Ben. Hi Ben, You probably know most of this, but: The problem is that with stacked devices, if the lower device has a merge_bvec_fn, and the upper device never bothers to call it, then the upper device must make sure that it never sends a bio with more than one page in the bi_iovec. This is a property of the block device interface. The patch you back-ported fixes md so when it is the upper device it behaves correctly. However in the original problem, the md/raid10 is the lower device, and dm is the upper device. So dm needs to be fixed. Despite the fact that I learned about setting blk_queue_max_segments on the dm mailing list (if I remember correctly), dm still doesn't include this fix in mainline. The fix I would recommend for 2.6.26 is to add if (q-merge_bvec_fn) rs-max_phys_segments = 1; to dm_set_device_limits. Though the redhat one is probably adequate. If you really need an upstream fix, you will need to chase upstream to apply one :-( NeilBrown signature.asc Description: PGP signature
Processed: tagging 604083
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 604083 + pending Bug #604083 [linux-2.6] add support for megaraid 9240 9260 9280 8704 8708 8880 Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 604083: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604083 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.12908941799270.transcr...@bugs.debian.org
Processed: tagging 604457
Processing commands for cont...@bugs.debian.org: tags 604457 + upstream Bug #604457 [linux-2.6] linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k Bug #461644 [linux-2.6] linux-image-2.6.18-5-xen-686: Exporting an lvm-on-md LV to Xen as a disk results in kernel errors and corrupt filesystems Added tag(s) upstream. Added tag(s) upstream. thanks Stopping processing here. Please contact me if you need assistance. -- 604457: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604457 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.12908942919695.transcr...@bugs.debian.org
Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888
On Wed, 2010-11-24 at 19:48 +0100, Ivan Sergio Borgonovo wrote: [...] I don't know how to help further to increase the chances that squeeze will have support for these controllers. If you could point me to some instructions I could follow to give you some useful feedback I'll be happy to try. I've applied the upstream changes to add support for the 9240. You can test the result by following the instructions at http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official-vcs. The distribution name to use is 'sid' (all our changes for 'squeeze' are still going via 'sid'). 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#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
Package: linux-2.6 Severity: wishlist Tags: patch (resending without attachments so it's not too big for the list, they can be found on the bug report, sorry for the inconvenience) Hey people, First, please excuse me, I wasn't able to attend the Paris Miniconf and thus the kernel summit, to propose this at that time. In any case, it's not about Squeeze so there's still a lot of time to discuss this anyway. I'd like to propose adding a new featureset to Debian kernels for Wheezy, using grsecurity (http://www.grsecurity.net) patchset. == Introduction For people not familiar with grsecurity, the website as plenty of information, but it's basically a hardening patch for the Linux kernel, with major features beeing: * a role-based access control system * chroot() hardening * memory protection using PaX (address randomization, arbitrary code execution prevention...) * auditing On the long term the best would be to upstream those features mainline, and there's actually a process to do that from Ubuntu developers (https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening), but in the meantime having a grsecurity enabled kernel by default in Debian would be really nice, in my opinion. I know some people concerned about security have the habit to rebuild a vanilla kernel anyway, but I think some people and organization would be very interested by having a hardened kernel available in Debian, like virtual hosting companies etc. Doing it using a featureset is nice because it's not too intrusive (it's not the default, it has to be chosen explicitly by the user and it's a separate patch in the source package) and using the existing linux-2.6 package architecture it's actually quite easy. == Implementation Attached is a patch (against Debian linux-2.6 svn tree, for the 2.6.32-28 kernel, targeted to Squeeze) which do that. Basically it adds the latest grsecurity patch, defines the variants where it's used and the default config. So far I've only tested on i386 and amd64 so I didn't do anything on other architectures. The grsecurity patch itself has been edited because some of the files touched by the patch have already been patched by backports from latest kernel versions, for example. It's not really hard work to do, and it shouldn't be necessary for 2.6.36 kernel. The sha256sum of the edited patch is: 8df533f83817542277e34fed9ae766b9059a144a73fe536d003569b17ac03f1f grsecurity-2.2.0-2.6.32.25-201011151726+debian.patch and I've attached it to the bug so it's easier to look at it independantly of the svn patch. Packages based on Squeeze kernel are available on http://molly.corsac.net/~corsac/debian/kernel-grsec (it's apt-get'able for amd64 or the dsc is present for those who just want to look at the source package). == Configuration The KConfig is the one I use, which is open to discussion (like everything else anyway). I've tried to be fairly secure, so some features might not work for some people. When possible, options are configurable at runtime using sysctl. Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so people can fine-tune their installation. I didn't find a way to ship it cleanly in a linux-image package so if anyone has an idea please say so. For example, I've set kernel.grsecurity.disable_priv_io=0 so Xorg with KMS works fine (it still won't work for non-KMS people though). Without that, Xorg will fail to start with: xf86EnableIOPorts: failed to set IOPL for I/O (operation not permitted) so it's still clear why this happen and it's easy to fix. I've tried to provide a default config which could fit for most people, but I think it should be tuned by users in the end, so besides the gids I'm not sure there's much to discuss. === Chroot chroot sysctls are all configured to 1, but for people working on Debian stuff, especially building in chroots, it might be a good idea to set: kernel.grsecurity.chroot_execlog=0 kernel.grsecurity.chroot_deny_chmod=0 === Trusted Path Execution Trusted Path Execution (TPE) is a way to restrict code execution. Basically, binaries execution is forbidden from paths not owned by root. It's configured using a GID (which I chose to be 500, once again it can and should be discussed), it and can be opt-in (users belonging to the group are prevented to execute “untrusted” binaries) or opt-out (only people belonging to the group can execute “untrusted” binaries). I chose the latter, to have a “secure by default” system. === Socket restrictions The same kind of restrictions exist on socket, gid-based again: when you add users to the relevant group, you deny them the right to create sockets. I've chosen gids 501, 502 and 503 for respectively “all” sockets, “client” sockets and “server” sockets. Once again, this is configurable using sysctls. == Maintenance While I'd like to participate in the upstreaming effort, as noted above I still think it'd be a good idea to have a grsecurity kernel for Wheezy. As it means more work for the
[PATCH] econet: Move to staging; remove from defconfig
Recent review has revealed several bugs in econet and other obscure
protocol implementations that can be exploited by local users for
denial of service or privilege escalation.
The econet protocol (PF_ECONET) is unmaintained. There appear to be
no published applications for it, and it has never progressed beyond
'experimental' status.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
As requested, I'm actually renaming the directory this time. I also
noticed that ECONET was enabled in a couple of ARM defconfigs and
explicitly disabled in various other defconfigs, so I've removed those
lines as well.
This is based on linux-next; I hope it applies to staging.
Ben.
arch/arm/configs/ixp4xx_defconfig |3 ---
arch/arm/configs/pnx4008_defconfig |3 ---
arch/mips/configs/gpr_defconfig |3 ---
arch/mips/configs/mtx1_defconfig|3 ---
arch/um/defconfig |1 -
arch/xtensa/configs/common_defconfig|1 -
arch/xtensa/configs/iss_defconfig |1 -
arch/xtensa/configs/s6105_defconfig |1 -
drivers/staging/Kconfig |2 ++
drivers/staging/Makefile|1 +
{net = drivers/staging}/econet/Kconfig |0
{net = drivers/staging}/econet/Makefile|0
{net = drivers/staging}/econet/af_econet.c |0
net/Kconfig |1 -
net/Makefile|1 -
15 files changed, 3 insertions(+), 18 deletions(-)
rename {net = drivers/staging}/econet/Kconfig (100%)
rename {net = drivers/staging}/econet/Makefile (100%)
rename {net = drivers/staging}/econet/af_econet.c (100%)
diff --git a/arch/arm/configs/ixp4xx_defconfig
b/arch/arm/configs/ixp4xx_defconfig
index 5c50239..bd85c32 100644
--- a/arch/arm/configs/ixp4xx_defconfig
+++ b/arch/arm/configs/ixp4xx_defconfig
@@ -88,9 +88,6 @@ CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
diff --git a/arch/arm/configs/pnx4008_defconfig
b/arch/arm/configs/pnx4008_defconfig
index bd481f0..8301e4a 100644
--- a/arch/arm/configs/pnx4008_defconfig
+++ b/arch/arm/configs/pnx4008_defconfig
@@ -101,9 +101,6 @@ CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
diff --git a/arch/mips/configs/gpr_defconfig b/arch/mips/configs/gpr_defconfig
index 53edc13..9f9aa97 100644
--- a/arch/mips/configs/gpr_defconfig
+++ b/arch/mips/configs/gpr_defconfig
@@ -116,9 +116,6 @@ CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
diff --git a/arch/mips/configs/mtx1_defconfig b/arch/mips/configs/mtx1_defconfig
index 8146997..79cfb0b 100644
--- a/arch/mips/configs/mtx1_defconfig
+++ b/arch/mips/configs/mtx1_defconfig
@@ -154,9 +154,6 @@ CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
diff --git a/arch/um/defconfig b/arch/um/defconfig
index 564f3de..1fd4718 100644
--- a/arch/um/defconfig
+++ b/arch/um/defconfig
@@ -296,7 +296,6 @@ CONFIG_DEFAULT_TCP_CONG=cubic
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
-# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
diff --git a/arch/xtensa/configs/common_defconfig
b/arch/xtensa/configs/common_defconfig
index 1d230ee..8c8916c 100644
--- a/arch/xtensa/configs/common_defconfig
+++ b/arch/xtensa/configs/common_defconfig
@@ -239,7 +239,6 @@ CONFIG_IP_PNP_RARP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
-# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
diff --git a/arch/xtensa/configs/iss_defconfig
b/arch/xtensa/configs/iss_defconfig
index 7368164..de0c75f 100644
--- a/arch/xtensa/configs/iss_defconfig
+++ b/arch/xtensa/configs/iss_defconfig
@@ -249,7 +249,6 @@ CONFIG_DEFAULT_TCP_CONG=cubic
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
-# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
diff --git a/arch/xtensa/configs/s6105_defconfig
b/arch/xtensa/configs/s6105_defconfig
index bb84fbc..c273505 100644
--- a/arch/xtensa/configs/s6105_defconfig
+++ b/arch/xtensa/configs/s6105_defconfig
@@ -204,7 +204,6 @@ CONFIG_DEFAULT_TCP_CONG=cubic
Bug#604824: linux-2.6: problems with ata disk interface: temporary freezes
Let me repeat: Also send the output of 'lspci -vn', and the output of 'dmesg' when the system is booted without pci=noacpi. ^^^ 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 604748
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 604748 + pending Bug #604748 [linux-image-2.6.32-5-ixp4xx] linux-image-2.6.32-5-ixp4xx: kernel stack trace errors in pppol2tp.ko Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 604748: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604748 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.129089924832166.transcr...@bugs.debian.org
Bug#603229: Further information
On Tue, 2010-11-23 at 13:17 +0100, Frede Feuerstein wrote: Hi ! This shows something about what's going wrong. Could you please try adding 'debug' to the kernel parameters? That will show some more context for these errors. I booted 2.6.32-5 with the debug option on, and for comparison did the same with 2.6.30-2. The errors concerning the power management itself are also showing up in 2.6.30-2. The error message about 'domain-cpu_power' does not refer to power management, but to the scheduler's estimation of the processing power of each group of processor threads. The scheduler is trying to group the processor threads by: - NUMA node (NODE; sharing a connection to RAM) - Package (CPU; sharing some caches) - Core (MC; sharing execution units) so that it can make good decisions about where a task should run when it is ready to do so. But whereas 2.6.32-5 afterwards crashes with a divide error, 2.6.30-2 starts up normally: [...] I suppose that it is the divide error in [0.852154], we have to deal with. [...] The division by zero appears to be a result of getting bad information from the firmware about the groups of processors. I realise that this same bad information did not previously result in a crash, but I (and the upstream developers) need to know what that information is before we can understand how this can be avoided. 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#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
On Sat, 2010-11-27 at 23:34 +0100, Yves-Alexis Perez wrote: [...] == Configuration The KConfig is the one I use, which is open to discussion (like everything else anyway). I've tried to be fairly secure, so some features might not work for some people. When possible, options are configurable at runtime using sysctl. Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so people can fine-tune their installation. I didn't find a way to ship it cleanly in a linux-image package so if anyone has an idea please say so. I suggest you put it in a separate package e.g. linux-grsec-base and have the image packages depend on or recommend it. [...] === Trusted Path Execution Trusted Path Execution (TPE) is a way to restrict code execution. Basically, binaries execution is forbidden from paths not owned by root. It's configured using a GID (which I chose to be 500, once again it can and should be discussed), it and can be opt-in (users belonging to the group are prevented to execute “untrusted” binaries) or opt-out (only people belonging to the group can execute “untrusted” binaries). I chose the latter, to have a “secure by default” system. === Socket restrictions The same kind of restrictions exist on socket, gid-based again: when you add users to the relevant group, you deny them the right to create sockets. I've chosen gids 501, 502 and 503 for respectively “all” sockets, “client” sockets and “server” sockets. Once again, this is configurable using sysctls. These gids are in the 'dynamically assigned' range and must not be configured into the kernel; see Debian policy §9.2. [...] == Conclusion So, what do you think? Does it look like a good idea, are there some blockers, some implementation details to discuss? Any comment is welcome. Ideally I'd like to see the worthwhile bits merged upstream in some form, with the most paranoid stuff in an LSM. But I'm not going to spend time on that myself. If you're prepared to maintain this and accept that it might not be kept for more than one release then I have no objection. 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
Re: [PATCH] econet: Move to staging; remove from defconfig
On Sat, Nov 27, 2010 at 10:44:28PM +, Ben Hutchings wrote:
Recent review has revealed several bugs in econet and other obscure
protocol implementations that can be exploited by local users for
denial of service or privilege escalation.
The econet protocol (PF_ECONET) is unmaintained. There appear to be
no published applications for it, and it has never progressed beyond
'experimental' status.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
As requested, I'm actually renaming the directory this time. I also
noticed that ECONET was enabled in a couple of ARM defconfigs and
explicitly disabled in various other defconfigs, so I've removed those
lines as well.
This is based on linux-next; I hope it applies to staging.
Ben.
arch/arm/configs/ixp4xx_defconfig |3 ---
arch/arm/configs/pnx4008_defconfig |3 ---
arch/mips/configs/gpr_defconfig |3 ---
arch/mips/configs/mtx1_defconfig|3 ---
arch/um/defconfig |1 -
arch/xtensa/configs/common_defconfig|1 -
arch/xtensa/configs/iss_defconfig |1 -
arch/xtensa/configs/s6105_defconfig |1 -
No need to change the defconfigs, they will get updated on their own if
they need to be.
drivers/staging/Kconfig |2 ++
drivers/staging/Makefile|1 +
{net = drivers/staging}/econet/Kconfig |0
{net = drivers/staging}/econet/Makefile|0
{net = drivers/staging}/econet/af_econet.c |0
net/Kconfig |1 -
net/Makefile|1 -
15 files changed, 3 insertions(+), 18 deletions(-)
rename {net = drivers/staging}/econet/Kconfig (100%)
rename {net = drivers/staging}/econet/Makefile (100%)
rename {net = drivers/staging}/econet/af_econet.c (100%)
diff --git a/arch/arm/configs/ixp4xx_defconfig
b/arch/arm/configs/ixp4xx_defconfig
index 5c50239..bd85c32 100644
--- a/arch/arm/configs/ixp4xx_defconfig
+++ b/arch/arm/configs/ixp4xx_defconfig
@@ -88,9 +88,6 @@ CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
Doesn't this imply that someone is actually using this?
CONFIG_WAN_ROUTER=m
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
diff --git a/arch/arm/configs/pnx4008_defconfig
b/arch/arm/configs/pnx4008_defconfig
index bd481f0..8301e4a 100644
--- a/arch/arm/configs/pnx4008_defconfig
+++ b/arch/arm/configs/pnx4008_defconfig
@@ -101,9 +101,6 @@ CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
-CONFIG_ECONET=m
-CONFIG_ECONET_AUNUDP=y
-CONFIG_ECONET_NATIVE=y
Same here and for the others.
I also need a TODO file for the staging directory location (see the
others for drivers that are going away as an example.)
And I need an ack from the networking maintainer to be able to accept
this also.
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/20101128002135.ga4...@suse.de
Bug#605200: linux-image-2.6.32-5-686: ipw2100 fatal interrupts using TKIP (WPA2-PSK)
Package: linux-2.6
Version: 2.6.32-27
Severity: normal
I set up a new wireless router and started getting frequent network
dropouts associated with the message ipw2100: Fatal interrupt.
Scheduling firmware restart. I have narrowed down the problem to TKIP
encryption in WPA2-PSK. If I use WEP or no encryption, or if I switch
my encryption to AES, I don't have this problem.
computer
- IBM Thinkpad X40
- Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)
- ipw2100 firmware 1.3
- Debian unstable
- linux-image-2.6.32-5-686 (no other kernel/driver versions tested)
- wpa_supplicant 0.6.10-2 with a hand-edited wpa_supplicant.conf. My
entry for this network is:
network={
ssid=ESSID
key_mgmt=WPA-PSK
psk=passphrase
}
access point
- Ubee (Ambit) U10C019
- All advanced wireless settings at their default (I played with them,
but none made a difference)
- WPA2-PSK set to enabled, WPA-PSK set to disabled (I don't WPA vs WPA2
makes a difference though)
Then, I switch the option WPA/WPA2 Encryption between TKIP and AES.
In the first case only, I get frequent fatal interrupts. They coincide
with me initiating network activity and happen very reliably, ie, an
interactive ssh session is unusable.
I have used other WPA-PSK networks in the past without trouble, but I
don't know whether they were using TKIP.
Let me know if I can provide more information.
Andrew
-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-27) (m...@debian.org) (gcc version
4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 22:47:19 UTC 2010
** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686
root=UUID=73cf35da-d145-4e4b-b662-3849f9a0ae64 ro
** Not tainted
** Kernel log:
[535890.008817] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[535900.432028] eth1: no IPv6 routers present
[535936.909959] ipw2100: Fatal interrupt. Scheduling firmware restart.
[535940.454914] ADDRCONF(NETDEV_UP): eth1: link is not ready
[535942.552687] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[535952.932024] eth1: no IPv6 routers present
[536157.662633] ADDRCONF(NETDEV_UP): eth1: link is not ready
[536183.396795] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[536193.756138] eth1: no IPv6 routers present
[537151.793914] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537180.200072] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537183.648274] ADDRCONF(NETDEV_UP): eth1: link is not ready
[537185.444772] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[537196.296144] eth1: no IPv6 routers present
[537236.830482] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537273.668774] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537277.457861] ADDRCONF(NETDEV_UP): eth1: link is not ready
[537279.448683] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[537289.548137] eth1: no IPv6 routers present
[537302.730971] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537316.785067] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537328.839142] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537405.981689] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537416.051722] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537425.833668] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537435.119690] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537448.773420] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537461.787196] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537469.185193] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537488.759275] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537516.269445] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537519.809102] ADDRCONF(NETDEV_UP): eth1: link is not ready
[537522.784864] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[537532.824135] eth1: no IPv6 routers present
[537759.989349] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537829.116000] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537973.187184] ipw2100: Fatal interrupt. Scheduling firmware restart.
[537985.113332] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538002.191421] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538026.917427] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538077.083697] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538091.265583] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538547.819491] ipw2100: Fatal interrupt. Scheduling firmware restart.
[538551.373429] ADDRCONF(NETDEV_UP): eth1: link is not ready
[538553.800688] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[538564.068035] eth1: no IPv6 routers present
[538593.374828] ADDRCONF(NETDEV_UP): eth1: link is not ready
[538595.436766] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[538606.396146] eth1: no IPv6 routers present
[538621.281997] ipw2100: Fatal interrupt. Scheduling firmware restart.
Re: [PATCH] econet: Move to staging; remove from defconfig
From: Greg KH gre...@suse.de Date: Sat, 27 Nov 2010 16:21:35 -0800 And I need an ack from the networking maintainer to be able to accept this also. I'm not applying this, nor do I want anyone else to. If people think this protocol is not maintained adequately right now, wait until you push it into staging. Furthermore, once Phil Blundell was made aware of security holes in econet he fixed them within a few days. Which is much better than I can say for some of the other protocols and filesystems in the tree. Moving this into staging, is therefore not appropriate. -- 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/20101127.172644.226781076.da...@davemloft.net
Bug#605204: linux-image-2.6.32-5-amd64: hp dv5035nr laptop: failed suspend make X crash
On Sat, 2010-11-27 at 20:23 -0500, Andres Cimmarusti wrote: Package: linux-2.6 Version: 2.6.32-27 Severity: normal I formulated a bug report (#583968) about this laptop not being able to suspend/hibernate with KMS enabled (Xpress 200m radeon chip). A fix was backported from upstream (http://article.gmane.org/gmane.comp.video.dri.devel/48108) and it seemed to solve the problem. I regret to report back after several tests that the patch works in most cases, but sometimes (when using audio just before suspending) the computer fails to go to sleep. The screen turns black as usual and shows the message: atiixp: codec reset timeout That is a sound driver, so it makes some sense that this is related to playing audio. This error presumably will cause the suspend process to be aborted. But also freezes there and a strange effect shows on screen. It looks like as if the black screen were slowly turning gray very diffusely, looks like smoke... I've tried switching VT to no avail. Only holding the power button works. [...] It sounds like the radeon driver is not properly restoring power to the LCD when the suspend process is aborted. Could you test Linux 2.6.36 as packaged in experimental? 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
Re: [PATCH] econet: Move to staging; remove from defconfig
On Sat, 2010-11-27 at 17:26 -0800, David Miller wrote: From: Greg KH gre...@suse.de Date: Sat, 27 Nov 2010 16:21:35 -0800 And I need an ack from the networking maintainer to be able to accept this also. I'm not applying this, nor do I want anyone else to. If people think this protocol is not maintained adequately right now, wait until you push it into staging. Furthermore, once Phil Blundell was made aware of security holes in econet he fixed them within a few days. Which is much better than I can say for some of the other protocols and filesystems in the tree. Those bugs were present for years and would have been obvious to anyone who cared to read the code. While I very much appreciate Phil's quick response, I don't think this reactive maintenance is enough. Moving this into staging, is therefore not appropriate. Oh well, it's not enough as if many distributions bothered to build it anyway, and we've learned our lesson now. Whether it's labelled as staging or not, it's dead, Jim. 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
Re: [PATCH] econet: Move to staging; remove from defconfig
On Sat, Nov 27, 2010 at 05:26:44PM -0800, David Miller wrote: From: Greg KH gre...@suse.de Date: Sat, 27 Nov 2010 16:21:35 -0800 And I need an ack from the networking maintainer to be able to accept this also. I'm not applying this, nor do I want anyone else to. If people think this protocol is not maintained adequately right now, wait until you push it into staging. Furthermore, once Phil Blundell was made aware of security holes in econet he fixed them within a few days. Which is much better than I can say for some of the other protocols and filesystems in the tree. Moving this into staging, is therefore not appropriate. Agreed. Ben, why are you trying to remove these protocols that people use and maintain? This is the third one that has been shot down recently... -- 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/20101128013923.ga9...@suse.de
Re: [PATCH] econet: Move to staging; remove from defconfig
On Sat, 2010-11-27 at 17:39 -0800, Greg KH wrote: On Sat, Nov 27, 2010 at 05:26:44PM -0800, David Miller wrote: From: Greg KH gre...@suse.de Date: Sat, 27 Nov 2010 16:21:35 -0800 And I need an ack from the networking maintainer to be able to accept this also. I'm not applying this, nor do I want anyone else to. If people think this protocol is not maintained adequately right now, wait until you push it into staging. Furthermore, once Phil Blundell was made aware of security holes in econet he fixed them within a few days. Which is much better than I can say for some of the other protocols and filesystems in the tree. Moving this into staging, is therefore not appropriate. Agreed. Ben, why are you trying to remove these protocols that people use and maintain? This is the third one that has been shot down recently... Moving to staging is a step toward removal, but not removal itself. I already stated the reasons I picked those three protocols; I'm not going to push the issue if David disagrees. 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#594561: State of the bug 594561
On Wed, 2010-11-24 at 22:29 +0100, Wenceslao González-Viñas wrote: Could someone tell me what is the state of this bug? What can I do to help to fix the problem? Well, you can prompt me to look again, as you did. :-) It seems that the code I changed, which looks like it sets the valid channels, is not actually used at all! The code that really does is another file. This code reads a region number from ROM in the chip, and sets the allowed channels according to that region's radio regulations. We should not override this. However, I cannot explain why the Windows driver decides that channels 1-13 are allowed (correct for Europe) while the Linux driver (which is based on it) decides that channels 1-11 are allowed. Perhaps there is a bug in reading the ROM. I've made a change to the driver that will cause it to log the entire contents of the ROM when it is loaded: Patch file: http://people.debian.org/~benh/rt28x0-dump-efuse.patch New module: http://people.debian.org/~benh/rt2870sta.ko GPG signature for module: http://people.debian.org/~benh/rt2870sta.ko.asc Please download the new module, verify my signature, then load the module by running: rmmod rt2870sta insmod rt2870sta.ko Finally run 'dmesg' to get the listing of the ROM data, and send that 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#605210: linux-image-2.6.32-5-amd64: cdrom stops working
Package: linux-2.6
Version: 2.6.32-27
Severity: important
If a cdrom is inserted, things work for a short while. I can for instance read
one or two
files on the CD. But, invariably, it stops working and a number of error
messages are logged.
Typical messages are:
[ 329.673137] UDF-fs: Partition marked readonly; forcing readonly mount
[ 329.740260] UDF-fs INFO UDF: Mounting volume 'Antidote HD', timestamp
2010/06/30 16:20 (1000)
[ 446.568967] ata6: drained 32768 bytes to clear DRQ.
[ 446.575346] ata6.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 446.575352] sr 5:0:1:0: [sr0] CDB: Read(10): 28 00 00 00 07 85 00 00 1f 00
[ 446.575368] ata6.01: cmd a0/01:00:00:00:f8/00:00:00:00:00/b0 tag 0 dma 63488
in
[ 446.575369] res 40/00:02:08:08:00/00:00:00:00:00/b0 Emask 0x4
(timeout)
[ 446.575373] ata6.01: status: { DRDY }
[ 446.575426] ata6: soft resetting link
[ 451.728152] ata6.01: qc timeout (cmd 0xa1)
[ 451.728172] ata6.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 451.728175] ata6.01: revalidation failed (errno=-5)
[ 451.728225] ata6: soft resetting link
[ 461.884122] ata6.01: qc timeout (cmd 0xa1)
[ 461.884141] ata6.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 461.884145] ata6.01: revalidation failed (errno=-5)
[ 461.884195] ata6: soft resetting link
[ 492.040124] ata6.01: qc timeout (cmd 0xa1)
[ 492.040144] ata6.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 492.040147] ata6.01: revalidation failed (errno=-5)
[ 492.040151] ata6.01: disabled
[ 492.040265] ata6: soft resetting link
[ 492.196802] ata6: EH complete
[ 492.196832] sr 5:0:1:0: [sr0] Unhandled error code
[ 492.196835] sr 5:0:1:0: [sr0] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[ 492.196839] sr 5:0:1:0: [sr0] CDB: Read(10): 28 00 00 00 07 85 00 00 1f 00
[ 492.196850] end_request: I/O error, dev sr0, sector 7700
[ 492.196856] Buffer I/O error on device sr0, logical block 1925
[ 492.196864] Buffer I/O error on device sr0, logical block 1926
[ 492.196867] Buffer I/O error on device sr0, logical block 1927
[ 492.196871] Buffer I/O error on device sr0, logical block 1928
[ 492.196874] Buffer I/O error on device sr0, logical block 1929
[ 492.196878] Buffer I/O error on device sr0, logical block 1930
[ 492.196881] Buffer I/O error on device sr0, logical block 1931
[ 492.196885] Buffer I/O error on device sr0, logical block 1932
[ 492.196888] Buffer I/O error on device sr0, logical block 1933
[ 492.196891] Buffer I/O error on device sr0, logical block 1934
[ 492.196927] sr 5:0:1:0: [sr0] Unhandled error code
[ 492.196929] sr 5:0:1:0: [sr0] Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK
[ 492.196933] sr 5:0:1:0: [sr0] CDB: Read(10): 28 00 00 00 07 85 00 00 01 00
[ 492.196943] end_request: I/O error, dev sr0, sector 7700
[ 492.197355] VFS: busy inodes on changed media or resized disk sr0
[ 492.197851] VFS: busy inodes on changed media or resized disk sr0
[ 492.200278] VFS: busy inodes on changed media or resized disk sr0
(Then quite a few more of these. They continue after the cd has been reomved.)
I have tried another drive and get the same errors, so I don't think the
problem is
related to the drive itself. A harddisk is attached to the same controller,
making
a controller error a little less likely.
The problem has been around for a while. Less than a year, but certainly for
several
kernel versions.
-- Package-specific info:
** Version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-27) (m...@debian.org) (gcc version
4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 14:18:21 UTC 2010
** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64
root=UUID=4213b79c-6f32-4f5d-9690-825d96ebc45f ro quiet
** Not tainted
** Kernel log:
See above.
** Model information
sys_vendor:
product_name:
product_version:
chassis_vendor:
chassis_version:
bios_vendor: Award Software International, Inc.
bios_version: F2
board_vendor: Gigabyte Technology Co., Ltd.
board_name: 965GM-S2
board_version: x.x
** Loaded modules:
Module Size Used by
udf66628 1
binfmt_misc 6431 1
ip6table_filter 2384 0
ip6_tables 15075 1 ip6table_filter
ebtable_nat 1588 0
ebtables 13933 1 ebtable_nat
ppdev 5030 0
lp 7462 0
sco 7209 2
bridge 39646 0
stp 1440 1 bridge
bnep9443 2
rfcomm 29613 0
l2cap 24736 6 bnep,rfcomm
crc16 1319 1 l2cap
bluetooth 41827 6 sco,bnep,rfcomm,l2cap
rfkill 13044 2 bluetooth
kvm_intel 38050 0
kvm 213800 1 kvm_intel
battery 4998 0
autofs420805 1
acpi_cpufreq 0
cpufreq_powersave902 0
cpufreq_stats 2659 0
cpufreq_userspace 1992 0
Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
Please can you test whether this is fixed in 2.6.32-28? We backported a KVM feature (VCPU_EVENTS) which meant we needed an additional fix beyond the one which Michael Tokarev identified, and that was done in -28. Note, by the way, that an i386 version of qemu-kvm will not work with the amd64 kernel flavour in version 2.6.32-28. I have a candidate fix for this but I am trying to get the upstream KVM maintainers to check it. 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#604457: linux-image-2.6.26-2-xen-686: Raid10 exporting LV to xen results in error can't convert block across chunks or bigger than 64k
On Sun, 2010-11-28 at 08:28 +1100, Neil Brown wrote: On Sat, 27 Nov 2010 19:53:54 + Ben Hutchings b...@debian.org wrote: Neil, would you mind looking at this: On Sat, 2010-11-27 at 10:49 +0100, Wouter D'Haeseleer wrote: Ben, I'm running 4 days now without any disk errors anymore. As stated in my previous message this is with the RedHat patch applied. If I compair the patches I see that the patch you grabed upstream does not deal with t-limits.max_sectors I've tried backporting your commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 to Linux 2.6.26 in Debian stable but it doesn't seem to fix the problem there. My version is http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=57;filename=0002-md-deal-with-merge_bvec_fn-in-component-devices-bett.patch;att=1;bug=604457 and RH's very different patch for RHEL 5 is https://bugzilla.redhat.com/attachment.cgi?id=342638action=diffcontext=patchcollapsed=headers=1format=raw Our bug log is at http://bugs.debian.org/604457. Ben. Hi Ben, You probably know most of this, but: The problem is that with stacked devices, if the lower device has a merge_bvec_fn, and the upper device never bothers to call it, then the upper device must make sure that it never sends a bio with more than one page in the bi_iovec. This is a property of the block device interface. The patch you back-ported fixes md so when it is the upper device it behaves correctly. However in the original problem, the md/raid10 is the lower device, and dm is the upper device. So dm needs to be fixed. Thanks, I didn't spot that subtlety. Despite the fact that I learned about setting blk_queue_max_segments on the dm mailing list (if I remember correctly), dm still doesn't include this fix in mainline. The fix I would recommend for 2.6.26 is to add if (q-merge_bvec_fn) rs-max_phys_segments = 1; to dm_set_device_limits. Though the redhat one is probably adequate. If you really need an upstream fix, you will need to chase upstream to apply one :-( I won't do that myself - as you can see, I don't really understand the issue fully. Is that fix also valid (modulo renaming of max_phys_segments) for later versions? Ben. -- Ben Hutchings, Debian Developer and kernel team member signature.asc Description: This is a digitally signed message part
Bug#603229: Further information
Hi ! The error message about 'domain-cpu_power' does not refer to power management, but to the scheduler's estimation of the processing power of each group of processor threads. The scheduler is trying to group the processor threads by: - NUMA node (NODE; sharing a connection to RAM) - Package (CPU; sharing some caches) - Core (MC; sharing execution units) So lets start here: On this machine NUMA node and Package are identical: CPU0 / CPU1 are one group and CPU2 / CPU3 is the other. As for all Socket 940 Opterons, the cores logically are complete CPUs i.e. do not share execution units. so that it can make good decisions about where a task should run when it is ready to do so. But whereas 2.6.32-5 afterwards crashes with a divide error, 2.6.30-2 starts up normally: [...] I suppose that it is the divide error in [0.852154], we have to deal with. [...] The division by zero appears to be a result of getting bad information from the firmware about the groups of processors. Well, technically a division error always is a result of bad data fed to that division. I rather meant, that this is the point to backtrace the error. Though the bios of the w2100z is known for some problems, the cpus are reported correctly by the bios and it is the latest version (R01-B5-S1). I realise that this same bad information did not previously result in a crash, but I (and the upstream developers) need to know what that information is before we can understand how this can be avoided. Are there any means to gather more information ? Tell me and i shall do it. Tilo -- 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/1290920436.4255.1025.ca...@localhost
Re: [PATCH] econet: Move to staging; remove from defconfig
From: Ben Hutchings b...@decadent.org.uk Date: Sun, 28 Nov 2010 01:53:35 + On Sat, 2010-11-27 at 17:26 -0800, David Miller wrote: From: Greg KH gre...@suse.de Date: Sat, 27 Nov 2010 16:21:35 -0800 And I need an ack from the networking maintainer to be able to accept this also. I'm not applying this, nor do I want anyone else to. If people think this protocol is not maintained adequately right now, wait until you push it into staging. Furthermore, once Phil Blundell was made aware of security holes in econet he fixed them within a few days. Which is much better than I can say for some of the other protocols and filesystems in the tree. Those bugs were present for years and would have been obvious to anyone who cared to read the code. While I very much appreciate Phil's quick response, I don't think this reactive maintenance is enough. These same arguments could for be made for RDS. Look at all the hellacious awful obvious crap we've discovered in that code recently. A simple read would have caught those too, and I don't see it's maintainer doing such things. So, you're very much still not convincing Ben, but feel free to keep trying. -- 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/20101127.223845.189711153.da...@davemloft.net
