>> That could definitely cause mouse lock-ups. Sorry, that should have
>> occurred to me yesterday when you mentioned the problem your kids
>> were seeing, but it didn't for some reason.
>
> Btw, could it have caused the USB stack to be *really* confused? Some
> of those mouse lockups ended up a
Linus Torvalds wrote:
> On Tue, 21 Aug 2007, Linus Torvalds wrote:
>>
>> Side note: after reverting 196705c9bb I can't get the mouse to skip
>> any more on that mac mini. But since the bad behaviour wasn't 100%
>> reliable to begin with, that's not really a guarantee of anything.
>> Two out of thr
Hayes, Stuart wrote:
> David Brownell wrote:
>>> Hm... I've got a 0.95. I'll try to get a Via EHCI 1.00 controller
>>> and make sure it's the same problem.
>>
>> Yeah, for some reason way too many of the add-on PCI cards with VIA
>> chips use that pretty-broken VT6202 chip. Ones with VT6212 are
David Brownell wrote:
>> Hm... I've got a 0.95. I'll try to get a Via EHCI 1.00 controller
>> and make sure it's the same problem.
>
> Yeah, for some reason way too many of the add-on PCI cards with VIA
> chips use that pretty-broken VT6202 chip. Ones with VT6212 are also
> available, and work a
Daniel Exner wrote:
> David Brownell wrote:
>> On Monday 13 August 2007, Daniel Exner wrote:
> [..]
>>> Where exactly should I search for this? Neither lspci nor lsusb
>>> showed any hint on the EHCI rev. the chip conforms to..
>>
>> The driver logs that information as it starts; on this sytem:
>>
Daniel Exner wrote:
> Jiri Kosina wrote:
>> On Fri, 10 Aug 2007, Daniel Exner wrote:
>>> Please CC me, as I'm currently not subscribed to this list, thx.
>>
>> Please also don't forget to CC relevant people/lists when reporting
>> bugs, thanks.
> Guess its ok, now? Thanks anyway :)
>
>>> After so
Jiri Kosina wrote:
> On Fri, 10 Aug 2007, Daniel Exner wrote:
>
>> After some serious hangs with 2.6.23-rc2 I did some bisects and this
>> was the result:
>> 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit
>> 196705c9bbc03540429b0f7cf9ee35c2f928a534
>> Author: [EMAIL PROTECTED]
Greg KH wrote:
> On Tue, Jul 31, 2007 at 03:06:07PM -0600, Grant Likely wrote:
>> I've observed instability on my Macbook c2d with the Linus' latest
>> tree. Symptom is that USB devices start behaving badly and the
>> kernel seems to be registering incorrect HID events; (ie. moving the
>> mouse ca
I think reading the IDE status register clears the interrupt in the IDE
device, which might be causing the drive to think it's OK to generate
another interrupt. This could either cause it to get stuck trying to
service an interrupt that is never getting cleared as you suggested, or
possibly when
I wasn't actually able to reproduce the bug myself, but I guess it is
pretty obvious that I shouldn't have called cpufreq_unregister_notifier
with a spinlock held. I haven't been doing this long enough to know
exactly which kernel this patch should be against, so let me know if
this ins't good.
Sorry about that. Would it be helpful if I verified that and sent it in
signed off?
Thanks
Stuart
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Friday, May 25, 2007 5:00 PM
To: Greg KH
Cc: Mattia Dongili; Linux Kernel Mailing List; Hayes, Stuart; David
Brownell
Hayes, Stuart wrote:
> Ingo Molnar wrote:
>> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>>> Ingo Molnar wrote:
there's one problem with the patch: it breaks things that need the
low 1MB executable (e.g. APM bios32 calls). It would at a minimum
be needed to exclude the BIOS ar
Ingo Molnar wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar wrote:
>>> there's one problem with the patch: it breaks things that need the
>>> low 1MB executable (e.g. APM bios32 calls). It would at a minimum be
>>> needed to exclude the BIOS area in 0xd-0xf.
>>>
>
Ingo Molnar wrote:
> there's one problem with the patch: it breaks things that need the
> low 1MB executable (e.g. APM bios32 calls). It would at a minimum be
> needed to exclude the BIOS area in 0xd-0xf.
>
> Ingo
I wrote it to make everything below 1MB executable, if it isn't RAM
>>
>> Andi--
>>
>> I made another pass at this. This does roughly the same thing, but
>> it doesn't create the new "change_page_attr_perm()" functions. With
>> this patch, the change to init.c (cleanup_nx_in_kerneltext()) is
>> optional.
>> I changed __change_page_attr() so that, if the page t
randy_dunlap wrote:
> On Tue, 5 Jul 2005 15:02:26 -0500 [EMAIL PROTECTED] wrote:
>
>> Hayes, Stuart wrote:
So, if I understand correctly what's going on in x86_64, your fix
wouldn't be applicable to i386. In x86_64, every large page has a
correct "ref_prot" that is the normal setti
Hayes, Stuart wrote:
>> So, if I understand correctly what's going on in x86_64, your fix
>> wouldn't be applicable to i386. In x86_64, every large page has a
>> correct "ref_prot" that is the normal setting for that page... but in
>> i386, the kernel text area does not--it should ideally be split
17 matches
Mail list logo
