"Rodney W. Grimes" <[EMAIL PROTECTED]> wrote:
>Yes please please please. Those of us doing strange stuff with strange
>machines would be eternally greatful if there were device nodes for
>PIC's, PIT's, RTC's and ``other random bits''.
I'll second that.
At one stage, I wrote the code to attach t
On Sun, 5 Sep 1999, Peter Wemm wrote:
> Doug Rabson wrote:
> > On Sat, 4 Sep 1999, Mike Smith wrote:
> >
> > > > > I'm curious what can be made of the PNP resource list we get from the B
> IOS
> > > > > at boot time... It lists motherboard resources too, we could probably
> end
> > > >
Doug Rabson wrote:
> On Sat, 4 Sep 1999, Mike Smith wrote:
>
> > > > I'm curious what can be made of the PNP resource list we get from the B
IOS
> > > > at boot time... It lists motherboard resources too, we could probably
end
> > > > up with a fairly complete map of known resources to
On Sun, 5 Sep 1999, Garrett Wollman wrote:
> < said:
>
> > The enumerator should assign these resources to a placeholder; I was
> > thinking the nexus was as good an owner as any. If there's an
> > "unknown" device that's probably even better.
>
> Some of them should be claimed by real devic
On Sat, 4 Sep 1999, Mike Smith wrote:
> > > I'm curious what can be made of the PNP resource list we get from the BIOS
> > > at boot time... It lists motherboard resources too, we could probably end
> > > up with a fairly complete map of known resources to avoid.
> >
> > I bet we can roll anoth
On Sat, 4 Sep 1999, Chuck Robey wrote:
> Does the sio driver know about PCI? Can it run PCI sio cards, like
> those sold by SIIG?
Not at the moment. I don't know anything about these cards.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd.
> < said:
>
> > The enumerator should assign these resources to a placeholder; I was
> > thinking the nexus was as good an owner as any. If there's an
> > "unknown" device that's probably even better.
>
> Some of them should be claimed by real devices -- for example, the
> pseudo-i8237 ISA DM
> > ummm... I thought that the plan was to disable all PnP devices, do the
> > legacy isa probes, and then reenable the PnP devices and probe them...
>
> The fact that a device is reported via PnP does not guarantee that you
> can disable it. Most of the "devices" reported by the PnP BIOS can
< said:
> The enumerator should assign these resources to a placeholder; I was
> thinking the nexus was as good an owner as any. If there's an
> "unknown" device that's probably even better.
Some of them should be claimed by real devices -- for example, the
pseudo-i8237 ISA DMA controller sho
> > This is one reason why I think that the PnP scan should be done
> > _before_ the legacy scan; there are cases where the legacy scan is
> > going to find stuff that the PnP enumerator also knows about. If the
> > PnP enumerator has already found it, then the legacy scan aborts; in
> > the
Mike Smith scribbled this message on Sep 4:
> > > I'm curious what can be made of the PNP resource list we get from the BIOS
> > > at boot time... It lists motherboard resources too, we could probably end
> > > up with a fairly complete map of known resources to avoid.
> >
> > I bet we can roll
> > I'm curious what can be made of the PNP resource list we get from the BIOS
> > at boot time... It lists motherboard resources too, we could probably end
> > up with a fairly complete map of known resources to avoid.
>
> I bet we can roll another enumerator similar to pnp.c which takes the bi
On Sat, 4 Sep 1999, Doug Rabson wrote:
> On Fri, 3 Sep 1999, Steve Price wrote:
>
> > Can anyone think of a good reason why I can't migrate the
> > old PNP ids to the new sio.c? I just rebooted my box with
> > a fresh kernel and much to my shagrin (sp?) my USR PNP
> > modem didn't work anymore.
On Sun, 5 Sep 1999, Peter Wemm wrote:
> Doug Rabson wrote:
> > On Sat, 4 Sep 1999, John-Mark Gurney wrote:
> >
> > > Doug Rabson scribbled this message on Sep 4:
> > > > > This is of course a special case, a cranky network card and a
> > > > > non-compiling driver for it. If the new pnp code av
Doug Rabson wrote:
> On Sat, 4 Sep 1999, John-Mark Gurney wrote:
>
> > Doug Rabson scribbled this message on Sep 4:
> > > > This is of course a special case, a cranky network card and a
> > > > non-compiling driver for it. If the new pnp code avoids using resource
s
> > > > hard-wired to non
On Sat, 4 Sep 1999, John-Mark Gurney wrote:
> Doug Rabson scribbled this message on Sep 4:
> > > This is of course a special case, a cranky network card and a
> > > non-compiling driver for it. If the new pnp code avoids using resources
> > > hard-wired to non-pnp isa devices (it may, I changed
Doug Rabson scribbled this message on Sep 4:
> > This is of course a special case, a cranky network card and a
> > non-compiling driver for it. If the new pnp code avoids using resources
> > hard-wired to non-pnp isa devices (it may, I changed hardware before the
> > code was fixed), there should
On Sat, 4 Sep 1999, Steve Price wrote:
> On Sat, 4 Sep 1999, Doug Rabson wrote:
>
> # The reason I didn't move the old ids wholesale is that the old system
> # matched against the vendor id (which is bogus for multifunction cards).
> # The new system matches with the logical device id which is o
On Sat, 4 Sep 1999, Doug Rabson wrote:
# The reason I didn't move the old ids wholesale is that the old system
# matched against the vendor id (which is bogus for multifunction cards).
# The new system matches with the logical device id which is often different
# from the vendor id. Some simple s
On Sat, 4 Sep 1999, Zach N. Heilig wrote:
> On Sat, Sep 04, 1999 at 10:21:51AM +0100, Doug Rabson wrote:
> > The pnp command should no longer be needed (crossed fingers) since the new
> > code automatically detects devices and assigns resources to them.
>
> What about the situation where:
>
> p
On Sat, Sep 04, 1999 at 10:21:51AM +0100, Doug Rabson wrote:
> The pnp command should no longer be needed (crossed fingers) since the new
> code automatically detects devices and assigns resources to them.
What about the situation where:
pnp sound card (soundblaster awe64).
non pnp network card
On Fri, 3 Sep 1999, Steve Price wrote:
> Can anyone think of a good reason why I can't migrate the
> old PNP ids to the new sio.c? I just rebooted my box with
> a fresh kernel and much to my shagrin (sp?) my USR PNP
> modem didn't work anymore. The following patch got it
> working again.
The r
Steve Price wrote:
> Now that we can't use the pnp command from 'boot -c', what
> has (if anything) replaced it? I seem to be remember this
> being discussed recently but I'll be darned if I can find
> it in the mailing list archives.
The old pnp code is fundamentally incompatable with the new
Can anyone think of a good reason why I can't migrate the
old PNP ids to the new sio.c? I just rebooted my box with
a fresh kernel and much to my shagrin (sp?) my USR PNP
modem didn't work anymore. The following patch got it
working again.
Index: sio.c
==
24 matches
Mail list logo