What (if any) are the problems with
native FreeBSD ELF Netscape Communicator/Navigator binaries ?
N.Dudorov
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[EMAIL PROTECTED] wrote:
What (if any) are the problems with
native FreeBSD ELF Netscape Communicator/Navigator binaries ?
AFAIK one major problem exist - ELF version is still unavailable.
From
Poul-Henning Kamp wrote:
I still hear reports of sporadic calcru() warnings.
If any of you see these, could you try to see if they correlate
to the uptime of the machine in question ?
Should they start or stop when a machine has been running a while? I see
neither (negative calcru
On 25-Nov-99 [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED] Maxim Sobolev [EMAIL PROTECTED]
wrote:
[EMAIL PROTECTED] wrote:
Sorry, but my question must be - WHY there still is no
ELF version of Netscape Communicator for FreeBSD ?
(FreeBSD's point of view to this problem ?)
Hi,
had the same trouble with yesterdays' build. Try running cvsup again and
it fixed the problem for me.
Regards,
Ilya
-Original Message-
From: Mikhail A. Sokolov [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 25, 1999 18:23
To: [EMAIL PROTECTED]
Subject: tcp (nfs?) troubles.
[EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED] Maxim Sobolev [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
What (if any) are the problems with
native FreeBSD ELF Netscape Communicator/Navigator binaries ?
AFAIK one major problem exist - ELF version is still unavailable.
Okay, I've had a couple of reports so far about the if_dc driver which
were mostly positive. I've also gotten some new hardware and did some
more testing and bug fixing:
- Fixed support for non-MII 10/100 cards based on the 21143 chip. This
includes the DEC DE500-BA and the built-in 21143
On 1999-Nov-26 05:09:20 +1100, Greg Lehey wrote:
I don't suppose it would be that big a deal to remove the old driver,
but what speaks against leaving it in the tree along with a comment in
the GENERIC config file saying "if you use antediluvial disk hardware,
you may prefer to use an old driver
Repeatable mbuf leak leading to crash in current of Saturday 20th
November and all snapshots I've taken prior to that since August (i.e.
when I got the ISDN card).
Hardware is BT Highway (AVM PCI) passive ISDN card.
It's triggered when I call my ISDN number from a PSTN telephone, and use
the
In article [EMAIL PROTECTED] you wrote:
Hi,
I am running 4.0-current of:
FreeBSD gmarco.eclipse.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Nov 18
09:33:43 CET
1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GMARCO i386
But I have now a lot of errors (as you can see in this logs) on my
In article [EMAIL PROTECTED], Gary Jennejohn
[EMAIL PROTECTED] writes
Can you a) increase the size of the message buffer in your config file
(options MSGBUF_SIZE=81920, for example) b) turn on ALL the
trace in the kernel with isdndebug c) cause the panic to happen again
and get a crash
Hi.
When upgrading a box from current ~ 1999-11-15 to ~ today, the 3c509b
network interface fails to work.
These are the kernels (the first one working, the second one not).
/kernel.old:
FreeBSD 4.0-CURRENT #1: Mon Nov 15 00:03:00 CET 1999
/kernel:
FreeBSD 4.0-CURRENT #0: Fri
Don't use the generic kernel unchanged with the 3com card.
Disable the ex0 and ie0 drivers, one of those pummel the 3com
cards magic config registers.
ep0: 3Com EtherLink III (3c509-Combo) at port 0x300-0x30f irq 9 on isa0
ep0: eeprom failed to come ready
...
Ethernet address ff:ff:ff:ff:ff:ff
On Wed, 24 Nov 1999, Poul-Henning Kamp wrote:
I still hear reports of sporadic calcru() warnings.
If any of you see these, could you try to see if they correlate
to the uptime of the machine in question ?
Since I replaced a September 15 -current with October 14 -current, I
get lots of
On Thu, 25 Nov 1999, Gary Jennejohn wrote:
!I can only guess, but it looks like the user-land process isn't told
!about the hangup and keeps sending packets down the line. The packets
!never go out (no connection), so the mbufs eventually run out. The
!raw interface evidently doesn't have the
Poul-Henning Kamp [EMAIL PROTECTED] writes:
Don't use the generic kernel unchanged with the 3com card.
Disable the ex0 and ie0 drivers, one of those pummel the 3com
cards magic config registers.
Tack. Now it manages to find ep0 properly. It still finds a `ghost'
ep1 and hangs hard when
In message [EMAIL PROTECTED], Assar Westerlund writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
Don't use the generic kernel unchanged with the 3com card.
Disable the ex0 and ie0 drivers, one of those pummel the 3com
cards magic config registers.
Tack. Now it manages to find ep0
Poul-Henning Kamp [EMAIL PROTECTED] writes:
no. Try to disable ep1 (if you can).
Not hardwiring ep0 in the configuration file made it work. Thanks
again.
Here's an trivial patch to GENERIC to add comments about these
characteristics about ep0.
/assar
Index: GENERIC
"David O'Brien" [EMAIL PROTECTED] writes:
+# don't try to hardware ep0 - it will not work
If we don't hardware it in GENERIC, then why do people think they should
be doing so?
(s/hardware/hardwire/ of course)
there's (to my mind) a difference between it's not done by default and
it will
in src/lib/libc/i386/SYS.h we see:
#ifdef __ELF__
#define KERNCALLint $0x80 /* Faster */
#else
#define KERNCALLLCALL(7,0) /* The old way */
#endif
and in /usr/src/sys/i386/i386/exception.s
we see:
/*
* Call gate entry for syscall.
* The intersegment call has been
On 26 Nov 1999, Assar Westerlund wrote:
there's (to my mind) a difference between it's not done by default and
it will not work. I did it because I had hardwired it in my previous
config.
Yes, and when I converted if_ep to newbus I mentioned that hardwire was no
longer supported.
I'm a
Am I also right in assuming that all the registers that the user was
running when they did the KERNCALL have been saved on the KERNEL stack by
the time that the above routines are called?
No, that's what the pushal (push all) does.
-DG
David Greenman
Co-founder/Principal Architect, The
22 matches
Mail list logo
