IPv6 locking crash (recursion)
Has anyone else tried out the most basic IPv6 test: ndp -I iface and
then ping6 fe80::normal address without %iface 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 ?)
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
ums0: 3 buttons and Z dir. uhub5: Texas Instruments TUSB2046 hub, class 9/0, rev 1.10/1.25, addr 5 uhub5: 4 ports with 4 removable, bus powered umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 7 umass0: Get Max Lun not supported (STALLED) pcm0: CMedia CMI8738 port 0xc800-0xc8ff irq 2 at device 4.0 on pci2 dc0: ADMtek AN985 10/100BaseTX port 0xc400-0xc4ff mem 0xeb80-0xeb8003ff irq 5 at device 5.0 on pci2 dc0: Ethernet address: 00:20:78:0f:88:c9 miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: HighPoint HPT366 UDMA66 controller 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: HighPoint HPT366 UDMA66 controller 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: MII bus on xl0 ukphy1: Generic IEEE 802.3u media interface on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) 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: Parallel port bus on ppc0 ppbus0: IEEE1284 device found Probing for PnP devices on ppbus0: lpt0: Printer 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: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 orm0: Option ROMs at iomem 0xcc000-0xc,0xc-0xc9fff on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA 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 WDC WD800BB-32BSA0 [155061/16/63] at ata0-master UDMA100 GEOM: create disk ad1 dp=0xc239bd70 ad1: 43979MB IBM-DTLA-307045 [89355/16/63] at ata1-master UDMA100 acd0: CDROM FX322M 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: SanDisk ImageMate II 1.30 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
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
snprintf_func, 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)
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 stdio.h
#include unistd.h
#include stdlib.h
#include sys/types.h
#include sys/mman.h
#include fcntl.h
#include sys/stat.h
#include machine/param.h
#include errno.h
/*
** 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
) {
/* 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
vnode locking screwed up in src/sys/ufs/ffs/ffs_snapshot.c:ffs_snapshot()
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
kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
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: SanDisk ImageMate II 1.30 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
USB detach crashes possibly fixed
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.54r2=1.55f=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)
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 sys/param.h
+#include sys/mount.h
#include sys/time.h
#include signal.h
#include libutil.h
@@ -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?
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
quick informal survey: OpenSSH broken?
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
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
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
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: cvs commit: src/secure/lib/libcrypto Makefile Makefile.inc
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
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: panic: reducing sbsize: lost count, uid = 1001
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
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: Why no CDR ioctls for SCSI cds?
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
Re: make buildworld br0ken in libutil
On Tue, 22 Aug 2000, Garrett Wollman wrote:
On Tue, 22 Aug 2000 17:53:09 +0200, Jeroen Ruigrok van der Werven
[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
Anyone have newmidi working?
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
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
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
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 sys/tty.h' which in turn has the line: #include sys/select.h /* 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: cvs commit: src/sys/sys select.h
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: sort(1) broken?
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
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: snes9x
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
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: randomdev entropy gathering is really weak
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: fcntl and /dev/random
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: randomdev entropy gathering is really weak
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 sys/systm.h
#include sys/types.h
#include sys/queue.h
+#include sys/kthread.h
#include sys/linker.h
#include sys/libkern.h
#include sys/mbuf.h
@@ -72,4 +73,23 @@
nanotime(timebuf);
(*reap)(timebuf, entropy, count, bits, frac, origin);
}
+}
+
+/*
+ * Helper routines to let kthread_exit() do its stuff properly (i.e. no crash).
+ */
+void
+set_wakeup(int *var, int value
Re: Mouse behaving funny since 5.0-CURRENT upgrade
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
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
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: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking
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
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: Recent -current Performance Drop?
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
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?
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?
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
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?
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?
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: ed driver broken in today's -CURRENT?
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?
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?
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?
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?
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 have OpenSSH + X11-fwd working?
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?
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?
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 able to verify the fix for (was Re: panic: vm_object_shadow:source object has OBJ_ONEMAPPING set.)
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
Anyone have OpenSSH + X11-fwd working?
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: Anyone have OpenSSH + X11-fwd working?
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
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
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: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
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.
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.
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.
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.
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: Netscape 6 Linux pre-release, got it going.
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 2conftest.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
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
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
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: breakage still in sys/systm.h
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: Dynamic sysctls - patches for review
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: [PATCH] Fix login.conf, expiration, BSD compatibility in OpenSSH
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
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.
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: After last ATAPI update system doesn't boot if modules loadedby /boot/loader.
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: [HEADS UP] xinstall/setflags (was Re: cvs commit: src/share/
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/
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
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: Crash from ^T during heavy paging
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: 0xdeadc0de ???
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: MII bus on aue0 ukphy0: Generic IEEE 802.3u media interface 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
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_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) */
#definepstat_endzero pstat_startcopy
#definepstat_startcopy p_timer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI broken, but why?
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
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
Re: Crash from ^T during heavy paging
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
ATAPI broken, but why?
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
Re: ATA atapi-all.c problems/fixes/cleanups
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; residlength; resid+=sizeof(int16_t))
-inw(request-device-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-device-controller-ioaddr + ATA_DATA, sixteen);
+ length -= sizeof(int16_t);
+ }
for (resid=request-bytecount; residlength; resid+=sizeof(int16_t))
outw(request-device-controller-ioaddr + ATA_DATA, 0);
*buffer += request-bytecount;
request-bytecount = 0;
}
else {
- outsw(req
SoftUpdates crash with new code
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
ATA CD-R problems, still...
irq 7 drq 3 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 pps0: Pulse per second Timing Interface on ppbus 0 unknown0: PNP0c01 at iomem 0-0x9,0xe-0xf on isa0 unknown: PNP can't assign resources unknown1: PNP0200 at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: PNP0100 at port 0x40-0x43 irq 0 on isa0 unknown3: PNP0b00 at port 0x70-0x71 irq 8 on isa0 unknown: PNP0303 can't assign resources unknown: PNP0800 can't assign resources unknown4: PNP0c04 at port 0xf0-0xff irq 13 on isa0 unknown5: PNP0a03 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: PNP0501 can't assign resources unknown: PNP0400 can't assign resources unknown6: PNP0700 at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 unknown: PNP0f13 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: ST36422A/3.04 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: WDC AC310100B/32.02S32 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: Maxtor 71626 AP/QA3C1D20 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: CR-2801TE/1.10 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: Macronix 98715/98715A 10/100BaseTX 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: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface 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 CD-R problems, still...
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
Re: ATA atapi-all.c problems/fixes/cleanups
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
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
ATA atapi-all.c problems/fixes/cleanups
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: ATA atapi-all.c problems/fixes/cleanups
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
Re: ATA atapi-all.c problems/fixes/cleanups
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; residlength; resid+=sizeof(int16_t))
-inw(request-device-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; residlength; resid+=sizeof(int16_t))
+ for (resid = minlen; resid length; resid += sizeof(int16_t))
outw(request-device-controller-ioaddr + ATA_DATA, 0);
}
else
+#ifdef ATA_16BIT_ONLY
outsw(request-device-controller-ioaddr + ATA_DATA,
- (void *)((uintptr_t)*buffer), length /
Re: new PCM problems
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: [Majordomo@FreeBSD.ORG: Majordomo results: which]
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: multiple cd devices
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
Re: gcc compiler problem part deux
On Fri, 31 Dec 1999, Peter Jeremy wrote:
Last time I checked (I haven't moved to the latest gcc, so I can't
confirm it there), one significant difference between 'cc -E' and
/usr/libexec/cpp was that the latter would read from a pipe, whilst
the former wouldn't. This can make converting to 'cc -E' a
non-trivial exercise.
Huh? Non-trivial?
{"/home/green"}$ echo __FreeBSD__ | cc -E -
# 1 ""
4
Peter
--
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
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. -- 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: sh(1) broken caching [was: Re: Broken sh(1)?]
On Fri, 17 Dec 1999, Martin Cracauer wrote: I still think we should *seriously* consider switching to pdksh. As I said before, pdksh has other bugs. Also we would loose all the PRs we received in the past. This testing effort by our user base is a valuable resource. From the tests I ran on all available shells, only bash2 is considerably better than the other shells, pdksh has other bugs than our ash, not less. HAHAHAHAHAHAHAHAHAHAhahahahahahahahahahahaha *cough, HACK, wheeze*. Ahem. Heh, bash2 considerably better. *continues ROFL* Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 -- 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: sh(1) broken caching [was: Re: Broken sh(1)?]
Over the last year, I did an extensive amount of testinging on bourne shell behaviour. bash2 was the only free sh clone that I never had to complain over. I'm surprised. Is there something substantially you'd like to contribute to the discussion, like - say - an example where bash-2.03 doesn't work well? It's definitely broken on some of my scripts before. If you want me to go try to find one of those cases, I will. If your experience is based on old bash1 stuff, forget it. bash got improved greatly since it is used as the standard shell for a UNIX clone in wide use. Just like our shell improved from the beatings it got because it has been the standard script-executing shell on FreeBSD and NetBSD for (together) 10 years now. ISTR that bash1 had fundamental design flaws; it's been redesigned? Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 -- 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: OpenSSL update
On Thu, 9 Dec 1999, Kris Kennaway wrote: Due to time constraints (exams) I haven't been able to do much more towards the OpenSSL build infrastructure (specifically, jumping through the requisite hoops for US stupidity). I have it building fine, although compiling without RSA seems broken in openssl 0.9.4. Unfortunately, the openssl binary seems to depend nontrivially on both libcrypto and libssl, so we can't get away with just importing the former, without some recoding. Why don't you want libssl, too? If we don't have that, then we'll end up having to install the port for using SSL and there will be redundancy (wasted space) and two copies of OpenSSL to maintain, still. Since I'm flying back home to australia next tuesday, and we have a feature freeze for -current coming up, what I'll probably do is just import all of openssl into the international repository, and enable the build only for people who have defined USA_RESIDENT==NO. When I get back in January I can get the munged version (i.e. w/o RSA sources, optionally building with RSAREF) imported and enabled for US people, as well as solving the binary distribution problem. The alternative, given the feature freeze, seems to be to forgo any kind of enhanced crypto support in 4.x, which would suck. Sound okay to everyone? Sounds great. I hope this means I get to import OpenSSH! Kris -- 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: HEADSUP: wd driver will be retired!
On Wed, 8 Dec 1999, Soren Schmidt wrote: It seems Julian Elischer wrote: please do not remove it.. And why is that ?? There is no point in having done a new one then, and you guys have known I've been working on this for ages so this cannot come as a surprise to anybody... The same thing is about to apply to the woxware sound code, we have a new shiny system that works and is much better designed... ATA doesn't do ESDI, does it? Therefore, wd(4) should still be available. NewPCM doesn't work with all the equipment VoxWare does, does it? I don't want to lose my SB16 (non-PnP) FM, certainly. -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
