On Wed, Nov 08, 2000 at 03:11:46AM +0100, [EMAIL PROTECTED] wrote:
I'm sure I must have overseen something trivial, but currently I can't
figure out what it is.
The lower 16 MB memory has been used for
kernel text, data, bss
arrays allocated by vm_page_startup()
I updated my sources using cvsup, and i am unable to make the world : the message i
get is :
=== doc
/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/gperf/doc created for
/usr/src/gnu/usr.bin/gperf/doc
make: don't know how to make bool-array.cc. Stop
*** Error code 2
Stop in /usr/src.
*** Error
Hi!
licq doesn't work since crt* change.. (coredumps) Any workaround?
(recompile if licq qt doesn't help).
/usr/ports/net/licq
Dmitry.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote:
In message [EMAIL PROTECTED] Alfred Perlstein writes:
: Yes, this used to work quite well for some time, I have no idea
: who broke it. Maybe you can sprinkle some printfs in the code and
: narrow it down a bit?
I'll give it a shot.
John Polstra [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Alexander N. Kabaev
[EMAIL PROTECTED] wrote:
Why FreeBSD does not link libgcc into shared libraries by
default? Everyone else is doing that. Linking shared libraries
with libgcc seems to be the ultimate work-around.
I've had been considering running xinted for some time now, and thanks to
Forest's suggestions I've been able to successfully get it up and running
smoothly. I am personnaly left wondering why not just replact inetd altogether
with this version? It certainly enhances security a bit.
Well these
In message [EMAIL PROTECTED] Johan Karlsson writes:
: At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote:
: In message [EMAIL PROTECTED] Alfred Perlstein writes:
: : Yes, this used to work quite well for some time, I have no idea
: : who broke it. Maybe you can sprinkle some printfs in the
The IRQ allocation needs the RF_SHAREABLE flag or it will blow up in
the case where the IRQ is shared with another device.
So the EISA attachment doesn't set RF_SHAREABLE if the system is
using a level sensitive interrupt?
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Wed, 08 Nov 2000 09:30:02 EST, Mikel wrote:
I am personnaly left wondering why not just replact inetd altogether
with this version? It certainly enhances security a bit.
Well these are just thoughts from the peanut gallery.
Too many of those and a mailing list becomes unreadable. :-)
On Wed, Nov 08, 2000 at 07:43:24AM -0700, Warner Losh wrote:
It is a problem that I could have sworn worked before SMPNG.
Negative, this occurs on releng_4 machines for me as well.
It also was occuring on my -current workstation that was about 110 days
old before a disk went out, so it was
On Wed, Nov 08, 2000 at 07:43:24AM -0700, Warner Losh scribbled:
| In message [EMAIL PROTECTED] Johan Karlsson writes:
| : At Tue, 07 Nov 2000 14:54:50 MST, Warner Losh wrote:
| : In message [EMAIL PROTECTED] Alfred Perlstein writes:
| : : Yes, this used to work quite well for some time, I have
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
So the EISA attachment doesn't set RF_SHAREABLE if the system is using
a level sensitive interrupt?
The current EISA code isn't as smart as it should be.
I've got uncommitted code that ties it to the ELCR.
Bus front end code shouldn't have to know
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
So the EISA attachment doesn't set RF_SHAREABLE if the system is using
a level sensitive interrupt?
The current EISA code isn't as smart as it should be.
Speaking of that, I'd like to see the EISA code move to be
more like PCI. We should see if
On Wed, Nov 08, 2000 at 10:18:18AM +0100, urded wrote:
I updated my sources using cvsup, and i am unable to make the world : the message i
get is :
=== doc
/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/gperf/doc created for
/usr/src/gnu/usr.bin/gperf/doc
make: don't know how to make
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: Bus front end code shouldn't have to know about level/edge triggered IRQs.
The cardbus code, for example, will or in the RF_SHAREABLE bit when
appropriate.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
Speaking of that, I'd like to see the EISA code move to be
more like PCI. We should see if there is something at slot
0 and only then attempt to probe for sub-devices on the bus.
Humm... I've got EISA BIOS extension code that correctly returns IDs
On Wed, 8 Nov 2000, Warner Losh wrote:
The cardbus code, for example, will or in the RF_SHAREABLE bit when
appropriate.
Right, but the drivers that are consumers of the PCI or CARDBUS bus
interface shouldn't have to deal with RF_SHAREABLE; the bus driver should
do that. I grant you that this
In message [EMAIL PROTECTED] "Matthew N.
Dodd" writes:
: On Wed, 8 Nov 2000, Warner Losh wrote:
: The cardbus code, for example, will or in the RF_SHAREABLE bit when
: appropriate.
:
: Right, but the drivers that are consumers of the PCI or CARDBUS bus
: interface shouldn't have to deal with
The only reason this isn't done is because I, due to the
fledgling nature of the EISA code and the ahc VL card's
almost looking like EISA cards, did the wrong thing here.
We also need to be verifying that io ranges required to
probe for slots are not already claimed by other devices
before
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
Try ftp://ftp.jurai.net/users/winter/eisabook.zip
I can't seem to fetch it. Permission denied.
Damn firewall. Try with passive mode off.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x
Not really. See my previous mail.
It seems that a SYSV4 Syscall maps to the evil call.
Unless you had the SVR4 module loaded, it would still have been run as a
FreeBSD binary, which would give you exactly the same behaviour.
Is it possible to refuse to run the binary, unless it is
The EISA code currently doesn't reserve resources for empty slots.
I'd like to make the bus driver reserve all EISA specific address space
though.
This would prevent an ISA card that just happens to use an EISA
like identification scheme from attaching after EISA. Unfortunately,
the
On Wed, 8 Nov 2000, Terry Lambert wrote:
Maybe it would be possible to have a separate "VLBus" bus that
went in before the EISA bus?
I'm still not clear as to why we need to differentiate them. There really
is no requirement that slot 0 be present (other than it being standard and
all.)
Can
I'm still not clear as to why we need to differentiate them. There really
is no requirement that slot 0 be present (other than it being standard and
all.)
Can we even tell if which EISA devices are really VL devices in disguise?
The only reason is to return the EISA probe to a read-only probe.
On Wed, 8 Nov 2000, Justin T. Gibbs wrote:
The only reason is to return the EISA probe to a read-only probe. The
ahc VL cards require that their ID0 register be written too prior to
reading the ID byte.
Humm... I had wondered why that was there. Is there a way to detect VLB
devices some
Humm... I had wondered why that was there. Is there a way to detect VLB
devices some other way?
This is specific to the aha2842 and is the only way I know of detecting
those boards.
--
Justin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
On Wed, Nov 08, 2000 at 12:46:43PM +0300, Dmitry Valdov wrote:
licq doesn't work since crt* change.. (coredumps) Any workaround?
(recompile if licq qt doesn't help).
/usr/ports/net/licq
IIRC, the discussion about that found that it wasn't crt*'s fault but
rather a bug in the dynamic linker.
On Wed 2000-11-08 (09:30), Mikel wrote:
I've had been considering running xinted for some time now, and thanks to
Forest's suggestions I've been able to successfully get it up and running
smoothly. I am personnaly left wondering why not just replact inetd altogether
with this version? It
My machines get their source code from a local CVS mirror of the
FreeBSD source tree, which is at /home/cvs/freebsd/src.. we have
our own CVSROOT stuff of course.
So when stuff is checked out of the freebsd/* repostitories, the
$FreeBSD$ tags don't get substituted correctly.
This causes
In article [EMAIL PROTECTED],
Will Andrews [EMAIL PROTECTED] wrote:
On Wed, Nov 08, 2000 at 12:46:43PM +0300, Dmitry Valdov wrote:
licq doesn't work since crt* change.. (coredumps) Any workaround?
(recompile if licq qt doesn't help).
/usr/ports/net/licq
IIRC, the discussion about that
"Matthew N. Dodd" wrote:
On Wed, 8 Nov 2000, Terry Lambert wrote:
Maybe it would be possible to have a separate "VLBus" bus that
went in before the EISA bus?
I'm still not clear as to why we need to differentiate them. There really
is no requirement that slot 0 be present (other than it
On Thu, 9 Nov 2000, Peter Wemm wrote:
Do you want to know what is even funnier? One of my onboard ahc *PCI*
controllers (7895 based I think) also responds to the EISA probes if I
enable EISA.
What machine and what does the output from the probe/attach look like?
--
| Matthew N. Dodd | '78
At 13:37 6-11-00 -0500, drwilco wrote:
Yes I do have PERL_THREADED=true. Or rather I did have it until a minute
ago =)
Building world kernel was succesful without PERL_THREADED. Maybe a
warning should be added to /etc/make.conf?
DocWilco
To Unsubscribe: send mail to [EMAIL
Hello All,
anyone wants to review and commit the following patch.
thanks,
emax
__
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one Place.
http://shopping.yahoo.com/
if_tap.c.diff
I just glanced at it and see no major mistakes.
Sorry I don't have time for a real review.
Poul-Henning
In message [EMAIL PROTECTED], Maksim Yevmenkin
writes:
--0-783368690-973704660=:11219
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello All,
anyone wants to
It seems [Ivan Debn_r] wrote:
I'm just looking at the disk partitions, and the first 63 sectors are by
default marked as unused. So is it really nescessary to have the ofset in
the ar driver for HPT?
I would prefer to have the requirement to not to use dangerously dedicated,
but be able to
Thanks for feedback.
Please tell me if tou find this scenario possible:
I will install on one of the drives - ad0. It will work normally.
Than a few day, weeks, later, when we decide that the ar is fine, go to the
RAID bios, duplicate the disk ad0 to ad1 and RAID1 them.
Other than changing
OK, i tested this. Sysinstall works fine now, and the system installs OK
from the SNAP 5 ftp server. ON reboot, however, the computer thing refuses
to boot of the RAID device. After the BIOS message "verifying
DMI.."(or similar) the system hangs.
Does anybody know why this could be?
jan
On
OK, i tested this. Sysinstall works fine now, and the system installs OK
from the SNAP 5 ftp server. ON reboot, however, the computer thing refuses
to boot of the RAID device. After the BIOS message "verifying
DMI.."(or similar) the system hangs.
Because of the offset 10, sysinstall
I have the same problem on 4, and I have a response from Soren:
--- start ---
Ugh, booting from the HPT RAID is not supported as is. This is due
to the HPT using sector #9 for the RAID config stuff, this is not
compatible with our bootcode/loader as in some circumstances it
would happily
I'm just looking at the disk partitions, and the first 63 sectors are by
default marked as unused. So is it really nescessary to have the ofset in
the ar driver for HPT?
I would prefer to have the requirement to not to use dangerously dedicated,
but be able to boot the drive and install on it as
41 matches
Mail list logo
