My linux/.config ...
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m
CONFIG_BLK_DEV_IDEDISK=m
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_IDE_MODES=y
System version ...
module-init-tools-0.9.3
linux-2.5.51
depmod will ecounter "Segmentation fault" if the ide.ko and ide-io.ps
modules are in /lib/modules/2.5.51/kernel
After "rm ide.ko ide-io.ps", depmod runs fine, but that means ide won't
load.
Thanks,
Jeff
[ [email protected] ]
>depmod will ecounter "Segmentation fault" if the ide.ko and ide-io.ps
>modules are in /lib/modules/2.5.51/kernel
I think the new depmod recurses infinitely when it encounters
circular dependencies. It eventually segfaults and leaves a huge
modules.dep file from the infinite loop. If you look at the final
huge line in that file, you can see where the loop occurred.
depmod has no need to do any recursion, since it only needs
to determine the immediate dependencies of each module. However,
noticing such loops and printing them out would be a handy feature.
I use IDE as a module, but I had to change the Makefile to
build a big ide-mod.o from most of the core objects rather than
allowing each one to be its own module. I believe I posted IDE
modularization patches at least once a couple of months ago, but it
seems to have fallen between the cracks. I could repost it if need
be, although I have not yet booted 2.5.51.
Also note that I have not used the in kernel-based module
loader recently, as I have been patching my kernels to use the user
level module code. I am planning to try the kernel-base module loader
in 2.5.51 once I fix other problems it has finding the root device
under devfs. So, it's remotely possible that you may also see module
problems that I've missed.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Tue, 10 Dec 2002, Adam J. Richter wrote:
> >depmod will ecounter "Segmentation fault" if the ide.ko and ide-io.ps
> >modules are in /lib/modules/2.5.51/kernel
>
> I think the new depmod recurses infinitely when it encounters
> circular dependencies. It eventually segfaults and leaves a huge
> modules.dep file from the infinite loop. If you look at the final
> huge line in that file, you can see where the loop occurred.
>
> depmod has no need to do any recursion, since it only needs
> to determine the immediate dependencies of each module. However,
> noticing such loops and printing them out would be a handy feature.
>
> I use IDE as a module, but I had to change the Makefile to
> build a big ide-mod.o from most of the core objects rather than
> allowing each one to be its own module. I believe I posted IDE
> modularization patches at least once a couple of months ago, but it
> seems to have fallen between the cracks. I could repost it if need
> be
Yes, please, send me your patch. I hope this patch works for
module-init-tools-0.9.3
>, although I have not yet booted 2.5.51.
I had same problem with pre 2.5.51. With 2.5.51, kernel now boot and I'm
able to get login prompt using ramdisk. Only catch is I've to specify
root=/dev/ram0 instead of /dev/ram for it to boot.
Thanks,
Jeff.
>
> Also note that I have not used the in kernel-based module
> loader recently, as I have been patching my kernels to use the user
> level module code. I am planning to try the kernel-base module loader
> in 2.5.51 once I fix other problems it has finding the root device
> under devfs. So, it's remotely possible that you may also see module
> problems that I've missed.
>
> Adam J. Richter __ ______________ 575 Oroville Road
> [email protected] \ / Milpitas, California 95035
> +1 408 309-6081 | g g d r a s i l United States of America
> "Free Software For The Rest Of Us."
>
On Wed, Dec 11, 2002 at 03:07:33PM +0800, Jeff Chua wrote:
> On Tue, 10 Dec 2002, Adam J. Richter wrote:
> > I use IDE as a module, but I had to change the Makefile to
> > build a big ide-mod.o from most of the core objects rather than
> > allowing each one to be its own module. I believe I posted IDE
> > modularization patches at least once a couple of months ago, but it
> > seems to have fallen between the cracks. I could repost it if need
> > be
>
> Yes, please, send me your patch. I hope this patch works for
> module-init-tools-0.9.3
Here is a quick diff of my drivers/ide subdirectory versus stock 2.5.51.
--
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Wed, Dec 11, 2002 at 05:29:03PM +0800, Jeff Chua wrote:
> On Wed, 11 Dec 2002, Adam J. Richter wrote:
> > Here is a quick diff of my drivers/ide subdirectory versus stock 2.5.51.
>
> +++ linux/drivers/ide/pci/cmd640.c 2002-11-27 18:24:00.000000000
> -int cmd640_vlb = 0;
>
> These lines must "stay" in cmd640.c, else it won't compile.
>
> "depmod -a" works now, but encounter a new problem when I tried to load
> ide ...
>
> # modprobe ide-mod
> FATAL: Error inserting ide_mod (/lib/modules/2.5.51/kernel/ide-mod.ko):
> Unknown symbol in module
> ide_mod: Unknown symbol pci_enable_device_bars
Jeff: Sorry, I forgot to include diffs for include/linux/ide.h
and drivers/pci/pci.c. Here is a corrected patch. I am running the
code on that machine on which I'm composing this email, and I have
also verified that cmd640.c compiled without complaint (well,
actually, I've modified the patch slightly to eliminate some unrelated
diffs).
Alan: If you want, please feel free to merge this change.
Alternatively, if you're stepping away from 2.5 while waiting for
modules to stabilize, I'd appreciate knowing what you'd prefer be done
with incoming IDE patches (submit them to Andre and Jens, just wait,
something else?). For what it's worth, 2.5.51 +
init-module-tools-0.9.3 is the first kernel-based module loader
configuration which works enough so that I'm able to work on other
things. For the past few releases, I had been restoring user level
module loading. There still are a lot of quirks with the kernel based
module loading, but you might find it sufficient to get things done.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Fri, 2002-12-13 at 07:59, Adam J. Richter wrote:
> --- linux-2.5.51/drivers/pci/pci.c 2002-12-09 18:45:52.000000000 -0800
> +++ linux/drivers/pci/pci.c 2002-12-09 19:03:18.000000000 -0800
> @@ -736,6 +736,7 @@
> EXPORT_SYMBOL(isa_bridge);
> #endif
>
> +EXPORT_SYMBOL(pci_enable_device_bars);
> EXPORT_SYMBOL(pci_enable_device);
> EXPORT_SYMBOL(pci_disable_device);
> EXPORT_SYMBOL(pci_max_busnr);
This one looks correct.
> diff -r -u linux-2.5.51/drivers/ide/Kconfig linux/drivers/ide/Kconfig
> --- linux-2.5.51/drivers/ide/Kconfig 2002-12-09 18:45:56.000000000 -0800
> +++ linux/drivers/ide/Kconfig 2002-11-27 18:23:46.000000000 -0800
> @@ -199,7 +199,7 @@
> depends on BLK_DEV_IDE
>
> config BLK_DEV_CMD640
> - bool "CMD640 chipset bugfix/support"
> + tristate "CMD640 chipset bugfix/support"
Please don't do this. You can't "load" the workaround meaningfully for
this device
> config BLK_DEV_GENERIC
> - bool "Generic PCI IDE Chipset Support"
> + tristate "Generic PCI IDE Chipset Support"
> depends on PCI && BLK_DEV_IDEPCI
Probably ok. I need to review that.
> -obj-$(CONFIG_BLK_DEV_IDE) += ide-io.o ide-probe.o ide-geometry.o ide-iops.o ide-taskfile.o ide.o ide-lib.o
> +obj-$(CONFIG_BLK_DEV_IDE) += ide-mod.o
> +ide-mod-objs += ide-io.o ide-probe.o ide-geometry.o ide-iops.o ide-taskfile.o ide.o ide-lib.o
Looks ok
> diff -r -u linux-2.5.51/drivers/ide/pci/cmd640.c linux/drivers/ide/pci/cmd640.c
> --- linux-2.5.51/drivers/ide/pci/cmd640.c 2002-12-09 18:46:22.000000000 -0800
> +++ linux/drivers/ide/pci/cmd640.c 2002-11-27 18:24:00.000000000 -0800
> @@ -102,6 +102,7 @@
No (as per comment above)
> --- linux-2.5.51/drivers/ide/ide-probe.c 2002-12-09 18:46:10.000000000 -0800
> +++ linux/drivers/ide/ide-probe.c 2002-12-12 23:50:58.000000000 -0800
> @@ -831,7 +831,8 @@
> ide_toggle_bounce(drive, 1);
>
> #ifdef CONFIG_BLK_DEV_IDE_TCQ_DEFAULT
> - HWIF(drive)->ide_dma_queued_on(drive);
> + if (HWIF(drive)->ide_dma_queued_on)
> + HWIF(drive)->ide_dma_queued_on(drive);
Looks right
At a first glance (and its only that), drop out the CMD640 changes and
the rest seems ok. Please check it on a few setups and also non modular
since you've changed the probe bits a little.
Alan
On Thu, 12 Dec 2002, Adam J. Richter wrote:
> something else?). For what it's worth, 2.5.51 + init-module-tools-0.9.3
> is the first kernel-based module loader configuration which works enough
> so that I'm able to work on other things. For the past few releases, I
> had been restoring user level module loading. There still are a lot of
> quirks with the kernel based module loading, but you might find it
> sufficient to get things done.
I just test your patch and IDE modules are working now on 2.5.51.
reiserfs, devmap and lvm2 are all working ... but the modules has
to be loaded in a certain order, otherwise the whole system would crash.
modprobe ide-mod
ide_info /dev/hda
--> this crashs the system
ide_mod looks for ide_hwifs, start_request, ide_do_request,
ide_do_drive_cmd, ide_diag_taskfile, ide_raw_taskfile,
taskfile_lib_get_identify, task_in_intr, proc_ide_read_identify,
proc_file_read, vfs_read, sys_read, syscall_call
modprobe ide-disk
ide_info /dev/hda
--> this works (ide-disk will load ide-mod first)
Under 2.4, I don't have to load the ide module first, calling fdisk
/dev/hda will automatically loads the ide modules, but under 2.5, I've to
manually load the ide modules.
Thanks,
Jeff.
On 2002-12-13, Alan Cox wrote:
>On Fri, 2002-12-13 at 07:59, Adam J. Richter wrote:
>> --- linux-2.5.51/drivers/pci/pci.c 2002-12-09 18:45:52.000000000 -0800
>> +++ linux/drivers/pci/pci.c 2002-12-09 19:03:18.000000000 -0800
[...]
>> diff -r -u linux-2.5.51/drivers/ide/Kconfig linux/drivers/ide/Kconfig
>> --- linux-2.5.51/drivers/ide/Kconfig 2002-12-09 18:45:56.000000000 -0800
>> +++ linux/drivers/ide/Kconfig 2002-11-27 18:23:46.000000000 -0800
>> @@ -199,7 +199,7 @@
>> depends on BLK_DEV_IDE
>>
>> config BLK_DEV_CMD640
>> - bool "CMD640 chipset bugfix/support"
>> + tristate "CMD640 chipset bugfix/support"
>Please don't do this. You can't "load" the workaround meaningfully for
>this device
I'd appreciate some clarification on what trouble the generic
IDE driver can get into when the cmd640 code is not present.
linux-2.5.52/Documentation/ide.txt says:
| For the CMD640, linux disables "IRQ unmasking" (hdparm -u1) on any
| drive for which the "prefetch" mode of the CMD640 is turned on.
| If "prefetch" is disabled (hdparm -p8), then "IRQ unmasking" can be
| used again.
|
| For the CMD640, linux disables "32bit I/O" (hdparm -c1) on any drive
| for which the "prefetch" mode of the CMD640 is turned off.
| If "prefetch" is enabled (hdparm -p9), then "32bit I/O" can be
| used again.
|
| The CMD640 is also used on some Vesa Local Bus (VLB) cards, and is *NOT*
| automatically detected by Linux. For safe, reliable operation with such
| interfaces, one *MUST* use the "ide0=cmd640_vlb" kernel option.
|
| Use of the "serialize" option is no longer necessary.
As I understand it, both IRQ unmasking and 32 bit I/O are off
by default. So, while a system could get into trouble by enabling
those options on a cmd640 system before the cmd640 module is loaded,
it sounds like it should be feasible to have IDE initially come up
without the cmd640 workarounds at a stage where the user level code
knows not to enable DMA or 32-bit PIO (for example, a boot floppy or
initial ramdisk), and then later loads the cmd640 workaround and other
PCI drivers (when a directory tree with a wider selection of modules
has been mounted).
I wouldn't mind submitting the other IDE modularization
changes first sorting out cmd640 modularization later, but doing so
would involve a couple of inelegant Makefile changes that would have
to be reversed if cmd640 could later be a separate module, because it
would inolvolve linking d a .o from a subdirectory to build a module
(ide-probe.o, ide.o, ..., pci/cmd640.o). So, I'd like to try to
understand now if this is really necessary.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
`h
I forgot to mention one thing in my the message that I sent
a minute ago: I understand that the cmd640_vlb kernel command line
argument needs to be settable via a module parameters for cmd640 to
be fully functional as a kernel module. I will take care of that
if making cmd640 a module would work in the scenario that I described
(userland is careful not to set 32-bit IO or IRQ unmasking until the
cmd640 module can be loaded).
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Wed, 2002-12-18 at 14:14, Adam J. Richter wrote:
> I'd appreciate some clarification on what trouble the generic
> IDE driver can get into when the cmd640 code is not present.
> linux-2.5.52/Documentation/ide.txt says:
I'll get back to 2.5 IDE things next year. For the moment I'm only
concerned in getting the modular stuff sorted out completely in 2.4.
Hopefully that will be mostly valid for 2.5 as well.
CMD640 has hooks into the code that need generalising and cleaning up.
Alan
On 18 Dec 2002, Alan Cox wrote:
> I'll get back to 2.5 IDE things next year. For the moment I'm only
> concerned in getting the modular stuff sorted out completely in 2.4.
> Hopefully that will be mostly valid for 2.5 as well.
I can't even boot 2.4.21-pre1 with IDE as modules. Works fine under 2.4.20
Looks like the IDE patch for 2.4.21-pre1 broke up the modules very similar
to 2.5.51
Thanks,
Jeff
Jeff,
Everybody cried screamed an whinned about making the chipsets modular.
Now that we are going do that path, you have no choice but to wait.
Use 2.4.20 and be happy. Or have FedEX write the check for it to be
worked on fulltime. I do not care which, but don't bitch about progress.
On 18 Dec 2002, Alan Cox wrote:
> On Wed, 2002-12-18 at 19:50, Jeff Chua wrote:
> >
> > On 18 Dec 2002, Alan Cox wrote:
> >
> > > I'll get back to 2.5 IDE things next year. For the moment I'm only
> > > concerned in getting the modular stuff sorted out completely in 2.4.
> > > Hopefully that will be mostly valid for 2.5 as well.
> >
> > I can't even boot 2.4.21-pre1 with IDE as modules. Works fine under 2.4.20
> >
> > Looks like the IDE patch for 2.4.21-pre1 broke up the modules very similar
> > to 2.5.51
>
> Yes it did, and I plan to fix it there first
>
Andre Hedrick
LAD Storage Consulting Group
On Wed, 2002-12-18 at 19:50, Jeff Chua wrote:
>
> On 18 Dec 2002, Alan Cox wrote:
>
> > I'll get back to 2.5 IDE things next year. For the moment I'm only
> > concerned in getting the modular stuff sorted out completely in 2.4.
> > Hopefully that will be mostly valid for 2.5 as well.
>
> I can't even boot 2.4.21-pre1 with IDE as modules. Works fine under 2.4.20
>
> Looks like the IDE patch for 2.4.21-pre1 broke up the modules very similar
> to 2.5.51
Yes it did, and I plan to fix it there first
Hi Everybody,
I wish you all a nice Christmas and A Happy New Year!
Now to the stuff that matters (for me 8) ):
I recently bought 4 80G IDE disks which I considered to combine into a
software RAID (RAID5). The four discs are connected via a Promise
Ultra100 TX2 (driver: PDC202xx, PDC20268 - I believe ;) ). It all works
fine for me just that the data throughput (i.e. speed) has been very
varying.
I had an older 80G IDE disc (yet capable of UDMA5) which I wanted to
make a spare disk.
This is my configuration:
raiddev /dev/md0
raid-level 5
nr-raid-disks 4
nr-spare-disks 1
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 64
## ALL NEW DISCS :)
device /dev/hde
raid-disk 0
device /dev/hdf
raid-disk 1
device /dev/hdg
raid-disk 2
device /dev/hdh
raid-disk 3
## GOOD, OLD, BRAVE DISC ;)
device /dev/hdc
spare-disk 0
Now to the funny part:
For some funny reason, a 2.4.20 kernel refuses to set the DMA-level on
the new disks (all connected to a UDMA5-capable Ultra100 TX2 controller)
to UDMA5,4,3 and settles it for UDMA2, which is the highest possibility
for the OLD onboard-controller (but NOT for the promise card). A recent
2.5.52 gives me :) UDMA5 on the new discs while (correctly) UDMA2 for
the old drive.
This is generally not a very big problem, I can live 8( with my new fine
discs only being used in UDMA2 (instead of 5).
After I initialized the array using 'mkraid /dev/md0' I open up 'while
true; do clear; cat /proc/mdstat; sleep 1; done' on one terminal to
watch the progress.
The first try I gave it was (very satisfying) giving me 15MB/sec at the
beginning. After about 30-40% the speed fell down to unsatisfying
100-200KB/sec (nothing CPU-intensive running besides raid5d).
I have been having problems with the older controller and I was not sure
about the throughput of the old drive, therefore I stopped the syncing,
stopped the raid and ran five synced (i.e. with a semaphore) bonnie++
processes to benchmark the discs, they all performed likely well (the
old one was a little slower at random seeks, but that was indeed
expected).
I tried the same thing on a 2.4.18 kernel (bf2.4 flavour from Debian
SID) but that gave me funny DMA timeout errors (something like DMA
timeout func 14 only supported) and kicked out one of (sporadic) my
newer drives from the array.
I wanted to try a 2.5.x kernel and settled for the newest one: 2.5.52
(vanilla). This wonderful kernel detected the UDMA5 capability of the
new drives and the new controller (veeery satisfying =) ) and gave me a
throughput of about 20-22MB/sec in the beginning. Sadly the system
Ooopsed at 30% percent giving me some DMA errors.
I have been wondering if it could be the powersupply, I have a 360W (max
load) powersupply, 4 new IBM 80G discs, 1 older 80G SEAGATE, 1 20G
MAXTOR.
Hmm, there it was again, one of my new drives got kicked out of the
array before the initial sync was ready.
The errors was (2.4.20):
<DATE> webber kernel: hdg: dma_intr: status=0x51
<DATE> webber kernel: hdg: end_request: I/O error, dev 22:00 (hdg)
sector 58033224
<DATE> webber kernel: hdg: dma_intr: status=0x51
<DATE> webber kernel: hdg: dma_intr: error=0x40 LBAsect=58033238,
sector=58033232
<DATE> webber kernel: end_request: I/O error, dev 22:00 (hdg), sector
58033232
Hmm, what could it be, this didn't happen while running bonnie++ :(
Any help will be appreciated,
Regards,
Mikael
--
Mikael Olenfalk <[email protected]>
Netgineers