Re: So, AGAIN, why was tcpdump moved?
Just out of curiosity, why is there an "AGAIN" in the subject line, since this is the first email I've gotten on the subject? tcpdump is capable of decrypting ESP, if you give it the key and if it's linked with libcrypto. Since IPSEC is part of FreeBSD, and libcrypto is part of FreeBSD, I figured it would be a nice thing to have. It didn't occur to me that this would change where tcpdump lived (i.e. it seemed like libcrypto was part of FreeBSD) so it wasn't an explicit choice on my part to move distributions. I agree that's a bad side effect. It's easy to disable the decrypting-ESP feature if the disadvantage of having it is greater than the advantage. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, AGAIN, why was tcpdump moved?
Just out of curiosity, why is there an "AGAIN" in the subject line, since this is the first email I've gotten on the subject? Sorry, the first queries about this probably didn't go directly to you since it was only yesterday that I actually bothered to go track down the specific commit which resulted in this behavior in 4.0-RELEASE. There's been general mutterings but no conclusions. tcpdump is capable of decrypting ESP, if you give it the key and if it's linked with libcrypto. Since IPSEC is part of FreeBSD, and libcrypto is part of FreeBSD, I figured it would be a nice thing to have. Agreed. It didn't occur to me that this would change where tcpdump lived (i.e. it seemed like libcrypto was part of FreeBSD) so it wasn't an explicit choice on my part to move distributions. I agree that's a bad side effect. It's easy to disable the decrypting-ESP feature if the disadvantage of having it is greater than the advantage. I think most people are pretty flabbergasted that tcpdump is gone from the bindist, so yes, we should definitely see to this side-effect. That said, isn't there some way we could build it twice, once for the crypto dist and once for the bindist? That would mean that the crypto distribution copy simply blops over the bin distribution version if selected and POLA is fully obeyed. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, AGAIN, why was tcpdump moved?
On Friday, March 31, 2000, Bill Fenner wrote: It didn't occur to me that this would change where tcpdump lived (i.e. it seemed like libcrypto was part of FreeBSD) so it wasn't an explicit choice on my part to move distributions. I agree that's a bad side effect. It's easy to disable the decrypting-ESP feature if the disadvantage of having it is greater than the advantage. Well, I believe the disadvantage greatly outweighs the advantage in this situation. On one hand you have a tcpdump that can decrypt ESP and on the other you have systems that don't have tcpdump because they didn't install crypto. -- |Chris Costello [EMAIL PROTECTED] |Managing programmers is like herding cats. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, AGAIN, why was tcpdump moved?
That said, isn't there some way we could build it twice, once for the crypto dist and once for the bindist? That would mean that the crypto distribution copy simply blops over the bin distribution version if selected and POLA is fully obeyed. Sounds perfectly reasonable to me. I'd be happy if someone else wants to look at this, or I can look at it on the 10th when I get back from Australia. This would mean there's a src/secure/usr.sbin/tcpdump that builds with crypto and src/usr.sbin/tcpdump that builds without? Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, AGAIN, why was tcpdump moved?
Sounds perfectly reasonable to me. I'd be happy if someone else wants to look at this, or I can look at it on the 10th when I get back from Australia. This would mean there's a src/secure/usr.sbin/tcpdump that builds with crypto and src/usr.sbin/tcpdump that builds without? Correct! Both would share some common set of sources with VPATH directives and install conditionally on some boolean set of variable tests where one would always succeed and one always fail unless it was the distribute target being invoked, in which case both would install with different values for DISTRIBUTION and not collide. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP buildworld times / performance tests
In message [EMAIL PROTECTED], Matthew Dillon writes: The general problem with the timecounter is that not only is the hardware indeterminant, but the timecounter structure itself is *NOT* MP safe, at least not by my read of it. Well, read again then :-) I've had a paper in the works about timecounters for over a year now, I should really sit down and finish it. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP buildworld times / performance tests
On Thu, 30 Mar 2000, Matthew D. Fuller wrote: Does softupdates provide faster performance than async/noatime? I keep /usr/src and /usr/obj as such, would it be faster with softupdates? And if so, why? Async is theoretically faster if it is implemented properly. It is poorly implemented in FreeBSD, but is good enough for things like makeworld. From my makeworld logs: async mounts, standard kernel, standard Makefile.inc1, NOSHARED=yes -- elf make world started on Mon Jan 17 12:11:25 EST 2000 elf make world completed on Mon Jan 17 13:23:23 EST 2000 -- 4317.91 real 3237.34 user 636.77 sys 11864 maximum resident set size 1105 average shared memory size 1061 average unshared data size 129 average unshared stack size 9103073 page reclaims 15251 page faults 0 swaps 40230 block input operations 4313 block output operations 0 messages sent 0 messages received 7 signals received 372803 voluntary context switches 198051 involuntary context switches There were only 4313 disk writes for the whole makeworld. This shows that -async is doing a good job of stopping writes going to the disk. 4313 writes is too few too take very long. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP buildworld times / performance tests
In message [EMAIL PROTECTED], Jesper Skriver writes: On the box below, a relative new dual PIII box, with a Intel motherboard, does it use the i8254 or the PIIX timecounter ? [...] Timecounter "PIIX" frequency 3579545 Hz You're using the PIIX. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA library problems
Hello,
On 0, Kris Kennaway [EMAIL PROTECTED] wrote:
On Thu, 23 Mar 2000, Paul Richards wrote:
I stuck a dlerror() in there and the problem is
usr/lib/librsaINTL.so: Undefined symbol "BN_mod_exp_mont"
This symbol is defined in bn_ext.c and should be compiled into libcrypto -
can you verify yours has it?
Kris
I had the same problem. "BN_mod_exp_mont" is in libcrypto,but isn't
visible from librsaINTL.so because libcrypto is loaded in conjunction
with the load of /usr/local/libexec/apache/libssl.so via dlopen() .
The man page to dlopen states " The symbols exported by objects added
to the address space by dlopen() can be accessed only through calls
to dlsym()".
I have solved the problem with the attached patch. It adds libcrypto
to the list of linked libs.
Maybe there is a better solution,who knows ?
Regards
Dirk
Index: Makefile
===
RCS file: /usr/current/src/secure/lib/librsaintl/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- Makefile2000/03/13 21:50:37 1.2
+++ Makefile2000/03/31 09:37:12
@@ -9,6 +9,7 @@
SHLIB_MAJOR= 1
CFLAGS+= -I${.OBJDIR}
+LDADD+=-lcrypto
# rsaref
SRCS+= rsa_err.c rsa_eay.c rsa_intlstubs.c
Re: So, AGAIN, why was tcpdump moved?
On Fri, 31 Mar 2000, Bill Fenner wrote: Just out of curiosity, why is there an "AGAIN" in the subject line, since this is the first email I've gotten on the subject? First I've heard about it too. It didn't occur to me that this would change where tcpdump lived (i.e. it seemed like libcrypto was part of FreeBSD) so it wasn't an explicit choice on my part to move distributions. I agree that's a bad side effect. It's easy to disable the decrypting-ESP feature if the disadvantage of having it is greater than the advantage. AFAIK there were two versions built, one which ends up in the bin distribution and one in the crypto distribution (I believe ppp also does this to take advantage of crypto support if it's available). Both versions of tcpdump are built from the same place (usr.sbin/tcpdump where it's always been), and so theres no need to have two separate copies of the build infrastructure (e.g. the proposed extra one in secure/). There *were* several problems with the .ifdefs in the tcpdump makefile which I fixed prior to 4.0, and I thought I had fixed the problem of tcpdump in the bin distribution being linked against libcrypto (this was broken in the initial 4.0 Release but fixed when jkh rereleased it). If I screwed something up I apologise - I didn't test the outcome of a full make release. I just looked at the makefile again - am I misinterpreting the following: .if exists(../../../secure) !defined(NOCRYPT) !defined(NOSECURE) \ !defined(NO_OPENSSL) !defined(RELEASE_CRUNCH) DISTRIBUTION=crypto ... .endif which I interpret as saying "if we're building release and making the bin distribution (NOCRYPT) then don't build the crypto stuff, and leave us in the bin distribution, but if we're not building NOCRYPT then put us in the crypto distribution and build the extra bits". This is the same thing usr.sbin/ppp does as far as I can see (it was copied directly from there). What did I miss? Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, AGAIN, why was tcpdump moved?
There *were* several problems with the .ifdefs in the tcpdump makefile which I fixed prior to 4.0, and I thought I had fixed the problem of tcpdump in the bin distribution being linked against libcrypto (this was broken in the initial 4.0 Release but fixed when jkh rereleased it). If I screwed something up I apologise - I didn't test the outcome of a full make release. What you missed is that this pass is done once, in the release.2 target of release/Makefile. Perhaps if you'd also special-cased it in release.5, it might have worked as you expected. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP buildworld times / performance tests
At 5:44 PM -0600 2000/3/30, Matthew D. Fuller wrote: Does softupdates provide faster performance than async/noatime? I keep /usr/src and /usr/obj as such, would it be faster with softupdates? And if so, why? Of course, once you ask this question, the next logical one that follows is "what happens if you do all three?" -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dual Pathing to SCSI/FC devices.
At 10:41 AM +1000 2000/3/31, Carl Makin wrote: heh, the buzzword for this is "Dynamic Failover". :) In management circles where the current focus is on 24x7, this is seen as a distinct advantage. Okay, then I'd certainly like to have that. "Dual Pathing" the buzzword for using both paths to the device would also be desirable, but then you get into things like wanting to optimise data paths depending on how busy each path is. Ahh, right. Basically you're talking about active/active load balancing. Yup, I'd like to have that, too. No, sorry. I can't actually say what box we're buying yet since we haven't signed the contract. :( You may be fortunate -- we were stupid enough to sign a three year lease on equipment we thought would do the job, but are now having some problems with. ;-( -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: So, AGAIN, why was tcpdump moved?
On Fri, 31 Mar 2000, Jordan K. Hubbard wrote: What you missed is that this pass is done once, in the release.2 target of release/Makefile. Perhaps if you'd also special-cased it in release.5, it might have worked as you expected. Aha, so I see. I'll commit a fix tomorrow if you don't get there sooner. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reading from bad disk ?
Leif Neland wrote: It seems Warner Losh wrote: ... mount it in front of the drive to get it to run at a reasonable temperature. W/o the fan, it was running at 58C or so. With the fan it runs at 39C or so. I've included the script that I use to find this information out. Ken Merry sent it to me. It works on some IBM drives. Warner #!/bin/sh TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"` TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc` echo "The temperature is: $TEMPF F $TEMPC C" Tried this: #!/bin/sh TEMPC=`camcontrol cmd -v -n da -u 2 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"` TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc` echo "The temperature is: $TEMPF F $TEMPC C" I.e. replaced -u 0 with -u 2, because unit 2 is an IBM: ncr0: ncr 53c810 fast10 scsi port 0xd100-0xd1ff mem 0x2000-0x20ff irq 11 at device 1.0 on pci0 ncr0: driver is using old-style compatability shims da1 at ncr0 bus 0 target 1 lun 0 da0 at ncr0 bus 0 target 0 lun 0 da2 at ncr0 bus 0 target 2 lun 0 da2: IBM DCAS-34330 S65A Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8) da2: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) But I get this: camcontrol: error sending command (pass2:ncr0:0:2:0): LOG SENSE. CDB: 4d 0 76 0 0 0 0 0 20 0 (pass2:ncr0:0:2:0): ILLEGAL REQUEST asc:24,0 (pass2:ncr0:0:2:0): Invalid field in CDB dc: stack empty The temperature is: 33.80 F C Does this simply mean this drive does not support temperature measurement, or should something more be changed to use dev da2 instead of da0? I'm running a week or so old current. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Have had same Problem with my DCAS-34330's. Having a look in IBM's product specification at http://www.storage.ibm.com/techsup/hddtech/prodspec/dcas_spw.pdf, chapter 7.8 and others. It seems there is no information logging in this type of harddisk drive?! Rainer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PicoBSD
The following patch is for -CURRENT. It at least gets past that dumb
floppy loop. The problem I'm having is that after the scripts, nothing
else is done, it just sits there with "Welcome to PicoBSD". Any ideas?
To Luigi: I made the changes you asked for, disregard that patchfile as
I've incorporated those changes in here.
-- snip --
--- /usr/src/release/picobsd/build/Makefile.crunch Tue Feb 8 03:27:55 2000
+++ /usr/src/release/picobsd/build/Makefile.crunch Thu Mar 30 14:28:20 2000
@@ -4,3 +4,3 @@
SRC?=/usr/src
-CRUNCHFLAGS+= -DNOPAM -DRELEASE_CRUNCH -DNOSECURE -DNOCRYPT
+CRUNCHFLAGS+= -DNOPAM -DRELEASE_CRUNCH -DNOSECURE -DNOCRYPT -DNONETGRAPH -DNOIPSEC
@@ -31,12 +31,12 @@
install:
- cp crunch1 /mnt/stand/crunch
- chmod 555 /mnt/stand/crunch
+ cp crunch1 ${MFS_MOUNTPOINT}/stand/crunch
+ chmod 555 ${MFS_MOUNTPOINT}/stand/crunch
for i in `crunchgen -l crunch1.conf` ; \
do \
- ln /mnt/stand/crunch /mnt/stand/$${i}; \
+ ln ${MFS_MOUNTPOINT}/stand/crunch ${MFS_MOUNTPOINT}/stand/$${i}; \
done
- rm /mnt/stand/crunch
+ rm ${MFS_MOUNTPOINT}/stand/crunch
# Install the MIB files
- #mkdir -p /mnt/usr/local/share/snmp/mibs
- #cp ../../net/crunch1/mibs/*.txt /mnt/usr/local/share/snmp/mibs/
+ #mkdir -p ${MFS_MOUNTPOINT}/usr/local/share/snmp/mibs
+ #cp ../../net/crunch1/mibs/*.txt ${MFS_MOUNTPOINT}/usr/local/share/snmp/mibs/
--- /usr/src/release/picobsd/build/buildTue Feb 8 03:24:59 2000
+++ /usr/src/release/picobsd/build/buildThu Mar 30 14:33:40 2000
@@ -75,3 +75,3 @@
-# Main build procedure. It calls another scripts (stage1)
+# Main build procedure. It calls another script (stage1)
main() {
@@ -103,4 +103,5 @@
echo -n "- Cleaning temporary files... "
- umount -f /mnt
- vnconfig -u /dev/rvn0
+ umount -f ${MFS_MOUNTPOINT}
+ rm -rf ${MFS_MOUNTPOINT}
+ vnconfig -u /dev/rvn${VNUM}
./clean ${TYPE}
--- /usr/src/release/picobsd/build/crunch.inc Tue Feb 8 03:29:18 2000
+++ /usr/src/release/picobsd/build/crunch.inc Thu Mar 30 12:04:03 2000
@@ -6 +6,2 @@
NONETGRAPH=yes
+NOIPSEC=yes
--- /usr/src/release/picobsd/build/mfs.mtreeTue Feb 8 06:39:28 2000
+++ /usr/src/release/picobsd/build/mfs.mtreeThu Mar 30 12:04:04 2000
@@ -49,2 +49,8 @@
..
+locale
+..
+syscons
+..
+nls
+..
..
--- /usr/src/release/picobsd/build/stage1 Tue Feb 8 03:25:00 2000
+++ /usr/src/release/picobsd/build/stage1 Thu Mar 30 14:03:27 2000
@@ -10,4 +10,8 @@
+# By default, /tmp should exist.
+#
MFS_NAME=fs.PICOBSD
-MFS_MOUNTPOINT=/mnt
+MFS_MOUNTPOINT=`mktemp -d "/tmp/picobsd.XX"`
+export MFS_MOUNTPOINT
+
# fail errno errcode
@@ -21,3 +25,3 @@
no_vnconfig)
- echo "Error while doing vnconfig of ${MFS_NAME} on /dev/rvn0..."
+ echo "Error while doing vnconfig of ${MFS_NAME} on /dev/rvn${VNUM}..."
echo " Most probably your running kernel doesn't have the vn(4) device."
@@ -28,3 +32,3 @@
no_mount)
- echo "Error while mounting ${MFS_NAME} (/dev/vn0c) on ${MFS_MOUNTPOINT}"
+ echo "Error while mounting ${MFS_NAME} (/dev/vn${VNUM}c) on ${MFS_MOUNTPOINT}"
;;
@@ -40,3 +44,3 @@
vnconfig2)
- echo "Error while doing vnconfig of floppy.img on /dev/rvn0..."
+ echo "Error while doing vnconfig of floppy.img on /dev/rvn${VNUM}..."
;;
@@ -56,2 +60,4 @@
echo "- Aborting $0"
+umount ${MFS_MOUNTPOINT} 2 /dev/null || true
+rm -rf ${MFS_MOUNTPOINT} 2 /dev/null || true
exit 10
@@ -63,5 +69,9 @@
echo "- Preparing MFS filesystem..."
-umount /dev/vn0 2 /dev/null || true
+VNUM=`mount | awk "/vn/ { num++ } END { printf \"%d\", num }"`
+export VNUM
+echo "- Using vn${VNUM}..."
+
+umount /dev/vn${VNUM} 2 /dev/null || true
umount ${MFS_MOUNTPOINT} 2 /dev/null || true
-vnconfig -u /dev/rvn0 2 /dev/null || true
+vnconfig -u /dev/rvn${VNUM} 2 /dev/null || true
@@ -72,3 +82,3 @@
-vnconfig -s labels -c /dev/rvn0 ${MFS_NAME} 2/dev/null || \
+vnconfig -s labels -c /dev/rvn${VNUM} ${MFS_NAME} 2/dev/null || \
fail $? no_vnconfig
@@ -80,9 +90,9 @@
if [ ${MFS_SIZE} -lt 1024 ] ; then
- disklabel -rw /dev/rvn0 fd${MFS_SIZE} || fail $? disklabel
+ disklabel -rw /dev/rvn${VNUM} fd${MFS_SIZE} || fail $? disklabel
else
- disklabel -rw vn0 auto || fail $? disklabel
+ disklabel -rw vn${VNUM} auto || fail $? disklabel
fi
-newfs -i ${MFS_INODES} -m 0 -p 0 -o space /dev/rvn0c
-mount /dev/vn0c ${MFS_MOUNTPOINT} || fail $? no_mount
+newfs -i ${MFS_INODES} -m 0 -p 0 -o space /dev/rvn${VNUM}c
+mount /dev/vn${VNUM}c ${MFS_MOUNTPOINT} || fail $? no_mount
@@ -148,4 +158,4 @@
umount ${MFS_MOUNTPOINT}
-fsck -p /dev/rvn0c
-vnconfig -u
hostcache
I need to store some info (in kernel) indexed by peer hosts ip addresses. in_hostcache.h interface looks good, but i hasn't found any use of it in -CURRENT kernel sources. It this interface obsoleted by other? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
Subject: Mail::Internet test subject This is a test message that was sent by the test suite of Mail::Internet. Testing. one From foo four From bar seven To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Someone can this idiot. On Fri, Mar 31, 2000 at 05:11:34PM +0200, Charlie Root wrote: Subject: Mail::Internet test subject This is a test message that was sent by the test suite of Mail::Internet. Testing. one From foo four From bar seven To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kldload of driver for isa pnp card (cycle two)
Hot days of 4.0 preparation are behind. May be some guru will find the solution for the subject? Two problems are here a) devices without driver attached to 'unknown' driver, thus no orphan devices -- no reason to call device_probe method from kldloaded driver. b) if disable 'unknown' driver as was recommended earlier, device still consume resources, and this resources are not presented to kldloaded driver -- resource leak. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
:The thing is i'm not sure if it's vinum, I could also duplicate this on
:another machine without vinum.. except I duplicated it differently..
:
:Consider the following perl script:
:
:#!/usr/bin/perl
:for ( ; ; ) {
:system("fetch http://www.web.site/index.html");
:}
:
:Of course, replacing the site with something else, but on this one box
:(and the raid), it panic'd the box.. See if you can duplicate this on any
:4.0/5.0 boxes you have, I have tried on both and it worked, however it
:does not crash 3.x boxes..
:
:Try your luck,
:Jason DiCioccio
Ok, I'm a bit confused.
You are running this script on the NFS client while CD'd into an
NFS mount and the NFS server is crashing?
Or are you running this on the NFS server while CD'd into a local
disk mount and the NFS server is crashing?
I presume the web site you are fetching from is not crashing.
Have you tried exporting a non-raid mount from the server to the
client to see if that crashes? The only thing that happens to me
when I run the above script on an NFS client while CD'd into an NFS
server is that the client winds up with thousands of sockets
in TIME_WAIT on the client until it runs out and starts getting
'socket is not connected' errors (I was using a web server on my LAN
so the fetches were completeing very quickly). But the NFS
server didn't have any problems.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the cause of the problem (though I have never in my life seen the panic message you posted in relation to the NCR cards). If you can get the panic regularly then it may be worthwhile trying to get some more information out of it. If you compile up a kernel with the DDB option and your console is not running X, then the kernel will drop into DDB on the console when it panics and allow you to do a stack 'trace'. You may also be able to then dump the machine by typing 'panic' manually at the ddb prompt after copying down the trace information. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Neat kernel development environment.
I have just managed to get the following going: By writing a device driver that is two terminals back-to-back, and configuring vmware to map one of the virtual ttys over the 'null-modem' device, and then running a kernel configured with the console on com1 and the gdb port on com2, (in the virtual machine in vmware) I can on a single machine run a test system, allow it to run the vmware X server, and at the same time have access to the console, AND be able to single step it under xxdgb or DDB depending on the task. Thus no need to have that second machine for debugging.. :-) It's amazing to see on the same X screen, 1/ The xserver of the virtual BSD box 2/ the console in another window, (which can be sent into DDB if needed) 3/ a 3rd window running xxgdb, single stepping the kernel with source and setting breakpoints etc. 4/ some othe rwindow on the host system, completely unaffected. I'll try get a screenshot. (And yes I did buy a vmware licence) Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
Julian Elischer writes: | | I have just managed to get the following going: | | By writing a device driver that is two terminals back-to-back, | and configuring vmware to map one of the virtual ttys over the | 'null-modem' device, and then running a kernel configured with the console | on com1 and the gdb port on com2, (in the virtual machine in vmware) | I can on a single machine run a test system, allow it to run the vmware X | server, and at the same time have access to the console, AND be able to | single step it under xxdgb or DDB depending on the task. FYI, via the latest Etherboot port that was commited you can netboot a vmware machine. Could you post your null-modem device? ... it saves on serial ports. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
:I have just managed to get the following going: : :By writing a device driver that is two terminals back-to-back, :and configuring vmware to map one of the virtual ttys over the :.. : :Thus no need to have that second machine for debugging.. ::-) :It's amazing to see on the same X screen, :1/ The xserver of the virtual BSD box :2/ the console in another window, (which can be sent into DDB if needed) :3/ a 3rd window running xxgdb, single stepping the kernel with source :and setting breakpoints etc. :4/ some othe rwindow on the host system, completely unaffected. : :I'll try get a screenshot. :(And yes I did buy a vmware licence) : :Julian I can just see all the coolness seeping out. Now guys, we have to have as a goal something at least as comparable as what IBM did with one of their mainframes. Oh, say, lets shoot for being able to run 4000 copies or so of linux under VMWare on FreeBSD :-) Once we fix the deadlocks, that is. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
Here is my dmesg output, and btw, sorry.. the perl script was not running on the NFS volume, just regularly on a regular 4.0 box, and it crashed the box (yes, I had login limits set), I was just giving another example of what seems to be some instability in 4.0 under high loads.. Here my dmesg from the raid/nfs server: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Fri Mar 31 00:03:37 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RAID Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 186006596 Hz CPU: IDT WinChip C6 (186.01-MHz 586-class CPU) Origin = "CentaurHauls" Id = 0x541 Stepping = 1 Features=0x8000b5FPU,DE,TSC,MSR,MCE,MMX real memory = 50331648 (49152K bytes) config en ed0 config po ed0 0x240 config ir ed0 5 config iom ed0 0xd8000 config f ed0 0 config q avail memory = 45297664 (44236K bytes) Preloaded elf kernel "kernel" at 0xc036f000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc036f09c. npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: DEC 21050 PCI-PCI bridge at device 3.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82375EB PCI-EISA bridge at device 4.0 on pci0 eisa0: EISA bus on isab0 mainboard0: HWPc0d1 (System Board) on eisa0 slot 0 isa0: ISA bus on isab0 ahc0: Adaptec aic7855 SCSI adapter port 0xf800-0xf8ff mem 0xfedff000-0xfed f irq 15 at device 5.0 on pci0 ahc0: Using left over BIOS settings ahc0: aic7855 Single Channel A, SCSI Id=7, 3/255 SCBs ahc1: Adaptec aic7855 SCSI adapter port 0xf400-0xf4ff mem 0xfedfe000-0xfedfeff f irq 15 at device 6.0 on pci0 ahc1: Using left over BIOS settings ahc1: aic7855 Single Channel A, SCSI Id=7, 3/255 SCBs fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3cf iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA (mono) 16 virtual consoles, flags=0x200 ed0 at port 0x240-0x25f iomem 0xd8000-0xd9fff irq 5 drq 0 on isa0 ed0: address 00:00:c0:00:dc:ba, type SMC8416T (16 bit) Waiting 15 seconds for SCSI devices to settle vinum: loaded da1 at ahc1 bus 0 target 1 lun 0 da1: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da5 at ahc1 bus 0 target 5 lun 0 da5: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da5: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da5: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da6 at ahc1 bus 0 target 6 lun 0 da6: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da6: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da6: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da4 at ahc1 bus 0 target 4 lun 0 da4: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da4: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da4: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da3 at ahc1 bus 0 target 3 lun 0 da3: HP 2.13 GB 1st ### 1221 Fixed Direct Access SCSI-2 device da3: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da3: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) da2 at ahc1 bus 0 target 2 lun 0 da2: HP 2.13 GB 1st ### 1212 Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 2033MB (4165272 512 byte sectors: 64H 32S/T 2033C) Mounting root from ufs:/dev/da0s1a cd0 at ahc0 bus 0 target 5 lun 0 cd0: TOSHIBA CD-ROM XM-5301TA 1535 Removable CD-ROM SCSI-2 device cd0: 4.032MB/s transfers (4.032MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: SGI SeagateST12550N 2703 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2048MB (4195116 512 byte sectors: 64H 32S/T 2048C) WARNING: / was not properly dismounted vinum: reading configuration from /dev/da6s1e vinum: updating configuration from /dev/da5s1e vinum: updating configuration from /dev/da4s1e vinum: updating configuration from /dev/da3s1e vinum: updating configuration from /dev/da2s1e vinum: updating configuration from /dev/da1s1e I hope this helps.. and i'll setup crash dumping on raid, thanks for your time On Fri, 31 Mar 2000, Matthew Dillon wrote: ::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the
Re: Neat kernel development environment.
In message [EMAIL PROTECTED], Matthew Dillon writes: :I have just managed to get the following going: : :By writing a device driver that is two terminals back-to-back, :and configuring vmware to map one of the virtual ttys over the :.. : :Thus no need to have that second machine for debugging.. ::-) :It's amazing to see on the same X screen, :1/ The xserver of the virtual BSD box :2/ the console in another window, (which can be sent into DDB if needed) :3/ a 3rd window running xxgdb, single stepping the kernel with source :and setting breakpoints etc. :4/ some othe rwindow on the host system, completely unaffected. : :I'll try get a screenshot. :(And yes I did buy a vmware licence) : :Julian I can just see all the coolness seeping out. Now guys, we have to have as a goal something at least as comparable as what IBM did with one of their mainframes. Oh, say, lets shoot for being able to run 4000 copies or so of linux under VMWare on FreeBSD :-) Once we fix the deadlocks, that is. We don't need VMWare really, we can just run N jails... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/Vinum problems
One more thing, here's my kernel config file just in case you need it: machine i386 cpu I586_CPU ident RAID maxusers64 makeoptions DEBUG=-g#Build kernel with gdb(1) debug options DDB_UNATTENDED options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep options NFS #Network Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options NMBCLUSTERS=10240 options VINUMDEBUG #enable Vinum debugging hooks device isa device eisa device pci # Floppy drives device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device cd # CD device pass# Passthrough device (direct SCSI access) device mlx # Mylex DAC960 family # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device vga0at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Floating point support - do not disable. device npx0at nexus? port IO_NPX irq 13 # ISA Ethernet NICs. device ed0 at isa? port 0x240 irq 5 iomem 0xd8000 # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop# Network loopback pseudo-device ether # Ethernet support pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device vinum #Vinum concat/mirror/raid driver pseudo-device snp # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf #Berkeley packet filter On Fri, 31 Mar 2000, Matthew Dillon wrote: ::Jason DiCioccio Another possibility -- could you post your 'dmesg' output? One thing that NFS does do is severely exercise both the network and the SCSI device in a concurrent fashion. If you happen to be using an NCR SCSI chipset, that could be the cause of the problem (though I have never in my life seen the panic message you posted in relation to the NCR cards). If you can get the panic regularly then it may be worthwhile trying to get some more information out of it. If you compile up a kernel with the DDB option and your console is not running X, then the kernel will drop into DDB on the console when it panics and allow you to do a stack 'trace'. You may also be able to then dump the machine by typing 'panic' manually at the ddb prompt after copying down the trace information. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
I'll put the device driver on http://www.freebsd.org/~julian/ but it needs teh eyes of someone who's really at home in the tty system to look at it. I got kinda confused half way through hacking it (from the pty driver) and it shows. basically each pair of minor numbers is a pair and are connected to each other back-to-back. The support for 'select' etc is a bit confused at this stage. also originally I wanted it to shut down the other one (e.g. like loss of carrier) when one gets closed, and for one that is openning to stall waiting for its partner, but it turns out that makes it hard to use with vmware. So I backed that out (which gives a bit more confusion). the screenshot will be there too, (but it's big) also the little script I use to get it all sarteed (trivial). Julian On Fri, 31 Mar 2000, Doug Ambrisko wrote: Julian Elischer writes: | | I have just managed to get the following going: | | By writing a device driver that is two terminals back-to-back, | and configuring vmware to map one of the virtual ttys over the | 'null-modem' device, and then running a kernel configured with the console | on com1 and the gdb port on com2, (in the virtual machine in vmware) | I can on a single machine run a test system, allow it to run the vmware X | server, and at the same time have access to the console, AND be able to | single step it under xxdgb or DDB depending on the task. FYI, via the latest Etherboot port that was commited you can netboot a vmware machine. Could you post your null-modem device? ... it saves on serial ports. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
In message [EMAIL PROTECTED], Julian El ischer writes: Oh? can you run a kernel in a jail for debugging? No, not quite yet, but what IBM bragged about the 41k linuxes for was for what jails do for you. Poul-Henning That's what I'm using it for.. (debugging kernel code.. I only have one machine here.) On Fri, 31 Mar 2000, Poul-Henning Kamp wrote: run 4000 copies or so of linux under VMWare on FreeBSD :-) Unfortunatly you can only run one vmware at a time under BSD. Once we fix the deadlocks, that is. We don't need VMWare really, we can just run N jails... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
It seems Vallo Kallaste wrote: Hi I have four (4) ATA disks, all same new 20GB IBM 7200rpm models. Intel Seattle BX2 mobo, PIIX4 controller. I'm not expecting any performance increase or such, simply want to get my hands on. Ata driver, as the -current doesn't have wd anymore. I have raid5 volume laid over four disks, containing /usr filesystem, stripe unit size 256k. Machine deadlocks very reliably while doing ordinary buildworld, keyboard is responsive, network also but no disk I/O happens. I see syncer and bufdaemon in vrlock state; make, ln, syslogd and dhclient in flswait state. I usually don't see such states. Sources from which I built the system are todays, before I set up vinum. Yup, Greg and I know of this problem, it also happens with the wd driver and with CAM, so the problem is probably not the driver. I'm investigating this right now, and it looks like vinum is botching a struct buf in action somehow. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Odd problem with ppp0 in -current
Hi, I'm trying to track down the change that broke my ppp. The symptoms are that I cannot telnet out though my ppp0 interface. Ktrace indicates that the connect() to the remote system never returns (it may eventually timeout - I didn't wait a really long time). However, I run natd and have several other boxes here that I _can_ use to establish a connection with a remote system, via my ppp0 interface (my gateway) . Very odd indeed. Does this ring a bell with anyone as far as what recent commit (last few days) might have resulted in such behaviour? My previous kernel of about a week ago is fine. Telnet works fine through my xl0 interface to my local machines. It's just my ppp0 interface that has this problem. Looking through the commit messages, I didn't see anything that jumped out as being the culprit. Any ideas? Is anyone else seeing this? For reference, this is with last night's cvs update, and kernel with IPFIREWALL, IPDIVERT, and natd. I use 'pppd' and 'ppp0'. Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldload of driver for isa pnp card (cycle two)
On Fri, Mar 31, 2000 at 08:55:37PM +0100, Doug Rabson wrote: I will try to tackle these issues soon. Due to other commitments, this won't happen for a few days though. Can I halp somehow? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
io memory requests from pnp devices lands in video bios
It has the internal identification `kern/17715'. The individual assigned to look at your report is: freebsd-bugs. Category: kern Responsible:freebsd-bugs Synopsis: io memory requests from pnp devices lands in video bios Arrival-Date: Fri Mar 31 12:50:01 PST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
Poul-Henning Kamp writes: | In message [EMAIL PROTECTED], Julian |El | ischer writes: | | Oh? can you run a kernel in a jail for debugging? | | No, not quite yet, but what IBM bragged about the 41k linuxes for | was for what jails do for you. Nope not quite. Since you could actually crash the kernel in the VM/Linux session and the others are still going. Crash the kernel in a jail and all sessions are toast. Note I do like jail on FreeBSD one thing that would be nice with jail is if the IP address for the jail disappeared from the non-jail machine. For example sendmail doesn't like to send mail to the jail session if it sees the jail's IP is one of its own IPs. Sort of like, I'm already there why bother and it could cause mail looping under mis-configuration. This isn't a problem for the IBM type solution or vmware. Then with IBM the machine can disable a bad CPU and call home for a fix. None of the session are bothered (except performance) assuming you have more then one CPU working. Maybe we heard different bragging. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP buildworld times / performance tests
On Fri, Mar 31, 2000 at 12:24:27PM +0200, a little birdie told me that Brad Knowles remarked At 5:44 PM -0600 2000/3/30, Matthew D. Fuller wrote: Does softupdates provide faster performance than async/noatime? I keep /usr/src and /usr/obj as such, would it be faster with softupdates? And if so, why? Of course, once you ask this question, the next logical one that follows is "what happens if you do all three?" TTBOMK, nothing, as softupdates will override the other two. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
On Friday, 31 March 2000 at 21:32:22 +0200, Søren Schmidt wrote: It seems Vallo Kallaste wrote: Hi I have four (4) ATA disks, all same new 20GB IBM 7200rpm models. Intel Seattle BX2 mobo, PIIX4 controller. I'm not expecting any performance increase or such, simply want to get my hands on. Ata driver, as the -current doesn't have wd anymore. I have raid5 volume laid over four disks, containing /usr filesystem, stripe unit size 256k. Machine deadlocks very reliably while doing ordinary buildworld, keyboard is responsive, network also but no disk I/O happens. I see syncer and bufdaemon in vrlock state; make, ln, syslogd and dhclient in flswait state. I usually don't see such states. Sources from which I built the system are todays, before I set up vinum. Yup, Greg and I know of this problem, it also happens with the wd driver and with CAM, so the problem is probably not the driver. I'm investigating this right now, and it looks like vinum is botching a struct buf in action somehow. I'm not sure that this is the same problem. Please supply the information I ask for in http://www.lemis.com/vinum/how-to-debug.html. The problem that Søren and I are looking at is usually a panic. We don't really know where it's happening, but we're each sure it's not in *our* code :-) From a Vinum standpoint, it happens between the time that Vinum sends a request to the driver and when the I/O completes, so it's difficult to blame Vinum. On the other hand, we've seen it with SCSI as well, so it's difficult to blame the driver. I'm half guessing that it's something else altogether which is spamming freed data. Vinum mallocs the buffer headers rather than using geteblk(), which could explain why it happens only with Vinum. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
:I'm not sure that this is the same problem. Please supply the :information I ask for in http://www.lemis.com/vinum/how-to-debug.html. : :The problem that Søren and I are looking at is usually a panic. We :don't really know where it's happening, but we're each sure it's not :in *our* code :-) From a Vinum standpoint, it happens between the time :that Vinum sends a request to the driver and when the I/O completes, :so it's difficult to blame Vinum. On the other hand, we've seen it :with SCSI as well, so it's difficult to blame the driver. I'm half :guessing that it's something else altogether which is spamming freed :data. Vinum mallocs the buffer headers rather than using geteblk(), :which could explain why it happens only with Vinum. : :Greg The business about vinum malloc()ing the buffer header has always bothered me, maybe we should introduce an 'allocpbuf' call (and 'freepbuf') to complement the getpbuf()/relpbuf() routines we already have to take this out of the hands of the device driver. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
On Friday, 31 March 2000 at 16:37:44 -0800, Matthew Dillon wrote: I'm not sure that this is the same problem. Please supply the information I ask for in http://www.lemis.com/vinum/how-to-debug.html. The problem that Søren and I are looking at is usually a panic. We don't really know where it's happening, but we're each sure it's not in *our* code :-) From a Vinum standpoint, it happens between the time that Vinum sends a request to the driver and when the I/O completes, so it's difficult to blame Vinum. On the other hand, we've seen it with SCSI as well, so it's difficult to blame the driver. I'm half guessing that it's something else altogether which is spamming freed data. Vinum mallocs the buffer headers rather than using geteblk(), which could explain why it happens only with Vinum. The business about vinum malloc()ing the buffer header has always bothered me, maybe we should introduce an 'allocpbuf' call (and 'freepbuf') to complement the getpbuf()/relpbuf() routines we already have to take this out of the hands of the device driver. Seems good to me. I thought of a few alternatives as well. But if this is a problem with some other process nuking data which has since been freed, this will just drive the problem into hiding. The most obvious alternative would be for Vinum to use geteblk() after all and use b_caller1 to point to the rest of the information; but it would still need to be malloced. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange problem with Wavelan card.
I just go two new wavelan cards. The drivers comes up and the interface is there but these messages keep appearing. No traffic seems to get through. FreeBSD lupo.thebarn.com 4.0-STABLE FreeBSD 4.0-STABLE #6: Thu Mar 30 23:15:22 CST 2000 [EMAIL PROTECTED]:/export/cyan/src/sys/compile/LUPO i386 Tried loading the driver as a module and statically compiled in the kernel... same result. Any ideas? Mar 30 23:45:22 lupo pccard:wi0: WaveLAN/IEEE inserted Mar 30 23:45:22 lupo pccardd[334]: pccardd started Mar 30 23:45:57 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:45:57 lupo /kernel: wi0: starting DAD for fe80:000c::0260:1dff:fe1d :3848 Mar 30 23:45:57 lupo /kernel: wi0: xmit failed Mar 30 23:45:57 lupo routed[85]: possible netmask problem between wi0:10.0.0. 0/8 and xl0:10.0.0.0/24 Mar 30 23:45:58 lupo /kernel: wi0: DAD complete for fe80:000c::0260:1dff:fe1d :3848 - no duplicates found Mar 30 23:46:00 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:46:00 lupo /kernel: wi0: xmit failed Mar 30 23:46:04 lupo /kernel: wi0: device timeout Mar 30 23:46:04 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:46:07 lupo /kernel: wi0: xmit failed Mar 30 23:46:12 lupo /kernel: wi0: device timeout Mar 30 23:46:12 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:53:32 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:53:32 lupo /kernel: wi0: xmit failed Mar 30 23:53:36 lupo /kernel: wi0: device timeout Mar 30 23:53:36 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:53:38 lupo /kernel: wi0: xmit failed Mar 30 23:53:43 lupo /kernel: wi0: device timeout Mar 30 23:53:43 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:53:47 lupo /kernel: wi0: xmit failed Mar 30 23:53:52 lupo /kernel: wi0: device timeout Mar 30 23:53:52 lupo /kernel: wi0: tx buffer allocation failed Mar 30 23:54:19 lupo /kernel: pid 85 (routed), uid 0: exited on signal 11 (co re dumped) Mar 30 23:54:19 lupo /kernel: wi0: xmit failed Mar 30 23:54:24 lupo /kernel: wi0: device timeout Mar 30 23:54:24 lupo /kernel: wi0: tx buffer allocation failed -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RSAREF in make.conf
This can be deleted from "src/etc/defaults/make.conf" now, right? I can't find any uses of it in the tree. # To tell the base system that you are using RSAREF (from ports). # (This needs revisiting) - it is very likely that this is too # heavily tied to USA_RESIDENT==YES. #RSAREF=YES John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA library problems
A similar patch was added for the USA version of RSA for the same basic reason. Your patch is almost correct. It should add the line: LDADD+= -L$[.OBJDIR]/../libcrypto -lcrypto Your version would reference the system crypto library and not the one being built as part of buildworld. Jim Bloom [EMAIL PROTECTED] Dirk Roehrdanz wrote: I had the same problem. "BN_mod_exp_mont" is in libcrypto,but isn't visible from librsaINTL.so because libcrypto is loaded in conjunction with the load of /usr/local/libexec/apache/libssl.so via dlopen() . The man page to dlopen states " The symbols exported by objects added to the address space by dlopen() can be accessed only through calls to dlsym()". I have solved the problem with the attached patch. It adds libcrypto to the list of linked libs. Maybe there is a better solution,who knows ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another current crash (cvs-cur.6183
Hi,
Boy I wish I had read this message before I went out and bought a USB zip
drive... I'm in the exact same situation IOPENER with 4.0 installed and
screwed up to a point where I can boot but not mount the sandisk drive. I
figured that I would get a zip drive and mount it instead.
Anyways if you found some way around this please let me know, otherwise I've
got to make another trip out and get a SuperDisk instead...
BTW What state are you in? Mine will boot, but gets to the point where it
tries to mount the sandisk and panics with a ffs_write panic. Booting in
single user doesn't help.
---
Paul Haddad ([EMAIL PROTECTED])
Imagine that Cray computer decides to make a personal computer. It has
a 150 MHz processor, 200 megabytes of RAM, 1500 megabytes of disk
storage, a screen resolution of 4096 x 4096 pixels, relies entirely on
voice recognition for input, fits in your shirt pocket and costs $300.
What's the first question that the computer community asks?
"Is it PC compatible?"
- Original Message -
From: "Christopher Masto" [EMAIL PROTECTED]
To: "Paul Richards" [EMAIL PROTECTED]; "Stephen Hocking-Senior
Programmer PGS SPS Perth" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, March 22, 2000 12:16 AM
Subject: Re: Another current crash (cvs-cur.6183
On Wed, Mar 22, 2000 at 03:02:02AM +, Paul Richards wrote:
I've got a different but I think related panic.
#9 0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
busy!!!")
at ../../kern/kern_shutdown.c:552
#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
at ../../vm/vm_page.h:346
I've been playing around with one of those iopener things and got
myself into a state I thought I could get out of with the help of a
USB Zip drive. Unfortunately, upon purchasing and connecting one,
I discovered that I can't access it without a panic, which I
point out here on the chance it's also related.
#7 0xc024ac2c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1018879976, tf_esi = 256, tf_ebp = -919618472, tf_isp
= -919618500,
tf_ebx = -1071201278, tf_edx = 0, tf_ecx = -1070746656, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071396739, tf_cs = 8,
tf_eflags = 582,
tf_esp = -1071099905, tf_ss = -1071212893}) at
../../i386/i386/trap.c:549
#8 0xc023c87d in Debugger (msg=0xc02696a3 "panic") at
machine/cpufunc.h:64
#9 0xc01549e8 in panic (fmt=0xc026c402 "allocbuf: buffer too small")
at ../../kern/kern_shutdown.c:552
#10 0xc0178f5a in allocbuf (bp=0xc3452018, size=83886080) at
../../kern/vfs_bio.c:2346
#11 0xc0178f01 in geteblk (size=83886080) at ../../kern/vfs_bio.c:2315
#12 0xc025cb57 in dsinit (dev=0xc0be1e00, lp=0xc0c490f4, sspp=0xc0c490f0)
at ../../kern/subr_diskmbr.c:186
#13 0xc015eec6 in dsopen (dev=0xc0be1e00, mode=8192, flags=0,
sspp=0xc0c490f0,
lp=0xc0c490f4) at ../../kern/subr_diskslice.c:683
#14 0xc015dfbf in diskopen (dev=0xc0be1e00, oflags=1, devtype=8192,
p=0xc88be860)
at ../../kern/subr_disk.c:146
#15 0xc018ae65 in spec_open (ap=0xc92fbe10) at
../../miscfs/specfs/spec_vnops.c:191
#16 0xc018ad65 in spec_vnoperate (ap=0xc92fbe10)
at ../../miscfs/specfs/spec_vnops.c:117
#17 0xc01ff2e9 in ufs_vnoperatespec (ap=0xc92fbe10) at
../../ufs/ufs/ufs_vnops.c:2301
#18 0xc018595f in vn_open (ndp=0xc92fbedc, fmode=1, cmode=0) at
vnode_if.h:189
#19 0xc0181951 in open (p=0xc88be860, uap=0xc92fbf80) at
../../kern/vfs_syscalls.c:994
#20 0xc024b4ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077937212, tf_esi = 134894800, tf_ebp = -1077937132,
tf_isp = -919617580, tf_ebx = 0, tf_edx = 8, tf_ecx = 134894828,
tf_eax = 5,
tf_trapno = 12, tf_err = 2, tf_eip = 672026540, tf_cs = 31,
tf_eflags = 642,
tf_esp = -1077937316, tf_ss = 47}) at ../../i386/i386/trap.c:1073
#21 0xc023cf26 in Xint0x80_syscall ()
I'm not intimately familiar with the function involved, and I'm out of
time tonight, so I'm backing up a few days to see if it goes away.
--
Christopher Masto Senior Network Monkey NetMonger
Communications
[EMAIL PROTECTED][EMAIL PROTECTED]
http://www.netmonger.net
Free yourself, free your machine, free the daemon --
http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Panic in pmap_enter
I rebuilt my -current system this morning and am now getting paincs with both the SMP and non-SMP kernels. The current panic with a uniprocessor kernel is: panic: pmap_enter: invalid page directory, pdir=0, va=0xc0da It occurs right after the output for pci0. I'm currently sitting at the db prompt with this kernel. With an SMP kernel, I get the following at the same point in the boot process: panic: pmap_enter: invalid page directory, pdir=0, va=0xc0da3000 mp_lock=0023; cpuid=0; Fatal trap 12: page fault while in kernel mode mp_lock=0024; cpuid=0; This is with sources cvsup'd around 8:30 am CST today (3/31). I can still boot my old kernel (from 3/26), but I get a panic in ifconfig when my Ethernet card (an onboard Intel EtherExpress Pro 10/100) is configured, so it's not easy for me to get working sources or newer changes. Has anyone else seen this? I haven't seen much email today because my -current machine is where I normally get my mail. :( -Patrick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in pmap_enter
Matthew Dillon [EMAIL PROTECTED] wrote: :I rebuilt my -current system this morning and am now getting paincs with :both the SMP and non-SMP kernels. The current panic with a uniprocessor :kernel is: : :panic: pmap_enter: invalid page directory, pdir=0, va=0xc0da : :It occurs right after the output for pci0. I'm currently sitting at the db :prompt with this kernel. : :With an SMP kernel, I get the following at the same point in the boot :process: : :panic: pmap_enter: invalid page directory, pdir=0, va=0xc0da3000 This usually happens when you set kernel resource options that are too high. If you are setting kernel resource options, try commenting them out. Well, I did recently add options for shared memory settings to get XFree86 4.0 working better. It hadn't caused any problems until now though. I just tried commenting out those options and recompiling, but I still get the panic. To get your old kernel to boot you may have to remove your ethernet card. That's not an option. ;) I am, however, using the if_fxp module instead of compiling the driver into the kernel, so I can avoid loading the module. :I can still boot my old kernel (from 3/26), but I get a panic in ifconfig :when my Ethernet card (an onboard Intel EtherExpress Pro 10/100) is ^^^ :configured, so it's not easy for me to get working sources or newer changes. :Has anyone else seen this? I haven't seen much email today because my :-current machine is where I normally get my mail. :( : : -Patrick You can boot the kernel into single user mode. Interrupt the FreeBSD boot sequence by hitting space, then (typically) type 'boot /kernel -s' (specify a path to your working kernel if not /kernel). Yes, I know how to get into single-user mode and how to choose kernels at boot time. I was a bit vague in what I was trying to do with my old kernel. Sorry for any confusion. -Patrick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in pmap_enter
Patrick Hartling [EMAIL PROTECTED] wrote: Matthew Dillon [EMAIL PROTECTED] wrote: :I rebuilt my -current system this morning and am now getting paincs with :both the SMP and non-SMP kernels. The current panic with a uniprocessor :kernel is: : :panic: pmap_enter: invalid page directory, pdir=0, va=0xc0da : :It occurs right after the output for pci0. I'm currently sitting at the d b :prompt with this kernel. : :With an SMP kernel, I get the following at the same point in the boot :process: : :panic: pmap_enter: invalid page directory, pdir=0, va=0xc0da3000 This usually happens when you set kernel resource options that are too high. If you are setting kernel resource options, try commenting them out. Well, I did recently add options for shared memory settings to get XFree86 4.0 working better. It hadn't caused any problems until now though. I just tried commenting out those options and recompiling, but I still get the panic. Revision 1.5 of sys/isa/pnpparse.c has fixed my problems, and I didn't have to give up the shared memory options. It was acquired through the magic of cvsweb and copied over via a floppy. :) What a day. -Patrick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in pmap_enter
:Revision 1.5 of sys/isa/pnpparse.c has fixed my problems, and I didn't have :to give up the shared memory options. It was acquired through the magic of :cvsweb and copied over via a floppy. :) What a day. : : -Patrick Ah, excellent. P.S. word to the wise even though this wasn't your problem this time: modules and -current don't mix, if you get out of sync you usually wind up crashing the system. I usually compile everything I use into -current kernels directly. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock with vinum raid5
It seems Greg Lehey wrote: The problem that Søren and I are looking at is usually a panic. We don't really know where it's happening, but we're each sure it's not in *our* code :-) From a Vinum standpoint, it happens between the time that Vinum sends a request to the driver and when the I/O completes, so it's difficult to blame Vinum. On the other hand, we've seen it with SCSI as well, so it's difficult to blame the driver. I'm half guessing that it's something else altogether which is spamming freed data. Vinum mallocs the buffer headers rather than using geteblk(), which could explain why it happens only with Vinum. It happens also with the wd driver, so its 3 drivers against one :) What seems to be happening is that *something* is corrupting the buf structure, or the pointer to it. What I see in most cases is that the buf structure I get in adstrategy has gotten some of its fields changed when I get to work on it in ad_start. That should _not_ be happening, and doesn't when vinum is not involved. Somehow I think that vinums shuffleing around with buf's and copies of them at some point gets confused. I'm still instrumenting my kernel to locate where it happens, and I havn't got anything definite yet... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
JetDirect 500X and FreeBSD
Does anyone have any experiance or information about using HP JetDirect 500X Printer Hubs with FreeBSD ? This is mission critical for my company, so any information greatly appriciated. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
