Hi.
New version, just collected latest important bugfixes:
- Serial port number assign (05-serial.gz)
- pagemap.h include for fs/ (04-fs-pagemap.gz)
- unlocking order in buffer.c::end_buffer_io_kiobuf (03-unlock-bh-before.gz)
And a couple new additions:
- ide update -3a (very shrinked wrt original, the big ppc part has gone
in mainline)
- netconsole-C2-2 (for my beowulf...)
Rest as usual, O1-sched-k3 (is any backport of the updates planned ??)
mini-low-lat, splitted-vm-33, bproc-3.1.9.
Enjoy !!
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre7-jam1 #1 SMP Wed Apr 17 00:42:27 CEST 2002 i686
There is a micro bug in 3a, look for 4 to arrive.
regards
On Wed, 17 Apr 2002, J.A. Magallon wrote:
> Hi.
>
> New version, just collected latest important bugfixes:
>
> - Serial port number assign (05-serial.gz)
> - pagemap.h include for fs/ (04-fs-pagemap.gz)
> - unlocking order in buffer.c::end_buffer_io_kiobuf (03-unlock-bh-before.gz)
>
> And a couple new additions:
>
> - ide update -3a (very shrinked wrt original, the big ppc part has gone
> in mainline)
> - netconsole-C2-2 (for my beowulf...)
>
> Rest as usual, O1-sched-k3 (is any backport of the updates planned ??)
> mini-low-lat, splitted-vm-33, bproc-3.1.9.
>
> Enjoy !!
>
> --
> J.A. Magallon # Let the source be with you...
> mailto:[email protected]
> Mandrake Linux release 8.3 (Cooker) for i586
> Linux werewolf 2.4.19-pre7-jam1 #1 SMP Wed Apr 17 00:42:27 CEST 2002 i686
> -
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
On 2002.04.17 Andre Hedrick wrote:
>There is a micro bug in 3a, look for 4 to arrive.
>
>regards
>
[...]
>>
>> - ide update -3a (very shrinked wrt original, the big ppc part has gone
>> in mainline)
Can it be related to my system getting hung on boot trying to do
an hdparm ?
I had not the time to dig more, just disabled it and booted fine (I had
some work to get done...)
TIA
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre7-jam1 #1 SMP Wed Apr 17 00:42:27 CEST 2002 i686
Yep
That is the bug on the ide_driveid_update call.
Find it and change the #if 1 to #if 0
Cheers,
On Wed, 17 Apr 2002, J.A. Magallon wrote:
>
> On 2002.04.17 Andre Hedrick wrote:
> >There is a micro bug in 3a, look for 4 to arrive.
> >
> >regards
> >
> [...]
> >>
> >> - ide update -3a (very shrinked wrt original, the big ppc part has gone
> >> in mainline)
>
> Can it be related to my system getting hung on boot trying to do
> an hdparm ?
> I had not the time to dig more, just disabled it and booted fine (I had
> some work to get done...)
>
> TIA
>
> --
> J.A. Magallon # Let the source be with you...
> mailto:[email protected]
> Mandrake Linux release 8.3 (Cooker) for i586
> Linux werewolf 2.4.19-pre7-jam1 #1 SMP Wed Apr 17 00:42:27 CEST 2002 i686
> -
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
On Wed Apr 17 2002, J.A. Magallon wrote:
> Can it be related to my system getting hung on boot trying to do
> an hdparm ?
Yep, here it is exactly the same.
I also changed '#if 1' to '#if 0' as Andre mentioned but it has no effect,
my machine hangs at boot time....
--
# Heinz Diehl, 68259 Mannheim, Germany
On 2002.04.18 Heinz Diehl wrote:
>On Wed Apr 17 2002, J.A. Magallon wrote:
>
>> Can it be related to my system getting hung on boot trying to do
>> an hdparm ?
>
>Yep, here it is exactly the same.
>
>I also changed '#if 1' to '#if 0' as Andre mentioned but it has no effect,
>my machine hangs at boot time....
>
It worked for me, just booted fine with hdparm included...
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre7-jam1 #2 SMP Wed Apr 17 21:20:31 CEST 2002 i686
Thanks for the positive feedback!
About to add and test HPT372 final and then complete the MMIO operations.
Next will be to make the driver do the error recovery path that block does
not support and accellerate IO with true zero-copy. Lastly will make the
entire stack modular, which is about 50% completed.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 18 Apr 2002, J.A. Magallon wrote:
>
> On 2002.04.18 Heinz Diehl wrote:
> >On Wed Apr 17 2002, J.A. Magallon wrote:
> >
> >> Can it be related to my system getting hung on boot trying to do
> >> an hdparm ?
> >
> >Yep, here it is exactly the same.
> >
> >I also changed '#if 1' to '#if 0' as Andre mentioned but it has no effect,
> >my machine hangs at boot time....
> >
>
> It worked for me, just booted fine with hdparm included...
>
> --
> J.A. Magallon # Let the source be with you...
> mailto:[email protected]
> Mandrake Linux release 8.3 (Cooker) for i586
> Linux werewolf 2.4.19-pre7-jam1 #2 SMP Wed Apr 17 21:20:31 CEST 2002 i686
> -
> 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 Thu Apr 18, 2002 at 12:34:29PM -0700, Andre Hedrick wrote:
>
> Thanks for the positive feedback!
FYI, I have tried it as well (ide-2.4.19-p6.all.convert.3a.patch
on 2.4.19-p7 plus your recommended #if 0 change) and it has been
working nicely for me as well on a number of machines. This
certainly seems to be a nice improvement.
> About to add and test HPT372 final and then complete the MMIO operations.
> Next will be to make the driver do the error recovery path that block does
Can you go into a little detail on your plans for error handling?
I think the currently error handling for the ide-subsystem,
especially in the presence of sequences of bad sectors, is not
especially robust (and is quite slow)... In one case I tested
yesterday (with 2.4.19-p7 plus your patch) using a 340 MB
microdrive with a big chunk of bad sectors on it (the device
admittedly is in pretty sorry shape but makes an excellent
ide-subsystem tester ;-), the kernel wedged solid while trying to
read from it...
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Well the proper solution is for me to finish the "ide-flash" subdriver.
As CFA devices have special error transformations and decodes, as will any
SDA device.
Proper error path in the driver ... hmmm, I have a discription and batted
it around and more people understand the problem now. The issue becomes
in full disclosure and not producing a mass panic. I would like to have a
solution complete before "wolf" and nothing to kill the beast in sight.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 18 Apr 2002, Erik Andersen wrote:
> On Thu Apr 18, 2002 at 12:34:29PM -0700, Andre Hedrick wrote:
> >
> > Thanks for the positive feedback!
>
> FYI, I have tried it as well (ide-2.4.19-p6.all.convert.3a.patch
> on 2.4.19-p7 plus your recommended #if 0 change) and it has been
> working nicely for me as well on a number of machines. This
> certainly seems to be a nice improvement.
>
> > About to add and test HPT372 final and then complete the MMIO operations.
> > Next will be to make the driver do the error recovery path that block does
>
> Can you go into a little detail on your plans for error handling?
>
> I think the currently error handling for the ide-subsystem,
> especially in the presence of sequences of bad sectors, is not
> especially robust (and is quite slow)... In one case I tested
> yesterday (with 2.4.19-p7 plus your patch) using a 340 MB
> microdrive with a big chunk of bad sectors on it (the device
> admittedly is in pretty sorry shape but makes an excellent
> ide-subsystem tester ;-), the kernel wedged solid while trying to
> read from it...
>
> -Erik
>
> --
> Erik B. Andersen http://codepoet-consulting.com/
> --This message was written using 73% post-consumer electrons--
> -
> 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/
>
J.A. Magallon wrote:
[-]
> Rest as usual, O1-sched-k3 (is any backport of the updates planned ??)
> mini-low-lat, splitted-vm-33, bproc-3.1.9.
Have you ever done any "regression testing" with your -jam patch?
Then you should have found very very bad latency behavior with O(1)-K3
applied! Even Alan's -ac series (including the latest O(1)-K3 patch) is
shocked.
No uptodate O(1) patch for 2.4. Very sad.
So there isn't any change to see a current preemption patch on top of vm33 and
O(1).
No, lowlatency didn't come close to preemption+lock-break (best latency
numbers for 2.4.17-preX-rml, were ~2.9ms max).
I'm under the impression that "all" development is focused on 2.5.x, now.
Even the VM stuff show no mayor growth ;-(
Additional latencytest0.42-png numbers for both kernels are available.
Thanks,
Dieter
2.4.19-pre7-dn1
splitted vm33
23-lowlatency-mini
24-lowlatency-fixes-5
25-read-latency-2
SunWave1 dbench/latencytest0.42-png# time ./do_tests none 3 256 0 350000000
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40200000 on :0.0
from SunWave1
Thu Apr 18 21:03:48 2002
Sync time adjustment is 0.2185 msecs.
3000 reps @ 2.2690 msec ( 441.0/sec): Scroll 500x500 pixels
3000 reps @ 2.2747 msec ( 440.0/sec): Scroll 500x500 pixels
3000 reps @ 2.2709 msec ( 440.0/sec): Scroll 500x500 pixels
3000 reps @ 2.2697 msec ( 441.0/sec): Scroll 500x500 pixels
3000 reps @ 2.2771 msec ( 439.0/sec): Scroll 500x500 pixels
15000 trep @ 2.2723 msec ( 440.0/sec): Scroll 500x500 pixels
800 reps @ 11.8050 msec ( 84.7/sec): ShmPutImage 500x500 square
800 reps @ 11.8099 msec ( 84.7/sec): ShmPutImage 500x500 square
800 reps @ 11.9632 msec ( 83.6/sec): ShmPutImage 500x500 square
800 reps @ 11.8041 msec ( 84.7/sec): ShmPutImage 500x500 square
800 reps @ 11.8199 msec ( 84.6/sec): ShmPutImage 500x500 square
4000 trep @ 11.8404 msec ( 84.5/sec): ShmPutImage 500x500 square
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
4.2ms ( 0)|
1MS num_time_samples=64412 num_times_within_1ms=62014 factor=96.277091
2MS num_time_samples=64412 num_times_within_2ms=64403 factor=99.986027
PIXEL_PER_MS=103
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
4.2ms ( 0)|
1MS num_time_samples=20748 num_times_within_1ms=20050 factor=96.635820
2MS num_time_samples=20748 num_times_within_2ms=20746 factor=99.990361
PIXEL_PER_MS=103
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
4.5ms ( 1)|
1MS num_time_samples=10451 num_times_within_1ms=10007 factor=95.751603
2MS num_time_samples=10451 num_times_within_2ms=10436 factor=99.856473
PIXEL_PER_MS=103
-rw-r--r-- 1 root root 350000000 Apr 18 21:06 tmpfile
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
7.8ms ( 4)|
1MS num_time_samples=21423 num_times_within_1ms=20546 factor=95.906269
2MS num_time_samples=21423 num_times_within_2ms=21411 factor=99.943985
PIXEL_PER_MS=103
-rw-r--r-- 1 root root 350000000 Apr 18 21:06 tmpfile
-rw-r--r-- 1 root root 350000000 Apr 18 21:07 tmpfile2
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
4.4ms ( 1)|
1MS num_time_samples=16340 num_times_within_1ms=15597 factor=95.452876
2MS num_time_samples=16340 num_times_within_2ms=16324 factor=99.902081
PIXEL_PER_MS=103
-rw-r--r-- 1 root root 350000000 Apr 18 21:06 tmpfile
-rw-r--r-- 1 root root 350000000 Apr 18 21:07 tmpfile2
109.610u 17.740s 4:03.41 52.3% 0+0k 0+0io 10444pf+0w
*******************************************************************************
2.4.19-pre7-dn1
splitted vm33
23-lowlatency-mini
24-lowlatency-fixes-5
25-read-latency-2
20-sched-O1-K3
21-sched-balance
22-sched-aa-fixes
SunWave1 dbench/latencytest0.42-png# time ./do_tests none 3 256 0 350000000
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40200000 on :0.0
from SunWave1
Fri Apr 19 00:40:11 2002
Sync time adjustment is 0.1351 msecs.
3000 reps @ 1.8390 msec ( 544.0/sec): Scroll 500x500 pixels
3000 reps @ 1.6942 msec ( 590.0/sec): Scroll 500x500 pixels
3000 reps @ 1.6915 msec ( 591.0/sec): Scroll 500x500 pixels
3000 reps @ 1.6962 msec ( 590.0/sec): Scroll 500x500 pixels
3000 reps @ 1.6949 msec ( 590.0/sec): Scroll 500x500 pixels
15000 trep @ 1.7231 msec ( 580.0/sec): Scroll 500x500 pixels
1200 reps @ 5.2230 msec ( 191.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2480 msec ( 191.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2290 msec ( 191.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2355 msec ( 191.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2289 msec ( 191.0/sec): ShmPutImage 500x500 square
6000 trep @ 5.2328 msec ( 191.0/sec): ShmPutImage 500x500 square
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
247.4ms (423)|
1MS num_time_samples=6079 num_times_within_1ms=5462 factor=89.850304
2MS num_time_samples=6079 num_times_within_2ms=5646 factor=92.877118
PIXEL_PER_MS=103
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
351.8ms ( 15)|
1MS num_time_samples=19475 num_times_within_1ms=15437 factor=79.265725
2MS num_time_samples=19475 num_times_within_2ms=19415 factor=99.691913
PIXEL_PER_MS=103
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
150.7ms ( 24)|
1MS num_time_samples=7052 num_times_within_1ms=6852 factor=97.163925
2MS num_time_samples=7052 num_times_within_2ms=7003 factor=99.305162
PIXEL_PER_MS=103
-rw-r--r-- 1 root root 350000000 Apr 19 00:42 tmpfile
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
42.9ms (378)|
1MS num_time_samples=16697 num_times_within_1ms=16021 factor=95.951369
2MS num_time_samples=16697 num_times_within_2ms=16273 factor=97.460622
PIXEL_PER_MS=103
-rw-r--r-- 1 root root 350000000 Apr 19 00:42 tmpfile
-rw-r--r-- 1 root root 350000000 Apr 19 00:43 tmpfile2
fragment latency = 1.451247 ms
cpu latency = 1.160998 ms
525.6ms (551)|
1MS num_time_samples=13764 num_times_within_1ms=12584 factor=91.426911
2MS num_time_samples=13764 num_times_within_2ms=12839 factor=93.279570
PIXEL_PER_MS=103
-rw-r--r-- 1 root root 350000000 Apr 19 00:42 tmpfile
-rw-r--r-- 1 root root 350000000 Apr 19 00:43 tmpfile2
40.610u 16.630s 3:28.57 27.4% 0+0k 0+0io 10796pf+0w
--
Dieter N?tzel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [email protected]
On Thu, 2002-04-18 at 19:36, Dieter N?tzel wrote:
> No uptodate O(1) patch for 2.4. Very sad.
> So there isn't any change to see a current preemption patch on top of vm33
> and O(1).
I am working on backports of all the O(1) scheduler changes in 2.5, the
pending changes, and some other misc. bits. I also have versions of the
migration_thread and affinity stuff for 2.4.
I will release a general O(1) patch and a patch for -ac soon - hopefully
tomorrow or Monday. I have no idea if it fixes the problems you are
seeing, because I have no idea what caused a regression in the O(1)
code.
> No, lowlatency didn't come close to preemption+lock-break (best latency
> numbers for 2.4.17-preX-rml, were ~2.9ms max).
Good to hear ;)
> I'm under the impression that "all" development is focused on 2.5.x, now.
> Even the VM stuff show no mayor growth ;-(
That is the point of 2.5 :)
Development => !Stability and people need to start using 2.4 to get work
done, not reap faster and faster benchmarks times. I seriously suspect
2.4 is performing fine right now for what you are doing, anyhow.
Also, a lot of VM work is happening in 2.4 (and not in 2.5 even, at the
moment). 2.4.19-pre has seen a few of the -aa bits merged and should
see most of the others in due time.
There is also Rik's -rmap for 2.4 ...
Robert Love
On Friday 19 April 2002 01:44, Robert Love wrote:
> On Thu, 2002-04-18 at 19:36, Dieter N?tzel wrote:
> > No uptodate O(1) patch for 2.4. Very sad.
> > So there isn't any change to see a current preemption patch on top of
> > vm33 and O(1).
>
> I am working on backports of all the O(1) scheduler changes in 2.5, the
> pending changes, and some other misc. bits. I also have versions of the
> migration_thread and affinity stuff for 2.4.
Ahhh, I'm very happy to hear this. GREAT!!!
> I will release a general O(1) patch and a patch for -ac soon - hopefully
> tomorrow or Monday. I have no idea if it fixes the problems you are
> seeing, because I have no idea what caused a regression in the O(1)
> code.
I couldn't figure it right, but I've rechecked simple 2.4.18 without all
"pending stuff" and it shows the same numbers as 2.4.19-pre7+AA.
When I apply Ingo's originall sched-O1-2.4.18-pre8-K3.patch or J.A.'s the
latency goes bad.
> > No, lowlatency didn't come close to preemption+lock-break (best latency
> > numbers for 2.4.17-preX-rml, were ~2.9ms max).
>
> Good to hear ;)
>
> > I'm under the impression that "all" development is focused on 2.5.x, now.
> > Even the VM stuff show no mayor growth ;-(
>
> That is the point of 2.5 :)
Yes, I know, it is more fun...;-)
> Development => !Stability and people need to start using 2.4 to get work
> done, not reap faster and faster benchmarks times. I seriously suspect
> 2.4 is performing fine right now for what you are doing, anyhow.
Nope, it is my devel machine and I do "heavy" C++ VIS app and XFree86 DRI
compiler runs in the background during browsing, mail, etc. --- "Normal"
workstation use...;-)
My dual Athlon MP/XP is some days around the corner ;-(
> Also, a lot of VM work is happening in 2.4 (and not in 2.5 even, at the
> moment). 2.4.19-pre has seen a few of the -aa bits merged and should
> see most of the others in due time.
>
> There is also Rik's -rmap for 2.4 ...
Wouldn't start a VM flameware, again but -rmap didn't come close in VM
throughput. 2.4.17-preX-aa-O(1)-rml was the killer.
Thank you for all your work!
-Dieter
BTW As always, send me copies, please ;-)
On Thu, Apr 18 2002, Andre Hedrick wrote:
> not support and accellerate IO with true zero-copy. [...]
Care to expand on what you are talking about here?
--
Jens Axboe
On Fri, 19 Apr 2002, Dieter [iso-8859-15] N?tzel wrote:
> No uptodate O(1) patch for 2.4. Very sad. So there isn't any change to
> see a current preemption patch on top of vm33 and O(1).
>
> [...]
> I'm under the impression that "all" development is focused on 2.5.x, now.
well, 2.5's scheduler bits were pretty much in flux in the past two months
or so, partly due to the preemption feature going in. And there are a
number of other changes in the pipeline as well. So what makes sense for
2.4 is Robert's plan: to backport O(1)+preempt once 2.5 is slowing down,
that way we get the proper testing of both components, instead of a
separated scheduler patch that doesnt even exist in that form in 2.5.
Ingo
On Friday 19 April 2002 09:43, Ingo Molnar wrote:
> On Fri, 19 Apr 2002, Dieter [iso-8859-15] N?tzel wrote:
> > No uptodate O(1) patch for 2.4. Very sad. So there isn't any change to
> > see a current preemption patch on top of vm33 and O(1).
> >
> > [...]
> > I'm under the impression that "all" development is focused on 2.5.x, now.
>
> well, 2.5's scheduler bits were pretty much in flux in the past two months
> or so, partly due to the preemption feature going in. And there are a
> number of other changes in the pipeline as well. So what makes sense for
> 2.4 is Robert's plan: to backport O(1)+preempt once 2.5 is slowing down,
> that way we get the proper testing of both components, instead of a
> separated scheduler patch that doesnt even exist in that form in 2.5.
Thank you very much for your answer Ingo.
It was somewhat still around you. So I was not sure if we have to be worry
about you.
OK, you are fine.
Regards,
Dieter
On Thu Apr 18 2002, J.A. Magallon wrote:
> >I also changed '#if 1' to '#if 0' as Andre mentioned but it has no effect,
> >my machine hangs at boot time....
> It worked for me, just booted fine with hdparm included...
I just merged "ide-2.4.19-p7.all.convert.5.patch" into my tree, and now
it works also for me. With former versions my machine hung at boot time,
wether #if 0 or 1 was set.
--
# Heinz Diehl, 68259 Mannheim, Germany
Thank you for the positive report ! :-)
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Fri, 19 Apr 2002, Heinz Diehl wrote:
> On Thu Apr 18 2002, J.A. Magallon wrote:
>
> > >I also changed '#if 1' to '#if 0' as Andre mentioned but it has no effect,
> > >my machine hangs at boot time....
>
> > It worked for me, just booted fine with hdparm included...
>
> I just merged "ide-2.4.19-p7.all.convert.5.patch" into my tree, and now
> it works also for me. With former versions my machine hung at boot time,
> wether #if 0 or 1 was set.
>
> --
> # Heinz Diehl, 68259 Mannheim, Germany
> -
> 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 2002.04.19 Heinz Diehl wrote:
>On Thu Apr 18 2002, J.A. Magallon wrote:
>
>> >I also changed '#if 1' to '#if 0' as Andre mentioned but it has no effect,
>> >my machine hangs at boot time....
>
>> It worked for me, just booted fine with hdparm included...
>
>I just merged "ide-2.4.19-p7.all.convert.5.patch" into my tree, and now
>it works also for me. With former versions my machine hung at boot time,
>wether #if 0 or 1 was set.
>
Just a 'me too'. Patch -5 booted fine, I have put a -jam2 in the usual place:
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre7-jam2 #1 SMP s?b abr 20 00:20:15 CEST 2002 i686
http://www.linuxdiskcert.org/ide-2.4.19-p7.all.convert.6.patch.bz2
fixes hpt372
migration towards modular chipsets
devfs ide-scsi
more but can not remember
little uglyer but will collapse clean.
thanks for testing...
On Sat, 20 Apr 2002, J.A. Magallon wrote:
>
> On 2002.04.19 Heinz Diehl wrote:
> >On Thu Apr 18 2002, J.A. Magallon wrote:
> >
> >> >I also changed '#if 1' to '#if 0' as Andre mentioned but it has no effect,
> >> >my machine hangs at boot time....
> >
> >> It worked for me, just booted fine with hdparm included...
> >
> >I just merged "ide-2.4.19-p7.all.convert.5.patch" into my tree, and now
> >it works also for me. With former versions my machine hung at boot time,
> >wether #if 0 or 1 was set.
> >
>
> Just a 'me too'. Patch -5 booted fine, I have put a -jam2 in the usual place:
>
>
> --
> J.A. Magallon # Let the source be with you...
> mailto:[email protected]
> Mandrake Linux release 8.3 (Cooker) for i586
> Linux werewolf 2.4.19-pre7-jam2 #1 SMP s?b abr 20 00:20:15 CEST 2002 i686
> -
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
On Sat, Apr 20, 2002 at 03:41:17AM -0700, Andre Hedrick wrote:
> http://www.linuxdiskcert.org/ide-2.4.19-p7.all.convert.6.patch.bz2
>
> fixes hpt372
> migration towards modular chipsets
> devfs ide-scsi
> more but can not remember
> little uglyer but will collapse clean.
>
> thanks for testing...
Boots fine here. I'll bang on the ide-scsi bit by burning some stuff.
--
Dan Chen [email protected]
GPG key: http://www.unc.edu/~crimsun/pubkey.gpg.asc
On Sat Apr 20 2002, Andre Hedrick wrote:
> http://www.linuxdiskcert.org/ide-2.4.19-p7.all.convert.6.patch.bz2
No problems so far, will report if something strange occurs.
--
# Heinz Diehl, 68259 Mannheim, Germany
Heinz Diehl wrote:
> On Sat Apr 20 2002, Andre Hedrick wrote:
>
>
>>http://www.linuxdiskcert.org/ide-2.4.19-p7.all.convert.6.patch.bz2
>>
>
> No problems so far, will report if something strange occurs.
>
>
Same here.
Running *very* smoothly.
Fran?ois