Skip to contentSkip to conversation

post-halloween 0.2

DISCUSSION Dave Jones 19 participants 34 messages Oct 30, 2002 – Nov 7, 2002

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

I updated the list of various things that wannabe testers might hit. If theres something I missed let me know, and I'll get it right next time round..

Dave

The post-halloween document. v0.2
(aka, 2.5 - what to expect)

Dave Jones <[email protected]>

This document explains some of the new functionality to be found in the 2.5 Linux kernel, some pitfalls you may encounter, and also points out some new features which could really use testing.
Note, that "contact [email protected]" below also implies that you should also
cc: [email protected].

Latest version of this document can always be found at
http://www.codemonkey.org.uk/post-halloween-2.5.txt

Regressions:
~~~~~~~~~~~~
(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional.
- Various SCSI drivers still need work, and don't even compile.
- software suspend is still in development, and in need of more work. It is unlikely to work as expected currently.
- Some filesystems still need work (Coda, Intermezzo).

Deprecated features:
~~~~~~~~~~~~~~~~~~~~
- khttpd is gone.
- Older Direct Rendering Manager (DRM) support (For XFree86 4.0) has been removed. Upgrade to XFree86 4.1.0 or higher.

IO subsystem.
~~~~~~~~~~~~~
You should notice considerable throughput improvements over 2.4 due to much reworking of the block and the memory management layers. Report any regressions in this area to Jens Axboe <[email protected]> and Andrew Morton <[email protected]>.

Assorted changes throughout the block layer meant various block device drivers had a large scale cleanup whilst being updated to newer APIs.

Kernel preemption.
~~~~~~~~~~~~~~~~~~
The much talked about preemption patches made it into 2.5. With this included you should notice much lower latencies especially in demanding multimedia applications.
Note, there are still cases where preemption must be temporarily disabled where we do not. If you get "xxx exited with preempt count=n" messages in syslog, don't panic, these are non fatal, but are somewhat unclean. Report such cases (and any other preemption related problems) to [email protected]

O(1) Scheduling improvements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another much talked about feature. Ingo Molnar reworked the process scheduler to use an O(1) algorithm. In operation, you should notice no changes with low loads, and increased scalability with large numbers of processes, especially on large SMP systems. Regressions to [email protected]

Input layer
~~~~~~~~~~~
Possibly the most visible change to the end user. If misconfigured, you'll find that your keyboard/mouse/other input device will no longer work. 2.5 offers a much more flexable interface to devices such as keyboards. The downside is more confusing options.
In the "Input device support" menu, be sure to enable at least the following.

--- Input I/O drivers
< > Serial i/o support
< > i8042 PC Keyboard controller
[ ] Keyboards
[ ] Mice

(Also choose the relevant keyboard/mouse from the list)

If you find your keyboard/mouse still don't work, edit the file drivers/input/serio/i8042.c, and replace the #undef DEBUG with a #define DEBUG

When you boot, you should now see a lot more debugging information. Forward this information to Vojtech Pavlik <[email protected]>

If you use a KVM switcher, and experience problems, booting with the boot time argument 'psmouse_noext' should fix your problems.

PnP layer
~~~~~~~~~
Support for plug and play devices such as early ISAPNP cards has improved a lot in the 2.5 kernel. You should no longer need to futz with userspace tools to configure IRQ's and the likes. Report any regressions in plug & play functionality to Adam Belay <[email protected]>

ALSA
~~~~
The advanced linux sound architecture got merged into 2.5. This offers considerably improved functionality over the older OSS drivers, but requires new userspace tools. Several distros have shipped ALSA for some time, so you may already have the necessary tools. If not, you can find them at http://www.alsa-project.org/
(Note that the OSS drivers are also still functional, and
still present)

procps
~~~~~~
The 2.5 /proc filesystems exports more statistics, which confuse older versions of procps. Rik van Riel and Robert Love have been maintaining a forked version of procps during the 2.5 cycle, which you can find at http://tech9.net/rml/procps/

Framebuffer layer
~~~~~~~~~~~~~~~~~
James Simmons has reworked the framebuffer/console layer considerably during 2.5. Support for some cards is still lagging a little, but it should be functionally no different than previous incarnations.

IDE
~~~
The IDE code was subject to much criticism in early 2.5.x, which put off a lot of people from testing. This work was then subsequently dropped, and reverted back to a 2.4.18 IDE status.
(Since then additional work has occured, but not to the extent
of the first cleanup attempts).
Additional work on the ATA code is happening in 2.4-ac, and pending merging to 2.5

IDE TCQ
~~~~~~~
Tagged command queueing for IDE devices has been included. Not all devices may like this, so handle with care. If you didn't choose the "TCQ on by default" option, you can enable it by using the command

echo "using_tcq:32" > /proc/ide/hdX/settings
(replacing 32 with 0 disables TCQ again).
Report success/failure stories to Jens Axboe <[email protected]> with inclusion of hdparm -i /dev/hdX

v4l2
~~~~
The video4linux API finally got its long awaited cleanup. xawtv, bttv and most other existing v4l tools are also compatable with the new v4l2 layer. You should notice no loss in functionality.
http://bytesex.org/v4l/

Quota reworking
~~~~~~~~~~~~~~~
The new quota system needs new tools. ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/alpha/quota-3.05-pre1.tar.gz

CD Recording
~~~~~~~~~~~~
Jens Axboe added the ability to use DMA for writing CDs on ATAPI devices. Writing CDs should be much faster than it was in 2.4, and also less prone to buffer underruns and the like. Updated cdrecord in rpm and tar.gz can be found at *.kernel.org/pub/linux/kernel/people/axboe/tools/

With the above tools, you also no longer need ide-scsi in order to use an IDE CD writer.

Ripping audio tracks off of CDs now also uses DMA and should be notably faster. You can also find an updated cdda2wav at the same location.

Send good/bad reports of audio extraction with cdda2wav and burning with cdrecord to Jens Axboe <[email protected]>

More info at http://lwn.net/Articles/13538/ & http://lwn.net/Articles/13160/

Filesystems:
~~~~~~~~~~~~
A number of additional filesystems have made their way into 2.5. Whilst these have had testing out of tree, the level of testing after merging is unparalleled. Be wary of trusting data to immature filesystems. A number of new features and improvements have also been made to the existing filesystems from 2.4.

Reports of stress testing with the various tools available would be beneficial.

NFS
~~~
Support has been added for NFSv4 (server and client), and additionally, NFS over TCP. Reports of interoperability with other OS's would be useful.

driverfs
~~~~~~~~
In simple terms, the driverfs filesystem is a saner way for drivers to export their innards than /proc.
This filesystem is always compiled in, and can be mounted just like another virtual filesystem. No userspace tools beyond cat and echo are needed.

mount -t driverfs none /sys

*NB*, at some point the name of this filesystem will be changing to sysfs. See Documentation/filesystems/sysfs.txt for more info.

XFS
~~~
The SGI XFS filesystem has been merged, and has a number of userspace features. Users are encouraged to read http://oss.sgi.com/project
for more information.
The various utilties for creating and manipulating XFS volumes can
be found on SGI's ftp server.. ftp://oss.sgi.com/projects/xfs/download/download/cmd_tars/xfsprogs-2.2.2.src.tar.gz

CIFS
~~~~
Support utilities and documentation for the common internet file system (CIFS) can be found at http://us1.samba.org/samba/Linux_CIFS_client.html

EXT3 Htree support.
~~~~~~~~~~~~~~~~~~~
The ext3 filesystem has gained indexed directory support, which offers considerable performance gains when used on filesystems with large directories. In order to use the htree feature, you need at least version 1.29 of e2fsprogs. Existing filesystems can be converted using the command "tune2fs -O dir_index /dev/hdXXX" The latest e2fsprogs can be found at http://prdownloads.sourceforge.net/e2fsprogs

Oprofile.
~~~~~~~~~
A system wide performance profiler has been included in 2.5. The userspace utilities for this are very young, and still being developed. You can find out more at http://oprofile.sourceforge.net/oprofile-2.5.html

Simple boot flag support.
~~~~~~~~~~~~~~~~~~~~~~~~~
The SBF specification is an x86 BIOS extension that allows improved system boot speeds. It does this by marking a CMOS field to say
"I booted okay, skip extensive POST next reboot".
Userspace tool is at http://www.codemonkey.org.uk/cruft/sbf-0.3.c
More info on SBF is at http://www.microsoft.com/hwdev/resources/specs/simp_bios.asp

x86 CPU detection.
~~~~~~~~~~~~~~~~~~
The CPU detection code got a pretty hefty shake up. To be certain your CPU has all relevant workarounds applied, be sure to check that it was detected correctly. cat /proc/cpuinfo will tell what the kernel thinks it is. Likewise, the x86 MTRR driver got a considerable makeover.
Any regressions in both should go to [email protected]

Extra tainting.
~~~~~~~~~~~~~~~
Running certain AMD processors in SMP boxes is out of spec, and will taint the kernel with the 'S' flag. Running 2 Athlon XPs for example may seem to work fine, but may also introduce difficult to pin down bugs. In time it's likely this tainting will be extended to cover other out of spec cases.

Power management.
~~~~~~~~~~~~~~~~~
2.5 contains a more up to date snapshot of the ACPI driver. Should you experience any problems booting, try booting with the argument "acpi=off" to rule out any ACPI interaction. ACPI has a much more involved role in bringing the system up in 2.5 than it did in 2.4
The old "acpismp=force" boot option is now obsolete, and will be ignored due to the old "mini ACPI" parser being removed.

CPU frequency scaling.
~~~~~~~~~~~~~~~~~~~~~~
Certain processors have the facility to scale their voltage/clockspeed. 2.5 introduces an interface to this feature, see Documentation/cpufreq for more information. This functionality also covers features like Intel's speedstep, and will be extended in time to cover the Powernow feature present in mobile Athlons.

Background polling of MCE
~~~~~~~~~~~~~~~~~~~~~~~~~
The machine check handler has been extended so that it regularly polls for any problems on AMD Athlon systems. This may result in machine check exceptions occuring more frequently than they did in 2.4 on out of spec systems (Overclocking/poor cooling/underated PSU etc..).

LVM2 - DeviceMapper.
~~~~~~~~~~~~~~~~~~~~
The LVM code got a massive overhaul (read as: replacement). This means new tools are needed to manage the device mapper. You can get these from ftp://ftp.sistina.com/pub/LVM2/tools/

Debugging options.
~~~~~~~~~~~~~~~~~~
During the stabilising period, it's likely that the debugging options in the kernel hacking menu will trigger quite a few problems. Please report any of these problems to [email protected] rather than just disabling the relevant CONFIG_ options.

TODO
~~~~
- Reiser4 ?
http://www.namesys.com/snapshots/2002.10.29/reiser4progs-0.1.0.tar.gz
- ipsec ?
- ebtables
- compilers
When compiled with a modern gcc (Ie gcc 3.x), 2.5 will use additional optimisations that 2.4 didn't. This may shake out compiler bugs that 2.4 didn't expose. The recommended compiler is still 2.95.3.
- boot time root= parsing changed.
ramdisks now have ram<n> isntead of rd<n> and cm206 - cm206cd (instead of cm206).

Signature · 1 line
| Dave Jones.        http://www.codemonkey.org.uk
#1 lore raw
Quoted 5 lines · Dave Jones

driverfs
~~~~~~~~
[...]
*NB*, at some point the name of this filesystem will be changing to sysfs. See Documentation/filesystems/sysfs.txt for more info.

Probably have to wait until we push the rock up the hill again.

ian

#2 lore raw
Quoted 9 lines · Ian Soboroff
Quoted 5 lines · Dave Jones

driverfs
~~~~~~~~
[...]
*NB*, at some point the name of this filesystem will be changing to sysfs. See Documentation/filesystems/sysfs.txt for more info.

Probably have to wait until we push the rock up the hill again.

What do you mean? This should happen in the next few kernel releases.

thanks,

greg k-h

#3 lore raw
Quoted 9 lines · Greg KH
Quoted 8 lines · Ian Soboroff
Quoted 5 lines · Dave Jones

driverfs
~~~~~~~~
[...]
*NB*, at some point the name of this filesystem will be changing to sysfs. See Documentation/filesystems/sysfs.txt for more info.

Quoted 3 lines
Quoted 1 line

Probably have to wait until we push the rock up the hill again.

What do you mean? This should happen in the next few kernel releases.

sysfs == Sisyphus, a character of Greek mythology doomed by the gods to roll a boulder up a hill for all time. When he gets to the top, it rolls back down.

Kind of like fixing /proc. <ducks>

ian

#4 lore raw
Quoted 11 lines · Ian Soboroff
Quoted 9 lines · Greg KH
Quoted 8 lines · Ian Soboroff
Quoted 5 lines · Dave Jones

driverfs
~~~~~~~~
[...]
*NB*, at some point the name of this filesystem will be changing to sysfs. See Documentation/filesystems/sysfs.txt for more info.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

Probably have to wait until we push the rock up the hill again.

What do you mean? This should happen in the next few kernel releases.

sysfs == Sisyphus, a character of Greek mythology doomed by the gods to roll a boulder up a hill for all time. When he gets to the top, it rolls back down.

sysfs != Sisyphus. They are coincidental hominems.

Quoted 1 line

Kind of like fixing /proc. <ducks>

Recall also that (Feature Freeze != Code Freeze). There will be a lot of cleanup and conversion happening the next few months, from old school driver models to the new driver models, and the population of a sane sysfs layout.

driverfs will hopefully die today. Stay tuned..

-pat

#5 lore raw
Quoted 5 lines · Patrick Mochel
Quoted 3 lines

sysfs == Sisyphus, a character of Greek mythology doomed by the gods to roll a boulder up a hill for all time. When he gets to the top, it rolls back down.

sysfs != Sisyphus. They are coincidental hominems.

Homonyms. Or is this an ad-homonym attack?

Quoted 10 lines
Quoted 1 line

Kind of like fixing /proc. <ducks>

Recall also that (Feature Freeze != Code Freeze). There will be a lot of cleanup and conversion happening the next few months, from old school driver models to the new driver models, and the population of a sane sysfs layout.

driverfs will hopefully die today. Stay tuned..

-pat

#6 lore raw
Quoted 4 lines
Quoted 2 lines

sysfs != Sisyphus. They are coincidental hominems.

Homonyms. Or is this an ad-homonym attack?

Woops. Hasn't anyone ever told you no one likes a smart ass? ;)

-pat

#7 lore raw
In reply to Patrick Mochel
Quoted 8 lines · Patrick Mochel
Quoted 1 line

Kind of like fixing /proc. <ducks>

Recall also that (Feature Freeze != Code Freeze). There will be a lot of cleanup and conversion happening the next few months, from old school driver models to the new driver models, and the population of a sane sysfs layout.

driverfs will hopefully die today. Stay tuned..

Also, I meant to say, no insult was intended, it was just a joke. ian

#8 lore raw
In reply to Ian Soboroff
Quoted 11 lines · Ian Soboroff
Quoted 9 lines · Greg KH
Quoted 8 lines · Ian Soboroff
Quoted 5 lines · Dave Jones

driverfs
~~~~~~~~
[...]
*NB*, at some point the name of this filesystem will be changing to sysfs. See Documentation/filesystems/sysfs.txt for more info.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

Probably have to wait until we push the rock up the hill again.

What do you mean? This should happen in the next few kernel releases.

sysfs == Sisyphus, a character of Greek mythology doomed by the gods to roll a boulder up a hill for all time. When he gets to the top, it rolls back down.

Doh!

/me goes and digs out his old Mythology books...

Quoted 1 line

Kind of like fixing /proc. <ducks>

All too true :)

greg k-h

#9 lore raw
In reply to Dave Jones
Quoted 4 lines · Dave Jones

Regressions:
~~~~~~~~~~~~
(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional.

[These hopefully can be converted to use device mapper..]

Quoted 1 line

- Various SCSI drivers still need work, and don't even compile.

Many older network drivers ditto
Much of the ISDN layer ditto

Quoted 3 lines

- software suspend is still in development, and in need of more work. It is unlikely to work as expected currently.
- Some filesystems still need work (Coda, Intermezzo).

		UFS, HFS HPFS,...

Add "Most older SCSI controllers are *NOT* doing error handling. Be careful."
Add "Simplex IDE devices (eg Ali15x3) are missing DMA sometimes" Add "Serverworks OSB4 may panic on bad blocks or other non fatal errors" Add "PCMCIA IDE hangs on eject"
Add "Most PCMCIA devices have unload races and may oops on eject" Add "Modular IDE does not yet work, modular IDE PCI modules sometimes oops on loading"

Quoted 5 lines
Quoted 1 line

Deprecated features:

~~~~~~~~~~~~~~~~~~~~
- khttpd is gone.
- Older Direct Rendering Manager (DRM) support (For XFree86 4.0) has been removed. Upgrade to XFree86 4.1.0 or higher.

LVM1 is no longer supported, upgrade to LVM2. This supports the LVM1 disk format.

Quoted 7 lines

PnP layer
~~~~~~~~~
Support for plug and play devices such as early ISAPNP cards has improved a lot in the 2.5 kernel. You should no longer need to futz with userspace tools to configure IRQ's and the likes. Report any regressions in plug & play functionality to Adam Belay <[email protected]>

Right at the moment the executive summary would be "ISAPnP doesnt work any more but the new interfaces will mean it works a lot better soon (I hope)"

Quoted 10 lines

ALSA
~~~~
The advanced linux sound architecture got merged into 2.5. This offers considerably improved functionality over the older OSS drivers, but requires new userspace tools. Several distros have shipped ALSA for some time, so you may already have the necessary tools. If not, you can find them at http://www.alsa-project.org/
(Note that the OSS drivers are also still functional, and
still present)

Kind of work in some cases, they are deprecated and may vanish before 2.6 or may vanish the release after.

Quoted 9 lines

IDE
~~~
The IDE code was subject to much criticism in early 2.5.x, which put off a lot of people from testing. This work was then subsequently dropped, and reverted back to a 2.4.18 IDE status.
(Since then additional work has occured, but not to the extent
of the first cleanup attempts).
Additional work on the ATA code is happening in 2.4-ac, and pending merging to 2.5

Actually its happening in 2.5 back merging to 2.4-ac now.

Quoted 11 lines

IDE TCQ
~~~~~~~
Tagged command queueing for IDE devices has been included. Not all devices may like this, so handle with care. If you didn't choose the "TCQ on by default" option, you can enable it by using the command

echo "using_tcq:32" > /proc/ide/hdX/settings
(replacing 32 with 0 disables TCQ again).
Report success/failure stories to Jens Axboe <[email protected]> with inclusion of hdparm -i /dev/hdX

** Don't use IDE TCQ on any data you value.

Quoted 7 lines

x86 CPU detection.
~~~~~~~~~~~~~~~~~~
The CPU detection code got a pretty hefty shake up. To be certain your CPU has all relevant workarounds applied, be sure to check that it was detected correctly. cat /proc/cpuinfo will tell what the kernel thinks it is. Likewise, the x86 MTRR driver got a considerable makeover.
Any regressions in both should go to [email protected]

Early PII Xeon processors and possibly other early PII processors require microcode updates either from the BIOS or the microcode driver to handle O(1) scheduler reliably

Can you also mention not using gcc 3.0.x (stack pointer handling bug)

#10 lore raw
Quoted 1 line

Can you also mention not using gcc 3.0.x (stack pointer handling bug)

Any chance of putting this sort of thing as #error detection in the compile so it auto-breaks? I seem to recall that's done for some versions of GCC already ...

M.

#11 lore raw
Quoted 5 lines · Martin J. Bligh
Quoted 1 line

Can you also mention not using gcc 3.0.x (stack pointer handling bug)

Any chance of putting this sort of thing as #error detection in the compile so it auto-breaks? I seem to recall that's done for some versions of GCC already ...

And what arch is that for? Adding a nice facility for per-arch (and maybe global) compiler / binutils testing would be nice, if we're going to go down that road..

Signature · 2 lines
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
#12 lore raw
Quoted 9 lines
Quoted 5 lines
Quoted 1 line

Can you also mention not using gcc 3.0.x (stack pointer handling bug)

Any chance of putting this sort of thing as #error detection in the compile so it auto-breaks? I seem to recall that's done for some versions of GCC already ...

And what arch is that for? Adding a nice facility for per-arch (and maybe global) compiler / binutils testing would be nice, if we're going to go down that road..

Alan, would you consider something like (TOTALLY untested):

init/main.c +1 -1
diff -purN -X /home/mbligh/.diff.exclude virgin/init/main.c gcc/init/main.c
@@ -50,7 +50,7 @@
  * To avoid associated bogus bug reports, we flatly refuse to compile
  * with a gcc that is known to be too old from the very beginning.
  */
-#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 91)
+#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 91) || (__GNUC__ == 3 && __GNUC_MINOR__ == 0)
 #error Sorry, your GCC is too old. It builds incorrect kernels.
 #endif
 

If you like it, I'll get it tested.

Probably some things are per-arch and some are global, at a guess. Currently we have:

init/main.c:
/*
* Versions of gcc older than that listed below may actually compile
* and link okay, but the end product can have subtle run time bugs.
* To avoid associated bogus bug reports, we flatly refuse to compile
* with a gcc that is known to be too old from the very beginning. */
#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 91) #error Sorry, your GCC is too old. It builds incorrect kernels. #endif

arch/arm/kernel/asm-offsets.c

/*
* Make sure that the compiler and target are compatible.
*/
#if defined(__APCS_32__) && defined(CONFIG_CPU_26)
#error Sorry, your compiler targets APCS-32 but this kernel requires APCS-26 #endif
#if defined(__APCS_26__) && defined(CONFIG_CPU_32)
#error Sorry, your compiler targets APCS-26 but this kernel requires APCS-32 #endif
#if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 95)
#error Sorry, your compiler is known to miscompile kernels. Only use gcc 2.95.3
and later.
#endif
#if __GNUC__ == 2 && __GNUC_MINOR__ == 95
/* shame we can't detect the .1 or .2 releases */
#warning GCC 2.95.2 and earlier miscompiles kernels.
#endif

#13 lore raw
Quoted 11 lines · Martin J. Bligh
Quoted 9 lines
Quoted 5 lines
Quoted 1 line

Can you also mention not using gcc 3.0.x (stack pointer handling bug)

Any chance of putting this sort of thing as #error detection in the compile so it auto-breaks? I seem to recall that's done for some versions of GCC already ...

And what arch is that for? Adding a nice facility for per-arch (and maybe global) compiler / binutils testing would be nice, if we're going to go down that road..

Alan, would you consider something like (TOTALLY untested):

[snip]

So it's a global thing then?

Quoted 4 lines

If you like it, I'll get it tested.

Probably some things are per-arch and some are global, at a guess. Currently we have:

[snip]

And then ppc32 does some binutils checks, not-in-C and before we let the kernel get too far. What I was proposing is we add something outside of the direct kernel src (something in scripts? Generic make magic?) to verify that a compiler / binutils / whatever tool is a good version. This is rather easy for binutils + obvious instruction problem (missing / incorrect operands), and for compiler versions, something to generate a test-file and then see if it compiles.

Signature · 2 lines
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
#14 lore raw
In reply to Martin J. Bligh
Quoted 1 line · On Wed, 30 Oct 2002 11:57:58 -0800 "Martin J. Bligh" <[email protected]> wrote:

#error Sorry, your GCC is too old. It builds incorrect kernels.

well, we are calling 3.0 "old" when 2.95 works. Changing the text here would be nice too :)

#15 lore raw
Quoted 7 lines
Quoted 1 line · On Wed, 30 Oct 2002 11:57:58 -0800 "Martin J. Bligh" <[email protected]> wrote:
 # error Sorry, your GCC is too old. It builds incorrect kernels.

well, we are calling 3.0 "old" when 2.95 works. Changing the text here would be nice too :)

#error Sorry, your GCC is too crap. It builds incorrect kernels.

?

M.

#16 lore raw
In reply to Martin J. Bligh
Quoted 1 line · Martin J. Bligh

Alan, would you consider something like (TOTALLY untested):

Except that I don't know if its an X86 specific problem. I'll see if Jakub knows the exact releases

author
#17 lore raw
In reply to Alan Cox
Quoted 3 lines · Alan Cox
Quoted 2 lines

(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional.

[These hopefully can be converted to use device mapper..]

Thats a fairly large 'mandatory' requirement for existing users of hptraid and friends.

Quoted 3 lines
Quoted 1 line

- Various SCSI drivers still need work, and don't even compile.

Many older network drivers ditto
Much of the ISDN layer ditto

I held off on this to see if Kai would get things in order in time. Looking at current BK, it looks like he's done quite a bit. Kai, any changes from a user point of view wrt tools ?

Quoted 4 lines
Quoted 3 lines

- software suspend is still in development, and in need of more work. It is unlikely to work as expected currently.
- Some filesystems still need work (Coda, Intermezzo).

		UFS, HFS HPFS,...

Hadn't realised they were still broken. Added to the list.

Quoted 2 lines

Add "Most older SCSI controllers are *NOT* doing error handling. Be careful."

Added. Was covered by the 'most drivers wont compile' though now that current BK has nuked the abort: and reset: members.

Quoted 6 lines

Add "Simplex IDE devices (eg Ali15x3) are missing DMA sometimes" Add "Serverworks OSB4 may panic on bad blocks or other non fatal errors" Add "PCMCIA IDE hangs on eject"
Add "Most PCMCIA devices have unload races and may oops on eject" Add "Modular IDE does not yet work, modular IDE PCI modules sometimes oops on loading"

Added.

Quoted 2 lines

LVM1 is no longer supported, upgrade to LVM2. This supports the LVM1 disk format.

Was covered in the devicemapper section.
Reworded to make the 'backwards compatability' thing a bit more obvious.

Quoted 4 lines
Quoted 2 lines

(Note that the OSS drivers are also still functional, and
still present)

Kind of work in some cases, they are deprecated and may vanish before 2.6 or may vanish the release after.

I'd agree that it would make sense to at least remove some of the lesser maintained drivers. Linus didnt seem to keen on the idea last time I proposed it.

Quoted 3 lines
Quoted 2 lines

Additional work on the ATA code is happening in 2.4-ac, and pending merging to 2.5

Actually its happening in 2.5 back merging to 2.4-ac now.

Oops, my bad. Hard to keep up with the crazy world of IDE these days..

Quoted 7 lines
Quoted 7 lines

IDE TCQ
~~~~~~~
Tagged command queueing for IDE devices has been included. Not all devices may like this, so handle with care. If you didn't choose the "TCQ on by default" option, you can enable it by using the command

Quoted 6 lines
Quoted 4 lines

echo "using_tcq:32" > /proc/ide/hdX/settings
(replacing 32 with 0 disables TCQ again).
Report success/failure stories to Jens Axboe <[email protected]> with inclusion of hdparm -i /dev/hdX

** Don't use IDE TCQ on any data you value.

Ok, I'll make that a little bolder. (In fact, I'll just cut-n-paste your text 8-)

Thanks for the feedback. I've merged the rest of your comments, and will put an updated version up after merging everyone elses feedback too 8-)

BTW: How's i2o shaping up in 2.5 ?

Dave

Signature · 1 line
| Dave Jones.        http://www.codemonkey.org.uk
#18 lore raw
Quoted 8 lines · Dave Jones
Quoted 3 lines · Alan Cox
Quoted 2 lines

(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional.

[These hopefully can be converted to use device mapper..]

Thats a fairly large 'mandatory' requirement for existing users of hptraid and friends.

Whether its a userspace thing or DM is simply told by the hptraid driver to do the work for it is an open question yes

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

(Note that the OSS drivers are also still functional, and
still present)

Kind of work in some cases, they are deprecated and may vanish before 2.6 or may vanish the release after.

I'd agree that it would make sense to at least remove some of the lesser maintained drivers. Linus didnt seem to keen on the idea last time I proposed it.

OSS hasnt worked on SMP between about 2.5.35 and 2.5.44 so I dont think its that major 8)

Quoted 1 line

BTW: How's i2o shaping up in 2.5 ?

It compiles I've got to put stuff together to do the full test runs on it yet. The code is actually a lot cleaner with the new block layer, much more scalable and also Al Viro took a hatchet to bits of it when tidying the block layer so the disk add/remove and other stuff has also improved dramatically. The fast path for I/O now executes a mere four instructions within the driver under a spinlock on i2o_block 8)

Mostly I'm working on the NCR5380 first. That happens to be attached to my scanner so spinning for 15 seconds in IRQ context is annoying me 8)

#19 lore raw
Quoted 8 lines · Alan Cox
Quoted 3 lines · Dave Jones

I'd agree that it would make sense to at least remove some of the lesser maintained drivers. Linus didnt seem to keen on the idea last time I proposed it.

OSS hasnt worked on SMP between about 2.5.35 and 2.5.44 so I dont think its that major 8)

Thank you, since all the systems I have been using for 2.5 testing are SMP, I just thought sound was broken in general. And still may be, since I found that some audio CD's I burned with 2.5 are just noise while the same hardware burned CD's from the same batch of blanks using 2.4.19+patches. Using SMP. I'll try a uni burn tomorrow.

Quoted 2 lines

Mostly I'm working on the NCR5380 first. That happens to be attached to my scanner so spinning for 15 seconds in IRQ context is annoying me 8)

I can't get the aha142x working either, if you're looking for stuff to do ;-)

Signature · 3 lines
bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
#20 lore raw
In reply to Dave Jones
Quoted 9 lines · Dave Jones

I updated the list of various things that wannabe testers might hit. If theres something I missed let me know, and I'll get it right next time round..

Deprecated features:
~~~~~~~~~~~~~~~~~~~~
- khttpd is gone.
- Older Direct Rendering Manager (DRM) support (For XFree86 4.0) has been removed. Upgrade to XFree86 4.1.0 or higher.

Anyone that uses multimedia keys without X will see changes in how the kernel handles those keys. People who customize keymaps or keycodes in 2.4 may need to make some changes to those scripts in 2.5

A new keyboard package was released, but I haven't tested it yet to make sure everything works. I hacked up loadkeys and setkeycodes on my own to get it to work, and I just haven't upgraded to the new package yet.

Quoted 26 lines

Input layer
~~~~~~~~~~~
Possibly the most visible change to the end user. If misconfigured, you'll find that your keyboard/mouse/other input device will no longer work. 2.5 offers a much more flexable interface to devices such as keyboards. The downside is more confusing options.
In the "Input device support" menu, be sure to enable at least the following.

--- Input I/O drivers
< > Serial i/o support
< > i8042 PC Keyboard controller
[ ] Keyboards
[ ] Mice

(Also choose the relevant keyboard/mouse from the list)

If you find your keyboard/mouse still don't work, edit the file drivers/input/serio/i8042.c, and replace the #undef DEBUG with a #define DEBUG

When you boot, you should now see a lot more debugging information. Forward this information to Vojtech Pavlik <[email protected]>

If you use a KVM switcher, and experience problems, booting with the boot time argument 'psmouse_noext' should fix your problems.

Signature · 1 line
Skip
#21 lore raw

Htree ate my hard drive, was: post-halloween 0.2

In reply to Dave Jones
Quoted 8 lines

EXT3 Htree support.
~~~~~~~~~~~~~~~~~~~
The ext3 filesystem has gained indexed directory support, which offers considerable performance gains when used on filesystems with large directories. In order to use the htree feature, you need at least version 1.29 of e2fsprogs. Existing filesystems can be converted using the command "tune2fs -O dir_index /dev/hdXXX" The latest e2fsprogs can be found at
http://prdownloads.sourceforge.net/e2fsprogs

I ran this (tune2fs -O dir_index /dev/hdXXX).

After a bit of switching back and forth between 2.4.19 and 2.5.44, fsck was run while booting 2.4.19 (the usual check because of >30 mounts). There was a message about optimizing directories. Booting continued but (big surprise) X refused to run. It turned out that some device files had vanished. Very strange. On rebooting, fsck found a gazillion bad inodes. They all turned out to be from the 2.5.44 tree - poetic justice I suppose! But this did not suffice. Rebooting, I got "optimizing directories" again. Next fsck showed up more dud inodes. After a few cycles of this, I ran

tune2fs -O ^dir_index /dev/hdXXX

to remove htree support. No problems since then.

Duncan.

PS: UP, no preempt.

tune2fs 1.30-WIP (30-Sep-2002)

Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          ee433ceb-6b14-45b1-894c-2a8aad1e280f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal needs_recovery
Filesystem state:         clean
Errors behavior:          Unknown (continue)
Filesystem OS type:       Linux
Inode count:              290816
Block count:              2315368
Reserved block count:     115768
Free blocks:              871842
Free inodes:              36718
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   128
Last mount time:          Thu Oct 31 06:37:46 2002
Last write time:          Thu Oct 31 06:37:46 2002
Mount count:              7
Maximum mount count:      30
Last checked:             Wed Oct 30 11:50:37 2002
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal UUID:             <none>
Journal inode:            493
Journal device:           0x0000
First orphan inode:       139500
#22 lore raw

Re: Htree ate my hard drive, was: post-halloween 0.2

Quoted 21 lines · Duncan Sands
Quoted 8 lines

EXT3 Htree support.
~~~~~~~~~~~~~~~~~~~
The ext3 filesystem has gained indexed directory support, which offers considerable performance gains when used on filesystems with large directories. In order to use the htree feature, you need at least version 1.29 of e2fsprogs. Existing filesystems can be converted using the command "tune2fs -O dir_index /dev/hdXXX" The latest e2fsprogs can be found at
http://prdownloads.sourceforge.net/e2fsprogs

I ran this (tune2fs -O dir_index /dev/hdXXX).

After a bit of switching back and forth between 2.4.19 and 2.5.44, fsck was run while booting 2.4.19 (the usual check because of >30 mounts). There was a message about optimizing directories. Booting continued but (big surprise) X refused to run. It turned out that some device files had vanished. Very strange. On rebooting, fsck found a gazillion bad inodes. They all turned out to be from the 2.5.44 tree - poetic justice I suppose! But this did not suffice. Rebooting, I got "optimizing directories" again. Next fsck showed up more dud inodes. After a few cycles of this, I ran

Quoted 5 lines

tune2fs -O ^dir_index /dev/hdXXX

to remove htree support. No problems since then.

tune2fs 1.30-WIP (30-Sep-2002)

I wonder if there is still a bug in the e2fsck code for re-hashing directories? It shouldn't be possible to have e2fsck complete and there still be an error in the filesystem (ok, sometimes it happens, but in those cases it spews a lot of warnings about the filesystem not being fixed yet and to run manually).

What else is strange (at least to me) is e2fsck "optimizing directories" on a reboot. My understanding at least is that this would be done only when explicitly asked for, otherwise it might slow down booting a lot, and as you can see it adds to the possibility of corrupting the fs when e2fsck should only be fixing it.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

#23 lore raw

Re: Htree ate my hard drive, was: post-halloween 0.2

Quoted 26 lines · Andreas Dilger
Quoted 25 lines · Duncan Sands
Quoted 8 lines

EXT3 Htree support.
~~~~~~~~~~~~~~~~~~~
The ext3 filesystem has gained indexed directory support, which offers considerable performance gains when used on filesystems with large directories. In order to use the htree feature, you need at least version 1.29 of e2fsprogs. Existing filesystems can be converted using the command "tune2fs -O dir_index /dev/hdXXX" The latest e2fsprogs can be found at http://prdownloads.sourceforge.net/e2fsprogs

I ran this (tune2fs -O dir_index /dev/hdXXX).

After a bit of switching back and forth between 2.4.19 and 2.5.44, fsck was run while booting 2.4.19 (the usual check because of >30 mounts). There was a message about optimizing directories. Booting continued but (big surprise) X refused to run. It turned out that some device files had vanished. Very strange. On rebooting, fsck found a gazillion bad inodes. They all turned out to be from the 2.5.44 tree - poetic justice I suppose! But this did not suffice. Rebooting, I got "optimizing directories" again. Next fsck showed up more dud inodes. After a few cycles of this, I ran

tune2fs -O ^dir_index /dev/hdXXX

to remove htree support. No problems since then.

Quoted 7 lines
Quoted 1 line

tune2fs 1.30-WIP (30-Sep-2002)

I wonder if there is still a bug in the e2fsck code for re-hashing directories? It shouldn't be possible to have e2fsck complete and there still be an error in the filesystem (ok, sometimes it happens, but in those cases it spews a lot of warnings about the filesystem not being fixed yet and to run manually).

It is possible that the filesystem was fine when fsck completed, but was damaged afterwards, i.e. in the time between fsck completing and the reboot.

Duncan.

Quoted 5 lines

What else is strange (at least to me) is e2fsck "optimizing directories" on a reboot. My understanding at least is that this would be done only when explicitly asked for, otherwise it might slow down booting a lot, and as you can see it adds to the possibility of corrupting the fs when e2fsck should only be fixing it.

#24 lore raw

Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2

In reply to Andreas Dilger

Hi,

Quoted 8 lines · Andreas Dilger
Quoted 5 lines · Duncan Sands

After a bit of switching back and forth between 2.4.19 and 2.5.44, fsck was run while booting 2.4.19 (the usual check because of >30 mounts). There was a message about optimizing directories. Booting continued but (big surprise) X refused to run. It turned out that some device files had vanished.

Quoted 5 lines
Quoted 2 lines

tune2fs -O ^dir_index /dev/hdXXX
to remove htree support. No problems since then.

I wonder if there is still a bug in the e2fsck code for re-hashing directories?

Possibly, but I'm more worried about why the fsck did a directory optimise on reboot, especially on the root filesystem (where /dev is usually stored). Doing major fs surgery on a mounted, readonly filesystem is sort-of safe, but only if you reboot afterwards. Continuing and remounting read-write can cause all sorts of damage as the cached fs data no longer matches what's on disk.

Duncan, did you have fsck set up to do a forced htree rebuild on reboot?

Cheers,
Stephen

#25 lore raw

Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2

Quoted 23 lines · Stephen C. Tweedie

Hi,

Quoted 7 lines · Andreas Dilger
Quoted 6 lines · Duncan Sands

After a bit of switching back and forth between 2.4.19 and 2.5.44, fsck was run while booting 2.4.19 (the usual check because of >30 mounts). There was a message about optimizing directories. Booting continued but (big surprise) X refused to run. It turned out that some device files had vanished.

Quoted 5 lines
Quoted 2 lines

tune2fs -O ^dir_index /dev/hdXXX
to remove htree support. No problems since then.

I wonder if there is still a bug in the e2fsck code for re-hashing directories?

Possibly, but I'm more worried about why the fsck did a directory optimise on reboot, especially on the root filesystem (where /dev is usually stored). Doing major fs surgery on a mounted, readonly filesystem is sort-of safe, but only if you reboot afterwards. Continuing and remounting read-write can cause all sorts of damage as the cached fs data no longer matches what's on disk.

Quoted 2 lines

Duncan, did you have fsck set up to do a forced htree rebuild on reboot?

Hmmm, fsck is called from the debian checkroot init script which does fsck -a -C
So I guess the answer is "no".

Duncan.

PS: I am using version 1.30-WIP of e2fsck.

#26 lore raw

Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2

In reply to Stephen C. Tweedie

On Mon, 4 Nov 2002 22:42:13 +0000 Stephen C. Tweedie (SCT) wrote:

SCT> On Thu, Oct 31, 2002 at 01:07:17AM -0700, Andreas Dilger wrote:
SCT> > I wonder if there is still a bug in the e2fsck code for re-hashing SCT> > directories?
SCT>
SCT> Possibly, but I'm more worried about why the fsck did a directory SCT> optimise on reboot, especially on the root filesystem (where /dev is SCT> usually stored). Doing major fs surgery on a mounted, readonly SCT> filesystem is sort-of safe, but only if you reboot afterwards. SCT> Continuing and remounting read-write can cause all sorts of damage as SCT> the cached fs data no longer matches what's on disk.

Just a "me too". I've used htree with 2.5.44 and 2.4.20rc1. The next fs check on the root filesystem founds corruption in /dev. After repairing the damage and recreating the lost devices the machine ran ok for 2 days. Then I had some ext3-fs errors and the partition got remounted read-only. The following fsck revealed two inodes sharing the same block. I don't have any logs of that incident anymore though :/

I'm running Slackware 9.0-beta and e2fsprogs-1.30-WIP.

Regards,
-Udo.

#27 lore raw

Re: Htree ate my hard drive, was: post-halloween 0.2

In reply to Duncan Sands

In article <[email protected]> you write:

Quoted 12 lines
Quoted 9 lines

EXT3 Htree support.
~~~~~~~~~~~~~~~~~~~
The ext3 filesystem has gained indexed directory support, which offers considerable performance gains when used on filesystems with large directories. In order to use the htree feature, you need at least version 1.29 of e2fsprogs. Existing filesystems can be converted using the command "tune2fs -O dir_index /dev/hdXXX" The latest e2fsprogs can be found at
http://prdownloads.sourceforge.net/e2fsprogs

I ran this (tune2fs -O dir_index /dev/hdXXX).

Quoted 8 lines

After a bit of switching back and forth between 2.4.19 and 2.5.44, fsck was run while booting 2.4.19 (the usual check because of >30 mounts). There was a message about optimizing directories. Booting continued but (big surprise) X refused to run. It turned out that some device files had vanished. Very strange. On rebooting, fsck found a gazillion bad inodes. They all turned out to be from the 2.5.44 tree - poetic justice I suppose! But this did not suffice. Rebooting, I got "optimizing directories" again. Next fsck showed up more dud inodes.

For info, I had this as well. Kernel 2.4.19 only. Using e2fsprogs 1.29.

I've not used tune2fs, just using -D switch to e2fsck. Using ext3 on all filesystems.

No obvious complaints from e2fsck, although I wasn't really watching it. No entries in /'s lost+found. No problems with other filesystems.

Only lost device files in /dev (about 120) with no discernible pattern.

Mike

dumpe2fs output:

Filesystem volume name:   root
Last mounted on:          /
Filesystem UUID:          6278d5f9-5583-4651-8d58-f12886a4e3a9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal dir_index filetype needs_recovery sparse_super
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122624
Block count:              244991
Reserved block count:     2449
Free blocks:              79421
Free inodes:              86789
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         15328
Inode blocks per group:   479
Last mount time:          Thu Oct 31 17:08:15 2002
Last write time:          Thu Oct 31 17:08:15 2002
Mount count:              4
Maximum mount count:      31
Last checked:             Wed Oct 30 18:57:46 2002
Check interval:           15552000 (6 months)
Next check after:         Mon Apr 28 19:57:46 2003
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal UUID:             <none>
Journal inode:            8
Journal device:           0x0000
First orphan inode:       0
Default directory hash:   tea
Directory Hash Seed:      c9f2f715-bc28-4302-a2e9-e53aa08576f7
#28 lore raw

Re: Htree ate my hard drive, was: post-halloween 0.2

Quoted 1 line · Mike Civil

For info, I had this as well. Kernel 2.4.19 only. Using e2fsprogs 1.29.

Do you mean that you did not run a 2.5 kernel, or that you tried several 2.4 kernels and this was the only one that chewed on your hard drive?

Ciao,

Duncan.

#29 lore raw

Re: Htree ate my hard drive, was: post-halloween 0.2

In article <[email protected]>,

Quoted 6 lines · Duncan Sands
Quoted 1 line · Mike Civil

For info, I had this as well. Kernel 2.4.19 only. Using e2fsprogs 1.29.

Do you mean that you did not run a 2.5 kernel, or that you tried several 2.4 kernels and this was the only one that chewed on your hard drive?

No, at the moment I only run a 2.4.19 kernel.

Mike

#30 lore raw

Re: Htree ate my hard drive, was: post-halloween 0.2

In reply to Duncan Sands

hi :)

after testing htree support, i ran into similar problems:

booted 2.5, tune2fs -O dir_index on all filesystems, umounted home
fscked -D home, mounted home, all is well... rebooted into 2.4.19 and everything is still fine

then i got a 'maximum mount count reached' on / while booting 2.4 on fscking, it optimized some directories.
afterwards i had some files missing all over the root fs

after removing dir_index all files were there again

lately my / got checked again, and fsck complained about some hashed directory entries on a fs without dir_index...
i had to press return several times but did not run into problems...

Signature · 10 lines
CU,		  / Friedrich-Alexander University Erlangen, Germany
Martin Waitz	//  [Tali on IRCnet]  [tali.home.pages.de] _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet    //
tippfehler und ist auch ohne grossbuchstaben gueltig.   /
			    -
Wer bereit ist, grundlegende Freiheiten aufzugeben, um sich 
kurzfristige Sicherheit zu verschaffen, der hat weder Freiheit 
noch Sicherheit verdient.
			Benjamin Franklin  (1706 - 1790)
#31 lore raw
In reply to Dave Jones

Hi!

Quoted 11 lines

Latest version of this document can always be found at
http://www.codemonkey.org.uk/post-halloween-2.5.txt

Regressions:
~~~~~~~~~~~~
(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional.
- Various SCSI drivers still need work, and don't even compile.
- software suspend is still in development, and in need of more work. It is unlikely to work as expected currently.

As swsusp is new feature in 2.5. (it does not exist in official 2.4), I do not think it is regression. Anyway, I hope to fix that real soon now.
Pavel

Signature · 1 line
When do you have heart between your knees?
#32 lore raw
In reply to Dave Jones

Hi,

Quoted 4 lines

Quota reworking
~~~~~~~~~~~~~~~
The new quota system needs new tools. ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/alpha/quota-3.05-pre1.tar.gz

http://www.sf.net/projects/linuxquota/ is actually the right address for getting new quota tools (it's even written in README in my FTP directory - but who does read README files :)).

Honza

author
#33 lore raw
Quoted 5 lines · Jan Kara
Quoted 2 lines

The new quota system needs new tools. ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/alpha/quota-3.05-pre1.tar.gz

http://www.sf.net/projects/linuxquota/ is actually the right address for getting new quota tools (it's even written in README in my FTP directory - but who does read README files :)).

I just cut-n-pasted from your original announcement 8-) URL has been updated anyway,. Thanks for the update.

Dave

Signature · 1 line
| Dave Jones.        http://www.codemonkey.org.uk