On 06-02-08 15:38, Thomas Renninger wrote:
I expect on Rene's machine (might be something else, but this probably
often happens), BIOS exports dma and IO ports. The irq seem to be
missing and the driver does not use pnp_irq_valid, but pnp_irq. It
No. Please note we're talking about ISAPnP,
On 06-02-08 15:38, Thomas Renninger wrote:
I expect on Rene's machine (might be something else, but this probably
often happens), BIOS exports dma and IO ports. The irq seem to be
missing and the driver does not use pnp_irq_valid, but pnp_irq. It
No. Please note we're talking about ISAPnP,
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?
This one includes findings from tests with Rene on a isa system.
It handles possible NULL pointers and
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?
This one includes findings from tests with Rene on a isa system.
It handles possible NULL pointers and checks
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
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
> Hi Thomas,
>
> On Jan 19, 2008 10:00 PM, Thomas Renninger <[EMAIL PROTECTED]> wrote:
> > +static int pnp_alloc_port(struct pnp_resource_table *res)
> > +{
>
> [snip]
>
> > + res->port_resource = krealloc(res->port_resource,
> > +
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger [EMAIL PROTECTED] wrote:
+static int pnp_alloc_port(struct pnp_resource_table *res)
+{
[snip]
+ res-port_resource = krealloc(res-port_resource,
+
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger <[EMAIL PROTECTED]> wrote:
> +static int pnp_alloc_port(struct pnp_resource_table *res)
> +{
[snip]
> + res->port_resource = krealloc(res->port_resource,
> + (sizeof(struct resource) * res->allocated_ports)
> +
Allocate pnp resources dynamically via krealloc
The patch is against 2.6.24-rc6-mm1.
Latest BIOS ACPI PNP device resource descriptions may have (especially on the
general device PNP0c02) more than 20 IO port resources.
Reserve the space in a static array wastes a lot of memory on every PNP
Allocate pnp resources dynamically via krealloc
The patch is against 2.6.24-rc6-mm1.
Latest BIOS ACPI PNP device resource descriptions may have (especially on the
general device PNP0c02) more than 20 IO port resources.
Reserve the space in a static array wastes a lot of memory on every PNP
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger [EMAIL PROTECTED] wrote:
+static int pnp_alloc_port(struct pnp_resource_table *res)
+{
[snip]
+ res-port_resource = krealloc(res-port_resource,
+ (sizeof(struct resource) * res-allocated_ports)
+ +
32 matches
Mail list logo
