"Brandon D. Valentine" wrote:
> do intend to work on this. At the moment I sit daily in front of an SGI
> Indigo2 running IRIX because it's better than Linux and integrates quite
> well with our environment. I really want a FreeBSD workstation on my
> desk, so I'll likely end up writing the patc
Mike Smith wrote:
> This just isn't going to work. The _CRS data stream stops at byte 0x17,
> and these extra items are simply mis-aimed.
>
> The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
> this is a BIOS bug, and should be reported to the vendor. (It should
> also hav
Hi Warner,
I hope you can point me in the right direction or directly
answer the question I have. I'm an active -CURRENT user and
have aquired a Compaq WL100 wireless nic which does not work
with the 'NEWCARD' options defined. In order to get my 3Com
card to work, I need these options since thi
Hello!
After upgrade to 3.5 to 4.3-stable we encoutered a problem
with our custom device connected to com-port. The device
accepts command strings and returns strings in response,
but under 4.3 it strangely does not respond to commands
that are longer than 15 bytes ( 16 with \r).
The device is
I tried to install current snapshot as of October 2, 2001 from
current.jp.FreeBSD.org, but it seems to fail at
sysinstall.c:installFilesystems().
The function installFilesystems() calls MakeDevChunk() of
lib/libdisk/create_chunk.c, which then calls mknod(2) via
MakeDev(). The error message I see
While Openoffice for BSD is still milestones away from compiling,
I tried to port the linux version of SO6.0 beta to FreeBSD.
I got it extracted, and could run setup.bin, which fails miserably:
> 79358 setup.bin RET read 4096/0x1000
> 79358 setup.bin CALL linux_mmap(0xbfbfcfac)
> 79358 se
On Tue, Oct 02, 2001 at 09:23:50PM +0200, Riccardo Torrini wrote:
> Different behaviour from 4.4 to 5.0 of host command. Why?
> Yes, I got finally delegation for reverse (with RFC 2317).
> Yes, my -CURRENT is really old, but I'm reading this list... ;)
That's your problem.
You see that this has
> You lose. Until someone writes a fallback for machines that don't
> have the BIOS32 entry point for PCIBIOS, you are stuck.
>
> Warner
No I don't. I knew I will get bitten by putting my comments at the end
of the long message, but I did it nonetheless :(. Anyway, here is shorter
and hopefully
On 03-Oct-2001 (14:14:57/GMT) Bernd Walter wrote:
>> Yes, my -CURRENT is really old, but I'm reading this list... ;)
> That's your problem.
Pilot error :-( Ok, sorry for that.
> You see that this has been fixed at least since a month:
> ticso@cicely9> uname -v
> FreeBSD 5.0-CURRENT #1: Tue
> All these "solutions" assume that everyone is wired up with IP
> connectivity. The original questions was "who uses UUCP?"
Correct.
> One answer is: "those without IP connectivity."
Do you mean 'full-time IP connectivity', because if you can setup a UUCP
connection, you can just as easily set
As you've already noticed, sysinstall basically tries to create the
device nodes it needs under the old assumption that /dev will be
mostly empty. Now that devfs is the default, phk needs to update
libdisk so that it doesn't attempt to make the device nodes in this
way. Fortunately, the person w
* Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:33] wrote:
> As you've already noticed, sysinstall basically tries to create the
> device nodes it needs under the old assumption that /dev will be
> mostly empty. Now that devfs is the default, phk needs to update
> libdisk so that it doesn't attem
sysinstall, by design, knows very little about devices. It uses
libdisk(3) as the abstraction for dealing with all disks in
particular.
> * Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:33] wrote:
> > As you've already noticed, sysinstall basically tries to create the
> > device nodes it needs u
> > * Jordan Hubbard <[EMAIL PROTECTED]> [011003 15:33] wrote:
> > > As you've already noticed, sysinstall basically tries to create the
> > > device nodes it needs under the old assumption that /dev will be
> > > mostly empty. Now that devfs is the default, phk needs to update
> > > libdisk so t
Well, since I don't own libdisk(3) and had no idea why you'd be
addressing this to me unless you were still confused, I presumed you
were confused. In any case, you need to be talking to phk about this.
- Jordan
From: Alfred Perlstein <[EMAIL PROTECTED]>
Subject: Re: current install failure
Dat
On Wed, Oct 03, 2001 at 03:58:06PM +0200, Martin Blapp wrote:
>
> > 79358 setup.bin RET close 0
> > 79358 setup.bin PSIG SIGSEGV SIG_DFL
> > 79358 setup.bin NAMI "setup.bin.core"
>
>
> BTW: This is CURRENT from today with a "old" linux base installed.
What if you try it with linux_base-
Andrew Gallatin wrote:
>
> Thyer, Matthew writes:
> >
> > Now xterm 1 has the message "yp_first: clnt_call: RPC: Timed out"
> > as its first line and xterm 2 has two of these messages.
> The problem is that there is no global caching of NIS maps. Each app
> maintains its own cache..
Since t
At 1:52 AM +0900 10/3/01, Hajimu UMEMOTO wrote:
> > On Tue, 2 Oct 2001 12:30:33 -0400
> > Garance A Drosihn <[EMAIL PROTECTED]> said:
>drosih> The print queue for 'lp' on oink refers to a remote machine that
>drosih> is named neutron. That hostname maps to an IPv6 address. Thus,
>drosi
Kris Kennaway wrote:
> On Wed, Oct 03, 2001 at 01:56:11PM -0500, Jim Bryant wrote:
>
>>This may sounds strange, but as I don't actually recall seeing any actual changes to
>burncd unless i missed something in my cvsup
>>early this morning CDT...
>>
>>I just decided to give it another try befor
Thyer, Matthew writes:
>
> Now xterm 1 has the message "yp_first: clnt_call: RPC: Timed out"
> as its first line and xterm 2 has two of these messages.
What's really fun is when you've got a rack or two of machines which
are NIS clients and their switch blows out overnight. As soon as they
Kazutaka YOKOTA wrote:
>
> Is there any way for the loadable module to detect if
> the kernel is configured for SMP or UP?
There is a global variable, "ncpu". Its name may have changed
recently, so you will want to look at the SYSCTL() stuff in
/sys/i386/i386 to be sure.
-- Terry
To Unsubscri
All these "solutions" assume that everyone is wired up with IP
connectivity. The original questions was "who uses UUCP?"
One answer is: "those without IP connectivity." Part of the problem
here I suspect is that the people who develop and maintain FreeBSD
live a life where a T-3 into your living
sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440
/R/stage/image.kern 8 fd1440
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 6.
Warning: 1216 sector(s) in last cylinder unallocated
/dev/
Nate Williams wrote:
> > POP and IMAP (I think) will lose all the envelope information,
>
> You've been listening to Terry too long. It's certainly not the case,
> although I've decided to quit arguing with Terry, since it's an
> excercise in futility. No matter what you say, he'll either chang
> > > POP and IMAP (I think) will lose all the envelope information,
> >
> > You've been listening to Terry too long. It's certainly not the case,
> > although I've decided to quit arguing with Terry, since it's an
> > excercise in futility. No matter what you say, he'll either change the
> > s
This may sounds strange, but as I don't actually recall seeing any actual changes to
burncd unless i missed something in my cvsup
early this morning CDT...
I just decided to give it another try before booting into the kernel built this
morning, and it seems that it was a "world" issue,
and no
D'ya think it might be time for a 3rd floppy?
On Wed, 3 Oct 2001, Jordan Hubbard wrote:
> sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt
>1440 /R/stage/image.kern 8 fd1440
> disklabel: ioctl DIOCWLABEL: Operation not supported by device
> Warning: Block
Julian Elischer wrote:
> > See above. fetchmail + pop works fine. I've been get all of my envelope
> > information, and there is no worries.
>
> This has noty been the case where I have seen..
>
> This requires that you have a mailbox set up on the server which can
> 'encode' all of the envel
> Interestingly, Microsoft Exchange is one of the few commercial
> SMTP servers that can handle more than a few hundred ETRN based
> virtual domain instances. Go figure...
Any Q-Mail based solution using the commonly available ETRN patch also
scales well, although you have to 'roll your own' rel
< said:
> I was wondering if anyone had thought of implementing the above ioctl. Right
> now from what I can tell, (from wmnet, and netstat) all stats for a network
> device are kvm_read out of the kernel.
These applications should use sysctl instead. All of the information
is available throu
On Wed, Oct 03, 2001 at 02:34:51PM -0600, Lyndon Nerenberg wrote:
> > Do you mean 'full-time IP connectivity', because if you can setup a UUCP
> > connection, you can just as easily setup a PPP connection over the same
> > medium, giving you IP connectivity.
>
> True, but there's a lot more infra
> Do you mean 'full-time IP connectivity', because if you can setup a UUCP
> connection, you can just as easily setup a PPP connection over the same
> medium, giving you IP connectivity.
True, but there's a lot more infrastructure overhead involved in
setting up a group of disconnected machines v
Sure, I just don't have time to work on this right now.
- jordan
>
> D'ya think it might be time for a 3rd floppy?
>
>
> On Wed, 3 Oct 2001, Jordan Hubbard wrote:
>
> > sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt
>1440 /R/stage/image.kern 8 fd1440
>
On Wed, Oct 03, 2001 at 01:56:11PM -0500, Jim Bryant wrote:
> This may sounds strange, but as I don't actually recall seeing any actual changes to
>burncd unless i missed something in my cvsup
> early this morning CDT...
>
> I just decided to give it another try before booting into the kernel b
On Wed, Oct 03, 2001 at 12:55:08PM -0600, Nate Williams wrote:
> > Tell me, is your mail compliant with the non-disclosure of "Bcc:"
> > recipients requirement? If fetchmail doesn't strip the tunneling
> > headers (it doesn't), then the headers disclose "Bcc:"'ed
> > recipients to anyone who choo
35 matches
Mail list logo
