IPv6 locking crash (recursion)

[Brian Fundakowski Feldman]

Has anyone else tried out the most basic IPv6 test: ndp -I  and
then ping6 fe80:: extension>? I was
greeted by recursion on a non-recursive lock. After some sleuthing,
I tried to determine what conditions could be tested for that would
indicate "this must not call the nd6_is_addr_neighbor() call because
we're from a normal RTM_RESOLVE initializing a new route", and this
is the most correct thing I can come up with. It actually would do
something entirely different if recursion were allowed. Comments?

Index: nd6.c
===
RCS file: /u/FreeBSD-cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.37
diff -u -r1.37 nd6.c
--- nd6.c   8 Nov 2003 23:36:32 -   1.37
+++ nd6.c   26 Nov 2003 13:45:45 -
@@ -1095,7 +1095,8 @@
 
if (req == RTM_RESOLVE &&
(nd6_need_cache(ifp) == 0 || /* stf case */
-!nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp))) {
+   ((!(rt->rt_flags & RTF_WASCLONED) || rt->rt_flags & RTF_LLINFO) &&
+   !nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp {
/*
 * FreeBSD and BSD/OS often make a cloned host route based
 * on a less-specific route (e.g. the default route).

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

runningbufspace related lock-ups with md(4)/UFS/SU (PATCH ?)

[Brian Fundakowski Feldman]

I'm having problems where the entire system is locking up when using a MD 
UFS+SoftUpdates partition.  I can simply dd if=/dev/zero of=/mnt/foo and in 
a couple tries it will lock up.  When it locks up, buf_daemon (or if that is 
patched against, syncer) is calling waitrunningbufspace() from a non-B_ASYNC 
buf call.  Because of this, the md(4) ("md0") thread is stuck in "ufs" 
waiting to receive a lock on the vnode that one of the syncer/flusher 
daemons has locked, waiting for bufspace to run down.  The user program 
causing the problem is still stuck in "wdrain" because it's also waiting for 
waitrunningbufspace() to return.  In short, everything wants to try to 
reduce the amount of outstanding buffer space, but nothing moves forward 
while GEOM/md(4)/what have you are waiting for the daemons to let go of the 
vnode so they can write out data.
Does this scenario make sense?  I have fixed it here using the following 
very simple patch, which disables the implicit waitrunningbufspace() calls
so the daemons can't get stuck there.

diff -r1.412 vfs_bio.c
73a74,75
> static struct proc *bufdaemonproc;
>
889c891,893
<   waitrunningbufspace();
---
>   if (curthread->td_proc != bufdaemonproc &&
>   curthread->td_proc != updateproc)
>   waitrunningbufspace();
2038,2039d2041
<
< static struct proc *bufdaemonproc;

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

yep, umass still broken

[Brian Fundakowski Feldman]

dc0: Ethernet address: 00:20:78:0f:88:c9
miibus0:  on dc0
ukphy0:  on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
atapci1:  port 
0xb400-0xb4ff,0xb800-0xb803,0xc000-0xc007 irq 2 at device 6.0 on pci2
atapci1: [MPSAFE]
ata2: at 0xc000 on atapci1
ata2: [MPSAFE]
atapci2:  port 
0xa400-0xa4ff,0xa800-0xa803,0xb000-0xb007 irq 2 at device 6.1 on pci2
atapci2: [MPSAFE]
ata3: at 0xb000 on atapci2
ata3: [MPSAFE]
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xa000-0xa07f mem 0xeb00-0xeb7f 
irq 9 at device 8.0 on pci2
xl0: Ethernet address: 00:e0:18:9b:ad:9e
miibus1:  on xl0
ukphy1:  on miibus1
ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fdc0:  port 0x3f7,0x3f2-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
ppbus0:  on ppc0
ppbus0: IEEE1284 device found 
Probing for PnP devices on ppbus0:
lpt0:  on ppbus0
lpt0: Interrupt-driven port
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model MouseMan+, device ID 0
orm0:  at iomem 0xcc000-0xc,0xc-0xc9fff on isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2

Timecounters tick every 1.000 msec
ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, 
logging limited to 100 packets/entry by default
IPsec: Initialized Security Association Processing.
acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0%
GEOM: create disk ad0 dp=0xc239c070
ad0: 76319MB  [155061/16/63] at ata0-master UDMA100
GEOM: create disk ad1 dp=0xc239bd70
ad1: 43979MB  [89355/16/63] at ata1-master UDMA100
acd0: CDROM  at ata2-master PIO4
GEOM: create disk da0 dp=0xc2391c50
SMP: AP CPU #1 Launched!
da0 at umass-sim0 bus 0 target 0 lun 0
da0:  Removable Direct Access SCSI-2 device 
da0: 1.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
(da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): NOT READY asc:3a,0
(da0:umass-sim0:0:0:0): Medium not present
(da0:umass-sim0:0:0:0): Unretryable error
Opened disk da0 -> 6
(da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
(da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI Status: Check Condition
(da0:umass-sim0:0:0:0): NOT READY asc:3a,0
(da0:umass-sim0:0:0:0): Medium not present
(da0:umass-sim0:0:0:0): Unretryable error
Opened disk da0 -> 6
Mounting root from ufs:/dev/ad0s2a
-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

panic: cred/uidinfo botch

[Brian Fundakowski Feldman]

No, that's not the actual panic message, but the one you get isn't very 
useful except to notify you that your uidinfo struct was just freed :)  
Here's my backtrace.  I run an SMP machine, so I'm leaning toward the idea 
this is a race condition.  Am I the first to experience extra uidinfo frees?
I don't think it should be that strange that the uidinfo didn't have many 
extra references lying around, since the credential shared by my processes 
was generally the only thing referencing that entry... but I don't know why 
the cred was getting freed, as there was obviously a lot more than that one 
process running as my user with stock credentials, but uihashtbl[] 
definitely showed that all information relevant to my uid was freed.

#0  doadump () at ../../../kern/kern_shutdown.c:239
#1  0xc019d720 in boot (howto=0x104) at ../../../kern/kern_shutdown.c:371
#2  0xc019d9d9 in panic () at ../../../kern/kern_shutdown.c:542
#3  0xc02e6b4b in trap_fatal (frame=0xd76e7b0c, eva=0x0) at 
../../../i386/i386/trap.c:843
#4  0xc02e6802 in trap_pfault (frame=0xd76e7b0c, usermode=0x0, eva=0x1a0) at 
../../../i386/i386/trap.c:757
#5  0xc02e6379 in trap (frame={tf_fs = 0x18, tf_es = 0x10, tf_ds = 0x10, tf_edi = 
0xc291fe10, tf_esi = 0xc030f532, tf_ebp = 0xd76e7b4c, tf_isp = 0xd76e7b38, tf_ebx = 
0x1a0, tf_edx = 0x1a0, tf_ecx = 0x0, tf_eax = 0x1a0, tf_trapno = 0xc, tf_err = 0x0, 
tf_eip = 0xc01fd0a8, tf_cs = 0x8, tf_eflags = 0x10246, tf_esp = 0xd76e7c14, tf_ss = 
0xc01b932c}) at ../../../i386/i386/trap.c:444
#6  0xc02cf788 in calltrap () at {standard input}:97
#7  0xc01b932c in kvprintf (fmt=0xc030f532 " @ %s:%d", func=0xc01b8d00 
, arg=0xd76e7c30, radix=0xa, ap=0xd76e7c74 "Òü0À¬\003") at 
../../../kern/subr_prf.c:668
#8  0xc01b8c7e in vsnprintf (str=0xc03720c0 "page fault", size=0x0, format=0x0, 
ap=0x0) at ../../../kern/subr_prf.c:413
#9  0xc019d947 in panic (fmt=0xd76e7c30 "Ù 7Àç") at ../../../kern/kern_shutdown.c:509
#10 0xc0194123 in _mtx_lock_flags (m=0x0, opts=0x0, file=0xc030fcd2 
"../../../kern/kern_resource.c", line=0x3ac) at ../../../kern/kern_mutex.c:333
#11 0xc019c86d in uifree (uip=0x3ac) at ../../../kern/kern_resource.c:940
#12 0xc019a5f1 in crfree (cr=0xc030fcd2) at ../../../kern/kern_prot.c:1725
#13 0xc019a885 in cred_update_thread (td=0xc291fe10) at ../../../kern/kern_prot.c:1832
#14 0xc02e6c31 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x805a08e, tf_esi = 0x806a092, tf_ebp = 0xbfbff4e8, tf_isp = 0xd76e7d74, tf_ebx = 
0xbfbff3b0, tf_edx = 0x10, tf_ecx = 0x805a0a1, tf_eax = 0xbc, tf_trapno = 0x0, tf_err 
= 0x2, tf_eip = 0x2821bd93, tf_cs = 0x1f, tf_eflags = 0x282, tf_esp = 0xbfbff2ec, 
tf_ss = 0x2f}) at ../../../i386/i386/trap.c:960
#15 0xc02cf7dd in Xint0x80_syscall () at {standard input}:139

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

fincore.c strikes again (panic bremfree: bp not locked)

[Brian Fundakowski Feldman]

I don't have any more info since for some reason the kernel wasn't saved 
when my system dumped core, but yet again fincore.c causes evidence that 
-CURRENT has regressed again.  I can't find the old thread I'm thinking of, 
but from a slightly different thread, bde knew what was going on.  For 
further reference:


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/*
** print pages of file in core
*/

void usage(char *name)
{
printf("Usage: %s [-ns] files...\n",name);
printf("\t-n\t\tDo not print filename\n");
printf("\t-o\t\tOnly print files with at least one page in core\n");
printf("\t-s\t\tDo not print file size in pages\n");
}

main(int ac,char **av)
{
int c;
int print_name = 1;
int print_sizepages = 1;
int only_nonzero = 0;
int status = 0;

while((c = getopt(ac,av,"nos")) != -1) {
switch(c) {
case 'n':
print_name = 0;
break;
case 'o':
only_nonzero = 1;
break;
case 's':
print_sizepages = 0;
break;
default:
usage(av[0]);
exit(1);
}
}
for(; optind < ac ; optind++) {
int fd;
int pind,pcount;
caddr_t addr;
struct stat statbuf;
size_t len;
size_t numpages;
char *pvec;

if (stat(av[optind],&statbuf)) {
perror("stat");
status = 1;
continue;
}
if (!S_ISREG(statbuf.st_mode)) {
close(fd);
continue;
}
if ((fd = open(av[optind],O_RDONLY)) < 0) {
perror(av[optind]);
status = 1;
continue;
}
if (fstat(fd,&statbuf)) {
perror("fstat");
close(fd);
status = 1;
continue;
}
if (!S_ISREG(statbuf.st_mode)) {
close(fd);
continue;
}
len = statbuf.st_size;
numpages = len/PAGE_SIZE + ((len % PAGE_SIZE) != 0);

if (! (statbuf.st_mode & (S_IFREG|S_IFCHR))) {
pcount = 0;
} else if (len) {
if ((addr = mmap(0,len,PROT_READ,MAP_SHARED,fd,0)) == 
MAP_FAILED) {
fprintf(stderr, "mmap (%s): %s\n", av[optind],
strerror(errno));
close(fd);
status = 1;
continue;
}
pvec = malloc(numpages);
if (mincore(addr,len,pvec))
{
perror("mincore");
exit(1);
}
for(pcount = 0,pind = 0 ; pind < numpages ; pind++) {
if (pvec[pind]) pcount++;
}
free(pvec);
if (munmap(addr,len)) {
perror("munmap");
exit(1);
}
} else {
pcount = 0;
}
if (pcount || !only_nonzero) {
if (print_name) printf("%s: ",av[optind]);
printf("%d",pcount);
        if (print_sizepages) printf("/%d",numpages);
printf("\n");
}
close(fd);
}
exit(status);
}

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

UFS2 extended attribute corruption woes

[Brian Fundakowski Feldman]

(stand_alone)
ffs_close_ea(ap->a_vp, 0, ap->a_cred, ap->a_td);
-   return(ENOATTR);
+   return (error);
}
-    if (olen == -1) {
+if (error == ENOATTR) {
/* new, append at end */
p = eae + easize;
easize += ealength;


-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Brian Fundakowski Feldman]

I can't get more info because crash dumps don't work when this happens, but 
for what it's worth, here's a traceback which shows what happens when I 
attempt to use my da0:  Removable Direct Access
SCSI-2 device on an OHCI-based controller.  This was working just a few days 
ago with a UHCI controller, so ...

The crash is from an invalid read at 0xbff3e000, which is PTmap plus some
offset. The trace as far as I can get it, from a kernel with USB but no
"options" 
enabled, would be:

ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe)
ohci_device_bulk_start+0x0d
ohci_device_bulk_transfer+0x27
usbd_transfer+0xc0
umass_setup_transfer+0x4f
umass_bbb_state
usb_transfer_complete
ohci_softintr

Can anyone confirm if this is normal or I have an exceptional system?  I 
have two completely unrelated OHCI-based controllers in my system and 
neither works.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

vnode locking screwed up in src/sys/ufs/ffs/ffs_snapshot.c:ffs_snapshot()

[Brian Fundakowski Feldman]

I got a crash today because "xvp" did not have an interlock when the
call was made to vn_lock(LK_INTERLOCK):
407 if (snapdebug)
408 vprint("ffs_snapshot: busy vnode", xvp);
409 if (vn_lock(xvp, LK_EXCLUSIVE | LK_INTERLOCK, td) != 0)
410 goto loop;
411 xp = VTOI(xvp);
412

I don't in fact see any reason why "xvp" would have been locked already
and that this could possibly be valid in the face of a mountpoint which
had any vnodes at all open.  This occurred on fscking my "/tmp"
filesystem because of crashes (due to an SSE utilization bug in the
kernel, it seems), which I'm sure was a filesystem in heavy use already.

Does anyone have any insight on what the correct fix to this is?  I
don't have any idea exactly how to correct the locking in this function.
Thanks for insight!

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

USB detach crashes possibly fixed

[Brian Fundakowski Feldman]

Please try this change (already committed to -CURRENT) and let me know if 
crashes due to detaching USB devices specifically have been eliminated.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb.c.diff?r1=1.54&r2=1.55&f=h

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''''''''''\
  <> [EMAIL PROTECTED]  <> [EMAIL PROTECTED]  \  The Power to Serve! \
 Opinions expressed are my own.   \,,\



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

CD sysinstall broken (fix)

[Brian Fundakowski Feldman]

Sysinstall via the CD media (and probably other physical disc mediums) is 
broken currently due to the devfs filesystem not being available at all 
times in placesw here it is needed.  I've changed the behavior in my 
green_lomac branch to fix this, and would like if other people would verify 
this indeed fixes the problem for them as well (I imagine it does) and does 
what it should be expected to (which I also think it does).

Does this logic appear to be flawed in any cases?  If all seems right, I 
shall commit this to -CURRENT to unbreak CD installs.

 //depot/user/green/lomac/usr.sbin/sysinstall/dist.c#2 (text+ko) 

@@ -35,6 +35,8 @@
  */
 
 #include "sysinstall.h"
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -544,7 +546,7 @@
 static Boolean
 distExtract(char *parent, Distribution *me)
 {
-int i,j, status, total, intr;
+int i,j, status, total, intr, unmounted_dev;
 int cpid, zpid, fd2, chunk, numchunks;
 char *path, *dist, buf[30];
 const char *tmp;
@@ -684,6 +686,12 @@
total = 0;
(void)gettimeofday(&start, (struct timezone *)0);
 
+   if (me[i].my_bit == DIST_BIN && RunningAsInit && !Fake) {
+   unmounted_dev = 1;
+   unmount("/dev", MNT_FORCE);
+   } else
+   unmounted_dev = 0;
+
/* We have one or more chunks, initialize unpackers... */
mediaExtractDistBegin(root_bias(me[i].my_dir), &fd2, &zpid, &cpid);
 
@@ -810,6 +818,10 @@
*(me[i].my_mask) &= ~(me[i].my_bit);
else
continue;
+   if (unmounted_dev) {
+   (void)mount("devfs", "/dev", 0, NULL);
+   unmounted_dev = 0;
+   }
 }
 properties_free(dist_attr);
 sigaction(SIGINT, &old, NULL); /* Restore signal handler */

 //depot/user/green/lomac/usr.sbin/sysinstall/install.c#2 (text+ko) 

@@ -812,6 +812,8 @@
/* BOGON #1: Resurrect /dev after bin distribution screws it up */
dialog_clear_norefresh();
msgNotify("Remaking all devices.. Please wait!");
+   if (!Fake)
+   (void)unmount("/dev", MNT_FORCE);
if (vsystem("cd /dev; sh MAKEDEV all")) {
msgConfirm("MAKEDEV returned non-zero status");
return DITEM_FAILURE | DITEM_RESTORE;
@@ -1070,8 +1072,6 @@
 
 command_sort();
 command_execute();
-if (!mountfailed && !Fake)
-   unmount("/mnt/dev", MNT_FORCE);
 dialog_clear_norefresh();
 return DITEM_SUCCESS | DITEM_RESTORE;
 }


-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

CD-ROM installation of -CURRENT broken?

[Brian Fundakowski Feldman]

Does anyone know when installation of -CURRENT from CD-ROM got broken or a 
solution thereof?  We end up having two problems: the fixit shell doesn't 
work, but before that an actual installation doesn't work because 
sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT.  I havne't 
determined yet why this could be; anyone have clues?

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

can't write CD-Rs with or without new DAO mode

[Brian Fundakowski Feldman]

After updating my system I can't burn CD-Rs successfully.  Can anyone else?  
What happens is pretty simple:

{"/home/green/toxicity"}$ burncd -s 8 -d audio /dev/null $(ls | trackclassify >
burncd: ioctl(CDRIOCINITWRITER): Input/output error
acd0: MODE_SELECT_BIG - ILLEGAL REQUEST asc=0x26 ascq=0x00 error=0x00

The specific hardware is:

atapci0:  port 0xa000-0xa00f at device 7.1 on pci0
acd0: CD-RW  at ata0-master WDMA2

I'd provide more info if I had it.  Using atacontrol to stick the CD-ROM 
drive in PIO mode doesn't help, nor does the "reinit" command.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

quick informal survey: OpenSSH broken?

[Brian Fundakowski Feldman]

I need to know, if OpenSSH is ever going to get MFC'ed, are there any people 
currently running OpenSSH 2.9 from -CURRENT's base and getting major 
problems with it?  Or even minor ones that actually make things more 
difficult?  I want to have no real outstanding issues, except simple ones 
like Protocol being set to 2,1 by default (which is a reasonable default 
nowadays), before I MFC OpenSSH, because I really don't want to leave anyone 
screwed over in the process.

So let me know, ASAP, what problems you all are having with OpenSSH in 
-CURRENT, specifically in the FreeBSD-specific parts.  I'm also not certain 
of KRB4 and KRB5 auth still both work properly, and need that verified.
Thanks, everybody.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

VM bug

[Brian Fundakowski Feldman]

I've run into what I thought was an ffs bug but really is a VM bug
after poking past the surface.  I don't know what to do past what is
here.  Maybe we need more invariants?

(kgdb) bt
#0  boot (howto=0x100) at ../../kern/kern_shutdown.c:303
#1  0xc01669a9 in panic (fmt=0xc0281a20 "vm_page_free: freeing free page") at 
../../kern/kern_shutdown.c:553
#2  0xc021b389 in vm_page_free_toq (m=0xc0535f70) at ../../vm/vm_page.c:1076
#3  0xc021b0be in vm_page_alloc (object=0xd079a900, pindex=0x19d0, page_req=0x0) at 
../../vm/vm_page.h:523
#4  0xc01930dc in allocbuf (bp=0xc37152c0, size=0x2000) at ../../kern/vfs_bio.c:2467
#5  0xc0192c86 in getblk (vp=0xd03d79c0, blkno=0xce8, size=0x2000, slpflag=0x0, 
slptimeo=0x0)
at ../../kern/vfs_bio.c:2247
#6  0xc01fde1d in ffs_balloc (ap=0xd0428e2c) at ../../ufs/ffs/ffs_balloc.c:313
#7  0xc02097c1 in ffs_write (ap=0xd0428e6c) at vnode_if.h:1077
#8  0xc01a09e7 in vn_write (fp=0xc13bb440, uio=0xd0428edc, cred=0xc0ec5e00, flags=0x0, 
p=0xd031bbe0) at vnode_if.h:363
#9  0xc01782dd in dofilewrite (p=0xd031bbe0, fp=0xc13bb440, fd=0x5, buf=0x8061000, 
nbyte=0x7770, 
offset=0x, flags=0x0) at ../../sys/file.h:157
#10 0xc01781c3 in write (p=0xd031bbe0, uap=0xd0428f80) at ../../kern/sys_generic.c:310
#11 0xc024b0a9 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x8061000, tf_esi = 0x7770, 
  tf_ebp = 0xbfbff894, tf_isp = 0xd0428fd4, tf_ebx = 0x0, tf_edx = 0x0, tf_ecx = 
0x4ec, tf_eax = 0x4, 
  tf_trapno = 0x7, tf_err = 0x2, tf_eip = 0x8054d84, tf_cs = 0x1f, tf_eflags = 
0x297, tf_esp = 0xbfbff868, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1150
#12 0xc023f0f5 in Xint0x80_syscall ()
#13 0x8048998 in ?? ()
#14 0x80496b3 in ?? ()
#15 0x8048efd in ?? ()
#16 0x8048139 in ?? ()
(kgdb) frame 2
#2  0xc021b389 in vm_page_free_toq (m=0xc0535f70) at ../../vm/vm_page.c:1076
1076panic("vm_page_free: freeing free page");
(kgdb) printf "%d %d\n", m->queue, m->pc
102 101

Anyone know where to go from here?  I don't think there's anything
that could have fixed it in the meantime...

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

ffs panic

[Brian Fundakowski Feldman]

Has anyone seen this one?  It's not like this is one of the one's its
really possible to reasonably debug :-(

#0  boot (howto=0x100) at ../../kern/kern_shutdown.c:303
#1  0xc01669a9 in panic (fmt=0xc0281a20 "vm_page_free: freeing free page") at 
../../kern/kern_shutdown.c:553
#2  0xc021b389 in vm_page_free_toq (m=0xc0535f70) at ../../vm/vm_page.c:1076
#3  0xc021b0be in vm_page_alloc (object=0xd079a900, pindex=0x19d0, page_req=0x0) at 
../../vm/vm_page.h:523
#4  0xc01930dc in allocbuf (bp=0xc37152c0, size=0x2000) at ../../kern/vfs_bio.c:2467
#5  0xc0192c86 in getblk (vp=0xd03d79c0, blkno=0xce8, size=0x2000, slpflag=0x0, 
slptimeo=0x0)
at ../../kern/vfs_bio.c:2247
#6  0xc01fde1d in ffs_balloc (ap=0xd0428e2c) at ../../ufs/ffs/ffs_balloc.c:313
#7  0xc02097c1 in ffs_write (ap=0xd0428e6c) at vnode_if.h:1077
#8  0xc01a09e7 in vn_write (fp=0xc13bb440, uio=0xd0428edc, cred=0xc0ec5e00, flags=0x0, 
p=0xd031bbe0) at vnode_if.h:363
#9  0xc01782dd in dofilewrite (p=0xd031bbe0, fp=0xc13bb440, fd=0x5, buf=0x8061000, 
nbyte=0x7770, 
offset=0x, flags=0x0) at ../../sys/file.h:157
#10 0xc01781c3 in write (p=0xd031bbe0, uap=0xd0428f80) at ../../kern/sys_generic.c:310
#11 0xc024b0a9 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x8061000, tf_esi = 0x7770, 
  tf_ebp = 0xbfbff894, tf_isp = 0xd0428fd4, tf_ebx = 0x0, tf_edx = 0x0, tf_ecx = 
0x4ec, tf_eax = 0x4, 
  tf_trapno = 0x7, tf_err = 0x2, tf_eip = 0x8054d84, tf_cs = 0x1f, tf_eflags = 
0x297, tf_esp = 0xbfbff868, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1150
#12 0xc023f0f5 in Xint0x80_syscall ()
#13 0x8048998 in ?? ()
#14 0x80496b3 in ?? ()
#15 0x8048efd in ?? ()
#16 0x8048139 in ?? ()

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: reducing sbsize: lost count, uid = 1001

[Brian Fundakowski Feldman]

On Sun, 27 Aug 2000, John Polstra wrote:

> In article <[EMAIL PROTECTED]>,
> Brian Fundakowski Feldman  <[EMAIL PROTECTED]> wrote:
> > If this is a problem with sbsize, this should take care of any possibility
> > ever of there being a problem...
> 
> I tried your patch, but it panics reliably on start-up:

Woops, I have the KASSERT bungled up.  Please change
KASSERT(to < *hiwat && uip != NULL,
to
    KASSERT(to >= *hiwat || uip != NULL,

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: reducing sbsize: lost count, uid = 1001

[Brian Fundakowski Feldman]

error = 0;
struct unpcb *unp = sotounpcb(so);
struct socket *so2;
+   u_long newhiwat;
 
if (unp == 0) {
error = EINVAL;
@@ -342,10 +345,10 @@
so->so_snd.sb_mbmax -=
so2->so_rcv.sb_mbcnt - unp->unp_conn->unp_mbcnt;
unp->unp_conn->unp_mbcnt = so2->so_rcv.sb_mbcnt;
-   so->so_snd.sb_hiwat -=
-   so2->so_rcv.sb_cc - unp->unp_conn->unp_cc;
-   (void)chgsbsize(so->so_cred->cr_uid,
-   (rlim_t)unp->unp_conn->unp_cc - so2->so_rcv.sb_cc, RLIM_INFINITY);
+   newhiwat = so->so_snd.sb_hiwat -
+   (so2->so_rcv.sb_cc - unp->unp_conn->unp_cc);
+   (void)chgsbsize(so->so_cred->cr_uid, &so->so_snd.sb_hiwat,
+   newhiwat, RLIM_INFINITY);
unp->unp_conn->unp_cc = so2->so_rcv.sb_cc;
sorwakeup(so2);
m = 0;
Index: sys/proc.h
===
RCS file: /usr2/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.107
diff -u -r1.107 proc.h
--- sys/proc.h  2000/07/11 22:07:53 1.107
+++ sys/proc.h  2000/08/26 23:31:17
@@ -422,7 +423,7 @@
 extern struct vm_zone *proc_zone;
 
 intchgproccnt __P((uid_t uid, int diff, int max));
-intchgsbsize __P((uid_t uid, rlim_t diff, rlim_t max));
+intchgsbsize __P((uid_t uid, u_long *hiwat, u_long to, rlim_t max));
 intenterpgrp __P((struct proc *p, pid_t pgid, int mksess));
 void   fixjobc __P((struct proc *p, struct pgrp *pgrp, int entering));
 intinferior __P((struct proc *p));

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: cvs commit: src/secure/lib/libcrypto Makefile Makefile.inc

[Brian Fundakowski Feldman]

On Thu, 24 Aug 2000, Nickolay Dudorov wrote:

>   I usually run 'make -j32 buildworld' on my current
> system. After this commit I can not do this. The next patch
> permits to use '-j32' again.

Since it can't really break things to do so, I added it :)  Thanks.

>   N.Dudorov

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: reducing sbsize: lost count, uid = 1001

[Brian Fundakowski Feldman]

Try making them small critical sections.  If it makes it easier,
which it probably will, try this: pass the pointer to sb_hiwat as an
argument to chgsbsize and make that the only way to modify it (sockbuf
creation would have to be a place where it's initialized manually to
0 ;) I'd say stick the hiwat increment of delta at the end, after
malloc, since that would place it in the same context as the setting.

Luckily, doing this right would be making the code clearer in several
of the (few) places sb_hiwat is used.  We just have to assure that
sb_hiwat is always consistent with the ui_sbsize which can be done with
a critical section that "knows" the delta to apply and where to apply
it.

Using splimp() should not be necessary as that is used for mbuf
protection, which is why network card drivers' interrupts must be
called at splimp() (an aggregate mask which includes splnet()): they
need to not corrupt the mbuf subsystem.  Plus, it makes a convenient
critical section for the network drivers in this way :)

At least, this is how I learned it to be.  I'm not sure if it's
absolutely correct, but it should be.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: reducing sbsize: lost count, uid = 1001

[Brian Fundakowski Feldman]

On Wed, 23 Aug 2000, Alfred Perlstein wrote:

> * Alfred Perlstein <[EMAIL PROTECTED]> [000823 14:29] wrote:
> > 
> > I have a feeling that this is related to missing spl protection around
> > the chgsbsize subsystem, this was probably an issue before I touched it
> > but since I touched it last I'll have a look-see.
> > 
> > Brian, does that makes sense?
> [...]
> 
> Does it make sense to wrap chgsbsize with spl so callers don't have
> to worry about it?
> 

Yeah, I say to go for it.  I was /certain/ that these functions had
the right spl()s before; if the patch fixes jdp's problem, I can't see
a good reason not to change it, other than it would hide what may be
quite problematic for other reasons even if not for that one...

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: make buildworld br0ken in libutil

[Brian Fundakowski Feldman]

On Tue, 22 Aug 2000, Garrett Wollman wrote:

> <<[EMAIL PROTECTED]> said:
> 
> > -On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote:
> >> Brian, I'm afraid you broke libutil... Every program using libutil now must
> >> depend on libcrypt too.
> 
> No.  This is precisely why shared libraries have dependencies.  For
> static linking, what Brian has done Just Works.  For dynamic linking,
> libutil needs to depend on libcrypt to get its symbols resolved.
> (Alternatively you might be able to do it with weak symbols.)

Further, I cannot see how the make world _could_ be broken!  This is
strange, since I've never had the problem at all and have tested this
change in several places (5.0 and 4.1).

{"/home/green"}$ objdump --all-headers /usr/lib/libutil.so | grep NEEDED
/usr/libexec/elf/objdump: /usr/lib/libutil.so: no symbols
  NEEDED  libcrypt.so.2

> -GAWollman

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Why no CDR ioctls for SCSI cds?

[Brian Fundakowski Feldman]

One thing that's missing is the ioctl CDRIOCSETBLOCKSIZE.  It would
be _really_ nice if cd(4) supported that ioctl so I could just seek
and read from a CD.  I had knu trying out my read_cd program, and it
doesn't work for SCSI CD-ROMs, seemingly because of this issue :(

Would you be adverse to implementeing that ioctl?

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Anyone have newmidi working?

[Brian Fundakowski Feldman]

Newmidi doesn't seem to work.  The oplsbc device handling had to be
hacked a bit to support non-PnP SBs, but that's inconsequential.
It probes and boots fine.  It seems that newmidi is completely
disconnected from actually being able to work.

I haven't gotten any response from the author :-(  Does anyone have it
working?  I don't see how it could with the current state of the code.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: crypt(3) problems

[Brian Fundakowski Feldman]

On Wed, 9 Aug 2000, Pete Carah wrote:

> > We should switch to using just libdescrypt and being allowed to switch
> > crypt formats easily between md5 and des.  My proposed solution using
> > login.conf is at http://people.FreeBSD.org/~green/crypt_switching.patch,
> > and it's going to be put into production usage relatively soon (that is,
> > whether or not it's actually in FreeBSD).
> 
> As long as things get switched around so that the format decision is 
> external to libdescrypt and the existing password, so we can change an existing
> des passwd to md5.  However, in our case, apache still needs to
> generate des but *all* other uses want md5.  The link choice is the
> easiest way to select this, with environment next.  Config files won't
> really work since they can't anticipate all uses.

Well, first of all assume that by default DES-based scheme is what
crypt() uses.

> The full-blown pam implementations do it with pam parameters; login.conf
> is fine but won't work for "third-party" situations like I was commenting
> on (i.e. apache needs to accept and generate des but most other need 
> md5, etc etc)...  Perhaps an environment variable?

PAM still needs support from the crypt() library.  There's not going to
be a way to do it without a proper interface to the crypt library :-/
Right now there is
int crypt_set_format(const char *format);

This wouldn't be thread-safe to change formats, but crypt() isn't thread
safe in the slightest bit anyway, by design.

> libdescrypt is close since it will accept either; a fixed choice for
> what it generates, external to *any* application code (e.g. environment 
> vars (easiest) or (if possible) config files that are somehow *completely* 
> universal (I don't see how to do this without application mods unless the 
> library can transparently get at argv[0] independently of what the app does 
> like ++argv, etc)) would be nice.

You really cannot do this properly.  It's best just to do what it takes
to get the right format on a given platform.  On FreeBSD now, that's use
libdescrypt and crypt() with a normal salt, or to get MD5 use a salt
with the "$1$" format.  On FreeBSD with the changes I have, you call
e.g. crypt_set_format("md5") and then crypt() with a generic salt.

> -- Pete

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: crypt(3) problems

[Brian Fundakowski Feldman]

We should switch to using just libdescrypt and being allowed to switch
crypt formats easily between md5 and des.  My proposed solution using
login.conf is at http://people.FreeBSD.org/~green/crypt_switching.patch,
and it's going to be put into production usage relatively soon (that is,
whether or not it's actually in FreeBSD).

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: cvs commit: src/sys/sys select.h

[Brian Fundakowski Feldman]

On Sun, 6 Aug 2000, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> Brian 
>Fundakowski Feldman writes:
> : I knew something like this would happen and we'd catch some improperly
> : written software.  Thanks :)
> 
> No offense, but if you knew this was going to happen, why didn't you
> do a make buildworld first?

There are only three choices.  One is to break some of the software.
Another is to break some other amount of the software.  The other is
to make our headers even more totally horrid than they are now, but
still tenuously allowing "all" of the software to work, no matter how
wrong it is.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: cvs commit: src/sys/sys select.h

[Brian Fundakowski Feldman]

On Sun, 6 Aug 2000, Nickolay Dudorov wrote:

> In article <[EMAIL PROTECTED]> you wrote:
> > green   2000/08/05 19:14:53 PDT
> > 
> >   Modified files:
> > sys/sys  select.h 
> >   Log:
> >   None of select.h needs to be exposed to !_KERNEL.
> 
>   But 'src/lib/lib/libkvm/libkvm_proc.c' does
> '#include ' which in turn has the line:
> 
> #include/* For struct selinfo */
> 
> 
>   As a result 'make buildworld' stops in
> 'src/lib/libkvm'.

I knew something like this would happen and we'd catch some improperly
written software.  Thanks :)

>   N.Dudorov   

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: sort(1) broken?

[Brian Fundakowski Feldman]

On Mon, 31 Jul 2000, Kris Kennaway wrote:

> The following no longer seems to work on any of my 5.0 boxes:
> 
> ls -l | sort -n -k 5
> 
> which should sort numerically by the size column (instead it seems to do
> the same thing as sort -n). It works correctly on 3.x and 4.x boxes.
> 
> Anyone have ideas?

Sure:

{"/home/green"}$ ls -l | MALLOC_OPTIONS=AJ sort -nk5 | tail -10 | head -5
drwxr-xr-x  13 green  green512 Jun  7  1999 saint-1.4
drwxr-xr-x  16 green  green512 Aug  5  1999 stress
drwxr-xr-x  17 green  green512 Feb 14 23:27 ioccc
drwxr-xr-x  17 green  www 1536 Jul 30 18:39 public_html
drwxr-xr-x  21 green  green   1024 Feb  7  1999 descent

{"/home/green"}$ ls -l | MALLOC_OPTIONS=aj sort -nk5 | tail -10 | head -5
-rwx--   1 green  green   31017984 Jan 19  2000 quake1.tar.gz
-rw-r--r--   1 green  green   32642085 Jun 25 00:31 mail.tar.gz
-rw-rw-rw-   1 green  green   47845836 Jun 26 18:52 ccs12.rm
-rw-r--r--   1 green  green   52525668 Jun  5 21:30 SaberMarionetteJ-ep04.rm
-rw-r--r--   1 green  green   53822026 Jul 11 07:53 SaberMarionetteJ-ep02.rm

To fix this particular bug, the patch is:

Index: sort.c
===
RCS file: /usr2/ncvs/src/gnu/usr.bin/sort/sort.c,v
retrieving revision 1.15
diff -u -r1.15 sort.c
--- sort.c  1999/04/25 22:14:05 1.15
+++ sort.c  2000/07/31 11:26:33
@@ -1860,6 +1860,7 @@
  insertkey (key);
key = (struct keyfield *)
  xmalloc (sizeof (struct keyfield));
+   bzero(key, sizeof(*key));
key->eword = -1;
key->ignore = NULL;
key->translate = NULL;

I'm doubtful it's the only one of it's kind in GNU sort(1).  Time for BSD
sort(1)?

> Kris
> 
> --
> In God we Trust -- all others must submit an X.509 certificate.
> -- Charles Forsythe <[EMAIL PROTECTED]>

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: randomdev entropy gathering is really weak

[Brian Fundakowski Feldman]

On Sun, 30 Jul 2000, Mark Murray wrote:

> > How does entropy gathering at a high enough rate solve this
> > particularly?
> 
> EG, by having it such that Yarrow state perturbations happen often
> enough that each read is "guaranteed" to be associated with at least
> one and preferably more.

Can you give me an idea how this would work, at least with e.g.
pseudocode annotation of the current code?  I'm curious what you're
going to change that will allow reseeeding while a read is in
progress.

> M
> --
> Mark Murray
> Join the anti-SPAM movement: http://www.cauce.org

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: randomdev entropy gathering is really weak

[Brian Fundakowski Feldman]

On Sun, 30 Jul 2000, Mark Murray wrote:

> This is a reversion to the count-entropy-and-block model which I have
> been fiercely resisting (and which argument I thought I had sucessfully
> defended).
> 
> My solution is to get the entropy gathering at a high enough rate that
> this is not necessary.

How does entropy gathering at a high enough rate solve this
particularly?  Unless you wait for reseeds while reading, it simply
doesn't matter how much entropy is being gathered at the time since
reading any amount just doesn't give you a new key.  Indeed, if you
can get enough entropy that the blocking in read would be very short,
you would still need to block in read to give it time to use the
entropy.

The only alternative I can see that you might be thinking of would be
that the user would be encouraged to only read a small amount at a
time and reading more soon later in the assumption that Yarrow will be
rekeyed.  Then this would be just forcing the user to do the blocking
manually, and non-deterministically.

So how exactly _would_ just having a high entropy gathering rate help
the case that you need a large amount of data from /dev/random with
true entropic value, not only 256 bits worth?  It's not like reseeds
would be occurring while reads were in progress; reads are too fast
for that and are splsofttq() protected, anyway.

> I also agreed to _maybe_ look at a re-engineer of the "old" code in a
> secure way if a decent algorithm could be found (I am reading some
> papers about this ATM).
> 
> M
> --
> Mark Murray
> Join the anti-SPAM movement: http://www.cauce.org

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: snes9x

[Brian Fundakowski Feldman]

On Sun, 30 Jul 2000, Jeroen Ruigrok/Asmodai wrote:

> I am really uncertain where to set the reply-to to.
> I don't read ports though.
> 
> Anyways.
> 
> I have been using snes9x 1.26 some time ago on my CURRENT box and
> everything worked ok.
> 
> Today, after I updated my CURRENT this weeks from a month old to
> something more recent, I figured I should install snes9x again.
> 
> So I installed 1.29.  'lo and behold, the colours are all crazy, lots of
> green.

Hmm... are you trying to tell me something? *g*

> I cannot remember exactly when I last used snes9x, but my
> .snes96_snapshots/ directory shows february as the last savedates.

Definitely too long ;)

> I just asked some guys who are using 4-STABLE to test a ROM and with
> 4-STABLE, snes9x 1.29 and that same rom they see the colours as they
> should be.
> 
> So I cannot say anything else but that CURRENT has a weird bug
> somewhere.  So therefor I am looking for people with CURRENTs which are
> between january and now to install snes9x 1.29 and try the rom at
> http://lucifer.in-nomine.org/~asmodai/Ff5.zip
> And see what colours the opening screen have [that's the final fantasy
> logo].  I get all kinds of greens, but it should be blue IIRC.

Indeed it's blue on my current as of last week.

> Some info about my setup: Xfree 3.3.6 on CURRENT.

Same here.

> /usr/X11R6/bin/snes9x:
>   libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x280e7000)
>   libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x280f2000)
>   libz.so.2 => /usr/lib/libz.so.2 (0x28192000)
>   libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x2819f000)
>   libm.so.2 => /usr/lib/libm.so.2 (0x281de000)
>   libc_r.so.4 => /usr/lib/libc_r.so.4 (0x281fa000)
>   libXThrStub.so.6 => /usr/X11R6/lib/libXThrStub.so.6 (0x282aa000)
> 
> 4-STABLE:
> 
> /usr/X11R6/bin/snes9x:
>   libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x280e7000)
>   libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x280f6000)
>   libz.so.2 => /usr/lib/libz.so.2 (0x281e9000)
>   libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x281f6000)
>   libm.so.2 => /usr/lib/libm.so.2 (0x28234000)
>   libc_r.so.4 => /usr/lib/libc_r.so.4 (0x2824f000)
> 
> The only difference is the XThrStub, but that's the X Threaded Stub
> library if I can judge by its name.
> 
> Ideas are welcome, I mean, could syscons influence this?

What color depth are you running at?  I wouldn't expect that anything
16-bit or higher wouldn't work well, at least.  -CURRENT usually works
great for gaming for me; I'm going through, e.g., Chrono Trigger my
second time now :)

I'd guess something may be taking up a HUGE amount of the palette,
unless you are running in 24-bit mode.  If it's not that, perhaps
it's the video card itself.  This is a rather strange problem to have.

> -- 
> Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
> Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
> The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
> Abandon hope, all ye who enter here...

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: randomdev entropy gathering is really weak

[Brian Fundakowski Feldman]

On Sun, 30 Jul 2000, Mark Murray wrote:

> > Content-Disposition: attachment; filename="yarrow_blocking.patch"
> 
> Brian:
> 
> I want to take a different approach to this one.
> 
> Do not commit anything to the /dev/random device, please, without running
> it by me.

I was not planning on it.  You really should take a look at the bugfixes,
though; reading buffer sizes of >8 bytes but not-8-byte-multiple should
do it.  There's also the ioctl handler which you need stubs for and then
checking for open devices when you attempt to unload the module.

> M
> --
> Mark Murray
> Join the anti-SPAM movement: http://www.cauce.org

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: randomdev entropy gathering is really weak

[Brian Fundakowski Feldman]

On Mon, 24 Jul 2000, Jeroen C. van Gelderen wrote:

> > > What I meant with that point is that the user may get, say an extra few
> > > hundred bits out of it with no new entropy before the scheduled reseed
> > > task kicks in.
> > 
> > How does he know which bits are which? His analysis task just got a whole
> > lot more difficult.
> 
> Again, not entirely correct but not relevant either...
> 
> Kris is simply right in that the /dev/random semantics change 
> and that more bits can be output by Yarrow than there is entropy 
> gathered. *In theory* the complexity of an attack on our Yarrow 
> has an upper bound of 2^256 and *in theory* this is less than 
> the complexity of an attack on our current /dev/random. This is 
> a hard fact, no way around that.

Even if the attack on a single non-blocking read from Yarrow is only
of 2^256 complexity, it is designed to be much more expensive than
just cracking a single block cipher.  Blowfish has a very large keying
step, and Yarrow is designed to exploit having large keying steps and
then adding more complexity in its setup in addition.  This makes it
infeasible to mount attacks on Yarrow, and the security is really not
as weak as just cracking 20-round Blowfish-256.

However, none of this makes Yarrow useless for getting many bits of
high-quality random data for, e.g., generation of an RSA key.

> However, the big question here is not about theory but about
> *practicality*. Is Yarrow less secure than /dev/random in 
> practice? How does our /dev/random hold up under attack? How 
> does Yarrow compare? I think we need to evaluate these practical
> questions instead of deep theoretical issues as Yarrow is all 
> about practicality.
> 
> At a more fundamental level we will need to answer the question:
> "Do we need to preserve the current /dev/random semantics or 
> can we decide to change 'em? [1]". And how will this affect our
> applications *in practice*.

Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0
(I guess that's the proper name for this :-) is complex enough and
generates good enough ouput.  If you /really/ want to make the attack
on it much harder, how about this: if you're going to read 1024 bits
of entropy from Yarrow on /dev/random, you will request it all at once
and block just as the old random(4) used to block; the blocking can
occur at 256 bit intervals and sleep until there is a reseed.  Waiting
to reseed for each read will ensure a much larger amount of "real"
entropy than it "maybe" happening at random times.

Can you really find anything wrong with doing what I propose *in
practice*?  I'm certain that it would make it about as hard to
brute-force the key while knowing certain parameters of its generation
as it would be to just factor the damned 1024-bit number.  I've
already implemented this as well as some other bugfixes, so see the
attached diff.

> So let's concentrate this discussion on the practical issues
> and explain why you think backing /dev/random with Yarrow and
> changing the semantics is justifyable or even a good thing.
> 
> Cheers,
> Jeroen
> 
> [1] And, should we decide not to change /dev/random semantics,
> can we still back /dev/random with a modified Yarrow? 

I think it makes sense :)

> -- 
> Jeroen C. van Gelderen  o  _ _     _
> [EMAIL PROTECTED]  _o /\_   _ \\o  (_)\__/o  (_)
>   _< \_   _>(_) (_)/<_\_| \   _|/' \/
>  (_)>(_) (_)(_)   (_)(_)'  _\o_

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'


Index: sys/sys/random.h
===
RCS file: /usr2/ncvs/src/sys/sys/random.h,v
retrieving revision 1.25
diff -u -r1.25 random.h
--- sys/sys/random.h2000/07/25 21:18:45 1.25
+++ sys/sys/random.h2000/07/29 23:19:20
@@ -36,6 +36,8 @@
 enum esource { RANDOM_WRITE, RANDOM_KEYBOARD, RANDOM_MOUSE, RANDOM_NET, \
ENTROPYSOURCE };
 void random_harvest(void *, u_int, u_int, u_int, enum esource);
+void set_wakeup(int *, int);
+void set_wakeup_exit(int *, int, int);
 
 #endif
 
Index: sys/dev/randomdev/harvest.c
===
RCS file: /usr2/ncvs/src/sys/dev/randomdev/harvest.c,v
retrieving revision 1.4
diff -u -r1.4 harvest.c
--- sys/dev/randomdev/harvest.c 2000/07/25 21:18:46 1.4
+++ sys/dev/randomdev/harvest.c 2000/07/29 23:18:50
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -72,4 +73,23 @@
nanotime(&timebuf);
(*reap)(&timebuf, entropy, cou

Re: fcntl and /dev/random

[Brian Fundakowski Feldman]

On Sat, 29 Jul 2000, Hiroyuki Hanai wrote:
> 
> Setting status flags using F_SETFL command of fcntl(2) on the file
> descriptor, which is returned by open(2)ing /dev/random, seems not to
> be supported. For example, when I run following code;
>
> [...]
> 
> 3.4-RELEASE(and possibly 3.5 and 3.5.1) and 4.1-RELEASE/4.1-STABLE say
> `Inappropriate ioctl for device' and 5-current says `Operation not
> supported by device'.

EOPNOTSUPP is definitely wrong.  Try this:

Index: randomdev.c
===
RCS file: /usr2/ncvs/src/sys/dev/randomdev/randomdev.c,v
retrieving revision 1.10
diff -u -u -1 -r1.10 randomdev.c
--- randomdev.c 2000/07/25 21:22:17 1.10
+++ randomdev.c 2000/07/29 08:12:47
@@ -51,2 +51,3 @@
 static d_write_t random_write;
+static d_ioctl_t random_ioctl;
 
@@ -61,3 +62,3 @@
/* write */ random_write,
-   /* ioctl */ noioctl,
+   /* ioctl */ random_ioctl,
/* poll */  nopoll,
@@ -133,2 +134,9 @@
return error;
+}
+
+static int
+random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct proc *p)
+{
+
+   return (ENOTTY);
 }

> I've found above in BIND9's source and its `named' program complains
> everytime it's invoked.
> 
> Should I fix BIND9's code? or wait for fcntl's F_SETFL being
> supported on FreeBSD?

Err, this is a minor bug, but should definitely be fixed.

> Actually, in BIND9, fd is already open(2)ed with `O_RDONLY | O_NONBLOCK'
> and setting O_NONBLOCK status with fcntl(2) is not needed, which means
> that fixing BIND9's code is very simple; just comment out the fcntl(2)ing line.

I'd say send that to the maintainer :)

> h.hanai

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Mouse behaving funny since 5.0-CURRENT upgrade

[Brian Fundakowski Feldman]

On Fri, 28 Jul 2000, Robert Watson wrote:

> Kazu,
> 
> Nope, it didn't appear to help.  When I move the mouse around, it
> intermitently pauses, perhaps once a second, for a short period of time.

Robert, how fast is the machine that it's pausing on?  I have a feeling
this could easily be Yarrow at work, since Yarrow runs right now most
of the work done inside an interrupt handler (a taskqueue, at least).

I'd like you to test the kthread version of Yarrow when Mark Murray and I
are ready, which should be in a few days.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking

[Brian Fundakowski Feldman]

On Fri, 28 Jul 2000, Sheldon Hearn wrote:

> 
> Just a quick note to let you two gentlement know that the problem
> persists with rev 1.107 of buf.h.
> 
> Brian, these are realy easy for me to reproduce on my own box here.  Do
> you want to send me the stuff for maintaining the queues that you said
> would help you figure out what's going on?  Or are you able to reproduce
> this yourself?

I havne't been able to reproduce this, but this case is going to have
more to do with analysis of the code than with "debugging", I think.
By chance are you running with softupdates enabled on /?  If I can
reproduce it here, I will spend a while inspecting all the state to
figure this one out as best as possible.

> Ciao,
> Sheldon.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking

[Brian Fundakowski Feldman]

On Wed, 26 Jul 2000, Sheldon Hearn wrote:

> 
> Hi Kirk,
> 
> On Tue, 25 Jul 2000 11:28:47 MST, Kirk McKusick wrote:
> 
> >   Modified files:
> > sys/kern vfs_bio.c 
> >   Log:
> >   Now that buffer locks can be recursive, we need to delete the panics
> >   that complain about them.
> 
> This looks related.  I get it pretty consistently on shutdown, provided
> the machine did some work subsequent to going multi-user.

[Script cut]

Yeah, several people are noticing that one.  Robert Watson and I were
trying to debug it, but it was really late at night so personally I
gave up on it until I could reproduce it here.

I got a different one.  I'd like to track it down but it hasn't repeated
itself (yet?).  My call stack was (disregarding ATA's call stack mostly):

panic()
bufdone() checking that B_DONE's not set (which it is)
cluster_callback() calling bp->b_iodone()
biodone() calling bufdone()
ad_interrupt() calling biodone()

I implemented a little circular buffer which holds (calling function,
bp) pairs for bufdone(), but so far I have had no crash yet (yay? :-/).
When I do, the circular buffer (thanks, Greg!) will help me out to
actually debug this instead of just wondering why B_DONE was set.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking

[Brian Fundakowski Feldman]

On Tue, 25 Jul 2000, Ollivier Robert wrote:

> According to Brian Fundakowski Feldman:
> > Actually, I'm pretty certain this is the fix:
> 
> Well it won't panic but isn't it putting the problem under the carpet? I
> agree the panic seems to be here temporarely but...

No, I'm really certain this isn't the case.  You see, struct buf has
a b_lock that until recently was a plain, exclusive lockmgr lock.  In
Kirk's last round of changes, he converted b_lock to be LK_CANRECURSE,
which means that the lock, while still an exclusive lock, may be
relocked multiple times by the same caller.

The panics are plain wrong.  What's left is to determine what is the
proper thing to do in each of these cases, which I'm certain that many
people already know already (you see, I'm still a bit green ;). What I
am _almost_ sure about is that the right thing is just to remove one
of the locks and let it get freed back up the call chain.  I'm almost
certain this is the case because if you are grabbing exclusive locks
and recursing upon them, your call chain is the only consumer and in
a recursive-locking-callchain, you will have multiple symmetric lock
and unlock pairs.  Anything else horribly complicates things, and this
makes me a good 95% certain that this is exactly the right fix, not
that it's sweeping any true bugs under the carpet.

Allowing recursive locks is pretty much the only way to solve many of
the problems here because it's simply not possible to support all code
paths without allowing for this recursion.  The code would either be
horribly complicated or non-functional.  I'm certain Kirk may be able
to back me up here.  It seems that the cleanup is meant to make the
locks recursive mostly to facilitate correct/proper call chains, and
that's consistent with my understand at least :)

Indeed, if you look at the comment in brelse() from the delta, you
will see that the intention of allowing this very situation to occur
and simply BUF_UNLOCK() was planned for and the panic()s were for
debugging during the previous time that b_locks weren't LK_CANRECURSE.

As always, take what I say with a grain of salt since I'm definitely
not a VFS guru in any manner; I just happen to think I understand this
one :)

> -- 
> Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
> The Postman hits! The Postman hits! You have new mail.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking

[Brian Fundakowski Feldman]

Actually, I'm pretty certain this is the fix:

Index: vfs_bio.c
===
RCS file: /usr2/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.260
diff -u -r1.260 vfs_bio.c
--- vfs_bio.c   2000/07/11 22:07:43 1.260
+++ vfs_bio.c   2000/07/25 14:24:26
@@ -1067,9 +1067,6 @@
if (bp->b_qindex != QUEUE_NONE)
panic("brelse: free buffer onto another queue???");
if (BUF_REFCNT(bp) > 1) {
-   /* Temporary panic to verify exclusive locking */
-   /* This panic goes away when we allow shared refs */
-   panic("brelse: multiple refs");
/* do not release to free list */
BUF_UNLOCK(bp);
splx(s);
@@ -1192,7 +1189,6 @@
panic("bqrelse: free buffer onto another queue???");
if (BUF_REFCNT(bp) > 1) {
/* do not release to free list */
-   panic("bqrelse: multiple refs");
BUF_UNLOCK(bp);
    splx(s);
    return;


--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking

[Brian Fundakowski Feldman]

On Tue, 25 Jul 2000, Ollivier Robert wrote:

> I just got two panics tonight, the same each time. Current from yesterday,
> after the latest round of patch from Kirk. The second panic is exactly the
> same including the trace.

Welp, I didn't get em before, but I do now.  I'll see what I can do to figure
this one out, but don't know at all if I'll be able to solve it.  My
backtrace is similar.  The important par about the backtrace is the
part before the panic:

#9  0xc0164695 in panic (fmt=0xc02662eb "bqrelse: multiple refs") at 
../../kern/kern_shutdown.c:553
#10 0xc018f3b5 in bqrelse (bp=0xc373e100) at ../../kern/vfs_bio.c:1195
#11 0xc018e9b9 in vfs_backgroundwritedone (bp=0xc37812e0) at ../../kern/vfs_bio.c:696
#12 0xc0190fbd in bufdone (bp=0xc37812e0) at ../../kern/vfs_bio.c:2666
#13 0xc0190f06 in bufdonebio (bp=0xc37812e0) at ../../kern/vfs_bio.c:2617
#14 0xc0221258 in ad_interrupt (request=0xc10f43c0) at ../../sys/bio.h:103
#15 0xc021f756 in ata_intr (data=0xc0c7ff80) at ../../dev/ata/ata-all.c:1126
#16 0xc024b747 in splx (ipl=0xc018e41a) at ../../i386/isa/ipl_funcs.c:181
#17 0xc018e41a in bread (vp=0xcf889600, blkno=0x260030, size=0x1800, cred=0x0, 
bpp=0xd0476ad0)
at ../../kern/vfs_bio.c:459
#18 0xc01fa070 in ffs_blkfree (ip=0xd0476b58, bno=0x1373c8, size=0x2000) at 
../../ufs/ffs/ffs_alloc.c:1346
#19 0xc0201153 in indir_trunc (ip=0xd0476b58, dbn=0x24cf40, level=0x0, lbn=0xc, 
countp=0xd0476b48)
at ../../ufs/ffs/ffs_softdep.c:2098
#20 0xc0200f29 in handle_workitem_freeblocks (freeblks=0xc0ce9200) at 
../../ufs/ffs/ffs_softdep.c:2002
#21 0xc02009b0 in softdep_setup_freeblocks (ip=0xc0f4ac00, length=0x0) at 
../../ufs/ffs/ffs_softdep.c:1710
#22 0xc01fbac6 in ffs_truncate (vp=0xd036a800, length=0x0, flags=0x0, cred=0xc0ce9080, 
p=0xd0c0)
at ../../ufs/ffs/ffs_inode.c:196
#23 0xc020bc12 in ufs_setattr (ap=0xd0476e44) at ../../ufs/ufs/ufs_vnops.c:498
#24 0xc020dedd in ufs_vnoperate (ap=0xd0476e44) at ../../ufs/ufs/ufs_vnops.c:2291
#25 0xc0199cb8 in open (p=0xd0c0, uap=0xd0476f80) at vnode_if.h:305
#26 0xc02479d1 in syscall2 (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0xbfbff9f0, tf_esi = 0xbfbff9d8, 
  tf_ebp = 0xbfbff964, tf_isp = 0xd0476fd4, tf_ebx = 0xbfbff9d8, tf_edx = 0x7, 
tf_ecx = 0x7, tf_eax = 0x5, 
  tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x804d788, tf_cs = 0x1f, tf_eflags = 
0x246, tf_esp = 0xbfbff928, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1128
#27 0xc023bab5 in Xint0x80_syscall ()
#28 0x8048ec2 in ?? ()
#29 0x8048139 in ?? ()

At frame 10, the lock is held in multiple:
(kgdb) p bp->b_lock
$1 = {
  lk_interlock = {
lock_data = 0x0
  }, 
  lk_flags = 0x440, 
  lk_sharecount = 0x0, 
  lk_waitcount = 0x0, 
  lk_exclusivecount = 0x2, 
  lk_prio = 0x14, 
  lk_wmesg = 0xc0265fe4 "bufwait", 
  lk_timo = 0x0, 
  lk_lockholder = 0x752f
}

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Recent -current Performance Drop?

[Brian Fundakowski Feldman]

On Tue, 11 Jul 2000, Poul-Henning Kamp wrote:

> >I seem to see somewhat of a performance drop in the past week.
> 
> You should have read the commit messages :-)
> 
> I enabled malloc flags AJ by default, this has a performance
> cost.  It will be turned off for releases of course.
> 
> It has already exposed on bug (see peters commit).

 ^- Multiple bugs, thankyouverymuch :)

> You can disable it if you want to run benchmarks:

If you run a desktop system (need good response) and aren't willing to
take the large performance hit, too.  Note it's a large performance
hit when you tend to run a LOT of stuff and always dig into swap very
quickly.  I imagine for most people, the performance drop isn't nearly
as high, so they can live with it :)

>   ln -sf aj /etc/malloc.conf
> 
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

HEADS UP: recent panics fixed

[Brian Fundakowski Feldman]

Please let me know if any of you still have spontaneous panics!

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'

-- Forwarded message --
Date: Mon, 10 Jul 2000 23:47:38 -0700 (PDT)
From: Brian Feldman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: cvs commit: src/sys/dev/randomdev yarrow.c

green   2000/07/10 23:47:38 PDT

  Modified files:
sys/dev/randomdevyarrow.c 
  Log:
  One should never allocate 4-kilobyte structs and such on the interrupt
  stack.  It's bad for your machine's health.
  
  Make the two huge structs in reseed() static to prevent crashes.  This
  is the bug that people have been running into and panic()ing on for the
  past few days.
  
  Reviewed by:  phk
  
  Revision  ChangesPath
  1.8   +7 -3  src/sys/dev/randomdev/yarrow.c





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

Re: Scheduler changes?

[Brian Fundakowski Feldman]

On Sun, 11 Jun 2000, Luigi Rizzo wrote:

> Hi,
> i understand that this means maybe a somwthat
> large change in the system, but what do you think
> if we have a lok at implementing the CPU scheduler using
> weights instead of strict priorities ?
> Do we have parts of the kernel which rely on priority
> to implement locking etc ?
> 
> This would not be too different from what the EclipseBSD people
> did, and the code i recently committed to dummynet can be easily
> reused to this purpose, and it is efficient.
> 
> With a little bit of guidance (I am not too familiar with that area
> of the code) i think we can do something good with little
> effort.

I've been thinking about this a lot.  As for the current scheduler, a
NICE_WEIGHT of 1.8 seems to work nicely; see the attached patch.  I
have been looking more into making things more like Eclipse.  I have to
say I'm very impressed with their work in implementing QoS, and we
would do well to update some of our ancient designs to a model that
resembles theirs.  I'm looking at their process and disk scheduler now,
after reading their network scheduling paper from the Usenix proceedings.
I'm very interested in finding a better algorithm than the current one,
yes :)

>   cheers
>   luigi

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'


Index: sys/kern/kern_synch.c
===
RCS file: /usr2/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.95
diff -u -r1.95 kern_synch.c
--- sys/kern/kern_synch.c   2000/07/04 11:25:23 1.95
+++ sys/kern/kern_synch.c   2000/07/08 00:20:23
@@ -916,7 +916,7 @@
 
if (p->p_rtprio.type == RTP_PRIO_NORMAL) {
newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT +
-   NICE_WEIGHT * (p->p_nice - PRIO_MIN);
+   (p->p_nice - PRIO_MIN) * NICE_WEIGHT;
newpriority = min(newpriority, MAXPRI);
p->p_usrpri = newpriority;
}
Index: sys/sys/proc.h
===
RCS file: /usr2/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.106
diff -u -r1.106 proc.h
--- sys/sys/proc.h  2000/06/22 22:27:16 1.106
+++ sys/sys/proc.h  2000/07/08 00:21:14
@@ -405,10 +405,10 @@
  * the range 100-256 Hz (approximately).
  */
 #defineINVERSE_ESTCPU_WEIGHT   8   /* 1 / (priorities per estcpu level) 
*/
-#defineNICE_WEIGHT 1   /* priorities per nice level */
+#defineNICE_WEIGHT 9 / 5   /* priorities per nice level */
 #definePPQ (128 / NQS) /* priorities per queue */
 #defineESTCPULIM(e) \
-min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * PRIO_TOTAL - PPQ) + \
+min((e), INVERSE_ESTCPU_WEIGHT * (PRIO_TOTAL * NICE_WEIGHT - PPQ) + \
INVERSE_ESTCPU_WEIGHT - 1)
 
 extern u_long ps_arg_cache_limit;

Re: -e option to umount?

[Brian Fundakowski Feldman]

On Thu, 22 Jun 2000, Wes Peters wrote:

> Greg Lehey wrote:
> > 
> > What do people think about adding a -e option to umount(8) to eject a
> > removable medium where possible?
> 
> Yes!

For what it's worth, there's a port, ports/sysutils/eject, which is made
to do this.  I'm not one to deny a simple feature in the base system,
though, even if this feature is not /really/ that simple.

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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

kernel config format migration script

[Brian Fundakowski Feldman]

I made a sed script to ease migration of kernel configuration files from
the few-weeks-ago-CURRENT to current-CURRENT, and thought I might as well
share it since it makes things easy (autonomous :)

You can find it at
http://people.freebsd.org/~green/oldconfig2new
It requires extended regular expression support (because old regexps
are so cumbersome to actually _use_), so for example:
mv GREEN GREEN.old
perl gethints.pl GREEN
sed -Ef oldconfig2new GREEN.old > GREEN

Hope it saves some people time! :)

-- 
 Brian Fundakowski Feldman   /  "Any sufficiently advanced bug is\
 [EMAIL PROTECTED]   |   indistinguishable from a feature."  |
 FreeBSD: The Power to Serve!\-- Rich Kulawiec   /



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

Re: Scheduler changes?

[Brian Fundakowski Feldman]

On Sun, 11 Jun 2000, Jacob A. Hart wrote:

> On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote:
> >
> >The diff should make a process at -20 which uses all available CPU
> > schedule just slightly the ahead of a process at +20 which uses no CPU.
> > A process which uses full CPU at 0 niceness would have a priority of
> > 128, whereas a process using no CPU at 0 niceness would have a priority
> > of 90. All processes will always have a priority less than or equal to
> > 128, which is the priority at which a process with a niceness of +20
> > always runs at. A +20 process won't get better priority than anything
> > else, period. Try it out, see how it works for you:)
> 
> I tried this patch today.
> 
> While it didn't quite fix the problem, it sure made for some interesting
> pacman gameplay.  ;-)

Yeah, I tried it out myself.  I didn't actually think beforehand (hence the
testing...) why it would be bad for a process of niceness -20 to always
have better than the last priority in every case...  I tried it with
MAME and it took a long time before my "escape" key event registered
(X not getting run...).

I'm thinking of ways to make the algorithm both good for people who need
(err... want) low-priority background processes only to run when there's
free time, and high-priority processes run but not to the exclusion of
everything else.  The whole scheduling algorithm proper is quite tricky
to do very well; previously, it had most of the properties we want, but
it also easily allowed for deadlocks.

> Using idprio as Volodymyr suggested seems to be a viable workaround.  You
> mentioned in another message that idprio could potentially deadlock my
> machine, though.  Under what conditions could this happen (and how likely
> is it to occur)? 
> 
> 
> -jake
> 
> -- 
> Jacob A. Hart <[EMAIL PROTECTED]>
> Powered by: FreeBSD 5.0-CURRENT #18: Sun Jun 11 19:25:03 EST 2000
> 

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Scheduler changes?

[Brian Fundakowski Feldman]

On Sat, 10 Jun 2000, Volodymyr Kostyrko wrote:

> On Fri, Jun 09, 2000 at 08:28:06PM -0400, Brian Fundakowski Feldman wrote:
> >It's an issue. Nice values count for less than before due to fixes
> > that Luoqi Chen made (and I committed). The behavior now isn't optimal,
> > but it is better than the system locking up. NICE_WEIGHT might be okay
> > to keep at 2. Try the attached diff; I'm pretty sure it won't blow
> > things up :)
> >The diff should make a process at -20 which uses all available CPU
> > schedule just slightly the ahead of a process at +20 which uses no CPU.
> > A process which uses full CPU at 0 niceness would have a priority of
> > 128, whereas a process using no CPU at 0 niceness would have a priority
> > of 90. All processes will always have a priority less than or equal to
> > 128, which is the priority at which a process with a niceness of +20
> > always runs at. A +20 process won't get better priority than anything
> > else, period. Try it out, see how it works for you:)
> 
>   I think this is not the clear solution for descibed problem 'couse the dnetc 
>client still gets a priority and still have the share of time while other programs 
>might run. For me idprio works great. Just change last string in the starting shell 
>scipt.

There is no clear solution at all... try it out. Of _course_ it still gets a
share of the time.  If it didn't, then it could deadlock the system (like
idprio and rtprio both can).

>   idprio 31 su nobody -c "$dir/dnetc -quiet" 2>/dev/null >/dev/null &
> 
> -- 
> [WBR], Arcade Zardos. [AIST] [SAT Astronomy//Think to survive!] [mp3.aist.net]

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Scheduler changes?

[Brian Fundakowski Feldman]

On Sun, 28 May 2000, Jacob A. Hart wrote:

> I remember the scheduler bug you're talking about.  My system feels much
> the same as it did during 4.0-CURRENT when that bug was active.  I had a
> collection of wrapper scripts for CPU intensive programs that suspended
> rc5des, ran the program, then reenabled it again.  Should have held on to
> them, I guess.

Check out http://people.FreeBSD.org/~green/mean.c.

> > If this change
> > fixes things for you, please report it asap, since my understanding is
> > that this problem is rather elusive and annoying.
> 
> No, it didn't work, unfortunately.  To test it, I renice'd rc5des to a
> couple of different values while encoding an MP3.

   It's an issue. Nice values count for less than before due to fixes
that Luoqi Chen made (and I committed). The behavior now isn't optimal,
but it is better than the system locking up. NICE_WEIGHT might be okay
to keep at 2. Try the attached diff; I'm pretty sure it won't blow
things up :)
   The diff should make a process at -20 which uses all available CPU
schedule just slightly the ahead of a process at +20 which uses no CPU.
A process which uses full CPU at 0 niceness would have a priority of
128, whereas a process using no CPU at 0 niceness would have a priority
of 90. All processes will always have a priority less than or equal to
128, which is the priority at which a process with a niceness of +20
always runs at. A +20 process won't get better priority than anything
else, period. Try it out, see how it works for you:)

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'


--- /usr/src/sys/sys/proc.h Fri May 26 20:15:46 2000
+++ /home/green/tmp/proc.h  Fri Jun  9 20:13:30 2000
@@ -405,10 +405,10 @@
  * the range 100-256 Hz (approximately).
  */
 #defineINVERSE_ESTCPU_WEIGHT   8   /* 1 / (priorities per estcpu level) */
-#defineNICE_WEIGHT 1   /* priorities per nice level */
+#defineNICE_WEIGHT 2   /* priorities per nice level */
 #definePPQ (128 / NQS) /* priorities per queue */
 #defineESTCPULIM(e) \
-min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * PRIO_TOTAL - PPQ) + \
+min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * PRIO_TOTAL / 2 - PPQ) + \
INVERSE_ESTCPU_WEIGHT - 1)
 
 extern u_long ps_arg_cache_limit;



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

Re: ed driver broken in today's -CURRENT?

[Brian Fundakowski Feldman]

On Sun, 7 May 2000, Mike Smith wrote:

> 
> Since there's a sysctl you can use to turn the former off, perhaps it 
> would have been smart to take a few seconds to narrow it down?

Those changes wouldn't have affected ICMP, but we tried that anyway.
The problem was that the code changed the expression ~sum & 0x
to sum == 0x ? sum : ~sum & 0x.  I had just found and fixed
this locally when I noticed Paul Saab committed the same functional
fix.

Well, it's nice to know that we can get multiple people finding the
problem as soon as the symptoms of the breakage are known :)

> -- 
> \\ 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]

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

On Fri, 21 Apr 2000, Ben Smithurst wrote:

> X11 forwarding is working for me now, but wasn't when I first tried
> it.  I found I was explicitly setting XAUTHORITY=~/.Xauthority in my
> .zshrc file, so the temporary bits created in /tmp/ssh-foo/cookies by
> ssh weren't being picked up.  I missed the beginning of this thread, but
> you're not doing anything similar are you?  After fixing that, it seems
> to be working for me.  Of course, I'm on 4.0-stable, so if that works
> for you anyway and it's just 5.0-current which is broken, ignore me.

Sorry, no dice :(  It doesn't seem to be that.  All I've got left is
maybe sending out every bit of configuration info, and maybe someone
could figure it out.  I doubt it, though, so I'm not gonna.

> -- 
> Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

On Fri, 21 Apr 2000, Andrew Reilly wrote:
> 
> What man ssh(1) doesn't tell you in this paragraph is that even
> if you say "ForwardX11 yes" in ~/.ssh/config, you will not get
> a proxy X session unless the server has "X11Forwarding yes" in
> /etc/ssh/sshd_config.  The default that my system configured
> itself with was "X11Forwarding no", and I've just changed it,
> and now it works.
> 
> That's what I found out as a result of this conversation.

For better or for worse, my configuration files haven't changed at all,
and are all still correct for OpenSSH, and nothing is fixed with the
latest OpenSSH code either...  All I can think of is perhaps reinstalling
XFree.

> -- 
> Andrew

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

On Fri, 21 Apr 2000, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> "Andrew Reilly" writes:
> : Have you got "X11Forwarding yes"
> 
> Ahem.  "ForwardX11 yes" is what's documented and is known to work.

According to the documentation, ForwardX11 yes is for ssh configs and
X11Forwarding yes is for sshd configs. (O_o)

> Warner

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

On Thu, 20 Apr 2000, Chris Piazza wrote:

> It's working from my 5.0 box to my 4.0-R box across town, too.
> 
> -Chris

Okay, give me some more info, please:

You're going from the 5.0 box to the 4.0 box.  What's the /etc/hosts
look like on the 5.0 box?  What's xauth list show (you don't have to
show me the cookies, of course :)?  What does xauth list say when
you're ssh'd into the 4.0 box?

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

On Thu, 20 Apr 2000, Chris Piazza wrote:

> It's working from my 5.0 box to my 4.0-R box across town, too.
> 
> -Chris

Thanks.  There's one data point.  Now it's evidently nothing in the
code, as it fails exactly the same way with 4.0-STABLE OpenSSH,
-CURRENT OpenSSH, and my latest port update OpenSSH.

I have no idea what it could be now.  I suppose I'll investigate problems
with XFree86 itself now :-/  This is extremely weird.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

On Thu, 20 Apr 2000, Brooks Davis wrote:

> It works for me.  I just tested it from my laptop (current as of
> yesterday) to a 4.0-S machine, a 3.3-RC running ssh 1.2.26, and Solaris
> 2.6 system also running 1.2.26.  I seem to recall that we were shipping
> with the server disabling forwarding which was bogus.  It's not
> disabled in the default client config.
> 
> -- Brooks

No, I'm interested in a pure FreeBSD 4.X/5.X to 4x/5.X tunnel.  Can you
try just ssh to localhost and using X forwarding there (display will
be localhost:10.0)?

> -- 
> Any statement of the form "X is the one, true Y" is FALSE.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

Just FYI:

It still doesn't work at all, after multiple make worlds with the latest
crypto sources all around.  I'm going to update the port and then try that
instead.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone able to verify the fix for (was Re: panic: vm_object_shadow:source object has OBJ_ONEMAPPING set.)

[Brian Fundakowski Feldman]

On Tue, 18 Apr 2000, Alan Cox wrote:

> This patch introduces a new bug.  While it does guarantee that
> the assertion in vm_object_shadow isn't tripped over, it doesn't
> clear the OBJ_ONEMAPPING flag on the newly created shadow object.
> (New objects are created with OBJ_ONEMAPPING set.)  Consequently,
> we'll have two overlapping mappings to the same shadow object
> that has OBJ_ONEMAPPING set.  That's bad.

Well, it didn't blow up my computer; that's good!  It prevented the panic,
and it can't possibly be worse than my previous patch.

> The real problem is that the assertion is just plain wrong, not
> the code around it.  It needs to be corrected or removed.

As I suspected all along ;)

> Alan

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

On Mon, 17 Apr 2000, Shin-ichi YOSHIMOTO wrote:

> At 10:01 -0400 04/17/2000, Brian Fundakowski Feldman wrote:
> > Has anyone tried it recently and gotten it to work?
> 
> Yes, sure. Check your config file.

That doesn't explain the failures here.  Look.  The initial
SSH_CHANNEL_X11_OPEN is totally fucked up basically nothing at
all like it should be, and there's nothing to explain it.

SSH Version OpenSSH-1.2.2, protocol version 1.5.
Compiled with SSL.
debug: Reading configuration data /home/green/.ssh/config
debug: Applying options for *
debug: Reading configuration data /etc/ssh/ssh_config
debug: Applying options for *
debug: ssh_connect: getuid 0 geteuid 0 anon 0
debug: Connecting to green.dyndns.org [10.0.0.1] port 22.
debug: Allocated local port 926.
debug: Connection established.
debug: Remote protocol version 1.5, remote software version OpenSSH-1.2.2
debug: Waiting for server public key.
debug: Received server public key (768 bits) and host key (1024 bits).
debug: Host 'green.dyndns.org' is known and matches the host key.
debug: Encryption type: blowfish
debug: Sent encrypted session key.
debug: Installing crc compensation attack detector.
debug: Received encrypted confirmation.
debug: Doing password authentication.
debug: Requesting pty.
debug: Requesting X11 forwarding with authentication spoofing.
debug: Requesting shell.
debug: Entering interactive session.
Last login: Mon Apr 17 14:06:18 2000 from littlehost
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California.  All rights reserved.
FreeBSD 5.0-CURRENT (GREEN) #15: Sun Apr  9 23:06:23 EDT 2000

Welcome to FreeBSD!

Before seeking technical support, please use the following resources:

o  Security advisories and updated errata information for all releases are
   at http://www.FreeBSD.org/releases/ - always consult the ERRATA section
   for your release first as it's updated frequently.

o  The Handbook and FAQ documents are at http://www.freebsd.org/ and,
   along with the mailing lists, can be searched by going to
   http://www.FreeBSD.org/search.html.  If the doc distribution has
   been installed, they're also available formatted in /usr/share/doc.

If you still have a question or problem, please take the output of
`uname -a',  along with any relevant error messages, and email it
as a question to the [EMAIL PROTECTED] mailing list.  If you are
unfamiliar with FreeBSD's directory layout, please refer to the hier(7)
man page. If you are not familiar with man pages, type "man man".
You may also use `/stand/sysinstall' to re-enter the installation and
configuration utility.  Edit /etc/motd to change this login announcement.

/usr/X11R6/bin/xauth:  creating new authority file /tmp/ssh-JfGYR325/cookies
{"/home/green"}$ xterm
debug: Received X11 open request.
debug: channel 0: new [X11 connection from localhost port 1743]
debug: X11 connection uses different authentication protocol.
X11 connection rejected because of wrong authentication.

debug: X11 rejected 0 i1/o16
debug: channel 0: INPUT_OPEN -> INPUT_WAIT_DRAIN [read failed]
debug: channel 0: shutdown_read
debug: channel 0: OUTPUT_OPEN -> OUTPUT_WAIT_IEOF [write failed]
debug: channel 0: shutdown_write
debug: X11 rejected 0 i2/o64
debug: channel 0: INPUT_WAIT_DRAIN -> INPUT_WAIT_OCLOSE [inbuf empty, send IEOF]
debug: channel 0: OUTPUT_WAIT_IEOF -> OUTPUT_CLOSED [rvcd IEOF]
debug: channel 0: INPUT_WAIT_OCLOSE -> INPUT_CLOSED [rcvd OCLOSE]
debug: channel 0: full closed
X connection to green.dyndns.org:12.0 broken (explicit kill or server shutdown).
{"/home/green"}$ ^D
Connection to green.dyndns.org closed.
debug: Transferred: stdin 7, stdout 1533, stderr 40 bytes in 6.8 seconds
debug: Bytes per second: stdin 1.0, stdout 225.7, stderr 5.9
debug: Exit status 1

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Anyone have OpenSSH + X11-fwd working?

[Brian Fundakowski Feldman]

I'm not able to get X11 connection forwarding to work anymore.  I've tracked
it down to the packet sent for SSH_CHANNEL_X11_OPEN being completely bogus,
therefore trying to extract the "proto" and "data" fails, and the connection
doesn't work.

Has anyone tried it recently and gotten it to work?  I'd also be interested
in people who have not gotten it to work and get the error message about
an "invalid protocol".

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.

[Brian Fundakowski Feldman]

On Sat, 15 Apr 2000, Matthew Dillon wrote:

> Note that the ref_count == 1 test in the vm_object_shadow optimization
> should be left intact.  This optimization requires a much stricter set
> of tests because we do not want to assume sharability of an object
> if someone else (the 'else' being 'someone unknown to us') has a reference
> on it, even if OBJ_ONEMAPPING is set.

The KASSERT is broken in another way, BTW: it has undefined (read:
panic before the test even occurs) results if source is NULL, which
vm_object_shadow otherwise handles.  I don't know why it's never been
tripped on, though...

>   -Matt
>   Matthew Dillon 
>           <[EMAIL PROTECTED]>

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.

[Brian Fundakowski Feldman]

On Sat, 15 Apr 2000, Alan Cox wrote:

> > It is totally legal for OBJ_ONEMAPPING to be set even if the ref_count
> > is greater then 1.
> 
> Agreed.  OBJ_ONEMAPPING actually means that *each page* within the object
> is mapped at most once.  The object itself may be mapped many times,
> as long as the previous rule isn't violated.  In other words, none
> of the mappings map an overlapping set of pages.

Alright, this makes sense to me.

> > ...  The ref_count has no bearing on the shareability
> > of the object any more.  The tests were there before due to all sorts
> > of crud that had been hacked in in the 2.2.x and 3.x era to get around
> > serious bugs in the OBJ_ONEMAPPING flag and elsewhere in the VM system.
> > 
> > Note that the ref_count == 1 test in the vm_object_shadow optimization
> > should be left intact.  This optimization requires a much stricter set
> > of tests because we do not want to assume sharability of an object
> > if someone else (the 'else' being 'someone unknown to us') has a reference
> > on it, even if OBJ_ONEMAPPING is set.
> > 
> 
> Here's what troubles me about the state of the OBJ_ONEMAPPING management
> code: When we clear the OBJ_ONEMAPPING attribute on an object, we don't
> touch any of its backing objects.  Specifically, we don't guarantee
> that they don't have OBJ_ONEMAPPING set.  I think we should, if only
> because it makes reasoning about the system's behavior a lot easier.
> 
> If we cleared OBJ_ONEMAPPING recursively, then the rationale for
> this assertion would go away.

I'm still trying to understand this:  if you know that the object may
have pages mapped elsewhere, the backing objects recursively inherit
the assumption that it may have parts mapped elsewhere?  So, when you
set OBJ_ONEMAPPING, should you check upward recursively to check if
those objects can have OBJ_ONEMAPPING set?  I assume that you mean that
a backing object itself should have OBJ_ONEMAPPING cleared if any of
the children have it cleared.

> Brian, if you'd like to try this, I'll be happy to review it.

I'm going to research the VM a bit more now that you and Matt have gotten
me on track again, and soon wouldn't mind doing that :)

> Alan

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.

[Brian Fundakowski Feldman]

On Sat, 15 Apr 2000, Matthew Dillon wrote:

> [explanation]
> 
> Here is a new patch.  Please try it (and get rid of any prior patches
> to vm_object.c before applying this one).
> 

Thanks for the reply :)  What you say makes sense, so I'll try out this
patch as soon as I work out a way to get my machine to panic on demand,
as I'm also trying to track down an issue with the machine responding
to net interrupts and I can't tell if it responds to anything else, but
certainly doesn't function much at all.

I still have my test case (a 3/15 CVS checkout of Wine) lying around, so
I'll be able to definitely test it :)

>   -Matt
>   Matthew Dillon 
>           <[EMAIL PROTECTED]>

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.

[Brian Fundakowski Feldman]

On Sat, 15 Apr 2000, Alfred Perlstein wrote:

> Yes, find all places where source->ref_count is incremented and check
> for OBJ_ONEMAPPING as well as where OBJ_ONEMAPPING is set.
> 
> Then add some printfs to find the snippet that's incrementing it
> to complain when the OBJ_ONEMAPPING bit is set, and complain if
> setting OBJ_ONEMAPPING when the refcount is too high.

Further elaboration:

there is an assumption that it is wrong for OBJ_ONEMAPPING to be set but
not when ref_count > 1.  This assumption is defeated in the multiple test
cases we can find.  It seems that in the test cases, the common problem
is with (I think mmap()d) memory across multiple processes that _share_
_a_VM_space_!  It seems like what's happening is that the ref_count is
increased to reflect that each process has a hold of this object, which
may or may not be correct, and when that object is faulted on, the code
panics because it assumes that OBJ_ONEMAPPING means that there's only
one mapping of the object, but there are multiple references and so it
panics.

The question is not just "why" a OBJ_ONEMAPPING object has a ref_count > 1,
it's whether or not that is correct WRT multiple, shared-VM processes.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.

[Brian Fundakowski Feldman]

On Sat, 15 Apr 2000, Alfred Perlstein wrote:

> Yes, find all places where source->ref_count is incremented and check
> for OBJ_ONEMAPPING as well as where OBJ_ONEMAPPING is set.
> 
> Then add some printfs to find the snippet that's incrementing it
> to complain when the OBJ_ONEMAPPING bit is set, and complain if
> setting OBJ_ONEMAPPING when the refcount is too high.
> 
> Blotting out a KASSERT isn't the right thing to do.

Well, first the question must be answered, in an absolute yes or no:
is it wrong in the first place to have OBJ_ONEMAPPING set with a ref_count
of more than 1?  I'd accept an authoritative answer about this from
alc, dillon, dyson, or luoqi, who are all very familiar with the new
VM.

> -- 
> -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
> "I have the heart of a child; I keep it in a jar on my desk."

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.

[Brian Fundakowski Feldman]

On Thu, 13 Apr 2000, Michael Reifenberger wrote:

> Hi,
> when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
> FreeBSD -current. Kernel+mods in sync.
> Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday.
> Backtrace see crash.txt. Kernelconfig see nihil.
> Any thoughts anyone?

Yes, I've gotten these too.  I really believe the assumptions the code
there makes are wrong, and I've got a patch to correct them to what I
think they are supposed to be.  You've got the standard disclaimer on
the patch, though I assure you it has shown no ill effects to me, and I
noticed this bug through WINE.

I've asked Poul-Henning Kamp, who seems to also think that the code makes
wrong assumptions.  I've asked Matt Dillon and gotten no reply (a month
now, at least).  I've asked Alan Cox, and he'd help if we could get him
a test case so he can watch it happen himself and debug it himself.

Do you think you can find a specific set of steps for Alan to reproduce
it?

> Bye!
> 
> Michael Reifenberger
> ^.*Plaut.*$, IT, R/3 Basis, GPS

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'

Index: vm_object.c
===
RCS file: /usr2/ncvs/src/sys/vm/vm_object.c,v
retrieving revision 1.173
diff -u -r1.173 vm_object.c
--- vm_object.c 2000/03/26 15:20:22 1.173
+++ vm_object.c 2000/04/10 00:03:22
@@ -903,15 +903,25 @@
 * Don't create the new object if the old object isn't shared.
 */
 
-   if (source != NULL &&
-   source->ref_count == 1 &&
-   source->handle == NULL &&
-   (source->type == OBJT_DEFAULT ||
-source->type == OBJT_SWAP))
-   return;
+   if (source != NULL) {
+   if ((source->flags & OBJ_ONEMAPPING) != 0 &&
+   source->ref_count != 1)
+   printf("vm_object %p: flags %d, ref_count %d, " \
+   "type %d, handle %p\n",
+   source, source->flags, source->ref_count,
+   source->type, source->handle);
+   if ((source->flags & OBJ_ONEMAPPING) != 0 ||
+   (source->ref_count == 1 &&
+source->handle == NULL &&
+(source->type == OBJT_DEFAULT ||
+ source->type == OBJT_SWAP)))
+   return;
+   }
 
-   KASSERT((source->flags & OBJ_ONEMAPPING) == 0,
+#if 0
+   KASSERT(source != NULL && (source->flags & OBJ_ONEMAPPING) == 0,
("vm_object_shadow: source object has OBJ_ONEMAPPING set.\n"));
+#endif
 
/*
 * Allocate a new object with the given length



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

Re: Netscape 6 Linux pre-release, got it going.

[Brian Fundakowski Feldman]

On 11 Apr 2000, Dr. Brain wrote:

> I've had a good deal of success getting Mozilla to build straight out of the 
> nightly source tar files:
> ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-source.tar.gz
> 
> I recommend installing the jpeg and png libraries out of the ports tree and
> using a ~/.mozconfig with the following lines:
> [...]

I use this:
/usr2/build/mozilla/configure  --enable-optimize --with-jpeg=/usr/local 
--with-png=/usr/local --with-zlib=/usr --enable-x11-shm --disable-test --disable-debug 
--disable-mathml --with-pthreads

Note that you WILL want to support X11 shm if you want decent rapid redraw
speed.  The X11-SHM support in the autoconf is totally broken for any real
OS, so if you have a real OS that separates X11 includes from /usr/include,
you'll need to chenge this line:

for ac_hdr in sys/ipc.h shm.h sys/shm.h X11/extensions/XShm.h

What I do is to change the next ac_try= line to:
ac_try="$ac_cpp -I/usr/X11R6/include conftest.$ac_ext >/dev/null 2>conftest.out"

However, I imagine it would work to just remove the X!1/extensions/XShm.h
from the list, since that's a given on XFree86.

> To build mozilla: gmake -f client.mk build

gmake -f client.mk checkout seems to be quite broken.  It doesn't actually
check anything out, but if I perform exactly what it says it's doing, that
works and updates mozilla.  It used to work.

> -- 
> Eric Hodel - [EMAIL PROTECTED] - http://segment7.net
> 
>   Al Gore didn't invent the Internet, WE DID!
>   BSD Leading the Way!
>   -LinuxWorld2000 FreeBSD poster
> 

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Transparent proxying using ``ipfw fwd'' seems broken as of today

[Brian Fundakowski Feldman]

On Wed, 29 Mar 2000, Jos Backus wrote:

> Is it just me or is anybody else seeing this as well with today's
> kernel/world?

Phew, I thought I was going insane.  Yes, ipfw fwd is definitely broken
as of at least 3/28/2000.

jlemon has found the problem and is working on a fix.

> Thanks,
> -- 
> Jos Backus  _/ _/_/_/  "Reliability means never
>_/ _/   _/   having to say you're sorry."
>   _/ _/_/_/ -- D. J. Bernstein
>  _/  _/ _/_/
> [EMAIL PROTECTED]  _/_/  _/_/_/      use Std::Disclaimer;

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: DDB and dumping disk

[Brian Fundakowski Feldman]

On Tue, 28 Mar 2000, Jeroen Ruigrok van der Werven wrote:

> Your patch is a step in the right direction.
> 
> I am currently only trying to figure out why the DDB way doesn't trigger
> savecore to recognise the dump.

Did you try "call setdumpdev(0xf00)" with the proper show disk/ yet?
It's probably worth documenting the procedure even if it will be later
be replaced with a loader functionality... however, we should still
support the way it is now for people who want to get a dump but don't
have the ability to use loader(8) fully (Alpha?).

> -- 
> Jeroen Ruigrok van der Werven  Network- and systemadministrator
> <[EMAIL PROTECTED]>  VIA NET.WORKS The Netherlands
> BSD: Technical excellence at its best  http://www.bart.nl
> How are the mighty fallen...

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: DDB and dumping disk

[Brian Fundakowski Feldman]

On Sun, 26 Mar 2000, Jeroen Ruigrok/Asmodai wrote:

> Ok,
> 
> so thanks to Brian I can at least get a good value for my swap slice by
> using show disk/ad0s1b.
> 
> It returns that the dev_t is 0xc0b65800
> 
> Ok, so I then proceed to look at dumpdev
> 
> A p dumpdev shows me that it is set to a weird value not matching my
> dev_t above.

Right, that's the address of "dev_t dumpdev".

> A p *dumpdev returns 

That's the value of dumpdev itself.  The -1 is the value for NODEV, which
is right as you haven't set it :)

> When I want to set dumpdev to the dev_t by using w 
> dumpdev=c0b65800 or w dumpdev=c0b65800 or whatever combination will
> either result in `nothing written' or `symbol not found'.
> 
> I am obviously doing something wrong.  Help appreciated.

Just do a "w dumpdev 0xc0b65800".  You do need the 0x prefix, something
I tried to hint at with the printout of show disk ;)

> -- 
> Jeroen Ruigrok vd Werven/Asmodaiasmodai@[wxs.nl|bart.nl|freebsd.org]
> Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
> The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
> The descent to hell is easy...
> 

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: Dynamic sysctls - patches for review

[Brian Fundakowski Feldman]

On Fri, 24 Mar 2000, Andrzej Bialecki wrote:

> I'd appreciate some feedback. Thanks!
> 

Note this is not an actual peer review (yet), but... Good job!  This
is another big step in the right direction, and the code looks good
to me :)  The only problems I can see right now are just all style
bugs (^_^)

> Andrzej Bialecki
> 
> //  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
> // ---
> // -- FreeBSD: The Power to Serve. http://www.freebsd.org 
> // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: breakage still in sys/systm.h

[Brian Fundakowski Feldman]

On Fri, 24 Mar 2000, Steve Kiernan wrote:

> The definitions of major() and minor() in sys/systm.h break usage of the
> header.  Since sys/types.h defines major() and minor() as macros which
> compute the major and minor numbers, this creates an order dependency on
> sys/systm.h and sys/types.h.  Is this not a bad thing?

The sys/types.h header is meant to be included in userland code; the
sys/systm.h header is not to be included from outside of kernel code.
What possible reason would you have for systm.h in userland code?

> --
> Stephen Kiernan
> [EMAIL PROTECTED]
> NAI Labs, A Division of Network Associates, Inc.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: [PATCH] Fix login.conf, expiration, BSD compatibility in OpenSSH

[Brian Fundakowski Feldman]

On Tue, 29 Feb 2000, Andrey A. Chernov wrote:

> On Mon, Feb 28, 2000 at 08:57:08PM -0500, Brian Fundakowski Feldman wrote:
> > I'm not very comfortable with this, to be honest.  I don't see why
> > everything got moved around, at the least.
> 
> I am ready to answer to all your questions if they will be more specific.
> I don't understand what you mean by "moved around". If you mean that
> "expire" code moved earlier, it is the place where standard BSD login
> inform about expiration - before /etc/motd and so on printed. This patches
> live in SSH1 port for years and I not hear a single objection from you.

To be fair, I never touched the original SSH1 port beyond the process of
"make all install clean", so I wouldn't know.  The only real problem is
that I didn't see why things like the expiry checking were changed, but I
can see why now because of your clarification.

> -- 
> Andrey A. Chernov
> <[EMAIL PROTECTED]>
> http://nagual.pp.ru/~ache/

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




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

Re: [PATCH] Fix login.conf, expiration, BSD compatibility in OpenSSH

[Brian Fundakowski Feldman]

On Sun, 27 Feb 2000, Andrey A. Chernov wrote:

> This patch revive almost all login.conf and password/account expiration
> features, makes OpenSSH more FreeBSD login compatible and fix non-critical
> memory leak.
> 
> Please review and commit.

I'm not very comfortable with this, to be honest.  I don't see why
everything got moved around, at the least.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: After last ATAPI update system doesn't boot if modules loadedby /boot/loader.

[Brian Fundakowski Feldman]

On Thu, 24 Feb 2000, Mike Smith wrote:

> > > I'd hazard a guess that the presence of modules is causing the kernel 
> > > linker to run and pull all the sysctl hooks for modules it's finding.  
> > > I'm probably wrong, just a guess.
> ...
> > I'll go look up cold usage, and see if it necessarily has to be done that
> > early.  I'll also investigate that sysctl possibility.
> 
> Oops.  I meant sysinit, not sysctl.

Well, I don't think that's it.  I've tried moving it around a bit.
None of the code is called until the intrhook handler is called back,
so I don't see how it can be the sysinit itself causing the failure.

> -- 
> \\ 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]

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: After last ATAPI update system doesn't boot if modules loadedby /boot/loader.

[Brian Fundakowski Feldman]

On Thu, 24 Feb 2000, Mike Smith wrote:

> > It seems Mike Smith wrote:
> > > That's possible; it may be that the kernel linker is calling something 
> > > before you expect it to be called.
> > 
> > Well, its rather that the delayed probe rutine I register with 
> > config_intrhook_establish() is called before interrupts are actually
> > working, that would explain why it times out on the probe...
> > This didn't happen before, so thats probably why it breaks...
> > It should break SCSI systems too, ass they do the same...
> 
> Hmm.  You're assuming that interrupts are working when the hooks are run, 
> rather than assuming that it's safe to do things which will subsequently 
> cause interrupts which ought to be correctly handled.
> 
> I'd hazard a guess that the presence of modules is causing the kernel 
> linker to run and pull all the sysctl hooks for modules it's finding.  
> I'm probably wrong, just a guess.

It certainly seems like the intrhooks are called really early.  I did a
little bit of experimenting with this problem last night, and that's
the most I found: intrhooks really seem to be called to early.  I guess
I'll go look up cold usage, and see if it necessarily has to be done that
early.  I'll also investigate that sysctl possibility.

> -- 
> \\ 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]

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/

[Brian Fundakowski Feldman]

On Fri, 4 Feb 2000, John Baldwin wrote:

> >An even easier solution would be to get rid of setflags entirely
> >and put it back in the original sources that embedded it.
> 
> Umm, that's bascially what Joe's currently proposed patch does.
> 
> /me sighs
> 

But that would not fix the installation problem.

> >   -Matt
> 
> -- 
> 
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/

[Brian Fundakowski Feldman]

On Fri, 4 Feb 2000, John Baldwin wrote:

> > 2. Right after we resolve this issue, your patch (provided that you
> >fix errors Bruce pointed out), should be committed to make it
> >possible to compile -current xinstall in a host environment, e.g.
> >from 3.x (IMHO, the most important case).
> 
> I think his patch can go in now.  Since the names of the functions is up
> to date, it is best to not have them in libc, otherwise we'll have to bump
> libc's version number after we do finally settle on the appropriate names,
> which would be a Bad Thing(tm).
> 

This has an easy solution.  One, get rid of setflags usage by reverting
the Makefiles somewhat.  Two, remove setflags from the headers.  Three,
make libc have an _XXX_setflags and __weak_reference() it to setflags.
This won't break anyone, or make apps not be able to use [gs]etflags.

Of course, this would all be done at the same time :)

> -- 
> 
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: That fix for the ^T crash

[Brian Fundakowski Feldman]

On Fri, 28 Jan 2000, Stephen McKay wrote:

> Hi, Brian!
> 
> I'm concerned that your fix won't make it before the code freeze.  Is
> there a problem with it?  I admit I haven't actually tested it. :-(
> My excuse is that I assumed you had.
> 
> Or should I just do a quick test on your patch (+ bde fixes) and commit
> it myself?

The best thing to do is get on BDE's case to have it fixed very soon :)
He knows what he's doing!

> Stephen.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: 0xdeadc0de ???

[Brian Fundakowski Feldman]

On Tue, 18 Jan 2000, Jun Kuriyama wrote:

> 
> I found message below at inserting aue0 (after pccard ed0
> insert/remove).
> 
> -
> aue0: LUA-TX MELCO LUA-TX, rev 1.10/1.01, addr 2
> aue0: Ethernet address: 00:40:26:61:10:c7
> miibus0:  on aue0
> ukphy0:  on miibus0
> ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> Data modified on freelist: word 7 of object 0xc0828400 size 364 previous type USBdev 
>(0x0 != 0xdeadc0de)
> aue0: starting DAD for fe80:0003::0240:26ff:fe61:10c7
> aue0: DAD complete for fe80:0003::0240:26ff:fe61:10c7 - no duplicates found
> -
> 
> Should I track this behaviour (if I can revisit this message), or I
> can simply ignore this message?
> 

Basically, this means that you correctly enabled INVARIANT* to catch
bugs, and you found one.  Here, it seems that a USBdev is being used
after being free()d.  I'd suggest reporting it directly to Bill Paul
and Nick Hibma, since they'll be familiar with their code :)

> 
> Jun Kuriyama // [EMAIL PROTECTED]
> // [EMAIL PROTECTED]
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Crash from ^T during heavy paging

[Brian Fundakowski Feldman]

On Mon, 17 Jan 2000, Bruce Evans wrote:

> > Using the magic of :%s:p_stats->p_\([usi]\)\(u[^a-zA-Z_0-9]\):p_\1\2:g,
> > and just using vi to edit the headers too :), I submit the following to
> > you for review.  I'll be testing it in its entirety tomorrow, but I'm
> > already reasonably confident this is correct.  What do you think?
> 
> The substitution has a good chance of being correct if it sort of works
> at all :-), except global substitions give style bugs when long lines
> become shorter, etc.  About 2 lines are affected.

Nuts! :)

> > @@ -239,6 +239,9 @@
> > struct proc *p_leader;
> > struct  pasleep p_asleep;   /* Used by asleep()/await(). */
> > void*p_emuldata;/* process-specific emulator state data */
> > +   u_int64_t p_uu; /* previous user time (us) */
> > +   u_int64_t p_su; /* previous system time (us) */
> > +   u_int64_t p_iu; /* previous interrupt time (us) */
> >  };
> >  
> >  #definep_session   p_pgrp->pg_session
> 
> Bug: I think p_uu etc. are no longer initialized on fork.  They should be
> in the zeroed section.  They should be next to p_runtime and p_uticks,
> etc. for stylistic reasons.

Hm.  I would think that the intuitive thing is them being initialized
to reasonable values on a fork.  I must not be very intuitive *g*

> 
> Moving code gives style bugs when the styles in different files are
> different.  proc.h actually follows the rule about comments being filled
> like English sentences, as in the p_asleep line, except in sloppy FreeBSD
> additions like the p_emuldata line.  Don't fix this.  I already have.

I wasn't even aware of differences in language like that between files.
Maybe I'm too used to there being no sentence structure :)

Thank you, though!  I now understand the idea of header theory a bit
better.

> 
> Bruce
> 
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Crash from ^T during heavy paging

[Brian Fundakowski Feldman]

On Wed, 12 Jan 2000, Bruce Evans wrote:

> 
> Please do the work, but send it to me for review.
> 
> I didn't have a fix for this particular problem until after seeing
> your first mail about it.  It didn't make sense for P_INMEM to be so
> apparently broken without it causing problems until recently.

Using the magic of :%s:p_stats->p_\([usi]\)\(u[^a-zA-Z_0-9]\):p_\1\2:g,
and just using vi to edit the headers too :), I submit the following to
you for review.  I'll be testing it in its entirety tomorrow, but I'm
already reasonably confident this is correct.  What do you think?

> 
> Bruce

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'

Index: kern_resource.c
===
RCS file: /usr2/ncvs/src/sys/kern/kern_resource.c,v
retrieving revision 1.53
diff -u -r1.53 kern_resource.c
--- kern_resource.c 1999/11/29 11:29:03 1.53
+++ kern_resource.c 2000/01/17 07:08:31
@@ -528,7 +528,7 @@
tu += (tv.tv_usec - switchtime.tv_usec) +
(tv.tv_sec - switchtime.tv_sec) * (int64_t)100;
}
-   ptu = p->p_stats->p_uu + p->p_stats->p_su + p->p_stats->p_iu;
+   ptu = p->p_uu + p->p_su + p->p_iu;
if (tu < ptu || (int64_t)tu < 0) {
/* XXX no %qd in kernel.  Truncate. */
printf("calcru: negative time of %ld usec for pid %d (%s)\n",
@@ -542,30 +542,30 @@
iu = tu - uu - su;
 
/* Enforce monotonicity. */
-   if (uu < p->p_stats->p_uu || su < p->p_stats->p_su ||
-   iu < p->p_stats->p_iu) {
-   if (uu < p->p_stats->p_uu)
-   uu = p->p_stats->p_uu;
-   else if (uu + p->p_stats->p_su + p->p_stats->p_iu > tu)
-   uu = tu - p->p_stats->p_su - p->p_stats->p_iu;
+   if (uu < p->p_uu || su < p->p_su ||
+   iu < p->p_iu) {
+   if (uu < p->p_uu)
+   uu = p->p_uu;
+   else if (uu + p->p_su + p->p_iu > tu)
+   uu = tu - p->p_su - p->p_iu;
if (st == 0)
-   su = p->p_stats->p_su;
+   su = p->p_su;
else {
su = ((tu - uu) * st) / (st + it);
-   if (su < p->p_stats->p_su)
-   su = p->p_stats->p_su;
-   else if (uu + su + p->p_stats->p_iu > tu)
-   su = tu - uu - p->p_stats->p_iu;
+   if (su < p->p_su)
+   su = p->p_su;
+   else if (uu + su + p->p_iu > tu)
+   su = tu - uu - p->p_iu;
}
-   KASSERT(uu + su + p->p_stats->p_iu <= tu,
+   KASSERT(uu + su + p->p_iu <= tu,
("calcru: monotonisation botch 1"));
iu = tu - uu - su;
-   KASSERT(iu >= p->p_stats->p_iu,
+   KASSERT(iu >= p->p_iu,
("calcru: monotonisation botch 2"));
}
-   p->p_stats->p_uu = uu;
-   p->p_stats->p_su = su;
-   p->p_stats->p_iu = iu;
+   p->p_uu = uu;
+   p->p_su = su;
+   p->p_iu = iu;
 
up->tv_sec = uu / 100;
up->tv_usec = uu % 100;
Index: proc.h
===
RCS file: /usr2/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.98
diff -u -r1.98 proc.h
--- proc.h  1999/12/29 04:24:45 1.98
+++ proc.h  2000/01/17 06:57:17
@@ -239,6 +239,9 @@
struct proc *p_leader;
struct  pasleep p_asleep;   /* Used by asleep()/await(). */
void*p_emuldata;/* process-specific emulator state data */
+   u_int64_t p_uu; /* previous user time (us) */
+   u_int64_t p_su; /* previous system time (us) */
+   u_int64_t p_iu; /* previous interrupt time (us) */
 };
 
 #definep_session   p_pgrp->pg_session
Index: resourcevar.h
===
RCS file: /usr2/ncvs/src/sys/sys/resourcevar.h,v
retrieving revision 1.15
diff -u -r1.15 resourcevar.h
--- resourcevar.h   1999/12/29 04:24:46 1.15
+++ resourcevar.h   2000/01/17 06:56:17
@@ -47,9 +47,6 @@
 #definepstat_startzero p_ru
struct  rusage p_ru;/* stats for this proc */
struct  rusage p_cru;   /* sum of stats for reaped children */
-   u_in

Re: ATA CD-R problems, still...

[Brian Fundakowski Feldman]

Can you try this patch to src/usr.sbin/burncd, and see if things work
after that?  Thanks! (BTW, there's also an extra feature in there, hope
you don't mind :)

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'

Index: burncd.c
===
RCS file: /usr2/ncvs/src/usr.sbin/burncd/burncd.c,v
retrieving revision 1.4
diff -u -r1.4 burncd.c
--- burncd.c2000/01/15 15:51:47 1.4
+++ burncd.c2000/01/16 03:56:18
@@ -38,8 +38,9 @@
 #include 
 #include 
 #include 
+#include 
 
-#define BLOCKS 32
+#define BLOCKS 16
 
 static int fd, saved_block_size;
 void cleanup(int);
@@ -142,8 +143,13 @@
err(EX_IOERR, "ioctl(CDRIOCNEXTWRITEABLEADDR)");
 
if (!quiet) {
+   struct stat sb;
+
+   if (fstat(file, &sb) < 0)
+   err(EX_IOERR, "fstat(%s)", argv[arg]);
fprintf(stderr, "next writeable LBA %d\n", addr);
-   fprintf(stderr, "writing from file %s\n", argv[arg]);
+   fprintf(stderr, "writing from file %s - %d KB\n",
+   argv[arg], sb.st_size / (1 << 10));
}
lseek(fd, 0, SEEK_SET);
size = 0;




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

Re: ATAPI broken, but why?

[Brian Fundakowski Feldman]

On Thu, 13 Jan 2000, Soren Schmidt wrote:

> It seems Brian Fundakowski Feldman wrote:
> > I'm sure everyone's seen my e-mail and others' e-mail about ATAPI in the
> > ATA driver, at least, being broken (WRT CD-Rs).  The question is, does
> > anyone have any idea at all why?  I tried reverting to just before the
> > CDRIOC* changes, and that didn't help (using wormcontrol to test that).
> > If any of you have any hints at all, please let me know.
> 
> Uhm, if reverting the driver to the state BEFORE the change doesn't
> help, you probably should look somewhere else, as you stated once
> that that used to work. Have you change other things in the system ?
> Overclocking ? checked the cables ? can you check the drive otherwise ?

I was trying to rule out the CDRIO* changes themselves being at fault.
It seems they're not, but another person also share's my experiences
with no longer being able to write CDs now.  How about this:  I'll
find out when it broke, and perhaps we can work from there?

> 
> -Søren
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Crash from ^T during heavy paging

[Brian Fundakowski Feldman]

On Tue, 11 Jan 2000, Bruce Evans wrote:

> I broke calcru() with the monotonicity fixes (kern_resource.c rev.1.45
> (1999/03/13).  Accessing p->p_stats at interrupt time is only valid if
> p == curproc.
> 
> Fix: move the new monotonicity fields from struct pstats to struct
> proc.  I only put them in struct pstats because they logically go with
> some fields in struct rusage.
> 
> P_INMEM is probably not supposed to work in interrupt contexts.
> Checking it in ttyinfo() is a wrong fix for the bug in calcru().  It
> was committed in tty.c rev.1.119 (1999/05/22).

Do you want to do this work, or shall I take out a bit of time and do
it?  I'm wondering since quite often when someone fixes something,
you've got a similar fix already sitting in your local tree :)

> 
> Bruce

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: Crash from ^T during heavy paging

[Brian Fundakowski Feldman]

On Mon, 10 Jan 2000, Stephen McKay wrote:

> The problem is that calcru() thinks that P_INMEM means that the proc
> structure is fully and accurately populated.  But P_INMEM is one of the
> first flags set.
>
> So, calcru() and possibly some other places, are looking at a struct proc
> before it's all there.  What's the "proper" way to do it?

It should really be one of the _last_ flags set, if it's to mean anything.
I don't know how to explain the prevalance of race conditions in the old
code, except to say it probably has to do with not planning ahead.
Certainly it's not acceptable to create new race conditions now (even if
it can happen by accident).

So, here's something to defer P_INMEM til the end, when the process is
really "ready":

--- sys/kern/kern_fork.cTue Dec  7 22:11:35 1999
+++ /tmp/kern_fork.cTue Jan 11 03:32:44 2000
@@ -351,7 +351,7 @@
 * Increase reference counts on shared objects.
 * The p_stats and p_sigacts substructs are set in vm_fork.
 */
-   p2->p_flag = P_INMEM;
+   p2->p_flag = 0;
if (p1->p_flag & P_PROFIL)
startprofclock(p2);
MALLOC(p2->p_cred, struct pcred *, sizeof(struct pcred),
@@ -499,6 +499,7 @@
microtime(&(p2->p_stats->p_start));
p2->p_acflag = AFORK;
(void) splhigh();
+   p2->p_flag |= P_INMEM;
    p2->p_stat = SRUN;
setrunqueue(p2);
(void) spl0();

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

ATAPI broken, but why?

[Brian Fundakowski Feldman]

I'm sure everyone's seen my e-mail and others' e-mail about ATAPI in the
ATA driver, at least, being broken (WRT CD-Rs).  The question is, does
anyone have any idea at all why?  I tried reverting to just before the
CDRIOC* changes, and that didn't help (using wormcontrol to test that).
If any of you have any hints at all, please let me know.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

SoftUpdates crash with new code

[Brian Fundakowski Feldman]

Well, I'm having problems with SoftUpdates.  I've disabled it for now.
Here's the backtrace for the crash; more info from the crashdump is
available upon request, but I think this is a general problem, and
easily reproduced.

GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 3272704
initial pcb at 282620
panicstr: softdep_lock: locking against myself
panic messages:
---
panic: softdep_lock: locking against myself

syncing disks... panic: softdep_lock: locking against myself
Uptime: 9m58s

dumping to dev #ad/0x20001, offset 262144
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 
107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 
52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
---
#0  boot (howto=0x104) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) #0  boot (howto=0x104) at ../../kern/kern_shutdown.c:304
#1  0xc013f5d5 in panic (fmt=0xc023c6e0 "softdep_lock: locking against myself") at 
../../kern/kern_shutdown.c:554
#2  0xc01bacc5 in acquire_lock (lk=0xc026635c) at ../../ufs/ffs/ffs_softdep.c:276
#3  0xc01bfdb0 in softdep_count_dependencies (bp=0xc37131d0, wantcount=0x0) at 
../../ufs/ffs/ffs_softdep.c:4473
#4  0xc01c2f98 in ffs_fsync (ap=0xd8189b08) at ../../ufs/ffs/ffs_vnops.c:169
#5  0xc01c1b47 in ffs_sync (mp=0xc0b63000, waitfor=0x2, cred=0xc073d600, p=0xc02988a0) 
at vnode_if.h:537
#6  0xc016b893 in sync (p=0xc02988a0, uap=0x0) at ../../kern/vfs_syscalls.c:549
#7  0xc013f00b in boot (howto=0x100) at ../../kern/kern_shutdown.c:226
#8  0xc013f5d5 in panic (fmt=0xc023c6e0 "softdep_lock: locking against myself") at 
../../kern/kern_shutdown.c:554
#9  0xc01bacc5 in acquire_lock (lk=0xc026635c) at ../../ufs/ffs/ffs_softdep.c:276
#10 0xc01bcc38 in indir_trunc (ip=0xd8189c00, dbn=0x800, level=0x0, lbn=0xc, 
countp=0xd8189bf0)
at ../../ufs/ffs/ffs_softdep.c:2024
#11 0xc01bcb15 in handle_workitem_freeblocks (freeblks=0xc0c43d80) at 
../../ufs/ffs/ffs_softdep.c:1959
#12 0xc01bc562 in softdep_setup_freeblocks (ip=0xc0d08c00, length=0x0) at 
../../ufs/ffs/ffs_softdep.c:1667
#13 0xc01ba212 in ffs_truncate (vp=0xd81b1be0, length=0x0, flags=0x0, cred=0x0, 
p=0xd776fa00)
at ../../ufs/ffs/ffs_inode.c:195
#14 0xc01c3eaa in ufs_inactive (ap=0xd8189eb8) at ../../ufs/ufs/ufs_inode.c:84
#15 0xc01c8f4d in ufs_vnoperate (ap=0xd8189eb8) at ../../ufs/ufs/ufs_vnops.c:2283
#16 0xc016995a in vput (vp=0xd81b1be0) at vnode_if.h:794
#17 0xc016ccb5 in unlink (p=0xd776fa00, uap=0xd8189f80) at 
../../kern/vfs_syscalls.c:1421
#18 0xc02101da in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x0, tf_esi = 0x80601b0, 
  tf_ebp = 0xbfbff984, tf_isp = 0xd8189fd4, tf_ebx = 0x8060230, tf_edx = 0x0, 
tf_ecx = 0x0, tf_eax = 0xa, 
  tf_trapno = 0x0, tf_err = 0x2, tf_eip = 0x280aac70, tf_cs = 0x1f, tf_eflags = 
0x297, tf_esp = 0xbfbff8f8, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1057
#19 0xc0203f86 in Xint0x80_syscall ()
#20 0x804a30a in ?? ()
#21 0x80501b1 in ?? ()
#22 0x8048fa9 in ?? ()
(kgdb) 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

On Thu, 6 Jan 2000, Soren Schmidt wrote:

> You should respect the blocksize when talking to a device with a
> fixed blocklength, dont write  ! % blocksize blocks to the device..
> 

By the way, I think I've redone this enough times that it's all correct.
It's 32-bit support _outside_ of the overrun/underrun loops in atapi-all,
a bugfix for atapi-cd, and the full support for weird overrun/underrun
sizes.  The drive is still not working, but I know this has nothing to
do with it.  Think you might use this at all?  I think it's important
for stability if the driver handles overruns and underruns well, and
this makes everything full-block-size-sized.

> -Søren

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'


Index: atapi-all.c
===
RCS file: /usr2/ncvs/src/sys/dev/ata/atapi-all.c,v
retrieving revision 1.33
diff -u -r1.33 atapi-all.c
--- atapi-all.c 2000/01/07 15:51:45 1.33
+++ atapi-all.c 2000/01/08 23:50:08
@@ -558,23 +558,44 @@
*buffer = (int8_t *)&request->sense;
 
 if (request->bytecount < length) {
-   printf("%s: read data overrun %d/%d\n",
-  request->device->devname, length, request->bytecount);
+   printf("%s: read data overrun (%d buffer < %d bs), some data ignored\n",
+  request->device->devname, request->bytecount, length);
 #ifdef ATA_16BIT_ONLY
insw(request->device->controller->ioaddr + ATA_DATA, 
-(void *)((uintptr_t)*buffer), request->bytecount/sizeof(int16_t));
+(void *)*buffer, request->bytecount / sizeof(int16_t));
 #else
insl(request->device->controller->ioaddr + ATA_DATA, 
-(void *)((uintptr_t)*buffer), request->bytecount/sizeof(int32_t));
+(void *)*buffer, request->bytecount / sizeof(int32_t));
+   if (request->bytecount & sizeof(int16_t))
+   ((int16_t *)*buffer)[(request->bytecount % sizeof(int32_t)) /
+   sizeof(int16_t)] =
+   inw(request->device->controller->ioaddr + ATA_DATA);
 #endif
+   if (request->bytecount & sizeof(int8_t)) {
+   int16_t sixteen;
+
+   sixteen = inw(request->device->controller->ioaddr + ATA_DATA);
+   (*buffer)[request->bytecount - sizeof(int8_t)] =
+   *(int8_t *)&sixteen;
+   length -= sizeof(int16_t);
+   }
for (resid=request->bytecount; residdevice->controller->ioaddr + ATA_DATA);
+(void)inw(request->device->controller->ioaddr + ATA_DATA);
*buffer += request->bytecount;
request->bytecount = 0;
 }  
 else {
+#ifdef ATA_16BIT_ONLY
insw(request->device->controller->ioaddr + ATA_DATA,
-(void *)((uintptr_t)*buffer), length / sizeof(int16_t));
+(void *)*buffer, length / sizeof(int16_t));
+#else
+   insl(request->device->controller->ioaddr + ATA_DATA,
+(void *)*buffer, length / sizeof(int32_t));
+   if (length & sizeof(int16_t))
+   ((int16_t *)*buffer)[(length - (length % sizeof(int32_t))) /
+   sizeof(int16_t)] =
+   inw(request->device->controller->ioaddr + ATA_DATA);
+#endif
*buffer += length;
request->bytecount -= length;
 }
@@ -590,24 +611,46 @@
*buffer = (int8_t *)&request->sense;
 
 if (request->bytecount < length) {
-   printf("%s: write data underrun %d/%d\n",
-  request->device->devname, length, request->bytecount);
+   printf("%s: write data underrun (%d buffer < %d bs), padding\n",
+  request->device->devname, request->bytecount, length);
 #ifdef ATA_16BIT_ONLY
outsw(request->device->controller->ioaddr + ATA_DATA, 
- (void *)((uintptr_t)*buffer), request->bytecount/sizeof(int16_t));
+ (void *)*buffer, request->bytecount / sizeof(int16_t));
 #else
outsl(request->device->controller->ioaddr + ATA_DATA, 
- (void *)((uintptr_t)*buffer), request->bytecount/sizeof(int32_t));
+ (void *)*buffer, request->bytecount / sizeof(int32_t));
+   if (request->bytecount & sizeof(int16_t))
+   outw(request->device->controller->ioaddr + ATA_DATA,
+((int16_t *)*buffer)[(request->bytecount % sizeof(int32_t)) /
+sizeof(int16_t)]);
 #endif
+   if (request->bytecount & sizeof(int8_t)) {
+   int16_t sixteen;
+
+   sixteen = 0;
+   *(int8_t *)&sixteen =
+   (*buffer)[request->bytecount - sizeof(int8_t)];
+   outw(request

Re: ATA CD-R problems, still...

[Brian Fundakowski Feldman]

On Sat, 8 Jan 2000, Bryan Liesner wrote:

> On Sat, 8 Jan 2000, Brian Fundakowski Feldman wrote:
> 
> >Well, I don't know about anyone else out there having the problems I'm
> >having, but I might as well ask.  I'm using the ATA driver with the
> >following bugfix applied, otherwise the same.
> >
> 
> At the risk of sounding like an AOLer, me too.   Prior to the most
> recent changes incorporating burncd, I was able to write to my HP
> 8250i using wormcontrol.  Never burned a coaster, it was very
> reliable.  Now when I use burncd, I get WRITE_BIG errors, and then
> the driver tries endlessly to reset.  The only way out is to hit the
> big red reset button. 

To add a little bit to that, on the side-note area...  Okay, first of
all, the reason it keeps resetting is that when the timeout() is
called (which resets the controller, see ata{,pi}_reset()), the timer
which fires is in the kernel proper (!) and as such takes over all
control of the CPU.  E.g. you won't get your processes run very much
(to make an understatement).  I have been able to get a Ctrl+Alt+Del
in at the right time (between the timer being set and being fired)
to get the box rebooted, otherwise I have the same problem as you.
   Now, failing to address why the hardware is failing, there really
needs to be a better way to reset controllers.  Why don't we have
timers fire in their own kthread, one per timeout()?  I think that
this would be a very useful change, and an important one that could
be implemented before the "feature freeze" for 4.0.  Does anyone
have a better idea regarding that?
   But, don't let me take the focus away from the CD-R issue.  It's
pretty important to be able to figure out why some CD-Rs no longer
work (obviously, Soren's work :)

> -Bryan

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

ATA CD-R problems, still...

[Brian Fundakowski Feldman]

 on isa0
unknown5:  at port 
0x4d0-0x4d1,0xcf8-0xcff,0x3f7,0x4000-0x403f,0x5000-0x501f,0x480-0x49f,0x40b,0x4d6,0x73,0x92,0xb0-0xb3,0x10
 iomem 0xfffe-0x,0x10-0x7ff on isa0
unknown:  can't assign resources
unknown:  can't assign resources
unknown6:  at port 0x3f0-0x3f5 irq 6 drq 2 on isa0
unknown:  can't assign resources
DUMMYNET initialized (000106)
IP packet filtering initialized, divert enabled, rule-based forwarding enabled, 
logging limited to 100 packets/entry by default
IPsec: Initialized Security Association Processing.
ad0:  ATA-4 disk at ata0 as master
ad0: 6103MB (12500460 sectors), 13228 cyls, 15 heads, 63 S/T, 512 B/S
ad0: 16 secs/int, 1 depth queue, UDMA33
ad1:  ATA-4 disk at ata1 as master
ad1: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S
ad1: 16 secs/int, 1 depth queue, UDMA33
ad2:  ATA-0 disk at ata3 as master
ad2: 1554MB (3183264 sectors), 3158 cyls, 16 heads, 63 S/T, 512 B/S
ad2: 16 secs/int, 1 depth queue, WDMA2
acd0:  CD-R drive at ata2 as master
acd0: read 1377KB/s (1377KB/s) write 344KB/s (344KB/s), 512KB buffer, PIO3
acd0: Reads: CD-R, CD-DA stream
acd0: Writes: CD-R, test write
acd0: Audio: play, 2 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: no/blank disc inside, unlocked
Mounting root from ufs:/dev/ad0s1a
dc0:  port 0xde00-0xdeff mem 0xeefeff00-0xeefe 
irq 11 at device 16.0 on pci0
dc0: Ethernet address: 00:80:c6:f9:50:a6
dc0: supplying EUI64: 00:80:c6:ff:fe:f9:50:a6
miibus0:  on dc0
dcphy0:  on miibus0
dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: starting DAD for fe80:0005::0280:c6ff:fef9:50a6
dc0: DAD complete for fe80:0005::0280:c6ff:fef9:50a6 - no duplicates found
acd0: WRITE_BIG - ILLEGAL REQUEST asc=10 ascq=00 error=00
acd0: WRITE_BIG - ILLEGAL REQUEST asc=10 ascq=00 error=00
acd0: WRITE_BIG - ILLEGAL REQUEST asc=10 ascq=00 error=00

I don't have any non-default ATA options in my kernel config, by the way.
Has anyone else experienced this, or does anyone know what it's all
about?

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

On Thu, 6 Jan 2000, Soren Schmidt wrote:

> It seems Brian Fundakowski Feldman wrote:
> > How about this?  It's mostly the changes in your patch, but it also takes
> > into account non-int{8,16}_t-sizing/alignment.  It also takes care of the
> > truncation problem when you use outsl and insl, as part of that.  Please
> > review it, as I think it should be the right thing to do.
> 
> Hmm, sortof. In the real world we should newer ever see partial
> transfers, they should always be of N * DEV_BSIZE, so this is
> a bitt overkill. However some of the internal ATAPI handling
> use odd sizes for modes etc, but they are all at least 16 bit
> aligned, so 8 bit alignment is not needed, I'll have to check
> if we need 16 bit alignment, I can't remember ofhand...

It's just as well. It's almost 4 AM and I've just about given up on getting
this all working.  Anyway, if everything has to be DEV_BSIZE, then I guess
that would simplify things, except when I try, say, writing 4697 bytes
as an audio blocksize (2 * 2352 - 7), it goes all the way through the
acdstrategy as 4697... I don't know why DEV_BSIZE isn't respected, then,
but I suppose Poul might be able to help here?
Anyway, for now, I'd just be satisfied with having atapi-all.c
corrected WRT the request->bytecount and length mixup.  I've been working
on this for four hours, have no clue what I'm doing wrong, and have
school tomorrow.

> 
> -Søren
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

How about this?  It's mostly the changes in your patch, but it also takes
into account non-int{8,16}_t-sizing/alignment.  It also takes care of the
truncation problem when you use outsl and insl, as part of that.  Please
review it, as I think it should be the right thing to do.

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'


Index: atapi-all.c
===
RCS file: /usr2/ncvs/src/sys/dev/ata/atapi-all.c,v
retrieving revision 1.29
diff -u -r1.29 atapi-all.c
--- atapi-all.c 2000/01/03 10:26:56 1.29
+++ atapi-all.c 2000/01/05 23:37:27
@@ -552,23 +552,39 @@
*buffer = (int8_t *)&request->sense;
 
 if (request->bytecount < length) {
-   printf("%s: read data overrun %d/%d\n",
+   printf("%s: read data buffer too small (bs %d > buflen %d)\n",
   request->device->devname, length, request->bytecount);
 #ifdef ATA_16BIT_ONLY
insw(request->device->controller->ioaddr + ATA_DATA, 
-(void *)((uintptr_t)*buffer), length / sizeof(int16_t));
+(void *)*buffer, request->bytecount / sizeof(int16_t));
 #else
insl(request->device->controller->ioaddr + ATA_DATA, 
-(void *)((uintptr_t)*buffer), length / sizeof(int32_t));
+(void *)*buffer, request->bytecount / sizeof(int32_t));
+   if (request->bytecount & sizeof(int16_t)) {
+*(int16_t *)(*buffer + request->bytecount -
+   (sizeof(int16_t) + (request->bytecount & sizeof(int8_t =
+   inw(request->device->controller->ioaddr + ATA_DATA);
+length -= sizeof(int16_t);
+   }
 #endif
-   for (resid=request->bytecount; residdevice->controller->ioaddr + ATA_DATA);
+   if (request->bytecount & sizeof(int8_t)) {
+(*buffer)[request->bytecount - sizeof(int8_t)] =
+inb(request->device->controller->ioaddr + ATA_DATA);
+(void)inb(request->device->controller->ioaddr + ATA_DATA);
+length -= sizeof(int8_t);
+   }
+   resid = request->bytecount & ~(sizeof(int16_t) | sizeof(int8_t));
+   for (; resid < length; resid += sizeof(int16_t))
+(void)inw(request->device->controller->ioaddr + ATA_DATA);
+   *buffer += request->bytecount;
+   request->bytecount = 0;
 }  
-else
+else {
insw(request->device->controller->ioaddr + ATA_DATA,
-(void *)((uintptr_t)*buffer), length / sizeof(int16_t));
-request->bytecount -= length;
-*buffer += length;
+(void *)*buffer, length / sizeof(int16_t));
+   *buffer += length;
+   request->bytecount -= length;
+}
 }
 
 static void
@@ -581,23 +597,38 @@
*buffer = (int8_t *)&request->sense;
 
 if (request->bytecount < length) {
-   printf("%s: write data underrun %d/%d\n",
-  request->device->devname, length, request->bytecount);
+   printf("%s: write data underrun (buflen %d < bs %d), padding written\n",
+  request->device->devname, request->bytecount, length);
 #ifdef ATA_16BIT_ONLY
outsw(request->device->controller->ioaddr + ATA_DATA, 
- (void *)((uintptr_t)*buffer), length / sizeof(int16_t));
+ (void *)*buffer, request->bytecount / sizeof(int16_t));
 #else
outsl(request->device->controller->ioaddr + ATA_DATA, 
- (void *)((uintptr_t)*buffer), length / sizeof(int32_t));
+ (void *)*buffer, request->bytecount / sizeof(int32_t));
+   if (request->bytecount & sizeof(int16_t)) {
+   outw(request->device->controller->ioaddr + ATA_DATA,
+*(int16_t *)(*buffer + request->bytecount -
+(sizeof(int16_t) + (request->bytecount & sizeof(int8_t);
+   length -= sizeof(int16_t);
+   }
 #endif
-   for (resid=request->bytecount; residbytecount & sizeof(int8_t)) {
+   outb(request->device->controller->ioaddr + ATA_DATA,
+(*buffer)[request->bytecount]);
+   length -= sizeof(int8_t);
+   }
+   resid = request->bytecount & ~(sizeof(int16_t) | sizeof(int8_t));
+   for (; resid < length; resid += sizeof(int16_t))
 outw(request->device->controller->ioaddr + ATA_DATA, 0);
+   *buffer += request->bytecount;
+   request->bytecount = 0;
 }
-else
+else {
outsw(request->device->controller->ioaddr + ATA_DATA, 
- (void *)((uintptr_t)*buffer), length / sizeof(int16_t));
-request->bytecount -= length;
-*buffer += length;
+ (void *)*buffer, length / sizeof(int16_t));
+   *buffer += length;
+   request->bytecount -= length;
+}
 }
 
 static void 



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

Re: ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

On Wed, 5 Jan 2000, Soren Schmidt wrote:

> Try this patch instead, it should do the right thing..

Since they're functionally the same, sure, I wouldn't mind either
way :)

> 
> -Søren
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

On Tue, 4 Jan 2000, Soren Schmidt wrote:

> The problem here is that you will then do a lot of unneeded padding
> as the driver will attempt to pad to the blocksize used which is not
> wanted. You HAVE to use the right blocksize especially for audio, or
> you will get "silent" ie zero padded blocks on disk, and thats not
> what you want is it ?

I used a multiple of the blocksize, and it works fine, except for on
the very last bit of data.  The very last bit of data is what causes
an underrun, and the code that's there for overrun/underrun is
wrong right now.  For underrun, it ends up writing the underlying
blocksize length from the user buffer of _less_than_that_size_, then
it writes (blocksize - user buffer size) _more_ zeroed data!  This
promptly locks up the IDE bus with my CD-R.  That's what the patch was
about and you didn't say anything about; yes, I know that blocksizes
should be matched perfectly and padded perfectly to prevent the ATA
driver from having to handle the underrun/overrun cases, but the
current handling is/was still broken.

>  
> -Søren
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

On Tue, 4 Jan 2000, Soren Schmidt wrote:

> Either the patch is very short, or you forgot to include it :)

*LOL*  I can't believe I did that :)  It'll be on this one!!

> 
> The ATA_16BIT_ONLY thing is to only do 16bit wide inb/outb instructions
> as old ISA HW don't allow 32bit wide access. This option is now deprecated
> as it is switched on automagically for ISA cards.

Is all data a multiple of 4 bytes, though?

> 
> You _should_ _always_ have dd (or whatever you use) pad the output to the 
> given blocksize, or you will run into problems. 

IMHO, it should be better to use a larger multiple of block size (2352)
to not perform so many operations in userland (since the kernel does a
great job of doing writes in the right size in order).  Then, it would
be pessimal to use "conv=osync" because you'd lose more room from the
media.  But anyway, the padding should work properly, no matter what :)

Thanks for the prompt reply!  Now I'll remember that patch...

> -Søren

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'

cvs diff: Diffing .
Index: atapi-all.c
===
RCS file: /usr2/ncvs/src/sys/dev/ata/atapi-all.c,v
retrieving revision 1.28
diff -u -r1.28 atapi-all.c
--- atapi-all.c 1999/12/21 20:18:55 1.28
+++ atapi-all.c 2000/01/04 06:26:31
@@ -71,6 +71,10 @@
 /* defines */
 #define ATAPI_MAX_RETRIES  5
 
+/* This is temporary until I can read up more on the specs WRT packet length. */
+#undef ATA_16BIT_ONLY
+#defineATA_16BIT_ONLY
+
 static __inline int
 apiomode(struct atapi_params *ap)
 {
@@ -546,58 +550,70 @@
 atapi_read(struct atapi_request *request, int32_t length)
 {
 int8_t **buffer = (int8_t **)&request->data;
+int32_t minlen = min(request->bytecount, length);
 int32_t resid;
 
 if (request->ccb[0] == ATAPI_REQUEST_SENSE)
*buffer = (int8_t *)&request->sense;
 
-if (request->bytecount < length) {
-   printf("%s: read data overrun %d/%d\n",
-  request->device->devname, length, request->bytecount);
+if (minlen < length) {
+   printf("%s: read data overrun (%d < %d); some data discarded.\n",
+  request->device->devname, minlen, length);
 #ifdef ATA_16BIT_ONLY
insw(request->device->controller->ioaddr + ATA_DATA, 
-(void *)((uintptr_t)*buffer), length / sizeof(int16_t));
+(void *)((uintptr_t)*buffer), minlen / sizeof(int16_t));
 #else
insl(request->device->controller->ioaddr + ATA_DATA, 
-(void *)((uintptr_t)*buffer), length / sizeof(int32_t));
+(void *)((uintptr_t)*buffer), minlen / sizeof(int32_t));
 #endif
-   for (resid=request->bytecount; residdevice->controller->ioaddr + ATA_DATA);
-}  
+   for (resid = minlen; resid < length; resid += sizeof(int16_t))
+(void)inw(request->device->controller->ioaddr + ATA_DATA);
+}
 else
+#ifdef ATA_16BIT_ONLY
insw(request->device->controller->ioaddr + ATA_DATA,
-(void *)((uintptr_t)*buffer), length / sizeof(int16_t));
-request->bytecount -= length;
-*buffer += length;
+(void *)((uintptr_t)*buffer), minlen / sizeof(int16_t));
+#else
+   insl(request->device->controller->ioaddr + ATA_DATA,
+(void *)((uintptr_t)*buffer), minlen / sizeof(int32_t));
+#endif
+request->bytecount -= minlen;
+*buffer += minlen;
 }
 
 static void
 atapi_write(struct atapi_request *request, int32_t length)
 {
 int8_t **buffer = (int8_t **)&request->data;
+int32_t minlen = min(request->bytecount, length);
 int32_t resid;
 
 if (request->ccb[0] == ATAPI_REQUEST_SENSE)
*buffer = (int8_t *)&request->sense;
 
-if (request->bytecount < length) {
-   printf("%s: write data underrun %d/%d\n",
-  request->device->devname, length, request->bytecount);
+if (minlen < length) {
+   printf("%s: write data underrun (%d < %d); padding to full length.\n",
+  request->device->devname, minlen, length);
 #ifdef ATA_16BIT_ONLY
outsw(request->device->controller->ioaddr + ATA_DATA, 
- (void *)((uintptr_t)*buffer), length / sizeof(int16_t));
+ (void *)((uintptr_t)*buffer), minlen / sizeof(int16_t));
 #else
outsl(request->device->controller->ioaddr + ATA_DATA, 
- (void *)((uintptr_t)*buffer), length / sizeof(int32_t));
+ (void *)((uintptr_t)*buffer), minlen / sizeof(int32_t));
 #endif
-   for (resid=request->bytecount; residdevice->controller->ioaddr + ATA_DATA, 0);
 }
 else
+#ifdef ATA_16BI

Re: ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

On Tue, 4 Jan 2000, Brian Fundakowski Feldman wrote:

>Anyone else experiencing lockups when an underrun/overrun occurs, try
> this patch; it has fixed the problem for me, and now I'm on my way to
> writing music CDs :)  The current way to hack around that bug must be
> to use the "obs" operand to dd(1), since that's what came naturally to
> me :)

Correction: I meant using "conv=osync" as an operand to dd(1), not just
"bs"/"obs".

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

ATA atapi-all.c problems/fixes/cleanups

[Brian Fundakowski Feldman]

I just noticed a problem with the ATA driver with my (not quite, but to me)
new CD-R drive.  The behavior is that underruns and overruns are handled
incorrectly, due to a mixup between variables.  The end result is that
too much data is sent to the drive and it chokes, borking my entire 2nd ATA
bus and thereforeo my box.
   Enclosed is my fix in the form of a patch to atapi-all.c.  The changes
are:
* general cleanups
* the bugfixes
* make the {over,under}run messages easier to understand/more helpful
* more use of ATA_16BIT_ONLY and *l functions to maintain consistency
I'm pretty certain that the bugfixes are correct, since it fixed the problem
for me, but I don't know about the ATA_16BIT_ONLY usage.  My uncertainty
there lies in wondering if packets have to be a certain modulus.  From the
code, I'd assume that all packets would have a modulus of 4 bytes.  Is this
correct?
   Anyone else experiencing lockups when an underrun/overrun occurs, try
this patch; it has fixed the problem for me, and now I'm on my way to
writing music CDs :)  The current way to hack around that bug must be
to use the "obs" operand to dd(1), since that's what came naturally to
me :)

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: [Majordomo@FreeBSD.ORG: Majordomo results: which]

[Brian Fundakowski Feldman]

On Sun, 2 Jan 2000, Kip Macy wrote:

> 
> Any pointers to web pages on setting up a killfile? The signal to noise
> ratio on this list is dropping rapidly.

I haven't done it myself, but I know that you can read some of the
documentation for procmail (/usr/ports/mail/procmail) and easily
forward certain mail to /dev/null.  If you want an example, I'm
certain I could come up with one for you :)

>   -Kip

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: new PCM problems

[Brian Fundakowski Feldman]

On Sun, 2 Jan 2000, Kenneth Wayne Culver wrote:

> OK, there is still the static problem with the pcm driver with a ViBRA16X
> soundcard. It also seems that the problem with xmms's analyzer is gone.
> However, now whenever a sound that is shorter than roughly 1 second or so
> plays, it gets cut short. The sound doesn't completely play. I just
> thought I'd let someone know what is going on here on my -CURRENT box.

I'm noticing the exact same thing.  I'll CC this to cg and tanimura,
since they're the big maintainers of the driver.

> =
> | 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/|
> =========

(I didn't know you lived so close :)

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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

Re: multiple cd devices

[Brian Fundakowski Feldman]

On Fri, 31 Dec 1999, Chuck Robey wrote:

> On Fri, 31 Dec 1999, Brian Fundakowski Feldman wrote:
> 
> > The way certain devices, like cd with its monotonically increasing counter
> > where devices are probed in order and assigned device based on precedence
> > and not hardwiring/controller connection, work is consistent between
> > the kernel and MAKEDEV.  If you have 2 cd devices, you have cd0 and cd1,
> > so MAKEDEV accepts "cd2" for "two cd devices".  All CD devices work
> > that way.  Disks don't, because there is potential for hard-wiring
> > there, and will often be gaps.
> 
> Why are "certain" devices wildly different than all other ones?  I've
> never encountered that kind of syntax before, and I can't see that it's
> documented anywhere at all.  Certainly, MAKEDEV itself (in it's
> comments) treats cd* just like all the others, specifying that the number
> following is a unit number, and *not* a quantity.  I don't know when this
> happened, but it's surely not obvious.  Not one word in the handbook,
> either.

*shrug*  This is the only rationality I could think of.  Obviously, this
breaks POLA, so it should be changed (with ample warning).

> 
> In fact, according to cd(4), you *can* specify the unit number:
> 
> ... Prior to FreeBSD
> 2.1, the first device found will be attached as cd0 the next, cd1, etc.
> Beginning in FreeBSD 2.1 it is possible to specify what cd unit a device
> should come on line as; refer to scsi(4) for details on kernel configura-
> tion.
> 
> That makes this odd setup even odder.  Can't understand why this was done.

So maybe it's just hysterical raisins.  I'm not saying I like the behavior,
just that I understand what that MAKEDEV behavior is.

> 
> 
> Chuck Robey| Interests include C & Java programming,
> New Year's Resolution:  I  | electronics, communications, and
> will not sphroxify gullible| signal processing.
> people into looking up | I run picnic.mat.net: FreeBSD-current(i386) and
> fictitious words in the|  jaunt.mat.net : FreeBSD-current(Alpha)|
> dictionary.|
> 
> 

-- 
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'



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