Re: Bug#613074: xserver-xorg-input-synaptics: Touchpad left and right physical buttons send only button2 events instead of left and right clicks as expected
reassign 613074 src:linux-2.6 thanks Tayroni Francisco de Alencar tayroni.al...@gmail.com (13/02/2011): and the output of evtest /dev/input/event7 (on tty1) Input driver version is 1.0.0 Input device ID: bus 0x11 vendor 0x2 product 0x8 version 0x7321 Input device name: AlpsPS/2 ALPS GlidePoint Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 325 (ToolFinger) Event code 330 (Touch) Event type 2 (Relative) Event code 0 (X) Event code 1 (Y) Event type 3 (Absolute) Event code 0 (X) Value238 Min0 Max 1023 Event code 1 (Y) Value343 Min0 Max 767 Event code 24 (Pressure) Value 0 Min0 Max 127 Testing ... (interrupt to exit) Event: time 1297647718.798783, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1297647718.798787, type 1 (Key), code 273 (RightBtn), value 1 Event: time 1297647718.798790, -- Report Sync Event: time 1297647718.957825, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1297647718.957829, type 1 (Key), code 273 (RightBtn), value 0 Event: time 1297647718.957831, -- Report Sync Event: time 1297647720.472790, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1297647720.472793, type 1 (Key), code 273 (RightBtn), value 1 Event: time 1297647720.472796, -- Report Sync Event: time 1297647720.642271, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1297647720.642274, type 1 (Key), code 273 (RightBtn), value 0 Event: time 1297647720.642276, -- Report Sync Event: time 1297647721.340442, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1297647721.340445, type 1 (Key), code 273 (RightBtn), value 1 Event: time 1297647721.340447, -- Report Sync Event: time 1297647721.549657, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1297647721.549660, type 1 (Key), code 273 (RightBtn), value 0 Event: time 1297647721.549662, -- Report Sync Event: time 1297647722.167348, type 1 (Key), code 272 (LeftBtn), value 1 Event: time 1297647722.167351, type 1 (Key), code 273 (RightBtn), value 1 Event: time 1297647722.167354, -- Report Sync Event: time 1297647722.296923, type 1 (Key), code 272 (LeftBtn), value 0 Event: time 1297647722.296926, type 1 (Key), code 273 (RightBtn), value 0 Event: time 1297647722.296928, -- Report Sync I've pressed two times the left physical button and then, two times the right button. Thanks, Tayroni. As you can see, LeftBtn+RightBtn is sent every time, so that's not a bug on the X side, rather on the kernel side. Reassigning there. KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#613074: xserver-xorg-input-synaptics: Touchpad left and right physical buttons send only button2 events instead of left and right clicks as expected
Processing commands for cont...@bugs.debian.org: reassign 613074 src:linux-2.6 Bug #613074 [xserver-xorg-input-synaptics] xserver-xorg-input-synaptics: Touchpad left and right physical buttons send only button2 events instead of left and right clicks as expected Bug reassigned from package 'xserver-xorg-input-synaptics' to 'src:linux-2.6'. Bug No longer marked as found in versions xserver-xorg-input-synaptics/1.2.2-2. thanks Stopping processing here. Please contact me if you need assistance. -- 613074: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613074 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.129767218032684.transcr...@bugs.debian.org
Bug#605090: Updated patch
On jeu., 2011-02-10 at 10:51 +0100, Bastian Blank wrote: On Wed, Jan 26, 2011 at 09:56:35PM +0100, Yves-Alexis Perez wrote: On mer., 2011-01-26 at 14:54 +0100, Bastian Blank wrote: On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote: On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote: On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote: +++ debian/config/amd64/grsec/config(revision 0) Remove, no real settings here. What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it has been implemented without segmentation. Real settings can be modified by the user, this two can't. I still don't get it. Use menuconfig. Try to modify the values. Understood, thanks, they're implicitely set. You will need a git repository in the future. So please start with it. I was kind-of waiting for the git linux-2.6 transition. I contacted Ben Hutchings about his linux-2.6 tree on git.debian.org but he told me to rather directly request to join the alioth project and don't wait for the transition to happen. Please start with it. I don't want random code drops _right_ _now_. Well, I've started to setup a git tree, but it's a bit hard to make the kernel package git transition myself. I used the script from Ben Hutchings to setup a git repository with Debian patches applied, but the result isn't really intended to be maintained, as far as I see it. As I already pointed out on the first mail, Brad Sprengler has already said he wasn't interested in upstreaming stuff. What Brad wants or don't want is irrelevant here. While the patch policy for the main kernel is rather strict, other featuresets can incorporate more changes. However this is no free ticket to push anything into it. Okay. Then I set the rules: * The patch must be minimal. This means: - Arbitrary fixes must go to mainline. “arbitrary fixes” are picked up from mainline, which is why I remove them from the patch since they're already backported into Debian. - No style changes in random code. I guess that can be cleaned-up. Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM signature.asc Description: This is a digitally signed message part
Re: link_in_boot
Ben Hutchings b...@decadent.org.uk writes: On Sun, 2011-02-13 at 20:24 +0100, Bjørn Mork wrote: Ben Hutchings b...@decadent.org.uk writes: This has nothing to do with where the kernel images are (they are always installed in /boot), but only to do with where the symlinks are created. The default is to create them in /, but I recall there is an option (now deprecated) to create them in /boot. Not related to this bug, but I was wondering: Why deprecate this feature? All configuration through kernel-img.conf is deprecated. It is a legacy of kernel-package, and even current versions of kernel-package do not use it. Ah, right. That makes sense. I find it very useful for systems where I keep /boot in a separate partition. Having the symlinks in the same partition allow you to configure boot loaders like extlinux with the generic symlink names. They should be using hook scripts to generate a separate entry for each installed kernel version. Yes, I know. In practise, I often find myself turning that off and configuring the boot loader manually instead. The reason is the lack of flexibility in the automatic scripts, like e.g. missing serial support in extlinux. Or the ability to keep a few special kernels in /boot without adding all of them to the boot menu. Might be just me. Just wanted to register an interest in keeping the link_in_boot feature. But I can of course implement it using the hook feature instead of kernel-img.conf. I do understand the wish to get rid of that file. The links in / are generally not very useful IMHO if /boot and / are different partitions. That depends on whether the symlink is resolved at installation time or at boot time. Well, links in /boot can be used at both times, links in / cannot. Bjørn -- 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/87ipwm53g6@nemi.mork.no
Dropping 686 non-pae kernel
Hi folks I'd like to drop the i686 non-pae kernel. Currently we have sometimes -686 with PAE; only the normal kernel is without PAE. I'd like to get rid of this problem. Also this enables the use of the NX bit if supported by the CPU. There are some i686 processors without PAE support. This are some of the Pentium M (all of the Banias line and some of the Dothan line) and the Via C3 Nehemiah. All of them are released 2005 and earlier. There are several possibilities to do this: * Change name of meta-package: - Breaks nothing - Needs manual intervention by anyone using it * Don't change the name: - Breaks some systems - No manual intervention by the rest Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 signature.asc Description: Digital signature
Debug infos for remaining packages
Hi folks Currently we build debug infos only for selected images for size reasons. A recent gcc compiler supports to not emit structure debug informations. This drastically reduces the amount of data produced. However it also makes it impossible to debug into structures, so it is only usefull for gathering line numbers of problems. This setting reduces the size by 70%: 1527674 debug-full/linux-image-2.6.37-trunk-amd64-dbg 399288 debug-full/linux-image-2.6.37-trunk-amd64-dbg_2.6.37-1~experimental.2_amd64.deb 510118 debug-reduced/linux-image-2.6.37-trunk-amd64-dbg 117152 debug-reduced/linux-image-2.6.37-trunk-amd64-dbg_2.6.37-1~experimental.2_amd64.deb Maybe this could be used to enable the possibility to do limited debugging on all images without emiting too much preasure on the buildd/archive. Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 signature.asc Description: Digital signature
Re: Dropping 686 non-pae kernel
On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote: Hi folks I'd like to drop the i686 non-pae kernel. Currently we have sometimes -686 with PAE; only the normal kernel is without PAE. I'd like to get rid of this problem. Also this enables the use of the NX bit if supported by the CPU. There are some i686 processors without PAE support. This are some of the Pentium M (all of the Banias line and some of the Dothan line) and the Via C3 Nehemiah. All of them are released 2005 and earlier. Also Geode LX. Are there any changes we could/should make to the 486 flavour that would make it perform better on 686-class processors? Should we consider also dropping 486 support and making it a 586 flavour with corresponding optimisations? There are several possibilities to do this: * Change name of meta-package: - Breaks nothing - Needs manual intervention by anyone using it * Don't change the name: - Breaks some systems - No manual intervention by the rest Rename 686-bigmem to 686. Keep the 686-bigmem metapackage as a dummy package depending on the 686 metapackage (for one release). When the 686 metapackage is upgraded on a system that doesn't support PAE, display a warning with debconf. 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: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 11:34:51AM +, Ben Hutchings wrote: On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote: There are some i686 processors without PAE support. This are some of the Pentium M (all of the Banias line and some of the Dothan line) and the Via C3 Nehemiah. All of them are released 2005 and earlier. Also Geode LX. Ah, yes. Are there any changes we could/should make to the 486 flavour that would make it perform better on 686-class processors? Should we consider also dropping 486 support and making it a 586 flavour with corresponding optimisations? The 486 flavour have only 8% of the usage of the 686 and steadily dropping. Which CPU types would be affected? Rename 686-bigmem to 686. Keep the 686-bigmem metapackage as a dummy package depending on the 686 metapackage (for one release). When the 686 metapackage is upgraded on a system that doesn't support PAE, display a warning with debconf. Okay. Bastian -- ... freedom ... is a worship word... It is our worship word too. -- Cloud William and Kirk, The Omega Glory, stardate unknown -- 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/20110214121102.ga11...@wavehammer.waldi.eu.org
Bug#605090: Updated patch
On Mon, Feb 14, 2011 at 11:02:53AM +0100, Yves-Alexis Perez wrote: On jeu., 2011-02-10 at 10:51 +0100, Bastian Blank wrote: Please start with it. I don't want random code drops _right_ _now_. Well, I've started to setup a git tree, but it's a bit hard to make the kernel package git transition myself. I thought about using something derived from the stable tree. You need it to do proper patch imports anyway. - Arbitrary fixes must go to mainline. “arbitrary fixes” are picked up from mainline, which is why I remove them from the patch since they're already backported into Debian. No. I meant the arbitrary fixes like the const-ness changes. 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/20110214122522.ga12...@wavehammer.waldi.eu.org
Dropping -2.6- meta-packages
Hi folks I'd like to drop the -2.6- meta-packages. They where relevant during the Etch timeframe with support for both 2.4 and 2.6 Linux kernels. However it is unlikely to happen again in the medium future. Bastian -- It would seem that evil retreats when forcibly confronted. -- Yarnek of Excalbia, The Savage Curtain, stardate 5906.5 signature.asc Description: Digital signature
Re: Debug infos for remaining packages
Bastian Blank wa...@debian.org writes: Maybe this could be used to enable the possibility to do limited debugging on all images without emiting too much preasure on the buildd/archive. Probably not a bad idea. However, such partially debuggable kernels should be marked clearly. It is not nice to spend weeks trying to reproduce a bug and then to notice that the debug information for that version to be minimal. How about using -partial-dbg instead of -dbg for those? ;-) -- 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/84pqqu949v@sauna.l.org
Re: Dropping 686 non-pae kernel
On Monday 14 February 2011, Ben Hutchings wrote: On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote: Hi folks I'd like to drop the i686 non-pae kernel. Currently we have sometimes -686 with PAE; only the normal kernel is without PAE. I'd like to get rid of this problem. Also this enables the use of the NX bit if supported by the CPU. There are some i686 processors without PAE support. This are some of the Pentium M (all of the Banias line and some of the Dothan line) and the Via C3 Nehemiah. All of them are released 2005 and earlier. Also Geode LX. There are also the Vortex86SX based boards which are showing up in a variety of little embedded boards. I am not sure these will run with -586 (but I may be wrong). There are many embedded boards with Geode SC1100 boards out there as well, PCEngines WRAP boards, and one of the Microtik boards. The Geode LX appears in places like the PCEngines Alix boards which are very much still current. Although some of these are are no longer manufacturered they are still in the field. I have some 8 year old boards still doing sterling service, and I would not like to be blocked from using current software. In fact I have just upgrade one (an old Wrap card) to Squeeze because it was easier to do that and then install the extra package I needed that to search through the archives looking for old copied of the package that were current at the time I build the system image. David Are there any changes we could/should make to the 486 flavour that would make it perform better on 686-class processors? Should we consider also dropping 486 support and making it a 586 flavour with corresponding optimisations? There are several possibilities to do this: * Change name of meta-package: - Breaks nothing - Needs manual intervention by anyone using it * Don't change the name: - Breaks some systems - No manual intervention by the rest Rename 686-bigmem to 686. Keep the 686-bigmem metapackage as a dummy package depending on the 686 metapackage (for one release). When the 686 metapackage is upgraded on a system that doesn't support PAE, display a warning with debconf. Ben. -- 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/201102141305.33593.david.goodeno...@btconnect.com
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 01:05:33PM +, David Goodenough wrote: There are also the Vortex86SX based boards which are showing up in a variety of little embedded boards. I am not sure these will run with -586 (but I may be wrong). The website does not tell anything about supported instruction set. Rumors tells me, that is is in fact a plain 486 instruction set. There are many embedded boards with Geode SC1100 boards out there as well, PCEngines WRAP boards, and one of the Microtik boards. The Geode LX appears in places like the PCEngines Alix boards which are very much still current. The Geode LX only fails the PAE constraint. In theorie it should run fine with a 586-kernel. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, The Omega Glory, stardate unknown -- 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/2011021418.ga13...@wavehammer.waldi.eu.org
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 01:11:02PM +0100, Bastian Blank wrote: On Mon, Feb 14, 2011 at 11:34:51AM +, Ben Hutchings wrote: [...] Are there any changes we could/should make to the 486 flavour that would make it perform better on 686-class processors? Should we consider also dropping 486 support and making it a 586 flavour with corresponding optimisations? The 486 flavour have only 8% of the usage of the 686 and steadily dropping. Which CPU types would be affected? [...] According to the Kconfig help, anything called 486 plus UMC U5D and U5S. According to Wikipedia, the Cyrix 5x86, 6x86 and MediaGX and the NatSemi/AMD Geode GX1 and SC1100 processors also use a 486-class core. Kconfig has an option for GX1 which is the same as 486 modulo some bug workarounds. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20110214143506.gc28...@decadent.org.uk
Re: Dropping 686 non-pae kernel
On Mon, Feb 14, 2011 at 02:33:38PM +0100, Bastian Blank wrote: On Mon, Feb 14, 2011 at 01:05:33PM +, David Goodenough wrote: There are also the Vortex86SX based boards which are showing up in a variety of little embedded boards. I am not sure these will run with -586 (but I may be wrong). The website does not tell anything about supported instruction set. Rumors tells me, that is is in fact a plain 486 instruction set. [...] The Wikipedia article describes it as 586-class except for the lack of FPU. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20110214143719.gd28...@decadent.org.uk
Bug#611301: linux-image-2.6.37-trunk-amd64: uswsusp does not work on linux 2.6.37
On 28 January 2011 23:08, maximilian attems m...@debian.org wrote: On Fri, Jan 28, 2011 at 05:31:33PM +0100, Michal Suchanek wrote: On 28 January 2011 00:23, maximilian attems m...@debian.org wrote: does echo mem work?? echo disk works (at least powers off) but does not resume. well with that many external modules, you are a bit on your own. tried to unload them before? It's none of the externals modules, its r300(rv530) kms. When the radeon module is removed (completely from the filesystem as I did not find any easy way to disable loading it) )suspend and resume with uswsusp works (at least with 2.6.38 to which I upgraded trying to fix this). I experienced no such issue with r600(rv710 and Redwood). Thanks Michal -- 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=uy866tr-kuwefvayp0nlhuyzf6fc8kj+ty...@mail.gmail.com
[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 #595124 (http://bugs.debian.org/595124) # * http://bugzilla.kernel.org/show_bug.cgi?id=16140 # * remote status changed: (?) - NEW usertags 595124 + status-NEW thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110214163751.1085.22197.btsl...@busoni.debian.org
Bug#613271: workaround
Hello, I also have this one reported here Bug#599582 so you can merge those too. a turn around is to recompile the alsa driver via module-assistant regards, Jean-Louis Biasini -- 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/4d597d61.8050...@gmail.com
Bug#600769: linux-image-2.6.32-5-amd64: brcm80211 suspend to ram issues
On Wed, Oct 20, 2010 at 01:01:48AM +0200, Simon Paillard wrote: Package: linux-2.6 Version: 2.6.32-25 Severity: normal On suspend to ram (Toshiba R700-11E), with firmware-brcm80211 from sid/non-free, the brcm80211 module must *always* to be unloaded and reloaded again to get a fonctionnal wifi chip. (BTW, why not requesting an unblock for firmware-nonfree ?) A patch is announced at https://patchwork.kernel.org/patch/474491/ Will try to adapt it to squeeze kernel. -- Simon Paillard -- 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/20110214202342.gj31...@glenfiddich.ikibiki.org
Bug#612463: linux-image-2.6.32-5-vserver-powerpc: Vserver functionality not working at all
Hi, I can confirm this bug and could also test patches or images. cheers, Holger signature.asc Description: This is a digitally signed message part.
Processed: tagging 607879
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 607879 + pending Bug #607879 [linux-2.6] aufs: kernel BUG at .../mm/mmap.c:873 Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 607879: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607879 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.12977245879592.transcr...@bugs.debian.org
Bug#607879: System hangs up with mmap.c:873!
On Tue, 2011-02-08 at 08:38 +0100, Ronny Standtke wrote: Fortunately, after some trial and error, I successfully built a linux-headers-2.6.32-5-common_2.6.32-30a~test package with the following two commands: export UPSTREAMVERSION=2.6.32-5 fakeroot make -f debian/rules.real binary-arch-featureset Is this the right way? To partially answer my own question: No, the resulting package is not useable. I had to use the following list of commands to build a package that worked for me: export VERSION=2.6.32 export UPSTREAMVERSION=2.6.32-5 export KERNEL_ARCH=x86 fakeroot make -f debian/rules.real binary-arch-featureset I still would like to know the official and supported way to build the linux-headers-x.y.z-a-common package. Ben? You can use: fakeroot make -f debian/rules.gen binary-arch_i386_none but this is subject to change at any time. I would not say it is official or supported. Anyway, it shouldn't be necessary to rebuild the header packages as there is no ABI change and the previous version should be compatible. Does live-build require an exact version match? The good thing is that the patch series Ben provided seems to fix the problem. At least I did no longer run into this bug for more than a week now. OK, we'll include these changes in an update to squeeze. 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: Dropping 686 non-pae kernel
On 14/02/2011 13:11, Bastian Blank wrote: Are there any changes we could/should make to the 486 flavour that would make it perform better on 686-class processors? Should we consider also dropping 486 support and making it a 586 flavour with corresponding optimisations? The 486 flavour have only 8% of the usage of the 686 and steadily dropping. Which CPU types would be affected? Yes, but if you decide to drop the 686-non-pae flavour, you should expect 486 raising. For example my notebook use a Pentium M Dothan without pae support. :-( But please, don't raise too much the system request of the basic 486 kernel: Debian's kernel is one of the few that i can run on very old cpus. For example i've many K6-2 cpu that cannot run many live-CDs because they need cmov support. Debian-live works good. Switching from 486 to 586 i see the risk to cut out old hardware that is still able to use Debian. Ciao. Cesare. -- 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/4d59b765.3090...@gmail.com
Processed: tagging 599877
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 599877 + pending Bug #599877 [linux-2.6] Please enable FANOTIFY Bug #605636 [linux-2.6] Please enable CONFIG_FANOTIFY in 2.6.37(-rcX) Added tag(s) pending. Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 599877: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599877 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.129772589416023.transcr...@bugs.debian.org
Processed: tagging 611390
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 611390 + pending Bug #611390 [linux-2.6] linux-image-2.6.32-5-686: Asus WL-167g / rt2500usb regression: DHCP no longer possible Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 611390: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611390 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.129772686820929.transcr...@bugs.debian.org
Re: Dropping 686 non-pae kernel
On Tue, 2011-02-15 at 00:14 +0100, Cesare Leonardi wrote: On 14/02/2011 13:11, Bastian Blank wrote: Are there any changes we could/should make to the 486 flavour that would make it perform better on 686-class processors? Should we consider also dropping 486 support and making it a 586 flavour with corresponding optimisations? The 486 flavour have only 8% of the usage of the 686 and steadily dropping. Which CPU types would be affected? Yes, but if you decide to drop the 686-non-pae flavour, you should expect 486 raising. For example my notebook use a Pentium M Dothan without pae support. :-( Yes, that's what we expect. But please, don't raise too much the system request of the basic 486 kernel: Debian's kernel is one of the few that i can run on very old cpus. For example i've many K6-2 cpu that cannot run many live-CDs because they need cmov support. Debian-live works good. Switching from 486 to 586 i see the risk to cut out old hardware that is still able to use Debian. K6-2 is 586-class, so no problem for you. And of course some old PC hardware would no longer be usable - just like the Alpha and PA-RISC systems we dropped support for in squeeze. 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 612002
Processing commands for cont...@bugs.debian.org: tags 612002 + moreinfo unreproducible Bug #612002 [nfs-common] Starting NFS common utilities failed Added tag(s) unreproducible and moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 612002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612002 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.12977384982252.transcr...@bugs.debian.org
Bug#612002: Starting NFS common utilities failed
On Fri, 2011-02-04 at 09:57 -0500, Tong Sun wrote: Package: nfs-common Version: 1:1.2.2-4 Severity: important Symptom: The nfs-common failed to be installed properly: $ sudo apt-get install nfs-common Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: nfs-common 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 250 kB of archives. After this operation, 676 kB of additional disk space will be used. Get:1 http://cdn.debian.net/debian/ testing/main nfs-common amd64 1:1.2.2-4 [250 kB] Fetched 250 kB in 6s (41.4 kB/s) Selecting previously deselected package nfs-common. (Reading database ... 59010 files and directories currently installed.) Unpacking nfs-common (from .../nfs-common_1%3a1.2.2-4_amd64.deb) ... Processing triggers for man-db ... Setting up nfs-common (1:1.2.2-4) ... Creating config file /etc/idmapd.conf with new version Creating config file /etc/default/nfs-common with new version Starting NFS common utilities: statd failed! invoke-rc.d: initscript nfs-common, action start failed. dpkg: error processing nfs-common (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: nfs-common Launching it manually get the same error as well: % invoke-rc.d nfs-common start Starting NFS common utilities: statd failed! invoke-rc.d: initscript nfs-common, action start failed. The whole execution log of sudo bash -x /etc/init.d/nfs-common start is posted at http://pastebin.com/SQefWNQs On the surface, the reason of failure is the failure of statd+ start-stop-daemon --start --oknodo --quiet --exec /sbin/rpc.statd -- + RET=1 The symptom is confirmed as well by Dr. Ed Morbius, Chief Scientist, Krell Power Systems Unlimited. See http://thread.gmane.org/gmane.linux.debian.user/399917 The real reason is that the post install process of nfs-common didn't deal with portmap: What do you mean, 'didn't deal with portmap'? nfs-common depends on portmap | rpcbind, so one of them must be installed before it and will also be started automatically. Did you disable portmap? $ grep portmap /etc/runlevel.conf || echo not found not found [...] What is runlevel.conf? 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 601997, forcibly merging 582877 601997
Processing commands for cont...@bugs.debian.org: tags 601997 - moreinfo Bug #601997 [linux-2.6] [i915] Irregular sync flashes on gm45 Removed tag(s) moreinfo. forcemerge 582877 601997 Bug#582877: xserver-xorg-video-intel: Video flickering after kernel update Bug#601997: [i915] Irregular sync flashes on gm45 Bug#580601: [drm/i915] flickering and artifacts on (some?) gm45 with powersave Forcibly Merged 580601 582877 601997. thanks Stopping processing here. Please contact me if you need assistance. -- 582877: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582877 601997: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601997 580601: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580601 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.12977388213813.transcr...@bugs.debian.org
Bug#611832: linux-image-2.6.32-5-amd64: general protection fault at reboot under qemu: native_stop_other_cpus+0x86/0x90
On Thu, 2011-02-03 at 00:50 +0200, Timo Juhani Lindfors wrote: Ben Hutchings b...@decadent.org.uk writes: Which version of qemu are you using in the host? If you are using kvm-qemu, which kernel version are you using in the host? The host is a xen domU: So this is ordinary qemu, not using hardware virtualisation? lindi1:~$ qemu-system-x86_64 --version QEMU PC emulator version 0.12.5 (Debian 0.12.5+dfsg-3), Copyright (c) 2003-2008 Fabrice Bellard lindi1:~$ dpkg-query -W qemu qemu0.12.5+dfsg-3 lindi1:~$ dmesg|head -n3 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] 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 0x00600889 f+41: 57 push %rdi 0x0060088a f+42: 9d popfq 0x0060088b f+43: 66 66 90 xchg %ax,%ax 0x0060088e f+46: 66 90 xchg %ax,%ax This looks like deliberate patching by the PV-alternatives mechanism. Is this PV-alternatives a linux or qemu feature or are they both cooperating? I tried to look around but couldn't find the code yet. It's a kernel feature to be more efficient when running in a recognised virtual machine implementation (PV = paravirtualisation). 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#611806: marked as done (linux-headers-2.6.37-trunk-common: scripts/basic/Makefile missing)
Your message dated Tue, 15 Feb 2011 03:30:39 + with message-id 1297740639.3104.139.camel@localhost and subject line Re: Bug#611806: linux-headers-2.6.37-trunk-common: scripts/basic/Makefile missing has caused the Debian Bug report #611806, regarding linux-headers-2.6.37-trunk-common: scripts/basic/Makefile missing to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 611806: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611806 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-headers-2.6.37-trunk-common Version: 2.6.37-1~experimental.1 Severity: normal Hello, linux-headers-2.6.37-trunk-common misses scripts/basic/Makefile. This file is needed by scripts/Makefile.build. For instance, it breaks make kernelrelease which makes external module build harder. $ make kernelrelease -C /lib/modules/2.6.37-trunk-amd64/build make: Entering directory `/usr/src/linux-headers-2.6.37-trunk-amd64' /usr/src/linux-headers-2.6.37-trunk-common/scripts/Makefile.build:44: /usr/src/linux-headers-2.6.37-trunk-common/scripts/basic/Makefile: No such file or directory make[4]: *** No rule to make target `/usr/src/linux-headers-2.6.37-trunk-common/scripts/basic/Makefile'. Stop. make[3]: *** [scripts_basic] Error 2 2.6.37 make: Leaving directory `/usr/src/linux-headers-2.6.37-trunk-amd64' The relevant Makefile.build code didn't change recently (it has been including scripts/basic/Makefile since 2007) but the problem didn't occur in the past (at least it works fine with 2.6.32-5 and 2.6.34-1). Now that 2.6.37 seems to use this code easierly, scripts/basic/Makefile should be shipped in headers packages. Thanks, Brice -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- no debconf information ---End Message--- ---BeginMessage--- On Wed, 2011-02-02 at 14:06 +0100, Brice Goglin wrote: Package: linux-headers-2.6.37-trunk-common Version: 2.6.37-1~experimental.1 Severity: normal Hello, linux-headers-2.6.37-trunk-common misses scripts/basic/Makefile. This file is needed by scripts/Makefile.build. For instance, it breaks make kernelrelease which makes external module build harder. $ make kernelrelease -C /lib/modules/2.6.37-trunk-amd64/build make: Entering directory `/usr/src/linux-headers-2.6.37-trunk-amd64' /usr/src/linux-headers-2.6.37-trunk-common/scripts/Makefile.build:44: /usr/src/linux-headers-2.6.37-trunk-common/scripts/basic/Makefile: No such file or directory make[4]: *** No rule to make target `/usr/src/linux-headers-2.6.37-trunk-common/scripts/basic/Makefile'. Stop. make[3]: *** [scripts_basic] Error 2 2.6.37 make: Leaving directory `/usr/src/linux-headers-2.6.37-trunk-amd64' [...] You need to pass M=your-module-directory (in fact M=dummy will work). You can get away without it for some targets, but in general you should assume this is required. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part ---End Message---
Processed: tagging 597658
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 597658 + pending Bug #597658 [linux-2.6] linux-headers-2.6.32-5-amd64: Missing aesni-intel module in kernel Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 597658: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597658 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.129774097711160.transcr...@bugs.debian.org
Processed: tagging 577555, fixed 577555 in 2.6.37-1~experimental.1
Processing commands for cont...@bugs.debian.org: tags 577555 - moreinfo Bug #577555 [linux-2.6] linux-image-2.6.32-4-amd64: [athk9] Bad performance issue and losing easly connection with an AR9285 Removed tag(s) moreinfo. fixed 577555 2.6.37-1~experimental.1 Bug #577555 [linux-2.6] linux-image-2.6.32-4-amd64: [athk9] Bad performance issue and losing easly connection with an AR9285 There is no source info for the package 'linux-2.6' at version '2.6.37-1~experimental.1' with architecture '' Unable to make a source version for version '2.6.37-1~experimental.1' Bug Marked as fixed in versions 2.6.37-1~experimental.1. thanks Stopping processing here. Please contact me if you need assistance. -- 577555: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577555 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.129774102011306.transcr...@bugs.debian.org
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
On Tue, 2011-01-25 at 09:24 +0100, Bjørn Mork wrote: Marc-Christian Petersen m@gmx.de writes: so, what's up with this fix? Any chance to get it into Debians kernel tree? It's kind of uncomfortable to rebuild the whole kernel, with this applied, when Debian releases a new kernel which happens frequently ;- I fully understand. I must admit that I thought it would be a no-brainer to verify this and get it into the upstream and the 2.6.32.x stable tree. [...] Your patch removes the initialisation of kern_sge32[i] when ioc-sgl[i].iov_len is zero. I think it should at least set the length to zero. Perhaps it's safest to pass max(ioc-sgl[i].iov_len, 1) as the length parameter to dma_alloc_coherent(). 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 609615
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 609615 + pending Bug #609615 [linux-2.6] linux-2.6: please do not build in nvidiafb on powerpc systems Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 609615: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609615 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.129774321618274.transcr...@bugs.debian.org
Bug#604627: linux-image-2.6.32-5-amd64: megasas: Failed to alloc kernel SGL buffer for IOCTL
Ben Hutchings b...@decadent.org.uk writes: On Tue, 2011-01-25 at 09:24 +0100, Bjørn Mork wrote: Marc-Christian Petersen m@gmx.de writes: so, what's up with this fix? Any chance to get it into Debians kernel tree? It's kind of uncomfortable to rebuild the whole kernel, with this applied, when Debian releases a new kernel which happens frequently ;- I fully understand. I must admit that I thought it would be a no-brainer to verify this and get it into the upstream and the 2.6.32.x stable tree. [...] Your patch removes the initialisation of kern_sge32[i] when ioc-sgl[i].iov_len is zero. I think it should at least set the length to zero. Yes, you are of course right. I just considered it's usage in that function, where it won't be used as long as kbuff_arr[i] is 0, but kern_sge32[i] should be set to be absolutely safe with the firmware. Perhaps it's safest to pass max(ioc-sgl[i].iov_len, 1) as the length parameter to dma_alloc_coherent(). I agree that it would fix things, and that may be appropriate for a Debian specific workaround where the workaround context always is clear, but I don't think it's good as a permanent fix. Reading the patched code would be very confusing. Not allocating 0 is self-explanatory. Bjørn -- 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/878vxh3g7z@nemi.mork.no
Bug#613247: linux-image-2.6.32-5-amd64: FSC Amilo Pi 1505 reboots/hangs after pressing silent mode special key
I've contacted with another FSC Pi1505 owner that doesn't suffer this bug. It seems that a BIOS upgrade will solve the problem. I will upgrade my BIOS and post the result here.
