Re: -current and pcmcia problems
It seems Warner Losh wrote: In message [EMAIL PROTECTED] Soren Schmidt writes: : Hmm, I'm also having a hell of a time here, on closer inspection it : turns out that my problem is that the kernel allways finds an ed0 : device allthough none is present. I have both an ed0 an ep0 device : in my config as I use both type of cards. So my only interrupt for : pcmcia device is allready taken, and nothing will attach... It sounds like the probe routine for ed improperly is saying the card is there, when in fact it isn't. It shouldn't do that. I noticed that in David O'Brien's dmesg as well. Since I don't have any ne-2000 cards. : Anybody using the ed0 driver with pcmcia and has it working ?? I don't know. Peter Wemm and Matthew Dodd were working on this, but I'm not sure where things stand on it. if_ed is broken in this respect in 1.157, before that it probes right. This doesn't help much as 1.156 doesn't get the interrupt right :( Oh joy... -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VibraX audio broken with newpcm
On Tue, 07 Sep 1999 at 23:19:14 -0700, Jordan K. Hubbard wrote: Using: controller pnp0 devicepcm0 In my kernel and "pnp aware OS" turned both on and off in my BIOS, I get this on probe: pcm0: Vibra16X at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,3 on isa I'm having the same problem, however, I get drq 0,1 rather than 1,3 since I have ppc0 using drq 3. It doesn't work if I take ppc0 off drq 3 either. But just catting a .au file to /dev/audio (yep, MAKEDEV snd0 run previously) results in the cat hanging and no sound. Ditto. Playing mp3s seem to start (i.e., CPU usage goes up but then stops), then it just hangs and gqmpeg/mpg123 needs to be killed. Just for comparison, from a kernel of August 29th using: controller pnp0 devicepcm0 at nexus? port ? irq 5 drq 1 flags 0x13 I get this on probe: CSN 1 Vendor ID: CTL00f0 [0xf0008c0e] Serial 0x Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp Vibra16X sn 0x) at 0x220-0x22f irq 5 drq 1 flags 0x13 on isa That was the last working build for me as well. I've since downgraded to 3.3-RC. Here's the probe from 3.3-RC.. Probing for PnP devices: CSN 1 Vendor ID: CTL00f0 [0xf0008c0e] Serial 0x Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp Vibra16X sn 0x) at 0x220-0x22f irq 9 drq 1 flags 0x10 on isa And here's my kernel config.. controller pnp0 device pcm0 at isa ? port? tty irq 9 drq 1 flags 0x10 Which works fine. I think part of the problem I'm having is that newpcm won't find it on it's actual irq, which is 9 instead of 5. -- - Jim Mock - [EMAIL PROTECTED] - systems administrator - ghis.NET - - work: http://www.ghis.net/ - personal: http://www.ghis.net/~jim/ - - FreeBSD 'zine: http://www.freebsdzine.org/ - [EMAIL PROTECTED] - - The FreeBSD Project -- http://www.FreeBSD.org/ - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
32+ signals: an update
*This is still work in progress*
There's a new set of patches (sources: sep 8, 7am CEST):
o http://www.FreeBSD.org/~marcel/signal/sys_i386.diff
sys/i386/i386, sys/i386/include
o http://www.FreeBSD.org/~marcel/signal/sys_ibcs2.diff
sys/i386/ibcs2
o http://www.FreeBSD.org/~marcel/signal/sys_linux.diff
sys/i386/linux
o http://www.FreeBSD.org/~marcel/signal/sys_kern.diff
sys/kern, sys/sys
o http://www.FreeBSD.org/~marcel/signal/sys_misc.diff
sys/coda, sys/miscfs, sys/nfs
o http://www.FreeBSD.org/~marcel/signal/userland.diff
bin/sh, include, lib/libc, lib/libc_r and more to come...
Changelog:
o sigset_t now accomodates 128 signals
o LINT compiles
o {sig|_}?{set|long}jmp uses new sigset_t
o libc uses new syscalls only
o cpp coredump fixed
o sh coredump fixed
Todo:
o Update {sig|_}?{set|long}jmp now libc_r is fixed.
o Continue fixing userland (games/hack does not compile).
o Alpha port
--
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking Databases http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PNP problems
On Tue, 7 Sep 1999, Randy Bush wrote: I built and installed a new world today. My last make world was some months ago. It seems that the boot loader has changed. Now, my AWE64 soundcard is not detected anymore. My kernel.config looks like this pnp 1 0 os enable port0 0x220 port1 0x330 port2 0x388 irq0 5 drq0 1 drq1 5 pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 This syntax no longer seems to be supported, instead, the following commands may be used: What can I do in order to reenable my soundcard? Please try using the new pcm driver if you are not already. You should be able to do this by having these lines in your kernel config: controller pnp0 device pcm0 Note that you must not have an old-style non-pnp declaration (i.e. device pcm0 at isa? ...) since that currently confuses the pnp system. i am in a similar position. so i did as you say. controller pnp0# PnP support for ISA ... # pcm: Luigi's sound driver #device pcm0 at isa? port ? irq 5 drq 1 flags 0x0 device pcm0 now, although pcm0 shows up in dmesg, i get % xmix Error opening mixer device /dev/mixer: Device not configured and similar whinging. xmix worked before the change. Was the card recognised as pcm1 before? You probably need to go to /dev and type: sh MAKEDEV snd0 -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and pcmcia problems
On Wed, 8 Sep 1999, Soren Schmidt wrote: It seems Warner Losh wrote: In message [EMAIL PROTECTED] Michael Reifenberger writes: : if I do an upgrade to -current on my Tecra8000 the ep* driver stopps working. The ep driver works in -current. : The message from pccardc is that he failed the resouce allocation. Fix the resource allocation error. :-) That's really the only way that you'll be able to fix it. Hmm, I'm also having a hell of a time here, on closer inspection it turns out that my problem is that the kernel allways finds an ed0 device allthough none is present. I have both an ed0 an ep0 device in my config as I use both type of cards. So my only interrupt for pcmcia device is allready taken, and nothing will attach... Anybody using the ed0 driver with pcmcia and has it working ?? I had that too on my Tecra 8000 but I just removed ed0 from the kernel and ep0 started working again. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and pcmcia problems
It seems Doug Rabson wrote: Hmm, I'm also having a hell of a time here, on closer inspection it turns out that my problem is that the kernel allways finds an ed0 device allthough none is present. I have both an ed0 an ep0 device in my config as I use both type of cards. So my only interrupt for pcmcia device is allready taken, and nothing will attach... Anybody using the ed0 driver with pcmcia and has it working ?? I had that too on my Tecra 8000 but I just removed ed0 from the kernel and ep0 started working again. From closer inspection it seems pcmcia support in the if_ed driver has been totally disabled, and the HP probe seems to always find a card now. Lovely :( Could the comitter please fix that, or back out the "checkpoint" of this work in progress, this is an often used device you know... -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and pcmcia problems
On Wed, 8 Sep 1999, Matthew N. Dodd wrote: On Wed, 8 Sep 1999, Soren Schmidt wrote: Hmm, I'm also having a hell of a time here, on closer inspection it turns out that my problem is that the kernel allways finds an ed0 device allthough none is present. I have both an ed0 an ep0 device in my config as I use both type of cards. So my only interrupt for pcmcia device is allready taken, and nothing will attach... Anybody using the ed0 driver with pcmcia and has it working ?? I'll trade you my problem... My kernel never finds a PNP ed0 device when one is present. :) This still happens? I thought it might be caused by the problem in pci.c. What is the logical device id for the card? Does it match properly in ed_isa_probe()? -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and pcmcia problems
It seems Soren Schmidt wrote: It seems Doug Rabson wrote: Hmm, I'm also having a hell of a time here, on closer inspection it turns out that my problem is that the kernel allways finds an ed0 device allthough none is present. I have both an ed0 an ep0 device in my config as I use both type of cards. So my only interrupt for pcmcia device is allready taken, and nothing will attach... Anybody using the ed0 driver with pcmcia and has it working ?? I had that too on my Tecra 8000 but I just removed ed0 from the kernel and ep0 started working again. From closer inspection it seems pcmcia support in the if_ed driver has been totally disabled, and the HP probe seems to always find a card now. Lovely :( Could the comitter please fix that, or back out the "checkpoint" of this work in progress, this is an often used device you know... Just for the reference, going back to 1.156 of if_ed.c makes it work again, I get a single "ed0: device timeout" during the load, but afterwards it work just dandy... -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: repository changes done.
Some "large footprint" changes have been made to the CVS tree and should be nearly finished. In a nutshell: - $Id$ and all other traditional rcs keywords are now preserved and no longer touched by our tools. - $FreeBSD$ is expanded as an alias for $CVSHeader$ (like $Header$ but with the CVSROOT path chopped off). - -ko expansion on certain parts of the tree has been turned off as it's no longer needed to preserve vendor $Id$s. This has a couple of important implications for people pulling down the cvs tree. First, make sure you are fetching at least the src-base collection as this expansion is controlled by CVSROOT/options. Without it, $FreeBSD$ won't get expanded. FYI it looks like this: tag=FreeBSD=CVSHeader tagexpand=iFreeBSD The first line sets the tag alias (ie: $FreeBSD$ is exapanded like $CVSHeader$), and the second line controls the expansion.. it means "i"nclude only $FreeBSD$ in the list of expanded keywords. These changes to cvs and rcs have their roots in code obtained a long time ago from the XFree86 folks. There have been a few hiccups along the way. cvsweb.cgi isn't quite doing the right thing yet, but that will be fixed shortly. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PNP problems
Was the card recognised as pcm1 before? You probably need to go to /dev and type: sh MAKEDEV snd0 indeed, that was the problem. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sb16 not found with newpcm
I thought I'd try kicking sb0 out of my kernel and try pcm for a change, but I cannot get it to work with simply "device pcm0". My sb16 is not pnp, and adding controller pnp0 did not help. With just device pcm0, the kernel mentions nothing of pcm at all. sb0 worked fine with: controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 port 0x0 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 AND pcm does work with: device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15 as someone else suggested on the list. pcm0: SoundBlaster 16 4.11 at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 If dmesg from sb0 would help I could get it.. Anything else I could help with in making "device pcm0" work without params? or is that pnp only? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Latest kernel flop
Not only does the sio device give me trouble, since I don't use it I took it out, and rebuilt the kernel. Immediately upon reboot, I got a kernel panic. It went like this: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Then it panics. What's going on here? Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Latest kernel flop
Not only does the sio device give me trouble, since I don't use it I took it out, and rebuilt the kernel. Immediately upon reboot, I got a kernel panic. It went like this: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Then it panics. What's going on here? Kenneth Culver Oops, did a config -r and fixed the panic, but the sio problem is still there. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sb16 not found with newpcm
Adam McDougall wrote: I thought I'd try kicking sb0 out of my kernel and try pcm for a change, but I cannot get it to work with simply "device pcm0". My sb16 is not pnp, and adding controller pnp0 did not help. With just device pcm0, the kernel mentions nothing of pcm at all. sb0 worked fine with: controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 port 0x0 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 AND pcm does work with: device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15 as someone else suggested on the list. pcm0: SoundBlaster 16 4.11 at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 If dmesg from sb0 would help I could get it.. Anything else I could help with in making "device pcm0" work without params? or is that pnp only? Why you can't be happy with "device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15" if it works? -Max -- "We believe in the Power and the Might!" (Manowar, 1996) Maxim V. Sobolev, Financial Analyst, Vega International Capital Phone: +380-(44)-246-6396 Fax: +380-(44)-220-8715 E-mail: [EMAIL PROTECTED] ICQ: #42290709 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sb16 not found with newpcm
On Wed, 08 Sep 1999 16:53:37 +0300, Maxim Sobolev wrote: Why you can't be happy with "device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15" if it works? I think Adam's just trying to make sure that he hasn't done something silly which is preventing him from using a more graceful configuration than he has to. He hasn't done anything silly, he does have to specify parameters, but it wasn't unreasonable to ask. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sb16 not found with newpcm
pcm0: SoundBlaster 16 4.11 at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 If dmesg from sb0 would help I could get it.. Anything else I could help with in making "device pcm0" work without params? or is that pnp only? Yes, that is for pnp-only. -- we are but packets in the internet of life To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
weird Xfree86 Issue
I can only start my Xfree when ppp is up and running, is that a known problem ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: weird Xfree86 Issue
I can only start my Xfree when ppp is up and running, is that a known problem ? It's known that your DNS setup is busted, yes. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCCARD kernel config update (miibus0)
Hi, I have 'make release' up to the point where it fails building the PCCARD kernel. It needs to have the miibus0 controller added. A patch is attached.. Would someone please commit this? Thanks, john ps: I'm still having problems with the size of the fixit floppy, but currently I've simply removed some of the programs from fixit_crunch.conf such that it completes ok. crunchgen should probably output some size markers. It would make it alot easier to look in previous 'make release' logs and determine at a glance what has grown larger ... FreeBSD(root)/snap/release/usr/src/sys/i386/conf %cvs diff -u PCCARD Index: PCCARD === RCS file: /mirror/ncvs/src/sys/i386/conf/PCCARD,v retrieving revision 1.19 diff -u -r1.19 PCCARD --- PCCARD 1999/08/29 16:58:40 1.19 +++ PCCARD 1999/09/08 18:40:29 @@ -152,6 +152,9 @@ device ppi0# Parallel port interface device #controllervpo0# Requires scbus and da0 +# MII bus support, required for some 10/100 NICs +controller miibus0 + # PCI Ethernet NICs. device al0 # ADMtek AL981 (``Comet'') device ax0 # ASIX AX88140A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCCARD kernel config update (miibus0)
I have 'make release' up to the point where it fails building the PCCARD kernel. It needs to have the miibus0 controller added. A patch is attached.. Would someone please commit this? What a coincidence! I just fixed this! 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
Re: weird Xfree86 Issue
yeah, thanks. - Original Message - From: Mike Smith [EMAIL PROTECTED] To: Tomer Weller [EMAIL PROTECTED] Cc: Current [EMAIL PROTECTED]; Questions [EMAIL PROTECTED] Sent: Wednesday, September 08, 1999 8:34 PM Subject: Re: weird Xfree86 Issue I can only start my Xfree when ppp is up and running, is that a known problem ? It's known that your DNS setup is busted, yes. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Communicator 4 and LDAP
Hi, Has anyone had any luck using communicator with a LDAP server? Both communicator 4.5 and 4.61 fails to connect to any LDAP server that I have tried. It appears that the connect() gets interrupted and not restarted. This happens both under current and 3.0. Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Communicator 4 and LDAP
click on "Communicator" - AddressBook , then on your ldap server: Fill in : Description: User Friendly name for your ldap server LDAP Server: ldap's hostname Server Root: your server root Port Number : the port number where your ldap server is listening to From the address book window you should be able to query the ldap server. Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Communicator 4 and LDAP
Hi, I can't connect to the default ldap servers;however, on my win98 box I can connect to the InfoSpace ldap server. I have a local ldap server here and I can connect to it using netscape with no problem. Try it : rah.star-gate.com port 389 -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Communicator 4 and LDAP
Matthew Reimer wrote: Maybe the code is trying to bind the local side of the socket to port 0x5B? If so, then it could be proved by running Netscape as root. No, 0x5B is the LDAP_CONNECT_ERROR hex value. As I pointed out in the truss earlier a SIGALRM happens that causes connect() to return with a EINTR (which as far as I know it shouldn't and the connect(2) man page does not say that EINTR is a valid error return from connect()). The LDAP library assumes that connect() is restarted by libc if I read this right :-) Lars Matt Amancio Hasty wrote: Don't know what the problem is with netscape. I can search the ldap server with openldap's ldapsearch tool: /usr/local/openldap/bin/ldapsearch -h ldap.infospace.com -b "c=US" "cn=Amancio*" And what do you know I am listed there 8) cn=Amancio Hasty+ [EMAIL PROTECTED]; c=US; o=Amancio Hasty Jr; l=San Franci sco; st=CA; ou= objectclass=Person commonname=Amancio Hasty [EMAIL PROTECTED] cn=Amancio Hasty [EMAIL PROTECTED] surname=Hasty sn=Hasty c=US l=San Francisco st=CA o=Amancio Hasty Jr ou= title= description= postalAddress= telephonenumber= userPassword= userCertificate= givenname=Amancio facsimileTelephoneNumber= -- Amancio Hasty [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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ccd diffs for perusal.
After comments from Phk and Matt..
Particularly I'm looking for someone with a ccd and knowledge of it to
look at these patches, (not big) and see if they do anything of interest..
The theory is to inherrit the blocksizes of the underlying devices up to
the ccd device. I don't have a ccd array so it's a bit hard to test, but
it's more a "I think this is how it might work" sort of thing..
(also it should stop the requirement that ccds be on FFS labelled
partitions)
Anyone care to comment?
(Greg, I think these ideas probably apply to vinum, as well)
Index: ccd.c
===
RCS file: /cvs/freebsd/src/sys/dev/ccd/ccd.c,v
retrieving revision 1.56
diff -c -r1.56 ccd.c
*** ccd.c 1999/09/03 05:16:54 1.56
--- ccd.c 1999/09/09 00:59:47
***
*** 307,313
register int ix;
struct vnode *vp;
size_t minsize;
! int maxsecsize;
struct partinfo dpart;
struct ccdgeom *ccg = cs-sc_geom;
char tmppath[MAXPATHLEN];
--- 307,314
register int ix;
struct vnode *vp;
size_t minsize;
! int maxsecsize, delt;
! u_int partsecsize;
struct partinfo dpart;
struct ccdgeom *ccg = cs-sc_geom;
char tmppath[MAXPATHLEN];
***
*** 330,338
* Verify that each component piece exists and record
* relevant information about it.
*/
! maxsecsize = 0;
minsize = 0;
for (ix = 0; ix cs-sc_nccdisks; ix++) {
vp = ccd-ccd_vpp[ix];
ci = cs-sc_cinfo[ix];
ci-ci_vp = vp;
--- 331,340
* Verify that each component piece exists and record
* relevant information about it.
*/
! maxsecsize = 1;
minsize = 0;
for (ix = 0; ix cs-sc_nccdisks; ix++) {
+ partsecsize = 0;
vp = ccd-ccd_vpp[ix];
ci = cs-sc_cinfo[ix];
ci-ci_vp = vp;
***
*** 377,388
free(cs-sc_cinfo, M_DEVBUF);
return (error);
}
if (dpart.part-p_fstype == FS_BSDFFS) {
! maxsecsize =
! ((dpart.disklab-d_secsize maxsecsize) ?
! dpart.disklab-d_secsize : maxsecsize);
! size = dpart.part-p_size - CCD_OFFSET;
} else {
#ifdef DEBUG
if (ccddebug (CCDB_FOLLOW|CCDB_INIT))
printf("ccd%d: %s: incorrect partition type\n",
--- 379,403
free(cs-sc_cinfo, M_DEVBUF);
return (error);
}
+ size = dpart.part-p_size - CCD_OFFSET;
+ ci-ci_size = size;
if (dpart.part-p_fstype == FS_BSDFFS) {
! partsecsize = dpart.disklab-d_secsize;
! } else if (ci-ci_dev-si_bsize_phys) {
! partsecsize = ci-ci_dev-si_bsize_phys;
! }
! /*
!* All the sector sizes must divide into each other
!* evenly or it can't work.
!*/
! if (partsecsize maxsecsize) {
! delt = partsecsize % maxsecsize;
! maxsecsize = partsecsize;
} else {
+ delt = maxsecsize % partsecsize;
+ }
+
+ if ((partsecsize == 0) || (delt != 0)) {
#ifdef DEBUG
if (ccddebug (CCDB_FOLLOW|CCDB_INIT))
printf("ccd%d: %s: incorrect partition type\n",
***
*** 396,406
return (EFTYPE);
}
! /*
!* Calculate the size, truncating to an interleave
!* boundary if necessary.
!*/
if (cs-sc_ileave 1)
size -= size % cs-sc_ileave;
--- 411,447
return (EFTYPE);
}
! }
!
! /*
!* Don't allow the interleave to be smaller than
!* the biggest component sector.
!* Should be a multiple of maxsecsize.
!* XXX but is maxsecsize a clean multiple of DEV_BSIZE?
!*/
! if ((cs-sc_ileave 0)
! (cs-sc_ileave % (maxsecsize / DEV_BSIZE))) {
! #ifdef DEBUG
! if (ccddebug (CCDB_FOLLOW|CCDB_INIT))
! printf("ccd%d: interleave must be multiple of %d\n",
! ccd-ccd_unit, (maxsecsize / DEV_BSIZE));
! #endif
! while (ci = cs-sc_cinfo) {
! free(ci-ci_path, M_DEVBUF);
! ci--;
! }
!
optional 'make release' speed-up patch
Hi,
The following patch to /usr/src/release/Makefile allows the
specification of the variable FASTCLEAN, which instead of doing
a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of
course, this is only useful if your CHROOTDIR location is a
separate mount point (which mine is: /snap).
Comments and critiques welcome.
Would someone consider committing this please?
Thanks,
John
Index: Makefile
===
RCS file: /mirror/ncvs/src/release/Makefile,v
retrieving revision 1.508
diff -u -r1.508 Makefile
--- Makefile1999/09/07 20:47:42 1.508
+++ Makefile1999/09/09 04:01:37
@@ -152,11 +152,23 @@
.endif
.if make(release)
.if exists(${CHROOTDIR})
+.if defined(FASTCLEAN)
+#
+# Simply umount/newfs/mount the partition where $CHROOTDIR resides.
+# This only works if $CHROOTDIR is a separate mount point.
+#
+ -device=`df | grep '${CHROOTDIR}' | cut -f1 -d' '` \
+ /sbin/umount ${CHROOTDIR} \
+ /sbin/newfs $$device \
+ /sbin/mount ${CHROOTDIR} \
+ /bin/df ${CHROOTDIR}
+.else
# The first command will fail on a handful of files that have their schg
# flags set. But it greatly speeds up the next two commands.
-rm -rf ${CHROOTDIR}
-chflags -R noschg ${CHROOTDIR}/.
-rm -rf ${CHROOTDIR}
+.endif
.endif
-mkdir -p ${CHROOTDIR}
cd ${.CURDIR}/../etc ${MAKE} distrib-dirs DESTDIR=${CHROOTDIR}
Sample output:
%make release CHROOTDIR=/snap TITLE=test CVSROOT=/mirror/ncvs FASTCLEAN=yes
device=`df | grep '/snap' | cut -f1 -d' '` /sbin/umount /snap /sbin/newfs
$device /sbin/mount /snap /bin/df /snap
newfs: /dev/ccd0b: not a character-special device
Warning: 1328 sector(s) in last cylinder unallocated
/dev/ccd0b: 1120 sectors in 2713 cylinders of 1 tracks, 4096 sectors
5425.4MB in 170 cyl groups (16 c/g, 32.00MB/g, 7936 i/g)
super-block backups (for fsck -b #) at:
32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856,
655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680,
...
10616864, 10682400, 10747936, 10813472, 10879008, 10944544, 11010080, 11075616
Filesystem 1K-blocks UsedAvail Capacity Mounted on
/dev/ccd0b53841811 4953446 0%/snap
mkdir -p /snap
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: (P)review: sigset_t for more than 32 signals
John Polstra wrote: If/when you change the size of jmp_buf, please remember to increment __FreeBSD_version in "src/sys/sys/param.h". This is likely to break the Modula-3 threads support (CVSup), and I'll need a way to deal with that. Good one. jmp_buf has indeed changed. Consider it done. Thanks, -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: optional 'make release' speed-up patch
Hi,
The following patch to /usr/src/release/Makefile allows the
specification of the variable FASTCLEAN, which instead of doing
a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of
course, this is only useful if your CHROOTDIR location is a
separate mount point (which mine is: /snap).
Comments and critiques welcome.
And how about a similiar patch to /usr/src/Makefile that is
FASTCLEANDIR that brings back a patched up version of
my original CLEANDIR. Something like
-rm -rf /usr/obj/${.CURDIR}/tmp
chflags -R noschg /usr/obj/${.CURDIR}/tmp
rm -rf /usr/obj/${.CURDIR}
Would someone consider committing this please?
Thanks,
John
Index: Makefile
===
RCS file: /mirror/ncvs/src/release/Makefile,v
...
--
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: optional 'make release' speed-up patch
To me this very much sounds like feature creap. The less options, the better, no one is looking at them anyway. Who says you are doing a build on ufs anyway? It might be something for a FAQ though (if there is one) or for the handbook. Just my 0.01 BEF. Nick The following patch to /usr/src/release/Makefile allows the specification of the variable FASTCLEAN, which instead of doing a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of course, this is only useful if your CHROOTDIR location is a separate mount point (which mine is: /snap). No offense, but this is really pretty ugly for something that I'd anticipate to be a *major* edge case. I've been building releases for years, for example, and I've yet to build one on a filesystem all by itself. I usually just cast around for some space on an existing (shared) fs and go to it, and I suspect that many others are the same way. :-) I'm not saying there shouldn't be a *hook* of some sort for doing "fast cleans", but the patches as they stand add way too much of a delta for only one very specific optimization. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
