Vojtech Pavlik wrote:
>
> I'm *not* sure. It just looks like a reasonable explanation. It doesn't
> happen on Intel chips and older VIA chips, it only happens on new VIA
> chips, and the code is the same all the time. Also, it happens both with
> 2.2 and 2.4 kernels ...
>
> --
> Vojtech Pavlik
On Fri, Oct 27, 2000 at 02:04:58PM +0200, [EMAIL PROTECTED] wrote:
> > Interesting. If it's caused by SCSI as well (might be), then it's not
> > caused by heavy IDE activity but rather than that it could be heavy
> > BusMastering activity instead (The IDE chip does BM as well).
> >
> > I'm
On 26 Oct, Vojtech Pavlik wrote:
> On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote:
>
>> > On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote:
>> >
>> > > ...
>> > >
>> > > Have you any idea what is the relation between time and this chip ?
>> > >
>> > >
On Fri, Oct 27, 2000 at 01:16:34PM +0200, Yoann Vandoorselaere wrote:
> > Which part of the chipset you mean? The PIT (programmable interrupt
> > timer)? That one is standard since XT times. The rest of the ISA bridge?
> > Maybe, but that's mostly BIOS work and shouldn't impact the PIT
> > under
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere wrote:
>
> > > > > So this is not our problem here. Anyway I guess it's time to hunt for
> > > > > i8259 accesses in the kernel that lack the necessary spinlock, even when
> > > > >
On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere wrote:
> > > > So this is not our problem here. Anyway I guess it's time to hunt for
> > > > i8259 accesses in the kernel that lack the necessary spinlock, even when
> > > > they're not probably the cause of the problem we see here.
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares wrote:
>
> > > So this is not our problem here. Anyway I guess it's time to hunt for
> > > i8259 accesses in the kernel that lack the necessary spinlock, even when
> > > they're not probably the
On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares wrote:
> > So this is not our problem here. Anyway I guess it's time to hunt for
> > i8259 accesses in the kernel that lack the necessary spinlock, even when
> > they're not probably the cause of the problem we see here.
>
> BTW what about
Hi!
> So this is not our problem here. Anyway I guess it's time to hunt for
> i8259 accesses in the kernel that lack the necessary spinlock, even when
> they're not probably the cause of the problem we see here.
BTW what about trying to modify your work-around code to make it
attempt to read
Hi!
So this is not our problem here. Anyway I guess it's time to hunt for
i8259 accesses in the kernel that lack the necessary spinlock, even when
they're not probably the cause of the problem we see here.
BTW what about trying to modify your work-around code to make it
attempt to read the
On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares wrote:
So this is not our problem here. Anyway I guess it's time to hunt for
i8259 accesses in the kernel that lack the necessary spinlock, even when
they're not probably the cause of the problem we see here.
BTW what about trying
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares wrote:
So this is not our problem here. Anyway I guess it's time to hunt for
i8259 accesses in the kernel that lack the necessary spinlock, even when
they're not probably the cause of the
On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere wrote:
So this is not our problem here. Anyway I guess it's time to hunt for
i8259 accesses in the kernel that lack the necessary spinlock, even when
they're not probably the cause of the problem we see here.
BTW
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere wrote:
So this is not our problem here. Anyway I guess it's time to hunt for
i8259 accesses in the kernel that lack the necessary spinlock, even when
they're not probably the
On Fri, Oct 27, 2000 at 01:16:34PM +0200, Yoann Vandoorselaere wrote:
Which part of the chipset you mean? The PIT (programmable interrupt
timer)? That one is standard since XT times. The rest of the ISA bridge?
Maybe, but that's mostly BIOS work and shouldn't impact the PIT
under sane
On 26 Oct, Vojtech Pavlik wrote:
On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote:
On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote:
...
Have you any idea what is the relation between time and this chip ?
Also, I'm experiencing the
On Fri, Oct 27, 2000 at 02:04:58PM +0200, [EMAIL PROTECTED] wrote:
Interesting. If it's caused by SCSI as well (might be), then it's not
caused by heavy IDE activity but rather than that it could be heavy
BusMastering activity instead (The IDE chip does BM as well).
I'm still
Vojtech Pavlik wrote:
I'm *not* sure. It just looks like a reasonable explanation. It doesn't
happen on Intel chips and older VIA chips, it only happens on new VIA
chips, and the code is the same all the time. Also, it happens both with
2.2 and 2.4 kernels ...
--
Vojtech Pavlik
SuSE
On Thu, Oct 26, 2000 at 11:24:38PM +0200, Yoann Vandoorselaere wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> writes:
>
> > On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote:
> >
> > > yop, I 've done :
> > >
> > > make -j10 World
> > > in the xfree tree and simulateously :
>
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote:
>
> > yop, I 've done :
> >
> > make -j10 World
> > in the xfree tree and simulateously :
> >
> > while true; do make dep && make clean && make bzImage; done
> > in the kernel
On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote:
> yop, I 've done :
>
> make -j10 World
> in the xfree tree and simulateously :
>
> while true; do make dep && make clean && make bzImage; done
> in the kernel tree
Now it'd be nice to verify that the problem also happens
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Thu, Oct 26, 2000 at 10:11:54PM +0200, Yoann Vandoorselaere wrote:
>
> > > > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
> > > > > > to the timer. It writes 0 to the control-word for timer 0. This
> > > > > > does the
On Thu, Oct 26, 2000 at 10:11:54PM +0200, Yoann Vandoorselaere wrote:
> > > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
> > > > > to the timer. It writes 0 to the control-word for timer 0. This
> > > > > does the following:
> > > [Snipped...]
> > > >
> > > > Well,
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote:
>
> > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
> > > > to the timer. It writes 0 to the control-word for timer 0. This
> > > > does the following:
> >
On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote:
> > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
> > > to the timer. It writes 0 to the control-word for timer 0. This
> > > does the following:
> [Snipped...]
> >
> > Well, at least on 2.4.0-test9,
On Thu, 26 Oct 2000, Vojtech Pavlik wrote:
> On Thu, Oct 26, 2000 at 12:04:21PM -0400, Richard B. Johnson wrote:
>
> > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
> > to the timer. It writes 0 to the control-word for timer 0. This
> > does the following:
[Snipped...]
>
On Thu, Oct 26, 2000 at 12:04:21PM -0400, Richard B. Johnson wrote:
> ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
> to the timer. It writes 0 to the control-word for timer 0. This
> does the following:
>
> o Selects timer 0.
> o Latches the timer.
> o Selects
On 26 Oct 2000, Yoann Vandoorselaere wrote:
> Vojtech Pavlik <[EMAIL PROTECTED]> writes:
[Snipped...]
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
o Selects timer 0.
o Latches
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote:
>
> > > On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote:
> > >
> > > > ...
> > > >
> > > > Have you any idea what is the relation between time and this chip
On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote:
> > On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote:
> >
> > > ...
> > >
> > > Have you any idea what is the relation between time and this chip ?
> > >
> > > Also, I'm experiencing the problem for
On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote:
On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote:
...
Have you any idea what is the relation between time and this chip ?
Also, I'm experiencing the problem for several month on my
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote:
On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote:
...
Have you any idea what is the relation between time and this chip ?
Also, I'm
On 26 Oct 2000, Yoann Vandoorselaere wrote:
Vojtech Pavlik [EMAIL PROTECTED] writes:
[Snipped...]
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
o Selects timer 0.
o Latches the
On Thu, Oct 26, 2000 at 12:04:21PM -0400, Richard B. Johnson wrote:
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
o Selects timer 0.
o Latches the timer.
o Selects mode
On Thu, 26 Oct 2000, Vojtech Pavlik wrote:
On Thu, Oct 26, 2000 at 12:04:21PM -0400, Richard B. Johnson wrote:
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
[Snipped...]
Well,
On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote:
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
[Snipped...]
Well, at least on 2.4.0-test9, the above timing
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote:
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
[Snipped...]
On Thu, Oct 26, 2000 at 10:11:54PM +0200, Yoann Vandoorselaere wrote:
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
[Snipped...]
Well, at least on 2.4.0-test9,
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Thu, Oct 26, 2000 at 10:11:54PM +0200, Yoann Vandoorselaere wrote:
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things
to the timer. It writes 0 to the control-word for timer 0. This
does the following:
On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote:
yop, I 've done :
make -j10 World
in the xfree tree and simulateously :
while true; do make dep make clean make bzImage; done
in the kernel tree
Now it'd be nice to verify that the problem also happens when the
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote:
yop, I 've done :
make -j10 World
in the xfree tree and simulateously :
while true; do make dep make clean make bzImage; done
in the kernel tree
Now it'd be
On Thu, Oct 26, 2000 at 11:24:38PM +0200, Yoann Vandoorselaere wrote:
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote:
yop, I 've done :
make -j10 World
in the xfree tree and simulateously :
while true; do
42 matches
Mail list logo
