[dm-devel] Fwd: 2.6.25-rc1 patch prevents booting on LVM-based devices
Chuck Lever
chuck.lever at oracle.com
Wed Feb 20 16:20:24 UTC 2008
Begin forwarded message:
> From: Chuck Lever <chuck.lever at oracle.com>
> Date: February 20, 2008 10:50:01 AM EST
> To: dm-devel at redhat.com
> Subject: 2.6.25-rc1 patch prevents booting on LVM-based devices
>
> Hello-
>
> I've got a Fedora 8 x86 test system that uses LVM volumes for all
> it's file systems except /boot. After commit bdc80787, 2.6.24+
> doesn't boot on this system -- the LVM volume scan during start-up
> can no longer find any physical volumes on the system.
>
> I'm not sure whether this is an LVM issue, or something else is
> breaking during system init which prevents the LVM scan from
> working. I need some help troubleshooting the problem.
Interestingly, if I build a non-tickless kernel, the problem goes away.
> bdc80787 is:
>
> commit bdc807871d58285737d50dc6163d0feb72cb0dc2
> Author: H. Peter Anvin <hpa at zytor.com>
> Date: Fri Feb 8 04:21:26 2008 -0800
>
> avoid overflows in kernel/time.c
>
> When the conversion factor between jiffies and milli- or
> microseconds is
> not a single multiply or divide, as for the case of HZ == 300,
> we currently
> do a multiply followed by a divide. The intervening result,
> however, is
> subject to overflows, especially since the fraction is not
> simplified (for
> HZ == 300, we multiply by 300 and divide by 1000).
>
> This is exposed to the user when passing a large timeout to poll
> (), for
> example.
>
> This patch replaces the multiply-divide with a reciprocal
> multiplication on
> 32-bit platforms. When the input is an unsigned long, there is
> no portable
> way to do this on 64-bit platforms there is no portable way to
> do this
> since it requires a 128-bit intermediate result (which gcc does
> support on
> 64-bit platforms but may generate libgcc calls, e.g. on 64-bit
> s390), but
> since the output is a 32-bit integer in the cases affected,
> just simplify
> the multiply-divide (*3/10 instead of *300/1000).
>
> and so on...
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
More information about the dm-devel
mailing list