> I got the one email that said that there was some trouble with the ESS
> 1868 sound driver under FreeBSD-current. Is there an issue with -current
> and newpcm that is causing the 1868 sound driver to not work? Also, I'd
guys, you should realize that the ESS1868 codecs (and friends)
are extrem
I got the one email that said that there was some trouble with the ESS
1868 sound driver under FreeBSD-current. Is there an issue with -current
and newpcm that is causing the 1868 sound driver to not work? Also, I'd
like to know how to compile the newpcm sound driver as a loadable kernel
module,
Very fresh -current always paniced after detecting SCSI devices on
aha0: AHA-1542CF FW Rev. B.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBs
page fault: supervisor, read page not present
Old kernel from Oct 8 works nicely
Sorry can't provide more info about panic, it is remote computer.
--
Andr
At 04:25 PM 11/1/99 -0700, you wrote:
>What's your eeporm problem? I have fixed and committed patches to the
>ep driver where the card wasn't being identified.
I thought I sent you something about this before..
My card IS getting recognized, and seems to be on the appropriate port,
BUT, I think
In <[EMAIL PROTECTED]> Peter Jeremy
<[EMAIL PROTECTED]> wrote:
> On 1999-Nov-03 23:58:00 +1100, [EMAIL PROTECTED] wrote:
>> There are no new CTM-deltas on 'ctm.freebsd.org'
>>at least 22 hours.
>
> The last e-mail delta I have is cvs-cur.5804, which arrived here at
> 0808UTC (about 5 hours
This should bring CDROM-as-root operation almost back to the state it
was at prior to my gutting the i386 autoconf.c. I've left the really
old-and-nasty cdrom drives out of the list of devices that are searched
for automatically; you can either specify the device manually with eg.
set vfs.r
> About the only place which is sacred is the gdb-stubs, please be
> aware that particular isolation requirements apply to that code
> which make it un-smart to rely on library functions. (that is why
> the gdb-stubs even come with their own strlen(3) & strcat(3)
The same applies to ddb and ever
On Wed, 3 Nov 1999 [EMAIL PROTECTED] wrote:
> There are no new CTM-deltas on 'ctm.freebsd.org'
> at least 22 hours.
>
> Is this known problem ?
I've been waiting 41 hours now for cvs-cur.5804.gz.
Also, ftp.freebsd.org has been hard to reach since freebsdcon (it usually
refuses to c
On 1999-Nov-03 23:58:00 +1100, [EMAIL PROTECTED] wrote:
> There are no new CTM-deltas on 'ctm.freebsd.org'
>at least 22 hours.
The last e-mail delta I have is cvs-cur.5804, which arrived here at
0808UTC (about 5 hours before your message). I would have expected to
receive 5805 (or at least
Say is there anyone that can add signal delivery to the /sys/dev/fb/vga.c?
(For now any quick hack to the driver for delivering the signal will do )
The context is from a posting to the xfree86 mailing list:
[EMAIL PROTECTED] said:
> You need to fit one event in per retrace. If you knew
>
Forget for now, pls, about my earlier message. Found some discussion
about this (I hope) in cvs-all.
Thx.
Marc Schneiders
[EMAIL PROTECTED]
[EMAIL PROTECTED]
propro 10:55pm up 7 days, 16:36, load average: 0.70 0.27 0.18
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "un
To save on bandwidth and the ridiculous phone charges I pay, I would
like to make release to install on another machine, as I am afraid
installing 3.1 (of which I have the CD) and updating from the
/usr/obj on my main machine (which I did before) might not work with
recent changes in current.
Cv
On Tue, Nov 02, 1999 at 09:22:50PM -0700, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Jesper Skriver writes:
> : sysinstall can assign a ip address via. DHCP, but the machine cannot be
> : ping'ed from other hosts on the lan, same if I manually configure ep0
> : via ifconfig.
>
> This sou
[This is heading more towards -arch than -current]
On 1999-Nov-03 21:53:07 +1100, Richard Wackerbarth wrote:
>> How much of the probe code can we move into userland?
>Or alternately, transient kernel memory. Use it, then lose it.
IMHO, there are some items (like the PNP ID tables) that really be
At 11:09 AM -0800 11/3/99, Mike Smith wrote:
>I can either spend more time trying to deal with what I see
>as FUD, or actually do the work, and I'm picking the latter.
>
>[...snip...]. We need to keep ourselves focussed on where we're
>going, and right now, in this context, it means that we need
At 12:17 PM -0700 11/3/99, Nate Williams wrote:
> > BOOTP in
> > the kernel will go _when_there_is_an_acceptable_alternative_.
>
>You've already stated *THERE IS AN ACCEPTABLE ALTERNATIVE*, and it's
>PXE. (I can use all caps instead of underscores to make a point too :)
I thought he was saying t
Ok folks. It's pretty clear that Matt and I have a difference of
opinion here. I can either spend more time trying to deal with what I
see as FUD, or actually do the work, and I'm picking the latter.
Yes, I'm aware of what people are currently doing inre: diskless
booting.
No, I don't plan
> > > I think most if not all the ethernet cards I or my customers
> > > have bought over the last year have sported mighty fine netboot
> > > capabilities.
> >
> > FWIW, few of the cards I've bought over the years sport netboot. And,
> > netboot is an impossibility in 'embedded' systems that us
> > I think most if not all the ethernet cards I or my customers
> > have bought over the last year have sported mighty fine netboot
> > capabilities.
>
> FWIW, few of the cards I've bought over the years sport netboot. And,
> netboot is an impossibility in 'embedded' systems that use things lik
Now that we have grudingly accepted the existence of the ctype macros
(isdigit(3) and friends) along with strto{u}[ql](3) into the kernel,
there are a considerable number of places where they could be used
to make code more readable.
Needless to say you need to *test* your patches before you sen
:> I think most if not all the ethernet cards I or my customers
:> have bought over the last year have sported mighty fine netboot
:> capabilities.
:
:FWIW, few of the cards I've bought over the years sport netboot. And,
:netboot is an impossibility in 'embedded' systems that use things like
:PC
> I think most if not all the ethernet cards I or my customers
> have bought over the last year have sported mighty fine netboot
> capabilities.
FWIW, few of the cards I've bought over the years sport netboot. And,
netboot is an impossibility in 'embedded' systems that use things like
PCMCIA/CAR
:> No, I'm just giving you the reality. Until I can buy *generic*
:> motherboards and/or ethernet cards that actually netboot, what
:> standards a few of them might use is moot.
:
:You can. Go do it. Guess what I'm working on PXE with? Yes, if you
:make a bad buying choice on the
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>:I'm offended, and a little amused. You say "you aren't listening to
>:what I'm saying", yet you have quoted a paragraph in which I say
>:"... it doesn't require any buy-in from motherboard vendors."
>:
>:Are you calling me a liar, or stupi
> :I'm offended, and a little amused. You say "you aren't listening to
> :what I'm saying", yet you have quoted a paragraph in which I say
> :"... it doesn't require any buy-in from motherboard vendors."
> :
> :Are you calling me a liar, or stupid, or are you not reading what I'm
>
> No, I
:>tries to use them directly. PXE sounds cool, but coolness doesn't
:>count unless all the motherboard manufacturers start using it.
:
:Matt,
:
:Please try to do as Mike says, it would save a lot of time and windmills
:if you would check the facts rather than keep arguing your unfounded
:
:I'm offended, and a little amused. You say "you aren't listening to
:what I'm saying", yet you have quoted a paragraph in which I say
:"... it doesn't require any buy-in from motherboard vendors."
:
:Are you calling me a liar, or stupid, or are you not reading what I'm
No, I'm just giving
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>
>:
>:> I think there is only one thing that will ever allow us to remove
>:> the BOOTP code from the kernel, and that is if a time comes when
>:> the BIOSes for all standard off-the-shelf motherboards all have
>:> the ability
> :> I think there is only one thing that will ever allow us to remove
> :> the BOOTP code from the kernel, and that is if a time comes when
> :> the BIOSes for all standard off-the-shelf motherboards all have
> :> the ability to set a boot-from-network option. When/if that ever
>
:
:> I think there is only one thing that will ever allow us to remove
:> the BOOTP code from the kernel, and that is if a time comes when
:> the BIOSes for all standard off-the-shelf motherboards all have
:> the ability to set a boot-from-network option. When/if that ever
:>
There are no new CTM-deltas on 'ctm.freebsd.org'
at least 22 hours.
Is this known problem ?
N.Dudorov
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
$B!y!y!y(B $B%;%i%7!<%s>eN&%-%c%s%Z!<%s(B $B!y!y!y(B
'99$BG/EYA4JF(BNo.1$B%;!<%k%9$r>e$2$F$$$k9q:]FC5v%5%W%j%a%s%H!"(B
$B%;%i%7!<%s(B[CELLASENE]$B$,$$$h$$$h:#7nF|K\$K>eN&$7$^$9!#(B
$B%;%i%7!<%s$Oc32$r5/$3$7$F$$$k$?$a!"(B
$B0lEYH/@8$9$k$HHnBg2=$9$k$3$H$O$"$C$F$b!"(B
$B%@%$%(%C%
This should fix GENERIC and thus also the release builds. Sorry about
the delay in getting this part committed.
> msmith 1999/11/03 03:02:49 PST
>
> Modified files:
> sys/kern vfs_conf.c
> sys/ufs/mfs mfs_vfsops.c
> Log:
> Make MFS work with the new r
On Sat, 2 Oct 1999, William Woods wrote:
> Doing a make world on a DEC Alpha 200 4/233 I get this:
>
> The command that produced this was make -DNOGAMES -j 4 world
>
> /usr/obj/usr/src/tmp/usr/include/ufs/ffs
> install: ufs/ffs/softdep.h: No such file or directory
It looks like you have a brok
34 matches
Mail list logo
