date:20021102

 Now that uucp is no longer in the base system, is there any reason to
 keep user uucp in /usr/src/etc/master.passwd?

Probably not. If you remove this, please coordinate an upgrade
to the net/freebsd-uucp port the get the user added there.

Thanks!

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

CNet CNWLC-811 (PRISM2), kernel panic

Hello,

Just bought a CNet WLAN card, and it makes -CURRENT panic when inserted,
or if it is inserted while booting.

Userland installed from 20021101 snapshot.
Kernel from today: FreeBSD 5.0-CURRENT #0: Sat Nov  2 09:50:05 CET 2002

(second panic from me issuing panic from ddb)

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xd11fa000
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01aa2d5
stack pointer   = 0x10:0xcc00494c
frame pointer   = 0x10:0xcc004b78
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 9 (cbb1)
panic: from debugger


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc03b47d4
stack pointer   = 0x10:0xcc0046bc
frame pointer   = 0x10:0xcc0046c8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 9 (cbb1)
panic: from debugger
Uptime: 1m11s
Dumping 224 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208
---
#0  doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0  doadump () at ../../../kern/kern_shutdown.c:232
#1  0xc0242d89 in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2  0xc0242fd3 in panic () at ../../../kern/kern_shutdown.c:517
#3  0xc0147ac2 in db_panic () at ../../../ddb/db_command.c:450
#4  0xc0147a42 in db_command (last_cmdp=0xc0429b40, cmd_table=0x0, 
aux_cmd_tablep=0xc0422fb8, aux_cmd_tablep_end=0xc0422fbc)
at ../../../ddb/db_command.c:346
#5  0xc0147b56 in db_command_loop () at ../../../ddb/db_command.c:472
#6  0xc014a80a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#7  0xc03b4532 in kdb_trap (type=12, code=0, regs=0xcc00490c)
at ../../../i386/i386/db_interface.c:166
#8  0xc03c5e12 in trap_fatal (frame=0xcc00490c, eva=0)
at ../../../i386/i386/trap.c:841
#9  0xc03c5b22 in trap_pfault (frame=0xcc00490c, usermode=0,
eva=3508510720)
at ../../../i386/i386/trap.c:760
#10 0xc03c558d in trap (frame=
  {tf_fs = -1037107176, tf_es = -872415216, tf_ds = -1072168944,
tf_edi = -1036984320, tf_esi = -1037051392, tf_ebp = -872395912, tf_isp
= -872396488, tf_ebx = 0, tf_edx = -786460672, tf_ecx = -1037071868,
tf_eax = 4096, tf_trapno = 12, tf_err = 0, tf_eip = -1071996203, tf_cs =
8, tf_eflags = 66050, tf_esp = -1037051392, tf_ss = -1036984320}) at
../../../i386/i386/trap.c:446
#11 0xc03b5d08 in calltrap () at {standard input}:98
#12 0xc01aa105 in pccard_read_cis (sc=0x0)
at ../../../dev/pccard/pccard_cis.c:98
#13 0xc01a7ab2 in pccard_attach_card (dev=0xc230e000)
at ../../../dev/pccard/pccard.c:168
#14 0xc01afd26 in cbb_insert (sc=0xc22f8a00) at card_if.h:66
#15 0xc01afad8 in cbb_event_thread (arg=0xc22f8a00)
at ../../../dev/pccbb/pccbb.c:917
#16 0xc022dab4 in fork_exit (callout=0xc01afa40 cbb_event_thread,
arg=0x0, 
frame=0x0) at ../../../kern/kern_fork.c:860
(kgdb) 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Michal Mertl

On Fri, 1 Nov 2002, Terry Lambert wrote:

 Bill Fenner wrote:
  I think this can still crash (just like my patch); the problem is in
  what happens when it fails to allocate memory.  Unless you set one of
  the flags, it's still going to panic in the same place, I think, when
  you run out of memory.
 
  No.  The flags are only checked when so_head is not NULL.  sonewconn()
  was handing sofree() an inconsistent struct so (so_head was set without
  being on either queue), i.e. sonewconn() was creating an invalid data
  structure.

 You're right... I missed that; I was thinking too hard on the other
 situations (e.g. soabort()) that could trigger that code, and no
 enough on the code itself.

  The call in sonewconn() used to be to sodealloc(), which didn't care
  about whether or not the data structure was self-consistent.  The code
  was refactored to do reference counting, but the fact that the socket
  was inconsistent at that point wasn't noticed until now.

 Yeah; I looked at doing a ref() of the thing as a partial fix,
 but the unref() did the sotryfree() anyway.


  The problem is not at all based on what happens in the allocation or
  protocol attach failure cases.  The SYN cache is not involved, this is
  a bug in sonewconn(), plain and simple.

 I still think there is a potential failure case, but the amount of
 code you'd have to read through to follow it is immense.  It has to
 do with the conection completing at NETISR, instead of in a process
 context, in the allocation failure case.  I ran into the same issue
 when trying to run connections to completion up to the accept() at
 interrupt, in the LRP case.  The SYN cache case is very similar, in
 the case of a cookie that hits when there are no resources remaining.
 He might be able to trigger it with his setup, by setting the cache
 size way, way don, and thus relying on cookies, and then flooding it
 with conection requests until he runs it out of resources.

Do I read you correctly that Bill's patch is probably better than yours
(I tested both, both fix the problem)?

If you still believe there's a problem (bug) I may trigger with some
setting please tell me. I don't know how to make syncookies kick in - I
set net.inet.tcp.cachelimit to 100 but it doesn't seem to make a
difference but I don't know what am I doing :-). I imagine syncache
doesn't grow much when I'm connecting from signle IP and connections are quickly
eastablished. I'll be able to do some tests on monday - this is a computer
at work.

FWIW netstat -m during the benchmark run shows (I read it that it doesn't
have problem - even just before the crash):

mbuf usage:
GEN list:   0/0 (in use/in pool)
CPU #0 list:71/160 (in use/in pool)
CPU #1 list:79/160 (in use/in pool)
Total:  150/320 (in use/in pool)
Maximum number allowed on each CPU list: 512
Maximum possible: 34560
Allocated mbuf types:
  80 mbufs allocated to data
  70 mbufs allocated to packet headers
0% of mbuf map consumed
mbuf cluster usage:
GEN list:   0/0 (in use/in pool)
CPU #0 list:38/114 (in use/in pool)
CPU #1 list:41/104 (in use/in pool)
Total:  79/218 (in use/in pool)
Maximum number allowed on each CPU list: 128
Maximum possible: 17280
1% of cluster map consumed
516 KBytes of wired memory reserved (37% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


-- 
Michal Mertl
[EMAIL PROTECTED]









To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Installing CURRENT 20021101

Hello,

Got the 20021101 snapshot from USW2 to have some fun with testing, and
hoping to get my new WLAN card to work :)

I got some trouble installing.

- When installing over network, reinitializing network media does not
  work.  If you select wrong the first time, the only way to redo your 
  selection is to reboot.  Using the dc0 driver. (Network connection 
  pulled down and not set up again it seems.)

  I was unable to complete a NFS install, but I didn't try too hard 
  because of having to reboot on every try.

The nasty part:

- fdisk showed all partitions as type 165 (FreeBSD), I took a chance and
  continued anyway.  Now my two non-FreeBSD partitions are lost :)

The partitions were:
ad0s1   NTFS(WindowsXP)
ad0s2   FreeBSD
ad0s4   DOS, FAT32

(I guess I can get them back by setting correct type...)

fdisk also showed them in the wrong order, ad0s1 first, then ad0s4 and
then ad0s2.


Mvh,
Frode Nordahl


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

Michal Mertl wrote:
 This patch fixes the panics for me. Thanks a lot. I believe it should be
 commited.

I agree (Mark Murray -- this was the patch I was talking about).

 BTW: I get about 850 fetches pers second on UP an 600 SMP (the same
 machine and settings). Don't know if it's expected in this usage pattern.

It's expected.

Fetches per second isn't a very good benchmark, FWIW.  It doesn't
tell us how to repeat it.

A better measure is connections per second (at least for a server
box).

With proper tuning, and some minor patches, 7000/second isn't hard
to get.

If you add the Duke University version of the Rice University patches
for LRP, modify the mbuf allocator for static freelisting and then
pre-populate it, and tune the kernel properly, you should be able to
get over 20,000 connections per second.  The best I've managed with a
modified FreeBSD 4.2, before the SYN-cache code, was 32,000/second.

Use MAST or http_load on a number of simultaneous clients to get
in the neighborhood of those numbers.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Installing CURRENT 20021101

2002-11-02 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Frode Nordahl writ
es:
The nasty part:

- fdisk showed all partitions as type 165 (FreeBSD), I took a chance and
  continued anyway.  Now my two non-FreeBSD partitions are lost :)

Fixed.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: What is user uucp good for?

2002-11-02 Thread John Hay

  Now that uucp is no longer in the base system, is there any reason to
  keep user uucp in /usr/src/etc/master.passwd?
 
 Probably not. If you remove this, please coordinate an upgrade
 to the net/freebsd-uucp port the get the user added there.

Also remember that /dev/cua* is owned by uucp.

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

Michal Mertl wrote:
 Do I read you correctly that Bill's patch is probably better than yours
 (I tested both, both fix the problem)?

That's a hard question, and it takes a longer answer.  8-(.

They fix the problem different ways.  The problem is actually
a secondary effect.  There are several ways to trigger it.  Mine
fixes it by initializing the socket to a valid value on the list,
and Bill's fixes it by initializing it to a valid value off the
list.

Mine will fail under load when the protocol attach fails; the way
it works is that the protocol attach succeeds before the soreserve()
fails, so it's possible to undo the attach, which happens in the
sotryfree().  It's a good fix because it ups the reference count,
and destroys the socket normally (in the caller) on failure.

Bill's won't fail when the protocol attach fails, but it will fail
under other conditions.  For example, if you were to up the amount
of physical RAM in your box, Bill's might start failing, or if you
up'ed the mbuf allocations by manually tuning them larger, Bill's
would definititely fail when you ran out of mbuf clusters, but not
mbufs.  Both of these failures require you to hit the cookie code
(the SYN-cache load getting too high).

Both of them are poor workarounds for a problem, which is really
that some of the code that's being called by the SYN-cache code
to do delayed allocation of resources until a matching ACK, was
never written to be callable at NETISR, and the allocation occurs
in the wrong order.

Bill's fix is marginally better, because it will handle one more
case than mine (but I believe it will actually leak sockets on the
failure case, when you are at resource starvation).

Both of them are voodoo: they rely on causing a different side
effect of a side effect.  As voodoo goes, Bill's is marginally
less invisible than mine, so I've suggested that Mark Murray
commit Bill's, instead of mine, but without reading the code,
just seeing either patch, no one would know what the heck the
patch was intended to do, or why it was needed at all... both
of them look like you are gratuitously moving code around for no
good reason.  8-).


 If you still believe there's a problem (bug) I may trigger with some
 setting please tell me. I don't know how to make syncookies kick in - I
 set net.inet.tcp.cachelimit to 100 but it doesn't seem to make a
 difference but I don't know what am I doing :-). I imagine syncache
 doesn't grow much when I'm connecting from signle IP and connections are quickly
 eastablished. I'll be able to do some tests on monday - this is a computer
 at work.

The problem is that you've tuned your kernel for more committed
memory than you actually have available... you are overcommiting
socket receive buffers (actually, 16K sockets at the current default
would need a full 4G of physical RAM, if there weren't overcommit).

The real fix would be to make the code insensitive to allocation
failures at all points in the process.  Like I said before, it would
require passing the address of the 'so' pointer to one of the underlying
functions, so that all the initialization could be done in one place
(the attach routine would be best).  This would change the protocol
interface for all the protocols, so it's a hard change to sell.


If you want to cause your kernel to freak, even with Bill's patch,
in your kernel config file, increase the number of mbuf's, but not
the number of mbuf clusters (manually tune up the number of mbufs).
This is a boundary failure, and it's possible to cause it to happen
anyway, just by adding RAM, now that Matt Dillon's auto-tuning code
has gone in (the ratio of increase for more RAM is not 1:1 for these
resources).

If you want to see it die slowly, run it at high load; you should
see from vmstat -m that, for every allocation failure on an
incoming connection, you leak a SYN cache entry and an associated
socket structure.  Eventually, your box will lock up, but you may
have to run a week or more to get it to do that, unless you have a
gigabit NIC, and can keep it saturated with connect requests (then
it should lock up in about 36 hours).  With my patch, instead of
locking up, it panic's again (I guess that's a plus, if you prefer
it to reboot and start working again, and don't have a status
monitor daemon on another box that can force the reboot).

If you want it to panic with my patch, tune the number of maxfiles
way, way up.  When the in_pcballoc() fails in tcp_attach, then it
will blow up (say around 40,000 connections or so).  If you try this,
remember that the sysctl for maxfiles is useless for networking
connections: you have to tune in the boot loader, or in the kernel
config for the tuning to have the correct effect on the number of
network connections.

Actually, if you look at the tcp_attach() code in tcp_usrreq.c,
you'll see that it also calls soreserve(); probably, the soreserve()
in the sonewconn() code is plain bogus, but I didn't want to remove
it in the 0/0 case for high/low

alpha tinderbox failure

2002-11-02 Thread Dag-Erling Smorgrav

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sat Nov  2 03:06:15 PST 2002
--
 Kernel build for GENERIC completed on Sat Nov  2 03:35:34 PST 2002
--
 Kernel build for LINT started on Sat Nov  2 03:35:34 PST 2002
--
=== vinum
Makefile, line 4517: warning: duplicate script for target geom_bsd.o ignored
cc1: warnings being treated as errors
/h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc':
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different 
type arg (arg 3)
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different 
type arg (arg 4)
/h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata':
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different 
type arg (arg 3)
*** Error code 1

Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1

Stop in /h/des/src.
*** Error code 1

Stop in /h/des/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Recent panics in -current

2002-11-02 Thread Kyle Martin

On Fri, Nov 01, 2002 at 08:40:00PM -0600, David W. Chapman Jr. wrote:
 getting this.  Does anyone have any clues.  It usually happens during 
 periods of high cpu and disk activity, like make -j25 buildworld.  
 
and how many gigs of ram do you have?

-- 
Kyle Martin
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Current on PPC

2002-11-02 Thread Paolo Pisati


What's the status of FreeBSD-CURRENT on PPC (mainly PowerMac stuff)?
the ppc page/ml seems to be dead to me.

thanks

-- 

Paolo

Italian FreeBSD User Group: http://www.gufi.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD

Hmm, OK.

Let me rephrase it all.

I have a 120G IDE disk, which is under LBA mode.  It is the second disk
on my system.  I have been using it with my old (julyish) -current for a
while now as a backup disk thingy.

My disk layout:

ad1s1: 8997MB  FreeBSD slice
ad1s3: 50995MB FreeBSD slice
ad1s2: 54478MB FAT32 slice

(Note the order)

This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028.  The sizes
are displayed correctly here, but when I try labeling the disk through
sysinstall's Configure-Label, It shows:

Disk: ad3   Partition name: ad3s1   Free: 0 blocks (0MB)
Disk: ad3   Partition name: ad3s3   Free: 102110549 blocks (49858MB)

Part  Mount  Size Newfs   Part  Mount  Size Newfs
  -   -     -   -
ad3s1anone128MB *   ad3s2 none  54478MB DOS
ad3s1bnone   1008MB *
ad3s1enone256MB *
ad3s1fnone256MB *
ad3s1gnone   7348MB *
ad3s3anone128MB * -- Notice the sizes
ad3s3bnone   1008MB * --

Note, ad3 should only show up as one partition, which, is  50995MB in
size.  The size 1000MB and 128MB DOES NOT MAKE SENSE AT ALL.  Also NOTE,
that the DOS partition shows has the right size, without any problems.

This problem does not occur on my older -current, which, was before GEOM
or even KSE III was integrated.  On IRC, I have been told that it could
be that geom_mbr is somehow messed up, but I cant say anything on that.

FWIW, I have used up around 12G on the FreeBSD (ad1s3) slice, and around
20G on my DOS slice.  The data got there, because I sliced the disk on
my older -current, but I dont think that has got anything to do with it.

FDISK Data:

Script started on Fri Nov  1 05:04:33 2002
vmnet-current:1m/usr/src/sys/geomm# fdisk ad3
*** Working on device /dev/ad3 ***
parameters extracted from in-core disklabel are:
cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 18426492 (8997 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA))
start 122865120, size 111571425 (54478 Meg), flag 0
beg: cyl 1023/ head 0/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 3 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 18426555, size 104438565 (50995 Meg), flag 80 (active)
beg: cyl 1023/ head 0/ sector 1;
end: cyl 1023/ head 254/ sector 63
The data for partition 4 is:
UNUSED
Script done on Fri Nov  1 05:04:37 2002

When I go to Configure-Fdisk in sysinstall, it shows this WARNING
message, which, I dont get in my old NON-GEOM system.  If there is
anymore data you would like, then please do not hesitate to contact me.

Cheers.

-- 
Hiten Pandya
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

On Fri, Nov 01, 2002 at 05:35:21PM -0800, walt wrote the words in effect of:
 Hiten Pandya wrote:
  Hi there.
  
  I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G 
  harddrive, which is the second one on the system.  Sysinstall failed to get 
  the right geometry of the disk, even though the BIOS was in LBA mode.
  
  My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB.
 
 Sorry, I'm not understanding that sentence.  Is there a typographical error
 in there somewhere, perhaps?  1000MB + 128MB  50GB
 
  The DOS partition (ad1s2) on the harddrive was just right, and nothing 
  wrong it, but only the FreeBSD partitions messed up.
 
 Sorry, I'm still confused.  You have two different FBSD partitions on the
 same disk (s3 and s1)?
 
 
  I made a 8G partition on the front of the disk (ad1s1), in which I was 
  planning to install FreeBSD.  Now, I am not sure what the real cause is, 
  i.e. why are we not allowed to install on an 8G partition on a 120G disk?
 
 No reason.  It should work.  Is the install failing at some point with
 error messages?  Did the install finish but now you can't boot the new
 system?
 
  It could be that I am doing something very wrong, but I would like to get 
  to the bottom of this, as I lost about 15G worth of data,
 
 I'm confused again.  Data on the FreeBSD partition?  Which FBSD partition?
 How did the data get there and in what way is it lost now, exactly?
 
  i.e. fdisk still 
  shows that the partition is there, but fsck_ffs is not proceeding. 
 
 You mean when you try to boot the 8GB partition, or the 50GB partition?
 Is fsck complaining about something?  What is it saying?  Please

Re: questions about the state of current

2002-11-02 Thread Doug Rabson

On Tue, 29 Oct 2002, John Baldwin wrote:


 On 29-Oct-2002 clark shishido wrote:
  On Tue, Oct 29, 2002 at 11:40:53AM -0700, Raymond Kohler wrote:
  1) How is the speed compared to stable? I remember it being just too slow some 
months ago and
  was wondering how it was improving.
 
  2) Are the random hangs in X fixed yet? I can put up with a few issues (it is 
current, after
  all), but that's just too much to bear.
 
  3) Are there any Very Important Packages (mozilla, kde, c) that won't build or 
refuse to work
  right?
 
 
  I started using current a couple months ago, I just rebuilt the big three
  (world, XFree86, mozilla) last week after the latest gcc import. Speed
  difference with 4-STABLE on a PIII 866 is not very noticable.
 
  If I was reading the threads correctly they trace the X crashes back to
  a floating point error.
 
  I hear kde is broken, mozilla compiled cleanly so some gtk stuff is OK.
  (Sorry I don't use the full gnome suite either).
 
  I lost a filesystem on my current disk a month ago so make sure you
  use current on another disk.

 I compiled kde3 a week or so ago on my laptop running -current and it is
 now my new desktop, so I think reports of kde being totally hosed are a
 bit exagerated or perhaps dated.

It looks like my problems centered around not properly re-compiling the
fam port. KDE 3.0.4 is working nicely now.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Phone: +44 20 8348 6160



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM gets whole disk geometry for slice (instead of slice geometry)

2002-11-02 Thread Andrey A. Chernov

On Sun, Oct 27, 2002 at 03:37:47 +0300, Andrey A. Chernov wrote:
 I have disk shared between FreeBSD and M$ Win, two slices, and got 
 incorrect disklabel with GEOM kernel. Namely cylinders and 
 sectors/unit fields are from _whole_ disk, not from just requested 
 slice. 

Just found more brokeness: 'disklabel -r ad0s1' and 'disklabel ad0s1'
shows different results, for -r case 63 added to offset field of all a,
b and c partitions.

BTW, is there is a way to turn GEOM off, something like NOGEOM kernel 
option? I want my old good disklabel back.

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM gets whole disk geometry for slice (instead of slice geometry)

On Sat, Nov 02, 2002 at 04:37:16PM +0300, Andrey A. Chernov wrote the words in effect 
of:
 On Sun, Oct 27, 2002 at 03:37:47 +0300, Andrey A. Chernov wrote:
  I have disk shared between FreeBSD and M$ Win, two slices, and got 
  incorrect disklabel with GEOM kernel. Namely cylinders and 
  sectors/unit fields are from _whole_ disk, not from just requested 
  slice. 
 
 Just found more brokeness: 'disklabel -r ad0s1' and 'disklabel ad0s1'
 shows different results, for -r case 63 added to offset field of all a,
 b and c partitions.
 
 BTW, is there is a way to turn GEOM off, something like NOGEOM kernel 
 option? I want my old good disklabel back.
 

I think it is NO_GEOM, but I am not sure, grep'ing for NO_GEOM does not
come up with anything though, but give it a try.

Cheers.

-- 
Hiten Pandya
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

$BL$>5Bz9-9p"(EE;R%a!<%k9-9p(J

2002-11-02 Thread cmail11jp

MÒ
dq[LÐ

¡ãALð²ó]µÈ¢ûÍ±±Ö
(K¸{¶É È½Ì[AhXÌÝð¨«º³¢j
[EMAIL PROTECTED]
[AhXð²LüµÄ¾³¢B

§104-0061
sæâÀ8-19-3
æ2ECOr@3F
[}KWs

TEL@03-3544-6222
FAX@03-3544-6218

===
âè¤iÎ©èWßÜµ½ÌÅAÁ³êé°êª èÜ·ÌÅ
¨\ÝÍ¨ßÉI
===

¡@ïõ§[^Nu@¡

cucErfI2500~©ç
nCNIeBæ¿ÅÌÌ}jAbNÈfÌX
Ü¸ÍJ^O¿¨Ò¿µÄ¨èÜ·iÇ¯ßÅÌ¿Â\j
¨è³É¨ÍÉÍA¨qlÌ¨¼OÌÝIÐ¼ÍêØüèÜ¹ñB
J^Oð¨©ÄA¨\µÝ¾³¢B
³¿J^O

http://www.allround.sib.ru/roriclub/

http://magazine.japanesebabies.com/roriclub/

@@@@@@@@@@@@@@@@@@@@@ïõ§[^Nu
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ

¡SEXthåW¡

^ÉSEXthðTµÄ¢él¾¯WI
SÇ±ÅàßÌlðvtB[tÅ·®ÐîB
á¢l©çnNÜÅ¢ÁÏ¢¢éæ!
_iÉàÌHðyµà¤I

http://www.allround.sib.ru/sex/

http://magazine.japanesebabies.com/sex/

Nu
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ

¡ààªÍ¶¯ÄÔÇ¤ªäêé¡

µ¶ÝÆààÌR{[V
[^rfIicucjêå
¢ÂÜÅcÆÅ«é©í©èÜ¹ñ
²¶Í¨ßÉI

http://www.allround.sib.ru/roridvd/rori/

http://magazine.japanesebabies.com/roridvd/rori/


ìiá
`à@¼Ã®cn9@Ì¹
ÈÇÈÇ132ìiBD]I
   @(^-^)/~Fg[
QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ


¡@rlp[gi[Ðî¦ú@¡

rlp[gi[¦úÐîB
âSMNuÆÍá¢Arl¤DÒ¾¯ªW¤ïB
SÅ²ÐîÅ«Ü·B
 È½ÌvCÉ í¹Ä¦úÐîB
vCãàÍêØ©©èÜ¹ñB
NîÍ20ÎÈãB

http://www.allround.sib.ru/sm/

http://magazine.japanesebabies.com/sm/


@@@@@@@@@@@@@@@@@@@@@@@@@rlNu
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@l`tªìÁ½ìi@¡

ø«µß½Èéæ¤È¨l`³ñªìêÜµ½B
Iåqbg¤iI
É§Àª é½ßA¨\µÝÍ¨ßÉI
ÇÜÅ{¨»ÁèÉ§ìµ½½ßAXªÌÅ«Ü¹ñB

http://www.allround.sib.ru/dachi/dollc/

http://magazine.japanesebabies.com/dachi/dollc/


@@@@@@@@@@@@@@@@@@@@@l`t{ìfUC
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@tðÛçÔ@¡

fGÈj«Æ©ÜÅñlEEEB
fGÈj«ð¡·®MÌ³Öü©í¹Ü·B
Slbg[NÅ·®ÉÐînjB
á¢«à¶µÈ¢ÅVÑÜë¤I
PñÀèA·úA½Åà èB
ô«ÉDµÅ«éj«X^btà¯åWô

http://www.allround.sib.ru/enjyo/

http://magazine.japanesebabies.com/enjyo/


@@@@@@@@@@@@@@@@@@@@@@@@@tï
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@}t@iÌí@¡

}t@iª½ÜçÈD«ÈlAÇ¤¼A±±ÖB
 ÔÈ¢·èÌîñàèÉüéæI
uâÎÉ«pµÈ¢Å¾³¢Bv

http://www.allround.sib.ru/mari/

http://magazine.japanesebabies.com/mari/



@@@@@@@@@@@@@@@@@@@@@@@@@X@³j
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

¡@VJXIÀZ[@¡

AV.DVDÀZ[
¼XÅÍèÉüçÈ¢àÌÎ©µ¥¥
ÈOÌæ¤ÉAæëµ¨è¢µÜ·B
¼XÉ¯¸À¿àI

http://www.allround.sib.ru/pink/

http://magazine.japanesebabies.com/pink/

@@@
@@@@@@@@@@@@@@@@@@@@@@@@@üNu
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Recent panics in -current

2002-11-02 Thread David W. Chapman Jr.

 On Fri, Nov 01, 2002 at 08:40:00PM -0600, David W. Chapman Jr. wrote:
  getting this.  Does anyone have any clues.  It usually happens during
  periods of high cpu and disk activity, like make -j25 buildworld.
 
 and how many gigs of ram do you have?

1 gig of registered ECC

And since memory has something to do with it, let me add that this is a tyan
K7 and I have ECC Scrub turned on in the bios.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

__sF

2002-11-02 Thread Adam K Kirchhoff


Hey all,

About a month ago, I upgraded from -stable to -current.  I've
cvsuped about four times since then and upgraded my system each time.

So far I'm having a couple of difficulties.  Complete system
lockups (that dump into the kernel debugger) are not all uncommon.  I'm
not trying to deal with that problem today, though :-)

The bigger issue is that after at least two of the upgrades (the
initial upgrade to -current, and one from yesterday), I've ended up with
an error when trying to run and build certain applications:

For example:

[ adamk@sorrow ~ ]$ galeon
/usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libgconf-gtk-1.so.1: Undefined
symbol __sF

Or, when trying to build qt-3.0.5:

c++ -fno-exceptions -pthread -o ../../../bin/uic
.obj/release-shared-mt/main.o .obj/
release-shared-mt/uic.o .obj/release-shared-mt/form.o
.obj/release-shared-mt/object.
o .obj/release-shared-mt/subclassing.o .obj/release-shared-mt/embed.o
.obj/release-s
hared-mt/widgetdatabase.o .obj/release-shared-mt/domtool.o
.obj/release-shared-mt/pa
rser.o   -L/usr/local/lib  -L/usr/local/lib
-Wl,-rpath,/usr/ports/x11-toolkits/qt30
/work/qt-x11-free-3.0.5/lib
-L/usr/ports/x11-toolkits/qt30/work/qt-x11-free-3.0.5/l
ib  -L/usr/X11R6/lib  -L/usr/X11R6/lib -lz -lqt-mt -lGLU -lGL -lXmu -lICE
-lSM -lXex
t -lX11 -lm -lXinerama -lXrender -lXft -lfreetype
/usr/local/lib/liblcms.so.1: undefined reference to `__sF'

In both cases, FreeBSD doesn't seem to like __sF.

Now, the first time this happened, I simply cvsuped a couple days
later and the problem went away, but now it's back, which is making me
think I never really solved the problem the first time around.

Any ideas on how to permanently fix this problem?

Adam



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

   In both cases, FreeBSD doesn't seem to like __sF.

This is being discussed /ad nauseam/ on the lists. If you are running
CURRENT, the onus is on you to keep up with developments. :-)

   Now, the first time this happened, I simply cvsuped a couple days
 later and the problem went away, but now it's back, which is making me
 think I never really solved the problem the first time around.
 
   Any ideas on how to permanently fix this problem?

Rebuild _everything_. Ports, libraries, dependancies, the lot.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

2002-11-02 Thread Adam K Kirchhoff

On Sat, 2 Nov 2002, Mark Murray wrote:

In both cases, FreeBSD doesn't seem to like __sF.

This is being discussed /ad nauseam/ on the lists. If you are running
CURRENT, the onus is on you to keep up with developments. :-)

True. A few days after the first time I encountered this problem, I had
searched through the archives and seen a very recent discussion about how
it was fixed it -CURRENT about two days after I had upgraded. So I
upgraded again and, indeed, the problem was fixed.

And this past time, though, I did check out the archives again... I came
across this post:

http://www.freebsd.org/cgi/getmsg.cgi?fetch=1438233+1440468+/usr/local/www/db/text/2002/freebsd-current/20021020.freebsd-current

It indicated that __sF was added back into libc.

Now, the first time this happened, I simply cvsuped a couple days
later and the problem went away, but now it's back, which is making me
think I never really solved the problem the first time around.

Any ideas on how to permanently fix this problem?

Rebuild _everything_. Ports, libraries, dependancies, the lot.

So is the current position on the matter that __sF is going to remain out
of libc? If that's the case, fine, I have no objections to recompiling
all my ports, but the fact of the matter is that there doesn't seem to be
much agreement about whether or not that's the case, seeing how __sF keeps
getting removed and re-added.

Adam

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: GEOM gets whole disk geometry for slice (instead of slicegeometry)

2002-11-02 Thread Bruce Evans

On Sat, 2 Nov 2002, Andrey A. Chernov wrote:

 On Sun, Oct 27, 2002 at 03:37:47 +0300, Andrey A. Chernov wrote:
  I have disk shared between FreeBSD and M$ Win, two slices, and got
  incorrect disklabel with GEOM kernel. Namely cylinders and
  sectors/unit fields are from _whole_ disk, not from just requested
  slice.

 Just found more brokeness: 'disklabel -r ad0s1' and 'disklabel ad0s1'
 shows different results, for -r case 63 added to offset field of all a,
 b and c partitions.

This is because -r causes the raw disk to be read and written, and GEOM is
missing the i/o-snooping code that adjusts the offsets even if the labels
are accessed by reading and writing the raw disk.

 BTW, is there is a way to turn GEOM off, something like NOGEOM kernel
 option? I want my old good disklabel back.

Just NO_GEOM.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: What is user uucp good for?

2002-11-02 Thread Frank Mayhar

John Hay wrote:
   Now that uucp is no longer in the base system, is there any reason to
   keep user uucp in /usr/src/etc/master.passwd?
  
  Probably not. If you remove this, please coordinate an upgrade
  to the net/freebsd-uucp port the get the user added there.
 
 Also remember that /dev/cua* is owned by uucp.

And that /usr/bin/tip and /usr/bin/cu are setuid uucp, although I guess
they may now be a part of the port, eh?

I take it that this is all in -current?
-- 
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Recent panics in -current

2002-11-02 Thread Kyle Martin

On Sat, Nov 02, 2002 at 08:53:55AM -0600, David W. Chapman Jr. wrote:
  On Fri, Nov 01, 2002 at 08:40:00PM -0600, David W. Chapman Jr. wrote:
   getting this.  Does anyone have any clues.  It usually happens during
   periods of high cpu and disk activity, like make -j25 buildworld.
  
  and how many gigs of ram do you have?
 
 1 gig of registered ECC
 
 And since memory has something to do with it, let me add that this is a tyan
 K7 and I have ECC Scrub turned on in the bios.

odds are your running out of memory, i also have a tyan thunder k7 w/ dual
1.2ghz procs with 1 gig of registered ecc, but ive never pushed more than a
-j8


-- 
Kyle Martin
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Recent panics in -current

2002-11-02 Thread David W. Chapman Jr.

  And since memory has something to do with it, let me add that this is a tyan
  K7 and I have ECC Scrub turned on in the bios.
 
 odds are your running out of memory, i also have a tyan thunder k7 w/ dual
 1.2ghz procs with 1 gig of registered ecc, but ive never pushed more than a
 -j8

I don't believe I am, after building for a while I was able to use 
99% of the 1gig, but around 450MB was inactive.  This doesn't just 
occur during make buildworld, sometimes it is just compiling regular 
programs like kde3.  What is your ECC setting in the bios or do you 
have it turned on?

-- 
David W. Chapman Jr.
[EMAIL PROTECTED]   Raintree Network Services, Inc. www.inethouston.net
[EMAIL PROTECTED]   FreeBSD Committer www.FreeBSD.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Bill Fenner


Terry,

  I think most of your 9k of reasoning is based on the thought that
soreserve() allocates memory.  It doesn't, and never has.

  Bill

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

2002-11-02 Thread Kris Kennaway

On Sat, Nov 02, 2002 at 10:35:03AM -0500, Adam K Kirchhoff wrote:

 So is the current position on the matter that __sF is going to remain out
 of libc?

Yes.

Kris



msg45920/pgp0.pgp
Description: PGP signature

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Bill Fenner


Michal,

  Alan Cox pointed out to me that backing out to using sodealloc()
instead of sotryfree() is probably a better fix anyway - it solves
the panic in more or less the same way as mine, but it backs the code
out to be the same as it's been for years -- a much more well-tested
fix =)  He committed it this morning, so could you please test an
up to date -CURRENT (rev 1.105 of uipc_socket2.c) without my patch?

Thanks,
  Bill

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: A few questions

In message: [EMAIL PROTECTED]
Giorgos Keramidas [EMAIL PROTECTED] writes:
: On 2002-10-31 18:39, Conrad Sabatier [EMAIL PROTECTED] wrote:
:  I just upgraded a 4.7-STABLE box to current over the weekend.  Went off
:  very well, thanks to the great documentation in UPDATING.
:  [...]
:  And finally, is there a simple way to ensure that none of the debugging
:  code (including INVARIANTS stuff) is included during a buildworld?
: 
: INVARIANTS and WITNESS are kernel-only stuff.  They shouldn't affect
: your userland programs.  If they do, it's probably a bug.

Actually, they slow things down a little, which is likely why someone
wants to get of them.  Just make sure that they aren't in the kernel
config file should be sufficient.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Galen Sampson

Hi

--- Terry Lambert [EMAIL PROTECTED] wrote:
 With proper tuning, and some minor patches, 7000/second isn't hard
 to get.
 
 If you add the Duke University version of the Rice University patches
 for LRP, modify the mbuf allocator for static freelisting and then
 pre-populate it, and tune the kernel properly, you should be able to
 get over 20,000 connections per second.  The best I've managed with a
 modified FreeBSD 4.2, before the SYN-cache code, was 32,000/second.

Out of pure curiosity what is the reason that the Duke and Rice patches were
never incorporated into the base system.  If it really enables the same machine
to provide 4 times the number of connections this seems like it would be a
useful thing to include.

regards,
Galen Sampson

__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: crash with network load (in tcp syncache ?)

2002-11-02 Thread Don Bowman

 From: Galen Sampson [mailto:galen_sampson;yahoo.com]
 
 Out of pure curiosity what is the reason that the Duke and 
 Rice patches were
 never incorporated into the base system.  If it really 
 enables the same machine
 to provide 4 times the number of connections this seems like 
 it would be a
 useful thing to include.

I suspect because of the copyright:
http://www.cs.rice.edu/CS/Systems/ScalaServer/code/rescon-lrp/README.html

This code is copyrighted software and can NOT be redistributed

--don ([EMAIL PROTECTED] www.sandvine.com)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 09:47:26AM -0800, Kris Kennaway wrote:
 On Sat, Nov 02, 2002 at 10:35:03AM -0500, Adam K Kirchhoff wrote:
 
  So is the current position on the matter that __sF is going to remain out
  of libc?
 
 Yes.
 

This will break some commercially available software that
can't easily replaced.

kargl[248] f95 -V a.f90
NAGWare Fortran 95 compiler Release 4.2(468)
Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K.
f95comp version is 4.2(468)
/usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF'
collect2: ld returned 1 exit status

I seriously doubt that NAG will support both a 
4.x and 5.x version of their compiler.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: fdisk -BI ob clean disk broken

In message: [EMAIL PROTECTED]
John Hay [EMAIL PROTECTED] writes:
: On 4.x I have been using a slightly modified version of Warner's diskprep
: to write new compact flashes. On -current fdisk die with signal 8 (Floating
: point exception) when this part of the script runs:
: 
:   $dev = /dev/r${drive};
:   system /bin/dd if=/dev/zero of=$dev count=128  /dev/null 21;
:   system /sbin/fdisk -BI $drive;
: 
: $dev is normally da0, which is the compact flash plugged into a Sandisk
: usb CF reader.
: 
: So is there a better way in the GEOM world to achieve the same thing?

The reason that I do a dd first is to obliterate any MBR that's
there.  The intent is to force fdisk to fetch the actual disk geometry
from the disk so that the fdisk lable that is placed on there will
work as a boot disk.  Before I added the dd in 4.x, I found that many
CF came with MBRs that didn't match their actual geometry, so when I
tried to boot them, things failed.

Does removing the dd eliminate the problem?  If so, that's likely a
bug in GEOMification of fdisk.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: CNet CNWLC-811 (PRISM2), kernel panic

Does this happen with OLDCARD?  I have a couple of cards that do this,
but haven't been able to track down why this happens.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD

2002-11-02 Thread walt

Hiten Pandya wrote:

Hmm, OK.

Let me rephrase it all.

I have a 120G IDE disk, which is under LBA mode.  It is the second disk
on my system.  I have been using it with my old (julyish) -current for a
while now as a backup disk thingy.

My disk layout:

	ad1s1: 8997MB  FreeBSD slice
	ad1s3: 50995MB FreeBSD slice
	ad1s2: 54478MB FAT32 slice


Here you are discussing ad1, which should (I think) be the slave drive
on the first IDE controller.



This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028.  The sizes
are displayed correctly here, but when I try labeling the disk through
sysinstall's Configure-Label, It shows:

Disk: ad3   Partition name: ad3s1   Free: 0 blocks (0MB)
Disk: ad3   Partition name: ad3s3   Free: 102110549 blocks (49858MB)


Here you are discussing ad3, which should be the slave drive on the *second*
IDE controller.

Are you intending to discuss two different physical disks here?  I'm still
a bit confused.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

2002-11-02 Thread Will Andrews

On Sat, Nov 02, 2002 at 10:10:31AM -0800, Steve Kargl wrote:
 This will break some commercially available software that
 can't easily replaced.
 
 kargl[248] f95 -V a.f90
 NAGWare Fortran 95 compiler Release 4.2(468)
 Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K.
 f95comp version is 4.2(468)
 /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF'
 collect2: ld returned 1 exit status
 
 I seriously doubt that NAG will support both a 
 4.x and 5.x version of their compiler.

That's why we have compat libs.  compat4x should handle this
unless I'm mistaken.

Regards,
-- 
wca

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 10:58:41AM -0800, Will Andrews wrote:
 On Sat, Nov 02, 2002 at 10:10:31AM -0800, Steve Kargl wrote:
  This will break some commercially available software that
  can't easily replaced.
  
  kargl[248] f95 -V a.f90
  NAGWare Fortran 95 compiler Release 4.2(468)
  Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K.
  f95comp version is 4.2(468)
  /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF'
  collect2: ld returned 1 exit status
  
  I seriously doubt that NAG will support both a 
  4.x and 5.x version of their compiler.
 
 That's why we have compat libs.  compat4x should handle this
 unless I'm mistaken.
 

It doesn't work the way you think.  To understand the issues

http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/\
www/db/text/2002/freebsd-current/20021013.freebsd-current

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Minimal install

I'm downloading current snapshots.  I was wondering what the minimum
set of files I needed to download to do a minimal install.  I'm
guessing just floppies, base, or maybe floppies, base and crypto. (I'm
installing on pc98 machine, so need floppies).

Is this documented anywhere, or should I figure out it by trial and
error?

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

 I seriously doubt that NAG will support both a 
 4.x and 5.x version of their compiler.

This shouldn't be a problem. The commercial software Should Not Be(tm)
supporting something as variable as CURRENT, and with the STABLE libraries
around in COMPAT mode, the compiler Will Just Work(tm) (or should with
not much effort).

By the time __sF is mainstream, I guess the vendor will have adapted
their product to match. Win, win.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 07:06:47PM +, Mark Murray wrote:
  I seriously doubt that NAG will support both a 
  4.x and 5.x version of their compiler.
 
 This shouldn't be a problem. The commercial software Should Not Be(tm)
 supporting something as variable as CURRENT, and with the STABLE libraries
 around in COMPAT mode, the compiler Will Just Work(tm) (or should with
 not much effort).
 
 By the time __sF is mainstream, I guess the vendor will have adapted
 their product to match. Win, win.
 

No, it does not just work.  The NAG f95 compiler generates a
C file.  The C file is compiled by gcc.

f95 -o a a.f90 

is equivalent to 

f95 -c -o a.c a.f90
gcc -o a a.c -lf96 -lm -lc

libf96.so is linked against libc.so, which is a symlink
to libc.so.4 on a 4.x system.  libm.so and libc.so are
symlinks that point to libm.so.2 and libc.so.5 on 5.x.
You pick up the wrong libc.so in the above line.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: fdisk -BI ob clean disk broken

2002-11-02 Thread John Hay

 : On 4.x I have been using a slightly modified version of Warner's diskprep
 : to write new compact flashes. On -current fdisk die with signal 8 (Floating
 : point exception) when this part of the script runs:
 : 
 : $dev = /dev/r${drive};
 : system /bin/dd if=/dev/zero of=$dev count=128  /dev/null 21;
 : system /sbin/fdisk -BI $drive;
 : 
 : $dev is normally da0, which is the compact flash plugged into a Sandisk
 : usb CF reader.
 
 The reason that I do a dd first is to obliterate any MBR that's
 there.  The intent is to force fdisk to fetch the actual disk geometry
 from the disk so that the fdisk lable that is placed on there will
 work as a boot disk.  Before I added the dd in 4.x, I found that many
 CF came with MBRs that didn't match their actual geometry, so when I
 tried to boot them, things failed.
 
 Does removing the dd eliminate the problem?  If so, that's likely a
 bug in GEOMification of fdisk.

Hmmm. I just noticed that the disks probe with zero values for the
heads, sectors/track and cylinders. I have tried two different USB
CF readers and both do it. On 4.x it probes with the correct values
on the same machine and the same devices. So why do they probe
wrong?

#
umass0: SanDisk ImageMate CF-SD, rev 1.10/0.12, addr 2
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SanDisk ImageMate CF-SD1 0100 Removable Direct Access SCSI-0 device 
da0: 1.000MB/s transfers
da0: 61MB (125440 512 byte sectors: 0H 0S/T 0C)
umass0: at uhub0 port 1 (addr 2) disconnected
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
umass0: detached
umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2
umass0: Get Max Lun not supported (STALLED)
da0 at umass-sim0 bus 0 target 0 lun 0
da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device 
da0: 1.000MB/s transfers
da0: 61MB (125441 512 byte sectors: 0H 0S/T 0C)
###

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: fdisk -BI ob clean disk broken

In message: [EMAIL PROTECTED]
John Hay [EMAIL PROTECTED] writes:
: Hmmm. I just noticed that the disks probe with zero values for the
: heads, sectors/track and cylinders. I have tried two different USB
: CF readers and both do it. On 4.x it probes with the correct values
: on the same machine and the same devices. So why do they probe
: wrong?

Don't know.  I've had problems with CF readers returning the wrong
geometry values in 4.3, but never 0's

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: fdisk -BI ob clean disk broken

2002-11-02 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], John Hay wri
tes:
 : On 4.x I have been using a slightly modified version of Warner's diskprep
 : to write new compact flashes. On -current fdisk die with signal 8 (Floating
 : point exception) when this part of the script runs:
 : 
 :$dev = /dev/r${drive};
 :system /bin/dd if=/dev/zero of=$dev count=128  /dev/null 21;
 :system /sbin/fdisk -BI $drive;
 : 
 : $dev is normally da0, which is the compact flash plugged into a Sandisk
 : usb CF reader.
 
 The reason that I do a dd first is to obliterate any MBR that's
 there.  The intent is to force fdisk to fetch the actual disk geometry
 from the disk so that the fdisk lable that is placed on there will
 work as a boot disk.  Before I added the dd in 4.x, I found that many
 CF came with MBRs that didn't match their actual geometry, so when I
 tried to boot them, things failed.
 
 Does removing the dd eliminate the problem?  If so, that's likely a
 bug in GEOMification of fdisk.

Hmmm. I just noticed that the disks probe with zero values for the
heads, sectors/track and cylinders. I have tried two different USB
CF readers and both do it. On 4.x it probes with the correct values
on the same machine and the same devices. So why do they probe
wrong?

I have no idea either, but the answer must be somewhere in the da driver...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: What is user uucp good for?

On Sat, Nov 02, 2002 at 01:01:34PM +0200, John Hay wrote:
   Now that uucp is no longer in the base system, is there any reason to
   keep user uucp in /usr/src/etc/master.passwd?
  
  Probably not. If you remove this, please coordinate an upgrade
  to the net/freebsd-uucp port the get the user added there.
 
 Also remember that /dev/cua* is owned by uucp.

Maybe we should leave it for after 5.0. These last minute removals
of apparently non-important things do tend to open pandora's box
once in a while. It's not broken, so there's no rush...

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 11:24:32AM -0800, Steve Kargl wrote:
 On Sat, Nov 02, 2002 at 07:06:47PM +, Mark Murray wrote:
   I seriously doubt that NAG will support both a 
   4.x and 5.x version of their compiler.
  
  This shouldn't be a problem. The commercial software Should Not Be(tm)
  supporting something as variable as CURRENT, and with the STABLE libraries
  around in COMPAT mode, the compiler Will Just Work(tm) (or should with
  not much effort).
  
  By the time __sF is mainstream, I guess the vendor will have adapted
  their product to match. Win, win.
  
 
 No, it does not just work.  The NAG f95 compiler generates a
 C file.  The C file is compiled by gcc.
 
 f95 -o a a.f90 
 
 is equivalent to 
 
 f95 -c -o a.c a.f90
 gcc -o a a.c -lf96 -lm -lc
 
 libf96.so is linked against libc.so, which is a symlink
 to libc.so.4 on a 4.x system.  libm.so and libc.so are
 symlinks that point to libm.so.2 and libc.so.5 on 5.x.
 You pick up the wrong libc.so in the above line.

I see where this is breaking. The compat libs work because binaries
are already linked against them. What you're describing is a need to
link against libc.so.4 whilst on a -current box. Much the same as
developing under the Linuxulator: you're not using the native bits.

The problem is not unsolvable, but you also need the 4.x headers
to make it work. The first hurdle is getting NAG f90 to pick up a
random C compiler. The random C compiler then has to pick up the
4.x headers and libraries by having an alternate system includes
and libraries path. With GCC this should be simple enough.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

2002-11-02 Thread Peter Wemm

Steve Kargl wrote:
 On Sat, Nov 02, 2002 at 07:06:47PM +, Mark Murray wrote:
   I seriously doubt that NAG will support both a 
   4.x and 5.x version of their compiler.
  
  This shouldn't be a problem. The commercial software Should Not Be(tm)
  supporting something as variable as CURRENT, and with the STABLE libraries
  around in COMPAT mode, the compiler Will Just Work(tm) (or should with
  not much effort).
  
  By the time __sF is mainstream, I guess the vendor will have adapted
  their product to match. Win, win.
  
 
 No, it does not just work.  The NAG f95 compiler generates a
 C file.  The C file is compiled by gcc.
 
 f95 -o a a.f90 
 
 is equivalent to 
 
 f95 -c -o a.c a.f90
 gcc -o a a.c -lf96 -lm -lc
 
 libf96.so is linked against libc.so, which is a symlink
 to libc.so.4 on a 4.x system.  libm.so and libc.so are
 symlinks that point to libm.so.2 and libc.so.5 on 5.x.
 You pick up the wrong libc.so in the above line.

This is also solveable by setting a strategic symlink from libc.so -
/usr/lib/compat/libc.so.4 in the f95 backend's search path.

Does it do a gcc -o a a.c -L /usr/local/lib/f95 -lf96 -lm -lc or something
like that?  If so, you can put the libc.so symlink in there.

I assume that the generated code doesn't contain #includes...  If it does
you'll also need to do something about that so that you get the right
#includes.  libf96.so is a 4.x binary.  Even if it wasn't for __sF, you
should be compiling with 4.x libraries and (if needed) 4.x headers, because
you have parts of the 4.x stdio.h embedded in libf96.so.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: CNet CNWLC-811 (PRISM2), kernel panic

Hello,

With OLDCARD it does not crash!

After crafting a pccard.conf entry for the card, wi does not
successfully attach to the card.  Do you think it is feasible to add
support for this card in the wi driver?

Please don't hesitate to ask me for more information if you need it,
thanks!  If there is any dirty work to be done to make it work, tell me.
I'll be more than happy to do it for you :)


pccard.conf line:
# CNet CNWLC-811
card OEM 11Mbps Wireless LAN PC Card V-3
config  auto wi ?
insert  /etc/pccard_ether $device start
remove  /etc/pccard_ether $device stop


I get the following output from the driver:
wi0 at port 0x240-0x27f irq 11 slot 1 on pccard1
wi0: timeout in wi_cmd 0x; event status 0x
wi0: timeout in wi_cmd 0x; event status 0x
wi0: timeout in wi_cmd 0x; event status 0x
wi0: init failed
wi0: timeout in wi_cmd 0x0021; event status 0x
wi0: timeout in wi_cmd 0x0021; event status 0x
wi0: mac read failed 5
device_probe_and_attach: wi0 attach returned 5



# pccardc dumpcis
Configuration data for card in slot 1
Tuple #1, code = 0x17 (Attribute memory descriptor), length = 3
000:  d9 01 ff
Attribute memory device information:
Device number 1, type Function specific, WPS = ON
Speed = 250nS, Memory block size = 2Kb, 1 units
Tuple #2, code = 0x1d (Other conditions for attribute memory), length =
4
000:  01 d9 01 ff
(MWAIT)
Tuple #3, code = 0x20 (Manufacturer ID), length = 4
000:  00 00 00 00
PCMCIA ID = 0x0, OEM ID = 0x0
Tuple #4, code = 0x21 (Functional ID), length = 2
000:  06 00
Network/LAN adapter
Tuple #5, code = 0x15 (Version 1 info), length = 39
000:  05 00 4f 45 4d 00 31 31 4d 62 70 73 20 57 69 72
010:  65 6c 65 73 73 20 4c 41 4e 20 50 43 20 43 61 72
020:  64 20 56 2d 33 00 ff
Version = 5.0, Manuf = [OEM], card vers = [11Mbps Wireless LAN
PC Card V-3]
Tuple #6, code = 0x1a (Configuration map), length = 6
000:  01 02 00 08 03 ff
Reg len = 2, config register addr = 0x800, last config = 0xff
Registers: XX-- 1 bytes in subtuples
Tuple #7, code = 0x1b (Configuration entry), length = 15
000:  c1 81 9d 71 55 2e 2e 2d fc 14 45 10 b8 ff 20
Config index = 0x1(default)
Interface byte = 0x81 (I/O)  wait signal supported
Vcc pwr:
Nominal operating supply voltage: 5 x 1V
Max current average over 1 second: 2.5 x 100mA
Max current average over 10 ms: 2.5 x 100mA
Power down supply current: 2.5 x 10mA
Wait scale Speed = 1.2 x 10 us
Card decodes 5 address lines, limited 8/16 Bit I/O
IRQ modes:
IRQs:  3 4 5 7 8 9 10 11 12 13 14 15
Max twin cards = 0
Misc attr: (Power down supported)
Tuple #8, code = 0xff (Terminator), length = 0
2 slots found


Mvh,
Frode Nordahl

On Sat, 2002-11-02 at 19:15, M. Warner Losh wrote:
 Does this happen with OLDCARD?  I have a couple of cards that do this,
 but haven't been able to track down why this happens.
 
 Warner



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 12:00:42PM -0800, Marcel Moolenaar wrote:
 On Sat, Nov 02, 2002 at 11:24:32AM -0800, Steve Kargl wrote:
  
  No, it does not just work.  The NAG f95 compiler generates a
  C file.  The C file is compiled by gcc.
  
  f95 -o a a.f90 
  
  is equivalent to 
  
  f95 -c -o a.c a.f90
  gcc -o a a.c -lf96 -lm -lc
  
  libf96.so is linked against libc.so, which is a symlink
  to libc.so.4 on a 4.x system.  libm.so and libc.so are
  symlinks that point to libm.so.2 and libc.so.5 on 5.x.
  You pick up the wrong libc.so in the above line.
 
 I see where this is breaking. The compat libs work because binaries
 are already linked against them. What you're describing is a need to
 link against libc.so.4 whilst on a -current box. Much the same as
 developing under the Linuxulator: you're not using the native bits.
 
 The problem is not unsolvable, but you also need the 4.x headers
 to make it work. The first hurdle is getting NAG f90 to pick up a
 random C compiler. The random C compiler then has to pick up the
 4.x headers and libraries by having an alternate system includes
 and libraries path. With GCC this should be simple enough.
 

That's exactly the problem.  I haven't been able to 
state it in the same manner as you.

Alfred just committed a make.conf knob, WANT_COMPAT4_STDIO,
that permits libc to be built with __sF visible outside of 
libc.  I suspect most people will not need the knob, but
it will allow commercial apps to run if need be.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD

On Sat, Nov 02, 2002 at 10:38:33AM -0800, walt wrote the words in effect of:
 Hiten Pandya wrote:
  Hmm, OK.
  
  Let me rephrase it all.
  
  I have a 120G IDE disk, which is under LBA mode.  It is the second disk
  on my system.  I have been using it with my old (julyish) -current for a
  while now as a backup disk thingy.
  
  My disk layout:
  
  ad1s1: 8997MB  FreeBSD slice
  ad1s3: 50995MB FreeBSD slice
  ad1s2: 54478MB FAT32 slice
 
 Here you are discussing ad1, which should (I think) be the slave drive
 on the first IDE controller.
 
 
  This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028.  The sizes
  are displayed correctly here, but when I try labeling the disk through
  sysinstall's Configure-Label, It shows:
  
  Disk: ad3   Partition name: ad3s1   Free: 0 blocks (0MB)
  Disk: ad3   Partition name: ad3s3   Free: 102110549 blocks (49858MB)
 
 Here you are discussing ad3, which should be the slave drive on the *second*
 IDE controller.
 
 Are you intending to discuss two different physical disks here?  I'm still

Oops, change that ad3 into ad1.

-- 
Hiten Pandya
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 12:06:38PM -0800, Peter Wemm wrote:
 
 This is also solveable by setting a strategic symlink from libc.so -
 /usr/lib/compat/libc.so.4 in the f95 backend's search path.
 
 Does it do a gcc -o a a.c -L /usr/local/lib/f95 -lf96 -lm -lc or something
 like that?  If so, you can put the libc.so symlink in there.
 
 I assume that the generated code doesn't contain #includes...  If it does
 you'll also need to do something about that so that you get the right
 #includes.  libf96.so is a 4.x binary.  Even if it wasn't for __sF, you
 should be compiling with 4.x libraries and (if needed) 4.x headers, because
 you have parts of the 4.x stdio.h embedded in libf96.so.
 

The only include that I any aware of is f95.h
which mainly defines stuff in libf95 (e.g.,
a typedef for struct nagf95_complex).

The verbose compiler output is below.  Note,
that the crt* files are also 5.x instead of
4.x.  Maybe it's just good fortune, but NAG's
f95 compiler works great on 5.x (except for
the __sF snafu).

-- 
Steve

kargl[226] f95 -v -Wc,-v -Wl,-v a.f90
a.f90:
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20021009 (prerelease)
 /usr/libexec/cc1 -lang-c -v -I/usr/local/lib/NAGWare -D__GNUC__=3 -D__GNUC_MINOR__=2 
-D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__FreeBSD__=5 
-D__FreeBSD_cc_version=54 -Dunix -D__KPRINTF_ATTRIBUTE__ -D__FreeBSD__=5 
-D__FreeBSD_cc_version=54 -D__unix__ -D__KPRINTF_ATTRIBUTE__ -D__unix 
-Asystem=unix -Asystem=bsd -Asystem=FreeBSD -D__NO_INLINE__ -D__STDC_HOSTED__=1 
-Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ -D__ELF__ 
-D_LONGLONG -DBSD -DANSI_C -DINT64=long long -DPOW_IS_INACCURATE /var/tmp/a.051193.c 
-quiet -dumpbase a.051193.c -version -fsigned-char -o /var/tmp/cczLSErX.s
GNU CPP version 3.2.1 [FreeBSD] 20021009 (prerelease) (cpplib) (i386 FreeBSD/ELF)
GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease) (i386-undermydesk-freebsd)
compiled by GNU C version 3.2.1 [FreeBSD] 20021009 (prerelease).
ignoring duplicate directory /usr/include
#include ... search starts here:
#include ... search starts here:
 /usr/local/lib/NAGWare
 /usr/include
End of search list.
 /usr/bin/as -v -o a.o /var/tmp/cczLSErX.s
GNU assembler version 2.13 [FreeBSD] 2002-10-10 (i386-obrien-freebsd5.0) using BFD 
version 2.13 [FreeBSD] 2002-10-10
Loading...
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20021009 (prerelease)
 /usr/libexec/collect2 -V -dynamic-linker /usr/libexec/ld-elf.so.1 /usr/lib/crt1.o 
/usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /usr/local/lib/NAGWare/quickfit.o a.o 
-rpath /usr/local/lib/NAGWare /usr/local/lib/NAGWare/libf96.so 
/usr/local/lib/NAGWare/libf96.a -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
GNU ld version 2.13 [FreeBSD] 2002-10-10
  Supported emulations:
   elf_i386_fbsd

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

  By the time __sF is mainstream, I guess the vendor will have adapted
  their product to match. Win, win.
  
 
 No, it does not just work.  The NAG f95 compiler generates a
 C file.  The C file is compiled by gcc.

How about much effort? there _has_ to be some kind of way to
specify which C library to use.

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 08:42:35PM +, Mark Murray wrote:
   By the time __sF is mainstream, I guess the vendor will have adapted
   their product to match. Win, win.
   
  
  No, it does not just work.  The NAG f95 compiler generates a
  C file.  The C file is compiled by gcc.
 
 How about much effort? there _has_ to be some kind of way to
 specify which C library to use.
 

The only work-around I know is documented in (watch the line wrap) 

http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/www\
/db/text/2002/freebsd-current/20021013.freebsd-current

To recap, I can do

f95 -c hello.f90
gcc -v -o hello -nostdlib  \
   /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o \
   /usr/local/lib/NAGWare/quickfit.o hello.o /usr/local/lib/NAGWare/libf96.so\
   -lm \
   /usr/home/karg/tmp/minpack/lib/libc.so \
   /usr/lib/crtend.o /usr/lib/crtn.o

But, the 2nd and 6th lines in the gcc command use the crt* files
from freebsd-current.  The math library, -lm, is also from 
freebsd-current.  /usr/lib/compat does contains neither a 4.x math
library nor the crt* files.  The libc.so in the above is a 
symlink

kargl[274] ldd hello
hello:
libf96.so.1 = /usr/local/lib/NAGWare/libf96.so.1 (0x2806b000)
libm.so.2 = /usr/lib/libm.so.2 (0x2810b000)
libc.so.4 = /usr/lib/compat/libc.so.4 (0x28129000)



-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

Bill Fenner wrote:
   I think most of your 9k of reasoning is based on the thought that
 soreserve() allocates memory.  It doesn't, and never has.

The real problem is the in_pcballoc() in tcp_attach(), which calls
uma_zalloc().

But for mbufs, soreserve allocates space, for potential mbufs, even
though it does not itself allocate mbufs.  I didn't want to go through
the whole state machine to explain the additional failure modes, so I
simplified.

Consider the case where you receive network interrupts for packets
containing data on partially complete, or in-the-process-of sockets,
while you are in the middle of running the NETISR.

This code was not written to be reentrant in the failure case, and
the SYN cache adds this requirement.

The only safe way to do this, with the code unmodified, is to hold
splbio() around the calls, and split the if test I modified into
an if .. if..else .. else if..else.

Even then, it doesn't make one call that give a binary success/fail.

As evidence, I offer that my fix works, too, by changing the order of
operation.  8-).



Note that I'm not complaining about your fix any more than I'm
complaining about mine -- in fact, I have stated repeatedly for
the record that your fix has one less failure mode than my fix,
and should be committed.

Potentially, both of them should be committed (for the SYN cache
disable case, mine suppresses another panic, for the other, yours
suppresses a different panic, and enabled is the common case).

It's just that neither address the real problem, they just suppress
the side effect of a side effect, in different ways.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

Galen Sampson wrote:
  With proper tuning, and some minor patches, 7000/second isn't hard
  to get.
 
  If you add the Duke University version of the Rice University patches
  for LRP, modify the mbuf allocator for static freelisting and then
  pre-populate it, and tune the kernel properly, you should be able to
  get over 20,000 connections per second.  The best I've managed with a
  modified FreeBSD 4.2, before the SYN-cache code, was 32,000/second.
 
 Out of pure curiosity what is the reason that the Duke and Rice patches were
 never incorporated into the base system.  If it really enables the same machine
 to provide 4 times the number of connections this seems like it would be a
 useful thing to include.

To be accurate, it's 3X.  The 4X number requires a different
kernel memory allocator for mbufs, which my employer at the
time did not permit me to publish the code for, though the
idea has plenty of prior art (back to 1992 and DEC WRL).

The current Rice (FreeBSD 4.0) and Duke patches (FreeBSD 4.4)
require executing a technology transfer license in order to be
able to use them commercially; technically, they have license
restrictions incompatible with FreeBSD.

When the code was first offerred to the project (FreeBSD 2.2),
the project never integrated the code.  I don't know why they
didn't make it in, then.

FWIW, I personally dislike the rescon -- Resource Container
-- code in the newer implementation; for embedded devices, it's
not important to account overhead to a particular process, I
think.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

Don Bowman wrote:
 I suspect because of the copyright:
 http://www.cs.rice.edu/CS/Systems/ScalaServer/code/rescon-lrp/README.html
 
 This code is copyrighted software and can NOT be redistributed

That explains why the new code was integrate, not why the old code
wasn't, when it was initially offered by Rice.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD

2002-11-02 Thread walt

Hiten Pandya wrote:

On Sat, Nov 02, 2002 at 10:38:33AM -0800, walt wrote the words in effect of:


Hiten Pandya wrote:


Hmm, OK.

Let me rephrase it all.

I have a 120G IDE disk, which is under LBA mode.  It is the second disk
on my system.  I have been using it with my old (julyish) -current for a
while now as a backup disk thingy.

My disk layout:

	ad1s1: 8997MB  FreeBSD slice
	ad1s3: 50995MB FreeBSD slice
	ad1s2: 54478MB FAT32 slice


Here you are discussing ad1, which should (I think) be the slave drive
on the first IDE controller.




This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028.  The sizes
are displayed correctly here, but when I try labeling the disk through
sysinstall's Configure-Label, It shows:

Disk: ad3   Partition name: ad3s1   Free: 0 blocks (0MB)
Disk: ad3   Partition name: ad3s3   Free: 102110549 blocks (49858MB)


Here you are discussing ad3, which should be the slave drive on the *second*
IDE controller.

Are you intending to discuss two different physical disks here?  I'm still



Oops, change that ad3 into ad1.


Okay.  Well, I see that just today sysinstall/label.c was updated to correct
an error.  I have no idea if that may be your problem, but errors do creep
in regularly into -CURRENT, so it's possible.

My gut feeling is that your files are still there ready to be used but probably
not with the system you are using now.

I would download a -STABLE installation floppy from the FBSD ftp site and see
if you can use that disklable editor to examine the disk.  If the disklabel
looks correct then you can proceed to install a -STABLE system on that disk
using the *existing* label, and your data should be intact.

If the disklabel still looks bad then you have a bigger problem.  You really
need to save every label somewhere and restore it later if it gets trashed.
I just use a pencil and paper and write it all down and tape the paper to
the computer--very primitive but it's saved my backside more than once ;-)

When fooling with -CURRENT you need to be ready for such disasters, and
often all it takes is a pencil and paper and five minutes of preparation.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: crash with network load (in tcp syncache ?)

2002-11-02 Thread Bill Fenner


I really don't understand why you keep claiming that the SYN cache
changes anything.  Without the SYN cache, tcp_input() calls
sonewconn(so, 0) on receipt of a SYN; with the SYN cache, tcp_input()
calls some syncache function which calls sonewconn(so, SS_ISCONNECTED)
on receipt of a SYN/ACK.  In either case, it's with the same interrupt
level, etc -- you are in the middle of processing a packet that was
received by tcp_input().

So, you're saying that what we're hitting is a design flaw in 4BSD
and that this problem has been there since day one?

  Bill

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

2002-11-02 Thread Matthew N. Dodd

On Sat, 2 Nov 2002, Mark Murray wrote:
 This shouldn't be a problem. The commercial software Should Not Be(tm)
 supporting something as variable as CURRENT, and with the STABLE libraries
 around in COMPAT mode, the compiler Will Just Work(tm) (or should with
 not much effort).

 By the time __sF is mainstream, I guess the vendor will have adapted
 their product to match. Win, win.

This isn't the case for one piece of vendor software that I'm not allowed
to talk about.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: CNet CNWLC-811 (PRISM2), kernel panic

In message: [EMAIL PROTECTED]
Frode Nordahl [EMAIL PROTECTED] writes:
: With OLDCARD it does not crash!

I'll answer this twice...

Can I ask you to do the following:

pccardc pccard_mem
pccardc pccard_mem 0xf800
pccardc dumpcis

(well, where 0xf800 is the same address that NEWCARD reported it
was using for ccb bridge).

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: CNet CNWLC-811 (PRISM2), kernel panic

In message: [EMAIL PROTECTED]
Frode Nordahl [EMAIL PROTECTED] writes:
: I get the following output from the driver:
: wi0 at port 0x240-0x27f irq 11 slot 1 on pccard1
: wi0: timeout in wi_cmd 0x; event status 0x
: wi0: timeout in wi_cmd 0x; event status 0x
: wi0: timeout in wi_cmd 0x; event status 0x
: wi0: init failed
: wi0: timeout in wi_cmd 0x0021; event status 0x
: wi0: timeout in wi_cmd 0x0021; event status 0x
: wi0: mac read failed 5
: device_probe_and_attach: wi0 attach returned 5

This tells me that the wi driver likely doesn't support this (or 0x240
isn't a good place to put it, you might try 0x300 instead)...

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
 On Sat, 2 Nov 2002, Mark Murray wrote:
  This shouldn't be a problem. The commercial software Should Not Be(tm)
  supporting something as variable as CURRENT, and with the STABLE libraries
  around in COMPAT mode, the compiler Will Just Work(tm) (or should with
  not much effort).
 
  By the time __sF is mainstream, I guess the vendor will have adapted
  their product to match. Win, win.
 
 This isn't the case for one piece of vendor software that I'm not allowed
 to talk about.
 

See the new WANT_COMPAT4_STDIO make.conf knob.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

2002-11-02 Thread Matthew N. Dodd

On Sat, 2 Nov 2002, Steve Kargl wrote:
 On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
  This isn't the case for one piece of vendor software that I'm not allowed
  to talk about.

 See the new WANT_COMPAT4_STDIO make.conf knob.

This won't be acceptable as the vender will likely not be producing a
separate 5.0 build (ie the same build needs to run on both.) until 4.x is
EOLed.  Forcing people to rebuild libc seems a high barrier to entry.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 12:22:38PM -0800, Steve Kargl wrote:
 
 The verbose compiler output is below.  Note,
 that the crt* files are also 5.x instead of
 4.x.  Maybe it's just good fortune, but NAG's
 f95 compiler works great on 5.x (except for
 the __sF snafu).

Yes. The knob may help you now, but there's no guarantee that you'll
get hosed later on. Probably the easiest *real* solution would be
to build gcc on a 4.x machine and have it installed under /usr/local.
It will have a FQ name like i386-unknown-freebsd4.0-gcc. That version
has default paths for both includes and libraries in the gcc tree
rooted under /usr/local. You can populate that tree with headers and
libraries found on 4.x machine and then move it over (or NFS export
it) to your 5.x box.

In short: you've set yourself up for crossbuilding...

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 06:36:31PM -0500, Matthew N. Dodd wrote:
 On Sat, 2 Nov 2002, Steve Kargl wrote:
  On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
   This isn't the case for one piece of vendor software that I'm not allowed
   to talk about.
 
  See the new WANT_COMPAT4_STDIO make.conf knob.
 
 This won't be acceptable as the vender will likely not be producing a
 separate 5.0 build (ie the same build needs to run on both.) until 4.x is
 EOLed.  Forcing people to rebuild libc seems a high barrier to entry.
 

Maybe I misunderstand you.  But, a person running FreeBSD 5.x,
who wants to runs this vendor's 4.x software, will need to
build their libc with WANT_COMPAT4_STDIO defined if this
product needs to see __sF.

This is my exact problem.  I have NAG's Fortran 95 compiler,
which was built for FreeBSD 4.2.  I ran it on 5.0 without a
problem until __sF was made static.  NAG may never release
a 5.x version of their compiler because it may not be cost
effective.  This is a compromise to move forward with the
elimination of the visibility of __sF.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: speed of -CURRENT [was: questions about the state of current

2002-11-02 Thread Conrad Sabatier


On 30-Oct-2002 Stijn Hoop wrote:
 On Wed, Oct 30, 2002 at 07:48:14AM -0500, Alexander Kabaev wrote:
  I am experiencing a really noticable slower startup time on my very
  recent-CURRENT laptop for almost all programs. The problem seems to be
  in getting info in the cache, because it disappears when I start the
  same program again.
 
 This almost certainly is caused by the 'ioslow' addition to
 specfs_vnops.c. Find a block in specfs_strategy function which goes into
 tsleep for niced processes and comment it out. Let us know if that helps
 :)
 
 Yes, that's it. -CURRENT actually feels snappier than -STABLE now :)

I have to agree.  Until I did this, MP3 playback (using mpg123) was
horribly choppy at times.  Now it's running *much* smoother.

-- 
Conrad Sabatier [EMAIL PROTECTED]

I get up each morning, gather my wits.
Pick up the paper, read the obits.
If I'm not there I know I'm not dead.
So I eat a good breakfast and go back to bed.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD

On Sat, Nov 02, 2002 at 02:42:41PM -0800, walt wrote the words in effect of:
 
 Okay.  Well, I see that just today sysinstall/label.c was updated to correct
 an error.  I have no idea if that may be your problem, but errors do creep
 in regularly into -CURRENT, so it's possible.
 
 My gut feeling is that your files are still there ready to be used but probably
 not with the system you are using now.
 
 I would download a -STABLE installation floppy from the FBSD ftp site and see
 if you can use that disklable editor to examine the disk.  If the disklabel
 looks correct then you can proceed to install a -STABLE system on that disk
 using the *existing* label, and your data should be intact.
 
 If the disklabel still looks bad then you have a bigger problem.  You really
 need to save every label somewhere and restore it later if it gets trashed.
 I just use a pencil and paper and write it all down and tape the paper to
 the computer--very primitive but it's saved my backside more than once ;-)
 
 When fooling with -CURRENT you need to be ready for such disasters, and
 often all it takes is a pencil and paper and five minutes of preparation.

Yup.  Anyway, no one to blame, because I was aware it -current was gonna
punish me one day anyway, so. no regrets.  I will try your method out
anyway.  Lets see how it goes. :)

Thanks again.

-- 
Hiten Pandya
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

2002-11-02 Thread Juli Mallett

* De: Matthew N. Dodd [EMAIL PROTECTED] [ Data: 2002-11-02 ]
[ Subjecte: Re: __sF ]
 On Sat, 2 Nov 2002, Steve Kargl wrote:
  On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
   This isn't the case for one piece of vendor software that I'm not allowed
   to talk about.
 
  See the new WANT_COMPAT4_STDIO make.conf knob.
 
 This won't be acceptable as the vender will likely not be producing a
 separate 5.0 build (ie the same build needs to run on both.) until 4.x is
 EOLed.  Forcing people to rebuild libc seems a high barrier to entry.

Not making a clean break by default (i.e. not requiring a rebuild to get
the backwards behaviour) causes this to cascade.

But it worked in 4.x = Well then by golly it will in 5.0!
But it works in 5.0 = Then we'll keep it around for 5.x
But it worked in 5.x! = We'll make it tunable (on), but have rtld whine!
But it worked in 6.0, despite that rtld bug!

etc.

Look how long it took Microsoft to deprecate MS DOS apps.  It took until
they switched to an entirely new kernel (for the product line) and rebadged
the hell out of it.

I much prefer the idea of move onward, provide a backward solution if someone
really needs it...  Would it satisfy you to see a port, h0h0libc?

Solutions like that can't be guaranteed to work for (N+X).0 systems, to provide
vendor _libraries_ to link in a non-cross environment, where N is the system
the libraries are for, and where X is some number greater than one.

Keep in mind this only affects linking a closed library, and that this situation
is a bit absurd, given that a reasonable solution exists, and if necessary,
can be packaged up nicely...  Developers using this sort of environment are
asking for trouble.  It seems to me a serious developer will develop where the
tools are working and supported (keep in mind this is a issue with a vendor
LIBRARY being LINKED in, not a TOOL being USED), or set up a proper cross-env
to target the platform where the library is targettted, or will force their
vendor to support the new platform they (for whatever reason) see fit to
develop on.

[ I promise the rest of this won't be something someone will try to construe
  as a bikeshed. ]

juli.
--
Juli Mallett [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Upgrading 4.7-stable to -current question

2002-11-02 Thread Conrad Sabatier


On 02-Nov-2002 Ned Wolpert wrote:
 Folks-
 
   I've ran into problem upgrading to -current from RELENG_4 after the
 'make installkernel' process.  One the kernel was installed, I rebooted.
 However, the old 4.7 kernel was loaded instead of the new -current
 kernel.  I read from the archive about how the old /modules directory
 can cause problems, when loading the 5.x kernel, but that's not the
 issue since the wrong kernel was loaded in the first place.  Now, when I
 forced /boot/kernel/kernel, the system failed completely. (No error
 message, the loading never occurred as the whole system froze.)  Could
 that have been from the old /modules directory?
 
   Anyways, the question is when doing an upgrade, what's the best method
 to update the loader?  It isn't installed by default. (From what I could
 tell)

Read the UPDATING file very carefully.  You'll see that one of the steps in
upgrading from 4.x to 5.0 is updating the boot blocks.

-- 
Conrad Sabatier [EMAIL PROTECTED]

Given the choice between accomplishing something and just lying
around, I'd rather lie around.  No contest.
-- Eric Clapton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: CNet CNWLC-811 (PRISM2), kernel panic

On Sun, 2002-11-03 at 00:16, M. Warner Losh wrote:
 pccardc pccard_mem

# pccardc pccardmem
PCCARD Memory address set to 0xd

 pccardc pccard_mem 0xf800

# pccardc pccardmem 0xf800
PCCARD Memory address set to 0xf800

 pccardc dumpcis

# pccardc pccardmem
PCCARD Memory address set to 0xf800


# pccardc dumpcis
Configuration data for card in slot 1
Tuple #1, code = 0x17 (Attribute memory descriptor), length = 3
000:  d9 01 ff
Attribute memory device information:
Device number 1, type Function specific, WPS = ON
Speed = 250nS, Memory block size = 2Kb, 1 units
Tuple #2, code = 0x1d (Other conditions for attribute memory), length =
4
000:  01 d9 01 ff
(MWAIT)
Tuple #3, code = 0x20 (Manufacturer ID), length = 4
000:  00 00 00 00
PCMCIA ID = 0x0, OEM ID = 0x0
Tuple #4, code = 0x21 (Functional ID), length = 2
000:  06 00
Network/LAN adapter
Tuple #5, code = 0x15 (Version 1 info), length = 39
000:  05 00 4f 45 4d 00 31 31 4d 62 70 73 20 57 69 72
010:  65 6c 65 73 73 20 4c 41 4e 20 50 43 20 43 61 72
020:  64 20 56 2d 33 00 ff
Version = 5.0, Manuf = [OEM], card vers = [11Mbps Wireless LAN
PC Card V-3]
Tuple #6, code = 0x1a (Configuration map), length = 6
000:  01 02 00 08 03 ff
Reg len = 2, config register addr = 0x800, last config = 0xff
Registers: XX-- 1 bytes in subtuples
Tuple #7, code = 0x1b (Configuration entry), length = 15
000:  c1 81 9d 71 55 2e 2e 2d fc 14 45 10 b8 ff 20
Config index = 0x1(default)
Interface byte = 0x81 (I/O)  wait signal supported
Vcc pwr:
Nominal operating supply voltage: 5 x 1V
Max current average over 1 second: 2.5 x 100mA
Max current average over 10 ms: 2.5 x 100mA
Power down supply current: 2.5 x 10mA
Wait scale Speed = 1.2 x 10 us
Card decodes 5 address lines, limited 8/16 Bit I/O
IRQ modes:
IRQs:  3 4 5 7 8 9 10 11 12 13 14 15
Max twin cards = 0
Misc attr: (Power down supported)
Tuple #8, code = 0xff (Terminator), length = 0
2 slots found


 
 (well, where 0xf800 is the same address that NEWCARD reported it
 was using for ccb bridge).
 
 Warner



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 04:19:10PM -0800, Juli Mallett wrote:
 
 Keep in mind this only affects linking a closed library, and that this
 situation is a bit absurd, given that a reasonable solution exists, and
 if necessary, can be packaged up nicely...

A bit absurd?  Can you explain why it is absurb and can you
give me the reasonable solution that you have?

 Developers using this sort of environment are asking for trouble.  It
 seems to me a serious developer will develop where the tools are working
 and supported (keep in mind this is a issue with a vendor LIBRARY being
 LINKED in, not a TOOL being USED),

The TOOL was working fine until __sF was made static.

 or set up a proper cross-env to target the platform where the library
 is targettted

This is what I guess we'll have to do.

 or will force their vendor to support the new platform they
 (for whatever reason) see fit to develop on.

Force the vendor to support the new platform?  No, this will
most likely cause the vendor to abandon the FreeBSD platform.
So much for encouraging commercial support for FreeBSD.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

In message: [EMAIL PROTECTED]
Steve Kargl [EMAIL PROTECTED] writes:
: On Sat, Nov 02, 2002 at 09:47:26AM -0800, Kris Kennaway wrote:
:  On Sat, Nov 02, 2002 at 10:35:03AM -0500, Adam K Kirchhoff wrote:
:  
:   So is the current position on the matter that __sF is going to remain out
:   of libc?
:  
:  Yes.
:  
: 
: This will break some commercially available software that
: can't easily replaced.
: 
: kargl[248] f95 -V a.f90
: NAGWare Fortran 95 compiler Release 4.2(468)
: Copyright 1990-2002 The Numerical Algorithms Group Ltd., Oxford, U.K.
: f95comp version is 4.2(468)
: /usr/local/lib/NAGWare/libf96.so: undefined reference to `__sF'
: collect2: ld returned 1 exit status
: 
: I seriously doubt that NAG will support both a 
: 4.x and 5.x version of their compiler.

Then you should force it to link with libc.so.4.  That's the version
of libc that it build libf96.so against, so you are taking a big
chance having it use libc.so.5.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Upgrading 4.7-stable to -current question

2002-11-02 Thread Ned Wolpert

On Sat, 2002-11-02 at 17:20, Conrad Sabatier wrote:
 Read the UPDATING file very carefully.  You'll see that one of the steps in
 upgrading from 4.x to 5.0 is updating the boot blocks.

Yes, there are several entries.  2615 is the most interesting:

In addition, you'll need to update your boot blocks to a
more modern version, if you haven't already done so.  Modern
here means 4.0 release or newer (although older releases
may work).

Now, my system was installed around 4.4, so I should not need to
update my boot blocks.  Correct?

Getting back to my original question, the problem I was having was with
the loader itself.  Now, do I have to execute this step (from the
UPDATING document) 
cd src/sys/boot ; make install
Reason why I ask is because my loader is from 4.4, so it should work.
(Provided I do a 
ok unload
ok boot /boot/kernel/kernel
manually)  As the UPDATING doc mentions, upgrading from 4.x to 5.x needs
that step to avoid those extra steps, yes? But it should still boot if I
unload and load manually, correct?  I guess the real question was that
if this is the case, it didn't boot into /boot/kernel/kernel at that
point either... after the unload and boot steps above.  Could that have
occurred because I still had the old /modules directory?

-- 

Virtually, 
Ned Wolpert [EMAIL PROTECTED] 4e75




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

In message: [EMAIL PROTECTED]
Steve Kargl [EMAIL PROTECTED] writes:
: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1755928+1759974+/usr/local/\
: www/db/text/2002/freebsd-current/20021013.freebsd-current

You should be linking against the -stable versions of these items as
well as the libc.so.4.  If you don't, then you are asking for
problems.  Maybe you can kludge it to make libc.so.5 work, but the
whole reason that it is .5 and not .4 is that it is not binary
compatible with .4, and for more reasons than just __sF.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

In message: [EMAIL PROTECTED]
Steve Kargl [EMAIL PROTECTED] writes:
: On Sat, Nov 02, 2002 at 06:15:09PM -0500, Matthew N. Dodd wrote:
:  On Sat, 2 Nov 2002, Mark Murray wrote:
:   This shouldn't be a problem. The commercial software Should Not Be(tm)
:   supporting something as variable as CURRENT, and with the STABLE libraries
:   around in COMPAT mode, the compiler Will Just Work(tm) (or should with
:   not much effort).
:  
:   By the time __sF is mainstream, I guess the vendor will have adapted
:   their product to match. Win, win.
:  
:  This isn't the case for one piece of vendor software that I'm not allowed
:  to talk about.
:  
: 
: See the new WANT_COMPAT4_STDIO make.conf knob.

But that knob is a total kludge and *WRONG* for this case.  It lets
things link, but you are still cross threading 4.x and 5.x binaries,
which is asking to be shot in the foot.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

In message: [EMAIL PROTECTED]
Steve Kargl [EMAIL PROTECTED] writes:
: Maybe I misunderstand you.  But, a person running FreeBSD 5.x,
: who wants to runs this vendor's 4.x software, will need to
: build their libc with WANT_COMPAT4_STDIO defined if this
: product needs to see __sF.

All that kludge does is to allow a program that shouldn't be allowed
to link to link.  You need to setup to compile 4.x binaries on the 5.x
machine, or you will lose in the long run.  __sF is only the first of
many issues, some subtle, that you'll face cross-threading 4.x and 5.x
libraries.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Upgrading 4.7-stable to -current question

2002-11-02 Thread Conrad Sabatier


On 03-Nov-2002 Ned Wolpert wrote:
 On Sat, 2002-11-02 at 17:20, Conrad Sabatier wrote:
 Read the UPDATING file very carefully.  You'll see that one of the steps
 in upgrading from 4.x to 5.0 is updating the boot blocks.
 
 Yes, there are several entries.  2615 is the most interesting:
 
 In addition, you'll need to update your boot blocks to a
 more modern version, if you haven't already done so.  Modern
 here means 4.0 release or newer (although older releases
 may work).
 
 Now, my system was installed around 4.4, so I should not need to
 update my boot blocks.  Correct?

Mmm, perhaps not.  :-)

 Getting back to my original question, the problem I was having was with
 the loader itself.  Now, do I have to execute this step (from the
 UPDATING document) 
 cd src/sys/boot ; make install

Yes, that's the one I was thinking of, actually.  Had a little slip of the
brain there.  :-)

 Reason why I ask is because my loader is from 4.4, so it should work.
 (Provided I do a 
 ok unload
 ok boot /boot/kernel/kernel
 manually)  As the UPDATING doc mentions, upgrading from 4.x to 5.x needs
 that step to avoid those extra steps, yes? But it should still boot if I
 unload and load manually, correct?  I guess the real question was that
 if this is the case, it didn't boot into /boot/kernel/kernel at that
 point either... after the unload and boot steps above.  Could that have
 occurred because I still had the old /modules directory?

I do think this last step (make install in sys/boot) is an absolute must
to boot the new kernel.  Someone may correct me, but that's the impression I
got from reading the docs.

Myself, I played it ultra-safe and followed the upgrade instructions to the
letter, including moving the 4.x modules to a different directory.  The
upgrade went off without a single gotcha.

-- 
Conrad Sabatier [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Upgrading 4.7-stable to -current question

2002-11-02 Thread Ned Wolpert

On Sat, 2002-11-02 at 17:58, Conrad Sabatier wrote:

  Now, my system was installed around 4.4, so I should not need to
  update my boot blocks.  Correct?
 
 Mmm, perhaps not.  :-)

Eh, at this rate, I might as well...
 
 Myself, I played it ultra-safe and followed the upgrade instructions to the
 letter, including moving the 4.x modules to a different directory.  The
 upgrade went off without a single gotcha.

Perhaps I shouldn't try and play games.  I'd like a 'way out' where I
could return to 4.x since I'm experimenting with my desktop (not one of
my servers, of course), but at this rate, Damn the torpedoes, full
steam ahead!

Now, um, where did I put that backup tape...   ;-)

-- 

Virtually, 
Ned Wolpert [EMAIL PROTECTED] 4e75




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: ... could sleep with pcm0 locked from ...

2002-11-02 Thread Doug Barton

Our pcm maintainer is aware of this problem, and is working on the
solution. It's expected before 5.0-Release.

HTH,

Doug

-- 
   We have known freedom's price. We have shown freedom's power.
  And in this great conflict, ...  we will see freedom's victory.
- George W. Bush, President of the United States
  State of the Union, January 28, 2002

 Do YOU Yahoo!?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: What is user uucp good for?

2002-11-02 Thread Kris Kennaway

On Sat, Nov 02, 2002 at 04:11:39PM +1030, Greg 'groggy' Lehey wrote:
 Now that uucp is no longer in the base system, is there any reason to
 keep user uucp in /usr/src/etc/master.passwd?

A number of base system utilities and ports still use it for access to
the serial port devices (which are owned by the uucp user).  Really,
the uucp user is now misnamed and should be called something like
serial or dialer.

Kris



msg45978/pgp0.pgp
Description: PGP signature

Re: Minimal install

2002-11-02 Thread Jun Kuriyama

At Sat, 2 Nov 2002 19:07:33 + (UTC),
M. Warner Losh [EMAIL PROTECTED] wrote:
 I'm downloading current snapshots.  I was wondering what the minimum
 set of files I needed to download to do a minimal install.  I'm
 guessing just floppies, base, or maybe floppies, base and crypto. (I'm
 installing on pc98 machine, so need floppies).

I think latter.  You can check by selecting Custom after selecting
Minimal.


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
 [EMAIL PROTECTED] // FreeBSD Project

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 03:58:14PM -0800, Steve Kargl wrote:
  
   See the new WANT_COMPAT4_STDIO make.conf knob.
  
  This won't be acceptable as the vender will likely not be producing a
  separate 5.0 build (ie the same build needs to run on both.) until 4.x is
  EOLed.  Forcing people to rebuild libc seems a high barrier to entry.
  
 
 Maybe I misunderstand you.  But, a person running FreeBSD 5.x,
 who wants to runs this vendor's 4.x software, will need to
 build their libc with WANT_COMPAT4_STDIO defined if this
 product needs to see __sF.

No; you're mixing things up. The compat4x stuff we have now allows
you to run 4.x binaries on 5.x. The problem that WANT_COMPAT4_STDIO
addresses is *compiling* 4.x compatible programs on 5.x! A world
of difference.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: __sF

On Sat, Nov 02, 2002 at 08:42:57PM -0800, Marcel Moolenaar wrote:
 On Sat, Nov 02, 2002 at 03:58:14PM -0800, Steve Kargl wrote:
   
See the new WANT_COMPAT4_STDIO make.conf knob.
   
   This won't be acceptable as the vender will likely not be producing a
   separate 5.0 build (ie the same build needs to run on both.) until 4.x is
   EOLed.  Forcing people to rebuild libc seems a high barrier to entry.
   
  
  Maybe I misunderstand you.  But, a person running FreeBSD 5.x,
  who wants to runs this vendor's 4.x software, will need to
  build their libc with WANT_COMPAT4_STDIO defined if this
  product needs to see __sF.
 
 No; you're mixing things up. The compat4x stuff we have now allows
 you to run 4.x binaries on 5.x. The problem that WANT_COMPAT4_STDIO
 addresses is *compiling* 4.x compatible programs on 5.x! A world
 of difference.
 

I just looked through /usr/lib on the 4.7 live ISO.  We are
missing a bunch of libraries.  See another post with the list.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Ghost of __sF and COMPAT4X libraries.

Since I appear to one the few people caught by the __sF and commercial
software broken by staticizing __sF, I decided to look at the 4.7
live filesystem ISO image to see what I would need to build a proper
set of libraries.  Here is a summary of what I found.

List of shared libraries in 4.7 not included in COMPAT4X.

libacl.so.3  libalias.so.4 libasn1.so.5libatm.so.2
libbz2.so.1  libcalendar.so.2  libcam.so.2 libcipher.so.2
libcom_err.so.2  libcrypt.so.2 libcrypto.so.2  libdes.so.3
libdevstat.so.2  libdialog.so.4libfetch.so.3   libform.so.2
libftpio.so.5libg2c.so.1   libgmp.so.3 libgnuregex.so.2
libgssapi.so.5   libhdb.so.5   libhistory.so.4 libipsec.so.1
libipx.so.2  libisc.so.1   libkadm.so.3libkadm5clnt.so.5
libkadm5srv.so.5 libkafs.so.3  libkdb.so.3 libkrb.so.3
libkrb5.so.5 libkvm.so.2   libm.so.2   libmd.so.2
libmenu.so.2 libmilter.so.2libmp.so.3  libncp.so.1
libncurses.so.5  libnetgraph.so.1  libopie.so.2libpanel.so.2
libpcap.so.2 libposix1e.so.2   libradius.so.1  libreadline.so.4
libroken.so.5librpcsvc.so.2libskey.so.2libsmb.so.1
libssh.so.2  libssl.so.2   libtacplus.so.1 libusbhid.so.0
libutil.so.3 libvgl.so.2   libwrap.so.3libxpg4.so.3
libz.so.2
 
libgcc.a on 4.7 contains references to __sF.  There is no libgcc.so.



The following libraries are installed by COMPAT4X, but are not
present in 4.7.  I assume these are carried forward from 4.x x  7.

libssl.so.1  libusb.so.0   libcrypto.so.1  libfetch.so.2



The following 4.7 libs make reference to __sF.  Several of the
corresponding 5.0 libraries still have the same version number.
We may need to bump the version numbers.

libalias.so.4libbz2.so.1   libc.so.4libc_r.so.4
libcam.so.2  libcom_err.so.2   libcrypto.so.2   libdes.so.3
libdevstat.so.2  libdialog.so.4libedit.so.3 libfetch.so.3
libftpio.so.5libg2c.so.1   libgmp.so.3  libhistory.so.4
libipsec.so.1libisc.so.1   libkdb.so.3  libkrb.so.3
libkrb5.so.5 libkvm.so.2   libm.so.2libmp.so.3
libncp.so.1  libncurses.so.5   libopie.so.2 libpam.so.1
libpcap.so.2 libperl.so.3  libreadline.so.4 libroken.so.5
libskey.so.2 libsmb.so.1   libssh.so.2  libstdc++.so.3
libutil.so.3

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Ghost of __sF and COMPAT4X libraries.

On Sat, Nov 02, 2002 at 09:59:16PM -0800, Steve Kargl wrote:
 
 The following libraries are installed by COMPAT4X, but are not
 present in 4.7.  I assume these are carried forward from 4.x x  7.
 
 libssl.so.1  libusb.so.0   libcrypto.so.1  libfetch.so.2

G... This means we had version bumps on -stable without
providing compat4x libraries on 4.x - I think we're seriously
fscking up here :-(

 The following 4.7 libs make reference to __sF.  Several of the
 corresponding 5.0 libraries still have the same version number.
 We may need to bump the version numbers.
 
 libalias.so.4libbz2.so.1   libc.so.4libc_r.so.4
 libcam.so.2  libcom_err.so.2   libcrypto.so.2   libdes.so.3
 libdevstat.so.2  libdialog.so.4libedit.so.3 libfetch.so.3
 libftpio.so.5libg2c.so.1   libgmp.so.3  libhistory.so.4
 libipsec.so.1libisc.so.1   libkdb.so.3  libkrb.so.3
 libkrb5.so.5 libkvm.so.2   libm.so.2libmp.so.3
 libncp.so.1  libncurses.so.5   libopie.so.2 libpam.so.1
 libpcap.so.2 libperl.so.3  libreadline.so.4 libroken.so.5
 libskey.so.2 libsmb.so.1   libssh.so.2  libstdc++.so.3
 libutil.so.3

Yes, definitely. That's the problem with low-level ABI changes
to symbols that leak like runny noses :-/

I think you have an excellent point now that I realize to what
extend we're ignorant to the consequences of our actions :-(
Moi aussi :-/

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Ghost of __sF and COMPAT4X libraries.

2002-11-02 Thread Kris Kennaway

On Sat, Nov 02, 2002 at 11:05:18PM -0800, Marcel Moolenaar wrote:
 On Sat, Nov 02, 2002 at 09:59:16PM -0800, Steve Kargl wrote:
  
  The following libraries are installed by COMPAT4X, but are not
  present in 4.7.  I assume these are carried forward from 4.x x  7.
  
  libssl.so.1  libusb.so.0   libcrypto.so.1  libfetch.so.2
 
 G... This means we had version bumps on -stable without
 providing compat4x libraries on 4.x - I think we're seriously
 fscking up here :-(

libssl and libcrypto were bumped in -stable (about a year ago), and
the old versions were added to COMPAT4x on -stable (and -current).
There is no problem here; I don't know about the others.

Kris


msg45985/pgp0.pgp
Description: PGP signature

Re: Ghost of __sF and COMPAT4X libraries.