Hi,
I need help and/or advice on the following problem:
New mainboard platfrom with latest chipset from a chipset vendor that
can't do the job that we are asking for. The chipset (especially the
SATA controller is supported in Kernel 2.6.24 and later.
The target market for those boards is using old fashioned distributions
like CentOS, Debian, Fedora 8 openSUSE 10 and so on. So the gap is that
the latest driver from 2.6.24 is not yet in those distributions. The
impact of this is that the customer in the target market can't use the
mainboards to run actual Linux distributions on them.
So there is a need ot backport e.g. the AHCI driver from 2.6.24 to
2.6.16 or 2.6.18. Doing a diff on the sources makes me think this is a
sort of "mission impossible" since it sureley isn't just the ahci code
that changed but also a lot in the kernel infrastructure meanwhile.
So what options do we have to help the customer? Changing to 2.6.24
kernel is not an option due to the customer. So it looks like the
only way to "solve" this is a backport, but then we come to "who can
do this?".
Any hints welcome and thanks a lot for your attention
Rainer
--
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Business Clients
Dept. IP BC E SW OS
Fujitsu Siemens Computers
Bürgermeister-Ullrich-Str. 100
86199 Augsburg
Germany
Telephone: +49-821-804-3321
Telefax: +49-821-804-2131
Mail: mailto:[email protected]
Internet http://www.fujitsu-siemens.com
Company Details http://www.fujitsu-siemens.com/imprint.html
On Tuesday 2008-06-03 12:47, Rainer Koenig wrote:
>
>New mainboard platfrom with latest chipset from a chipset vendor that
>can't do the job that we are asking for. The chipset (especially the
>SATA controller is supported in Kernel 2.6.24 and later.
>
>The target market for those boards is using old fashioned distributions
>like CentOS, Debian, Fedora 8 openSUSE 10 and so on.
Wait a minute, that seems like an impossible dependency.
These boards cannot be targeted for these distro versions,
because the manufacturer knows (hopefully) that the shipped
kernel versions do not have the driver with the required
new code.
Rainer Koenig wrote:
> New mainboard platfrom with latest chipset from a chipset vendor that
> can't do the job that we are asking for. The chipset (especially the
> SATA controller is supported in Kernel 2.6.24 and later.
>
> The target market for those boards is using old fashioned distributions
> like CentOS, Debian, Fedora 8 openSUSE 10 and so on. So the gap is that
> the latest driver from 2.6.24 is not yet in those distributions.
Debian will offer the option to install a system using 2.6.24 with its
next update for Etch (stable). That point release is expected within the
next few weeks.
Cheers,
FJP
Frans Pop writes:
> Rainer Koenig wrote:
> > New mainboard platfrom with latest chipset from a chipset vendor that
> > can't do the job that we are asking for. The chipset (especially the
> > SATA controller is supported in Kernel 2.6.24 and later.
> >
> > The target market for those boards is using old fashioned distributions
> > like CentOS, Debian, Fedora 8 openSUSE 10 and so on. So the gap is that
> > the latest driver from 2.6.24 is not yet in those distributions.
>
> Debian will offer the option to install a system using 2.6.24 with its
> next update for Etch (stable). That point release is expected within the
> next few weeks.
Redhat seems to regularly backport the entire libata layer
to at least 2.6.18 (RHEL5) and maybe also 2.6.9 (RHEL4).
Rainer Koenig wrote:
> Hi,
>
> I need help and/or advice on the following problem:
>
> New mainboard platfrom with latest chipset from a chipset vendor that
> can't do the job that we are asking for. The chipset (especially the
> SATA controller is supported in Kernel 2.6.24 and later.
>
> The target market for those boards is using old fashioned distributions
> like CentOS, Debian, Fedora 8 openSUSE 10 and so on. So the gap is that
> the latest driver from 2.6.24 is not yet in those distributions. The
> impact of this is that the customer in the target market can't use the
> mainboards to run actual Linux distributions on them.
>
> So there is a need ot backport e.g. the AHCI driver from 2.6.24 to
> 2.6.16 or 2.6.18. Doing a diff on the sources makes me think this is a
> sort of "mission impossible" since it sureley isn't just the ahci code
> that changed but also a lot in the kernel infrastructure meanwhile.
>
> So what options do we have to help the customer? Changing to 2.6.24
> kernel is not an option due to the customer. So it looks like the
> only way to "solve" this is a backport, but then we come to "who can
> do this?".
..
I regularly do backports of libata stuff for various clients.
Contact me directly if you feel you really need this service.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
[email protected]
Hi Jan,
Am Dienstag, 3. Juni 2008 13:37 schrieb Jan Engelhardt:
> >The target market for those boards is using old fashioned
> > distributions like CentOS, Debian, Fedora 8 openSUSE 10 and so on.
>
> Wait a minute, that seems like an impossible dependency.
> These boards cannot be targeted for these distro versions,
> because the manufacturer knows (hopefully) that the shipped
> kernel versions do not have the driver with the required
> new code.
Yes, of course the manufacturer knows. But the customer wants to get the
benefits from the new chipset technologie (e.g. support for quad core
processors). The problem that we are facing is that we can't tell the
customer "You cannot install actual Linux distributions", especially
not when your customer is a firm that offers hosting services based on
that platform. :-)
This is a general problem that we frequently face with Linux. Whenever a
new piece of silicon is released it takes a while until the driver for
that (even if it just requires the addition of a device ID) is reaching
the distributions. In the worst case the hardware platform will be "out
of sale" when the driver finally hits the distributions. :-/
So in the actual case we really suffer from a chipset that is not fully
supported by the distribution kernels.
Thanks
Rainer
--
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Business Clients
Dept. IP BC E SW OS
Fujitsu Siemens Computers
B?rgermeister-Ullrich-Str. 100
86199 Augsburg
Germany
Telephone: +49-821-804-3321
Telefax: +49-821-804-2131
Mail: mailto:[email protected]
Internet http://www.fujitsu-siemens.com
Company Details http://www.fujitsu-siemens.com/imprint.html
Hi Mikael,
Am Dienstag, 3. Juni 2008 14:07 schrieb Mikael Pettersson:
> Redhat seems to regularly backport the entire libata layer
> to at least 2.6.18 (RHEL5) and maybe also 2.6.9 (RHEL4).
Yes indeed we get perfect support from both Red Hat and SUSE for their
enterprise level distribution. I already got a driver kit for the
SLES10 kernel. The problem is that the targeted market is not willing
to use enterprise level (which means spend money for subscription)
distros. They go for the "free" (as in free beer) distros and suffer
from missing drivers.
Regards
Rainer
--
Dipl.-Inf. (FH) Rainer Koenig
Project Manager Linux Business Clients
Dept. IP BC E SW OS
Fujitsu Siemens Computers
B?rgermeister-Ullrich-Str. 100
86199 Augsburg
Germany
Telephone: +49-821-804-3321
Telefax: +49-821-804-2131
Mail: mailto:[email protected]
Internet http://www.fujitsu-siemens.com
Company Details http://www.fujitsu-siemens.com/imprint.html
Rainer Koenig writes:
> Hi Mikael,
>
> Am Dienstag, 3. Juni 2008 14:07 schrieb Mikael Pettersson:
> > Redhat seems to regularly backport the entire libata layer
> > to at least 2.6.18 (RHEL5) and maybe also 2.6.9 (RHEL4).
>
> Yes indeed we get perfect support from both Red Hat and SUSE for their
> enterprise level distribution. I already got a driver kit for the
> SLES10 kernel. The problem is that the targeted market is not willing
> to use enterprise level (which means spend money for subscription)
> distros. They go for the "free" (as in free beer) distros and suffer
> from missing drivers.
a) the RHEL sources are freely available
b) lots of people and organisations grab, tweak, and build them
(including I might add many HPC sites using perfctr)
c) there's at least one no-cost binary redistribution (CentOS)
d) it's also easy to combine e.g. FC user-space with a
self-compiled RHEL kernel, at least as long as they're
closely matched (e.g. FC6 + RHEL5 is fine)
(heck, I've even run FC6 on top of a SLES10.1 kernel)
So everything's that's needed is out there.
On Wed, 4 Jun 2008, Rainer Koenig wrote:
> Hi Mikael,
>
> Am Dienstag, 3. Juni 2008 14:07 schrieb Mikael Pettersson:
> > Redhat seems to regularly backport the entire libata layer
> > to at least 2.6.18 (RHEL5) and maybe also 2.6.9 (RHEL4).
>
> Yes indeed we get perfect support from both Red Hat and SUSE for their
> enterprise level distribution. I already got a driver kit for the
> SLES10 kernel. The problem is that the targeted market is not willing
> to use enterprise level (which means spend money for subscription)
> distros. They go for the "free" (as in free beer) distros and suffer
> from missing drivers.
>
Why not just create custom boot cds with the newer kernel for each distro?
It seems like less work.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
Rainer Koenig <Rainer.Koenig <at> fujitsu-siemens.com> writes:
>
> Hi Jan,
>
> Am Dienstag, 3. Juni 2008 13:37 schrieb Jan Engelhardt:
> > >The target market for those boards is using old fashioned
> > > distributions like CentOS, Debian, Fedora 8 openSUSE 10 and so on.
> >
> > Wait a minute, that seems like an impossible dependency.
> > These boards cannot be targeted for these distro versions,
> > because the manufacturer knows (hopefully) that the shipped
> > kernel versions do not have the driver with the required
> > new code.
>
> Yes, of course the manufacturer knows. But the customer wants to get the
> benefits from the new chipset technologie (e.g. support for quad core
> processors). The problem that we are facing is that we can't tell the
> customer "You cannot install actual Linux distributions", especially
> not when your customer is a firm that offers hosting services based on
> that platform.
Fedora 8 may not work but Fedora 9 will work out of the box.
You've stated RHEL works. That means Centos will work too eventually if it's not
working already.
So on the RHEL/Centos/Fedora side you're already ok. Previous versions won't
work, but the Linux support model is to upgrade systems not maintain old ones on
life support indefinitely. The only way to shorten the hardware release to new
distro support time is to get drivers in kernel.org earlier.
On Wed, 2008-06-04 06:50:12 +0200, Rainer Koenig <[email protected]> wrote:
> Am Dienstag, 3. Juni 2008 14:07 schrieb Mikael Pettersson:
> > Redhat seems to regularly backport the entire libata layer
> > to at least 2.6.18 (RHEL5) and maybe also 2.6.9 (RHEL4).
>
> Yes indeed we get perfect support from both Red Hat and SUSE for their
> enterprise level distribution. I already got a driver kit for the
> SLES10 kernel. The problem is that the targeted market is not willing
> to use enterprise level (which means spend money for subscription)
> distros. They go for the "free" (as in free beer) distros and suffer
> from missing drivers.
Erm... Maybe you'd install a newer version of eg. Debian. At least
here, I have:
jbglaw@jblaptop:~$ uname -a
Linux jblaptop 2.6.25-2-686 #1 SMP Tue May 27 15:38:35 UTC 2008 i686 GNU/Linux
jbglaw@jblaptop:~$
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: Don't believe in miracles: Rely on them!
the second :