RSA support..
I have been trying to get ssh working in current, but with no luck. Since I updated recently, all I get is: ssh: no RSA support in libssl and libcrypto. See ssl(8). I have been off the lists for a bit, so I apologize if I missed something, but this has always been confusing. It used to just work. Now that i doesn't though, I have no clue where to start looking. There appears to be no ssl(8) manpage, or anything in the list archives about this. Thanks, Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA support..
On Thu, 29 Jun 2000 02:25:50 CDT, Chris Csanady wrote: I have been trying to get ssh working in current, but with no luck. Since I updated recently, all I get is: ssh: no RSA support in libssl and libcrypto. See ssl(8). This is the system's way of punishing you for neglecting your cvs-all mail, your freebsd-current mail and your src/UPDATING file. Hmm, I read through UPDATING, but didn't find much about this.. Your kernel is lacking support for the random device. Do your reading and smile. :-) I have been off the lists for a while, yes. :) Thanks very much for this tidbit.. Chris 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
Re: linux emulation broken.. (solution)
I *know* someone else said it wasn't so, but just 3 weeks ago I had this very problem, with word perfect, and it works just fine now. Are you sure you have a really up to date linux_base port installed? It was recently changed, a *lot* of new libs added, and I'd really like an answer on this, whether I'm right or wrong. Well, I found a solution to my problems with running linux-netscape and word perfect. It looks like it was not the linux emulation code that was at fault. I recently installed a real redhat 6.1, and mounted it on /compat/linux. Now all is well--so I can only assume it is some weird interaction between the linux_base port and my system. Maybe it is related to using XFree86 3.9.15, but I don't have the time to test that theory right now. Certainly not a great solution, but if things are broke for you this at least works. Chris Csanady To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
linux emulation broken..
It has been getting worse and worse for me recently. The two applications where it is noticeable are netscape, and word (im)perfect. I was using the linux version of netscape, until recently when it began hanging for long periods of time during network or disk activity. For a while with WP, it was fairly useable, except I could not print with it. Now though, I can't even save files, it hangs at the Save As dialog. I'm sorry I can't be more specific, but with a kernel from today it is still broken. I don't have time to go into it any further right now, but I thought I would check if others are having similar difficulties. I have a lot to do, and it is just extremely irritating right now. I swear, nothing relating to linux ever works.. I have the pleasure of using at it work on a regular basis, and it has been nothing but a complete PITA. So much time wasted. Sorry, I couldn't help including my $0.02 wrt linux.. Chris Csanady To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Some interrupt bogons still around.
my stock SB16 + freebsd+x11amp hasn't worked right since newbus. sound skips quite a bit. /me too I noticed the same thing. /usr/ports/audio/gqmpeg is a nice player which uses mpg123 as the backend; it plays fine. I think it may have just have something to do with x11amp, which should probably be considered a bogon itself. All other sources of sound work fine, like fxtv. Really? mpg123 and fxtv are broke for me. Have you tried using fxtv to capture audio and then play it back? I haven't tried it in a while, but they both acted like x11amp with regard to the skipping. x11amp still does not work right for me though.. This is on different audio hardware as well.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus, pcm, and matcd (was Re: new-bus breaks both sound drivers)
mp3s aren't playing quite right with x11amp though, little skips here and there, they work fine with the old kernel. mpg123 seems fine, as does the sound in FXTV. I'll try making the world again. Was there ever any resolution/further inspection of this? Not as far I know; its still happening here. cmp3 (mpg123) also skips in the same way, but its much less noticeable. I've been updating and recompiling almost daily. Ugh. This also has the same effect on captured audio using fxtv. It seems that everything audio related is messed up now. (Or perhaps real time?) I will try to find the exact day where things broke I guses. I don't have much time right now though.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
Hmm, you might like to try this patch and see what happens, there is a missing old driver wrapper for the pcm stuff. As a result, it's not getting run from the isa probe. Regarding the other driver, I'm not sure what's going on there as the hooks appear to be present. Right on, that patch does it for me. pcm0 at port 0x220 irq 5 drq 1 flags 0x15 on isa0 pcm0: interrupting at irq 5 I've got an old SB16 Value, non-pnp. mp3s aren't playing quite right with x11amp though, little skips here and there, they work fine with the old kernel. mpg123 seems fine, as does the sound in FXTV. I'll try making the world again. Was there ever any resolution/further inspection of this? x11amp behaves similarly for me. Actually, under considerable load, it is *really* bad. Have there been any notable scheduling changes recently? I remember people were seeing overflows on their serial ports after the new-bus integration since the driver was no longer using fast interrupts or something. Could there be something similar with the pcm driver? Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus breaks both sound drivers
Chris Piazza wrote: On 17-Apr-99 Brian Feldman wrote: Both sound drivers are broken with the new-bus code. My SB16, in the old driver, now gets recognized but sbxvi is never looked for. pcm0, the new driver, never initializes with the new code :( device pcm0 at isa? port? tty irq 5 drq 1 flags 0x16 The pcm0 sounddriver works for me. In fact, the only problem I had with new bus was it is now pcm0 instead of pcm1 ;-). es0: AudioPCI ES1370 at device 9.0 on pci0 pcm0: using I/O space register mapping at 0xd800 es0: interrupting at irq 4 device pcm0 On two different systems it works for me using pcm0.. This is an ESS clone card: Probing for PnP devices: CSN 1 Vendor ID: ESS1868 [0x68187316] Serial 0x Comp ID: PNPb02f [0x2f b0 d041] ESS1868 (rev 11) pcm1 (ESS1868 ESS1868 sn 0x) at 0x220-0x22f irq 5 drq 1 on isa This is an on-board Crystal SB-like PnP device: Probing for PnP devices: CSN 1 Vendor ID: CSC0b36 [0x360b630e] Serial 0x Comp ID: @@@ [0x00 00 ] mss_attach CS42361 at 0x530 irq 5 dma 1:0 flags 0x10 pcm1 (CS423x/Yamaha/AD1816 CS4236 sn 0x) at 0x530-0x537 irq 5 drq 1 fl ags 0x10 on isa For what it's worth, PnP has for the most part not been changed under new-bus and is using the old mechanisms. The only significant risk is that the attach code doesn't like what I've done with the emulation of isa_device-id_id for unit numbers. I thought PnP was not even using new-bus yet?! I haven't used PnP in a long time, but the pcm driver is broke for me too. I have used the following successfully with just the plain isa0 for quite some time.. device pcm0 at isa? port? tty irq 5 drq 1 flags 0x10 I'm sorry, you're going to need to have a bit of a look around and turning on or inserting some debug code to see what's happening. Where should I start? It doesn't print out anything upon boot.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!!!! Important instructions for -current users!
As of a few minutes ago, a minimal set of changes to bring the so-called 'new-bus' functionality to the i386 kernel in -current. This seems to have broken disk wiring for me. Is there some necessary change in syntax that I am not aware of? I have the following scsi related stuff in my config file.. controller ahc0 controller ncr0 controller ncr1 controller scbus0 at ahc0 controller scbus1 at ncr0 controller scbus2 at ncr1 device da0 device cd0 device pass0 diskda0 at scbus2 target 0 diskda1 at scbus2 target 1 diskda2 at scbus1 target 2 ..and when I try to build a kernel, it fails. Also, for some reason I seem to need both the ncr0 and ncr1 or config complains. These are the error messages I get: cc -c -O2 -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf ioconf.c ioconf.c:111: warning: `da0_count' redefined ioconf.c:100: warning: this is the location of the previous definition ioconf.c:107: redefinition of `da0_resources' ioconf.c:98: `da0_resources' previously defined here Any ideas what the problem may be? In any case, it is very nice to see new-bus being integrated. I have been awaiting loadable PCI drivers for some time. :) Great work.. Thanks, Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Serious mbuf cluster leak..
On Thu, 11 Feb 1999 09:15:29 -0800 Justin C. Walker jus...@apple.com wrote: I can say that our implementation doesn't seem to = suffer from this problem. Could be there's an issue in the use of = PRUS_* v. the socket state we use. The code in my kernel looks like: The NetBSD code looks pretty much just like this, and also does not suffer from an mbuf cluster leak of any kind. I'll take a look at the NetBSD code when I have a chance. Are you sure you just have not seen it though? I only see it over gigabit ethernet, and even then only when doing lots of large writes. Perhaps it is a timing issue? I am only pointing out what I see. It does not happen with source from before this change--so what else should I think? You are welcome to take a glance at my driver, although I don't think it is the problem. There are only 2 places where clusters are touched, and they never become seperate from the mbuf header. But I don't see any mbuf leak.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Serious mbuf cluster leak..
After a while, I have determined the cause of the leak to be the following commit. Although, I can't seem to find any reason why it would cause this behavior--reverting these files fixes it. Any thoughts? fenner 1999/01/20 09:32:01 PST Modified files: sys/kern uipc_socket.c sys/netinet tcp_output.c tcp_usrreq.c tcp_var.h sys/sys protosw.h Log: Add a flag, passed to pru_send routines, PRUS_MORETOCOME. This flag means that there is more data to be put into the socket buffer. Use it in TCP to reduce the interaction between mbuf sizes and the Nagle algorithm. Based on: Justin C. Walker jus...@apple.com's description of Apple's fix for this problem. Revision ChangesPath 1.50 +4 -2 src/sys/kern/uipc_socket.c 1.32 +3 -2 src/sys/netinet/tcp_output.c 1.40 +7 -2 src/sys/netinet/tcp_usrreq.c 1.49 +18 -17src/sys/netinet/tcp_var.h 1.26 +2 -1 src/sys/sys/protosw.h I have been seeing a nasty cluster leak in both 3.0 stable and 4.0 current as of today. Until now, I thougt maybe it was something in my driver, athough after much careful looking over my code, it simply does not look possible. Also, I downgraded to current of Dec 12, and the problem dissappears. The odd thing is that the clusters that leak don't seem to be attached to mbufs. Or at least there is not a 1-1 ratio. Following is netstat output after a while of running netpipe in streaming mode. (NPtcp -s; see ftp://ftp.scl.ameslab.gov/pub/netpipe) Also, the leak only becomes apparent when the send write size is very large--several hundred K to several megabytes. Does anyone have any idea what this may be? I really am not sure where to look aside from trying prorgressively newer kernels. Also, I only have alphas to test on right now.. puck:~ netstat -m 211/416 mbufs in use: 116 mbufs allocated to data 95 mbufs allocated to packet headers 1674/1688/2048 mbuf clusters in use (current/peak/max) 3480 Kbytes allocated to network (97% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Chris Csanady To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How many people use VI? This is unbelievable..
I unfortunately have a lot of data to type in, and to my surprise the keypad is unuseable in vi. It doesn't even work in vim. Thank god it works on Irix--I thought I would be using ee. Anyways, here is what happens when I type the digits 1-9 on the keypad while in insert mode.. y x w v u t s r q Chris Csanady To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How many people use VI? This is unbelievable..
On Wed, Feb 03, 1999 at 09:53:05PM -0600, Chris Csanady wrote: I unfortunately have a lot of data to type in, and to my surprise the keypad is unuseable in vi. It doesn't even work in vim. Thank god it works on Irix--I thought I would be using ee. Anyways, here is what happens when I type the digits 1-9 on the keypad while in insert mode.. y x w v u t s r q You don't say what terminal emulator you're using, but with xterm, the application keypad option gets enabled when entering vi, which prevents the keypad from generating numbers. You can change it once in vi with the Ctrl+left-button menu. I haven't looked into this sufficiently to know the direct cause of this behaviour. Maybe it could be avoided by tuning the termcap entry? Maybe 'vi' (as the application) should interpret the sequences in the correct way? This was using the xterm termcap entry. Although when I login to other machines running DU4.0 or Irix6, vi works without touching anything. Regardless, I would be inclined to blame this on our vi. I don't understand much about tercap entries, but this certainly violates POLA. :( So does this mean that the default xterm entry should be different? Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: /etc/nsswitch.conf
I noticed that NetBSD is switching over to using /etc/nsswitch.conf (like Slowlaris, PH-UX, etc.). Would it be a good idea to do this for FreeBSD too (when I first started using FreeBSD, it took me a long time to figure out the analogous file for hostname lookups was /etc/host.conf) -- it seems consolidating all that config information would in one place would be a good thing. I would really like to see this integrated into FreeBSD. Does anyone have any plans to do this? It would be really nice to be able to do lookups using hesiod or perhaps even LDAP. Btw, has anyone looked at nsd in Irix6.5? It is quite interesting.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
