Hi,
Jeff Garzik sent me a SATA update to be merged in 2.4.x.
A lot of new boxes are shipping with SATA-only disks, and its pretty bad
to not have a "stable" series without such industry-standard support.
This is the last feature to be merged on 2.4.x, and only because its quite
necessary.
Any oppositions?
Marcelo Tosatti wrote:
> Hi,
>
> Jeff Garzik sent me a SATA update to be merged in 2.4.x.
>
> A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> to not have a "stable" series without such industry-standard support.
>
> This is the last feature to be merged on 2.4.x, and only because its quite
> necessary.
>
> Any oppositions?
There are alternative ways* to get sata support for some chips but I
believe it's the right choice to do the 'full' route so I believe it's
the right choice. 2.4 will still be used for quite a while, especially
until "everybody" trusts 2.6, same way that happened with 2.2 and 2.4 ..
* siimage.c, add sata8237 entry to via driver, etc...
// Stefan
Marcelo Tosatti <[email protected]> writes:
> Jeff Garzik sent me a SATA update to be merged in 2.4.x.
>
> A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> to not have a "stable" series without such industry-standard support.
>
> This is the last feature to be merged on 2.4.x, and only because its quite
> necessary.
>
> Any oppositions?
The big problem is that the SATA code will move some disks from
/dev/hdX to /dev/sdX (e.g. most disks in modern intel chipsets) And
then the boxes don't boot anymore. It's probably a bad idea to merge
it.
-Andi
On Thu, Apr 15, 2004 at 09:24:09PM +0200, Andi Kleen wrote:
> Marcelo Tosatti <[email protected]> writes:
>
> > Jeff Garzik sent me a SATA update to be merged in 2.4.x.
> >
> > A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> > to not have a "stable" series without such industry-standard support.
> >
> > This is the last feature to be merged on 2.4.x, and only because its quite
> > necessary.
> >
> > Any oppositions?
>
> The big problem is that the SATA code will move some disks from
> /dev/hdX to /dev/sdX (e.g. most disks in modern intel chipsets) And
> then the boxes don't boot anymore. It's probably a bad idea to merge
> it.
This statement is false for the majority of the SATA drivers.
Further, ata_piix is not included in the merge.
Jeff
On Thu, Apr 15, 2004 at 09:24:09PM +0200, Andi Kleen wrote:
> Marcelo Tosatti <[email protected]> writes:
>
> > Jeff Garzik sent me a SATA update to be merged in 2.4.x.
> >
> > A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> > to not have a "stable" series without such industry-standard support.
> >
> > This is the last feature to be merged on 2.4.x, and only because its quite
> > necessary.
> >
> > Any oppositions?
>
> The big problem is that the SATA code will move some disks from
> /dev/hdX to /dev/sdX (e.g. most disks in modern intel chipsets) And
> then the boxes don't boot anymore. It's probably a bad idea to merge
> it.
Oh, this is also false for all the distro users which are _already_
using /dev/sdX for their disks.
They _have_ to patch in libata, otherwise the upstream kernel will break
their disks by changing them from /dev/hdX to /dev/sdX.
Another problem is that the upstream /dev/hdX driver locks up for a many
users, where libata does not.
Jeff
On Thursday 15 of April 2004 21:24, Andi Kleen wrote:
> Marcelo Tosatti <[email protected]> writes:
> > Jeff Garzik sent me a SATA update to be merged in 2.4.x.
> >
> > A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> > to not have a "stable" series without such industry-standard support.
> >
> > This is the last feature to be merged on 2.4.x, and only because its
> > quite necessary.
> >
> > Any oppositions?
>
> The big problem is that the SATA code will move some disks from
> /dev/hdX to /dev/sdX (e.g. most disks in modern intel chipsets) And
> then the boxes don't boot anymore. It's probably a bad idea to merge
> it.
ICH5 SATA and SiI3112 are the only affected chipsets.
You don't have to enable libata drivers for them or their
PCI IDs can be removed from the libata drivers if needed.
Bartlomiej
Marcelo Tosatti wrote:
> Hi,
>
> Jeff Garzik sent me a SATA update to be merged in 2.4.x.
>
> A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> to not have a "stable" series without such industry-standard support.
I also sent you a new driver that is unrelated to libata.
Jeff
On Thu, 15 Apr 2004, Bartlomiej Zolnierkiewicz wrote:
> ICH5 SATA and SiI3112 are the only affected chipsets.
> You don't have to enable libata drivers for them or their
> PCI IDs can be removed from the libata drivers if needed.
Hmm, do you mean that existent SATA drives on current 2.4.x kernels where
"seen" as /dev/hdX and with the SATA merge will be /dev/sdX ? I dont think
2.4.x supported SATA (at least not on Intel). I have a ICH5 motherboard
with one PATA drive and one SATA drive. With 2.6.5 kernel with support for
IDE PIIX (in the ATA section) and SATA PIIX (in the SCSI low level drivers
section) I see my PATA as /dev/hda and my SATA as /dev/sdb (I have another
SCSI disk on a SCSI controller which is /dev/sda). So it does seem to me
to do the right thing. Also on 2.4.25 with PIIX support I only saw the
PATA disk. In BIOS the PATA/SATA configuration is set to "Enhanced". More
informations:
ICH5: IDE controller at PCI slot 0000:00:1f.1
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
00:1f.1 IDE interface: Intel Corp.: Unknown device 25a2 (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Intel Corp.: Unknown device 342f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at <unassigned>
Region 1: I/O ports at <unassigned>
Region 2: I/O ports at <unassigned>
Region 3: I/O ports at <unassigned>
Region 4: I/O ports at fc00 [size=16]
Region 5: Memory at 40000000 (32-bit, non-prefetchable) [size=1K]
00:1f.2 IDE interface: Intel Corp.: Unknown device 25a3 (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Intel Corp.: Unknown device 342f
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at ec00 [size=8]
Region 1: I/O ports at e800 [size=4]
Region 2: I/O ports at e400 [size=8]
Region 3: I/O ports at e000 [size=4]
Region 4: I/O ports at dc00 [size=16]
> Bartlomiej
--
Mihai RUSU Email: [email protected]
GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net
"Linux is obsolete" -- AST
Marcelo,
To be RUDELY BLUNT! When in the hell did it matter in the past?
Recall your failure to include ATA133 and SATA 1.0 back in 2.4.16-19.
I actually object to it on the sheer principle of past history.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 15 Apr 2004, Marcelo Tosatti wrote:
> Hi,
>
> Jeff Garzik sent me a SATA update to be merged in 2.4.x.
>
> A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> to not have a "stable" series without such industry-standard support.
>
> This is the last feature to be merged on 2.4.x, and only because its quite
> necessary.
>
> Any oppositions?
> -
> 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/
>
Marcelo,
You are suggesting that 2.6 is not stable ? How could that be ?
Should it not be backported to 2.2 and why not 2.0 ?
What about the rest of the feature sets ?
Necessary? But their is the new and improved called 2.6.
It is time for the old and lousy to quietly wimper off and die.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 16 Apr 2004, Andre Hedrick wrote:
>
> Marcelo,
>
> To be RUDELY BLUNT! When in the hell did it matter in the past?
>
> Recall your failure to include ATA133 and SATA 1.0 back in 2.4.16-19.
>
> I actually object to it on the sheer principle of past history.
>
> Regards,
>
> Andre Hedrick
> LAD Storage Consulting Group
>
> On Thu, 15 Apr 2004, Marcelo Tosatti wrote:
>
> > Hi,
> >
> > Jeff Garzik sent me a SATA update to be merged in 2.4.x.
> >
> > A lot of new boxes are shipping with SATA-only disks, and its pretty bad
> > to not have a "stable" series without such industry-standard support.
> >
> > This is the last feature to be merged on 2.4.x, and only because its quite
> > necessary.
> >
> > Any oppositions?
> > -
> > 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/
> >
>
> -
> 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/
>
Quote from Andre Hedrick <[email protected]>:
> You are suggesting that 2.6 is not stable ? How could that be ?
It hasn't exactly been audited for security issues yet.
John.
On Fri, 2004-04-16 at 12:20, John Bradford wrote:
> Quote from Andre Hedrick <[email protected]>:
> > You are suggesting that 2.6 is not stable ? How could that be ?
>
> It hasn't exactly been audited for security issues yet.
neither has the biggest part of the 2.4 codebase.
Quote from Arjan van de Ven <[email protected]>:
>
> --=-De0mPL9BnMYZGB8TurTV
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Fri, 2004-04-16 at 12:20, John Bradford wrote:
> > Quote from Andre Hedrick <[email protected]>:
> > > You are suggesting that 2.6 is not stable ? How could that be ?
> >=20
> > It hasn't exactly been audited for security issues yet.
>
> neither has the biggest part of the 2.4 codebase.
A valid point, but last time I checked, there were known exploits that had
been fixed in 2.4 but not in 2.6.
John.
On Fri, Apr 16, 2004 at 11:30:53AM +0100, John Bradford wrote:
> Quote from Arjan van de Ven <[email protected]>:
> >
> > --=-De0mPL9BnMYZGB8TurTV
> > Content-Type: text/plain
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Fri, 2004-04-16 at 12:20, John Bradford wrote:
> > > Quote from Andre Hedrick <[email protected]>:
> > > > You are suggesting that 2.6 is not stable ? How could that be ?
> > >=20
> > > It hasn't exactly been audited for security issues yet.
> >
> > neither has the biggest part of the 2.4 codebase.
>
> A valid point, but last time I checked, there were known exploits that had
> been fixed in 2.4 but not in 2.6.
maybe you should check again and report what you find because I for sure
can't think of any.
Since we are going over the cliff, lets get there faster!
Has 2.2 or 2.0 ever been audited for security issues, and fixed?
Whee this is fun!
Andre Hedrick
LAD Storage Consulting Group
On Fri, 16 Apr 2004, John Bradford wrote:
> Quote from Arjan van de Ven <[email protected]>:
> >
> > --=-De0mPL9BnMYZGB8TurTV
> > Content-Type: text/plain
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Fri, 2004-04-16 at 12:20, John Bradford wrote:
> > > Quote from Andre Hedrick <[email protected]>:
> > > > You are suggesting that 2.6 is not stable ? How could that be ?
> > >=20
> > > It hasn't exactly been audited for security issues yet.
> >
> > neither has the biggest part of the 2.4 codebase.
>
> A valid point, but last time I checked, there were known exploits that had
> been fixed in 2.4 but not in 2.6.
>
> John.
>
Quote from Arjan van de Ven <[email protected]>:
>
> --g7w8+K/95kPelPD2
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Fri, Apr 16, 2004 at 11:30:53AM +0100, John Bradford wrote:
> > Quote from Arjan van de Ven <[email protected]>:
> > >
> > > --=-De0mPL9BnMYZGB8TurTV
> > > Content-Type: text/plain
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > On Fri, 2004-04-16 at 12:20, John Bradford wrote:
> > > > Quote from Andre Hedrick <[email protected]>:
> > > > > You are suggesting that 2.6 is not stable ? How could that be ?
> > > >=20
> > > > It hasn't exactly been audited for security issues yet.
> > >
> > > neither has the biggest part of the 2.4 codebase.
> >
> > A valid point, but last time I checked, there were known exploits that had
> > been fixed in 2.4 but not in 2.6.
>
> maybe you should check again and report what you find because I for sure
> can't think of any.
I honestly don't have the time to go through the archives at the moment, and
having been busy, I could well have missed any fixes that have gone in during
the last couple of releases, but I am 99% sure that Alan identified a couple
of local root exploits around 2.6.0 that had been fixed in 2.4 but never
applied to 2.6.
John.
On Fri, Apr 16, 2004 at 01:37:09PM +0100, John Bradford wrote:
> of local root exploits around 2.6.0 that had been fixed in 2.4 but never
> applied to 2.6.
we're at 2.6.6-rc1 now, and afaik all those got applied.
On Friday 16 April 2004 14:37, John Bradford wrote:
Hi,
> > > A valid point, but last time I checked, there were known exploits that
> > > had been fixed in 2.4 but not in 2.6.
> > maybe you should check again and report what you find because I for sure
> > can't think of any.
> I honestly don't have the time to go through the archives at the moment,
> and having been busy, I could well have missed any fixes that have gone in
> during the last couple of releases, but I am 99% sure that Alan identified
> a couple of local root exploits around 2.6.0 that had been fixed in 2.4 but
> never applied to 2.6.
well, last time I checked that (some weeks ago), also reading must-fix.txt,
all 2.4 security fixes are in 2.6 now too. IMHO we should update must-fix.txt
so it does not tell there are 60-70 security vulns not fixed yet.
ciao, Marc
Quote from Andre Hedrick <[email protected]>:
>
> Since we are going over the cliff, lets get there faster!
>
> Has 2.2 or 2.0 ever been audited for security issues, and fixed?
>
> Whee this is fun!
I don't really see the relevence of what you're saying.
Maybe I wasn't clear when I said 'audited for security issues' - I meant
ensuring that fixes for 2.4 also eventually went in to 2.6. I'm not talking
about doing any kind of complete audit of the entire codebase.
For a long time, (since before 2.6.0), there were known local root exploits
that had been fixed in 2.4 and not in 2.6. I never saw those fixed, but I
don't have the details of them to hand, nor do I have the time to search
through years of mailing list archives at the moment. However, I am also not
claiming that 2.6 is stable, (yet).
John.
On Fri, Apr 16, 2004 at 02:29:16AM -0700, Andre Hedrick wrote:
>
> Marcelo,
>
> To be RUDELY BLUNT! When in the hell did it matter in the past?
>
> Recall your failure to include ATA133 and SATA 1.0 back in 2.4.16-19.
ATA133 was merged by Alan Cox in 2.4.21. SATA 1.0 was posted by Jeff in the past,
but I preferred to hold it for a while (to make sure its more stable).
It now seems Jeff is more confident with it.
> I actually object to it on the sheer principle of past history.
This is a special case. I dont see any good arguments to not merge it
from you.
On Fri, Apr 16, 2004 at 10:51:02AM -0300, Marcelo Tosatti wrote:
>
> Marcelo,
>
> You are suggesting that 2.6 is not stable ? How could that be ?
It is stable, but some people still use 2.4 for production machines, and
will still do for sometime.
> Should it not be backported to 2.2 and why not 2.0 ?
The amount of people using 2.2/2.0 and SATA is probably small.
But sure, why dont you start the backport ?
> What about the rest of the feature sets ?
This is not like "the rest of the feature sets", this is
basic functionality needed to support new systems in the market.
And again, unfortunately not everyone is running v2.6 on their production
environment, yet.
> Necessary? But their is the new and improved called 2.6.
> It is time for the old and lousy to quietly wimper off and die.
Right, the old and lousy should wimper off and die. But this is
a special case (a lot of people are applying SATA by hand, look at lkml).
On Fri, Apr 16, 2004 at 10:51:02AM -0300, Marcelo Tosatti wrote:
>
> Marcelo,
>
> You are suggesting that 2.6 is not stable ? How could that be ?
>
>It is stable, but some people still use 2.4 for production machines,
>and will still do for sometime.
>
Now, while I truly believe that the situation with 2.6 is much better
than 2.4, we should not forget that a lot of people would not call any
2.4.X stable, with X<18 (that number may vary :-).
Some more "conservative" outfits will use some 2.4.X for quite a long
time. Even on new hardware. Continuity, you know. Maybe stupid, maybe
annoying, but is a fact of life.
Martin
=====
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
> Marcelo,
>
> You are suggesting that 2.6 is not stable ? How could that be ?
Andre, ressure me, you were drunk ?
A stable kernel is a kernel in which a new release does not induce 20 rejects
when applying the same patches as on the previous one, and in which you can
confidently upgrade to fix a security issue without worrying that everything
else will break under your feet. I'm really happy that 2.4 *WILL* become
stable with 2.4.27, and probably will be the first 2.4 kernel ready for far
remote deployment. Since about 2.4.23, it has become a lot easier to maintain
up-to-date parallel trees in sync with Marcelo's because of less core changes
all the time, and I really thank him for this progressive feature freeze.
When I'll have a fair insurance that 2.6 does not change so fast, may be I'll
start to think about it. But right now, 2.6 only serves me as a boot loader
in conjunction with Randy's kexec patch. Sad but true.
> Should it not be backported to 2.2 and why not 2.0 ?
I thought you were more aware than that about the number of people still
using 2.0 and 2.2. They are "a lot". What does "a lot" mean ? Well, I think
that there are more people still running production machines on 2.2 and 2.0
than people who have ever used 1.0 or 1.2. And at these times, we considered
that "a lot". I know some people who still install RedHat 6.2 from time to
time. Why do they do this ? certainly because a standard 2.2.26 kernel +
grsecurity offers them enough stability and security to satisfy their needs
and not to have to upgrade every 4 months.
> Necessary? But their is the new and improved called 2.6.
> It is time for the old and lousy to quietly wimper off and die.
I would better say that it's time for the old and stable to live long and
quitely, and for the young baby to slowly discover the desktop world, then
the production world before engaging its reputation on mission-critical
systems.
Regards,
Willy
Marcelo Tosatti wrote:
> On Fri, Apr 16, 2004 at 10:51:02AM -0300, Marcelo Tosatti wrote:
> And again, unfortunately not everyone is running v2.6 on their production
> environment, yet.
That's right! I certainly won't run it before 2.6.20 or even higher on
desktops. For example, 2.6 vanilla is much to slow (about 9%), even on
desktops - tested with compiling. It must be fixed.
Another example: My production servers (a cluster system) are running fine
and rockstable since years with 2.2.x.
Regards,
Andreas Hartmann
Willy,
I do not drink. I have enough trouble keeping friends when I am sobber.
Sheesh, I worked for Merkey before and drinking and posting is a bad idea.
Point being, it was not important in the beginning ... so it is not
important now. Being consistant is one thing I have always been.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 16 Apr 2004, Willy Tarreau wrote:
> > Marcelo,
> >
> > You are suggesting that 2.6 is not stable ? How could that be ?
>
> Andre, ressure me, you were drunk ?
>
> A stable kernel is a kernel in which a new release does not induce 20 rejects
> when applying the same patches as on the previous one, and in which you can
> confidently upgrade to fix a security issue without worrying that everything
> else will break under your feet. I'm really happy that 2.4 *WILL* become
> stable with 2.4.27, and probably will be the first 2.4 kernel ready for far
> remote deployment. Since about 2.4.23, it has become a lot easier to maintain
> up-to-date parallel trees in sync with Marcelo's because of less core changes
> all the time, and I really thank him for this progressive feature freeze.
> When I'll have a fair insurance that 2.6 does not change so fast, may be I'll
> start to think about it. But right now, 2.6 only serves me as a boot loader
> in conjunction with Randy's kexec patch. Sad but true.
>
> > Should it not be backported to 2.2 and why not 2.0 ?
>
> I thought you were more aware than that about the number of people still
> using 2.0 and 2.2. They are "a lot". What does "a lot" mean ? Well, I think
> that there are more people still running production machines on 2.2 and 2.0
> than people who have ever used 1.0 or 1.2. And at these times, we considered
> that "a lot". I know some people who still install RedHat 6.2 from time to
> time. Why do they do this ? certainly because a standard 2.2.26 kernel +
> grsecurity offers them enough stability and security to satisfy their needs
> and not to have to upgrade every 4 months.
>
> > Necessary? But their is the new and improved called 2.6.
> > It is time for the old and lousy to quietly wimper off and die.
>
> I would better say that it's time for the old and stable to live long and
> quitely, and for the young baby to slowly discover the desktop world, then
> the production world before engaging its reputation on mission-critical
> systems.
>
> Regards,
> Willy
>
> -
> 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/
>
Andreas Hartmann <[email protected]> writes:
> Marcelo Tosatti wrote:
>> On Fri, Apr 16, 2004 at 10:51:02AM -0300, Marcelo Tosatti wrote:
>> And again, unfortunately not everyone is running v2.6 on their production
>> environment, yet.
>
> That's right! I certainly won't run it before 2.6.20 or even higher on
> desktops. For example, 2.6 vanilla is much to slow (about 9%), even on
> desktops - tested with compiling. It must be fixed.
This most likely comes from the 1ms timer tick vs 10ms previously. I
doubt this will change in mainline, but you can change it yourself
with an easy tweak. Just change the HZ parameter back to 100
-Andi
On Sat, 17 Apr 2004 13:36:11 +0200, Andi Kleen wrote:
>Andreas Hartmann <[email protected]> writes:
>
>> Marcelo Tosatti wrote:
>>> On Fri, Apr 16, 2004 at 10:51:02AM -0300, Marcelo Tosatti wrote:
>>> And again, unfortunately not everyone is running v2.6 on their production
>>> environment, yet.
>>
>> That's right! I certainly won't run it before 2.6.20 or even higher on
>> desktops. For example, 2.6 vanilla is much to slow (about 9%), even on
>> desktops - tested with compiling. It must be fixed.
>
>This most likely comes from the 1ms timer tick vs 10ms previously. I
>doubt this will change in mainline, but you can change it yourself
>with an easy tweak. Just change the HZ parameter back to 100
I have a patch which adds CONFIG_HZ for the i386 and ppc architectures,
allowing you to choose HZ==1000, HZ==100, or HZ=512. I originally wrote
it because my oldest test box (a 486) loses lots of timer interrupts
during heavy disk I/O otherwise, but I also use it on less handicapped
boxes because I find HZ==1000 to be wasteful and of little value for me.
http://www.csd.uu.se/~mikpe/linux/patches/2.6/patch-config-hz-2.6.6-rc1
/Mikael