* Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> > Ingo Molnar wrote:
> > >
> > >for example git-bisect was godsent. I remember that
> > >years ago bisection of a bug was a very laborous task
> >
* James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote:
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> > Date: Wed, 14 Nov 2007 15:08:47 +0100
> >
> > > In fact this thread is the very example: David points ou
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 15:08:47 +0100
>
> > In fact this thread is the very example: David points out that on netdev
> > some of those bugs were already discussed and resolved.
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Nov 2007 21:16:39 +0100 Ingo Molnar wrote:
>
> > countered by the underlined sentences above, just in case you missed
> > it.
>
> I didn't miss your claim.
ok, then you conceded it by not replying to it? good ;-)
Ingo
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > so please stop this "too busy and too noisy" nonsense already. It
> > was nonsense 10 years ago and it's nonsense today. In 10 years the
> > kernel grew from a 1 million lines codebase to an 8 million lines
> > codebase, so what? Deal with it and b
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote:
>
> >
> > * Randy Dunlap <[EMAIL PROTECTED]> wrote:
> >
> > > > (and this is in no way directed at the networking folks - it holds
> &
* Mark Lord <[EMAIL PROTECTED]> wrote:
>> You're assuming that everything in linux-2.6 was downloaded; that's
>> not true. Everything in linux-2.6/.git was downloaded; but then you
>> do a checkout which happens to approximately double the size of the
>> linux-2.6 directory.
> ..
>
> Ah, I wo
* Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > (and this is in no way directed at the networking folks - it holds
> > for all of us. I have one main complaint about networking: the
> > separate netdev list is a bad idea - networking regressions should
> > be discussed and fixed on lkml, like mo
* Benoit Boissinot <[EMAIL PROTECTED]> wrote:
> For debugging, maybe it's time someone does an amazon ec2+s3 service
> to automate the bisecting and create .deb/.rpm from git, I don't know
> how much it would cost though.
a few months ago i estimated the costs of this and it's just a few
tera
* Mark Lord <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> ..
>> This is all QA-101 that _cannot be argued against on a rational basis_,
>> it's just that these sorts of things have been largely ignored for years,
>> in favor of the all-too-easy "ope
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > Do you believe that our response to bug reports is adequate?
> >
> > Do you feel that making us feel and look like shit helps?
>
> That doesn't answer my question.
>
> See, first we need to work out whether we have a problem. If we do
> this,
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Some day we may have modesetting support in the kernel for some
> > graphics hw, right now it's pretty damn spotty.
>
> Yep, that's the way to go.
hey, i wildly supported this approach ever since 1996, when GGI came up
:-/
Ingo
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Even if one doesn't use the fb console at all, radeonfb apparently
> > is still required on some ThinkPad models to work around BIOS bugs:
> >
> > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
>
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > disabling the following radeonfb options in the .config made resume
> > work again:
>
> In general, don't even *try* to use radeonfb for suspend/resume.
>
> I don't think it has ever worked, except on some very rare laptops
> (largely PPC Macs)
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Here's another suspend/resume artifact: one of my boxes wouldnt
> > resume, it hangs at:
> >
> > [1.456633] pci :00:18.2: resuming
> > [1.456641] pci :00:18.3: resuming
> >
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Here's another suspend/resume artifact: one of my boxes wouldnt
> resume, it hangs at:
>
> [1.456633] pci :00:18.2: resuming
> [1.456641] pci :00:18.3: resuming
> [1.456648] 8139too :05:07.0: resum
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Thomas found a new twist to this today: applying the patch below
> (which turns on ATA_DEBUG) made the SATA problem go away on his
> laptop. Michael, could you try this patch, does it change the behavior
> of your laptop in any wa
* Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > Michael - does your 'date' output advance after resume? If not then
> > i'd say it's a NO_HZ related problem. If yes then i'd guess it's the
> > SATA problem.
>
> I'll test, but I have NO_HZ off for now.
there can still be effects of it (the
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > 2. First disk access after resume takes a couple of minutes
> >(seemed instant with 2.6.20) during this time no new messages
> >show on console
>
> Yeah, there is some problem with SATA resume. It would be beautiful if
> the people who ac
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Michael - does your 'date' output advance after resume? If not then
> i'd say it's a NO_HZ related problem. [...]
in that case please do this on such a 'frozen date' system:
echo q > /proc/sysrq
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of
> > windows
> >after waiting for some 10 min, I rebooted. no new messages showed
> >up in /var/log/messages
>
> I think this is likely just more of the disk being bugg
21 matches
Mail list logo
