Bug#608865: tmp noexec
Sorry for not following up sooner, it kind of slipped away since I had my workaround... ~#df /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/buildServer--1-tmp 4805760142028 4419612 4% /tmp So its obvious why your code snippet does not trigger: df /tmp does not output the information that /tmp is mounted noexec. Even though it definitely is mounted noexec: ~#mount | grep 'on /tmp' /dev/mapper/buildServer--1-tmp on /tmp type ext3 (rw,noexec,nosuid,nodev) -- Mit freundlichen Grüßen Martin Gerdes Fachinformatiker (Systemintegration) * * Deutsche Software Engineering Research GmbH * * Postanschrift: * Melanchthonstraße 19 - 02826 Görlitz - Germany * * Phone: +49 (0) 35 81 / 309 250 * Fax: +49 (0) 35 81 / 309 259 * * E-Mail: martin.ger...@dser.de * Web: http://www.dser.de * * Sitz der Gesellschaft: * Melanchthonstraße 19 - 02826 Görlitz - Germany * Registergericht: Amtsgericht Dresden - HRB 24819 * * Vertretungsberechtigte Geschäftsführer: * Johann Horch (CEO) - Marek Wester (CTO) * This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- 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/4d41300a.5030...@dser.de
Bug#608865: tmp noexec
On Thu, 2011-01-27 at 09:42 +0100, Martin Gerdes wrote: Sorry for not following up sooner, it kind of slipped away since I had my workaround... ~#df /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/buildServer--1-tmp 4805760142028 4419612 4% /tmp So its obvious why your code snippet does not trigger: df /tmp does not output the information that /tmp is mounted noexec. df is just used to get the device name for the mount point, the subsequent mount | grep actually checks for noexec. However because your device name is quite long df has split the entry over two lines which causes the awk expresion to print the wrong thing (nothing in fact). Maks, perhaps df -P helps? It's always annoyed me that there is no (to my knowledge) simple get the device name / mount point for this path tool in Unix. Alternatively if mount took an option which caused it to just print the information pertaining to a given path (inferring the relevant mount point from it) then that would be very useful. (the purpose of this paragraph is to provoke someone into saying oh, you can just use $FOO, ;-)) Ian. Even though it definitely is mounted noexec: ~#mount | grep 'on /tmp' /dev/mapper/buildServer--1-tmp on /tmp type ext3 (rw,noexec,nosuid,nodev) -- Mit freundlichen Grüßen Martin Gerdes Fachinformatiker (Systemintegration) * * Deutsche Software Engineering Research GmbH * * Postanschrift: * Melanchthonstraße 19 - 02826 Görlitz - Germany * * Phone: +49 (0) 35 81 / 309 250 * Fax: +49 (0) 35 81 / 309 259 * * E-Mail: martin.ger...@dser.de * Web: http://www.dser.de * * Sitz der Gesellschaft: * Melanchthonstraße 19 - 02826 Görlitz - Germany * Registergericht: Amtsgericht Dresden - HRB 24819 * * Vertretungsberechtigte Geschäftsführer: * Johann Horch (CEO) - Marek Wester (CTO) * This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- Ian Campbell Current Noise: Motörhead - Metropolis All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant -- 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/1296119809.14780.6843.ca...@zakaz.uk.xensource.com
Bug#611264: linux-image-2.6.32-5-amd64: Linux kernel tainted.
Package: linux-2.6
Version: 2.6.32-30
Severity: normal
See attached trace. Problem appeared when swithing network connection from
wlan0 to eth0.
-- Package-specific info:
** Version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 03:40:32 UTC 2011
** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64
root=UUID=bf4cba67-e87c-4ca6-a2bc-ba1b2c55114c ro nosplash quiet
acpi_backlight=vendor resume=UUID=d499e746-95bc-478d-9f10-f6416becc142 nosplash
quiet acpi_backlight=vendor resume=UUID=d499e746-95bc-478d-9f10-f6416becc142
** Tainted: W (512)
* Taint on warning.
** Kernel log:
[24617.893456] wlan0: direct probe to AP 00:18:6e:27:ce:84 (try 1)
[24617.898169] wlan0: direct probe responded
[24617.898175] wlan0: authenticate with AP 00:18:6e:27:ce:84 (try 1)
[24617.899649] wlan0: authenticated
[24617.899706] wlan0: associate with AP 00:18:6e:27:ce:84 (try 1)
[24617.903103] wlan0: RX AssocResp from 00:18:6e:27:ce:84 (capab=0x411 status=1
aid=0)
[24617.903109] wlan0: AP denied association (code=1)
[24617.903127] wlan0: deauthenticating from 00:18:6e:27:ce:84 by local choice
(reason=3)
[24631.176472] wlan0: direct probe to AP 00:18:6e:27:ce:84 (try 1)
[24631.179553] wlan0: direct probe responded
[24631.179559] wlan0: authenticate with AP 00:18:6e:27:ce:84 (try 1)
[24631.187425] wlan0: authenticated
[24631.187484] wlan0: associate with AP 00:18:6e:27:ce:84 (try 1)
[24631.194804] wlan0: RX AssocResp from 00:18:6e:27:ce:84 (capab=0x411 status=1
aid=0)
[24631.194811] wlan0: AP denied association (code=1)
[24631.194829] wlan0: deauthenticating from 00:18:6e:27:ce:84 by local choice
(reason=3)
[24644.559507] wlan0: direct probe to AP 00:18:6e:27:b4:44 (try 1)
[24644.564067] wlan0: direct probe responded
[24644.564074] wlan0: authenticate with AP 00:18:6e:27:b4:44 (try 1)
[24644.565778] wlan0: authenticated
[24644.565836] wlan0: associate with AP 00:18:6e:27:b4:44 (try 1)
[24644.574437] wlan0: RX AssocResp from 00:18:6e:27:b4:44 (capab=0x411 status=0
aid=11)
[24644.574443] wlan0: associated
[24644.601587] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[24654.912081] wlan0: no IPv6 routers present
[24867.702631] xscreensaver-gl[22857]: segfault at 4 ip 7fcf9478b0be sp
7fffd5813bb0 error 4 in libGL.so.1.2[7fcf9473+ae000]
[24902.801143] xscreensaver-gl[22888]: segfault at 4 ip 7f12839b20be sp
7fff91271410 error 4 in libGL.so.1.2[7f1283957000+ae000]
[25044.208269] ata1: exception Emask 0x10 SAct 0x0 SErr 0x5 action 0xf
[25044.208281] ata1: SError: { PHYRdyChg CommWake }
[25044.208297] ata1: hard resetting link
[25044.932077] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[25045.601051] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[25045.601063] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK)
filtered out
[25045.601072] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered
out
[25045.605917] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[25045.605927] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK)
filtered out
[25045.605936] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered
out
[25045.607967] ata1.00: configured for UDMA/100
[25045.612326] ata1.00: configured for UDMA/100
[25045.612333] ata1: EH complete
[25756.726662] xscreensaver-gl[23620]: segfault at 4 ip 7fd7bc5910be sp
7fff51006980 error 4 in libGL.so.1.2[7fd7bc536000+ae000]
[26296.785601] xscreensaver-gl[24042]: segfault at 4 ip 7f424154c0be sp
7fff07378090 error 4 in libGL.so.1.2[7f42414f1000+ae000]
[26844.288330] xscreensaver-gl[24461]: segfault at 4 ip 7f562b2cb0be sp
7fff395b04a0 error 4 in libGL.so.1.2[7f562b27+ae000]
[27384.307667] xscreensaver-gl[25911]: segfault at 4 ip 7f88ad1010be sp
7e585c60 error 4 in libGL.so.1.2[7f88ad0a6000+ae000]
[27924.325175] xscreensaver-gl[26356]: segfault at 4 ip 7f1d59dad0be sp
7fff47220330 error 4 in libGL.so.1.2[7f1d59d52000+ae000]
[31142.297568] xscreensaver-gl[31089]: segfault at 4 ip 7f0a00c440be sp
7fffb1004020 error 4 in libGL.so.1.2[7f0a00be9000+ae000]
[31682.350305] xscreensaver-gl[31447]: segfault at 4 ip 7f3f388320be sp
7fff4a015140 error 4 in libGL.so.1.2[7f3f387d7000+ae000]
[3.372461] xscreensaver-gl[31804]: segfault at 4 ip 7f22efeb90be sp
7fff94fc4170 error 4 in libGL.so.1.2[7f22efe5e000+ae000]
[32762.388070] xscreensaver-gl[32158]: segfault at 4 ip 7f73911dd0be sp
7fffadfc1090 error 4 in libGL.so.1.2[7f7391182000+ae000]
[33816.573351] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control:
None
[33816.573359] :00:19.0: eth0: 10/100 speed: disabling TSO
[33816.574850] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[33823.636127] wlan0: deauthenticating from 00:18:6e:27:b4:44 by local choice
(reason=3)
[33823.741277] Registered led device: iwl-phy0::radio
[33823.741327] Registered led
Processed: tagging 607041
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 607041 + pending Bug #607041 [linux-image-2.6.32-5-openvz-amd64] linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 607041: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607041 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.129614013513822.transcr...@bugs.debian.org
Bug#611216: linux-2.6 - New monitor chip: w83795
On Wed, Jan 26, 2011 at 10:20:10PM +0100, Bastian Blank wrote: Please add support for new monitor chip w83795. Okay. Either my system is broken, the existing driver is broken or my backport is broken. After some minutes/hours, both the main system and the ipmi-card looses access to the monitoring chip. Bastian -- She won' go Warp 7, Cap'n! The batteries are dead! -- 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/20110127151550.ga31...@wavehammer.waldi.eu.org
Bug#611278: linux-image-2.6.32-5-xen-amd64: boot fails when iommu is enabled in bios
Package: linux-2.6 Version: 2.6.32-30 Severity: important When enabling the BIOS IOMMU option, the system does not boot. The kernel resets itself endlessly. I've recorded a video of a boot attempt (it is 28MB): http://ward.vandewege.net/h8dgt-hibqf/iommu-reset.mov The hardware is Supermicro H8DGT-HIBQF http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8DGT-HIBQF.cfm It is currently running BIOS revision 1.0c (date 10/29/10). Thanks, Ward. -- Package-specific info: ** Version: Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-30) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed Jan 12 05:46:49 UTC 2011 ** Command line: placeholder root=UUID=1ab080f3-e10c-45aa-91c9-a339c384e3b6 ro ** Tainted: W (512) * Taint on warning. ** Kernel log: [ 261.667004] xen_allocate_pirq: returning irq 19 for gsi 19 [ 261.667124] xen: -- irq=19 [ 261.667134] Already setup the GSI :19 [ 261.667250] pciback :02:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 261.667384] pciback :02:00.0: PCI INT A disabled [ 390.372087] device vif2.0 entered promiscuous mode [ 390.386288] eth0: port 2(vif2.0) entering forwarding state [ 390.469449] ip_tables: (C) 2000-2006 Netfilter Core Team [ 390.603573] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 390.604535] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use [ 390.604639] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or [ 390.604639] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. [ 390.635127] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 390.658486] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 390.668642] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 390.668851] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 390.776312] pciback: vpci: :02:00.0: assign to virtual slot 0 [ 400.848073] vif2.0: no IPv6 routers present [ 404.753819] eth0: port 2(vif2.0) entering disabled state [ 404.776420] eth0: port 2(vif2.0) entering disabled state [ 405.001553] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 405.001780] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 405.011702] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 405.023602] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 436.434249] device vif3.0 entered promiscuous mode [ 436.448297] eth0: port 2(vif3.0) entering forwarding state [ 436.504563] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 436.516203] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 436.525930] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 436.526134] physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. [ 436.781413] pciback: vpci: :02:00.0: assign to virtual slot 0 [ 436.783759] pciback :02:00.0: device has been assigned to another domain! Over-writting the ownership, but beware. [ 437.964718] pciback :02:00.0: enabling device ( - 0002) [ 437.964899] xen: registering gsi 19 triggering 0 polarity 1 [ 437.964908] xen_allocate_pirq: returning irq 19 for gsi 19 [ 437.965044] xen: -- irq=19 [ 437.965056] Already setup the GSI :19 [ 437.965184] pciback :02:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 437.965343] pciback :02:00.0: setting latency timer to 64 [ 437.974877] blkback: ring-ref 768, event-channel 9, protocol 1 (x86_64-abi) [ 438.007384] blkback: ring-ref 769, event-channel 10, protocol 1 (x86_64-abi) [ 438.971703] pciback :02:00.0: Driver tried to write to a read-only configuration space field at offset 0x68, size 2. This may be harmless, but if you have problems with your device: [ 438.971709] 1) see permissive attribute in sysfs [ 438.971713] 2) report problems to the xen-devel mailing list along with details of your device obtained from lspci. [ 438.973267] xen: registering gsi 19 triggering 0 polarity 1 [ 438.973275] xen_allocate_pirq: returning irq 19 for gsi 19 [ 438.973408] xen: -- irq=19 [ 438.973417] Already setup the GSI :19 [
Bug#611278: linux-image-2.6.32-5-xen-amd64: boot fails when iommu is enabled in bios
On Thu, Jan 27, 2011 at 11:45:59AM -0500, Ward Vandewege wrote: When enabling the BIOS IOMMU option, the system does not boot. The kernel resets itself endlessly. Which version works? How do you know that it is no bug in the BIOS? The hardware is Supermicro H8DGT-HIBQF H8GQ6-F exhibits the same problem. Bastian -- There is an order of things in this universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 -- 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/20110127171501.ga1...@wavehammer.waldi.eu.org
Processed: [bts-link] source package linux-2.6
Processing commands for cont...@bugs.debian.org: # # 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 Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). # remote status report for #525220 (http://bugs.debian.org/525220) # * http://bugzilla.kernel.org/show_bug.cgi?id=10126 # * remote status changed: (?) - NEW usertags 525220 + status-NEW Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout There were no usertags set. Usertags are now: status-NEW. # remote status report for #580927 (http://bugs.debian.org/580927) # * http://bugzilla.openvz.org/show_bug.cgi?id=1299 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 580927 + fixed-upstream Bug #580927 [linux-2.6] linux-image-2.6.32-5-openvz-686: Uncharging too much ... res shmpages ub Added tag(s) fixed-upstream. usertags 580927 - status-NEW Bug#580927: linux-image-2.6.32-5-openvz-686: Uncharging too much ... res shmpages ub Usertags were: status-NEW. Usertags are now: . usertags 580927 + status-RESOLVED resolution-FIXED Bug#580927: linux-image-2.6.32-5-openvz-686: Uncharging too much ... res shmpages ub There were no usertags set. Usertags are now: status-RESOLVED resolution-FIXED. # remote status report for #607041 (http://bugs.debian.org/607041) # * http://bugzilla.openvz.org/show_bug.cgi?id=1723 # * remote status changed: PATCHSENT - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 607041 + fixed-upstream Bug #607041 [linux-image-2.6.32-5-openvz-amd64] linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE Added tag(s) fixed-upstream. usertags 607041 - status-PATCHSENT Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE Usertags were: status-PATCHSENT. Usertags are now: . usertags 607041 + status-RESOLVED resolution-FIXED Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE There were no usertags set. Usertags are now: status-RESOLVED resolution-FIXED. # remote status report for #589690 (http://bugs.debian.org/589690) # * https://bugs.freedesktop.org/show_bug.cgi?id=29153 # * remote status changed: REOPENED - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 589690 + fixed-upstream Bug #589690 [linux-2.6] [drm/i915] oops in i915_irq_emit on 965GM with UMS Added tag(s) fixed-upstream. usertags 589690 - status-REOPENED Bug#589690: [drm/i915] oops in i915_irq_emit on 965GM with UMS Usertags were: status-REOPENED. Usertags are now: . usertags 589690 + status-RESOLVED resolution-FIXED Bug#589690: [drm/i915] oops in i915_irq_emit on 965GM with UMS There were no usertags set. Usertags are now: status-RESOLVED resolution-FIXED. thanks Stopping processing here. Please contact me if you need assistance. -- 589690: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589690 607041: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607041 580927: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580927 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.12961503106257.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 #525220 (http://bugs.debian.org/525220) # * http://bugzilla.kernel.org/show_bug.cgi?id=10126 # * remote status changed: (?) - NEW usertags 525220 + status-NEW # remote status report for #580927 (http://bugs.debian.org/580927) # * http://bugzilla.openvz.org/show_bug.cgi?id=1299 # * remote status changed: NEW - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 580927 + fixed-upstream usertags 580927 - status-NEW usertags 580927 + status-RESOLVED resolution-FIXED # remote status report for #607041 (http://bugs.debian.org/607041) # * http://bugzilla.openvz.org/show_bug.cgi?id=1723 # * remote status changed: PATCHSENT - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 607041 + fixed-upstream usertags 607041 - status-PATCHSENT usertags 607041 + status-RESOLVED resolution-FIXED # remote status report for #589690 (http://bugs.debian.org/589690) # * https://bugs.freedesktop.org/show_bug.cgi?id=29153 # * remote status changed: REOPENED - RESOLVED # * remote resolution changed: (?) - FIXED # * closed upstream tags 589690 + fixed-upstream usertags 589690 - status-REOPENED usertags 589690 + status-RESOLVED resolution-FIXED 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/20110127174509.5717.52575.btsl...@busoni.debian.org
Re: Bug#605090: Updated patch
maximilian attems m...@stro.at schrieb: On Tue, 18 Jan 2011, Yves-Alexis Perez wrote: Kernel team, what do you think? Could the patches be merged against trunk? Config might still need some reviewing but that can be done once people start testing the packages. What follows is my personal view, in short what I miss most is an assessement of the involved cost of this specific feature branch. first of all merging a patch that deviates from mainline for an eternety and shows zero interest of upstream merging is not a good candidate. You get longterm plenty of cost versus allmost no benefit. I'm quite unsure that this patch benefits Debian. I disagree, the benefit is substantial. From a distant past look it was in fact quite untastefull. The second trouble is that I question your understanding of this patch. (viewing the way you answered waldi's questions). Third beside security theatre what is gained by it? What you call theatre is likely the most important decision factor for most people running Linux professionally. Fourth why not invest the time for Wheezy and have finally the mainline and security backed SELinux ready. This seems like a much better time investment. SELinux is mostly orthogonal to what grsecurity provides. Fifth the ninties are over, an upstream that still doesn't use an VSC seems very untrustworthy. That's silly. If there's anyone who has credible understanding of Linux kernel security then it's Brad and the PAX team. Cheers, Moritz -- 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/slrnik3kng.2mb@inutil.org
Re: Possible bug in kernel 2.6.37
Hi Jean, Given that the 2.6.37 kernel is only in experimental I think Debian can only offer very limited support for it. I recommend you stick with your dialog with upstream, it is likely to be the most effective way to get to the bottom of the issue. Ian. On Wed, 2011-01-26 at 21:02 +0100, Jean Baptiste FAVRE wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm not sure this is neither the right place, nor the right way to introduce my problem, but I've only small kernel knowledge. Please excuse me if I'm wrong. I'm using 2 Debian Squeeze Xen Dom0 servers. Those 2 servers provide PCI passthrough for a network card. The idea is to filter network trafic inside dedicated domU instead of having dom0 directly connected on the network. For my tests, I choose Debian Squeeze with 2.6.37 kernel from experimental. Here are the results: - - Debian Squeeze 32bits + 32bits 2.6.37 kernel: incoming packets larger than 128 bytes are blocked somewhere. - - Debian Squeeze 32bits + 64bits 2.6.37 kernel: everything works fine. - - Debian Squeeze 64bits + 64bits 2.6.37 kernel: everything works fine. My first thought was I discovered a bug in Xen PCI passthrough code. I exchange some mails on xen-devel mailing list about it, mostly with Konrad Rzeszutek Wilk. He asked me to do many tests which did not help to diagnose the problem. Then he suggest me to change memory allocated to domU from 256mb to 512mb. That solved my problem. Now, I don't know exactly what I shall do. Any help will be appreciated, Regards, Jean Baptiste Favre -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Afb8ACgkQM2eZoKJfKd3Y/QCgtMm2sTTj3VL/0hyPkMoP8my4 2lEAoKy13l/NiQBscuzCNmlgLc4aHfur =HIsl -END PGP SIGNATURE- -- Ian Campbell If anything can go wrong, it will. -- 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/1296160968.20804.48.camel@localhost.localdomain
Bug#611301: linux-image-2.6.37-trunk-amd64: uswsusp does not work on linux 2.6.37
Package: linux-2.6 Version: 2.6.37-1~experimental.1 Severity: normal On both the Debian experimental package and my package built from vanilla source uswsusp fails. It would attempt a suspend but never get to the part when pages are saved to disk. The screens go into suspend mode and the fans spin, power keeps on. On another system or with kernel 2.6.36-rc5 on this system uswsusp works flawlessly. From the top of my head I have these differences on the troublesome system: - older chipset with buggy ehci implementation that requires the ehci driver to be unloaded before suspend - openafs - oss4 (causes the missing modules) - cifs mounts -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: System manufacturer product_name: System Product Name product_version: System Version chassis_vendor: Chassis Manufacture chassis_version: Chassis Version bios_vendor: American Megatrends Inc. bios_version: 0802 board_vendor: ASUSTeK Computer INC. board_name: P5L-VM 1394 board_version: Rev 1.xx ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub [8086:2770] (rev 02) Subsystem: ASUSTeK Computer Inc. P5LD2-VM Mainboard [1043:817a] 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 00:01.0 PCI bridge [0604]: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port [8086:2771] (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: 16 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: cff0-cfff Prefetchable memory behind bridge: d000-dfff 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 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 01) Subsystem: ASUSTeK Computer Inc. Device [1043:8249] 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: 16 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at cfcf8000 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: oss_hdaudio 00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 1 [8086:27d0] (rev 01) (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: 16 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: c800-c81f Prefetchable memory behind bridge: c820-c83f 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 00:1c.1 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 2 [8086:27d2] (rev 01) (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: 16 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: cfe0-cfef 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 00:1d.0 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.
Bug#607041: Bug#590321: vzctl: ip6tables does not work in VE
On 15/01/11 16:18, Ola Lundqvist wrote: severity 607041 important merge 607041 590321 thanks Thanks for the information. Merging them. Hi Ola, I notice these bugs didn't actually get merged. From the BTS documentation it seems you must first resassign 590321 to linux-image-2.6.32-5-openvz-amd64 before you can merge or forcemerge them. Right now I'm running this test build posted by Max Attems which I'm happy to say fixes the issue for me (although I had to --force-depends to install it without an updated linux-base package): have a 2.6.32-31 build for testing here, ola or anyone? http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb.sha512sum.asc I also note that 'tc' works now inside VEs; this was a separate issue that someone had reported here: http://bugzilla.openvz.org/1238 Thanks, everyone! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d41df40.8080...@pyro.eu.org
Re: Possible bug in kernel 2.6.37
Hello Ian, Thanks for your answer. Let's talk about his back on xen-devel list so. See you there :) Regards, JB Le 27/01/2011 21:42, Ian Campbell a écrit : Hi Jean, Given that the 2.6.37 kernel is only in experimental I think Debian can only offer very limited support for it. I recommend you stick with your dialog with upstream, it is likely to be the most effective way to get to the bottom of the issue. Ian. On Wed, 2011-01-26 at 21:02 +0100, Jean Baptiste FAVRE wrote: Hello, I'm not sure this is neither the right place, nor the right way to introduce my problem, but I've only small kernel knowledge. Please excuse me if I'm wrong. I'm using 2 Debian Squeeze Xen Dom0 servers. Those 2 servers provide PCI passthrough for a network card. The idea is to filter network trafic inside dedicated domU instead of having dom0 directly connected on the network. For my tests, I choose Debian Squeeze with 2.6.37 kernel from experimental. Here are the results: - Debian Squeeze 32bits + 32bits 2.6.37 kernel: incoming packets larger than 128 bytes are blocked somewhere. - Debian Squeeze 32bits + 64bits 2.6.37 kernel: everything works fine. - Debian Squeeze 64bits + 64bits 2.6.37 kernel: everything works fine. My first thought was I discovered a bug in Xen PCI passthrough code. I exchange some mails on xen-devel mailing list about it, mostly with Konrad Rzeszutek Wilk. He asked me to do many tests which did not help to diagnose the problem. Then he suggest me to change memory allocated to domU from 256mb to 512mb. That solved my problem. Now, I don't know exactly what I shall do. Any help will be appreciated, Regards, Jean Baptiste Favre -- 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/4d41e4be.50...@jbfavre.org
Bug#605090: Updated patch
On jeu., 2011-01-27 at 00:29 +0100, maximilian attems wrote: On Tue, 18 Jan 2011, Yves-Alexis Perez wrote: Kernel team, what do you think? Could the patches be merged against trunk? Config might still need some reviewing but that can be done once people start testing the packages. What follows is my personal view, in short what I miss most is an assessement of the involved cost of this specific feature branch. I follow both 2.6.32 (“stable”) and 2.6.36 then 2.6.37 (“test”) releases since few weeks, integrating them to the linux-2.6 (sid and trunk) source packages. There's an rss feed with a changelog which I use to see what changed and apply the debian diff (which is about removing the “localpart” in 2.6.37 and removing the security bugfixes in 2.6.32). Right now I'm doing it manually (applying against a tree after debian/rules source and fixing the rej) and intend to switch to git when the migration is done. For 2.6.37 it's immediate, for 2.6.32 it's a bit longer since I need to do the removal part. Then there is the testing. Nothing really specific there. first of all merging a patch that deviates from mainline for an eternety and shows zero interest of upstream merging is not a good candidate. You get longterm plenty of cost versus allmost no benefit. There's no interest in upstreaming from grsec/pax teams but some other people are indeed interested in upstreaming those kind of features. In the meantime, having a featureset is a nice way to move along. I'm quite unsure that this patch benefits Debian. A lot of Debian users build their own kernels for integrating grsecurity patch and I really think they would be interested in having it directly in the distribution. Though it's not exactly the same situation (especially wrt. the config) I think Gentoo Hardened kernel is really appreciated. Professional as well a personal people do use it daily because it's critical in their work. If we can provide them a package I think they'll be grateful. From a distant past look it was in fact quite untastefull. The second trouble is that I question your understanding of this patch. (viewing the way you answered waldi's questions). Indeed there are parts in that patch I wouldn't be able to explain precisely, especially very low-level stuff, linker, sparc64 assembly... Third beside security theatre what is gained by it? I think the whole point of the “Grsecurity” patchset is “security”. Fourth why not invest the time for Wheezy and have finally the mainline and security backed SELinux ready. This seems like a much better time investment. Trying to push some bits upstream is indeed a good time investment (though it takes time and I really think moving forward now is a good idea). But Grsecurity isn't a drop-in replacement for SELinux. Some features like RBAC and auditing have some similarities, but all the hardening and memory protection really have nothing to do with that. Fifth the ninties are over, an upstream that still doesn't use an VSC seems very untrustworthy. I didn't say anything about upstream VCS usage. Indeed it'd be nice to have a repository available for users and I'm sure openvz and vserver patchsets maintainers would agree. Thank you for your comments anyway. Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM signature.asc Description: This is a digitally signed message part
Bug#605090: Updated patch
On Wed, 2011-01-26 at 13:29 +0100, Yves-Alexis Perez wrote: config PAX_MEMORY_UDEREF bool Prevent invalid userland pointer dereference depends on X86 !UML_X86 !XEN select PAX_PER_CPU_PGD if X86_64 help By saying Y here the kernel will be prevented from dereferencing userland pointers in contexts where the kernel expects only kernel pointers. This is both a useful runtime debugging feature and a security measure that prevents exploiting a class of kernel bugs. The tradeoff is that some virtualization solutions may experience a huge slowdown and therefore you should not enable this feature for kernels meant to run in such environments. Whether a given VM solution is affected or not is best determined by simply trying it out, the performance impact will be obvious right on boot as this mechanism engages from very early on. A good rule of thumb is that VMs running on CPUs without hardware virtualization support (i.e., the majority of IA-32 CPUs) will likely experience the slowdown. I was assuming people wanting a grsec kernel would prefer having UDEREF than XEN, but we might as well use the more conservative approach and keep XEN enabled (and UDEREF disabled) and wait for feedback from users. If bugreports are reported asking for UDEREF we can still revisite that later. Can you describe how it works and what makes it slow for Xen? It sounds like strictly speaking it's not broken under Xen as such, it's just not recommended since it is effectively unusable with certain guest types. It's not clear if the comment is referring to PV guests or HVM guests using shadow mode. i.e. It's not clear if hardware virtualization support refers to HVM generally or more specifically to HAP (hardware assisted paging). The problem with disabling CONFIG_XEN in this way is that it will also disable the Xen PVHVM drivers which enhance disk and network performance for HVM guests. Hardware with HVM is really quite common these days and HAP has been around for quite a while too so it's not as rare as the comment makes out. I think that if we are going to have this flavour then it should have both Xen and grsec. That allows it to work for people using HVM (+/- HAP as discussed above) guests. For people with PV guests they can either choose dog-slow-but-secure or fast. Maybe that's not much of a choice ;-) Ian. -- Ian Campbell Be free and open and breezy! Enjoy! Things won't get any better so get used to it. signature.asc Description: This is a digitally signed message part
Processed: reassign 611278 to xen-hypervisor-4.0-amd64
Processing commands for cont...@bugs.debian.org: reassign 611278 xen-hypervisor-4.0-amd64 4.0.1-1 Bug #611278 [linux-2.6] linux-image-2.6.32-5-xen-amd64: boot fails when iommu is enabled in bios Bug reassigned from package 'linux-2.6' to 'xen-hypervisor-4.0-amd64'. Bug No longer marked as found in versions 2.6.32-30. Bug #611278 [xen-hypervisor-4.0-amd64] linux-image-2.6.32-5-xen-amd64: boot fails when iommu is enabled in bios Bug Marked as found in versions xen/4.0.1-1. thanks Stopping processing here. Please contact me if you need assistance. -- 611278: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611278 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.129616927226210.transcr...@bugs.debian.org
Bug#607041: Bug#590321: vzctl: ip6tables does not work in VE
On Thu, Jan 27, 2011 at 09:10:24PM +, Steven Chamberlain wrote: I notice these bugs didn't actually get merged. From the BTS documentation it seems you must first resassign 590321 to linux-image-2.6.32-5-openvz-amd64 before you can merge or forcemerge them. reassigned both to linux-2.6 and forcemerged them. The source is the culprit not the binary package. Right now I'm running this test build posted by Max Attems which I'm happy to say fixes the issue for me (although I had to --force-depends to install it without an updated linux-base package): oh right this is a pain I allways forget, we need to get rid of this postsqueeze, now libata switch is done. http://charm.itp.tuwien.ac.at/~mattems/linux-base_2.6.32-31_all.deb http://charm.itp.tuwien.ac.at/~mattems/linux-base_2.6.32-31_all.deb.sha512.asc have a 2.6.32-31 build for testing here, ola or anyone? http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb.sha512sum.asc I also note that 'tc' works now inside VEs; this was a separate issue that someone had reported here: http://bugzilla.openvz.org/1238 good pointer, added to changelog. thanks for the testing!! -- maks -- 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/20110127232140.gh21...@vostochny.stro.at
Bug#611301: linux-image-2.6.37-trunk-amd64: uswsusp does not work on linux 2.6.37
On Thu, Jan 27, 2011 at 09:45:18PM +0100, Michal Suchanek wrote: On both the Debian experimental package and my package built from vanilla source uswsusp fails. It would attempt a suspend but never get to the part when pages are saved to disk. The screens go into suspend mode and the fans spin, power keeps on. On another system or with kernel 2.6.36-rc5 on this system uswsusp works flawlessly. From the top of my head I have these differences on the troublesome system: - older chipset with buggy ehci implementation that requires the ehci driver to be unloaded before suspend - openafs aie, still not dead? - oss4 (causes the missing modules) we do not support that crap, use alsa. - cifs mounts does echo mem work?? -- maks -- 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/20110127232308.gi21...@vostochny.stro.at
Processed: tagging 607041
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 607041 + pending Bug #607041 [linux-image-2.6.32-5-openvz-amd64] linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE Ignoring request to alter tags of bug #607041 to the same tags previously set End of message, stopping processing here. Please contact me if you need assistance. -- 607041: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607041 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.129617034531927.transcr...@bugs.debian.org
Processed: reassign 607041 to linux-2.6
Processing commands for cont...@bugs.debian.org: reassign 607041 linux-2.6 Bug #607041 [linux-image-2.6.32-5-openvz-amd64] linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE Bug reassigned from package 'linux-image-2.6.32-5-openvz-amd64' to 'linux-2.6'. Bug No longer marked as found in versions linux-2.6/2.6.32-29. thanks Stopping processing here. Please contact me if you need assistance. -- 607041: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607041 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.129617038232072.transcr...@bugs.debian.org
Processed: reassign 590321 to linux-2.6
Processing commands for cont...@bugs.debian.org: reassign 590321 linux-2.6 Bug #590321 [vzctl] vzctl: ip6tables does not work in VE Bug reassigned from package 'vzctl' to 'linux-2.6'. Bug No longer marked as found in versions vzctl/3.0.23-18. thanks Stopping processing here. Please contact me if you need assistance. -- 590321: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590321 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.129617038832097.transcr...@bugs.debian.org
Processed: forcibly merging 607041 590321
Processing commands for cont...@bugs.debian.org: forcemerge 607041 590321 Bug#607041: linux-image-2.6.32-5-openvz-amd64: amd64 ip6tables broken in OpenVZ VE Bug#590321: vzctl: ip6tables does not work in VE Forcibly Merged 590321 607041. thanks Stopping processing here. Please contact me if you need assistance. -- 607041: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607041 590321: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590321 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.129617041032276.transcr...@bugs.debian.org
Bug#590105: LS-CHL support
* cvel...@gmail.com cvel...@gmail.com [2011-01-15 22:37]: I'm also trying to install Squeeze on a LS-CHL (LS-C640L-EU) and can confirm, that it still does not recognise the sata drive. LS-CHL has been added to the mainline kernel in the meantime: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4bba1c34e0a70d0db2506e1b68f69d7edc8afd78 so we can add it to the Debian kernel. I'll look into this in a few weeks. -- Martin Michlmayr http://www.cyrius.com/ -- 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/20110128014832.gu1...@jirafa.cyrius.com
Bug#590321: Bug#607041: Bug#590321: vzctl: ip6tables does not work in VE
Thanks to you both (Steven and Maximilian) Thanks for the fast feedback and the testing. Especially the testing saves me the hassle to re-install my lab machine. For some reason I was hit by the ATA driver change in the recent kernels so not that machine no longer boots. Now I still need to re-install (or fix) it but I do not have to do it today. :-) Best regards, // Ola On Thu, Jan 27, 2011 at 11:21:40PM +, maximilian attems wrote: On Thu, Jan 27, 2011 at 09:10:24PM +, Steven Chamberlain wrote: I notice these bugs didn't actually get merged. From the BTS documentation it seems you must first resassign 590321 to linux-image-2.6.32-5-openvz-amd64 before you can merge or forcemerge them. reassigned both to linux-2.6 and forcemerged them. The source is the culprit not the binary package. Right now I'm running this test build posted by Max Attems which I'm happy to say fixes the issue for me (although I had to --force-depends to install it without an updated linux-base package): oh right this is a pain I allways forget, we need to get rid of this postsqueeze, now libata switch is done. http://charm.itp.tuwien.ac.at/~mattems/linux-base_2.6.32-31_all.deb http://charm.itp.tuwien.ac.at/~mattems/linux-base_2.6.32-31_all.deb.sha512.asc have a 2.6.32-31 build for testing here, ola or anyone? http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb http://charm.itp.tuwien.ac.at/~mattems/linux-image-2.6.32-5-openvz-amd64_2.6.32-31_amd64.deb.sha512sum.asc I also note that 'tc' works now inside VEs; this was a separate issue that someone had reported here: http://bugzilla.openvz.org/1238 good pointer, added to changelog. thanks for the testing!! -- maks -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- 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/20110128063948.ga20...@inguza.net
