Bug#892517: linux: swiotlb coherent allocation failed
control: found -1 4.16.5-1 control: reopen -1 This is back for me as well. Best wishes, Mike
Bug#892517: linux: swiotlb coherent allocation failed
On Tue, Mar 20, 2018 at 6:15 AM, Salvatore Bonaccorso wrote: > Can you confirm that before we would proceed to mark it as fixed with > 4.15.11-1? I have not seen it since updating, so I think it can be considered fixed. Best wishes, Mike
Bug#892517: linux: swiotlb coherent allocation failed
package: src:linux version: 4.15.4-1 severity: minor forwarded: https://lkml.org/lkml/2017/12/18/1259 This is a message that shows up a lot in dmesg starting with linux 4.15. See LKML discussion and Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749202 Best wishes, Mike
re: Debian 8/jessie - SECCOMP_FILTER_FLAG_TSYNC
Julien Tinnes from google says that next releases of chromium will drops support for kernels without TSYNC So, first of all, this has never been Google's track record when it comes to missing sandbox features. They happily use fall backs whenever you're missing support for any of those. See about:sandbox. So, to summarize I'm somewhat doubtful that they're changing their behavior now, but well who knows... Secondly, as one of the chromium maintainers, if somehow upstream really does choose to make TSYNC a requirement, I'll happily apply any quality patch that reverts that. Google Chrome is a different story. If Google makes TSYNC a requirement there, yes nothing can be done at all. Being binary-only that's solely up to Google. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MNYW_OLHd=qulbvggl+op66pf66tbu0teuisoaxiyv...@mail.gmail.com
Bug#772508: linux: mitigate offset2lib ASLR issue
package: src:linux severity: important version: 3.16.7-1 control: tag -1 security control: forwarded -1 https://lkml.org/lkml/2014/12/5/482 A fix is currently being developed for an an ASLR bypass issue (see link). Please consider applying and enabling it by default for jessie kernels once a final version emerges. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mn-stemvxsjfbakutp3b5qaqhqxapwk9j_ozhxxczb...@mail.gmail.com
Bug#704987: system freezes after hibernate/suspend
control: severity -1 important Reducing severity since this doesn't meet the kernel team's requirements for a grave or higher. Best wishes, Mike -- 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/CANTw=MMWPzfWzOOTzrG8E_R5heHepvuoD=o702jmndsbjvc...@mail.gmail.com
Bug#703468: linux-image-3.2.0-4-amd64 fails to boot on apple iMac
The following string is still recognizable: i915_gem_init_ppgtt+0x93/0x16c [i915] This is going to take some work on your end to get fixed. 3.2.39-1 included backported patches from aspects of the i915 driver. To help, you could do some testing by unapplying those patches and rebuilding the kernel package to figure out which one is causing your crash. You can find what has changed between 3.2.35 and 3.2.39 by using debdiff from the devscripts package, and the patches that you'll want to unapply will be in debian/patches. Best wishes, Mike -- 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/CANTw=MN_wx-oFNde4wZ66ry=nu_6hijxwj0rr5mqsdrehgh...@mail.gmail.com
Bug#700884: linux: please use a three-number version for experimental kernel packages
package: linux severity: important control: affects -1 src:debootstrap uname presents a two-number version in the experimental kernel packages, e.g. $ dpkg -l | grep linux-image ii linux-image-3.7-trunk-amd643.7.3-1~experimental.1 $ uname -r 3.7-trunk-amd64 This makes it impossible to bootstrap releases older than squeeze (when running an experimental kernel). See bug #642031. As mentioned in that bug report, debootsrap could include a fake-uname LD_PRELOAD, but that is quite ugly, and Joey Hess is understandably reluctant to do that. Please consider using a three-number version for the experimental packages. Thanks, MIke -- 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/CANTw=MO5GWS+LAszhXKcNPQak+w2NNNfWN8=ejp_0_jfjnu...@mail.gmail.com
Bug#700884: linux: please use a three-number version for experimental kernel packages
That's using a kernel three releases newer than the userland. We generally like backward compatibility, but I don't it's tenable to go that far. I find this loss of compatibility unfortunate. I think there is value in continuing to support chroots of old releases. Does the uname26 program from http://mirror.linux.org.au/linux/kernel/people/ak/uname26/ help? Thanks for the pointer. uname26 works like a charm. Mike -- 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/CANTw=MNCNGU8v=qofckhbbwx6pe_nuqlpldtdjyqsoe9mlj...@mail.gmail.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Sun, 20 Feb 2011 08:24:32 +0100 Lucas Nussbaum wrote: On 19/02/11 at 17:40 -0500, Michael Gilbert wrote: On Sat, 19 Feb 2011 21:39:03 + Ben Hutchings wrote: Hypothesis 1: using an older kernel in testing results in fewer vulnerabilities Criteria: fewer vulnerabilities in lenny than squeeze during squeeze testing cycle Evidence: lenny's kernel was vulnerable to 67% of the vulnerabilities that squeeze Conclusion: hypothesis verified Criteria: fewer vulnerabilities in squeeze than wheezy during wheezy testing cycle Evidence: to be collected # vulnerabilities in squeeze and wheezy Conclusion: to be determined This experiment does not require that the propagation of kernel packages into testing is changed. OK, revised hypothesis 1: using 2.6.32 in wheezy for the first year of its development will result in fewer vulnerabilities Criteria: fewer vulnerabilities in wheezy/2.6.32 vs unstable kernel over 1 year period Evidence: to be collected # vulnerabilities affecting 2.6.32 and kernel in unstable at the same time Conclusion: to be determined I can't imagine anyone else being put through such a arduous process to try an experiment for a couple months. Why does it have to be so difficult? Because this experiment would involve many thousands of users, and you have to convince other developers that the benefit to these users may be worth the cost. OK, are you sufficiently convinced to give me a chance at this experiment, at least for a couple months??? I don't understand why you think that testing or CUT users want an old kernel, but want to run recent software for everything else on their system. I've already answered that in another mail. But basically the answer is a transition to unstable for users that *don't want* the older/stabler kernel. Of course that does require users to change their ways, but that's not so bad. In fact it may be good to have more users running unstable, finding bugs, and submitting reports. Also, you need to see the downsides of this proposed experiment. By not upgrading the kernel in testing, you will limit the amount of testing that the new kernel will receive. That could, in turn, cause more bugs to be found late in the wheezy release process, making it harder to reach a newer stable kernel. Or are you suggesting that we stay with 2.6.32 forever? ;) Of course not ;) I actually think there are a lot of people using unstable, and those are really the best users to find bugs in the kernel anyway (since presumably they actually know what they are doing). I suppose that would be an alternative hypothesis: keeping 2.6.32 in testing for too long will lead to a lower quality final wheezy kernel. That's more of a subjective/qualitative issue, and I don't really know how to define criteria to quantify it. But like I said, in my opinion unstable users are sufficient to work out the bugs. Best wishes, Mike -- 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/20110220162909.140506e7.michael.s.gilb...@gmail.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Sat, 19 Feb 2011 14:09:50 +0100 Raphael Hertzog wrote: On Fri, 18 Feb 2011, Michael Gilbert wrote: This will also help to provide a bit more stability for CUT [0]. Over a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream kernels will be released, and each new kernel comes along with a high probability of introducing breakage. I'm trying to provide CUT releases once a month, so every 3 months I will be looking at a likely broken CUT release (or 25% of the time). However, if there is just one kernel transition in testing development cycle, then there is only 1 likely broken period (or 4% of the time). The kernel is not the sole component that can introduce breakage. So it seems ridiculous to do such statistics based on the kernel only. Hi Raphael, I completely concur that there are indeed other important components like grub and xorg where breakage would be a showstopper. However, I don't think the consequences would be quite so substantial. There is just so much intimately dependent on the kernel that breakage there has a very wide area of effect; whereas grub or xorg breakage is somewhat contained. This is why I'm only significantly concerned about the kernel. Anyway, I agree that there will be breakage, but I don't want CUT to be mostly about constantly resolving the same repetitive kernel breakage. Also, this solution isn't just about CUT stability. As I've been describing, it is about killing about 2 birds with one stone: 1. Make testing always installable by retaining a stable/well-tested kernel and associated d-i infrastructure 2. Improve testing security by reducing the amount of vulnerabilities existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as described previously) In fact these are two of the three known problems in testing mentioned in your LWN article [0]. And the only consequence is that testing users don't get the latest kernel bling. However, that is offset by the availability of 2.6.37 and associated infrastructure in unstable. So there really are no downsides that can't be worked around with a little education/effort on the part of the user. And like Lucas said, CUT users want recent software and that includes the kernel I don't think it is appropriate to project a singular perspective onto all users. Ultimately our goal is to perform a balancing act between freshness and stability. In the past the primary focus has been on freshness in testing, but I think there is room to swing the pendulum a bit more toward stability. It's really a requirement if we're ever going to be able to achieve something a testing that's constantly usable. Also, users needing bleeding-edge freshness can always take the plunge into unstable. (which is also important for new hardware support). This seems to be a meme that continues to persist without much in the way of evidence. It certainly may have been true in the past, but I think things have changed for the better with the advent of stable upstream support (i.e. support for new hardware is backported to the stable kernels). Also, I've read about 10 reviews of squeeze, and none of them have indicated any problems with hardware support (except for missing support for non-free firmware) even though that uses a kernel initially released almost a year and a half ago. In fact, I've only ever had one piece of hardware (a wireless card) that was unsupported by Debian, and that was when sarge was still in testing, and all that was needed was to enter the device id into the discover list. It wasn't even a kernel issue. Ultimately I don't see why the newest blingy kernel is a necessity in testing. Best wishes, Mike [0] http://lwn.net/Articles/406301/ -- 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/20110219131235.1c8ee6b5.michael.s.gilb...@gmail.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote: On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote: [...] Also, this solution isn't just about CUT stability. As I've been describing, it is about killing about 2 birds with one stone: 1. Make testing always installable by retaining a stable/well-tested kernel and associated d-i infrastructure We do backport new hardware support to stable but we do not have the resources (time and equipment) to cover everything. So this would mean that neither stable nor testing would be installable on some newer hardware. Right, and in those rare cases, the user will have to sufficiently educate themselves to be able to use unstable. 2. Improve testing security by reducing the amount of vulnerabilities existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as described previously) Huh? I don't see any source for this figure. http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000193.html http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000194.html [...] (which is also important for new hardware support). This seems to be a meme that continues to persist without much in the way of evidence. It certainly may have been true in the past, but I think things have changed for the better with the advent of stable upstream support (i.e. support for new hardware is backported to the stable kernels). Also, I've read about 10 reviews of squeeze, and none of them have indicated any problems with hardware support (except for missing support for non-free firmware) even though that uses a kernel initially released almost a year and a half ago. [...] I can assure you there is already a substantial backlog of new hardware that is currently unsupported in squeeze. For example, any current ATI graphics chip. And this is at the start of squeeze's lifetime, not the end. I've been using ati cards exclusively for some time now; although I've also been willing to install the fglrx driver for full support ;) Also, the xorg vesa driver does work. Again, if the user is interested in such new developments, they will need to be willing to learn how to run an unstable system. Best wishes, Mike -- 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/20110219140422.d87cadf7.michael.s.gilb...@gmail.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote: On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote: On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote: On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote: [...] 2. Improve testing security by reducing the amount of vulnerabilities existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as described previously) Huh? I don't see any source for this figure. http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000193.html http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000194.html I read those and I can't see any source for comparison between 2.6.32 and 2.6.37. In fact you say that 'squeeze (2.6.32) was vulnerable to 98% (51 out of 52)' which implies only 2% fewer vulnerabilities. I suppose the way I said that is confusing. That research was from past results, and my latest statement is a projection based on the past. In other words, if lenny was vulnerable to 67% of the issues that squeeze was, I'm projecting that it will be similar for squeeze: it will be vulnerable to about 67% of the issues that wheezy will; although that could be +-10%, +-20%, who knows since events have yet to happen. I've been using ati cards exclusively for some time now; although I've also been willing to install the fglrx driver for full support ;) Then I really can't take your concern for security seriously. The changelog for fglrx-source has no mention of security fixes, and I don't for one moment believe there are no vulnerabilities in it. Well, that's a risk I'm willing to accept for myself. Others may have a differing perspective, and that's fine. My risk mitigation strategy should have nothing to do with the rest of the project's. Also, the xorg vesa driver does work. Seems like a waste of money to buy an ATI card and then use it as a dumb framebuffer. Not all ati cards are top of the line, and not all users need 3D anyway. Again, if the user is interested in such new developments, they will need to be willing to learn how to run an unstable system. I thought that users interested in new stuff were supposed to run CUT. Most packages will in fact be new, just the kernel and reverse dependencies will be held back. Hence CUT users will get 99% new stuff (with respect to stable), and a tiny bit held back simply for stability. Like I've said a couple times now, its a balancing act. All I'm asking for is a few month long experiment. And if the experiment shows signs of flaws/weaknesses, then the blocker can certainly be lifted. Best wishes, Mike -- 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/20110219145927.3cda91e3.michael.s.gilb...@gmail.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Sat, 19 Feb 2011 14:59:27 -0500 Michael Gilbert wrote: On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote: On Sat, 2011-02-19 at 14:04 -0500, Michael Gilbert wrote: On Sat, 19 Feb 2011 18:48:40 + Ben Hutchings wrote: On Sat, 2011-02-19 at 13:12 -0500, Michael Gilbert wrote: [...] 2. Improve testing security by reducing the amount of vulnerabilities existent in older kernels (roughly 67% fewer in 2.6.32 vs 2.6.37 as described previously) Huh? I don't see any source for this figure. http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000193.html http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000194.html I read those and I can't see any source for comparison between 2.6.32 and 2.6.37. In fact you say that 'squeeze (2.6.32) was vulnerable to 98% (51 out of 52)' which implies only 2% fewer vulnerabilities. I suppose the way I said that is confusing. That research was from past results, and my latest statement is a projection based on the past. In other words, if lenny was vulnerable to 67% of the issues that squeeze was, I'm projecting that it will be similar for squeeze: it will be vulnerable to about 67% of the issues that wheezy will; although that could be +-10%, +-20%, who knows since events have yet to happen. I still think I've written this confusingly. Let me try one more time. Over squeeze's testing period, the stable kernel (2.6.26) was vulnerable to roughly 67% of the issues that the testing kernels (2.6.28-32) were vulnerable to. Hence projecting for the future, over wheezy's testing period, the stable kernel (2.6.32) will be vulnerable to roughly 67% (+- some uncertainty value) of the issues that the testing kernels (2.6.37-4x) will be vulnerable to. Best wishes, Mike -- 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/20110219152529.9356a506.michael.s.gilb...@gmail.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Sat, 19 Feb 2011 20:30:47 + Ben Hutchings wrote: On Sat, 2011-02-19 at 14:59 -0500, Michael Gilbert wrote: On Sat, 19 Feb 2011 19:32:08 + Ben Hutchings wrote: [...] Again, if the user is interested in such new developments, they will need to be willing to learn how to run an unstable system. I thought that users interested in new stuff were supposed to run CUT. Most packages will in fact be new, just the kernel and reverse dependencies will be held back. Hence CUT users will get 99% new stuff (with respect to stable), and a tiny bit held back simply for stability. Like I've said a couple times now, its a balancing act. All I'm asking for is a few month long experiment. And if the experiment shows signs of flaws/weaknesses, then the blocker can certainly be lifted. If an experiment is to have any validity, the hypothesis and the criteria for assessing the outcome must be decided in advance. If you can do that, perhaps you will persuade some people that this is worth doing. Hypothesis 1: using an older kernel in testing results in fewer vulnerabilities Criteria: fewer vulnerabilities in lenny than squeeze during squeeze testing cycle Evidence: lenny's kernel was vulnerable to 67% of the vulnerabilities that squeeze Conclusion: hypothesis verified Criteria: fewer vulnerabilities in squeeze than wheezy during wheezy testing cycle Evidence: to be collected # vulnerabilities in squeeze and wheezy Conclusion: to be determined Hypothesis 2: using an older kernel version makes less work to provide CUT Criteria: how often CUT target release date is met Evidence: to be collected monthly release date by retaining 2.6.32 and monthly for standard unstable-testing transitions (note: requires a 2.6.32-only period for reference) Conclusion: to be determined I can't imagine anyone else being put through such a arduous process to try an experiment for a couple months. Why does it have to be so difficult? Best wishes, Mike -- 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/20110219155503.c48a981e.michael.s.gilb...@gmail.com
Re: [Secure-testing-team] [cut-team] For discussion: security support strategy for the wheezy kernel
On Sat, 19 Feb 2011 22:28:17 +0100 Bastian Blank wrote: On Sat, Feb 19, 2011 at 03:55:03PM -0500, Michael Gilbert wrote: Hypothesis 1: using an older kernel in testing results in fewer vulnerabilities Criteria: fewer vulnerabilities in lenny than squeeze during squeeze testing cycle Evidence: lenny's kernel was vulnerable to 67% of the vulnerabilities that squeeze Conclusion: hypothesis verified Actually you did not yet proof this. Please do it. I did verify it for the timeframe of the LWN study. Actually, there is no such thing as a proof ; I suppose I could do a more thorough study using the detailed kernel-sec data over the entire squeeze development cycle...but that may take a while since I don't have much free time any more. Criteria: fewer vulnerabilities in squeeze than wheezy during wheezy testing cycle Evidence: to be collected # vulnerabilities in squeeze and wheezy Conclusion: to be determined Hypothesis 2: using an older kernel version makes less work to provide CUT Criteria: how often CUT target release date is met Evidence: to be collected monthly release date by retaining 2.6.32 and monthly for standard unstable-testing transitions (note: requires a 2.6.32-only period for reference) Conclusion: to be determined Hypothesis 3: Testing users wants old software Criteria: to be determined Evidence: easy Conclusion: sorry, no chance Users have a variety of desires. It's the developers job to make the best overall decision regardless of users' immediate demands. The release team fights with this all the time during the freeze (users want new software, but the risk of breakage outweighs their immediate wants). I can't imagine anyone else being put through such a arduous process to try an experiment for a couple months. Why does it have to be so difficult? You can run you little experiment. For blocking packages please persuade the release team as responsible entity within Debian. Isn't it the kernel team that I need to convince? That's what this discussion is all about. Thanks, Mike -- 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/20110219165850.dbb02549.michael.s.gilb...@gmail.com
Re: [cut-team] For discussion: security support strategy for the wheezy kernel
On Sat, 19 Feb 2011 21:39:03 + Ben Hutchings wrote: Hypothesis 1: using an older kernel in testing results in fewer vulnerabilities Criteria: fewer vulnerabilities in lenny than squeeze during squeeze testing cycle Evidence: lenny's kernel was vulnerable to 67% of the vulnerabilities that squeeze Conclusion: hypothesis verified Criteria: fewer vulnerabilities in squeeze than wheezy during wheezy testing cycle Evidence: to be collected # vulnerabilities in squeeze and wheezy Conclusion: to be determined This experiment does not require that the propagation of kernel packages into testing is changed. OK, revised hypothesis 1: using 2.6.32 in wheezy for the first year of its development will result in fewer vulnerabilities Criteria: fewer vulnerabilities in wheezy/2.6.32 vs unstable kernel over 1 year period Evidence: to be collected # vulnerabilities affecting 2.6.32 and kernel in unstable at the same time Conclusion: to be determined I can't imagine anyone else being put through such a arduous process to try an experiment for a couple months. Why does it have to be so difficult? Because this experiment would involve many thousands of users, and you have to convince other developers that the benefit to these users may be worth the cost. OK, are you sufficiently convinced to give me a chance at this experiment, at least for a couple months??? Best wishes, Mike -- 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/20110219174028.adc96d08.michael.s.gilb...@gmail.com
Re: For discussion: security support strategy for the wheezy kernel
On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote: On Sun, 6 Feb 2011 21:58:08 -0400, Joey Hess wrote: Michael Gilbert wrote: Another issue was that a lot of vulnerabilities that were found in that time frame were actually flaws in new kernel code, so testing/unstable were vulnerable, but the stable kernel itself was unaffected, so it was a bit safer to be running the stable kernel since the code was older (i.e. there was more time to find and fix issues). For example, the vulnerability for one of the local privilege escalations that was exploited in the wild was introduced in 2.6.30, so lenny wasn't affected, but testing/unstable were. LWN's analysis of age of introduction of kernel security holes in 2010 doesn't seem to agree? http://lwn.net/Articles/410606/ | So, in a sense, the above-mentioned kernel hacker was correct - an | awful lot of the vulnerabilities fixed over the last year predate the | git era, and are thus over five years old. LWN's analysis is far from comprehensive, and the conclusions are not based in sufficiently rigorous analysis, but instead on the usual numbers game. Their reporting is however very useful as a basis for further research. The first fact that they completely miss is that not all CVEs are created equal. A memory info disclosure gets a CVE just like a privilege escalation that has known exploits, but both are on the same playing field in the numbers game. Annecdotally, CVE-2010-3301 and CVE-2010-1146 had an exploit in the wild, and 2.6.26 was never affected. The only issue that had an in-the-wild exploit affecting lenny in that list (that I'm aware of) was CVE-2010-3081 (and lenny would have sidestepped that too if it had had been even more conservative and gone with the older/stabler 2.6.25). Even playing the numbers game with a bit more thoughtful analysis with the LWN data, lenny looks a lot better. It can be seen that lenny (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of 52). In my opinion that's a rather substantial difference, and thus a problem worth pondering. So, now that I've had some time to contemplate the replies on this issue, I have a much better appreciation of the need to keep unstable closely in line with upstream development, and thus don't want to push the original solution anymore. Also 2.6.37 is in unstable now, so that idea is impossible, which is OK. However, as I justify above, there is still a problem, and I think it can still be solved relatively easily and without too much impact. This time I suggest blocking 2.6.37 so 2.6.32 remains in testing for a while. This will allow it to get updates in sync with stable kernel security updates (without any additional effort by Dann, Moritz, and other kernel team members other than the package upload to testing as well). This will also help to provide a bit more stability for CUT [0]. Over a 1.5-year period (the non-freeze timeframe) roughly 6 new upstream kernels will be released, and each new kernel comes along with a high probability of introducing breakage. I'm trying to provide CUT releases once a month, so every 3 months I will be looking at a likely broken CUT release (or 25% of the time). However, if there is just one kernel transition in testing development cycle, then there is only 1 likely broken period (or 4% of the time). Anyway, I know that the fact that this may have a future effect on my efforts isn't a great argument, but this does impact whether CUT will be successful, which impacts the whole project. I wonder if we can at least try it for a few months, and if there really are problems with keeping the old kernel in testing, then we can just end this experiment and unblock the newer upstream version. If there is some concurrence on this, I'll submit an RC blocker bug on the kernel. Note there are only 8 days to discuss before the transition is automatic (I think the current RC blocker [1] may disappear by then). Best wishes, Mike [0] http://lists.alioth.debian.org/pipermail/cut-team/2011-February/000195.html [1] http://qa.debian.org/excuses.php?package=linux-2.6 -- 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/20110218172432.239da727.michael.s.gilb...@gmail.com
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, 7 Feb 2011 19:12:48 +0100, Moritz Mühlenhoff wrote: Michael Gilbert michael.s.gilb...@gmail.com schrieb: Hi, So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). No way. The idea of unstable is to get the current upstream code in shape and that won't be achieved with staying with an old kernel. I'm not sure if there's a precise definition of unstable other than the statement at [0], but it seems to be whatever teams make of it. It's perfectly ok to upload only stable versions (if that's what the team wants to do), and its perfectly ok to upload the most unstable thing ever, but then the consequences of that have to be dealt with. I guess what I'm saying is that each team can decide specifically how they want to use unstable, so the kernel team can deviate from the status quo if they decide to; that is if I can make a sufficiently convincing argument. Also, my suggestion does involve eventually moving to a newer kernel in the wheezy development cycle; just a while from now, rather than rushing in to things. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. 2.6.32.x is in fact an upstream kernel currently being developed ;) Best wishes, Mike [0] http://www.debian.org/releases/unstable/ -- 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/20110207162831.fbd75367.michael.s.gilb...@gmail.com
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
2011/2/7 Ben Hutchings wrote: On Mon, Feb 07, 2011 at 07:12:48PM +0100, Moritz Mühlenhoff wrote: Michael Gilbert michael.s.gilb...@gmail.com schrieb: Hi, So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). No way. The idea of unstable is to get the current upstream code in shape and that won't be achieved with staying with an old kernel. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. Totally agreed. We should be tracking current upstream releases, and not just in experimental (which can now be used for upstream release candidates). What about introducing a new linux-2.6-stable kernel package as a compromise? That way users that want stability and security support in testing continue to have that as an option. Also, I will assume responsibility as the maintainer, so there will be hopefully very little impact to any other part of Debian. Also, I can look at generating d-i media for this kernel. Any thoughts on that? The only downside I can think of right away is introducing a huge code copy into the archive. Best wishes, Mike -- 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/AANLkTin7H+4DNM90YK-6hwLaaT+m=gcpukz6xs2gr...@mail.gmail.com
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, Feb 7, 2011 at 5:08 PM, Michael Gilbert wrote: What about introducing a new linux-2.6-stable kernel package as a compromise? That way users that want stability and security support in testing continue to have that as an option. Also, I will assume responsibility as the maintainer, so there will be hopefully very little impact to any other part of Debian. Also, I can look at generating d-i media for this kernel. Any thoughts on that? The only downside I can think of right away is introducing a huge code copy into the archive. Also the same effect can be achieved by apt-pinning the squeeze kernel. Best wishes, Mike -- 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/AANLkTinNLPeSzJn+VhYMFn6om0duiYrX6=m6zjn2x...@mail.gmail.com
Re: [Secure-testing-team] For discussion: security support strategy for the wheezy kernel
On Mon, Feb 7, 2011 at 5:09 PM, Julien Cristau wrote: What does that buy us? It means instead of dealing with bugs on an ongoing basis, you get them all at the same time and get to bisect along many kernel versions at once instead of just one. It means problems don't get reported (and fixed) upstream until it's too late. It means any package that could use a newer kernel interface doesn't get any testing. I'm sure there's plenty of others. Bugs can be submitted and dealt with in experimental just as well as in unstable. Whatever the technical solution to testing-security kernel might be, it needs to be based on following the upstream kernel development. 2.6.32.x is in fact an upstream kernel currently being developed ;) No it's not. Go read the definition of development. I'm sorry, but your proposal is insane. Is this kind of negativity really necessary? I'm trying to guide a discussion on a real problem, and I'm an engineer, so I never present problems without at least an idea about a solution. It may not be the best, but you start at something and work toward bettering it until you have something good. Best wishes, Mike -- 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/AANLkTimiCaXv+Yhgg=UW7=1miK-Y5=aLwp9=psvh1...@mail.gmail.com
Re: For discussion: security support strategy for the wheezy kernel
On Mon, 7 Feb 2011 22:54:53 -0500 Michael Gilbert wrote: Even playing the numbers game with a bit more thoughtful analysis with the LWN data, lenny looks a lot better. It can be seen that lenny (2.6.26) was vulnerable to 69% (36 out of 52) of the vulnerabilities listed there, and squeeze (2.6.32) was vulnerable to 98% (51 out of 52). In my opinion that's a rather substantial difference, and thus a problem worth pondering. Minor correction: lenny was vulnerable to 67% (35 out of 51) and squeeze was vulnerable to 98% (50 out of 51). I had missed the issue that was fixed in 2.6.20 and didn't affect either releases. Best wishes, Mike -- 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/20110207230314.c81daa29.michael.s.gilb...@gmail.com
For discussion: security support strategy for the wheezy kernel
Hi, Now that squeeze is released, I've started thinking about how to improve the quality of security support for testing. The biggest problem I saw during the squeeze development cycle was that kernel security update transitions were extremely slow due to unrelated RC bugs. This was bad since it left testing users vulnerable to issues for much larger periods of time than stable/unstable users. Another issue was that a lot of vulnerabilities that were found in that time frame were actually flaws in new kernel code, so testing/unstable were vulnerable, but the stable kernel itself was unaffected, so it was a bit safer to be running the stable kernel since the code was older (i.e. there was more time to find and fix issues). For example, the vulnerability for one of the local privilege escalations that was exploited in the wild was introduced in 2.6.30, so lenny wasn't affected, but testing/unstable were. I'd like to propose a solution to these two problems: only upload known rock solid longterm cadence upstream supported kernels into testing/unstable. This will hopefully reduce the amount of transition delay since the longterm kernels should have fewer RC issues (after they've had a little time to cook of course). There are, of course, some undesirable consequences to this plan. One is that a certain subset of testing users expect the latest shiny all the time; but they can easily get their fix from the experimental kernels instead, so that isn't really a problem (I think). The second issue is that testing d-i will not support the latest and greatest hardware and features. I think this can be solved by providing two sets of d-i media for testing (one that uses the longterm testing kernel and one that uses newer experimental kernel). Of course this means that some d-i development will need to move to experimental to make use of the newer kernel feature, but I don't think that would really be a problem. A benefit to this proposal is that there will be reduced work for those currently supporting kernel security updates since the same package can be uploaded to both stable-security and unstable. Also, there should be no RC issues that prevent transitions to testing since for example the 2.6.32 kernel is so well-tested already. Anyway, I think this would go a long way toward improving the quality of security support in testing and thus reducing the common advice/meme that users should avoid testing if they're concerned about security. So, my proposal in a nutshell is to only upload upstream 2.6.32 point releases to wheezy/sid for the next 12-18 months. At that time, reevaluate and determine what the next longterm cadence kernel will be, and then once that is reasonable stabilized in experimental, finally upload it to unstable for the final stages of wheezy development (perhaps a few months before the freeze). Looking forward to thoughts and discussion on the matter. Best wishes, Mike Disclaimer: note that I haven't participated in kernel packaging or applied kernel security patches directly myself (yet), but I have been triaging and tracking kernel security issues for about a year and a half now [0], so I have a pretty good understanding of the status quo. [0] http://svn.debian.org/wsvn/kernel-sec/?op=log -- 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/20110206175211.cd94ac24.michael.s.gilb...@gmail.com
Bug#597576: [Secure-testing-team] Bug#597576: linux-image-2.6.32-5-amd64: 2.6.32-23 still vulnerable to CVE-2010-3301
On Mon, 20 Sep 2010 18:51:16 -0400 Jon wrote: Package: linux-2.6 Version: 2.6.32-23 Justification: root security hole Severity: critical Tags: security The changelog says the CVE-2010-3301 was fixed in this update: * x86-64, compat (CVE-2010-3301): - Retruncate rax after ia32 syscall entry tracing - Test %rax for the syscall number, not %eax But a test of the exploit shows otherwise: n...@nobel:~(0)$ ./robert_you_suck resolved symbol commit_creds to 0x8106914d resolved symbol prepare_kernel_cred to 0x81069050 mapping at 3f8000 UID 1000, EUID:1000 GID:100, EGID:100 $ did you reboot? mike -- 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/20100920191926.2516291a.michael.s.gilb...@gmail.com
Bug#564110: r8169: Fix for CVE-2009-1389 introduces denial of service issue
can we downgrade the severity of this issue since there is a fix included (even though it isn't ideal)? it's currently RC. best wishes, mike -- 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/20100801175331.a671e3bb.michael.s.gilb...@gmail.com
Bug#579175: linux-2.6: does not remove /lib/modules/modules.softdep on removal
package: linux-2.6 severity: minor version: 2.6.32-11 apt-get purge linux-image-2.6.32-4-amd64 does not currently clean up the modules.softdep file in /lib/modules. minor issue; thanks for looking into it. mike -- 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/20100425182813.1402c039.michael.s.gilb...@gmail.com
Bug#569724: Please support /etc/kernel/header_postinst.d directory
here is some initial work on a patch for this issue. i'm not familiar enough with kernel packaging right now, and i've run into a problem. right now, the new headers postinst is placed into the debian/linux-headers-*-$arch directory at build time, which i thought would be sufficient to get it into the deb, but it isn't. anyone have any advise on how to do this correctly? mike headers-postinst.debdiff Description: Binary data
Bug#564114: [Secure-testing-team] e1000: Potential packet filtering bypass
On Fri, 08 Jan 2010 13:38:37 +, Ben Hutchings wrote: On Thu, 2010-01-07 at 22:11 -0500, Michael Gilbert wrote: On Thu, 07 Jan 2010 19:27:02 + Ben Hutchings wrote: Julien Cristau pointed out the thread http://thread.gmane.org/gmane.comp.security.oss.general/2457. It appears that Red Hat allocated CVE-2009-4536 for this and CVE-2009-4538 for a similar bug in e1000e. do you follow kernel-sec [0]? i entered these CVEs when they were first disclosed over a week ago. I wasn't aware of it! mike [0] http://svn.debian.org/wsvn/kernel-sec I will check this out and make sure to refer to it in future. But why don't you (or others in that group) file bug reports? Dann Frazier usually handles kernel-sec issues in a reasonably quick fashion, so filing bugs seems like additional unnecessary work; especially since kernel-sec, with it being limited to only security issues, is a much better arrangement than the cluttered kernel bts pages. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564114: [Secure-testing-team] e1000: Potential packet filtering bypass
On Thu, 07 Jan 2010 19:27:02 + Ben Hutchings wrote: Julien Cristau pointed out the thread http://thread.gmane.org/gmane.comp.security.oss.general/2457. It appears that Red Hat allocated CVE-2009-4536 for this and CVE-2009-4538 for a similar bug in e1000e. do you follow kernel-sec [0]? i entered these CVEs when they were first disclosed over a week ago. mike [0] http://svn.debian.org/wsvn/kernel-sec -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562975: linux-2.6: patch for CVE-2009-3939
Actually, no Debian release contains a kernel version affected by CVE-2009-3889. CVE-2009-3889 was fixed in upstream commit 66dca9b8 in linux 2.6.27, so debian's 2.6.24 and 2.6.26 are affected, but 2.6.18 and 2.6.32 are not. You can look at the dbg_lvl permissions, for example in the 2.6.32 kernel, to see that they are correctly restrictive, S_IWUSR. CVE-2009-3889 should be dealt with at the same time. That covers the dbg_lvl parameter which is also world-writable. For 2.6.32, CVE-2009-3939 will need to be patched separately since CVE-2009-3889 is already fixed there. As a minor aside, please include nn-submitter in your replies so your bug reporters get CC'd. I just happened to be looking at my submitted bugs recently when I came across your messages. Thanks, Mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562975: linux-2.6: patch for CVE-2009-3939
package: linux-2.6 version: 2.6.32-3 severity: important tags: patch , security hi, attached is a patch for the megaraid poll_mode_io permissions issue. mike diff -ur a/linux-2.6-2.6.32/drivers/scsi/megaraid/megaraid_sas.c b/linux-2.6-2.6.32/drivers/scsi/megaraid/megaraid_sas.c --- a/linux-2.6-2.6.32/drivers/scsi/megaraid/megaraid_sas.c 2009-12-02 22:51:21.0 -0500 +++ b/linux-2.6-2.6.32/drivers/scsi/megaraid/megaraid_sas.c 2009-12-29 13:02:34.0 -0500 @@ -3451,7 +3451,7 @@ return retval; } -static DRIVER_ATTR(poll_mode_io, S_IRUGO|S_IWUGO, +static DRIVER_ATTR(poll_mode_io, S_IRUGO|S_IWUSR, megasas_sysfs_show_poll_mode_io, megasas_sysfs_set_poll_mode_io);
Bug#560831: linux-2.6: make linux-headers automatically install headers for all currently installed kernel images
package: linux-2.6 version: 2.6.32-1 severity: wishlist hi, a lot of module building issues could be solved if the linux-headers packages were to automagically install all of the corresponding headers for all of the currently installed kernel images (instead of just providing a virtual package to any set of headers). see bug #560822 for an example where this would make an impact. this will also reduce the complexity (as percieved by some users) of having to figure out which headers package is needed. best wishes, mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550379: closed by Bastian Blank wa...@debian.org (Re: Bug#550379: linux-kbulid-2.6: embeds linux-2.6)
ropen 550379 thanks the preceding discussion has not resolved this issue satisfactorily. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550379: linux-kbulid-2.6: embeds linux-2.6
package: linux-kbuild-2.6 version: 2.6.30-1 severity: important tags: security hi, the linux-kbuild-2.6 source package includes portions of code from the linux-2.6 source package (i.e. everything in ./kbuild/*). this is bad in terms of security support because it causes more work for the security team and increases the risk of errors, omissions, and mistakes. less significant, but also important, is that since the kbuild package is separated from the linux package, the kbuild packages always lag by weeks or months after a new kernel release; making it impossible to build modules for that new kernel. the recommended course of action is to update the linux-2.6 source package to also build the kbuild binaries. thanks. mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550379: closed by Bastian Blank wa...@debian.org (Re: Bug#550379: linux-kbulid-2.6: embeds linux-2.6)
On Fri, 09 Oct 2009 21:09:06 +, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the linux-kbuild-2.6 package: #550379: linux-kbulid-2.6: embeds linux-2.6 It has been closed by Bastian Blank wa...@debian.org. On Fri, Oct 09, 2009 at 02:04:20PM -0400, Michael Gilbert wrote: the linux-kbuild-2.6 source package includes portions of code from the linux-2.6 source package (i.e. everything in ./kbuild/*). this is bad in terms of security support because it causes more work for the security team and increases the risk of errors, omissions, and mistakes. No, it does not. It is a different source package and both are derived from the same upstream code. two different source packages with portions being the same code are considered a case of an embedded code copy; which is generally considered bad practice from a security perspective. Also security support for the kernel is solely done by the team itself. i am acutely aware of this, and you could be making life easier for yourself (or more accurately for Dann Frazier since he is the primary kernel-sec contributor). less significant, but also important, is that since the kbuild package is separated from the linux package, the kbuild packages always lag by weeks or months after a new kernel release; making it impossible to build modules for that new kernel. the recommended course of action is to update the linux-2.6 source package to also build the kbuild binaries. thanks. This is not possible for other reasons. what are these reasons, and why do they seem so insurmountable? mike -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521482: closed by maximilian attems m...@stro.at (Re: Bug#521482: linux-2.6: adopt hardening patches (execshield and grsecurity) into default kernel packages for squeeze)
get them upstream merged see http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines but doesn't it make sense to be proactive about security? this isn't really a security fix, but it a security improvement. i can't even fathom how to get this merged upstream since redhat has been working on execshield for over 5 years or so and hasn't been able to merge it themselves... or better use selinux and improve it!! selinux has a different scope. it doesn't do things like adress space randomization and doesn't preventing stack smashing (which is what execshield is designed for). supposedly vista does this stuff really well now, and it's dissapointing that linux is behind the curve (well at least fedora has it, so part of the community has the extra protection). -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447549: linux-2.6: orinoco.c printk messages flood terminal
forwarded 447549 http://marc.info/?l=linux-wirelessm=123058933020818w=2 thank you just forwarded this today. please follow progress upstream. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447549: linux-2.6: orinoco.c printk messages flood terminal
would it be feasible to have level 6 as the default printk level in debian rather than 7? hiding info, i'm sorry but that's not what people expect from debian, info is not being hidden -- it will still be fully available via dmesg. and if someone really wants/needs this level of verbosity in their terminal, they can certainly increase the printk level back to 7. the point is to reduce the annoyance to average users. another possible solution would be for orinoco.c (which contains the code that prints these messages) to use the KERN_DEBUG printk level instead of KERN_INFO. i'm wondering why you are reporting this as bug against debian linux-images we have no orinoco specific patch. please discuss that issue upstream on [EMAIL PROTECTED] - any upstream change will directly land into debian. i reported it here because this is an alternative to the first suggestion above (changing the debian default kernel printk level). i figured it was up to the kernel maintainers to determine the correct solution. maybe the appropriate solution should be for orinoco.c to only print messages to dmesg, rather than to the shell as well as dmesg? i am not really that familiar with the kernel -- is there an alternative to printk that would do this? i will also take this upstream. thanks. mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447549: linux-2.6: orinoco.c printk messages flood terminal
Package: linux-2.6 Version: 2.6.22-2 Severity: normal i am at a location where a nearby wireless router comes in and out of range, so i get a ton of eth2: New link status: AP Out of Range (0004) and eth2: New link status: AP In Range (0005) messages on the active terminal. this makes it difficult to work (especially in vi). i found a solution using cat 6 /proc/sys/kernel/printk to suppress KERN_INFO and KERN_DEBUG level printk messages. i'm sure there are many other users out there that are annoyed by the current behavior. would it be feasible to have level 6 as the default printk level in debian rather than 7? another possible solution would be for orinoco.c (which contains the code that prints these messages) to use the KERN_DEBUG printk level instead of KERN_INFO. let me know if any of this seems reasonable. thank you for all the hard work. mike -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (400, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268583: hotplug failure with shpchp and pciehp
Hello, Looks like this is indeed fixed as you suggest. The shpchp line in /var/log/kern.log with 2.6.15 is: Jan 7 19:49:56 localhost kernel: shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 So its working correctly. Thanks for the hard work! Peace. Mike On 1/3/06, David Schmitt [EMAIL PROTECTED] wrote: On Wed, Nov 02, 2005 at 08:45:41PM -0500, Michael Gilbert wrote: Package: linux-2.6 Followup-For: Bug #268583 Could any of the affected parties verify this is still a problem with 2.6.12-4. I expect it is, but it would be good to verify. i couldn't find a linux-image-2.6.12-4 package anwhere, but i can verify that the kernel log contains this error: Could you please retest this with a current linux image? 2.6.15 will enter unstable tomorrow. Thanks for your time and work, David
Bug#268583: hotplug failure with shpchp and pciehp
Package: linux-2.6 Followup-For: Bug #268583 Could any of the affected parties verify this is still a problem with 2.6.12-4. I expect it is, but it would be good to verify. i couldn't find a linux-image-2.6.12-4 package anwhere, but i can verify that the kernel log contains this error: Nov 2 19:37:57 localhost kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5 Nov 2 19:37:57 localhost kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5 for the linux-image-2.6.12-1-386, linux-image-2.6.12-1-686 and linux-image-2.6.14-1-686 kernel packages on my Dell laptop. mike -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268583: hotplug failure with shpchp and pciehp
Package: kernel Followup-For: Bug #268583 i too encounter this system on my Dell Inspiron 8200 laptop. i reported the problem to the hotplug maintainer, which was abrubtly closed without sufficient explaination (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334172). an lspci of my system is: $ lspci :00:00.0 Host bridge: Intel Corporation 82845 845 (Brookdale) Chipset Host Bridge (rev 04) :00:01.0 PCI bridge: Intel Corporation 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) :00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #1) (rev 02):00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #3) (rev 02):00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 42) :00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 02) :00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 (rev 02) :00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02) :00:1f.6 Modem: Intel Corporation 82801CA/CAM AC'97 Modem Controller (rev 02) :01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 Go] (rev a3) :02:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) :02:01.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller :02:01.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller :02:01.2 FireWire (IEEE 1394): Texas Instruments PCI4451 IEEE-1394 Controller :02:03.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adding linux-image-version dependency on linux-headers-version?
Now, those wanting to compile third party drivers like the nvidia ones, should take the nvidia package (or whatever it is called) and build it following to instructions, or even better, the new policy should call for pre-compilation for all official flavours of those modules, like it is already done on powerpc for the MOL packages for example. In any case, if it fails because of missing headers, there is a bug in the third-party-module package. Thanks for the well-thought-out reply. I was curious as to whether this problem had been pondered yet. Perhaps I will bring it up with nvidia that their driver installer should not be depending on the linux headers in debian. The sarge situation was a complete mess, and i strongly suggest to move to a 2.6.12 backport. The situation there should be rather clear, and to build third party modules, you only need to set KSRC=/lib/modules/version/build, works fine. I disagree with the above statement. I am using currently using the 2.6.12 kernel (on etch), and there is no /lib/modules/2.6.12-1-686/build directory with a default linux-image install. However, this directory is created when I install the linux-headers-2.6.12-1-686 package, which is why we always need to tell people to install the headers. Can you clarify what you meant above? Thanks. Kind regards, Mike Gilbert
Adding linux-image-version dependency on linux-headers-version?
Hello all, I am curious as to the reasoning behind not including the kernel headers along with a kernel install? The reason that I bring this up is that many (new/Joe) users end up unable to figure out why they can't compile certain modules (such as the nvidia driver, etc.)...until someone more knowledgeable points out that kernel-headers-version needs to be installed (for example, see http://www.linuxquestions.org/questions/showthread.php?s=postid=1901559#post1901559, and other threads that i and many others have replied to with basically the same suggestion to install the headers). There is a probably a certain amount of user rejection because of this (at least one of my friends gave up on Debian in part because of this...he's moved on to mac os...which is not totally unadmirable). I understand that the kernel-headers-version package adds about 50 megs of data to a default install (which is already at about 2 gigs anyway when selecting desktop environment in tasksel), but with disk space so readily available (200 gigs for like $100), I see no reason why this should be a factor. Besides, those interested in disk space conservation can prune the package if they so desire. So what are the other reasons for the current situation? Can this be changed? And if so, how? Thank you for your consideration of the poor Joe User. Regards, Mike Gilbert
