On Wed, 5 May 2004, Carlos Velasco wrote: > On 02/05/2004 at 22:24 Carlos Velasco wrote: > > >On 02/05/2004 at 9:14 M. Warner Losh wrote: > > > >>: sio4: 118 more interrupt-level buffer overflows (total 118) > >>: sio4: 162 more interrupt-level buffer overflows (total 280) > >> > >>That may be due to the MFC interrupt issue that I talked about. But > >>it could be something else... > > > >I have tried playing with pccard_intr but it doesn't work. > >I'm reading about a patch for sio.c in the list, i don't know if it can > >helps into this I will try it in near future and see the results. > > Well... this didn't work. > > However I googled and found this: > http://lists.freebsd.org/pipermail/freebsd-bugs/2003-May/000687.html > > Applying it solves problem for me. > Could we commit this in sio.c until GIANT solve work is done? > > This is my complete patch (it works for me), including sio change and also > pccard 64k alignment: It seems like a patch for MFC sincd it has mfc's in it (what is a MFC?). > diff -ru sys/dev/sio/sio.c sysnew/dev/sio/sio.c > --- sys/dev/sio/sio.c Mon May 3 22:35:28 2004 > +++ sysnew/dev/sio/sio.c Wed May 5 13:04:14 2004 > _at__at_ -2374,7 +2374,7 _at__at_ > * (about 3 ticks if input flow control is not used or not honoured, > * but a bit less for CS5-CS7 modes). > */ > - cp4ticks = speed / 10 / hz * 4; > + cp4ticks = speed / 10 / hz * 40; > for (ibufsize = 128; ibufsize < cp4ticks;) > ibufsize <<= 1; > if (ibufsize == com->ibufsize) { However, you may need only this part of it. This part permits software interrupts to be delayed by 38 ticks instead of the expected maximim of 2 ticks. I keep forgetting to fix this. Scaling by hz is not quite right, because hz may be set to values that are too small to work all the time or even most of the time. There is a clamp to 128 (min), but this is a bit small. E.g., with hz = 1000 and speed = 115200, the original code in the above gives cp4ticks = 44 and ibufsize = 128. If hz = 1000 actually worked, then the buffer would be drained every 1 msec and would never have more than 12 characters in it, but the software interrupt latency is apparently sometimes >= 12 msec so the buffer overflows. There are some mii Giant hogs which sometimes delay timeout processing for that long or nearly so (each). sio's software interrupt[s] should have a priority higher than timeouts, but sio now has 2 software interrupts with one of them having the same low priority as timeouts. This priority should work (in fact, old versions of sio just use timeouts), but in RELENG_4 the priority is much higher than that as a side effect of having only only the correct number of SWIs (1). RELENG_4 may now depend on this. BruceReceived on Wed May 05 2004 - 05:26:49 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC