Dan Nelson wrote:
In the last episode (Nov 25), Terry Lambert said:
Marcin Dalecki wrote:
I don't think this is really possible.
I went looking for a generic "application use" CMOS are for this
sort of thing a while back, and I was unable to find one.
Well you should please take a look at t
Dan Nelson wrote:
> > Is there documentation available for this anywhere? The BIOS vendor
> > documentation, not the Linux source code.
>
> http://www.microsoft.com/hwdev/resources/specs/simp_bios.asp
> http://www.microsoft.com/hwdev/resources/specs/simp_boot.asp
>
> is the best I could find; yo
In the last episode (Nov 25), Terry Lambert said:
> Marcin Dalecki wrote:
> > > I don't think this is really possible.
> > >
> > > I went looking for a generic "application use" CMOS are for this
> > > sort of thing a while back, and I was unable to find one.
> >
> > Well you should please take a
Marcin Dalecki wrote:
> > I don't think this is really possible.
> >
> > I went looking for a generic "application use" CMOS are for this
> > sort of thing a while back, and I was unable to find one.
>
> Well you should please take a look at the "fast boot" option
> of moderately modern BIOS-es. S
Brad Knowles wrote:
> At 2:02 PM -0800 2002/11/25, Terry Lambert wrote:
> > If you made system dumps mandatory (or marked swap with a non-dump
> > header in case of panic), this still would not handle the "silent
> > reboot", "double panic", or "single panic with disk I/O trashed"
> > cases. 8
Kris Kennaway wrote:
> On Mon, Nov 25, 2002 at 02:02:14PM -0800, Terry Lambert wrote:
> > I don't think this is really possible.
>
> Yeah :(
>
> > If you made system dumps mandatory (or marked swap with a non-dump
> > header in case of panic), this still would not handle the "silent
> > reboot",
At 2:02 PM -0800 2002/11/25, Terry Lambert wrote:
If you made system dumps mandatory (or marked swap with a non-dump
header in case of panic), this still would not handle the "silent
reboot", "double panic", or "single panic with disk I/O trashed"
cases. 8-(.
How about we do the safe thin
On Mon, Nov 25, 2002 at 02:02:14PM -0800, Terry Lambert wrote:
> I don't think this is really possible.
Yeah :(
> If you made system dumps mandatory (or marked swap with a non-dump
> header in case of panic), this still would not handle the "silent
> reboot", "double panic", or "single panic wit
Terry Lambert wrote:
Kris Kennaway wrote:
On Mon, Nov 25, 2002 at 10:24:46AM -0500, Robert Watson wrote:
I thought, this might be due to the priority of the background fsck and
have once left it alone for several hours -- with no effect. The usual
fsck takes a few minutes.
We really need to
Mikhail Teterin wrote:
> On Monday 25 November 2002 12:24 pm, Kris Kennaway wrote:
> = On Mon, Nov 25, 2002 at 10:24:46AM -0500, Robert Watson wrote:
> =
> = > > I thought, this might be due to the priority of the background
> = > > fsck and have once left it alone for several hours -- with no
> =
Kris Kennaway wrote:
> On Mon, Nov 25, 2002 at 10:24:46AM -0500, Robert Watson wrote:
> > > I thought, this might be due to the priority of the background fsck and
> > > have once left it alone for several hours -- with no effect. The usual
> > > fsck takes a few minutes.
>
> We really need to dis
Mikhail Teterin wrote:
> The only way to get my -current system back to normal after a crash is
> to boot into single user and do an explicit ``fsck -p''.
>
> Otherwise the system will, seemingly, boot fine, but none of the ttyvs
> will accept any input, although tty-switching works fine. Remote
>
On Monday 25 November 2002 12:24 pm, Kris Kennaway wrote:
= On Mon, Nov 25, 2002 at 10:24:46AM -0500, Robert Watson wrote:
=
= > > I thought, this might be due to the priority of the background
= > > fsck and have once left it alone for several hours -- with no
= > > effect. The usual fsck takes a
On Mon, Nov 25, 2002 at 10:24:46AM -0500, Robert Watson wrote:
> > I thought, this might be due to the priority of the background fsck and
> > have once left it alone for several hours -- with no effect. The usual
> > fsck takes a few minutes.
We really need to disable background fsck if the sys
On Mon, 25 Nov 2002, Mikhail Teterin wrote:
> The only way to get my -current system back to normal after a crash is
> to boot into single user and do an explicit ``fsck -p''.
>
> Otherwise the system will, seemingly, boot fine, but none of the ttyvs
> will accept any input, although tty-switch
The only way to get my -current system back to normal after a crash is
to boot into single user and do an explicit ``fsck -p''.
Otherwise the system will, seemingly, boot fine, but none of the ttyvs
will accept any input, although tty-switching works fine. Remote
connections (ssh, telnet) don't br
16 matches
Mail list logo
