subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PPP still has problems with config parsing
[.] tun0: Command: ip-telecom: set dial ABORT BUSY ABORT NO\sCARRIER ABORT NO\sDIAL\sTONE TIMEOUT 5 "" AT OK-AT-OK ATF OK AT#F0$R1%E0S20=8E2S48=16 OK \dATDP\T TIMEOUT 40 CONNECT [.] ppp was treating everything from the # to the end of line as a comment. It should be fixed now. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Mon, 27 Dec 1999 03:39:56 -0500, Donn Miller [EMAIL PROTECTED] said: http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz Donn Hmmm... this seems to have broken the probe at boot time. Donn Here's a sample of my dmesg: (snip) Donn unknown1: ESS ES1868 Plug and Play AudioDrive at port Donn 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 That is odd... The patch does not even touch sbc.c. How does your pnpinfo(1) look like? -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
On Mon, 27 Dec 1999 16:08:01 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo Another fix was made on feeding and sucking pcm data. Now chn_wrfeed() Seigo and the other functions do not attempt excessive feeding during DMA Seigo transfer to eat up the whole processor. The patch is at: Ouch, the patch broke Rollemup, so I fixed just now. The URI is the same. Seigo http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
At 8:55 AM -0500 12/24/99, Robert Watson wrote: ... keep in mind that this optimization does not produce behavior behavior in some cases. For example, imagine that the user has a number of hard links to the file in question. If the file is copied and then deleted, then the link count is decremented by one, and the data used to print is independent of the original file. However, if a single file system rename is used, the link count remains the same until the end of the print job, and if any of the other references to the same inode are modified, the print job will see inconsistent versions of the file (i.e., it being changed out from under it). Hmm. This was a very good point to bring up, even if people don't use it to modify the file (or do anything else nefarious). The real problem here is that lpr changes the ownership and permissions of the file after moving it. That means that if the user does give us a file with multiple hard links, lpr will repermit *all* copies of the file, not just the version it moved into the spool directory. Clearly we also need to check the inode count. Thanks for that observation! I do not know whether the current lpr waits until it finishes copying before returning, but assume so, meaning that once lpr returns, normally, you are guaranteed that unless using the symlink option, you can continue to modify the inode in question with impunity. With this optimization makes that assumption not true. A caveat is already present for the symlink, "-s", option to this effect. I believe this also allows users to present files that start out being within the maximum file size when that is checked, but later add more, allowing users to avoid the file size limit on print jobs. This is presumably already present with "-s", and it's possible that lpd checks for this. Well, for some reason lpr is dumber than that. The spooled datafile ends up being owned by the user who sent the job, and thus the user can go in any time and make changes. That's already true, without this update or '-s' being used. Personally I think that is bad, because it does allow the user to circumvent any checks done at job-submission time. I think I'll write a separate update for that (maybe next year... :-). --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Installation bug (4.0-19991227-CURRENT)
Did a test install against the latest snapshot. The network configuration comes up with "dc0" (we have de0), this "works" in that we were able to perform the network install (so it must be a typo somewhere). However, it results in multiple entries in /etc/rc.conf (three, total), which have to be removed before the network will come up correctly after rebooting. NB, this was an install over a previous 4.0 instance, so there's the possibility that the rc.conf file was edited rather than written over -- though I would doubt that (?). FYI. _F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installation bug (4.0-19991227-CURRENT)
The 'de' driver has been obsoleted for the 21143 part by the 'dc' driver. You should be using 'dc' for those devices that it supports. Did a test install against the latest snapshot. The network configuration comes up with "dc0" (we have de0), this "works" in that we were able to perform the network install (so it must be a typo somewhere). However, it results in multiple entries in /etc/rc.conf (three, total), which have to be removed before the network will come up correctly after rebooting. NB, this was an install over a previous 4.0 instance, so there's the possibility that the rc.conf file was edited rather than written over -- though I would doubt that (?). FYI. _F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ 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: Installation bug (4.0-19991227-CURRENT)
On Mon, Dec 27, 1999 at 02:14:29PM -0500, Forrest Aldrich wrote: Did a test install against the latest snapshot. The network configuration comes up with "dc0" (we have de0), this "works" in that we were able to perform the network install (so it must be a typo somewhere). If you had been following -current, you would know that Bill Paul has written the dc driver, that works with much of the same cards that the de driver does. If both the de and dc driver are available, the dc driver wins. However, it results in multiple entries in /etc/rc.conf (three, total), which have to be removed before the network will come up correctly after rebooting. NB, this was an install over a previous 4.0 instance, so there's the possibility that the rc.conf file was edited rather than written over -- though I would doubt that (?). That is probably the case ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installation bug (4.0-19991227-CURRENT)
In message [EMAIL PROTECTED], Forrest Aldrich writes : Did a test install against the latest snapshot. The network configuration comes up with "dc0" (we have de0), this "works" in that we were able to perform the network install (so it must be a typo somewhere). No, dc0 is the new and improved driver for the newer tulip chips. However, it results in multiple entries in /etc/rc.conf (three, total), which have to be removed before the network will come up correctly after rebooting. NB, this was an install over a previous 4.0 instance, so there's the possibility that the rc.conf file was edited rather than written over -- though I would doubt that (?). That is probably what happened here. -- 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
IPFW
Hi, I apologize if this question is not appropriate for this list but... I just installed FreeBSD 4.0-CURRENT (19991226) on a box. I also recompiled the kernel so it would support SMP. All I basicly did is change two lines concerning SMP in the GENERIC kernel (I followed the handbook). The box is running just fine and I am very pleased with it. Here is the problem: I'm trying to firewall it using ipfw, when I issue the command ipfw add deny udp from any to any 1-2200 I get 0 deny udp from any to any 1-2200 ipfw: setsockopt(IP_FW_ADD): Protocol not available I only changed two lines in the GENERIC kernel. Did I screw it up? I assumed packet filtering was enabled in the GENERIC kernel by default. Can anyone give me hints on how to fix this, or what this message means? I already RTFM and the stuff in the handbook (the man page looks very similar to the stuff that was in the handbook). Any help is greatly appreciated :) (PS: does the IPFILTER package work with FreeBSD? Because I'm used it and ipfw syntax is kinda anal. If so, has anyone tried it and successfully used it? Thanks.) -- Emre Yildirim Fingerprint = B16C EBA7 97FE EF2C 365F C4C4 54AA 3676 5E9E E10A DSS/DH 1024/4064: 0x5E9EE10A/0x2486FEBE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPFW
On Mon, 27 Dec 1999, Emre wrote: Hi, I apologize if this question is not appropriate for this list but... I just installed FreeBSD 4.0-CURRENT (19991226) on a box. I also recompiled the kernel so it would support SMP. All I basicly did is change two lines concerning SMP in the GENERIC kernel (I followed the handbook). The box is running just fine and I am very pleased with it. Here is the problem: I'm trying to firewall it using ipfw, when I issue the command ipfw add deny udp from any to any 1-2200 I get 0 deny udp from any to any 1-2200 ipfw: setsockopt(IP_FW_ADD): Protocol not available Add the line: options IPFIREWALL to your kernel config and recompile. See LINT for documentation and other options you may wish to consider. IP Firewalling is not enabled by default in GENERIC. -- Brian Buchanan [EMAIL PROTECTED] -- FreeBSD - The Power to Serve! http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPFW
On Mon, Dec 27, 1999 at 01:06:52PM -0800, Brian W. Buchanan wrote: Add the line: options IPFIREWALL to your kernel config and recompile. See LINT for documentation and other options you may wish to consider. IP Firewalling is not enabled by default in GENERIC. Oh Thanks for the quick reply, I will try now :) -- Emre Yildirim Fingerprint = B16C EBA7 97FE EF2C 365F C4C4 54AA 3676 5E9E E10A DSS/DH 1024/4064: 0x5E9EE10A/0x2486FEBE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
How to de-select DMA to ad0?
I've had my share of problems with this drive's DMA abilities. I'm convinced that it has none... even though it probes as such. ad0: NEC Coporation DSE2550A/5DE0314 ATA-0 disk at ata0 as master ad0: ... ad0: 16 secs/int, 1 depth queue, DMA now... when I boot -v, I don't have a chance to write down what it says, but it will hang every time with the following output: ad0: ad-timeout: lost disk contact ata0: resetting drives -- mask=03 status0=50 status1=50 .. And that's it. It never prints out "done" which I see in many of the list messages. Is there a way of disabling DMA on a specific drive? I read a bit of the source, but didn't find any obvious documentation on the issue. (This is all on a kernel compiled from a cvsup this afternoon) Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: es1371 PCI128 Rev 7 patch
The problem with the PCI128 rev 7 and ASUS boards seem to be solved with a simple patch. Anybody with such a combination please try this patch ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.patch Once it is verified to work, I'm sure somebody will want to commit it. dunno what's solved by what, but current is not blasting sound for me. reading the lists, suggestions for adding controller pnp0 seem out of date, as i get rip.psg.com:/sys/i386/conf# config RIP Don't forget to do a ``make depend'' Warning: controller "pnp" is unknown Kernel build directory is ../../compile/RIP the patch mentioned above does not take with current.9912270034, two rejects. so i expect a commit was done. dmesg whines pci0: Intel PIIX4 ATA controller (vendor=0x8086, dev=0x7111) at 4.1 pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 4.2 irq 19 ... bktr0: BrookTree 878 irq 18 at device 10.0 on pci0 iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 bktr0: Hauppauge Model 6 A M bktr0: Detected a MSP3430G-A1 at 0x80 Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18 pcm0: AudioPCI ES1371 irq 17 at device 11.0 on pci0 ac97: dac not ready ... kernel sez device pcm0 randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
At 8:55 AM -0500 12/24/99, Robert Watson wrote:
For example, imagine that the user has a
number of hard links to the file in question.
Okay, here's my newer version of the code, which takes into
account multiple hard links, and also makes it so the spooled
data file is owned by daemon instead of the user. This works
fine. At some later point I'll write an update so the spooled
data file is owned by daemon in other cases, too.
Further comments or observations welcome. If this looks okay
I'll submit this as a new PR.
Index: lpr/lpr.c
===
RCS file: /Users/cvsdepot/lpr-fbsd/lpr/lpr.c,v
retrieving revision 1.1.1.1
diff -U5 -r1.1.1.1 lpr.c
--- lpr.c 1999/11/30 16:15:22 1.1.1.1
+++ lpr.c 1999/12/27 21:58:39
@@ -382,10 +382,69 @@
nact++;
continue;
}
if (sflag)
printf("%s: %s: not linked, copying
instead\n", name, arg);
+
+ if (f) {
+ /*
+* The user wants the file removed after it is copied,
+* so see if it can be mv'ed instead of copy/unlink'ed.
+* This will be much faster and better than copying the
+* file, especially for larger files. Can be very
+* useful for services like samba, pcnfs, CAP, et al.
+*/
+ int ret, didlink;
+ struct stat statb2;
+ seteuid(euid);
+ didlink = 0;
+ /* don't do this if the user's file is a symlink */
+ if (lstat(arg, statb) 0) goto nohardlink;
+ if (S_ISLNK(statb.st_mode)) goto nohardlink;
+ /* if the attempt to link fails, abandon the move */
+ if (link(arg, dfname) != 0) goto nohardlink;
+ didlink = 1;
+ /* make sure the user hasn't tried to trick us via
+* any race conditions */
+ if (lstat(dfname, statb2) 0)goto nohardlink;
+ if (statb.st_dev != statb2.st_dev) goto nohardlink;
+ if (statb.st_ino != statb2.st_ino) goto nohardlink;
+ /* skip if the file already had multiple hard links,
+* because changing the owner and access-bits would
+* change ALL versions of the file */
+ if (statb2.st_nlink 2) goto nohardlink;
+
+ /* if we can access and remove the given file without
+* special setuid-ness then this method is safe. */
+ seteuid(uid);
+ ret = access(dfname, R_OK);
+ if (ret == 0)
+ ret = unlink(arg);
+ seteuid(euid);
+ /* the user does not have access to read or remove
+* this file, so abandon the move and fall back to
+* the usual (copy) methods. */
+ if (ret != 0) goto nohardlink;
+
+ /* unlink of user file was successful. fixup perms,
+* add entries to control file, and skip copy step */
+ chown(dfname, pp-daemon_user, getegid());
+ chmod(dfname, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP);
+ seteuid(uid);
+ if (format == 'p')
+ card('T', title ? title : arg);
+ for (i = 0; i ncopies; i++)
+ card(format, dfname[inchar-2]);
+ card('U', dfname[inchar-2]);
+ card('N', arg);
+ nact++;
+ continue;
+nohardlink:
+ if (didlink) unlink(dfname);
+ seteuid(uid); /* restore old uid */
+ } /* end: if (f) */
+
if ((i = open(arg, O_RDONLY)) 0) {
printf("%s: cannot open %s\n", name, arg);
} else {
copy(pp, i, arg);
(void) close(i);
===
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: es1371 PCI128 Rev 7 patch
Randy Bush wrote: The problem with the PCI128 rev 7 and ASUS boards seem to be solved with a simple patch. Anybody with such a combination please try this patch ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.patch Once it is verified to work, I'm sure somebody will want to commit it. dunno what's solved by what, but current is not blasting sound for me. reading the lists, suggestions for adding controller pnp0 The pnp stuff shouldn't have anything to do with this card, it's pi. Cameron did a bunch of code clean up, which is why the patch didn't apply. I generated a new patch that should apply to current -current. ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.2,patch seem out of date, as i get rip.psg.com:/sys/i386/conf# config RIP Don't forget to do a ``make depend'' Warning: controller "pnp" is unknown Kernel build directory is ../../compile/RIP the patch mentioned above does not take with current.9912270034, two rejects. so i expect a commit was done. dmesg whines pci0: Intel PIIX4 ATA controller (vendor=0x8086, dev=0x7111) at 4.1 pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 4.2 irq 19 ... bktr0: BrookTree 878 irq 18 at device 10.0 on pci0 iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 bktr0: Hauppauge Model 6 A M bktr0: Detected a MSP3430G-A1 at 0x80 Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18 pcm0: AudioPCI ES1371 irq 17 at device 11.0 on pci0 ac97: dac not ready ... kernel sez device pcm0 randy -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPFW
On Mon, Dec 27, 1999 at 10:02:29PM +0100, Wilko Bulte wrote: Is there any reason for you to run -current? Because if there isn't you'd be better off using a -stable version of FreeBSD. Not really. All my other boxes (NetBSD/OpenBSD) run -current so I'm used to be on the "bleeding edge" I figured it would be enabled by default, since FreeBSD promises to be _the_ Server O/S. Actually I haven't tried -release or -stable...I'm willing to take the chance. BTW, I fixed the firewalling stuff, ipfw still has a bit anal syntax but I think I got it working. Thanks for the help :) -- Emre Yildirim Fingerprint = B16C EBA7 97FE EF2C 365F C4C4 54AA 3676 5E9E E10A DSS/DH 1024/4064: 0x5E9EE10A/0x2486FEBE To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: es1371 PCI128 Rev 7 patch
dunno what's solved by what, but current is not blasting sound for me. reading the lists, suggestions for adding controller pnp0 The pnp stuff shouldn't have anything to do with this card, it's pi. ^c unnerstand. but there's stuff on the current list saying to use that with the pci128, so i thought i would debunk it. ftp://ftp.thebarn.com/FreeBSD/es1371/es1371-src4-PCI128rev7.2,patch yes! works fine on my asus p2b-ds with current as of this morning. thank you. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unknown pci card
any clue how i can find out what this puppy is Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. - pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18 pcm0: AudioPCI ES1371 irq 17 at device 11.0 on pci0 i think everything in the box is working. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown pci card
On Mon, 27 Dec 1999, Randy Bush wrote: any clue how i can find out what this puppy is Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. - pci0: unknown card (vendor=0x109e, dev=0x0878) at 10.1 irq 18 Go to http://www.pcisig.com/membership/vendors/sorted.html to look up vendor ids (this one's a brooktree part) pcm0: AudioPCI ES1371 irq 17 at device 11.0 on pci0 i think everything in the box is working. randy 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: if_fxp.c
hehe oops.. follow up to my own message this is for -stable :) -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" On Mon, 27 Dec 1999, Eric D. Futch wrote: This is from -current as of Wed Dec 22 01:48:17 EST 1999 ../../pci/if_fxp.c: In function `fxp_intr': ../../pci/if_fxp.c:1069: warning: label `getit' defined but not used ../../pci/if_fxp.c:1064: warning: label `dropit' defined but not used -- Eric Futch New York Connect.Net, Ltd. [EMAIL PROTECTED] Technical Support Staff http://www.nyct.net (212) 293-2620 "Bringing New York The Internet Access It Deserves" 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
Proposed patch to fix VN device (again)
Sigh. Ok, I've fixed the VN device. Again. It looks like the removal of
/dev/drum removed a little too much. We need the device infrastructure
to support the VN device's use of swap backing store.
This patch below is a commit candidate. It could use a review, then I'll
commit it.
-Matt
Index: swap_pager.h
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.h,v
retrieving revision 1.27
diff -u -r1.27 swap_pager.h
--- swap_pager.h1999/11/18 06:55:40 1.27
+++ swap_pager.h1999/12/27 23:59:49
@@ -106,6 +106,7 @@
/* choose underlying swap device and queue up I/O */
struct buf;
+struct vnode *vm_swap_makevnode __P((void));
void swstrategy __P((struct buf *bp)); /* probably needs to move elsewhere */
#endif
Index: vm_swap.c
===
RCS file: /home/ncvs/src/sys/vm/vm_swap.c,v
retrieving revision 1.93
diff -u -r1.93 vm_swap.c
--- vm_swap.c 1999/12/15 23:02:35 1.93
+++ vm_swap.c 1999/12/28 00:05:55
@@ -68,6 +68,42 @@
static int nswdev = NSWAPDEV;
int vm_swap_size;
+#define CDEV_MAJOR 4
+
+static struct cdevsw sw_cdevsw = {
+ /* open */ nullopen,
+ /* close */ nullclose,
+ /* read */ noread,
+ /* write */ nowrite,
+ /* ioctl */ noioctl,
+ /* poll */ nopoll,
+ /* mmap */ nommap,
+ /* strategy */ swstrategy,
+ /* name */ "sw",
+ /* maj */ CDEV_MAJOR,
+ /* dump */ nodump,
+ /* psize */ nopsize,
+ /* flags */ D_DISK,
+ /* bmaj */ -1
+};
+
+struct vnode *
+vm_swap_makevnode(void)
+{
+ struct vnode *vp = NULL;
+
+ if (getnewvnode(VT_NON, NULL, spec_vnodeop_p, vp)) {
+ panic("Cannot get vnode for swapdev");
+ return(NULL);
+ }
+ vp-v_rdev = make_dev(sw_cdevsw, 1, UID_ROOT, GID_KMEM,
+ 0640, "swapdev");
+ vp-v_rdev-si_bsize_phys = PAGE_SIZE;
+ vp-v_rdev-si_bsize_best = PAGE_SIZE;
+ vp-v_type = VCHR;
+ return(vp);
+}
+
/*
* swstrategy:
*
Index: swap_pager.c
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.129
diff -u -r1.129 swap_pager.c
--- swap_pager.c1999/11/22 15:27:09 1.129
+++ swap_pager.c1999/12/28 00:01:24
@@ -329,10 +329,7 @@
swhash_mask = n - 1;
- n = getnewvnode(VT_NON, NULL, spec_vnodeop_p, swapdev_vp);
- if (n)
- panic("Cannot get vnode for swapdev");
- swapdev_vp-v_type = VBLK;
+ swapdev_vp = vm_swap_makevnode();
}
/*
Index: /usr/src/sys/conf/majors
===
RCS file: /home/ncvs/src/sys/conf/majors,v
retrieving revision 1.94
diff -u -r1.94 majors
--- majors 1999/12/17 19:56:39 1.94
+++ majors 1999/12/27 23:27:37
@@ -21,7 +21,7 @@
1 ctty/dev/tty
2 mm /dev/mem,kmem,etc
3 wd ST506 disk controller (with IDE extensions)
-4 was:swap/dev/drum
+4 swap/dev/drum
5 pts pseudo tty "tty" half
6 ptc pseudo tty "master" half
7 log system log
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure
so, to go for 3.4 to -current i had to o comment kerberos4 and perl from /etc/make.conf o build o build and install perl right in the directory o the usual cruft it works. and it fixed o wl0 o my dlt free bus error still working on kerberos, but i have learned to care less and less about it. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
In message [EMAIL PROTECTED], Matthew Dillon writes: Sigh. Ok, I've fixed the VN device. Again. It looks like the removal of /dev/drum removed a little too much. We need the device infrastructure to support the VN device's use of swap backing store. This patch below is a commit candidate. It could use a review, then I'll commit it. Could you please explain why you need this ? -- 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: Proposed patch to fix VN device (again)
: :In message [EMAIL PROTECTED], Matthew Dillon writes: : :Sigh. Ok, I've fixed the VN device. Again. It looks like the removal of :/dev/drum removed a little too much. We need the device infrastructure :to support the VN device's use of swap backing store. : :This patch below is a commit candidate. It could use a review, then I'll :commit it. : :Could you please explain why you need this ? : :-- :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! VN calls vm_pager_strategy() which collects I/O in filesystem buffers (bp)'s in order to cluster the I/O, and you cannot initiate I/O on filesystem buffers without a valid b_dev. So, the jist of the problem is that in order to get reasonable performance out of the thing (i.e. not issue 4K I/O's to the disk), we have to use filesystem buffers which means the bp must be properly initialized. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
troubles with X
Hi all, I just rebooted my -current box for the first time in a long time. Everything on this box is freshly compiled (including X) as of only a couple of hours ago. I even mergemaster'd for good measure. For some reason now I can't startx(1) as either myself or root. I type startx and the PAM auth routines loop forever printing out 'Password:'. I comment out the last two lines in /etc/pam.conf and I get an authentication failure (as I should). Anyone have any ideas what I'm doing wrong? What is the correct method to start X on -current nowadays? Thanks. -steve PS: I'd search the mailing lists but I can't get to my browser and I'm not so good with lynx. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
newpcm and non-PnP SoundBlaster Vibra 16 4.13
Hi. I have been following the thread(s) about getting the SoundBlaster Vibra 16 sound-cards working in -current, and it appears that if you have a PnP card, it seems to be working. I do not have a PnP version of this card, and the last time I was able to get the sound card recognised was October 2nd. A verbose boot of that kernel reveals sb_probe: no addr, trying (0x220, 0x240) pcm: SoundBlaster 16 4.13) at irq 10 drq 3 flags 0x17 on isa0 sb_probe: no addr, trying (0x220, 0x240) pcm: setmap 4c, ff00; 0xc80b500 - 4c000 pcm: setmap 4d, ff00; 0xc80c500 - 4d000 and /dev/sndstat reveals FreeBSD Audio Driver (newpcm) Oct 2 1999 14:30:27 Installed devices: pcm0: SoundBlaster 16 4.13 at io 0x220 irq 10 drq 3:7 (1/1 channels duplex) With subsequent kernels, including a -current kernel from 20 Dec, the sound card is not detected. The definitions I'm using in my kernel currently (no pun intended :) are #sound card device pcm0 device sbc0 at isa? port ? irq 10 drq 3 flags 0x17 as compared to what I had device pcm0 at isa? port ? irq 10 drq 3 flags 0x17 The card is probed if the machine is booted with a kernel of Oct 2, and not probed if the machine is botted with a kernel of Dec 20. The only other thing I can think of is that the old kernel had support for PnP, whereas the new ones doesn't. This shouldn't matter though if I'm supplying the parameters directly to the card. Khetan Gajjar. --- [EMAIL PROTECTED] * [EMAIL PROTECTED]* PGP Key, contact UUNET South Africa * FreeBSD enthusiast * details and other http://www.uunet.co.za/ * http://www.freebsd.org/ * information at System Administration * http://link.os.org.za/ * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
In message [EMAIL PROTECTED], Matthew Dillon writes: VN calls vm_pager_strategy() which collects I/O in filesystem buffers (bp)'s in order to cluster the I/O, and you cannot initiate I/O on filesystem buffers without a valid b_dev. So, the jist of the problem is that in order to get reasonable performance out of the thing (i.e. not issue 4K I/O's to the disk), we have to use filesystem buffers which means the bp must be properly initialized. vm_pager_strategy() branches out based on the object type and ends up in swap_pager_strategy() which only uses b_dev after calling swstrategy() then only in a diagnostic printf which we had better never reach. swstrategy() which initializes bp-b_dev to the right physical device. I'm afraid I don't see why or where we would need the bogus /dev/drum dev_t. Furthermore, since we have already clustered above the VN device, I seriously doubt the utility of doing it again between VN and the swapdevice. -- 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: Proposed patch to fix VN device (again)
:In message [EMAIL PROTECTED], Matthew Dillon writes: : :VN calls vm_pager_strategy() which collects I/O in filesystem buffers :(bp)'s in order to cluster the I/O, and you cannot initiate I/O on :filesystem buffers without a valid b_dev. : :So, the jist of the problem is that in order to get reasonable performance :out of the thing (i.e. not issue 4K I/O's to the disk), we have to use :filesystem buffers which means the bp must be properly initialized. : :vm_pager_strategy() branches out based on the object type and ends up :in swap_pager_strategy() which only uses b_dev after calling swstrategy() :then only in a diagnostic printf which we had better never reach. : :swstrategy() which initializes bp-b_dev to the right physical device. : :I'm afraid I don't see why or where we would need the bogus /dev/drum dev_t. : :Furthermore, since we have already clustered above the VN device, :I seriously doubt the utility of doing it again between VN and the :swapdevice. : :-- :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! Umm. Poul, I know you don't like the idea but you obviously do not understand the code in question. First, you are confusing the underlying swap devices that we swapon on with the parent swap device that controls them. The parent swap device needs to have a dev_t - it does not currently have one, and this is the entry point that the buffers are going into. The underlying swap devices *already* have a dev_t. My kernel crashes on a NULL bp-b_dev. In fact, it also crashes on a NULL vp-v_rdev. Without the patch. So if you are trying to say that b_dev is being magically set I gotta tell you that my kernel dumps say otherwise. Second, the clustering done above the VN device is done by the filesystem and has no understanding of whether the underlying media controlled by the VN device can itself be clustered in the same way. When using swap as backing store what may appear to be clusterable by the filesystem may actually *NOT* be clusterable when you get into the swap device due to potentially non-contiguous mappings as well as border-crossings between interleaved swap devices. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
In message [EMAIL PROTECTED], Matthew Dillon writes: First, you are confusing the underlying swap devices that we swapon on with the parent swap device that controls them. The parent swap device needs to have a dev_t - it does not currently have one, and this is the entry point that the buffers are going into. The underlying swap devices *already* have a dev_t. My kernel crashes on a NULL bp-b_dev. In fact, it also crashes on a NULL vp-v_rdev. And where in the code does this crash happen ? Second, the clustering done above the VN device is done by the filesystem and has no understanding of whether the underlying media controlled by the VN device can itself be clustered in the same way. When using swap as backing store what may appear to be clusterable by the filesystem may actually *NOT* be clusterable when you get into the swap device due to potentially non-contiguous mappings as well as border-crossings between interleaved swap devices. So you need to cluster all the way through the VN device ? Obviously clustering on just one side will not buy you anything. Tough luck... It sounds more and more like the mistake here is for VN to have a specfs VOP vector on top, I think it needs its own VOP vector so it can get hold of the VOP_BMAP function... -- 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: Proposed patch to fix VN device (again)
:In message [EMAIL PROTECTED], Matthew Dillon writes: : :First, you are confusing the underlying swap devices that we swapon on :with the parent swap device that controls them. The parent swap device :needs to have a dev_t - it does not currently have one, and this is :the entry point that the buffers are going into. The underlying swap :devices *already* have a dev_t. My kernel crashes on a NULL bp-b_dev. :In fact, it also crashes on a NULL vp-v_rdev. : :And where in the code does this crash happen ? #9 0xc023c5b3 in trap () #10 0xc014b862 in devsw () #11 0xc017fa4a in vn_isdisk () #12 0xc018e1f3 in spec_strategy () #13 0xc020eb42 in flushchainbuf () #14 0xc0202e1e in swap_pager_strategy () #15 0xc020e675 in vm_pager_strategy () #9 0xc023c5e3 in trap () #10 0xc014b862 in devsw () #11 0xc018e26e in spec_strategy () #12 0xc020eb72 in flushchainbuf () #13 0xc0202e4e in swap_pager_strategy () #14 0xc020e6a5 in vm_pager_strategy () #9 0xc023c5c3 in trap () #10 0xc018e23f in spec_strategy () #11 0xc020eb52 in flushchainbuf () #12 0xc0202e2e in swap_pager_strategy () #13 0xc020e685 in vm_pager_strategy () :Second, the clustering done above the VN device is done by the :filesystem and has no understanding of whether the underlying media :controlled by the VN device can itself be clustered in the same way. :When using swap as backing store what may appear to be clusterable :by the filesystem may actually *NOT* be clusterable when you get into :the swap device due to potentially non-contiguous mappings as well :as border-crossings between interleaved swap devices. : :So you need to cluster all the way through the VN device ? Obviously :clustering on just one side will not buy you anything. Tough luck... : :It sounds more and more like the mistake here is for VN to have a :specfs VOP vector on top, I think it needs its own VOP vector so :it can get hold of the VOP_BMAP function... : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." Ummm. The VN device is not a filesystem, it's a 'disk'. The UFS filesystem does not recursively VOP_BMAP down into the underlying media so implementing VOP_BMAP in VN would not help. We could implement our own set of device vectors but it would be rather pointless since specfs's device vectors do everything we want. And, in anycase, I am not going to spend hours putting together a long involved patch when a simple short patch suffices. If you want to spend the time to come up with your own patch (that doesn't screw the pooch in regards to cluster performance!), then I'm all ears, otherwise this patch is what is going to go in for the 4.0 release. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
Ahh, I see the mistake.
All you need to fix this is to add a new function:
void
flushswchainbuf(struct buf *nbp)
{
if (nbp-b_bcount) {
nbp-b_bufsize = nbp-b_bcount;
if ((nbp-b_flags B_READ) == 0)
nbp-b_dirtyend = nbp-b_bcount;
BUF_KERNPROC(nbp);
swstrategy(nbp);
} else {
biodone(nbp);
}
}
And use this instead of flushchainbuf() in swap_pager_strategy().
--
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: Proposed patch to fix VN device (again)
:
:
:Ahh, I see the mistake.
:
:All you need to fix this is to add a new function:
:
: void
: flushswchainbuf(struct buf *nbp)
: {
: if (nbp-b_bcount) {
: nbp-b_bufsize = nbp-b_bcount;
: if ((nbp-b_flags B_READ) == 0)
: nbp-b_dirtyend = nbp-b_bcount;
: BUF_KERNPROC(nbp);
: swstrategy(nbp);
: } else {
: biodone(nbp);
: }
: }
:
:And use this instead of flushchainbuf() in swap_pager_strategy().
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED] "Real hackers run -current on their laptop."
Uh... no. The chain buffer routines are supposed to be generic. In fact,
all the filesystem buffer cache I/O routines are supposed to be generic.
There is no way I'm going to pollute them to special case swap.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
In message [EMAIL PROTECTED], Matthew Dillon writes:
:
:Ahh, I see the mistake.
:
:All you need to fix this is to add a new function:
:
: void
: flushswchainbuf(struct buf *nbp)
: {
: if (nbp-b_bcount) {
: nbp-b_bufsize = nbp-b_bcount;
: if ((nbp-b_flags B_READ) == 0)
: nbp-b_dirtyend = nbp-b_bcount;
: BUF_KERNPROC(nbp);
: swstrategy(nbp);
: } else {
: biodone(nbp);
: }
: }
:
:And use this instead of flushchainbuf() in swap_pager_strategy().
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED] "Real hackers run -current on their laptop."
Uh... no. The chain buffer routines are supposed to be generic. In fact,
all the filesystem buffer cache I/O routines are supposed to be generic.
There is no way I'm going to pollute them to special case swap.
Ok, fair enough: Then stop abusing struct buf for swap device access :-)
If you want to abuse struct buf for swap device access, you will need
to special case it as applicable.
--
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: Proposed patch to fix VN device (again)
::-- ::Poul-Henning Kamp FreeBSD coreteam member ::[EMAIL PROTECTED] "Real hackers run -current on their laptop." : :Uh... no. The chain buffer routines are supposed to be generic. In fact, :all the filesystem buffer cache I/O routines are supposed to be generic. :There is no way I'm going to pollute them to special case swap. : :Ok, fair enough: Then stop abusing struct buf for swap device access :-) : :If you want to abuse struct buf for swap device access, you will need :to special case it as applicable. : :-- :Poul-Henning Kamp FreeBSD coreteam member :[EMAIL PROTECTED] "Real hackers run -current on their laptop." Huh? Look Poul, I don't know what your problem is but I'm through playing around with you. You aren't making any sense and, frankly my dear sir, the buffer cache, vm_pager interface, VN device, and vm_pager_strategy subsystem is my ball of wax, not yours... I don't need your permission and I certainly don't need your help if this is all you can come up with. I'm not going to twist up all that wonderful clean code just to avoid making the swapper a real device. After all, making it a real device is only a few simple lines of code - simple and straightforward. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
In message [EMAIL PROTECTED], Matthew Dillon writes: Huh? Look Poul, I don't know what your problem is but I'm through playing around with you. You aren't making any sense and, frankly my dear sir, the buffer cache, vm_pager interface, VN device, and vm_pager_strategy subsystem is my ball of wax, not yours... Sorry, not so (and you've been told plenty many times already). You should fix the swap-pager to remove this last smoldering assumption about the existence of /dev/drum, rather than obfuscate the rest of the system by adding it back. I know it means more work for you, but we're not here to cut corners, we're here to get a better system. We don't get a better system if you keep pushing the dirty bits into obscure corners of the kernel rather than fix them where they need fixed. I don't need your permission and I certainly don't need your help if this is all you can come up with. I objected to your patch on the grounds that it would be a step backwards, that has nothing to do with getting my permission. can come up with. I'm not going to twist up all that wonderful clean code just to avoid making the swapper a real device. You can call that "wonderful clean code" all you like, it is most certainly not the term I would use for it, and either way the matter of the fact is that struct buf is being abused to do something which it isn't able to do in its current design, and the way to fix that is not to add a hacked up dev_t but to give it special handling where it needs that. And adding a bogus dev_t and a equally bogus devsw does by no means make the swapper "a real device". I still object to your patch. It is a step backwards and it would further obfuscate the swap_pagers 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! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
: :In message [EMAIL PROTECTED], Matthew Dillon writes: : :Huh? Look Poul, I don't know what your problem is but I'm through :playing around with you. You aren't making any sense and, frankly my :dear sir, the buffer cache, vm_pager interface, VN device, and :vm_pager_strategy subsystem is my ball of wax, not yours... : :Sorry, not so (and you've been told plenty many times already). : :You should fix the swap-pager to remove this last smoldering :assumption about the existence of /dev/drum, rather than obfuscate :the rest of the system by adding it back. : :I know it means more work for you, but we're not here to cut corners, :we're here to get a better system. We don't get a better system if :you keep pushing the dirty bits into obscure corners of the kernel :rather than fix them where they need fixed. Sorry Poul, but you have no authority in this matter. All the statements you have made in the last hour simply point out, in very clear terms, that you don't know what you are talking about. Instead of simply admiting a mistake or even spending some time to review the code more closely, your solution is instead to continue to make outrageous statements. Frankly, Poul, I strongly, *STRONGLY* recommend that you simply not reply to any of my postings. Not a single one, because I am wholely sick and tired of your superiority complex. This thread was not meant for you, and your presence in it is not welcome. And don't even think about doing an end-run around me and committing your frankly inappropriate 'solution' - I'm going through proper channels to get this in. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
In message [EMAIL PROTECTED], Matthew Dillon writes: Sorry Poul, but you have no authority in this matter. All the statements you have made in the last hour simply point out, in very clear terms, that you don't know what you are talking about. Instead of simply admiting a mistake or even spending some time to review the code more closely, your solution is instead to continue to make outrageous statements. The fact that I think the hacks should be kept firmly inside the VM system, rather than spill out into the rest of the kernel is not something I count amongst my mistakes. I have actually spent quite some time looking at the code, both before and again tonight just because of your email. That is probably the best example of a review process which works. Frankly, Poul, I strongly, *STRONGLY* recommend that you simply not reply to any of my postings. This has been my general policy for a long time, but it gets overridden whenever you come up with something which is obviously wrong. (And I find the fact that so many people have adopted this policy disturbing, and sufficient grounds for me to relax my instance of it.) Not a single one, because I am wholely sick and tired of your superiority complex. This thread was not meant for you, and your presence in it is not welcome. And don't even think about doing an end-run around me and committing your frankly inappropriate 'solution' - I'm going through proper channels to get this in. I have all rights I need to answer you when you send an email in public asking for a review. It is my obligation to answer you when I am one of the few people who are not intimidated by neither you nor the code in question and I can see that what you are proposing is plain wrong. So far you have one very experienced kernel programmer objecting to your patch, so yes: you will bloddy have to go through proper channels to resolve this issue. -- 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: Proposed patch to fix VN device (again)
I've heard from both of you that you think the other is wrong. This isn't very helpful, however, in finding the correct solution. What I'd like to hear from both of you is the reasons why swap is better as a device, or not. There seems to be some unstated architectural philosophy that needs to be stated before any informed decision can be made about what is the right direction to go in. -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: INET6 userland tools
Very INET6 specific patches are already prepared and under the review. getaddrinfo() and getaddrname() is not yet, but I'll also prepare them. And after those libraries are prepared, porting KAME tools onto current won't be difficult. Getaddrinfo(), getaddrname(), etc support is commited, and also several udp and raw socket apps are also committed. -gethostbyaddr(), gethostbyname(), etc support in libc/net (but DNS query over IPv6 transport is not yet) -several udp and raw socket apps ping6 rtsol(host address autoconfiguration tool. Actually the source code is shared with 'rtsold'. Though it needs 'rtadvd' daemon on a router, 'rtadvd' for current is not yet.) rtsold(host address autoconfiguration daemon for Note PC, which frequently change its subnet) gifconfig(v6/v4, v6/v4, v4/v4, v6/v6 tunneling configuration) ifmcstat(print out v6 multicast addr configuration info) prefix(assigne address prefix, e.g. subnet addr, just like ifconfig for full addr. it also support host internal prefix renumbering) route6d rip6query Anyone interested in them please try and enjoy. (Note that you need to build kernel with INET6 option.) If there is any problems, please let me know. Thanks, Yoshinobu Inoue KAME project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
Matthew Dillon wrote: [..] And, in anycase, I am not going to spend hours putting together a long involved patch when a simple short patch suffices. If you want to spend the time to come up with your own patch (that doesn't screw the pooch in regards to cluster performance!), then I'm all ears, otherwise this patch is what is going to go in for the 4.0 release. Please hold fire for a bit longer. I have (what I think is) a much cleaner fix in mind. There is no urgency here, a couple of hours isn't going to make the slightest difference to the big picture. On a side note, as the original author of the changes that lead to this, I would have thought it would have been appropriate to ask ME directly first before going public. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
David Greenman wrote:
I've heard from both of you that you think the other is wrong. This isn't
very helpful, however, in finding the correct solution. What I'd like to hear
from both of you is the reasons why swap is better as a device, or not. There
seems to be some unstated architectural philosophy that needs to be stated
before any informed decision can be made about what is the right direction to
go in.
The problem is that swapdev_vp needs to handle VOP_STRATEGY(), and swapdev_vp
is incorrectly being pointed at spec_vnops. Here is a proposed (UNTESTED!)
clean fix:
Index: swap_pager.c
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.129
diff -u -r1.129 swap_pager.c
--- swap_pager.c1999/11/22 15:27:09 1.129
+++ swap_pager.c1999/12/28 03:22:08
@@ -199,6 +199,32 @@
static daddr_t swp_pager_meta_ctl __P((vm_object_t, vm_pindex_t, int));
/*
+ * Handle a VOP_STRATEGY() on swapdev_vp
+ */
+
+static int
+swapdev_strategy(ap)
+ struct vop_strategy_args /* {
+ struct vnode *a_vp;
+ struct buf *a_bp;
+ } */ *ap;
+{
+ struct buf *bp;
+
+ bp = ap-a_bp;
+ return swstrategy(bp);
+}
+
+vop_t **swapdev_vnodeop_p;
+static struct vnodeopv_entry_desc swapdev_vnodeop_entries[] = {
+ { vop_strategy_desc, (vop_t *) swapdev_strategy },
+ { NULL, NULL }
+};
+static struct vnodeopv_desc swapdev_vnodeop_opv_desc =
+ { swapdev_vnodeop_p, swapdev_vnodeop_entries };
+VNODEOP_SET(swapdev_vnodeop_opv_desc);
+
+/*
* SWP_SIZECHECK() - update swap_pager_full indication
*
* update the swap_pager_almost_full indication and warn when we are
@@ -329,7 +355,7 @@
swhash_mask = n - 1;
- n = getnewvnode(VT_NON, NULL, spec_vnodeop_p, swapdev_vp);
+ n = getnewvnode(VT_NON, NULL, swapdev_vnodeop_p, swapdev_vp);
if (n)
panic("Cannot get vnode for swapdev");
swapdev_vp-v_type = VBLK;
After this, flushchainbuf() on a bp that is bound to swapdev_vp should do
the right thing. There is still no need at all to redirect this via a fake
device.
I'll be testing this shortly, but I wanted to get an alternative in before the
arms race truely turned nuclear.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: General ata grousing
In message [EMAIL PROTECTED] Peter Wemm writes: : Just as a BTW, dfr and sos are exchanging patches right now (and have been : for quite a few days) that happen to fix the inthand_add() stuff. This may also help the pccard code cases which I have floating around. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
: : I've heard from both of you that you think the other is wrong. This isn't :very helpful, however, in finding the correct solution. What I'd like to hear :from both of you is the reasons why swap is better as a device, or not. There :seems to be some unstated architectural philosophy that needs to be stated :before any informed decision can be made about what is the right direction to :go in. : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Ok, I'll buy that. Though I will note that VN has been broken for over a month - I found that out about half a month ago and posted the fact, and if Poul is so interested in fixing it he could easily have done so then. I'm the one who has spent all the time tracking it down, patching, and testing it, and frankly that should count for a hellofalot more then nil. Poul frankly does not have a leg to stand on to demand that I work on a 'better' solution when I didn't cause the problem in the first place, nor does he have any right to pollute the VM code to end-run around the issue. It would be tragic if Poul's behavior were allowed to conclude the matter. That said, here is my position, split into a 'history' and my 'reasoning': Previously we had /dev/drum, which didn't work, and the SWAP device was layered around a device and swap I/O was vectored through the device subsystem. One month ago, after discussions, Peter Wemm removed the userland frontend for the swap device, /dev/drum, and at the same time thought it would be a good idea to collapse the VOP_STRATEGY routines (that ran through the SWAP dev_t) into direct calls to swstrategy(). At the time I was ambivalent but since the change seemed to clear out a bunch of cruft I went with it. However, this broke the VN device. I found this out about half a month later (around half a month ago) but at the time was hip deep in NFS work for the 3.4 release and could not address the issue. Now that the NFS work is finished I revisited the now broken VN device to determine what went wrong. It turns out that the VN device indirectly runs through the swap device using several generic filesystem buffer related subsystems. When the swap dev_t was removed, the result was a panic. - The VN device uses vm_pager_strategy() to implement swap backing store. vm_pager_strategy() is a generic mechanism that I introduced into the VM system a number of months ago for two reasons: (1) As a sounding board for giving the vm_pager_*() functions a strategy entry point, to see how well it would work. (2) To implement the swap backing store feature for the VN device. vm_pager_strategy() in turn looks at the pager ID and does a table lookup call through to the swap_pager_strategy() function. This function takes a VM object and a *generic* bp. While the function itself is swap-specific, the design of the code is supposed to be as generic as possible. vm_pager_strategy() may need to cut up the bp into subrequests to deal with clustering issues. It uses the generic 'chainbuf' routines to manage the asynchronous I/O. The 'chainbuf' routines are designed to be as generic as possible.. they take BP's. They do *NOT* and are not intended to be special cased in any way. This is my design for these routines, and even though they are currently used only by the swap_pager_strategy() code I believe the generic nature of the routines must be maintained. I/O sequencing for the swap-backed VN device is thus: VN-vm_pager_strategy-chainbuf-STRATEGY. I advocate that the best solution is to simply undo part of the original commit and restore SWAP's dev_t which was removed a month ago. Poul's solution is considerably more complicated (the patch he offered will not work in all cases, and I've already corrected all his other misstatements that I do not really feel it appropriate to continue to correct his misstatements when all he does with those corrections is use them as a poolboard to make his next set of incorrect statements!). I will tell you why Poul's patch will not work, but I am NOT going to tell Poul because, damn it, he has no right to spend 5 minutes working up a shoddy patch and then try to dictate to me that it should be used over my well tested 8-hours-of-work patch! Poul's patch will not work because flushchainbuf() is not the only chain routine that flushes the buffers. getchainbuf() and waitchainbuf() may *also* flush the buffers if there are already too many chain buffers built up in the linked list. Poul only addressed flushchainbuf(). He obviously didn't bother to read the code carefully and he just as obviously doesn't understand it. And not understanding it I can't imagine
Re: Proposed patch to fix VN device (again)
In message [EMAIL PROTECTED], David Greenman writes: There seems to be some unstated architectural philosophy that needs to be stated before any informed decision can be made about what is the right direction to go in. The underlying problem is of course that struct buf is a conglomerate of "struct block_cache" and "struct io_request", and in the cases where you need only the latter functionality you still have to respect all the conventions of the former. This issue leads to complexity and hacks in all code that needs to splite a io operation: vinum, ccd, swap_pager and disk_slice/label. For this reason the swap-pager has a bogus vnode: (swapdev_vp) to hang buffers from. This vnode even more bogusly uses spec_vnodeop_p for its vop[], and at the far end of that vop[] it used to abuse /dev/drum to get things done. If we want to maintain the presently unused generality of the chainbuf routines (they are currently only used in the swap-pager), then the fix is to add a real vop[] to the bogus swapdev_vp so that VOP_STRATEGY correctly end up in swstrategy() for swap device buffers. If we accept that the chainbuf routines are of limited utility, we can simply s/VOP_STRATEGY/swstrategy/ in the flushchain procedure. The reason why /dev/drum should not be brought back is that it isn't a device and it shouldn't be made one. In particular it should not made one to paste over a bogus vnode, that would be a step backwards. If we want to *really* fix the problem, we should introduce a bop[] function vector on struct buf. Kirk already (almost) did this: struct bio_ops. This bop[] would be where code would find the strategy, bwrite* and other operations on the buffer without knowing if the buffer has a dev_t, a dev_t + a vnode, only a vnode or neither associated with it. This fix is out of scope for the present problem, and certainly not a 4.0 item. This fix will be needed before we can put a non-device backed storage layer under UFS. -- 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: Proposed patch to fix VN device (again)
Frankly, Poul, I strongly, *STRONGLY* recommend that you simply not reply to any of my postings. Not a single one, because I am wholely sick and tired of your superiority complex. This thread was not meant This is unwontedly personal and has no place in a public mailing list. Please keep your replies confined to technical content (or your concerns about the lack thereof) and keep always in mind that getting emotional serves only to generate heat when what's needed is light. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
It makes no sense whatsoever to spend hours or days reworking a major subsystem *just* so the swap device can do without a dev_t. I don't really give a damn about /dev/drum -- I said before and I will say again that we can leave it out. But we need to give the swap device its's dev_t back to fix VN because no matter what you believe the *right* thing is to do, (A) nobody has time to rework a major subsystem at this time, and (B) VN was broken when the dev_t was removed, the dev_t should be added back in until someone comes up with a better overall solution. I also strongly believe that polluting *OTHER* subsystems (the buffer chaining code) just to avoid creating a dev_t for SWAP makes even less sense. I do not have the inclination to spend huge amounts of my time reworking the VOP or filesystem buffer subsystem because someone isn't willing to spend a tiny amount of code to partially back out a patch that broke something (VN) in the system, that someone also not themselves willing to spend the time required to rework the system properly. It's that simple. It makes no sense to impose such a requirement on someone else to fix a problem that they did not create. Now I would like to make a clarification: The commit we are talking about was actually one Peter did with the approval of everyone, including me. At the end of November.However, nobody including me realized that the second part of his commit, which was an optimization to remove the 'cruft' of the SWAP device, broke VN. If we had known then that this optimization would break VN it would *NOT* have gone in until the VN problem was fixed. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
Peter Wemm wrote: David Greenman wrote: I've heard from both of you that you think the other is wrong. This isn' t very helpful, however, in finding the correct solution. What I'd like to he ar from both of you is the reasons why swap is better as a device, or not. The re seems to be some unstated architectural philosophy that needs to be stated before any informed decision can be made about what is the right direction to go in. The problem is that swapdev_vp needs to handle VOP_STRATEGY(), and swapdev_vp is incorrectly being pointed at spec_vnops. Here is a proposed (UNTESTED!) clean fix: This is missing a vop_default entry, so it will panic. But as a proof of concept it still stands. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
: :Matthew Dillon wrote: :[..] : And, in anycase, I am not going to spend hours putting together a long : involved patch when a simple short patch suffices. If you want to : spend the time to come up with your own patch (that doesn't screw the : pooch in regards to cluster performance!), then I'm all ears, otherwise : this patch is what is going to go in for the 4.0 release. : :Please hold fire for a bit longer. I have (what I think is) a much cleaner :fix in mind. There is no urgency here, a couple of hours isn't going to :make the slightest difference to the big picture. : :On a side note, as the original author of the changes that lead to this, I :would have thought it would have been appropriate to ask ME directly first :before going public. : :Cheers, :-Peter Your fix looks pretty good, Peter. I'll run it in and test it. I only wish you had come up with it before Poul started going off the deep end. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
This is unwontedly personal and has no place in a public mailing list. Please keep your replies confined to technical content (or your concerns about the lack thereof) and keep always in mind that getting emotional serves only to generate heat when what's needed is light. - Jordan And it undermines even the strongest of technical arguments. -Kip To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DVD driver
I noticed recently (10 minutes ago) that FreeBSD will mount a DVD and I can even look around on it as if it were a regular CD (on -CURRENT). I was wondering if there was any mpeg2 decoder that would play DVD movies. I don't have a hardware decoder the software one looks fine but I'd like to know if anyone has tried to make a software decoder for FreeBSD. Thanks.. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: AgRSkaterq | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problem with PAM-AUTH for XFree86?
Hello, I just got my box up and running Current 12-27. ATA works great for both drives now. However, I compiled XFree86 from the port and I chose the options for RPC, Wraphelp.c, PAM and threads. When I start x (using startkde), I get many many password prompts. I can only assume that the PAM module used for athentication by XFree86 is broken. Is the owner aware of this? I recompiled without PAM support and everything works as expected. Tom Veldhouse [EMAIL PROTECTED]
Problem with PAM-AUTH for XFree86?
Hello, I just got my box up and running Current 12-27. ATA works great for both drives now. However, I compiled XFree86 from the port and I chose the options for RPC, Wraphelp.c, PAM and threads. When I start x (using startkde), I get many many password prompts. I can only assume that the PAM module used for athentication by XFree86 is broken. Is the owner aware of this? I recompiled without PAM support and everything works as expected. Tom Veldhouse [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Make world documentation
Recently someone posted a url that provided a quick run through on some important extra steps to take while doing a make world from -STABLE to -CURRENT, unfortunatly I lost the URL. I was wondering if someone could post it again? I did check the archives, but I wasn't able to find it. Thanks. Regards, Kevin. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world documentation
On Mon, Dec 27, 1999 at 11:23:21PM -0600, Kevin Entringer wrote: Recently someone posted a url that provided a quick run through on some important extra steps to take while doing a make world from -STABLE to -CURRENT, unfortunatly I lost the URL. I was wondering if someone could post it again? I did check the archives, but I wasn't able to find it. http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html Though I though it was supposed to have been moved to the main site, but that's what http://www.freebsd.org/tutorials/ says. -- Brooks P.S. This belonged on -questions. -- "Those who desire to give up freedom in order to gain security, will not have, nor do they deserve, either one" --Thomas Jefferson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPFW
On 27-Dec-99 Emre wrote: Actually I haven't tried -release or -stable...I'm willing to take the chance. I think you will find that you are taking much more of a chance with -current than with -stable. After all -current is allowed to break sometimes, -stable only does it by accident. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with PAM-AUTH for XFree86?
On Mon, Dec 27, 1999 at 11:01:50PM -0600, Thomas T. Veldhouse wrote: Hello, I just got my box up and running Current 12-27. ATA works great for both drives now. However, I compiled XFree86 from the port and I chose the options for RPC, Wraphelp.c, PAM and threads. When I start x (using startkde), I get many many password prompts. I can only assume that the PAM module used for athentication by XFree86 is broken. Is the owner aware of this? I recompiled without PAM support and everything works as expected. Hi! I dunno if this is tooo tricky, but I added a single line to solved the same question as yours. the xserver line... X clive@cartier ~ tail -5 /etc/pam.conf # tricky tricky forgive me xserver authsufficient pam_permit.so no_use # If we don't match anything else, default to using getpwnam(). other authrequiredpam_unix.so try_first_pass other account requiredpam_unix.so try_first_pass X clive@cartier ~ -- CirX Clive Lin [EMAIL PROTECTED] FreeBSD - The Power to Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with PAM-AUTH for XFree86?
I just got my box up and running Current 12-27. ATA works great for = both drives now. However, I compiled XFree86 from the port and I chose = the options for RPC, Wraphelp.c, PAM and threads. When I start x (using = startkde), I get many many password prompts. I can only assume that the = PAM module used for athentication by XFree86 is broken. Is the owner = aware of this? I recompiled without PAM support and everything works as expected. Is your /etc/* up to date? Specifically /etc/pam.conf? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DVD driver
Quoth Kenneth Wayne Culver on Mon, 27 December: : I don't have a hardware decoder the software one looks fine but I'd like to : know if anyone has tried to make a software decoder for FreeBSD. Thanks.. (I'll redirect to multimedia.) I've been trying to build the nist mpeg2player on current lately. It was reported to be working in late October, but I'm not having any luck at the moment because of failures in static initializers in the Regex package -- probably something to do with pthreads, and very much non-trivial to debug, given my vanishingly small understanding of the ever-changing thread model on CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more patch for secondary buffer, polling and DMA emulation in pcm
Seigo Tanimura wrote: Another fix was made on feeding and sucking pcm data. Now chn_wrfeed() and the other functions do not attempt excessive feeding during DMA transfer to eat up the whole processor. The patch is at: http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz Hmmm... this seems to have broken the probe at boot time. Here's a sample of my dmesg: unknown0: ESS ES1868 Plug and Play AudioDrive at port 0x800-0x807 on isa0 unknown1: ESS ES1868 Plug and Play AudioDrive at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 unknown2: ESS ES1868 Plug and Play AudioDrive at port 0x201 on isa0 - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
