Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

[Jörn Engel]

On Fri, 22 April 2005 11:22:51 +0300, Denis Vlasenko wrote:
> 
> I do it this way:
> 
> int f()
> {
> - tuple_t tuple;
> - cisparse_t parse;
> - u_char buf[255];
> + struct {
> + tuple_t tuple;
> + cisparse_t parse;
> + u_char buf[255];
> + } local;
> + local = kmalloc(sizeof(*local),...); if(!local)...
>   ...
> -     tuple.Attributes = tuple.TupleOffset = 0;
> -     tuple.TupleData = (cisdata_t *)buf;
> -     tuple.TupleDataMax = sizeof(buf);
> +     local->tuple.Attributes = local->tuple.TupleOffset = 0;
> +     local->tuple.TupleData = (cisdata_t *)local->buf;
> +     local->tuple.TupleDataMax = sizeof(local->buf);
> 
> I see the following advantages:
> 
> 1) struct is unnamed and local to function
> 2) Variables do not change their type, the just sit in local-> now.
>I can just add 'local->' to each affected variable,
>without "it was an object, now it is a pointer" changes.
>No need to replace . with ->, remove &, etc.

I'd have proposed the same, before reading further down in the patch.
Basically, the driver is full of duplication, so the exact same struct
can be used several times.  Therefore, the downsides of your approach
seem to prevail.

> 3) I do not need to do this part of your patch which adds more locals:
> +    tuple_t *tuple;
> +    cisparse_t *parse;
> +    cistpl_cftable_entry_t *cf;
> +    u_char *buf;
> ...
> +    tuple = _mem->tuple;
> +    parse = _mem->parse;
> +    buf = cfg_mem->buf;
> 4) in resulting asm one base pointer instead of many will require
>less registers

Yup.  There are thousands of detail to improve in that driver.  It's
current maintainership (there is none) may explain that state.

Jörn

-- 
Fantasy is more important than knowledge. Knowledge is limited,
while fantasy embraces the whole world.
-- Albert Einstein
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

[Jörn Engel]

On Fri, 22 April 2005 11:22:51 +0300, Denis Vlasenko wrote:
 
 I do it this way:
 
 int f()
 {
 - tuple_t tuple;
 - cisparse_t parse;
 - u_char buf[255];
 + struct {
 + tuple_t tuple;
 + cisparse_t parse;
 + u_char buf[255];
 + } local;
 + local = kmalloc(sizeof(*local),...); if(!local)...
   ...
 -     tuple.Attributes = tuple.TupleOffset = 0;
 -     tuple.TupleData = (cisdata_t *)buf;
 -     tuple.TupleDataMax = sizeof(buf);
 +     local-tuple.Attributes = local-tuple.TupleOffset = 0;
 +     local-tuple.TupleData = (cisdata_t *)local-buf;
 +     local-tuple.TupleDataMax = sizeof(local-buf);
 
 I see the following advantages:
 
 1) struct is unnamed and local to function
 2) Variables do not change their type, the just sit in local- now.
I can just add 'local-' to each affected variable,
without it was an object, now it is a pointer changes.
No need to replace . with -, remove , etc.

I'd have proposed the same, before reading further down in the patch.
Basically, the driver is full of duplication, so the exact same struct
can be used several times.  Therefore, the downsides of your approach
seem to prevail.

 3) I do not need to do this part of your patch which adds more locals:
 +    tuple_t *tuple;
 +    cisparse_t *parse;
 +    cistpl_cftable_entry_t *cf;
 +    u_char *buf;
 ...
 +    tuple = cfg_mem-tuple;
 +    parse = cfg_mem-parse;
 +    buf = cfg_mem-buf;
 4) in resulting asm one base pointer instead of many will require
less registers

Yup.  There are thousands of detail to improve in that driver.  It's
current maintainership (there is none) may explain that state.

Jörn

-- 
Fantasy is more important than knowledge. Knowledge is limited,
while fantasy embraces the whole world.
-- Albert Einstein
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

[Denis Vlasenko]

On Friday 22 April 2005 01:02, Yum Rayan wrote:
> This patch reduces the stack usage of the function smc91c92_event() in
> smc91c92_cs driver from 3540 to 132. Currently this is the highest
> stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
> 3.4.3 on i386 with -fno-unit-at-a-time disabled.
> 
> The patch has only been compile tested. It would be nice to get
> feedback if someone that owns the hardware can actually test this
> patch.
> 
> Acked-by: JЖrn Engel <[EMAIL PROTECTED]>
> Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
> Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
> 
>  smc91c92_cs.c |  287 
> ++
>  1 files changed, 189 insertions(+), 98 deletions(-)
> 
> diff -Nupr -X dontdiff
> linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c
> linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c
> --- linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c   2005-04-14
> 22:15:43.0 -0700
> +++ linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c   2005-04-20
> 18:12:00.0 -0700
> @@ -127,6 +127,12 @@ struct smc_private {
>  int  rx_ovrn;
>  };
>  
> +struct smc_cfg_mem {
> +tuple_t tuple;
> +cisparse_t parse;
> +u_char buf[255];
> +};
> +
>  /* Special definitions for Megahertz multifunction cards */
>  #define MEGAHERTZ_ISR0x0380
>  
> @@ -498,14 +504,24 @@ static int mhz_mfc_config(dev_link_t *li
>  {
>  struct net_device *dev = link->priv;
>  struct smc_private *smc = netdev_priv(dev);
> -tuple_t tuple;
> -cisparse_t parse;
> -u_char buf[255];
> -cistpl_cftable_entry_t *cf = _entry;
> +struct smc_cfg_mem *cfg_mem;
> +tuple_t *tuple;
> +cisparse_t *parse;
> +cistpl_cftable_entry_t *cf;
> +u_char *buf;

I do it this way:

int f()
{
-   tuple_t tuple;
-   cisparse_t parse;
-   u_char buf[255];
+   struct {
+   tuple_t tuple;
+   cisparse_t parse;
+   u_char buf[255];
+   } local;
+   local = kmalloc(sizeof(*local),...); if(!local)...
...
-       tuple.Attributes = tuple.TupleOffset = 0;
-       tuple.TupleData = (cisdata_t *)buf;
-       tuple.TupleDataMax = sizeof(buf);
+       local->tuple.Attributes = local->tuple.TupleOffset = 0;
+       local->tuple.TupleData = (cisdata_t *)local->buf;
+       local->tuple.TupleDataMax = sizeof(local->buf);

I see the following advantages:

1) struct is unnamed and local to function
2) Variables do not change their type, the just sit in local-> now.
   I can just add 'local->' to each affected variable,
   without "it was an object, now it is a pointer" changes.
   No need to replace . with ->, remove &, etc.
3) I do not need to do this part of your patch which adds more locals:
+    tuple_t *tuple;
+    cisparse_t *parse;
+    cistpl_cftable_entry_t *cf;
+    u_char *buf;
...
+    tuple = _mem->tuple;
+    parse = _mem->parse;
+    buf = cfg_mem->buf;
4) in resulting asm one base pointer instead of many will require
   less registers

Look into nfs4_proc_unlink_setup() for example.
I see that Trond do not use locally declared struct there,
but otherwise it is done as described above.
--
vda

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

[Denis Vlasenko]

On Friday 22 April 2005 01:02, Yum Rayan wrote:
 This patch reduces the stack usage of the function smc91c92_event() in
 smc91c92_cs driver from 3540 to 132. Currently this is the highest
 stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
 3.4.3 on i386 with -fno-unit-at-a-time disabled.
 
 The patch has only been compile tested. It would be nice to get
 feedback if someone that owns the hardware can actually test this
 patch.
 
 Acked-by: Jrn Engel [EMAIL PROTECTED]
 Acked-by: Randy Dunlap [EMAIL PROTECTED]
 Signed-off-by: Yum Rayan [EMAIL PROTECTED]
 
  smc91c92_cs.c |  287 
 ++
  1 files changed, 189 insertions(+), 98 deletions(-)
 
 diff -Nupr -X dontdiff
 linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c
 linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c
 --- linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c   2005-04-14
 22:15:43.0 -0700
 +++ linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c   2005-04-20
 18:12:00.0 -0700
 @@ -127,6 +127,12 @@ struct smc_private {
  int  rx_ovrn;
  };
  
 +struct smc_cfg_mem {
 +tuple_t tuple;
 +cisparse_t parse;
 +u_char buf[255];
 +};
 +
  /* Special definitions for Megahertz multifunction cards */
  #define MEGAHERTZ_ISR0x0380
  
 @@ -498,14 +504,24 @@ static int mhz_mfc_config(dev_link_t *li
  {
  struct net_device *dev = link-priv;
  struct smc_private *smc = netdev_priv(dev);
 -tuple_t tuple;
 -cisparse_t parse;
 -u_char buf[255];
 -cistpl_cftable_entry_t *cf = parse.cftable_entry;
 +struct smc_cfg_mem *cfg_mem;
 +tuple_t *tuple;
 +cisparse_t *parse;
 +cistpl_cftable_entry_t *cf;
 +u_char *buf;

I do it this way:

int f()
{
-   tuple_t tuple;
-   cisparse_t parse;
-   u_char buf[255];
+   struct {
+   tuple_t tuple;
+   cisparse_t parse;
+   u_char buf[255];
+   } local;
+   local = kmalloc(sizeof(*local),...); if(!local)...
...
- tuple.Attributes = tuple.TupleOffset = 0;
- tuple.TupleData = (cisdata_t *)buf;
- tuple.TupleDataMax = sizeof(buf);
+ local-tuple.Attributes = local-tuple.TupleOffset = 0;
+ local-tuple.TupleData = (cisdata_t *)local-buf;
+ local-tuple.TupleDataMax = sizeof(local-buf);

I see the following advantages:

1) struct is unnamed and local to function
2) Variables do not change their type, the just sit in local- now.
   I can just add 'local-' to each affected variable,
   without it was an object, now it is a pointer changes.
   No need to replace . with -, remove , etc.
3) I do not need to do this part of your patch which adds more locals:
+  tuple_t *tuple;
+  cisparse_t *parse;
+  cistpl_cftable_entry_t *cf;
+  u_char *buf;
...
+  tuple = cfg_mem-tuple;
+  parse = cfg_mem-parse;
+  buf = cfg_mem-buf;
4) in resulting asm one base pointer instead of many will require
   less registers

Look into nfs4_proc_unlink_setup() for example.
I see that Trond do not use locally declared struct there,
but otherwise it is done as described above.
--
vda

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH linux-2.6.12-rc2-mm3] serial_cs: Reduce stack usage in serial_event()

[Yum Rayan]

This patch reduces the stack usage of the function serial_event() in
serial_cs from 2212 to 228. I used a patched version of gcc 3.4.3 on
i386 with -fno-unit-at-a-time disabled.

This patch is only compile tested. It would be nice to get feedback
from someone that owns the hardware and would like to test it.

Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>

 serial_cs.c |  170 ++--
 1 files changed, 110 insertions(+), 60 deletions(-)

diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/serial/serial_cs.c
linux-2.6.12-rc2-mm3.b/drivers/serial/serial_cs.c
--- linux-2.6.12-rc2-mm3.a/drivers/serial/serial_cs.c   2005-04-19
23:20:14.0 -0700
+++ linux-2.6.12-rc2-mm3.b/drivers/serial/serial_cs.c   2005-04-20
23:22:19.0 -0700
@@ -110,6 +110,13 @@ struct serial_info {
int line[4];
 };
 
+struct serial_cfg_mem {
+   tuple_t tuple;
+   cisparse_t parse;
+   u_char buf[256];
+};
+
+
 static void serial_config(dev_link_t * link);
 static int serial_event(event_t event, int priority,
event_callback_args_t * args);
@@ -388,14 +395,24 @@ static int simple_config(dev_link_t *lin
static int size_table[2] = { 8, 16 };
client_handle_t handle = link->handle;
struct serial_info *info = link->priv;
-   tuple_t tuple;
-   u_char buf[256];
-   cisparse_t parse;
-   cistpl_cftable_entry_t *cf = _entry;
+   struct serial_cfg_mem *cfg_mem;
+   tuple_t *tuple;
+   u_char *buf;
+   cisparse_t *parse;
+   cistpl_cftable_entry_t *cf;
config_info_t config;
int i, j, try;
int s;
 
+   cfg_mem = kmalloc(sizeof(struct serial_cfg_mem), GFP_KERNEL);
+   if (!cfg_mem)
+   return -1;
+   
+   tuple = _mem->tuple;
+   parse = _mem->parse;
+   cf = >cftable_entry;
+   buf = cfg_mem->buf;
+
/* If the card is already configured, look up the port and irq */
i = pcmcia_get_configuration_info(handle, );
if ((i == CS_SUCCESS) && (config.Attributes & CONF_VALID_CLIENT)) {
@@ -408,21 +425,23 @@ static int simple_config(dev_link_t *lin
port = config.BasePort1 + 0x28;
info->slave = 1;
}
-   if (info->slave)
+   if (info->slave) {
+   kfree(cfg_mem);
return setup_serial(handle, info, port, 
config.AssignedIRQ);
+   }
}
link->conf.Vcc = config.Vcc;
 
/* First pass: look for a config entry that looks normal. */
-   tuple.TupleData = (cisdata_t *) buf;
-   tuple.TupleOffset = 0;
-   tuple.TupleDataMax = 255;
-   tuple.Attributes = 0;
-   tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+   tuple->TupleData = (cisdata_t *) buf;
+   tuple->TupleOffset = 0;
+   tuple->TupleDataMax = 255;
+   tuple->Attributes = 0;
+   tuple->DesiredTuple = CISTPL_CFTABLE_ENTRY;
/* Two tries: without IO aliases, then with aliases */
for (s = 0; s < 2; s++) {
for (try = 0; try < 2; try++) {
-   i = first_tuple(handle, , );
+   i = first_tuple(handle, tuple, parse);
while (i != CS_NO_MORE_ITEMS) {
if (i != CS_SUCCESS)
goto next_entry;
@@ -440,14 +459,14 @@ static int simple_config(dev_link_t *lin
goto found_port;
}
 next_entry:
-   i = next_tuple(handle, , );
+   i = next_tuple(handle, tuple, parse);
}
}
}
/* Second pass: try to find an entry that isn't picky about
   its base address, then try to grab any standard serial port
   address, and finally try to get any free port. */
-   i = first_tuple(handle, , );
+   i = first_tuple(handle, tuple, parse);
while (i != CS_NO_MORE_ITEMS) {
if ((i == CS_SUCCESS) && (cf->io.nwin > 0) &&
((cf->io.flags & CISTPL_IO_LINES_MASK) <= 3)) {
@@ -460,7 +479,7 @@ next_entry:
goto found_port;
}
}
-   i = next_tuple(handle, , );
+   i = next_tuple(handle, tuple, parse);
}
 
   found_port:
@@ -468,6 +487,7 @@ next_entry:
printk(KERN_NOTICE
   "serial_cs: no usable port range found, giving up\n");
cs_error(link->handle, RequestIO, i);
+   kfree(cfg_mem);
return -1;
}
 
@@ 

[PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

[Yum Rayan]

This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time disabled.

The patch has only been compile tested. It would be nice to get
feedback if someone that owns the hardware can actually test this
patch.

Acked-by: Jörn Engel <[EMAIL PROTECTED]>
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>

 smc91c92_cs.c |  287 ++
 1 files changed, 189 insertions(+), 98 deletions(-)

diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c
linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c
--- linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c 2005-04-14
22:15:43.00000 -0700
+++ linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c 2005-04-20
18:12:00.0 -0700
@@ -127,6 +127,12 @@ struct smc_private {
 intrx_ovrn;
 };
 
+struct smc_cfg_mem {
+tuple_t tuple;
+cisparse_t parse;
+u_char buf[255];
+};
+
 /* Special definitions for Megahertz multifunction cards */
 #define MEGAHERTZ_ISR  0x0380
 
@@ -498,14 +504,24 @@ static int mhz_mfc_config(dev_link_t *li
 {
 struct net_device *dev = link->priv;
 struct smc_private *smc = netdev_priv(dev);
-tuple_t tuple;
-cisparse_t parse;
-u_char buf[255];
-cistpl_cftable_entry_t *cf = _entry;
+struct smc_cfg_mem *cfg_mem;
+tuple_t *tuple;
+cisparse_t *parse;
+cistpl_cftable_entry_t *cf;
+u_char *buf;
 win_req_t req;
 memreq_t mem;
 int i, k;
 
+cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
+if (!cfg_mem)
+return CS_OUT_OF_RESOURCE;
+
+tuple = _mem->tuple;
+parse = _mem->parse;
+cf = >cftable_entry;
+buf = cfg_mem->buf;
+
 link->conf.Attributes |= CONF_ENABLE_SPKR;
 link->conf.Status = CCSR_AUDIO_ENA;
 link->irq.Attributes =
@@ -514,12 +530,12 @@ static int mhz_mfc_config(dev_link_t *li
 link->io.Attributes2 = IO_DATA_PATH_WIDTH_8;
 link->io.NumPorts2 = 8;
 
-tuple.Attributes = tuple.TupleOffset = 0;
-tuple.TupleData = (cisdata_t *)buf;
-tuple.TupleDataMax = sizeof(buf);
-tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+tuple->Attributes = tuple->TupleOffset = 0;
+tuple->TupleData = (cisdata_t *)buf;
+tuple->TupleDataMax = 255;
+tuple->DesiredTuple = CISTPL_CFTABLE_ENTRY;
 
-i = first_tuple(link->handle, , );
+i = first_tuple(link->handle, tuple, parse);
 /* The Megahertz combo cards have modem-like CIS entries, so
we have to explicitly try a bunch of port combinations. */
 while (i == CS_SUCCESS) {
@@ -532,10 +548,10 @@ static int mhz_mfc_config(dev_link_t *li
if (i == CS_SUCCESS) break;
}
if (i == CS_SUCCESS) break;
-   i = next_tuple(link->handle, , );
+   i = next_tuple(link->handle, tuple, parse);
 }
 if (i != CS_SUCCESS)
-   return i;
+   goto free_cfg_mem;
 dev->base_addr = link->io.BasePort1;
 
 /* Allocate a memory window, for accessing the ISR */
@@ -544,7 +560,7 @@ static int mhz_mfc_config(dev_link_t *li
 req.AccessSpeed = 0;
 i = pcmcia_request_window(>handle, , >win);
 if (i != CS_SUCCESS)
-   return i;
+   goto free_cfg_mem;
 smc->base = ioremap(req.Base, req.Size);
 mem.CardOffset = mem.Page = 0;
 if (smc->manfid == MANFID_MOTOROLA)
@@ -556,6 +572,8 @@ static int mhz_mfc_config(dev_link_t *li
&& (smc->cardid == PRODID_MEGAHERTZ_EM3288))
mhz_3288_power(link);
 
+free_cfg_mem:
+kfree(cfg_mem);
 return i;
 }
 
@@ -563,39 +581,61 @@ static int mhz_setup(dev_link_t *link)
 {
 client_handle_t handle = link->handle;
 struct net_device *dev = link->priv;
-tuple_t tuple;
-cisparse_t parse;
-u_char buf[255], *station_addr;
+struct smc_cfg_mem *cfg_mem;
+tuple_t *tuple;
+cisparse_t *parse;
+u_char *buf, *station_addr;
+int rc;
+
+cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
+if (!cfg_mem)
+   return -1;
 
-tuple.Attributes = tuple.TupleOffset = 0;
-tuple.TupleData = buf;
-tuple.TupleDataMax = sizeof(buf);
+tuple = _mem->tuple;
+parse = _mem->parse;
+buf = cfg_mem->buf;
+
+tuple->Attributes = tuple->TupleOffset = 0;
+tuple->TupleData = (cisdata_t *)buf;
+tuple->TupleDataMax = 255;
 
 /* Read the station address from the CIS.  It is stored as the last
(fourth) string in the Version 1 Version/ID tuple. */
-tuple.DesiredTuple = CISTPL_VERS_1;
-if (first_tuple(handle, , ) != CS_SUCCESS)
-   return -1;
+tuple->DesiredTuple = CISTPL_VERS_1;
+if (first_

[PATCH linux-2.6.12-rc2-mm3] smc91c92_cs: Reduce stack usage in smc91c92_event()

[Yum Rayan]

This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time disabled.

The patch has only been compile tested. It would be nice to get
feedback if someone that owns the hardware can actually test this
patch.

Acked-by: Jörn Engel [EMAIL PROTECTED]
Acked-by: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Yum Rayan [EMAIL PROTECTED]

 smc91c92_cs.c |  287 ++
 1 files changed, 189 insertions(+), 98 deletions(-)

diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c
linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c
--- linux-2.6.12-rc2-mm3.a/drivers/net/pcmcia/smc91c92_cs.c 2005-04-14
22:15:43.0 -0700
+++ linux-2.6.12-rc2-mm3.b/drivers/net/pcmcia/smc91c92_cs.c 2005-04-20
18:12:00.0 -0700
@@ -127,6 +127,12 @@ struct smc_private {
 intrx_ovrn;
 };
 
+struct smc_cfg_mem {
+tuple_t tuple;
+cisparse_t parse;
+u_char buf[255];
+};
+
 /* Special definitions for Megahertz multifunction cards */
 #define MEGAHERTZ_ISR  0x0380
 
@@ -498,14 +504,24 @@ static int mhz_mfc_config(dev_link_t *li
 {
 struct net_device *dev = link-priv;
 struct smc_private *smc = netdev_priv(dev);
-tuple_t tuple;
-cisparse_t parse;
-u_char buf[255];
-cistpl_cftable_entry_t *cf = parse.cftable_entry;
+struct smc_cfg_mem *cfg_mem;
+tuple_t *tuple;
+cisparse_t *parse;
+cistpl_cftable_entry_t *cf;
+u_char *buf;
 win_req_t req;
 memreq_t mem;
 int i, k;
 
+cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
+if (!cfg_mem)
+return CS_OUT_OF_RESOURCE;
+
+tuple = cfg_mem-tuple;
+parse = cfg_mem-parse;
+cf = parse-cftable_entry;
+buf = cfg_mem-buf;
+
 link-conf.Attributes |= CONF_ENABLE_SPKR;
 link-conf.Status = CCSR_AUDIO_ENA;
 link-irq.Attributes =
@@ -514,12 +530,12 @@ static int mhz_mfc_config(dev_link_t *li
 link-io.Attributes2 = IO_DATA_PATH_WIDTH_8;
 link-io.NumPorts2 = 8;
 
-tuple.Attributes = tuple.TupleOffset = 0;
-tuple.TupleData = (cisdata_t *)buf;
-tuple.TupleDataMax = sizeof(buf);
-tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+tuple-Attributes = tuple-TupleOffset = 0;
+tuple-TupleData = (cisdata_t *)buf;
+tuple-TupleDataMax = 255;
+tuple-DesiredTuple = CISTPL_CFTABLE_ENTRY;
 
-i = first_tuple(link-handle, tuple, parse);
+i = first_tuple(link-handle, tuple, parse);
 /* The Megahertz combo cards have modem-like CIS entries, so
we have to explicitly try a bunch of port combinations. */
 while (i == CS_SUCCESS) {
@@ -532,10 +548,10 @@ static int mhz_mfc_config(dev_link_t *li
if (i == CS_SUCCESS) break;
}
if (i == CS_SUCCESS) break;
-   i = next_tuple(link-handle, tuple, parse);
+   i = next_tuple(link-handle, tuple, parse);
 }
 if (i != CS_SUCCESS)
-   return i;
+   goto free_cfg_mem;
 dev-base_addr = link-io.BasePort1;
 
 /* Allocate a memory window, for accessing the ISR */
@@ -544,7 +560,7 @@ static int mhz_mfc_config(dev_link_t *li
 req.AccessSpeed = 0;
 i = pcmcia_request_window(link-handle, req, link-win);
 if (i != CS_SUCCESS)
-   return i;
+   goto free_cfg_mem;
 smc-base = ioremap(req.Base, req.Size);
 mem.CardOffset = mem.Page = 0;
 if (smc-manfid == MANFID_MOTOROLA)
@@ -556,6 +572,8 @@ static int mhz_mfc_config(dev_link_t *li
 (smc-cardid == PRODID_MEGAHERTZ_EM3288))
mhz_3288_power(link);
 
+free_cfg_mem:
+kfree(cfg_mem);
 return i;
 }
 
@@ -563,39 +581,61 @@ static int mhz_setup(dev_link_t *link)
 {
 client_handle_t handle = link-handle;
 struct net_device *dev = link-priv;
-tuple_t tuple;
-cisparse_t parse;
-u_char buf[255], *station_addr;
+struct smc_cfg_mem *cfg_mem;
+tuple_t *tuple;
+cisparse_t *parse;
+u_char *buf, *station_addr;
+int rc;
+
+cfg_mem = kmalloc(sizeof(struct smc_cfg_mem), GFP_KERNEL);
+if (!cfg_mem)
+   return -1;
 
-tuple.Attributes = tuple.TupleOffset = 0;
-tuple.TupleData = buf;
-tuple.TupleDataMax = sizeof(buf);
+tuple = cfg_mem-tuple;
+parse = cfg_mem-parse;
+buf = cfg_mem-buf;
+
+tuple-Attributes = tuple-TupleOffset = 0;
+tuple-TupleData = (cisdata_t *)buf;
+tuple-TupleDataMax = 255;
 
 /* Read the station address from the CIS.  It is stored as the last
(fourth) string in the Version 1 Version/ID tuple. */
-tuple.DesiredTuple = CISTPL_VERS_1;
-if (first_tuple(handle, tuple, parse) != CS_SUCCESS)
-   return -1;
+tuple-DesiredTuple = CISTPL_VERS_1;
+if (first_tuple(handle, tuple, parse) != CS_SUCCESS) {
+   rc = -1;
+   goto free_cfg_mem;
+}
 /* Ugh

[PATCH linux-2.6.12-rc2-mm3] serial_cs: Reduce stack usage in serial_event()

[Yum Rayan]

This patch reduces the stack usage of the function serial_event() in
serial_cs from 2212 to 228. I used a patched version of gcc 3.4.3 on
i386 with -fno-unit-at-a-time disabled.

This patch is only compile tested. It would be nice to get feedback
from someone that owns the hardware and would like to test it.

Acked-by: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Yum Rayan [EMAIL PROTECTED]

 serial_cs.c |  170 ++--
 1 files changed, 110 insertions(+), 60 deletions(-)

diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/serial/serial_cs.c
linux-2.6.12-rc2-mm3.b/drivers/serial/serial_cs.c
--- linux-2.6.12-rc2-mm3.a/drivers/serial/serial_cs.c   2005-04-19
23:20:14.0 -0700
+++ linux-2.6.12-rc2-mm3.b/drivers/serial/serial_cs.c   2005-04-20
23:22:19.0 -0700
@@ -110,6 +110,13 @@ struct serial_info {
int line[4];
 };
 
+struct serial_cfg_mem {
+   tuple_t tuple;
+   cisparse_t parse;
+   u_char buf[256];
+};
+
+
 static void serial_config(dev_link_t * link);
 static int serial_event(event_t event, int priority,
event_callback_args_t * args);
@@ -388,14 +395,24 @@ static int simple_config(dev_link_t *lin
static int size_table[2] = { 8, 16 };
client_handle_t handle = link-handle;
struct serial_info *info = link-priv;
-   tuple_t tuple;
-   u_char buf[256];
-   cisparse_t parse;
-   cistpl_cftable_entry_t *cf = parse.cftable_entry;
+   struct serial_cfg_mem *cfg_mem;
+   tuple_t *tuple;
+   u_char *buf;
+   cisparse_t *parse;
+   cistpl_cftable_entry_t *cf;
config_info_t config;
int i, j, try;
int s;
 
+   cfg_mem = kmalloc(sizeof(struct serial_cfg_mem), GFP_KERNEL);
+   if (!cfg_mem)
+   return -1;
+   
+   tuple = cfg_mem-tuple;
+   parse = cfg_mem-parse;
+   cf = parse-cftable_entry;
+   buf = cfg_mem-buf;
+
/* If the card is already configured, look up the port and irq */
i = pcmcia_get_configuration_info(handle, config);
if ((i == CS_SUCCESS)  (config.Attributes  CONF_VALID_CLIENT)) {
@@ -408,21 +425,23 @@ static int simple_config(dev_link_t *lin
port = config.BasePort1 + 0x28;
info-slave = 1;
}
-   if (info-slave)
+   if (info-slave) {
+   kfree(cfg_mem);
return setup_serial(handle, info, port, 
config.AssignedIRQ);
+   }
}
link-conf.Vcc = config.Vcc;
 
/* First pass: look for a config entry that looks normal. */
-   tuple.TupleData = (cisdata_t *) buf;
-   tuple.TupleOffset = 0;
-   tuple.TupleDataMax = 255;
-   tuple.Attributes = 0;
-   tuple.DesiredTuple = CISTPL_CFTABLE_ENTRY;
+   tuple-TupleData = (cisdata_t *) buf;
+   tuple-TupleOffset = 0;
+   tuple-TupleDataMax = 255;
+   tuple-Attributes = 0;
+   tuple-DesiredTuple = CISTPL_CFTABLE_ENTRY;
/* Two tries: without IO aliases, then with aliases */
for (s = 0; s  2; s++) {
for (try = 0; try  2; try++) {
-   i = first_tuple(handle, tuple, parse);
+   i = first_tuple(handle, tuple, parse);
while (i != CS_NO_MORE_ITEMS) {
if (i != CS_SUCCESS)
goto next_entry;
@@ -440,14 +459,14 @@ static int simple_config(dev_link_t *lin
goto found_port;
}
 next_entry:
-   i = next_tuple(handle, tuple, parse);
+   i = next_tuple(handle, tuple, parse);
}
}
}
/* Second pass: try to find an entry that isn't picky about
   its base address, then try to grab any standard serial port
   address, and finally try to get any free port. */
-   i = first_tuple(handle, tuple, parse);
+   i = first_tuple(handle, tuple, parse);
while (i != CS_NO_MORE_ITEMS) {
if ((i == CS_SUCCESS)  (cf-io.nwin  0) 
((cf-io.flags  CISTPL_IO_LINES_MASK) = 3)) {
@@ -460,7 +479,7 @@ next_entry:
goto found_port;
}
}
-   i = next_tuple(handle, tuple, parse);
+   i = next_tuple(handle, tuple, parse);
}
 
   found_port:
@@ -468,6 +487,7 @@ next_entry:
printk(KERN_NOTICE
   serial_cs: no usable port range found, giving up\n);
cs_error(link-handle, RequestIO, i);
+   kfree(cfg_mem);
return -1;
}
 
@@ -481,9 +501,10 @@ next_entry:
i = pcmcia_request_configuration(link-handle, link-conf

Re: [PATCH Linux 2.6.12-rc2 00/04] blk: generic tag support fixes

[Jens Axboe]

On Wed, Apr 20 2005, Tejun Heo wrote:
>  Hello, Jens.
> 
>  These are fixes to generic tag support in the blk layer.  They all
> compile okay and I've proof read it, but as I don't have any HBA which
> uses generic tag support, I wasn't able to test directly.  However,
> all changes are fairly straight-forward.

All patches look good, thanks!

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Linux 2.6.12-rc2 04/04] blk: cleanup generic tag support error messages

[Tejun Heo]

04_blk_tag_map_error_handling_cleanup.patch

Add KERN_ERR and __FUNCTION__ to generic tag error messages,
and add a comment in blk_queue_end_tag() which explains the
silent failure path.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

 ll_rw_blk.c |   18 +-
 1 files changed, 13 insertions(+), 5 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:38.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:40.0 +0900
@@ -911,10 +911,15 @@ void blk_queue_end_tag(request_queue_t *
BUG_ON(tag == -1);
 
if (unlikely(tag >= bqt->max_depth))
+   /*
+* This can happen after tag depth has been reduced.
+* FIXME: how about a warning or info message here?
+*/
return;
 
if (unlikely(!__test_and_clear_bit(tag, bqt->tag_map))) {
-   printk("attempt to clear non-busy tag (%d)\n", tag);
+   printk(KERN_ERR "%s: attempt to clear non-busy tag (%d)\n",
+  __FUNCTION__, tag);
return;
}
 
@@ -923,7 +928,8 @@ void blk_queue_end_tag(request_queue_t *
rq->tag = -1;
 
if (unlikely(bqt->tag_index[tag] == NULL))
-   printk("tag %d is missing\n", tag);
+   printk(KERN_ERR "%s: tag %d is missing\n",
+  __FUNCTION__, tag);
 
bqt->tag_index[tag] = NULL;
bqt->busy--;
@@ -956,8 +962,9 @@ int blk_queue_start_tag(request_queue_t 
 
if (unlikely((rq->flags & REQ_QUEUED))) {
printk(KERN_ERR 
-  "request %p for device [%s] already tagged %d",
-  rq, rq->rq_disk ? rq->rq_disk->disk_name : "?", rq->tag);
+  "%s: request %p for device [%s] already tagged %d",
+  __FUNCTION__, rq,
+  rq->rq_disk ? rq->rq_disk->disk_name : "?", rq->tag);
BUG();
}
 
@@ -1000,7 +1007,8 @@ void blk_queue_invalidate_tags(request_q
rq = list_entry_rq(tmp);
 
if (rq->tag == -1) {
-   printk("bad tag found on list\n");
+   printk(KERN_ERR
+  "%s: bad tag found on list\n", __FUNCTION__);
list_del_init(>queuelist);
rq->flags &= ~REQ_QUEUED;
} else

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Linux 2.6.12-rc2 03/04] blk: remove BLK_TAGS_{PER_LONG|MASK}

[Tejun Heo]

03_blk_tag_map_remove_BLK_TAGS_PER_LONG.patch

Replace BLK_TAGS_PER_LONG with BITS_PER_LONG and remove unused
BLK_TAGS_MASK.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

 drivers/block/ll_rw_blk.c |4 ++--
 include/linux/blkdev.h|3 ---
 2 files changed, 2 insertions(+), 5 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:37.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:38.0 +0900
@@ -788,7 +788,7 @@ init_tag_map(request_queue_t *q, struct 
if (!tag_index)
goto fail;
 
-   nr_ulongs = ALIGN(depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   nr_ulongs = ALIGN(depth, BITS_PER_LONG) / BITS_PER_LONG;
tag_map = kmalloc(nr_ulongs * sizeof(unsigned long), GFP_ATOMIC);
if (!tag_map)
goto fail;
@@ -879,7 +879,7 @@ int blk_queue_resize_tags(request_queue_
return -ENOMEM;
 
memcpy(bqt->tag_index, tag_index, max_depth * sizeof(struct request *));
-   nr_ulongs = ALIGN(max_depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   nr_ulongs = ALIGN(max_depth, BITS_PER_LONG) / BITS_PER_LONG;
memcpy(bqt->tag_map, tag_map, nr_ulongs * sizeof(unsigned long));
 
kfree(tag_index);
Index: blk-fixes/include/linux/blkdev.h
===
--- blk-fixes.orig/include/linux/blkdev.h   2005-04-20 20:36:37.0 
+0900
+++ blk-fixes/include/linux/blkdev.h2005-04-20 20:36:38.0 +0900
@@ -285,9 +285,6 @@ enum blk_queue_state {
Queue_up,
 };
 
-#define BLK_TAGS_PER_LONG  (sizeof(unsigned long) * 8)
-#define BLK_TAGS_MASK  (BLK_TAGS_PER_LONG - 1)
-
 struct blk_queue_tag {
struct request **tag_index; /* map of busy tags */
unsigned long *tag_map; /* bit map of free/busy tags */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Linux 2.6.12-rc2 02/04] blk: remove blk_queue_tag->real_max_depth optimization

[Tejun Heo]

02_blk_tag_map_remove_real_max_depth.patch

blk_queue_tag->real_max_depth was used to optimize out
unnecessary allocations/frees on tag resize.  However, the
whole thing was very broken - tag_map was never allocated to
real_max_depth resulting in access beyond the end of the map,
bits in [max_depth..real_max_depth] were set when initializing
a map and copied when resizing resulting in pre-occupied tags.

As the gain of the optimization is very small, well, almost
nill, remove the whole thing.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

 drivers/block/ll_rw_blk.c |   35 ++-
 include/linux/blkdev.h|1 -
 2 files changed, 10 insertions(+), 26 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:36.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:37.0 +0900
@@ -716,7 +716,7 @@ struct request *blk_queue_find_tag(reque
 {
struct blk_queue_tag *bqt = q->queue_tags;
 
-   if (unlikely(bqt == NULL || tag >= bqt->real_max_depth))
+   if (unlikely(bqt == NULL || tag >= bqt->max_depth))
return NULL;
 
return bqt->tag_index[tag];
@@ -774,9 +774,9 @@ EXPORT_SYMBOL(blk_queue_free_tags);
 static int
 init_tag_map(request_queue_t *q, struct blk_queue_tag *tags, int depth)
 {
-   int bits, i;
struct request **tag_index;
unsigned long *tag_map;
+   int nr_ulongs;
 
if (depth > q->nr_requests * 2) {
depth = q->nr_requests * 2;
@@ -788,24 +788,17 @@ init_tag_map(request_queue_t *q, struct 
if (!tag_index)
goto fail;
 
-   bits = (depth / BLK_TAGS_PER_LONG) + 1;
-   tag_map = kmalloc(bits * sizeof(unsigned long), GFP_ATOMIC);
+   nr_ulongs = ALIGN(depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   tag_map = kmalloc(nr_ulongs * sizeof(unsigned long), GFP_ATOMIC);
if (!tag_map)
goto fail;
 
memset(tag_index, 0, depth * sizeof(struct request *));
-   memset(tag_map, 0, bits * sizeof(unsigned long));
+   memset(tag_map, 0, nr_ulongs * sizeof(unsigned long));
tags->max_depth = depth;
-   tags->real_max_depth = bits * BITS_PER_LONG;
tags->tag_index = tag_index;
tags->tag_map = tag_map;
 
-   /*
-* set the upper bits if the depth isn't a multiple of the word size
-*/
-   for (i = depth; i < bits * BLK_TAGS_PER_LONG; i++)
-   __set_bit(i, tag_map);
-
return 0;
 fail:
kfree(tag_index);
@@ -870,32 +863,24 @@ int blk_queue_resize_tags(request_queue_
struct blk_queue_tag *bqt = q->queue_tags;
struct request **tag_index;
unsigned long *tag_map;
-   int bits, max_depth;
+   int max_depth, nr_ulongs;
 
if (!bqt)
return -ENXIO;
 
/*
-* don't bother sizing down
-*/
-   if (new_depth <= bqt->real_max_depth) {
-   bqt->max_depth = new_depth;
-   return 0;
-   }
-
-   /*
 * save the old state info, so we can copy it back
 */
tag_index = bqt->tag_index;
tag_map = bqt->tag_map;
-   max_depth = bqt->real_max_depth;
+   max_depth = bqt->max_depth;
 
if (init_tag_map(q, bqt, new_depth))
return -ENOMEM;
 
memcpy(bqt->tag_index, tag_index, max_depth * sizeof(struct request *));
-   bits = max_depth / BLK_TAGS_PER_LONG;
-   memcpy(bqt->tag_map, tag_map, bits * sizeof(unsigned long));
+   nr_ulongs = ALIGN(max_depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   memcpy(bqt->tag_map, tag_map, nr_ulongs * sizeof(unsigned long));
 
kfree(tag_index);
kfree(tag_map);
@@ -925,7 +910,7 @@ void blk_queue_end_tag(request_queue_t *
 
BUG_ON(tag == -1);
 
-   if (unlikely(tag >= bqt->real_max_depth))
+   if (unlikely(tag >= bqt->max_depth))
return;
 
if (unlikely(!__test_and_clear_bit(tag, bqt->tag_map))) {
Index: blk-fixes/include/linux/blkdev.h
===
--- blk-fixes.orig/include/linux/blkdev.h   2005-04-20 20:36:35.0 
+0900
+++ blk-fixes/include/linux/blkdev.h2005-04-20 20:36:37.0 +0900
@@ -294,7 +294,6 @@ struct blk_queue_tag {
struct list_head busy_list; /* fifo list of busy tags */
int busy;   /* current depth */
int max_depth;  /* what we will send to device */
-   int real_max_depth; /* what the array can hold */
atomic_t refcnt;/* map can be shared */
 };
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

Re: [PATCH Linux 2.6.12-rc2 01/04] blk: use find_first_zero_bit() in blk_queue_start_tag()

[Tejun Heo]

01_blk_tag_map_use_find_first_zero_bit.patch

blk_queue_start_tag() hand-coded searching for the first zero
bit in the tag map.  Replace it with find_first_zero_bit().
With this patch, blk_queue_star_tag() doesn't need to fill
remains of tag map with 1, thus allowing it to work properly
with the next remove_real_max_depth patch.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>

 ll_rw_blk.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:35.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:36.0 +0900
@@ -967,8 +967,7 @@ EXPORT_SYMBOL(blk_queue_end_tag);
 int blk_queue_start_tag(request_queue_t *q, struct request *rq)
 {
struct blk_queue_tag *bqt = q->queue_tags;
-   unsigned long *map = bqt->tag_map;
-   int tag = 0;
+   int tag;
 
if (unlikely((rq->flags & REQ_QUEUED))) {
printk(KERN_ERR 
@@ -977,14 +976,10 @@ int blk_queue_start_tag(request_queue_t 
BUG();
}
 
-   for (map = bqt->tag_map; *map == -1UL; map++) {
-   tag += BLK_TAGS_PER_LONG;
-
-   if (tag >= bqt->max_depth)
-   return 1;
-   }
+   tag = find_first_zero_bit(bqt->tag_map, bqt->max_depth);
+   if (tag >= bqt->max_depth)
+   return 1;
 
-   tag += ffz(*map);
__set_bit(tag, bqt->tag_map);
 
rq->flags |= REQ_QUEUED;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH Linux 2.6.12-rc2 00/04] blk: generic tag support fixes

[Tejun Heo]

 Hello, Jens.

 These are fixes to generic tag support in the blk layer.  They all
compile okay and I've proof read it, but as I don't have any HBA which
uses generic tag support, I wasn't able to test directly.  However,
all changes are fairly straight-forward.

[ Start of patch descriptions ]

01_blk_tag_map_use_find_first_zero_bit.patch
: use find_first_zero_bit() in blk_queue_start_tag()

blk_queue_start_tag() hand-coded searching for the first zero
bit in the tag map.  Replace it with find_first_zero_bit().
With this patch, blk_queue_star_tag() doesn't need to fill
remains of tag map with 1, thus allowing it to work properly
with the next remove_real_max_depth patch.

02_blk_tag_map_remove_real_max_depth.patch
: remove blk_queue_tag->real_max_depth optimization

blk_queue_tag->real_max_depth was used to optimize out
unnecessary allocations/frees on tag resize.  However, the
whole thing was very broken - tag_map was never allocated to
real_max_depth resulting in access beyond the end of the map,
bits in [max_depth..real_max_depth] were set when initializing
a map and copied when resizing resulting in pre-occupied tags.

As the gain of the optimization is very small, well, almost
nill, remove the whole thing.

03_blk_tag_map_remove_BLK_TAGS_PER_LONG.patch
: remove BLK_TAGS_{PER_LONG|MASK}

Replace BLK_TAGS_PER_LONG with BITS_PER_LONG and remove unused
BLK_TAGS_MASK.

04_blk_tag_map_error_handling_cleanup.patch
: cleanup generic tag support error messages

Add KERN_ERR and __FUNCTION__ to generic tag error messages,
and add a comment in blk_queue_end_tag() which explains the
silent failure path.

[ End of patch descriptions ]

 Thanks a lot. :-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Linux 2.6.12-rc2 01/04] blk: use find_first_zero_bit() in blk_queue_start_tag()

[Tejun Heo]

01_blk_tag_map_use_find_first_zero_bit.patch

blk_queue_start_tag() hand-coded searching for the first zero
bit in the tag map.  Replace it with find_first_zero_bit().
With this patch, blk_queue_star_tag() doesn't need to fill
remains of tag map with 1, thus allowing it to work properly
with the next remove_real_max_depth patch.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 ll_rw_blk.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:35.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:36.0 +0900
@@ -967,8 +967,7 @@ EXPORT_SYMBOL(blk_queue_end_tag);
 int blk_queue_start_tag(request_queue_t *q, struct request *rq)
 {
struct blk_queue_tag *bqt = q-queue_tags;
-   unsigned long *map = bqt-tag_map;
-   int tag = 0;
+   int tag;
 
if (unlikely((rq-flags  REQ_QUEUED))) {
printk(KERN_ERR 
@@ -977,14 +976,10 @@ int blk_queue_start_tag(request_queue_t 
BUG();
}
 
-   for (map = bqt-tag_map; *map == -1UL; map++) {
-   tag += BLK_TAGS_PER_LONG;
-
-   if (tag = bqt-max_depth)
-   return 1;
-   }
+   tag = find_first_zero_bit(bqt-tag_map, bqt-max_depth);
+   if (tag = bqt-max_depth)
+   return 1;
 
-   tag += ffz(*map);
__set_bit(tag, bqt-tag_map);
 
rq-flags |= REQ_QUEUED;

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH Linux 2.6.12-rc2 00/04] blk: generic tag support fixes

[Tejun Heo]

 Hello, Jens.

 These are fixes to generic tag support in the blk layer.  They all
compile okay and I've proof read it, but as I don't have any HBA which
uses generic tag support, I wasn't able to test directly.  However,
all changes are fairly straight-forward.

[ Start of patch descriptions ]

01_blk_tag_map_use_find_first_zero_bit.patch
: use find_first_zero_bit() in blk_queue_start_tag()

blk_queue_start_tag() hand-coded searching for the first zero
bit in the tag map.  Replace it with find_first_zero_bit().
With this patch, blk_queue_star_tag() doesn't need to fill
remains of tag map with 1, thus allowing it to work properly
with the next remove_real_max_depth patch.

02_blk_tag_map_remove_real_max_depth.patch
: remove blk_queue_tag-real_max_depth optimization

blk_queue_tag-real_max_depth was used to optimize out
unnecessary allocations/frees on tag resize.  However, the
whole thing was very broken - tag_map was never allocated to
real_max_depth resulting in access beyond the end of the map,
bits in [max_depth..real_max_depth] were set when initializing
a map and copied when resizing resulting in pre-occupied tags.

As the gain of the optimization is very small, well, almost
nill, remove the whole thing.

03_blk_tag_map_remove_BLK_TAGS_PER_LONG.patch
: remove BLK_TAGS_{PER_LONG|MASK}

Replace BLK_TAGS_PER_LONG with BITS_PER_LONG and remove unused
BLK_TAGS_MASK.

04_blk_tag_map_error_handling_cleanup.patch
: cleanup generic tag support error messages

Add KERN_ERR and __FUNCTION__ to generic tag error messages,
and add a comment in blk_queue_end_tag() which explains the
silent failure path.

[ End of patch descriptions ]

 Thanks a lot. :-)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Linux 2.6.12-rc2 02/04] blk: remove blk_queue_tag-real_max_depth optimization

[Tejun Heo]

02_blk_tag_map_remove_real_max_depth.patch

blk_queue_tag-real_max_depth was used to optimize out
unnecessary allocations/frees on tag resize.  However, the
whole thing was very broken - tag_map was never allocated to
real_max_depth resulting in access beyond the end of the map,
bits in [max_depth..real_max_depth] were set when initializing
a map and copied when resizing resulting in pre-occupied tags.

As the gain of the optimization is very small, well, almost
nill, remove the whole thing.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/block/ll_rw_blk.c |   35 ++-
 include/linux/blkdev.h|1 -
 2 files changed, 10 insertions(+), 26 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:36.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:37.0 +0900
@@ -716,7 +716,7 @@ struct request *blk_queue_find_tag(reque
 {
struct blk_queue_tag *bqt = q-queue_tags;
 
-   if (unlikely(bqt == NULL || tag = bqt-real_max_depth))
+   if (unlikely(bqt == NULL || tag = bqt-max_depth))
return NULL;
 
return bqt-tag_index[tag];
@@ -774,9 +774,9 @@ EXPORT_SYMBOL(blk_queue_free_tags);
 static int
 init_tag_map(request_queue_t *q, struct blk_queue_tag *tags, int depth)
 {
-   int bits, i;
struct request **tag_index;
unsigned long *tag_map;
+   int nr_ulongs;
 
if (depth  q-nr_requests * 2) {
depth = q-nr_requests * 2;
@@ -788,24 +788,17 @@ init_tag_map(request_queue_t *q, struct 
if (!tag_index)
goto fail;
 
-   bits = (depth / BLK_TAGS_PER_LONG) + 1;
-   tag_map = kmalloc(bits * sizeof(unsigned long), GFP_ATOMIC);
+   nr_ulongs = ALIGN(depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   tag_map = kmalloc(nr_ulongs * sizeof(unsigned long), GFP_ATOMIC);
if (!tag_map)
goto fail;
 
memset(tag_index, 0, depth * sizeof(struct request *));
-   memset(tag_map, 0, bits * sizeof(unsigned long));
+   memset(tag_map, 0, nr_ulongs * sizeof(unsigned long));
tags-max_depth = depth;
-   tags-real_max_depth = bits * BITS_PER_LONG;
tags-tag_index = tag_index;
tags-tag_map = tag_map;
 
-   /*
-* set the upper bits if the depth isn't a multiple of the word size
-*/
-   for (i = depth; i  bits * BLK_TAGS_PER_LONG; i++)
-   __set_bit(i, tag_map);
-
return 0;
 fail:
kfree(tag_index);
@@ -870,32 +863,24 @@ int blk_queue_resize_tags(request_queue_
struct blk_queue_tag *bqt = q-queue_tags;
struct request **tag_index;
unsigned long *tag_map;
-   int bits, max_depth;
+   int max_depth, nr_ulongs;
 
if (!bqt)
return -ENXIO;
 
/*
-* don't bother sizing down
-*/
-   if (new_depth = bqt-real_max_depth) {
-   bqt-max_depth = new_depth;
-   return 0;
-   }
-
-   /*
 * save the old state info, so we can copy it back
 */
tag_index = bqt-tag_index;
tag_map = bqt-tag_map;
-   max_depth = bqt-real_max_depth;
+   max_depth = bqt-max_depth;
 
if (init_tag_map(q, bqt, new_depth))
return -ENOMEM;
 
memcpy(bqt-tag_index, tag_index, max_depth * sizeof(struct request *));
-   bits = max_depth / BLK_TAGS_PER_LONG;
-   memcpy(bqt-tag_map, tag_map, bits * sizeof(unsigned long));
+   nr_ulongs = ALIGN(max_depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   memcpy(bqt-tag_map, tag_map, nr_ulongs * sizeof(unsigned long));
 
kfree(tag_index);
kfree(tag_map);
@@ -925,7 +910,7 @@ void blk_queue_end_tag(request_queue_t *
 
BUG_ON(tag == -1);
 
-   if (unlikely(tag = bqt-real_max_depth))
+   if (unlikely(tag = bqt-max_depth))
return;
 
if (unlikely(!__test_and_clear_bit(tag, bqt-tag_map))) {
Index: blk-fixes/include/linux/blkdev.h
===
--- blk-fixes.orig/include/linux/blkdev.h   2005-04-20 20:36:35.0 
+0900
+++ blk-fixes/include/linux/blkdev.h2005-04-20 20:36:37.0 +0900
@@ -294,7 +294,6 @@ struct blk_queue_tag {
struct list_head busy_list; /* fifo list of busy tags */
int busy;   /* current depth */
int max_depth;  /* what we will send to device */
-   int real_max_depth; /* what the array can hold */
atomic_t refcnt;/* map can be shared */
 };
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH Linux 2.6.12-rc2 03/04] blk: remove BLK_TAGS_{PER_LONG|MASK}

[Tejun Heo]

03_blk_tag_map_remove_BLK_TAGS_PER_LONG.patch

Replace BLK_TAGS_PER_LONG with BITS_PER_LONG and remove unused
BLK_TAGS_MASK.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/block/ll_rw_blk.c |4 ++--
 include/linux/blkdev.h|3 ---
 2 files changed, 2 insertions(+), 5 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:37.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:38.0 +0900
@@ -788,7 +788,7 @@ init_tag_map(request_queue_t *q, struct 
if (!tag_index)
goto fail;
 
-   nr_ulongs = ALIGN(depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   nr_ulongs = ALIGN(depth, BITS_PER_LONG) / BITS_PER_LONG;
tag_map = kmalloc(nr_ulongs * sizeof(unsigned long), GFP_ATOMIC);
if (!tag_map)
goto fail;
@@ -879,7 +879,7 @@ int blk_queue_resize_tags(request_queue_
return -ENOMEM;
 
memcpy(bqt-tag_index, tag_index, max_depth * sizeof(struct request *));
-   nr_ulongs = ALIGN(max_depth, BLK_TAGS_PER_LONG) / BLK_TAGS_PER_LONG;
+   nr_ulongs = ALIGN(max_depth, BITS_PER_LONG) / BITS_PER_LONG;
memcpy(bqt-tag_map, tag_map, nr_ulongs * sizeof(unsigned long));
 
kfree(tag_index);
Index: blk-fixes/include/linux/blkdev.h
===
--- blk-fixes.orig/include/linux/blkdev.h   2005-04-20 20:36:37.0 
+0900
+++ blk-fixes/include/linux/blkdev.h2005-04-20 20:36:38.0 +0900
@@ -285,9 +285,6 @@ enum blk_queue_state {
Queue_up,
 };
 
-#define BLK_TAGS_PER_LONG  (sizeof(unsigned long) * 8)
-#define BLK_TAGS_MASK  (BLK_TAGS_PER_LONG - 1)
-
 struct blk_queue_tag {
struct request **tag_index; /* map of busy tags */
unsigned long *tag_map; /* bit map of free/busy tags */

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Linux 2.6.12-rc2 04/04] blk: cleanup generic tag support error messages

[Tejun Heo]

04_blk_tag_map_error_handling_cleanup.patch

Add KERN_ERR and __FUNCTION__ to generic tag error messages,
and add a comment in blk_queue_end_tag() which explains the
silent failure path.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 ll_rw_blk.c |   18 +-
 1 files changed, 13 insertions(+), 5 deletions(-)

Index: blk-fixes/drivers/block/ll_rw_blk.c
===
--- blk-fixes.orig/drivers/block/ll_rw_blk.c2005-04-20 20:36:38.0 
+0900
+++ blk-fixes/drivers/block/ll_rw_blk.c 2005-04-20 20:36:40.0 +0900
@@ -911,10 +911,15 @@ void blk_queue_end_tag(request_queue_t *
BUG_ON(tag == -1);
 
if (unlikely(tag = bqt-max_depth))
+   /*
+* This can happen after tag depth has been reduced.
+* FIXME: how about a warning or info message here?
+*/
return;
 
if (unlikely(!__test_and_clear_bit(tag, bqt-tag_map))) {
-   printk(attempt to clear non-busy tag (%d)\n, tag);
+   printk(KERN_ERR %s: attempt to clear non-busy tag (%d)\n,
+  __FUNCTION__, tag);
return;
}
 
@@ -923,7 +928,8 @@ void blk_queue_end_tag(request_queue_t *
rq-tag = -1;
 
if (unlikely(bqt-tag_index[tag] == NULL))
-   printk(tag %d is missing\n, tag);
+   printk(KERN_ERR %s: tag %d is missing\n,
+  __FUNCTION__, tag);
 
bqt-tag_index[tag] = NULL;
bqt-busy--;
@@ -956,8 +962,9 @@ int blk_queue_start_tag(request_queue_t 
 
if (unlikely((rq-flags  REQ_QUEUED))) {
printk(KERN_ERR 
-  request %p for device [%s] already tagged %d,
-  rq, rq-rq_disk ? rq-rq_disk-disk_name : ?, rq-tag);
+  %s: request %p for device [%s] already tagged %d,
+  __FUNCTION__, rq,
+  rq-rq_disk ? rq-rq_disk-disk_name : ?, rq-tag);
BUG();
}
 
@@ -1000,7 +1007,8 @@ void blk_queue_invalidate_tags(request_q
rq = list_entry_rq(tmp);
 
if (rq-tag == -1) {
-   printk(bad tag found on list\n);
+   printk(KERN_ERR
+  %s: bad tag found on list\n, __FUNCTION__);
list_del_init(rq-queuelist);
rq-flags = ~REQ_QUEUED;
} else

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH Linux 2.6.12-rc2 00/04] blk: generic tag support fixes

[Jens Axboe]

On Wed, Apr 20 2005, Tejun Heo wrote:
  Hello, Jens.
 
  These are fixes to generic tag support in the blk layer.  They all
 compile okay and I've proof read it, but as I don't have any HBA which
 uses generic tag support, I wasn't able to test directly.  However,
 all changes are fairly straight-forward.

All patches look good, thanks!

-- 
Jens Axboe

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

Its a T41 "without p" :) 

On Apr 8, 2005 9:09 PM, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
> On Apr 7, 2005 11:28 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > > except that neither returns from suspend-to-ram with video restored on
> > > the LCD. I believe I was able to get video restored on an external CRT
> > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> > > restore (can verify later today, if you'd like). I had dumped out the
> > > radeontool regs values before & after the sleep, in case they help.
> > > They are attached.
> >
> > Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well
> > except for a backtrace complaining about __might_sleep but otherwise ok).
> 
> A T41 or a T41p? I believe they have different graphics cards...
> 
> Thanks,
> Nish
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Nish Aravamudan]

On Apr 7, 2005 11:28 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > except that neither returns from suspend-to-ram with video restored on
> > the LCD. I believe I was able to get video restored on an external CRT
> > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> > restore (can verify later today, if you'd like). I had dumped out the
> > radeontool regs values before & after the sleep, in case they help.
> > They are attached.
> 
> Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well
> except for a backtrace complaining about __might_sleep but otherwise ok).

A T41 or a T41p? I believe they have different graphics cards...

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

Ok this time I did with radeontool and it works good :)) (2.6.12-rc2 on T41).

1. I have "radeontool regs" before susp to ram (presusp)
2. turn off LCD with "radeontool light off"
3. Suspend to RAM and wake up. (same backtrace)
4. LCD is back on (no problem)
5. regs in postsusp

only diff is 

< RADEON_CRTC_GEN_CNTL=03200600
---
> RADEON_CRTC_GEN_CNTL=03000600


presusp
---
RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=
RADEON_TV_DAC_CNTL=07680142
RADEON_DISP_OUTPUT_CNTL=1002
RADEON_CONFIG_MEMSIZE=0200
RADEON_AUX_SC_CNTL=
RADEON_CRTC_EXT_CNTL=8048
RADEON_CRTC_GEN_CNTL=03200600
RADEON_CRTC2_GEN_CNTL=0080
RADEON_DEVICE_ID=4c66
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=
RADEON_GPIO_MONIDB=0300
RADEON_GPIO_CRT2_DDC=0300
RADEON_GPIO_DVI_DDC=0013
RADEON_GPIO_VGA_DDC=0003
RADEON_LVDS_GEN_CNTL=003dffa1

postsusp
---
RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=
RADEON_TV_DAC_CNTL=07680142
RADEON_DISP_OUTPUT_CNTL=1002
RADEON_CONFIG_MEMSIZE=0200
RADEON_AUX_SC_CNTL=
RADEON_CRTC_EXT_CNTL=8048
RADEON_CRTC_GEN_CNTL=03000600
RADEON_CRTC2_GEN_CNTL=0080
RADEON_DEVICE_ID=4c66
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=
RADEON_GPIO_MONIDB=0300
RADEON_GPIO_CRT2_DDC=0300
RADEON_GPIO_DVI_DDC=0013
RADEON_GPIO_VGA_DDC=0003
RADEON_LVDS_GEN_CNTL=003dffa1


On Apr 8, 2005 12:09 PM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> Err... never mind... I was not doing any radeon control.
> 
> On Apr 8, 2005 11:58 AM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> > > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > > except that neither returns from suspend-to-ram with video restored on
> > > the LCD. I believe I was able to get video restored on an external CRT
> > > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> > > restore (can verify later today, if you'd like). I had dumped out the
> > > radeontool regs values before & after the sleep, in case they help.
> > > They are attached.
> >
> > Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well
> > except for a backtrace complaining about __might_sleep but otherwise ok).
> >
> > Apr  7 23:17:10 localhost kernel: Debug: sleeping function called from
> > invalid context at mm/slab.c:2090
> > Apr  7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1
> > Apr  7 23:17:10 localhost kernel:  [] __might_sleep+0xa3/0xc0
> > Apr  7 23:17:10 localhost kernel:  [] kmem_cache_alloc+0x50/0x60
> > Apr  7 23:17:10 localhost kernel:  [] acpi_pci_link_set+0x4a/0x1a2
> > Apr  7 23:17:10 localhost kernel:  [] irqrouter_resume+0x1c/0x24
> > Apr  7 23:17:10 localhost kernel:  [] sysdev_resume+0x66/0xc4
> > Apr  7 23:17:10 localhost kernel:  [] device_power_up+0x5/0xa
> > Apr  7 23:17:10 localhost kernel:  [] suspend_enter+0x36/0x60
> > Apr  7 23:17:10 localhost kernel:  [] suspend_prepare+0x63/0xb0
> > Apr  7 23:17:10 localhost kernel:  [] enter_state+0x5c/0x70
> > Apr  7 23:17:10 localhost kernel:  [] state_store+0xa9/0xbc
> > Apr  7 23:17:10 localhost kernel:  [] state_store+0x0/0xbc
> > Apr  7 23:17:10 localhost kernel:  [] subsys_attr_store+0x36/0x50
> > Apr  7 23:17:10 localhost kernel:  [] flush_write_buffer+0x2e/0x40
> > Apr  7 23:17:10 localhost kernel:  [] sysfs_write_file+0x4e/0x80
> > Apr  7 23:17:10 localhost kernel:  [] vfs_write+0x12e/0x130
> > Apr  7 23:17:10 localhost kernel:  [] sys_write+0x41/0x70
> > Apr  7 23:17:10 localhost kernel:  [] sysenter_past_esp+0x54/0x75
> >
> >
> > >
> > > I posted these problems in the "Call for help S3" thread, but no one 
> > > responded.
> > >
> > > Thanks,
> > > Nish
> > >
> > >
> > >
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

Err... never mind... I was not doing any radeon control. 

On Apr 8, 2005 11:58 AM, AsterixTheGaul <[EMAIL PROTECTED]> wrote:
> > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > except that neither returns from suspend-to-ram with video restored on
> > the LCD. I believe I was able to get video restored on an external CRT
> > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> > restore (can verify later today, if you'd like). I had dumped out the
> > radeontool regs values before & after the sleep, in case they help.
> > They are attached.
> 
> Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well
> except for a backtrace complaining about __might_sleep but otherwise ok).
> 
> Apr  7 23:17:10 localhost kernel: Debug: sleeping function called from
> invalid context at mm/slab.c:2090
> Apr  7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1
> Apr  7 23:17:10 localhost kernel:  [] __might_sleep+0xa3/0xc0
> Apr  7 23:17:10 localhost kernel:  [] kmem_cache_alloc+0x50/0x60
> Apr  7 23:17:10 localhost kernel:  [] acpi_pci_link_set+0x4a/0x1a2
> Apr  7 23:17:10 localhost kernel:  [] irqrouter_resume+0x1c/0x24
> Apr  7 23:17:10 localhost kernel:  [] sysdev_resume+0x66/0xc4
> Apr  7 23:17:10 localhost kernel:  [] device_power_up+0x5/0xa
> Apr  7 23:17:10 localhost kernel:  [] suspend_enter+0x36/0x60
> Apr  7 23:17:10 localhost kernel:  [] suspend_prepare+0x63/0xb0
> Apr  7 23:17:10 localhost kernel:  [] enter_state+0x5c/0x70
> Apr  7 23:17:10 localhost kernel:  [] state_store+0xa9/0xbc
> Apr  7 23:17:10 localhost kernel:  [] state_store+0x0/0xbc
> Apr  7 23:17:10 localhost kernel:  [] subsys_attr_store+0x36/0x50
> Apr  7 23:17:10 localhost kernel:  [] flush_write_buffer+0x2e/0x40
> Apr  7 23:17:10 localhost kernel:  [] sysfs_write_file+0x4e/0x80
> Apr  7 23:17:10 localhost kernel:  [] vfs_write+0x12e/0x130
> Apr  7 23:17:10 localhost kernel:  [] sys_write+0x41/0x70
> Apr  7 23:17:10 localhost kernel:  [] sysenter_past_esp+0x54/0x75
> 
> 
> >
> > I posted these problems in the "Call for help S3" thread, but no one 
> > responded.
> >
> > Thanks,
> > Nish
> >
> >
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

> FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> except that neither returns from suspend-to-ram with video restored on
> the LCD. I believe I was able to get video restored on an external CRT
> in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> restore (can verify later today, if you'd like). I had dumped out the
> radeontool regs values before & after the sleep, in case they help.
> They are attached.

Hmm... I have 2.6.12-rc2 on a T41 and "suspend to ram" works good (well
except for a backtrace complaining about __might_sleep but otherwise ok).

Apr  7 23:17:10 localhost kernel: Debug: sleeping function called from
invalid context at mm/slab.c:2090
Apr  7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1
Apr  7 23:17:10 localhost kernel:  [] __might_sleep+0xa3/0xc0
Apr  7 23:17:10 localhost kernel:  [] kmem_cache_alloc+0x50/0x60
Apr  7 23:17:10 localhost kernel:  [] acpi_pci_link_set+0x4a/0x1a2
Apr  7 23:17:10 localhost kernel:  [] irqrouter_resume+0x1c/0x24
Apr  7 23:17:10 localhost kernel:  [] sysdev_resume+0x66/0xc4
Apr  7 23:17:10 localhost kernel:  [] device_power_up+0x5/0xa
Apr  7 23:17:10 localhost kernel:  [] suspend_enter+0x36/0x60
Apr  7 23:17:10 localhost kernel:  [] suspend_prepare+0x63/0xb0
Apr  7 23:17:10 localhost kernel:  [] enter_state+0x5c/0x70
Apr  7 23:17:10 localhost kernel:  [] state_store+0xa9/0xbc
Apr  7 23:17:10 localhost kernel:  [] state_store+0x0/0xbc
Apr  7 23:17:10 localhost kernel:  [] subsys_attr_store+0x36/0x50
Apr  7 23:17:10 localhost kernel:  [] flush_write_buffer+0x2e/0x40
Apr  7 23:17:10 localhost kernel:  [] sysfs_write_file+0x4e/0x80
Apr  7 23:17:10 localhost kernel:  [] vfs_write+0x12e/0x130
Apr  7 23:17:10 localhost kernel:  [] sys_write+0x41/0x70
Apr  7 23:17:10 localhost kernel:  [] sysenter_past_esp+0x54/0x75


> 
> I posted these problems in the "Call for help S3" thread, but no one 
> responded.
> 
> Thanks,
> Nish
> 
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

 FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
 except that neither returns from suspend-to-ram with video restored on
 the LCD. I believe I was able to get video restored on an external CRT
 in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
 restore (can verify later today, if you'd like). I had dumped out the
 radeontool regs values before  after the sleep, in case they help.
 They are attached.

Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well
except for a backtrace complaining about __might_sleep but otherwise ok).

Apr  7 23:17:10 localhost kernel: Debug: sleeping function called from
invalid context at mm/slab.c:2090
Apr  7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1
Apr  7 23:17:10 localhost kernel:  [c011d9e3] __might_sleep+0xa3/0xc0
Apr  7 23:17:10 localhost kernel:  [c015beb0] kmem_cache_alloc+0x50/0x60
Apr  7 23:17:10 localhost kernel:  [c0269750] acpi_pci_link_set+0x4a/0x1a2
Apr  7 23:17:10 localhost kernel:  [c0269bc9] irqrouter_resume+0x1c/0x24
Apr  7 23:17:10 localhost kernel:  [c02b70f6] sysdev_resume+0x66/0xc4
Apr  7 23:17:10 localhost kernel:  [c02bbcc5] device_power_up+0x5/0xa
Apr  7 23:17:10 localhost kernel:  [c014a426] suspend_enter+0x36/0x60
Apr  7 23:17:10 localhost kernel:  [c014a3a3] suspend_prepare+0x63/0xb0
Apr  7 23:17:10 localhost kernel:  [c014a4ec] enter_state+0x5c/0x70
Apr  7 23:17:10 localhost kernel:  [c014a639] state_store+0xa9/0xbc
Apr  7 23:17:10 localhost kernel:  [c014a590] state_store+0x0/0xbc
Apr  7 23:17:10 localhost kernel:  [c01d27c6] subsys_attr_store+0x36/0x50
Apr  7 23:17:10 localhost kernel:  [c01d2a6e] flush_write_buffer+0x2e/0x40
Apr  7 23:17:10 localhost kernel:  [c01d2ace] sysfs_write_file+0x4e/0x80
Apr  7 23:17:10 localhost kernel:  [c017bdee] vfs_write+0x12e/0x130
Apr  7 23:17:10 localhost kernel:  [c017bea1] sys_write+0x41/0x70
Apr  7 23:17:10 localhost kernel:  [c01039ff] sysenter_past_esp+0x54/0x75


 
 I posted these problems in the Call for help S3 thread, but no one 
 responded.
 
 Thanks,
 Nish
 
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

Err... never mind... I was not doing any radeon control. 

On Apr 8, 2005 11:58 AM, AsterixTheGaul [EMAIL PROTECTED] wrote:
  FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
  except that neither returns from suspend-to-ram with video restored on
  the LCD. I believe I was able to get video restored on an external CRT
  in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
  restore (can verify later today, if you'd like). I had dumped out the
  radeontool regs values before  after the sleep, in case they help.
  They are attached.
 
 Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well
 except for a backtrace complaining about __might_sleep but otherwise ok).
 
 Apr  7 23:17:10 localhost kernel: Debug: sleeping function called from
 invalid context at mm/slab.c:2090
 Apr  7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1
 Apr  7 23:17:10 localhost kernel:  [c011d9e3] __might_sleep+0xa3/0xc0
 Apr  7 23:17:10 localhost kernel:  [c015beb0] kmem_cache_alloc+0x50/0x60
 Apr  7 23:17:10 localhost kernel:  [c0269750] acpi_pci_link_set+0x4a/0x1a2
 Apr  7 23:17:10 localhost kernel:  [c0269bc9] irqrouter_resume+0x1c/0x24
 Apr  7 23:17:10 localhost kernel:  [c02b70f6] sysdev_resume+0x66/0xc4
 Apr  7 23:17:10 localhost kernel:  [c02bbcc5] device_power_up+0x5/0xa
 Apr  7 23:17:10 localhost kernel:  [c014a426] suspend_enter+0x36/0x60
 Apr  7 23:17:10 localhost kernel:  [c014a3a3] suspend_prepare+0x63/0xb0
 Apr  7 23:17:10 localhost kernel:  [c014a4ec] enter_state+0x5c/0x70
 Apr  7 23:17:10 localhost kernel:  [c014a639] state_store+0xa9/0xbc
 Apr  7 23:17:10 localhost kernel:  [c014a590] state_store+0x0/0xbc
 Apr  7 23:17:10 localhost kernel:  [c01d27c6] subsys_attr_store+0x36/0x50
 Apr  7 23:17:10 localhost kernel:  [c01d2a6e] flush_write_buffer+0x2e/0x40
 Apr  7 23:17:10 localhost kernel:  [c01d2ace] sysfs_write_file+0x4e/0x80
 Apr  7 23:17:10 localhost kernel:  [c017bdee] vfs_write+0x12e/0x130
 Apr  7 23:17:10 localhost kernel:  [c017bea1] sys_write+0x41/0x70
 Apr  7 23:17:10 localhost kernel:  [c01039ff] sysenter_past_esp+0x54/0x75
 
 
 
  I posted these problems in the Call for help S3 thread, but no one 
  responded.
 
  Thanks,
  Nish
 
 
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

Ok this time I did with radeontool and it works good :)) (2.6.12-rc2 on T41).

1. I have radeontool regs before susp to ram (presusp)
2. turn off LCD with radeontool light off
3. Suspend to RAM and wake up. (same backtrace)
4. LCD is back on (no problem)
5. regs in postsusp

only diff is 

 RADEON_CRTC_GEN_CNTL=03200600
---
 RADEON_CRTC_GEN_CNTL=03000600


presusp
---
RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=
RADEON_TV_DAC_CNTL=07680142
RADEON_DISP_OUTPUT_CNTL=1002
RADEON_CONFIG_MEMSIZE=0200
RADEON_AUX_SC_CNTL=
RADEON_CRTC_EXT_CNTL=8048
RADEON_CRTC_GEN_CNTL=03200600
RADEON_CRTC2_GEN_CNTL=0080
RADEON_DEVICE_ID=4c66
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=
RADEON_GPIO_MONIDB=0300
RADEON_GPIO_CRT2_DDC=0300
RADEON_GPIO_DVI_DDC=0013
RADEON_GPIO_VGA_DDC=0003
RADEON_LVDS_GEN_CNTL=003dffa1

postsusp
---
RADEON_DAC_CNTL=ff002102
RADEON_DAC_CNTL2=
RADEON_TV_DAC_CNTL=07680142
RADEON_DISP_OUTPUT_CNTL=1002
RADEON_CONFIG_MEMSIZE=0200
RADEON_AUX_SC_CNTL=
RADEON_CRTC_EXT_CNTL=8048
RADEON_CRTC_GEN_CNTL=03000600
RADEON_CRTC2_GEN_CNTL=0080
RADEON_DEVICE_ID=4c66
RADEON_DISP_MISC_CNTL=5b300600
RADEON_GPIO_MONID=
RADEON_GPIO_MONIDB=0300
RADEON_GPIO_CRT2_DDC=0300
RADEON_GPIO_DVI_DDC=0013
RADEON_GPIO_VGA_DDC=0003
RADEON_LVDS_GEN_CNTL=003dffa1


On Apr 8, 2005 12:09 PM, AsterixTheGaul [EMAIL PROTECTED] wrote:
 Err... never mind... I was not doing any radeon control.
 
 On Apr 8, 2005 11:58 AM, AsterixTheGaul [EMAIL PROTECTED] wrote:
   FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
   except that neither returns from suspend-to-ram with video restored on
   the LCD. I believe I was able to get video restored on an external CRT
   in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
   restore (can verify later today, if you'd like). I had dumped out the
   radeontool regs values before  after the sleep, in case they help.
   They are attached.
 
  Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well
  except for a backtrace complaining about __might_sleep but otherwise ok).
 
  Apr  7 23:17:10 localhost kernel: Debug: sleeping function called from
  invalid context at mm/slab.c:2090
  Apr  7 23:17:10 localhost kernel: in_atomic():0, irqs_disabled():1
  Apr  7 23:17:10 localhost kernel:  [c011d9e3] __might_sleep+0xa3/0xc0
  Apr  7 23:17:10 localhost kernel:  [c015beb0] kmem_cache_alloc+0x50/0x60
  Apr  7 23:17:10 localhost kernel:  [c0269750] acpi_pci_link_set+0x4a/0x1a2
  Apr  7 23:17:10 localhost kernel:  [c0269bc9] irqrouter_resume+0x1c/0x24
  Apr  7 23:17:10 localhost kernel:  [c02b70f6] sysdev_resume+0x66/0xc4
  Apr  7 23:17:10 localhost kernel:  [c02bbcc5] device_power_up+0x5/0xa
  Apr  7 23:17:10 localhost kernel:  [c014a426] suspend_enter+0x36/0x60
  Apr  7 23:17:10 localhost kernel:  [c014a3a3] suspend_prepare+0x63/0xb0
  Apr  7 23:17:10 localhost kernel:  [c014a4ec] enter_state+0x5c/0x70
  Apr  7 23:17:10 localhost kernel:  [c014a639] state_store+0xa9/0xbc
  Apr  7 23:17:10 localhost kernel:  [c014a590] state_store+0x0/0xbc
  Apr  7 23:17:10 localhost kernel:  [c01d27c6] subsys_attr_store+0x36/0x50
  Apr  7 23:17:10 localhost kernel:  [c01d2a6e] flush_write_buffer+0x2e/0x40
  Apr  7 23:17:10 localhost kernel:  [c01d2ace] sysfs_write_file+0x4e/0x80
  Apr  7 23:17:10 localhost kernel:  [c017bdee] vfs_write+0x12e/0x130
  Apr  7 23:17:10 localhost kernel:  [c017bea1] sys_write+0x41/0x70
  Apr  7 23:17:10 localhost kernel:  [c01039ff] sysenter_past_esp+0x54/0x75
 
 
  
   I posted these problems in the Call for help S3 thread, but no one 
   responded.
  
   Thanks,
   Nish
  
  
  
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Nish Aravamudan]

On Apr 7, 2005 11:28 PM, AsterixTheGaul [EMAIL PROTECTED] wrote:
  FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
  except that neither returns from suspend-to-ram with video restored on
  the LCD. I believe I was able to get video restored on an external CRT
  in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
  restore (can verify later today, if you'd like). I had dumped out the
  radeontool regs values before  after the sleep, in case they help.
  They are attached.
 
 Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well
 except for a backtrace complaining about __might_sleep but otherwise ok).

A T41 or a T41p? I believe they have different graphics cards...

Thanks,
Nish
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[AsterixTheGaul]

Its a T41 without p :) 

On Apr 8, 2005 9:09 PM, Nish Aravamudan [EMAIL PROTECTED] wrote:
 On Apr 7, 2005 11:28 PM, AsterixTheGaul [EMAIL PROTECTED] wrote:
   FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
   except that neither returns from suspend-to-ram with video restored on
   the LCD. I believe I was able to get video restored on an external CRT
   in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
   restore (can verify later today, if you'd like). I had dumped out the
   radeontool regs values before  after the sleep, in case they help.
   They are attached.
 
  Hmm... I have 2.6.12-rc2 on a T41 and suspend to ram works good (well
  except for a backtrace complaining about __might_sleep but otherwise ok).
 
 A T41 or a T41p? I believe they have different graphics cards...
 
 Thanks,
 Nish

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Nish Aravamudan]

On Apr 7, 2005 3:45 PM, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
> > On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> > > Benjamin Herrenschmidt wrote:
> > > > > 1. When resuming from S3 suspend and having switched off the backlight
> > > > > with radeontool the backlight isn't switched back on any more.
> > > >
> > > > I'm not sure what's up here, it's a nasty issue with backlight. Can
> > > > radeontool bring it back ?
> > >
> > > Before suspending I power down the backlight with "radeontool light off"
> > > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
> > > backlight remains switched off and if I switch it on with radeontool it
> > > becomes lighter, but there's still no text from the fbcon, just the blank
> > > screen.
> >
> > FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> > except that neither returns from suspend-to-ram with video restored on
> > the LCD. I believe I was able to get video restored on an external CRT
> > in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> > restore (can verify later today, if you'd like). I had dumped out the
> > radeontool regs values before & after the sleep, in case they help.
> > They are attached.
> >
> > I posted these problems in the "Call for help S3" thread, but no one 
> > responded.
> 
> I would say the different value in LVDS_GEN_CNTL explains it. I'll see
> if I can force radeonfb to save/restore this.

Great! That seemed odd to me, as well. I'll be more than happy to try
any patches (I'll take a look at the code tonight myself).

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Benjamin Herrenschmidt]

On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
> On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> > Benjamin Herrenschmidt wrote:
> > > > 1. When resuming from S3 suspend and having switched off the backlight
> > > > with radeontool the backlight isn't switched back on any more.
> > >
> > > I'm not sure what's up here, it's a nasty issue with backlight. Can
> > > radeontool bring it back ?
> > 
> > Before suspending I power down the backlight with "radeontool light off"
> > and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
> > backlight remains switched off and if I switch it on with radeontool it
> > becomes lighter, but there's still no text from the fbcon, just the blank
> > screen.
> 
> FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
> except that neither returns from suspend-to-ram with video restored on
> the LCD. I believe I was able to get video restored on an external CRT
> in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
> restore (can verify later today, if you'd like). I had dumped out the
> radeontool regs values before & after the sleep, in case they help.
> They are attached.
> 
> I posted these problems in the "Call for help S3" thread, but no one 
> responded.

I would say the different value in LVDS_GEN_CNTL explains it. I'll see
if I can force radeonfb to save/restore this.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Benjamin Herrenschmidt]

On Thu, 2005-04-07 at 19:50 +0200, Moritz Muehlenhoff wrote:
> Benjamin Herrenschmidt wrote:
> > > 1. When resuming from S3 suspend and having switched off the backlight
> > > with radeontool the backlight isn't switched back on any more.
> > 
> > I'm not sure what's up here, it's a nasty issue with backlight. Can
> > radeontool bring it back ?
> 
> Before suspending I power down the backlight with "radeontool light off"
> and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
> backlight remains switched off and if I switch it on with radeontool it
> becomes lighter, but there's still no text from the fbcon, just the blank
> screen.
> 
> > > 2. I'm using fbcon as my primary work environment, but tty switching has
> > > become _very_ sloppy, it's at least a second now, while with 2.6.11 it
> > > was as fast as a few ms. Is this caused by the "proper PLL accesses"?
> > 
> > Yes. Unfortunately. It's surprised it is that slow though, there
> > shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with
> > 5ms pause for each, that should still be very reasonable. It looks like
> > we are doing a lot more accesses which I don't completely understand.
> 
> Can you tell me which function you have in mind, so that I can insert
> some printks to see how often it's called?

radeon_pll_errata_after_data() calls radeon_msleep() (it's in
radeonfb.h)

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Nish Aravamudan]

On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
> > > 1. When resuming from S3 suspend and having switched off the backlight
> > > with radeontool the backlight isn't switched back on any more.
> >
> > I'm not sure what's up here, it's a nasty issue with backlight. Can
> > radeontool bring it back ?
> 
> Before suspending I power down the backlight with "radeontool light off"
> and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
> backlight remains switched off and if I switch it on with radeontool it
> becomes lighter, but there's still no text from the fbcon, just the blank
> screen.

FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
except that neither returns from suspend-to-ram with video restored on
the LCD. I believe I was able to get video restored on an external CRT
in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
restore (can verify later today, if you'd like). I had dumped out the
radeontool regs values before & after the sleep, in case they help.
They are attached.

I posted these problems in the "Call for help S3" thread, but no one responded.

Thanks,
Nish


radeontool_pre
Description: Binary data


radeontool_post
Description: Binary data

Re: Linux 2.6.12-rc2

[Moritz Muehlenhoff]

Benjamin Herrenschmidt wrote:
> > 1. When resuming from S3 suspend and having switched off the backlight
> > with radeontool the backlight isn't switched back on any more.
> 
> I'm not sure what's up here, it's a nasty issue with backlight. Can
> radeontool bring it back ?

Before suspending I power down the backlight with "radeontool light off"
and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
backlight remains switched off and if I switch it on with radeontool it
becomes lighter, but there's still no text from the fbcon, just the blank
screen.

> > 2. I'm using fbcon as my primary work environment, but tty switching has
> > become _very_ sloppy, it's at least a second now, while with 2.6.11 it
> > was as fast as a few ms. Is this caused by the "proper PLL accesses"?
> 
> Yes. Unfortunately. It's surprised it is that slow though, there
> shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with
> 5ms pause for each, that should still be very reasonable. It looks like
> we are doing a lot more accesses which I don't completely understand.

Can you tell me which function you have in mind, so that I can insert
some printks to see how often it's called?

Cheers,
Moritz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Moritz Muehlenhoff]

Benjamin Herrenschmidt wrote:
  1. When resuming from S3 suspend and having switched off the backlight
  with radeontool the backlight isn't switched back on any more.
 
 I'm not sure what's up here, it's a nasty issue with backlight. Can
 radeontool bring it back ?

Before suspending I power down the backlight with radeontool light off
and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
backlight remains switched off and if I switch it on with radeontool it
becomes lighter, but there's still no text from the fbcon, just the blank
screen.

  2. I'm using fbcon as my primary work environment, but tty switching has
  become _very_ sloppy, it's at least a second now, while with 2.6.11 it
  was as fast as a few ms. Is this caused by the proper PLL accesses?
 
 Yes. Unfortunately. It's surprised it is that slow though, there
 shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with
 5ms pause for each, that should still be very reasonable. It looks like
 we are doing a lot more accesses which I don't completely understand.

Can you tell me which function you have in mind, so that I can insert
some printks to see how often it's called?

Cheers,
Moritz
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Nish Aravamudan]

On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote:
 Benjamin Herrenschmidt wrote:
   1. When resuming from S3 suspend and having switched off the backlight
   with radeontool the backlight isn't switched back on any more.
 
  I'm not sure what's up here, it's a nasty issue with backlight. Can
  radeontool bring it back ?
 
 Before suspending I power down the backlight with radeontool light off
 and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
 backlight remains switched off and if I switch it on with radeontool it
 becomes lighter, but there's still no text from the fbcon, just the blank
 screen.

FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
except that neither returns from suspend-to-ram with video restored on
the LCD. I believe I was able to get video restored on an external CRT
in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
restore (can verify later today, if you'd like). I had dumped out the
radeontool regs values before  after the sleep, in case they help.
They are attached.

I posted these problems in the Call for help S3 thread, but no one responded.

Thanks,
Nish


radeontool_pre
Description: Binary data


radeontool_post
Description: Binary data

Re: Linux 2.6.12-rc2

[Benjamin Herrenschmidt]

On Thu, 2005-04-07 at 19:50 +0200, Moritz Muehlenhoff wrote:
 Benjamin Herrenschmidt wrote:
   1. When resuming from S3 suspend and having switched off the backlight
   with radeontool the backlight isn't switched back on any more.
  
  I'm not sure what's up here, it's a nasty issue with backlight. Can
  radeontool bring it back ?
 
 Before suspending I power down the backlight with radeontool light off
 and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
 backlight remains switched off and if I switch it on with radeontool it
 becomes lighter, but there's still no text from the fbcon, just the blank
 screen.
 
   2. I'm using fbcon as my primary work environment, but tty switching has
   become _very_ sloppy, it's at least a second now, while with 2.6.11 it
   was as fast as a few ms. Is this caused by the proper PLL accesses?
  
  Yes. Unfortunately. It's surprised it is that slow though, there
  shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with
  5ms pause for each, that should still be very reasonable. It looks like
  we are doing a lot more accesses which I don't completely understand.
 
 Can you tell me which function you have in mind, so that I can insert
 some printks to see how often it's called?

radeon_pll_errata_after_data() calls radeon_msleep() (it's in
radeonfb.h)

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Benjamin Herrenschmidt]

On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
 On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote:
  Benjamin Herrenschmidt wrote:
1. When resuming from S3 suspend and having switched off the backlight
with radeontool the backlight isn't switched back on any more.
  
   I'm not sure what's up here, it's a nasty issue with backlight. Can
   radeontool bring it back ?
  
  Before suspending I power down the backlight with radeontool light off
  and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
  backlight remains switched off and if I switch it on with radeontool it
  becomes lighter, but there's still no text from the fbcon, just the blank
  screen.
 
 FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
 except that neither returns from suspend-to-ram with video restored on
 the LCD. I believe I was able to get video restored on an external CRT
 in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
 restore (can verify later today, if you'd like). I had dumped out the
 radeontool regs values before  after the sleep, in case they help.
 They are attached.
 
 I posted these problems in the Call for help S3 thread, but no one 
 responded.

I would say the different value in LVDS_GEN_CNTL explains it. I'll see
if I can force radeonfb to save/restore this.

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Nish Aravamudan]

On Apr 7, 2005 3:45 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
 On Thu, 2005-04-07 at 11:54 -0700, Nish Aravamudan wrote:
  On Apr 7, 2005 10:50 AM, Moritz Muehlenhoff [EMAIL PROTECTED] wrote:
   Benjamin Herrenschmidt wrote:
 1. When resuming from S3 suspend and having switched off the backlight
 with radeontool the backlight isn't switched back on any more.
   
I'm not sure what's up here, it's a nasty issue with backlight. Can
radeontool bring it back ?
  
   Before suspending I power down the backlight with radeontool light off
   and with 2.6.11 the display is properly restored. With 2.6.12rc2 the
   backlight remains switched off and if I switch it on with radeontool it
   becomes lighter, but there's still no text from the fbcon, just the blank
   screen.
 
  FWIW, I have the same problem on a T41p with 2.6.11 and 2.6.12-rc2,
  except that neither returns from suspend-to-ram with video restored on
  the LCD. I believe I was able to get video restored on an external CRT
  in either 2.6.12-rc2 or 2.6.12-rc2-mm1, but the LCD still didn't
  restore (can verify later today, if you'd like). I had dumped out the
  radeontool regs values before  after the sleep, in case they help.
  They are attached.
 
  I posted these problems in the Call for help S3 thread, but no one 
  responded.
 
 I would say the different value in LVDS_GEN_CNTL explains it. I'll see
 if I can force radeonfb to save/restore this.

Great! That seemed odd to me, as well. I'll be more than happy to try
any patches (I'll take a look at the code tonight myself).

Thanks,
Nish
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Dave Jones]

On Wed, Apr 06, 2005 at 05:20:52PM -0600, Bob Gill wrote:
 > OK.  So far so good.  I can get 2.6.12-rc2 to run fine if:
 > 1. I do not in any way attempt to *ahem* overclock the box.
 > --if I do, I get really ugly race errors flying around from just about
 > everywhere (pick a device at random, have it trip, and the scheduler
 > tripping right behind it).

"Doctor it hurts when I do this.."

 > 2. I do not attempt in any way to run any sort of Nvidia (non-GPL)
 > driver. 

Totally unsurprising. They'll need serious brain surgery
to work with the multi-gart support. I'm amazed they even
compiled for you.

Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Bob Gill]

OK.  So far so good.  I can get 2.6.12-rc2 to run fine if:
1. I do not in any way attempt to *ahem* overclock the box.
--if I do, I get really ugly race errors flying around from just about
everywhere (pick a device at random, have it trip, and the scheduler
tripping right behind it).
2. I do not attempt in any way to run any sort of Nvidia (non-GPL)
driver.  It fights with SBP2 (in a lot of different ways, first the
drivers want to kill off Firewire drives (one detected, the other not,
then on next boot, the reverse...), and also, when using GLX apps (and
trying to write to an SBP2 connected device, they clash (and fight and
the kernel doesn't die but gets bogged in errors...)
and with the notes above, as I say, so far, so good.  I am
attempting to hammer away at every device I have on the box (scanner,
printer, video (only GPL Nvidia), audio, cd, dvd, tv tuner etc.) so far,
so good.
Bob
-- 
Bob Gill <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Benjamin Herrenschmidt]

On Wed, 2005-04-06 at 19:14 +0200, Moritz Muehlenhoff wrote:
> Linus Torvalds wrote:
> > Benjamin Herrenschmidt:
> >   o radeonfb: Implement proper workarounds for PLL accesses
> >   o radeonfb: DDC i2c fix
> >   o radeonfb: Fix mode setting on CRT monitors
> >   o radeonfb: Preserve TMDS setting
> 
> One of these patches introduced two regressions on my Thinkpad X31 with
> "ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])":
> 
> 1. When resuming from S3 suspend and having switched off the backlight
> with radeontool the backlight isn't switched back on any more.

I'm not sure what's up here, it's a nasty issue with backlight. Can
radeontool bring it back ?

> 2. I'm using fbcon as my primary work environment, but tty switching has
> become _very_ sloppy, it's at least a second now, while with 2.6.11 it
> was as fast as a few ms. Is this caused by the "proper PLL accesses"?

Yes. Unfortunately. It's surprised it is that slow though, there
shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with
5ms pause for each, that should still be very reasonable. It looks like
we are doing a lot more accesses which I don't completely understand.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Moritz Muehlenhoff]

Linus Torvalds wrote:
> Benjamin Herrenschmidt:
>   o radeonfb: Implement proper workarounds for PLL accesses
>   o radeonfb: DDC i2c fix
>   o radeonfb: Fix mode setting on CRT monitors
>   o radeonfb: Preserve TMDS setting

One of these patches introduced two regressions on my Thinkpad X31 with
"ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])":

1. When resuming from S3 suspend and having switched off the backlight
with radeontool the backlight isn't switched back on any more.

2. I'm using fbcon as my primary work environment, but tty switching has
become _very_ sloppy, it's at least a second now, while with 2.6.11 it
was as fast as a few ms. Is this caused by the "proper PLL accesses"?

Cheers,
Moritz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Moritz Muehlenhoff]

Linus Torvalds wrote:
 Benjamin Herrenschmidt:
   o radeonfb: Implement proper workarounds for PLL accesses
   o radeonfb: DDC i2c fix
   o radeonfb: Fix mode setting on CRT monitors
   o radeonfb: Preserve TMDS setting

One of these patches introduced two regressions on my Thinkpad X31 with
ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]):

1. When resuming from S3 suspend and having switched off the backlight
with radeontool the backlight isn't switched back on any more.

2. I'm using fbcon as my primary work environment, but tty switching has
become _very_ sloppy, it's at least a second now, while with 2.6.11 it
was as fast as a few ms. Is this caused by the proper PLL accesses?

Cheers,
Moritz
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Benjamin Herrenschmidt]

On Wed, 2005-04-06 at 19:14 +0200, Moritz Muehlenhoff wrote:
 Linus Torvalds wrote:
  Benjamin Herrenschmidt:
o radeonfb: Implement proper workarounds for PLL accesses
o radeonfb: DDC i2c fix
o radeonfb: Fix mode setting on CRT monitors
o radeonfb: Preserve TMDS setting
 
 One of these patches introduced two regressions on my Thinkpad X31 with
 ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]):
 
 1. When resuming from S3 suspend and having switched off the backlight
 with radeontool the backlight isn't switched back on any more.

I'm not sure what's up here, it's a nasty issue with backlight. Can
radeontool bring it back ?

 2. I'm using fbcon as my primary work environment, but tty switching has
 become _very_ sloppy, it's at least a second now, while with 2.6.11 it
 was as fast as a few ms. Is this caused by the proper PLL accesses?

Yes. Unfortunately. It's surprised it is that slow though, there
shouldn't be more than 5 or 6 PLL accesses on a normal mode switch, with
5ms pause for each, that should still be very reasonable. It looks like
we are doing a lot more accesses which I don't completely understand.

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Bob Gill]

OK.  So far so good.  I can get 2.6.12-rc2 to run fine if:
1. I do not in any way attempt to *ahem* overclock the box.
--if I do, I get really ugly race errors flying around from just about
everywhere (pick a device at random, have it trip, and the scheduler
tripping right behind it).
2. I do not attempt in any way to run any sort of Nvidia (non-GPL)
driver.  It fights with SBP2 (in a lot of different ways, first the
drivers want to kill off Firewire drives (one detected, the other not,
then on next boot, the reverse...), and also, when using GLX apps (and
trying to write to an SBP2 connected device, they clash (and fight and
the kernel doesn't die but gets bogged in errors...)
and with the notes above, as I say, so far, so good.  I am
attempting to hammer away at every device I have on the box (scanner,
printer, video (only GPL Nvidia), audio, cd, dvd, tv tuner etc.) so far,
so good.
Bob
-- 
Bob Gill [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Dave Jones]

On Wed, Apr 06, 2005 at 05:20:52PM -0600, Bob Gill wrote:
  OK.  So far so good.  I can get 2.6.12-rc2 to run fine if:
  1. I do not in any way attempt to *ahem* overclock the box.
  --if I do, I get really ugly race errors flying around from just about
  everywhere (pick a device at random, have it trip, and the scheduler
  tripping right behind it).

Doctor it hurts when I do this..

  2. I do not attempt in any way to run any sort of Nvidia (non-GPL)
  driver. 

Totally unsurprising. They'll need serious brain surgery
to work with the multi-gart support. I'm amazed they even
compiled for you.

Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

JFS supports larger page size in linux-2.6.12-rc2-mm1

[Dave Kleikamp]

I have finally added support for a page size greater than 4K for jfs and
the code is now in 2.6.12-rc2-mm1.  This will allow jfs to work on
architectures with larger page sizes: alpha, sparc, all configs of ia64,
etc.

I completely replaced the address-space operations for jfs's metadata,
and I expect to see some performance improvements on workloads that
stress metadata operations.

I welcome anybody interested to stress jfs on 2.6.12-rc2-mm1 and give me
any feedback, bug reports, flames, etc.

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Hubert Tonneau]

2.6.12-rc2 still does not boot properly on my box.

Hubert Tonneau wrote:
>
> When switching from 2.6.11 to 2.6.12-rc1,
> I get a 'cannot open root device' fatal error at end of kernel boot process.
> Root device is 'hda1'.
> 
> Hardware content of the box:
> 
> 8086  Intel Corporation   334082855PM 0   
> Host-Hub Interface Bridge
> 8086  Intel Corporation   334182855PM 0   AGP 
> Bridge
> 8086  Intel Corporation   24C282801DB/DBL/DBM B   
> USB UHCI Controller #1
> 8086  Intel Corporation   24C482801DB/DBL/DBM B   
> USB UHCI Controller #2
> 8086  Intel Corporation   24C782801DB/DBL/DBM B   
> USB UHCI Controller #3
> 8086  Intel Corporation   24CD82801DB/DBL/DBM B   
> USB EHCI Controller
> 8086  Intel Corporation   244882801BAM/CAM/DBM0   
> Hub Interface to PCI Bridge
> 8086  Intel Corporation   24CC82801DBM0   LPC 
> Interface Bridge
> 8086  Intel Corporation   24CA82801DBMB   IDE 
> Controller (UltraATA/100)
> 8086  Intel Corporation   24C582801DB/DBL/DBM B   
> AC97 Audio Controller
> 8086  Intel Corporation   24C682801DB/DBM B   AC97 
> Modem Controller
> 10DE  NVIDIA Corporation  0324NV31B   NVIDIA NV31GL
> 14E4  Broadcom Corporation165DBCM5705MB   
> Broadcom NetXtreme Gigabit Ethernet
> 104C  Texas Instruments   AC477510/4510   B   Cardbus
> 104C  Texas Instruments   AC4AB   
> 104C  Texas Instruments   802BB   
> 104C  Texas Instruments   82044610, 4515, 4610FM  0   
> TI UltraMedia Firmware Loader Device
> 8086  Intel Corporation   4220MPCI3B  B   Intel 2200 mPCI 
> 3B - RoW
> 
> 2.6.11 kernel report:
> 
> <4>Linux version 2.6.11 ([EMAIL PROTECTED]) (gcc version 3.3 (Debian)) #1 Sun 
> Mar 6 12:00:57 CET 2005
> <6>BIOS-provided physical RAM map:
> <4> BIOS-e820:  - 0009f000 (usable)
> <4> BIOS-e820: 0009f000 - 000a (reserved)
> <4> BIOS-e820: 0010 - 3ffae000 (usable)
> <4> BIOS-e820: 3ffae000 - 4000 (reserved)
> <4> BIOS-e820: feda - fee0 (reserved)
> <4> BIOS-e820: ffb0 - 0001 (reserved)
> <4>Warning only 896MB will be used.
> <4>Use a HIGHMEM enabled kernel.
> <5>896MB LOWMEM available.
> <7>On node 0 totalpages: 229376
> <7>  DMA zone: 4096 pages, LIFO batch:1
> <7>  Normal zone: 225280 pages, LIFO batch:16
> <7>  HighMem zone: 0 pages, LIFO batch:1
> <6>DMI 2.3 present.
> <7>ACPI: RSDP (v000 DELL  ) @ 0x000fdf00
> <7>ACPI: RSDT (v001 DELLCPi R   0x27d40903 ASL  0x0061) @ 0x3fff
> <7>ACPI: FADT (v001 DELLCPi R   0x27d40903 ASL  0x0061) @ 0x3fff0400
> <7>ACPI: ASF! (v016 DELLCPi R   0x27d40903 ASL  0x0061) @ 0x3fff0800
> <7>ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x
> <4>Allocating PCI resources starting at 4000 (gap: 4000:beda)
> <4>Built 1 zonelists
> <4>Kernel command line: BOOT_IMAGE=recover ro root=301
> <4>Local APIC disabled by BIOS -- you can enable it with "lapic"
> <7>mapped APIC to d000 (01703000)
> <6>Initializing CPU#0
> <4>PID hash table entries: 4096 (order: 12, 65536 bytes)
> <4>Detected 1998.546 MHz processor.
> <6>Using tsc for high-res timesource
> <4>Console: colour VGA+ 80x25
> <4>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> <4>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> <6>Memory: 906620k/917504k available (1598k kernel code, 10432k reserved, 
> 518k data, 140k init, 0k highmem)
> <4>Checking if this processor honours the WP bit even in supervisor mode... 
> Ok.
> <7>Calibrating delay loop... 3956.73 BogoMIPS (lpj=1978368)
> <4>Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> <7>CPU: After generic identify, caps: afe9f9bf    
> 0180  
> <7>CPU: After vendor identify, caps: afe9f9bf    
> 0180  
> <6>CPU: L1 I cache: 32K, L1 D cache: 32K
> <6>CPU: L2 cache: 2048K
> <7>CPU: After all inits, caps: afe9f9bf   0040 0180 
>  
> <6>Intel machine check architecture supported.
> <6>Intel machine check reporting enabled on CPU#0.
> <4>CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 06
> <6>Enabling fast FPU save and restore... done.
> <6>Enabling unmasked SIMD FPU exception support... done.
> <6>Checking 'hlt' instruction... OK.
> <4>ACPI: setting ELCR to 0200 (from 0800)
> <6>NET: Registered protocol family 16
> <6>PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=2
> <6>PCI: Using 

Re: Linux 2.6.12-rc2

[Andrew Morton]

Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > Oleg Nesterov:
> >   o x86: fix ESP corruption CPU bug (take 2)
> 
> I don't even absolutely understand what this patch does :)
> I only send a very minor fix on top of Stas Sergeev's patch.
> 

I'm suspecting a problem in the reporting scripts.  The patch had:


From: Stas Sergeev <[EMAIL PROTECTED]>

Attached patch works around the corruption of the high word of the ESP
register, which is the official bug of x86 CPUs.  The bug triggers only
when the one is using the 16bit stack segment, and is described here:

http://www.intel.com/design/intarch/specupdt/27287402.PDF

From: Oleg Nesterov <[EMAIL PROTECTED]>

  I think that Stas tries to steal 1024 bytes from kernel's memory.

Acked-by: Linus Torvalds <[EMAIL PROTECTED]>
Acked-by: Petr Vandrovec <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Stas Sergeev <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>



It looks like the final From: was used...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Oleg Nesterov]

> Oleg Nesterov:
>   o x86: fix ESP corruption CPU bug (take 2)

I don't even absolutely understand what this patch does :)
I only send a very minor fix on top of Stas Sergeev's patch.

Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

JFS supports larger page size in linux-2.6.12-rc2-mm1

[Dave Kleikamp]

I have finally added support for a page size greater than 4K for jfs and
the code is now in 2.6.12-rc2-mm1.  This will allow jfs to work on
architectures with larger page sizes: alpha, sparc, all configs of ia64,
etc.

I completely replaced the address-space operations for jfs's metadata,
and I expect to see some performance improvements on workloads that
stress metadata operations.

I welcome anybody interested to stress jfs on 2.6.12-rc2-mm1 and give me
any feedback, bug reports, flames, etc.

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Oleg Nesterov]

 Oleg Nesterov:
   o x86: fix ESP corruption CPU bug (take 2)

I don't even absolutely understand what this patch does :)
I only send a very minor fix on top of Stas Sergeev's patch.

Oleg.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Andrew Morton]

Oleg Nesterov [EMAIL PROTECTED] wrote:

  Oleg Nesterov:
o x86: fix ESP corruption CPU bug (take 2)
 
 I don't even absolutely understand what this patch does :)
 I only send a very minor fix on top of Stas Sergeev's patch.
 

I'm suspecting a problem in the reporting scripts.  The patch had:


From: Stas Sergeev [EMAIL PROTECTED]

Attached patch works around the corruption of the high word of the ESP
register, which is the official bug of x86 CPUs.  The bug triggers only
when the one is using the 16bit stack segment, and is described here:

http://www.intel.com/design/intarch/specupdt/27287402.PDF

From: Oleg Nesterov [EMAIL PROTECTED]

  I think that Stas tries to steal 1024 bytes from kernel's memory.

Acked-by: Linus Torvalds [EMAIL PROTECTED]
Acked-by: Petr Vandrovec [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Stas Sergeev [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]



It looks like the final From: was used...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Hubert Tonneau]

2.6.12-rc2 still does not boot properly on my box.

Hubert Tonneau wrote:

 When switching from 2.6.11 to 2.6.12-rc1,
 I get a 'cannot open root device' fatal error at end of kernel boot process.
 Root device is 'hda1'.
 
 Hardware content of the box:
 
 8086  Intel Corporation   334082855PM 0   
 Host-Hub Interface Bridge
 8086  Intel Corporation   334182855PM 0   AGP 
 Bridge
 8086  Intel Corporation   24C282801DB/DBL/DBM B   
 USB UHCI Controller #1
 8086  Intel Corporation   24C482801DB/DBL/DBM B   
 USB UHCI Controller #2
 8086  Intel Corporation   24C782801DB/DBL/DBM B   
 USB UHCI Controller #3
 8086  Intel Corporation   24CD82801DB/DBL/DBM B   
 USB EHCI Controller
 8086  Intel Corporation   244882801BAM/CAM/DBM0   
 Hub Interface to PCI Bridge
 8086  Intel Corporation   24CC82801DBM0   LPC 
 Interface Bridge
 8086  Intel Corporation   24CA82801DBMB   IDE 
 Controller (UltraATA/100)
 8086  Intel Corporation   24C582801DB/DBL/DBM B   
 AC97 Audio Controller
 8086  Intel Corporation   24C682801DB/DBM B   AC97 
 Modem Controller
 10DE  NVIDIA Corporation  0324NV31B   NVIDIA NV31GL
 14E4  Broadcom Corporation165DBCM5705MB   
 Broadcom NetXtreme Gigabit Ethernet
 104C  Texas Instruments   AC477510/4510   B   Cardbus
 104C  Texas Instruments   AC4AB   
 104C  Texas Instruments   802BB   
 104C  Texas Instruments   82044610, 4515, 4610FM  0   
 TI UltraMedia Firmware Loader Device
 8086  Intel Corporation   4220MPCI3B  B   Intel 2200 mPCI 
 3B - RoW
 
 2.6.11 kernel report:
 
 4Linux version 2.6.11 ([EMAIL PROTECTED]) (gcc version 3.3 (Debian)) #1 Sun 
 Mar 6 12:00:57 CET 2005
 6BIOS-provided physical RAM map:
 4 BIOS-e820:  - 0009f000 (usable)
 4 BIOS-e820: 0009f000 - 000a (reserved)
 4 BIOS-e820: 0010 - 3ffae000 (usable)
 4 BIOS-e820: 3ffae000 - 4000 (reserved)
 4 BIOS-e820: feda - fee0 (reserved)
 4 BIOS-e820: ffb0 - 0001 (reserved)
 4Warning only 896MB will be used.
 4Use a HIGHMEM enabled kernel.
 5896MB LOWMEM available.
 7On node 0 totalpages: 229376
 7  DMA zone: 4096 pages, LIFO batch:1
 7  Normal zone: 225280 pages, LIFO batch:16
 7  HighMem zone: 0 pages, LIFO batch:1
 6DMI 2.3 present.
 7ACPI: RSDP (v000 DELL  ) @ 0x000fdf00
 7ACPI: RSDT (v001 DELLCPi R   0x27d40903 ASL  0x0061) @ 0x3fff
 7ACPI: FADT (v001 DELLCPi R   0x27d40903 ASL  0x0061) @ 0x3fff0400
 7ACPI: ASF! (v016 DELLCPi R   0x27d40903 ASL  0x0061) @ 0x3fff0800
 7ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x
 4Allocating PCI resources starting at 4000 (gap: 4000:beda)
 4Built 1 zonelists
 4Kernel command line: BOOT_IMAGE=recover ro root=301
 4Local APIC disabled by BIOS -- you can enable it with lapic
 7mapped APIC to d000 (01703000)
 6Initializing CPU#0
 4PID hash table entries: 4096 (order: 12, 65536 bytes)
 4Detected 1998.546 MHz processor.
 6Using tsc for high-res timesource
 4Console: colour VGA+ 80x25
 4Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
 4Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
 6Memory: 906620k/917504k available (1598k kernel code, 10432k reserved, 
 518k data, 140k init, 0k highmem)
 4Checking if this processor honours the WP bit even in supervisor mode... 
 Ok.
 7Calibrating delay loop... 3956.73 BogoMIPS (lpj=1978368)
 4Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
 7CPU: After generic identify, caps: afe9f9bf    
 0180  
 7CPU: After vendor identify, caps: afe9f9bf    
 0180  
 6CPU: L1 I cache: 32K, L1 D cache: 32K
 6CPU: L2 cache: 2048K
 7CPU: After all inits, caps: afe9f9bf   0040 0180 
  
 6Intel machine check architecture supported.
 6Intel machine check reporting enabled on CPU#0.
 4CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 06
 6Enabling fast FPU save and restore... done.
 6Enabling unmasked SIMD FPU exception support... done.
 6Checking 'hlt' instruction... OK.
 4ACPI: setting ELCR to 0200 (from 0800)
 6NET: Registered protocol family 16
 6PCI: PCI BIOS revision 2.10 entry at 0xfc96e, last bus=2
 6PCI: Using configuration type 1
 6mtrr: v2.0 (20020519)
 6ACPI: Subsystem revision 20050211
 6ACPI: Interpreter enabled
 6ACPI: Using PIC for interrupt routing
 6ACPI: PCI Root Bridge [PCI0] (00:00)
 4PCI: Probing 

Re: Linux 2.6.12-rc2

[Gene Heskett]

On Monday 04 April 2005 17:32, Linus Torvalds wrote:
>The diffstat output tells the story: this is a lot of very small
> changes, ie tons of small cleanups and bug fixes. With a few new
> drivers thrown in for good measure.
>
>This is also the point where I ask people to calm down, and not send
> me anything but clear bug-fixes etc. We're definitely well into -rc
> land. So keep it quiet out there,
>
>  Linus

Well, I'm happy to report that it not only built, it booted, and that 
the one program thats been a noshow for video, tvtime, in any kernel 
newer than -rc1, failing in all the . releases after .2, or any -mm I 
tried, is working quite nicely thank you in -rc2.  Its late, and I'll 
check the rest of my checklist in the morning.

-rc1 was one heck of an improvement in feel and usability, I hope -rc2 
will continue that tradition.  Great stuff.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Al Viro]

On Tue, Apr 05, 2005 at 12:49:55AM +0100, Russell King wrote:
> IOW, when sysdev.h is updated to prototype the function pointer with
> pm_message_t, this'll also be solved.
> 
> Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as
> the minimal patch.

OK...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Al Viro]

On Tue, Apr 05, 2005 at 09:37:18AM +1000, Stephen Rothwell wrote:
> On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> 
> wrote:
> >
> >   o missing include in lanai.c
> 
> After this patch I have ended up with linux/dma-mapping.h included twice
> in this file ...

Argh.  Looks like the same fix went in twice (now and in -rc1-bk3) and
these patches added include in places just far enough from each other to
create no rejects when porting patchset to -bk3 and further.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Russell King]

On Tue, Apr 05, 2005 at 12:24:19AM +0100, Al Viro wrote:
> On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
> > This is also the point where I ask people to calm down, and not send me
> > anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> > keep it quiet out there,
> 
>   * missing include in arm/kernel/time.c - see #ifdef CONFIG_PM
> further down in the file.

See previous threads.

The include should be in linux/sysdev.h.  The reason this has come up is
because the ARM changes got merged before the generic changes, so there's
currently a minor disparity with the calling convention for system
device suspend methods.

IOW, when sysdev.h is updated to prototype the function pointer with
pm_message_t, this'll also be solved.

Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as
the minimal patch.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

> 
> 
> The diffstat output tells the story: this is a lot of very small changes,
> ie tons of small cleanups and bug fixes. With a few new drivers thrown in
> for good measure.
> 
> This is also the point where I ask people to calm down, and not send me
> anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> keep it quiet out there,
> 
>   Linus
> 
> 
> Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
> ==
> 
[...]
> Andres Salomon:
>   o Possible AMD8111e free irq issue
>   o Possible VIA-Rhine free irq issue

These first two fixes were from Panagiotis Issaris
<[EMAIL PROTECTED]>; I merely forwarded them to gregkh & co.


>   o fix pci_disable_device in 8139too

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Stephen Rothwell]

On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> 
wrote:
>
>   o missing include in lanai.c

After this patch I have ended up with linux/dma-mapping.h included twice
in this file ...

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpaAmtwPxCtH.pgp
Description: PGP signature

Re: Linux 2.6.12-rc2

[Al Viro]

On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
> This is also the point where I ask people to calm down, and not send me
> anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> keep it quiet out there,

* missing include in arm/kernel/time.c - see #ifdef CONFIG_PM
further down in the file.

diff -urN RC12-rc2-base/arch/arm/kernel/time.c current/arch/arm/kernel/time.c
--- RC12-rc2-base/arch/arm/kernel/time.c2005-04-04 18:20:42.0 
-0400
+++ current/arch/arm/kernel/time.c  2005-04-04 19:17:12.446004816 -0400
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

> 
> 
> The diffstat output tells the story: this is a lot of very small changes,
> ie tons of small cleanups and bug fixes. With a few new drivers thrown in
> for good measure.
> 
> This is also the point where I ask people to calm down, and not send me
> anything but clear bug-fixes etc. We're definitely well into -rc land. So 
> keep it quiet out there,
> 
>   Linus
> 
> 
> Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
> ==
> 
[...]
> Andres Salomon:
>   o Possible AMD8111e free irq issue
>   o Possible VIA-Rhine free irq issue
>   o fix pci_disable_device in 8139too
> 

The first two fixes were from Panagiotis Issaris
<[EMAIL PROTECTED]>; I merely forwarded them on.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

[...]
> 
> 
> Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
> ==
> 
[...]
> 
> Andres Salomon:
>   o Possible AMD8111e free irq issue
>   o Possible VIA-Rhine free irq issue

Those two were from Panagiotis Issaris <[EMAIL PROTECTED]>; I just
forwarded them on.


>   o fix pci_disable_device in 8139too


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

[...]
 
 
 Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
 ==
 
[...]
 
 Andres Salomon:
   o Possible AMD8111e free irq issue
   o Possible VIA-Rhine free irq issue

Those two were from Panagiotis Issaris [EMAIL PROTECTED]; I just
forwarded them on.


   o fix pci_disable_device in 8139too


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

 
 
 The diffstat output tells the story: this is a lot of very small changes,
 ie tons of small cleanups and bug fixes. With a few new drivers thrown in
 for good measure.
 
 This is also the point where I ask people to calm down, and not send me
 anything but clear bug-fixes etc. We're definitely well into -rc land. So 
 keep it quiet out there,
 
   Linus
 
 
 Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
 ==
 
[...]
 Andres Salomon:
   o Possible AMD8111e free irq issue
   o Possible VIA-Rhine free irq issue
   o fix pci_disable_device in 8139too
 

The first two fixes were from Panagiotis Issaris
[EMAIL PROTECTED]; I merely forwarded them on.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Al Viro]

On Mon, Apr 04, 2005 at 02:32:52PM -0700, Linus Torvalds wrote:
 This is also the point where I ask people to calm down, and not send me
 anything but clear bug-fixes etc. We're definitely well into -rc land. So 
 keep it quiet out there,

* missing include in arm/kernel/time.c - see #ifdef CONFIG_PM
further down in the file.

diff -urN RC12-rc2-base/arch/arm/kernel/time.c current/arch/arm/kernel/time.c
--- RC12-rc2-base/arch/arm/kernel/time.c2005-04-04 18:20:42.0 
-0400
+++ current/arch/arm/kernel/time.c  2005-04-04 19:17:12.446004816 -0400
@@ -28,6 +28,7 @@
 #include linux/profile.h
 #include linux/sysdev.h
 #include linux/timer.h
+#include linux/pm.h
 
 #include asm/hardware.h
 #include asm/io.h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Stephen Rothwell]

On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] 
wrote:

   o missing include in lanai.c

After this patch I have ended up with linux/dma-mapping.h included twice
in this file ...

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/


pgpaAmtwPxCtH.pgp
Description: PGP signature

Re: Linux 2.6.12-rc2

[Andres Salomon]

On Mon, 04 Apr 2005 14:32:52 -0700, Linus Torvalds wrote:

 
 
 The diffstat output tells the story: this is a lot of very small changes,
 ie tons of small cleanups and bug fixes. With a few new drivers thrown in
 for good measure.
 
 This is also the point where I ask people to calm down, and not send me
 anything but clear bug-fixes etc. We're definitely well into -rc land. So 
 keep it quiet out there,
 
   Linus
 
 
 Summary of changes from v2.6.12-rc1 to v2.6.12-rc2
 ==
 
[...]
 Andres Salomon:
   o Possible AMD8111e free irq issue
   o Possible VIA-Rhine free irq issue

These first two fixes were from Panagiotis Issaris
[EMAIL PROTECTED]; I merely forwarded them to gregkh  co.


   o fix pci_disable_device in 8139too

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Al Viro]

On Tue, Apr 05, 2005 at 09:37:18AM +1000, Stephen Rothwell wrote:
 On Mon, 4 Apr 2005 14:32:52 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] 
 wrote:
 
o missing include in lanai.c
 
 After this patch I have ended up with linux/dma-mapping.h included twice
 in this file ...

Argh.  Looks like the same fix went in twice (now and in -rc1-bk3) and
these patches added include in places just far enough from each other to
create no rejects when porting patchset to -bk3 and further.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Al Viro]

On Tue, Apr 05, 2005 at 12:49:55AM +0100, Russell King wrote:
 IOW, when sysdev.h is updated to prototype the function pointer with
 pm_message_t, this'll also be solved.
 
 Therefore, if anything, linux/pm.h should be added to linux/sysdev.h as
 the minimal patch.

OK...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.12-rc2

[Gene Heskett]

On Monday 04 April 2005 17:32, Linus Torvalds wrote:
The diffstat output tells the story: this is a lot of very small
 changes, ie tons of small cleanups and bug fixes. With a few new
 drivers thrown in for good measure.

This is also the point where I ask people to calm down, and not send
 me anything but clear bug-fixes etc. We're definitely well into -rc
 land. So keep it quiet out there,

  Linus

Well, I'm happy to report that it not only built, it booted, and that 
the one program thats been a noshow for video, tvtime, in any kernel 
newer than -rc1, failing in all the . releases after .2, or any -mm I 
tried, is working quite nicely thank you in -rc2.  Its late, and I'll 
check the rest of my checklist in the morning.

-rc1 was one heck of an improvement in feel and usability, I hope -rc2 
will continue that tradition.  Great stuff.

-- 
Cheers, Gene
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/