On Sun, Sep 26, 1999 at 02:23:18PM -0700, Mike Smith wrote:
> > Can you give me a few hints on what would be necessary to get the old
> > driver to work with the new PnP?
>
> As has already been explained to you (you _do_ read these messages in
> their entirety, right?), the old driver has been
Thanks. That is exactly what I have done. The AWE device cannot
work this way, but everything else is functional if I remove the
PnP controller from my kernel...
On Sun, Sep 26, 1999 at 10:04:38PM +0200, D. Rock wrote:
> "Donald J . Maddox" schrieb:
> > Is the new PnP code really so smart that
On Sun, Sep 26, 1999 at 11:59:33AM -0700, Mike Smith wrote:
> > On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
> > >
> > > PnP is an infrastructure facility used by drivers to detect and
> > > configure hardware. The side-effect you were relying on was that the
> > > old code woul
On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
> >
> > But we do have a working driver for the AWE64. Or rather, it worked fine
> > before the new PnP code was comitted, now it doesn't. It seems to me that
> > this indicates a deficiency in the new PnP code. Isn't that correct?
>
On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
>
> PnP is an infrastructure facility used by drivers to detect and
> configure hardware. The side-effect you were relying on was that the
> old code would indiscriminately configure any and all PnP hardware
> regardless of whether a
Sigh. Again, I didn't demand anything.
I simply pointed out that functionality had been lost. If I
was the author of this code, I would *want* feedback on how
it was working out for people out here in userland. I assume
that the authors in question _do_ want such feedback.
On Sun, Sep 26, 199
On Sun, Sep 26, 1999 at 01:11:55PM -0400, Gary Palmer wrote:
> "Donald J . Maddox" wrote in message ID
> <[EMAIL PROTECTED]>:
> > I'm just suggesting here that it would be nice if the authors of
> > this code would make it _equally functional_ to what was removed.
> > It's not nice to remove funct
On Sun, Sep 26, 1999 at 10:51:59AM -0700, Mike Smith wrote:
> > Sigh. Again, I didn't demand anything.
> >
> > I simply pointed out that functionality had been lost. If I
> > was the author of this code, I would *want* feedback on how
> > it was working out for people out here in userland. I a
The whole point is that I want to be able to use the wavetable
synthesis features of the card. Newpcm (or oldpcm, for that matter)
provides NO support for the AWE device whatsoever, as you can see
from your dmesg below.
It makes little sense to me that PnP functionality should be tied
down to a
The new PnP code just plain does not work for my PnP AWE64.
If I configure like this:
controller pnp0
controller snd0
device sb0
device sbxvi0
device sbmidi0
device awe0
device opl0
device joy0
Which is the way it *should* work, in
AIL PROTECTED],
Ollivier Robert <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: Loss of Functionality with newpnp
>
> Warner Losh wrote:
> >
> > In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
> > : Let me chime in here.
> > Justin has said that porting old scsi aic to cam wouldn't be too hard,
> > but would still provide a level of buginess that is too high..
> > Otherwise, i'd have done that a long time ago...
>
> I don't know, I have never used the aic driver before. It would seem
> that aic users were not tha
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
: I don't know, I have never used the aic driver before. It would seem
: that aic users were not that unhappy with the driver.
I tried getting it to work on 5 different occasions on one of 8
different cards. 0 for 8. I didn't try the pcmc
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
> : Let me chime in here. We *DO* care about ancient AIC drivers as long
> : as no PCMCIA alternative exists.
>
> Justin has said that porting old scsi aic to cam wouldn't be too hard,
> but would still provide a le
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
: Let me chime in here. We *DO* care about ancient AIC drivers as long
: as no PCMCIA alternative exists.
Justin has said that porting old scsi aic to cam wouldn't be too hard,
but would still provide a level of buginess that is too high..
"Rodney W. Grimes" wrote:
>
> I also know that we are a lot better off with CAM, and could care less
> that the old ancient AIC drivers are dead, but some how I am also pretty
Let me chime in here. We *DO* care about ancient AIC drivers as long
as no PCMCIA alternative exists.
> sure we won't b
[Reinsertion of original answer by jkh]
> > > That work is underway, and something to understand about -current
> > > is that it doesn't have to actually work at all times during the
> > > interim periods between releases. Now, should 4.0 be on the horizon
> > > and the situation still be one wh
On Mon, 27 Sep 1999, Amancio Hasty wrote:
> > It requires converting the ancient voxware driver to newbus which isn't
> > really feasable.
>
> I am not sure about that ... The irq handling, card registration on the voxware
> is fairly straight forward.
It seems that the awe-specific driver is
> If that was only true. Or should I ask why didn't CAM from -3.3 get
> reverted to the old scsi code before 3.3 was released. I have seen
> no less than 2, and perhaps 3 people try to get cards that did work
> under pre-CAM 3.x working under post-CAM 3.x. I know this is a slippery
> slope, but
> > I'm just suggesting here that it would be nice if the authors of
> > this code would make it _equally functional_ to what was removed.
> > It's not nice to remove functionality unconditionally and then
> > provide no replacement at all...
>
> That work is underway, and something to understand
> I'm just suggesting here that it would be nice if the authors of
> this code would make it _equally functional_ to what was removed.
> It's not nice to remove functionality unconditionally and then
> provide no replacement at all...
That work is underway, and something to understand about -curr
> It requires converting the ancient voxware driver to newbus which isn't
> really feasable.
I am not sure about that ... The irq handling, card registration on the voxware
is fairly straight forward.
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Sun, 26 Sep 1999, Donald J . Maddox wrote:
> On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
> > >
> > > But we do have a working driver for the AWE64. Or rather, it worked fine
> > > before the new PnP code was comitted, now it doesn't. It seems to me that
> > > this indicates
Mike Smith wrote in list.freebsd-current:
> > Can you give me a few hints on what would be necessary to get the old
> > driver to work with the new PnP?
>
> As has already been explained to you (you _do_ read these messages in
> their entirety, right?), the old driver has been obsoleted. Y
> On Sun, 26 Sep 1999, Mike Smith wrote:
>
> > > This is only partially related, but I still can't even boot a kernel with
> > > the pnp0 controller enabled. It just hangs after probing the soundcard.
> >
> > You seem to have accidentally deleted all of the details related to
> > this bug repor
Well said.
On Sun, 26 Sep 1999, Donald J . Maddox wrote:
> On a more personal note - What *is* your problem, anyway? If you
> don't have anything useful to contribute to the conversation, why
> reply at all? Peter answered all my questions, and provided lots of
> useful information in a single
On Sun, 26 Sep 1999, Mike Smith wrote:
> > This is only partially related, but I still can't even boot a kernel with
> > the pnp0 controller enabled. It just hangs after probing the soundcard.
>
> You seem to have accidentally deleted all of the details related to
> this bug report from your em
On Sun, 26 Sep 1999, Donald J . Maddox wrote:
> I just reviewed this thread in it's entirety. No one has said, up to
> this point, that the AWE driver was obsoleted, but rather that it was
> broken with respect to PnP. It appears that my ability to read remains
> intact.
Ah, but if you had don
On Sun, Sep 26, 1999 at 02:23:18PM -0700, Mike Smith wrote:
> > Can you give me a few hints on what would be necessary to get the old
> > driver to work with the new PnP?
>
> As has already been explained to you (you _do_ read these messages in
> their entirety, right?), the old driver has been
> On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
> > >
> > > But we do have a working driver for the AWE64. Or rather, it worked fine
> > > before the new PnP code was comitted, now it doesn't. It seems to me that
> > > this indicates a deficiency in the new PnP code. Isn't that c
>From the keyboard of Kenneth Wayne Culver:
> This is only partially related, but I still can't even boot a kernel with
> the pnp0 controller enabled. It just hangs after probing the soundcard.
Same here for a week or two in which dfr was very helpful to try to find
out what happened.
With new
>From the keyboard of Mike Smith:
> I don't think an explanation of how PnP works or how it fits into our
> device architecture is feasible at this point, so I'm going to
> encourage you to do some research of your own.
An explanation of how PnP works is not necessary, some good books and
pap
"Donald J . Maddox" wrote:
> Thanks. That is exactly what I have done. The AWE device cannot
> work this way, but everything else is functional if I remove the
> PnP controller from my kernel...
Do not count on this working for long. The PNP probe code is integral to
the isa bus now and it's j
Thanks. That is exactly what I have done. The AWE device cannot
work this way, but everything else is functional if I remove the
PnP controller from my kernel...
On Sun, Sep 26, 1999 at 10:04:38PM +0200, D. Rock wrote:
> "Donald J . Maddox" schrieb:
> > Is the new PnP code really so smart that
On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
> >
> > But we do have a working driver for the AWE64. Or rather, it worked fine
> > before the new PnP code was comitted, now it doesn't. It seems to me that
> > this indicates a deficiency in the new PnP code. Isn't that correct?
>
"Donald J . Maddox" schrieb:
> Is the new PnP code really so smart that it has no use for user intervention
> ever? My experience indicates that it is not.
>
> It would be very nice if the architects of the new PnP code would add back
> this lost functionality.
My (Q&D) solution for this problem
> This is only partially related, but I still can't even boot a kernel with
> the pnp0 controller enabled. It just hangs after probing the soundcard.
You seem to have accidentally deleted all of the details related to
this bug report from your email before sending it. Please try again.
--
\\
> On Sun, Sep 26, 1999 at 11:59:33AM -0700, Mike Smith wrote:
> > > On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
> > > >
> > > > PnP is an infrastructure facility used by drivers to detect and
> > > > configure hardware. The side-effect you were relying on was that the
> > > > o
This is only partially related, but I still can't even boot a kernel with
the pnp0 controller enabled. It just hangs after probing the soundcard.
On Sun, 26 Sep 1999, Mike Smith wrote:
> > Sigh. Again, I didn't demand anything.
> >
> > I simply pointed out that functionality had been lost. If
On Sun, Sep 26, 1999 at 11:59:33AM -0700, Mike Smith wrote:
> > On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
> > >
> > > PnP is an infrastructure facility used by drivers to detect and
> > > configure hardware. The side-effect you were relying on was that the
> > > old code woul
> On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
> >
> > PnP is an infrastructure facility used by drivers to detect and
> > configure hardware. The side-effect you were relying on was that the
> > old code would indiscriminately configure any and all PnP hardware
> > regardless
On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
>
> PnP is an infrastructure facility used by drivers to detect and
> configure hardware. The side-effect you were relying on was that the
> old code would indiscriminately configure any and all PnP hardware
> regardless of whether a
> On Sun, Sep 26, 1999 at 10:51:59AM -0700, Mike Smith wrote:
> > > Sigh. Again, I didn't demand anything.
> > >
> > > I simply pointed out that functionality had been lost. If I
> > > was the author of this code, I would *want* feedback on how
> > > it was working out for people out here in us
On Sun, Sep 26, 1999 at 10:51:59AM -0700, Mike Smith wrote:
> > Sigh. Again, I didn't demand anything.
> >
> > I simply pointed out that functionality had been lost. If I
> > was the author of this code, I would *want* feedback on how
> > it was working out for people out here in userland. I a
> Sigh. Again, I didn't demand anything.
>
> I simply pointed out that functionality had been lost. If I
> was the author of this code, I would *want* feedback on how
> it was working out for people out here in userland. I assume
> that the authors in question _do_ want such feedback.
Actuall
Sigh. Again, I didn't demand anything.
I simply pointed out that functionality had been lost. If I
was the author of this code, I would *want* feedback on how
it was working out for people out here in userland. I assume
that the authors in question _do_ want such feedback.
On Sun, Sep 26, 199
"Donald J . Maddox" wrote in message ID
<[EMAIL PROTECTED]>:
> Ummm... I'm not screaming anything, Gary. The intent of my message is
> just to let the authors of this code know that it is *not* equal in
> functionality to what was removed. As I said in my original message, it
> would be nice to
On Sun, Sep 26, 1999 at 01:11:55PM -0400, Gary Palmer wrote:
> "Donald J . Maddox" wrote in message ID
> <[EMAIL PROTECTED]>:
> > I'm just suggesting here that it would be nice if the authors of
> > this code would make it _equally functional_ to what was removed.
> > It's not nice to remove funct
"Donald J . Maddox" wrote in message ID
<[EMAIL PROTECTED]>:
> I'm just suggesting here that it would be nice if the authors of
> this code would make it _equally functional_ to what was removed.
> It's not nice to remove functionality unconditionally and then
> provide no replacement at all...
I
The whole point is that I want to be able to use the wavetable
synthesis features of the card. Newpcm (or oldpcm, for that matter)
provides NO support for the AWE device whatsoever, as you can see
from your dmesg below.
It makes little sense to me that PnP functionality should be tied
down to a
According to Donald J . Maddox:
> I get the same failures as above from the PnP code, but the card still
> works (mostly) because it has already been configured by the PnP BIOS.
> The SB16-compatible portion of the card works OK even if I take PnP
> support out of the kernel completely, and always
The new PnP code just plain does not work for my PnP AWE64.
If I configure like this:
controller pnp0
controller snd0
device sb0
device sbxvi0
device sbmidi0
device awe0
device opl0
device joy0
Which is the way it *should* work, in
52 matches
Mail list logo
