On Thu, 2007-07-05 at 14:46 -0400, David Woodhouse wrote:
> Oh, I suck. I failed to noticed that it had oopsed earlier, in slab
> debugging. I shall look at my 'obviously correct' slab patch a little
> harder, now that I'm not distracted by the fireworks.
Hm, it's no
On Thu, 2007-07-05 at 09:28 -0700, Linus Torvalds wrote:
>
> On Wed, 4 Jul 2007, David Woodhouse wrote:
> >
> > Oh, and here's another one for you. My Bluetooth mouse just stopped
> > working and hidd is deadlocked...
>
> Looks like it is stuck on hidp_se
On Thu, 2007-07-05 at 09:28 -0700, Linus Torvalds wrote:
>
> On Wed, 4 Jul 2007, David Woodhouse wrote:
> >
> > Oh, and here's another one for you. My Bluetooth mouse just stopped
> > working and hidd is deadlocked...
>
> Looks like it is stuck on hidp_ses
On Tue, 2007-07-03 at 18:45 +0200, Michal Piotrowski wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.22-rc7.
Oh, and here's another one for you. My Bluetooth mouse just stopped
working and hidd is deadlocked...
hidd D 1FE27798 5940 1695 1 (NOTLB)
Call Trace:
ed on sparc32 by
Mark Fortescue, who reported the new problem.
Also, fix the conditions for FORCED_DEBUG, which hadn't been adjusted to
the new sizes. Again noticed by Mark.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/mm/slab.c b/mm/slab.c
index a9c4472..b344e67 100644
On Tue, 2007-07-03 at 18:45 +0200, Michal Piotrowski wrote:
> Subject: random invalid instruction occourances on sparc32 (sun4c)
> References : http://lkml.org/lkml/2007/6/17/111
> Submitter : Mark Fortescue <[EMAIL PROTECTED]>
> Status : problem is being debugged
Hm, when testing the fi
On Wed, 2007-07-04 at 11:27 +0100, Mark Fortescue wrote:
> Another related point that may also need to be considered is that I think
> I am correct in saying that on ARM and on the 64bit platforms, sizeof
> (unsigned long long) is 16 (128bits).
No, it's always 64 bits.
> Should the RedZone word
On Wed, 2007-07-04 at 04:27 +0100, Mark Fortescue wrote:
> I tried the previous patch and it looks like it fixes the issue however
> one of the test builds I did caused depmod to use up all available memory
> (40M - kernel memory) before taking out the kernel with the oom killer.
> At present, I
On Tue, 2007-07-03 at 23:47 +0100, Mark Fortescue wrote:
> Hi David,
>
> I will try out your patch shortly.
Thanks.
> I may be wrong about the size calculations but if you take a look at lines
> 2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
> these need to be changed t
On Tue, 2007-07-03 at 14:41 -0700, David Miller wrote:
> Please don't use get_unaligned() or whatever to fix this, it's
> going to generate the byte-at-a-time accesses on sparc64
> which doesn't need it since the redzone will be aligned.
Yes, get_unaligned() would suck. But 'u64 __aligned__((BYTE
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
> The problem is that sun4c Sparc32 can't handle un-aligned variables so
> having a 64bit readzone word that is not aligned on a 64bit boundary is a
> problem.
Surely, it can. You just have to tell the compiler that it's not
properly align
On Tue, 2007-07-03 at 19:57 +0100, Mark Fortescue wrote:
> > Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment
> > issues but does not ensure that all 64bit alignment requirements of sparc32
> > are met. Tests have shown that the redzone2 word can become misallignd.
Oops,
On Thu, 2007-05-24 at 12:50 -0700, Linus Torvalds wrote:
> There's a huge difference between "You killed my father, prepare to
> die", and "Btw, I didn't like that, but I'll just continue".
There are three cases, not two:
1. Something slightly suboptimal happened. We didn't like it.
2. Something
13 matches
Mail list logo
