NT vs Linux benchmark saga continues (fwd)
It'd be interesting to see where FreeBSD stacks up -- Forwarded message -- Date: 25 Jun 1999 17:00:02 -0400 From: Ramana Juvvadi <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: NT vs Linux benchmark saga continues http://www.zdnet.com/pcweek/stories/news/0,4153,1015266,00.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Changing the semantics of splsoftclock()
> >>Why have splr semantics? That is, it raises to splsoftclock if current > >>priority is lower, else doesn't fiddle with it. > > splsoftclock() has always had spllower() semantics, and its main users > (kern_clock.c and kern_time.c) depend on this. Okay. Then Justin's suggestion of splcallout with splr semantics makes sense? > > FreeBSD has a precedent of not changing poor spl names because the change > would be confusing: splnet() should be named splsoftnet() and splimp() > should be named splnet() as in NetBSD. I'm not sure what this means. I guess the gist is "don't change splsoftclock". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
this of interest to anyone?
panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: this of interest to anyone?
> > > > > panic: lockmgr: pid 3344, not exclusive lock holder 3341 unlocking > > Sorry- -current as of today, alpha. rebooting. Likely an NFS lock. > > It might be if you supplied some additional information, like what > sources your kernel was built from, as a minimum. UP or SMP? What > was the box doing when it paniced? If you have a dump, can you > provide a stack trace? Anything else useful. > > > David > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
> On Friday, 2 July 1999 at 15:26:35 -0400, Brian F. Feldman wrote: > > On Fri, 2 Jul 1999, Brian F. Feldman wrote: > > > >> Here's the fix. I'm sure it's not absolutely the same as what Greg will have, > >> but if anyone wants to commit it, it will fix world. > > > > I know I _could_ commit it, but it's someone else's work that's being actively > > maintained. It still does break world, but I don't think I have authority to > > commit over Greg's work. > > I personally think that, in such a case, you'd be justified to commit > it as a temporary measure. Due to the difference in time zones, this > has hit people while I've been asleep. That doesn't mean the commit > would stay, of course, but at least it would save people unnecessary > pain. Note, of course, that I have now committed the correct file, > which I had forgotten last night. > > What do you others think? opinion: If it's really blocking folks because things don't compile, it is always acceptable to do what you need to do- the tree should always compile even if -current. If the system doesn't boot because of change, then that's an obvious one too. If things work differently or not as well, but things are more or less working, it's not an emergency, so leave it for the author to fix. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
Let me add to this: > opinion: > > If it's really blocking folks because things don't compile, it is always > acceptable to do what you need to do- the tree should always compile even > if -current. If the system doesn't boot because of change, then that's an > obvious one too. If things work differently or not as well, but things > are more or less working, it's not an emergency, so leave it for the > author to fix ...always modulo a short delay (call it a couple of hours) after reporting the problem... after all, you don't *know* that the update isn't finished and that other things are coming down the pipe... but a couple of hours leaves really the most reasonable time for an integration to complete and the author to have had lunch in between. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
> > > > > > If it's really blocking folks because things don't compile, it is always > > > acceptable to do what you need to do- the tree should always compile even > > > if -current. If the system doesn't boot because of change, then that's an > > > obvious one too. If things work differently or not as well, but things > > > are more or less working, it's not an emergency, so leave it for the > > > author to fix > > > > ...always modulo a short delay (call it a couple of hours) after reporting > > the problem... after all, you don't *know* that the update isn't finished > > and that other things are coming down the pipe... but a couple of hours > > leaves really the most reasonable time for an integration to complete and > > the author to have had lunch in between. > > > > I worded my original post wrong; my change did fix world. Your second point > (the "wait and see" approach) wouldn't apply in this case: Greg was asleep, > and world was broken. You have to wait at least a little bit because with CVS there is no atomic update of a set of modules. IF make world is broken, waiting at least a certain period of time and then doing another update is important to ensure that you just simply updated only part of a an active checkin cycle. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Soft-updates feedback
while this is happening, what does 'iostat 1' and 'vmstat 1' tell you? On Sat, 3 Jul 1999, Alex Povolotsky wrote: > About a week ago, I've posted a message here and didn't got positive replies. > > The problem is: > > when I use soft-updates on IDE disks (disk on primary master, disk on > secondary master, CD on primary slave), any active disk-using program > (starting Netscape, starting EXMH) causes all other programs literally to stop > for several seconds (well, 20-30 seconds is quite often!). Turning > soft-updates off causes this nastiness to disappear, but also slows down > disk-active processess. > > Alex. > > > > > 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: panic in dadone, PR 12041
I'll fix it, but not this way. It's time to prepare for handling larger than terabyte disks that still have a 512 byte sector size as well. The actual calculation should be: (((u_int64_t) dp->secsize) * ((u_int64_t) dp->sectors)) >> 20LL and the format statement should be %qdMB for the Megabyte size. On Sat, 3 Jul 1999, Nick Hibma wrote: > > PR 12041 complains about the fact that the system panics with a divide > by zero if a zip drive is connected with a medium in it. I've not been > able to reproduce the problem, but remember having similar problems > when implementing the umass driver for USB. The problem is caused by the > following line in scsi_da.c:1326 (3.2-STABLE but applies to CURRENT as > well): > >snprintf(announce_buf, sizeof(announce_buf), > "%ldMB (%d %d byte sectors: %dH %dS/T%dC)", > dp->sectors / ((1024L * 1024L) / dp->secsize), > dp->sectors, dp->secsize, dp->heads, > dp->secs_per_track, dp->cylinders); > > secsize is 0 in some cases (I think it happens when an INQUIRY fails > without being detected as having failed). > > In any case a/(b/c) = a*c/b, but without any divl (with b sometimes 0 > and c == 2^20). > > Patch attached. > > Nick > > -- > e-Mail: [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent current misreports scsi disk size
Sorry, I pooched it. I'll fix. On Mon, 5 Jul 1999, Kenneth D. Merry wrote: > Vallo Kallaste wrote... > > Hello > > > > I just cvsupped the src-all, built the world, kernel and noticed that: > > > > changing root device to da0s1a > > da0 at ncr0 bus 0 target 5 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > > da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) > > da1 at ncr0 bus 0 target 6 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > > da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) > > ^ > > Actually the size is around 4GB. > > The change made to scsi_da.c in revision 1.28 doesn't quite work right for > disks over 2G on 32 bit machines. > > You can probably revert back to scsi_da.c version 1.27 and fix the problem. > > Instead of this: > > (((unsigned long) dp->secsize) * ((unsigned long) dp->sectors)) >> 20ul, > > The calculation might work better as something like this: > > (((u_int64_t)dp->secsize) * ((u_int64_t) dp->sectors)) >> 20 > > That'll probably cause a printf format warning, though. > > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > > > 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: snapshot stability
> > On Wed, 29 Dec 1999 15:31:38 GMT, Jonathon McKitrick wrote: > > > As of right now, which would that be? The august CD snapshot release or > > the one available on the cvs servers right now? > > If I were you, I'd hold out for 4.0-RELEASE, since it's just around the > corner (January some time). Otherwise, just inhale and prepare to > bleed. :-) > Despite the risk of bleeding, I have to say that I've installed several snaps (from the freebsd snapshot server) with excellent results. Now that spasm over the block device removal has gone away, things have been pretty darn stable for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Majordomo@FreeBSD.ORG: Majordomo results: which]
Uh, Karl, sometimes majordomo will get rampant and pull one w/o warning if there was a mail bounce. It may be a stupid mail robot problem, not a human out to get you. If so, you've directed your vituperation at the wrong ip address/port combo- try port 9 instead of port 25. On Sun, 2 Jan 2000, Karl Denninger wrote: > Oh, so the treehouse maggots continue to fester, eh? > > Nice move shitheads. > > Do you intend to continue? > > Consider this forwarded to Steve, a withdrawal of my port, and notice of my > intent to post it along with a transcript on my web page for HomeDaemon. > > Who is the two-bit-peckerhead who removed my subscription to several of > the lists? > > -- > -- > Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org > Isn't it time we started putting KIDS first? See the above URL for > a plan to do exactly that! > > > - Forwarded message from [EMAIL PROTECTED] - > > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > Subject: Majordomo results: which > Reply-To: [EMAIL PROTECTED] > Date: Sun, 2 Jan 2000 15:52:37 -0800 (PST) > > -- > > which denninger.net > > > NOTE: the "which" command does not show subscriptions >to either freebsd-arch or freebsd-security-notifications > > > The string 'denninger.net' appears in the following > entries in lists served by [EMAIL PROTECTED]: > > ListAddress > === > freebsd-hackers [EMAIL PROTECTED] > freebsd-ports [EMAIL PROTECTED] > freebsd-scsi[EMAIL PROTECTED] > freebsd-security[EMAIL PROTECTED] > > > > - End forwarded message - > > > 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: 4.0 code freeze scheduled for Jan 15th
Yes, this is a very good point. Jordan, which is it? On Fri, 7 Jan 2000, Peter Jeremy wrote: > On 2000-Jan-07 01:43:09 +1100, Steve Ames <[EMAIL PROTECTED]> wrote: > > _FEATURE_ freeze is January 15th. > > Not quite - Jordan specifically stated _CODE_ freeze (see the Subject:). > > Maybe I misunderstood Jordan's original announcement, but this was > also a surprise for me. Jordan originally stated that there'd be a > feature freeze from 15th December 1999. I got the impression that > this was going to be in effect for several months and would allow any > code updates, but prevent the introduction of new features. This > would then be followed by a _CODE_ freeze sometime in 2000Q1, leading > to 4.0-RELEASE late in 2000Q1. (My understanding of the difference is > that during the code freeze, only changes that demonstrably fix known > bugs, without deleterious side effects, are allowed). > > A few weeks ago, I saw comments that it had slipped a month, followed > a few days ago by Jordan's announcement of a code freeze. > > Peter > > > 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: So, tell me again why we can't read audio CDs in SCSI drives?
Hmm! Better hold the 4.0 Code Freeze until this sorts out! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
installing over the wire with a tulip card...
Umm- I know I've done this before, but maybe this is something stupid I've forgotten I went home to my shiny new 400Mhz intel with the 40GB IBM drive in hand.. I'd pulled a couple of the 4.0 snapshot floppy sets off off current.freebsd.org... boot the floppies- they see the de0 card I have in the probe messages (which is connected to the DSL modem ...), but only present sl0/ppp0 as network install media. What have I forgotten that makes me a bonehead here? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing over the wire with a tulip card...
This shouldn't be a PNP-OS issue because this is a PCI card- the card is seen during booting- which means it's getting detected. I don't know why 'ifconfig -l' doesn't see it though. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing over the wire with a tulip card...
Hmm. Very interesting and subtle. I'll check this out. Gawd, PCs are *s* lame On Fri, 7 Jan 2000, Thomas Veldhouse wrote: > I wouldn't think so. However, the problem disappears when the PNP OS > setting is set to OFF on another box - and it reappears when I turn it > back on. When Linux boots - it says something to the extent that the card > has not been initialized by the BIOS - and then it does it - this is when > the driver detects it. Oddly, it does have an IRQ under FreeBSD - it just > doesn't work [with PNP OS on]. I used to get this problem [Not PNP > OS related though] with "auto" under the interfaces section of > /etc/rc.conf. Overriding that with "lo0 de0" has not fixed the problem. > > I had to get a different card for my box without the option to > run PNP OS off, a PNIC II based Linksys card. > > Tom Veldhouse > [EMAIL PROTECTED] > > On Fri, 7 Jan 2000, Matthew Jacob wrote: > > > > > This shouldn't be a PNP-OS issue because this is a PCI card- the card is > > seen during booting- which means it's getting detected. I don't know why > > 'ifconfig -l' doesn't see it though. > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
does this look broken to you?
1) Alpha's don't have a trap.h... 2) Why are derived files ending up in the source tree? Yes, this is after a make obj. -- >>> stage 1: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/alpha DESTDIR=/usr/obj/usr/src/alpha INSTALL="sh /usr/src/tools/install.sh" MACHINE_ARCH=alpha TOOLS_PREFIX=/usr/obj/usr/src/alpha PATH=/usr/obj/usr/src/alpha/usr/sbin:/usr/obj/usr/src/alpha/usr/bin:/usr/obj/usr/src/alpha/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 -DNOMAN -DNOINFO -DNOHTML bootstrap-tools cd /usr/src/games/fortune/strfile; make obj; make depend; make all; make install /usr/obj/usr/src/alpha/usr/src/games/fortune/strfile created for /usr/src/games/fortune/strfile rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/alpha/usr/include /usr/src/games/fortune/strfile/strfile.c cd /usr/src/games/fortune/strfile; make _EXTRADEPEND echo strfile: /usr/obj/usr/src/alpha/usr/lib/libc.a >> .depend make: don't know how to make /usr/include/machine/trap.h. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld failing in "===> secure/usr.bin/openssl"
Has been fixed, approx 1700 EST. On Mon, 17 Jan 2000, bush doctor wrote: > >From sources cvsup around 14:00 EST ... > > cc -O -pipe -DMONOLITH -DNO_IDEA -I/usr/src/secure/usr.bin/openssl -DNO_RSA >-DNO_SSL2 -I/usr/obj/usr/src/i386/usr/include -o openssl apps.o asn1pars.o ca.o >ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o >genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o >s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl >-lcrypto > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomUpdate' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to >`R_GetRandomBytesNeeded' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to >`RSAPrivateDecrypt' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPublicEncrypt' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomFinal' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to >`RSAPrivateEncrypt' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `R_RandomInit' > /usr/obj/usr/src/i386/usr/lib/libcrypto.so: undefined reference to `RSAPublicDecrypt' > *** Error code 1 > > Stop in /usr/src/secure/usr.bin/openssl. > *** Error code 1 > > Stop in /usr/src/secure/usr.bin. > *** Error code 1 > > Stop in /usr/src/secure. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > #:^) > -- > So ya want ta hear da roots? > bush doctor <[EMAIL PROTECTED]> > Of course I run FreeBSD!! > 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
Re: boot messages for pci devices...
> On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote: > > fxp0: port 0xc400-0xc43f mem >0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0 > > Agreed. For a PCI card all I want to know is what it is, and what IRQ it > was assigned. A single line should be suffient. Do you even need to know what IRQ it was assigned? It seems to me that IRQ, like IO-PORT, is only needed if you're either interested in such stuff or to catch conflicts (both are under bootverbose) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot messages for pci devices...
> > What would be nice would be to have the normal version displayed and > the verbose stuff go to a seperate buffer and logged seperatly.. > > ie so you don't clutter your boot screen with junk, but if you have a > problem you can get at the verbose info :) > > .. and no I don't have any patches :) >From tne cmn_err(9f) man page for solaris: The first character in format affects where the message will be written: !the message goes only to the system buffer. ^the message goes only to the console. ?If level is also CE_CONT, the message is always sent to the system buffer, but is only written to the console when the system has been booted in verbose mode. See kernel(1M). If neither condition is met, the '?' character has no effect and is simply ignored. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot messages for pci devices...
On Tue, 18 Jan 2000, David O'Brien wrote: > On Tue, Jan 18, 2000 at 06:10:00PM -0800, Matthew Jacob wrote: > > > Agreed. For a PCI card all I want to know is what it is, and what IRQ it > > > was assigned. A single line should be suffient. > > > > Do you even need to know what IRQ it was assigned? It seems to me that IRQ, > > > With wacky PC hardware being what it is, I would say yes. Especially on > laptops. Having to tell everyone to boot verbose besides posting > /var/run/dmesg.boot would be yet one more thing to get over when pulling > teeth [read details] from people. Hmm? Haven't we argued over this before [ default grep output ]]? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot messages for pci devices...
> The IRQ is useful to me at least, since the ISA/PCI irq distribution is > rather hackish and non-trivial to get right at times. Note that I'm not saying that IRQ is not useful - I'm just asking whether it's important to see when bootverbose == 0. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: With feature freeze being in place
> On Sat, Jan 22, 2000 at 09:01:36PM +0100, Jeroen Ruigrok/Asmodai wrote: > > -On [2122 15:22], Nick Hibma ([EMAIL PROTECTED]) wrote: > > > > - update HARDWARE.TXT > > Urgh... > > > doing them or mdoc if someone wrote the bare text. But if someone takes > > this task from my shoulders, I'd be happy. > > > > Also, are GENERIC and LINT in sync? > > Do we want a LINT for alpha too? We do, but we're in no position to really respond to problems with it right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
more softdep funnies?
>From a kernel built over the last day or so, alpha, ata disk: Debugger() at Debugger+0x2c panic() at panic+0x100 initiate_write_inodeblock() at initiate_write_inodeblock+0x40 softdep_disk_io_initiation() at softdep_disk_io_initiation+0xac spec_strategy() at spec_strategy+0x48 bwrite() at bwrite+0x404 vop_stdbwrite() at vop_stdbwrite+0x1c vop_defaultop() at vop_defaultop+0x2c vfs_bio_awrite() at vfs_bio_awrite+0x484 spec_fsync() at spec_fsync+0x1ec sched_sync() at sched_sync+0x1a8 exception_return() at exception_return dump not available because the ATA drive and/or driver fouled up in the middle of the dump- and the ad drive didn't show back up on reboot and the system is wedged so I'd have to go to the office to fix it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AIC-7899 SCSI Driver?
> > It will only work at Ultra2 speeds right now, Ultra160 support is coming, > though. To be fair, the sym driver already supports Ultra3. And Qlogic Ultra3 support is coming too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
It crashes for me a lot. There's some deal about fonts, oddly enough, which causes it to crash right away- see the installation instructions that come out when you install communicator-47- it said something about mkfontdir. It still crashes or wedges for me a lot, though. I tried mozilla, and that was worse. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
> > :It crashes for me a lot. There's some deal about fonts, oddly enough, which > :causes it to crash right away- see the installation instructions that come out > :when you install communicator-47- it said something about mkfontdir. > : > :It still crashes or wedges for me a lot, though. I tried mozilla, and that was > :worse. > > Hmm. This sounds worse then usual. Make sure you are running netscape > with appropriate resource limits. > > unlimit data > limit descriptors 200 > > (The data limit should be at least 128 megabytes) Yep - 512MB data, 552 file descriptors. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: B_WRITE cleanup patch, please test!
> This patch is the first step towards the stackable BIO system as > sketched out on http://www.freebsd.org/~phk/Geom/ > > Please test & review. There's no code to test- it's just a sketch. It's fine as a start, but it's important that you clarify the role of node device drivers in informing the geometry device about what's what (to get information about physical limits) and how errors are to be flagged (if an out of range request comes floating thru). Presumably the latter is just marking a transaction with B_ERROR and setting b_errno to something specific that would say that the block is out of range (insert argument over 'correct' errno here), and that the range involved is the physical device limit (and what about commands that overlap the end of the device?). Presumably the former, if to give the geometry stack something worthwhile to chew on, can handle the case of devices that resize and devices where, unlike most devices currently, geometry really does matter. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: B_WRITE cleanup patch, please test!
On Mon, 13 Mar 2000, Matthew Jacob wrote:
> > This patch is the first step towards the stackable BIO system as
> > sketched out on http://www.freebsd.org/~phk/Geom/
> >
> > Please test & review.
{ as Poul reminded me, I missed the header line that had the patch - sorry
about that }
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSDCon Speaker Schedule [was: Newbus/bus/space info atFBSDcon?]
> On Wed, Sep 15, 1999 at 09:16:03AM +0100, Doug Rabson wrote: > > I will be there and I'm happy to support anyone's presentation by > > answering the 'hard' questions. I don't think I have enough time to > > prepare anything myself but since the schedule is full, that isn't a > > problem :-). > > Just to throw a monkeywrench in the work at the last minute... > > Do to the influx of new and valuable talk proposals that hit my desk > today we're going to run a third set of talks at the conference. This > opens up 7 new 1.5 hour slots. If you'd like to present something, please do > contact me. :) Scroan... I was just seeing if I could wiggle out of my Fibre Channel talk... guess not then... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DDB && SMP?
I just ran across this:
Debugger("isp_attach")
Stopped at Debugger+0x37: movl$0,in_Debugger
db> cont
whoa, other_cpus: 0x0002, stopped_cpus: 0x
panic: stop_cpus() failed
mp_lock = 0002; cpuid = 0; lapic.id =
Automatic reboot in 15 seconds - press a key on the console to abort
Whuffo?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DDB && SMP?
Thanks, that did the trick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ASSERT macros in the kernel....
I don't seem to see (after not looking very hard) any ASSERT macros for the kernel in FreeBSD. It'd be pretty easy to add them, and they're awfully useful. They're different from INVARIANT support in that they encapsulate (and panic if the assertion is triggered) more inline types of conditions. Any opinions? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ASSERT macros in the kernel....
> :I don't seem to see (after not looking very hard) any ASSERT macros for > :the kernel in FreeBSD. It'd be pretty easy to add them, and they're > :awfully useful. They're different from INVARIANT support in that they > :encapsulate (and panic if the assertion is triggered) more inline types of > :conditions. > : > :Any opinions? > : > :-matt > > I don't understand what you want to do. KASSERT() is the standard > way to assert something in the kernel, but we do not want to bloat > the code unnecessarily so KASSERT()s only do something if INVARIANT > support has been turned on. > > If we need to panic on something whether or not invariant support has > been turned on, we currently just use a conditional and a panic. > > How would ASSERT be different from KASSERT() ? > > -Matt > >>I don't seem to see (after not looking very hard) any ASSERT macros for That's what it was- I grepped for ASSERT, but somehow missed KASSERT- that's sufficinet for me, I can live with INVARIANTS. Sorry- I'm a moron- never mind To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BEWARE: CAM changes broke AHC!
While I don't dispute that the change rolling/rollout fixed what you see,
I'd have to say that if they're related there are *far* more serious
problems in there.
> (da0:ahc0:0:0:0) data overrun detected in Data-In phase. Tag = 0x8
> (da0:ahc0:0:0:0) Have seen Data Phase. Length = 0, NumSGs = 1
>
> Backing out the following sys/cam/scsi change set:
>
> revision 1.39
> date: 1999/10/01 09:34:09; author: phk; state: Exp; lines: +47 -117
> Introduce the disk mini-layer and devstat_end_transaction_buf() in cam/scsi.
>
> ..and the other files touched at the same time revived it and made the
> system bootable again.
>
> I am particularly suspicious about this:
>
> @@ -284,26 +283,14 @@
> return (error); /* error code from tsleep */
> }
>
> - if ((softc->flags & DA_FLAG_OPEN) == 0) {
> - if (cam_periph_acquire(periph) != CAM_REQ_CMP)
> - return(ENXIO);
> - softc->flags |= DA_FLAG_OPEN;
> - }
> + if (cam_periph_acquire(periph) != CAM_REQ_CMP)
> + return(ENXIO);
> + softc->flags |= DA_FLAG_OPEN;
>
> At first glance, it would appear it's re-inquiring on each open instead of
> the first open, including while it's mounted. I wasn't sure, so rather than
> risk disks, I backed the lot out and it worked again.
>
> Cheers,
> -Peter
>
>
>
> 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
broken SMPs, etc...
I have a very wierd case of a Dual PPRo SuperMicro board (two PCI busses) and when running -stable, I/O through boards on the second PCI bus is *really* delayed. Any notion on this? -verbose boot stuff below... -matt Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #1: Sat Oct 2 05:28:15 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/NOWORP Calibrating clock(s) ... TSC clock: 199459743 Hz, i8254 clock: 1193349 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 352321536 (344064K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00346000 - 0x14ff5fff, 348848128 bytes (85168 pages) avail memory = 339275776 (331324K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Found BIOS32 Service Directory header at 0xc00fdb70 Entry = 0xfdb80 (0xc00fdb80) Rev = 0 Len = 1 PCI BIOS entry at 0xdba1 Other BIOS signatures found: ACPI: $PnP: 000f5b50 Preloaded elf kernel "kernel" at 0xc032a000. Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12378086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x1237, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 chip0: rev 0x02 on pci0.0.0 found-> vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip1: rev 0x01 on pci0.7.0 I/O Recovery Timing: 8-bit 1 clocks, 16-bit 1 clocks Extended BIOS: disabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: enabled Interrupt Routing: A: IRQ11, B: disabled, C: IRQ9, D: IRQ10 MB0: IRQ15, MB1: found-> vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base ffa0, size 4 ide_pci0: rev 0x00 on pci0.7.1 intel_piix_status: primary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: primary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: primary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: ffa2 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: ffaa Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x5333, dev=0x8811, revid=0x54 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=16 map[0]: type 1, range 32, base 8000, size 26 vga0: rev 0x54 int a irq 16 on pci0.16.0 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=18 map[0]: type 3, range 32, base ffafe000, size 12 map[1]: type 4, range 32, base ef80, size 5 map[2]: type 1, range 32, base feb0, size 20 fxp0: rev 0x02 int a irq 18 on pci0.19.0 fxp0: Ethernet address 00:a0:c9:aa:16:d6 bpf: fxp0 attached found-> vendor=0x8086, dev=0x0960, revid=0x01 class=06-04-00, hdrtype=0x01, mfdev=1 subordinatebus=1secondarybus=1 chip2: rev 0x01 on pci0.20.0 Freeing (NOT implemented) redirected PCI irq 10. found-> vendor=0x8086, dev=0x1960, revid=0x01 class=05-80-00, hdrtype=0x00, mfdev=1
i386 wierd one...... kernel stack frame pointer corruption(?)
This just started happening over the last day... It's blowing up during
probing because the frame pointer is getting nuked... this is a 2xPPro
machine.
The code in question is:
static u_int64_t
isp_get_portname(isp, loopid, nodename)
struct ispsoftc *isp;
int loopid;
int nodename;
{
u_int64_t wwn = 0;
mbreg_t mbs;
mbs.param[0] = MBOX_GET_PORT_NAME;
mbs.param[1] = loopid << 8;
if (nodename)
mbs.param[1] |= 1;
isp_mboxcmd(isp, &mbs);
Which generates:
12f0 :
12f0: 55 pushl %ebp
12f1: 89 e5 movl %esp,%ebp
12f3: 83 ec 10subl $0x10,%esp
12f6: 56 pushl %esi
12f7: 53 pushl %ebx
12f8: bb 00 00 00 00 movl $0x0,%ebx
12fd: be 00 00 00 00 movl $0x0,%esi
1302: 66 c7 45 f0 6a movw $0x6a,0xfff0(%ebp)
1307: 00
1308: 8b 4d 0cmovl 0xc(%ebp),%ecx
130b: 66 c1 e1 08 shlw $0x8,%cx
130f: 66 89 4d f2 movw %cx,0xfff2(%ebp)
1313: 83 7d 10 00 cmpl $0x0,0x10(%ebp)
1317: 74 04 je 131d
1319: 80 4d f2 01 orb$0x1,0xfff2(%ebp)
131d: 8d 45 f0leal 0xfff0(%ebp),%eax
1320: 50 pushl %eax
1321: ff 75 08pushl 0x8(%ebp)
1324: e8 b7 27 00 00 call 3ae0
1329: 66 81 7d f0 00 cmpw $0x4000,0xfff0(%ebp) <-- EBP is 0
132e: 40
There isn't anything in isp_mboxcmd that I can see would wipe the stack
such that I can see in the C code or the generated output. This code
itself hasn't changed in months.
One thing that is possible is that it's a very deep callstack... It's
during probing and it may have called completion on a completing command
while down at the bottom of the stack starting another command. If you run
out of kernel stack, don't you get some other kind of fault?
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: scsi tape driver wants an update
Huh?
I'll check it out..
On Sun, 10 Oct 1999, Andy Farkas wrote:
>
> Just a reminder I guess,
>
> # uname -v
> FreeBSD 4.0-CURRENT #0: Sun Oct 10 16:16:34 EST 1999
>
> # mt retension
>
> console emits (in bright white):
>
> WARNING: driver sa should register devices with make_dev() (dev_t = "#sa/1")
>
>
>
> --
>
> :{ [EMAIL PROTECTED]
>
> Andy Farkas
> System Administrator
>Speednet Communications
> http://www.speednet.com.au/
>
>
>
>
>
> 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: scsi tape driver wants an update
This is a harmless message for the moment. I took a look at the new
make_dev stuff- it's more than a no-brainer to add because there's a lot
of stuff about supported device nodes, etc... I'll try and get back to
this after FreeBSDcon.
On Sun, 10 Oct 1999, Andy Farkas wrote:
>
> Just a reminder I guess,
>
> # uname -v
> FreeBSD 4.0-CURRENT #0: Sun Oct 10 16:16:34 EST 1999
>
> # mt retension
>
> console emits (in bright white):
>
> WARNING: driver sa should register devices with make_dev() (dev_t = "#sa/1")
>
>
>
> --
>
> :{ [EMAIL PROTECTED]
>
> Andy Farkas
> System Administrator
>Speednet Communications
> http://www.speednet.com.au/
>
>
>
>
>
> 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: scsi tape driver wants an update
On Tue, 12 Oct 1999, Daniel C. Sobral wrote: > Matthew Jacob wrote: > > > > This is a harmless message for the moment. I took a look at the new > > make_dev stuff- it's more than a no-brainer to add because there's a lot > > of stuff about supported device nodes, etc... I'll try and get back to > > this after FreeBSDcon. > > Funny, phk's comments led me to believe it's actually easier to use > make_dev() (!= makedev(), btw -- maybe you looked up the wrong > one?). No- it's easy to use but it requires thinking about all the minors you want to use and what max sizes, etc. I mean, yes, I could move it along and just delta the changes, but if it can wait a few weeks so I can actually finish off the media detection at open and the persistent density properties (which *would* have an impact about minors), I'd like to do it. The current D_NAG doesn't stop you from using the tape device, does it? > > And, talking about phk, it is also my impression that it is his > intent to push these changes as fast as he can. He gets strange at > this time of the year, y'know... I think Jordan once posted an > interesting explanation for this phenomenum. :-) > > -- > Daniel C. Sobral (8-DCS) > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > "I always feel generous when I'm in the inner circle of a > conspiracy to subvert the world order and, with a small group of > allies, just defeated an alien invasion. Maybe I should value myself > a little more?" > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: scsi tape driver wants an update
> "This time of the year" == "This time in the release cycle" > > If we want to have a somewhat clean line before 4.0 now is the time > to push it through, not after the code freeze. And could you mention when the code freeze might be so that some of us could plan our work? Perhaps I've missed something, but I hadn't heard when the freeze would be. I have a *lot* of things to consider changing before it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: scsi tape driver wants an update
On Tue, 12 Oct 1999, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Matthew Jacob >writes: > >> "This time of the year" == "This time in the release cycle" > >> > >> If we want to have a somewhat clean line before 4.0 now is the time > >> to push it through, not after the code freeze. > > > >And could you mention when the code freeze might be so that some of us > >could plan our work? Perhaps I've missed something, but I hadn't heard > >when the freeze would be. I have a *lot* of things to consider changing > >before it. > > I have no idea when the code freeze happens, neither has anybody else. > > Looking at my complete collection of FreeBSD CDs on the shelf here > I would put my money (but not too much) on january 2000. Well, you scared me with the "not after the code freeze" statement. I would like the work I do for FreeBSD 4.0 not to be as incomplete as it was for FreeBSD 3.0, so making plans as to when new feature freeze is would be a "good thing (tm)". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP stack faults...
Just a followup question on my question from a week ago or so ther was indeed a stack overflow I'd guess- I check the code path more carefully and there was a 2KB stack buffer there (oof)- and removing it seemed to make the problem go awaySo the question here is "Shouldn't this have been a more obvious fault"? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MSGBUF_SIZE
Uh, no, don't do that. There are still a lot of 386/486 machines out there. And perhaps stronger enforcement (and I'm a culprit at this) of drivers being quite unless bootverbose is set would be better. On Thu, 14 Oct 1999, Alexey Zelkin wrote: > hi, > > I propose to increase default value of MSGBUF_SIZE. Yes, I know > that current size is 8k, but today I saw that my machine > (PII-300/IDE HDD 4Gb/IDE CD/PnP sound card) started in VERBOSE mode > generated about 10k of bootstrap messages. I not sure that I want to specify > "options MSGBUF_SIZE=16384" in my kernel to see complete output > of dmesg(8). Anyway it's not problem for me, but what about other people ? > > -- > /* Alexey Zelkin && [EMAIL PROTECTED]*/ > /* Tavric National University && [EMAIL PROTECTED] */ > /* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */ > > > 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: -current crash
Well, a DDB traceback would help. Failing that, at least what does 0xc101891b correspond to otherwise, it's all ENOGUESS On Sun, 17 Oct 1999, Michael Reifenberger wrote: > Hi, > I got the following crash since a couple of time since upgrading one machine to > -current as of today. It seems to occurs during somewhat heavier diskaccess. > Sorry no detailed backtrace for now because I deleted my kernel.debug since the > last crash and dumping 256MB takes a long time... > > Does the crash trigger anything. > > SMP 2 cpus > IdlePTD 3194880 > initial pcb at 282c40 > panicstr: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > mp_lock = 0002; cpuid = 0; lapic.id = 0100 > fault virtual address = 0xdeadc0e6 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc101891b > stack pointer = 0x10:0xce004d3c > frame pointer = 0x10:0xce004d4c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 6296 (bash) > interrupt mask = none <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 0002; cpuid = 0; lapic.id = 0100 > boot() called on cpu#0 > > > Bye! > > Michael Reifenberger > Plaut Software GmbH, R/3 Basis > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current crash
Doesn't tell *me* a lot maybe a broken driver that's a KLD? It looks
like something from spec_strategy is being called that's not in the
/kernel space- could be a KLD- are your KLDs up to date for the new
kernel? Like, is this vinum perhaps?
> On Sun, 17 Oct 1999, Matthew Jacob wrote:
> ...
> > Well, a DDB traceback would help. Failing that, at least what does
> > 0xc101891b correspond to otherwise, it's all ENOGUESS
> Next try, next crash. No problem. Easy crashing :-)
>
> I tried to find the address 0xc101891b using nm(1) but can't seem to find it.
> Whats the preffered method for finding?
>
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...
> SMP 2 cpus
> IdlePTD 3194880
> initial pcb at 282c20
> panicstr: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 0102; cpuid = 1; lapic.id =
> fault virtual address = 0xdeadc0e6
> fault code= supervisor read, page not present
> instruction pointer = 0x8:0xc101e91b
> stack pointer = 0x10:0xce042cbc
> frame pointer = 0x10:0xce042ccc
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 16328 (dbv)
> interrupt mask= none <- SMP: XXX
> trap number = 12
> panic: page fault
> mp_lock = 0102; cpuid = 1; lapic.id =
> boot() called on cpu#1
>
> syncing disks... 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 done
>
> dumping to dev #da/0x20001, offset 540696
> dump 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236
>235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215
>214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194
>193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173
>172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152
>151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131
>130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110
>109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85
>84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57
>56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29
>28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> ---
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:280
> 280 dumppcb.pcb_cr3 = rcr3();
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:280
> #1 0xc015275d in panic (fmt=0xc02520cf "page fault") at
>../../kern/kern_shutdown.c:530
> #2 0xc0211b30 in trap_fatal (frame=0xce042c7c, eva=3735929062) at
>../../i386/i386/trap.c:907
> #3 0xc02117a1 in trap_pfault (frame=0xce042c7c, usermode=0, eva=3735929062)
> at ../../i386/i386/trap.c:800
> #4 0xc0211303 in trap (frame={tf_fs = -1057095656, tf_es = -1052377072, tf_ds =
>-1056112624,
> tf_edi = -559038242, tf_esi = -1052325860, tf_ebp = -838587188, tf_isp =
>-838587224,
> tf_ebx = -1056083712, tf_edx = -1070995904, tf_ecx = 16777217, tf_eax =
>-16162,
> tf_trapno = 12, tf_err = 0, tf_eip = -1056839397, tf_cs = 8, tf_eflags =
>66182,
> tf_esp = -1055894172, tf_ss = -969961680}) at ../../i386/i386/trap.c:426
> #5 0xc101e91b in ?? ()
> #6 0xc101e752 in ?? ()
> #7 0xc101e54e in ?? ()
> #8 0xc0186a82 in spec_strategy (ap=0xce042d4c) at
../../miscfs/specfs/spec_vnops.c:686
> #9 0xc0186039 in spec_vnoperate (ap=0xce042d4c) at
>../../miscfs/specfs/spec_vnops.c:133
> #10 0xc01bb371 in ufs_vnoperatespec (ap=0xce042d4c) at ../../ufs/ufs/ufs_vnops.c:2313
> #11 0xc01bad70 in ufs_strategy (ap=0xce042dd4) at vnode_if.h:940
> #12 0xc01bb341 in ufs_vnoperate (ap=0xce042dd4) at ../../ufs/ufs/ufs_vnops.c:2295
> #13 0xc0177e06 in cluster_read (vp=0xce16f380, filesize=1258299392, lblkno=137260,
>size=8192,
> cred=0x0, totread=8192, seqcount=127, bpp=0xce042e70) at vnode_if.h:940
> #14 0xc01b4517 in ffs_read (ap=0xce042e98) at ../../ufs/ufs/ufs_readwrite.c:249
> #15 0xc0182800 in vn_read (fp=0xc121cac0, uio=0xce042ee8, cre
Re: -current crash
Try it w/o vinum, procfs and nfs kernel objects. On Mon, 18 Oct 1999, Michael Reifenberger wrote: > On Mon, 18 Oct 1999, Bernd Walter wrote: > ... > > What kind of modules were you running? > (nullum)(root)# kldstat > Id Refs AddressSize Name > 17 0xc010 1eb518 kernel > 21 0xc02ec000 cdbc bktr.ko > 31 0xc1011000 c3000vinum.ko > 41 0xc000 6000 procfs.ko > 51 0xc1118000 8000 if_xl.ko > 61 0xc1121000 7000 miibus.ko > 71 0xc131e000 4c000nfs.ko > > Are these in sync with the kernel? > Yes. > > Configuration hasnt changed for weeks. > > boottext is attached. > > Softupdates is on on all FS. (Wasn't a problem so far) > (nullum)(root)# mount > /dev/da0s1a on / (ufs, local, soft-updates, writes: sync 5 async 274) > /dev/da0s1d on /usr (ufs, NFS exported, local, soft-updates, writes: sync 172 > async 5230) > /dev/vinum/data on /mnt/data (ufs, NFS exported, local, soft-updates, writes: > sync 2 async 0) > /dev/vinum/oracle on /oracle (ufs, NFS exported, local, soft-updates, writes: > sync 2 async 0) > /dev/vinum/sapdaten on /oracle/NIL/sapdaten (ufs, local, soft-updates, writes: > sync 2 async 0) > /dev/vinum/sapmnt on /sapmnt (ufs, local, soft-updates, writes: sync 2 async 0) > /dev/vinum/usr_sap on /usr/sap (ufs, NFS exported, local, soft-updates, writes: > sync 2 async 0) > procfs on /proc (procfs, local) > > Bye! > > Michael Reifenberger > Plaut Software GmbH, R/3 Basis > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Intel PRO/1000 Gigabit driver
Odd you should mention this. I have two cards and a plea from a customer to port it... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Intel PRO/1000 Gigabit driver
> Of all the gin joints in all the towns in all the world, John Reynolds~ > had to walk into mine and say: > > > > A friend just passed this along: > > > > http://www.newsalert.com/bin/story?StoryId=Coa6pWbKbyte0mtu > > > > Intel PRO/1000 Gigabit support for Linux. Source code too (non-GPL'ed very > > much like a BSD-ish license). > > Just in case anyone is wondering, I refuse to create BSD drivers based > soley on information from Linux drivers. I don't want any damn Linux > source: I want the programming manual used to create the driver in > the first place. Why? If Intel is willing to release unencumbered > Linux source, then they should be willing to release the manual as well. > If they're not willing, then I don't want anything to do with them. Okay, I'll do it then. > > > I don't have the technicals to understand how hard it would be to port, but > > the code is there for those who do! :) > > You work for Intel yet claim technical ignorance? I dunno man... :) Big company. Usual story. Lighten up. > -Bill > > -- > = > -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu > Work: [EMAIL PROTECTED] | Center for Telecommunications Research > Home: [EMAIL PROTECTED] | Columbia University, New York City > = > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > = > > > 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
does anybody but me have this problem (vgrind grinds forever...)
853 ?? Is 0:00.02 /bin/sh -c $HOME/bin/Nightly-FreeBSD-Build 855 ?? I 0:00.01 /bin/sh /home/mjacob/bin/Nightly-FreeBSD-Build 857 ?? I 0:00.02 sh ./DOMAKE buildworld 858 ?? I 0:00.03 make buildworld 861 ?? I 0:00.00 /bin/sh -ec cd /usr/src; make -f Makefile.inc0 -m /u 862 ?? I 0:00.03 make -f Makefile.inc0 -m /usr/src/share/mk buildworld 865 ?? I 0:00.00 /bin/sh -ec cd /usr/src; make -m /usr/src/share/mk - 866 ?? I 0:00.13 make -m /usr/src/share/mk -f Makefile.inc1 buildworld 1268 ?? I 0:00.00 /bin/sh -ec cd /usr/src; PATH=/usr/obj/usr/src/tmp/sb 1269 ?? I 0:00.08 /usr/obj/usr/src/tmp/usr/bin/make DESTDIR -f Makefile 1272 ?? I 0:00.01 /bin/sh -ec for entry in share/info include lib bin 21573 ?? I 0:00.03 /usr/obj/usr/src/tmp/usr/bin/make all SUBDIR_CHANGE D 21577 ?? I 0:00.01 /bin/sh -ec for entry in colldef dict doc examples in 21602 ?? I 0:00.03 /usr/obj/usr/src/tmp/usr/bin/make all SUBDIR_CHANGE D 21606 ?? I 0:00.01 /bin/sh -ec for entry in psd smm usd papers ; do (if 22824 ?? I 0:00.03 /usr/obj/usr/src/tmp/usr/bin/make all SUBDIR_CHANGE D 22828 ?? I 0:00.01 /bin/sh -ec for entry in beyond4.3 diskperf fsinterfa 22865 ?? I 0:00.04 /usr/obj/usr/src/tmp/usr/bin/make all SUBDIR_CHANGE D 22871 ?? I 0:00.00 /bin/sh -ec vgrind -f < /usr/src/share/doc/papers/ker 22872 ?? R 81:53.05 /bin/csh -f /usr/obj/usr/src/tmp/usr/bin/vgrind -f 22873 ?? Z 0:00.00 (vfontedpr) 22874 ?? Z 0:00.00 (cat) It really is vgring hanging on a file: vgrind -f < /usr/src/share/doc/papers/kernmalloc/appendix.t > appendix.ms A plain vgrind -f on this file also hangs. Anyone have a clue on this? This happens for me on an alpha. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: does anybody but me have this problem (vgrind grinds forever...)
On Sat, 23 Oct 1999, Matthew Dillon wrote: > :It really is vgring hanging on a file: > : > :vgrind -f < /usr/src/share/doc/papers/kernmalloc/appendix.t > appendix.ms > : > :A plain vgrind -f on this file also hangs. Anyone have a clue on this? > : > :This happens for me on an alpha. > : > :-matt > > The vgrind command above does not hang on my PIII test box. It takes > about a second to run. I tried both an old binary and a new binary of > vgrind. Both worked. > > I recommend compiling vgrind up w/ full debugging and attaching a > debugger to it to see what is up. Sigh. Yes. > > test3:/tmp# vgrind -f < /usr/src/share/doc/papers/kernmalloc/appendix.t > appendix.ms > test3:/tmp# md5 /usr/src/share/doc/papers/kernmalloc/appendix.t > MD5 (/usr/src/share/doc/papers/kernmalloc/appendix.t) = >bd78df7b99cbaddae3cf952b6898fe1d > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NOTE NOTE NOTE:Re: does anybody but me (..vgrinds forever...)
On Sat, 23 Oct 1999, Matthew Dillon wrote: > :It really is vgring hanging on a file: > : > :vgrind -f < /usr/src/share/doc/papers/kernmalloc/appendix.t > appendix.ms > : > :A plain vgrind -f on this file also hangs. Anyone have a clue on this? > : > :This happens for me on an alpha. > : > :-matt > > The vgrind command above does not hang on my PIII test box. It takes > about a second to run. I tried both an old binary and a new binary of > vgrind. Both worked. > > I recommend compiling vgrind up w/ full debugging and attaching a > debugger to it to see what is up. Not an executable... but I finally figured it out... Pipes possibly broken as set up by csh- csh was an old (Oct 1) csh. Until I updated csh from the current build tree, what actually was happening was vfontedpr was piping to 'cat -' and this was hanging. Wierd city, but all better now I believe... possibly related to the signal changes(?) -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock in nbufkv
You know, I noticed this also yesterday, but with a current as of yesterday. It wasn't a complete hang. Eventually it recovered and went into sbwait. The filesystem in question was a 32k/8k fs. I remade the filesystem into 8k/1k, and things went better, but also then went onto other things (the disk was an experimental disk also). On Mon, 25 Oct 1999, Peter Jeremy wrote: > I've recently upgraded a system from 3.2-RELEASE to -CURRENT as of > 30-Sept (just before the signal changes). I now find that when > I try to do a CVS checkout, the system hangs, with cvs in `nbufkv'. > > The CVSROOT is on a filesystem with standard 8K/1K blocks. The > target FS is 32k/4k. Both FS are running softupdates. This worked > without problem under 3.2. The kernel config files are basically > the same (modulo config(8) changes). FWIW, it has 'maxusers 5' > and no other options over-riding default kernel memory sizes. > > I notice that Matt Dillon found his FS stress program also hung in > nbufkv, but that was with 64k blocks. Other than that, I can't > find any reference to nbufkv here, in the PR list or in the sys > commitlogs. > > Does anyone have any ideas? Should I just go back to 8K/1K blocks? > > Peter > -- > Peter Jeremy (VK2PJ)[EMAIL PROTECTED] > Alcatel Australia Limited > 41 Mandible St Phone: +61 2 9690 5019 > ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 > > > 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
really draggy NFS access in -current?
I have the following setup for an alpha PC164 running a current -current (as in a kernel from the last day): farrago.feral.com > mount /dev/da0a on / (ufs, local, writes: sync 608 async 3306) procfs on /proc (procfs, local) mfs:30 on /tmp (mfs, asynchronous, local, writes: sync 2 async 7) bird:/export/home on /home (nfs) bird:/home/ncvs on /home/ncvs (nfs) bird:/space5/freebsd/FreeBSD-current/sys on /space/sys (nfs) bird:/space5/freebsd/FreeBSD-CVS on /cvs-src/FreeBSD-CVS (nfs) bird:/space5/freebsd/distfiles on /usr/ports/distfiles (nfs) /dev/da6a on /usr/obj (ufs, local, soft-updates, writes: sync 2 async 1) /dev/da5a on /usr/src (ufs, local, soft-updates, writes: sync 2 async 19415) Okay- I went home and left a cvs update going on /usr/src - reading from a local CVSUP repository NFS mounted on /home/ncvs. The server is a Sun SS1000 Solaris 2.6 box. 6 hours later, the cvs update is still chugging slowly along- top shows cvs as: PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 275 mjacob 2 0 8704K 7616K sbwait 1:28 1.90% 1.90% cvs most of the time. Just to check that something wasn't broken for da5, I did a test dd writing to a file just now and it happily munched along at 4MB/s. The filesystem *is* a fat block fs: a: 430489604.2BSD 8192 3276816 # (Cyl.0 - 267*) I suppose the blockage could be at the ufs end... Anyone have a pointer as to what try to narrow this down- mainly to save me the trouble of actually thinking about it (got a lot else on mind)? Unacceptably bad something or others here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
Hmm. Could be. That's a good thing to try. The connection is a Full Duplex 100BaseT to a 3com switch (both alpha/freebsd && Solaris) so what you suggest Just Didn't Occur To Me (tm). Thanks On Thu, 28 Oct 1999, Matthew Dillon wrote: > :Okay- I went home and left a cvs update going on /usr/src - reading from > :a local CVSUP repository NFS mounted on /home/ncvs. The server is a > :Sun SS1000 Solaris 2.6 box. 6 hours later, the cvs update is still chugging > :slowly along- top shows cvs as: > : > : PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND > : 275 mjacob 2 0 8704K 7616K sbwait 1:28 1.90% 1.90% cvs > : > :most of the time. Just to check that something wasn't broken for da5, > :I did a test dd writing to a file just now and it happily munched along > :at 4MB/s. > : > :The filesystem *is* a fat block fs: > : > : a: 430489604.2BSD 8192 3276816 # (Cyl.0 - 267*) > : > :I suppose the blockage could be at the ufs end... Anyone have a pointer > :as to what try to narrow this down- mainly to save me the trouble of > :actually thinking about it (got a lot else on mind)? Unacceptably bad > :something or others here. > > This kinda sounds like packet loss to me, causing the NFS link to > back off. This would be true for both a udp or tcp nfs mount, but > tcp tends to be more sensitive to packet loss. > > You should be able to tell by ktrace'ing the running cvs and then > kdump -R'ing the resulting ktrace.out file to see if weird delays are > occuring on nfs-related syscalls. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: really draggy NFS access in -current?
UDP. Local network. Very puzzling. On Thu, 28 Oct 1999, Andrew Gallatin wrote: > > Matthew Jacob writes: > > > > Hmm. Could be. That's a good thing to try. The connection is a Full Duplex > > 100BaseT to a 3com switch (both alpha/freebsd && Solaris) so what you > > suggest Just Didn't Occur To Me (tm). Thanks > > > > Is this a UDP or TCP mount? > > I've seen very strange things with TCP mounts of Solaris 2.7 servers > with i386 clients running recent -currents. Things start out just > fine (3-4MB/sec), then after some period of time (a day or 2 > generally), the performance degrades down to a few KB/sec. > > I didn't really have time to look into it properly, so I just switched > all my mounts over to udp & the problem just went away. > > Drew > > -- > Andrew Gallatin, Sr Systems Programmerhttp://www.cs.duke.edu/~gallatin > Duke University Email: [EMAIL PROTECTED] > Department of Computer SciencePhone: (919) 660-6590 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ick! blockdev goop with root in -current?
WARNING: / was not properly dismounted start_init: trying /sbin/init swapon: adding /dev/ad0b as swap device Automatic reboot in progress... /dev/rwd0s4a: 2199 files, 38154 used, 209893 free (277 frags, 26202 blocks, 0.1% fragmentation) [HANGS...] ^Cfsck in free(): warning: page is already free. fsck in free(): warning: page is already free. fsck in free(): warning: chunk is already free. fsck in free(): warning: junk pointer, too low to make sense. fsck: panic: lost 2 buffers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ick! blockdev goop with root in -current?
On Sat, 30 Oct 1999, Poul-Henning Kamp wrote: > > This has nothing to do with blockdevs. It is an old standing bug in fsck > which only happens when you interrupt it. "Uncle Milt" from vicor has a > set of fsck patches in for review with Kirk where this should be fixed > as well. > > In all likelyhood your fsck didn't hang but was working its way through > things. Try ^T next time rather than ^C Okay. Sorry for the false alarm... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD 4.0 SCSI Tape Driver
The design phase for FreeBSD 4.0 is coming to a close. There are a couple of things I'm planning on (belatedly) for the SCSI tape driver. I'd like feedback and suggestions about these and other things, so pass 'em my way. One change I'm thinking about is probably controversial, so I'd like to get some feedback on it now. Since this is a major release step, this would be the time to make such changes if at all. I'd like to make the *default* tape EOT handling behaviour such that all tapes use only *one* filemark at EOT rather than the current *two* filemarks at EOT (except for QIC). Probably one of the highest breakage items for this driver is someone adding yet another unknown QIC-like tape device which behaves unhappily when the driver tries to write two filemarks at the end of tape. Insofar as I know, the convention for two filemarks at the end of tape is useful only for devices that cannot determine physical eot (1/2" Reel tapes)- and I haven't seen those around for quite some time. There already is an ioctl (and control via mt(1)) to change the default eot model. There could very well also be a config option too. I'd like to make the 1 Filemark at EOT the default though. I'll have to fix tcopy, and I want to give some thought so that there are no compatibility and interchange problems, but if those concerns are adequately covered I think this is the right thing to do. So- let me know, either via this list or privately. Thanks in advance... -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
> > There seems to be a great amount of confusion about the 2 EOF marks on > tapes. It has nothing to do with physical EOT, even the 556BPI 1/2" > tape drives on an IBM 1401 can detect physical EOT. The problem is > with LOGICAL EOT, most tape drives do not have a logical EOT write > command, even modern drives. So when you overwrite a tape how do you > tell that you have gotten to the logical end of data, well, you write > 2 EOF marks. > > The other thing that causes lots of folks confusion here is that some > tape drives backspace over an EOF mark that is written, thus it gets > real fun to put 2 EOF marks on the tape. You have to mt eof, mt fsf, > mt eof. Yes, that *may* be a problem. Also, when you write two filemarks, as best as I can tell for some hardware, this is never able to be read back as two filemarks. > > Since you do not point out how we are suppose to detect logical EOT > on a tape I object to any elimination of dual EOF to indicate logical > EOT. > > > > There already is an ioctl (and control via mt(1)) to change the default > > eot model. There could very well also be a config option too. I'd like to > > make the 1 Filemark at EOT the default though. I'll have to fix tcopy, > > and I want to give some thought so that there are no compatibility > > and interchange problems, but if those concerns are adequately covered I > > think this is the right thing to do. > > 1 filemark can not be used for EOT, it is EOF, you can't tell if what you > read next is another file or not that may have been left by a previosly > longer usage on the tape. > > > > > So- let me know, either via this list or privately. > > Thanks in advance... > > Won't work, or would you care to explain how we are now suppose to detect > logical EOT? The driver detects EOT during reads. Subsequent reads from the user application return no data. A user application that detects a residual twice in a row knows it is at EOT. Nearly all other Unix systems work fine with this mechanism. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
Reread/reresponse, sorry- ENOCOFFEE: > > > > 1 filemark can not be used for EOT, it is EOF, you can't tell if what you > > read next is another file or not that may have been left by a previosly > > longer usage on the tape. > > Well, read until *BLANK CHECK* seems to be what the driver can and should do. Let me ponder this some- I believe what I propose actually works fine for all the devices we currently support (hell, I use it all the time myself). If you can provide an actual example of a SCSI tape device that if you take FreeBSD-current or FreeBSD-3.3 and do a 'mt seteotmodel 1' on and *not* be able to detect EOT, let me know! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
On Mon, 15 Nov 1999, Rodney W. Grimes wrote: > > > > Reread/reresponse, sorry- ENOCOFFEE: > > > > > > > > > > > > 1 filemark can not be used for EOT, it is EOF, you can't tell if what you > > > > read next is another file or not that may have been left by a previosly > > > > longer usage on the tape. > > > > > > > > > > Well, read until *BLANK CHECK* seems to be what the driver can and should > > do. Let me ponder this some- I believe what I propose actually works fine > > for all the devices we currently support (hell, I use it all the time > > myself). If you can provide an actual example of a SCSI tape device that > > if you take FreeBSD-current or FreeBSD-3.3 and do a 'mt seteotmodel 1' on > > and *not* be able to detect EOT, let me know! > > You won't get ``blank check'' if the tape has previosly been written > past where you just finished writing. Instead you often get trash. Sorry, no. When you write a tape with these devices there's always a leading erased area. That's why if you overwrite the front a tape you can't skip past this area to recover data you really need. A misfeature of modern technology. > > In your other message you talk about the driver getting 2 residuals > in a row, well, unless you write the 2 EOF's you won't always get that... > depends on if the tape drive does it automagically (which many newer > drives do, they write 2 eof's and backspace over 1 of them for you when > ever you tell them to write EOF, the drive itself uses 2 EOF's to > determine logical EOT :-)). I repeat what I said in other mail- can you actually show me a tape drive where what I propose really doesn't work? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
Okay- I hear you both. What do you do with QIC drives which cannnot write 2FM then? On Mon, 15 Nov 1999, Bob Bishop wrote: > Hi, > > At 11:01 am -0800 15/11/99, Matthew Jacob wrote: > >I repeat what I said in other mail- can you actually show me a tape drive > >where what I propose really doesn't work? > > I have access to a few assorted drives and I'll do the experiments but > don't hold your breath. > > BUT I have to say that on principle I'm with Rod on this one: EOF != EOT > and mixing them up is a recipe for (inter alia) finding you can't read back > dumps when you need them. > > > -- > Bob Bishop (0118) 977 4017 international code +44 118 > [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK > > > > > 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: FreeBSD 4.0 SCSI Tape Driver
On Mon, 15 Nov 1999, Rodney W. Grimes wrote: > > > > Okay- I hear you both. > > > > What do you do with QIC drives which cannnot write 2FM then? > > Can you give me a model of a QIC drive that has the ``can't write 2 FM's'' Just about all. For that matter, it isn't just QIC drives- see all the quirk entries in scsi_sa for 1FM and you'll see the scope of the problem. Nearly all of the problem reports in the last year had to do with a new drive that cannot do 2 FMs in a row. They're very commmon. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
> > Every night, I do a partial backup, one file on tape for each file > system, about 12 in all. Subsequently I read the tape and list > contents until I hit EOT. OK, the first time I use a tape, there will > be nothing behind it. But the next time, the total length of tape > written may be shorter, so there will be data after logical EOT. How > is the program going to know where to stop? Every time you stop writing, that's EOT. You can't read past it with SCSI drives- really, no, you can't. You can seek to end of recorded data and start writing, but you can't read past where you've written to. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver
> > > > Sorry, no. When you write a tape with these devices there's always a > > leading erased area. That's why if you overwrite the front a tape you > > can't skip past this area to recover data you really need. A misfeature of > > modern technology. > > Is this anchored in the standards? What about DLT? What about future > drives? I certainly wouldn't rely on anything that isn't guaranteed > to stay that way. What happens if I write a tape on FreeBSD and read > it in on System V? The whole point of what I'm trying to is to conform to other systems. I wouldn't do it if it added to interoperability problems. > > >> In your other message you talk about the driver getting 2 residuals > >> in a row, well, unless you write the 2 EOF's you won't always get that... > >> depends on if the tape drive does it automagically (which many newer > >> drives do, they write 2 eof's and backspace over 1 of them for you when > >> ever you tell them to write EOF, the drive itself uses 2 EOF's to > >> determine logical EOT :-)). > > > > I repeat what I said in other mail- can you actually show me a tape drive > > where what I propose really doesn't work? > > I think this question is the wrong way round. Apparently. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver- Okay, Okay, you win....
Too many people have objected. I didn't make my case clearly enough, but because enough people of have raised issues, the default won't be changed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver- Okay, Okay, you win....
On Tue, 16 Nov 1999, Greg Lehey wrote: > On Tuesday, 16 November 1999 at 8:04:05 -0800, Matthew Jacob wrote: > > > > Too many people have objected. I didn't make my case clearly enough, > > but because enough people of have raised issues, the default won't > > be changed. > > I think this is the correct decision in the short term. In the longer > term, we should continue to discuss the matter. Yes, well, I was driven by the coming of 4.0 My *original* plans for 4.0 was to do a complete rewrite of the tape driver using the HP sponsored TAPEALERT initiative, but I've had only a fraction of the time available. So, what with fixing some bugs, trying to make sure that subdevices come back with latchable settings, that'll probably be it for tape in 4.0. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 4.0 SCSI Tape Driver- Okay, Okay, you win....
On Sat, 20 Nov 1999, J Wunsch wrote: > Matthew Jacob <[EMAIL PROTECTED]> wrote: > > > Too many people have objected. I didn't make my case clearly enough, > > but because enough people of have raised issues, the default won't > > be changed. > > Too bad. I think your idea was absoultely right, and i'm rather tired > myself to have to `fix' it for every new tape drive we encounter. All > the current tape drives do support a form of physical EOD marks, where > you can't read on once you've hit EOD. > > The driver could easily have faked the double-filemark at EOT, so the > API wouldn't have changed at all. (Just as you see the EOD from the > tape, finish the current transfer and return a "short read", and being > asked a second time, return a null read. Upon further attempts, > return an error.) Sigh. Every time I've suggested this in both FreeBSD and NetBSD I've been shot down with that too. > > Btw., Matt, couldn't modepage 0x10, field "EOD defined" be used in > order to decide whether a tape drive supports a physical EOD notation, > and thus doesn't require two filemarks at EOD? If i read the standard > correctly, those fields should be set to 3 for a tape drive that > doesn't support physical EOD. (I can't verify, i don't have any such > drive.) Yes, I've though about this. I should indeed check. But I suspect that there is breakage with a number of drives here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Intel PRO/1000 Gigabit driver
Well, I'm *almost* there getting this driver to work well (it's now *just* managing to run without barfing all over memory). It's been a humiliating experience- I'm just not that hot with Network drivers as I spend most of my time in mass storage. This chipset is, uh, interesting too (as best as I can tell, any transmit decriptor of less than 60 bytes in length is either ignored or sent out with a frame error). And because I'm less experienced in doing NIC drivers, I'm sure folks will say, "You did WHAT? Why did you do that?"... So, I have some other items to take care of, but I plan to put this out for testing in a couple of weeks (slipped my original schedule, didn't I?).. Just wanted to let you know I hadn't forgotten and dropped it on the floor... -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
Well, I am truly f*cked now. I read enough of this thread, saw nothing new in UPDATING, and did the following: alpha kernel from today MAKEDEV from today (but not a make world install- the binaries/libs are ~week old) cannot get out of single user mode. fsck core dumps. Any failed command causes the single user shell to exit. What can I do to get out of this disaster other than attempt a reinstall? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
> Can't you boot from the old kernel? Or have you already wiped the I can boot the old kernel. A MAKEDEV using the new MAKEDEV has now wiped all block devs, so swapon, etc. ,fail.. However, this is the conundrum- it's not safe to do a 'make installworld' on a two week old kernel, but the new kernel with old mount, fsck, etc., obviously cannot cope with the new 'raw-only' devices. An experience like this will move users to OpenBSD. This kind of jump up is completely unacceptable. > bdevs? If so, how about the fixit floppy/CD-ROM? This is alpha, and no floppy. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FOLLOWUP: Re: HEADS-UP: bdevs have been assimilated.
Sorry- maybe more of an edge case. It really has to do with 'ad' support seemingly vanishing from the alpha. Or, rather, it's hard to say exactly what has happened: Mounting root from ufs:/dev/rad0a no such device 'rad' setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 But then, there's an older system on da0: Mounting root from ufs:da0a WARNING: clock gained 14 days -- CHECK AND RESET THE DATE! swapon: adding /dev/da0b as swap device which makes it less of a bad bad but still very very annoying. It's hard to find out what's going on because even though there is some vague attempts to stop the loader (whereupon you get a phony 'ok' prompt), no passing of variables set there occurs (so no 'bootverbose'). So, it's conceivable that this is just edge case alpha breakage. With < 2 weeks to feature freeze for 4.0 it is very hard for some of us who attempt to make sure things we deliver actually work on both platforms if the second platform is broken. I'm plenty pissed off, but, c'est la vie... -matt On Thu, 2 Dec 1999, Matthew Jacob wrote: > > Well, I am truly f*cked now. I read enough of this thread, saw nothing new > in UPDATING, and did the following: > > alpha > > kernel from today > MAKEDEV from today > (but not a make world install- the binaries/libs are ~week old) > > cannot get out of single user mode. fsck core dumps. Any failed command > causes the single user shell to exit. > > What can I do to get out of this disaster other than attempt a reinstall? > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
(removed from general list) > Slow down. You are getting screwed by a combination of things. It > isn't all phk's fault. > > The bdev elimination is one factor, but the most important one (the > fsck/mount segv) is due to int/long breakage introduced version 1.85 > of mount.h. This happened at the worst possible time (just after the > bdev elimination). > > If I wasn't such a timid committer, I would have just committed the > damned fix yesterday, before running it by Kirk & you wouldn't have > had this problem. I tried to be vocal about it (messages to -alpha > and -committers), but I guss that wasn't enought. Well, I wasn't back in town until last night with 5000 messages to catch up on. Sorry for not getting your questions first. There are other things broken too. Oh well- I really shouldn't get wired. *BSD will get taken as a serious effort as much as it deserves based upon what actually *occurs*, not what I would *wish* to actually occur -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sorry....
> Well, I wasn't back in town until last night with 5000 messages to catch > up on. Sorry for not getting your questions first. > > There are other things broken too. Oh well- I really shouldn't get wired. > *BSD will get taken as a serious effort as much as it deserves based upon > what actually *occurs*, not what I would *wish* to actually occur Sorry- I shouldn't get so bitchy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Apologies
I realize that I have been much more upset and unpleasant about this than the situation warranted, and I would like to extend my apologies to all and sundry for venting my frustration so publicly. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
> In message <[EMAIL PROTECTED]>, Matthew > Jacob writes: > > > >Well, I am truly f*cked now. I read enough of this thread, saw nothing new > >in UPDATING, and did the following: > > > >alpha > > > > kernel from today > > MAKEDEV from today > > (but not a make world install- the binaries/libs are ~week old) > > > >cannot get out of single user mode. fsck core dumps. Any failed command > >causes the single user shell to exit. > > This doesn't sound like a /dev related problem to me. You're probably right about this. Maybe we should all call it "Matt's really bad day where he got vicious" and we'll try again tomorrow after a new update/nightly build. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWUP: Re: HEADS-UP: bdevs have been assimilated.
> In message <[EMAIL PROTECTED]>, Matthew > Jacob writes: > > > >Sorry- maybe more of an edge case. It really has to do with 'ad' support > >seemingly vanishing from the alpha. Or, rather, it's hard to say exactly > >what has happened: > > > > > >Mounting root from ufs:/dev/rad0a > >no such device 'rad' > > Bruce and Mike smith took out a testing-shim a little early which > allowed us to test with /dev/r* in /etc/fstab. Change your > /etc/fstab to read /dev/ad0a and you should be happy again. Actually, no, I'm not- the 'rad' was less worrisome than the other stuff (like fsck core dumping, mount dyings, etc.). but, but we'll see what happens tomorrow. I'll be up to date and have a fresh build with the new mount.h and I'll make it work if it doesn't (I have to as I have too many other things backed up behind this toe stub). I probably should have used an i386 to test this change first rather than an alpha. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
With todays' build, the previous problems went away. Other problems have replaced them (sio's wierd again for alpha), but that's a different story. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current no longer builds on the alpha
What is beast? I was happily able to build -current at about 5 this morning on a pc164. On Fri, 3 Dec 1999, Jordan K. Hubbard wrote: > cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/reader.c > cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/skeleton.c > cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/symtab.c > cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/verbose.c > cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/warshall.c > cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -static -o yacc closure.o error.o >lalr.o lr0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o >warshall.o > install -c -o root -g wheel -m 555 /usr/src/usr.bin/yacc/yyfix.sh >/usr/obj/usr/src/tmp/usr/bin/yyfix > *** Signal 11 > > Stop in /usr/src/usr.bin/yacc. > *** Error code 1 > > > It dies every time right there, which makes me think this is more than > the usual memory/cache issues. Also, the alpha in question (beast) > will build the world just fine from 3 days ago. > > - Jordan > > > 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: -current no longer builds on the alpha
Q'uelle strange- what I have... well, we'll see what my nightly build brings... On Fri, 3 Dec 1999, Jordan K. Hubbard wrote: > > What is beast? I was happily able to build -current at about 5 this > > morning on a pc164. > > It's an Aspen systems DEC Durango PC164 motherboard based system. > > - Jordan > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current no longer builds on the alpha
> As Matthew Jacob wrote ... > > > > Q'uelle strange- what I have... well, we'll see what my nightly build > > brings... > > Mine fell over in 'truss'. I already reported it to Marcel, looks > like something was changed in kdump/mkioctls, a script that 'truss' also > uses. Mine's still going (I start mine at 0430 PST8PDT, the update from freefall runs at 0107 PST8PDT)) Nope, what a coincidence. It *just* finished. Went all the way through w/o errors on a buildworld. > > > > > On Fri, 3 Dec 1999, Jordan K. Hubbard wrote: > > > > > > What is beast? I was happily able to build -current at about 5 this > > > > morning on a pc164. > > > > > > It's an Aspen systems DEC Durango PC164 motherboard based system. > > Doesn't that one have ECC memory (refering to a previous post where > you theorised a bit on memory problems and sig-11s ;) It may or may not, but memory problems are typically detected pretty well on alphas and you'll get a 670 machine check if it was recoverable (which the PALcode has already done, except for TurboLaser if the memory problem was caused by one of the I/O boards (PALcode cannot go offboard to read registers on another board to find out what address was porked, IIRC)), or a 660 machine check, which is a panic. At any rate, this is a different entry point than mmu traps. It's not like I don't get sig-11s... ctags always seems to core dump on me- somewhere up in libc. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabel -W now seems to not work(?)
It seems that in the latest running around with things, disklabel -W doesn't seem to quite work, at least on the alpha- it seems to set the label writable, but the next attempt to open the disk sets the label area non-writable again. Before I go tracking this down as a bug, is it? Secondly, how do people feel about having dd(1) use the DIOCWLABEL argument to enable writing the label area of the disk if the output is a disk and there is no offset from zero? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
Wow. Okay. On Mon, 6 Dec 1999, Bruce Evans wrote: > On Sat, 4 Dec 1999, Matthew Jacob wrote: > > > It seems that in the latest running around with things, disklabel -W > > doesn't seem to quite work, at least on the alpha- it seems to set the > > label writable, but the next attempt to open the disk sets the label area > > non-writable again. > > It hasn't quite worked for 5 years now (except for additional not workage I was being polite... :-) > on alphas). There are layers and layers of bugs and features which > combine to make it very difficult to write the label sector except in the > normal way: > ... > > (4) Write protection and i/o snooping of labels is half-intentionally > broken for i/o to the whole disk slice (e.g., /dev/da0). It can be > used to work around bugs and features in the write protection and > snooping. E.g., the only way to clear a label is to write garbage > over it using the whole disk slice. Writing garbage over it using > an ordinary slice is prevented by the i/o snooping code. > > (5) The whole disk slice was broken for alphas in rev.1.63 of > subr_diskslice.c, by putting a label on it if the underlying disk > contains a label. The underlying disk contains a label in the > "dangerously dedicated case". If there is a label, then it is > initially write protected, and always snooped on. This closes > the back door in (4). > > > Secondly, how do people feel about having dd(1) use the DIOCWLABEL > > argument to enable writing the label area of the disk if the output is a > > disk and there is no offset from zero? > > Unwell. The whole disk device (e.g., /dev/da0) is already entirely > write-enabled and unsnooped. except as in (5). Write protection of > labels should continue to apply to partitions (e.g., /dev/da0a and > /dev/da0c) even if the partitions start at offset 0. The reason I brought this all up is that XX0 access would not work for me. The disk had a dangerously dedicated label, but I wanted to overwrite the front of the disk. Impossible. I've noticed this also in the case where you have slices but want to go to a dangerously dedicated label- no can do. Hence a "Well, gee, let's see if disklabel -W will help". Nope. So, what's the answer about what to do? I sure wouldn't want to leap in and 'fix' it because I don't have a good feel for the ins and outs of this stuff here (odd- I usually have a strong sense of knowing what's right, but this house of cards gives me the creeps). I have a hacked dd that works for me, but this can't be the right general solution. Probably if I added my disk tester into the test suites, that would allow one to force this (although by default the tester I use always skips label areas). -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
Good, but like just having popcorn for dinner, somehow unsatisfying... On Sun, 5 Dec 1999, Garrett Wollman wrote: > < said: > > > So, what's the answer about what to do? > > exec 3 dislabel -W xx0 > spam /dev/xx0 > exec 3<&- > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > [EMAIL PROTECTED] | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > > > 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: disklabel -W now seems to not work(?)
Sorry- I missed it. I was in Kaui. On Sun, 5 Dec 1999, David O'Brien wrote: > > It seems that in the latest running around with things, disklabel -W > > doesn't seem to quite work, at least on the alpha- it seems to set the > > This was the topic of my "Fscking disklabel crap" mail to freebsd-alpha > on Fri, 26 Nov 1999 11:56:59 -0800, which nobody responded to. > > -- > -- David([EMAIL PROTECTED]) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: disklabel -W now seems to not work(?)
Well, there *are* workarounds, but I agree that this is broken. I think we had better fix disklabel somehow. I'm just wary of leaping in to 'do it', because I'm sure I'll break more than I fix. On Sun, 5 Dec 1999, David O'Brien wrote: > On Mon, Dec 06, 1999 at 02:50:43AM +1100, Bruce Evans wrote: > > (5) The whole disk slice was broken for alphas in rev.1.63 of > > subr_diskslice.c, by putting a label on it if the underlying disk > > contains a label. The underlying disk contains a label in the > > "dangerously dedicated case". If there is a label, then it is > > initially write protected, and always snooped on. This closes > > the back door in (4). > > How do we fix this problem? I keeps from from > ``dd if=/dev/da1 of=/dev/da2'' ?? I was very peeved at having to put the > disks on a Solaris box to do such a normal Unix task. > > -- > -- David([EMAIL PROTECTED]) > > > 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
oh, btw...
>
> How do we fix this problem? I keeps from from
> ``dd if=/dev/da1 of=/dev/da2'' ?? I was very peeved at having to put the
> disks on a Solaris box to do such a normal Unix task.
this will fix your dd
Index: dd.c
===
RCS file: /home/ncvs/src/bin/dd/dd.c,v
retrieving revision 1.27
diff -u -r1.27 dd.c
--- dd.c1999/10/03 18:49:51 1.27
+++ dd.c1999/12/05 23:17:16
@@ -216,6 +216,16 @@
if (ioctl(io->fd, FIODTYPE, &type) == -1) {
err(1, "%s", io->name);
} else {
+if (type & D_DISK) {
+static int one = 1;
+#ifndefDIOCWLABEL
+#defineDIOCWLABEL _IOW('d', 109, int)
+#endif
+fprintf(stderr, "is a disk\n");
+if (ioctl(io->fd, DIOCWLABEL, &one) < 0) {
+perror("DIOCWLABEL");
+}
+}
if (type & D_TAPE)
io->flags |= ISTAPE;
else if (type & (D_DISK | D_MEM))
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mount(2) broken?
Happens to me every boot. And I'm up to date with all binaries and kernel. I don't have softupdates on the root filesystem. On Mon, 6 Dec 1999, Mike Smith wrote: > > On Mon, 6 Dec 1999, Nick Hibma wrote: > > > > > Most probably this is exactly the problem I was describing to you a > > > couple of days ago on IRC, phk. > > > > > > The solution is to boot single user, fsck / and reboot. After that > > > things are back to normal. Even crashing the machine does not make this > > > problem reoccur. > > > > Nah. This is about the third time I've seen this. I hadn't really > > gathered any useful information (and no data was lost) so I didn't bother > > to report it. I suspect it has something to do with soft-updates however. > > > Me too. > > > I just manifested this after a particularly nasty crash this evening > (about 500 outstanding buffers), but softupdates weren't active. > > (It's too easy to kill the system with them enabled; there's a whole > realm of exploration still untouched there.) > > -- > \\ 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-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: mount(2) broken?
On Tue, 7 Dec 1999, Luoqi Chen wrote: > > I've seen this exact same thing before too. In fact it was two rather > > annoying things, one being a single solitary last buffer that wouldn't > > sync and thus left the whole fs marked dirty, and then fsck would check > > it, see it was fine, but mount wouldn't recognize that it was clean. > > > > 'Course I saw this this morning too. Yes, with a new kernel, new devices, > > ata driver, and new world. 'Twas very odd. > > > > - alex > > > I'd like to add something about the last buffer wouldn't sync. This occurs > when a shutdown syscall is issued when the syncer process is asleep waiting > for a buffer write to complete. The write will never complete, because the > syncer won't be given a chance to run again, and the buffer will stay marked > as busy and become the buffer that wouldn't sync. I haven't thought about > a clean way of handling this situation, maybe some of you out there have > better ideas... Ah. That *could* be happening to me, but this happens even with a quiescent system (I mean, several times with nothing happening). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
> On Wed, Dec 15, 1999, George Michaelson wrote: > > Why do we have to make FreeBSD more like HP-UX? the most sucky UNIX ever > > invented apart from AIX? Hmmph. When FreeBSD has a fully SMP-ized kernel, including filesystem and network stacks and device drivers, and when it has something that allows dynamic paged kernel objects and when it has a device/system configuration manager that successfully balances persistent device names with dynamic reconfiguration, *then* do the comparison. Until then, umm, your underwear is showing, jack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV (Re: Speaking of moving files (Re: make world brokenbuilding fortunes ) )
On Wed, 15 Dec 1999, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Daniel C. Sobral" writes: > >"Rodney W. Grimes" wrote: > >> > >> Yea... been hearing that for 4 years... one of it's big short comings is > >> that it needs a persistent backing store for this. Sounds like this C > >> program could fullfill one of the missing parts of devfs :-) > > A "devd" program would solve 98% of what devfs could solve. It cannot > solve the homebrew-a-vnode-for-the-root-fs problem. FreeBSD needs a > "devd" program *anyway* because what good is dynamic devices if you > can't do something intelligent with them when they appear (mount/ifconfig > etc etc etc). I mostly agree with you. I tend to also not worry terribly much about root-fs type issues, except that I keep being told by *my* customers that this is what they want, particularly for large SANs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV (Re: Speaking of moving files (Re: make world brokenbuilding fortunes ) )
> > I would really like to see the devd functionality to live in init > and at the same time I wouldn't mind if init were taught to keep > important programs running, things like sshd, inetd, syslogd and > similar should be restarted if they die. > > No, I don't want sysV runlevels or the weird shit AIX has. I'm sure > a clean and sensible way can be found, if some mental energies are > poured into the problem. > Isn't this throwing an awful lot onto init? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV (Re: Speaking of moving files (Re: make world brokenbuilding fortunes ) )
> >Isn't this throwing an awful lot onto init? > > Not really... > > The meta-daemon part is no different from keeping gettys in the air... > > The devd thing consists of selecting on some magic fd and running a > program when something happens. This could be done with a getty > like daemon too of course. I was just thinking it could get tricky and have subtle ordering bugs of new tty devices, changes to ttys and signals all about the same time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV (Re: Speaking of moving files (Re: make world brokenbuilding fortunes ) )
> > > >I was just thinking it could get tricky and have subtle ordering bugs of > >new tty devices, changes to ttys and signals all about the same time. > > Well, they are no less subtle by having them in different processes... No, but possibly easier to track and debug. Just a minor nit. N'mind... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV (Re: Speaking of moving files (Re: make world brokenbuilding fortunes ) )
> But lets say you add a pccard on which you want a getty, so devd will > have to tell init to run a getty on that port wouldn't it ? Of course- but this lays out very clearly where breakage could occur and leads to be better flexibility. Let's assume this is devd and leave to the side whether devfs would or would not be better. a. insert card b. card recognized (8 new tty ports) c. devd awakened d. (re)makes /dev nodes e. updates /etc/ttys [ this is a debatable step ] f. notifies init (kill(1,1)) g. init awakens h. rescans /etc/ttys i. spawns new gettys, kills dead ones (the old rmut hat dance) Groups a-b, c-f, g-i, are separable steps with pretty clear audit trail stops as to how things could go. Let's take another more complicated example: a. SAN Fabric SCN (change notify) is received by Qlogic FC-AL driver. b. Fabric Nameserver rescanned- 32 new disks arrived, 8 disks left. c. ASYNC notification upcall to CAM is made [ this is as yet an undesigned area, but assume that does like what a camcontrol rescan now does (or is supposed to)- new disks get assigned new instance numbers, dead disks are either safely removed of pack invalidation occurs if they were still open ] d. devd awakened e. (re)makes /dev nodes f. [ VARIABLE HOOK HERE- POLICY LEFT OPEN ] g1. vinum awakened, yatta yatta yatta g2. VxVM (Veritas Volume Manager) awakened, yatta yatta yatta g3. Specified perl script activated, (auto disklabel, newfs, mount) ... Again, Groups a-b and d-f are separable steps with pretty clear audit trail stops. It's not quite clear what step G should be, or whether it should be left to 3rd party hooks, but it's pretty clear to me that putting volume management in init makes no sense whatsoever. For things like what init itself manages (tty lines), sure it does. Otherwise, no. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: ntp4 to replace xntpd
Huh? What about the impact on all ntp.conf files? Or is this seamless? On Thu, 16 Dec 1999, Ollivier Robert wrote: > This is a HEADSUP message to warn all current users that tha following is > being done: > > - disable xntpd build > - enable ntp build > - removal of old xntpd/xntpdc binaries as they've been renamed > - modifications in /etc/defaults/rc.conf to take the new daemon into > account. > > xntpd will be "cvs removed" in one week approx. > -- > Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- [EMAIL PROTECTED] > The Postman hits! The Postman hits! You have new mail. > > > 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: Linux vs. OpenBSD vs. FreeBSD vs. NetBSD (fwd)
fyi -- Forwarded message -- Date: Thu, 16 Dec 1999 12:15:48 -0500 (EST) From: Paul B. Brown <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Linux vs. OpenBSD vs. FreeBSD vs. NetBSD Resent-Date: 16 Dec 1999 17:15:54 - Resent-From: [EMAIL PROTECTED] Resent-cc: recipient list not shown: ; > Is there a handy collection of arguments over which OS is better? Hu . . . . this is a much debated topic. In a nutshell: Linux: 1. More prevalent 2. More support 3. More software ported 4. Multi-platform: Intel, Alpha, Sparc, Mac, PowerPC, etc. 5. GPLed Even though I think Linux needs further tweaking to become as high stress as FreeBSD, I still believe it is the best bang for the buck. There is more interest in this OS than any of the other "free" OSes. This is a plus and a minus. The plus is that it will continue to advance as an OS and a production platform. The minus is that now business needs may begin to drive Linux and that will skew the original intent of Linux and it's reason for being as good as it is. I've been talking to some Systems Operations boys at NASA HQ in Washington, DC who have done (and continue to do) testing on the "free" OSes as stable platforms for research and production at NASA. They found that even now, FreeBSD or OpenBSD are their choice either because of stability or speed. I found that interesting given some of the claims I've seem on this list, and others, that Linux is now as stable and high performance as FreeBSD on Intel. The NASA boys don't think so. FreeBSD: 1. Higher performance especially in the network stack. 2. Can run any Linux application using emulator. 3. BSDL 4. Intel Only: This means the OS is tweaked for max performance. This is a very stable, very robust, high stress-capable OS for Intel platforms only. If you want to get the max out of your production Intel platform, use FreeBSD. Yahoo does. The choice at NASA HQ. NetBSD: 1. Runs on a lot of old hardware: PDP, VAX, 3B2, etc. 2. Very stable. 3. BSDL. This one is used if you have some old hardware lying around and want to get it functional again. This is great for older companies, Universities, and research facilities. OpenBSD: 1. Runs on a lot of old hardware: PDP, VAX, 3B2, etc. 2. More secure out of the box than any other xBSD. 3. Offshoot of NetBSD. 4. Very stable. 5. BSDL. The same as NetBSD except it's security features are it's main selling point. There is my $0.02 worth. :-) Paul --- Paul B. Brown [EMAIL PROTECTED] President Brown Technologies Network, Inc. http://www.btechnet.com/ Systems and Applications Design, Development, Deployment, and Maintenance --- -- To unsubscribe: send e-mail to [EMAIL PROTECTED] with 'unsubscribe' as the subject. Do not send it to [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: ntp4 to replace xntpd
Thanks for the very clear writeup of what we can expect. I'm happy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
