Re: Selection of kernel for Lenny
On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. we have allways stated that .26 will be the release kernel. i don't understand why this would come as a surprise. .26 is to be released in a week, which is early enough to prepare all stuff including testing migration. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny (was: 2.6.25-2 testing sync)
On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: On Monday 07 July 2008, maximilian attems wrote: There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. Eh, how does that follow my last para which I assume you are commenting on, but which has nothing to do with testing? A side-note to your comment though... IMO testing kernel support is the weakest point in the current upload strategy by the kernel team. By uploading the next upstream release to unstable basically as soon as it's available upstream, Debian users (both unstable and testing) are frequently missing out on at least one or two upstream stable updates for the previous stable (stable -1) release. agreed on the week point, but not to your conclusions. it often happens that d-i is blocking on older release. like the beta that happened to want to stick to 2.6.22 which was a pure catastrophe, half a year too old, without support for e1000e and newer intel boards.. We worked around this for .24 by doing an upstream stable update through t-p-u. dannf did and he is from the kernel team. it was not a workaround, but again a stick to previous instead of working forward. Upstream does seem to recognize the fact that a new release will need at least a few updates before it is actually stable and usable, and will therefore do at least a few stable updates (for both new stable and stable -1 in parallel). This basically happens in parallel to the new merge window (say the time to -rc2) and some upstream releases get longer term upstream stable support (.18, .22, .25). .22 didn't stay long with us. this was said back then for .16 and didn't matter on the long run. My personal opinion is that it would be better to delay the upload of new upstream releases to unstable until the .2 or maybe even .3 upstream stable update has become available. This would mean a bit more work for the kernel team, but I would expect that to be solvable. don't see any point on that. it wouldn't accelerate the meta package sort. That would also give more time for initial arch-specific and l-m-e issues for the new upstream to be worked out (e.g. in experimental) without breaking unstable too much. IMO a new kernel version should only be uploaded to unstable if kernel meta packages can be updated at roughly the same time. this is a currently a week point, but unstable is the place to sort such. It would also allow to upload a few more stable updates for stable -1 and to migrate those to testing, giving testing users on average better support and it would give D-I some more breathing space to do releases. When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. sarcastic mode on never seen that, d-i has always been dragging. sarcastic mode off would wish that kmuto be an official d-i member. he even tracks rc snapshot releases when necessary. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. I don't understand why this would come as a surprise. I'll start with reminding you that the toolchain is frozen and that the kernel is part of it. Now could you explain how changing kernel for a new upstream, with the well known fact that one needs to wait for the .2/.3 to have a decent working kernel (IOW in at least 2/3 weeks after the release) is not a disruptive change[1]? Add testing migration to that, plus tied transitions, then I expect a really good rationale from you to explain why a 6-8 weeks delay in the toolchain freeze (IOW in the release process) is acceptable and needed[2]. The fact that you're unable to understand that is quite worrying. [0] http://lists.debian.org/debian-release/2007/04/msg00189.html [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? [2] and I'm pretty sure the d-i crew has alike reservations. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8H2BrkvQe0.pgp Description: PGP signature
Bug#488794: linux-image-2.6.25-2-686: cannot suspend to disk while a mounted cifs share is inaccessible
On Jul 3, 2008, at 5:49 PM, maximilian attems wrote: On Thu, Jul 03, 2008 at 05:43:37PM +0200, Michal Suchanek wrote: This also does not go away with the new kernel. The server exists in a local network, has a private IP address, and is referred to by a short DNS name (which the local name server resolves to the private IP address and a non-existent fully qualified DNS name). When a share is mounted from the server, and the computer is moved to a public network it won't suspend. When the computer is disconnected from any networks it suspends normally. To reproduce easily just mount a local share (I used an IP alias on eth0 to do so, does not work with 127.0.0.1), and set iptables -P OUTPUT DROP i see, could you please report that upstream on bugzilla.kernel.org to get the attention of the swsusp and cifs devs. thanks for letting us know the upstream bug number. -- maks http://bugzilla.kernel.org/show_bug.cgi?id=11050 MS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488799: linux-image-2.6.25-2-686: power button produces multiple events
On Jul 2, 2008, at 12:09 PM, maximilian attems wrote: if you consider it a bug please report upstream on bugzilla.kernel.org and let us know the bug number. http://bugzilla.kernel.org/show_bug.cgi?id=11022 MS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. right so the 2.6.26 summary: * closes 50 bugs on upload (mostly 2.6.25 regressions) * has upstream coordination with xen and openvz * is the first version with kernel debugger * much better laptop support (wireless, uvc,..) * kvm ported to IA64, PPC and S390 we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. right to debian-release that was the last time we got asked to give a statement. in discussion on d-kernel and with d-boot we allways stated to work on 2.6.26 for Lenny. I don't understand why this would come as a surprise. I'll start with reminding you that the toolchain is frozen and that the kernel is part of it. Now could you explain how changing kernel for a new upstream, with the well known fact that one needs to wait for the .2/.3 to have a decent working kernel (IOW in at least 2/3 weeks after the release) is not a disruptive change[1]? Add testing migration to that, plus tied transitions, then I expect a really good rationale from you to explain why a 6-8 weeks delay in the toolchain freeze (IOW in the release process) is acceptable and needed[2]. a freeze exception for releasing debian with an uptodate and tuned system is worth. [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? there are statements from waldi and vorlon to consider the 2.6.25 linux-libc-dev status as frozen. kind regards -- maks ps fjp is wrong we don't switch to pata and are not forced to do so for 2.6.26, no idea, where he got that idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
maximilian attems [EMAIL PROTECTED] writes: On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote: On Monday 07 July 2008, maximilian attems wrote: There are valid arguments to be found for staying with 2.6.25 a bit longer, but D-I has not yet converted to it is NOT one of them. testing users are currently on an unsupported kernel. Eh, how does that follow my last para which I assume you are commenting on, but which has nothing to do with testing? A side-note to your comment though... IMO testing kernel support is the weakest point in the current upload strategy by the kernel team. By uploading the next upstream release to unstable basically as soon as it's available upstream, Debian users (both unstable and testing) are frequently missing out on at least one or two upstream stable updates for the previous stable (stable -1) release. agreed on the week point, but not to your conclusions. it often happens that d-i is blocking on older release. like the beta that happened to want to stick to 2.6.22 which was a pure catastrophe, half a year too old, without support for e1000e and newer intel boards.. This was mostly caused due the risk of the kernel to not be ready on time. We do need to have a better process to avoid those two problems to happen from now on. ... My personal opinion is that it would be better to delay the upload of new upstream releases to unstable until the .2 or maybe even .3 upstream stable update has become available. This would mean a bit more work for the kernel team, but I would expect that to be solvable. don't see any point on that. it wouldn't accelerate the meta package sort. But it would accelerate the d-i migration since we could mostly of time do the switch at same time of kernel going sid. That would also give more time for initial arch-specific and l-m-e issues for the new upstream to be worked out (e.g. in experimental) without breaking unstable too much. IMO a new kernel version should only be uploaded to unstable if kernel meta packages can be updated at roughly the same time. this is a currently a week point, but unstable is the place to sort such. No. experimental is the place for that. It would also allow to upload a few more stable updates for stable -1 and to migrate those to testing, giving testing users on average better support and it would give D-I some more breathing space to do releases. When a new stable *is* uploaded, D-I should be able to switch faster too (at least, if there's someone willing to do the initial kernel-wedge work) as the main criterium for D-I to switch to a new kernel version is: does the new version look about to be ready to migrate to testing, which current early uploads of the kernel to unstable effectively never are. sarcastic mode on never seen that, d-i has always been dragging. sarcastic mode off would wish that kmuto be an official d-i member. he even tracks rc snapshot releases when necessary. It is different case when we are working with a full set of architectures and planning to not hurt users. You need to agree that if one derivative breaks, it hurts much less people then if oficial d-i breaks. A much more important argument is that .25 has seen and will almost certainly continue to get a lot more stabilization effort upstream than is normal for upstream kernel releases because long term releases for at least two important other distros are based on it. I doubt .26 will get the same upstream attention. Given the lack of capacity in Debian to do any real stabilization (cherry picking/backporting of fixes from later releases) ourselves, that could IMO be an important consideration for staying with .25 for Lenny. that doesn't matter a lot, if you look into our 2.6.18 or the RH patch biest you'll notice the RH men force boot behind their backporting machine. I'm having serious trouble parsing what you're trying to say here. Could you rephrase? you never checked the rh kernel. they do a *lot* of backporting and have a big team working on that. so you'll notice that none of those patches landed in ours. so your argument sounds nice, but doesn't help in practise. .26 got a *lot* upstream attention and solves a number of .25 regressions. it is wanted for read-only bind mounts, kernel debugger, kvm + xen + wireless improvements, allmost net namespaces and uvc cam support. And how about the other and correlated changes that would be need like toolchain and base? We're on _freeze_, bear that on mind. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Processed: bug 488794 is forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=11050
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.30 forwarded 488794 http://bugzilla.kernel.org/show_bug.cgi?id=11050 Bug#488794: linux-image-2.6.25-2-686: cannot suspend to disk while a mounted cifs share is inaccessible Noted your statement that Bug has been forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=11050. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 12:43:49PM +, maximilian attems wrote: On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. right so the 2.6.26 summary: * closes 50 bugs on upload (mostly 2.6.25 regressions) I'm really afraid with the number of bugs it'll open though. * has upstream coordination with xen and openvz Does this mean that dom0 will work with .26 ? If yes, then maybe .26 is really worth considering. If not, this is quite moot. * is the first version with kernel debugger * much better laptop support (wireless, uvc,..) * kvm ported to IA64, PPC and S390 we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. right to debian-release that was the last time we got asked to give a statement. in discussion on d-kernel and with d-boot we allways stated to work on 2.6.26 for Lenny. Well, we did asked for updates from core teams in our mails to d-d-a numerous times without our prior nagging, which was clearly meant to avoid this kind of communication issues. For the rest I assume the release team will have to discuss things a bit further. [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? there are statements from waldi and vorlon to consider the 2.6.25 linux-libc-dev status as frozen. Well, that's a sine qua non condition. L-L-Dev breakages are horrible, and we just cannot aford one. It does not mean that I consider .26 to be a clever idea right now, but a l-l-d breakage would be a plain no-go. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpab0ChSrdEt.pgp Description: PGP signature
Bug#482074: linux-image-2.6.25-2-686: version 2.6.25-4 locks too
linux-image-2.6.26-rc9-686 (2.6.26~rc9-1~experimental.1~snapshot.1) works fine. thanks, Marcello 2008/7/4 maximilian attems [EMAIL PROTECTED]: On Thu, 29 May 2008, Marcello Nuccio wrote: Package: linux-image-2.6.25-2-686 Version: 2.6.25-4 Followup-For: Bug #482074 same problem after the upgrade from 2.6.25-3. 2.6.24-* works fine. Marcello Nuccio could you please try 2.6.26-rc8 linux images, see apt trunk lines - http://wiki.debian.org/DebianKernel thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 03:27:17PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 12:43:49PM +, maximilian attems wrote: On Tue, Jul 08, 2008 at 12:56:50PM +0200, Pierre Habouzit wrote: On Tue, Jul 08, 2008 at 06:59:40AM +, maximilian attems wrote: On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. please read the changelog trunk on all the 2.6.26 fixes. Huh, that's not really our work, you as the maintainer should help us understand why we would like to deal with 3 months of FTBFS *right now*. Not to mention the libata changes fjp talks about, that would probably break many upgrades and for which there is no known solution. right so the 2.6.26 summary: * closes 50 bugs on upload (mostly 2.6.25 regressions) I'm really afraid with the number of bugs it'll open though. upstream has much better control of it thanks to kernelopps, random .config boot tests and regression handling. * has upstream coordination with xen and openvz Does this mean that dom0 will work with .26 ? If yes, then maybe .26 is really worth considering. If not, this is quite moot. we get snapshot working, that is *important* for guest. otherwise you would not be able to migrate your debian guest. and please don't dismiss openvz, which is the new emerging namespace solution that has more features then vserver and works actively on upstream merge. we have worked together with openvz devs to have .26 openvz images. * is the first version with kernel debugger * much better laptop support (wireless, uvc,..) * kvm ported to IA64, PPC and S390 of course a lot of fixes and forgot to mention the * Read-only bind mounts which can come in really handy for chroots and buildd. we have allways stated that .26 will be the release kernel. The sole mail from the kernel team that I can find is[0]. We've seen no updates from you since AFAICT. Given the content of the mail, and its age, I don't see how we can know that. right to debian-release that was the last time we got asked to give a statement. in discussion on d-kernel and with d-boot we allways stated to work on 2.6.26 for Lenny. Well, we did asked for updates from core teams in our mails to d-d-a numerous times without our prior nagging, which was clearly meant to avoid this kind of communication issues. For the rest I assume the release team will have to discuss things a bit further. okay sorry for having not catched that. [1] e.g. have you done full scale archive rebuilds to show that a new linux-libc-dev won't at least cause dozens of FTBFS like the 2.6.25 did ? there are statements from waldi and vorlon to consider the 2.6.25 linux-libc-dev status as frozen. Well, that's a sine qua non condition. L-L-Dev breakages are horrible, and we just cannot aford one. It does not mean that I consider .26 to be a clever idea right now, but a l-l-d breakage would be a plain no-go. sure fully agreeed. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 maximilian attems wrote: * Read-only bind mounts which can come in really handy for chroots and buildd. JFYI: recently 'bindfs' package was uploaded to Debian archive, it can do it easily without new kernel. My 2 cents, only. Regards, Eugene V. Lyubimkin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhzfLUACgkQchorMMFUmYwwOACgwTTcdSiNuJiko0tT+mG8seHc APgAnRSe2822LNilSH8Yfohmq4APr2O6 =GI4a -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
On Tue, Jul 08, 2008 at 05:41:57PM +0300, Eugene V. Lyubimkin wrote: maximilian attems wrote: * Read-only bind mounts which can come in really handy for chroots and buildd. JFYI: recently 'bindfs' package was uploaded to Debian archive, it can do it easily without new kernel. not at vfs level. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407217: r8169: Thecus N2100, multicast packets problem
Hello, I'm experiencing a problem with RTL-8169 network card on Thecus N2100 NAS device on 2.6.24 and 2.6.25 kernels (did not try other versions). System seems to be unable either to receive or to transmit multicast packets until promiscous mode is set on interface: mDNS does not work on this device, both for resolving other .local names or answering mDNS requests. Running tcpdump corrects the situation. Unicast packets work fine. I'm not on the list, so please keep me in CC. Additional info: [EMAIL PROTECTED]:~]1% cat /proc/cpuinfo Processor : XScale-80219 rev 0 (v5l) BogoMIPS: 593.10 Features: swp half fastmult edsp CPU implementer : 0x69 CPU architecture: 5TE CPU variant : 0x0 CPU part: 0x2e3 CPU revision: 0 Cache type : undefined 5 Cache clean : undefined 5 Cache lockdown : undefined 5 Cache format: Harvard I size : 32768 I assoc : 32 I line length : 32 I sets : 32 D size : 32768 D assoc : 32 D line length : 32 D sets : 32 Hardware: Thecus N2100 Revision: Serial : [EMAIL PROTECTED]:~]% lspci 00:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) 00:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) 00:03.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) 00:04.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 62) 00:04.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 62) 00:04.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65) [EMAIL PROTECTED]:~]% lspci -n 00:01.0 0200: 10ec:8169 (rev 10) 00:02.0 0200: 10ec:8169 (rev 10) 00:03.0 0180: 1095:3512 (rev 01) 00:04.0 0c03: 1106:3038 (rev 62) 00:04.1 0c03: 1106:3038 (rev 62) 00:04.2 0c03: 1106:3104 (rev 65) [EMAIL PROTECTED]:~]% uname -a Linux homenas 2.6.25-2-iop32x #2 Sat Jun 28 16:10:57 UTC 2008 armv5tel GNU/Linux -- pgpcoIKogwUiW.pgp Description: PGP signature
Processed: bug 488799 is forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=11022
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.30 forwarded 488799 http://bugzilla.kernel.org/show_bug.cgi?id=11022 Bug#488799: linux-image-2.6.25-2-686: power button produces multiple events Noted your statement that Bug has been forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=11022. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: bug 488794 is forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=11050
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.30 forwarded 488794 http://bugzilla.kernel.org/show_bug.cgi?id=11050 Bug#488794: linux-image-2.6.25-2-686: cannot suspend to disk while a mounted cifs share is inaccessible Forwarded-to-address changed from http://bugzilla.kernel.org/show_bug.cgi?id=11050 to http://bugzilla.kernel.org/show_bug.cgi?id=11050. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488284: linux-image-2.6.25-2-xen-686: kernel BUG at arch/x86/kernel/paravirt.c:241
maximilian attems [EMAIL PROTECTED] writes: On Fri, Jul 04, 2008 at 03:07:03PM +0200, Ferenc Wagner wrote: Ian Campbell [EMAIL PROTECTED] writes: On Fri, 2008-07-04 at 13:43 +0200, Ferenc Wagner wrote: Yes. Unfortunately I still can't save this domain. Xen 3.0 doesn't even try (xend.log): The patches to support save/restore on pvops kernel's are queued for 2.6.27. Ah, thanks. And what about migration? Is there a status page on the web perhaps? Or something similar, so that I know what's supposed to work and what isn't? http://wiki.xensource.com/xenwiki/XenParavirtOps Thanks! Looks like Lenny won't have real Xen support after all. :( -- Sadly, Feri. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485034: linux-image-2.6.25-2-686: ath5k associates but no network with WEP and AR5211
Same for me on 2.6.24-1-686 and AR5212. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489963: linux-image-2.6-amd64: Please enable USB_PERSIST on amd64
Package: linux-image-2.6-amd64 Version: 2.6.25+14 Severity: wishlist Bug 468213 requested that USB_PERSIST be enabled in the standard Debian kernels to support suspend and resume on machines that keep important filesystems on memory card/flash device. This bug was closed after USB_PERSIST was enabled for 686 (if I understand the changelog correctly - forgive me if I have misinterpreted it). It would be helpful to also have this feature for amd64 (and perhaps other architectures, but amd64 is what I use). As far as I can tell, it is not enabled as of 2.6.25-2-amd64. Thanks -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6-amd64 depends on: ii linux-image-2.6.25-2-amd642.6.25-6 Linux 2.6.25 image on AMD64 linux-image-2.6-amd64 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 489963
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 489963 + pending Bug#489963: linux-image-2.6-amd64: Please enable USB_PERSIST on amd64 There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489963: linux-image-2.6-amd64: Please enable USB_PERSIST on amd64
On Tue, Jul 08, 2008 at 07:00:35PM -0400, S Hwang wrote: Package: linux-image-2.6-amd64 Version: 2.6.25+14 Severity: wishlist Bug 468213 requested that USB_PERSIST be enabled in the standard Debian kernels to support suspend and resume on machines that keep important filesystems on memory card/flash device. This bug was closed after USB_PERSIST was enabled for 686 (if I understand the changelog correctly - forgive me if I have misinterpreted it). It would be helpful to also have this feature for amd64 (and perhaps other architectures, but amd64 is what I use). As far as I can tell, it is not enabled as of 2.6.25-2-amd64. Thanks it is default enabled by upstream in 2.6.26 which is the designated lenny kernel. thanks for report -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Reasons for removal of several files from linux-libc-dev?
Hi all, I noticed that several files have been removed from linux-libc-dev, recently. While, for example, /usr/include/linux/user.h can be replaced by the various linux header packages, other include files have become rare. /usr/include/asm/user.h is only available from libuclibc-dev now. Unless I mis-understand the purpose of libuclibc-dev, embedded systems, this might pose a problem. Point in case, the above makes cryopid FTBFS in current sid. I am wondering why those files, and others, have been removed and wanted to ask if there are plans to provide a single (meta)package with a stable name that could be used as build dep. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reasons for removal of several files from linux-libc-dev?
On Wed, Jul 9, 2008 at 03:17, Richard Hartmann [EMAIL PROTECTED] wrote: /usr/include/asm/user.h is only available from libuclibc-dev now. I just realized the various kernel header packages carry asm-x86/user.h -- Still, I would be interested in the reasons for the removal from linux-libc-dev. Thanks, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489990: linux-image-2.6.25-2-amd64: b43 Error loading microcode following Hibernate
Package: linux-image-2.6.25-2-amd64 Version: 2.6.25-6 Severity: normal Although my architecture is different(AMD/MCP51), I am experiencing exactly the problem described in #482153. My broadcom device is 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 01) After hibernate, I receive the following message. Unloading b43 results in a hard lock-up. Reboot seems to be the only way to re-enable the wireless card. b43-phy0 ERROR: Microcode not responding As shown below, my firmware is the latest (4.150.10.5) [ 11.484587] b43-phy0: Broadcom 4311 WLAN found [ 38.422374] input: b43-phy0 as /class/input/input10 [ 38.829277] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10) [ 40.021541] Registered led device: b43-phy0::tx [ 40.021596] Registered led device: b43-phy0::rx [ 40.021639] Registered led device: b43-phy0::radio Prior to 2.6.25 an RTC bug prevented any kind of hibernate stability on my hardware (dv9000z), so there are not many options for other AMD/HP Pavillion 9000z users. Suspend S3 works great every time. cheers, iMac -- Package-specific info: ** Version: Linux version 2.6.25-2-amd64 (Debian 2.6.25-6) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Fri Jun 27 00:16:12 UTC 2008 ** Command line: root=/dev/md0 resume=/dev/sdb6 ro ** Tainted: P (1) ** Kernel log: [ 10.451590] i2c-adapter i2c-0: nForce2 SMBus adapter at 0x3040 [ 10.451667] i2c-adapter i2c-1: nForce2 SMBus adapter at 0x3000 [ 10.483734] Bluetooth: HCI USB driver ver 2.9 [ 10.485921] usbcore: registered new interface driver hci_usb [ 10.747716] ricoh-mmc: Ricoh MMC Controller disabling driver [ 10.747784] ricoh-mmc: Copyright(c) Philip Langdale [ 10.747874] ricoh-mmc: Ricoh MMC controller found at :07:05.2 [1180:0843] (rev 1) [ 10.747958] ricoh-mmc: Controller is now disabled. [ 10.923815] input: PC Speaker as /class/input/input8 [ 10.973790] sdhci: Secure Digital Host Controller Interface driver [ 10.973850] sdhci: Copyright(c) Pierre Ossman [ 10.973936] sdhci: SDHCI controller found at :07:05.1 [1180:0822] (rev 19) [ 10.974378] ACPI: PCI Interrupt Link [LNK2] enabled at IRQ 7 [ 10.974443] ACPI: PCI Interrupt :07:05.1[B] - Link [LNK2] - GSI 7 (level, high) - IRQ 7 [ 10.974598] sdhc0:slot0: Will use DMA mode even though HW doesn't fully claim to support it. [ 10.974712] mmc0: SDHCI at 0xc8000800 irq 7 DMA [ 11.083530] Linux video capture interface: v2.00 [ 11.253502] usbcam: registering driver r5u870 0.11.1SVN [ 11.253586] r5u870-0: Detected HP Pavilion Webcam (UVC) [ 11.413523] r5u870-0: registered as video0 [ 11.413605] usbcore: registered new interface driver r5u870 [ 11.484587] b43-phy0: Broadcom 4311 WLAN found [ 11.576900] phy0: Selected rate control algorithm 'pid' [ 11.768396] Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ] [ 11.836149] Synaptics Touchpad, model: 1, fw: 6.2, id: 0x1a0b1, caps: 0xa04713/0x20 [ 11.867418] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 21 [ 11.867486] ACPI: PCI Interrupt :00:10.1[B] - Link [LAZA] - GSI 21 (level, high) - IRQ 21 [ 11.867710] PCI: Setting latency timer of device :00:10.1 to 64 [ 11.899970] input: SynPS/2 Synaptics TouchPad as /class/input/input9 [ 14.043078] Adding 2104472k swap on /dev/sdb6. Priority:-1 extents:1 across:2104472k [ 14.787894] EXT3 FS on md0, internal journal [ 15.143349] loop: module loaded [ 15.759664] nvidia: module license 'NVIDIA' taints kernel. [ 15.794952] ACPI: PCI Interrupt Link [LK1E] enabled at IRQ 16 [ 15.795021] ACPI: PCI Interrupt :05:00.0[A] - Link [LK1E] - GSI 16 (level, high) - IRQ 16 [ 15.795166] PCI: Setting latency timer of device :05:00.0 to 64 [ 15.795345] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 173.14.09 Wed Jun 4 23:40:50 PDT 2008 [ 15.869372] ieee80211_crypt: registered algorithm 'NULL' [ 15.881207] ieee80211: 802.11 data/management/control stack, git-1.1.13 [ 15.881277] ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] [ 16.103712] powernow-k8: Found 1 AMD Turion(tm) 64 X2 Mobile Technology TL-60 processors (2 cpu cores) (version 2.20.00) [ 16.235812] powernow-k8:0 : fid 0xc (2000 MHz), vid 0x13 [ 16.235854] powernow-k8:1 : fid 0xa (1800 MHz), vid 0x15 [ 16.235915] powernow-k8:2 : fid 0x8 (1600 MHz), vid 0x17 [ 16.235977] powernow-k8:3 : fid 0x0 (800 MHz), vid 0x1e [ 17.686031] fuse init (API version 7.9) [ 20.914948] RPC: Registered udp transport module. [ 20.915015] RPC: Registered tcp transport module. [ 28.597261] warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use) [ 28.764344] NET: Registered protocol family 10 [ 28.765357] lo: Disabled Privacy Extensions [ 31.516810] Clocksource tsc unstable (delta = -71904674 ns) [ 31.549372] pnp: the driver 'parport_pc' has been registered [ 31.549684] lp:
Bug#489995: linux-image-2.6.24-1-amd64: Kernel NULL pointer dereference in NFS server
Package: linux-image-2.6.24-1-amd64 Version: 2.6.24-7 Severity: normal I'm not sure what triggers it (it seems completely random), but every once in a while, my NFS server will log an Oops message in the kernel NFS server. It does seem to be recoverable, but I doubt it's a good thing. The dmesg from the event is as follows: Unable to handle kernel NULL pointer dereference at 0018 RIP: [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 PGD 328c8067 PUD 1eb84067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: tcp_diag inet_diag des_generic cbc blkcipher nfs nfsd lockd nfs_acl exportfs ppdev parport_pc lp parport wlan_scan_ap sit tunnel4 sch_sfq cls_u32 cls_fw sch_htb ipt_REJECT iptable_filter xt_tcpudp ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 ipt_owner xt_DSCP xt_dscp xt_MARK iptable_mangle ip_tables x_tables xfs reiserfs nf_nat_sip nf_conntrack_sip nf_nat_h323 nf_conntrack_h323 nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack ipv6 rpcsec_gss_krb5 auth_rpcgss sunrpc loop snd_hda_intel psmouse ath_rate_sample pcspkr ath_pci wlan ath_hal(P) snd_pcm snd_timer snd soundcore serio_raw k8temp snd_page_alloc i2c_nforce2 i2c_core pl2303 usblp usbserial evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic sd_mod amd74xx sata_nv ide_core r8169 forcedeth firewire_ohci firewire_core crc_itu_t sata_sil ata_generic ohci_hcd libata scsi_mod ehci_hcd Pid: 16606, comm: nfs4_cb_probe Tainted: P2.6.24-1-amd64 #1 RIP: 0010:[882b8f7e] [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 RSP: 0018:8100018ade90 EFLAGS: 00010246 RAX: fffb RBX: RCX: 810001436fa0 RDX: 0002 RSI: fffb RDI: RBP: 810007482e00 R08: 882e2750 R09: 81000176e000 R10: 81000176e000 R11: 80273a34 R12: 0018 R13: R14: 80578f20 R15: FS: 2b898a7b1270() GS:81003f5e0a40() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0018 CR3: 3a173000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 4ff0 DR7: 0400 Process nfs4_cb_probe (pid: 16606, threadinfo 8100018ac000, task 81003d904800) Stack: 80578f20 0282 0282 81003e04c080 882be0ff fffb 810007482ec0 810007482e00 8100399dbbd0 884f34b2 Call Trace: [882be0ff] :sunrpc:rpc_put_task+0x6d/0x81 [884f34b2] :nfsd:do_probe_callback+0x48/0x6a [884f346a] :nfsd:do_probe_callback+0x0/0x6a [80247f03] kthread+0x47/0x74 [8020cc48] child_rip+0xa/0x12 [80247ebc] kthread+0x0/0x74 [8020cc3e] child_rip+0x0/0x12 Code: 4c 39 63 18 0f 85 73 ff ff ff 48 89 df e8 ec fd ff ff 48 83 RIP [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 RSP 8100018ade90 CR2: 0018 ---[ end trace f553cdd2937e7544 ]--- -- Package-specific info: ** Version: Linux version 2.6.24-1-amd64 (Debian 2.6.24-7) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080114 (prerelease) (Debian 4.1.2-19)) #1 SMP Sat May 10 09:28:10 UTC 2008 ** Command line: rw root=/dev/disk/by-label/root console=ttyS0,115200 ** Tainted: P (129) ** Kernel log: doldacond[4805]: segfault at 12615e0 rip 417790 rsp 7fff6c9733b0 error 6 nfs4_cb: server 192.168.2.253 not responding, timed out UDP: bad checksum. From 93.80.151.26:53 to 82.182.133.20:1937 ulen 464 nfs4_cb: server 192.168.2.253 not responding, timed out nfs4_cb: server 192.168.2.253 not responding, timed out Unable to handle kernel NULL pointer dereference at 0018 RIP: [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 PGD 328c8067 PUD 1eb84067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: tcp_diag inet_diag des_generic cbc blkcipher nfs nfsd lockd nfs_acl exportfs ppdev parport_pc lp parport wlan_scan_ap sit tunnel4 sch_sfq cls_u32 cls_fw sch_htb ipt_REJECT iptable_filter xt_tcpudp ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 ipt_owner xt_DSCP xt_dscp xt_MARK iptable_mangle ip_tables x_tables xfs reiserfs nf_nat_sip nf_conntrack_sip nf_nat_h323 nf_conntrack_h323 nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack ipv6 rpcsec_gss_krb5 auth_rpcgss sunrpc loop snd_hda_intel psmouse ath_rate_sample pcspkr ath_pci wlan ath_hal(P) snd_pcm snd_timer snd soundcore serio_raw k8temp snd_page_alloc i2c_nforce2 i2c_core pl2303 usblp usbserial evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic sd_mod amd74xx sata_nv ide_core r8169 forcedeth firewire_ohci firewire_core crc_itu_t sata_sil ata_generic ohci_hcd libata scsi_mod ehci_hcd Pid: 16606, comm: nfs4_cb_probe Tainted: P2.6.24-1-amd64 #1 RIP: 0010:[882b8f7e] [882b8f7e]
