Re: HEADS-UP: bdevs have been assimilated.
In message [EMAIL PROTECTED], Matthew Jacob writes: Well, I am truly f*cked now. I read enough of this thread, saw nothing new in UPDATING, and did the following: alpha kernel from today MAKEDEV from today (but not a make world install- the binaries/libs are ~week old) cannot get out of single user mode. fsck core dumps. Any failed command causes the single user shell to exit. This doesn't sound like a /dev related problem to me. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
In message [EMAIL PROTECTED], Matthew Jacob writes: Well, I am truly f*cked now. I read enough of this thread, saw nothing new in UPDATING, and did the following: alpha kernel from today MAKEDEV from today (but not a make world install- the binaries/libs are ~week old) cannot get out of single user mode. fsck core dumps. Any failed command causes the single user shell to exit. This doesn't sound like a /dev related problem to me. You're probably right about this. Maybe we should all call it "Matt's really bad day where he got vicious" and we'll try again tomorrow after a new update/nightly build. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWUP: Re: HEADS-UP: bdevs have been assimilated.
In message [EMAIL PROTECTED], Matthew Jacob writes: Sorry- maybe more of an edge case. It really has to do with 'ad' support seemingly vanishing from the alpha. Or, rather, it's hard to say exactly what has happened: Mounting root from ufs:/dev/rad0a no such device 'rad' Bruce and Mike smith took out a testing-shim a little early which allowed us to test with /dev/r* in /etc/fstab. Change your /etc/fstab to read /dev/ad0a and you should be happy again. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FOLLOWUP: Re: HEADS-UP: bdevs have been assimilated.
In message [EMAIL PROTECTED], Matthew Jacob writes: Sorry- maybe more of an edge case. It really has to do with 'ad' support seemingly vanishing from the alpha. Or, rather, it's hard to say exactly what has happened: Mounting root from ufs:/dev/rad0a no such device 'rad' Bruce and Mike smith took out a testing-shim a little early which allowed us to test with /dev/r* in /etc/fstab. Change your /etc/fstab to read /dev/ad0a and you should be happy again. Actually, no, I'm not- the 'rad' was less worrisome than the other stuff (like fsck core dumping, mount dyings, etc.). but, but we'll see what happens tomorrow. I'll be up to date and have a fresh build with the new mount.h and I'll make it work if it doesn't (I have to as I have too many other things backed up behind this toe stub). I probably should have used an i386 to test this change first rather than an alpha. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
Kazutaka YOKOTA wrote: I'm using non-standard 100x37 console mode on my notebook, because in 80x25 text mode letters seems too big for my 12' panel, while other modes doesn't cover all panel size. So I've patched vidcontrol to switch to the VESA_800x600 100x37 mode (instead of default 80x25) with 8x16 font, and in most cases all works just fine (including ncurses and dialog bases apps), but sometimes when I'm building world or some other app text suddenly shifts from the edge of the screen by several spaces and all text passed to the console after that also being printed with that offset. For example: [...] This strange behavior was reported several times in the past. It must be related to screen update logic in syscons. But, I don't think we have successfully fixed it at that time :-( It's time to analyze the problem again... Obviously... If any help with debugging/testing would be necessary please do not hesitate to contact me. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: incorrect irqs with pci devices
On Fri, 3 Dec 1999, Mike Heffner wrote: Hi, I have recently noticed that the irqs for my PCI devices are being screwed up somehow. It is easily noticeable with dmesg, the correct one's are in paren.: Is this an SMP box by any chance? Does the kernel work with the irqs which it chose? -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
Kazutaka YOKOTA wrote (1999/12/03):
This strange behavior was reported several times in the past. It must
be related to screen update logic in syscons. But, I don't think we
have successfully fixed it at that time :-(
It's time to analyze the problem again...
Yes. I know about this problem too but I have no time to fix and test
it. Is anybody interested in bug reports? ;-)
* Left margin moving to the right is related to the screen width not
divisible by 8 and an use of tabulators at the end of line after the
last valid tab position. So the same problem could be seen for
example with screen width 90, which is accessible for all
-current users: Let's suppose that cursor range is 0..89: If the
cursor is on 80..87, it will move to position 88 and everything is ok.
If the cursor is on 88..89, the position is calculated properly (you
can switch to another console then return and cursor will be on
the right position on column 0), but cursor is moved incorrectly
on column 8 on the next line and next lines are moved to the left too
until you switch between consoles.
I think the fix should be trivial (syscons.c,v 1.327) - but it is
speculated right now without testing:
--
*** syscons.c Sun Nov 28 15:29:28 1999
--- /tmp/syscons.c Fri Dec 3 10:28:59 1999
***
*** 2946,2956
case 0x09: /* non-destructive tab */
mark_for_update(scp, scp-cursor_pos);
scp-cursor_pos += (8 - scp-xpos % 8u);
- mark_for_update(scp, scp-cursor_pos);
if ((scp-xpos += (8 - scp-xpos % 8u)) = scp-xsize) {
scp-xpos = 0;
scp-ypos++;
}
break;
case 0x0a: /* newline, same pos */
--- 2946,2957
case 0x09: /* non-destructive tab */
mark_for_update(scp, scp-cursor_pos);
scp-cursor_pos += (8 - scp-xpos % 8u);
if ((scp-xpos += (8 - scp-xpos % 8u)) = scp-xsize) {
scp-xpos = 0;
scp-ypos++;
+ scp-cursor_pos = scp-xsize * scp-ypos;
}
+ mark_for_update(scp, scp-cursor_pos);
break;
case 0x0a: /* newline, same pos */
--
* There are another problems with syscons updating: When a block
of text is selected by mouse, it should be hidden when text in this
block is changed. Unfortunately in many cases the block stays
selected on the same position... I think we should learn from
xterm. (But when I tested xterm, it had some problems too...)
I have created small testing script which can show
all upcoming problems (I think). But in some cases you have to know
which block of text should be selected...
--
#!/usr/local/bin/bash
c_before()
{
tput clear
I=20
while [ $I -gt 0 ]; do
echo "$I $I $I $I $I $I $I $I $I $I $I $I $I $I $I $I $I $I $I $I"
I=`expr $I - 1`
done
tput sc ; tput cm $1 $2 ; echo -n "*" ; tput rc
echo "Mark a block and then press Enter and after test too..."
read Q
tput cm $1 $2
}
c_after()
{
read Q
clear
}
c_cycle()
{
I=$1
while [ $I -gt 0 ]; do
echo -n $2
I=`expr $I - 1`
done
}
c_print()
{
tput cm 89 8
printf "\t\nThis text must start at the beginning of the line!\n"
}
clear
PS3="Which test? "
select X in Tab Text Mu1 El0 El1 El2 Il1 Dl1 Dc1 Ic1 Su1 Sd1 Ec1 Sw1 Quit ; do
if [ -z "$X" ]; then
echo "Unknown selection"
break
fi
if [ $X = Quit ]; then
break
fi
c_before 40 8
case $X in
Tab)c_print ;; # Bug - 90x30 and tab at the end of line
Text) c_cycle 4 "Text " ;;# Bug - remove_markings
Mu1)c_cycle 22 "M" ;; # Bug - remove_markings
El0)c_cycle 1 "[0K" ;; # Bug - remove_markings
El1)c_cycle 1 "[1K" ;; # Bug - remove_markings
El2)c_cycle 1 "[2K" ;; # Bug - remove_markings
Il1)c_cycle 5 "[1L" ;; # Bug - remove_markings
Dl1)c_cycle 5 "[1M" ;; # Bug - remove_markings
Dc1)c_cycle 10 "[1P" ;;# Bug - remove_markings
Ic1)c_cycle 10 "[1@" ;;# Bug - remove_markings
Su1)c_cycle 10 "[1S" ;;# Bug - remove_markings
Sd1)c_cycle 10 "[1T" ;;# Bug - remove_markings
Ec1)c_cycle 1 "[10X" ;;# Bug - remove_markings
Sw1)c_cycle 1 "[100z" ;; # Bug - don't beep after this
esac
c_after
done
--
I have a fast-partial-fix for syscons.c,v 1.308. But please don't apply
this patch - it should be much more intelligent than following patch -
the block is hidden in all cases but I would like to see solution
similar to xterm - a block is hidden only in needed cases.
--
*** syscons.c Thu Jun 24 20:14:56 1999
--- syscons.c.new
ssh2 port
Tried to build ssh2 (after installing ssh1) from the ports, and I got the following error: SHELL@:No such file or directory I added USE_GMAKE= yes to the security/ssh2/Makefile, and tried it again and it completed successfully. Has anyone else came across this? Davec -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc-2.95.2, jade and freebsd-sgml-documentationSubject:
thanks for the responses! "make" and "make install" worked fine with the newest port changes, but when making the handbook jade dumped core at last. Memory consumption raised to over 30 MByte before the core dump. I made a mistake in the former posting as i tried to compile jade-1.2.2.tar.gz and forgot to mention this fact, sorry. -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://ES-i2.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
Yes. I know about this problem too but I have no time to fix and test it. Is anybody interested in bug reports? ;-) * Left margin moving to the right is related to the screen width not divisible by 8 and an use of tabulators at the end of line after the last valid tab position. So the same problem could be seen for example with screen width 90, which is accessible for all [...] I think the fix should be trivial (syscons.c,v 1.327) - but it is speculated right now without testing: This is an excellent analysis. I will test your patch. Thank you. * There are another problems with syscons updating: When a block of text is selected by mouse, it should be hidden when text in this block is changed. Unfortunately in many cases the block stays selected on the same position... I think we should learn from xterm. (But when I tested xterm, it had some problems too...) This is a known problem which I haven't worked on... ;- Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with syscons in VESA mode
Cejka Rudolf wrote: Kazutaka YOKOTA wrote (1999/12/03): This strange behavior was reported several times in the past. It must be related to screen update logic in syscons. But, I don't think we have successfully fixed it at that time :-( It's time to analyze the problem again... Yes. I know about this problem too but I have no time to fix and test it. Is anybody interested in bug reports? ;-) * Left margin moving to the right is related to the screen width not divisible by 8 and an use of tabulators at the end of line after the last valid tab position. So the same problem could be seen for example with screen width 90, which is accessible for all -current users: Let's suppose that cursor range is 0..89: If the cursor is on 80..87, it will move to position 88 and everything is ok. If the cursor is on 88..89, the position is calculated properly (you can switch to another console then return and cursor will be on the right position on column 0), but cursor is moved incorrectly on column 8 on the next line and next lines are moved to the left too until you switch between consoles. I think the fix should be trivial (syscons.c,v 1.327) - but it is speculated right now without testing: -- *** syscons.c Sun Nov 28 15:29:28 1999 --- /tmp/syscons.c Fri Dec 3 10:28:59 1999 *** *** 2946,2956 [...] Thanks! It seems fixed my problems with syscons. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How do I get a USB mouse working in todays -CURRENT ?
Thanks Nick, my USB mouse works perfectly now.
On Thu, 2 Dec 1999, Nick Hibma wrote:
The problem is that the mouse doesn't work (its not a hardware problem),
all I get whenever I move the mouse are lots of the following messages
on the console:
Discarded 7 bytes in queue
This means that your mouse is working but moused is closing while the
buffer is not empty yet. This looks a lot like my mistake I fixed
earlier.
Do I need to change /etc/usbd.conf in some way ?
No, you are probably looking at a stale moused.c. Please update the file
/usr/src/usr.sbin/moused/moused.c with the following diff (there is an
extra semicolon at the end of that line) and execute makemake install
in that directory:
Index: src/usr.sbin/moused/moused.c
===
RCS file: /home/ncvs/src/usr.sbin/moused/moused.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -w -r1.32 -r1.33
--- moused.c1999/11/29 17:21:07 1.32
+++ moused.c1999/11/30 10:20:33 1.33
@@ -746,7 +746,7 @@
}
/* mouse event */
- if (read(rodent.mfd, b, 1) == -1);
+ if (read(rodent.mfd, b, 1) == -1)
return; /* file seems to be closed on us */
if (r_protocol(b, action)) { /* handler detected action */
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
--
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
E. P. Tryon from "Nature" Vol.246 Dec.14, 1973
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: incorrect irqs with pci devices
On 03-Dec-99 Doug Rabson said: | On Fri, 3 Dec 1999, Mike Heffner wrote: | | Hi, | | I have recently noticed that the irqs for my PCI devices are being screwed | up | somehow. It is easily noticeable with dmesg, the correct one's are in | paren.: | | Is this an SMP box by any chance? Does the kernel work with the irqs which | it chose? | Yes, it is a SMP box, and yes, the devices work fine. I just thought it was odd that the kernel would report incorrect ones. - Mike Heffner [EMAIL PROTECTED] Fredericksburg, VA ICQ# 882073 Date: 03-Dec-99 Time: 09:54:12 - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh2 port
I had the same type of problem compiling rpm (so I could install the latest linux_base to try vmware) My problem turned out to be I had autoconf 2.12 installed and I needed 2.13 the @SHELL@ is supposed to be substituted by configure, but wasn't because of the autoconf bit. Check your autoconf. -Charlie On Fri, Dec 03, 1999 at 03:19:07AM -0700, Davec wrote: Tried to build ssh2 (after installing ssh1) from the ports, and I got the following error: SHELL@:No such file or directory I added USE_GMAKE=yes to the security/ssh2/Makefile, and tried it again and it completed successfully. Has anyone else came across this? [EMAIL PROTECTED] -- Charles Anderson[EMAIL PROTECTED] No quote, no nothin' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: incorrect irqs with pci devices
On Fri, 03 Dec 1999 09:55:43 -0500 (EST), Mike Heffner [EMAIL PROTECTED] said: Yes, it is a SMP box, and yes, the devices work fine. I just thought it was odd that the kernel would report incorrect ones. They are not incorrect. SMP uses a different interrupt system. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
With todays' build, the previous problems went away. Other problems have replaced them (sio's wierd again for alpha), but that's a different story. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS client zeroing out blocks on write?
I just upgraded a server from 2.2.8 to -current (991201 kernel) and am
seeing some NFS corruption. It looks like byte ranges are getting
zeroed out by the client (or not getting written at all, and the server
at the other end is filling with zeros?). I've seen it while writing
to both a Solaris 2.6 server (NFSv3) and a Netware NFS server (NFSv2),
so I'm pretty sure it's the client causing the problem.
Details:
4.0-CURRENT FreeBSD 4.0-CURRENT #2: Thu Dec 2 17:07:57 CST 1999
CPU: Dual Pentium III/Xeon 600 Mhz
RAM: 256MB
NIC: fxp0, full-duplex 100mbit
NFS mount point: /mnt/filesystem/u01, mounting a Solaris 2.6 box also
with a 100mbit full-duplex net connection, 8K NFS blocksize,
UDP, via amd.
My testcase is a 7-gig text file that I'm copying around with the
following commands:
$ cd /net/remotesystem/u01
$ split -b 10 /u01/bigfile.txt file
creating seven 1-gig files fileaa .. fileag (running at a nice rate of
5-6 MB/sec :). I then run "blankcheck" (attached) to scan the file for
runs of zeroes, and get the following:
$ for i in filea{a,b,c,d,e,f} ; do echo $i ; ./blankcheck $i ; done
fileaa
fileab
168173568-168179199(5632)
384966656-384972287(5632)
385753088-385758719(5632)
( snip 156 lines just like the above, all ranges 5632 bytes in size )
464068608-464074239(5632)
464723968-464729599(5632)
465248256-465253887(5632)
fileac
203448320-203451391(3072)
filead
fileae
372097024-372103167(6144)
fileaf
561774592-561778175(3584)
$
All the zeroed out blocks start on an 8k NFS boundary, and I have
verified that the rest of the 8k block has the correct data in it.
Each corrupted block is always a multiple of 512 bytes long (so far
multiples are 6, 7, 11, and 12).
On this example run, each file either has no corruption at all, or has
corruption with all the zeroed out ranges the same size. Dunno if this
matters, but it's interesting.
If I run without nfsiod, or copy from a remote NFS mount to a remote
NFS mount, the corruption goes way down but still happens. I got only
one corrupted block in my 7-gig test run in each of those test cases.
I'm afraid I don't know much about the internal workings of NFS, so I'm
hoping my description is enough to pinpoint the problem.
--
Dan Nelson
[EMAIL PROTECTED]
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #2: Thu Dec 2 17:07:57 CST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/EMSSRV7
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Xeon (596.92-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x673 Stepping = 3
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM
real memory = 268427264 (262136K bytes)
avail memory = 257163264 (251136K bytes)
Programming 24 pins in IOAPIC #0
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0
cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc0303000.
VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc02af1c2 (122)
VESA: ATI MACH64
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
vga-pci0: ATI model 4757 graphics accelerator at device 0.0 on pci1
pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 2.0 on pci0
pci2: PCI bus on pcib2
ahc0: Adaptec 2944 Ultra SCSI adapter irq 21 at device 9.0 on pci2
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc1: Adaptec aic7890/91 Ultra2 SCSI adapter irq 16 at device 11.0 on pci2
ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
chip1: Intel PIIX4 IDE controller at device 7.1 on pci0
pci0: UHCI USB controller (vendor=0x8086, dev=0x7112) at 7.2 irq 19
Timecounter "PIIX" frequency 3579545 Hz
intpm0: Intel 82371AB Power management controller at device 7.3 on pci0
intpm0: I/O mapped 850
intpm0: intr IRQ 9 enabled revision 0
smbus0: System Management Bus on intsmb0
smb0: SMBus general purpose I/O on smbus0
intpm0: PM I/O mapped 800
fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 18 at device 14.0 on pci0
fxp0: Ethernet address 00:90:27:dc:44:eb
fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5" drive on fdc0 drive 0
wdc1 at port 0x170-0x177 irq 15 on isa0
wdc1: unit 0 (atapi): SAMSUNG SC-140B/d005, removable, intr, dma, iordis
wcd0: drive speed 6875KB/sec, 128KB cache
wcd0: supported read types: CD-R, CD-RW, CD-DA, packet track
wcd0: Audio: play, 255 volume levels
wcd0:
Re: incorrect irqs with pci devices
Mike Heffner wrote: On 03-Dec-99 Doug Rabson said: | On Fri, 3 Dec 1999, Mike Heffner wrote: | | Hi, | | I have recently noticed that the irqs for my PCI devices are being screw ed | up | somehow. It is easily noticeable with dmesg, the correct one's are in | paren.: | | Is this an SMP box by any chance? Does the kernel work with the irqs whic h | it chose? | Yes, it is a SMP box, and yes, the devices work fine. I just thought it was o dd that the kernel would report incorrect ones. It isn't "incorrect".. SMP motherboards have a seperate interrupt controller (APIC - Advanced programmable interupt controller) that is used for message passing as well as distributing interrupts per cpu. It also generally has 24 interrupt pins, and there can be more than one APIC in a system. When a system boots, it's in "legacy" mode until the switch is thrown and it's running in SMP mode. At that time, the alternative IRQ assignments are activated. fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 18 at device 6.0 on pci0 ahc0: Adaptec aic7880 Ultra SCSI adapter irq 17 at device 9.0 on pci0 etc. Run the mptable(1) program to see your motherboard config. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world failure in pccardc
=== usr.sbin/pccard/pccardc cc -O -pipe -I/usr/src/usr.sbin/pccard/pccardc/../pccardd -Wall -g -static -c /usr/src/usr.sbin/pccard/pccardc/power.c /usr/src/usr.sbin/pccard/pccardc/power.c: In function `power_main': /usr/src/usr.sbin/pccard/pccardc/power.c:79: `PIOCSVIR' undeclared (first use in this function) /usr/src/usr.sbin/pccard/pccardc/power.c:79: (Each undeclared identifier is reported only once /usr/src/usr.sbin/pccard/pccardc/power.c:79: for each function it appears in.) *** Error code 1 Stop in /usr/src/usr.sbin/pccard/pccardc. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current state of native Netscape?
Has the signal structure problem that hangs native Netscape been corrected? I haven't seen a definitive "its fixed" statement recently... Thanks, Bruce -- --- Bruce Burden[EMAIL PROTECTED] Tandem Computers Inc. 512-432-8944Network Verification 14231 Tandem Blvd. Auto answer(4 rings) Austin, TX 78726 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FA410TXC support in -current
Hi gang, I noticed that /src/etc/pccard.conf.sample listed the Netgear FA410TX card as supported. Does it still use the ed0 driver? I take it I no longer need to worry about the PAO additions if I use a build of -current that lists the FA410TX as supported, right? Bruce -- --- Bruce Burden[EMAIL PROTECTED] Tandem Computers Inc. 512-432-8944Network Verification 14231 Tandem Blvd. Auto answer(4 rings) Austin, TX 78726 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current build failed...
Hello! After cvsuped my source, i try rebuild my -current system... === usr.bin/truss cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master /bin/sh /usr/src/usr.bin/truss/../../sys/kern/makesyscalls.sh syscalls.master /usr/src/usr.bin/truss/i386.co nf cp /usr/src/usr.bin/truss/../../sys/i386/linux/syscalls.master i386l-syscalls.master /bin/sh /usr/src/usr.bin/truss/../../sys/kern/makesyscalls.sh i386l-syscalls.master /usr/src/usr.bin/truss/i 386linux.conf cc -nostdinc -O -pipe -I/usr/src/usr.bin/truss -I. -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/t russ/main.c cc -nostdinc -O -pipe -I/usr/src/usr.bin/truss -I. -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/t russ/setup.c cc -nostdinc -O -pipe -I/usr/src/usr.bin/truss -I. -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/t russ/syscalls.c /bin/sh /usr/src/usr.bin/truss/../../usr.bin/kdump/mkioctls ioctl.c *** Error code 1 Stop in /usr/src/usr.bin/truss. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Rgdz, Osokin Sergey, [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FA410TXC support in -current
I noticed that /src/etc/pccard.conf.sample listed the Netgear FA410TX card as supported. Does it still use the ed0 driver? I take it I no longer need to worry about the PAO additions if I use a build of -current that lists the FA410TX as supported, right? Yes. Note that you need to be up-to-date with the pccard.conf entry; until a few weeks ago it was a cut-and-paste from PAO that didn't work. You're reading this courtesy of one, so I know it's working. -- \\ 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] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
More crashes under heavy exec() load in -CURRENT (and strange savecore)
I've been experiencing more strange crashes. I've been getting them about once or
twice a day lately, but only if I'm running my testing for the FreeBSD-audit project.
I'm basically brute forcing the FreeBSD toolchain, and reporting the results to the
audit mailing list. Unfortunatly, the crashes have been getting in the way..
Matt Dillon told me to try to up my PV's in my kernel as a first step. After upping it
to 1000 (this could have nothing to do with it), my machine would no longer dump core,
or drop into DDB, it'd simply reboot. So I lowered it back down to the default, and
now it cored again. I'll pop it up to 1000 again to what it does.
For an idea of the load, it was probably at about 1.50. I had three processes doing a
bunch of execs, and just before the crash the tester was only at ~1800 exec()'s a
minute.
I've got all of the info (dmesg, kernel conf, vmcore, kernel) sitting at
http://www.afterthought.org/freebsd/crashes/
I also noticed this oddity in my /var/log/messages:
Dec 3 15:35:45 karma savecore: reboot after panic: page fault
Dec 3 15:35:45 karma savecore: /var/crash/bounds: No such file or directory
Dec 3 15:35:45 karma savecore: /dev/rrwd0s1b: No such file or directory; using block
device
Dec 3 15:35:45 karma savecore: writing core to /var/crash/vmcore.0
Dec 3 15:36:03 karma savecore: writing kernel to /var/crash/kernel.0
Dec 3 15:36:03 karma savecore: read: No such file or directory
My rc.conf says:
dumpdev="/dev/wd0s1b"
Kernel:
FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Thu Dec 2 13:04:29
EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
Last 'make world':
November 29th.
Here's a backtrace:
===
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01d8339
stack pointer = 0x10:0xcf71addc
frame pointer = 0x10:0xcf71adec
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 = 86209 (cc1plus)
interrupt mask = none
trap number = 12
panic: page fault
syncing disks... 34 8
done
dumping to dev #wd/0x20001, offset 1413889
dump ata0: resetting devices .. WARNING: WAIT_READY active=UNKNOWN
done
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=256) at ../../kern/kern_shutdown.c:273
273 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:273
#1 0xc0132295 in panic (fmt=0xc0244fcf "page fault") at ../../kern/kern_shutdown.c:523
#2 0xc02158e2 in trap_fatal (frame=0xcf71ad9c, eva=0) at ../../i386/i386/trap.c:908
#3 0xc0215595 in trap_pfault (frame=0xcf71ad9c, usermode=0, eva=0) at
../../i386/i386/trap.c:801
#4 0xc0215167 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16777232, tf_edi = 0,
tf_esi = -1071179392, tf_ebp = -814633492,
tf_isp = -814633528, tf_ebx = -1071179392, tf_edx = 0, tf_ecx = 11, tf_eax = 0,
tf_trapno = 12, tf_err = 2,
tf_eip = -1071807687, tf_cs = 8, tf_eflags = 66118, tf_esp = -1071172824, tf_ss
= -814624768})
at ../../i386/i386/trap.c:425
#5 0xc01d8339 in _vm_map_clip_end (map=0xc0273328, entry=0xc0271980, end=3480358912)
at ../../vm/vm_map.c:835
#6 0xc01d93bf in vm_map_delete (map=0xc0273328, start=3480342528, end=3480358912) at
../../vm/vm_map.c:1751
#7 0xc01d9536 in vm_map_remove (map=0xc0273328, start=3480342528, end=3480358912) at
../../vm/vm_map.c:1822
#8 0xc01d747d in kmem_free (map=0xc0273328, addr=3480342528, size=16384) at
../../vm/vm_kern.c:233
#9 0xc0141731 in pipeclose (cpipe=0xccd40a20) at ../../kern/sys_pipe.c:1093
#10 0xc014161d in pipe_close (fp=0xc3154540, p=0xcf67a300) at
../../kern/sys_pipe.c:1049
#11 0xc012a4f1 in fdrop (fp=0xc3154540, p=0xcf67a300) at ../../sys/file.h:211
#12 0xc012a42f in closef (fp=0xc3154540, p=0xcf67a300) at
../../kern/kern_descrip.c:1017
#13 0xc0129b90 in close (p=0xcf67a300, uap=0xcf71af80) at ../../kern/kern_descrip.c:515
#14 0xc0215b1a in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
136883640, tf_esi = 0, tf_ebp = -1077978820,
tf_isp = -814633004, tf_ebx = 136674112, tf_edx = 136674200, tf_ecx = 0, tf_eax
= 6, tf_trapno = 7, tf_err = 2,
tf_eip = 136203996, tf_cs = 31, tf_eflags = 647, tf_esp = -1077978848, tf_ss =
47}) at ../../i386/i386/trap.c:1057
#15 0xc020a516 in Xint0x80_syscall ()
#16 0x81dd327 in ?? ()
#17 0x807fd54 in ?? ()
#18 0x80d8979 in ?? ()
#19 0x80db8cb in ?? ()
#20 0x80480f9 in ?? ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
Re: -current build failed...
Sergey Osokin wrote: Hello! After cvsuped my source, i try rebuild my -current system... Please re-cvsup. There was a longish delay between 2 related commits. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Where to put HPFS driver?
In message [EMAIL PROTECTED], Ustimenko S emen writes: Hi! Promised somewhere in spring, i am now almost ready to put HPFS driver into current. So i have question: Where have to go driver sources src/sys/hpfs or src/sys/i386/hpfs, or something else ? Where have to go mount_hpfs: src/sbin/i386/mount_hpfs? The code for a filesystem should not be architecture dependent. I would advocate for sys/fs/hpfs. We have too many filesystems cluttering up /sys already, we should start to cluster them in sys/fs -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: rpc.umntall does not work with AIX [LONG]
Well, it seems like RPCMNT_UMNTALL call always fails with RPC_SYSTEMERROR on
all systems except FreeBSD. I tested HP/UX, AIX and Solaris boxes - they all
behave identically as follows:
rpc.umntall -h $HOST always fails
rpc.umntall -h $HOST -p $DIR - works just fine since it is using RPCMNT_UMOUNT
umount $HOST:$DIR works just fine
Interesting, even if RPC_UMNTALL call returns error code, it nonetheless
causes mount entry to be removed from the server, i.e. showmount -a $HOST
output does not report my client machine as having any mounts on $HOST anymore.
All entries in my /var/db/mounttab appear to be correct, I do not think they
are causing the problem.
Also, I have questions regarding the following code fragment from the
rpc.umntall.c file:
1) for (mtab = mtabhead; mtab != NULL; mtab = mtab-next) {
2) if (*mtab-mtab_host != '\0'
3) (do_umntall(mtab-mtab_host) ||
4) mtab-mtab_time = (time(now) - expire))) {
5) if (keep is_mounted(mtab-mtab_host,
6) mtab-mtab_dirp)) {
7) if (verbose) {
8) warnx("skipping entry %s:%s",
9) mtab-mtab_host,
10)mtab-mtab_dirp);
11)}
12)} else
13)clean_mtab(mtab-mtab_host, NULL);
14)}
15)}
It seems like it does RPCMNT_UMNTALL call for each mounttab entry regardless of
the -k parameter passed in the command line, while man page suggests that
it should simply skip entries for currently mounted filesystems.
-k Keep entries for existing NFS filesystems. Compare the NFS
filesystems from the mounttab against the kernel mount list and do
not send the RPC to existing mount entries. Useful during startup
of the system. It may be possible that there are already mounted
NFS filesystems, so calling RPC UMNTALL isn't a good idea. This
is the case if the user has rebooted to 'single user mode' and
starts up the system again.
Furthermore, using RPC_UMNTALL in the above loop is probably not a good idea
either because client host may have two different directories mounted from the
same server. If -k flag is specified, you cannot use UMNTALL because it will
remove /var/run/mountdtab entries not only for the mount point left over
from the crash but also for all other mounts some of which may be perfectly
valid and should be kept intact.
May be, we should use RPCMNT_UMOUNT call instead? It seems to me that
RMCMNT_UMNTALL is only applicable when utility is called with -h option as the
only option.
-Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Actually, I don't think so. I'm not 100% sure, but I think that you end up in the interrupt handler for the card that's going away, but with tty interrupts masked so you can't get back into DDB. If it's a modem card, then you'll have them masked as well. I'm _fairly_ sure that you'll find you're spinning in the card's interrupt handler. Stick a printf or two in there and see for yourself. I guess you must have been right. The card suspend and resumes fine now (apart from resource allocation, but that is a different issue). It seems that the proper deleting of the driver solved the problem of freezing my machine. Cheers, Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: incorrect irqs with pci devices
Garrett Wollman wrote:
On Fri, 03 Dec 1999 09:55:43 -0500 (EST), Mike Heffner [EMAIL PROTECTED] said:
Yes, it is a SMP box, and yes, the devices work fine. I just thought it was odd
that the kernel would report incorrect ones.
They are not incorrect. SMP uses a different interrupt system.
They are on my box, where incorrect is defined as the interrupts not reaching
their
supposed destination. I would really like to fix this, but I don't know enough
about exactly what is wrong. Any ideas would really be appreciated, as I would
like to remove my disgusting hack. :)
I have an AMI raid controller that the system reports that it is on irq 11. The
problem is that the interrupts actually go to irq 17. If I hard wire them with
*** pci.c.old Mon Nov 29 19:34:46 1999
--- pci.c Thu Dec 2 17:48:42 1999
***
*** 347,352
--- 347,356
}
}
}
+ if (cfg-intline == 11) {
+ printf("apic_io: incorrect int 11 - 17\n");
+ cfg-intline = 17;
+ }
#endif /* APIC_IO */
cfg-mingnt = pci_cfgread(cfg, PCIR_MINGNT, 1);
...everything works fine. I believe the problem has something to do with the
fact that it is a bridged card, but I'm not sure how things should work.
Any thoughts?
Chris
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-current no longer builds on the alpha
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/reader.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/skeleton.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/symtab.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/verbose.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/warshall.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -static -o yacc closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o install -c -o root -g wheel -m 555 /usr/src/usr.bin/yacc/yyfix.sh /usr/obj/usr/src/tmp/usr/bin/yyfix *** Signal 11 Stop in /usr/src/usr.bin/yacc. *** Error code 1 It dies every time right there, which makes me think this is more than the usual memory/cache issues. Also, the alpha in question (beast) will build the world just fine from 3 days ago. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current no longer builds on the alpha
What is beast? I was happily able to build -current at about 5 this morning on a pc164. On Fri, 3 Dec 1999, Jordan K. Hubbard wrote: cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/reader.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/skeleton.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/symtab.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/verbose.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/yacc/warshall.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -static -o yacc closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o install -c -o root -g wheel -m 555 /usr/src/usr.bin/yacc/yyfix.sh /usr/obj/usr/src/tmp/usr/bin/yyfix *** Signal 11 Stop in /usr/src/usr.bin/yacc. *** Error code 1 It dies every time right there, which makes me think this is more than the usual memory/cache issues. Also, the alpha in question (beast) will build the world just fine from 3 days ago. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules/netgraph/bpf breaks world
thanks, committed.
For thise wondering this is a netgraph node that can do arbitrary
filtering using the existing bpf engine.
On Fri, 3 Dec 1999, Steven G. Kargl wrote:
*** Makefile.orig Fri Dec 3 16:46:54 1999
--- Makefile Fri Dec 3 16:46:25 1999
***
*** 6,11
MAN8= ng_bpf.8
KMODDEPS= netgraph
! .PATH: ../../../net
.include bsd.kmod.mk
--- 6,11
MAN8= ng_bpf.8
KMODDEPS= netgraph
! .PATH: ${.CURDIR}/../../../net
.include bsd.kmod.mk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Bktr driver
It seems that the bktr driver is still broken. I have looked through the code for the driver, and have yet to find the problem. here is a dmesg output with the error that seems to be causeing my problem: bktr0: BrookTree 878 irq 9 at device 17.0 on pci0 bktr0: Hauppauge Model 61291 D110 Warning - Unknown Hauppauge Tuner 0xa Hauppauge WinCast/TV, Philips NTSC tuner, remote control. The problem with the driver can be found at: www.wam.umd.edu/~culverk/fxtv.jpg I am positive that this problem is not with X or fxtv, I have already talked to the X people about this problem. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current no longer builds on the alpha
What is beast? I was happily able to build -current at about 5 this morning on a pc164. It's an Aspen systems DEC Durango PC164 motherboard based system. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: modules in ports
On 03-Dec-99 Nick Hibma wrote: Has anyone ever devised a good way to put a module in a port? Well the skip port creates a module.. Maybe it is the more general question of how to relate modules to other parts of the base system, like the kernel, downloadable firmware files, etc. Urk! :) Creating a module which will build outside the source tree is fairly simple, for an example have a look at wpaul's if_dc driver which does this. Then you can just install in in /usr/local/share/myport/kld and load it from /usr/local/etc/rc.d/myport.sh --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: modules/netgraph/bpf breaks world
thanks, committed.
For thise wondering this is a netgraph node that can do arbitrary
filtering using the existing bpf engine.
And just when is ipfw going to become a netgraph node 0.5 * :-)
God I wish I had some free time to go play with this code!!
On Fri, 3 Dec 1999, Steven G. Kargl wrote:
*** Makefile.orig Fri Dec 3 16:46:54 1999
--- MakefileFri Dec 3 16:46:25 1999
***
*** 6,11
MAN8= ng_bpf.8
KMODDEPS= netgraph
! .PATH:../../../net
.include bsd.kmod.mk
--- 6,11
MAN8= ng_bpf.8
KMODDEPS= netgraph
! .PATH:${.CURDIR}/../../../net
.include bsd.kmod.mk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Bktr driver
Kenneth Culver wrote... It seems that the bktr driver is still broken. I have looked through the code for the driver, and have yet to find the problem. here is a dmesg output with the error that seems to be causeing my problem: bktr0: BrookTree 878 irq 9 at device 17.0 on pci0 bktr0: Hauppauge Model 61291 D110 Warning - Unknown Hauppauge Tuner 0xa Hauppauge WinCast/TV, Philips NTSC tuner, remote control. The problem with the driver can be found at: www.wam.umd.edu/~culverk/fxtv.jpg I am positive that this problem is not with X or fxtv, I have already talked to the X people about this problem. You should probably look at the -multimedia list. Chris Csanady reported that his problems went away when he backed bktr_core.c from version 1.102 to version 1.101. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: bdevs have been assimilated.
Excerpts from FreeBSD-Current: 2-Dec-99 Re: HEADS-UP: bdevs have be.. by "David O'Brien"@FreeBSD. At 2MB the Alpha fixit floppy isn't very useful. Nor is there a live files system for the Alpha. Nor can you even boot sysinstall and get a shell if you use a serial console. All-in-all recovery on the Alpha is "lacking". Yup, at the times when I trashed my alpha install the install disk and NFS have been my only friends (the emergency shell is just enough to get you to mount_nfs a snapshot sitting elsewhere, albeit not in a friendly way not even having 'ls' :) One could make an NFS-client bootdisk for rescue, although a live cdrom fits the bill far better... is there room on the i386 disk for alpha bits? It would save having to ship an extra disk if that's an issue. It's no big deal to cd /cdrom/alpha, maybe toss a few symlinks around, to easilly recover the system. Tom (who is joyful enough since floppy support appeared on the alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Importing OpenSSL
I would like to get OpenSSL imported into -current. I currently have the build framework almost ready to go, I'm just running some buildworld tests to make sure it's working properly. OpenSSL would give a number of potential benefits. Some of the coolest ones are: * Precursor to importing OpenSSH and providing secure network connectivity out-of-the-box * Possibility of teaching fetch to talk to https servers (i.e. talk SSL) * Fixing the HUGE SECURITY HOLE in CTM, namely the fact that it provides no authentication of what it's stuffing into your source tree (it only provides integrity). * Integration of cryptography into other parts of the system where it would be useful. There are potential issues which need to be addressed before this can proceed, namely how to best deal with US patent restrictions on e.g. the RSA code. What I'm thinking of is this: * distribution sites within the US carry an "openssl-lite" distribution which has all the RSA code removed, plus anything else which is usage restricted (IDEA?). This absolves them from any legal liability for providing patented source code. International sites carry the full version. * Supposing someone in the US downloads the RSA code from an international site, the RSA code would only be built conditional on USA_RESIDENT == NO. Currently we don't set USA_RESIDENT out of the box (AFAIK) - this would mean that US people have to take explicit action in order to have RSA binary code built. At least this way no-one will accidentally ship a product containing RSA, although I don't know if it's still illegal to just possess (non-RSAREF) RSA source without a license. This has the downside that international folks have to also take explicit action to get RSA built, but it's probably better to be conservative and document the process well. I think it's high time we expanded our cryptographic support beyond the bare minimum of DES - anyone violently disagree? Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Importing OpenSSL
I think you should look at exactly how OpenBSD 2.6 has integrated it and then report back with your amended proposal. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Importing OpenSSL
I think it's high time we expanded our cryptographic support beyond the bare minimum of DES - anyone violently disagree? On the contrary; I violently agree! We need to make OpenSSH work with K5 as a matter of priority. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
