On Tue, 2005-08-02 at 12:13 -0400, Bill Davidsen wrote:
> You are hardly the first person to implement the "it doesn't work right,
> but it sure is FAST!" algorithm.
>
I would actually call it the "It works _most_ of the time, and it sure
is FAST!" algorithm. It's a step up from what you mentio
Steven Rostedt wrote:
On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote:
On Fri, 29 Jul 2005, Cal Peake wrote:
Thanks Andrew! Indeed your suspicions are correct. Adding in all the
debugging moved the problem around, it now shows itself when probing
parport. Upon further investigation r
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll le
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll le
Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> For the bennefit of those of us who were not at LKS, could someone
> elaborate a bit on "the new release process" ?
http://lwn.net/Articles/144281/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
On Fri, 29 Jul 2005, Mickey Stein wrote:
> This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
> and gave it a test run. It had a bit of a problem and ground to a halt after
> spewing these into the log.
>
> If I can find the time tomorrow morning, I'll leave parport_pc
On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote:
>
> On Fri, 29 Jul 2005, Cal Peake wrote:
> >
> > Thanks Andrew! Indeed your suspicions are correct. Adding in all the
> > debugging moved the problem around, it now shows itself when probing
> > parport. Upon further investigation revert
On Fri, 29 Jul 2005, Linus Torvalds wrote:
> Thanks. Just out of interest, does this patch fix it instead?
Indeed it does, thanks Linus!
-cp
>
> diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
> --- a/include/asm-i386/bitops.h
> +++ b/include/asm-i386/bitops.h
> @@ -335,
On Fri, 29 Jul 2005, Cal Peake wrote:
>
> Thanks Andrew! Indeed your suspicions are correct. Adding in all the
> debugging moved the problem around, it now shows itself when probing
> parport. Upon further investigation reverting the commit below seems to
> have nixed the problem.
Thanks. Ju
On Thu, 28 Jul 2005, Andrew Morton wrote:
> The procfs inode IDR tree is scrogged. I'd be suspecting a random memory
> scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB,
> CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest.
>
> If that doesn't show anything, try eliminating s
On 7/29/05, Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
>
> > On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > >
> > > Hey everybody,
> > >
> > > as many of you are aware, we were talking (not enough) about the
> release
> > > process at LKS this year.
> > >
> > > This ain't it.
> > >
> >
> On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > Hey everybody,
> >
> > as many of you are aware, we were talking (not enough) about the
release
> > process at LKS this year.
> >
> > This ain't it.
> >
> > This is just the regular old release "process", with some LKS
backlog p
On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Hey everybody,
>
> as many of you are aware, we were talking (not enough) about the release
> process at LKS this year.
>
> This ain't it.
>
> This is just the regular old release "process", with some LKS backlog put
> in for good measu
Hey everybody,
as many of you are aware, we were talking (not enough) about the release
process at LKS this year.
This ain't it.
This is just the regular old release "process", with some LKS backlog
put in for good measure.
But the good news is, that I'll try the new release process after 2.
Cal Peake <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Getting this nastiness when probing snd-cs46xx:
>
> Unable to handle kernel paging request at virtual address 000a75a8
> ...
> EIP is at sub_alloc+0x42/0x170
> ...
> [] idr_get_new_above_int+0x78/0x120
> [] idr_get_new+0x1f/0x50
> [] get_inode_n
Hi,
Getting this nastiness when probing snd-cs46xx:
Unable to handle kernel paging request at virtual address 000a75a8
printing eip:
c01afe52
*pde =
Oops: [#1]
Modules linked in: snd_cs46xx gameport snd_rawmidi snd_seq_device
snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page
ARTs on MPC824x individual platform devices
ppc32: Add proper prototype for cpm2_reset()
I2C-MPC: Restore code removed
Kurt Wall:
Add text for dealing with "dot releases" to README
Kyle Moffett:
[NET]: Fix setsockopt locking bug
Linda Xie:
[SCSI] IBM VSCSI Client: sending cli
17 matches
Mail list logo
