pmac_nvram problems

pmac_nvram problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Hi,

Please CC me on answers, I'm not subscribed. I wasn't too sure where to
send this, so CC'ing to Benjamin Herrenschmidt as the author of the
relevant driver.

Note that this might apply to the copy in ppc64 as well, not sure.

Currently, the pmac_nvram driver can be built as a module, but doesn't
specify its license and also fails to load because it uses
alloc_bootmem:
| pmac_nvram: module license 'unspecified' taints kernel.
| pmac_nvram: Unknown symbol __alloc_bootmem

I'm not sure why alloc_bootmem is used at all (is the nvram larger than
a couple of pages on any machine? And if it is, should it really be
cached in RAM?), but I think it should be sufficient to just use kmalloc
(well, it works for me).

Secondly, this driver misses power management. Having suspended, I
booted OSX which always resets the boot volume. But after resuming
linux, nvsetvol(8) still reports 0 as the boot volume because the
pmac_nvram driver caches the nvram contents. Fixing this would require
converting the driver to the new model though, I think.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: pmac_nvram problems

[Benjamin Herrenschmidt]

> I'm not sure why alloc_bootmem is used at all (is the nvram larger than
> a couple of pages on any machine? And if it is, should it really be
> cached in RAM?), but I think it should be sufficient to just use kmalloc
> (well, it works for me).

There used to be cases where we used the nvram stuff before kmalloc()
was available. I'll check if this is still the case.
 
> Secondly, this driver misses power management. Having suspended, I
> booted OSX which always resets the boot volume. But after resuming
> linux, nvsetvol(8) still reports 0 as the boot volume because the
> pmac_nvram driver caches the nvram contents. Fixing this would require
> converting the driver to the new model though, I think.

Well... the driver doesn't expect you to boot a different OS while
suspended to disk :)

Regarding caching the data in memory, this is done becaues nvram is
actually a flash on recent machines, and you really want to limit the
number of write cycles to it.

Ben.

Re: pmac_nvram problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Thu, 2005-08-18 at 15:00 +1000, Benjamin Herrenschmidt wrote:

> There used to be cases where we used the nvram stuff before kmalloc()
> was available. I'll check if this is still the case.

Ah, ok. Makes sense. In that case I suppose it must be #ifdef'ed for the
module case.
 
> Well... the driver doesn't expect you to boot a different OS while
> suspended to disk :)

Yeah :) It'd be nice though since except for that I haven't found any
other adverse effects.

> Regarding caching the data in memory, this is done becaues nvram is
> actually a flash on recent machines, and you really want to limit the
> number of write cycles to it.

Ok, makes sense. When I get some time I'll look into converting and
implementing reloading for that case, but now that I compile as a module
and unload it, it hardly is a priority.

Thanks for your answers,
johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: pmac_nvram problems

[Benjamin Herrenschmidt]

On Thu, 2005-08-18 at 15:03 +0200, Johannes Berg wrote:
> On Thu, 2005-08-18 at 15:00 +1000, Benjamin Herrenschmidt wrote:
> 
> > There used to be cases where we used the nvram stuff before kmalloc()
> > was available. I'll check if this is still the case.
> 
> Ah, ok. Makes sense. In that case I suppose it must be #ifdef'ed for the
> module case.
>  
> > Well... the driver doesn't expect you to boot a different OS while
> > suspended to disk :)
> 
> Yeah :) It'd be nice though since except for that I haven't found any
> other adverse effects.
> 
> > Regarding caching the data in memory, this is done becaues nvram is
> > actually a flash on recent machines, and you really want to limit the
> > number of write cycles to it.
> 
> Ok, makes sense. When I get some time I'll look into converting and
> implementing reloading for that case, but now that I compile as a module
> and unload it, it hardly is a priority.

Just a question: Why do you want to have the nvram low level code as a
module ? It's sort-of an intergral part of the arch code ...

Ben.

Re: pmac_nvram problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

On Fri, 2005-08-19 at 07:40 +1000, Benjamin Herrenschmidt wrote:

> Just a question: Why do you want to have the nvram low level code as a
> module ? It's sort-of an intergral part of the arch code ...

Because I Can (TM). Actually, I just did this because of the suspend
issue where OSX would reset some values (notably the boot sound volume),
but Linux wouldn't see this. So I figured that if I can compile it as a
module (the Kconfig option is a tristate after all) I could just unload
it. But that failed because of the alloc_bootmem issue.

I wouldn't mind having it built-in at all, if it would re-read the
cached values when resuming from suspend.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: pmac_nvram problems

[Benjamin Herrenschmidt]

On Fri, 2005-08-19 at 12:55 +0200, Johannes Berg wrote:
> On Fri, 2005-08-19 at 07:40 +1000, Benjamin Herrenschmidt wrote:
> 
> > Just a question: Why do you want to have the nvram low level code as a
> > module ? It's sort-of an intergral part of the arch code ...
> 
> Because I Can (TM). Actually, I just did this because of the suspend
> issue where OSX would reset some values (notably the boot sound volume),
> but Linux wouldn't see this. So I figured that if I can compile it as a
> module (the Kconfig option is a tristate after all) I could just unload
> it. But that failed because of the alloc_bootmem issue.
> 
> I wouldn't mind having it built-in at all, if it would re-read the
> cached values when resuming from suspend.

Best then is to add a sysdev there so you get suspend() and resume()
notification. You can then write to flash on suspend (same call done by
machine restart/powerdown) and re-read on resume.

Ben.