Re: PCI4800
Ok! I've attached the files with configurations of PCI4800 and BR500 (external). External bridge send an error: > E Radio Error : 3 CRC errors Whereis problem ?? P.S. On the PCI4800 card Firmware v.4.25.30. - Original Message - From: "Brooks Davis" <[EMAIL PROTECTED]> To: "Dmitry A. Bondareff" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, June 26, 2002 12:39 AM Subject: Re: PCI4800 ! CONFIGURATION of Aironet BR500E V8.24 BR500E_00 = configuration radio ssid "test" configuration radio root on configuration radio rates 1_11 configuration radio basic_rates 1_11 configuration radio frequency "2412" configuration radio distance 0 configuration radio i80211 beacon 100 configuration radio i80211 dtim 1 configuration radio i80211 extend off configuration radio i80211 bcst_ssid off configuration radio i80211 rts 2312 configuration radio i80211 Privacy encryption off configuration radio i80211 Privacy client open configuration radio i80211 Encapsulation encap 802.1H configuration radio i80211 Encapsulation remove all configuration radio linktests destination any configuration radio linktests size 512 configuration radio linktests count 100 configuration radio linktests autotest once configuration radio extended bridge_mode access_point configuration radio extended time_retry 8 configuration radio extended count_retry 0 configuration radio extended roaming directed configuration radio extended Balance off configuration radio extended diversity off configuration radio extended modulation cck configuration radio extended power 1 configuration radio extended fragment 2048 configuration ethernet active on configuration ethernet size 1518 configuration ethernet port auto configuration ident inaddr 192.168.001.002 configuration ident inmask 255.255.255.000 configuration ident routing delete all configuration ident routing net 000.000.000.000 192.168.001.001 000.000.000.000 configuration ident dns1 000.000.000.000 configuration ident dns2 000.000.000.000 configuration ident domain "" configuration ident name "BR500E_00" configuration ident location "" configuration ident contact "" configuration ident bootp_DHCP off configuration ident class "BR500E" configuration console Remote on configuration console telnet on configuration console http on configuration console delete all configuration console communities remote off configuration console type teletype configuration console port rate 9600 configuration console port bits 8 configuration console port parity none configuration console port flow xon/xoff configuration console linemode off configuration stp active off configuration stp priority 8000 configuration stp hello_time 2 configuration stp forward_delay 15 configuration stp msg_age_timeout 20 configuration stp port port on configuration stp port priority 80 configuration stp port cost 100 configuration mobile-IP AgentType off configuration mobile-IP remove all configuration mobile-IP setup lifetime 600 configuration mobile-IP setup ReplayProt timestamps configuration mobile-IP setup broadcasts off configuration mobile-IP setup RegRequired on configuration mobile-IP setup HostRedirects off configuration mobile-IP advert AdvertType multicast configuration mobile-IP advert AdvertInterval 5 configuration mobile-IP advert PrefixLen off configuration mobile-IP advert AdvertRtrs on configuration time time_server 000.000.000.000 configuration time sntp_server 000.000.000.000 configuration time offset 0 configuration time dst off statistics display_time 10 statistics ipAdr off association maximum 1024 association autoreg on association staletime 350 association niddisp numeric filter multicast default forward filter multicast remove all filter multicast radio_mcst everywhere filter node ethdst forward filter node raddst forward filter node source off filter node remove all filter protocols default off filter protocols remove all filter direction both logs printlevel all logs loglevel all logs ledlevel error/severe logs statistics ra rpa any logs statistics re rdf any logs statistics re rce any logs statistics re trr any logs statistics re tmr any logs statistics re ter any logs statistics re tho any logs bnodelog on logs snmp trapdest none logs snmp trapcomm "public" logs snmp loglevel off logs snmp authtrap off logs syslog 192.168.001.001 logs syslevel all logs facility 23 logs rcvsyslog on diagnostics network escape "^X^Y^Z" diagnostics load ftp dest 000.000.000.000 diagnostics load ftp username "" diagnostics load ftp filename "" diagnostics load distribute type firmware diagnostics load distribute control newer diagnostics load distribute remove all configuration ident bootp_DHCP off configuration ident class "BR500E" > 0:08:50 E Radio Error : 3 CRC errors xl0: flags=8843 mtu 1500 inet 1.1.2.2 netmask 0xff00 broadcast 1.1.2.255 ether 00:60:08:30:21:c5
FSCK/current and dump errors
Not sure if I should blame current - but see the errors below. I've tried an fsck and an fsck -f from single user mode on each of the affected disks (7 disk, mix of ide/scsi give this). FSCK comes through clean. Prior to running -CURRENT the disks where attached to a 2.0.8 machine; and the dump prior to the upgrade is good (and restore can fully read it). But right now a real dump to tape; or a dump to /dev/null give me the errors below. -> Is there a more throurough consistency check I could do ? I've attached one of the SCSU disks to a 4.5 RELEASE machine; and fsck sees no errors; and there dump gives me similar errors. Any ideas, or should I just ignore this as -CURRENT madness :-) Thanks, Dw sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end | DUMP: Date of this level 0 dump: Sat Jun 29 05:10:43 2002 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/ad2s1f (/local2) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 1874624 tape blocks. | DUMP: dumping (Pass III) [directories] | DUMP: dumping (Pass IV) [regular files] ? DUMP: read error from /dev/ad2s1f: Invalid argument: [block -645840818]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840818]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840817]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840816]: count=-1 ...cut 150 lines... ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840749]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840748]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840747]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [block -645840746]: count=-1 ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840746]: count=-1 ...cut 1500 lines... ? DUMP: read error from /dev/ad2s1f: Invalid argument: [sector -645840147]: count=-1 ? DUMP: More than 32 block read errors from 135025408 ? DUMP: This is an unrecoverable error. ? DUMP: fopen on /dev/tty fails: Device not configured | DUMP: The ENTIRE dump is aborted. sendbackup: error [/sbin/dump returned 3] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How noisy should ch(4) be ?
> - run 'chio ielem' before you do anything. This may make the changer look >at what it has, and perhaps figure out that it doesn't really have a >source addresses for various elements. > > - try moving every tape in the changer to some destination and back. The >fastest thing to do, if the changer supports it, would probably be >moving the tapes to the picker and then back to a slot. Did not work :-) > - comment out the warning in copy_element_status(). Fixed the problem perfectly :-) > - see if there is updated firmware for the changer. There is - but it seems to need special third party SCSI software which only works on windows. I've got no desire to disconnect the unit for now. Dw. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw/dummynet suggestion
Usually remote MAC address. It's used for restricting users on a subnet. I have an ugly hack that does this at present and am looking forward to the MAC address support. Yes, I know users can conceivably change their MAC addresses but most would never know how. They change their IP addresses to get around security restrictions all the time. Nate > Ken Ebling wrote: > > > >Part 1.1Type: Plain Text (text/plain) > >Encoding: quoted-printable > > | I know this isn't performed at the ip level, but I think a useful = > | addition to ipfw would be to allow filtering by mac addresses. I think = > | a lot of people would find it useful, and a lot of linux users I try and = > | ``convert'' to FreeBSD say they require this feature too. > > Local or remote MAC addresses? > > The remote MAC address is always going to be a peer on the local > wire; usually, this is your router. > > The local MAC address is a 1:N correspondance with IP addresses, > so you can always do whatever you were planning on doing there > using the local IP addresses that are associated with the MAC > in question. > > What is it you are trying to do that is apparently not very > obvious? > > -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw/dummynet suggestion
On Sat, Jun 29, 2002 at 10:02:51AM -0700, Nielsen wrote: > Usually remote MAC address. It's used for restricting users on a subnet. I > have an ugly hack that does this at present and am looking forward to the > MAC address support. Yes, I know users can conceivably change their MAC THERE IS MAC SUPPORT IN THE NEW IPFW!!! > addresses but most would never know how. They change their IP addresses to several viruses do change the MAC address. The only real security is to have one user per port and filter the ports. Next step (but not as safe) is to wire down the arp table and only accept things that are in there (will be easy to implement in the new ipfw) cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw/dummynet suggestion
> several viruses do change the MAC address. The only real > security is to have one user per port and filter the ports. > Next step (but not as safe) is to wire down the arp table and only accept > things that are in there (will be easy to implement in the > new ipfw) I think it would be easier to deny all mac address in the ipfw rules except by those that you know, right? --- Joao Carlos [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw/dummynet suggestion
On Sat, Jun 29, 2002 at 03:17:24PM -0300, Joao Carlos wrote: > > several viruses do change the MAC address. The only real > > security is to have one user per port and filter the ports. > > Next step (but not as safe) is to wire down the arp table and only accept > > things that are in there (will be easy to implement in the > > new ipfw) > > I think it would be easier to deny all mac address in the ipfw rules except > by those that you know, right? which must be recorded somewhere, and static entries in the arp table are a nice place to look at. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Driver for device on serial (COM) port
Hello, freebsd-hackers! How are you? I want to write driver for some device, which is attached to standard serial (COM, RS-232) port. I want to make this driver full-featured -- with device node in /dev, ioctl()s and other. But I don't want to re-implement all this serial tty stuff, that is implemented in `sys/isa/sio.c' In case of LPT we have `ppbus'. What should I do in case of COM port? I want to `take' com port (any calls to corresponding /dev/ttydX, /dev/cuaaX and other should failed after this), monitor com port state (know about new bytes, etc) and after that detach from com port (when device is shutdowned and switched off), so com port could be used for other deviced (i.e. modem) without rebooting. It looks like userland program, but I really NEED full-featured driver, which is controlled via device node... Lev Serebryakov /---\ | FIDONet: 2:5030/661.0 | | E-Mail: [EMAIL PROTECTED] | | Page:http://lev.serebryakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FSCK/current and dump errors
On Sat, Jun 29, 2002 at 01:09:26PM +0200, [EMAIL PROTECTED] wrote: > > Not sure if I should blame current - but see the errors below. I've tried > an fsck and an fsck -f from single user mode on each of the affected disks > (7 disk, mix of ide/scsi give this). > > FSCK comes through clean. Prior to running -CURRENT the disks where > attached to a 2.0.8 machine; and the dump prior to the upgrade is good > (and restore can fully read it). > > But right now a real dump to tape; or a dump to /dev/null give me the > errors below. I'm seeing similar problems. There was a couple week window between the daddr_t commits and UFS2 were things worked, but post UFS2 I get the following when I dump /var. -- Brooks [12:26pm] brooks@minya (/usr/src/sbin/dump): sudo -u operator /sbin/dump -f /dev/null -a /var DUMP: Date of this level 0 dump: Sat Jun 29 12:27:27 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad0s2e (/var) to /dev/null DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 956071 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: read error from /dev/ad0s2e: Invalid argument: [block -2]: count=-1 DUMP: read error from /dev/ad0s2e: Invalid argument: [sector -2]: count=-1 DUMP: read error from /dev/ad0s2e: Invalid argument: [sector -1]: count=-1 master/slave protocol botched. DUMP: The ENTIRE dump is aborted. -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg35384/pgp0.pgp Description: PGP signature
Re: Driver for device on serial (COM) port
in -current, we have a new netgraph node ng_device that gives a device interface to netgraph. We also have the ng_tty node that attaches to a tty as a 'line disciplin' adding a node between these to do you own stuff would give you what you want. (the ng_device node shuld be Merged from current soon and you could even do it yourself.. it shouldn't be hard) in any case you probably want to attach to the tty as a line disciplin of some kind.. for example there is a graphics-tablet disciplin around somewhere (but I don't know where). On Sat, 29 Jun 2002, Lev Serebryakov wrote: > Hello, freebsd-hackers! How are you? > > I want to write driver for some device, which is attached to > standard serial (COM, RS-232) port. > I want to make this driver full-featured -- with device node in > /dev, ioctl()s and other. But I don't want to re-implement all this > serial tty stuff, that is implemented in `sys/isa/sio.c' > In case of LPT we have `ppbus'. What should I do in case of COM > port? I want to `take' com port (any calls to corresponding /dev/ttydX, > /dev/cuaaX and other should failed after this), monitor com port > state (know about new bytes, etc) and after that detach from com > port (when device is shutdowned and switched off), so com port could > be used for other deviced (i.e. modem) without rebooting. > It looks like userland program, but I really NEED full-featured > driver, which is controlled via device node... > >Lev Serebryakov > /---\ > | FIDONet: 2:5030/661.0 | > | E-Mail: [EMAIL PROTECTED] | > | Page:http://lev.serebryakov.spb.ru/ | > | ICQ UIN: 3670018 | > | Phone: You know, if you have world nodelist | > \===/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs(1) bug? with cvs update -rX -DY
On 2002-06-26 02:44 +, Makoto Matsushita wrote: > > scott> You could simply pop up a couple directories and checkout the > scott> given tag and date over your existing checkout. CVS is smart > scott> enough to notice that you've already got something checked out, > scott> and it will just update things. > > matusita> It would be fine to me. Thank you. > > Hmm, my cvs(1) doesn't allow me to checkout. > > % rm -rf src > % cvs -R -d /home/ncvs checkout -rRELENG_4 -D"Wed Jun 26 00:00:00 JST 2002" >src/contrib/lukemftpd > cvs checkout: Updating src/contrib/lukemftpd > cvs checkout: Updating src/contrib/lukemftpd/src Nope. You have to do this in two steps. First you checkout the files from the proper branch with -r BRANCH_TAG. This makes the branch 'sticky' and subsequent 'update' operations assume the same branch, unless -A is specified. See the transcript shown below. % cd /tmp % cvs -R -d /home/ncvs co -r RELENG_4 -l src cvs checkout: Updating src U src/COPYRIGHT U src/Makefile U src/Makefile.inc1 U src/Makefile.upgrade U src/README U src/UPDATING % cd src % cvs -q up -APdl bin U bin/Makefile U bin/Makefile.inc % cd bin % cvs -q up -APd cat U cat/Makefile U cat/cat.1 U cat/cat.c % cd cat Let's see what the one before the last commit was to the cat.c file. % ident cat.c cat.c: $FreeBSD: src/bin/cat/cat.c,v 1.14.2.7 2002/04/24 13:36:45 asmodai Exp $ The 1.14.2.6 revision was created (as you can verify with `cvs log') shortly before -D '2002-04-24 13:34:00 UTC'. Let's update to that date, or at least attempt to: % cvs -q up -Pd -D '2002-04-24 13:34:00 UTC' cat.c U cat.c % cvs stat cat.c === File: cat.c Status: Up-to-date Working revision:1.21Sat Jun 29 17:12:00 2002 Repository revision: 1.21/home/ncvs/src/bin/cat/cat.c,v Sticky Tag: (none) Sticky Date: 2002.04.24.13.34.00 Sticky Options: (none) Nope. Not quite. This is the HEAD revision of the file. Let's see if both a branch AND a date can be specified: % cvs -q up -Pd -rRELENG_4 -D '2002-04-24 13:34:00 UTC' cat.c U cat.c % cvs stat cat.c === File: cat.c Status: Needs Patch Working revision:1.14.2.6Sat Jun 29 17:12:15 2002 Repository revision: 1.14.2.7/home/ncvs/src/bin/cat/cat.c,v Sticky Tag: RELENG_4 (branch: 1.14.2) Sticky Date: (none) Sticky Options: (none) Note that cat.c has a sticky tag of RELENG_4 but the working revision is identical to 1.14.2.6 and not 1.14.2.7 which is the latest revision in the RELENG_4 branch :-) So, the proper steps to get the files of a branch other than HEAD, in the revisions they had at a certain point in time would be: + Checkout using the branch as a sticky tag. + Update using both -D DATE and -r BRANCH_TAG. I hope this helps a bit... - Giorgos msg35386/pgp0.pgp Description: PGP signature
Re: ipfw/dummynet suggestion
Joao Carlos wrote: > > several viruses do change the MAC address. The only real > > security is to have one user per port and filter the ports. > > Next step (but not as safe) is to wire down the arp table and only accept > > things that are in there (will be easy to implement in the > > new ipfw) > > I think it would be easier to deny all mac address in the ipfw rules except > by those that you know, right? Particularly, you should limit access to the antivirus server this way, so that if anyone does get a virus that does this, they are screwed for all time. NOT. Seriously, I'm wondering what "security restrictions" are so onerous that users are willing to change their IP addresses to get around them, and why they are there in the first place? I'm also wishing I had your posting in time to wave in the face of someone who once forced the implementation of a stupid access control model that required network identification of particular users, on the theory that users wouldn't do exactly what your users appear to be doing. Finally, I'll suggest that if you truly want to implement this thing, that the "correct" way to do it is probably to use the per machine NT Domain Controller information via hacking up the code from the SAMBA project, so that you can *ask* the NT domain controller for the credentials associated with an IP address, since this access control model is why NT Domaons were designed. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw/dummynet suggestion
> Seriously, I'm wondering what "security restrictions" are so > onerous that users are willing to change their IP addresses to > get around them, and why they are there in the first place? Well in certain cases it's company policy that certain machines (ie: users) can't browse the web during certain hours. I didn't make the rules, just asked to implement them. > Finally, I'll suggest that if you truly want to implement this > thing, that the "correct" way to do it is probably to use the > per machine NT Domain Controller information via hacking up the > code from the SAMBA project, so that you can *ask* the NT domain > controller for the credentials associated with an IP address, > since this access control model is why NT Domaons were designed. True, but often the simplest, semi-reliable solution wins out, so it came down to machines and MAC addresses. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to enlarge your penis 1-4"...guaranteed
Our sales aren't the only thing GROWING with this product! Increase penis size 1-4"...guaranteed!! For complete information on how to gain back your self esteem: http://www.freehostchina.com/site2/69chevelle/index.html +++ AS Seen On TV!! *Want to attract that special woman? *Interested in a little extra edge in business affairs? *Ever wonder why some people seem to have it all? If you answered yes to any of the above questions, and would like to gain that unfair advantage to attract that special woman or women: http://www.freehostchina.com/Minshan/shezwan/index.html +++ To "optOut": mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw/dummynet suggestion
Nielsen wrote: > > Seriously, I'm wondering what "security restrictions" are so > > onerous that users are willing to change their IP addresses to > > get around them, and why they are there in the first place? > > Well in certain cases it's company policy that certain machines (ie: users) > can't browse the web during certain hours. I didn't make the rules, just > asked to implement them. Yes, this is the same restriction that we were asked to implement in the InterJet, even though it meant the proxy software had to be non-transparent in order to grab credentials, and made life very complicated for all the engineers. I rather expect that you will find people fighting to step on the MAC address of any middle and upper management machine that spends any time at all in the "off" or "undocked" state. If your users want, I can give them some pointers to sites on how they can do this under Windows. 8-). Luigi is right: the only place you can really do this at this level is under Windows. The other alternative is to run a socks proxy, and make them use that to get out to the Internet, giveing internal users a non-routable IP address and/or simply blocking the entire netblock, minus a couple of static IP addresses (e.g. the gateway server/socks server). Unless you are in a country that charges for the sending of packets (like Japan), then you probably should not be trying to block employees from going to www.m-w.com in order to use a thesaurus. Note that there are a number of Windows products available (e.g. "CyberPatrol", etc.) that can do what you want from a single machine, as long as they are located somewhere on the wire out (they do it by forging failure packets back from the remote system the user attempts to contact). Maybe you just need to buy a copy of "NetNanny" or whatever? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw/dummynet suggestion
Terry Lambert wrote: > Luigi is right: the only place you can really do this at this > level is under Windows. Don't know what the heck happened here... it's supposed to read "on a per switch port basis". I think I lost part of a paragraph... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs(1) bug? with cvs update -rX -DY
keramida> So, the proper steps to get the files of a branch other than HEAD, in keramida> the revisions they had at a certain point in time would be: keramida> + Checkout using the branch as a sticky tag. keramida> + Update using both -D DATE and -r BRANCH_TAG. No, it doesn't work as you said. The second "cvs update" will delete all lukemftpd files (see my previous email posted to hackers@). Would you please try same operations to src/contrib/lukemftpd? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs(1) bug? with cvs update -rX -DY
On 2002-06-30 10:48 +, Makoto Matsushita wrote: > > keramida> So, the proper steps to get the files of a branch other than HEAD, in > keramida> the revisions they had at a certain point in time would be: > > keramida> + Checkout using the branch as a sticky tag. > keramida> + Update using both -D DATE and -r BRANCH_TAG. > > No, it doesn't work as you said. The second "cvs update" will delete > all lukemftpd files (see my previous email posted to hackers@). > > Would you please try same operations to src/contrib/lukemftpd? Ah, hummm. Perhaps this is because no files have been taken off the vendor branch. I see that the latest revision of lukemftpd.h (for instance) is 1.1.1.2, which is still in the vendor branch and not in a separate RELENG_4 branch :-/ Hmmm, you're right. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: signals in apps built with -pthread
On Wed, 19 Jun 2002, Daniel Eischen wrote:
> Andrew MacIntyre wrote:
{...}
> > The attached C code is a simple example of a signal handling situation
> > which works in the non-threaded interpreter, but fails in a threaded
> > interpreter.
{...}
> Try the patch included at the bottom.
{...}
> Index: uthread/uthread_sigpending.c
{...}
> Index: uthread/uthread_sigsuspend.c
This patch does indeed resolve the issue with the Python interpreter.
Could I expect this patch to be applied to -stable before 4.7?
BTW, my apologies for the extended delay in this response.
Regards, Andrew.
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED] | Snail: PO Box 370
[EMAIL PROTECTED]|Belconnen ACT 2616
Web:http://www.andymac.org/|Australia
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ftp and mail much slower into fbsd 4.4 vs and old BSDi
Sorry, hackers, I posted this twice in -questions and got no response. If the problem is newreno, can somebody say how to up just that piece for 4.4 so as to be as non-disruptive, non-dice-rolling as possible on this otherwise solid machine? Thanks Len FreeBSD 4.4-RELEASE #0 CPU: Pentium III/Pentium III Xeon/Celeron (848.05-MHz 686-class CPU) avail memory = 518156288 (506012K bytes) tx0: port 0x1000-0x10ff mem 0xe800-0xe8000fff irq 10 at device 14.0 on pci0 qsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto tx0: address 00:e0:29:24:17:80, type SMC9432TX ahc0: port 0x1400-0x14ff mem 0xe8001000-0xe8001fff irq 9 at device 16.0 on pci0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 31, 16bit), Tagged Queueing Enabled # sysctl -a | grep tcp tcpcb: 544, 1064, 51,152,70748 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 720 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.tcp_lq_overflow: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 65535 net.inet.tcp.newreno: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 51 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.strict_rfc1948: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.msl: 3 net.inet.tcp.always_keepalive: 1 # sysctl -a | grep buf kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.mbuf_wait: 32 kern.ipc.nmbufs: 4096 kern.msgbuf: kern.msgbuf_clear: 0 vfs.nfs.bufpackets: 4 vfs.numdirtybuffers: 130 vfs.lodirtybuffers: 499 vfs.hidirtybuffers: 998 vfs.numfreebuffers: 3785 vfs.lofreebuffers: 222 vfs.hifreebuffers: 444 vfs.runningbufspace: 0 vfs.maxbufspace: 64143360 vfs.hibufspace: 63488000 vfs.lobufspace: 63422464 vfs.bufspace: 63422464 vfs.maxmallocbufspace: 3174400 vfs.bufmallocspace: 712704 vfs.getnewbufcalls: 556989 vfs.getnewbufrestarts: 0 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 3871 vfs.reassignbufcalls: 3716853 vfs.reassignbufloops: 0 vfs.reassignbufsortgood: 474986 vfs.reassignbufsortbad: 1252304 vfs.reassignbufmethod: 1 debug.bpf_bufsize: 4096 debug.bpf_maxbufsize: 524288 machdep.msgbuf: machdep.msgbuf_clear: 0 with a 190 mbyte file: an ftp client pulling the file from fbsd is "blindingly fast" (aka "immeasurably" :)) ) ftp client sending to freebsd is 52 kbytes/sec ftp client sending to another ftp server on the same LAN is 1.6 megabytes/sec sending mail with a large attachment to the fbsd box is 100 kbytes/sec. (postfix is MTA) ftp a 5.5 mbyte from workstation client to fbsd: 109 seconds ftp a 5.5 mbyte from fbsd client to workstation ftp server: 3 seconds the machine runs a apache, qpopper, postfix, ftp, bind9 for a small LAN all on the same segment. dmesg and messages shows no errors. netstat -bi gives Name Mtu Network AddressIpkts Ierrs IbytesOpkts Oerrs Obytes Coll tx0 1500 00:e0:29:24:17:80 3171595 552 465267774 4214806 0 720458428 0 yeah, we don't like the Ierrs of 552. change the nic? change the driver? or is this the "newreno" tcp/ip problem? The Ierrs go up by 2 or 3 after each 5.5 mbytes file transfer. The new FBSD box replaces a BSDi on older hardware, with everybody on the LAN now noting that ftp of big files to and mail with big attachments to the new FBSD box are dramatically slower than the BSDi box. Anybody have any idea how to speed up / fix the transfers to the fbsd box? thanks Len www.menandmice.com/DNS-training : DNS Training BIND8NT.MEIway.com : ISC BIND for NT4 & W2K IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: signals in apps built with -pthread
On Sun, 30 Jun 2002, Andrew MacIntyre wrote:
> On Wed, 19 Jun 2002, Daniel Eischen wrote:
>
> > Andrew MacIntyre wrote:
>
> {...}
>
> > > The attached C code is a simple example of a signal handling situation
> > > which works in the non-threaded interpreter, but fails in a threaded
> > > interpreter.
>
> {...}
>
> > Try the patch included at the bottom.
> {...}
> > Index: uthread/uthread_sigpending.c
> {...}
> > Index: uthread/uthread_sigsuspend.c
>
> This patch does indeed resolve the issue with the Python interpreter.
>
> Could I expect this patch to be applied to -stable before 4.7?
Should be no problem. It's already been committed to -current.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
