> please try attached patch with 2.6.27-rc3
Thx for the patch... and for providing it as an attachment. My email
situation is less than optimal, and I am stuck using my ISP's web
interface for the present.
I used 'git apply --check <patchfilename>' first, and got no errors, so
I applied it, built, installed, and rebooted.
The kernel froze in the same way as the others.
BTW, I saw a new last line of output -- which may or may not be
relevant -- but I thought I should mention it since I had never seen
it before:
With the patched 2.6.27-rc3 kernel, I thought I saw some different
output during the boot. The messages were from pnp_system_init(), and
had to do with not being able to use iomem ranges. I rebooted one of
my 2.6.26 kernels (with HPET enabled so it would freeze) so I could
compare the messages, and found that I was wrong: the messages were not
new, and are probably normal.
However, each time one of these 2.6.2[67] kernels locks up, the last
line on the screen is the (now familiar) inet_init() message:
NET: Registered protocol family 2
When I booted the older 2.6.26 kernel, I saw something I haven't seen
before:
Clocksource tsc unstable (delta = 4398046170281 ns)
Now, I have experienced aggravating TSC messages at boot ever since I built
my first AMD dual-core machine last year. I researched the issue, I found
that I could use "notsc" to suppress the messages. I have GRUB
automatically add the "notsc" parameter for my everyday-usage kernels, but
I have intentionally NOT been using "notsc" for any of the freezing kernels
about which I have been reporting information here. (I have tried "notsc"
before as an experiment, but it does not prevent freezing.)
Getting a TSC message when not using "notsc" is no surprise. I only mention
it because this is the first time I have seen that message as the last
output line during a freeze.
Beware: this TSC output happened just now with an older 2.6.26 kernel, not
with the patched 2.6.27-rc3 kernel... so it has nothing to do with the new
patch. That time "delta" is ridiculous: 4398 seconds. Total time from
GRUB to freeze is < 3 seconds. It reminds me of info I posted before about
the pci_bios_assign_resources() initcall falsely reporting a return in
285000+ msecs.
Thanks,
Dave W.
On Wed, Aug 13, 2008 at 5:03 AM, David Witbrodt <[email protected]> wrote:
>
>
>> please try attached patch with 2.6.27-rc3
>
> Thx for the patch... and for providing it as an attachment. My email
> situation is less than optimal, and I am stuck using my ISP's web
> interface for the present.
>
> I used 'git apply --check <patchfilename>' first, and got no errors, so
> I applied it, built, installed, and rebooted.
that patch revert to use request_resource, so there is some other problem
YH
On Wed, Aug 13, 2008 at 5:03 AM, David Witbrodt <[email protected]> wrote:
>
>
>> please try attached patch with 2.6.27-rc3
>
> Thx for the patch... and for providing it as an attachment. My email
> situation is less than optimal, and I am stuck using my ISP's web
> interface for the present.
>
> I used 'git apply --check <patchfilename>' first, and got no errors, so
> I applied it, built, installed, and rebooted.
could apply with
cat revert_*.;patch | patch -p1
YH