Hi there brave visitor from the future ;)
Andi Kleen wrote:
> Actually that's not correct. With panic=30 and lilo -R and a working
> backup kernel a system can recover from this. With your endless loop it can't.
>
> Always add some kind of timeout.
>
>
Did you check the second version? Is
Pierre Ossman <[EMAIL PROTECTED]> writes:
>
> If the device never shows up than we will hang in an infinite loop.
> Previously we panic:ed instead, so this behaviour should be no
> worse.
Actually that's not correct. With panic=30 and lilo -R and a working
backup kernel a
Hi there brave visitor from the future ;)
Andi Kleen wrote:
Actually that's not correct. With panic=30 and lilo -R and a working
backup kernel a system can recover from this. With your endless loop it can't.
Always add some kind of timeout.
Did you check the second version? Is that
Pierre Ossman [EMAIL PROTECTED] writes:
If the device never shows up than we will hang in an infinite loop.
Previously we panic:ed instead, so this behaviour should be no
worse.
Actually that's not correct. With panic=30 and lilo -R and a working
backup kernel a system can
Haavard Skinnemoen wrote:
On Mon, 14 May 2007 17:18:06 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
New suggestion.
Works wonderfully here:
Waiting for root device /dev/mmcblk0p1...
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).
Of course, it also
On Mon, 14 May 2007 17:18:06 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> New suggestion.
Works wonderfully here:
Waiting for root device /dev/mmcblk0p1...
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).
Of course, it also fixes the case where the card
On Mon, 14 May 2007 17:18:06 +0200
Pierre Ossman [EMAIL PROTECTED] wrote:
New suggestion.
Works wonderfully here:
Waiting for root device /dev/mmcblk0p1...
inserts card
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).
Of course, it also fixes the case where
Haavard Skinnemoen wrote:
On Mon, 14 May 2007 17:18:06 +0200
Pierre Ossman [EMAIL PROTECTED] wrote:
New suggestion.
Works wonderfully here:
Waiting for root device /dev/mmcblk0p1...
inserts card
mmcblk0: mmc0:a95c SD128 123008KiB
mmcblk0: p1
VFS: Mounted root (ext2 filesystem).
Of course,
New suggestion.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit bb8c44ee8b4d584295add58a4ea2f03b9938fc3c
Author: Pierre Ossman
On Mon, 14 May 2007 15:56:15 +0200
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> > As for the patch, an infinite loop is *much* worse than a panic.
> > When one is installing a new kernel on remote box, having it
> > booted with reboot on panic and loader falling back to old
> > kernel on the next
Al Viro wrote:
> On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
>
> First of all, please do not put patches in attachments.
>
>
My mailer tends to fsck them up if I just paste them. And it's attached
without any base64 silliness, so most people can usually read it directly.
>
On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
First of all, please do not put patches in attachments.
As for the patch, an infinite loop is *much* worse than a panic.
When one is installing a new kernel on remote box, having it
booted with reboot on panic and loader falling back
Testing and/or comments welcome.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 7c542a5a027caa95bb00f8a8223c7e4aef88c931
Author:
Testing and/or comments welcome.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit 7c542a5a027caa95bb00f8a8223c7e4aef88c931
Author:
On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
First of all, please do not put patches in attachments.
As for the patch, an infinite loop is *much* worse than a panic.
When one is installing a new kernel on remote box, having it
booted with reboot on panic and loader falling back
Al Viro wrote:
On Mon, May 14, 2007 at 02:19:37PM +0200, Pierre Ossman wrote:
First of all, please do not put patches in attachments.
My mailer tends to fsck them up if I just paste them. And it's attached
without any base64 silliness, so most people can usually read it directly.
As for
On Mon, 14 May 2007 15:56:15 +0200
Pierre Ossman [EMAIL PROTECTED] wrote:
As for the patch, an infinite loop is *much* worse than a panic.
When one is installing a new kernel on remote box, having it
booted with reboot on panic and loader falling back to old
kernel on the next boot is a
New suggestion.
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
commit bb8c44ee8b4d584295add58a4ea2f03b9938fc3c
Author: Pierre Ossman
18 matches
Mail list logo
