Re: Checking for other kernel modules on load
On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
> 2011/12/28 Kostik Belousov :
> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
> >> 2011/12/28 Kostik Belousov :
> >> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
> >> >> On 28 December 2011 12:21, Daniel O'Connor
> >> >> wrote:
> >> >> >
> >> >> > On 28/12/2011, at 22:07, Chris Rees wrote:
> >> >> >> Is there a simple way to check for existence of a driver? I could
> >> >> >> even check for /dev/sndstat, though that doesn't seem elegant to
> >> >> >> me...
> >> >> >
> >> >> > kldstat -v, but really /dev/sndstat seems simpler and just as
> >> >> > effective.
> >> >> >
> >> >>
> >> >> Cheers-- I was thinking of a kernel-level function though.
> >> >>
> >> >> cognet@ suggested using modfind("sound"), I'll go with that.
> >> > Obvious question is what the panic is. Checking for modules loaded is
> >> > papering over some issue.
> >>
> >> True, although I figured that it was a simple conflict, possibly to do
> >> with sndstat.
> >>
> >> Also, I'm getting panics with the following patch, whether sound is
> >> loaded or not :)
> >>
> >> + if (modfind("sound") >= 0)
> >> + {
> >> + cmn_err (CE_WARN, "A conflicting sound driver is already loaded");
> >> + return EBUSY;
> >> + }
> >> +
> >>
> >> Is there a better way to handle such conflicts?
> >
> > You have missed the point. There is some bug in oss driver that causing
> > the panic. Presumed 'conflict' cannot cause the harm itself, besides not
> > allowing second driver to attach to the same device, and should not result
> > in panic. Trying to implement a half-measure that only covers the problem
> > you do a mis-service.
> >
> > And you still did not provided the panic message.
>
> I'm sorry, you're right. However, your guess was in fact correct;
> make_dev was being called, which returned a null pointer because it
> failed.
>
> The patch at [1] stops the panic, however I was hoping that returning
> EBUSY would abort loading the module... At the moment it loads the
> module, and doesn't create the sndstat dev, which causes weird errors
> with the oss binary commands.
>
> Since this solves the panic and anyone should be able to work out from
> the warning message what the problem is, AND this is a port that
> apparently no-one else uses, should this be sufficient?
>
> BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
> machine, but could once I upgraded it.
On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
So you get absolutely undeterministic behaviour which driver is referenced
by devfs node.
> Chris
>
> [1]
> http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
I highly recommend to return error in case of any make_dev_p(9) failure, and
not only EEXIST.
pgpwW0Pqu6gLw.pgp
Description: PGP signature
Re: Checking for other kernel modules on load
2011/12/29 Kostik Belousov :
> On Thu, Dec 29, 2011 at 12:53:19PM +, Chris Rees wrote:
>> 2011/12/29 Kostik Belousov :
>> > On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
>> >> 2011/12/28 Kostik Belousov :
>> >> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
>> >> >> 2011/12/28 Kostik Belousov :
>> >> >> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
>> >> >> >> On 28 December 2011 12:21, Daniel O'Connor
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > On 28/12/2011, at 22:07, Chris Rees wrote:
>> >> >> >> >> Is there a simple way to check for existence of a driver? I
>> >> >> >> >> could
>> >> >> >> >> even check for /dev/sndstat, though that doesn't seem elegant to
>> >> >> >> >> me...
>> >> >> >> >
>> >> >> >> > kldstat -v, but really /dev/sndstat seems simpler and just as
>> >> >> >> > effective.
>> >> >> >> >
>> >> >> >>
>> >> >> >> Cheers-- I was thinking of a kernel-level function though.
>> >> >> >>
>> >> >> >> cognet@ suggested using modfind("sound"), I'll go with that.
>> >> >> > Obvious question is what the panic is. Checking for modules loaded is
>> >> >> > papering over some issue.
>> >> >>
>> >> >> True, although I figured that it was a simple conflict, possibly to do
>> >> >> with sndstat.
>> >> >>
>> >> >> Also, I'm getting panics with the following patch, whether sound is
>> >> >> loaded or not :)
>> >> >>
>> >> >> + if (modfind("sound") >= 0)
>> >> >> + {
>> >> >> + cmn_err (CE_WARN, "A conflicting sound driver is already
>> >> >> loaded");
>> >> >> + return EBUSY;
>> >> >> + }
>> >> >> +
>> >> >>
>> >> >> Is there a better way to handle such conflicts?
>> >> >
>> >> > You have missed the point. There is some bug in oss driver that causing
>> >> > the panic. Presumed 'conflict' cannot cause the harm itself, besides not
>> >> > allowing second driver to attach to the same device, and should not
>> >> > result
>> >> > in panic. Trying to implement a half-measure that only covers the
>> >> > problem
>> >> > you do a mis-service.
>> >> >
>> >> > And you still did not provided the panic message.
>> >>
>> >> I'm sorry, you're right. However, your guess was in fact correct;
>> >> make_dev was being called, which returned a null pointer because it
>> >> failed.
>> >>
>> >> The patch at [1] stops the panic, however I was hoping that returning
>> >> EBUSY would abort loading the module... At the moment it loads the
>> >> module, and doesn't create the sndstat dev, which causes weird errors
>> >> with the oss binary commands.
>> >>
>> >> Since this solves the panic and anyone should be able to work out from
>> >> the warning message what the problem is, AND this is a port that
>> >> apparently no-one else uses, should this be sufficient?
>> >>
>> >> BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
>> >> machine, but could once I upgraded it.
>> > On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
>> > So you get absolutely undeterministic behaviour which driver is referenced
>> > by devfs node.
>> >
>> >> Chris
>> >>
>> >> [1]
>> >> http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
>> >
>> > I highly recommend to return error in case of any make_dev_p(9) failure,
>> > and
>> > not only EEXIST.
>>
>> That'd be great-- but I can't work out how to do it :(
>>
>> Do I need to return a different value?
>
> error = make_dev_p();
> if (error != 0) {
> printf("Error creating device node /dev/%s: %d\n", name,
> error);
> return (error);
> }
>
No, that's what I wanted. Thank you.
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Checking for other kernel modules on load
2011/12/29 Kostik Belousov :
> On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
>> 2011/12/28 Kostik Belousov :
>> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
>> >> 2011/12/28 Kostik Belousov :
>> >> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
>> >> >> On 28 December 2011 12:21, Daniel O'Connor
>> >> >> wrote:
>> >> >> >
>> >> >> > On 28/12/2011, at 22:07, Chris Rees wrote:
>> >> >> >> Is there a simple way to check for existence of a driver? I could
>> >> >> >> even check for /dev/sndstat, though that doesn't seem elegant to
>> >> >> >> me...
>> >> >> >
>> >> >> > kldstat -v, but really /dev/sndstat seems simpler and just as
>> >> >> > effective.
>> >> >> >
>> >> >>
>> >> >> Cheers-- I was thinking of a kernel-level function though.
>> >> >>
>> >> >> cognet@ suggested using modfind("sound"), I'll go with that.
>> >> > Obvious question is what the panic is. Checking for modules loaded is
>> >> > papering over some issue.
>> >>
>> >> True, although I figured that it was a simple conflict, possibly to do
>> >> with sndstat.
>> >>
>> >> Also, I'm getting panics with the following patch, whether sound is
>> >> loaded or not :)
>> >>
>> >> + if (modfind("sound") >= 0)
>> >> + {
>> >> + cmn_err (CE_WARN, "A conflicting sound driver is already loaded");
>> >> + return EBUSY;
>> >> + }
>> >> +
>> >>
>> >> Is there a better way to handle such conflicts?
>> >
>> > You have missed the point. There is some bug in oss driver that causing
>> > the panic. Presumed 'conflict' cannot cause the harm itself, besides not
>> > allowing second driver to attach to the same device, and should not result
>> > in panic. Trying to implement a half-measure that only covers the problem
>> > you do a mis-service.
>> >
>> > And you still did not provided the panic message.
>>
>> I'm sorry, you're right. However, your guess was in fact correct;
>> make_dev was being called, which returned a null pointer because it
>> failed.
>>
>> The patch at [1] stops the panic, however I was hoping that returning
>> EBUSY would abort loading the module... At the moment it loads the
>> module, and doesn't create the sndstat dev, which causes weird errors
>> with the oss binary commands.
>>
>> Since this solves the panic and anyone should be able to work out from
>> the warning message what the problem is, AND this is a port that
>> apparently no-one else uses, should this be sufficient?
>>
>> BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
>> machine, but could once I upgraded it.
> On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
> So you get absolutely undeterministic behaviour which driver is referenced
> by devfs node.
>
>> Chris
>>
>> [1]
>> http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
>
> I highly recommend to return error in case of any make_dev_p(9) failure, and
> not only EEXIST.
That'd be great-- but I can't work out how to do it :(
Do I need to return a different value?
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Checking for other kernel modules on load
On Thu, Dec 29, 2011 at 12:53:19PM +, Chris Rees wrote:
> 2011/12/29 Kostik Belousov :
> > On Thu, Dec 29, 2011 at 11:46:57AM +, Chris Rees wrote:
> >> 2011/12/28 Kostik Belousov :
> >> > On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
> >> >> 2011/12/28 Kostik Belousov :
> >> >> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
> >> >> >> On 28 December 2011 12:21, Daniel O'Connor
> >> >> >> wrote:
> >> >> >> >
> >> >> >> > On 28/12/2011, at 22:07, Chris Rees wrote:
> >> >> >> >> Is there a simple way to check for existence of a driver? I could
> >> >> >> >> even check for /dev/sndstat, though that doesn't seem elegant to
> >> >> >> >> me...
> >> >> >> >
> >> >> >> > kldstat -v, but really /dev/sndstat seems simpler and just as
> >> >> >> > effective.
> >> >> >> >
> >> >> >>
> >> >> >> Cheers-- I was thinking of a kernel-level function though.
> >> >> >>
> >> >> >> cognet@ suggested using modfind("sound"), I'll go with that.
> >> >> > Obvious question is what the panic is. Checking for modules loaded is
> >> >> > papering over some issue.
> >> >>
> >> >> True, although I figured that it was a simple conflict, possibly to do
> >> >> with sndstat.
> >> >>
> >> >> Also, I'm getting panics with the following patch, whether sound is
> >> >> loaded or not :)
> >> >>
> >> >> + if (modfind("sound") >= 0)
> >> >> + {
> >> >> + cmn_err (CE_WARN, "A conflicting sound driver is already
> >> >> loaded");
> >> >> + return EBUSY;
> >> >> + }
> >> >> +
> >> >>
> >> >> Is there a better way to handle such conflicts?
> >> >
> >> > You have missed the point. There is some bug in oss driver that causing
> >> > the panic. Presumed 'conflict' cannot cause the harm itself, besides not
> >> > allowing second driver to attach to the same device, and should not
> >> > result
> >> > in panic. Trying to implement a half-measure that only covers the problem
> >> > you do a mis-service.
> >> >
> >> > And you still did not provided the panic message.
> >>
> >> I'm sorry, you're right. However, your guess was in fact correct;
> >> make_dev was being called, which returned a null pointer because it
> >> failed.
> >>
> >> The patch at [1] stops the panic, however I was hoping that returning
> >> EBUSY would abort loading the module... At the moment it loads the
> >> module, and doesn't create the sndstat dev, which causes weird errors
> >> with the oss binary commands.
> >>
> >> Since this solves the panic and anyone should be able to work out from
> >> the warning message what the problem is, AND this is a port that
> >> apparently no-one else uses, should this be sufficient?
> >>
> >> BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
> >> machine, but could once I upgraded it.
> > On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR.
> > So you get absolutely undeterministic behaviour which driver is referenced
> > by devfs node.
> >
> >> Chris
> >>
> >> [1]
> >> http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
> >
> > I highly recommend to return error in case of any make_dev_p(9) failure, and
> > not only EEXIST.
>
> That'd be great-- but I can't work out how to do it :(
>
> Do I need to return a different value?
error = make_dev_p();
if (error != 0) {
printf("Error creating device node /dev/%s: %d\n", name, error);
return (error);
}
Or I do not understand your question.
pgpv6Kv0D7MoL.pgp
Description: PGP signature
Re: Checking for other kernel modules on load
2011/12/28 Kostik Belousov :
> On Wed, Dec 28, 2011 at 02:53:42PM +, Chris Rees wrote:
>> 2011/12/28 Kostik Belousov :
>> > On Wed, Dec 28, 2011 at 12:23:58PM +, Chris Rees wrote:
>> >> On 28 December 2011 12:21, Daniel O'Connor wrote:
>> >> >
>> >> > On 28/12/2011, at 22:07, Chris Rees wrote:
>> >> >> Is there a simple way to check for existence of a driver? I could
>> >> >> even check for /dev/sndstat, though that doesn't seem elegant to me...
>> >> >
>> >> > kldstat -v, but really /dev/sndstat seems simpler and just as effective.
>> >> >
>> >>
>> >> Cheers-- I was thinking of a kernel-level function though.
>> >>
>> >> cognet@ suggested using modfind("sound"), I'll go with that.
>> > Obvious question is what the panic is. Checking for modules loaded is
>> > papering over some issue.
>>
>> True, although I figured that it was a simple conflict, possibly to do
>> with sndstat.
>>
>> Also, I'm getting panics with the following patch, whether sound is
>> loaded or not :)
>>
>> + if (modfind("sound") >= 0)
>> + {
>> + cmn_err (CE_WARN, "A conflicting sound driver is already loaded");
>> + return EBUSY;
>> + }
>> +
>>
>> Is there a better way to handle such conflicts?
>
> You have missed the point. There is some bug in oss driver that causing
> the panic. Presumed 'conflict' cannot cause the harm itself, besides not
> allowing second driver to attach to the same device, and should not result
> in panic. Trying to implement a half-measure that only covers the problem
> you do a mis-service.
>
> And you still did not provided the panic message.
I'm sorry, you're right. However, your guess was in fact correct;
make_dev was being called, which returned a null pointer because it
failed.
The patch at [1] stops the panic, however I was hoping that returning
EBUSY would abort loading the module... At the moment it loads the
module, and doesn't create the sndstat dev, which causes weird errors
with the oss binary commands.
Since this solves the panic and anyone should be able to work out from
the warning message what the problem is, AND this is a port that
apparently no-one else uses, should this be sufficient?
BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev
machine, but could once I upgraded it.
Chris
[1]
http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os_freebsd.c
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables
On 28 December 2011 05:26, Devin Teske wrote: > D'Oh! Attached wrong (OLD; already applied) patch. > > Please find appropriate patch attached! Hi. I committed your patch to head as svn r228985. Thank you! > >> -Original Message- >> From: Devin Teske [mailto:devin.te...@fisglobal.com] >> Sent: Tuesday, December 27, 2011 5:24 PM >> To: 'freebsd-hackers@freebsd.org' >> Cc: Garrett Cooper; devin.te...@fisglobal.com >> Subject: [PATCH] Fix kenv(1) output in w/respect to new boot loader variables >> >> Garrett Cooper and a few others have requested that I write a patch to fix a >> regression w/respect to kenv(1) output in FreeBSD-9.0 and HEAD. >> >> The issue is with the new boot loader menu. It adds many loader variables >> including ones that contain ANSI color escapes. >> >> Obviously, these ANSI codes don't play well with serial consoles when kenv(1) > is >> executed without arguments (reports vary as to what happens, but it's never >> pretty). >> >> Attached is a patch to the Forth code that clears-out the menu-associated >> variables before invoking the kernel. >> >> The net-effect is that kenv(1) no longer reports menu-related variables. >> >> In essence, kenv(1) output should now appear the same as on RELENG_8 (which >> lacks the new boot loader and didn't use any such variables). Thus, restoring >> serial console glory. >> -- >> Devin > > _ > The information contained in this message is proprietary and/or confidential. > If you are not the intended recipient, please: (i) delete the message and all > copies; (ii) do not disclose, distribute or use the message in any manner; > and (iii) notify the sender immediately. In addition, please be aware that > any message addressed to our domain is subject to archiving and review by > persons other than the intended recipient. Thank you. Great! -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
