--On January 21, 2006 1:38:46 AM +0000 Alan Cox <[email protected]>
wrote:
On Gwe, 2006-01-20 at 13:56 -0700, Michael Loftis wrote:
and is fine once getty gets ahold of it, it's just during the initial
bootup phases where it's being used as the console either by the rc
scripts or by the kernel that seems to go wonky. It goes out during
the initial
A bug where the serial console could get stuck on SMP IFF a kernel and a
non kernel message were output at the same time did get fixed
(yesterday) other than that I'm not aware of any problems in this area
but the maintainer may have more ideas.
Diff is tiny if you want to see if that is what you hit, although it
would be remarkable co-incidence and luck if it was ;)
Coincidence I'm full of, and (bad) luck this week as well it seems. I want
to know who's black cat has been crossing my path. This gives me a better
direction to test it in. The machines I have the problem with are all
running SMP preemptible 2.6.8 on an HT machine with a single physical core,
I'll try putting or booting them into a non-SMP kernel...if it's suddenly
good, well....we found our rat. That would though explain it pretty well
since thinking about it, it doesn't happen in the debian installer nor... i
think it's one of the gentoo installers or something...and those are 386
non-SMP kernels.
Might've found some sort of wacky edge-case that can reproduce that bug
reliably. I'd be much appreciative if you pass a link or the diff itself
along to me (or a specific bit to look for in archives/etc). It might, or
might not, be my little gremlin. In the meantime I just leave off
console=ttyS1,38400 and hold my breath while they boot.
printk output, or sometimes later...exactly when seems to be a bit of a
random thing. Also it either causes, or is inputting NULL's or some
other (consistent) garbage (CRLF? instead of CR?) on these same blades.
So you
Never seen CR, nul reported. Would the blades happen to use rlogin to
manage this remote serial do you know ?
No...telnet...though...I just realised I haven't verified that on anything
but the BSD based telnet program on Mac OS X, and FreeBSD 4.11(ish), so
really, it might be something there too, but again, 2.4 never sees these
issues, and I'm really not sure what's getting into the stream, I think nul
because I get a '^@' translated back at me, which IIRC is the
representation for nul but lord knows if that's from the telnet client
after it echos or what, I haven't done a packet dump of this gremlin, yet.
I think I have more kernel bugs and can go on, but I'll just be told
'upgrade to 2.6.15' which is not an option in many cases if these are
indeed development releases, if only 'politically', but there are often
real costs involved. And with nowhere to put patches that end up in
Its hard to maintain an old release and just merge all the fixes into it
backporting when neccessary. At the kernel summit before 2.6 this was
discussed a lot. There are a small number of groups of people who wanted
this for the long term. Said groups either maintain such trees and sell
support/services for money, or rebuild the output of the former as a
community project.
It therefore seemed reasonable that those who want it should bear the
cost, or figure out how to maintain such backports between themselves.
OK atleast I'm not total net.kook here.
maintenance releases we're forced to maintain our own private forks, and
likely, because of the GPL, also publish these forks and incur all the
costs associated with that directly, and hope they don't become
popular/wanted outside of the customer base they're intended for, or
skirt the GPL, and only allow customers access to this stuff.
The GPL is very careful about this. If you ship the sources to your
customers then you have done your duty. If your customers choose to give
it to others so be it. If the others ask you for changes then I believe
the phrase is "business opportunity".
whatever their version numbers are. I'm in an odd position of working
for a web hosting company, *and* doing my own Linux consulting as well,
and maintaining some 'embedded distros' used in these specific niche
applications.
Embedded can be more problematic because it is harder to spread the
load, but there are communities of people who looked at things like Red
Hat Enterprise Linux and decided that they could use the code but didn't
currently need/want the training, support and services that are what
really makes it. One obvious example is Centos which is a community tree
derived from the RHEL work, rebuilt, rebranded without
support/services/etc and downloadable for free.
Yeah, embedded certainly is its own special little corner of heaven or hell
depending on your view, or whims.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
