On Mon, 2008-01-28 at 22:12 +0100, Rene Herman wrote:
> On 28-01-08 20:12, Thomas Renninger wrote:
>
> > This was more a step backward, hopefully this one (on top), gets the
> > area bugfree?
>
> I'm afraid not. Next oops in pnp_check_port(). The attached lets it get past
> that point but
On Mon, 2008-01-28 at 22:12 +0100, Rene Herman wrote:
On 28-01-08 20:12, Thomas Renninger wrote:
This was more a step backward, hopefully this one (on top), gets the
area bugfree?
I'm afraid not. Next oops in pnp_check_port(). The attached lets it get past
that point but _then_ things
On 28-01-08 20:12, Thomas Renninger wrote:
This was more a step backward, hopefully this one (on top), gets the
area bugfree?
I'm afraid not. Next oops in pnp_check_port(). The attached lets it get past
that point but _then_ things fall apart a little bit further on again which
seems to
On Mon, 2008-01-28 at 19:07 +0100, Rene Herman wrote:
> On 28-01-08 17:04, Thomas Renninger wrote:
>
> > Can you try these two "on top" patches pls.
>
> Thought I could, but my machine begs to differ...
>
> ===
> pnp: the driver 'cs4236_isapnp' has been registered
> cs4236_isapnp 01:01.00:
On 28-01-08 17:04, Thomas Renninger wrote:
Can you try these two "on top" patches pls.
Thought I could, but my machine begs to differ...
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp
On Mon, 2008-01-28 at 16:00 +0100, Rene Herman wrote:
> On 28-01-08 15:21, Thomas Renninger wrote:
>
> > I think I know what is going on.
> > While pnpbios and pnpacpi theoretically do not have limits, isapnp has
> > spec restrictions (AFAIK, I have not read this up, but taken over from
> >
On Mon, 2008-01-28 at 16:00 +0100, Rene Herman wrote:
> On 28-01-08 15:21, Thomas Renninger wrote:
>
> > I think I know what is going on.
> > While pnpbios and pnpacpi theoretically do not have limits, isapnp has
> > spec restrictions (AFAIK, I have not read this up, but taken over from
> >
On 28-01-08 15:21, Thomas Renninger wrote:
I think I know what is going on.
While pnpbios and pnpacpi theoretically do not have limits, isapnp has
spec restrictions (AFAIK, I have not read this up, but taken over from
previous implementation...).
Therefore in isapnp I wanted to stay with:
On Sun, 2008-01-27 at 20:19 +0100, Rene Herman wrote:
> On 23-01-08 18:38, Thomas Renninger wrote:
>
> > isapnp is totally untested. Also the sysfs is rather untested.
>
> If nobody beats me to it I'll debug this myself later on, but as a quick
> heads up:
I think I know what is going on.
While
On 28-01-08 17:04, Thomas Renninger wrote:
Can you try these two on top patches pls.
Thought I could, but my machine begs to differ...
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp
On 28-01-08 20:12, Thomas Renninger wrote:
This was more a step backward, hopefully this one (on top), gets the
area bugfree?
I'm afraid not. Next oops in pnp_check_port(). The attached lets it get past
that point but _then_ things fall apart a little bit further on again which
seems to
On Mon, 2008-01-28 at 16:00 +0100, Rene Herman wrote:
On 28-01-08 15:21, Thomas Renninger wrote:
I think I know what is going on.
While pnpbios and pnpacpi theoretically do not have limits, isapnp has
spec restrictions (AFAIK, I have not read this up, but taken over from
previous
On Mon, 2008-01-28 at 19:07 +0100, Rene Herman wrote:
On 28-01-08 17:04, Thomas Renninger wrote:
Can you try these two on top patches pls.
Thought I could, but my machine begs to differ...
===
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
On Sun, 2008-01-27 at 20:19 +0100, Rene Herman wrote:
On 23-01-08 18:38, Thomas Renninger wrote:
isapnp is totally untested. Also the sysfs is rather untested.
If nobody beats me to it I'll debug this myself later on, but as a quick
heads up:
I think I know what is going on.
While
On Mon, 2008-01-28 at 16:00 +0100, Rene Herman wrote:
On 28-01-08 15:21, Thomas Renninger wrote:
I think I know what is going on.
While pnpbios and pnpacpi theoretically do not have limits, isapnp has
spec restrictions (AFAIK, I have not read this up, but taken over from
previous
On 28-01-08 15:21, Thomas Renninger wrote:
I think I know what is going on.
While pnpbios and pnpacpi theoretically do not have limits, isapnp has
spec restrictions (AFAIK, I have not read this up, but taken over from
previous implementation...).
Therefore in isapnp I wanted to stay with:
Hi Thomas,
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
> > When krealloc() returns NULL, there wasn't enough memory to fit the
> > new size but the original memory region remains unchanged.
On Jan 23, 2008 7:38 PM, Thomas Renninger <[EMAIL PROTECTED]> wrote:
> Thanks Pekka, this one
On 23-01-08 18:38, Thomas Renninger wrote:
isapnp is totally untested. Also the sysfs is rather untested.
If nobody beats me to it I'll debug this myself later on, but as a quick
heads up:
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
On 23-01-08 18:38, Thomas Renninger wrote:
isapnp is totally untested. Also the sysfs is rather untested.
If nobody beats me to it I'll debug this myself later on, but as a quick
heads up:
pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
Hi Thomas,
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
When krealloc() returns NULL, there wasn't enough memory to fit the
new size but the original memory region remains unchanged.
On Jan 23, 2008 7:38 PM, Thomas Renninger [EMAIL PROTECTED] wrote:
Thanks Pekka, this one should
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
> Hi Thomas,
...
> When krealloc() returns NULL, there wasn't enough memory to fit the
> new size but the original memory region remains unchanged.
...
Thanks Pekka, this one should be better now:
The patch is against latest 2.6.24-rc8 not
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
Hi Thomas,
...
When krealloc() returns NULL, there wasn't enough memory to fit the
new size but the original memory region remains unchanged.
...
Thanks Pekka, this one should be better now:
The patch is against latest 2.6.24-rc8 not -mm
22 matches
Mail list logo
