Sharity Light
Hi, What way can I mount directory from NT server in boot process? (shlight //Sever/dir /mnt_point ). This instruction placed in /usr/local/etc/rc.d has no result. Piotr Wozniak To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/usr.bin/kdump mkioctls
On Wed, Aug 02, 2000 at 12:29:40PM +0700, Nickolay Dudorov wrote: In article [EMAIL PROTECTED] you wrote: ru 2000/08/01 01:15:06 PDT Modified files: usr.bin/kdumpmkioctls Log: Fix an off-by-nine error when building a list of includes. Revision ChangesPath 1.17 +2 -2 src/usr.bin/kdump/mkioctls After this commit newly generated 'ioctl.c' includes net/if_ieee80211.h which used 'ETHER_ADDR_LEN' defined in net/ethernet.h which is not included in 'ioctl.c'. With the next patch I can make "usr.bin/kdump" and "usr.bin/truss". Fixed as of src/usr.bin/kdump/mkioctls,v 1.18, thanks! -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Custom ISO Images
dear All, i need to build a large number of machine with a customer distribution based on 4.1-RELEASE are there any pointers or help you can give me on how to create an ISO image of my distribution ? -- Marc Teichtahl Manager, Data Network DesignVersatel Telecom "We *WILL* Deliver !" NASDAQ: VRSA AEX:VRSA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Custom ISO Images
On Wed 2000-08-02 (11:05), Marc Teichtahl wrote: i need to build a large number of machine with a customer distribution based on 4.1-RELEASE are there any pointers or help you can give me on how to create an ISO image of my distribution ? cd /usr/src/release make release You might need to adjust a few things, though ;) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp
Hi, Below I have part of ppp.log. Could you tell me what the fifth line does mean? What is CD? When I try to connect using ATDT12345 I get message 'BUSY'. -- Aug 2 11:57:11 sec ppp[205]: tun0: Phase: bundle: Establish Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: closed - opening Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: Connected! Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: opening - carrier Aug 2 11:57:12 sec ppp[205]: tun0: Phase: deflink: /dev/cuaa1 doesn't support CD -- what does it mean?? Aug 2 11:57:12 sec ppp[205]: tun0: Phase: deflink: carrier - ready -- Piotr Wozniak To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ppp
On Wed, 2 Aug 2000, Piotr [iso-8859-1] Woniak wrote: Hi, Below I have part of ppp.log. Could you tell me what the fifth line does mean? What is CD? Carrier Detect? When I try to connect using ATDT12345 I get message 'BUSY'. -- Aug 2 11:57:11 sec ppp[205]: tun0: Phase: bundle: Establish Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: closed - opening Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: Connected! Aug 2 11:57:11 sec ppp[205]: tun0: Phase: deflink: opening - carrier Aug 2 11:57:12 sec ppp[205]: tun0: Phase: deflink: /dev/cuaa1 doesn't support CD -- what does it mean?? Aug 2 11:57:12 sec ppp[205]: tun0: Phase: deflink: carrier - ready -- Piotr Wozniak Any relation? :) - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic in pmap_clear_reference()
I keep getting panics on -current since mid juli, they seem to
always accour here:
IdlePTD 3264512
initial pcb at 299f00
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02133a0
stack pointer = 0x10:0xcbffdf34
frame pointer = 0x10:0xcbffdf3c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (pagedaemon)
interrupt mask = net bio cam
trap number = 12
panic: page fault
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc0160fa0 in poweroff_wait (junk=0xc0249a0f, howto=-872457120)
at ../../kern/kern_shutdown.c:553
#2 0xc0214fb9 in trap_fatal (frame=0xcbffdef4, eva=262144)
at ../../i386/i386/trap.c:929
#3 0xc0214c91 in trap_pfault (frame=0xcbffdef4, usermode=0, eva=262144)
at ../../i386/i386/trap.c:822
#4 0xc0214863 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1072231923, tf_esi = 0, tf_ebp = -872423620,
tf_isp = -872423648, tf_ebx = 262144, tf_edx = 0, tf_ecx = -1066433920,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071565920, tf_cs = 8,
tf_eflags = 66054, tf_esp = -1068397780, tf_ss = 0})
at ../../i386/i386/trap.c:427
#5 0xc02133a0 in pmap_clear_reference (m=0xc0518b2c)
at ../../i386/i386/pmap.c:3012
#6 0xc01e9353 in vm_pageout_scan () at ../../vm/vm_pageout.c:713
#7 0xc01e9f38 in vm_pageout () at ../../vm/vm_pageout.c:1370
#8 0xc020a36c in fork_trampoline ()
This is happening on 3 different machines now, at first I thought
it was bad HW, but since its always here and on 3 machines thats
not likely anymore
Peter ?? Matt ?? Anybody ??
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
World breakage in usr.bin/kdump
cc -march=pentium -Os -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:94: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:80: warning: this is the location of the previous definition In file included from ioctl.c:63: /usr/obj/usr/src/i386/usr/include/net/if_ieee80211.h:14: `ETHER_ADDR_LEN' undeclared here (not in a function) /usr/obj/usr/src/i386/usr/include/net/if_ieee80211.h:15: `ETHER_ADDR_LEN' undeclared here (not in a function) /usr/obj/usr/src/i386/usr/include/net/if_ieee80211.h:16: `ETHER_ADDR_LEN' undeclared here (not in a function) *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in usr.bin/kdump
On Wed, 02 Aug 2000 09:19:36 -0400, Donn Miller wrote: In file included from ioctl.c:63: /usr/obj/usr/src/i386/usr/include/net/if_ieee80211.h:14: `ETHER_ADDR_LEN' undeclared here (not in a function) I'm pretty sure this was fixed several hours ago. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
More compile errors in current (if_dc.c)
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../pci/if_dc.c ../../pci/if_dc.c: In function `dc_setcfg': ../../pci/if_dc.c:1228: `DC_WDOG_CTLWREN' undeclared (first use in this function) ../../pci/if_dc.c:1228: (Each undeclared identifier is reported only once ../../pci/if_dc.c:1228: for each function it appears in.) -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More compile errors in current (if_dc.c)
On Wed, 02 Aug 2000 08:31:59 EST, Stephen Hocking wrote: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extension s -ansi -g -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../pci/if_dc.c ../../pci/if_dc.c: In function `dc_setcfg': ../../pci/if_dc.c:1228: `DC_WDOG_CTLWREN' undeclared (first use in this function) ../../pci/if_dc.c:1228: (Each undeclared identifier is reported only once ../../pci/if_dc.c:1228: for each function it appears in.) You can get around this by backing out rev 1.19 of if_dc.c . As developers get progressively slacker about checking their changes, you're going to have to learn to follow your cvs-all mail more closely. :-) Of course, that doesn't apply in this case, since the breakage was immediately merged onto the RELENG_4 branch. ;-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More compile errors in current (if_dc.c)
Yeah - I was just trying to express my irritation without being overly nasty. Beats me why thing are commited without being compiled though. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA66 support
A friend of a friend asked me to find out how ATA66 support was coming along. Is it still necessary to disable DMA or PIO settings for it to work? jm -- - Jonathon McKitrick -- [EMAIL PROTECTED] "The physicist's greatest tool is his wastebasket." - Albert Einstein - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current buildkernel problems.
after doing a cvsup I tried to build a new kernel and found that I was getting this error: (while doing config) ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard so, I searched the mailing lists and found that I needed to update /usr/sbin/config, so I did, and was able to config, and start building the kernel. well, that led me to a rather nice compile error: cc -c -x assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/bioscall.s /tmp/ccv99837.s: Assembler messages: /tmp/ccv99837.s:772: Error: operands given don't match any known 386 instruction /tmp/ccv99837.s:837: Error: operands given don't match any known 386 instruction *** Error code 1 After searching the mailing lists (this one) again, I found that the answer was to use the newest gcc, and that I probably want to be using "make buildkernel" in /usr/src, so, thats what I did, and I'm getting this error again: ../../conf/files: coda/coda_fbsd.c must be optional, mandatory or standard so, anyone have an answer? I've also tried compiling the newest gcc, standalone, with no luck. -Rex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA66 support
* j mckitrick [EMAIL PROTECTED] [000802 06:38] wrote: A friend of a friend asked me to find out how ATA66 support was coming along. Is it still necessary to disable DMA or PIO settings for it to work? There's rumors of some "problem" chipsets, but afaik 66 has been working for quite some time. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Latest kernel won't boot
Just recently build a kernel from cvsup, and the kernel won't boot. It gets to the point where you see booting [kernel] \ And it just hangs right there. There's a lot of disk activity, and after about 2 minutes (and no boot messages), I see a login prompt, but the machine is froze. Anyone else see this? - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current buildkernel problems.
On Wed, Aug 02, 2000 at 12:04:19PM -0400, Rex A. Roof wrote: /tmp/ccv99837.s: Assembler messages: /tmp/ccv99837.s:772: Error: operands given don't match any known 386 instruction /tmp/ccv99837.s:837: Error: operands given don't match any known 386 instruction After searching the mailing lists (this one) again, I found that the answer was to use the newest gcc, and that I probably Not GCC, Binutils (assembler and linker). Of course you've told us nothing that allows us to help you. The output from ``uname -a'' being the most important. Also why reather than build and install the various bits you will have to in order to compile a -current kernel, you don't just do a ``make world'' first. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current buildkernel problems.
ok, here's the output from uname -a FreeBSD shaolin.wccnet.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Thu Apr 27 19:04:53 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/SHAOLIN i386 usually, in the past, I've found the best way to upgrade (and, what I thought was the proper way) was to make a new kernel, reboot on it, and then build world is that not the right away? -Rex On Wed, Aug 02, 2000 at 11:38:57AM -0700, David O'Brien wrote: On Wed, Aug 02, 2000 at 12:04:19PM -0400, Rex A. Roof wrote: /tmp/ccv99837.s: Assembler messages: /tmp/ccv99837.s:772: Error: operands given don't match any known 386 instruction /tmp/ccv99837.s:837: Error: operands given don't match any known 386 instruction After searching the mailing lists (this one) again, I found that the answer was to use the newest gcc, and that I probably Not GCC, Binutils (assembler and linker). Of course you've told us nothing that allows us to help you. The output from ``uname -a'' being the most important. Also why reather than build and install the various bits you will have to in order to compile a -current kernel, you don't just do a ``make world'' first. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current buildkernel problems.
On Wed, 2 Aug 2000, Rex A. Roof wrote: ok, here's the output from uname -a FreeBSD shaolin.wccnet.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Thu Apr 27 19:04:53 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/SHAOLIN i386 usually, in the past, I've found the best way to upgrade (and, what I thought was the proper way) was to make a new kernel, reboot on it, and then build world is that not the right away? Not according to the handbook. The above is used under OpenBSD though. - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA66 support
On Wed, Aug 02, 2000 at 08:31:00AM -0700, Alfred Perlstein wrote: * j mckitrick [EMAIL PROTECTED] [000802 06:38] wrote: A friend of a friend asked me to find out how ATA66 support was coming along. Is it still necessary to disable DMA or PIO settings for it to work? There's rumors of some "problem" chipsets, but afaik 66 has been working for quite some time. -Alfred atapci0: VIA 82C686 ATA66 controller port 0xffa0-0xffaf at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ad0: 19574MB IBM-DPTA-372050 [39770/16/63] at ata0-master using UDMA66 ad1: 19574MB IBM-DPTA-372050 [39770/16/63] at ata0-slave using UDMA66 Works like a champ with this in my kernel config file: device ata0at isa? port IO_WD1 irq 14 device ata1at isa? port IO_WD2 irq 15 no further settings done. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(no subject)
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in xpt_setup_ccb (cam_xpt.c)
On 1 Aug, Nick Hibma wrote: Hm, I had a look at the source code, and to be honest I can't find a single reason why the path would be unset. Did the CD reader detached itself from the bus in the meantime, or did something like a bus error occur? Check your messages log around the time the panic occurred to see if something like that happened. ---snip--- Jul 29 10:40:55 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out in Message-in phase, SEQADDR == 0x194 Jul 29 10:40:55 Magelan /kernel: (cd0:ahc0:0:1:0): BDR message in message buffer Jul 29 10:40:57 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out in Message-in phase, SEQADDR == 0x194 Jul 29 10:40:57 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:40:57 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:42:26 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:42:26 Magelan /kernel: (cd0:ahc0:0:1:0): Queuing a BDR SCB Jul 29 10:42:28 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:42:28 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:42:28 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:43:04 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:43:04 Magelan /kernel: (cd0:ahc0:0:1:0): Queuing a BDR SCB Jul 29 10:43:06 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:43:06 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:43:06 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:43:47 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:43:47 Magelan /kernel: (cd0:ahc0:0:1:0): Queuing a BDR SCB Jul 29 10:43:49 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:43:49 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:43:49 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:45:12 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:45:12 Magelan /kernel: (cd0:ahc0:0:1:0): Queuing a BDR SCB Jul 29 10:45:14 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:45:14 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:45:14 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:45:51 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:45:51 Magelan /kernel: (cd0:ahc0:0:1:0): Queuing a BDR SCB Jul 29 10:45:53 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:45:53 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:45:53 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:47:31 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:47:31 Magelan /kernel: (cd0:ahc0:0:1:0): Queuing a BDR SCB Jul 29 10:47:33 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:47:33 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:47:33 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:48:34 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:48:34 Magelan /kernel: (cd0:ahc0:0:1:0): Queuing a BDR SCB Jul 29 10:48:36 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out while idle, SEQADDR == 0x194 Jul 29 10:48:36 Magelan /kernel: (cd0:ahc0:0:1:0): no longer in timeout, status = 34b Jul 29 10:48:37 Magelan /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 29 10:48:47 Magelan /kernel: (cd0:ahc0:0:1:0): SCB 0x7 - timed out in Message-in phase, SEQADDR == 0x194 Jul 29 10:48:47 Magelan /kernel: (cd0:ahc0:0:1:0): BDR message in message buffer ---snip--- At that point in the code it was using the path variable stored in the periph and that one is available from when the peripheral was allocated up to the point where the refcount for the peripheral reaches zero (that could be wrong) or the device is invalidated. Justin Gibbs (CCed) is looking into a bug with an aic7880, which hit the tree with his recent commits, perhaps it's related. Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E 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, Jul 30, 2000 at 01:25:18AM -0400, Jeroen C. van Gelderen wrote: Hmm, maybe the complainers should provide proof that they do need more than 2^256 complexity. Makes it easier for us, proponents ;-/ How about creating one-time pads? That said, in Applied Cryptography, Schneier makes the comment (end of section 7.1) that, based on thermodynamic limitations, "brute force attacks against 256-bit keys will be infeasible until computers are build from something other than matter and occupy something other than space". (Though it's possible that a quantum computer would meet those criteria - since it doesn't need to iterate through all possible keys, it can bypass that part of the second law of thermodynamics). This implies that if brute force is the best attack against Yarrow-256 (Blowfish), it is unbreakable. (Of course, that's a big if). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Request for review
I originally sent this to -committers but was advised that the maintainers and -hackers or -current was more appropriate. I've posted some patches for PR 14682 which include some changes to the source code for lpr(1), lprm(1) etc. Could someone review them for me please, especially the C code. Thanks. (please Cc: me as I'm not subscribed to -current) -- If I buy a copy of WinDelete, and it doesn't delete Windows, am I entitled to my money back? 51.44°N FreeBSD - The Power To Serve http://www.freebsd.org 2.057°W My Webpage http://ukug.uk.freebsd.org/~mark mailto:[EMAIL PROTECTED]http://www.radan.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review (LPDEST vs PRINTER)
At 10:39 PM +0100 8/2/00, Mark Ovens wrote:
I originally sent this to -committers but was advised that the
maintainers and -hackers or -current was more appropriate.
I've posted some patches for PR 14682 which include some changes
to the source code for lpr(1), lprm(1) etc.
Could someone review them for me please, especially the C code.
Your comments in the PR included:
Whilst investigating this problem I found in /usr/bin/lp:
# Posix 1003.2 compliant print spooler interface.
[snip]
# Posix says LPDEST gets precedence over PRINTER
dest=${LPDEST:-${PRINTER:-lp}}
So it would seem that the Right Thing(tm) to do is to make
the other programs POSIX-compliant by making them honour the
LPDEST environment variable rather than simply documenting
the fact that they don't (the manpages need updating to
reflect this).
Strictly speaking, that is not the right thing to do. POSIX
is talking about the 'lp' command, which is one of the commands
from the SysV-ish printing world. 'lpr' is the BSD-ish print
world, and therefore it is not covered by what POSIX describes
for 'lp'. These are two different command sets for printing.
The 'lprm' command is also part of the BSD-ish print world.
I do not have a reference for what POSIX says about commands,
but the "Single Unix Specification" has a description of the
'lp' command. The description for 'lp' does not talk about
the 'lprm' command. It says the way to cancel print jobs
sent via the 'lp' command is via the 'cancel' command. It
also talks about using 'lpstat' instead of 'lpq'.
So, strictly speaking, if we wanted POSIX compliance then
we should add 'cancel' and 'lpstat' commands, and have
those commands behave as POSIX describes them. If POSIX does
also describe the behavior of the 'lprm' or 'lpq' commands,
then we could talk about changing those commands to be
POSIX-compliant. I would guess that it doesn't have them.
So, that is my off-the-cuff pedantic-mode reaction, which is
not much help in closing the PR...
I don't feel too strongly about this, but in general I'd
rather document that LPDEST is not used by lpr/lpq/lprm,
and maybe later on add cancel/lpstat commands for those
people who are really expecting the "POSIX print system".
The other printing-system alternative is LPRng (which people
can install from ports). LPRng does add the 'lpstat' command,
in addition to replacing lpr/lpq/lprm. And if I am reading
this code right, it does check LPDEST for all of those commands,
*-but-* it has PRINTER taking precedence over LPDEST, and not
the way POSIX (apparently) describes it. If we do add checking
for LPDEST, I would probably have PRINTER continue to take
precedence over LPDEST. Right now, anyone who *is* setting
both variables must be used to the idea that PRINTER is the
value lpr/lprm/lpq uses, and I do not think we should change
that.
I would also like to see what openbsd and netbsd do for this,
if anything, but I haven't the time right now.
As to your actual C code, it looks like it would work fine, if
we wanted to do that.
---
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Loss of fetch(1) functionality with libfetch
I don't recall seeing this mentioned: In order to access the Internet, I need to use proxy authorization. With the old fetch(1) I could use an environment variable like "HTTP_PROXY_AUTH=basic:*:username" and it would prompt for a password. The new libfetch-based fetch(1) ignores the HTTP_PROXY_AUTH variable unless it is in the form "HTTP_PROXY_AUTH=basic:*:username:password" and doesn't appear to have any provision for requesting a password. (HTTP_AUTH appears to suffer from the same problem). Whilst the environment is somewhat safer than the command line, I'd still prefer not to have passwords embedded in environment variables. Has this feature been deliberately left out, or is it just one of the bits that you haven't gotten around to implementing yet? Would you be interested in patches to implement it? On a related note, I noticed the following bug - though it has no effect on the operation of libfetch in its current form. Index: http.c === RCS file: /home/CVSROOT/src/lib/libfetch/http.c,v retrieving revision 1.34 diff -u -r1.34 http.c --- http.c 2000/07/25 11:45:38 1.34 +++ http.c 2000/08/03 04:25:53 @@ -91,7 +91,7 @@ #define HTTP_MOVED_TEMP302 #define HTTP_SEE_OTHER 303 #define HTTP_NEED_AUTH 401 -#define HTTP_NEED_PROXY_AUTH 403 +#define HTTP_NEED_PROXY_AUTH 407 #define HTTP_PROTOCOL_ERROR999 #define HTTP_REDIRECT(xyz) ((xyz) == HTTP_MOVED_PERM \ Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
