Fixed my MAMEd sio problem. Was: Re: Doesn't anyone care about the broken sio ??
Just so you all know (the list included) how I have fixed my silo overflow problem which occurred while running xmame (and after I quit until I restarted the X server) I have found the problem doesn't occur if I remove the following lines from the shell script I use to start xmame: xsetpointer Joystick sleep 1 xsetpointer pointer I was doing those three lines just before starting xmame to get the mouse pointer into the top left hand corner (my script also used vidtune to get the right resolution for each game). Since I have removed those lines it works fine. I can now download to my hearts content whilst playing some ancient game. (I'd like to know an easy way to move the mouse pointer though!) With those lines in the script I had to restart the X-server after using xmame or I'd get continuous silo overflows. FYI, the output of xsetpointer -l is: keyboard [XKeyboard] pointer [XPointer] SWITCH[XExtensionDevice] Joystick [XExtensionDevice] And as you can see from the XF86Config file in the message I'm replying to, I am loading several modules to use XExtension Devices and the PC joystick (which is compiled into my kernel): Load xie.so Load pex5.so Load xf86Jstk.so Matthew Thyer wrote: *** STOP PRESS *** I have just confirmed that restarting the X server is enough to fix the problem. So my apologies to Bruce, -CURRENT and the whole FreeBSD community in general for blaming sio. For the benefit of David Dawes, I'll quickly restate the problem: Running xmame (from the ports collection) causes lots of silo overflows with user mode ppp until I either restart the X server or reboot. This occurs even after I exit xmame. This is all on FreeBSD-CURRENT but has been happenning for months and is not newbus related. Thankyou Brian, you are the first to NOT reproduce the problem. Note that all my recent testing of this has been at 300 MHz so dont jump on me when you see that I normally overclock at 450 MHz. So compare configuration: My X server is XFree86 3.3.3.1 (from ports) and I use the XF86_SVGA server. My video card is an ET6000 Jaton VIDEO-58P with 2.25 MB RAM. I run in 16 bit colour with KDE 1.1.1. I run MAME with sound enabled and I'm NOT using Luigi's PCM driver but rather the old driver (whats it called ??). I have a new ABIT BX6 release 2.0 motherboard (with 16550s I assume). I have an Intel Celeron 300a CPU which I normally run at 450 MHz (using a 100 MHz memory bus speed instead of 66 MHz but when I run it at 300 MHz it doesn't make any difference to this problem). I have PC100 SD RAM with an EPROM. This RAM is rated at 7ns believe it or not. I'd like to be using Soren's ATAPI driver but it doesn't like my CD-ROM drive so I'm using the normal wd driver with flags a0ffa0ff. I'm using a KTX V.90 modem at 115000 baud. I typically get 45333, 46667 or 48000 connections to my ISP. I'm using a Microsoft serial mouse but am not using moused. I do have a PS/2 intellimouse compatible mouse attached but only use it when I'm on the darkside (In Windows 95) as it doesn't work with moused or in XFree86. My whole system has been re-compiled within the last 2 days (world, updated /etc, kernel AND ALL ports [XFree86 3.3.3.1, kde 1.1.1 etc etc etc]) Kernel config file (MATTE), /etc/XF86Config file and dmesg output attached. I have one question about my kernel config: How do I know when it's unsafe to use options CPU_DISABLE_5X86_LSSER ? It would be good if the kernel disabled this option under those cases. My /etc/ppp/ppp.conf is: default: set log chat connect phase set device /dev/cuaa1 set speed 115200 allow users matt deny lqr deny chap set timeout 0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ ATX4S95=47 OK-AT-OK \\dATDT\\T TIMEOUT 80 CONNECT set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 isp: set phone ISPNUMBER set login TIMEOUT 10 sername:--sername: MYUSER ssword: MYPASS dial Brian Feldman wrote: On Sat, 8 May 1999, Jordan K. Hubbard wrote: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. Hmm, so now you're the second to cite the possibility of X masking interrupts too long, eh? ;) Actually, I use MAME all the time, and this problem does NOT occur (XF86_SVGA on an S3 ViRGE/DX). Oh, user-ppp too of course. If I could have
Re: Fixed my MAMEd sio problem. Was: Re: Doesn't anyone care about the broken sio ??
Just so you all know (the list included) how I have fixed my silo overflow problem which occurred while running xmame (and after I quit until I restarted the X server) I have found the problem doesn't occur if I remove the following lines from the shell script I use to start xmame: xsetpointer Joystick sleep 1 xsetpointer pointer FreeBSD's joystick driver certainly causes silo overflows. It disables CPU interrupts and polls for 2 msec. For 16550 serial hardware, this may cause loss of 21 characters at 115200 bps (23 characters arriving in 2 msec less 2 characters of buffering provided by the 16550 fifo above the trigger level). If sio used a more conservative trigger level of 8, then then the loss would be limited to only 15 characters. With those lines in the script I had to restart the X-server after using xmame or I'd get continuous silo overflows. Closing the joystick device should also work. The joystick driver shouldn't disable CPU interrupts or mask clock interrupts. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Doesn't anyone care about the broken sio ??
I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? Does core know that sio is seriously broken and doesn't want to admit it ? [dont take that comment too seriously please]. What am I supposed to think ? Here we go again. Can someone please run M.A.M.E. (/usr/ports/emulators/xmame) and then exit from it and then try to use user mode ppp. [NOTE you will need a M.A.M.E. ROM image from somewhere]. On my system and the previous system I had, this results in serious amounts of silo overflows, so much that the serial port is useless which requires me to reboot before I can use user mode ppp properly. My user mode ppp is fine unless I run MAME at any time before using user mode ppp without a reboot inbetween. All I want is for others to try to reproduce this problem. Previous messages attached giving more information. -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973---BeginMessage--- I have been investigating the silo overflow situation for some time. I can trigger them every time by the following action: - Run M.A.M.E. (Multi arcade machine emulator) and then try to download something. (I am using user mode ppp). I believe that the sio driver is its own worst enemy in that once you get one silo overflow, it seems that the driver tries to compensate but it only makes it worse as I continue to get them and the serial port is unusable after that. Exiting MAME doesn't help, I have to reboot or I will be unable to do the smallest thing such as download my mail. I dont think its just MAME but rather anything that thrashes the interrupt system. This is not related to newbus as it occurrred before then in just the same manner. I have seen this effect on my home system no matter what combination of motherboard, modem, serial hardware. I was running a patch to sio.c before newbus came in to improve the speed at which the FIFO buffers were processed but MAME would still trigger the start of the silo overflow storm. With either a patched or unpatched system I can download huge files no problems as long as I dont run MAME at any time. Now dont say just dont do that (I know some of you will want to). Kernel config is attached. /etc/ppp/ppp.conf (edited) is attached. dmesg output is also attached. -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973# Machine with Ultra DMA 32 Bit WD disk, ATAPI CD-ROM, SB16, NE2000 NIC, # NCR PCI SCSI, APM and Intel PIIX power management. # $Id: MATTE,v 11.8 1999/05/02 01:06:00 +09:30 matt Exp $ # based on: $Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $ # machine i386 ident MATTE maxusers20 options INCLUDE_CONFIG_FILE # Include this file in kernel config kernel root on wd0 cpu I686_CPU options CPU_DISABLE_5X86_LSSER # Dont use if you use memory mapped I/O device(s). options CPU_FASTER_5X86_FPU # Faster FPU exception handler options NO_F00F_HACK# Disable Pentium F00F hack # COMPATIBILITY OPTIONS options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT# Let processes manipulate their local descriptor table (needed for WINE) options SYSVSHM # Enable SYSV style shared memory options SYSVSEM # Enable SYSV style semaphores options SYSVMSG # Enable SYSV style message queues options MD5 # Include a MD5 routine in the kernel options VM86# Allow processes to switch to vm86 mode (needed for doscmd) # DEBUGGING OPTIONS options DDB # Enable the kernel debugger #optionsINVARIANTS # Extra sanity checking (slower) #options
Re: Doesn't anyone care about the broken sio ??
I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. If you can say here's a small stand-alone C program which hogs things to the extent that the serial driver seriously overruns its buffers then it's likely that someone will be at least motivated to compile, run and try it. If it involves running some esoteric application which requires downloading data of questionable legality on top of it, it's far less likely that anyone will even bother to look. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Doesn't anyone care about the broken sio ??
Bruce said, in his own quite way, that somebody had broken fast interrupts as part of newbus, and that is the end of that story. Poul-Henning In message 9.926181...@zippy.cdrom.com, Jordan K. Hubbard writes: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. If you can say here's a small stand-alone C program which hogs things to the extent that the serial driver seriously overruns its buffers then it's likely that someone will be at least motivated to compile, run and try it. If it involves running some esoteric application which requires downloading data of questionable legality on top of it, it's far less likely that anyone will even bother to look. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Doesn't anyone care about the broken sio ??
On Sat, 8 May 1999, Jordan K. Hubbard wrote: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. Hmm, so now you're the second to cite the possibility of X masking interrupts too long, eh? ;) Actually, I use MAME all the time, and this problem does NOT occur (XF86_SVGA on an S3 ViRGE/DX). Oh, user-ppp too of course. If I could have reproduced this problem, I would have replied. If you can say here's a small stand-alone C program which hogs things to the extent that the serial driver seriously overruns its buffers then it's likely that someone will be at least motivated to compile, run and try it. If it involves running some esoteric application which requires downloading data of questionable legality on top of it, it's far less likely that anyone will even bother to look. MAME is a great piece of software, and in and of itself entirely legal; what problem do you have with it? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Doesn't anyone care about the broken sio ??
MAME is a great piece of software, and in and of itself entirely legal; what problem do you have with it? I'm not talking about MAME, go read the message again. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Doesn't anyone care about the broken sio ??
As far as I can tell, this is unrelated to newbus as the same actions would trigger this problem before and after newbus. I have been seeing this problem for many months (maybe years - but I've only recently identified a set of actions to reproduce it every time). The wierd thing is that I can download heaps of stuff all at the same time (at 48000 baud) and get over 5.5 K/s without a silo overflow BUT as soon as I run MAME, the serial port is stuffed and requires a reboot to do the smallest amount of traffic. NOTE: This occurs AFTER I exit MAME or while I keep it running Very strange. And its not just on this hardware. I'd just like someone to try to reproduce this. I realise that downloading a MAME ROM is problematic but surely someone out there owns an old space invaders machine or something similar. Poul-Henning Kamp wrote: Bruce said, in his own quite way, that somebody had broken fast interrupts as part of newbus, and that is the end of that story. Poul-Henning In message 9.926181...@zippy.cdrom.com, Jordan K. Hubbard writes: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. If you can say here's a small stand-alone C program which hogs things to the extent that the serial driver seriously overruns its buffers then it's likely that someone will be at least motivated to compile, run and try it. If it involves running some esoteric application which requires downloading data of questionable legality on top of it, it's far less likely that anyone will even bother to look. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Doesn't anyone care about the broken sio ??
*** STOP PRESS *** I have just confirmed that restarting the X server is enough to fix the problem. So my apologies to Bruce, -CURRENT and the whole FreeBSD community in general for blaming sio. For the benefit of David Dawes, I'll quickly restate the problem: Running xmame (from the ports collection) causes lots of silo overflows with user mode ppp until I either restart the X server or reboot. This occurs even after I exit xmame. This is all on FreeBSD-CURRENT but has been happenning for months and is not newbus related. Thankyou Brian, you are the first to NOT reproduce the problem. Note that all my recent testing of this has been at 300 MHz so dont jump on me when you see that I normally overclock at 450 MHz. So compare configuration: My X server is XFree86 3.3.3.1 (from ports) and I use the XF86_SVGA server. My video card is an ET6000 Jaton VIDEO-58P with 2.25 MB RAM. I run in 16 bit colour with KDE 1.1.1. I run MAME with sound enabled and I'm NOT using Luigi's PCM driver but rather the old driver (whats it called ??). I have a new ABIT BX6 release 2.0 motherboard (with 16550s I assume). I have an Intel Celeron 300a CPU which I normally run at 450 MHz (using a 100 MHz memory bus speed instead of 66 MHz but when I run it at 300 MHz it doesn't make any difference to this problem). I have PC100 SD RAM with an EPROM. This RAM is rated at 7ns believe it or not. I'd like to be using Soren's ATAPI driver but it doesn't like my CD-ROM drive so I'm using the normal wd driver with flags a0ffa0ff. I'm using a KTX V.90 modem at 115000 baud. I typically get 45333, 46667 or 48000 connections to my ISP. I'm using a Microsoft serial mouse but am not using moused. I do have a PS/2 intellimouse compatible mouse attached but only use it when I'm on the darkside (In Windows 95) as it doesn't work with moused or in XFree86. My whole system has been re-compiled within the last 2 days (world, updated /etc, kernel AND ALL ports [XFree86 3.3.3.1, kde 1.1.1 etc etc etc]) Kernel config file (MATTE), /etc/XF86Config file and dmesg output attached. I have one question about my kernel config: How do I know when it's unsafe to use options CPU_DISABLE_5X86_LSSER ? It would be good if the kernel disabled this option under those cases. My /etc/ppp/ppp.conf is: default: set log chat connect phase set device /dev/cuaa1 set speed 115200 allow users matt deny lqr deny chap set timeout 0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ ATX4S95=47 OK-AT-OK \\dATDT\\T TIMEOUT 80 CONNECT set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 isp: set phone ISPNUMBER set login TIMEOUT 10 sername:--sername: MYUSER ssword: MYPASS dial Brian Feldman wrote: On Sat, 8 May 1999, Jordan K. Hubbard wrote: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. Hmm, so now you're the second to cite the possibility of X masking interrupts too long, eh? ;) Actually, I use MAME all the time, and this problem does NOT occur (XF86_SVGA on an S3 ViRGE/DX). Oh, user-ppp too of course. If I could have reproduced this problem, I would have replied. If you can say here's a small stand-alone C program which hogs things to the extent that the serial driver seriously overruns its buffers then it's likely that someone will be at least motivated to compile, run and try it. If it involves running some esoteric application which requires downloading data of questionable legality on top of it, it's far less likely that anyone will even bother to look. MAME is a great piece of software, and in and of itself entirely legal; what problem do you have with it? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in
Re: Doesn't anyone care about the broken sio ??
On Sun, May 09, 1999 at 12:39:56PM +0930, Matthew Thyer wrote: *** STOP PRESS *** I have just confirmed that restarting the X server is enough to fix the problem. So my apologies to Bruce, -CURRENT and the whole FreeBSD community in general for blaming sio. For the benefit of David Dawes, I'll quickly restate the problem: Running xmame (from the ports collection) causes lots of silo overflows with user mode ppp until I either restart the X server or reboot. This occurs even after I exit xmame. This is all on FreeBSD-CURRENT but has been happenning for months and is not newbus related. OK, so there may be a problem with the tseng driver in XFree86. Does xmame use DGA? If so, the problem may be related to switching in and out of DGA mode. A test for that would be to try another DGA client and see if it triggers the same problem (like the 'dga' test client that comes with XFree86 -- if you try it, press 'q' to exit it). The first thing I would suspect is PCI retries. The driver doesn't use those by default, but a bug might cause it to overfill the ET6000's fifo queue, which would bring the PCI retry mechanism into action. Do you only get the overflows when the X server is doing things? Do you think the X server process is using more CPU when this problem shows up compared with before? One other thing to try is adding the following line to the relevant Device section in your XF86Config file: Option xaa_no_color_exp and see if that makes any difference. David To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
