I am not subscribed to the list please cc me on replies.
I have seen a number of reports of complete lockup of systems. I have been
experiencing them almost since I decided to switch over to an all reiserfs
system - and had installed linux 2.4.5-ac22 since it supposidly contained a
patch
I am not subscribed to the list please cc me on replies.
I have seen a number of reports of complete lockup of systems. I have been
experiencing them almost since I decided to switch over to an all reiserfs
system - and had installed linux 2.4.5-ac22 since it supposidly contained a
patch
I am not subscribed to the list, but I scan the archives and saw the
following. Please cc e-mail me in followups.
>Rob Landley ([EMAIL PROTECTED]) wrote
...
>In late '79 early '80, they heard the rumors that IBM was pondering a PC,
> and Paul Allen went "any real computer will run Unix", so
I am not subscribed to the list, but I scan the archives and saw the
following. Please cc e-mail me in followups.
Rob Landley ([EMAIL PROTECTED]) wrote
...
In late '79 early '80, they heard the rumors that IBM was pondering a PC,
and Paul Allen went any real computer will run Unix, so they
On Sun, 04 Feb 2001 10:31:35 -0500, you wrote:
>Technical explanations aside, some sort of clock drift exists in all
>computers. My experience with Sun hardware, for instance, was that the
>hardware and software clocks rarely agreed.
>
>You should set up your machines to use some sort of time
On Sun, 04 Feb 2001 10:31:35 -0500, you wrote:
Technical explanations aside, some sort of clock drift exists in all
computers. My experience with Sun hardware, for instance, was that the
hardware and software clocks rarely agreed.
You should set up your machines to use some sort of time
On Thu, 1 Feb 2001 19:06:53 +0100, Vojtech Pavlik wrote:
>On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
>
>> Yeah, by bios does the same thing too on the Abit KT7(a).
>
>Ok, I'll remember this. This is most likely the cause of the problems
>many people had with the KT7 in the
As I was building 2.4.1 afresh I took the opportunity to build some of
the device drivers as modules. In particular I have a SCSI cdrom
device (it actually is a cd writer) and I had made that and its
controller (Adaptec AIC-7xxx driver) modules.
However, during boot they fail to load because at
I accidentally built my 2.4.1 kernel with /devfs so had a interesting
few minutes looking round it to see what it was doing.
The thing that struck me most was the spelling of disc with a 'c'. As
an Englishman this is the correct spelling for me most of the time,
but I have come to accept "as a
I accidentally built my 2.4.1 kernel with /devfs so had a interesting
few minutes looking round it to see what it was doing.
The thing that struck me most was the spelling of disc with a 'c'. As
an Englishman this is the correct spelling for me most of the time,
but I have come to accept "as a
As I was building 2.4.1 afresh I took the opportunity to build some of
the device drivers as modules. In particular I have a SCSI cdrom
device (it actually is a cd writer) and I had made that and its
controller (Adaptec AIC-7xxx driver) modules.
However, during boot they fail to load because at
I'm probably doing something silly, but I have just tried to rebuild
the 2.4.0 kernel. I changed a few config things and did
make dep clean bzlilo modules modules_install
and the following appeared. I did a brief look around for the
declaration of skb_datarefp but couldn't find it.
I'm probably doing something silly, but I have just tried to rebuild
the 2.4.0 kernel. I changed a few config things and did
make dep clean bzlilo modules modules_install
and the following appeared. I did a brief look around for the
declaration of skb_datarefp but couldn't find it.
On Sat, 20 Jan 2001 20:18:34 -0500 (EST), you wrote:
>that's not the topic: Andre's talking about pci-clock-based timing
>constants the the driver programs into the ide controller - a matter
>of an extra few/more nanoseconds.
I know, but when looking hard for a problem in one place and not
On Sat, 20 Jan 2001 20:18:34 -0500 (EST), you wrote:
that's not the topic: Andre's talking about pci-clock-based timing
constants the the driver programs into the ide controller - a matter
of an extra few/more nanoseconds.
I know, but when looking hard for a problem in one place and not
On Sat, 20 Jan 2001 14:57:07 -0800 (PST), Andre Hedrick wrote:
...
>
>Vojtech, I worry that the dynamic timing that you are calculating could
>bite you. Timings are exact especially at modes 3/4/5 the margins go to
>an effective zero for varition or wiggle room. The state diagrams from
On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote:
>On Sat, 20 Jan 2001, Alan Chandler wrote:
>
>> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM
>> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only
>> do UDMA mode 2. I am not
on Fri Jan 19 2001 - 10:56:10 EST Vojtech Pavlik ([EMAIL PROTECTED])
wrote
> ...
>I'm sending you (and others who might be interested) my latest VIA and
>IDE drivers. The VIA driver (v3.15) should have a complete support for
>UDMA100 on the vt82c686b chip, the AMD driver (v1.5) should have full
on Fri Jan 19 2001 - 10:56:10 EST Vojtech Pavlik ([EMAIL PROTECTED])
wrote
...
I'm sending you (and others who might be interested) my latest VIA and
IDE drivers. The VIA driver (v3.15) should have a complete support for
UDMA100 on the vt82c686b chip, the AMD driver (v1.5) should have full
On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote:
On Sat, 20 Jan 2001, Alan Chandler wrote:
I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM
deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only
do UDMA mode 2. I am not overclocking or anything - all
On Sat, 20 Jan 2001 14:57:07 -0800 (PST), Andre Hedrick wrote:
...
Vojtech, I worry that the dynamic timing that you are calculating could
bite you. Timings are exact especially at modes 3/4/5 the margins go to
an effective zero for varition or wiggle room. The state diagrams from
Quantum
21 matches
Mail list logo
