Re: Turbochannel based Alpha, quickie question
In message [EMAIL PROTECTED] "Kenneth D. Merry" writes: : Nope. You've CAMified a driver, would you like to write it? :) I started with a CAMified driver and hacked it... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Is there way to recover system from I/O lockup?
Hello. It's relatively simple to force system in swap-in/out loop. The user can produce a lot of processes that use a lot of VM memory, so bringing system to unusable state, due to very big response time (hours). This is also achievable through active IO. I know about defense way - resource limiting, but I'm interested in other way. I do not want to limit someone until this situation. But in case of it, I want be able to enter such system using ssh and "killall" offending processes. Technically speaking, I do not want performance degradation for some running processes and processes forked from them. I do not want to allow swap-out data of this processes and want them to get prioritized IO? (CPU priority, I can get using rtprio. Isn't it?) Is it possible to implement such behavior? Is there any way configure system such way without kernel modification? with kernel modifications? What parts of kernel should I see for it? Thanks in advance, Sergey. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
3.3-STABLE panic in m_copym
I have a Compaq Proliant 3000 (2 x PII-333) running 3.3-STABLE which has
crashed several times with the following backtrace:
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc0144299 in panic (fmt=0xc023eb04 "m_copym") at ../../kern/kern_shutdown.c:446
#2 0xc015ac7e in m_copym (m=0xc141ae80, off0=10788, len=1216, wait=1) at
../../kern/uipc_mbuf.c:435
#3 0xc019286a in tcp_output (tp=0xd0be8960) at ../../netinet/tcp_output.c:505
#4 0xc0194106 in tcp_usr_send (so=0xd0ae9640, flags=0, m=0xc1420680, nam=0x0,
control=0x0, p=0xd0e95b20) at ../../netinet/tcp_usrreq.c:395
#5 0xc015c4b2 in sosend (so=0xd0ae9640, addr=0x0, uio=0xd0ee5f10, top=0xc1420680,
control=0x0, flags=0, p=0xd0e95b20)
at ../../kern/uipc_socket.c:530
#6 0xc01525dc in soo_write (fp=0xc210c600, uio=0xd0ee5f10, cred=0xc1fce600, flags=0)
at ../../kern/sys_socket.c:82
#7 0xc014f46a in dofilewrite (p=0xd0e95b20, fp=0xc210c600, fd=7, buf=0x806f0f4,
nbyte=8192, offset=-1, flags=0)
at ../../kern/sys_generic.c:363
#8 0xc014f373 in write (p=0xd0e95b20, uap=0xd0ee5f94) at ../../kern/sys_generic.c:298
#9 0xc021f39b in syscall (frame={tf_es = 39, tf_ds = -1078001625, tf_edi = 671806342,
tf_esi = 7, tf_ebp = -1077949676,
tf_isp = -789684252, tf_ebx = 0, tf_edx = 434759, tf_ecx = 0, tf_eax = 4,
tf_trapno = 7, tf_err = 2, tf_eip = 134533700, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077949700, tf_ss = 39}) at
../../i386/i386/trap.c:1100
#10 0xc020b2ac in Xint0x80_syscall ()
The panic is the following loop in m_copym:
while (off 0) {
if (m == 0)
panic("m_copym");
if (off m-m_len)
break;
off -= m-m_len;
m = m-m_next;
}
so it seems to be running off the end of the mbuf chain before having
verified the whole length. Following the m_next pointers, starting with
the mbuf pointer from the calling routine, I get a total of 5 mbufs in
this chain, with the following lengths:
0xc141ae80 2048
0xc13fef80 2008
0xc1446e00 2048
0xc147fe80 872
0xc1420680 1216
The total is 8192, so obviously copying 1216 bytes at offset 10788
won't work.
The crash only happens occasionally, typically several days apart.
The crash is not specific to 3.3-STABLE, it also happened with 3.2-STABLE.
Does this ring a bell with anybody? Anything more I should check in the
kernel dump?
The machine is a news feeder box, running diablo-1.24 - thus it would be
expected to be a heavy consumer of mbufs. It has NMBCLUSTERS=4096 in the
kernel config.
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
--
# From: $FreeBSD: src/sys/i386/conf/GENERIC,v 1.143.2.22 1999/09/14 22:53:30 jkh Exp $
machine "i386"
cpu "I686_CPU"
ident "NEWSFEED1"
maxusers50
options MATH_EMULATE#Support for x87 emulation
options INET#InterNETworking
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options NFS #Network Filesystem
options NFS_ROOT#NFS usable as root device, "NFS" req'ed
options MSDOSFS #MSDOS Filesystem
options "CD9660"#ISO 9660 Filesystem
options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed
options PROCFS #Process filesystem
options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!]
options SCSI_DELAY=5000 #Be pessimistic about Joe SCSI device
options UCONSOLE#Allow users to grab the console
options USERCONFIG #boot -c editor
options VISUAL_USERCONFIG #visual boot -c editor
options KTRACE #ktrace(1) syscall trace support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options MSGBUF_SIZE=32768
options INCLUDE_CONFIG_FILE # Include this file in kernel
options "NMBCLUSTERS=4096" # default based on maxusers=50 is 1312 - not
enough!
options DDB
options DDB_UNATTENDED
options SOFTUPDATES
options "MAXMEM=(576*1024)" # 64 MB + 512 MB, in kB
config kernel root on da0
options SMP # Symmetric MultiProcessor Kernel
options APIC_IO # Symmetric (APIC) I/O
options NINTR=50# number of INTs
controller isa0
controller eisa0
controller pci0
controller fdc0at isa? port "IO_FD1" bio irq 6 drq 2
diskfd0 at fdc0 drive 0
options "CMD640"# work around CMD640 chip
CAM-ification - documentation
While on the topic: What documentation is there for CAM? I've found the following, but would like to know whether there is more - CAM specification (at Digital?) - justin's docu on freefall. Especially some help on the topic of polling would be appreciated. Otherwise I'll have to resort to figuring out how to do things in interrupt context, and that is going to be dirty. Nick Warner Losh wrote... In message [EMAIL PROTECTED] Wilko Bulte writes: : How difficult would CAMifying a driver be? Speaking of which, has a "How to CAMify a driver" doc been written? Nope. You've CAMified a driver, would you like to write it? :) Ken -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for the kill-list (userland nfs)
Hi,
warnx("WARNING: path@server syntax is deprecated, use server:path");
before line 667 of /usr/src/sbin/mount_nfs.c. But I don't see anywhere
where it differentiates between delimitors and path-components. It is
just a simple strchr() and the first @ or : it finds is assumed the be
I've changed it already and I hope it will be committed to
CURRENT soon. Have a look at :
http://www.attic.ch/patches/MOUNTPATCH-PART-1
http://www.attic.ch/patches/MOUNTPATCH-PART-4
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP + fxp0 wierdness
Mike Smith [EMAIL PROTECTED] wrote, in response to [EMAIL PROTECTED]: We're running 3.3-REL on dual processor PII-450's, with a N440BX motherboard, using the onboard EtherExpress Pro (fxp) NIC and 512MB RAM. These machines are running custom software that excercises the disk, CPU and network quite heavily. The SMP machines seem to have both "fxp0: device timeout" problems, and spontaneous reboots. snip Could this be a problem with SMP + fxp combination? Any other thoughts or ideas? This is a known problem, insofar as it's been seen on a wide range of systems. It's not SMP specific, but it does appear to be very sensitive to your hardware configuration (eg. we were seeing it repeatedly in combination with an ncr SCSI card, and when we switched to an Adaptec it went away). Just a bit of additional info. We haven't yet seen the 'fxp0: device timeout' message on the machines that are running 3.3, even though at least one of the 3.3 machines used to throw many timeout messages under 3.1. On that machine, we were seeing 4 or 5 of the timeout messages per high-volume hour - until I dropped it back to a uniprocessor kernel, at which point those messages stopped completely. Also, excepting a single machine, the rebooting problem only seems to happen after around a week or runtime, and that period has been falling in proportion to the volume the machines are servicing (it used to take two weeks, and earlier almost a month). Thanks, scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
: : Adjusting the bytes-per-inode (-i) specification in newfs should not : pose a problem. : :IOW now you say it's ok to use very high values of -i... ;-) : :Andrzej Bialecki No, I didn't say that. My recommended maximum is still 262144. Fsck should be reasonably fast with that number and the filesystem should still be able to maintain reasonable efficiency. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pcm sound delays
In message [EMAIL PROTECTED] Reinier Bezuidenhout writes: : What I am though experiencing is some delay in sound e.g. xgal : (xgalaga) and a few other splications. The sound is not in sync with : the application. When I quit/kill the application sound is sometimes : still generated for quite a few second after the application has : died. : : Anyone got any ideas what causes this and maybe how to fix it ??? I've seen that all the time with xgalaga going back to when the es1370 driver was just a set of patches. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On Thu, Oct 07, 1999 at 02:02:48PM -0400, Bill Fumerola wrote: On Wed, 6 Oct 1999, Josef Karthauser wrote: cdidDisplay the serial number of the cd using the method used by the cddb (http://www.cddb.org) project. pedantic URLs end with a trailing slash. (http://www.cddb.org/) /pedantic pedantic FDDN end in a dot. (http://www.cddb.org./) /pedantic -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (781) 899-7484 x704 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Compaq Proliant 2500 file corruptions
My school has recently acquired a Compaq Proliant 2500 and we are trying to set up FreeBSD on it. I download the 3.3 kern and mfsroot disks and replaced the kernel with a custom one that had the IDA driver included in it. Everything installed fine. Then I started working on it again and whenever I'd cvsup or download ports the files would get corrupted. Unfortunately I do not have the machine here, but it is a dual Pentium Pro with 4.3 GB scsi disks, Thunderlan net card, and a ncr scsi controller. 1. I was wondering if anyone knew of any such problems, or what other info I could provide to help figure this out. 2. There are no panics or anything. I can't seem to find an isolated case to look at. Anyone have any idea how I would go about debugging this? 3. Would I be better off running the newer driver in current? I keep tabs with whats going on in the current list, I just need a somewhat stable machine. It's only going to get light usage. Thanks for any help. Sorry this is so vauge. I'd really like you to get a dmesg. Below is the kernel config Dan Diephouse machine "i386" cpu "I686_CPU" ident OWL maxusers64 options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options MFS #Memory Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660"#ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Be pessimistic about Joe SCSI device options UCONSOLE#Allow users to grab the console options FAILSAFE#Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options DDB options DDB_UNATTENDED config kernel root on wd0 # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #optionsNCPU=2 # number of CPUs #optionsNBUS=4 # number of busses #optionsNAPIC=1 # number of IO APICs #optionsNINTR=42# number of INTs controller isa0 controller pnp0# PnP support for ISA controller eisa0 controller pci0 # Floppy drives controller fdc0at isa? port "IO_FD1" bio irq 6 drq 2 diskfd0 at fdc0 drive 0 # IDE controller and disks #options"CMD640"# work around CMD640 chip deficiency controller wdc0at isa? port "IO_WD1" bio irq 14 diskwd0 at wdc0 drive 0 diskwd1 at wdc0 drive 1 #controller wdc1at isa? port "IO_WD2" bio irq 15 #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 # ATAPI devices #optionsATAPI #Enable ATAPI support for IDE bus #optionsATAPI_STATIC#Don't do it as an LKM #device acd0#IDE CD-ROM #device wfd0#IDE Floppy (e.g. LS-120) # SCSI Controllers # A single entry for any of these controllers (ncr, ahb, ahc) is # sufficient for any number of installed devices. controller ncr0# NCR/Symbios Logic controller ida0at isa? bio irq ? vector idaintr diskid0 at ida0 drive 0 diskid1 at ida0 drive 1 diskid2 at ida0 drive 2 diskid3 at ida0 drive 3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On Fri, Oct 08, 1999 at 12:44:06PM -0400, Brian Reichert wrote: pedantic URLs end with a trailing slash. (http://www.cddb.org/) /pedantic pedantic FDDN end in a dot. (http://www.cddb.org./) /pedantic Not in a URL, or in an email address :) Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compaq Proliant 2500 file corruptions
:1. I was wondering if anyone knew of any such problems, or what other :info I could provide to help figure this out. :2. There are no panics or anything. I can't seem to find an isolated :case to look at. Anyone have any idea how I would go about debugging :this? :3. Would I be better off running the newer driver in current? I keep :tabs with whats going on in the current list, I just need a somewhat :stable machine. It's only going to get light usage. : :Thanks for any help. Sorry this is so vauge. I'd really like you to :get a dmesg. Below is the kernel config The very first think I would do is look at the disklabel for the drive and make sure that none of the offset/sizes overlap (except for the 'c' whole-disk partition, of course). e.g. take the offset, add the size, make sure the result is the offset for the next partition, and repeat. The final offset+size should of course not exceed the size of the disk. Partitions can slice up the disk out of order, but if they overlap (except for c) you will get file corruption. Also look for error messages in /var/log/messages. # disklabel da0 (or in your case perhaps wd0) 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 26214404.2BSD 1024 819216 # (Cyl.0 - 16*) b: 1048576 262144 swap# (Cyl. 16*- 81*) c: 41929020unused0 0 # (Cyl.0 - 260*) d: 262144 13107204.2BSD 1024 819216 # (Cyl. 81*- 97*) e: 262144 15728644.2BSD 1024 819216 # (Cyl. 97*- 114*) f: 2097152 18350084.2BSD 1024 819216 # (Cyl. 114*- 244*) g: 260742 39321604.2BSD 1024 819216 # (Cyl. 244*- 260*) -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.3-STABLE panic in m_copym
[EMAIL PROTECTED] writes:
I have a Compaq Proliant 3000 (2 x PII-333) running 3.3-STABLE which has
crashed several times with the following backtrace:
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc0144299 in panic (fmt=0xc023eb04 "m_copym") at ../../kern/kern_shutdown.c:446
#2 0xc015ac7e in m_copym (m=0xc141ae80, off0=10788, len=1216, wait=1) at
../../kern/uipc_mbuf.c:435
#3 0xc019286a in tcp_output (tp=0xd0be8960) at ../../netinet/tcp_output.c:505
#4 0xc0194106 in tcp_usr_send (so=0xd0ae9640, flags=0, m=0xc1420680, nam=0x0,
control=0x0, p=0xd0e95b20) at ../../netinet/tcp_usrreq.c:395
#5 0xc015c4b2 in sosend (so=0xd0ae9640, addr=0x0, uio=0xd0ee5f10, top=0xc1420680,
control=0x0, flags=0, p=0xd0e95b20)
at ../../kern/uipc_socket.c:530
#6 0xc01525dc in soo_write (fp=0xc210c600, uio=0xd0ee5f10, cred=0xc1fce600,
flags=0) at ../../kern/sys_socket.c:82
#7 0xc014f46a in dofilewrite (p=0xd0e95b20, fp=0xc210c600, fd=7, buf=0x806f0f4,
nbyte=8192, offset=-1, flags=0)
at ../../kern/sys_generic.c:363
#8 0xc014f373 in write (p=0xd0e95b20, uap=0xd0ee5f94) at
../../kern/sys_generic.c:298
#9 0xc021f39b in syscall (frame={tf_es = 39, tf_ds = -1078001625, tf_edi =
671806342, tf_esi = 7, tf_ebp = -1077949676,
tf_isp = -789684252, tf_ebx = 0, tf_edx = 434759, tf_ecx = 0, tf_eax = 4,
tf_trapno = 7, tf_err = 2, tf_eip = 134533700, tf_cs = 31,
tf_eflags = 518, tf_esp = -1077949700, tf_ss = 39}) at
../../i386/i386/trap.c:1100
#10 0xc020b2ac in Xint0x80_syscall ()
The panic is the following loop in m_copym:
while (off 0) {
if (m == 0)
panic("m_copym");
if (off m-m_len)
break;
off -= m-m_len;
m = m-m_next;
}
so it seems to be running off the end of the mbuf chain before having
verified the whole length. Following the m_next pointers, starting with
the mbuf pointer from the calling routine, I get a total of 5 mbufs in
this chain, with the following lengths:
0xc141ae80 2048
0xc13fef80 2008
0xc1446e00 2048
0xc147fe80 872
0xc1420680 1216
This may or may not be helpful, but..
Packet mbuf's contain redundant information: the header mbuf contains
the total length (m-m_pkthdr.len), which must be equal to the sum of
the lengths of the individual mbuf's in the chain (m-m_len).
I think these numbers getting out of sync is a common source of bugs.
For example, code that builds an mbuf chain by concatenating mbuf's
forgets to update the m-m_pkthdr.len field.
You might look at where the packet originated, ie in dofilewrite() (?)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
read/write atomic?
I just spent a bit of time talking to the Linux Alan Cox and I was suprised to find out that it seems that Linux doesn't garantee read/write atomicity. It sounded somewhat strange however, it dawned on me that one should be using advisory locks instead of depending on that feature. Removing those locks would simplify a lot of the locking code, and probably aid in performance quite a bit. I know Matt Dillon wanted to implement byterange I/O locks to handle this, but it seems unnessesary in terms of complexity and performance gains. I know some people will be eager to just spout "Linux is broken" but what i'm really looking for is a situation where this would cause problems. Can anyone comment on this or reference a thread that has gone over this issue? thanks, -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
[ reply moved the bottom... ] Nick Hibma wrote... Warner Losh wrote... In message [EMAIL PROTECTED] Wilko Bulte writes: : How difficult would CAMifying a driver be? Speaking of which, has a "How to CAMify a driver" doc been written? Nope. You've CAMified a driver, would you like to write it? :) Ken While on the topic: What documentation is there for CAM? I've found the following, but would like to know whether there is more - CAM specification (at Digital?) www.t10.org, as Matt pointed out. FreeBSD/CAM is mostly CAM-2, with some CAM-3 thrown in. - justin's docu on freefall. Especially some help on the topic of polling would be appreciated. Otherwise I'll have to resort to figuring out how to do things in interrupt context, and that is going to be dirty. Well, first off, are you talking about polling for completion in a peripheral driver or a SIM/HBA driver? If you're looking to poll for CCB completion in a peripheral driver, there's already xpt_polled_action() and an example of how to use it in dadump() in scsi_da.c. If you're talking about polling for transaction completion in a device driver, my guess is that you're going to have to do things in an interrupt context. (Unless you use a kernel process to do it.) The thing to remember is that when you get CCBs down in a CAM device driver, it may well be in an interrupt context. You have to be able to deal with that. My guess is that it might be easiest to just use a timeout handler to poll the device for completion every so often. A kernel process may also be an option, depending on how nasty the device is. I would recommend talking to Justin about it. I'm sure he'll be glad to give you some recommendations on how to proceed. He's also not the only one who knows about this sort of stuff. By now, Matt Jacob has a reasonable amount of experience with CAM drivers and he may also be able to give you some advice. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: read/write atomic?
:I just spent a bit of time talking to the Linux Alan Cox and I :was suprised to find out that it seems that Linux doesn't :garantee read/write atomicity. : :It sounded somewhat strange however, it dawned on me that one should :be using advisory locks instead of depending on that feature. : :Removing those locks would simplify a lot of the locking code, :and probably aid in performance quite a bit. I know Matt Dillon :wanted to implement byterange I/O locks to handle this, but it :seems unnessesary in terms of complexity and performance gains. : :I know some people will be eager to just spout "Linux is broken" :but what i'm really looking for is a situation where this would :cause problems. : :Can anyone comment on this or reference a thread that has :gone over this issue? : :thanks, :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] I would love to see the guarentee go away, at least for anything not O_APPEND. O_APPEND writes would probably still have to be exclusively locked. Such a change would clean up many of the deadlock problems with the current code and would also drastically improve parallel I/O performance on the same file (because I/O requests whos data is cached in memory would not have to block waiting for an I/O request whos data must be obtained from the disk). BUT! And this is a big but... I/O atomicy has been 'standard' in UNIX for a very long time. If we were to make such a change, we would no longer be in conformance with the UNIX spec. This is why it hasn't been done and why it probably will not be done in the near future. Simply put, Linux is doing it wrong. On the otherhand, way back then mmap() was not used to the degree that it is used today, and with mmap() you already lose I/O atomicy (you lose it even between mmap() and discrete I/O, not just mmap-to-mmap). It would be great if someone could ram such a change through the standards committees. Alternatively Linux could become enough of a defacto standard that we could ignore the standards committee. Barring that, the only solution available to us to increase performance is to implement temporary byte-ranged locks within the kernel to allow the I/O to be parallelized. It isn't necessarily as bad as you think... support for such locks already exists in order to deal with POSIX locks, but it would certainly be easier if we didn't have to mess with it at all. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Questions regarding memory usage
Does FreeBSD have the following features: (1) Limit the physical memory it uses even if the machine has larger memory without having to pull out the memory chip physically. This should be done at the boot time. (2) Tell if a particular program has ever been swapped out. Any help is appreicated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Turbochannel based Alpha, quickie question
On Thu, 7 Oct 1999, Warner Losh wrote: In message [EMAIL PROTECTED] Wilko Bulte writes: : How difficult would CAMifying a driver be? Speaking of which, has a "How to CAMify a driver" doc been written? In my experience, X3T10/990D and friends + ahc_*.c + aic7xxx.c + cam/*.h (+ cam/*.c, cam/scsi/*, etc ... if your are curious) are better materials for such an operation that any incomplete and/or unmaintained documentation (when existing such kind of documentations have been generally just written once forever). Just my 0.02 euro. Gérard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Questions regarding memory usage
Does FreeBSD have the following features: (1) Limit the physical memory it uses even if the machine has larger memory without having to pull out the memory chip physically. This should be done at the boot time. In -current and (I think) -stable, you can set the 'hw.physmem' tunable in the loader. See 'help set tunables' in the loader, or read /boot/loader.help. (2) Tell if a particular program has ever been swapped out. There is no trivial way to determine this, no. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compaq Proliant 2500 file corruptions
I brought the computer home with me. Below is some of the system information. I'm still stumped as to what to next...The disklabel all matches up correctly. Anyone have any more ideas? Thanks Again -- Dan Diephouse disklabel wd0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 15360004.2BSD 1024 819216 # (Cyl.0 - 9*) b: 512000 153600 swap# (Cyl.9*- 41*) c: 163541700unused0 0 # (Cyl.0 - 1017) e: 204800 6656004.2BSD 1024 819216 # (Cyl. 41*- 54*) f: 15483770 8704004.2BSD 1024 819216 # (Cyl. 54*- 1017*) (This was trying to boot non-smp) Preloaded elf kernel "kernel.old" at 0xc037b000. Pentium Pro MTRR support enabled eisa0: CPQ551 (System Board) Probing for devices on the EISA bus Probing for devices on PCI bus 0: Correcting Natoma config for non-SMP chip0: Intel 82440FX (Natoma) PCI and memory controller rev 0x02 on pci0.0.0 chip1: IBM 82351 PCI-PCI bridge rev 0x01 on pci0.13.0 chip2: IBM 82351 PCI-PCI bridge rev 0x01 on pci0.15.0 chip3: PCI to EISA bridge (vendor=0e11 device=0001) rev 0x07 on pci0.20.0 Probing for devices on PCI bus 1: vga0: Cirrus Logic GD5430 SVGA controller rev 0x22 int a irq 255 on pci1.6.0 tl0: Compaq Netelligent 10/100 Proliant rev 0x10 int a irq 10 on pci1.7.0 tl0: Ethernet address: 00:80:5f:a6:29:6f tl0: autoneg not complete, no carrier ncr0: ncr 53c875 fast20 wide scsi rev 0x03 int a irq 11 on pci1.9.0 xl0: 3Com 3c905B-TX Fast Etherlink XL rev 0x24 int a irq 5 on pci1.13.0 xl0: Ethernet address: 00:10:4b:66:b4:3b xl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for devices on PCI bus 2: ida0: Compaq SMART-2/P array controller rev 0x02 int a irq 9 on pci2.0.0 ida0: drvs=2 firm_rev=1.36 ida0: unit 0 (id0): Compaq Logical Drive id0: 8024MB (16434495 total sec), 1023 cyl, 255 head, 63 sec, bytes/sec 512 ida0: unit 1 (id1): Compaq Logical Drive id1: 4257MB (8719950 total sec), 953 cyl, 183 head, 50 sec, bytes/sec 512 ida: wdc vector stealing on (mode = always, boot major = 0) Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard Matthew Dillon wrote: :1. I was wondering if anyone knew of any such problems, or what other :info I could provide to help figure this out. :2. There are no panics or anything. I can't seem to find an isolated :case to look at. Anyone have any idea how I would go about debugging :this? :3. Would I be better off running the newer driver in current? I keep :tabs with whats going on in the current list, I just need a somewhat :stable machine. It's only going to get light usage. : :Thanks for any help. Sorry this is so vauge. I'd really like you to :get a dmesg. Below is the kernel config The very first think I would do is look at the disklabel for the drive and make sure that none of the offset/sizes overlap (except for the 'c' whole-disk partition, of course). e.g. take the offset, add the size, make sure the result is the offset for the next partition, and repeat. The final offset+size should of course not exceed the size of the disk. Partitions can slice up the disk out of order, but if they overlap (except for c) you will get file corruption. Also look for error messages in /var/log/messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compaq Proliant 2500 file corruptions
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write:
My school has recently acquired a Compaq Proliant 2500 and we are trying
to set up FreeBSD on it. I download the 3.3 kern and mfsroot disks and
replaced the kernel with a custom one that had the IDA driver included
in it. Everything installed fine. Then I started working on it again
and
whenever I'd cvsup or download ports the files would get corrupted.
Let me guess, the symptom is that blocks of zeros are scattered
randomly throughout the file? If this is the case, the IDA driver
in 3.3 is the culprit.
3. Would I be better off running the newer driver in current? I keep
tabs with whats going on in the current list, I just need a somewhat
stable machine. It's only going to get light usage.
This probably is one solution. Another is to try a couple of patches
to see if they fix the problem; attached is some code that might help.
--
Jonathan
Index: ida.c
===
RCS file: /ncvs/src/sys/i386/isa/Attic/ida.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 ida.c
--- ida.c 1999/08/29 16:07:18 1.1.2.3
+++ ida.c 1999/10/08 19:41:57
@@ -1206,7 +1206,8 @@
if (PCI_CONTROLLER(ida)) {
qcbp-hdr.priority = 0x00;
-qcbp-hdr.flags = 0x24;
+qcbp-hdr.flags =
+ (sizeof(struct ida_req) + sizeof(struct ida_sgb) * IDA_MAX_SGLEN)
} else {
qcbp-hdr.priority = IDA_DEF_PRIORITY;
qcbp-hdr.flags = 0x10;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: A bike shed (any colour will do) on greener grass...
On Fri, Oct 08, 1999 at 06:00:08PM +0200, Juergen Lock wrote: One maybe useful tip from a (mostly) lurker: turn your list email into news and read them with a decent threaded newsreader. I use inn and its mailpost script and read with trn, both in /usr/ports/news. I suggest a threaded mail reader. I use mutt. Just thought i'd mention... -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (781) 899-7484 x704 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On Fri, 8 Oct 1999, Josef Karthauser wrote: :On Fri, Oct 08, 1999 at 12:44:06PM -0400, Brian Reichert wrote: : pedantic : URLs end with a trailing slash. (http://www.cddb.org/) : /pedantic : pedantic : FDDN end in a dot. (http://www.cddb.org./) : /pedantic : :Not in a URL, or in an email address :) FQDNs always terminate with a dot. Even in a URL or mail address. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
netbooting on fxp0?
I'm somewhat aware that we have netboot code that understands 3com 3c509s and nc8390's. Last I checked, one had to burn a boot ROM for these cards and they were 10Mb. The current batch of IBM etherjets (probe as fxp0) have dhcp-enabled boot ROMs built into them. What is required to support these, or has someone worked on this already. 100Mb cards could make a decent diskless workstation/server. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: read/write atomic?
It would be great if someone could ram such a change through the standards committees. The changes nowadays are coming via "The Austin Group". See http://www.opengroup.org/austin/ and associated mailing list. Alternatively Linux could become enough of a defacto standard that we could ignore the standards committee. Barring that, the only solution available to us to increase performance is to implement temporary byte-ranged locks within the kernel to allow the I/O to be parallelized. It isn't necessarily as bad as you think... support for such locks already exists in order to deal with POSIX locks, but it would certainly be easier if we didn't have to mess with it at all. Adding more reliance on the POSIX locks works fine if that implementation is extended to include the common filesystems... in particular NFS file locking seems needed. A footnote is ensuring the deadlock detection code finds deadlocks which span multiple filesystem types. BTW the NFS version 4 protocol includes byte range locking. Version 2 and 3 use a seperate (out-of-band) locking protocol. Matthew Dillon [EMAIL PROTECTED] -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc Alternative email address: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: netbooting on fxp0?
David Gilbert writes: | The current batch of IBM etherjets (probe as fxp0) have dhcp-enabled | boot ROMs built into them. What is required to support these, or has | someone worked on this already. 100Mb cards could make a decent | diskless workstation/server. Look at ports/net/etherboot. It supports fxp0 and booting FreeBSD ELF kernels as well as Linux and DOS. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A bike shed (any colour will do) on greener grass...
On Fri, Oct 08, 1999 at 03:43:20PM -0400, Brian Reichert wrote: On Fri, Oct 08, 1999 at 06:00:08PM +0200, Juergen Lock wrote: One maybe useful tip from a (mostly) lurker: turn your list email into news and read them with a decent threaded newsreader. I use inn and its mailpost script and read with trn, both in /usr/ports/news. I suggest a threaded mail reader. I use mutt. Yeah mutt's threading is certainly an improvement... (and as you can see I'm using it myself too) But it still can't beat trn! :) Regards, -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
KLDs
On Slashdot, in a discussion regarding QNX, someone described it with the following: Under QNX, if your driver crashes, the kernel just restarts it. After reading it, I became more interested in KLDs. My only prior experiece was installing the Linux KLD and that was done by a port. Anyway, in an effort to learn, I decided to KLD-ify EXT2FS support. It took about 20 minutes and works great, but I still do not know how KLDs work. :) (I submitted the patch in kern/14217, if someone could look at it, that would be swell. I've been able to mount, read, write and umount without any problems) I also managed to get IPX KLD-ified in about 15 minutes, I can load it and now NCP loads but I have no way to test it. It also panics the kernel on unload. Anyway, back to the point, if it is this so simple (is it?), how much of the kernel can be KLDs? It would be interesting to see a kernel so small that all it had was KLD support in it and everything else was a module. I could upgrade my TCP/IP stack or filesystem code without a reboot. Imagine the uptime? Has anyone else thought about this? Is this a good idea? Is this a bad idea? How fundamentally different would this be from a microkernel? Could things be done in such a way that like QNX, it can kill and restart a misbehaving driver? What other cool things can be done? Thanks, Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file system full
On Fri, Oct 08, 1999, James Howard wrote: When running "strobe" (from the ports collection, it is a port scanner), I often or always get the message "file: table is full" many, many times. I have seen this under 2.2.6 through 4.0. What exactly is going wrong here and what should I do to fix it? Too many open file descriptors. This has nothing to do with the file system. -- |Chris Costello [EMAIL PROTECTED] |Never lick a gift horse in the mouth. `- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Surplus 3.2-RELEASE cds
Hello all, I have, piled around my desk, a little over 1000 copies of FreeBSD 3.2-RELEASE. Of course I've never really been fond of cubicles and dont really need to make a cube out of all these boxes so I need to get rid of them :) If you are part of an organization that could use FreeBSD 3.2-R discs in bulk please email me and let me know. The discs come in boxes of 52 each. Suitable uses for these would be giving out at users groups, ploping on the desks of developers that would make use of it, stocking local library shelves, and giving away at relavent trade shows. If at all possible it would be great to squeeze as much publicity as possible out of these events. Doing things like having a info sheet to hand out a long with the discs that explains what FreeBSD is and why it rocks, will make giving the discs out a worthwhile exercise. Please contact me if you think you have a worthy cause. As always it's great if you can pay for the shipping on these but we won't turn anyone away due to not being able to (anyone in the US that is). -Bill -- -=| --- B i l l S w i n g l e --- http://www.dub.net/ -=| [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] -=| Different all twisty a of in maze are you, passages little To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Compaq Proliant 2500 file corruptions
Just to provide some feedback, I was having the exact problem and this patch
appears to resolved it.
I CVSUP late afternoon, and make world with no problem on CPQ 1600 PII450
with Smart 2P controller.
Thanks
cuneyt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Lemon
Sent: Friday, October 08, 1999 2:43 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Compaq Proliant 2500 file corruptions
In article
local.mail.freebsd-hackers/[EMAIL PROTECTED] you write:
My school has recently acquired a Compaq Proliant 2500 and we are trying
to set up FreeBSD on it. I download the 3.3 kern and mfsroot disks and
replaced the kernel with a custom one that had the IDA driver included
in it. Everything installed fine. Then I started working on it again
and
whenever I'd cvsup or download ports the files would get corrupted.
Let me guess, the symptom is that blocks of zeros are scattered
randomly throughout the file? If this is the case, the IDA driver
in 3.3 is the culprit.
3. Would I be better off running the newer driver in current? I keep
tabs with whats going on in the current list, I just need a somewhat
stable machine. It's only going to get light usage.
This probably is one solution. Another is to try a couple of patches
to see if they fix the problem; attached is some code that might help.
--
Jonathan
Index: ida.c
===
RCS file: /ncvs/src/sys/i386/isa/Attic/ida.c,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 ida.c
--- ida.c 1999/08/29 16:07:18 1.1.2.3
+++ ida.c 1999/10/08 19:41:57
@@ -1206,7 +1206,8 @@
if (PCI_CONTROLLER(ida)) {
qcbp-hdr.priority = 0x00;
-qcbp-hdr.flags = 0x24;
+qcbp-hdr.flags =
+ (sizeof(struct ida_req) + sizeof(struct ida_sgb) *
IDA_MAX_SGLEN)
} else {
qcbp-hdr.priority = IDA_DEF_PRIORITY;
qcbp-hdr.flags = 0x10;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pcm sound delays
I have an ESS1869 also and it has always had sound delays. Im currently using 3.3 upgrade from 3.1 and it has always happened. MP3's and anything with sound, always chocks. I think it has to do with with DMA. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file system full
On Fri, 8 Oct 1999, Chris Costello wrote: Too many open file descriptors. This has nothing to do with the file system. Is there anyway this can be gotten around? A friend has a mail server that will spontaneously do this then crash. Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP + fxp0 wierdness
Thanks for your response David. Do you think the problem is isolated to just the onboard devices? Would a PCI NIC help or is it the entire N440BX board? Regards, Stevan Arychuk AvantGo Inc. [EMAIL PROTECTED] David Greenman wrote: We're running 3.3-REL on dual processor PII-450's, with a N440BX motherboard, using the onboard EtherExpress Pro (fxp) NIC and 512MB RAM. These machines are running custom software that excercises the disk, CPU and network quite heavily. The SMP machines seem to have both "fxp0: device timeout" problems, and spontaneous reboots. We were uable to get a working savecore until now, and have traced the reboots back to the fxp driver as well. Here are the debug outputs, and any custom changes to our kernel config. Could this be a problem with SMP + fxp combination? Any other thoughts or ideas? We've serached, and read, and searched all the FAQ's for both of these problems, and have pretty well come up empty. Suggestions for the next course of action? Thanks in advance for anyones help. There is some kind of hardware problem with the Intel N440BX motherboard that is causing memory corruption during the DMA. This is the third nearly identical report I've gotten about it. It does not appear to be a FreeBSD bug and so far only occurs when using the N440BX. You might try messing with the BIOS options and see if changing any of the DMA related settings will make the problem go away...I'd be very interested in the results. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP + fxp0 wierdness
Thanks for your response David. Do you think the problem is isolated to just the onboard devices? Would a PCI NIC help or is it the entire N440BX board? We've seen these symptoms on non-Intel boards. (eg. ASUS P2L, P2B). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
