One of the -rc4 fixes was not correct and -rc4 missed an important SMP
race "fix" on the block layer.
Summary of changes from v2.4.19-rc4 to v2.4.19-rc5
============================================
<[email protected]> (02/08/01 1.662)
[PATCH] Correct openprom fix
<[email protected]> (02/07/31 1.661)
[PATCH] Add missing check to openprom driver
<[email protected]> (02/08/01 1.663)
[PATCH] disable READA
<[email protected]> (02/08/01 1.664)
Change EXTRAVERSION to -rc5
On Thu, Aug 01 2002, Marcelo Tosatti wrote:
> <[email protected]> (02/08/01 1.663)
> [PATCH] disable READA
Since -rc5 is not to be found yet, I don't know what version of this
made it in. Is READA just being disabled on SMP, or was it the general
#if 0 change that got included? I'm asking since plain disabling READA
might have nasty performance effects. Andrew, I bet you did some numbers
on this, care to share?
--
Jens Axboe
patch-2.4.19-rc5.gz has been there for 25 minutes but the .bz2 file and
the signature have not been created yet. Is there a problem with the
automatic conversion and signing code on master?
On Thu, 1 Aug 2002, Jens Axboe wrote:
> On Thu, Aug 01 2002, Marcelo Tosatti wrote:
> > <[email protected]> (02/08/01 1.663)
> > [PATCH] disable READA
>
> Since -rc5 is not to be found yet, I don't know what version of this
> made it in. Is READA just being disabled on SMP, or was it the general
> #if 0 change that got included?
Its being disabled on UP and SMP. I dont like having such readahead IO
mode working only for UP.
> I'm asking since plain disabling READA might have nasty performance
> effects. Andrew, I bet you did some numbers on this, care to share?
If thats true (the performance effects) I'll release -final with IMO not
very coherent READA semantics :)
Anyway, lets wait for the numbers.
On Thu, Aug 01 2002, Marcelo Tosatti wrote:
>
> On Thu, 1 Aug 2002, Jens Axboe wrote:
>
> > On Thu, Aug 01 2002, Marcelo Tosatti wrote:
> > > <[email protected]> (02/08/01 1.663)
> > > [PATCH] disable READA
> >
> > Since -rc5 is not to be found yet, I don't know what version of this
> > made it in. Is READA just being disabled on SMP, or was it the general
> > #if 0 change that got included?
>
> Its being disabled on UP and SMP. I dont like having such readahead IO
> mode working only for UP.
You are right, that would be ugly. Should only be the last resort.
> > I'm asking since plain disabling READA might have nasty performance
> > effects. Andrew, I bet you did some numbers on this, care to share?
>
> If thats true (the performance effects) I'll release -final with IMO not
> very coherent READA semantics :)
>
> Anyway, lets wait for the numbers.
It just 'feels' like the sort of change that might have odd side
effects.
--
Jens Axboe
On Thu, Aug 01 2002, Keith Owens wrote:
> patch-2.4.19-rc5.gz has been there for 25 minutes but the .bz2 file and
> the signature have not been created yet. Is there a problem with the
> automatic conversion and signing code on master?
that is slow, hwoever it's there now.
--
Jens Axboe
Jens Axboe wrote:
>
> ...
> > Anyway, lets wait for the numbers.
>
> It just 'feels' like the sort of change that might have odd side
> effects.
It's almost impossible to get READA to do anything. For example, in
current 2.5, if a READA attempt is actually aborted, end_buffer_io_sync
reports a "buffer I/O error". Every time. And nobody has reported this.
It _is_ possible to hit this in 2.5, because of ext2_preread_inode().
Probably, also it's possible to hit it in 2.4 with hundreds of processes
all issuing ext3 directory readahead. But it's pretty remote.
On Thu, Aug 01 2002, Andrew Morton wrote:
> Jens Axboe wrote:
> >
> > ...
> > > Anyway, lets wait for the numbers.
> >
> > It just 'feels' like the sort of change that might have odd side
> > effects.
>
> It's almost impossible to get READA to do anything. For example, in
> current 2.5, if a READA attempt is actually aborted, end_buffer_io_sync
> reports a "buffer I/O error". Every time. And nobody has reported this.
Ahem, I've actually seen that happen :-). But maybe a total of 20 times
or so.
> It _is_ possible to hit this in 2.5, because of ext2_preread_inode().
>
> Probably, also it's possible to hit it in 2.4 with hundreds of processes
> all issuing ext3 directory readahead. But it's pretty remote.
Alright, I'm happy then.
--
Jens Axboe
Hi Marcello,
This is just a cleanup for the network devices configuration.
Basically, the TOSHIBA TC35815 configuration entry appears
just between DECchip Tulip, and the 2 Tulip-specific config lines
which are indented so we could think that they are related to
the TC35815 instead of the Tulip.
You only see them when Tulip is enabled though.
Here is the obvious fix against -rc5 which avoids this confusion :
Cheers,
Willy
--- linux-2.4.19-rc5/drivers/net/Config.in.orig Thu Aug 1 13:26:58 2002
+++ linux-2.4.19-rc5/drivers/net/Config.in Thu Aug 1 13:27:14 2002
@@ -162,8 +162,8 @@
dep_tristate ' Apricot Xen-II on board Ethernet' CONFIG_APRICOT $CONFIG_ISA
dep_tristate ' CS89x0 support' CONFIG_CS89x0 $CONFIG_ISA
- dep_tristate ' DECchip Tulip (dc21x4x) PCI support' CONFIG_TULIP $CONFIG_PCI
dep_tristate ' TOSHIBA TC35815 Ethernet support' CONFIG_TC35815 $CONFIG_PCI
+ dep_tristate ' DECchip Tulip (dc21x4x) PCI support' CONFIG_TULIP $CONFIG_PCI
if [ "$CONFIG_TULIP" = "y" -o "$CONFIG_TULIP" = "m" ]; then
dep_bool ' New bus configuration (EXPERIMENTAL)' CONFIG_TULIP_MWI $CONFIG_EXPERIMENTAL
bool ' Use PCI shared mem for NIC registers' CONFIG_TULIP_MMIO
Marcelo,
I observe a kernel panic at boot time if I set apm=power-off. OK with apm=off.
This is on an ASUS A7M266D with two Athlon XP 1800+. Since it works well on
2.4.19-pre10, I'm recompiling intermediate versions to check which one brought
the problem.
This is rather strange, since the crash occurs in do_softirq, but 2 bytes after
the beginning of an instruction :
c0120d09 fa cli
c0120d0a 8b b5 80 17 3c c0 mov 0xc03c1780(%ebp),%esi
The crash occurs at c0120d0c (80 17 3c c0 ...). Seems like a bad pointer
somewhere.
Regards,
Willy
On Thu, Aug 01, 2002 at 02:54:04PM +0100, Alan Cox wrote:
> On Thu, 2002-08-01 at 12:32, Willy TARREAU wrote:
> > Hi Marcello,
> >
> > This is just a cleanup for the network devices configuration.
> > Basically, the TOSHIBA TC35815 configuration entry appears
> > just between DECchip Tulip, and the 2 Tulip-specific config lines
> > which are indented so we could think that they are related to
> > the TC35815 instead of the Tulip.
>
> This is true, but the fix wants tweaking - the file is supposed to bein
> basically Alphabetical order. Can you move the toshiba one down instead
> ?
OK, in this case it goes just before VIA rhine. (BTW, [P]CI NE2000 is before
[N]ovell, but I assume we're talking about [N]E2000).
Marcelo, please ignore my previous patch in favor of this one.
Cheers,
Willy
--- linux-2.4.19-rc5/drivers/net/Config.in.orig Thu Aug 1 14:43:09 2002
+++ linux-2.4.19-rc5/drivers/net/Config.in Thu Aug 1 14:44:29 2002
@@ -163,7 +163,6 @@
dep_tristate ' Apricot Xen-II on board Ethernet' CONFIG_APRICOT $CONFIG_ISA
dep_tristate ' CS89x0 support' CONFIG_CS89x0 $CONFIG_ISA
dep_tristate ' DECchip Tulip (dc21x4x) PCI support' CONFIG_TULIP $CONFIG_PCI
- dep_tristate ' TOSHIBA TC35815 Ethernet support' CONFIG_TC35815 $CONFIG_PCI
if [ "$CONFIG_TULIP" = "y" -o "$CONFIG_TULIP" = "m" ]; then
dep_bool ' New bus configuration (EXPERIMENTAL)' CONFIG_TULIP_MWI $CONFIG_EXPERIMENTAL
bool ' Use PCI shared mem for NIC registers' CONFIG_TULIP_MMIO
@@ -195,6 +194,7 @@
if [ "$CONFIG_PCI" = "y" -o "$CONFIG_EISA" = "y" ]; then
tristate ' TI ThunderLAN support' CONFIG_TLAN
fi
+ dep_tristate ' TOSHIBA TC35815 Ethernet support' CONFIG_TC35815 $CONFIG_PCI
dep_tristate ' VIA Rhine support' CONFIG_VIA_RHINE $CONFIG_PCI
dep_mbool ' Use MMIO instead of PIO (EXPERIMENTAL)' CONFIG_VIA_RHINE_MMIO $CONFIG_VIA_RHINE $CONFIG_EXPERIMENTAL
dep_tristate ' Winbond W89c840 Ethernet support' CONFIG_WINBOND_840 $CONFIG_PCI
On Thu, 2002-08-01 at 12:32, Willy TARREAU wrote:
> Hi Marcello,
>
> This is just a cleanup for the network devices configuration.
> Basically, the TOSHIBA TC35815 configuration entry appears
> just between DECchip Tulip, and the 2 Tulip-specific config lines
> which are indented so we could think that they are related to
> the TC35815 instead of the Tulip.
This is true, but the fix wants tweaking - the file is supposed to bein
basically Alphabetical order. Can you move the toshiba one down instead
?
Marcelo,
I've narrowed down the APM problem encountered in -rc5. In fact, it also
affects -rc4, but not -rc3. I'm a bit stumped since the changes are not
too heavy...
The crash happens at the same place with -rc4 and -rc5 : 0xc0120d0c
c0120cec: fb sti
c0120ced: bb 40 a2 39 c0 mov $0xc039a240,%ebx
c0120cf2: f7 c6 01 00 00 00 test $0x1,%esi
c0120cf8: 74 08 je c0120d02 <do_softirq+0x72>
c0120cfa: 53 push %ebx
c0120cfb: 8b 03 mov (%ebx),%eax
c0120cfd: ff d0 call *%eax
c0120cff: 83 c4 04 add $0x4,%esp
c0120d02: 83 c3 08 add $0x8,%ebx
c0120d05: d1 ee shr %esi
c0120d07: 75 e9 jne c0120cf2 <do_softirq+0x62>
c0120d09: fa cli
c0120d0a: 8b b5 80 17 3c c0 mov 0xc03c1780(%ebp),%esi
^^ ^^ ^^ ^^
The processor branches here (2 bytes after local_irq_disable()) !!
c0120d10: 85 fe test %edi,%esi
c0120d12: 74 0c je c0120d20 <do_softirq+0x90>
c0120d14: 89 f0 mov %esi,%eax
c0120d16: f7 d0 not %eax
c0120d18: 21 c7 and %eax,%edi
c0120d1a: eb c6 jmp c0120ce2 <do_softirq+0x52>
This code is from do_softirq() in kernel/softirq.c, lines 84-95 :
local_irq_enable();
h = softirq_vec;
do {
if (pending & 1)
h->action(h);
h++;
pending >>= 1;
} while (pending);
local_irq_disable();
The hand-written traces show that this function was correctly called by
ksoftirqd(), which in turn was called by kernel_thread().
Part of the hand-written oops shows :
EFLAGS=00010057
eax=00000900 ebx=c039a260 ecx=00000000 edx=c0390000
esi=00000000 edi=fffffff7 ebp=00000000 esp=c15b1fc8
Since softirq_vec is c039a240 in my System.map, I can deduce that h->action(h)
has been called 4 times because it's 8 bytes long. <pending> is represented
by %esi here, which is null. So this implies that it's not the call to h->action(h)
which branched to this place. But int this case, I don't see how the CPU
can branch here (a ret prehaps ?). I don't see in what this can be related to
the "apm=power-off" case either.
Alan, I believe you have the same mobo, but with two MPs on it. Although I've
never had any SMP problem with XPs, did you notice anything strange with APM
on 2.4.19-rc[45] ? I will check 2.4.19-rc3-ac5 to see if it hangs too...
Cheers,
Willy
> Marcelo,
>
> I observe a kernel panic at boot time if I set apm=power-off. OK with apm=off.
> This is on an ASUS A7M266D with two Athlon XP 1800+. Since it works well on
> 2.4.19-pre10, I'm recompiling intermediate versions to check which one brought
> the problem.
>
> This is rather strange, since the crash occurs in do_softirq, but 2 bytes after
> the beginning of an instruction :
> c0120d09 fa cli
> c0120d0a 8b b5 80 17 3c c0 mov 0xc03c1780(%ebp),%esi
>
> The crash occurs at c0120d0c (80 17 3c c0 ...). Seems like a bad pointer
> somewhere.
On Thu, 2002-08-01 at 14:32, Willy TARREAU wrote:
> > I observe a kernel panic at boot time if I set apm=power-off. OK with apm=off.
> > This is on an ASUS A7M266D with two Athlon XP 1800+. Since it works well on
> > 2.4.19-pre10, I'm recompiling intermediate versions to check which one brought
> > the problem.
> >
> > This is rather strange, since the crash occurs in do_softirq, but 2 bytes after
I've only run -ac on the box (I need the IDE) and that has subtly
different APM code. I do not however understand why it has changed
behaviour. I could understand if it did it at the actual poweroff point
but not earlier
On Thu, Aug 01, 2002 at 03:55:32PM +0100, Alan Cox wrote:
> I've only run -ac on the box (I need the IDE) and that has subtly
> different APM code. I do not however understand why it has changed
> behaviour. I could understand if it did it at the actual poweroff point
> but not earlier
Ok, thanks. I'll try to revert some patches from -rc4. But it looks
more like a side effect IMHO. Perhaps the APM initialization code
triggers one of the numerous bugs in the bios :-/
If I enable APM in the bios, the crash is somewhat different. I get
about two pages of call traces looping back every 8 pointers.
Seems like a memory corruption to me...
2.4.19-rc3-ac5 is OK, BTW.
Cheers,
Willy
On Thu, 2002-08-01 at 03:02, Andrew Morton wrote:
> Jens Axboe wrote:
> >
> > ...
> > > Anyway, lets wait for the numbers.
> >
> > It just 'feels' like the sort of change that might have odd side
> > effects.
>
> It's almost impossible to get READA to do anything. For example, in
> current 2.5, if a READA attempt is actually aborted, end_buffer_io_sync
> reports a "buffer I/O error". Every time. And nobody has reported this.
>
> It _is_ possible to hit this in 2.5, because of ext2_preread_inode().
>
> Probably, also it's possible to hit it in 2.4 with hundreds of processes
> all issuing ext3 directory readahead. But it's pretty remote.
I've never seen this on 2.4.19-rc3 and I've been beating on it pretty
hard, running dbench 128 many times. However, 2.5 is another story.
This might not be the best thread to report this, but since the subject
came up, I'm getting the following message with recent 2.5.x kernels
whenever I run relatively large numbers of dbench clients.
Buffer I/O error on device sd(8,8), logical block XXXXXXX
where logical block repeats 0-6 times. This behavior is repeatable, but
only occurs under fairly high load. I ran dbench with increasing numbers
of clients, with the following results:
dbench clients Buffer I/O error messages
>=48 0
52 1
56 0
64 0
80 11
96 9
112 7
128 4
This particular run was with 2.5.29 with rmap13b and slabLRU patches, but the behavior with 2.5.29-vanilla was similar. Kernel is SMP, no preempt,
and /dev/sda8 where dbench was running was mounted ext2.
The test box is 2-way p3, SCSI, 1GB memory.
Time to go beat on -rc5 and see if anything falls out.
Steven
> Ok, thanks. I'll try to revert some patches from -rc4. But it looks
> more like a side effect IMHO. Perhaps the APM initialization code
> triggers one of the numerous bugs in the bios :-/
It seems that I cannot reproduce it anymore if I revert arch/i386/kernel/vm86.c
to the state of -rc3. Reverting clear_AC doesn't change anything, but the
rest of the patch does. I don't know why, it seems correct at first glance.
Perhaps old code hides a bug in the bios... Well, i don't know, I'm not
enough aware of apm or vm86 internals to understand what's happening.
Cheers,
Willy
On Thu, 2002-08-01 at 16:24, Willy Tarreau wrote:
> > Ok, thanks. I'll try to revert some patches from -rc4. But it looks
> > more like a side effect IMHO. Perhaps the APM initialization code
> > triggers one of the numerous bugs in the bios :-/
>
> It seems that I cannot reproduce it anymore if I revert arch/i386/kernel/vm86.c
> to the state of -rc3. Reverting clear_AC doesn't change anything, but the
> rest of the patch does. I don't know why, it seems correct at first glance.
> Perhaps old code hides a bug in the bios... Well, i don't know, I'm not
> enough aware of apm or vm86 internals to understand what's happening.
Very curious indeed because someone else reported that rc3-ac5 works
(which has the same vm86 code). In addition the vm86 handler in the
kernel isnt actually used for APM. We make 32bit APM calls and the one
16bit case we do is a true return to real mode.
On Thu, Aug 01, 2002 at 05:53:46PM +0100, Alan Cox wrote:
> Very curious indeed because someone else reported that rc3-ac5 works
> (which has the same vm86 code). In addition the vm86 handler in the
> kernel isnt actually used for APM. We make 32bit APM calls and the one
> 16bit case we do is a true return to real mode.
well, I saw it wrong. In fact, sometimes the system boots OK if it
is after a warm boot, and it seems that all the tests I've done with
"old" vm86 code were done from a warm boot. Now I can confirm that
from a cold boot, it also panics. And you're right about rc3-ac5,
since it also works for me.
Still searching...
Willy
Steven Cole wrote:
>
> ...
> I've never seen this on 2.4.19-rc3 and I've been beating on it pretty
> hard, running dbench 128 many times. However, 2.5 is another story.
>
> This might not be the best thread to report this, but since the subject
> came up, I'm getting the following message with recent 2.5.x kernels
> whenever I run relatively large numbers of dbench clients.
>
> Buffer I/O error on device sd(8,8), logical block XXXXXXX
>
> where logical block repeats 0-6 times. This behavior is repeatable, but
> only occurs under fairly high load. I ran dbench with increasing numbers
> of clients, with the following results:
>
> dbench clients Buffer I/O error messages
> >=48 0
> 52 1
> 56 0
> 64 0
> 80 11
> 96 9
> 112 7
> 128 4
Yup. The printk is bogus - I thought I'd removed it a couple of
kernels ago.
It's a bit sad that an abandoned readahead attempt is indistinguishable
from a dead disk.
-
On Thu, 2002-08-01 at 01:14, Marcelo Tosatti wrote:
>
> On Thu, 1 Aug 2002, Jens Axboe wrote:
>
> > On Thu, Aug 01 2002, Marcelo Tosatti wrote:
> > > <[email protected]> (02/08/01 1.663)
> > > [PATCH] disable READA
> >
> > Since -rc5 is not to be found yet, I don't know what version of this
> > made it in. Is READA just being disabled on SMP, or was it the general
> > #if 0 change that got included?
>
> Its being disabled on UP and SMP. I dont like having such readahead IO
> mode working only for UP.
>
> > I'm asking since plain disabling READA might have nasty performance
> > effects. Andrew, I bet you did some numbers on this, care to share?
>
> If thats true (the performance effects) I'll release -final with IMO not
> very coherent READA semantics :)
>
> Anyway, lets wait for the numbers.
Marcelo,
Here are some dbench numbers, from the "for what it's worth" department.
This was done with SMP kernels, on a dual p3 box, SCSI disk, ext2.
The first column is dbench clients. The numbers are throughput
in MB/sec. The 2.5.29 kernel had a few RR-supplied smp fixes.
Looks like for this limited test, 2.4.19-rc5 holds up pretty well.
I've also ran this set of tests several times on -rc5 using ext3
and data=writeback, and everything looks fine.
Steven
2.4.19-rc2 2.4.19-rc5 2.5.29
1 114.616 113.402 112.668
2 173.234 183.829 175.148
3 185.995 187.411 184.63
4 185.447 186.891 188.199
6 191.115 191.439 191.787
8 191.962 191.551 191.53
10 192.984 194.036 194.923
12 183.847 185.73 195.328
16 183.609 183.439 196.224
20 181.519 179.956 193.681
24 183.509 183.387 194.09
28 176.04 175.832 169.326
32 174.583 163.09 137.815
36 155.04 164.154 121.861
40 155.37 156.028 102.014
44 152.546 138.171 91.6088
48 146.419 135.447 84.3884
52 139.788 125.968 89.2374
56 113.933 122.592 81.021
64 110.792 106.484 84.648
80 87.4692 60.6054
96 87.7201 57.9622
112 74.9503 49.468
128 67.2649 47.0254
On Thu, Aug 01, 2002 at 05:53:46PM +0100, Alan Cox wrote:
> Very curious indeed because someone else reported that rc3-ac5 works
> (which has the same vm86 code). In addition the vm86 handler in the
> kernel isnt actually used for APM. We make 32bit APM calls and the one
> 16bit case we do is a true return to real mode.
I finally got rid of it ! I now understand why it hanged randomly, and
why I spent lots of time adding/removing unrelated patches. It's because
in apm=power-off mode (SMP), a kernel thread is started for the apm()
function, which does bios calls. And sometimes, the bios is called from
CPU >0, which my bios doesn't like at all, thus explaining why the oopses
were corrupted.
By copying a piece of code somewhere else in the same file, I could force
apm() to be used only by CPU0. I could verify that it doesn't crash anymore,
and that I can also crash it on demand if I force CPU1.
The bonus is that I could re-enable the debug code in this function even
in SMP mode since we're sure that it runs on CPU0.
Here is the patch against 2.4.19-rc5. Marcelo, Alan, please review and apply.
Cheers,
Willy
diff -urN linux-2.4.19-rc5/arch/i386/kernel/apm.c linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c
--- linux-2.4.19-rc5/arch/i386/kernel/apm.c Thu Aug 1 22:07:39 2002
+++ linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c Thu Aug 1 22:26:56 2002
@@ -1661,6 +1661,17 @@
strcpy(current->comm, "kapmd");
sigfillset(¤t->blocked);
+#ifdef CONFIG_SMP
+ /* 2002/08/01 - WT
+ * This is to avoid random crashes at boot time during initialization
+ * on SMP systems in case of "apm=power-off" mode. Seen on ASUS A7M266D.
+ * Some bioses don't like being called from CPU != 0.
+ */
+ while (cpu_number_map(smp_processor_id()) != 0) {
+ schedule();
+ }
+#endif
+
if (apm_info.connection_version == 0) {
apm_info.connection_version = apm_info.bios.version;
if (apm_info.connection_version > 0x100) {
@@ -1707,7 +1718,7 @@
}
}
- if (debug && (smp_num_cpus == 1)) {
+ if (debug) {
error = apm_get_power_status(&bx, &cx, &dx);
if (error)
printk(KERN_INFO "apm: power status not available\n");
Willy TARREAU writes:
> I finally got rid of it ! I now understand why it hanged randomly, and
> why I spent lots of time adding/removing unrelated patches. It's because
> in apm=power-off mode (SMP), a kernel thread is started for the apm()
> function, which does bios calls. And sometimes, the bios is called from
> CPU >0, which my bios doesn't like at all, thus explaining why the oopses
> were corrupted.
[...]
> diff -urN linux-2.4.19-rc5/arch/i386/kernel/apm.c linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c
> --- linux-2.4.19-rc5/arch/i386/kernel/apm.c Thu Aug 1 22:07:39 2002
> +++ linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c Thu Aug 1 22:26:56 2002
> @@ -1661,6 +1661,17 @@
> strcpy(current->comm, "kapmd");
> sigfillset(¤t->blocked);
>
> +#ifdef CONFIG_SMP
> + /* 2002/08/01 - WT
> + * This is to avoid random crashes at boot time during initialization
> + * on SMP systems in case of "apm=power-off" mode. Seen on ASUS A7M266D.
> + * Some bioses don't like being called from CPU != 0.
> + */
> + while (cpu_number_map(smp_processor_id()) != 0) {
> + schedule();
> + }
> +#endif
> +
Hm. I bet you didn't try this with CONFIG_PREEMPT=y, right? IIRC, the
wonderful world of preemption means that you can get rescheduled on
another CPU without warning, unless you take a lock or explicitely
disable preemption.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Thu, Aug 01, 2002 at 02:52:16PM -0600, Richard Gooch wrote:
> > diff -urN linux-2.4.19-rc5/arch/i386/kernel/apm.c linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c
> > --- linux-2.4.19-rc5/arch/i386/kernel/apm.c Thu Aug 1 22:07:39 2002
> > +++ linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c Thu Aug 1 22:26:56 2002
>
> Hm. I bet you didn't try this with CONFIG_PREEMPT=y, right? IIRC, the
> wonderful world of preemption means that you can get rescheduled on
> another CPU without warning, unless you take a lock or explicitely
> disable preemption.
It's a 2.4 patch. Leave preemption problems to those insane
enough to run 2.4+preempt.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Thu, 2002-08-01 at 21:35, Willy TARREAU wrote:
>
> +#ifdef CONFIG_SMP
> + /* 2002/08/01 - WT
> + * This is to avoid random crashes at boot time during initialization
> + * on SMP systems in case of "apm=power-off" mode. Seen on ASUS A7M266D.
> + * Some bioses don't like being called from CPU != 0.
> + */
> + while (cpu_number_map(smp_processor_id()) != 0) {
> + schedule();
> + }
> +#endif
What guarantees that loop will ever exit ?
Richard Gooch writes:
> Hm. I bet you didn't try this with CONFIG_PREEMPT=y, right? IIRC, the
> wonderful world of preemption means that you can get rescheduled on
> another CPU without warning, unless you take a lock or explicitely
> disable preemption.
Apologies. I forgot that CONFIG_PREEMPT is a 2.5.x feature, and
doesn't exist on 2.4 (thankfully).
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
On Thu, Aug 01, 2002 at 11:16:23PM +0100, Alan Cox wrote:
> On Thu, 2002-08-01 at 21:35, Willy TARREAU wrote:
> > + while (cpu_number_map(smp_processor_id()) != 0) {
> > + schedule();
> > + }
> What guarantees that loop will ever exit ?
none, as in the already existing other implementation. But at least, I'd
prefer an infinite loop instead of some random code being executed without
noticing it.
Do you know a better way of doing that ? The other implementation
used a fake thread which also did a schedule(). I wonder if this
is to make the scheduler work a bit more so that we get more
chances to swap the CPU.
Cheers,
Willy
On Thu, Aug 01, 2002 at 02:54:08PM -0600, Richard Gooch wrote:
> Richard Gooch writes:
> > Hm. I bet you didn't try this with CONFIG_PREEMPT=y, right? IIRC, the
> > wonderful world of preemption means that you can get rescheduled on
> > another CPU without warning, unless you take a lock or explicitely
> > disable preemption.
>
> Apologies. I forgot that CONFIG_PREEMPT is a 2.5.x feature, and
> doesn't exist on 2.4 (thankfully).
Never mind, your comment is interesting anyway because it shows that
preemption patch for 2.4 needs to adapt to such updates.
Thanks,
willy
On Thu, 2002-08-01 at 22:17, Willy TARREAU wrote:
> On Thu, Aug 01, 2002 at 02:54:08PM -0600, Richard Gooch wrote:
> > Richard Gooch writes:
> > > Hm. I bet you didn't try this with CONFIG_PREEMPT=y, right? IIRC, the
> > > wonderful world of preemption means that you can get rescheduled on
> > > another CPU without warning, unless you take a lock or explicitely
> > > disable preemption.
> >
> > Apologies. I forgot that CONFIG_PREEMPT is a 2.5.x feature, and
> > doesn't exist on 2.4 (thankfully).
>
> Never mind, your comment is interesting anyway because it shows that
> preemption patch for 2.4 needs to adapt to such updates.
Pre-emption for 2.4 needs to do a lot of work on raid and even athlon
compiles to fix the FPU stuff, let alone corner cases
In article <[email protected]>,
Willy Tarreau <[email protected]> wrote:
>On Thu, Aug 01, 2002 at 11:16:23PM +0100, Alan Cox wrote:
>> On Thu, 2002-08-01 at 21:35, Willy TARREAU wrote:
>> > + while (cpu_number_map(smp_processor_id()) != 0) {
>> > + schedule();
>> > + }
>
>> What guarantees that loop will ever exit ?
>
>none, as in the already existing other implementation. But at least, I'd
>prefer an infinite loop instead of some random code being executed without
>noticing it.
>
>Do you know a better way of doing that ?
It should set its CPU affinity to be cpu0. I don't know how well that
works in 2.4.x, though. Ask Ingo..
Linus
On Thu, Aug 01, 2002 at 11:16:23PM +0100, Alan Cox wrote:
> On Thu, 2002-08-01 at 21:35, Willy TARREAU wrote:
> > +#ifdef CONFIG_SMP
> > + /* 2002/08/01 - WT
> > + * This is to avoid random crashes at boot time during initialization
> > + * on SMP systems in case of "apm=power-off" mode. Seen on ASUS A7M266D.
> > + * Some bioses don't like being called from CPU != 0.
> > + */
> > + while (cpu_number_map(smp_processor_id()) != 0) {
> > + schedule();
> > + }
> > +#endif
>
> What guarantees that loop will ever exit ?
I asked Ingo for some advice, and he gently sent me a piece of code as an
example of how to reliably bind a task to a CPU. I tried it, and it's OK here.
I could reliably switch several times from cpu0 to cpu1, then back to cpu0.
Since it was cleaner than the previous method, I also did the same for
apm_power_off(), thus getting rid of apm_magic() and its dedicated thread.
Then again, I tested with multiple cpu switches, and every time, my system
correctly handles the case. I'm writing this mail under 2.4.19-rc5.
So here is the patch against 2.4.19-rc5, hoping it will get in this time.
I think it should apply without a glitch to 2.4.19-rc5-ac1, but don't
know about 2.5, nor even if it is needed.
Feedback welcome, of course ;-)
Cheers,
Willy
--- linux-2.4.19-rc5/arch/i386/kernel/apm.c Thu Aug 1 22:07:39 2002
+++ linux-2.4.19-rc5-fix/arch/i386/kernel/apm.c Fri Aug 2 01:52:55 2002
@@ -862,14 +862,6 @@
apm_do_busy();
}
-#ifdef CONFIG_SMP
-static int apm_magic(void * unused)
-{
- while (1)
- schedule();
-}
-#endif
-
/**
* apm_power_off - ask the BIOS to power off
*
@@ -897,10 +889,11 @@
*/
#ifdef CONFIG_SMP
/* Some bioses don't like being called from CPU != 0 */
- while (cpu_number_map(smp_processor_id()) != 0) {
- kernel_thread(apm_magic, NULL,
- CLONE_FS | CLONE_FILES | CLONE_SIGHAND | SIGCHLD);
+ if (cpu_number_map(smp_processor_id()) != 0) {
+ current->cpus_allowed = 1;
schedule();
+ if (unlikely(cpu_number_map(smp_processor_id()) != 0))
+ BUG();
}
#endif
if (apm_info.realmode_power_off)
@@ -1661,6 +1654,21 @@
strcpy(current->comm, "kapmd");
sigfillset(¤t->blocked);
+#ifdef CONFIG_SMP
+ /* 2002/08/01 - WT
+ * This is to avoid random crashes at boot time during initialization
+ * on SMP systems in case of "apm=power-off" mode. Seen on ASUS A7M266D.
+ * Some bioses don't like being called from CPU != 0.
+ * Method suggested by Ingo Molnar.
+ */
+ if (cpu_number_map(smp_processor_id()) != 0) {
+ current->cpus_allowed = 1;
+ schedule();
+ if (unlikely(cpu_number_map(smp_processor_id()) != 0))
+ BUG();
+ }
+#endif
+
if (apm_info.connection_version == 0) {
apm_info.connection_version = apm_info.bios.version;
if (apm_info.connection_version > 0x100) {
@@ -1707,7 +1715,7 @@
}
}
- if (debug && (smp_num_cpus == 1)) {
+ if (debug) {
error = apm_get_power_status(&bx, &cx, &dx);
if (error)
printk(KERN_INFO "apm: power status not available\n");
> <[email protected]> (02/07/19 1.646)
> Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
Because of this fix my Promise 20265 became ide0 instead of ide2.
Is there any reason to mark pdc20265 as ON_BOARD controller?
Anyway, attached patch fix it for me :)
--
With best wishes,
Nick Orlov.
On Thu, Aug 01, 2002 at 09:47:28PM -0400, Nick Orlov wrote:
>
> > <[email protected]> (02/07/19 1.646)
> > Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
>
> Because of this fix my Promise 20265 became ide0 instead of ide2.
> Is there any reason to mark pdc20265 as ON_BOARD controller?
>
> Anyway, attached patch fix it for me :)
>
Sorry, wrong diff format. Rediffed and attached.
--
With best wishes,
Nick Orlov.
On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
>
> > <[email protected]> (02/07/19 1.646)
> > Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
>
> Because of this fix my Promise 20265 became ide0 instead of ide2.
> Is there any reason to mark pdc20265 as ON_BOARD controller?
How about because it can be and it should be checked. I don't know what
is going on with the ifdef in your case to cause this but its not as
simple as it seems
On Fri, Aug 02, 2002 at 01:27:25PM +0100, Alan Cox wrote:
> On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
> >
> > > <[email protected]> (02/07/19 1.646)
> > > Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> >
> > Because of this fix my Promise 20265 became ide0 instead of ide2.
> > Is there any reason to mark pdc20265 as ON_BOARD controller?
>
> How about because it can be and it should be checked. I don't know what
> is going on with the ifdef in your case to cause this but its not as
> simple as it seems
Why pdc20265 is so special ? All other Promises marked as OFF_BOARD...
And what determines how id will be assigned to controllers if both of
them are ON_BOARD ?
--
With best wishes,
Nick Orlov.
On Fri, 2 Aug 2002, Nick Orlov wrote:
> On Fri, Aug 02, 2002 at 01:27:25PM +0100, Alan Cox wrote:
> > On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
> > >
> > > > <[email protected]> (02/07/19 1.646)
> > > > Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> > >
> > > Because of this fix my Promise 20265 became ide0 instead of ide2.
> > > Is there any reason to mark pdc20265 as ON_BOARD controller?
> >
> > How about because it can be and it should be checked. I don't know what
> > is going on with the ifdef in your case to cause this but its not as
> > simple as it seems
>
> Why pdc20265 is so special ? All other Promises marked as OFF_BOARD...
>
> And what determines how id will be assigned to controllers if both of
> them are ON_BOARD ?
AFAIR problem is that some vendors included onboard 20265 as primary
device (playing tricks for that) and to be consistent we have to treat it as
onboard, we have right now no way to check if it is on or offboard.
EDD support will probably help here.
Regards
--
Bartlomiej
> --
> With best wishes,
> Nick Orlov.
On Fri, Aug 02, 2002 at 04:00:32PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> On Fri, 2 Aug 2002, Nick Orlov wrote:
>
> > On Fri, Aug 02, 2002 at 01:27:25PM +0100, Alan Cox wrote:
> > > On Fri, 2002-08-02 at 02:47, Nick Orlov wrote:
> > > >
> > > > > <[email protected]> (02/07/19 1.646)
> > > > > Fix wrong #ifdef in ide-pci.c: Was causing problems with FastTrak
> > > >
> > > > Because of this fix my Promise 20265 became ide0 instead of ide2.
> > > > Is there any reason to mark pdc20265 as ON_BOARD controller?
> > >
> > > How about because it can be and it should be checked. I don't know what
> > > is going on with the ifdef in your case to cause this but its not as
> > > simple as it seems
> >
> > Why pdc20265 is so special ? All other Promises marked as OFF_BOARD...
> >
> > And what determines how id will be assigned to controllers if both of
> > them are ON_BOARD ?
>
> AFAIR problem is that some vendors included onboard 20265 as primary
> device (playing tricks for that) and to be consistent we have to treat it as
> onboard, we have right now no way to check if it is on or offboard.
> EDD support will probably help here.
>
Just FYI,
before these "#ifdef" fixes it was treated as OFF_BOARD unless
CONFIG_PDC202XX_FORCE is set. (now it's inverted)
And my point is that it does not matter how physically this controller
installed - onboard or offboard. Idea is that we should have control
which controller should be treated as "primary" (ide0/1) and which as
"secondary" (ide2/3). I don't see/know how we can do it unless we mark
one of controllers ON_BOARD and another OFF_BOARD and play with
CONFIG_BLK_DEV_OFFBOARD.
And also I don't believe that this is good idea to treat one of Promises so
differently.
--
With best wishes,
Nick Orlov.
> Just FYI,
>
> before these "#ifdef" fixes it was treated as OFF_BOARD unless
> CONFIG_PDC202XX_FORCE is set. (now it's inverted)
This should be fixed.
>
> And my point is that it does not matter how physically this controller
> installed - onboard or offboard. Idea is that we should have control
It is not on/offboard case. It is primary/secondary boot device case.
> which controller should be treated as "primary" (ide0/1) and which as
> "secondary" (ide2/3). I don't see/know how we can do it unless we mark
> one of controllers ON_BOARD and another OFF_BOARD and play with
> CONFIG_BLK_DEV_OFFBOARD.
Yes.
> And also I don't believe that this is good idea to treat one of Promises
> so differently.
Once again - on some machines it is primary IDE (booting one), so we have
to give user possibility for 'onboarding' it. However it should depend on
CONFIG_PDC202XX_FORCE... hmm... but on others it is offboard so distro
compiled kernels might have problem here :\.
Regards
--
Bartlomiej
On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
>
> > Just FYI,
> >
> > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
>
> This should be fixed.
If we change the #ifdef on ide-pci.c it will skip some controllers which
worked before _without_ CONFIG_PDC202XX_FORCE set.
On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
>
> On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> > On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > > Just FYI,
> > > >
> > > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> > >
> > > This should be fixed.
> >
> > If we change the #ifdef on ide-pci.c it will skip some controllers which
> > worked before _without_ CONFIG_PDC202XX_FORCE set.
>
> I was thinking about changing it globally to do what its name suggest.
>
> Main problem is that before introducing skipping Promises, FORCE
> controlled overriding BIOS only (?) and now it is also used to control
> 'skipping'. (FORCE should be by default on of course)
> Probably 'skipping' should be separated to another config option...
Indeed. I appreciate patches ;)
>
> And second problem is that 20265 is used as primary onboard
> sometimes and sometimes as offboard (another config option?).
On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > Just FYI,
> > >
> > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> >
> > This should be fixed.
>
> If we change the #ifdef on ide-pci.c it will skip some controllers which
> worked before _without_ CONFIG_PDC202XX_FORCE set.
I was thinking about changing it globally to do what its name suggest.
Main problem is that before introducing skipping Promises, FORCE
controlled overriding BIOS only (?) and now it is also used to control
'skipping'. (FORCE should be by default on of course)
Probably 'skipping' should be separated to another config option...
And second problem is that 20265 is used as primary onboard
sometimes and sometimes as offboard (another config option?).
Regards
--
puzzled Bartlomiej
On Sat, Aug 03, 2002 at 02:55:21AM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> > On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > > Just FYI,
> > > >
> > > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> > >
> > > This should be fixed.
> >
> > If we change the #ifdef on ide-pci.c it will skip some controllers which
> > worked before _without_ CONFIG_PDC202XX_FORCE set.
>
> I was thinking about changing it globally to do what its name suggest.
>
> Main problem is that before introducing skipping Promises, FORCE
> controlled overriding BIOS only (?) and now it is also used to control
> 'skipping'. (FORCE should be by default on of course)
> Probably 'skipping' should be separated to another config option...
>
> And second problem is that 20265 is used as primary onboard
> sometimes and sometimes as offboard (another config option?).
>
I think that question is _how often_ pdc20265 is used as primary
controller? Actually I know a lot of mobos with pdc20265 as additional
controller (and I don't see the one that uses it as primary).
Don't forget about "ide=reverse" parameter that allows you to treat
pdc20265 as primary if by default kernel treat pdc20265 as secondary.
So I don't see _any_ reason to force pdc20265 to be primary (onboard)
unless CONFIG_PDC202XX_FORCE is set.
--
With best wishes,
Nick Orlov.
On Sat, 2002-08-03 at 02:22, Nick Orlov wrote:
> I think that question is _how often_ pdc20265 is used as primary
> controller? Actually I know a lot of mobos with pdc20265 as additional
> controller (and I don't see the one that uses it as primary).
>
> Don't forget about "ide=reverse" parameter that allows you to treat
> pdc20265 as primary if by default kernel treat pdc20265 as secondary.
>
> So I don't see _any_ reason to force pdc20265 to be primary (onboard)
> unless CONFIG_PDC202XX_FORCE is set.
This is the wrong question.
The right question for a stable kernel is "Why isnt it behaving
precisely the same way as it did before the merge". What got confused in
the _FORCE stuff. Why did _FORCE checks even get into the raid probe not
another config option...
On Fri, Aug 02, 2002 at 09:08:15PM -0300, Marcelo Tosatti wrote:
>
>
> On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
>
> >
> > On Fri, 2 Aug 2002, Marcelo Tosatti wrote:
> > > On Fri, 2 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> > > > > Just FYI,
> > > > >
> > > > > before these "#ifdef" fixes it was treated as OFF_BOARD unless
> > > > > CONFIG_PDC202XX_FORCE is set. (now it's inverted)
> > > >
> > > > This should be fixed.
> > >
> > > If we change the #ifdef on ide-pci.c it will skip some controllers which
> > > worked before _without_ CONFIG_PDC202XX_FORCE set.
> >
> > I was thinking about changing it globally to do what its name suggest.
> >
> > Main problem is that before introducing skipping Promises, FORCE
> > controlled overriding BIOS only (?) and now it is also used to control
> > 'skipping'. (FORCE should be by default on of course)
> > Probably 'skipping' should be separated to another config option...
>
> Indeed. I appreciate patches ;)
>
New config option added (CONFIG_PDC20265_ONBOARD).
Comments / suggestions highly appreciated :)
--
With best wishes,
Nick Orlov.
On Sat, Aug 03, 2002 at 11:37:34AM -0400, Nick Orlov wrote:
>
> New config option added (CONFIG_PDC20265_ONBOARD).
> Comments / suggestions highly appreciated :)
>
Slightly changed according to Bartlomiej's comments patch attached.
--
With best wishes,
Nick Orlov.
Keith Owens wrote:
> patch-2.4.19-rc5.gz has been there for 25 minutes but the .bz2 file and
> the signature have not been created yet. Is there a problem with the
> automatic conversion and signing code on master?
The sign/convert/upload machinery is sometimes slow when it is either
transferring large files, or doing its daily "rsync --checksum" for
paranoia's sake. The latter happens at 00:00 local time, currently
17:00 UTC.
-hpa
On Mon, Aug 05, 2002 at 11:48:47PM -0400, Bill Davidsen wrote:
> On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
>
> > And second problem is that 20265 is used as primary onboard
> > sometimes and sometimes as offboard (another config option?).
>
> Can that not be configured at boot time with ide0=xxx or similar? I'm
> clearly missing why it would matter on or off board as long as the
> controller(s) were checked in the right order.
>
I'm not expert in this field, but my current understanding is:
1. ide0/1 reserved for onboard controllers.
2. on most hardware, pdc20xxx is really additional controller.
3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
4. ide0=<what> ??? (do we have this option?)
Correct me, if I'm wrong.
--
With best wishes,
Nick Orlov.
On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
> And second problem is that 20265 is used as primary onboard
> sometimes and sometimes as offboard (another config option?).
Can that not be configured at boot time with ide0=xxx or similar? I'm
clearly missing why it would matter on or off board as long as the
controller(s) were checked in the right order.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Bill Davidsen wrote:
>
> On 1 Aug 2002, Steven Cole wrote:
>
> > Here are some dbench numbers, from the "for what it's worth" department.
> > This was done with SMP kernels, on a dual p3 box, SCSI disk, ext2.
> > The first column is dbench clients. The numbers are throughput
> > in MB/sec. The 2.5.29 kernel had a few RR-supplied smp fixes.
> > Looks like for this limited test, 2.4.19-rc5 holds up pretty well.
> > I've also ran this set of tests several times on -rc5 using ext3
> > and data=writeback, and everything looks fine.
> >
> > Steven
>
> Call me an optimist, but after all the reliability problems we had win the
> 2.5 series, I sort of hoped it would be better in performance, not
> increasingly worse. Am I misreading this? Can we fall back to the faster
> 2.4 code :-(
IO in 2.5 is much more CPU efficient that in 2.4, and straight-line
bandwidth is better as well.
The scheduling of that IO has a few problems, so in wildly seeky loads
like dbench the kernel still falls over its own feet a bit. The
two main culprits here are the lock_buffer() in block_write_full_page()
against the blockdev mapping, and the writeback of dirty pages from the
tail of the LRU in page reclaim.
And no, the eventual dbench numbers will not be a measure of the success
of the tuning which will happen on the run in to 2.6. Dbench throughput
may well be lower, because we probably should be starting writeback
at lower dirty thresholds.
If you want good dbench numbers:
echo 70 > /proc/sys/vm/dirty_background_ratio
echo 75 > /proc/sys/vm/dirty_async_ratio
echo 80 > /proc/sys/vm/dirty_sync_ratio
echo 30000 > /proc/sys/vm/dirty_expire_centisecs
On Mon, Aug 05 2002, Bill Davidsen wrote:
> On 1 Aug 2002, Steven Cole wrote:
>
> > Here are some dbench numbers, from the "for what it's worth" department.
> > This was done with SMP kernels, on a dual p3 box, SCSI disk, ext2.
> > The first column is dbench clients. The numbers are throughput
> > in MB/sec. The 2.5.29 kernel had a few RR-supplied smp fixes.
> > Looks like for this limited test, 2.4.19-rc5 holds up pretty well.
> > I've also ran this set of tests several times on -rc5 using ext3
> > and data=writeback, and everything looks fine.
> >
> > Steven
>
> Call me an optimist, but after all the reliability problems we had win the
> 2.5 series, I sort of hoped it would be better in performance, not
> increasingly worse. Am I misreading this? Can we fall back to the faster
> 2.4 code :-(
try a work load that excercises the block i/o layer alone (O_DIRECT,
raw, whatnot) and then compare 2.4 and 2.5. ibm had some slides on this
from ols, unfortunately I don't know if they have then online.
please don't put too much wait in dbench numbers for this sort of thing
:-)
--
Jens Axboe
> I sort of hoped it would be better in performance, not
> increasingly worse.
There were a lot of improvements during the 2.4.19-pre series on
several I/O benchmarks. Comparing 2.4.18 to 2.4.19 on a quad xeon.
Here are a few of the big changes (average of 5 runs):
200% improvement on reiserfs for dbench 192
125% improvement on ext3 for dbench 192
248% improvement on ext2 for dbench 192
40% improvement on reiserfs for dbench 64
30% improvement on ext3 for dbench 64
67% improvement on ext2 for dbench 64
30% improvement on ext2 for tiobench seq reads with threads >= 32
100% improvement on ext2 and reiserfs for tiobench seq writes with threads >= 32
300% drop in cpu usage on ext3 for tiobench seq reads
(latency and throughput also improved)
In most cases, average and max tiobench latency went down with 2.4.19.
Max sequential write latency with one thread on ext2 went up 1000% though.
imho, it's worthwhile to track and investigate regressions
and improvements.
More benchmarks and several pre's and rc's in between at:
http://home.earthlink.net/~rwhron/kernel/bigbox.html
Small boxes are important too:
http://home.earthlink.net/~rwhron/kernel/k6-2-475.html
--
Randy Hron
On 1 Aug 2002, Steven Cole wrote:
> Here are some dbench numbers, from the "for what it's worth" department.
> This was done with SMP kernels, on a dual p3 box, SCSI disk, ext2.
> The first column is dbench clients. The numbers are throughput
> in MB/sec. The 2.5.29 kernel had a few RR-supplied smp fixes.
> Looks like for this limited test, 2.4.19-rc5 holds up pretty well.
> I've also ran this set of tests several times on -rc5 using ext3
> and data=writeback, and everything looks fine.
>
> Steven
Call me an optimist, but after all the reliability problems we had win the
2.5 series, I sort of hoped it would be better in performance, not
increasingly worse. Am I misreading this? Can we fall back to the faster
2.4 code :-(
> 2.4.19-rc2 2.4.19-rc5 2.5.29
>
> 1 114.616 113.402 112.668
> 2 173.234 183.829 175.148
> 3 185.995 187.411 184.63
> 4 185.447 186.891 188.199
> 6 191.115 191.439 191.787
> 8 191.962 191.551 191.53
> 10 192.984 194.036 194.923
> 12 183.847 185.73 195.328
> 16 183.609 183.439 196.224
> 20 181.519 179.956 193.681
> 24 183.509 183.387 194.09
> 28 176.04 175.832 169.326
> 32 174.583 163.09 137.815
> 36 155.04 164.154 121.861
> 40 155.37 156.028 102.014
> 44 152.546 138.171 91.6088
> 48 146.419 135.447 84.3884
> 52 139.788 125.968 89.2374
> 56 113.933 122.592 81.021
> 64 110.792 106.484 84.648
> 80 87.4692 60.6054
> 96 87.7201 57.9622
> 112 74.9503 49.468
> 128 67.2649 47.0254
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tue, 6 Aug 2002, Jens Axboe wrote:
>...
> try a work load that excercises the block i/o layer alone (O_DIRECT,
> raw, whatnot) and then compare 2.4 and 2.5. ibm had some slides on this
> from ols, unfortunately I don't know if they have then online.
>...
Pages 390-406 in
http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz
or are you talking about something different?
cu
Adrian
--
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox
On Tue, Aug 06 2002, Adrian Bunk wrote:
> On Tue, 6 Aug 2002, Jens Axboe wrote:
>
> >...
> > try a work load that excercises the block i/o layer alone (O_DIRECT,
> > raw, whatnot) and then compare 2.4 and 2.5. ibm had some slides on this
> > from ols, unfortunately I don't know if they have then online.
> >...
>
> Pages 390-406 in
>
> http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz
>
> or are you talking about something different?
Right thanks, exactly those. Table 3 on page 395 is the one I noted.
Forget readv, as that hasn't been done in 2.5 yet. I'd say a 2.5.17
untweaked kernel beating 2.4 tweaked beyond recognition isn't too shabby
for a devel series kernel.
--
Jens Axboe
On 5 Aug 02 at 23:48, Bill Davidsen wrote:
> On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:
>
> > And second problem is that 20265 is used as primary onboard
> > sometimes and sometimes as offboard (another config option?).
>
> Can that not be configured at boot time with ide0=xxx or similar? I'm
> clearly missing why it would matter on or off board as long as the
> controller(s) were checked in the right order.
Make me favor, and extend ide0=<port> to also allow
ide0=pci<slotnumber>.primary or .secondary... Until then
I do not know port address in advance (my board also uses
20265 as secondary ATA host, and I was really surprised what happened
to my /dev/hde after upgrade).
Petr Vandrovec
[email protected]
At 07:42 AM 6/08/2002 +0200, Jens Axboe wrote:
> > Call me an optimist, but after all the reliability problems we had win the
> > 2.5 series, I sort of hoped it would be better in performance, not
> > increasingly worse. Am I misreading this? Can we fall back to the faster
> > 2.4 code :-(
>
>try a work load that excercises the block i/o layer alone (O_DIRECT,
>raw, whatnot) and then compare 2.4 and 2.5. ibm had some slides on this
>from ols, unfortunately I don't know if they have then online.
the BIO in 2.5 kicks butt over the 2.4 BIO - both in terms of increased
throughput and decreased cpu utilization.
see some testing i previously did:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102635456620627&w=2
cheers,
lincoln.
On Mon, 2002-08-05 at 22:30, Andrew Morton wrote:
[snipped]
>
> IO in 2.5 is much more CPU efficient that in 2.4, and straight-line
> bandwidth is better as well.
>
> The scheduling of that IO has a few problems, so in wildly seeky loads
> like dbench the kernel still falls over its own feet a bit. The
> two main culprits here are the lock_buffer() in block_write_full_page()
> against the blockdev mapping, and the writeback of dirty pages from the
> tail of the LRU in page reclaim.
>
> And no, the eventual dbench numbers will not be a measure of the success
> of the tuning which will happen on the run in to 2.6. Dbench throughput
> may well be lower, because we probably should be starting writeback
> at lower dirty thresholds.
>
> If you want good dbench numbers:
>
> echo 70 > /proc/sys/vm/dirty_background_ratio
> echo 75 > /proc/sys/vm/dirty_async_ratio
> echo 80 > /proc/sys/vm/dirty_sync_ratio
> echo 30000 > /proc/sys/vm/dirty_expire_centisecs
That last one looks like the biggest cheat. Rather than optimizing for
dbench, is there a set of pessimizing numbers which would optimally turn
dbench into a semi-useful tool for measuring meaningful IO performance?
Or is dbench really only useful for stress testing?
Thanks for the explanations.
Steven
On Mon, 5 Aug 2002, Bill Davidsen wrote:
> > Here are some dbench numbers, from the "for what it's worth" department.
>
> Call me an optimist, but after all the reliability problems we had win the
> 2.5 series, I sort of hoped it would be better in performance, not
> increasingly worse. Am I misreading this? Can we fall back to the faster
> 2.4 code :-(
Dbench is at its best when half (or more) of the dbench processes
are stuck semi-infinitely in __get_request_wait and the others can
operate in RAM without ever touching the disk.
In effect, if you want the best dbench throughput you should make
the system completely unsuitable for real world applications ;)
There are a few things that are good for both real world performance
and dbench performance, but those are easily dwarved by random factors
like IO scheduling, timeslice length, etc...
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On 6 Aug 2002, Steven Cole wrote:
> That last one looks like the biggest cheat. Rather than optimizing for
> dbench, is there a set of pessimizing numbers which would optimally turn
> dbench into a semi-useful tool for measuring meaningful IO performance?
> Or is dbench really only useful for stress testing?
Yes, dbench is only useful as a stress testing tool.
A minor varation in kernel behaviour can change dbench
throughput by an order of magnitude and I'm not talking
about any specific kernel component here ... ANY kernel
component could trigger it.
While it is easy to measure dbench throughput, it is
nearly impossible to:
1) analyse why dbench throughput changed from kernel to kernel
2) predict the relation (if any) these changes in dbench
throughput have with changes in performance of real
applications, if any
3) identify which kernel subsystem was responsible for the
change in dbench performance
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Steven Cole wrote:
>
> ...
> > If you want good dbench numbers:
> >
> > echo 70 > /proc/sys/vm/dirty_background_ratio
> > echo 75 > /proc/sys/vm/dirty_async_ratio
> > echo 80 > /proc/sys/vm/dirty_sync_ratio
> > echo 30000 > /proc/sys/vm/dirty_expire_centisecs
>
> That last one looks like the biggest cheat. Rather than optimizing for
> dbench, is there a set of pessimizing numbers which would optimally turn
> dbench into a semi-useful tool for measuring meaningful IO performance?
> Or is dbench really only useful for stress testing?
>
We tend to use dbench in two modes nowadays. One is the "RAM only"
mode, where the run completes before hitting disk at all. That's
a very useful and repeatable test for CPU efficiency and lock contention.
The other mode is of course when there are enough clients and
enough dirty data for the test to go to disk. As Rik says, this
tends to be subject to chaotic effects, and it is also extremely
non linear.
Because when the run slows down a little bit, it takes longer, so
more data becomes eligible for time-expiry-based writeback, which
causes more IO, which causes the run to take longer, etc, etc.
Yes, one does tend still to keep one's eye on the "heavy" dbench
throughput, but I suspect that tuning for this workload is a bad
thing overall. This is because good dbench numbers come from
allowing a large amount of dirty data to float about in memory
(it will never get written out). But for real workloads which
don't delete their own output 30 seconds later, we want to start
writeback earlier. To use the disk bandwidth more smoothly
and to decrease memory allocation latency.
>On Tue, Aug 06 2002, Adrian Bunk wrote:
> > On Tue, 6 Aug 2002, Jens Axboe wrote:
> >
> > >...
> > > try a work load that excercises the block i/o layer alone (O_DIRECT,
> > > raw, whatnot) and then compare 2.4 and 2.5. ibm had some slides on
this
> > > from ols, unfortunately I don't know if they have then online.
> >...
> >
> > Pages 390-406 in
> >
> > http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz
> >
> > or are you talking about something different?
> Right thanks, exactly those. Table 3 on page 395 is the one I noted.
> Forget readv, as that hasn't been done in 2.5 yet. I'd say a 2.5.17
> untweaked kernel beating 2.4 tweaked beyond recognition isn't too shabby
> for a devel series kernel.
The corresponding presentation in the sdd format is available at
http://www-124.ibm.com/developerworks/opensource/linuxperf/.
Regards,
Peter
Peter Wai Yee Wong
IBM Linux Technology Center, Performance Analysis
email: [email protected]
On Tue, 6 Aug 2002, Rik van Riel wrote:
> On Mon, 5 Aug 2002, Bill Davidsen wrote:
>
> > > Here are some dbench numbers, from the "for what it's worth" department.
> >
> > Call me an optimist, but after all the reliability problems we had win the
> > 2.5 series, I sort of hoped it would be better in performance, not
> > increasingly worse. Am I misreading this? Can we fall back to the faster
> > 2.4 code :-(
>
> Dbench is at its best when half (or more) of the dbench processes
> are stuck semi-infinitely in __get_request_wait and the others can
> operate in RAM without ever touching the disk.
>
> In effect, if you want the best dbench throughput you should make
> the system completely unsuitable for real world applications ;)
I assumed that the posted results were apples and apples. That may not be
the case. If this was one kernel tuned for dbench and one for something
else, then the information content is pretty low, to me at least. But if
it is both tuned or both stock, then I would hope 2.5 would be better. If
the text said that and I read past it, I apologise.
> There are a few things that are good for both real world performance
> and dbench performance, but those are easily dwarved by random factors
> like IO scheduling, timeslice length, etc...
I confess to being a kernel junkie when I have the time, I have run into
the limitation of 19 boot stanzas in LILO :-( I have a case statement in
rc.local to tune -aa VM, stock, and -ac rmap a little differently, since
this machine is fairly fast and has bigish memory (2GB this week) and
getting several ISO images in RAM and then having bdflush kick them out is
bad. Looking forward to the io scheduler.
I like to see 2.4.19 vs. 2.5.{29+} both tuned and untuned, but I have no
days off in the next ten. By then there will be more new stuff, but the
fast machine will be several area codes away, perhaps one of the people
who like to do benchmarks might be too curious to wait.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tue, 6 Aug 2002 [email protected] wrote:
> > I sort of hoped it would be better in performance, not
> > increasingly worse.
>
> There were a lot of improvements during the 2.4.19-pre series on
> several I/O benchmarks. Comparing 2.4.18 to 2.4.19 on a quad xeon.
> Here are a few of the big changes (average of 5 runs):
Clearly, I may not have been clear that I expected 2.5.xx to be better
than 2.4.xx. That may have been an artifact of tuning one kernel or the
other, I'm waiting to get clarification on that.
> 300% drop in cpu usage on ext3 for tiobench seq reads
??? I hope you mean 67% drop.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tue, 6 Aug 2002, Nick Orlov wrote:
> 1. ide0/1 reserved for onboard controllers.
Not sure about that, I've run 2.4.x (ie. x<10} on machines so old that
they had no onboard anything, and were using "VESA bus" ide controllers. I
think they were ide0/1.
> 2. on most hardware, pdc20xxx is really additional controller.
That's the problem, most not all. No matter what we assume it will be
wrong part of the time.
> 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
Does this matter as long as we can force it to be where we want?
> 4. ide0=<what> ??? (do we have this option?)
I made that up, I believe we do/did if my memory isn't totally kidding me.
> Correct me, if I'm wrong.
This is lkml, count on it. Sometimes they correct you if you're right ;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tue, 2002-08-06 at 19:09, Bill Davidsen wrote:
> On Tue, 6 Aug 2002, Rik van Riel wrote:
>
> > On Mon, 5 Aug 2002, Bill Davidsen wrote:
> >
> > > > Here are some dbench numbers, from the "for what it's worth" department.
> > >
> > > Call me an optimist, but after all the reliability problems we had win the
> > > 2.5 series, I sort of hoped it would be better in performance, not
> > > increasingly worse. Am I misreading this? Can we fall back to the faster
> > > 2.4 code :-(
> >
> > Dbench is at its best when half (or more) of the dbench processes
> > are stuck semi-infinitely in __get_request_wait and the others can
> > operate in RAM without ever touching the disk.
> >
> > In effect, if you want the best dbench throughput you should make
> > the system completely unsuitable for real world applications ;)
>
> I assumed that the posted results were apples and apples. That may not be
Well, maybe Granny Smiths and Red Delicious. The problem with dbench is
that it checks how well they roll and bounce. But even that can be
important sometimes. ;)
> the case. If this was one kernel tuned for dbench and one for something
> else, then the information content is pretty low, to me at least. But if
> it is both tuned or both stock, then I would hope 2.5 would be better. If
> the text said that and I read past it, I apologise.
All kernels were stock as patched with no special changes to
/proc/sys/vm/bdflush for 2.4.x or to /proc/sys/vm/dirty* for 2.5.x.
Sorry, I didn't explicitly state that in the initial report.
Steven
On Tue, Aug 06, 2002 at 11:09:14PM -0400, Bill Davidsen wrote:
>
> > 2. on most hardware, pdc20xxx is really additional controller.
>
> That's the problem, most not all. No matter what we assume it will be
> wrong part of the time.
Agreed.
>
> > 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> > pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
>
> Does this matter as long as we can force it to be where we want?
But wouldn't it be a cleaner solution if we will have _compile_ time
option that by default is turned on in order to handle rare cases,
and _can_ be turned off in order to handle _most_ cases without any
boot-time options?
--
With best wishes,
Nick Orlov.
Nick Orlov writes:
>But wouldn't it be a cleaner solution if we will have _compile_ time
>option that by default is turned on in order to handle rare cases,
>and _can_ be turned off in order to handle _most_ cases without any
>boot-time options?
You might not see them on linux-kenrel, but there are
lots of Linux users that are not comfortable compiling a custom
kernel (or even competent to do so), but are a bit more willing
to edit files and rerun a boot configuration utility like lilo.
Linux users in the "I'm not a sysadmin" crowd (?) probably
don't care about the scan order of the pdc20265 IDE controller,
but people in the "I'm a sysadmin, not a programmer" crowd
may have legitimiate reasons to.
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-08-07 at 08:54, Adam J. Richter wrote:
> Linux users in the "I'm not a sysadmin" crowd (?) probably
> don't care about the scan order of the pdc20265 IDE controller,
> but people in the "I'm a sysadmin, not a programmer" crowd
> may have legitimiate reasons to.
The non sysadmin people care that is has not change, and generally
prefer that its the same ordering as windows seems to use. Once you go
to modular IDE it gets trickier. Certainly if you load modules the usual
bets are off (as with scsi)
It is possible to take a serial like approach and we could say
if(pci && southbridge_has_ide_device())
reserve_ide0();
That would ensure the southbridge IDE stayed in one place. Another
alternative is to enumerate all the IDE devices by class (we can do that
nice and easy, with a little tweak for the fasttrak stuff) then hand
them off according to the enumeration position. That would preserve the
old semantics nicely for pci IDE. (Plug in ISA IDE is pretty rare and
since we can't probe those its kind of hard to do anything much about
it).
Andre is currently dealing with some of this in the main IDE code
On 7 Aug 02 at 0:54, Adam J. Richter wrote:
> Nick Orlov writes:
> >But wouldn't it be a cleaner solution if we will have _compile_ time
> >option that by default is turned on in order to handle rare cases,
> >and _can_ be turned off in order to handle _most_ cases without any
> >boot-time options?
>
> Linux users in the "I'm not a sysadmin" crowd (?) probably
> don't care about the scan order of the pdc20265 IDE controller,
> but people in the "I'm a sysadmin, not a programmer" crowd
> may have legitimiate reasons to.
But such "I'm not a sysadmin" people will be very surprised that their
promise was IDE2 in 2.2.x, it was IDE2 in 2.4.18, it is IDE2 in 2.5.30,
and now - oops - it is IDE0 in 2.4.19. Broken, I'd say.
There is an CONFIG_BLK_DEV_OFFBOARD option (apparently unused...),
so use this one, if some distribution must force ide0= to promise
if their installer cannot find master disk on /dev/hde. But changing
behavior for no reason - especially in the middle of stable series -
is IMHO unacceptable.
Fortunately I use 2.5.30's IDE for real work ;-)
Petr Vandrovec
[email protected]
Hi,
On Wed, 7 Aug 2002, Adam J. Richter wrote:
> You might not see them on linux-kenrel, but there are
> lots of Linux users that are not comfortable compiling a custom
> kernel (or even competent to do so), but are a bit more willing
> to edit files and rerun a boot configuration utility like lilo.
>
> Linux users in the "I'm not a sysadmin" crowd (?) probably
> don't care about the scan order of the pdc20265 IDE controller,
> but people in the "I'm a sysadmin, not a programmer" crowd
> may have legitimiate reasons to.
Oh, that's really no problem. You can reduce the programm to choosing a
simple list entry and clicking a button. Anything can be made easy via the
proper frontend. (And BTW, one should always be both - (sys|net)admin and
"programmer".)
Thunder
--
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-
On Wed, 2002-08-07 at 10:47, Alan Cox wrote:
>On Wed, 2002-08-07 at 08:54, Adam J. Richter wrote:
>> Linux users in the "I'm not a sysadmin" crowd (?) probably
>> don't care about the scan order of the pdc20265 IDE controller,
>> but people in the "I'm a sysadmin, not a programmer" crowd
>> may have legitimiate reasons to.
>
>The non sysadmin people care that is has not change, and generally
>prefer that its the same ordering as windows seems to use. Once you go
>to modular IDE it gets trickier. Certainly if you load modules the usual
>bets are off (as with scsi)
[...]
And Petr Vandrovec wrote:
| But such "I'm not a sysadmin" people will be very surprised that their
| promise was IDE2 in 2.2.x, it was IDE2 in 2.4.18, it is IDE2 in 2.5.30,
| and now - oops - it is IDE0 in 2.4.19. Broken, I'd say.
I was not expresing an opinion on what the default
ordering should be.
There seemed to be agreement that no single ordering would
make all users happy and that there should be some way of changing
the ordering. The post that I replied to discussed and module
arguments versus a compile time flag. All that I was saying was
that providing arguments would probably be more useful for the
population that might care about this issue, as they might not be
comfortable having to rebuild custom kernels (or supporting another
kernel in their site, I should add now).
I might as well address the response from "Thunder from the hill" as well;
: Oh, that's really no problem. You can reduce the programm to choosing a
: simple list entry and clicking a button. Anything can be made easy via the
: proper frontend. (And BTW, one should always be both - (sys|net)admin and
: "programmer".)
That would require the distribution provider to double
the number of precompiled kernels or module trees that they ship
and support. That would be a lot more work than implementing a
module option and a boot option and use a lot more space, for no
substatial advantages that I'm aware of.
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."
Marcelo,
Well here is the long a waited "I Told You So, but You Would Not Listen".
It worked just fine until you all decided to let an OEM get in the game
and dictate the changes. Back out the cruft and return sanity to an
insane world. Just because and OEM makes hardware does not mean they can
make it run proper.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Tue, 6 Aug 2002, Nick Orlov wrote:
> On Tue, Aug 06, 2002 at 11:09:14PM -0400, Bill Davidsen wrote:
> >
> > > 2. on most hardware, pdc20xxx is really additional controller.
> >
> > That's the problem, most not all. No matter what we assume it will be
> > wrong part of the time.
>
> Agreed.
>
> >
> > > 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> > > pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
> >
> > Does this matter as long as we can force it to be where we want?
>
> But wouldn't it be a cleaner solution if we will have _compile_ time
> option that by default is turned on in order to handle rare cases,
> and _can_ be turned off in order to handle _most_ cases without any
> boot-time options?
>
>
> --
> With best wishes,
> Nick Orlov.
>
> -
> 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/
>
On Wed, 2002-08-07 at 20:33, Thunder from the hill wrote:
>
> Not exactly. Somebody who releases Linux distributions should be able to
> release it with a kernel that can have a boot parameter or such about it
> which is configured via mouse click...
>
> That still doesn't make it any harder to achieve.
You know where to send the patches
Hi,
On 7 Aug 2002, Alan Cox wrote:
> You know where to send the patches
If you want me to, yes.
Thunder
--
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-
Hi,
On Wed, 7 Aug 2002, Adam J. Richter wrote:
> That would require the distribution provider to double the number of
> precompiled kernels or module trees that they ship and support. That
> would be a lot more work than implementing a module option and a boot
> option and use a lot more space, for no substatial advantages that I'm
> aware of.
Not exactly. Somebody who releases Linux distributions should be able to
release it with a kernel that can have a boot parameter or such about it
which is configured via mouse click...
That still doesn't make it any harder to achieve.
Thunder
--
.-../../-./..-/-..- .-./..-/.-.././.../.-.-.-
> It worked just fine until you all decided to let an OEM get in the game
> and dictate the changes. Back out the cruft and return sanity to an
> insane world. Just because and OEM makes hardware does not mean they can
> make it run proper.
Btw, Andre, I have this system with an extra PDC20268 controller that
I can't get to work in UDMA >2, *but only* until I actually I force it
to using "ide2=ata66 ide3=ata66". You wouldn't happen to have an idea
as to what could be the cause here, would you?
This applies for all the recent 2.4 kernels that I've tested, both
vanilla and -ac.
A comment in ide.c reads:
* Added idex=ata66 for the quirky chipsets that are
* ATA-66 compliant, but have yet to determine a method
* of verification of the 80c cable presence.
* Specifically Promise's PDC20262 chipset.
i.e. it talks of a chipset different from what I have here.
All right. Supposing CONFIG_BLK_DEV_IDEPCI=y and "idex=ata66"
hasn't been specified as a boot option, the value of
hwif->udma_four remains unset during setup and is to
be determined later:
if (hwif->udma_four) {
printk("%s: ATA-66/100 forced bit set (WARNING)!!\n", d->name);
} else {
hwif->udma_four = (d->ata66_check) ? d->ata66_check(hwif) : 0;
}
If I parse this right, then if a function has been defined that can find
out about the chipset's ability to support DMA4+, it's called to do its
job, otherwise we assume UDMA4+ can't be had. This narrows my problem down
to: 1) either this cunning function doesn't exist for PDC20268, or 2) for
some weird reason it exists but is not nearly as cunning, because it doesn't
know it should be returning a nice "one" for my controller.
Trouble is, I have failed to find where the value of ata66_check in struct
ide_pci_device_s is assigned for the controller so I couldn't go on tracking
the problem. The code is sooooo beautifully messy. <g>
T.
ide_setup: ide2=ata66
ide_setup: ide3=ata66
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX3: IDE controller on PCI bus 00 dev 21
PCI: Enabling device 00:04.1 (0000 -> 0001)
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
PIIX3: neither IDE port enabled (BIOS)
PDC20268: IDE controller on PCI bus 00 dev 30
PDC20268: chipset revision 2
PDC20268: not 100% native mode: will probe irqs later
PDC20268: ATA-66/100 forced bit set (WARNING)!!
ide2: BM-DMA at 0xf8b0-0xf8b7, BIOS settings: hde:pio, hdf:pio
PDC20268: ATA-66/100 forced bit set (WARNING)!!
ide3: BM-DMA at 0xf8b8-0xf8bf, BIOS settings: hdg:pio, hdh:pio
hde: WDC WD205BA, ATA DISK drive
hdg: IBM-DJNA-351520, ATA DISK drive
ide2 at 0xf898-0xf89f,0xf8aa on irq 9
ide3 at 0xf8a0-0xf8a7,0xf8ae on irq 9
hde: host protected area => 1
hde: 40088160 sectors (20525 MB) w/2048KiB Cache, CHS=39770/16/63, UDMA(66)
hdg: host protected area => 1
hdg: 30033360 sectors (15377 MB) w/430KiB Cache, CHS=29795/16/63, UDMA(33)
00:06.0 Unknown mass storage controller: Promise Technology, Inc. 20268 (rev 02) (prog-if 85)
Subsystem: Promise Technology, Inc. Ultra100TX2
Flags: bus master, 66Mhz, slow devsel, latency 64, IRQ 9
I/O ports at f898 [size=8]
I/O ports at f8a8 [size=4]
I/O ports at f8a0 [size=8]
I/O ports at f8ac [size=4]
I/O ports at f8b0 [size=16]
Memory at fedfc000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at <unassigned> [disabled] [size=16K]
Capabilities: [60] Power Management version 1
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=m
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=m
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=m
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_TASKFILE_IO=y
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CMD680 is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_ADMA100 is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_PDC202XX_BURST=y
# CONFIG_PDC202XX_FORCE is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
On Wed, 2002-08-07 at 21:02, Thunder from the hill wrote:
> Hi,
>
> On 7 Aug 2002, Alan Cox wrote:
> > You know where to send the patches
>
> If you want me to, yes.
I'm all for the promise raid switch being runtime
On 6 Aug 2002, Steven Cole wrote:
> On Tue, 2002-08-06 at 19:09, Bill Davidsen wrote:
> > I assumed that the posted results were apples and apples. That may not be
>
> Well, maybe Granny Smiths and Red Delicious. The problem with dbench is
> that it checks how well they roll and bounce. But even that can be
> important sometimes. ;)
>
> > the case. If this was one kernel tuned for dbench and one for something
> > else, then the information content is pretty low, to me at least. But if
> > it is both tuned or both stock, then I would hope 2.5 would be better. If
> > the text said that and I read past it, I apologise.
>
> All kernels were stock as patched with no special changes to
> /proc/sys/vm/bdflush for 2.4.x or to /proc/sys/vm/dirty* for 2.5.x.
> Sorry, I didn't explicitly state that in the initial report.
Actually that was what I was assuming when I noted that the 2.5 appeared
to be slower by a good bit for some high load values of dbench. In a
perfect world the kernel would hit the hardware spped, guess no one is
claiming that until 2.7 ;-)
The initial results from the io scheduler, as posted here, look as if
there will be a way to "take it up another notch" in the future.
Thanks much for the clarification, the data are useful even if they do
show room for improvement in the corner case.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 7 Aug 2002, Bill Davidsen wrote:
> Thanks much for the clarification, the data are useful even if they do
> show room for improvement in the corner case.
If dbench numbers are meaningful to you, maybe you could
translate them into something kernel developers can
understand ? ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Tue, 6 Aug 2002, Nick Orlov wrote:
> On Tue, Aug 06, 2002 at 11:09:14PM -0400, Bill Davidsen wrote:
> > > 3. if we put pdc20265 in "onboard" list on some hardware (mine for example)
> > > pdc20265 is assigned to ide0/1 (even if it's really ide2/3)
> >
> > Does this matter as long as we can force it to be where we want?
>
> But wouldn't it be a cleaner solution if we will have _compile_ time
> option that by default is turned on in order to handle rare cases,
> and _can_ be turned off in order to handle _most_ cases without any
> boot-time options?
Nick, I think that's a matter of taste. I am perfectly happy to default to
using the ideN based on the io address, or any other determanent method,
as long as it's reasonable to have the user specify the order if s/he has
a reason to do so. Of course some BIOS will mess up io addresses at some
time, crappy {hard,firm}ware is a problem in any case.
I would just as soon use a boot option as to try and make it a compile
option, and I think that many people just use a compiled kernel and never
change, which argues for a reasonable default (most pdc20265) ARE
currently offboard, and an easy way to change it.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 7 Aug 2002, Petr Vandrovec wrote:
> On 7 Aug 02 at 0:54, Adam J. Richter wrote:
> > Linux users in the "I'm not a sysadmin" crowd (?) probably
> > don't care about the scan order of the pdc20265 IDE controller,
> > but people in the "I'm a sysadmin, not a programmer" crowd
> > may have legitimiate reasons to.
>
> But such "I'm not a sysadmin" people will be very surprised that their
> promise was IDE2 in 2.2.x, it was IDE2 in 2.4.18, it is IDE2 in 2.5.30,
> and now - oops - it is IDE0 in 2.4.19. Broken, I'd say.
And on that one I really do agree. A change like that in 2.5 wouldn't
bother me beyond usual ten minutes of consigning whoever did it to the
darkest level of hell ;-) I would think that distributions would ship with
a kernel which follows Plauger's "law of least astonishment," so it may
not matter unless you roll your own. Kind of violates the idea of "stable"
IMHO, but I have other design decisions which bother me far more.
> There is an CONFIG_BLK_DEV_OFFBOARD option (apparently unused...),
> so use this one, if some distribution must force ide0= to promise
> if their installer cannot find master disk on /dev/hde. But changing
> behavior for no reason - especially in the middle of stable series -
> is IMHO unacceptable.
I disagree with "no reason," there was a reason, but I do think it was a
bad idea. There just aren't that many people with an onboard controller to
justify a change. My opinion, of course.
> Fortunately I use 2.5.30's IDE for real work ;-)
I use 2.5 kernels to test my backups :-( The last one I ran drooled
spillage in every attached drive, including my BSD drive which is on an
offboard controller. I would tell you the version, but it gone. Somewhere
in the 2.5.24..27 range.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On 7 Aug 2002, Alan Cox wrote:
> That would ensure the southbridge IDE stayed in one place. Another
> alternative is to enumerate all the IDE devices by class (we can do that
> nice and easy, with a little tweak for the fasttrak stuff) then hand
> them off according to the enumeration position. That would preserve the
> old semantics nicely for pci IDE. (Plug in ISA IDE is pretty rare and
> since we can't probe those its kind of hard to do anything much about
> it).
ISA my foot, real men went to the VESA bus as soon as it came out, to get
32 bit i/o. I have a 486 router, with 2.4.9 or so, maybe I should refresh
my memory as to what hardware lives there. Last install moderately recent,
it had the new bind and I had to convert all the files.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 7 Aug 2002, Bill Davidsen wrote:
> Sure, glad to. If the 2.5 numbers are much worse than 2.4, somthing
> isn't working as well,
Are you volunteering to identify that "something" for us ?
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Wed, 7 Aug 2002, Rik van Riel wrote:
> On Wed, 7 Aug 2002, Bill Davidsen wrote:
>
> > Thanks much for the clarification, the data are useful even if they do
> > show room for improvement in the corner case.
>
> If dbench numbers are meaningful to you, maybe you could
> translate them into something kernel developers can
> understand ? ;)
Sure, glad to. If the 2.5 numbers are much worse than 2.4, somthing isn't
working as well, another problem, go have a beer to drown your sorrow. On
the other hand if it runs much better, you have done a great job and can
go have a beer to celebrate.
Seriously, I would read the reasonably smooth curve of values as good
sign, as opposed to "gets real badd and improves under more load" or
similar. And the fact that it stayed up, and presumably didn't eat all the
filesystems indicates that the system is getting more stable IDE.
One more thing, if you have been fighting bad machines for 15 hours and no
one is looking, it's time to go get a beer. And cashews, and cheddar. I am
out of here (as in where I am working right now, not my office).
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 7 Aug 2002, Bill Davidsen wrote:
> On 7 Aug 2002, Alan Cox wrote:
>
> > That would ensure the southbridge IDE stayed in one place. Another
> > alternative is to enumerate all the IDE devices by class (we can do that
> > nice and easy, with a little tweak for the fasttrak stuff) then hand
> > them off according to the enumeration position. That would preserve the
> > old semantics nicely for pci IDE. (Plug in ISA IDE is pretty rare and
> > since we can't probe those its kind of hard to do anything much about
> > it).
Well there is also the ISAPNP IDE plug in variant, or would these qualify
as 'pci' in terms of enumeration? The devices i'm thinking about are the
ones on ISAPNP sound cards.
Zwane
--
function.linuxpower.ca
On Wed, 7 Aug 2002, Bill Davidsen wrote:
> I would just as soon use a boot option as to try and make it a compile
> option, and I think that many people just use a compiled kernel and never
> change, which argues for a reasonable default (most pdc20265) ARE
> currently offboard, and an easy way to change it.
There are ZERO pdc20265's offboard, only pdc20267's were in both options.
This is the direct asic packaging. Thus all pdc20265 have the right to be
listed as onboard. If you have a pdc20265 on an add-on card please send
me a digital photo so I can question promise as to why.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On 8 Aug 02 at 3:50, Andre Hedrick wrote:
> On Wed, 7 Aug 2002, Bill Davidsen wrote:
>
> > I would just as soon use a boot option as to try and make it a compile
> > option, and I think that many people just use a compiled kernel and never
> > change, which argues for a reasonable default (most pdc20265) ARE
> > currently offboard, and an easy way to change it.
>
> There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> This is the direct asic packaging. Thus all pdc20265 have the right to be
> listed as onboard. If you have a pdc20265 on an add-on card please send
> me a digital photo so I can question promise as to why.
They are on the mainboard, but mainboard has also (in my case VIA) IDE
chipset on the shelf, and BIOS shows everywhere (autodetection, IDE config)
that VIA is the primary chipset, and PDC ('UDMA100' interface in the BIOS)
is an additional, optional, interface. So forcing PDC20265 as primary is
a bug - it is not consistent with BIOS, it is not consistent with Windows,
and it is not consistent with other Linux versions.
Up to now nobody showed me mainboard which has PDC20265, but which does
not have other IDE chipset integrated in the southbridge, or at least
mainbord with BIOS which names disks connected to the PDC primary/secondary
master/slave. It is 3rd/4th channel on all mainboards I ever saw.
Petr Vandrovec
[email protected]
Please go check your BIOS and search or support/boot INT19 services.
That is how the mainboard selects ordering from the bios.
Go read e01125r0 and the e01133r0's related sections.
There are mainboard out there designed specifically to boot off the third
party host. I have one with the pdc20265 on it. So if you mainboard is
produced by some lame OEM who is trying to grant first access to the addon
host chip by playing silly devfn/bus ordering games you get what you
bought. Yeah there are cheesy crap-mainboard oem's that play this game.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 8 Aug 2002, Petr Vandrovec wrote:
> On 8 Aug 02 at 3:50, Andre Hedrick wrote:
> > On Wed, 7 Aug 2002, Bill Davidsen wrote:
> >
> > > I would just as soon use a boot option as to try and make it a compile
> > > option, and I think that many people just use a compiled kernel and never
> > > change, which argues for a reasonable default (most pdc20265) ARE
> > > currently offboard, and an easy way to change it.
> >
> > There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> > This is the direct asic packaging. Thus all pdc20265 have the right to be
> > listed as onboard. If you have a pdc20265 on an add-on card please send
> > me a digital photo so I can question promise as to why.
>
> They are on the mainboard, but mainboard has also (in my case VIA) IDE
> chipset on the shelf, and BIOS shows everywhere (autodetection, IDE config)
> that VIA is the primary chipset, and PDC ('UDMA100' interface in the BIOS)
> is an additional, optional, interface. So forcing PDC20265 as primary is
> a bug - it is not consistent with BIOS, it is not consistent with Windows,
> and it is not consistent with other Linux versions.
>
> Up to now nobody showed me mainboard which has PDC20265, but which does
> not have other IDE chipset integrated in the southbridge, or at least
> mainbord with BIOS which names disks connected to the PDC primary/secondary
> master/slave. It is 3rd/4th channel on all mainboards I ever saw.
> Petr Vandrovec
> [email protected]
>
>
On 8 Aug 02 at 6:02, Andre Hedrick wrote:
>
> There are mainboard out there designed specifically to boot off the third
> party host. I have one with the pdc20265 on it. So if you mainboard is
Vendor + motherboard name, please.
> produced by some lame OEM who is trying to grant first access to the addon
> host chip by playing silly devfn/bus ordering games you get what you
> bought. Yeah there are cheesy crap-mainboard oem's that play this game.
Uhh? Changing boot order in the BIOS must NOT change what ide0 is.
What are you smoking? It would completely screw my system that if I
decide to boot from secondary channel, it magically becomes ide0. If
Linux would behave this way, I could never tell which disk will get which
name until I boot. What if I boot from floppy? Then IDE interfaces will
become numbered from ide1, because of there was no IDE boot device?
Should we also swap hda with hdb if I boot my system from primary slave?
And I did not found anything about ide0 in documents you provided.
And BTW, my board is A7V from Asus. Manual refers to VIA interface
as 'primary/secondary channels', and to PDC as 'UDMA100 interface'(s).
And PDC is always run in the native mode, IRQ14/15 is not wired to the
PDC chip at all.
I always thought that if there is IDE interface at the 0x1F0 in the
system, it will become ide0, and if there is interface at the 0x170,
it will become ide1 (and simillary for ISA-based tertiary/quaterniary).
After this step unused ide* interfaces are populated with native PCI IDE
interfaces, starting at ide0, and going up...
Petr Vandrovec
[email protected]
On Thu, Aug 08, 2002 at 03:50:19AM -0700, Andre Hedrick wrote:
> On Wed, 7 Aug 2002, Bill Davidsen wrote:
>
> > I would just as soon use a boot option as to try and make it a compile
> > option, and I think that many people just use a compiled kernel and never
> > change, which argues for a reasonable default (most pdc20265) ARE
> > currently offboard, and an easy way to change it.
>
> There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> This is the direct asic packaging. Thus all pdc20265 have the right to be
> listed as onboard.
Could you comment next couple lines of code (2.4.19-vanilla):
==========================================
#else /* !CONFIG_PDC202XX_FORCE */
[ ... skipped ... ]
{DEVID_PDC20265,"PDC20265" .... OFF_BOARD ..... },
^^^^^^^^^
[ ... skipped ... ]
#endif
==========================================
Another bug? Just typo?
Why author put PDC20265 in off-board list ?
> Cheers,
>
> Andre Hedrick
> LAD Storage Consulting Group
>
--
With best wishes,
Nick Orlov.
Petr,
Here is a short list!
http://www.tyan.com/products/html/thunderlet.html
http://www.tyan.com/products/html/tiger200t.html
http://www.tyan.com/products/html/trinityi845e.html
http://www.tyan.com/products/html/trinitygcsl.html
http://www.epox.com/html/english/products/motherboard/ep-d3va.htm
http://www.epox.com/html/english/products/motherboard/ep-8k3a.htm
http://www.supermicro.com/PRODUCT/MotherBoards/VIA/370DDE.htm
http://www.supermicro.com/PRODUCT/MotherBoards/VIA/P3TDDE.htm
It is absolutely lame that people in 2.5 are clueless to what is going to
need to be supported. Also it is lame in 2.4 that cruft from OEMs who do
not get Linux, but their changes are accepted. There were very careful
decisions made over the past 4-5 years about device ordering and
protecting the power of ide0/ide1. Within a few days it is shot to hell
because nobody ever thinks to look at what was there before them. They
all know better, are wiser, empower w/ megalmania (sp) and gawd knows what
else. Please next time, do your homework before you attempt to call me
on these issues. Do the two word "Native" and "Compatablity" in ATA-ATAPI
have meaning? This will help you go a long way.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 8 Aug 2002, Petr Vandrovec wrote:
> On 8 Aug 02 at 6:02, Andre Hedrick wrote:
> >
> > There are mainboard out there designed specifically to boot off the third
> > party host. I have one with the pdc20265 on it. So if you mainboard is
>
> Vendor + motherboard name, please.
>
> > produced by some lame OEM who is trying to grant first access to the addon
> > host chip by playing silly devfn/bus ordering games you get what you
> > bought. Yeah there are cheesy crap-mainboard oem's that play this game.
>
> Uhh? Changing boot order in the BIOS must NOT change what ide0 is.
>
> What are you smoking? It would completely screw my system that if I
> decide to boot from secondary channel, it magically becomes ide0. If
> Linux would behave this way, I could never tell which disk will get which
> name until I boot. What if I boot from floppy? Then IDE interfaces will
> become numbered from ide1, because of there was no IDE boot device?
> Should we also swap hda with hdb if I boot my system from primary slave?
>
> And I did not found anything about ide0 in documents you provided.
>
> And BTW, my board is A7V from Asus. Manual refers to VIA interface
> as 'primary/secondary channels', and to PDC as 'UDMA100 interface'(s).
> And PDC is always run in the native mode, IRQ14/15 is not wired to the
> PDC chip at all.
>
> I always thought that if there is IDE interface at the 0x1F0 in the
> system, it will become ide0, and if there is interface at the 0x170,
> it will become ide1 (and simillary for ISA-based tertiary/quaterniary).
> After this step unused ide* interfaces are populated with native PCI IDE
> interfaces, starting at ide0, and going up...
> Petr Vandrovec
> [email protected]
>
>
Two cases one HighPoint the other Promise.
See how they play games with device locations?
[root@autobuild root]# lspci
00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
00:01.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00:03.0 RAID bus controller: Promise Technology, Inc. 20267 (rev 02)
00:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
00:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 50)
00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
00:0f.2 USB Controller: ServerWorks OSB4/CSB5 USB Controller (rev 04)
[root@autobuild root]#
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20267: IDE controller on PCI bus 00 dev 18
PDC20267: chipset revision 2
PDC20267: not 100% native mode: will probe irqs later
PDC20267: ROM enabled at 0xfeae0000
(U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.
ide0: BM-DMA at 0xdf00-0xdf07, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xdf08-0xdf0f, BIOS settings: hdc:pio, hdd:pio
SvrWks OSB4: IDE controller on PCI bus 00 dev 79
SvrWks OSB4: chipset revision 0
SvrWks OSB4: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xffa0-0xffa7, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdg:pio, hdh:pio
hda: IBM-DPTA-373420, ATA DISK drive
hdc: IBM-DPTA-373420, ATA DISK drive
hde: CW038D ATAPI CD-R/RW, ATAPI CD/DVD-ROM drive
ide0 at 0xdfe0-0xdfe7,0xdfae on irq 31
ide1 at 0xdfa0-0xdfa7,0xdfaa on irq 31
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
bp6:~ # lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0d.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:0f.0 VGA compatible controller: S3 Inc. 86c988 [ViRGE/VX] (rev 02)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 01)
00:13.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366 (rev 01)
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
HPT366: onboard version of chipset, pin1=1 pin2=2
PCI: HPT366: Fixing interrupt 18 pin 2 to ZERO
HPT366: IDE controller on PCI bus 00 dev 98
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:pio
HPT366: IDE controller on PCI bus 00 dev 99
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
ide1: BM-DMA at 0xec00-0xec07, BIOS settings: hdc:DMA, hdd:pio
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: device not capable of full native PCI mode
PIIX4: device disabled (BIOS)
PIIX4: device disabled (BIOS)
hda: DupliDisk IDE RAID-1 Adapter( 1.19), ATA DISK drive
hdc: QUANTUM FIREBALLP KA13.6, ATA DISK drive
ide2: ports already in use, skipping probe
ide0 at 0xd800-0xd807,0xdc02 on irq 18
ide1 at 0xe400-0xe407,0xe802 on irq 18
hda: setmax LBA 18041184, native 18039168
hda: DupliDisk IDE RAID-1 Adapter( 1.19), 8808MB w/371kB Cache, CHS=17896/16/63, UDMA(33)
hdc: QUANTUM FIREBALLP KA13.6, 13217MB w/371kB Cache, CHS=26853/16/63, UDMA(33)
Andre Hedrick
LAD Storage Consulting Group
On 8 Aug 02 at 10:30, Andre Hedrick wrote:
>
> http://www.tyan.com/products/html/thunderlet.html
Page 40 of manual: choose Onboard IDE or FastTrak ATA-100/RAID.
OnboardIDE means Serverworks, FastTrak means PDC20265.
BIOS settings for primary/secondary disk relate to the Serverworks
channels.
> http://www.tyan.com/products/html/tiger200t.html
Page 11: Primary/secondary IDE: VIA, RAID primary/secondary: PDC.
Page 33: Primary/secondary IDE settings relate to the VIA.
> http://www.tyan.com/products/html/trinityi845e.html
Page 5: Integrated PCI IDE (it talks about i845 internal) +
integrated IDE RAID (20267, so no relevance here). Page 28:
primary/secondary disables i845, not PDC.
> http://www.tyan.com/products/html/trinitygcsl.html
Serverworks, with IDE. Serverworks IDE is primary.
RAID is 20267, so no relevance. Manual not available yet.
> http://www.epox.com/html/english/products/motherboard/ep-d3va.htm
VIA onboard, HPT370 RAID. Connectors of RAID marked IDE3/IDE4.
> http://www.epox.com/html/english/products/motherboard/ep-8k3a.htm
8k3a has no RAID. 8k3a+ has PDC20267. Primary IDE is from VIA,
RAID is additional...
> http://www.supermicro.com/PRODUCT/MotherBoards/VIA/370DDE.htm
Manual unavailable from the web (404 Page not found after clicking
on manual). Picture shows IDE #1/IDE #2 (VIA) and IDE RAID #1/#2.
Besides that it has PDC20267, so it has no relevance to this discussion.
> http://www.supermicro.com/PRODUCT/MotherBoards/VIA/P3TDDE.htm
Manual page #10: IDE1/IDE2 for VIA, IDE RAID #1/#2 for PDC.
Page 14: 2 IDE bus master interfaces support UDMA/100 (listed first),
2 IDE RAID connectors (listed later). Page 49: IDE primary/secondary
settings relate to the VIA.
> all know better, are wiser, empower w/ megalmania (sp) and gawd knows what
> else. Please next time, do your homework before you attempt to call me
> on these issues. Do the two word "Native" and "Compatablity" in ATA-ATAPI
> have meaning? This will help you go a long way.
I did my homework. I still believe that there is NO MAINBOARD with
PDC20265, and without southbridge IDE - be it VIA, SiS, Intel or Nvidia.
All motherboards you listed have PDC (or HPT) as an additional controller,
and manual always refers to southbridge as IDE#1/IDE#2, while PDC
is referred as IDE RAID#1/#2, or even as IDE#3/IDE#4.
If you tried to prove that PDC20265 should never be ide0/ide1, then
we are on the same boat.
Petr Vandrovec
[email protected]
P.S.: Both Tyan and Epox should make their ftp servers much, much faster...
Because I can not get a FSCKING PATCH past any of the Lead Penquins.
/src/linux-2.5.4-pristine/drivers/ide/ide-pci.c
#ifdef CONFIG_PDC202XX_FORCE
{DEVID_PDC20265,"PDC20265", PCI_PDC202XX, ATA66_PDC202XX,
INIT_PDC202XX, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
ON_BOARD,
48 },
#else /* !CONFIG_PDC202XX_FORCE */
{DEVID_PDC20265,"PDC20265", PCI_PDC202XX, ATA66_PDC202XX,
INIT_PDC202XX, NULL, {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
OFF_BOARD,
48 },
#endif
But since there is the option to compile off-board as bootable, it is a
noop. I have not been able to directly add code or update any kernel
first hand since the change in 2.5.3 and my exit of Linux Development at
2.5.5. So I really don't give a damn.
But what I do know is people bug me for patches and updates and ask me to
fix 2.5.XX on a regular bases. Nobody takes my patches but man when crap
hits the fan they come running for me to put it right again.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 8 Aug 2002, Nick Orlov wrote:
> On Thu, Aug 08, 2002 at 03:50:19AM -0700, Andre Hedrick wrote:
> > On Wed, 7 Aug 2002, Bill Davidsen wrote:
> >
> > > I would just as soon use a boot option as to try and make it a compile
> > > option, and I think that many people just use a compiled kernel and never
> > > change, which argues for a reasonable default (most pdc20265) ARE
> > > currently offboard, and an easy way to change it.
> >
> > There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> > This is the direct asic packaging. Thus all pdc20265 have the right to be
> > listed as onboard.
>
> Could you comment next couple lines of code (2.4.19-vanilla):
>
> ==========================================
> #else /* !CONFIG_PDC202XX_FORCE */
> [ ... skipped ... ]
> {DEVID_PDC20265,"PDC20265" .... OFF_BOARD ..... },
> ^^^^^^^^^
> [ ... skipped ... ]
> #endif
> ==========================================
>
> Another bug? Just typo?
> Why author put PDC20265 in off-board list ?
>
> > Cheers,
> >
> > Andre Hedrick
> > LAD Storage Consulting Group
> >
>
> --
> With best wishes,
> Nick Orlov.
>
> -
> 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/
>
On 8 Aug 02 at 10:41, Andre Hedrick wrote:
> ide0 at 0xdfe0-0xdfe7,0xdfae on irq 31
> ide1 at 0xdfa0-0xdfa7,0xdfaa on irq 31
> ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
This is definitely bug. It should assigned ide0 to the port
in legacy mode, as far as I can tell.
> PIIX4: IDE controller on PCI bus 00 dev 39
> PIIX4: device not capable of full native PCI mode
> PIIX4: device disabled (BIOS)
> PIIX4: device disabled (BIOS)
> hda: DupliDisk IDE RAID-1 Adapter( 1.19), ATA DISK drive
> hdc: QUANTUM FIREBALLP KA13.6, ATA DISK drive
> ide2: ports already in use, skipping probe
> ide0 at 0xd800-0xd807,0xdc02 on irq 18
> ide1 at 0xe400-0xe407,0xe802 on irq 18
You have disabled PIIX4 here, so ide0/1 were not reserved. I assume
that if you enable PIIX4, it will use legacy ports, and will become
ide0/1.
Petr Vandrovec
Clearly the difference between what is silkscreened and the usage intent
is beyond the obvious :-/ Since I have had or still have first hand
experience in the observed behaior under Linux and MicroSoft, you are
going by what is read. Book knowledges gets you books not reality.
try a few w/ all of them bootable and see what happens. So until Linux
gets a clue about EDDS 2.0 and or 3.0 it has not a chance of getting the
correct hd0/hd1 from the INT13/19 services. Obviously experience and
first hand knowledge of reality is worthless in Linux. I am out of this
thread.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 8 Aug 2002, Petr Vandrovec wrote:
> On 8 Aug 02 at 10:30, Andre Hedrick wrote:
> >
> > http://www.tyan.com/products/html/thunderlet.html
>
> Page 40 of manual: choose Onboard IDE or FastTrak ATA-100/RAID.
> OnboardIDE means Serverworks, FastTrak means PDC20265.
> BIOS settings for primary/secondary disk relate to the Serverworks
> channels.
>
> > http://www.tyan.com/products/html/tiger200t.html
>
> Page 11: Primary/secondary IDE: VIA, RAID primary/secondary: PDC.
> Page 33: Primary/secondary IDE settings relate to the VIA.
>
> > http://www.tyan.com/products/html/trinityi845e.html
>
> Page 5: Integrated PCI IDE (it talks about i845 internal) +
> integrated IDE RAID (20267, so no relevance here). Page 28:
> primary/secondary disables i845, not PDC.
>
> > http://www.tyan.com/products/html/trinitygcsl.html
>
> Serverworks, with IDE. Serverworks IDE is primary.
> RAID is 20267, so no relevance. Manual not available yet.
>
> > http://www.epox.com/html/english/products/motherboard/ep-d3va.htm
>
> VIA onboard, HPT370 RAID. Connectors of RAID marked IDE3/IDE4.
>
> > http://www.epox.com/html/english/products/motherboard/ep-8k3a.htm
>
> 8k3a has no RAID. 8k3a+ has PDC20267. Primary IDE is from VIA,
> RAID is additional...
>
> > http://www.supermicro.com/PRODUCT/MotherBoards/VIA/370DDE.htm
>
> Manual unavailable from the web (404 Page not found after clicking
> on manual). Picture shows IDE #1/IDE #2 (VIA) and IDE RAID #1/#2.
> Besides that it has PDC20267, so it has no relevance to this discussion.
>
> > http://www.supermicro.com/PRODUCT/MotherBoards/VIA/P3TDDE.htm
>
> Manual page #10: IDE1/IDE2 for VIA, IDE RAID #1/#2 for PDC.
> Page 14: 2 IDE bus master interfaces support UDMA/100 (listed first),
> 2 IDE RAID connectors (listed later). Page 49: IDE primary/secondary
> settings relate to the VIA.
>
> > all know better, are wiser, empower w/ megalmania (sp) and gawd knows what
> > else. Please next time, do your homework before you attempt to call me
> > on these issues. Do the two word "Native" and "Compatablity" in ATA-ATAPI
> > have meaning? This will help you go a long way.
>
> I did my homework. I still believe that there is NO MAINBOARD with
> PDC20265, and without southbridge IDE - be it VIA, SiS, Intel or Nvidia.
> All motherboards you listed have PDC (or HPT) as an additional controller,
> and manual always refers to southbridge as IDE#1/IDE#2, while PDC
> is referred as IDE RAID#1/#2, or even as IDE#3/IDE#4.
>
> If you tried to prove that PDC20265 should never be ide0/ide1, then
> we are on the same boat.
> Petr Vandrovec
> [email protected]
>
> P.S.: Both Tyan and Epox should make their ftp servers much, much faster...
>
>
On Thu, 8 Aug 2002, Petr Vandrovec wrote:
> On 8 Aug 02 at 10:41, Andre Hedrick wrote:
>
> > ide0 at 0xdfe0-0xdfe7,0xdfae on irq 31
> > ide1 at 0xdfa0-0xdfa7,0xdfaa on irq 31
> > ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
>
> This is definitely bug. It should assigned ide0 to the port
> in legacy mode, as far as I can tell.
Again you have no experience in the logic!
This boots with Promise first because of BIOS Logic with INT19 hooks.
IE, that which I referenced in the documents that I know you did not read
but come back and state it has nothing to do with the issues.
> > PIIX4: IDE controller on PCI bus 00 dev 39
> > PIIX4: device not capable of full native PCI mode
> > PIIX4: device disabled (BIOS)
> > PIIX4: device disabled (BIOS)
> > hda: DupliDisk IDE RAID-1 Adapter( 1.19), ATA DISK drive
> > hdc: QUANTUM FIREBALLP KA13.6, ATA DISK drive
> > ide2: ports already in use, skipping probe
> > ide0 at 0xd800-0xd807,0xdc02 on irq 18
> > ide1 at 0xe400-0xe407,0xe802 on irq 18
>
> You have disabled PIIX4 here, so ide0/1 were not reserved. I assume
ASS U ME that is the word!
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
HPT366: onboard version of chipset, pin1=1 pin2=2
HPT366: IDE controller on PCI bus 00 dev 98
PCI: Enabling device 00:13.0 (0005 -> 0007)
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:pio
HPT366: IDE controller on PCI bus 00 dev 99
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
ide1: BM-DMA at 0xec00-0xec07, BIOS settings: hdc:DMA, hdd:pio
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xf000-0xf007, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xf008-0xf00f, BIOS settings: hdg:pio, hdh:pio
hda: DupliDisk IDE RAID-1 Adapter( 1.19), ATA DISK drive
hdc: QUANTUM FIREBALLP KA13.6, ATA DISK drive
ide0 at 0xd800-0xd807,0xdc02 on irq 18
ide1 at 0xe400-0xe407,0xe802 on irq 18
What do you need me to attach a device?
The FSCKING BIOS did this, because there is an option to boot UDMA66
first.
> that if you enable PIIX4, it will use legacy ports, and will become
> ide0/1.
> Petr Vandrovec
>
> -
> 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/
>
Electrons wasted :-/
On 8 Aug 02 at 11:43, Andre Hedrick wrote:
> On Thu, 8 Aug 2002, Petr Vandrovec wrote:
> > On 8 Aug 02 at 10:41, Andre Hedrick wrote:
> >
> > > ide0 at 0xdfe0-0xdfe7,0xdfae on irq 31
> > > ide1 at 0xdfa0-0xdfa7,0xdfaa on irq 31
> > > ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
> >
> > This is definitely bug. It should assigned ide0 to the port
> > in legacy mode, as far as I can tell.
>
> Again you have no experience in the logic!
>
> This boots with Promise first because of BIOS Logic with INT19 hooks.
> IE, that which I referenced in the documents that I know you did not read
> but come back and state it has nothing to do with the issues.
> Electrons wasted :-/
Yes, exactly. If you really believe that ide# (or even hd#) numbering
should change according to the BIOS boot order, then there is certainly
nothing we can agree on. And if I boot from floppy or SCSI, should IDE
code skip ide0/hda at all?
Maybe you did not notice that Linux can boot of /dev/hde, it does not
have to boot from /dev/hda. Just tell to LILO where /dev/hde lives (and
there are patches for EDD support, but adding two lines into /etc/lilo.conf
is easier than patching support for EDD structure, which is broken in 50%
of BIOSes I know anyway).
Petr
Uz.ytkownik Andre Hedrick napisa?:
> Because I can not get a FSCKING PATCH past any of the Lead Penquins.
>
> /src/linux-2.5.4-pristine/drivers/ide/ide-pci.c
> #ifdef CONFIG_PDC202XX_FORCE
> {DEVID_PDC20265,"PDC20265", PCI_PDC202XX, ATA66_PDC202XX,
> INIT_PDC202XX, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
> ON_BOARD,
> 48 },
> #else /* !CONFIG_PDC202XX_FORCE */
> {DEVID_PDC20265,"PDC20265", PCI_PDC202XX, ATA66_PDC202XX,
> INIT_PDC202XX, NULL, {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
> OFF_BOARD,
> 48 },
> #endif
>
> But since there is the option to compile off-board as bootable, it is a
> noop. I have not been able to directly add code or update any kernel
> first hand since the change in 2.5.3 and my exit of Linux Development at
> 2.5.5. So I really don't give a damn.
>
> But what I do know is people bug me for patches and updates and ask me to
> fix 2.5.XX on a regular bases. Nobody takes my patches but man when crap
> hits the fan they come running for me to put it right again.
Bullshit. First you have to send patches out at all before they can be
accepted or rejected. As far as I'm concerned I never saw anything from
him.
Uz.ytkownik Andre Hedrick napisa?:
> Clearly the difference between what is silkscreened and the usage intent
> is beyond the obvious :-/ Since I have had or still have first hand
> experience in the observed behaior under Linux and MicroSoft, you are
> going by what is read. Book knowledges gets you books not reality.
> try a few w/ all of them bootable and see what happens. So until Linux
> gets a clue about EDDS 2.0 and or 3.0 it has not a chance of getting the
> correct hd0/hd1 from the INT13/19 services. Obviously experience and
> first hand knowledge of reality is worthless in Linux. I am out of this
> thread.
BTW. EDDS is up to level 3.3
On Thu, 8 Aug 2002, Andre Hedrick wrote:
> On Wed, 7 Aug 2002, Bill Davidsen wrote:
>
> > I would just as soon use a boot option as to try and make it a compile
> > option, and I think that many people just use a compiled kernel and never
> > change, which argues for a reasonable default (most pdc20265) ARE
> > currently offboard, and an easy way to change it.
>
> There are ZERO pdc20265's offboard, only pdc20267's were in both options.
> This is the direct asic packaging. Thus all pdc20265 have the right to be
> listed as onboard. If you have a pdc20265 on an add-on card please send
> me a digital photo so I can question promise as to why.
I probably should have said non-primary, but the issue is the the pdc now
may be identified before the built-in IDE, such as VIA. If Linux doesn't
identify hda as the same drive as the BIOS, interesting boot problems
occur. And if 2.4.18 did one thing and 2.4.19 did another it gets even
more likely to confuse the user.
I think the real issue is if we should change the order of detection in a
stable kernel series, and I'll just sit and watch the sparks, there seem
to be strong feelings both ways.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thu, 8 Aug 2002, Petr Vandrovec wrote:
> Maybe you did not notice that Linux can boot of /dev/hde, it does not
> have to boot from /dev/hda. Just tell to LILO where /dev/hde lives (and
> there are patches for EDD support, but adding two lines into /etc/lilo.conf
> is easier than patching support for EDD structure, which is broken in 50%
> of BIOSes I know anyway).
You can tell LILO anything you want, but the system will "boot off"
whichever drive the BIOS chooses for reading the MBR. In other words,
unless you diddle the BIOS settings, the LILO MBR (1st level boot) must go
on hda, regardless of where the root filesystem lives.
Yes, I know you can install LILO in a partition, but then you have to
trust whatever MBR the BIOS runs to find it.
This was intended as a clarification of the process, I don't think I am
disagreeing with what you said.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Wed, 7 Aug 2002, Rik van Riel wrote:
> On Wed, 7 Aug 2002, Bill Davidsen wrote:
>
> > Sure, glad to. If the 2.5 numbers are much worse than 2.4, somthing
> > isn't working as well,
>
> Are you volunteering to identify that "something" for us ?
Hell no. I was simply commenting that there is some general qualitative
information available from those numbers, even if it is hard to quantify
them. Not working as well for a benchmark may indicate much better typical
performance, and as I understand dbench the io scheduler may improve that
significantly as well.
No, clearly there are other, probably a lot more representative numbers,
which show 2.5 is better. "Isn't working as well" for one thing doesn't
mean "in general," but might be of interest to the primary developers.
The fact that the curve doesn't end in a reload from backup tells me that
the IDE code is much better that it was ;-)
What time I have for diddling kernel code is spent on making network code
changes, and is all against 2.4 base.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Fri, 9 Aug 2002, Bill Davidsen wrote:
> On Wed, 7 Aug 2002, Rik van Riel wrote:
> > On Wed, 7 Aug 2002, Bill Davidsen wrote:
> >
> > > Sure, glad to. If the 2.5 numbers are much worse than 2.4, somthing
> > > isn't working as well,
> >
> > Are you volunteering to identify that "something" for us ?
>
> Hell no. I was simply commenting that there is some general qualitative
> information available from those numbers, even if it is hard to quantify
> them.
As long as there is nobody to interpret what the dbench
numbers actually mean, why are we treating them as the
most important thing around ? ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
On Fri, 9 Aug 2002, Marcin Dalecki wrote:
> Uz.ytkownik Andre Hedrick napisa?:
> > Clearly the difference between what is silkscreened and the usage intent
> > is beyond the obvious :-/ Since I have had or still have first hand
> > experience in the observed behaior under Linux and MicroSoft, you are
> > going by what is read. Book knowledges gets you books not reality.
> > try a few w/ all of them bootable and see what happens. So until Linux
> > gets a clue about EDDS 2.0 and or 3.0 it has not a chance of getting the
> > correct hd0/hd1 from the INT13/19 services. Obviously experience and
> > first hand knowledge of reality is worthless in Linux. I am out of this
> > thread.
>
> BTW. EDDS is up to level 3.3
That is nice to know since it has never been submitted to the Committee
and the last time I checked with the author it was 3.0. Then again you
are so vast with knowledge, maybe you submitted 3.3 ... LOL.
You are so full of BULLSHIT it is no longer funny.
e02112r1 is the current revision for project proposal for EDDS 3.0.
Gee, where is Martin's name and or Company to be found for the adoption
into ATA-7.
No where.
Andre Hedrick
LAD Storage Consulting Group
Hey PinHead #2,
> > /src/linux-2.5.4-pristine/drivers/ide/ide-pci.c
This was before you WRECKED the functionality.
I am having to much of a laugh watching you destroy the driver and the Fin
having the suffer the pain of the reports of your global failure.
The only patch I will send you is rm -rf ./linux-2.5.X/driver/ide/
It is the only proper thing to do at this time.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 9 Aug 2002, Marcin Dalecki wrote:
> Uz.ytkownik Andre Hedrick napisa?:
> > Because I can not get a FSCKING PATCH past any of the Lead Penquins.
> >
> > /src/linux-2.5.4-pristine/drivers/ide/ide-pci.c
> > #ifdef CONFIG_PDC202XX_FORCE
> > {DEVID_PDC20265,"PDC20265", PCI_PDC202XX, ATA66_PDC202XX,
> > INIT_PDC202XX, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
> > ON_BOARD,
> > 48 },
> > #else /* !CONFIG_PDC202XX_FORCE */
> > {DEVID_PDC20265,"PDC20265", PCI_PDC202XX, ATA66_PDC202XX,
> > INIT_PDC202XX, NULL, {{0x50,0x02,0x02}, {0x50,0x04,0x04}},
> > OFF_BOARD,
> > 48 },
> > #endif
> >
> > But since there is the option to compile off-board as bootable, it is a
> > noop. I have not been able to directly add code or update any kernel
> > first hand since the change in 2.5.3 and my exit of Linux Development at
> > 2.5.5. So I really don't give a damn.
> >
> > But what I do know is people bug me for patches and updates and ask me to
> > fix 2.5.XX on a regular bases. Nobody takes my patches but man when crap
> > hits the fan they come running for me to put it right again.
>
> Bullshit. First you have to send patches out at all before they can be
> accepted or rejected. As far as I'm concerned I never saw anything from
> him.
>
> -
> 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/
>