Testing and/or comments welcome.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
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 to old
kernel on the next boot is a bloody good idea - gives you extra
safety. With your patch it will get the box stuck.
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 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 bloody good idea - gives you extra
> safety. With your patch it will get the box stuck.
>
Ok. So a timeout or having the entire thing Kconfig optional?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
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 bloody good idea - gives you extra
> > safety. With your patch it will get the box stuck.
> >
>
> Ok. So a timeout or having the entire thing Kconfig optional?
How about command-line optional?
Haavard
New suggestion.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
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 the card _is_ inserted at
bootup :-)
Haavard
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, it also fixes the case where the card _is_ inserted at
> bootup :-)
Seconded. Love your work Pierre :)
Tested across 4 different brands of SD/MMC/RS-MMC card and 2 different
configurations (both AVR32 arch) just for the hells of it. All plays nice.
Thanks,
--Ben.
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 recover from this. With your endless loop it can't.
Always add some kind of timeout.
-Andi
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 sufficient or is a timeout a
must in your book?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org