sysctl interface to bootflags?

sysctl interface to bootflags?

[Thomas Hood]

As I've said, I think it would be nice to have /proc
control over two boot flags: the DIAG bit (which switches
on (1) and off (0) the BIOS diagnostics) and the PnP-OS bit
(which switches on (0) and off (1) PnP BIOS device configuration).

Would it be a good idea to do this using the sysctl infrastructure?
If so, can someone please suggest an appropriate pathname for
the flag files?  How about "/proc/sys/BIOS/bootflags/diagnostics"
and "/proc/sys/BIOS/bootflags/PnP-OS" ?

If this is a bad idea, someone please stop me before I waste my
time implementing it.

--
Thomas

Re: sysctl interface to bootflags?

[Dave Jones]

On 9 Oct 2001, Thomas Hood wrote:

> Would it be a good idea to do this using the sysctl infrastructure?
> If so, can someone please suggest an appropriate pathname for
> the flag files?  How about "/proc/sys/BIOS/bootflags/diagnostics"
> and "/proc/sys/BIOS/bootflags/PnP-OS" ?
> If this is a bad idea, someone please stop me before I waste my
> time implementing it.

Last week, I pointed you at http://www.codemonkey.org.uk/sbf.c
Can you give a reason why this needs to be done in kernel space ?

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: sysctl interface to bootflags?

[Thomas Hood]

Hi.  I looked at your code and I saw that it depended
on ACPI.  Since ACPI doesn't work on my machine, I 
thought I should look for another solution.  However,
Alan now tells me that what I want to do can already
be done via /dev/nvram.

Thanks to both of you.
Thomas

On Tue, 2001-10-09 at 10:15, Dave Jones wrote:
> On 9 Oct 2001, Thomas Hood wrote:
> 
> > Would it be a good idea to do this using the sysctl infrastructure?
> > If so, can someone please suggest an appropriate pathname for
> > the flag files?  How about "/proc/sys/BIOS/bootflags/diagnostics"
> > and "/proc/sys/BIOS/bootflags/PnP-OS" ?
> > If this is a bad idea, someone please stop me before I waste my
> > time implementing it.
> 
> Last week, I pointed you at http://www.codemonkey.org.uk/sbf.c
> Can you give a reason why this needs to be done in kernel space ?
> 
> regards,
> 
> Dave.

Re: sysctl interface to bootflags?

[Dave Jones]

On 9 Oct 2001, Thomas Hood wrote:

> Hi.  I looked at your code and I saw that it depended
> on ACPI.  Since ACPI doesn't work on my machine, I
> thought I should look for another solution.  However,

Huh ? Read the code again.
Its no more dependant upon ACPI than bootflag.c is.
The bootflag is pointed at by an ACPI table.
The code I wrote functions /exactly/ the same on
a kernel with APM, ACPI or NO power management.

> Alan now tells me that what I want to do can already
> be done via /dev/nvram.

My code _is_ using /dev/nvram !

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: sysctl interface to bootflags?

[Thomas Hood]

Sorry, I didn't read your code very carefully before because
I thought it relied on ACPI.  Now I understand it better.
It doesn't use /dev/nvram, but /dev/mem.

Here's what happens when I run it.

jdthood@thanatos:~/src/sbf$ gcc sbf.c
jdthood@thanatos:~/src/sbf$ su
Password: 
root@thanatos:/home/jdthood/src/sbf# gdb -q ./a.out
(no debugging symbols found)...(gdb) run
Starting program: /mnt/p/home/jdthood/src/sbf/./a.out 
BOOT @ 0x07fd0040
CMOS register:51
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x80489be in outb_p ()

--
Thomas

On Tue, 2001-10-09 at 11:34, Dave Jones wrote:
> On 9 Oct 2001, Thomas Hood wrote:
> 
> > Hi.  I looked at your code and I saw that it depended
> > on ACPI.  Since ACPI doesn't work on my machine, I
> > thought I should look for another solution.  However,
> 
> Huh ? Read the code again.
> Its no more dependant upon ACPI than bootflag.c is.
> The bootflag is pointed at by an ACPI table.
> The code I wrote functions /exactly/ the same on
> a kernel with APM, ACPI or NO power management.
> 
> > Alan now tells me that what I want to do can already
> > be done via /dev/nvram.
> 
> My code _is_ using /dev/nvram !
> 
> regards,
> 
> Dave.
> 
> -- 
> | Dave Jones.        http://www.suse.de/~davej
> | SuSE Labs
> 

Re: sysctl interface to bootflags?

[Dave Jones]

On 9 Oct 2001, Thomas Hood wrote:

> jdthood@thanatos:~/src/sbf$ gcc sbf.c
> Program received signal SIGSEGV, Segmentation fault.
> 0x80489be in outb_p ()

outb doesn't work unless you compile with -O2 iirc.

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: sysctl interface to bootflags?

[Thomas Hood]

jdthood@thanatos:~/src/sbf$ gcc -O2 sbf.c
jdthood@thanatos:~/src/sbf$ su
Password: 
root@thanatos:/home/jdthood/src/sbf# l
./  ../  a.out*  sbf.c
root@thanatos:/home/jdthood/src/sbf# ./a.out
BOOT @ 0x07fd0040
CMOS register:51
Segmentation fault

:(

Thomas

On Tue, 2001-10-09 at 11:52, Dave Jones wrote:
> On 9 Oct 2001, Thomas Hood wrote:
> 
> > jdthood@thanatos:~/src/sbf$ gcc sbf.c
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x80489be in outb_p ()
> 
> outb doesn't work unless you compile with -O2 iirc.
> 
> regards,
> 
> Dave.
> 
> -- 
> | Dave Jones.        http://www.suse.de/~davej
> | SuSE Labs
> 

Re: sysctl interface to bootflags?

[Dave Jones]

On 9 Oct 2001, Thomas Hood wrote:

> jdthood@thanatos:~/src/sbf$ gcc -O2 sbf.c
> Segmentation fault

Ok, I managed to repeat this here. Fortunatly, the
pending fixes from Randy Dunlap include a fix for this.
Updated version at http://www.codemonkey.org.uk/cruft/
(including a version with the /dev/nvram using interface
which got dropped for reasons I don't recall).

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: sysctl interface to bootflags?

[Alan Cox]

> Would it be a good idea to do this using the sysctl infrastructure?
> If so, can someone please suggest an appropriate pathname for
> the flag files?  How about "/proc/sys/BIOS/bootflags/diagnostics"
> and "/proc/sys/BIOS/bootflags/PnP-OS" ?

Userspace can already do it via /dev/nvram

Re: sysctl interface to bootflags?

[Thomas Hood]

On Tue, 2001-10-09 at 10:18, Alan Cox wrote:
> Userspace can already do it via /dev/nvram

I see.  Good.

I think that it would be helpful if the title for
this feature in the kernel configuration menu was
something more explanatory than "/dev/nvram support".
I thought this had something to do with video RAM!

Cheers
Thomas

Re: sysctl interface to bootflags?

[Thomas Hood]

Thanks.  I tested the new sbf.c and after hacking it a
bit to remove the fail-on-invalid-reg-value, it runs:

root@thanatos:/home/jdthood/src/sbf# ./a.out
BOOT @ 0x07fd0040
CMOS register: 0x33
Read current value := 0x88
Read updated value := 0x89

Here it has set bit 0, the PnP-OS bit.  Do you have any
plans to enhance the program to allow control of all the flags?

--
Thomas

Re: sysctl interface to bootflags?

[Dave Jones]

On 9 Oct 2001, Thomas Hood wrote:

> Read current value := 0x88
> Read updated value := 0x89
> Here it has set bit 0, the PnP-OS bit.  Do you have any
> plans to enhance the program to allow control of all the flags?

Could be a useful addition, if only during debugging.
The idea iirc is that kernel should put it into a state
where userspace only needs to clear the 'successful boot' flag.
By the time we get to userspace, the parity should be correct also,
so you shouldn't need to hack sbf.c to chop that test out.


regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: sysctl interface to bootflags?

[Thomas Hood]

Well, it may run, but what it changed was NOT the SBF field.
When I restarted my machine the BIOS beeped and told me
there was an error in the nonvolatile RAM.  I was made to
reset the system date, and then the computer rebooted
normally.

--
Thomas

> Thanks.  I tested the new sbf.c and after hacking it a
> bit to remove the fail-on-invalid-reg-value, it runs:
>
> root@thanatos:/home/jdthood/src/sbf# ./a.out
> BOOT @ 0x07fd0040
> CMOS register: 0x33
> Read current value := 0x88
> Read updated value := 0x89
>
> Here it has set bit 0, the PnP-OS bit.  Do you have any
> plans to enhance the program to allow control of all the flags?

Re: sysctl interface to bootflags?

[Thomas Hood]

Well, it may run, but what it changed was NOT the SBF field.
When I restarted my machine the BIOS beeped and told me
there was an error in the nonvolatile RAM.  I was made to
reset the system date, and then the computer rebooted
normally.

--
Thomas

> Thanks.  I tested the new sbf.c and after hacking it a
> bit to remove the fail-on-invalid-reg-value, it runs:
>
> root@thanatos:/home/jdthood/src/sbf# ./a.out
> BOOT @ 0x07fd0040
> CMOS register: 0x33
> Read current value := 0x88
> Read updated value := 0x89
>
> Here it has set bit 0, the PnP-OS bit.  Do you have any
> plans to enhance the program to allow control of all the flags?

Re: sysctl interface to bootflags?

[Dave Jones]

On 8 Oct 2001, Thomas Hood wrote:

> Well, it may run, but what it changed was NOT the SBF field.
> When I restarted my machine the BIOS beeped and told me
> there was an error in the nonvolatile RAM.  I was made to
> reset the system date, and then the computer rebooted
> normally.

Ouch. Can you verify that the CMOS register its changing matches
with what's listed in the BOOT record ?
add a printk to bootflag.c to check.

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: sysctl interface to bootflags?

[Thomas Hood]

On Wed, 2001-10-10 at 02:46, Dave Jones wrote:

> Ouch. Can you verify that the CMOS register its changing matches
> with what's listed in the BOOT record ?
> add a printk to bootflag.c to check.

I haven't rebooted since this happened; the error
occurred when I resumed from hibernation.

In any case, I suspect that the BIOS reset whatever
register it was that was incorrectly set.  Here again
is the output of the sbf program that cause the problem.
I ran the "sbf-0.3" version of the program, modified
to ignore the parity error on the value read back from the
register.

root@thanatos:/home/jdthood/src/sbf# ./a.out
BOOT @ 0x07fd0040
CMOS register: 0x33
Read current value := 0x88
Read updated value := 0x89

We need to come to a better understanding of what it's doing
differently from bootflag.c, which writes to the right place.

Regards
Thomas