Re: Ralink driver and FreeBSD 6.2?
A couple of things. - The newer rt2661.c driver has not been MFC'd to 6.2. That is most likely why your card is not working. - 'ifconfig' when run as root will load the module for a network driver provided it is a) in the path and b) name if_interface name.ko -Kip Hi Kip! That's good to hear - it actually didn't occur to me to peruse the 7.0 sources for improvements. I'll take a look at the -CURRENT rt2661.c source and see if a back-port to 6.2 is easy enough to do. Thanks for the pointer! - Dave Rivers - ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Ralink driver and FreeBSD 6.2?
I've got a Dell Dimension 4100 (circa 2000) running FreeBSD 6.2. I plugged in a Linksys WMP54G wireless PCI card, which should be supported by the 'ral' driver. However, my pciconf says: [EMAIL PROTECTED]:9:0: class=0x028000 card=0x00551737 chip=0x03011814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' class= network Note that it is labeled as none2. Also, then, the boot messages do not display anything about detecting an ral0 card. And, therefore the command: ifconfig ral0 simply gets ifconfig: interface ral0 does not exist Has anyone had any luck getting this card and the ral driver working with FreeBSD 6.2? - Thanks - - Dave Rivers - -- rivers dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Linksys WMP54G + ndis = panic
Well - I gave up on the ral(4) driver - seems it doesn't support the WMP54Gv4.1 linksys card. So - I've got ndis working. I can ifconfig ndis0, set the ssid and wepkey, etc... And - DHCP will get the wireless configured (IP address, default route, etc...) But - on the first packet after that (e.g. ping or any other network traffic) - I get an instant panic. I'm going to get a kernel dump to see what's going on, but I was wondering if this has already been seen? This is FreeBSD 6.2-RELEASE, straight off the CDs. - Thanks - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ralink driver and FreeBSD 6.2?
Forent Thoumie wrote: On Mon, 2007-02-19 at 23:05 -0500, Thomas David Rivers wrote: I've got a Dell Dimension 4100 (circa 2000) running FreeBSD 6.2. I plugged in a Linksys WMP54G wireless PCI card, which should be supported by the 'ral' driver. However, my pciconf says: [EMAIL PROTECTED]:9:0: class=3D0x028000 card=3D0x00551737 chip=3D0x03011814 re= v=3D0x00 hdr=3D0x00 vendor =3D 'Ralink Technology, Corp' class=3D network Load the if_ral.ko module using kldload (or/and /boot/loader.conf) or recompile your kernel with device ral. PS: This is a question for [EMAIL PROTECTED], not [EMAIL PROTECTED] -- Florent Thoumie Hi Florent! Many thanks for the suggestion - I should have provided more information, but, in fact, I did have the proper command in /boot/loader.conf. This was with the out-of-the-box GENERIC kernel. When I added the option in /boot/loader.conf, it complained about ral already being there - so I'm pretty sure it's in the kernel. That's what led me to freebsd-hackers instead of freebsd-stable, as something is amiss here. I'm beginning to wonder if it's the version of the card. Apparently, Ralink has a few versions - this is the linksys WMP54G version 4.1 instead of version 4.0. Perhaps the probe in if_ral.c doesn't find this card? I last did serious Freebsd kernel debugging in the FreeBSD 4.x timeframe, and a *lot* of things have changed since then. As soon as I can find my way around again, I'll start looking into what's going on. Also - on a related thread - using NDIS on this card doesn't work too well either. I can ifconfig the card, use DHCP to get everything set-up, but the first packet moving through it gets a very lovely panic.When I get kgdb up-and-running, I'll have more info to pass along. Thanks again! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FLEX, was Re: Return value of malloc(0)
Randall Hyde [EMAIL PROTECTED] BTW, if anyone is intrested in the full FLEX source, it's part of the HLA (High Level Assembler) source package found here: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip Just wondering if those guys knew that IBM calls their mainframe assembler the High Level Assembler, which they abbreviate HLASM. This isn't an x86 assembler like HLA - it's a z/Architecture (mainframe) assembler, very different beast indeed. But - they may want to pick a new name, lest they incur the wrath of IBM's lawyers. I think IBM took that name in the 80s. Also - it seems that 'webster.cs.ucr.edu' has gone missing from DNS somehow; so I wasn't able to look at the source, although I was able to look at the web pages thanks to Yahoo's cache. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
flock() returns EHOSTUNREACH on 5.3 with 4.5 NFS server
I'm applying flock() to a file that is on an NFS server. The program calling flock() is built on a 4.5 system, with the 4.5 libraries, etc... The NFS server is a 4.5-RELEASE system. The program running on a 4.5-release system doesn't display any problems. But - when I run that same program on a 5.3-RELEASE system, flock() returns with a -1 and sets errno to EHOSTUNREACH. Of course, the code is checking for EEOPNOTSUPP, but it doesn't expect to see EHOSTUNREACH from flock(). We changed it to set errno to zero to make sure that simply wasn't a dangling value in errno. Any ideas about what could be going on? Should flock() be setting errno to EHOSTUNREACH? And, as the file can be read, I don't understand where the EHOSTUNREACH comes from (the host is very reachable.) - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
Everyone, If I'm remembering correctly - the historical way to do this is to alias the rm command to something that else that checks the arguments and complains appropriately (and then executes /bin/rm.) Typically with just a shell alias. That keeps you from accidently doing something. Just thinking that putting extra smarts into a utility isn't the typical UNIXy way to do this. Let each tool do the one thing it does really well.. 'rm' removes; let it remove. I think, in the old UNIX Review magazine (what - almost 15+ years ago now?) There was a couple of examples of this. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more info on pccard insertion hang...
M. Warner Losh [EMAIL PROTECTED] wrote:
In message: [EMAIL PROTECTED]
Thomas David Rivers [EMAIL PROTECTED] writes:
: Warner - any ideas?
: pci_write_config(..., bcr,2); hangs
Interesting
So this pretty much confirms what I'd expect. We establish the
interrupt handler, then turn on the interrupts, then hang. I suspect
that there's an interrupt in the bridge that isn't being acked. Maybe
there's something in the pcic_pci_intr that should do that it isn't.
There's also one thing that I've been thinking about in the back of my
mind that you might want to check. I read in the mindshare books that
the we're supposed to mask one of the interrupts while we're powering
the card up. Maybe that's left over and we're not clearing it
properly.
Does adding
for (i = 0; i 0x40) sp-getb(sp, i);
at the end pcic_pci_intr do anything for you? The PCIC_STAT_CHG
should do that, but I'm not sure why it isn't.
I added:
{
int i;
for(i=0;i0x40;i++) {
sp-getb(sp,i);
}
}
to the end of pcic_pci_intr() - but that didn't change anything...
got the same hang in exactly the same place...
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: more info on pccard insertion hang...
M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Thomas David Rivers [EMAIL PROTECTED] writes: : to the end of pcic_pci_intr() - but that didn't change anything... : got the same hang in exactly the same place... Sounds like we may need to do the more extensive interrupt blocking/masking. Warner Well - unfortunately I'm nothing more than a (slow) keyboard/screen for you... I don't know squat about PCI interrupts... But - I'm happy to try things out, just let me know what you need. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
more info on pccard insertion hang...
OK - after *many* additional printf()s, and following the control flow through several twisty passages (all alike), I've figured out _where_ the hang is happening but, not why... First - the card is inserted, and the various callbacks occur... pccardd gets involved and reads the CIS to determine the kind of card that was inserted. We actually get through the pcic stuff, and through the device probe and attach. It's determined that the card is an ed-compatible ethernet card. Then, we try to set the interrupt for that card. (apparently, it's being set as an ISA interrupt number, even though pcic is using PCI interrupts.) This then hangs in pci_cfgdisable(). I'm hand-typing in the ddb trace results here, so forgive any obvious typo: --- interrupt, eip = 0xc0350d24, sp=0xc635eb14, ebp = 0xc635eb1c --- pci_cfgdisable(c0cc1808,2,c635eb4c,c03506ae,0) at pci_cfgdisable+0x1c pcireg_cfgwrite(0,c,0,3e,420) at pcireg_cfgwrite+0x54 pci_cfgregwrite(0,c,0,3e,420) at pci_cfgregwrite+0x1a pci_cfgwrite(c0cc1808,3e,420,2,c0396702,c0396630,c0cc1780,c03966c0,c0396697) at pci_cfgwrite+0x23 pci_write_config_method(c0cbd180,c0cc1780,3e,420,2) at pci_write_config_method+0x4e PCI_WRITE_CONFIG(c0cbd180,c0cc1780,3e,420,2) at PCI_WRITE_CONFIG+0x3a pcic_pci_gen_func(c0cc0a3c,2,c038d300,2,9) at pcic_pci_gen_func+0xa6 pcic_pci_ricoh_func(c0cc0a3c,2,c038d7e0,c0cc0a00,4) at pcic_pci_ricoh_fun+0x1d pcic_pci_gen_mapirq(c0cc0a3c,9,c0e03000,c0ccac00,c0df2680) at pcic_pci_gen_mapirq+0x56 pcic_pci_setup_intr(c0cc1780,c0df2680,c0ded8c0,4,c031898c) at pcic_pci_setup_intr+0xc1 BUS_SETUP_ITR(c0cc1780,c0df2680,c0ded8c0,4,c031898c) at BUS_SETUP_INTR+0x40 bus_generic_setup_intr(c0ccac00,c0df2680,c0ded8c0,4,c031898c) at bus_generic_setup_intr+0x2e BUS_SETUP_INTR(c0ccac00,c0df2680,c0ded8c0,4,c031898c) at BUS_SETUP_INTR+0x40 bus_setup_intr(c0df2680,c0ded8c0,4,c031898c,c0e03000) at bus_setup_intr+0x24 ed_pccard_attach(c0df2680,c635ed44,c01cdc05,c0df2680,c037ff53) at ed_pccard_attach+0x85 DEVICE_ATTACH(c0df2680,c037ff53,0,c0df2680,c0d4de00) at DEVICE_ATTACH+0x2e device_probe_and_attach(c0df2680,c038c0e0,c0cc0800,c0ac5006,c59ef60) at dvice_probe_and_attach+0x8d allocate_driver(c0cc0800,c0d4de00,c635ede4,c0ccab80,c595ef60) at allocate_driver+0x223 crdioctrl(c0ccab80,c0ac5006,c0d4de00,3,c595ef60) at crdioctl+0x3ca spec_ioctl(c635ede4,c635edcc,c02db1fd,c635ede4,c635ee74) at spec_ioctl+0x26 spec_vnoperate(c635ede4,c635ee74,c01fabab,c635ede4,c0d10180) at spec_vnoperate+0x15 ufs_vnoperatespec(c635ede4,c0d10180,0,ac,a03bbf00) at ufs_vnoperatespec+0x15 vn_ioctl(c0d10180,c0ac5006,c0d4de00,c595ef60,c595ef60) at vn_ioctl+0x10f ioctl(c595ef60,c635ef80,8072140,8072100,0) at ioctl+0x20a syscall2(2f,2f,2f,0,8072100) at syscall2+0x1f5 Xin0x80_syscall(0 at Xint0x80_syscall+0x25 db So - it seems the hang is occuring when trying to set up interrupts in the pcic_pci_gen_func() function. Using liberal printf()s - I've determined that `way' is pcic_iw_pci. So - it would seem that the following should be executed: bcr = pci_read_config(...) // bcr is 0x4a0 bcr = ~CB_BCR_INT_EXCA;// bcr becomes 0x420 pci_write_config(..., bcr,2); hangs Warner - any ideas? I'm wondering - it seems we're trying to set the ethernet's irq to #9 - which was also used for the pcic card... could there be some non-obvious interrupt confusion here? - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: any file -- symbol in .o file
E.B. Dreger [EMAIL PROTECTED] wrote: Greetings all, Eddy, Instead of a system-specific approach, you might want to take advantage of what the C language has to offer. For example, your multi-line issue. You realise that the C preprocessor/compiler will concatentate adjacent character string constants, forming one constant. So, you could code this up as: const char foo[] = \Escape\ chars make strings in 'C' code...\n ...messy. But - at least, line breaks are not an issue.\n; I don't have a nice way around the escapes needed for quotes though... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pccard hang - how to start debugging?
M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Thomas David Rivers [EMAIL PROTECTED] writes: : Also - I need to understand why this machine worked so well with : 4.1-RELEASE, and doesn't with 4.5-RELEASE. I'm guessing there : was a significant change of some kind?.. Yes. We went from using ISA interrupts to PCI interrupts. Warner Ah... Ok - the next question would be - is there a way to un-do that? Since ISA interrupts worked before? - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pccard hang - how to start debugging?
M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Thomas David Rivers [EMAIL PROTECTED] writes: : Ok - the next question would be - is there a way to un-do that? : Since ISA interrupts worked before? hw.pcic.intr_path=1 is supposed to do that. Warner Hmm... When I do that, my machine won't boot... it hangs. Unfortunately, in preparation for figuring this out, I took the laptop to the office and left it there on Friday, so I can't try things again. I'm thinking I just need to start over with the issue and see what happens. On Monday, I'll try setting hw.pcic.intr_path=1 to see how that does. But - just so I don't make a silly mistake - could you spell out exactly how that should be done? I'm thinking that the right way to do this is to put: hw.pcic.intr_path=1 in /boot/loader.conf Is that correct? - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pccard hang - how to start debugging?
In message: [EMAIL PROTECTED] Thomas David Rivers [EMAIL PROTECTED] writes: : : OK - : : pccard (or, more likely, the pcic driver) hangs when I insert : my ethernet card into the pcmcia slot on my VAIO F480 (with : 4.5-RELEASE.) : : The entire machine is hung up tight. : : When I remove the card, everything comes alive again : : This clearly feels like a missed interrupt somewhere... : : So - how do I start to attack this problem? I was thinking DDB : in the kernel would be the way to go, but if the machine is hung, : how do I interrupt it? Set a breakpoint in pcic_pci_intr before inserting the card. Try reading various exca registers by hand to see if reading one of them fixes things. Try looking at the pci memory mapped cardbus registers. Get lots of datasheets. OK - I'll start looking around : Any thoughts on how to debug this issue would be greatly : appreciated. I'm hoping a little stumbling around, err debugging, : will shed light on this. Good luck. I fought this one for a long time and gave up in the end and putting the hw.pcic.intr_path in as a work around. But... that doesn't work for me. If it set it to 1 - the machine will not boot. Also - I need to understand why this machine worked so well with 4.1-RELEASE, and doesn't with 4.5-RELEASE. I'm guessing there was a significant change of some kind?.. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
pccard hang - how to start debugging?
OK - pccard (or, more likely, the pcic driver) hangs when I insert my ethernet card into the pcmcia slot on my VAIO F480 (with 4.5-RELEASE.) The entire machine is hung up tight. When I remove the card, everything comes alive again This clearly feels like a missed interrupt somewhere... So - how do I start to attack this problem? I was thinking DDB in the kernel would be the way to go, but if the machine is hung, how do I interrupt it? Any thoughts on how to debug this issue would be greatly appreciated. I'm hoping a little stumbling around, err debugging, will shed light on this. - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Anyone using pptp?
Dear Thomas, Well - I'm still trying to get pptp to cooperate and set up a VPN connection to a Microsoft VPN server. I'm just wondering - is there _anyone_ out there that has met with success using pptp - and, if so, could you share your /etc/ppp/ppp.conf settings? http://kjkoster.org/?page=content/adsl.jsp It's specific for my provider, though. Kees Jan Thanks Kees! I read through your web pages - very nicely done, by the way! But - I'm afraid your /etc/ppp/ppp.conf doesn't work for me. Here's the current issue: The Microsoft VPN server I'm talking to is insisting on an encrypted MPPE connection at the LCP level. That connection requires MSChapV2 (0x81). If I add enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. So - I'm in the situation of both requiring and disallowing MSChapV2. Does anyone know if there is a way in /etc/ppp/ppp.conf to accomplish this? Some people on the Linux lists suggested that the FreeBSD ppp might have a noauth option, which meant that the peer didn't have to authenticate itself - but I couldn't find such an option. Any pointers would be appreciated! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Dominic Marks [EMAIL PROTECTED] wrote: On Wed, May 01, 2002 at 03:47:13PM -0400, Thomas David Rivers wrote: Well - I'm still trying to get pptp to cooperate and set up a VPN connection to a Microsoft VPN server. I'm just wondering - is there _anyone_ out there that has met with success using pptp - and, if so, could you share your /etc/ppp/ppp.conf settings? http://www.freebsd.org/handbook/pppoa.html Ah yes - that contains the same ppp.conf I have now. And - as I just detailed in other e-mail - it's not working for me... From the ppp.log file - it seems I have to have MSChapV2 both enabled and disabled at the same time. At some points in the negotiation it needs to be disabled (i.e. *not* used for authenticating the peer) - but at other points it needs to be enabled (to allow MPPE encryption - which the Microsoft peer requires.) - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Julian Elischer [EMAIL PROTECTED] wrote: I've always had better success using the mpd port for pptp.. It's installed now :-) I'm going to try and give it a go this morning! I'll let everyone know how it goes... - Thanks! - - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
mpd (was Re: Anyone using pptp?)
Julian Elischer [EMAIL PROTECTED] wrote: I've always had better success using the mpd port for pptp.. OK - I went through the mpd documentation, etc.. very nice. No problems setting things up, etc... However, mpd isn't working for me either. It makes it through the authentication, then has a complaint that is suspiciously like the problem with pptp-client. I've cut-and-pasted the log here. Any thoughts? - Thanks! - - Dave Rivers - Script started on Thu May 2 11:03:01 2002 office# mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 3199, version 3.2 ([EMAIL PROTECTED] 18:38 13-Sep-2001) [vpn] ppp node is mpd3199-vpn [vpn] using interface ng1 mpd: local IP address for PPTP is XXX.XX.XXX.X [vpn] IFACE: Open event [vpn] IPCP: Open event [vpn] IPCP: state change Initial -- Starting [vpn] IPCP: LayerStart [vpn:vpn] [vpn] bundle: OPEN event in state CLOSED [vpn] opening link vpn... [vpn] link: OPEN event [vpn] LCP: Open event [vpn] LCP: state change Initial -- Starting [vpn] LCP: LayerStart [vpn] device: OPEN event in state DOWN pptp0: connecting to XXX.XXX.X.XX:1723 [vpn] device is now in state OPENING pptp0: connected to XXX.XXX.X.XX:1723 pptp0: attached to connection with XXX.XXX.X.XX:1723 pptp0-0: outgoing call connected at 14808325 bps [vpn] PPTP call successful [vpn] device: UP event in state OPENING [vpn] device is now in state UP [vpn] link: UP event [vpn] link: origination is local [vpn] LCP: Up event [vpn] LCP: state change Starting -- Req-Sent [vpn] LCP: phase shift DEAD -- ESTABLISH [vpn] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2ac7d855 AUTHPROTO CHAP MSOFT [vpn] LCP: rec'd Configure Request #0 link 0 (Req-Sent) AUTHPROTO CHAP MSOFT MAGICNUM 07f67cce PROTOCOMP ACFCOMP CALLBACK Not supported MP MRRU 1614 ENDPOINTDISC [802.1] 00 80 5f 95 ae 21 UNKNOWN[23] len=4 [vpn] LCP: SendConfigRej #0 CALLBACK MP MRRU 1614 UNKNOWN[23] len=4 [vpn] LCP: rec'd Configure Ack #1 link 0 (Req-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2ac7d855 AUTHPROTO CHAP MSOFT [vpn] LCP: state change Req-Sent -- Ack-Rcvd [vpn] LCP: rec'd Configure Request #1 link 0 (Ack-Rcvd) AUTHPROTO CHAP MSOFT MAGICNUM 07f67cce PROTOCOMP ACFCOMP ENDPOINTDISC [802.1] 00 80 5f 95 ae 21 [vpn] LCP: SendConfigAck #1 AUTHPROTO CHAP MSOFT MAGICNUM 07f67cce PROTOCOMP ACFCOMP ENDPOINTDISC [802.1] 00 80 5f 95 ae 21 [vpn] LCP: state change Ack-Rcvd -- Opened [vpn] LCP: phase shift ESTABLISH -- AUTHENTICATE [vpn] LCP: auth: peer wants CHAP, I want CHAP [vpn] CHAP: sending CHALLENGE [vpn] LCP: LayerUp [vpn] CHAP: rec'd CHALLENGE #0 Name: Using authname X [vpn] CHAP: sending RESPONSE pptp0: CID 0xdac8 in SetLinkInfo not found [vpn] CHAP: rec'd SUCCESS #0 [vpn] LCP: rec'd Configure Request #3 link 0 (Opened) AUTHPROTO CHAP MSOFT MAGICNUM 0a8d47f5 PROTOCOMP ACFCOMP CALLBACK Not supported MP MRRU 1614 ENDPOINTDISC [802.1] 00 80 5f 95 ae 21 UNKNOWN[23] len=4 [vpn] LCP: LayerDown [vpn] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2ac7d855 AUTHPROTO CHAP MSOFT [vpn] LCP: SendConfigRej #3 CALLBACK MP MRRU 1614 UNKNOWN[23] len=4 [vpn] LCP: state change Opened -- Req-Sent [vpn] LCP: phase shift AUTHENTICATE -- ESTABLISH pptp0: CID 0xdac8 in SetLinkInfo not found [vpn] LCP: rec'd Configure Reject #2 link 0 (Req-Sent) AUTHPROTO CHAP MSOFT [vpn] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2ac7d855 [vpn] LCP: rec'd Configure Request #4 link 0 (Req-Sent) AUTHPROTO CHAP MSOFT MAGICNUM 0a8d47f5 PROTOCOMP ACFCOMP ENDPOINTDISC [802.1] 00 80 5f 95 ae 21 [vpn] LCP: SendConfigAck #4 AUTHPROTO CHAP MSOFT MAGICNUM 0a8d47f5 PROTOCOMP ACFCOMP ENDPOINTDISC [802.1] 00 80 5f 95 ae 21 [vpn] LCP: state change Req-Sent -- Ack-Sent [vpn] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2ac7d855 [vpn] LCP: state change Ack-Sent -- Opened [vpn] LCP: phase shift ESTABLISH -- AUTHENTICATE [vpn] LCP: auth: peer wants CHAP, I want nothing [vpn] LCP: LayerUp [vpn] CHAP: rec'd CHALLENGE #0 Name: Using authname X [vpn] CHAP: sending RESPONSE pptp0: CID 0xdac8 in SetLinkInfo not found [vpn] CHAP: rec'd SUCCESS #0 [vpn] LCP: authorization successful [vpn] LCP: phase shift AUTHENTICATE -- NETWORK [vpn] up: 1 link, total bandwidth 64000 bps [vpn] IPCP: Up event [vpn] IPCP: state change Starting -- Req-Sent [vpn] IPCP: SendConfigReq #1 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: Open event [vpn] CCP: state change Initial -- Starting [vpn] CCP: LayerStart [vpn] CCP: Up event [vpn] CCP: state change Starting -- Req-Sent [vpn] CCP: SendConfigReq #1 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #2 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #2 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP:
Re: Anyone using pptp?
Thomas David Rivers wrote: From the ppp.log file - it seems I have to have MSChapV2 both enabled and disabled at the same time. At some points in the negotiation it needs to be disabled (i.e. *not* used for authenticating the peer) - but at other points it needs to be enabled (to allow MPPE encryption - which the Microsoft peer requires.) You will need to add a knob. One knob is not enough. You can not have both tea and no tea at the sme time. -- Terry Clearly - A AND NOT A is not something that can exist. But - does anyone have an idea what that could be? I was thinking, perhaps incorrectly, that someone, somewhere, has already been there, done that. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Thomas David Rivers writes: If I add enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. Don't you want something like allow MSChapV2 and disable MSChapV2 ? -Archie Something like that... but - that's the default setting. With the default setting, it seems to pass through CHAP (0x80) Authentication. But - then, the MPPE encryption is not allowed - because MPPE compression requires MSChapV2 (0x81) Authentication... and, the VPN server doesn't authenticate that way. I notice there is a line in the ppp man page: For now, ppp can only get encryption keys from CHAP 81 authentication. But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't allow CHAP 81 authentication, but wants to use MPPE... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Archie Cobbs [EMAIL PROTECTED] wrote: Thomas David Rivers writes: enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. Don't you want something like allow MSChapV2 and disable MSChapV2 ? Something like that... but - that's the default setting. With the default setting, it seems to pass through CHAP (0x80) Authentication. But - then, the MPPE encryption is not allowed - because MPPE compression requires MSChapV2 (0x81) Authentication... and, the VPN server doesn't authenticate that way. I notice there is a line in the ppp man page: For now, ppp can only get encryption keys from CHAP 81 authentication. But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't allow CHAP 81 authentication, but wants to use MPPE... In that case you need to use mpd I guess. -Archie Yes - after some other investigation - I arrived at the same idea. mpd fails as well... with something very similar... it seems to send a CCP configuration request and simply gets no answer back from the Microsoft server. From the VPN log (you can see toward the bottom that both IPCP and CCP complain that parameter negotiation failed): [vpn] LCP: authorization successful [vpn] LCP: phase shift AUTHENTICATE -- NETWORK [vpn] up: 1 link, total bandwidth 64000 bps [vpn] IPCP: Up event [vpn] IPCP: state change Starting -- Req-Sent [vpn] IPCP: SendConfigReq #1 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: Open event [vpn] CCP: state change Initial -- Starting [vpn] CCP: LayerStart [vpn] CCP: Up event [vpn] CCP: state change Starting -- Req-Sent [vpn] CCP: SendConfigReq #1 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #2 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #2 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #3 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #3 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #4 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #4 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #5 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #5 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #6 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #6 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #7 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #7 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #8 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #8 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #9 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #9 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #10 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #10 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: state change Req-Sent -- Stopped [vpn] IPCP: LayerFinish [vpn] IPCP: parameter negotiation failed [vpn] IPCP: LayerFinish [vpn] CCP: state change Req-Sent -- Stopped [vpn] CCP: LayerFinish [vpn] CCP: parameter negotiation failed [vpn] CCP: Close event [vpn] CCP: state change Stopped -- Closed [vpn] CCP: encryption required, but MPPE was not negotiated in both directions [vpn] CCP: failed to negotiate required encryption [vpn] CCP: Close event [vpn] CCP: LayerFinish [vpn] IPCP: failed to negotiate required encryption [vpn] IPCP: LayerFinish [vpn] CCP: LayerFinish [vpn] bundle: CLOSE event in state OPENED [vpn] closing link vpn... [vpn] bundle: CLOSE event in state CLOSED [vpn] closing link vpn... [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] LCP: state change Opened -- Closing [vpn] LCP: phase shift NETWORK -- TERMINATE [vpn] up: 0 links, total bandwidth 9600 bps [vpn] IPCP: Down event [vpn] IPCP: state change Stopped -- Starting [vpn] IPCP: LayerStart [vpn] CCP: Down event [vpn] CCP: state change Closed -- Initial [vpn] CCP: Close event [vpn] closing link vpn... [vpn] LCP: SendTerminateReq #4 [vpn] LCP: LayerDown [vpn] bundle: CLOSE event in state CLOSED [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] bundle: OPEN event in state CLOSED [vpn] opening link vpn... [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] link: OPEN event [vpn] LCP: Open event [vpn] LCP: state change
Re: Anyone using pptp?
Terry Lambert [EMAIL PROTECTED] wrote: Archie Cobbs wrote: Thomas David Rivers writes: If I add enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. Don't you want something like allow MSChapV2 and disable MSChapV2 ? The MS PAP/CHAP stuff never made it to RFC because of the protocol layering violations. I think the problem T.D.R. is seeing are a result of not having some covert channel, which is *not* MSChapV2, to get a session key for the VPN session. I guess we need to see a packet trace for a Windows machine being successful, and a FreeBSD machine being unsuccessful, in order to run a side-by-side comparison. Believe me! I've asked for such a thingy... apparently, the magic software needed to do a packet trace on Windows isn't installed on the server. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Anyone using pptp?
Well - I'm still trying to get pptp to cooperate and set up a VPN connection to a Microsoft VPN server. I'm just wondering - is there _anyone_ out there that has met with success using pptp - and, if so, could you share your /etc/ppp/ppp.conf settings? - Many thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Lars Eggert [EMAIL PROTECTED] wrote: Thomas David Rivers wrote: Well - I'm still trying to get pptp to cooperate and set up a VPN connection to a Microsoft VPN server. I'm just wondering - is there _anyone_ out there that has met with success using pptp - and, if so, could you share your /etc/ppp/ppp.conf settings? This is a FAQ on -net. There's been a couple of threads on this recently, and configuration examples were posted for mpd. Lars Duh!!! I didn't even *think* of -net. Thanks for the pointer! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Anyone using pptp?
Dominic Marks [EMAIL PROTECTED] wrote: On Wed, May 01, 2002 at 03:47:13PM -0400, Thomas David Rivers wrote: Well - I'm still trying to get pptp to cooperate and set up a VPN connection to a Microsoft VPN server. I'm just wondering - is there _anyone_ out there that has met with success using pptp - and, if so, could you share your /etc/ppp/ppp.conf settings? http://www.freebsd.org/handbook/pppoa.html Thanks *very* much for the pointer I'll definately be looking at that soon! I wonder why a search of pptp at FreeBSD.org doesn't find this? Perhaps I mis-typed something? - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
pptp client?
I posted something on -questions, and got no reply... so, let me try here... Has _anyone_ been successfull at getting a pptp client connection to a Microsoft VPN server? I've - at last - gotten through two of the big hurdles, 1) Clearing the firewall to allow this to pass and 2) Getting the CHAP authentication to work. Now - right after it authenticates, I have the following in /var/log/ppp.log... and, as you can see, the link simply dies. My /etc/ppp/ppp.conf has: label: enable MSChap set authname set authkey set timeout 0 set ifaddr 0 0 alias enable yes And, here's the /var/log/ppp.log. *Any* pointers would be greatly appreciated! - Thanks! - - Dave Rivers - Apr 26 08:57:54 office ppp[294]: tun1: LCP: deflink: SendIdent(1) state = Opened Apr 26 08:57:54 office ppp[294]: tun1: Phase: bundle: Authenticate Apr 26 08:57:54 office ppp[294]: tun1: Phase: deflink: his = CHAP 0x80, mine = CHAP 0x80 Apr 26 08:57:54 office ppp[294]: tun1: Phase: Chap Output: CHALLENGE Apr 26 08:57:54 office ppp[294]: tun1: Phase: Chap Input: CHALLENGE (8 bytes from USRSVPN1) Apr 26 08:57:54 office ppp[294]: tun1: Phase: Chap Output: RESPONSE () Apr 26 08:57:55 office ppp[294]: tun1: Phase: Chap Input: SUCCESS Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: RecvConfigReq(4) state = Opened Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: LayerDown Apr 26 08:57:55 office ppp[294]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x80) Apr 26 08:57:55 office ppp[294]: tun1: LCP: MAGICNUM[6] 0x25240cb9 Apr 26 08:57:55 office ppp[294]: tun1: LCP: PROTOCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: ACFCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: CALLBACK[3] CBCP Apr 26 08:57:55 office ppp[294]: tun1: LCP: MRRU[4] 1614 Apr 26 08:57:55 office ppp[294]: tun1: LCP: ENDDISC[9] MAC 00:80:5f:95:ae:21 Apr 26 08:57:55 office ppp[294]: tun1: LCP: LDBACP[4] 1fac Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: SendConfigReq(2) state = Opened Apr 26 08:57:55 office ppp[294]: tun1: LCP: ACFCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: PROTOCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: ACCMAP[6] 0x Apr 26 08:57:55 office ppp[294]: tun1: LCP: MRU[4] 1500 Apr 26 08:57:55 office ppp[294]: tun1: LCP: MAGICNUM[6] 0xb6abbad9 Apr 26 08:57:55 office ppp[294]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x80) Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: SendConfigRej(4) state = Opened Apr 26 08:57:55 office ppp[294]: tun1: LCP: CALLBACK[3] CBCP Apr 26 08:57:55 office ppp[294]: tun1: LCP: MRRU[4] 1614 Apr 26 08:57:55 office ppp[294]: tun1: LCP: LDBACP[4] 1fac Apr 26 08:57:55 office ppp[294]: tun1: LCP: Sending ident magic b6abbad9 text user-ppp 2.3.2 (built Sep 18 2001) Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: SendIdent(2) state = Opened Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: State change Opened -- Req-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: RecvConfigRej(2) state = Req-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: Sending ident magic b6abbad9 text user-ppp 2.3.2 (built Sep 18 2001) Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: SendIdent(3) state = Req-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x80) Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: SendConfigReq(3) state = Req-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: ACFCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: PROTOCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: ACCMAP[6] 0x Apr 26 08:57:55 office ppp[294]: tun1: LCP: MRU[4] 1500 Apr 26 08:57:55 office ppp[294]: tun1: LCP: MAGICNUM[6] 0xb6abbad9 Apr 26 08:57:55 office ppp[294]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x80) Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: RecvConfigReq(5) state = Req-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x80) Apr 26 08:57:55 office ppp[294]: tun1: LCP: MAGICNUM[6] 0x25240cb9 Apr 26 08:57:55 office ppp[294]: tun1: LCP: PROTOCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: ACFCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: ENDDISC[9] MAC 00:80:5f:95:ae:21 Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: SendConfigAck(5) state = Req-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x80) Apr 26 08:57:55 office ppp[294]: tun1: LCP: MAGICNUM[6] 0x25240cb9 Apr 26 08:57:55 office ppp[294]: tun1: LCP: PROTOCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: ACFCOMP[2] Apr 26 08:57:55 office ppp[294]: tun1: LCP: ENDDISC[9] MAC 00:80:5f:95:ae:21 Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: State change Req-Sent -- Ack-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: deflink: RecvConfigRej(3) state = Ack-Sent Apr 26 08:57:55 office ppp[294]: tun1: LCP: Sending ident magic b6abbad9 text user-ppp 2.3.2 (built Sep 18 2001) Apr 26 08:57:55 office ppp[294]: tun1: LCP:
Re: locale problems with linux 7.1 base upgrade
Theo Pagtzis [EMAIL PROTECTED] wrote: Hi all, I upgraded to linux 7.1 base successfully for the purposes of getting linux java 1.4. The upgrade has created a consistent problem with the locale for any application that I am running. These applications are so far, Netscape and java 1.4 runtime. I have tried to set the XNLSPATH to some nls folder while I also tried a couple of en_US locales setup with LANG env var. Does somebody have any tips as to how to resolve this problem since it is a major showstopper for any application that makes use of locales, i.e. the application crashes as soon as it is run. I am running 4.5 STABLE and netscape is either 4.76 4.78 4.79 (the last two are linux based) Was there any resolution to this issue? I'm having exactly the same problem on 4.5-RELEASE (and XF86 4.2.) If someone actually _is_ using Netscape on 4.5-RELEASE with XF86 4.2, could they let me in on how they accomplished it? - Thanks! - - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Debugging natd?
The machine I redirected telnet too has changed IP addresses... And; I discovered after simply changing my natd_flags in /etc/rc.conf that natd isn't properly redirecting the port. I checked the messages log (/var/log/alias.log) and nothing appears to be amiss. (And, I've got -l on the natd_flags; but nothing is showing up in syslog) Here's the flags (this is 4.3-RELEASE): natd_flags=-l -m -u -redirect_port tcp 10.1.0.11:telnet -redirect_port udp 10.1.0.11:telnet -redirect_port tcp 10.1.0.26:telnet -redirect_port u dp 10.1.0.26:telnet (The previous/working IP addreses were 10.0.0.11 10.0.0.26.) So - per the subject - just how does one start debugging a problem like this - what tools are around to try and figure things out? - Thanks! - - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C++ to C translator
Hi, I have written some code in C++. However, I want to run it on an old mainframe machine, which a C++ compiler is not available. I know that the old g++ is a C++ to C compiler. Does anyone know which version it is? Also, anyone knows other C++ to C compilers? Thanks, Rayson Rayson, There are several C and C++ compilers available for the mainframe. (if you mean zSeries (nee IBM 390) mainframe. We market a C compiler HLASM compatible assembler (available natively, or as a cross-compiler/assembler.) See http://www.dignus.com IBM markets C C++ compilers. And SAS Institute markets C C++ compilers, see http://www.sas.com. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
Peter Pentchev [EMAIL PROTECTED] wrote:
On Thu, Jun 07, 2001 at 10:20:51AM -0700, John Baldwin wrote:
On 07-Jun-01 Peter Pentchev wrote:
On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote:
Hi,
Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr
with WARNS=2? (or more specifically, with -Wcast-qual)
Uhm. OK. So size_t may not be enough to hold a pointer. What is it then -
caddr_t?
uintptr_t for data pointers. In theory I think code pointers may not fit in a
uintptr_t.
free((void *)(uintptr_t)ptr) should work.
Of course, this begs the question of why you are free'ing a const. :)
OK, here's a scenario:
struct validation_fun {
const char *name;
valfun *fun;
int dyn;
};
This is a structure for a set of validation functions, referenced by
name from another type of object. There are some predefined functions,
present in the code at compile-time, and hardcoded in an array, with
names given as strings. Thus, the 'const'.
However, some of the functions may be defined at runtime, with both
name and code sent by a server. In that case, the name is a dynamically
allocated char *, which needs to be freed upon cleanup. So I have:
[cleanup function]
...
if (val-dyn)
free(val-name);
Any suggestions on how to improve the design to avoid this, if possible,
would be greatly welcome.
G'luck,
Peter
Since some strings are non-constant (the are allocated) - I believe
the `const' qualifier in the structure declaration is incorrect.
What happens if you simply don't have it in the structure declaration?
- Dave Rivers -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
GCC complains when I try to initialize the structure with something like:
struct validation_fun val_init[] = {
{init,valfun_init,0}
};
This can be avoided by:
struct validation_fun val_init[] = {
{(char *) (uintptr_t) init, valfun_init,0}
};
..but as a matter of fact, static, pre-initialized valfun structs are
the rule rather than the exception in this program, so having this
syntax for all of them seems.. well.. ugly :)
Ah.. I see..
(I don't think you need (uintptr_t) - you can cast a (const char *)
to a (char *) without having to go through that - I believe.)
Is this C, or C++.. there are some differences in the type of
a constant character string between the two...
But - basically, what you are trying to describe is a field which
is sometimes 'const' and othertimes isn't... which doesn't make
sense in the context of the C standard... you'll need a cast
for the initialization, or some other approach besides static
initialization I believe... (or, just live with the warning...
which isn't pleasant at all.)
- Dave R. -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Fri, Jun 08, 2001 at 08:51:54AM -0400, Thomas David Rivers wrote:
GCC complains when I try to initialize the structure with something like:
struct validation_fun val_init[] = {
{init,valfun_init,0}
};
This can be avoided by:
struct validation_fun val_init[] = {
{(char *) (uintptr_t) init, valfun_init,0}
};
..but as a matter of fact, static, pre-initialized valfun structs are
the rule rather than the exception in this program, so having this
syntax for all of them seems.. well.. ugly :)
Ah.. I see..
(I don't think you need (uintptr_t) - you can cast a (const char *)
to a (char *) without having to go through that - I believe.)
E.. this was the whole point of this thread. I *can't* cast
a (const char *) to a (char *) when using the -Wcast-qual gcc flag -
the -Wcast-qual flag produces exactly this type of warnings, to make
sure you don't treat const * pointers as normal pointers, and pass them
to functions that do stupid things like modify them or free them :)
Yes - I see now... sorry for being slow on the uptake :-)
Is this C, or C++.. there are some differences in the type of
a constant character string between the two...
But - basically, what you are trying to describe is a field which
is sometimes 'const' and othertimes isn't... which doesn't make
sense in the context of the C standard... you'll need a cast
for the initialization, or some other approach besides static
initialization I believe... (or, just live with the warning...
which isn't pleasant at all.)
Well, I can't live with the warning with -Werror ;) So I guess I'll
live with casting in free() :)
It's not pretty either way... is it?
- Dave R. -
--
[EMAIL PROTECTED]Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
Since some strings are non-constant (the are allocated) - I believe the `const' qualifier in the structure declaration is incorrect. 'const' just means I will not be modifying this; it's a way for a function prototype to constrain the function's implementation. Yes - it is.. However, a string is a const array of char. malloc(9) isn't. (And, can't be, since you have to, presumably, malloc the space and then write something meaningful to it...) So, if you declare a variable as const char * and then have different constness in assigning to that data, you are asking for the one variable to be both `const' and non-`const'... I was taking it from the other side (not the call to free() side, but the declaration of the data type...) Saying that the datum isn't actually `const' - it's only sometimes const (and only during the static initialization.) sometimes const doesn't make sense... But - then, if you remove the `const' - you get warnings from the initialization - assigning a pointer-to-const to a pointer-to-non-const. So... what's a programmer to do? That's the issue, right? - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD on S/390?
Long shot, probably, but I've got a bunch of virtual machines on an IBM S/390 mainframe, and while we're running SuSE Linux on most of them, on a whim I tossed out the idea of running FreeBSD on one of them, and to my surprise, it was taken seriously. So, has anyone done any work with getting FreeBSD running on a S/390? What can I do to make it happen if there's interest? Ken I'd like to see it as well I beleive we'd be willing to help with it too.. as resources permit. - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
Farooq Mela [EMAIL PROTECTED] wrote:
Hi,
Usually when I write programs, I have functions such as the following:
void *
xmalloc(size_t size)
{
nice code
}
void *
xrealloc(void *ptr, size_t size)
{
nice code
}
And then I use these instead of malloc and realloc throughout the
program, and never have to worry about return values. Sometimes these
functions also have additional cleanup they perform. Anyway, there are
certain libc functions which also use malloc, such as getaddrinfo,
vasprintf, etc. These may fail with errno = ENOMEM. In general, it is
annoying to have to check the return values for these functions too.
Would it not be convenient to set the memory allocator used by certain
functions inside libc? I.E, be able to write:
set_allocator(xmalloc);
set_reallocator(xrealloc);
From then on, one would never have to worry about the functions running
out of memory. I know that wrappers for functions which allocate memory
can also be written, but I feel that my proposal would is in general a
more convenient solution.
How do you guys feel about this?
-Farooq
This would have probably been an outstanding idea when the
C standard was being put together... (and, who knows, somethine
similar may very well have been proposed.)
But, let me point out that adding such a feature to the FreeBSD
library doesn't mean you can dispense with your checks and/or
wrapping functions. As soon as your code needs to run on another
platform, you'll need those checks...
Such is the way of the world - when you have a standard, that's
all you can expect from other systems...
- Dave Rivers -
--
[EMAIL PROTECTED] Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: EBCDIC - ASCII
Josef Grosch [EMAIL PROTECTED] wrote: Does anybody know of an EBCDIC to ASCII converter? I thought that at one time FreeBSD had one of these. Josef Check out the `dd' command.. particularly the `conv' suboption: conv= value[, value ...] Where value is one of the symbols from the following list. ascii, oldascii The same as the unblock value except that characters are translated from EBCDIC to ASCII before the records are converted. (These values imply unblock if the operand cbs is also specified.) There are two conver- sion maps for ASCII. The value ascii specifies the rec- ommended one which is compatible with System V. The value oldascii specifies the one used in historic ATT and pre-4.3BSD-reno systems. - Dave Rivers - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about -Wchar-subscripts
In the last episode (Oct 03), Larry Lile said: ...we get scores of warnings about using characters as subscripts to an array (-Wchar-subscripts), which generates so much noise as to mask real warnings burried within. Therefore, I would like to suppress this warning unless someone can explain why using a char as an array subscript is in any way an illegitimate thing to do. As far as I can tell, getting rid of the warning by changing the code would require adding a large number of frivolous casts to scores of source files... So why is using a "char" as an array subscript wrong? I had always avoided it because the compiler complained and that was good enough for me. Because your char value could be negative and end up referencing memory before your array start. Mainly a problem with the ctype macros and high-ascii characters. That's an interesting reason... any variable can be negative (well, except for the unsigned types...) - what's so interesting about `char'? Is it simply ctype macros that are the concern, or something "bigger"? - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about -Wchar-subscripts
Robert Nordier [EMAIL PROTECTED] wrote: Thomas David Rivers wrote: So why is using a "char" as an array subscript wrong? I had always avoided it because the compiler complained and that was good enough for me. Because your char value could be negative and end up referencing memory before your array start. Mainly a problem with the ctype macros and high-ascii characters. That's an interesting reason... any variable can be negative (well, except for the unsigned types...) - what's so interesting about `char'? Is it simply ctype macros that are the concern, or something "bigger"? What's interesting about char is that it's implementation defined whether "plain" char is the equivalent of "signed char" or "unsigned char" (or even something else). So, given an 8-bit, two's complement implementation of char, the statement char i = 128; may cause 'i' to end up as -128 or 128, for example. An implementation-defined value to your subscript is almost never useful, so this kind of behavior does warrant a warning. You'll notice gcc doesn't warn if explicitly signed or unsigned chars are used as subscripts, as then there is no uncertainty. -- Robert Nordier Ah - yes! That makes perfect sense... when you consider that `char' all alone can be signed or unsigned... Thanks for the explanation! - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: AW: Redirect stdout/stderr to syslog [OFF-TOPIC]
-Ursprungliche Nachricht- Von: Peter Pentchev [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 1. September 2000 14:00 man 1 logger pipe your stdout/stderr to logger(1), and you're all set. You may even specify a facility/level to log with. Thanks for your quick answer but I would prefer to do it entirely in C without calling external progs. I could think of a solution forking another child process which does the syslog logging and redirecting stdout/stderr of the execvped program via IPC to this child. But is there any easier solution? You can use popen() to start the external process (logger in this case) with the `IPC' already set up. Then, perhaps an freopen() stdin/stdout... to the pipes would be all you need. popen() is one-way though... - Dave R. - -- [EMAIL PROTECTED] Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: An IA-64 port?
On Sat, 3 Jun 2000, Jordan K. Hubbard wrote: Intel has furnished us with IA-64 hardware and a porting effort is already underway. Contact [EMAIL PROTECTED] if you would like to help out in some way with the process. What can those of us just out here do? I believe HP provides a IA64 emultor which runs on Linux/Windows? I recall stumbling into when looking at the IA64 compiler that SGI recently releases. One guess might be to: 1) Get the IA64 emulator running under FreeBSD 2) Get FreeBSD up under the IA64 emulator 3) Start working on bugs? [Although, I could be totally wrong about the emulator... need to look around on the SGI web pages where I recall the link...] - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: An IA-64 port?
I believe HP provides a IA64 emultor which runs on Linux/Windows? I recall stumbling into when looking at the IA64 compiler that SGI recently releases. It was mentioned on SGI's pages, but I couldn't find it anywhere on HP's site (the link didn't work). If you have a pointer to this, the IA64 porting team would love to have it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith Unfortunately, I don't have a pointer to it... I just noticed it there myself... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Building customized kernel without root passwd
My professor plans to use FreeBSD for teaching purpose. We will allow students to build their kernel but do not want to give them root password. So it's better to find a way to let students build kernel under their own account, save the kernel on a floppy and then boot from the floppy. I am familiar with normal kernel build process. But have not done the above before. I hope someone can give me some suggestions and I will try them out. Thanks a lot. -Zhihui Of course, once you've booted the floppy - you realize you can mount the hard disk and change the root password... Doesn't seem like too sound of an idea... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IBM releases JFS for Linux.
This came across the Linux/390 mailing list today, I thought it might be interesting for people: "IBM makes JFS technology available for Linux - Technology based on OS/2 Warp Journaled File System goes open source". See http://oss.software.ibm.com/developerworks/opensource/features/jfs_feature.h tml The URL there is incorrect - the correct one is: http://oss.software.ibm.com/developerworks/opensource/jfs - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mktime(3) and strange struct tm entries
Hello! Try the following: Take any year, minute, seconds, hours (etc...). set the struct tm accordingly. set the tm-tm_mon = 10 (November) set the tm-tm_mday = 31 (november has only 31 days) mktime(3) with this tm returns the date 1 Dezember. Does POSIX want this? Does anyone have the specs and could take a look? Or is this a bug? I believe this is correct behaviour. - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should -mieee-fp equal fpsetmask(0) to avoid SIGFPE on FreeBSD?
P.S. Actually, although Martin Cracauer's suggested replacement for the existing Mozilla code is certainly better than what Mozilla is using now, it may perhaps need to be slightly augmented with an additional check to see if the value of `d' is a NaN prior to per- forming the range check. But I'm not even sure about that. I'd have to go and dredge my copy of IEEE 754 out of my files again to find out what the results of = and = are in cases where one of the operands is a NaN. I think however that those operations are perhaps required to return False in that case, in which case Martin Cracauer's suggested Mozilla replacement code is just fine as it is. And in any case, that is all a moot point anyway if it is known in advance that `d' will not be a NaN. I don't believe the C89 standard doesn't have a way to test for NaN - so, if we're talking portability here - you can't test for NaN. I think C99 does have some library functions to do tests for NaN and Inf. This is interesting because the 390 HFP format doesn't have NaN or Inf. Why would that matter to Mozilla - well, there's a LINUX port now for the mainframe and Mozilla might want to run there. [I don't know if that port is using the old-style HFP format or the new-style IEEE format.] - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: modifying an object file
David - The man page for the ELF linker says: ld accepts Linker Command Language files to provide ex- plicit and total control over the linking process. This man page does not describe the command language; see the `ld' entry in `info', or the manual ld: the GNU linker , for full details on the command language and on other as- pects of the GNU linker. I'd bet there's something there that will let you rename your reference. On a 3.3 box, you can find the texi files in /usr/src/contrib/binutils/ld Just a possible place to look... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ncr scsi timeout
The kernel hangs (rather an endless loop) with messages like: ncr0: timeout nccb=0xc0c38000 if I attach a fujitsu M2513A2 640MB MO drive. From a quick glance in the ncr source it seems there's a problem with the script stuff in case of a timeout. Anyway, this doesn't happen with either the obsd or linux ncr driver (both derived from the fbsd one I believe), so that may provide some info for whoever maintains this driver. Please mail me with suggestions or pacthes to try out as I need the MO drive. Regards, Wouter You didn't say which version of FreeBSD you're using - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sys/sockets.h error
Include sys/types.h before sys/sockets.h - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Human readable df
In message 19991129230436.A6501@badmofo [EMAIL PROTECTED] writes: : [badmofo@/home/matt] df -h : FilesystemSize UsedAvail Capacity Mounted on : /dev/wd0s1a 722M20M 644M 3% / : /dev/wd0s2h 9.9G 4.4G 4.8G48% /usr : procfs4.0K 4.0K 0B 100% /proc This also looks a lot like what the SVR4 dfspace program produced. dfspace was simply an awk script that prettied up the output of df. Not that I'm against the patch - would such prettying up better be done outside of df itself (to follow the UNIX tools-built-on-tools philosophy...) maybe? maybe not? Just a thought - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Human readable df
Stephen McKay [EMAIL PROTECTED] write On Tuesday, 30th November 1999, Warner Losh wrote: FilesystemSize UsedAvail Capacity Mounted on /dev/da0s1a 62.0M 31.0M 26.1M54% / /dev/da0s1e 192M 167M 9.22M95% /usr /dev/da0s1d 61.4M 11.3M 45.2M20% /var /dev/da0s1f 288M 247M 18.4M93% /usr/local /dev/da0s1g 2.17G 1.88G 122M94% /home procfs 4.00K 4.00K 0B 100% /proc /dev/sd1a 990M 376M 534M41% /jaz /dev/da2s4c 1.94G 1.72G 68.0M96% /hawk /dev/da3s4a 3.93G 1.95G 1.67G54% /u Add a 'df -h' if you like, but to me this looks like an unreadable jumble of letters and digits. Which adds to my logic of not putting this in df itself, there will always be someone (for many valid reasons) that wants something else. I'd suggest going the dfspace route - then users have an example of something that parses the df output they can choose for themselves. I just checked on the Solaris box here, /etc/dfspace isn't there... I know it was there on my old ISC 3.2 box; and I recall making it work on FreeBSD. But, it was copyright ATT, so I simply can't post it. The way it works is to (honoring the block size correctly) skip the first few lines of df (the normal heading) and then grab all the following `table' if you will. With that information in hand, it can format things anyway it needed. - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Human readable df
Stephen McKay [EMAIL PROTECTED] wrote: And to Thomas: I've used dfspace before on ISC Unix, but never really liked it. I prefer df to do what I want. Am I greedy? :-) Not at all - it just seems to me the question should be asked, that's all. Since not a single person agreed - it seems it has been answered as well :-) - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Included file errors
You're missing a #include of sys/types.h - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel debug assistance?
I'm trying to track down a problem in 3.3-RELEASE (which I _think_ might be a linux emu bug that's crashing the kernel.) Anyway - I thought I might ask here for some kernel debugging assistance... I've got a debuggable kernel, with DDB. When the panic occurs (which I can readily reproduce) I drop down into DDB... Which is great - right? But - IP is 0x0 (or, sometimes 0x8000) - so the trace command in DDB (to show the stack traceback) doesn't seem to work - all I get is the Trap 12 message. Does anyone have any sage words of advice on how to proceed with tracking this down? At least some neat trick for determining where the bad branch is taken? - Thanks - - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
In message [EMAIL PROTECTED] Chuck Robey writes: : Uhhh? I've long since got the answer I wanted, but this seems a complete : mystery, so I'll bite, what's a OI_add_event? From some package? Can't : find a man page on it. OI was a native C++ toolkit that had a nice interface and was ported to Linux and FreeBSD back in 1993 or so by yours truly. It was available from ParcPlace. Sadly, it never went anywhere and all efforts of the engineers to make it open sourced (this was in 1996) failed. It was ment as a joke for the long timers on the list... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Let me add that as a stock holder of ParcPlace (now ObjectShare) and one of the people who tried out OI - I was disappointed it didn't go anywhere. It seemed nice... (I wonder where it is now?) ObjectShare is trading right now at 44-cents/share - an amazing 18.92% increase so far for the day (up 7 cents). Perhaps that outstanding stock price reflects the outcome of some of their decisions? [I believe my last purchase of ObjectShare was somewhere in the $10 range... sigh.] - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
Does anyone (anyone, that is, who's coded X11 applications) know how you
handle X11 callbacks to C++ object methods?
Thanks,
If you mean Xt (and possibly Motif) - the answer is "very carefully."
The Xt callbacks are C based, so you typically can't directly call a
C++ method.
But, you can have an extern "C" block that declares the call back
function (the extern "C" basically keeps any name mangling from going on)
and then, in that function, invoke the method as appropriate.
I believe you do something like:
class myclass {
void mymethod(void * arg1) {
cout "Ha! I got to the class" '\n';
};
}
extern "C" {
void
callback_function(arg1)
void *arg1;
{
/* Call the method */
myclass::mymethod(arg1);
}
}
Then, you register "callback_function" as the Xt/Motif callback.
I've at least "heard" of doing that kind of thing before...
- Dave Rivers -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
Then you just stick a C wrapper function around every C++ callback you want to register, is that it? Seems a bit inelegant, but I suppose, if the ultimate test of elegance is that "it's the only one that works", then it's perhaps elegant *enough*. I believe someone posted a better solution... from the Xt FAQ. - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -stable (in)stability (was Re: Best version of FBSD for INN ?)
And - to add to this - I still can freeze up my pentium laptop rather quickly (3.2-RELEASE, 40meg memory, P90) running setiathome. And - I've got DDB in the kernel, and ensured it's not overheating (it will freeze up in less than a minute from a _very_ cold start.) I don't get a panic, ddb prompt or anything - just a locked up machine. - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GNU GLOBAL
On Sun, 19 Sep 1999, Peter Wemm wrote: :Will you be assigning the copyright to the FSF? (ie: you'll never be able :to change your mind? 50 years is a long time...) 70 now I believe. Changed to be compatible with the euros, who are all 70 years apparently. If I understand things correctly, there will soon be legislation introduced to increase that time. Apparently, some companies, particularly Disney - were the big backers of the move to 70 years (to protect Mickey, et al) But, I've been lead to believe that the music and film industry has been pushing quite hard to increase that number... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor numbers in shared libraries.
In a discussion with Nate Williams, I have learned that the reason FreeBSD doesn't use minor numbers with shared libraries because standard ELF doesn't support it. Is this a hard-and-fast unbreakable rule, or is this something that could be implemented if it can be done in a way that's compatible with standard ELF? It seems to me that there should be a way of working around this, by adding a field (either in a new section or an unused field (properly flagged with a magic number) in the header) to communicate the minor version number to ld.so, and having ld.so modify its search path by looking for X.so.M.N (where N = the number in the header), before X.so.M. This shouldn't break any "foreign" libraries, nor break libraries created under FreeBSD when used on "foreign" systems. Am I missing something really obvious here? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message I would also add that you can "fake" a minor number by simple multiplication. You have to assume how many digits you want to allow in minor numbers. For example, if we assume a minor number has no more than 3 digits (allowing the minor numbers to grow to 999) then, M.N can readily be encoded as M*100+N. So, if M = 2 and N = 50, the Elf library number would be 2050. It doesn't look pretty when you do an ls. Also, you would want to "teach" the loaded about this. Just a thought - not really a suggestion - just a thought. - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor numbers in shared libraries.
In a discussion with Nate Williams, I have learned that the reason FreeBSD doesn't use minor numbers with shared libraries because standard ELF doesn't support it. Is this a hard-and-fast unbreakable rule, or is this something that could be implemented if it can be done in a way that's compatible with standard ELF? It seems to me that there should be a way of working around this, by adding a field (either in a new section or an unused field (properly flagged with a magic number) in the header) to communicate the minor version number to ld.so, and having ld.so modify its search path by looking for X.so.M.N (where N = the number in the header), before X.so.M. This shouldn't break any foreign libraries, nor break libraries created under FreeBSD when used on foreign systems. Am I missing something really obvious here? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message I would also add that you can fake a minor number by simple multiplication. You have to assume how many digits you want to allow in minor numbers. For example, if we assume a minor number has no more than 3 digits (allowing the minor numbers to grow to 999) then, M.N can readily be encoded as M*100+N. So, if M = 2 and N = 50, the Elf library number would be 2050. It doesn't look pretty when you do an ls. Also, you would want to teach the loaded about this. Just a thought - not really a suggestion - just a thought. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD???
Kenny Drobnack [EMAIL PROTECTED] writes: Lately i have seen a lot of speculation as to what will happen when the Intel Merced comes out. Will people wait 12-18 months for a 64 bit Windows (that's the amount of time I keep hearing it will take them to get Win2000 running on it) or will they just buy it and pop Linux onto it right away? If the majority of the people opt for option #2, it may mean Linux will finally get a huge edge over M$! While Linux is a great OS, and I like seeing M$ have some problems, I would even more like to have the assurance of being able to run FreeBSD on 64 bit architecture. Is there any port planned to that system? Has anyone even mention it? Also, will the lib/compat end up having a linux32 and a linux64 directory so it can run both old Linux apps and new? First - let me point out that FreeBSD already runs on the Alpha, so there's some 64-bit experience. Second - SCO and HP will be rolling out their UNIX variants with the Merced release. Perhaps some people will buy a Merced for that reason. But - for "Intel to hit it big" - they need Merced to become the next consumer architecture. Since they are continuing with plans for the IA32 line (what x86 got renamed to with the advent of IA64, nee' merced) they are hedging their bets. I don't believe they are convinced themselves that Merced will be the answer to their dreams... Also, recall that Intel launched Merced development when the idea was "bigger/faster is better." Last year's sudden reversal of that idea (i.e. Celeron as the answer to the AMD challenge) meant that bigger was better is not (at this moment) the right answer. Intel's requisite shift to lower-priced offerings likely was a contributing cause to all of the Merced slips. So - what Intel is facing is a chicken-and-egg problem. They need to sell a lot of these things, but will need Windows to do that. Microsoft won't bother with a Windows port until there is a significant market need for it (I point to the abandoned PPC and Alpha Windows ports as examples.) Microsoft needs a "business quality" version of Windows, which it claims is Windows/2000. That version of Windows could benefit from a 64-bit port, if for marketing only; but I don't think it would result in the volume of sales Intel is looking for. And - let me add - Intel has been down this path before (the i860) - and didn't see the success it wanted (although the i860 is popping up in some interesting places now...) I suppose what this "rant" is all about is that I'm not convinced Merced is the "chip of the future" that we all need to be worried about. I'm taking a "wait-and-see" attitude. [Also, since Microsoft has been working closely with Intel regarding Merced for several years now, and has yet to do anything `serious' - I believe they are taking the same "wait-and-see" approach. Likely while telling Intel otherwise.] That doesn't mean I think we shouldn't have a FreeBSD port; I would considering buying a Merced box if there was one (although, I don't have an Alpha box, so maybe it would never get past "consider".) - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD???
Kenny Drobnack kdrob...@mission.mvnc.edu writes: Lately i have seen a lot of speculation as to what will happen when the Intel Merced comes out. Will people wait 12-18 months for a 64 bit Windows (that's the amount of time I keep hearing it will take them to get Win2000 running on it) or will they just buy it and pop Linux onto it right away? If the majority of the people opt for option #2, it may mean Linux will finally get a huge edge over M$! While Linux is a great OS, and I like seeing M$ have some problems, I would even more like to have the assurance of being able to run FreeBSD on 64 bit architecture. Is there any port planned to that system? Has anyone even mention it? Also, will the lib/compat end up having a linux32 and a linux64 directory so it can run both old Linux apps and new? First - let me point out that FreeBSD already runs on the Alpha, so there's some 64-bit experience. Second - SCO and HP will be rolling out their UNIX variants with the Merced release. Perhaps some people will buy a Merced for that reason. But - for Intel to hit it big - they need Merced to become the next consumer architecture. Since they are continuing with plans for the IA32 line (what x86 got renamed to with the advent of IA64, nee' merced) they are hedging their bets. I don't believe they are convinced themselves that Merced will be the answer to their dreams... Also, recall that Intel launched Merced development when the idea was bigger/faster is better. Last year's sudden reversal of that idea (i.e. Celeron as the answer to the AMD challenge) meant that bigger was better is not (at this moment) the right answer. Intel's requisite shift to lower-priced offerings likely was a contributing cause to all of the Merced slips. So - what Intel is facing is a chicken-and-egg problem. They need to sell a lot of these things, but will need Windows to do that. Microsoft won't bother with a Windows port until there is a significant market need for it (I point to the abandoned PPC and Alpha Windows ports as examples.) Microsoft needs a business quality version of Windows, which it claims is Windows/2000. That version of Windows could benefit from a 64-bit port, if for marketing only; but I don't think it would result in the volume of sales Intel is looking for. And - let me add - Intel has been down this path before (the i860) - and didn't see the success it wanted (although the i860 is popping up in some interesting places now...) I suppose what this rant is all about is that I'm not convinced Merced is the chip of the future that we all need to be worried about. I'm taking a wait-and-see attitude. [Also, since Microsoft has been working closely with Intel regarding Merced for several years now, and has yet to do anything `serious' - I believe they are taking the same wait-and-see approach. Likely while telling Intel otherwise.] That doesn't mean I think we shouldn't have a FreeBSD port; I would considering buying a Merced box if there was one (although, I don't have an Alpha box, so maybe it would never get past consider.) - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD??? Intel? - NOT
On Fri, 27 Aug 1999, Jay West wrote: Keep in mind that the merced chip was not really designed or created by Intel at all. =20 It was created almost completely by HP (by the same group responsible for PA-RISC), with Intel as merely the production facilities. For obvious marketing, competitive, and resource reasons both HP and Intel share the rights to merced. =20 Does that mean that Merced is heir of the PA-RISC design just like PowerPC is the heir of IBM POWER processor family's? Not actually - I understand that many people who worked on PA-RISC worked on the initial Merced design. But, the instruction sets/implementation are totally different. Merced can run PA-RISC and IA32 instructions via mode bits on the chip. It's not transparent. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Mandatory locking?
All the files under Tandem's NSK has mandatory locking. The file cannot be opened if another process has it opened. some thing like * if the file is opened for reading, any one can open it for reading but opening for writing gives error * if the file is open for writing, it can't be opened for read/write * if the process holding the file is killed, the lock is gone * it is possible to get the pid of the process(es) which has a given file open (like which process has file "xyz" open? kind of query). btw, is there any way to get this info now in FBSD? This sounds interesting... But - aren't there NFS issues? I mean, in stateless access to a file - how do you know if the process holding the file is killed if it's remote? Just curious... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Mandatory locking?
All the files under Tandem's NSK has mandatory locking. The file cannot be opened if another process has it opened. some thing like * if the file is opened for reading, any one can open it for reading but opening for writing gives error * if the file is open for writing, it can't be opened for read/write * if the process holding the file is killed, the lock is gone * it is possible to get the pid of the process(es) which has a given file open (like which process has file xyz open? kind of query). btw, is there any way to get this info now in FBSD? This sounds interesting... But - aren't there NFS issues? I mean, in stateless access to a file - how do you know if the process holding the file is killed if it's remote? Just curious... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Need some advice regarding portable user IDs
I had a thought on this It seems you are trying to provide the floppy model that users currently have with their PCs. User A writes the floppy, User B can read it and do whatever he wants... (I know this is Apple - but I'll stick to MSDOS for the discussion, and floppy indicates any removable media.) The reason for this is that MSDOS filesystems don't keep any user credentials. So, use B can read anything on any floppy he can find. Wouldn't creating a file system that didn't support user credentials solve your problem? Format the floppy in that file system and hand it to user B. When user B mounts it, he can do whatever he wants. User A is aware of how the floppy was created, as presumably some special step is required to create the discard credential file system on the floppy. Perhaps, such a file system could even be a UFS with a special marker somewhere? Then, this marker could be twiddled after the fact. For example, user A formats and makes a new UFS file system on the floppy, and copies the files over. Marks it as having no credentials (twiddles the bit) and hands it to user B. User B mounts it, with a regular UFS mount - but because the magic bit is twiddled GID and UID are ??? (here's where things break down, just what do you use for those? root/nobody/user's giduid?) Just some thoughts... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: TCP stack hackers take a bow
Bill Fumerola writes: On Tue, 3 Aug 1999, Ted Faber wrote: http://www.sciencedaily.com/releases/1999/08/990802072727.htm The Duke release credits one Andrew Gallatin for a couple quotes. Not only FreeBSD in the news, but one of our own committers. Cool. http://www.dukenews.duke.edu/Research/GIGABIT.HTM Yes, my boss decided he wanted his 15 minutes of fame ;-) I tried hard to get FreeBSD a bigger mention than the rather poorly worded one that ended up coming out, but to little avail. After all, it is the BSD TCP stack that deserves the bulk of the credit; we were basically in the right place at the right time. It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. Yes - I noticed the conspicuous absence of any mention of BSD in the News Observer article. - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP stack hackers take a bow
Bill Fumerola writes: On Tue, 3 Aug 1999, Ted Faber wrote: http://www.sciencedaily.com/releases/1999/08/990802072727.htm The Duke release credits one Andrew Gallatin for a couple quotes. Not only FreeBSD in the news, but one of our own committers. Cool. http://www.dukenews.duke.edu/Research/GIGABIT.HTM Yes, my boss decided he wanted his 15 minutes of fame ;-) I tried hard to get FreeBSD a bigger mention than the rather poorly worded one that ended up coming out, but to little avail. After all, it is the BSD TCP stack that deserves the bulk of the credit; we were basically in the right place at the right time. It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. Yes - I noticed the conspicuous absence of any mention of BSD in the News Observer article. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: interesting bug in /usr/bin/cmp
If someone is interested to solve a problem: $ dd if=/dev/zero bs=8848 count=1 of=a 2/dev/null $ cp a b $ cmp a b 0 0x300 Segmentation fault (core dumped) $ cmp a b 0 0x200 cmp: EOF on b $ cmp a b 0x300 0 cmp: EOF on a Jean-Marc I've seen a similar problem when doing cmp with CD-ROM devices (I believe I entered a PR on it.) I think the problem has to do with cmp's use of mmap(), and potential issues there... But, that's just a guess on my part. It has to do with mmap(), but not any specific issues with mmap(), just a bug in its use. If noone has any objections, I will commit this and MFC it in a week or so. When I get into work today, I can apply your change and see if it fixes my problem as well. If it works, then, we can close the PR I entered on it... (kern/11969). - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: interesting bug in /usr/bin/cmp
If someone is interested to solve a problem: $ dd if=/dev/zero bs=8848 count=1 of=a 2/dev/null $ cp a b $ cmp a b 0 0x300 Segmentation fault (core dumped) $ cmp a b 0 0x200 cmp: EOF on b $ cmp a b 0x300 0 cmp: EOF on a Jean-Marc I've seen a similar problem when doing cmp with CD-ROM devices (I believe I entered a PR on it.) I think the problem has to do with cmp's use of mmap(), and potential issues there... But, that's just a guess on my part. It has to do with mmap(), but not any specific issues with mmap(), just a bug in its use. If noone has any objections, I will commit this and MFC it in a week or so. When I get into work today, I can apply your change and see if it fixes my problem as well. If it works, then, we can close the PR I entered on it... (kern/11969). - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: interesting bug in /usr/bin/cmp
If someone is interested to solve a problem: $ dd if=/dev/zero bs=8848 count=1 of=a 2/dev/null $ cp a b $ cmp a b 0 0x300 Segmentation fault (core dumped) $ cmp a b 0 0x200 cmp: EOF on b $ cmp a b 0x300 0 cmp: EOF on a Jean-Marc I've seen a similar problem when doing cmp with CD-ROM devices (I believe I entered a PR on it.) I think the problem has to do with cmp's use of mmap(), and potential issues there... But, that's just a guess on my part. What makes me think so is that cmp would declare the files on a CDROM and the files on a disk drive were different, (well, it would dump core as in your example) - while cat'ing the file from the CDROM to a temp place on the same disk and doing the cmp there would indicate there are no differences The speculation was that there was some problem with the SCSI CDROM... but... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: interesting bug in /usr/bin/cmp
If someone is interested to solve a problem: $ dd if=/dev/zero bs=8848 count=1 of=a 2/dev/null $ cp a b $ cmp a b 0 0x300 Segmentation fault (core dumped) $ cmp a b 0 0x200 cmp: EOF on b $ cmp a b 0x300 0 cmp: EOF on a Jean-Marc I've seen a similar problem when doing cmp with CD-ROM devices (I believe I entered a PR on it.) I think the problem has to do with cmp's use of mmap(), and potential issues there... But, that's just a guess on my part. What makes me think so is that cmp would declare the files on a CDROM and the files on a disk drive were different, (well, it would dump core as in your example) - while cat'ing the file from the CDROM to a temp place on the same disk and doing the cmp there would indicate there are no differences The speculation was that there was some problem with the SCSI CDROM... but... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sigaction inconsistancy (here I go again)
Also, I haven't gone into the code yet, but the floating point registers are not saved into the sigcontext so that they can be inspected and modified as appropriate. Thanks, John If I recall correctly - I think there's a discussion of why this is the case in the -hackers mail archive. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: support for i386 hardware debug watch points
I just wondered if this should be integrated into ptrace(), so the various debuggers wouldn't have to know about it. It seems that would be the proper abstraction - hardware that supports it would "have it" - and the programs that "used it" wouldn't have to know anything special. I only have a passing knowledge of ptrace() - so, I may be totally wrong... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: support for i386 hardware debug watch points
I just wondered if this should be integrated into ptrace(), so the various debuggers wouldn't have to know about it. It seems that would be the proper abstraction - hardware that supports it would have it - and the programs that used it wouldn't have to know anything special. I only have a passing knowledge of ptrace() - so, I may be totally wrong... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: support for i386 hardware debug watch points
Hi, After recently debugging a very elusive memory overwrite problem that I was only able to find by setting up a debugger watch point, and suffering through the slowness that this introduced, I began reading up on the ix86 support for hardware watch points. Using this facility of the chip would require OS support, and specifically, loading the debug registers at context switch time. Also, the 'ptrace' system call could easily be extended to provide an interface for doing this from user code. Is there any interest in supporting something like this in FreeBSD? I'm volunteering to spend some cycles on this, but I don't want to go to the effort if there's little chance that the work would be integrated. Thanks, -Brian -- Brian DeanSAS Institute Inc brd...@unx.sas.com Brian - Scan through the mail archives - I brought this up about this time last year, I think... There were several responses - some people may be willing to assist... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: "You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. I'd have to concur. I've done both - actually - the RedHat really isn't that different from FreeBSD (that was RedHat 5.2.) - a few of nice boxes you fill in - pop the CD in the drive... *poof* - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. I'd have to concur. I've done both - actually - the RedHat really isn't that different from FreeBSD (that was RedHat 5.2.) - a few of nice boxes you fill in - pop the CD in the drive... *poof* - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: setiathome crashes 3.2?
Would everyone agree that it's not a "good thing" for a user-mode program to be able to lock up the OS? There are severall resons. One of them is that I got panics with a to high set MAXUSER in kernel options. I don't know if it's a problem with 3.2. The other possible reason might be a CPU overheating. CPUs used under FreeBSD are typicall suspended during idle-time - when running seti or other permanent running programms there is no idle time. I didn't know that. This laptop does have a fan for the P-75 But, I don't believe it is that problem. You see, I can run it for about 5 minutes and *poof* - the machine is gone. I asume there are several more possbilities. But it sounds like there is something broken with your configuration. I think I'll need to put ddb in the kernel and see what's happening, since I get no panic or anything... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: setiathome crashes 3.2?
Would everyone agree that it's not a good thing for a user-mode program to be able to lock up the OS? There are severall resons. One of them is that I got panics with a to high set MAXUSER in kernel options. I don't know if it's a problem with 3.2. The other possible reason might be a CPU overheating. CPUs used under FreeBSD are typicall suspended during idle-time - when running seti or other permanent running programms there is no idle time. I didn't know that. This laptop does have a fan for the P-75 But, I don't believe it is that problem. You see, I can run it for about 5 minutes and *poof* - the machine is gone. I asume there are several more possbilities. But it sounds like there is something broken with your configuration. I think I'll need to put ddb in the kernel and see what's happening, since I get no panic or anything... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
setiathome crashes 3.2?
I seem to recall seeing this someone (this may not be the right list.) But - I downloaded the 3.2 s...@home and starting running it on a left-over 75mhz laptop I have. It seems to crash the laptop (silently lock it up, actually) fairly quickly. Did I recall someone else mentioning that? Would everyone agree that it's not a good thing for a user-mode program to be able to lock up the OS? - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: compiler warnings (was: RE: Typo: sys/pci/pcisupport.c)
There is a story behind it: our product was shipping for hpux and was later ported to sinix. It had some instabilities during development (it was first developed for hpux, then the enhancements were ported to sinix, almost in parallel). A colleague wrote (paraphrased) pointer-pointer-object.method; Some compilers will emit something like: Warning: Statement has no side effect for expressions like this (at least, the Systems/C compiler does.) where he wanted pointer-pointer-object.method(); hpux CC did not say a word. Naturally, the method had desired side effects :) /Marino -- riv...@dignus.com Work: (919) 676-0847 Get your mainframe (370) `C' compiler at http://www.dignus.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
3.2 SL/IP Install - can't get ifconfig to work...
I don't seem to be able to get 3.2 to do a SL/IP install (this is for a laptop which seems to be having PAO problems...) Turning on DEBUG in the install options, I can watch it nicely execute: ifconfig sl0 inet 10.0.0.98 10.0.0.99 netmask 255.255.255.0 but - not matter what - that always seems to fail with: ifconfig: ioctl(SIOCAIFADDR): File exists does anyone have a clue why the ioctl for the sl0 ifconfig would fail? (Perhaps the sl psuedo-device is missing from the kernel?) [I'm guessin the 'File exists' is left-over stuff in errno, as the ioctl(SIOCAIFADDR) message seems to be the result of perror().] - Thanks - - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3.2 SL/IP Install - can't get ifconfig to work...
I don't seem to be able to get 3.2 to do a SL/IP install (this is for a laptop which seems to be having PAO problems...) Turning on DEBUG in the install options, I can watch it nicely execute: ifconfig sl0 inet 10.0.0.98 10.0.0.99 netmask 255.255.255.0 but - not matter what - that always seems to fail with: ifconfig: ioctl(SIOCAIFADDR): File exists does anyone have a clue why the ioctl for the sl0 ifconfig would fail? (Perhaps the sl psuedo-device is missing from the kernel?) [I'm guessin the 'File exists' is left-over stuff in errno, as the ioctl(SIOCAIFADDR) message seems to be the result of perror().] - Thanks - - Dave Rivers - Just to add to my own mail... After the ifconfig fails (and the slattach succeeds) - it seems that SL/IP is actually working. From the server box (this is a straight-through null-modem connection) - I can ping the box I'm trying to install. Also - under the shell on VTY4 - I can mount_nfs the server's CDROM drive... so - the network is actually working... Although ifconfig has a non-zero return code. I tried doing an ifconfig sl0 down under the emergency shell on VTY4 - but that didn't seem to change anything; every ifconfig sl0 comes back with ioctl(SIOCAIFADDR): File exists. I think I can hack-around in sysinstall to get past this; but, something should be done before 3.3. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3.2 SL/IP Install - can't get ifconfig to work...
To add more to this - tracing through in.c in the kernel, I see that when you configure an interface it eventually works its way down to rtrequest - to add a route for the new interface. I believe rtrequest() is the one returning EEXIST which is what causes ifconfig on sl0 to always complain File exists. Now - why would rtrequest() believe there's a route already there? I made sure there was nothing in the GATEWAY and NAMESERVER field, just in case sysinstall was issuing the route somehow. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
More on ifconfig sl0 issue...
Well - I've added some printf()s to determine that what I suspected was correct. The route is being entered into the table twice. If looks like in_ifinit() is calling the sioctl() routine, which calls if_up(), which then adds the route. Then, in_ifinit() goes on to add another route and *poof* - the route's already there - you get EEXISTS. What's interesting about this is it only happens on my small laptop. On an older 486 I have - if_up() doesn't seem to get invokved (I'm working on finding out why.) For those interested - see /sys/netinet/in.c and /sys/net/if.c and /sys/net/if_sl.c. This is all with a 3.2-RELEASE source base. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3.2 SL/IP Install - can't get ifconfig to work...
Thomas David Rivers wrote: To add more to this - tracing through in.c in the kernel, I see that when you configure an interface it eventually works its way down to rtrequest - to add a route for the new interface. I believe rtrequest() is the one returning EEXIST which is what causes ifconfig on sl0 to always complain File exists. Now - why would rtrequest() believe there's a route already there? Probably because there is one. ;^) netstat -rn before and after the ifconfig should allow you to see what has changed. I suspect it might be your default route, but you'd have to look to be sure. netstat isn't on the install mfsroot (which is was) - but I tracked this down to a kernel bug. See PR#12251. Basically, if you do the slattach _before_ the ifconfig, the ifconfig will fail because the kernel tries to add the route twice. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symlink question
symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails yet again to appear in FreeBSD. Just think of the new security holes for a start. Name one, please. You can currently point a symlink anyplace you like; whether the user has permission to *read* or execute the target of the link, however, is where the genuine system administration takes over. How the actual value is derived shouldn't make that much difference. :) - Jordan My biggest problem with variant symlinks (which I've preached on before) is the following scenario: o) User A runs program P which takes advantage of a variant symlink in some fashion (either in finding P or finding some data P needs, etc...) o) User B runs program P which fails miserably. o) The sysadmin notes that the machines are the same, the symlinks are the same... then has to track down user B, and has to determine what variant symlinks P has been (perhaps even unaware to the designers of P) using and then has see what in user B's environment is causing this problem. Muliply B by several hundred... We would have problems like that on our Apollos; learning the hard way to avoid variant symlinks... just to ensure the environment was as expected.You don't have these same questions with plain symlinks. And, if the symlink changes, it's quite easy to see that it changed... So - I'd say that variant symlinks are like many other things, it's really easy to shoot yourself in the foot.. In my opinion variant symlinks make it too easy. Sometimes nifty things don't need to be done. I'd suggest that if they were implemented in FreeBSD - we leave the support 'off' by default, with a sysctl variable to enable them. When a user posts that his XXX/YYY/ZZZ directory has gone away we can ask, are variant symlinks turned on? and have a good first guess as to the culprit. Just my thoughts - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Wierd behavour from G++28!
On Wed, Jun 09, 1999 at 12:40:46AM +0100, Brian Somers wrote: Can someone comment please? Is this a bug in the way the gcc2.8 is installed, or is it a bug in my understanding? (probably the latter). Perhaps you need a gcc-compiled version of libstdc++. It's just a guess, but when we shifted to egcs, there were all sorts of problems linking against the gcc-compiled version. Ok. I've compiled up a 4.0-CURRENT box, with EGCS native, and recompiled the program. It still crashes, this time with: Core was generated by `search'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libstdc++.so.3...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libc.so.3...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x8053169 in __get_eh_info () at /usr/include/ctype.h:149 149 } (gdb) bt #0 0x8053169 in __get_eh_info () at /usr/include/ctype.h:149 #1 0x8053156 in __get_eh_info () at /usr/include/ctype.h:149 #2 0x8053132 in __get_eh_context () at /usr/include/ctype.h:149 #3 0x8059fda in my_setchar const *::my_set (this=0x805ff9c) at search.c:64 #4 0x804d3b9 in global constructors keyed to files () at search.c:64 #5 0x804a5d8 in _start () #6 0x804a25d in _init () (gdb) From search.c: 60char const* me; // executable name 61file_index files; 62word_index words, stop_words, meta_names; 63boolstem_words; 64string_set stop_words_found; 65 66voiddump_single_word( char const *word ); 67voiddump_word_window( char const *word, int window_size, int match ); I'm very confused... the programmer is convinced that it works under other platforms, but I'm not getting any joy out of it :( Joe Sorry I can't be of more help... I'd have to add that I have a suspicion that something is still not right library-wise... that is, the G++ library isn't built right, or the program isn't linking right. For what it's worth - the inline __XXX functions in ctype.h do work correctly... So, I don't believe the problem isn't in the source per se... I'd suggest building the library with debugging enabled, linking with that and determining what is wrong. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Wierd behavour from G++28!
Strange. I'm having a wierd time trying to get a package called Swish++ working. It's a C++/STL based program, which the author recommends compiling up with Gcc2.8 or higher. So... I've installed gcc-2.8.1 glibstdc++-2.8.1.1, and compiled it up. Strangely however, the 'search' part of it core dumps in an unexpected way. gandalf% ./search Segmentation fault (core dumped) gandalf% gdb search search.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... Core was generated by `search'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libc.so.3...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x8052c0f in ostream::flush () at /usr/include/ctype.h:149 149 } (gdb) bt #0 0x8052c0f in ostream::flush () at /usr/include/ctype.h:149 #1 0x8052912 in ostream::operator () at /usr/include/ctype.h:149 #2 0x804995f in main (argc=1, argv=0xbfbfdb54) at search.c:219 (gdb) l What gives? It looks like a library thing. Can anyone put me on the right track please? Joe Or - it could be that the stream wasn't properly opened and no-one checked for it... Look at line 219 in search.c, it should be a -operator operating on a stream of some kind. Then, find where that stream is declared/constructed and ensure everything is all right... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Wierd behavour from G++28!
On Tue, Jun 08, 1999 at 10:45:39AM -0400, Thomas David Rivers wrote:
(gdb) bt
#0 0x8052c0f in ostream::flush () at /usr/include/ctype.h:149
#1 0x8052912 in ostream::operator () at /usr/include/ctype.h:149
#2 0x804995f in main (argc=1, argv=0xbfbfdb54) at search.c:219
(gdb) l
Or - it could be that the stream wasn't properly opened and no-one
checked for it...
Look at line 219 in search.c, it should be a -operator operating
on a stream of some kind. Then, find where that stream is
declared/constructed and ensure everything is all right...
216file_vectorchar the_index( index_file_name );
217if ( !the_index ) {
218cerr me : could not read index from
219 index_file_name endl;
220::exit( 2 );
221}
(gdb) break 218
Breakpoint 1 at 0x8049941: file search.c, line 218.
(gdb) run
Starting program: /data/home/joe/src/swish/swish++-2.0/search
Breakpoint 1, main (argc=1, argv=0xbfbfdb14) at search.c:219
219 index_file_name endl;
(gdb) print index_file_name
$1 = 0x806bfe2 the.index
(gdb) print me
$2 = 0xbfbfdc35 search
(gdb) print cerr
$3 = 134671820
(gdb) print endl
$4 = {text variable, no debug info} 0x8052d20 endl(ostream )
(gdb) s
0x80528ed in ostream::operator () at /usr/include/ctype.h:149
149 }
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
0x8052c0f in ostream::flush () at /usr/include/ctype.h:149
149 }
Is it because the program's compiled using the wrong includes?
(/usr/include/ctype.h /usr/local/bin/g++28)
I was guessing that the stream may be wrong - but cerr is likely
correctly constructed...
You may have mixed up the libraries somehow when you linked... but
I'll have to defer that to someone who's used gcc2.8...
- Dave Rivers -
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Segfault in longjmp() ?
The machine is a SMP 3.0-RELEASE box. A heavily threaded program is segfaulting in the longjmp() function. Any ideas what would cause this? Regards, Dan You could have trashed your jmp_buf... (i.e. you're passing bad data to longjmp().) Just a thought... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ECC drive data recovery?
Hi, We're seeing the following message on one of the drives we have mounted in a server system. (da23:ahc1:0:14:0): READ(10). CDB: 28 0 0 46 aa 50 0 0 40 0 (da23:ahc1:0:14:0): RECOVERED ERROR info:46aa77 asc:18,7 (da23:ahc1:0:14:0): Recovered data with ECC - data rewritten sks:80,1a I've already got a replacement coming, but I was curious to know if anyone knows if the above means the existing data was recovered and written to the same, or different(spare) location? Thanks, John I'd hazard a guess that data rewritten means it was written to a spare location... but, it's just a guess. - Dave R. - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How to find the PCI chipset type inside a driver
Hi, I need the bt848/bt878 driver to find out the motherboard's PCI chipset. IE, Is this Bt878 card sitting on a VIA, SIS, OPTi or INTEL motherboard. Can this be done? The Bt878 can be programmed to run in Intel (Full PCI2.1 ompatible) Mode Intel 440FX mode SIS/VIA/OPTi mode. Each mode drives the PCI bus mastering slightly differently to cater for bugs/features in various PCI chipsets. Setting the Bt878 to SIS/VIA/OPTi mode fixed some strange machine hangs experienced by a UK user yesterday. I'd like the Bt848 driver to inquire about the PCI bus. To get the VENDOR and DEVICE_ID codes. It can then automatically enable the right mode on Bt878 chips. Any ideas? Ideally I need a method for 2.2.x, 3.x and -current. Bye Roger -- Roger Hardiman Strathclyde Uni Telepresence Research Group, Glasgow, Scotland. http://telepresence.dmem.strath.ac.uk 0141 548 2897 ro...@cs.strath.ac.uk Roger - Just a thought - not really an answer to your question... but... I struck me that since bt848 isn't in the default kernel (you have to build your own kernel for it) - couldn't you just make this a flag in the config file? Then, a couple of #ifdef's in the bt848 driver would handle it. Granted - the kernel becomes quite machine specific at that point, so - this is definately not the best answer (automatically determining as you suggest, would be better.) - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How to find the PCI chipset type inside a driver
Dave Just a thought - not really an answer to your question... but... I struck me that since bt848 isn't in the default kernel (you have to build your own kernel for it) - couldn't you just make this a flag in the config file? Then, a couple of #ifdef's in the bt848 driver would handle it. Actually, this is how I have implemented it. I have just commited to -current. Great minds think alike. :-) FYI, the linux bt848/bt878 driver is able to probe around and work out for itself that it is on an old triton 430fx board. Bye Roger Just out of curiosity - every now-and-then, when watching TV with my bt848 - the machine will lock up hard... could this be related? I'm not sure what the motherboard is in this machine (the documentation which should be right here appears to have walked off...) But, what are the problems one might expect from this issue? - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD, GPL, the world today.
Actually - this comes down to the argument of what the market will bear, contract law, and the legal ramifications of bugs/problems. You bought the software, and agreed to the license terms when you opened the box, didn't you - Caveat Emptor. As long as you keep buying it, people/companies will keep making it. And, being a software manafacturer myself (see http://www.dignus.com) - the thought of having legal responsibility for a potential problem in my software (which you've mentioned, despite anyone's best efforts, will have bugs) is very scary. I would want to pass that responsibility to the developers who wrote it, just as a bridge engineer is responsible for the bridge he designs. Then, the developers would, presumably, have to become licensed and have professional development/malpractice insurance... which ultimately drives up the price of the software. So, as everyone else, we disclaim everything up-front in our license agreement and sell our software at reasonable prices. But -hackers isn't likely the place for this... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
