Bug in libalias (firewall manipulating)

[Daniel Rock]

Hi,

just noticed:

adding dynamic rules to ipfw via PKT_ALIAS_PUNCH_FW (or the command
"nat punch_fw" in ppp) doesn't work:
For adding firewall rules, IP_FW_ADD requires getsockopt() instead of
setsockopt().

This should also be reflected in the manual page.

Below is my fix and a quick test suggest it is indeed working now.

Daniel

Index: alias_db.c
===
RCS file: /data/cvs/src/lib/libalias/alias_db.c,v
retrieving revision 1.47
diff -u -r1.47 alias_db.c
--- alias_db.c  3 Nov 2001 11:34:09 -   1.47
+++ alias_db.c  26 Nov 2001 03:34:22 -
@@ -2688,6 +2688,7 @@
 PunchFWHole(struct alias_link *link) {
 int r;  /* Result code */
 struct ip_fw rule;  /* On-the-fly built rule */
+int rsz;
 int fwhole; /* Where to punch hole */
 
 /* Don't do anything unless we are asked to */
@@ -2744,19 +2745,21 @@
(Code should be left even if the problem is fixed - it is a
clear optimization) */
 if (rule.fw_uar.fw_pts[0] != 0 && rule.fw_uar.fw_pts[1] != 0) {
-r = setsockopt(fireWallFD, IPPROTO_IP, IP_FW_ADD, &rule, sizeof rule);
+   rsz = sizeof(rule);
+r = getsockopt(fireWallFD, IPPROTO_IP, IP_FW_ADD, &rule, &rsz);
 #ifdef DEBUG
 if (r)
-err(1, "alias punch inbound(1) setsockopt(IP_FW_ADD)");
+err(1, "alias punch inbound(1) getsockopt(IP_FW_ADD)");
 #endif
 rule.fw_src = GetDestAddress(link);
 rule.fw_dst = GetOriginalAddress(link);
 rule.fw_uar.fw_pts[0] = ntohs(GetDestPort(link));
 rule.fw_uar.fw_pts[1] = ntohs(GetOriginalPort(link));
-r = setsockopt(fireWallFD, IPPROTO_IP, IP_FW_ADD, &rule, sizeof rule);
+   rsz = sizeof(rule);
+r = getsockopt(fireWallFD, IPPROTO_IP, IP_FW_ADD, &rule, &rsz);
 #ifdef DEBUG
 if (r)
-err(1, "alias punch inbound(2) setsockopt(IP_FW_ADD)");
+err(1, "alias punch inbound(2) getsockopt(IP_FW_ADD)");
 #endif
 }
 /* Indicate hole applied */

Re: cardbus help

[John McCullough]

Warner Losh wrote:

>In message <[EMAIL PROTECTED]> John McCullough writes:
>: I'd like to get card bus working, however under 5.0-current my pcmcia 
>: controller is failing to load with the message:
>: 
>: pccbb0:  at device 15.0 on pci2
>: pcib2: device pccbb0 requested unsupported memory randge 
>: 0x1000-0x (decoding 0xf400-0xfbff, 0xfff0-0xf)
>: pccbb0: Could not grab register memory
>: 
>: any insight? or will I have the pleasure of tinkering with the kerne?
>
>options PCI_ALLOW_UNSUPPORTED_IO_RANGE
>
>Or fix src/sys/dev/pci/pci_pci.c to properly trim the range.
>
>Warner
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
>
although config wouldn't allow the:
options PCI_ALLOW_UNSUPPORTED_IO_RANGE

I put it in the COPTS and it compiled alright, but now its having 
problems mapping irqs

pcib2: routed slot 15 INTA to irq 255
pccbb: Unable to map IRQ...
panic: resouce_list_release:can't find resource
Debugger("panic")
...

Is this also an issue with pci_pci assigning resouces properly?  Also 
where might I find information on pci<->cardbus behavior if I do find 
time to tinker with the code?

thanks

-johnm



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: patch to support sio with NEWCARD

[Warner Losh]

In message <[EMAIL PROTECTED]> YAMAMOTO
Shigeru writes: 
: I make a patch to support sio with NEWCARD.
: This patch is to avoid ghost interrupt when a PC-Card was removed.
: 
: This patch has one assamption,
:  - all Serial PC-Card have a 16450/16550 compatible interface.

This is a reasonable assumption.  If not, it should be easy to tweak
to return a small negative number so that other device have a chance
at this hardware.

: I tested it on my NotePC and there is no problems.
: Please try it if you have an interest.

I've tried it here too.  From what I can tell in my breif tests, the
interrupt patches aren't strictly required, unless you eject while the
card is busy.  Since bde is the main maintainer for sio, I'll clean
them up a little and run them by him.

The other part of the patch I went ahead and committed.  I've wanted
this for a while now.

This would be an excellent example of how to do, for example, the ata
pccard driver if someone was so inclined.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cardbus help

[Warner Losh]

In message <[EMAIL PROTECTED]> Mike Smith writes:
: This is a bug in the way that the pccbb code allocates the register 
: window when it hasn't been set up.  The "real" fix actually requires the 
: PCI code to configure the cardbus controller, but we don't do that yet 
: (we desperately need to, though).

s/cardbus controller/any device that needs memory and/or I/O addresses
assigned/.

: As a workaround for you, though, try adjusting the memory that the driver 
: requests for the register window to be based at 0xf400.

Actually, for most people, just ignoring the error is enough to make
it work.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cardbus help

[Warner Losh]

In message <[EMAIL PROTECTED]> John McCullough writes:
: I'd like to get card bus working, however under 5.0-current my pcmcia 
: controller is failing to load with the message:
: 
: pccbb0:  at device 15.0 on pci2
: pcib2: device pccbb0 requested unsupported memory randge 
: 0x1000-0x (decoding 0xf400-0xfbff, 0xfff0-0xf)
: pccbb0: Could not grab register memory
: 
: any insight? or will I have the pleasure of tinkering with the kerne?

options PCI_ALLOW_UNSUPPORTED_IO_RANGE

Or fix src/sys/dev/pci/pci_pci.c to properly trim the range.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cardbus help

[Mike Smith]

> I'd like to get card bus working, however under 5.0-current my pcmcia 
> controller is failing to load with the message:
> 
> pccbb0:  at device 15.0 on pci2
> pcib2: device pccbb0 requested unsupported memory randge 
> 0x1000-0x (decoding 0xf400-0xfbff, 0xfff0-0xf)
> pccbb0: Could not grab register memory
> 
> any insight? or will I have the pleasure of tinkering with the kerne?

This is a bug in the way that the pccbb code allocates the register 
window when it hasn't been set up.  The "real" fix actually requires the 
PCI code to configure the cardbus controller, but we don't do that yet 
(we desperately need to, though).

As a workaround for you, though, try adjusting the memory that the driver 
requests for the register window to be based at 0xf400.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: where is the idle_loop in current ?

[Peter Wemm]

Luigi Rizzo wrote:
> Now, the whole problem here seems to be that kernel threads
> are not preemptable, which is something that worries me a
> bit because in CURRENT we use them for interrupt handlers as
> well, and those used to be preemptable (subject to spl masks)
> in RELENG_4.

No, the kernel in general isn't preemptable in that a higher priority
process that becomes runnable will not run until the lower priority
process either blocks, returns to userland, or yields the cpu.

Interrupt threads are special in that they will preempt a process that is
in kernel context.  This is not the same as a higher priority process being
woken up with wakeup().  The problems in vm_zeroidle come from trying
to avoid changing both the mechanism and the work algorithm at the same
time.  The mechanism got switched over, and now it is time to fix the
algorithms to deal with that.  Bruce has written about this elsewhere.

Interrupts still preempt just like on releng_4, but subject to the
&Giant.  Obviously this means that a non-mpsafe interrupt cannot do
anything useful if it interrupts non-mpsafe code as it will immediately
block on &Giant.  Audio is an example of something that *is* mpsafe though
and can preempt just about anything in the kernel, even on another CPU.

The idle processes are special in -current.  What I said about them not
being able to do anything isn't quite correct.  The restriction is that they
cannot, and must not, block.  This means they cannot tsleep or get a mutex.
And since they run outside Giant, that means they cannot go anywhere near
the non-mpsafe parts of the kernel, such as the network stack or drivers.

That means, unfortunately, that you have no choice in -current.  It has to
be and idle priority process.  A side effect of that means that there is no
longer a reason that it cannot be machine independent and SMP safe.

> On the other hand, if preemptable threads are implemented
> (which one of the messages in this thread suggests might
> occur), then things will improve even wrt RELENG_4

It simplifies things a lot.  It means that the ugly hacks to yield the
cpu in things like vm_pagezero can go away entirely.  It makes life a lot
easier for people wanting to do idle priority work.

> On Sun, Nov 25, 2001 at 09:26:51PM +1100, Bruce Evans wrote:
> 
> > Anyway, I think luigi wants the non-process benefits of hacking on the
> > old idle loop.  Sorry, the only way to get these seems to be to upgrade
> > to RELENG_4.
> 
> which, funnily, I have already... This thread came out because in
> order to import my polling stuff in the tree (see my yet-unanswered
> request to -core), having a CURRENT version seems useful to lower
> resistance.

Because we haven't seen the cleaned up, -current version yet. We told you
before that we had issues with the style bugs etc.  We cant give you a
blanket commit approval without seeing it first.

> I don't mind having spent the time for doing it, in the process i
> certainly learned something on the internals of CURRENT, but this
> seems to be about the only useful result of this additional work :)
> 
>   cheers
>   luigi
> --+-
>  Luigi RIZZO, [EMAIL PROTECTED]  . ACIRI/ICSI (on leave from Univ. di Pisa)
>  http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
>  Phone: (510) 666 2927
> --+-
> 
> 

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

patch to support sio with NEWCARD

[YAMAMOTO Shigeru]

Hi all,

I make a patch to support sio with NEWCARD.
This patch is to avoid ghost interrupt when a PC-Card was removed.

This patch has one assamption,
 - all Serial PC-Card have a 16450/16550 compatible interface.

I tested it on my NotePC and there is no problems.
Please try it if you have an interest.

Thanks,
---
YAMAMOTO Shigeru<[EMAIL PROTECTED]>


Index: sys/dev/sio/sio.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/sio/sio.c,v
retrieving revision 1.352
diff -u -r1.352 sio.c
--- sys/dev/sio/sio.c   24 Oct 2001 18:30:04 -  1.352
+++ sys/dev/sio/sio.c   23 Nov 2001 10:41:30 -
@@ -1466,7 +1466,24 @@
com = (struct com_s *)arg;
 
mtx_lock_spin(&sio_lock);
-   siointr1(com);
+   while (!com->gone) {
+   u_int8_tiir = 0;
+
+   iir = inb(com->int_id_port);
+/*
+printf(__FUNCTION__ ":%d: iir = 0x%x\n", __LINE__, iir);
+*/
+   if (iir != 0xFF) {
+   siointr1(com);
+   if ((iir & IIR_IMASK) == IIR_NOPEND) {
+   break;
+   }
+   }
+   else {
+printf(__FUNCTION__ ":%d: maybe, card was remoted\n", __LINE__);
+   break;
+   }
+   }
mtx_unlock_spin(&sio_lock);
 #else /* COM_MULTIPORT */
bool_t  possibly_more_intrs;
@@ -1483,6 +1500,8 @@
do {
possibly_more_intrs = FALSE;
for (unit = 0; unit < sio_numunits; ++unit) {
+   u_int8_tiir = 0;
+
com = com_addr(unit);
/*
 * XXX COM_LOCK();
@@ -1490,8 +1509,9 @@
 */
if (com != NULL 
&& !com->gone
-   && (inb(com->int_id_port) & IIR_IMASK)
-  != IIR_NOPEND) {
+   && ((iir = inb(com->int_id_port)) & IIR_IMASK)
+  != IIR_NOPEND
+   && iir != 0xFF) {
siointr1(com);
possibly_more_intrs = TRUE;
}
@@ -1530,9 +1550,8 @@
}
}
line_status = inb(com->line_status_port);
-
/* input event? (check first to help avoid overruns) */
-   while (line_status & LSR_RCV_MASK) {
+   while ((line_status & LSR_RCV_MASK)) {
/* break/unnattached error bits or real input? */
if (!(line_status & LSR_RXRDY))
recv_data = 0;
@@ -1718,10 +1737,12 @@
}
}
 
+#if0
/* finished? */
 #ifndef COM_MULTIPORT
if ((inb(com->int_id_port) & IIR_IMASK) == IIR_NOPEND)
 #endif /* COM_MULTIPORT */
+#endif
return;
}
 }
Index: sys/dev/sio/sio_pccard.c
===
RCS file: /share/cvsup/FreeBSD/current/usr/src/sys/dev/sio/sio_pccard.c,v
retrieving revision 1.1
diff -u -r1.1 sio_pccard.c
--- sys/dev/sio/sio_pccard.c23 Oct 2001 15:17:33 -  1.1
+++ sys/dev/sio/sio_pccard.c24 Nov 2001 05:29:25 -
@@ -40,18 +40,28 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include 
 
-static int sio_pccard_attach __P((device_t dev));
-static int sio_pccard_detach __P((device_t dev));
-static int sio_pccard_probe __P((device_t dev));
+static int sio_pccard_match__P((device_t self));
+static int sio_pccard_probe__P((device_t self));
+static int sio_pccard_attach   __P((device_t self));
+static int sio_pccard_detach   __P((device_t self));
 
 static device_method_t sio_pccard_methods[] = {
/* Device interface */
-   DEVMETHOD(device_probe, sio_pccard_probe),
-   DEVMETHOD(device_attach,sio_pccard_attach),
+   DEVMETHOD(device_probe, pccard_compat_probe),
+   DEVMETHOD(device_attach,pccard_compat_attach),
DEVMETHOD(device_detach,sio_pccard_detach),
 
+   /* Card interface */
+   DEVMETHOD(card_compat_match,sio_pccard_match),
+   DEVMETHOD(card_compat_probe,sio_pccard_probe),
+   DEVMETHOD(card_compat_attach,   sio_pccard_attach),
+
{ 0, 0 }
 };
 
@@ -61,27 +71,53 @@
sizeof(struct com_s),
 };
 
-static int
-sio_pccard_probe(dev)
-   device_tdev;
-{
+static
+int
+sio_pccard_match(device_t self) {
+   int error = 0;
+   u_int32_t   fcn = PCCARD_FUNCTION_UNSPEC;
+
+   error = pccard_get_function(self, &fcn);
+   if (!error) {
+   switch (fcn) {
+   case PCCARD_FUNCTION_SERIAL:
+   

Re: df -l broken

[Maxime Henrion]

David Wolfskill wrote:
> >Date: Sun, 25 Nov 2001 22:41:01 +0100
> >From: Paul van der Zwan <[EMAIL PROTECTED]>
> 
> >I noticed the -l option of the df command is broken
> 
> That differs from my experience:
> 
> d141[1] df -l
> Filesystem  1K-blocks UsedAvail Capacity  Mounted on
> /dev/ad0s3a158783939195216264%/
> devfs   110   100%/dev
> /dev/ad0s1a158767652608080645%/S1
> /dev/ad0s1e   1871095  1059572   66183662%/S1/usr
> /dev/ad0s2a158767   1039454212171%/S2
> /dev/ad0s2e   1871095   804588   91682047%/S2/usr
> /dev/ad0s3e   1870751  1172006   54908568%/usr
> /dev/ad0s3g   101630358597   876402 6%/var
> /dev/ad0s3h  10277074  5916668  353824163%/common
> procfs  440   100%/proc
> /dev/md10c 520140   24   478508 0%/tmp
[...]

If my patch is exact, then the bug should manifest itself only if there
are no network filesystems mounted.  Do you have any network fs mounted
on your box ?

Thanks,
Maxime Henrion
-- 
Don't be fooled by cheap finnish imitations ; BSD is the One True Code

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: df -l broken

[Maxime Henrion]

Paul van der Zwan wrote:
> 
> I noticed the -l option of the df command is broken. It is supposed to 
> print df for local filesystems but on my system it prints nothing at all.
> I had a quick look at the code , as far as I can tell it uses sysctl to
> figure out the mounted filesystems but thinks all of them are non-local and
> ignores them.
> Using sysctl -a I could not find any entries which looked vaguely like
> describing a mount..
> 
>   Paul

Could you please test the attached patch ?  I did it in a hurry but it
may fix the problem.

Thanks,
Maxime Henrion
-- 
Don't be fooled by cheap finnish imitations ; BSD is the One True Code


Index: df.c
===
RCS file: /home/ncvs/src/bin/df/df.c,v
retrieving revision 1.32
diff -u -r1.32 df.c
--- df.c1 Aug 2001 02:09:09 -   1.32
+++ df.c25 Nov 2001 22:57:49 -
@@ -561,7 +561,8 @@
*strptr = ',';
free(listptr[i]);
}
-   *(--strptr) = NULL;
+   if (i > 0)
+   *(--strptr) = NULL;
 
free(listptr);
return (str);

Re: df -l broken

[David Wolfskill]

>Date: Sun, 25 Nov 2001 22:41:01 +0100
>From: Paul van der Zwan <[EMAIL PROTECTED]>

>I noticed the -l option of the df command is broken

That differs from my experience:

d141[1] df -l
Filesystem  1K-blocks UsedAvail Capacity  Mounted on
/dev/ad0s3a158783939195216264%/
devfs   110   100%/dev
/dev/ad0s1a158767652608080645%/S1
/dev/ad0s1e   1871095  1059572   66183662%/S1/usr
/dev/ad0s2a158767   1039454212171%/S2
/dev/ad0s2e   1871095   804588   91682047%/S2/usr
/dev/ad0s3e   1870751  1172006   54908568%/usr
/dev/ad0s3g   101630358597   876402 6%/var
/dev/ad0s3h  10277074  5916668  353824163%/common
procfs  440   100%/proc
/dev/md10c 520140   24   478508 0%/tmp
d141[2] uname -a
FreeBSD d141.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #182: Sun Nov 25 10:
59:43 PST 2001 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30
W  i386
d141[3] ssh freebeast tail /var/log/cvsup-history.log
CVSup begin from cvsup13.freebsd.org at Wed Nov 21 03:47:15 PST 2001
CVSup ended from cvsup13.freebsd.org at Wed Nov 21 03:53:35 PST 2001
CVSup begin from cvsup14.freebsd.org at Thu Nov 22 03:47:02 PST 2001
CVSup ended from cvsup14.freebsd.org at Thu Nov 22 03:53:07 PST 2001
CVSup begin from cvsup14.freebsd.org at Fri Nov 23 03:47:02 PST 2001
CVSup ended from cvsup14.freebsd.org at Fri Nov 23 03:53:23 PST 2001
CVSup begin from cvsup14.freebsd.org at Sat Nov 24 03:47:06 PST 2001
CVSup ended from cvsup14.freebsd.org at Sat Nov 24 03:53:47 PST 2001
CVSup begin from cvsup14.freebsd.org at Sun Nov 25 03:47:02 PST 2001
CVSup ended from cvsup14.freebsd.org at Sun Nov 25 03:52:57 PST 2001
d141[4]

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

cardbus help

[John McCullough]

I'd like to get card bus working, however under 5.0-current my pcmcia 
controller is failing to load with the message:

pccbb0:  at device 15.0 on pci2
pcib2: device pccbb0 requested unsupported memory randge 
0x1000-0x (decoding 0xf400-0xfbff, 0xfff0-0xf)
pccbb0: Could not grab register memory

any insight? or will I have the pleasure of tinkering with the kerne?

thanks




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: df -l broken

[Joerg Wunsch]

Paul van der Zwan <[EMAIL PROTECTED]> wrote:

> I noticed the -l option of the df command is broken.

Same for "mount -a -t local".  I noticed this has been broken for more
than a year now, maybe two.  I've always been too lazy to investigate
closer.  IIRC, the last FreeBSD versions where it actually worked date
back to 3.x or maybe even 2.2.x.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

df -l broken

[Paul van der Zwan]

I noticed the -l option of the df command is broken. It is supposed to 
print df for local filesystems but on my system it prints nothing at all.
I had a quick look at the code , as far as I can tell it uses sysctl to
figure out the mounted filesystems but thinks all of them are non-local and
ignores them.
Using sysctl -a I could not find any entries which looked vaguely like
describing a mount..

Paul


-- 
I have discovered the art of deceiving diplomats. I tell them the truth
and they never believe me.
-- Camillo Di Cavour



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: Sysinstall is still horribly broken.

[Makoto Matsushita]

matusita> OK, a patch is attached below.

Sorry, forget to add the patch... try again.

If anybody test with boot floppies, available at
http://people.FreeBSD.org/~matusita/5.0-CURRENT-20011121-JPSNAP_usedevfs/,
please let me know your results.

-- -
Makoto `MAR' Matsushita

Index: install.c
===
RCS file: /pub/snapshots/cvsup/FreeBSD.cvs/src/usr.sbin/sysinstall/install.c,v
retrieving revision 1.309
diff -c -r1.309 install.c
*** install.c   20 Oct 2001 09:28:53 -  1.309
--- install.c   21 Nov 2001 02:22:00 -
***
*** 932,938 
}
dialog_clear_norefresh();
msgNotify("Checking integrity of existing %s filesystem.", dname);
!   i = vsystem("fsck -y %s", dname);
if (i)
msgConfirm("Warning: fsck returned status of %d for %s.\n"
   "This partition may be unsafe to use.", i, dname);
--- 932,938 
}
dialog_clear_norefresh();
msgNotify("Checking integrity of existing %s filesystem.", dname);
!   i = vsystem("fsck_ffs -y %s", dname);
if (i)
msgConfirm("Warning: fsck returned status of %d for %s.\n"
   "This partition may be unsafe to use.", i, dname);
***
*** 949,954 
--- 949,967 
msgConfirm("Unable to mount the root file system on %s!  Giving up.", 
dname);
return DITEM_FAILURE | DITEM_RESTORE;
}
+ 
+   dialog_clear_norefresh();
+   msgNotify("Copying initial device files..");
+   /* Copy the boot floppy's dev files */
+   if ((root->newfs || upgrade) && vsystem("find -x /dev | cpio %s -pdum /mnt", 
+cpioVerbosity())) {
+   msgConfirm("Couldn't clone the /dev files!");
+   return DITEM_FAILURE | DITEM_RESTORE;
+   }
+ 
+   /* Mount devfs for other partitions to mount */
+   Mkdir("/mnt/dev");
+   if (!Fake)
+   mount("devfs", "/mnt/dev", 0, NULL);
  }
  
  /* Now buzz through the rest of the partitions and mount them too */
***
*** 962,974 
msgConfirm("No chunk list found for %s!", disk->name);
return DITEM_FAILURE | DITEM_RESTORE;
}
-   if (RunningAsInit && root && (root->newfs || upgrade)) {
-   Mkdir("/mnt/dev");
-   if (!Fake)
-   MakeDevDisk(disk, "/mnt/dev");
-   }
-   else if (!RunningAsInit && !Fake)
-   MakeDevDisk(disk, "/dev");
  
for (c1 = disk->chunks->part; c1; c1 = c1->next) {
if (c1->type == freebsd) {
--- 975,980 
***
*** 983,989 
if (tmp->newfs && (!upgrade || !msgNoYes("You are upgrading - 
are you SURE you want to newfs /dev/%s?", c2->name)))
command_shell_add(tmp->mountpoint, "%s %s/dev/%s", 
tmp->newfs_cmd, RunningAsInit ? "/mnt" : "", c2->name);
else
!   command_shell_add(tmp->mountpoint, "fsck -y %s/dev/%s", 
RunningAsInit ? "/mnt" : "", c2->name);
if (tmp->soft)
command_shell_add(tmp->mountpoint, "tunefs -n enable 
%s/dev/%s", RunningAsInit ? "/mnt" : "", c2->name);
command_func_add(tmp->mountpoint, Mount, c2->name);
--- 989,995 
if (tmp->newfs && (!upgrade || !msgNoYes("You are upgrading - 
are you SURE you want to newfs /dev/%s?", c2->name)))
command_shell_add(tmp->mountpoint, "%s %s/dev/%s", 
tmp->newfs_cmd, RunningAsInit ? "/mnt" : "", c2->name);
else
!   command_shell_add(tmp->mountpoint, "fsck_ffs -y 
%s/dev/%s", RunningAsInit ? "/mnt" : "", c2->name);
if (tmp->soft)
command_shell_add(tmp->mountpoint, "tunefs -n enable 
%s/dev/%s", RunningAsInit ? "/mnt" : "", c2->name);
command_func_add(tmp->mountpoint, Mount, c2->name);
***
*** 1015,1032 
}
  }
  
- if (RunningAsInit) {
-   dialog_clear_norefresh();
-   msgNotify("Copying initial device files..");
-   /* Copy the boot floppy's dev files */
-   if ((root->newfs || upgrade) && vsystem("find -x /dev | cpio %s -pdum /mnt", 
cpioVerbosity())) {
-   msgConfirm("Couldn't clone the /dev files!");
-   return DITEM_FAILURE | DITEM_RESTORE;
-   }
- }
- 
  command_sort();
  command_execute();
  dialog_clear_norefresh();
  return DITEM_SUCCESS | DITEM_RESTORE;
  }
--- 1021,1032 
}
  }
  
  command_sort();
  command_execute();
+ if (rootdev && RunningAsInit) {
+   if (!Fake)
+   unmount("/mnt/dev", MNT_FORCE);
+ }
  dialog_clear_norefresh();
  return DITEM_SUCCESS | DITEM_RESTORE;
  }
Index: boot_crunch.conf
=

Re: where is the idle_loop in current ?

[Luigi Rizzo]

Now, the whole problem here seems to be that kernel threads
are not preemptable, which is something that worries me a
bit because in CURRENT we use them for interrupt handlers as
well, and those used to be preemptable (subject to spl masks)
in RELENG_4.

On the other hand, if preemptable threads are implemented
(which one of the messages in this thread suggests might
occur), then things will improve even wrt RELENG_4

On Sun, Nov 25, 2001 at 09:26:51PM +1100, Bruce Evans wrote:

> Anyway, I think luigi wants the non-process benefits of hacking on the
> old idle loop.  Sorry, the only way to get these seems to be to upgrade
> to RELENG_4.

which, funnily, I have already... This thread came out because in
order to import my polling stuff in the tree (see my yet-unanswered
request to -core), having a CURRENT version seems useful to lower
resistance.

I don't mind having spent the time for doing it, in the process i
certainly learned something on the internals of CURRENT, but this
seems to be about the only useful result of this additional work :)

cheers
luigi
--+-
 Luigi RIZZO, [EMAIL PROTECTED]  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
--+-

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

[PATCH] - categorizing (XXX Lines) in NOTES

[Hiten Pandya]

hi all,

this patch will put an end to those XXX lines in the
NOTES file, which were regarding uncategorized
options.. such as USERCONFIG etc.

PATCH is below...
(start)
*** NOTES.old   Sun Nov 25 12:54:58 2001
--- NOTES   Sun Nov 25 13:11:35 2001
***
*** 292,298 
  #
  # Implement system calls compatible with 4.3BSD and
older versions of
  # FreeBSD.  You probably do NOT want to remove this
as much current code
! # still relies on the 4.3 emulation.
  #
  options   COMPAT_43
  
--- 292,299 
  #
  # Implement system calls compatible with 4.3BSD and
older versions of
  # FreeBSD.  You probably do NOT want to remove this
as much current code
! # still relies on the 4.3 emulation.# XXX - this
doesn't belong here.
! 
  #
  options   COMPAT_43
  
***
*** 420,435 
  #
  options   COMPILING_LINT
  
- 
- # XXX - this doesn't belong here.
- # Allow ordinary users to take the console - this is
useful for X.
- options   UCONSOLE
- 
- # XXX - this doesn't belong here either
- #options  USERCONFIG  #boot -c editor
- #options  INTRO_USERCONFIG#imply -c and show intro
screen
- #options  VISUAL_USERCONFIG   #visual boot -c editor
- 
 
#
  # NETWORKING OPTIONS
  
--- 421,426 
***
*** 1150,1158 
  # EISA, MCA, PCI and pccard are self identifying
buses, so no hints
  # are needed.
  
! #
  # Mandatory devices:
! #
  
  # The keyboard controller; it controls the keyboard
and the PS/2 mouse.
  deviceatkbdc  1
--- 1141,1149 
  # EISA, MCA, PCI and pccard are self identifying
buses, so no hints
  # are needed.
  
!
#--
  # Mandatory devices:
!
#--
  
  # The keyboard controller; it controls the keyboard
and the PS/2 mouse.
  deviceatkbdc  1
***
*** 1189,1194 
--- 1180,1189 
#for some laptops
  options   PSM_RESETAFTERSUSPEND   #reset the device at
the resume event
  
+
#--
+ # Video/Display Related Configuration Options
+
#--
+ 
  # The video card driver.
  devicevga
  hint.vga.0.at="isa"
***
*** 1231,1236 
--- 1226,1238 
  devicestar_saver
  devicewarp_saver
  
+
#--
+ # Console Related Configuration Options
+
#--
+ 
+ # Allow ordinary users to take the console - this is
useful for X.
+ options   UCONSOLE
+ 
  # The pcvt console driver (vt220 compatible).
  devicevt
  hint.vt.0.at="isa"
***
*** 1347,1355 
  deviceacpica
  options   ACPI_DEBUG
  
! #
  # Optional devices:
! #
  
  #
  # SCSI host adapters:
--- 1349,1357 
  deviceacpica
  options   ACPI_DEBUG
  
!
#--
  # Optional devices:
!
#--
  
  #
  # SCSI host adapters:
***
*** 2891,2897 
--- 2893,2905 
  options   PANIC_REBOOT_WAIT_TIME=16
  
 
#
+ # MISCELLENEOUS OPTIONS
  
+ #options  USERCONFIG  #boot -c editor
+ #options  INTRO_USERCONFIG#imply -c and show intro
screen
+ #options  VISUAL_USERCONFIG   #visual boot -c editor
+ 
+
#
  # More undocumented options for linting.
  # Note that documenting these are not considered an
affront.
  
***
*** 2955,2958 
  
  options   VM_KMEM_SIZE
  options   VM_KMEM_SIZE_MAX
! options   VM_KMEM_SIZE_SCALE
--- 2963,2966 
  
  options   VM_KMEM_SIZE
  options   VM_KMEM_SIZE_MAX
! options   VM_KMEM_SIZE_SCALE

---(end)



=
regards,
Hiten Pandya
<[EMAIL PROTECTED]>


MOTD: I just like _pumping_ the daylights out of a
PENGUIN!!!

__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: where is the idle_loop in current ?

[Bruce Evans]

On Fri, 23 Nov 2001, Peter Wemm wrote:

> Luigi Rizzo wrote:
> > My understanding is that idle_loop threads _need_ to give up the cpu
> > because they are special: they must never be in a run queue, and the
> > scheduler knows about them (as a matter of fact, I cannot see where
> > in kern/kern_idle.c a priority is associated to these threads).
>
> No.  In -current, the idle procs ***MUST***NOT*** do anything.

I.e., the unique idle process for each cpu.

A comment in idle_proc() still says otherwise:

>   for (;;) {
>   mtx_assert(&Giant, MA_NOTOWNED);
>
> #ifdef DIAGNOSTIC
>   count = 0;
>
>   while (count >= 0 && procrunnable() == 0) {
> #else
>   while (procrunnable() == 0) {
> #endif
>   /*
>* This is a good place to put things to be done in
>* the background, including sanity checks.
>*/

This is actually a BAD place for doing anything.

>
> If you want to do something at idle, you have to have an idle
> process/thread/whatever.  This is how vm_zeroidle works.  It is
> a process that is on the run queue.

vm_zeroidle is a good example of how not to do things.  Its watermark
stuff makes its idleness not very important.  My version of it wakes
up the pageout daemon a lot (but subject to a watermark) to maintain
a sufficient supply of pages of each color, and I've never noticed
problems (from this) due to the pageout daemon having much higher
priority.  It's the check for whether there is a page worth zeroing
(and whether there is a shortage of pages of some color in my version)
that should be done at idle priority, not the actual zeroing/freeing.
Once committed to zeroing/freeing, it's probably a mistake to d it at
a low priority, since getting switched from and back to work that must
be done won't help.  Things have regressed a bit relative to RELENG_4.
The check for pages to zero used to be done lazily.  Now it is done
in the main path of vm, by calling vm_page_zero_idle_wakeup() from
vm_page_free().  So we are now using an idle process for precisely the
parts of idly zeroing pages that don't need to be done idly.  However,
the watermark stuff limits the damage.

> > But I really do not follow the "safer design" reasoning for
> > vm_zeroidle. It would be much safer not to depend on it to cooperate
> > in the scheduling and be subject to to the regular scheduling policy
> > (i.e. preempt when someone with higher priority becomes ready,
> > or when its quantum is over).
>
> Thats the problem.. We do *not* have preemption in -current right now.
> If it takes 10 seconds to zero all memory, the system will freeze for 10
> seconds while vm_zeroidle runs, even if there is a higher priority process
> on the runqueue.

The watermark stuff limits the damage.  It won't actually zero all memory
since to high watermark is 4/5*cnt.v_free_count.  cnt.v_free_count must
not be very large or the pageout daemon might cause long freezes too.  The
pageout daemon will give up control if it writes to swap; this sort of
corresponds to the pagezero deamon giving up control after every
idlezero_maxrun pages (default 16).

Anyway, I think luigi wants the non-process benefits of hacking on the
old idle loop.  Sorry, the only way to get these seems to be to upgrade
to RELENG_4.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

subscribe

[Neil Houghton]

subscribe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message