Re: patches for test / review
> > Hm. But I'd think that even with modern drives a smaller number of bigger > I/Os is preferable over lots of very small I/Os. Not necessarily. It depends upon overhead costs per-i/o. With larger I/Os, you do pay in interference costs (you can't transfer data for request N because the 256Kbytes of request M is still in the pipe). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
On Mon, Mar 20, 2000 at 08:21:52PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > > >Keeping the currect cluster code is a bad idea, if the drivers were > >taught how to traverse the linked list in the buf struct rather > >than just notice "a big buffer" we could avoid a lot of page > >twiddling and also allow for massive IO clustering ( > 64k ) > > Before we redesign the clustering, I would like to know if we > actually have any recent benchmarks which prove that clustering > is overall beneficial ? > > I would think that track-caches and intelligent drives would gain > much if not more of what clustering was designed to do gain. Hm. But I'd think that even with modern drives a smaller number of bigger I/Os is preferable over lots of very small I/Os. Or have I missed the point? -- Wilko Bulte Arnhem, The Netherlands http://www.tcja.nl The FreeBSD Project: http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Duplicate inodes, filesystem weirdness
I have a followup fsck listing related to the above issue. Basically, it only seems to happen with my cvsup area(s). I don't know why this is, but cvsup craps out with 'can't create directory' and I find that a directory is now a file, with heaps of errors on the disk. I have attached a read-only fsck of my /usr (which is where all the problems are). Does anyone have any idea what this is ? Oh, and before you say it, no, it's _not_ hardware related. The disk in question runs fine under the old wd driver. Cheers Tim. 2819383 DUP I=6826572819384 DUP I=6826582819385 DUP I=6826592819386 DUP I=6826602819387 DUP I=6826612819388 DUP I=6826622819389 DUP I=6826632819390 DUP I=6826642819391 DUP I=6826652819392 DUP I=6826662819393 DUP I=6826672819394 DUP I=6826682819395 DUP I=6826692819396 DUP I=6826692819397 DUP I=6826702819398 DUP I=6826712819399 DUP I=6826722819400 DUP I=6826732819372 DUP I=6826742819402 DUP I=6826752819403 DUP I=6826762819404 DUP I=6826772819405 DUP I=6826772819406 DUP I=6826782819407 DUP I=6826792819408 DUP I=6826802819409 DUP I=6826812819410 DUP I=6826822819411 DUP I=6826832819412 DUP I=6826842819413 DUP I=6826842819414 DUP I=6826852819415 DUP I=6826862819416 DUP I=6826872819382 DUP I=6832572819382 DUP I=6826242819383 DUP I=6826252819384 DUP I=6826262819385 DUP I=6826272819386 DUP I=6826282819387 DUP I=6826292819388 DUP I=6826302819389 DUP I=6826312819390 DUP I=6826322819391 DUP I=6826332819392 DUP I=6826342819393 DUP I=6826352819394 DUP I=6826362819395 DUP I=6826372819396 DUP I=6826372819397 DUP I=6826382819398 DUP I=6826392819399 DUP I=6826402819400 DUP I=6826412819372 DUP I=6826422819402 DUP I=6826432819403 DUP I=6826442819404 DUP I=6826452819405 DUP I=6826452819406 DUP I=6826462819407 DUP I=6826472819408 DUP I=6826482819409 DUP I=6826492819410 DUP I=6826502819411 DUP I=6826512819412 DUP I=6826522819413 DUP I=6826522819414 DUP I=6826532819415 DUP I=6826542819416 DUP I=682655DUP/BAD FILE=/lost+found/#0682677 BAD TYPE VALUE FILE=/lost+found/#0682677 ZERO LENGTH DIRECTORY DIR=/ports/graphics/tgif-nls/patches ZERO LENGTH DIRECTORY DIR=/ports/graphics/pgplot/scripts ZERO LENGTH DIRECTORY DIR=/ports/irc/irssi/pkg ZERO LENGTH DIRECTORY DIR=/ports/java/jfc ZERO LENGTH DIRECTORY DIR=/ports/lang/intel2gas/pkg ZERO LENGTH DIRECTORY DIR=/ports/graphics/Cgraph/pkg DUP/BAD FILE=/ports/lang/squeak1/patches BAD TYPE VALUE FILE=/ports/lang/squeak1/patches ZERO LENGTH DIRECTORY DIR=/ports/japanese/ndtpd/pkg ZERO LENGTH DIRECTORY DIR=/ports/print/trueprint/pkg DUP/BAD FILE=/ports/mail/exim/files BAD TYPE VALUE FILE=/ports/mail/exim/files DUP/BAD FILE=/ports/print/trueprint/pkg/COMMENT ZERO LENGTH DIRECTORY DIR=/ports/print/trueprint/pkg/DESCR BAD TYPE VALUE DIR=/ports/print/trueprint/pkg/DESCR DUP/BAD FILE=/ports/print/trueprint/pkg/PLIST BAD INODE NUMBER FOR '.' DIR=? ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY ? BAD TYPE VALUE DIR=? DUP/BAD FILE=/ports/games/xoids/pkg/DESCR DUP/BAD FILE=/ports/games/xoids/pkg/PLIST DUP/BAD FILE=/ports/graphics/Cgraph/pkg/COMMENT DUP/BAD FILE=/ports/graphics/Cgraph/pkg/DESCR DUP/BAD FILE=/ports/graphics/Cgraph/pkg/PLIST BAD INODE NUMBER FOR '.' DIR=? ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY ?/files ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY ?/pkg DUP/BAD FILE=? DUP/BAD FILE=? BAD INODE NUMBER FOR '.' DIR=? ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/graphics/gview/files ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/graphics/gview/pkg DUP/BAD FILE=/ports/graphics/pgplot/scripts/configure DUP/BAD FILE=/ports/graphics/pgplot/scripts/COMMENT BAD INODE NUMBER FOR '.' DIR=? DUP/BAD FILE=/ports/graphics/tgif-nls/patches/patch-aa DUP/BAD FILE=/ports/graphics/tgif-nls/patches/patch-ab BAD INODE NUMBER FOR '.' DIR=? DUP/BAD FILE=/ports/irc/irssi/pkg/COMMENT DUP/BAD FILE=/ports/irc/irssi/pkg/DESCR DUP/BAD FILE=/ports/irc/irssi/pkg/PLIST BAD INODE NUMBER FOR '.' DIR=? DUP/BAD FILE=? DUP/BAD FILE=? DUP/BAD FILE=? DUP/BAD FILE=? DUP/BAD FILE=? BAD INODE NUMBER FOR '.' DIR=? DUP/BAD FILE=/ports/japanese/ndtpd/pkg/COMMENT DUP/BAD FILE=/ports/japanese/ndtpd/pkg/DESCR DUP/BAD FILE=/ports/japanese/ndtpd/pkg/INSTALL DUP/BAD FILE=/ports/japanese/ndtpd/pkg/MESSAGE DUP/BAD FILE=/ports/japanese/ndtpd/pkg/PLIST BAD INODE NUMBER FOR '.' DIR=? DUP/BAD FILE=? BAD INODE NUMBER FOR '.' DIR=? ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/files ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/patches ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/pkg ? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/scripts DUP/BAD FILE=/ports/misc/amanda/patches BAD TYPE VALUE FILE=/ports/misc/amanda/patches ZERO LENGTH DIRECTORY DIR=/ports/graphics/gview DUP/BAD FILE=/ports/security/zombiezapper/files BAD TYPE VALUE FILE=/ports/security/zombiezapper/files ZERO LENGTH DIRECTORY DIR=/ports/japanese/vfghostscript5 ZERO LENGTH DIRECTORY DIR=/ports/japanese/gn-gnspool/files BAD INODE NUMBER FO
Re: 4.0-RELEASE boot.flp fails to boot on K6/2
On Tue, Mar 21, 2000 at 07:52:18AM +0100, Thierry.herbelot wrote: > Joe Abley wrote: > > > > Problem report booting 4.0-RELEASE follows. > > > I had the exact same error message trying to boot from a floppy where I > had tried to dd the full boot.flp (2,8 Megs is just too much for a > normal floppy), instead of kern.flp (and dd does not give error messages > ..) Oh, how hideously embarassing. Thank you, Thierry, and please excuse me as I shoot myself in the head. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current sudden panics :(
After upgrading from 4.0-current (09.03) to 5.0-current(16.03,17.03) i've got subj. Machine panics and reboots. And i was not always near it. Finally i traced it: Fatal 12 trap: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01843fc stack pointer = 0x10:0xc026bd64 frame pointer = 0x10:0xc026bd64 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 = Idle interrupt mask = kernel: type 12 trap, code=0 Stopped at arpintr+0x9c: movl0x8(%ebx),%ecx trace gave this: arpint(c022537b,0,10,10,c0220010) at arpintr+0x9c swi_net_next() at awi_net_next I'm sending kernel config and dmesg in the attachment. I have INET6 there, but it is not configured by ifconfig. What's this and how can i avoid this panics? Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sat Mar 18 10:21:21 MSK 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/WS_ILMAR Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 134152192 (131008K bytes) avail memory = 127029248 (124052K bytes) Preloaded elf kernel "kernel" at 0xc02f4000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 11 chip1: port 0x5000-0x500f at device 7.3 on pci0 pci0: at 9.0 irq 9 rl0: port 0xe400-0xe47f mem 0xe700-0xe77f irq 11 at device 11.0 on pci0 rl0: Ethernet address: 00:c0:df:23:60:e2 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: supplying EUI64: 00:c0:df:ff:fe:23:60:e2 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port plip0: on ppbus0 unknown0: at port 0x800-0x807 on isa0 unknown1: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 unknown2: at port 0x201 on isa0 unknown3: at port 0x168-0x16f,0x36e-0x36f irq 12 on isa0 ad0: 3077MB [6253/16/63] at ata0-master using UDMA33 ad2: 19574MB [39770/16/63] at ata1-master using UDMA33 acd0: CDROM at ata1-slave using WDMA2 Mounting root from ufs:/dev/wd0s2a WARNING: / was not properly dismounted rl0: starting DAD for fe80:0001::02c0:dfff:fe23:60e2 rl0: DAD complete for fe80:0001::02c0:dfff:fe23:60e2 - no duplicates found # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.freebsd.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.247 2000/03/16 09:16:06 n_hibma Exp $ machine i386 cpu I686_CPU ident WS_ILMAR maxusers32 #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options MFS #Memory Filesystem #optionsMD_ROOT #MD is a potential root device options NFS
Re: 4.0-RELEASE boot.flp fails to boot on K6/2
Joe Abley wrote: > > Problem report booting 4.0-RELEASE follows. > > /boot.config: -P > Keyboard: yes > > BTX loader 1.00 BTX version is 1.01 > Console: internal video/keyboard > BIOS drive A: is disk0 > BIOS drive C: is disk1 > BIOS 639kB/56256kB available memory > > FreeBSD/i386 bootstrap loader, Revision 0.7 > ([EMAIL PROTECTED], Wed Mar 15 01:23:43 GMT 2000) > | > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [kernel]... > /kernel text=0x1d56fe data=0x2f4ca0+0x1a718 zf_read: fill error Hello, I had the exact same error message trying to boot from a floppy where I had tried to dd the full boot.flp (2,8 Megs is just too much for a normal floppy), instead of kern.flp (and dd does not give error messages ..) TfH > > elf_loadexec: archsw.readin failed > can't load 'kernel' > no bootable kernel > \ > > Type '?' for a list of commands, 'help' for more detailed help. > ok > > What does this mean? If this is a -questions question, then please feel > free to flame me privately (just thought it sounded -currentish). If > there are any useful diags I can type, let me know. > > Hardware is 350MHz K6/2, generic-looking Asus motherboard with > integrated video and audio, no-name PCI 10baseT ethernet adapter, > floppy, single 20G IDE disk, 64M RAM. No other peripherals. > > Have tried different floppies. Recent OpenBSD snapshot floppy works > just fine, by way of crude hardware sanity check. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Thierry HerbelotASCII RIBBON CAMPAIGN /"\ mailto:[EMAIL PROTECTED] AGAINST HTML MAIL & NEWS \ / http://perso.cybercable.fr/herbelot PAS DE HTML DANS X Hiroshima 45, Tchernobyl 86, Windows 95... LES COURRIELS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0-RELEASE boot.flp fails to boot on K6/2
Problem report booting 4.0-RELEASE follows. /boot.config: -P Keyboard: yes BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/56256kB available memory FreeBSD/i386 bootstrap loader, Revision 0.7 ([EMAIL PROTECTED], Wed Mar 15 01:23:43 GMT 2000) | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... /kernel text=0x1d56fe data=0x2f4ca0+0x1a718 zf_read: fill error elf_loadexec: archsw.readin failed can't load 'kernel' no bootable kernel \ Type '?' for a list of commands, 'help' for more detailed help. ok What does this mean? If this is a -questions question, then please feel free to flame me privately (just thought it sounded -currentish). If there are any useful diags I can type, let me know. Hardware is 350MHz K6/2, generic-looking Asus motherboard with integrated video and audio, no-name PCI 10baseT ethernet adapter, floppy, single 20G IDE disk, 64M RAM. No other peripherals. Have tried different floppies. Recent OpenBSD snapshot floppy works just fine, by way of crude hardware sanity check. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compat3x in 4.0-STABLE?
* From: "Thomas T. Veldhouse" <[EMAIL PROTECTED]> * Where did the compat3x install files go in the latest 4.0-STABLE * snapshot? They seem to be missing. That was actually a 3.4-STABLE snapshot that ended up in a directory with a wrong name. Jordan fixed it (and deleted the offending snapshot) so new ones, when they get built, should be fine. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I/O clustering, Re: patches for test / review
> I agree that it is obvious for NFS, but I don't see it as being > obvious at all for (modern) disks, so for that case I would like > to see numbers. > > If running without clustering is just as fast for modern disks, > I think the clustering needs rethought. I think it should be pretty obvious, actually. Command overhead is large (and not getting much smaller), and clustering primarily serves to reduce the number of commands and thus the ratio of command time vs. data time. So unless the clustering implementation is extremely poor, it's worthwhile. -- \\ 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
compat3x in 4.0-STABLE?
Where did the compat3x install files go in the latest 4.0-STABLE snapshot? They seem to be missing. Tom Veldhouse [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID lockup? not accepting commands.
A couple of clarifications on the last message: > Thus, when you see it printed as 0, somewhere between the test and the > printf the controller has updated the flag and indicated it's busy. That should of course be "not busy". > I'd be guessing that the current loop (100k iterations) is probably > completing far sooner than 1s. You could confirm this by grabbing a > timestamp at the beginning of amr_start and then checking again at the > point where it bails out. If that's the case, try cutting the initial > value of i down to 10,000 and insert a DELAY(100) in the "did not get > mailbox" case. I didn't use DELAY() initially because I wasn't sure it would work correctly if called before interrupts are enabled. That was probably a stupid mistake; I would try the above suggestion first as I suspect it'll get you going. Not that I consider this particuarly optimal; busy-waiting for the controller is a terrible waste of the host CPU. A better solution would probably defer the command and try again a short time later, but let's see if this works first. -- \\ 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
Davicam dc0 driver
I have a BookPC with a built in Davi Comm 10/100 ethernet card. I am always getting /kernel: dc0: watchdog timeout every few minutes.. Can thease errors be stopped? Thank you for any reply RP [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
Greg Lehey wrote: > > [Format recovered--see http://www.lemis.com/email/email-format.html] > > On Saturday, 18 March 2000 at 3:34:38 +0100, Palle Girgensohn wrote: > > Hi! > > Please don't send messages one line per paragraph. It's a pain to > reformat. Yeah, I had had fiddled with the setting for a specific purpose, but forgot to set them back. Sorry about that! > > Following the instructions in UPDATING, when rebooting to single > > user mode, vinum wouldn't work since the kernel module was out of > > date - no surprise. > > Hmm. After updating, you should have had new klds as well. But > that's probably not your fault. Could you enter a PR about it, > please? Yes. It's a documentation bug, as has been pointed out by Daniel C. Sobral. > > So, I copied a fresh vinum.ko in there and tried again. This time, > > vinum loaded fine, but complained that it couldn't get the list from > > disk (or similiar). > > How similar? That statement doesn't really help very much. Vinum > produces error messages to help pinpoint problems. Unfortunately, I didn't write it down. I regret it. Here's briefly what happened: since 'start' didn't work, I tried to read the configurations off the disks one by one, which wasn't a very good idea, apparently, for since they weren't all started at once(?), some plexes were marked a faulty. I rebooted the kernel-3.x and started vinum with the old kld. It started and read all disks, but some were still marked faulty or flaky. I stopped and restarted the plexes/disks/subdisks quite a bit before got them all up again. It seems to me that vinum sometimes isn't quite logical about its decisions as to whether a disk/plex/sd is up or flaky. Is there a trick with the restarting sequence if a disk is marked flaky? I got the error 16(?) (device busy) a lot, and had to reboot again to get rid of them. After installing all klds and remaking the devices, I got the kernel-4.0 to read all the disks with the start command. > > 3-stable kernel, make first installed the make binary itself, and OK. Here's another documentation bug, imho. I missed moving the /etc/rc.conf.local away. make all depends on target upgrade_checks and it installs make if the test target fails. I think there should be a note to run make test before installworld. My make binary was blown away with no warning, and I was lucky to have another 3.x system left to fetch it from... > It looks like you shot yourself in the foot. Yeah, that's one way to put it :) > I'd have to find out what went wrong first. It looks as if it should > have worked modulo the problems installing the klds. Yep. I'm preparing a pr for documentation bugs. Thanks for your time. /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID lockup? not accepting commands.
Hi,
The controller is new. Dell calls it a Perc2/dc and it has 128Meg
of memory installed in it. I'm not sitting infront of the
machine right now. More detailed information is available
when the machines is booted and you enter the bios setup
on the adapter card.
> >We have a system with a new AMI card in it controlling a pair
> > of shelves from Dell (fbsd dated: 4.0-2313-SNAP).
> >
> >The relevant dmesg output is below: (complete dmesg at end)
> >
> > amr0: mem 0xf6c0-0xf6ff irq 14 at device 10.1 on pci2
> > amr0: firmware 1.01 bios 1p00 128MB memory
> > amrd0: on amr0
> > amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
> >
> >The adapter does not lockup while testing with bonnie and such.
>
> Try running 20 or so bonnie processes in parallel; I can usually get it
> to lock up with this configuration. I'm wondering which controller
> you've got there though - I don't recognise the BIOS/firmware versions.
>
> > However, we have a 50Gig CVS repository sitting on the raid
> > volume. When we do a 'cvs co' of -HEAD, it causes it to lockup.
> > The following messages are repeating continuously:
> >
> > Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands)
>
> I'm not sure why this happens; the controller isn't coming ready even
> though we haven't hit any sort of limit that we're aware of. I've been
> considering some workarounds involving deferring the command until the
> controller gives us back an interrupt, but I'm still surprised that we
> get to this point at all.
Well, we've been playing around in amr.c/amr_start in the following
code sequence:
/* spin waiting for the mailbox */
debug("wait for mailbox");
for (i = 1, done = 0, worked = 0; (i > 0) && !done; i--) {
s = splbio();
/* is the mailbox free? */
if (sc->amr_mailbox->mb_busy == 0) {
debug("got mailbox");
sc->amr_mailbox64->mb64_segment = 0;
bcopy(&ac->ac_mailbox, sc->amr_mailbox, AMR_MBOX_CMDSIZE);
sc->amr_submit_command(sc);
done = 1;
sc->amr_workcount++;
TAILQ_INSERT_TAIL(&sc->amr_work, ac, ac_link);
/* not free, try to clean up while we wait */
} else {
-->> printf("%s: busy flag %x\n", __FUNCTION__, sc->amr_mailbox->mb_busy);
debug("busy flag %x\n", sc->amr_mailbox->mb_busy);
worked = amr_done(sc);
}
splx(s);
}
Note the addition of the printf statement in the else clause. Two
interesting things happen. One, we are unable to cause the controller
to lock up. Two, the following messages showup in syslog:
Mar 20 12:55:15 cvsstage /kernel: amr_start: busy flag 1
Mar 20 12:55:46 cvsstage last message repeated 1057 times
Mar 20 12:57:47 cvsstage last message repeated 5574 times
Mar 20 12:59:26 cvsstage last message repeated 5431 times
Mar 20 12:59:26 cvsstage /kernel: amr_start: busy flag 0
If I understand the sequence correctly, we enter splbio() and
then check the mailbox. Most of the time, we take the else clause
and the busy flag is 1 as it should be. However, once every 10 to 12
thousand loops, mb_busy is checked as being 1, but by the time we
get to the else clause, it's 0.
I wonder if there is some sort of timing issue since the
addition of the printf allows the card to operate correctly. I
haven't traced the kernel printf code, but it could change the
spl level thus allowing the mb_busy flag to be modified.
Comments?
>
> Unfortunately, I'm not able to spend any time on this at the moment; if
> someone wants to do a little experimenting I'd be very happy to talk them
> through what I think should be done (will require some programming
> ability).
We're more than willing to try. Just point us in the right
direction.
> --
> \\ 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]
-John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: emu10k1 (SB Live!) support under FreeBSD?
On 20-Mar-00 Dan Moschuk wrote: > | How current is this? Will it work against 4.0-STABLE? > I haven't tested it, but I believe so. I applied the patch to a machine which is *just* pre 4/5 split and it patched fine. I used it to get my ALS120 to work. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: >> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >> >> >Keeping the currect cluster code is a bad idea, if the drivers were >> >taught how to traverse the linked list in the buf struct rather >> >than just notice "a big buffer" we could avoid a lot of page >> >twiddling and also allow for massive IO clustering ( > 64k ) >> >> Before we redesign the clustering, I would like to know if we >> actually have any recent benchmarks which prove that clustering >> is overall beneficial ? > >Yes it is really benificial. > >I'm not talking about a redesign of the clustering code as much as >making the drivers that take a callback from it actually traverse >the 'union cluster_info' rather than relying on the system to fake >the pages being contiguous via remapping. > >There's nothing wrong with the clustering algorithms, it's just the >steps it has to take to work with the drivers. Hmm, try to keep vinum/RAID5 in the picture when you look at this code, it complicated matters a lot. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I/O clustering, Re: patches for test / review
>>Committing a 64k block would require 8 times the overhead of bundling >>up the RPC as well as transmission and reply, it may be possible >>to pipeline these commits because you don't really need to wait >>for one to complete before issueing another request, but it's still >>8x the amount of traffic. > >I agree that it is obvious for NFS, but I don't see it as being >obvious at all for (modern) disks, so for that case I would like >to see numbers. > >If running without clustering is just as fast for modern disks, >I think the clustering needs rethought. Depends on the type of disk drive and how it is configured. Some drives perform badly (skip a revolution) with back-to-back writes. In all cases, without aggregation of blocks, you pay the extra cost of additional interrupts and I/O rundowns, which can be a significant factor. Also, unless the blocks were originally written by the application in a chunk, they will likely be mixed with blocks to varying locations, in which case for drives without write caching enabled, you'll have additional seeks to write the blocks out. Things like this don't show up when doing simplistic sequential write tests. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID lockup? not accepting commands.
>The controller is new. Dell calls it a Perc2/dc and it has 128Meg
> of memory installed in it. I'm not sitting infront of the
> machine right now. More detailed information is available
> when the machines is booted and you enter the bios setup
> on the adapter card.
Ok. From some rumours coming out of Dell, I get the impression that this
is an Enterprise 1400 or 1500 with only two channels loaded. I guess I
need a better way of telling these controllers apart. 8(
> > >We have a system with a new AMI card in it controlling a pair
> > > of shelves from Dell (fbsd dated: 4.0-2313-SNAP).
> > >
> > >The relevant dmesg output is below: (complete dmesg at end)
> > >
> > > amr0: mem 0xf6c0-0xf6ff irq 14 at device 10.1 on pci2
> > > amr0: firmware 1.01 bios 1p00 128MB memory
> > > amrd0: on amr0
> > > amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
> > >
> > >The adapter does not lockup while testing with bonnie and such.
> >
> > Try running 20 or so bonnie processes in parallel; I can usually get it
> > to lock up with this configuration. I'm wondering which controller
> > you've got there though - I don't recognise the BIOS/firmware versions.
> >
> > > However, we have a 50Gig CVS repository sitting on the raid
> > > volume. When we do a 'cvs co' of -HEAD, it causes it to lockup.
> > > The following messages are repeating continuously:
> > >
> > > Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands)
> >
> > I'm not sure why this happens; the controller isn't coming ready even
> > though we haven't hit any sort of limit that we're aware of. I've been
> > considering some workarounds involving deferring the command until the
> > controller gives us back an interrupt, but I'm still surprised that we
> > get to this point at all.
>
>Well, we've been playing around in amr.c/amr_start in the following
> code sequence:
>
> /* spin waiting for the mailbox */
> debug("wait for mailbox");
> for (i = 1, done = 0, worked = 0; (i > 0) && !done; i--) {
> s = splbio();
>
> /* is the mailbox free? */
> if (sc->amr_mailbox->mb_busy == 0) {
> debug("got mailbox");
> sc->amr_mailbox64->mb64_segment = 0;
> bcopy(&ac->ac_mailbox, sc->amr_mailbox, AMR_MBOX_CMDSIZE);
> sc->amr_submit_command(sc);
> done = 1;
> sc->amr_workcount++;
> TAILQ_INSERT_TAIL(&sc->amr_work, ac, ac_link);
>
> /* not free, try to clean up while we wait */
> } else {
> -->> printf("%s: busy flag %x\n", __FUNCTION__, sc->amr_mailbox->mb_busy);
> debug("busy flag %x\n", sc->amr_mailbox->mb_busy);
> worked = amr_done(sc);
> }
> splx(s);
> }
>
>
>
>
>Note the addition of the printf statement in the else clause. Two
> interesting things happen. One, we are unable to cause the controller
> to lock up. Two, the following messages showup in syslog:
>
> Mar 20 12:55:15 cvsstage /kernel: amr_start: busy flag 1
> Mar 20 12:55:46 cvsstage last message repeated 1057 times
> Mar 20 12:57:47 cvsstage last message repeated 5574 times
> Mar 20 12:59:26 cvsstage last message repeated 5431 times
> Mar 20 12:59:26 cvsstage /kernel: amr_start: busy flag 0
>
>If I understand the sequence correctly, we enter splbio() and
> then check the mailbox. Most of the time, we take the else clause
> and the busy flag is 1 as it should be. However, once every 10 to 12
> thousand loops, mb_busy is checked as being 1, but by the time we
> get to the else clause, it's 0.
>
>I wonder if there is some sort of timing issue since the
> addition of the printf allows the card to operate correctly. I
> haven't traced the kernel printf code, but it could change the
> spl level thus allowing the mb_busy flag to be modified.
>
>Comments?
The mb_busy flag is in system memory, but it's maintained by the card
itself (it will bus-master and update it according to its internal state).
Thus, when you see it printed as 0, somewhere between the test and the
printf the controller has updated the flag and indicated it's busy.
You probably only see this quite rarely because the code path from the
if() to the printf() is very short (a jump) while the code path the rest of
the way 'round is much longer (through printf(), amr_done(), splx(),
splbio() etc.).
Adding the printfs massively slows the loop down; you might try
increasing the timeout (initial value of 'i') by an order of magnitude
instead. The real problem here is the spinloop - because the flag is in
system memory, the loop runs entirely in the cache and thus executes
insanely quickly. If it wasn't for the fact that this code is called
both with interrupts enabled and disabled, I'd use a much shorter loop
and simply defer the command if the controller didn't come ready almost
immediately. Some strategic use of DELAY() might also help. The Linu
Re: 3 -> 4 when /usr is a vinum volume?
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: : make buildworld : make buildkernel : make installkernel : MAKEDEV : reboot single user : make -DNOINFO installworld : make installworld : : As you see, the new klds don't get installed in the presently documented : procedure. I have read a report wrt to linux compatibility too, but with : vinum the problem is way bigger. They are installed as part of the installworld, which is too late. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/rc.firewall not reading /etc/rc.conf
On Monday, March 20, 2000, Jason wrote:
> Should /etc/rc.firewall be changed to read:
>
> # Suck in the configuration variables.
> if [ -r /etc/defaults/rc.conf ]; then
> . /etc/defaults/rc.conf
> fi
> if [ -r /etc/rc.conf ]; then
> . /etc/rc.conf
> fi
No. See /etc/defaults/rc.conf:
rc_conf_files="/etc/rc.conf /etc/rc.conf.local"
and at the very bottom,
for i in ${rc_conf_files}; do
if [ -f $i ]; then
. $i
fi
done
So /etc/rc.conf is read in by /etc/defaults/rc.conf.
--
|Chris Costello <[EMAIL PROTECTED]>
|I must have slipped a disk; my pack hurts.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
Alfred Perlstein wrote: > > Yowch, please wrap lines at 70 characters. :) Oops! Sorry about that. I had fiddled with the settings for a specific purpose, and forgot to set them back. :-/ > Read the loader page carefully and you should be able to boot 3.x > kernels with 3.x modules and 4.0 modules with a 4.0 kernel without > too much voodoo. Thanks for the tip. I'm not sure I read it close enough, for I set the module_path and it didn't help. Still, after installing all of the klds, I never really had to go back to the 3.x kernel, so it was ok anyway. The problem is of course that the UPDATING documentation lack info about installing the klds, and I didn't think about it. /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I/O clustering, Re: patches for test / review
:> :>I agree that it is obvious for NFS, but I don't see it as being :>obvious at all for (modern) disks, so for that case I would like :>to see numbers. :> :>If running without clustering is just as fast for modern disks, :>I think the clustering needs rethought. : : Depends on the type of disk drive and how it is configured. Some drives :perform badly (skip a revolution) with back-to-back writes. In all cases, :without aggregation of blocks, you pay the extra cost of additional interrupts :and I/O rundowns, which can be a significant factor. Also, unless the blocks :were originally written by the application in a chunk, they will likely be :mixed with blocks to varying locations, in which case for drives without :write caching enabled, you'll have additional seeks to write the blocks out. :Things like this don't show up when doing simplistic sequential write tests. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org I have an excellent example of this related to NFS. It's still applicable even though the NFS point has already been conceeded. As part of the performance enhancements package I extended the sequential detection heuristic to the NFS server side code and turned on clustering. On the server, mind you, not the client. Read performance went up drastically. My 100BaseTX network instantly maxed out and, more importantly, the server side cpu use went down drastically. Here is the relevant email from my archives describing the performance gains: :From: dillon :To: Alfred Perlstein <[EMAIL PROTECTED]> :Cc: Alan Cox <[EMAIL PROTECTED]>, Julian Elischer <[EMAIL PROTECTED]> :Date: Sun Dec 12 10:11:06 1999 : :... :This proposed patch allows us to maintain a sequential read heuristic :on the server side. I noticed that the NFS server side reads only 8K :blocks from the physical media even when the NFS client is reading a :file sequentially. : :With this heuristic in place I can now get 9.5 to 10 MBytes/sec reading :over NFS on a 100BaseTX network, and the server winds up being 80% :idle. Under -stable the same test runs 72% idle and 8.4 MBytes/sec. This is in spite of the fact that in this sequential test the hard drives were caching the read data ahead anyway. The reduction in command/response/interrupt overhead on the server by going from 8K read I/O's to 64K read I/O's in the sequential case made an obvious beneficial impact on the cpu. I almost halved the cpu overhead on the server! So while on-disk caching makes a lot of sense, it is in no way able to replace software clustering. Having both working together is a killer combination. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 75 second delay using telnet/ssh (ipv6 related)
> Hi. Hi, > This is kind of weird, so I want to see if anyone else has noticed > this or has a solution to it. > > If I use telnet or ssh (there might be more programs, > but I have only noticed these two so far), and supply a hostname to it, > my machine is constantly requesting records, and finally after > 75 seconds it requests and receives an A record from the nameserver. Currently, using -4 option is a workaround for the problem, but I think this should be fixed by a resolver change as discussed on this list before. The change is from, all trial, then all A trial, to try and A for each trial. Sorry for the inconvenience and I'll try the fix. Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID lockup? not accepting commands.
>We have a system with a new AMI card in it controlling a pair > of shelves from Dell (fbsd dated: 4.0-2313-SNAP). > >The relevant dmesg output is below: (complete dmesg at end) > > amr0: mem 0xf6c0-0xf6ff irq 14 at device 10.1 on pci2 > amr0: firmware 1.01 bios 1p00 128MB memory > amrd0: on amr0 > amrd0: 172780MB (353853440 sectors) RAID 5 (optimal) > >The adapter does not lockup while testing with bonnie and such. Try running 20 or so bonnie processes in parallel; I can usually get it to lock up with this configuration. I'm wondering which controller you've got there though - I don't recognise the BIOS/firmware versions. > However, we have a 50Gig CVS repository sitting on the raid > volume. When we do a 'cvs co' of -HEAD, it causes it to lockup. > The following messages are repeating continuously: > > Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands) I'm not sure why this happens; the controller isn't coming ready even though we haven't hit any sort of limit that we're aware of. I've been considering some workarounds involving deferring the command until the controller gives us back an interrupt, but I'm still surprised that we get to this point at all. Unfortunately, I'm not able to spend any time on this at the moment; if someone wants to do a little experimenting I'd be very happy to talk them through what I think should be done (will require some programming ability). -- \\ 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
Re: B_WRITE cleanup patch, please test!
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >I think the biggest win in regards to being able to arbitrarily stack >devices is to NOT attempt to forward struct buf's between devices when >non-trivial manipulation is required, and instead to make struct buf's >cheap enough that a device can simply allocate a new one and copy the >appropriate fields. > >In particular I really hate all the various b_*blkno fields. b_lblkno, >b_blkno, and b_pblkno. It is precisely due to the existance of these >hacks that arbitrary device stacking is difficult. This is basically what the stuff I'm doing addresses. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
In the last episode (Mar 20), Poul-Henning Kamp said: > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > >* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: > >> > >> Before we redesign the clustering, I would like to know if we > >> actually have any recent benchmarks which prove that clustering is > >> overall beneficial ? > > > >Yes it is really benificial. > > I would like to see some numbers if you have them. For hardware RAID arrays that support it, if you can get the system to issue writes that are larger than the entire RAID-5 stripe size, your immensely slow "read parity/recalc parity/write parity/write data" operations turn into "recalc parity for entire stripe/write entire stripe". RAID-5 magically achieves RAID-0 write speeds! Given 32k granularity, and 8 disks per RAID group, you'll need a write size of 32*7 = 224k. Given 64K granularity and 27 disks, that's 1.6MB. I have seen the jump in write throughput as I tuned an Oracle database's parameters on both Solaris and DEC Unix boxes. Get Oracle to write blocks larger than a RAID-5 stripe, and it flies. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I/O clustering, Re: patches for test / review
: :* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 12:03] wrote: :> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: :> >* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: :> >> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: :> >> :> >> >Keeping the currect cluster code is a bad idea, if the drivers were :> >> >taught how to traverse the linked list in the buf struct rather :> >> >than just notice "a big buffer" we could avoid a lot of page :> >> >twiddling and also allow for massive IO clustering ( > 64k ) :> >> :> >> Before we redesign the clustering, I would like to know if we :> >> actually have any recent benchmarks which prove that clustering :> >> is overall beneficial ? :> > :> >Yes it is really benificial. :> :> I would like to see some numbers if you have them. : :No I don't have numbers. : :Committing a 64k block would require 8 times the overhead of bundling :up the RPC as well as transmission and reply, it may be possible :to pipeline these commits because you don't really need to wait Clustering is extremely beneficial. DG and I and I think even BDE and Tor have done a lot of random tests in that area. I did a huge amount of clustering related work while optimizing NFSv3 and fixing up the random/sequential I/O heuristics for 4.0 (for both NFS and UFS). The current clustering code does a pretty good job and I would hesitate to change it at this time. The only real overhead comes from the KVA pte mappings for b_data in the pbuf that the clustering (and other) code uses. I do not think that redoing the clustering will have a beneficial result until *after* we optimize the I/O path as per my previous posting. Once we optimize the I/O path to make it more VM Object centric, it will make it a whole lot easier to remove *ALL* the artificial I/O size limitations. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCMCIA Maker Modem
In message <[EMAIL PROTECTED]> Julian Elischer writes: : you can also look at the pccard.conf file in /etc : and rename it to make sio2 if you want. That isn't guaranteed to work. Like you note later in your note, if sio2 is already in the kernel, you won't be able to attach it on pccard. The device numbers in /etc/pccard.conf are at best a weak hint. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/rc.firewall not reading /etc/rc.conf
> In my 4.0 cvsupped from 3/20 /etc/rc.firewall says this:
>
> # Suck in the configuration variables.
> if [ -r /etc/defaults/rc.conf ]; then
> . /etc/defaults/rc.conf
> elif [ -r /etc/rc.conf ]; then
> . /etc/rc.conf
> fi
>
> which would be fine, but /etc/defaults/rc.conf says this at the top:
It is fine, since /etc/defaults/rc.conf also says this at the bottom:
##
### Allow local configuration override at the very end here ##
##
#
#
for i in ${rc_conf_files}; do
if [ -f $i ]; then
. $i
fi
done
and rc_conf_files is set to "/etc/rc.conf /etc/rc.conf.local"
by default.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
/etc/rc.firewall not reading /etc/rc.conf
In my 4.0 cvsupped from 3/20 /etc/rc.firewall says this:
# Suck in the configuration variables.
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
which would be fine, but /etc/defaults/rc.conf says this at the top:
# This is rc.conf - a file full of useful variables that you can set
# to change the default startup behavior of your system. You should
# not edit this file! Put any overrides into one of the ${rc_conf_files}
# instead and you will be able to update these defaults later without
# spamming your local configuration information.
#
So, following directions, I put my changes in /etc/rc.conf, but rc.firewall
only looks at /etc/defaults/rc.conf.
Should /etc/rc.firewall be changed to read:
# Suck in the configuration variables.
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
fi
if [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
-jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: I/O clustering, Re: patches for test / review
Just as a perhaps interesting aside on this topic; it'd be quite neat for controllers that understand scatter/gather to be able to simply suck N regions of buffer cache which were due for committing directly into an S/G list... (wishlist item, I guess 8) -- \\ 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
Re: gcc -Os optimisation broken (RELENG_4)
David O'Brien wrote/schrieb (Saturday, March 18, 2000): | On Sat, Mar 18, 2000 at 03:18:45AM +0100, Thomas Köllmann wrote: | > | Perhaps this is a bit off topic, but can the pentium optimisations be | > | used for AMD K6 processors? | > | > I did a `make world' yesterday with | > CFLAGS= -O2 -pipe -march=pentium | > COPTFLAGS= -O2 -pipe -march=pentium | ..snip.. | > If it doesn't I'll probably try `-03 -pipe -march=pentium' come next | | What are people hoping to get by doing this? Are you actually doing a | scientific performance evaluation between the various optimization | options??? This is just playing, the machine I was talking about has it's backups in order and can afford downtime; I mentioned that already, and I was only answering somebody's question. | Are are people just being macho, and thinking they are | getting all this non-existent performance increase? You _are_ feeling strong about this, aren't you? :-) | "-O" is the only globally safe optimization on FreeBSD. -O2, etc.. | causes various problems for various people in various ports, and parts of | /usr/src/. If people are using these options just for fun, that is fine, Yes, just for fun, David, just for fun. | BUT if you experience *any* problems with compiling using -O2, etc.. | don't bug this list -- go bug the GCC people. Are they a bunch of machos themselves? :-) Thanks for your point of view. Gruß - Thomas -- Walking to the car, she takes his hand and puts it, for a moment, lightly between her moving legs. Roger's heart grows erect, and comes. That's really how it feels. -- Thomas Pynchon, Gravity's Rainbow # PGP key sent on request / PGP key auf Wunsch per e-mail To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PRoblems with more than 4 gif devices
Help! I am trying to use more than 4 gif devices for ipv6. i have set the appropiate values in config.h but still only can configure gif0 - gif3. Any help appreciated. Please respond OFF-List ! Jan -- Jan Ahrent Czmok Head of International Peering Department Gigabell AG http://www.gigabell.net phone: +49 69 17084-716 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
In message <[EMAIL PROTECTED]> Palle Girgensohn writes: : It in docs/17518 now. Thanks! Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
Alfred Perlstein wrote: > > * Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: > > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > > > > >Keeping the currect cluster code is a bad idea, if the drivers were > > >taught how to traverse the linked list in the buf struct rather > > >than just notice "a big buffer" we could avoid a lot of page > > >twiddling and also allow for massive IO clustering ( > 64k ) > > > > Before we redesign the clustering, I would like to know if we > > actually have any recent benchmarks which prove that clustering > > is overall beneficial ? > > Yes it is really benificial. Yes, I've seen stats that show the degradation when clustering is switched off. Richard Wendlake (who wrote the OS detection code for the Netcraft web server survey) did a lot of testing in this area because of some pathological behavior he was seeing using Gnu's dbm package. Richard, do you want to post a summary of your tests? > > I'm not talking about a redesign of the clustering code as much as > making the drivers that take a callback from it actually traverse > the 'union cluster_info' rather than relying on the system to fake > the pages being contiguous via remapping. > > There's nothing wrong with the clustering algorithms, it's just the > steps it has to take to work with the drivers. Well, there is something wrong with our clustering algorithm. It always starts a new cluster when the first block of a file is written to. I found this when trying to explain some of the pathological behavior that Richard was seeing. Imagine an algorithm that will write blocks 0,5,2,7,4,1,6,3,0,... The clustering algorithm starts a new cluster if the block is at the beginning of the file, so writing block 0 will always start a new cluster. When block 5 is written out, the clustering code will try and add it to the existing cluster, will fail and so will flush the existing cluster which only has block 0 in it and then start another cluster, with block 5 in it. This continues, with the previous cluster being flushed and a new cluster being created with the current block in it. Eventually, we get to the point where 7 blocks have been flushed and the current cluster contains block 3. When it comes to write out the next block 0 the clustering algorithm doesn't bother trying to add the block to the existing cluster but immediately starts a new one so the cluster with block 3 in it *never gets flushed*. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: > : make buildworld > : make buildkernel > : make installkernel > : MAKEDEV > : reboot single user > : make -DNOINFO installworld > : make installworld > : > : As you see, the new klds don't get installed in the presently documented > : procedure. I have read a report wrt to linux compatibility too, but with > : vinum the problem is way bigger. > > They are installed as part of the installworld, which is too late. > It in docs/17518 now. /Palle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
:> lock on the bp. With a shared lock you are allowed to issue READ :> I/O but you are not allowed to modify the contents of the buffer. :> With an exclusive lock you are allowed to issue both READ and WRITE :> I/O and you can modify the contents of the buffer. :> :> bread() -> bread_sh() and bread_ex() :> :> Obtain and validate (issue read I/O as appropriate) a bp. bread_sh() :> allows a buffer to be accessed but not modified or rewritten. :> bread_ex() allows a buffer to be modified and written. : :This seems to allow for expressing intent to write to buffers, :which would be an excellent place to cow the pages 'in software' :rather than obsd's way of using cow'd pages to accomplish the same :thing. Yes, absolutely. DG (if I remember right) is rabid about not taking VM faults while sitting in the kernel and I tend to agree with him that it's a cop-out to use VM faults in the kernel to get around those sorts of problems. :I'm not sure if you remeber what I brought up at BAFUG, but I'd :like to see something along the lines of BX_BKGRDWRITE that Kirk :is using for the bitmaps blocks in softupdates to be enabled on a :system wide basis. That way rewriting data that has been sent to :the driver isn't blocked and at the same time we don't need to page :protect during every strategy call. : :I may have misunderstood your intent, but using page protections :on each IO would seem to introduce a lot of performance issues that :the rest of these points are all trying to get rid of. At the low-level device there is no concept of page protections. If you pass an array of vm_page_t's then that is where the data will be taken from or written to. A background-write capability is actually much more easily implemented at the VM Object level then the buffer cache level. If you think about it, all you need to do is add another VM Object layer *below* the one representing the device. Whenever a device write is initiated the pages are moved to the underlying layer. If a process (or the kernel) needs to modify the pages while the write is in progress, a copy-on-write occurs through normal mechanisms. On completion of the I/O the pages are moved back to the main VM Object device layer except for those that would conflict with any copy-on-write that occured (the original device pages in the conflict case simply get thrown away). Problem solved. Plus this deals with low-memory situations properly... we do not introduce any new deadlocks. :> The idea for the buffer cache is to shift its functionality to one that :> is solely used to issue device I/O and to keep track of dirty areas for :> proper sequencing of I/O (e.g. softupdate's use of the buffer cache :> to placemark I/O will not change). The core buffer cache code would :... : :Keeping the currect cluster code is a bad idea, if the drivers were :taught how to traverse the linked list in the buf struct rather :than just notice "a big buffer" we could avoid a lot of page :twiddling and also allow for massive IO clustering ( > 64k ) because :we won't be limited by the size of the b_pages[] array for our :upper bound on the amount of buffers we can issue effectively a :scatter/gather on (since the drivers must VTOPHYS them anyway). This devolves down into how simple (or complex) an interface we are willing to use to talk to the low-level device. The reason I would hesitate to move to a 'linked list of buffers' methodology is that *ALL* of the current VM API's pass a single array of vm_page_t's... not just the current struct buf code, but also the VOP_PUTPAGES and VOP_GETPAGES API. I would much prefer to keep this simplicity intact in order to avoid introducing even more bugs into the source then we will when we try to do this stuff, which means changing the clustering code from: * copies vm_page_t's into the cluster pbuf's b_pages[] array * maps the pages into b_data to: * copies vm_page_t's into the cluster pbuf's b_pages[] array In otherwords, keeping the clustering changes as simple as possible. I think once the new I/O path is operational we can then start thinking about how to optimize it -- for example, by having a default (embedded) static array but also allowing the b_pages array to be dynamically allocated. :To realize my "nfs super commit" stuff all we'd need to do is make :the max cluster size something like 0-1 and instantly get an almost :unbounded IO burst. : :-- :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] : -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCMCIA Maker Modem
In message <007001bf9287$13b78de0$[EMAIL PROTECTED]> "Tim Ryder" writes: : My pcmcia modem seems to show up as sio4 which does not exist on my system. You have two choices. First, is to cd /dev and do a MAKEDEV ttyd4 cua4 which will make it possible to use the modem as /dev/ttyd4 and /dev/cuaa4. Second, you can remove the sio2 and sio3 entries in your config file. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
* Matthew Dillon <[EMAIL PROTECTED]> [000320 14:18] wrote: > > :>lock on the bp. With a shared lock you are allowed to issue READ > :>I/O but you are not allowed to modify the contents of the buffer. > :>With an exclusive lock you are allowed to issue both READ and WRITE > :>I/O and you can modify the contents of the buffer. > :> > :> bread() -> bread_sh() and bread_ex() > :> > :>Obtain and validate (issue read I/O as appropriate) a bp. bread_sh() > :>allows a buffer to be accessed but not modified or rewritten. > :>bread_ex() allows a buffer to be modified and written. > : > :This seems to allow for expressing intent to write to buffers, > :which would be an excellent place to cow the pages 'in software' > :rather than obsd's way of using cow'd pages to accomplish the same > :thing. > > Yes, absolutely. DG (if I remember right) is rabid about not taking > VM faults while sitting in the kernel and I tend to agree with him that > it's a cop-out to use VM faults in the kernel to get around those > sorts of problems. ok, so we're on the same page then. :) > > :I'm not sure if you remeber what I brought up at BAFUG, but I'd > :like to see something along the lines of BX_BKGRDWRITE that Kirk > :is using for the bitmaps blocks in softupdates to be enabled on a > :system wide basis. That way rewriting data that has been sent to > :the driver isn't blocked and at the same time we don't need to page > :protect during every strategy call. > : > :I may have misunderstood your intent, but using page protections > :on each IO would seem to introduce a lot of performance issues that > :the rest of these points are all trying to get rid of. > > At the low-level device there is no concept of page protections. > If you pass an array of vm_page_t's then that is where the data > will be taken from or written to. > > A background-write capability is actually much more easily implemented > at the VM Object level then the buffer cache level. If you think about > it, all you need to do is add another VM Object layer *below* the > one representing the device. Whenever a device write is initiated the > pages are moved to the underlying layer. If a process (or the kernel) > needs to modify the pages while the write is in progress, a copy-on-write > occurs through normal mechanisms. On completion of the I/O the pages > are moved back to the main VM Object device layer except for those that > would conflict with any copy-on-write that occured (the original device > pages in the conflict case simply get thrown away). > > Problem solved. Plus this deals with low-memory situations properly... > we do not introduce any new deadlocks. That does sound a lot better, using the buffer system for anything more than describing an IO is a hack and I'd like to see an implementation such as this be possible. > > :> The idea for the buffer cache is to shift its functionality to one that > :> is solely used to issue device I/O and to keep track of dirty areas for > :> proper sequencing of I/O (e.g. softupdate's use of the buffer cache > :> to placemark I/O will not change). The core buffer cache code would > :... > : > :Keeping the currect cluster code is a bad idea, if the drivers were > :taught how to traverse the linked list in the buf struct rather > :than just notice "a big buffer" we could avoid a lot of page > :twiddling and also allow for massive IO clustering ( > 64k ) because > :we won't be limited by the size of the b_pages[] array for our > :upper bound on the amount of buffers we can issue effectively a > :scatter/gather on (since the drivers must VTOPHYS them anyway). > > This devolves down into how simple (or complex) an interface we > are willing to use to talk to the low-level device. > > The reason I would hesitate to move to a 'linked list of buffers' > methodology is that *ALL* of the current VM API's pass a single > array of vm_page_t's... not just the current struct buf code, but also > the VOP_PUTPAGES and VOP_GETPAGES API. > > I would much prefer to keep this simplicity intact in order to avoid > introducing even more bugs into the source then we will when we try > to do this stuff, which means changing the clustering code from: > > * copies vm_page_t's into the cluster pbuf's b_pages[] array > * maps the pages into b_data > > to: > > > * copies vm_page_t's into the cluster pbuf's b_pages[] array > > In otherwords, keeping the clustering changes as simple as possible. > I think once the new I/O path is operational we can then start thinking > about how to optimize it -- for example, by having a default (embedded) > static array but also allowing the b_pages array to be dynamically > allocated. Why? Why allocate a special buffer pbuf just for all of this, problems can develop wher
Re: emu10k1 (SB Live!) support under FreeBSD?
| > http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1 | > driver (minus recording) which is need of debugging. Give it a try! | | How current is this? Will it work against 4.0-STABLE? I haven't tested it, but I believe so. -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
: :In message <[EMAIL PROTECTED]>, Matthew Dillon writes: : :>Well, let me tell you what the fuzzy goal is first and then maybe we :>can work backwards. :> :>Eventually all physical I/O needs a physical address. The quickest :>way to get to a physical address is to be given an array of vm_page_t's :>(which can be trivially translated to physical addresses). : :Not all: :PIO access to ATA needs virtual access. :RAID5 needs virtual access to calculate parity. ... which means that the initial implementation for PIO and RAID5 utilizes the mapped-buffer bioops interface rather then the b_pages[] bioops interface. But here's the point: We need to require that all entries *INTO* the bio system start with at least b_pages[] and then generate b_data only when necessary. If a particular device needs a b_data mapping, it can get one, but I think it would be a huge mistake to allow entry into the device subsystem to utilize *either* a b_data mapping *or* a b_pages[] mapping. Big mistake. There has to be a lowest common denominator that the entire system can count on and it pretty much has to be an array of vm_page_t's. If a particular subsystem needs b_data, then that subsystem is obviously willing to take the virtual mapping / unmapping hit. If you look at Greg's current code this is, in fact, what is occuring the critical path through the buffer cache in a heavily loaded system tends to require a KVA mapping *AND* a KVA unmapping on every buffer access (just that the unmappings tend to be for unrelated buffers). The reason this occurs is because even with the larger amount of KVA we made available to the buffer cache in 4.x, there still isn't enough to leave mappings intact for long periods of time. A 'systat -vm 1' will show you precisely what I mean (also sysctl -a | fgrep bufspace). So we will at least not be any worse off then we are now, and probably better off since many of the buffers in the new system will not have to be mapped. For example, when vinum's RAID5 breaks up a request and issues a driveio() it passes a buffer which is assigned to b_data which must be translated (through page table lookups) to physical addresses anyway, so the fact that that vinum does not populate b_pages[] does *NOT* help it in the least. It actually makes the job harder. -Matt Matthew Dillon <[EMAIL PROTECTED]> :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." :FreeBSD -- It will take a long time before progress goes too far! : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 under -current - a bug report
I can varify this on 4.0-STABLE as of March 19, ports cvsup the same time. I had a look at it, and though I'm not much of a programmer, I cant see where the parse error is.. maybe I'm blind. Matt -- Matt Heckaman [[EMAIL PROTECTED]|[EMAIL PROTECTED]] [Please do not send me] !Powered by FreeBSD/x86! [http://www.freebsd.org] [any SPAM (UCE) e-mail] On Mon, 20 Mar 2000, Ilya Naumov wrote: : Date: Mon, 20 Mar 2000 15:48:16 -0500 : From: Ilya Naumov <[EMAIL PROTECTED]> : To: [EMAIL PROTECTED] : Cc: [EMAIL PROTECTED] : Subject: XFree86 under -current - a bug report : : Hello, : : i've tried to build XFree86 4.0 on my 5.0-CURRENT and 4.0-RELEASE box, and :encountered : a problem. : : "make all" finishes successfully, but "make install" fails with the : following error message: : : making all in programs/Xserver/hw/xfree86/os-support/bsd... : rm -f bsd_mouse.o : cc -c -O -pipe -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../../../. : ./../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/ : hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include : -I../../../../../../exports/include/X11 -I../../../../../../include/extensions : -I../../../../../../programs/Xserver/mi -I -I../../../../../.. -I../. : ./../../../../exports/include -DCSRG_BASED -DSHAPE -DXKB -DLBX -DXAPPGROUP -DX : CSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DGCCU : SESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFre : e86LOADER -DXFree86Server -DXF86VIDMODE -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART : _SCHEDULE -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DPCCONS_SUPPORT -DSYSCONS_S : UPPORT -DPCVT_SUPPORT -DUSE_DEV_IO -DUSESTDRES -DHAS_MTRR_SUPPORT b : sd_mouse.c : In file included from bsd_mouse.c:11: : ../../../../../../programs/Xserver/hw/xfree86/common/xf86Xinput.h:99: syntax err : or before `xDeviceCtl' : *** Error code 1 : : Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support/ : bsd. : *** Error code 1 : : Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support. : *** Error code 1 : : ports were cvsupped today, and kernel/world were built on Mar 15. : : what should i try to do to cope with this? : : : -- : Best regards, : Ilya mailto:[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: B_WRITE cleanup patch, please test!
I think the biggest win in regards to being able to arbitrarily stack devices is to NOT attempt to forward struct buf's between devices when non-trivial manipulation is required, and instead to make struct buf's cheap enough that a device can simply allocate a new one and copy the appropriate fields. Here I am talking about situations where devices need callbacks (making forwarding impossible), need to split or combine requests, or do other non-trivial things. In particular I really hate all the various b_*blkno fields. b_lblkno, b_blkno, and b_pblkno. It is precisely due to the existance of these hacks that arbitrary device stacking is difficult. The key to making a struct buf cheap is to provide an I/O path that does not require the b_data KVA mapping. Once we provide this path, I think everything else will fall into place quite neatly. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree86 under -current - a bug report
Hello, i've tried to build XFree86 4.0 on my 5.0-CURRENT and 4.0-RELEASE box, and encountered a problem. "make all" finishes successfully, but "make install" fails with the following error message: making all in programs/Xserver/hw/xfree86/os-support/bsd... rm -f bsd_mouse.o cc -c -O -pipe -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../../../. ./../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/ hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../programs/Xserver/mi -I -I../../../../../.. -I../. ./../../../../exports/include -DCSRG_BASED -DSHAPE -DXKB -DLBX -DXAPPGROUP -DX CSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DGCCU SESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFre e86LOADER -DXFree86Server -DXF86VIDMODE -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART _SCHEDULE -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DPCCONS_SUPPORT -DSYSCONS_S UPPORT -DPCVT_SUPPORT -DUSE_DEV_IO -DUSESTDRES -DHAS_MTRR_SUPPORT b sd_mouse.c In file included from bsd_mouse.c:11: ../../../../../../programs/Xserver/hw/xfree86/common/xf86Xinput.h:99: syntax err or before `xDeviceCtl' *** Error code 1 Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support/ bsd. *** Error code 1 Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support. *** Error code 1 ports were cvsupped today, and kernel/world were built on Mar 15. what should i try to do to cope with this? -- Best regards, Ilya mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I/O clustering, Re: patches for test / review
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >> >> Before we redesign the clustering, I would like to know if we >> >> actually have any recent benchmarks which prove that clustering >> >> is overall beneficial ? >> > >> >Yes it is really benificial. >> >> I would like to see some numbers if you have them. > >No I don't have numbers. > >Committing a 64k block would require 8 times the overhead of bundling >up the RPC as well as transmission and reply, it may be possible >to pipeline these commits because you don't really need to wait >for one to complete before issueing another request, but it's still >8x the amount of traffic. I agree that it is obvious for NFS, but I don't see it as being obvious at all for (modern) disks, so for that case I would like to see numbers. If running without clustering is just as fast for modern disks, I think the clustering needs rethought. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 75 second delay using telnet/ssh (ipv6 related)
> On Mon, 20 Mar 2000 12:02:21 -0800 > Chris Piazza <[EMAIL PROTECTED]> said: > According to Mr. Stevens (Unix Network Programing Vol 1 > chapt 9.4) this option, or having the env. variable RES_OPTIONS=inet6 set > will cause the behavior you are describing... It's a behavior of gethostbyname(). Ssh uses getaddrinfo() instead of gethostbyname(). See RFC2553. cpiazza> No, neither of those. FreeBSD searches inet6 first at the moment. cpiazza> I don't know if I made this clear in my email, but this just started cpiazza> happening... Hmm... it's fixed again: Don't you see packet loss or name server problem? Your previous log seems 128.189.4.1 didn't answer to RR query. cpiazza> 12:01:15.622122 24.113.19.137.1253 > 24.2.10.36.53: 61892+ ? beast.freebsd.org. (35) cpiazza> 12:01:15.706319 24.2.10.36.53 > 24.113.19.137.1253: 61892 1/1/0 (132) cpiazza> 12:01:15.707070 24.113.19.137.1254 > 24.2.10.36.53: 61893+ A? beast.freebsd.org. (35) cpiazza> 12:01:15.750017 24.2.10.36.53 > 24.113.19.137.1254: 61893 2/4/4 (238) Is it a log with `ssh -4'? Why does ssh qurey RR with -4? > > Using ssh -4 or telnet -4 makes it work right away (of course), but > > I don't want to have to type that all the time. [program] ipv4address > > also works. How about `alias ssh "ssh -4"'? -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I/O clustering, Re: patches for test / review
* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 12:03] wrote: > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > >* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: > >> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > >> > >> >Keeping the currect cluster code is a bad idea, if the drivers were > >> >taught how to traverse the linked list in the buf struct rather > >> >than just notice "a big buffer" we could avoid a lot of page > >> >twiddling and also allow for massive IO clustering ( > 64k ) > >> > >> Before we redesign the clustering, I would like to know if we > >> actually have any recent benchmarks which prove that clustering > >> is overall beneficial ? > > > >Yes it is really benificial. > > I would like to see some numbers if you have them. No I don't have numbers. Committing a 64k block would require 8 times the overhead of bundling up the RPC as well as transmission and reply, it may be possible to pipeline these commits because you don't really need to wait for one to complete before issueing another request, but it's still 8x the amount of traffic. You also complicate and penalize drivers because not all drivers can add an IO request to an already started transaction, those devices will need to start new transactions for each buffer instead of bundling up the list and passing it all along. Maybe I'm missing something. Is there something to provide a clean way to cluster IO, can you suggest something that won't have this sort of impact on NFS (and elsewhere) if the clustering code was removed? Bruce, what part of the clustering code makes you think of it as hurting us, I thought it was mapping code? > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syslogd_flags in /etc/defaults/rc.conf
Nick Johnson wrote: > > I'm curious to see if anyone is like-minded with me that syslogd_flags in > /etc/defaults/rc.conf should be "-ss" instead of "". I reasoned that it > should be, considering: > > 1. Most people don't direct syslogs at other machines in my experience. While I am one of those people that does redirect syslogs to other machines, I agree with your change. > 2. Someone could conceivably DOS a machine by directing tons of crap at > port 121, which is also noted in the BUGS section of the syslogd > manpage. > 3. Syslogd runs as root, and while it is a mature piece of code, I think > it preferable to minimize the number of root applications listening > on sockets. > >Nick -- Joseph Scott [EMAIL PROTECTED] Office Of Water Programs - CSU Sacramento To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
Greg Lehey wrote: > > > Following the instructions in UPDATING, when rebooting to single > > user mode, vinum wouldn't work since the kernel module was out of > > date - no surprise. > > Hmm. After updating, you should have had new klds as well. But > that's probably not your fault. Could you enter a PR about it, > please? make buildworld make buildkernel make installkernel MAKEDEV reboot single user make -DNOINFO installworld make installworld As you see, the new klds don't get installed in the presently documented procedure. I have read a report wrt to linux compatibility too, but with vinum the problem is way bigger. IIRC, the build/installkernel targets were first steps in getting modules and loader dependencies handled correctly. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ICMP socket weirdness
< said: [Quoting my original description of icmp_input()'s behavior:] >> The ICMP never passes certain packets up to raw listeners. These >> include ECHO REQUEST, TIMESTAMP REQUEST, and SUBNET MASK REQUEST >> packets -- but not the corresponding replies! So, when you ping the >> local machine, you will see the ECHO REPLY packets on all raw >> listners, but not the initial ECHO REQUESTs. When you ping from a >> remote machine, you never see the ECHO REQUEST packets because the >> kernel takes care of them, and you never see the ECHO REPLY packets >> because they are addressed to the other machine. > Is this a FreeBSD-specific thing, or to other UNIX's have this > same peculiar behavior? It was the same in 4.3. I don't have 4.2 sources handy so I can't check there -- but in any case, the answers to your questions are ``no'' and ``yes''. The raw ICMP socket is defined to only see the traffic which the kernel is unable to handle itself. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 75 second delay using telnet/ssh (ipv6 related)
On Mon, Mar 20, 2000 at 11:33:24AM -0600, Visigoth wrote: > > > On Sun, 19 Mar 2000, Chris Piazza wrote: > > > If I use telnet or ssh (there might be more programs, > > but I have only noticed these two so far), and supply a hostname to it, > > my machine is constantly requesting records, and finally after > > 75 seconds it requests and receives an A record from the nameserver. > > Could it be possible that you have "options inet6" in your > /etc/resolv.conf file? This options causes calls for only records at > first and then if they fail, use A records. > > According to Mr. Stevens (Unix Network Programing Vol 1 > chapt 9.4) this option, or having the env. variable RES_OPTIONS=inet6 set > will cause the behavior you are describing... No, neither of those. FreeBSD searches inet6 first at the moment. I don't know if I made this clear in my email, but this just started happening... Hmm... it's fixed again: 12:01:15.622122 24.113.19.137.1253 > 24.2.10.36.53: 61892+ ? beast.freebsd.org. (35) 12:01:15.706319 24.2.10.36.53 > 24.113.19.137.1253: 61892 1/1/0 (132) 12:01:15.707070 24.113.19.137.1254 > 24.2.10.36.53: 61893+ A? beast.freebsd.org. (35) 12:01:15.750017 24.2.10.36.53 > 24.113.19.137.1254: 61893 2/4/4 (238) Weird. > > > Using ssh -4 or telnet -4 makes it work right away (of course), but > > I don't want to have to type that all the time. [program] ipv4address > > also works. > > Hmmm... I don't know but it seems that ssh -4 set's its own family to > AF_INET in all of it's calls to gethostbyname() rather than AF_INET6. > Thereby telling the resolver to only return A records Right. -Chris -- [EMAIL PROTECTED] [EMAIL PROTECTED] Abbotsford, BC, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emu10k1 (SB Live!) support under FreeBSD?
> > Cam's boredom out-weighed my initiative. 8) > > http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1 > driver (minus recording) which is need of debugging. Give it a try! How current is this? Will it work against 4.0-STABLE? Tom Veldhouse [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: >> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >> >> >Keeping the currect cluster code is a bad idea, if the drivers were >> >taught how to traverse the linked list in the buf struct rather >> >than just notice "a big buffer" we could avoid a lot of page >> >twiddling and also allow for massive IO clustering ( > 64k ) >> >> Before we redesign the clustering, I would like to know if we >> actually have any recent benchmarks which prove that clustering >> is overall beneficial ? > >Yes it is really benificial. I would like to see some numbers if you have them. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > > >Keeping the currect cluster code is a bad idea, if the drivers were > >taught how to traverse the linked list in the buf struct rather > >than just notice "a big buffer" we could avoid a lot of page > >twiddling and also allow for massive IO clustering ( > 64k ) > > Before we redesign the clustering, I would like to know if we > actually have any recent benchmarks which prove that clustering > is overall beneficial ? Yes it is really benificial. I'm not talking about a redesign of the clustering code as much as making the drivers that take a callback from it actually traverse the 'union cluster_info' rather than relying on the system to fake the pages being contiguous via remapping. There's nothing wrong with the clustering algorithms, it's just the steps it has to take to work with the drivers. > > I would think that track-caches and intelligent drives would gain > much if not more of what clustering was designed to do gain. > > I seem to remember Bruce saying that clustering could even hurt ? Yes because of the gyrations it needs to go through to maintain backward compatibility for devices that want to see "one big buffer" rather than simply follow a linked list of io operations. Not true, at least for 'devices' like NFS where large IO ops issued save milliseconds in overhead. Unless each device was to re-buffer IO (which is silly) or scan the vp passed to it (violating the adstraction and being really scary like my flopped super-commit stuff for NFS) it would make NFS performance even worse for doing commits. Without clustering you'd have to issue a commit RPC for each 8k block With the current clustering you have to issue a commit for each 64k block With an unbounded linked list, well there is only the limit that the filesystem asks for. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >Keeping the currect cluster code is a bad idea, if the drivers were >taught how to traverse the linked list in the buf struct rather >than just notice "a big buffer" we could avoid a lot of page >twiddling and also allow for massive IO clustering ( > 64k ) Before we redesign the clustering, I would like to know if we actually have any recent benchmarks which prove that clustering is overall beneficial ? I would think that track-caches and intelligent drives would gain much if not more of what clustering was designed to do gain. I seem to remember Bruce saying that clustering could even hurt ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >Well, let me tell you what the fuzzy goal is first and then maybe we >can work backwards. > >Eventually all physical I/O needs a physical address. The quickest >way to get to a physical address is to be given an array of vm_page_t's >(which can be trivially translated to physical addresses). Not all: PIO access to ATA needs virtual access. RAID5 needs virtual access to calculate parity. >What we want to do is to try to extend VMIO (aka the vm_page_t) all >the way through the I/O system - both VFS and DEV I/O, in order to >remove all the nasty back and forth translations. I agree, but some drivers need mapping we need to cater for those. They could simply call a vm_something(struct buf *) call which would map the pages and things would "just work". For RAID5 we have the opposite problem also: data is created which has only a mapped existance and the b_pages[] array is not populated. >In regards to odd block sizes and offsets the real question is whether >an attempt should be made to translate UIO ops into buffer cache b_pages[] >ops directly, maintaining offsets and odd sizes, or whether we should >back-off to a copy scheme where we allocate b_pages[] for oddly sized >uio's and then copy the data to the uio buffer. I don't know of any non DEV_BSIZE aligned apps that are sufficiently high-profile and high-performance to justify too much code to avoid a copy operation, so I guess that is OK. >My personal preference is to not pollute the VMIO page-passing mechanism >with all sorts of fields to handle weird offsets and sizes. Instead we >ought to take the copy hit for the non-optimal cases, and simply fix all >the programs doing the accesses to pass optimally aligned buffers. For >example, for a raw-I/O on an audio CD track you would pass a page-aligned >buffer with a request size of at least a page (e.g. 4K on IA32) in your >read(), and the raw device would return '2352' as the result and the >returned data would be page-aligned. No protest from here. Encouraging people to think about their data and the handling of them will always have my vote :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Buffer cache renovation
< said: > I think so. I can give -current a quick synopsis of the plan but I've > probably forgotten some of the bits (note: the points below are not > in any particular order): Cool! Sounds like you've really done a lot of work to clean up one of the darkest corners of the kernel. I can't wait to see the results. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ICMP socket weirdness
Garrett Wollman writes: > > When the program is run, if you ping the IP address from the > > local machine, it sees packets. However, if you ping it from > > a remote machine, it doesn't see packets. > > The ICMP never passes certain packets up to raw listeners. These > include ECHO REQUEST, TIMESTAMP REQUEST, and SUBNET MASK REQUEST > packets -- but not the corresponding replies! So, when you ping the > local machine, you will see the ECHO REPLY packets on all raw > listners, but not the initial ECHO REQUESTs. When you ping from a > remote machine, you never see the ECHO REQUEST packets because the > kernel takes care of them, and you never see the ECHO REPLY packets > because they are addressed to the other machine. Is this a FreeBSD-specific thing, or to other UNIX's have this same peculiar behavior? > It would be possible to pass all ICMP packets to the raw listeners, > but it would require rewriting parts of icmp_input() (which would not > be a bad idea) either to avoid modifying the packet in-place or to > keep a copy of the original before responding -- either of which would > slow down `ping' processing. The existence of m_dup() makes the latter option a lot easier.. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/8324
Don Lewis writes:
> } * Archie Cobbs <[EMAIL PROTECTED]> [000317 17:55] wrote:
> } > This bug has been around since at least 2.2.6 and is still present
> } > in RELENG_3, RELENG_4, and -current.
> } >
> } > http://www.freebsd.org/cgi/query-pr.cgi?pr=8324
> } >
> } > Is anyone planning to tackle it? What would be required to fix it?
> } > (it's not clear (to me anyway) from Bruce's description how hard
> } > this is to fix..)
>
> I never heard of using SIGIO for output, but section 6.4 of the daemon
> book says that SIGIO is sent "when a read or write becomes possible".
> On the other hand, section 10.8 (Terminal Operations) mentions SIGIO
> for input but not for output. I also looked at rev 1.1 of kern/tty.c
> and it only sends a SIGIO when input is ready, so this seems to be
> the historical behaviour, so I'm suprised that this program even
> worked with plain tty devices.
>
> } I think Bruce sort of went off into a tangent with his diagnosis,
> } anyhow this is untested (of course :) ), but looks like the right
> } thing to do (from sys_pipe.c).
> }
> } Perhaps the fcntls and ioctls aren't being propogated enough to set
> } the flags properly, but if they are then it should work sort of the
> } way SIGIO does, basically generating a signal for /some condition/
> } on a descriptor.
>
> This patch (vs the 3.4-STABLE version of tty.c) causes SIGIO to be
> sent when a regular or pseudo tty becomes writeable.
>
>
> --- tty.c.origSun Aug 29 09:26:09 1999
> +++ tty.c Sat Mar 18 03:09:32 2000
> @@ -2133,6 +2133,8 @@
>
> if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat)
> selwakeup(&tp->t_wsel);
> + if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL)
> + pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL));
> if (ISSET(tp->t_state, TS_BUSY | TS_SO_OCOMPLETE) ==
> TS_SO_OCOMPLETE && tp->t_outq.c_cc == 0) {
> CLR(tp->t_state, TS_SO_OCOMPLETE);
>
>
> BTW, I had to add:
> fcntl(1, F_SETOWN, getpid());
> to the test program since there is no longer a default target to send
> the signal to. The old scheme had the defect of sending SIGIO to the
> process group that owned the terminal, which implied that the terminal
> had to be the controlling terminal for the process group. This limited
> a process to only receiving SIGIO from one terminal device even if it
> had more than one open and it wanted to receive SIGIO from all of them.
> Also, SIGIO was sent to the entire process group, but it may be desireable
> to limit this to one process. I wonder if it might make sense to go
> back to the old default for tty devices so that processes only receive
> SIGIO when they are in the foreground ...
Don-
After applying your patch to kern/tty.c and adding the F_SETOWN,
the problem indeed seems to go away..
Is this patch ready to be committed, or do we need more reviewers?
Thanks,
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP; new options for -current!
Jeroen Ruigrok van der Werven wrote: > > I already addressed that in new-bus and there is some discussion and > finding out the best way to do a higher level wrapping for a lot of > newbus' stuff. Is there? Where? I don't recall seeing that in any of the newbus mailing lists I (used to) subscribe to. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
* Matthew Dillon <[EMAIL PROTECTED]> [000320 10:01] wrote: > > : > : > :>Kirk and I have already mapped out a plan to drastically update > :>the buffer cache API which will encapsulate much of the state within > :>the buffer cache module. > : > :Sounds good. Combined with my stackable BIO plans that sounds like > :a really great win for FreeBSD. > : > :-- > :Poul-Henning Kamp FreeBSD coreteam member > :[EMAIL PROTECTED] "Real hackers run -current on their laptop." > > I think so. I can give -current a quick synopsis of the plan but I've > probably forgotten some of the bits (note: the points below are not > in any particular order): > * Cleanup the buffer cache API (bread(), BUF_STRATEGY(), and so forth). > Specifically, split out the call functionality such that the buffer > cache can determine whether a buffer being obtained is going to be > used for reading or writing. At the moment we don't know if the system > is going to dirty a buffer until after the fact and this has caused a > lot of pain in regards to dealing with low-memory situations. > > getblk() -> getblk_sh() and getblk_ex() > > Obtain bp without issuing I/O, getting either a shared or exclusive > lock on the bp. With a shared lock you are allowed to issue READ > I/O but you are not allowed to modify the contents of the buffer. > With an exclusive lock you are allowed to issue both READ and WRITE > I/O and you can modify the contents of the buffer. > > bread() -> bread_sh() and bread_ex() > > Obtain and validate (issue read I/O as appropriate) a bp. bread_sh() > allows a buffer to be accessed but not modified or rewritten. > bread_ex() allows a buffer to be modified and written. This seems to allow for expressing intent to write to buffers, which would be an excellent place to cow the pages 'in software' rather than obsd's way of using cow'd pages to accomplish the same thing. I'm not sure if you remeber what I brought up at BAFUG, but I'd like to see something along the lines of BX_BKGRDWRITE that Kirk is using for the bitmaps blocks in softupdates to be enabled on a system wide basis. That way rewriting data that has been sent to the driver isn't blocked and at the same time we don't need to page protect during every strategy call. I may have misunderstood your intent, but using page protections on each IO would seem to introduce a lot of performance issues that the rest of these points are all trying to get rid of. > The idea for the buffer cache is to shift its functionality to one that > is solely used to issue device I/O and to keep track of dirty areas for > proper sequencing of I/O (e.g. softupdate's use of the buffer cache > to placemark I/O will not change). The core buffer cache code would > no longer map things to KVM with b_data, that functionality would be > shifted to the VM Object vm_pager_*() API. The buffer cache would > continue to use the b_pages[] array mechanism to collect pages for I/O, > for clustering, and so forth. Keeping the currect cluster code is a bad idea, if the drivers were taught how to traverse the linked list in the buf struct rather than just notice "a big buffer" we could avoid a lot of page twiddling and also allow for massive IO clustering ( > 64k ) because we won't be limited by the size of the b_pages[] array for our upper bound on the amount of buffers we can issue effectively a scatter/gather on (since the drivers must VTOPHYS them anyway). To realize my "nfs super commit" stuff all we'd need to do is make the max cluster size something like 0-1 and instantly get an almost unbounded IO burst. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
[Format recovered--see http://www.lemis.com/email/email-format.html] On Saturday, 18 March 2000 at 3:34:38 +0100, Palle Girgensohn wrote: > Hi! Please don't send messages one line per paragraph. It's a pain to reformat. > I'm having troubles updating a FreeBSD 3-stable system to current, > since it has /usr as a vinum volume. I've just updated about a dozen > machines without any problems, but none of them uses vinum. > > Following the instructions in UPDATING, when rebooting to single > user mode, vinum wouldn't work since the kernel module was out of > date - no surprise. Hmm. After updating, you should have had new klds as well. But that's probably not your fault. Could you enter a PR about it, please? > So, I copied a fresh vinum.ko in there and tried again. This time, > vinum loaded fine, but complained that it couldn't get the list from > disk (or similiar). How similar? That statement doesn't really help very much. Vinum produces error messages to help pinpoint problems. > A 'vinum list' command would show nothing. So, I tried rebooting > with the old 3-stable kernel. When makeing installworld running the > 3-stable kernel, make first installed the make binary itself, and > then could not do anything more, since the new libc was not in > place, and the just installed make needed the new libc... odd? shall > it really start by installing make? dunno how this happened? It looks like you shot yourself in the foot. > Anyway, what is a good strategy for upgrading a system where /usr is > a vinum volume? Any tips, tricks or ideas (apart from moving /usr to > a non-vinum volume and install onto that one). I'd have to find out what went wrong first. It looks as if it should have worked modulo the problems installing the klds. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
:Thanks for the sketch. It sounds really good. : :Is it your intention that drivers which cannot work from the b_pages[] :array will call to map them into VM, or will a flag on the driver/dev_t/ :whatever tell the generic code that it should be mapped before calling :the driver ? : :What about unaligned raw transfers, say a raw CD read of 2352 bytes :from userland ? I pressume we will need an offset into the first :page for that ? Well, let me tell you what the fuzzy goal is first and then maybe we can work backwards. Eventually all physical I/O needs a physical address. The quickest way to get to a physical address is to be given an array of vm_page_t's (which can be trivially translated to physical addresses). The buffer cache already has such an array, called b_pages[]. Any I/O that runs through b_data or runs through a uio must eventually be cut up into blocks of contiguous physical addresses. What we want to do is to try to extend VMIO (aka the vm_page_t) all the way through the I/O system - both VFS and DEV I/O, in order to remove all the nasty back and forth translations. In regards to raw devices I originally envisioned having two BUF_*() strategy calls - one that uses a page array, and one that uses b_data. But your idea below - using bio_ops[], is much better. In regards to odd block sizes and offsets the real question is whether an attempt should be made to translate UIO ops into buffer cache b_pages[] ops directly, maintaining offsets and odd sizes, or whether we should back-off to a copy scheme where we allocate b_pages[] for oddly sized uio's and then copy the data to the uio buffer. My personal preference is to not pollute the VMIO page-passing mechanism with all sorts of fields to handle weird offsets and sizes. Instead we ought to take the copy hit for the non-optimal cases, and simply fix all the programs doing the accesses to pass optimally aligned buffers. For example, for a raw-I/O on an audio CD track you would pass a page-aligned buffer with a request size of at least a page (e.g. 4K on IA32) in your read(), and the raw device would return '2352' as the result and the returned data would be page-aligned. This would allow the system call to use the b_pages[] strategy entry point even for devices with odd sizes and still get optimal (zero-copy) operation. If the user passes a non-aligned (or mulitiple of a page-sized) buffer, the system takes the copy hit in order to keep the lower level I/O interface clean. :One thing I would like to see is for the buffers to know how to :write themselves. There is nothing which mandates that a buffer :be backed by a disk-like device, and there are uses for buffers :which aren't. : :Being able to say bp->bop_write(bp) rather than bwrite(bp) would :allow that flexibility. Kirk already introduced a bio_ops[] but :made it global for now, that should be per buffer and have all the :bufferops in it, (except for the onces which instantiate the buffer). : :If we had this, pseudo filesystems like DEVFS could use UFS for :much of their naming management. This is currently impossible. : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." :FreeBSD -- It will take a long time before progress goes too far! I like the idea of dynamicizing bio_ops[] and using that to issue struct buf based I/O. It fits very nicely into the general idea of separating the VFS and DEV I/O interfaces (they are currently hopelessly intertwined). Actually, the more I think about it the more I'm willing to just say to hell with it and start doing all the changes all at once, in parallel, including the two patches you wanted reviewed earlier (though I would request that you not combine disparate patch funcitonalities into a single patch set). I agree with Julian on the point about IPSEC. Dynamicizing bio_ops[] ought to be trivial. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emu10k1 (SB Live!) support under FreeBSD?
| | I would love to help out, but I don't know where to start, and I have no | | kernel programming experience. There are reference drivers available for | | linux via http://opensource.creative.com or http://www.alsa-project.org | | (my preference). | | One is on the way... Cam's boredom out-weighed my initiative. 8) http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1 driver (minus recording) which is need of debugging. Give it a try! -- Dan Moschuk ([EMAIL PROTECTED]) "Waste not fresh tears on old griefs." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >I think so. I can give -current a quick synopsis of the plan but I've >probably forgotten some of the bits (note: the points below are not >in any particular order): Thanks for the sketch. It sounds really good. Is it your intention that drivers which cannot work from the b_pages[] array will call to map them into VM, or will a flag on the driver/dev_t/ whatever tell the generic code that it should be mapped before calling the driver ? What about unaligned raw transfers, say a raw CD read of 2352 bytes from userland ? I pressume we will need an offset into the first page for that ? One thing I would like to see is for the buffers to know how to write themselves. There is nothing which mandates that a buffer be backed by a disk-like device, and there are uses for buffers which aren't. Being able to say bp->bop_write(bp) rather than bwrite(bp) would allow that flexibility. Kirk already introduced a bio_ops[] but made it global for now, that should be per buffer and have all the bufferops in it, (except for the onces which instantiate the buffer). If we had this, pseudo filesystems like DEVFS could use UFS for much of their naming management. This is currently impossible. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
syslogd_flags in /etc/defaults/rc.conf
I'm curious to see if anyone is like-minded with me that syslogd_flags in /etc/defaults/rc.conf should be "-ss" instead of "". I reasoned that it should be, considering: 1. Most people don't direct syslogs at other machines in my experience. 2. Someone could conceivably DOS a machine by directing tons of crap at port 121, which is also noted in the BUGS section of the syslogd manpage. 3. Syslogd runs as root, and while it is a mature piece of code, I think it preferable to minimize the number of root applications listening on sockets. Nick -- "Why do so many people concern themselves so much with the private affairs of complete strangers?" - Me My PGP public key:http://www.spatula.net/pubkey.txt Nick Johnson, version 1.5 http://www.spatula.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: suggestion: a g77 -> f77 link
David O'Brien wrote: > > On Mon, Mar 20, 2000 at 11:48:02AM +0100, Jose M. Alcaide wrote: > > Now, a week after the discussion, what do you think about my proposal > > of the "g77" link under /usr/bin? > > What part about "NO" was unclear? > Hey, OK, don't get upset! :-) You are the maintainer, so you have the authority about this issue. Simply, I thought that, after explaining my arguments and Satoshi giving his opinion, there was a chance that you might changed your mind. If this not the case, well, forget it. I'll do, too. End of discussion. Regards, -- JMA --- José Mª Alcaide | mailto:[EMAIL PROTECTED] Universidad del País Vasco | mailto:[EMAIL PROTECTED] Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 --- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
: : :>Kirk and I have already mapped out a plan to drastically update :>the buffer cache API which will encapsulate much of the state within :>the buffer cache module. : :Sounds good. Combined with my stackable BIO plans that sounds like :a really great win for FreeBSD. : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." I think so. I can give -current a quick synopsis of the plan but I've probably forgotten some of the bits (note: the points below are not in any particular order): Probably the most important thing to keep in mind when reading over this list is to note that nearly all the changes being contemplated can be implemented without breaking current interfaces, and the current interfaces can then be shifted over to the new interfaces one subsystem at a time (shift, test, shift, test, shift test) until none of the original use remains. At the point the support for the original API can be removed. * make VOP locking calls recursive. That is, to obtain exclusive recursive locks by default rather then non-recursive locks. * cleanup all VOP_*() interfaces in regards to the special handling of the case where a locked vnode is passed, a locked vnode is returned, and the returned vnode happens to wind up being the same as the locked vnode (Allow a double-locked vnode on return and get rid of all the stupid code that juggles locks around to get around the non-recursive nature of current exclusive locks). VOP_LOOKUP is the most confused interface that needs cleaning up. With only a small amount of additional work, mainly KASERT's to catch potential problems, we should be able to turn on exclusive recursion. The VOP_*() interfaces will have to be fixed one at a time with VOP_LOOKUP topping the list. * Make exclusive buffer cache locks recursive. Kirk has completed all the preliminary work on this and we should be able to just turn it on. We just haven't gotten around to it (and the release got in the way). This is necessary to support up and coming softupdates mechanisms (e.g. background fsck, snapshot dumps) as well as better-support device recursion. * Cleanup the buffer cache API (bread(), BUF_STRATEGY(), and so forth). Specifically, split out the call functionality such that the buffer cache can determine whether a buffer being obtained is going to be used for reading or writing. At the moment we don't know if the system is going to dirty a buffer until after the fact and this has caused a lot of pain in regards to dealing with low-memory situations. getblk() -> getblk_sh() and getblk_ex() Obtain bp without issuing I/O, getting either a shared or exclusive lock on the bp. With a shared lock you are allowed to issue READ I/O but you are not allowed to modify the contents of the buffer. With an exclusive lock you are allowed to issue both READ and WRITE I/O and you can modify the contents of the buffer. bread() -> bread_sh() and bread_ex() Obtain and validate (issue read I/O as appropriate) a bp. bread_sh() allows a buffer to be accessed but not modified or rewritten. bread_ex() allows a buffer to be modified and written. * Many uses of the buffer cache in the critical path do not actually require the buffer data to be mapped into KVM. For example, a number of I/O devices need only the b_pages[] array and do not need a b_data mapping. It would not take a huge amount of work to adjust the uiomove*() interfaces appropriately. The general plan is to try remove whole portions of the current buffer cache funcitonality and shift them into the new vm_pager_*() API. That is, to operate on VM Object's directly whenever possible. The idea for the buffer cache is to shift its functionality to one that is solely used to issue device I/O and to keep track of dirty areas for proper sequencing of I/O (e.g. softupdate's use of the buffer cache to placemark I/O will not change). The core buffer cache code would no longer map things to KVM with b_data, that functionality would be shifted to the VM Object vm_pager_*() API. The buffer cache would continue to use the b_pages[] array mechanism to collect pages for I/O, for clustering, and so forth. It should be noted that the buffer cache's perceived slowness is almost entirely due to all the KVM manipulation it does for b_data, and that such manipulate is not necessary for the vast majority of the critical path: Reading and writing file data (can run through the VM Object API), and issuing I/O (can avoid b_data KVM mappings entirely). Meta data, such as
Re: 75 second delay using telnet/ssh (ipv6 related)
On Sun, 19 Mar 2000, Chris Piazza wrote: > If I use telnet or ssh (there might be more programs, > but I have only noticed these two so far), and supply a hostname to it, > my machine is constantly requesting records, and finally after > 75 seconds it requests and receives an A record from the nameserver. Could it be possible that you have "options inet6" in your /etc/resolv.conf file? This options causes calls for only records at first and then if they fail, use A records. According to Mr. Stevens (Unix Network Programing Vol 1 chapt 9.4) this option, or having the env. variable RES_OPTIONS=inet6 set will cause the behavior you are describing... > Using ssh -4 or telnet -4 makes it work right away (of course), but > I don't want to have to type that all the time. [program] ipv4address > also works. Hmmm... I don't know but it seems that ssh -4 set's its own family to AF_INET in all of it's calls to gethostbyname() rather than AF_INET6. Thereby telling the resolver to only return A records Damieon Stark Sr Unix System's Administrator [EMAIL PROTECTED] __ M$ Windows 2000 was built for the internet. Unix *BUILT* the internet. your call __ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCMCIA Maker Modem
you don't it IS sio4 you need to make /dev/ entried for sio4 and they should work. sio4 has been created in the kernel dynamically by the pcmcia code. you can also look at the pccard.conf file in /etc and rename it to make sio2 if you want. however in that case you'd have to make sure that sio2 is NOT in your kernel. julian On Mon, 20 Mar 2000, Tim Ryder wrote: > Also how do i compile sio4 into my kernel > > tim ryder > > -Original Message- > From: Tim Ryder <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Monday, March 20, 2000 11:12 AM > Subject: PCMCIA Maker Modem > > > >My pcmcia modem seems to show up as sio4 which does not exist on my system. > > > >It is a: > >pcmcia maker modem 56k v.90 datafax modem > > > > > >does any have the settings for this modem > > > >i use a sony vaio PCG_V505VE > > > >tim ryder > >please cc me on this because i am not on the list > > > >[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: PCMCIA Maker Modem
Also how do i compile sio4 into my kernel tim ryder -Original Message- From: Tim Ryder <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Monday, March 20, 2000 11:12 AM Subject: PCMCIA Maker Modem >My pcmcia modem seems to show up as sio4 which does not exist on my system. > >It is a: >pcmcia maker modem 56k v.90 datafax modem > > >does any have the settings for this modem > >i use a sony vaio PCG_V505VE > >tim ryder >please cc me on this because i am not on the list > >[EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCMCIA Maker Modem
My pcmcia modem seems to show up as sio4 which does not exist on my system. It is a: pcmcia maker modem 56k v.90 datafax modem does any have the settings for this modem i use a sony vaio PCG_V505VE tim ryder please cc me on this because i am not on the list [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SUS/2 non-compliance in waitpid() function?
Adherance to standards is always a goal for FreeBSD. If you wish to try implement this change, then your patches would make a good starting point for people to look and discuss. (I say this because technically those parts of the kernel are not that complex, but what is harder is finding people with time and who are interested in the change). Julian On Mon, 20 Mar 2000, Cejka Rudolf wrote: > > I have found that in Single Unix Specification 2 in waitpid() function > there are allowed options not only WNOHANG and WUNTRACED as is in FreeBSD, > but furthermore option WCONTINUED (Unixware and Solaris both know about > this option and FreeBSD and possible Linux don't). > > The next problem is in macro WIFCONTINUED(), which is specified > by SUS 2 too, but again in FreeBSD it is missing. > > Are there any chances to satisfy SUS 2 in FreeBSD in waitpid() function? > > -- > Rudolf Cejka ([EMAIL PROTECTED]; http://www.fee.vutbr.cz/~cejkar) > Brno University of Technology, Faculty of El. Engineering and Comp. Science > Bozetechova 2, 612 66 Brno, Czech Republic > > > 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: suggestion: a g77 -> f77 link
On Mon, Mar 20, 2000 at 11:48:02AM +0100, Jose M. Alcaide wrote: > Now, a week after the discussion, what do you think about my proposal > of the "g77" link under /usr/bin? What part about "NO" was unclear? -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SUS/2 non-compliance in waitpid() function?
I have found that in Single Unix Specification 2 in waitpid() function there are allowed options not only WNOHANG and WUNTRACED as is in FreeBSD, but furthermore option WCONTINUED (Unixware and Solaris both know about this option and FreeBSD and possible Linux don't). The next problem is in macro WIFCONTINUED(), which is specified by SUS 2 too, but again in FreeBSD it is missing. Are there any chances to satisfy SUS 2 in FreeBSD in waitpid() function? -- Rudolf Cejka ([EMAIL PROTECTED]; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP; new options for -current!
-On [2319 21:00], Poul-Henning Kamp ([EMAIL PROTECTED]) wrote: >In message <[EMAIL PROTECTED]>, Peter Wemm writes >: >>If you are using old drivers that haven't been newbusified yet, you will >>need to add 'options COMPAT_OLDPCI' and/or 'options COMPAT_OLDISA' to your >>kernel configs and regenerate. Otherwise you will get compile failures. > >I think this is premature. > >I tried to newbusify if_mn.c, but after having added about 50 lines >of code to replace the current about 10, I gave up. > >We need a highlevel wrapper for newbus before we should force people >to upgrade the old-style drivers. I already addressed that in new-bus and there is some discussion and finding out the best way to do a higher level wrapping for a lot of newbus' stuff. So rest assured, work is underway. =) -- Jeroen Ruigrok van der Werven Network- and systemadministrator <[EMAIL PROTECTED]> VIA NET.WORKS The Netherlands BSD: Technical excellence at its best http://www.bart.nl The mediocre teacher tells, the good teacher explains, the superior teacher demonstrates, the great teacher inspires... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: suggestion: a g77 -> f77 link
Hi David, Now, a week after the discussion, what do you think about my proposal of the "g77" link under /usr/bin? IMHO, the following facts are all good reasons for creating the link: - the output of "f77 -V", "f77 --version", "man f77", and "info g77"; - our Fortran compiler _is_ GNU Fortran, i.e., g77; - there are configure scripts which [legitimately] look for g77 when instructed to use the GNU Fortran compiler; - we already have a "gcc" link. I understand (and agree) your arguments against Gfoo, but I think that the benefits of the g77 link are worth the "sacrifice" (gsacrifice?) :-) Regards, -- JMA * Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] * "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
>Kirk and I have already mapped out a plan to drastically update >the buffer cache API which will encapsulate much of the state within >the buffer cache module. Sounds good. Combined with my stackable BIO plans that sounds like a really great win for FreeBSD. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
makeinfo for gdb.info is broken
My latest world breakage involves makeinfo on gdb.info. I tried to dig through the makefile maze to try and get just that bit not to build and I can't sort it out. Error message below. Doug -- "While the future's there for anyone to change, still you know it seems, it would be easier sometimes to change the past" - Jackson Browne, "Fountain of Sorrow" makeinfo --no-validate -I /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc -I /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld -I /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc -I /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc -I /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc --no-split -I /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc -I /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo -o gdb.info /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:4647: warning: unlikely character , in @var. /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:5284: warning: @sc argument all uppercase, thus no effect. /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:6531: warning: @sc argument all uppercase, thus no effect. /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc/rluser.texinfo:1331: warning: @sc argument all uppercase, thus no effect. ./inc-hist.texi:31: Index `bt' already exists. makeinfo: Removing output file `gdb.info' due to errors; use --force to preserve. *** Error code 2 Stop in /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc. *** Error code 1 Stop in /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin. *** Error code 1 Stop in /usr/amd/realmounts/slave/usr/current/src/gnu. *** Error code 1 Stop in /usr/amd/realmounts/slave/usr/current/src. *** Error code 1 Stop in /usr/amd/realmounts/slave/usr/current/src. *** Error code 1 Stop in /usr/amd/realmounts/slave/usr/current/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
:I have two patches up for test at http://phk.freebsd.dk/misc : :I'm looking for reviews and tests, in particular vinum testing :would be nice since Grog is quasi-offline at the moment. : :Poul-Henning : :2317 BWRITE-STRATEGY.patch : :This patch is machine generated except for the ccd.c and buf.h :parts. : :Rename existing BUF_STRATEGY to DEV_STRATEGY :substitute BUF_WRITE(foo) for VOP_BWRITE(foo->b_vp, foo); :substitute BUF_STRATEGY(foo) for VOP_STRATEGY(foo->b_vp, foo); : :Please test & review. : : :2317 b_iocmd.patch : :This patch removes B_READ, B_WRITE and B_FREEBUF and replaces :them with a new field in struct buf: b_iocmd. : :B_WRITE was bogusly defined as zero giving rise to obvious :coding mistakes and a lot of code implicitly knew this. : :This patch also eliminates the redundant flag B_CALL, it can :just as efficiently be done by comparing b_iodone to NULL. : :Should you get a panic or drop into the debugger, complaining about :"b_iocmd", don't continue, it is likely to write where it should :have read. : :Please test & review. Kirk and I have already mapped out a plan to drastically update the buffer cache API which will encapsulate much of the state within the buffer cache module. I don't think it makes much sense to make these relatively complex but ultimately not-significantly-improving changes to the buffer cache code at this time. Specifically, I don't think renaming the BUF_WRITE/VOP_BWRITE or BUF_STRATEGY/DEV_STRATEGY stuff is worth doing at all, and while I agree that the idea of separting out the IO command (b_iocmd patch) is a good one, it will be much more effective to do it *AFTER* Kirk and I have separated out the functional interfaces because it will be mostly encapsulated in a single source module. At the current time the extensive nature of the changes have too high a potential for introducing new bugs in a system that has undergone significant debugging and testing and is pretty much known to work properly. -Matt Matthew Dillon <[EMAIL PROTECTED]> : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." :FreeBSD -- It will take a long time before progress goes too far! : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: install problem with 4.0 (spec_getpages)
* Marc van Kempen <[EMAIL PROTECTED]> [000320 00:58] wrote: > > > > > You also ought to make sure the floppies can get through a complete > > format before dd'ing the images over them. > > > This was it! I went through 8 floppies before I found a decent pair, > these 3.5" things s*ck. Another fun one is dd'ing the 2.88MB images to a 1.44 diskette and being too tired to figure out what the #@$@#$@@# is going wrong while shivering your butt off in the colo facility. blech! :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: install problem with 4.0 (spec_getpages)
> > You also ought to make sure the floppies can get through a complete > format before dd'ing the images over them. > This was it! I went through 8 floppies before I found a decent pair, these 3.5" things s*ck. Thanks, Marc. -- Marc van Kempen BowTie Technology Email: [EMAIL PROTECTED]WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
