Seems to work alright here. dmesg and dd tests follow.
[before]
mercury# dd if=/dev/zero of=/tmp/zero bs=1024k count=32
32+0 records in
32+0 records out
33554432 bytes transferred in 6.013635 secs (5579725 bytes/sec)
mercury#
[after]
mercury# dd if=/dev/zero of=/tmp/zero bs=1024k count=3
> I for one would love to see 2.8.1 or newer in the tree for my own,
> selfish reasons. Many ports (new architectures) would benefit from
> this.
Is that to say that you prefer it over egcs 1.1.1? If so, why?
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebs
In message <19877.920165...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: I'm not sure I'd call it a "decision", but there are strong leanings
: towards egcs. It simply seems to be moving more aggressively (and
: more well-fundedly) in the right directions whereas gcc 2.8.1 has been
: very slow t
>
> The attached program sometimes causes a lockmgr panic. I do not think is
> always
> did. I am running 4.0-CURRENT form Feb 19.
>
> The trace is:
> panic lockmgr: locking against self
> lockmgr
> mv_map_growstack
> grow_stack
> trap_pfault
> tra
Whoops... I just realized: the output function in if_vlan is vlan_start(),
not vlan_output(), and it returns void, so what I said about ENOBUFS is
wrong. I still think the 'continue' that I added is correct though.
-Bill
--
While trying to figure out a way to support VLANs with the Alteon
gigabit NIC, I stumled across /sys/net/if_vlan.c. It seems simple
enough: pseudo IP interfaces are created which interacts with an
underlying physical interface and fixes up frame headers to deal
with VLAN tag encapsulation and extra
>I know that, back when we ran aout, our gcc was a long way changed from
>the stock gnu gcc ... I'm wondering how much our gcc is changed, now,
>from the gcc that is the regular GNU distribution?
$ cvs diff -r FSF /usr/src/contrib/gcc | wc
17467551 57123
[error ou
On Sun, Feb 28, 1999 at 03:21:38PM +1300, Joe Abley wrote:
> Is there any work in progress on sys/pccard/*?
>
> I'm using a Gateway Solo for the week which has the PCI/cardbus bridge
> mentioned in the title, and I have been getting spurious results with
> 4.0-CURRENT (supped a couple of days ago)
Is there any work in progress on sys/pccard/*?
I'm using a Gateway Solo for the week which has the PCI/cardbus bridge
mentioned in the title, and I have been getting spurious results with
4.0-CURRENT (supped a couple of days ago).
If there are some patches in test which might enhance support for
On Wednesday, 27 January 1999 at 18:17:20 -0800, Chris Piazza wrote:
> On 28-Feb-99 Greg Lehey wrote:
>> I've been given some code for recognizing and initializing Sis 5591
>> chipsets. In particular, it solves a recently introduced problem with
>> IDE Ultra DMA. It works fine for me, modulo a co
On 28-Feb-99 Greg Lehey wrote:
> I've been given some code for recognizing and initializing Sis 5591
> chipsets. In particular, it solves a recently introduced problem with
> IDE Ultra DMA. It works fine for me, modulo a couple of puzzling
> messages in the verbose probes, which I'll remove when
I've been given some code for recognizing and initializing Sis 5591
chipsets. In particular, it solves a recently introduced problem with
IDE Ultra DMA. It works fine for me, modulo a couple of puzzling
messages in the verbose probes, which I'll remove when I've had time
to study the data sheet.
> I'm wondering about the size of a project, to upgrade the compiler (this
> wants a relative answer, how much larger or smaller a job is it now,
> that it would have been a year ago under aout)? Is anyone doing this?
Peter was working on it, but I strongly suspect he won't have time to
even th
I know that, back when we ran aout, our gcc was a long way changed from
the stock gnu gcc ... I'm wondering how much our gcc is changed, now,
from the gcc that is the regular GNU distribution?
I'm wondering about the size of a project, to upgrade the compiler (this
wants a relative answer, how muc
In article <199902271936.laa25...@uop.cs.uop.edu>,
Bret Ford wrote:
> My 4.0-current buildworld broke. The sources were from yesterday
> night. The system is currently 4.0-current from Feb 16. My UNIX
> system is a 486 main board with an evergreen upgrade. The
> world was almost over, too! A
Julian Elischer wrote:
>On Fri, 26 Feb 1999, John Polstra wrote:
>> Julian Elischer wrote:
>> > you want to commit?
>> >
>> > (after you sir...)
>>
>> No, really, after you ... :-)
>
>Done
>in 3.1 and 4
I just remembered that MNT_UNION occurs in another file which on
investigation turned out to
On Sat, 27 Feb 1999, Jonathan Hanna wrote:
>
> The attached program sometimes causes a lockmgr panic. I do not think is
> always
> did. I am running 4.0-CURRENT form Feb 19.
>
> The trace is:
> panic lockmgr: locking against self
> lockmgr
> mv_map_growstack
> gr
The attached program sometimes causes a lockmgr panic. I do not think is always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
I believe that (uid_t)-2 has a lot to do with the user nobody. That was the
historical reason why the uid 65534 for chosen for nobody back when uid_t was
only 16 bits.
I would recommend that the default mapped uid for root be defined as 65534
instead of (uid_t)-2. This seems to make the most sen
My 4.0-current buildworld broke. The sources were from yesterday
night. The system is currently 4.0-current from Feb 16. My UNIX
system is a 486 main board with an evergreen upgrade. The
world was almost over, too! Argh! :-)
Bret Ford
===> usr.sbin/natd
gcc -O -Wall -I/tigger/obj/usr/src/t
>> >> =1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/
>> >> =
>> >> =funny, the same value. There is something left out very fundamentally
>> >> =somewhere.
>> >>
>> >> Just FYI. This number is 0xFFFE in hex... A search for this number
>> >> through the sources does not bring anyt
According to Chan Yiu Wah:
> Is there anyone knows what it means when running the soffice 5.01 .
> The message keeps growing as I using the soffice. Is it harmful the system?
It is explained on htt://lt.tar.com/. You need the following lines in your
kernel config file:
# -=-=-=-=-=-=-=-=-=-=-
On Sat, 27 Feb 1999, Jeroen Ruigrok/Asmodai wrote:
> On 27-Feb-99 sth...@nethelp.no wrote:
> >> Jeroen Ruigrok/Asmodai once stated:
> >>
> >> => -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54
> >> pdksh.core.xclink
> >>
> >> =this is exactly what I got when I tried to compile some things
Bruce Evans wrote:
>
> There's only one, at least in my version.
There is the PC98 one you removed, and then this one in
atapi_request_immediate():
> /* Wait for data i/o phase. */
> for (cnt=2; cnt>0; --cnt)
> if (((inb (ata->port + AR
Jeroen Ruigrok/Asmodai wrote:
>
> this is exactly what I got when I tried to compile some things over NFS.
> The created directory and files were also like this:
>
> 1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/
>
> funny, the same value. There is something left out very fundamenta
My current box, cvsupped at abot 15:30 (CET) of the 27-02-1999 fails to
complete the make world :
===> usr.sbin/natd
cc -nostdinc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.sbin/natd/nat
d.c
cc -nostdinc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.
On 27-Feb-99 sth...@nethelp.no wrote:
>> Jeroen Ruigrok/Asmodai once stated:
>>
>> => -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54
>> pdksh.core.xclink
>>
>> =this is exactly what I got when I tried to compile some things over
>> NFS.
>> =The created directory and files were also like t
On Sat, 27 Feb 1999, Nicolas Souchu wrote:
> On Wed, Feb 24, 1999 at 08:51:03AM +, Doug Rabson wrote:
> >
> >On Tue, 23 Feb 1999, Nicolas Souchu wrote:
> >
> >> Hi folks,
> >>
> >> Updating at Mar 23 f?v 1999 22:52:33 CET,
> >>
> >> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-
> Jeroen Ruigrok/Asmodai once stated:
>
> => -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink
>
> =this is exactly what I got when I tried to compile some things over NFS.
> =The created directory and files were also like this:
> =
> =1 drwxr-xr-x 3 4294967294 wheel - 5
On Wed, Feb 24, 1999 at 08:51:03AM +, Doug Rabson wrote:
>
>On Tue, 23 Feb 1999, Nicolas Souchu wrote:
>
>> Hi folks,
>>
>> Updating at Mar 23 fév 1999 22:52:33 CET,
>>
>> cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
>> -Wmissing-prototypes -Wpointer-arith -Winline
4.0-CURRENT supped about 3 hours ago, make buildworld:
===> usr.sbin/natd
cc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -c
/usr/src/usr.sbin/natd/natd.c
/usr/src/usr.sbin/natd/natd.c: In function `SetAliasAddressFromIfName':
/usr/src/usr.sbin/natd/natd.c:702: warning: implicit declaratio
Jeroen Ruigrok/Asmodai once stated:
=> -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink
=this is exactly what I got when I tried to compile some things over NFS.
=The created directory and files were also like this:
=
=1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09
On Fri, Feb 26, 1999 at 09:16:44PM +0100, Luigi Rizzo wrote:
> (about union mounts on 3.1 not returning all files with an 'ls' in 3.1
> while it did in 3.0)
>
> > Is it sorrect that this magic is implemented in sys/kern/vfs_lookup.c?
> > The odd thing is that AFAICS no-one has made significant cha
On 26-Feb-99 John W. DeBoskey wrote:
> Hi,
>
>I have some machines running 3.0-19981209-SNAP. I have seen
> some core dumps from pdksh (which I haven't figured out yet)
> that have some really strange uid values.
>
> -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink
Wh
On Sat, 27 Feb 1999, Chan Yiu Wah wrote:
>
> Hello,
>
> Is there anyone knows what it means when running the soffice 5.01 .
> The message keeps growing as I using the soffice. Is it harmful the system?
You need to add these lines to your kernel config file:
options "P1003_1B"
opti
Hello,
Is there anyone knows what it means when running the soffice 5.01 .
The message keeps growing as I using the soffice. Is it harmful the system?
cheers
Clarence
=
fbsd-elf# ./soffice
Feb 27 22:51:03 fbsd-elf last message repeated 238 times
Feb 27 22:52:12 fbsd-elf /kernel: c
>> Nope, that code snippet is in atapi.c its not in any of the drivers...
>> (and newer has been).
>
>You're right. Goes to show how long I haven't touched this part of
>the code. Alas, just reviewed it out of curiosity. It sure got more
>readable... :-) But I still hate those inb loops without DEL
37 matches
Mail list logo