Thank you very much for the quick response. I know
you must be terribly busy with the server move, so I
won't take up too much more of your time.
I did find an old (possibly related) discussion you
were involved in:
I can't tell from the thread whether it was a problem
seen on 188.8.131.52, but that might have been tip at the
> It's a bug which should be fixed but nevertheless I
> can highly recommend
> something like a SiliconImage SATA controller - the
> onboard PIO PATA
> controller is so slow.
I understand, but changing that is not an option for
> I've pushed the tag again so now there is a tarball.
Thanks. I thought something was terribly wrong with
.28 for it to be skipped.
> If you need to track something like this you're
> probably best with
> git bisect which should bring you right to the
> offending commit.
I probably should have used that approach instead of
diffing .27 and .29 and narrowing the file list by
hand. As it was, there were changes to non-MIPS
platforms and devices I'm not using so those were easy
to apply to .27. Also, there were many file changes
for MT SMP support, and *most* (but not all) of those
changes were wrapped with conditional compiles, so
those were also easy to apply. I knew once I got to
these five files I was in some interesting code that
could point to the problems I'm seeing.
> Later kernels do run on bcm1480 which is close
By "later kernels", do you mean 184.108.40.206 or different
Perhaps, but I'm seeing identical failures in .29 and
.60, although that could be misleading. I do see
significant SMP-related changes in c-sb1.c between .29
and .60, and I am running in SMP. I wish there was an
easy way to know whether it's in the same code.
Anyway, in the interest of time I may revert to .27
which appears to work. I don't need any of the MT SMP
related changes that followed, and perhaps I can live
without the enhancements between .27 and .60 for now.
Never miss a thing. Make Yahoo your home page.