Recent USB problems
Hello, after the following patch: joe 2002/02/15 16:51:26 PST Modified files: sys/dev/usb ohci.c uhci.c usb.h usb_subr.c usbdivar.h Log: Merge from NetBSD: Pave the way for USB2, by replacing 'lowspeed' with 'speed', so that it can take the values USB_SPEED_LOW, USB_SPEED_FULL or in time USB_SPEED_HIGH. my USB-mouse quits working. Normal dmesg output looks like this: uhci0: port 0xcc00-0xcc1f irq 12 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: KYE Genius USB Wheel Mouse, rev 1.00/0.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: port 0xd800-0xd81f irq 12 at device 7.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered Now the system pauses for approx. 15 second during boot and the output looks like this: uhci0: port 0xcc00-0xcc1f irq 12 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered << here pause >> usbd_new_device: addr=2, getting first desc failed uhub0: device problem, disabling port 1 uhci1: port 0xd800-0xd81f irq 12 at device 7.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered The system is a dual PIII Gigabyte system with VIA-Chipset. Any hints? Michael To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB detach crashes possibly fixed
Bruce Evans wrote: > On Sat, 16 Feb 2002, Terry Lambert wrote: > > PHK was threatening to murder /dev/speaker to work > > around some clock issues that would be hard to nail > > down the right way. > > I think you mean /dev/pcaudio. Yes; I confused the two, since I rarely do audio stuff at all (I think implementing the ALSA kernel and lib stuff for FreeBSD would not be a bad project for a junior person). So the problem can't be related to the timer changes that Poul was contemplating; therefore it *must* be related to the USB stuff. Maybe it's stomping on an interrupt or I/O address or something. 8-(. > I use /dev/pcaudio to expose the > brokenness of clock code that is not nailed down in the right way. Humor. Ar ar ar. To the original poster: So to fix the original problem, you should disable everything you can (and still boot) except the audio stuff, and then add things back in until it fails; this will identify the problem area, and we can go from there. Uh, it occurs to me that you might be loading your driver as a kernel module; if so, you remembered to recompile it when you recompiled your kernel, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB detach crashes possibly fixed
Fcc: outbox Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii > > > > > > and I got a small tune on attach but nothing on detach. > > > Now I am unable to play notes on /dev/speaker. Any hint? > > As Terry notes, shouldn't possibly be related. > > > I have no crashes but the detach action is never executed when I switch off > > my Sony camera ( it has never worked as far as I know) > > Attach actions are executed fine.. > > Have you tried compiling in all available USB debugging support or seeing if > anyone else is using one like yours? No, but if I run usbd in the foreground and with some -v flags it never reports seeing a detach event even though the device driver reports it. It looks like usbd just doesn't get it... This is what the kernel logs when switching the camera on and off. Feb 17 11:57:44 trantor kernel: umass0: Sony Sony DSC, rev 1.00/2.10, addr 2 Feb 17 11:57:44 trantor kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Feb 17 11:57:44 trantor kernel: da0: Removable Direct Access SCSI-0 device Feb 17 11:57:44 trantor kernel: da0: 150KB/s transfers Feb 17 11:57:44 trantor kernel: da0: 61MB (126848 512 byte sectors: 0H 0S/T 0C) Feb 17 11:58:04 trantor kernel: umass0: at uhub0 port 1 (addr 2) disconnected Feb 17 11:58:04 trantor kernel: (da0:umass-sim0:0:0:0): lost device Feb 17 11:58:04 trantor kernel: umass0: detached Looks OK to me. And this is what usbd prints $ sudo usbd -d -v -v -v -v usbd: opened /dev/usb0 usbd: opened /dev/usb1 usbd: opened /dev/usb2 usbd: reading configuration file /etc/usbd.conf usbd: action 1: Sony DSC S70 Camera vndr=0x054c prdct=0x0010 attach='sleep 5 ;mount /sony' detach='umount -f /sony' usbd: action 2: USB device usbd: 2 actions usbd: opened /dev/usb usbd: device-attach event at 1013898654.50584, Sony DSC, Sony: vndr=0x054c prdct=0x0010 rlse=0x0210 clss=0x subclss=0x prtcl=0x device names: umass0 usbd: Found action 'Sony DSC S70 Camera' for Sony DSC, Sony at umass0 usbd: action 0: Sony DSC S70 Camera vndr=0x054c prdct=0x0010 attach='sleep 5 ;mount /sony' detach='umount -f /sony' usbd: Setting DEVNAME='umass0' usbd: Executing 'sleep 5 ;mount /sony' msdosfs: /dev/da0s1: No such file or directory usbd: 'sleep 5 ;mount /sony' returned 71 usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: processing event queue on /dev/usb usbd: device-attach event at 1013943463.949946000, Sony DSC, Sony: vndr=0x054c prdct=0x0010 rlse=0x0210 clss=0x subclss=0x prtcl=0x device names: umass0 usbd: Found action 'Sony DSC S70 Camera' for Sony DSC, Sony at umass0 usbd: action 0: Sony DSC S70 Camera vndr=0x054c prdct=0x0010 attach='sleep 5 ;mount /sony' detach='umount -f /sony' usbd: Setting DEVNAME='umass0' usbd: Executing 'sleep 5 ;mount /sony' usbd: 'sleep 5 ;mount /sony' is ok usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 usbd: doing timeout discovery on /dev/usb2 usbd: processing event queue due to timeout on /dev/usb ^C It looks like the driver works fine as far as I can tell, but usbd just doesn't see the detach event. -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB detach crashes possibly fixed
On Sun, 2002-02-17 at 00:49, Paul van der Zwan wrote: > I have no crashes but the detach action is never executed when I switch off > my Sony camera ( it has never worked as far as I know) > Attach actions are executed fine.. I have not see crashas any more too, BUT now I can't see my usb keyboard and mice at all: On today's current: uhub1: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 4 ports with 4 removable, bus powered uhub1: device problem, disabling port 2 uhub1: device problem, disabling port 4 Same kernel with usb modules build on Feb 13 sources (previous): uhub1: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 4 ports with 4 removable, bus powered ukbd0: Behavior Tech. Computer Keyboard with mouse port, rev 1.00/1.00, addr 3, iclass 3/1 kbd1 at ukbd0 ums0: Behavior Tech. Computer Keyboard with mouse port, rev 1.00/1.00, addr 3, iclass 3/1 ums0: 3 buttons ums1: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 4, iclass 3/1 ums1: 5 buttons and Z dir. Output of usbdevs -v: Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 addr 2: power 100 mA, config 1, UT-USB41 hub(0x1446), Texas Instruments(0x0451), rev 1.10 port 1 powered port 2 addr 3: low speed, power 100 mA, config 1, Keyboard with mouse port(0x6782), Behavior Tech. Computer(0x046e), rev 1.00 port 3 powered port 4 addr 4: low speed, power 100 mA, config 1, Microsoft IntelliMouse® Explorer(0x001e), Microsoft(0x045e), rev 1.14 port 2 powered And usbd still not detect detaches (not execute detach scripts) People what is going on with USB code ??? > Paul -- TSB "Russian Express", Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB detach crashes possibly fixed
Paul van der Zwan wrote: > No, but if I run usbd in the foreground and with some -v flags it never > reports seeing a detach event even though the device driver reports it. > It looks like usbd just doesn't get it... [ ... ] > It looks like the driver works fine as far as I can tell, but usbd just > doesn't see the detach event. Does the daemon use kqueue? It looks like there's a bug in kqueue for FIN processing, and another bug in another area. It appears to all be FreeBSD 4.5/current specific (4.4 doesn't have the lost event problem). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
I also see these messages on my Dell 410 Workstation at work and a Dual
PIII Box I use at home to do builds with...they just seem to 'come and go'
with no particular pattern to them...I have just been ignoring them for the
most part...they don't really seem to cause any problems..
At 06:54 PM 2/17/2002 +1100, Bruce Evans wrote:
>On Sat, 16 Feb 2002, Matthew Dillon wrote:
>
>> Testing with a 'make -j 10 buildworld' on a -current box I am getting
>> regular:
>>
>> microuptime() went backwards (146.826785 -> 146.156715)
>> microuptime() went backwards (146.826782 -> 146.228636)
>> ...
>> microuptime() went backwards (8945.938288 -> 8945.251603)
>> microuptime() went backwards (8945.938306 -> 8945.347173)
>> microuptime() went backwards (9142.847550 -> 9142.847546)
>>
>> This occurs both with and without the gettimeofday Giant-removal patch, so
>> I am fairly sure it has nothing to do with any of my current work. This is
>> running -current on a DELL2550 (2xCPUs), compiled with the SMP option.
>
>The fact that the timecounter usually goes backwards by about 0.68 seconds
>is probably significant, but I can't quite explain it.
>
>> Timecounter "i8254" frequency 1193182 Hz
>> ...
>> Timecounter "ACPI" frequency 3579545 Hz
>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
>> acpi_cpu0: on acpi0
>> acpi_cpu1: on acpi0
>> acpi_pcib0: on acpi0
>> ...
>>
>> Question: How can this be occuring at all? Isn't the ACPI counter a
>> 32 bit counter that does not have the rollover problems that the 8254 timer
>> has?
>
>Timecounters go backwards when the timecounter update or reference code is
>called insufficiently often to prevent overflow. The rollover problems of
>the i8254 timecounter actually reduce this problem. If an i8254 rollover
>is missed, then it causes the the i8254 timecounter to go forward less
>than it should.
>
>I just wrote the following fix for some of the overflow problems.
>
>%%%
>Index: kern_tc.c
>===
>RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
>retrieving revision 1.113
>diff -c -2 -r1.113 kern_tc.c
>*** kern_tc.c 7 Feb 2002 21:21:55 - 1.113
>--- kern_tc.c 17 Feb 2002 06:25:14 -
>***
>*** 108,114
> struct timecounter *tc;
>
>! tc = timecounter;
>! *bt = tc->tc_offset;
>! bintime_addx(bt, tc->tc_scale * tco_delta(tc));
> }
>
>--- 95,129
> struct timecounter *tc;
>
>! /*
>! * The loop is to handle changes of timecounter underneath us.
>! * Such changes may even become normal for preemptive kernels.
>! * It is quite reasonable for idle priority processes to not
>! * run for many seconds, and if they are not running after
>! * being preempted here, the timecounter may cycle many times
>! * underneath them. An NTIMECOUNTER of > 2 is neither necessary
>! * or sufficient for fixing this problem, unless NTIMECOUNTER is
>! * preposterously large. NTIMECOUNTER == 2 suffices for most
>! * cases, and something more is required to fix the general case.
>! *
>! * I hope this also fixes problems with overflow of the
>! * multiplication. We depend on tc not becoming stale by more
>! * than 1 second. We will now normally see such staleness
>! * because it will cause the timecounter to change many times
>! * underneath us. There will only be problems if hardclock()
>! * doesn't run for many seconds, but hardclock() is a very
>! * high priority interrupt, so such problems "can't happen".
>! *
>! * XXX should use a generation count.
>! *
>! * XXX problems with hardclock() can happen, e.g., at boot time
>! * if you have fixed hardclock() to not be a broken fast interrupt
>! * handler, or if you sit at the ddb prompt for several seconds.
>! * Should do something to make them harmless.
>! */
>! do {
>! tc = timecounter;
>! *bt = tc->tc_offset;
>! bintime_addx(bt, tc->tc_scale * tco_delta(tc));
>! } while (tc != timecounter);
> }
>
>%%%
>
>Bruce
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
Glenn Gombert
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
FreeBSD unfinished NIS+ implementation in Linux ?
Hi all, While looking at nis-utils-1.4.1 from linux, I found that that whole package is based on Bill's work. Intersting that everything there is GNU labled. What happened to the BSD copyright ? Or has it been GPL'd from the beginning ? http://freshmeat.net/projects/nis-utils The author even forgot to remove one part of a manpage: nis-utils-1.4.1$ more man/nis_db.3 .Em The TI-RPCSRC 2.3 source code distribution. .Sh HISTORY This implementation of the .Nm nis_db library was written for and is scheduled to appear in a future release of FreeBSD 2.x as part of a complete, freely available NIS+ client and server package. This library was written entirely from scratch: no Sun code other than the publically available NIS+ header files was referenced. Strange thing. Bill, did you ever allowed them to make it GPL only ? Looking at the code it should be possible to import some things and make a NIS+ client available. But only if it's not GPL'd. Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
Bills Work: http://people.freebsd.org/~wpaul/nis.tar.gz Suse Linux version: ftp://ftp.kernel.org/pub/linux/utils/net/NIS+/nis-utils-1.4.1.tar.bz2 An example from a file: File: db_add_entry.c Bills Copyright: /* * Copyright (c) 1996, 1997 * Bill Paul <[EMAIL PROTECTED]>. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: * This product includes software developed by Bill Paul. * 4. Neither the name of the author nor the names of any co-contributors *may be used to endorse or promote products derived from this software *without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY Bill Paul AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL Bill Paul OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ Suse's Copyright: /* Copyright (c) 1999 Thorsten Kukuk Author: Thorsten Kukuk <[EMAIL PROTECTED]> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: function name collision on "getcontext" with ports/editors/joe
On Sun, 10 Feb 2002, Kevin Day wrote: > > I'm the maintainer for ports/editors/joe, and just tried compiling it under > -CURRENT. > > includes which includes ucontext.h > > > cc -O -pipe -c umath.c > > In file included from b.h:6, > > from bw.h:23, > > from umath.c:5: > > rc.h:41: conflicting types for `getcontext' > > /usr/include/sys/ucontext.h:54: previous declaration of `getcontext' > > *** Error code 1 > > > > Stop in /usr/ports/editors/joe/work/joe. > > > I can rename getcontext in joe, but "getcontext" seems like a pretty common > function name, I know I've used it in projects before. Not including > signal.h isn't really an option either. The ucontext related namespace pollution should be fixed now. Let me know otherwise. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problem installing ports
Hi, Two ports I've tried to install recently, open-motif-devel and AbiWord, have attempted to `mkdir /'. This fails with: "mkdir: /: Is a directory." Installing these ports works just fine under 4.5-STABLE. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn'tthat be impossible?
:I just wrote the following fix for some of the overflow problems.
I don't understand how this code is supposed to handle overflows.
You seem only to be checking to see if the master timecounter has
changed to a different type.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:%%%
:Index: kern_tc.c
:===
:RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
:retrieving revision 1.113
:diff -c -2 -r1.113 kern_tc.c
:*** kern_tc.c 7 Feb 2002 21:21:55 - 1.113
:--- kern_tc.c 17 Feb 2002 06:25:14 -
:***
:*** 108,114
: struct timecounter *tc;
:
:! tc = timecounter;
:! *bt = tc->tc_offset;
:! bintime_addx(bt, tc->tc_scale * tco_delta(tc));
: }
:
:--- 95,129
: struct timecounter *tc;
:
:! /*
:! * The loop is to handle changes of timecounter underneath us.
:! * Such changes may even become normal for preemptive kernels.
:! * It is quite reasonable for idle priority processes to not
:! * run for many seconds, and if they are not running after
:! * being preempted here, the timecounter may cycle many times
:! * underneath them. An NTIMECOUNTER of > 2 is neither necessary
:! * or sufficient for fixing this problem, unless NTIMECOUNTER is
:! * preposterously large. NTIMECOUNTER == 2 suffices for most
:! * cases, and something more is required to fix the general case.
:! *
:! * I hope this also fixes problems with overflow of the
:! * multiplication. We depend on tc not becoming stale by more
:! * than 1 second. We will now normally see such staleness
:! * because it will cause the timecounter to change many times
:! * underneath us. There will only be problems if hardclock()
:! * doesn't run for many seconds, but hardclock() is a very
:! * high priority interrupt, so such problems "can't happen".
:! *
:! * XXX should use a generation count.
:! *
:! * XXX problems with hardclock() can happen, e.g., at boot time
:! * if you have fixed hardclock() to not be a broken fast interrupt
:! * handler, or if you sit at the ddb prompt for several seconds.
:! * Should do something to make them harmless.
:! */
:! do {
:! tc = timecounter;
:! *bt = tc->tc_offset;
:! bintime_addx(bt, tc->tc_scale * tco_delta(tc));
:! } while (tc != timecounter);
: }
:
:%%%
:
:Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
On Sun, Feb 17, 2002 at 03:57:59PM +0100, Martin Blapp wrote: > Bill, did you ever allowed them to make it GPL only ? Looking at the code > it should be possible to import some things and make a NIS+ client > available. But only if it's not GPL'd. Interesting. I looked as nisgrep/nisgrep.c and noticed that the code structure was basically the same, but the variables were just slightly different... -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
Martin Blapp <[EMAIL PROTECTED]> wrote: > Suse's Copyright: > > /* Copyright (c) 1999 Thorsten Kukuk >Author: Thorsten Kukuk <[EMAIL PROTECTED]> That would at least be a copyright violation. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >> This occurs both with and without the gettimeofday Giant-removal patch, so >> I am fairly sure it has nothing to do with any of my current work. This is >> running -current on a DELL2550 (2xCPUs), compiled with the SMP option. The Gian removal doesn't come anywhere near this. >The fact that the timecounter usually goes backwards by about 0.68 seconds >is probably significant, but I can't quite explain it. >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Well: 2^32 / 3579545 = 1199.86 seconds. 2^24 / 3579545 =4.68 seconds. So even assuming that ACPI reported a wrong width, four seconds should still be enough to prevent a wraparound even though we cycle through the timecounter ring in one second. >I just wrote the following fix for some of the overflow problems. It is true that if a process is not running for arbitrary long time the timecounter may be modified underneat it, and bruce's patch is actually a pretty elegant solution for that case. By all means try it. I have had one other report of a similar problem, with the added information that changing to the TSC or i8254 instead of PIXX made it go away so I am not entirely convinced this is really what we are looking for in this case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: >:I just wrote the following fix for some of the overflow problems. > >I don't understand how this code is supposed to handle overflows. >You seem only to be checking to see if the master timecounter has >changed to a different type. Bruce's patch amounts to a retry if the current timecounter was updated while we were calculating time. It is a bit more defensive than it needs to be and generally pessimizes the timecounters elegant lockless design a fair bit, but it is still much better than slamming a mutex around the entire clock code. If this patch cures the PIIX problem, something I'm not at all convinced about, it should go in, if not only the comment should go in. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn'tthat be impossible?
Ok, I've looked at the code more carefully and I understand how this works now. However, it is not enough in an SMP environment. You need a generation count in the timecounter structure and you also need a synchronization point when you switch time counters or a process running on a different cpu may wind up using a time counter that is being actively updated. I'm experimenting with your patch now. I'll send email when I have some test results. -Matt : :I just wrote the following fix for some of the overflow problems. : :%%% :Index: kern_tc.c :=== :RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v :retrieving revision 1.113 :diff -c -2 -r1.113 kern_tc.c :... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
:Bruce's patch amounts to a retry if the current timecounter was updated
:while we were calculating time. It is a bit more defensive than it
:needs to be and generally pessimizes the timecounters elegant lockless
:design a fair bit, but it is still much better than slamming a mutex
:around the entire clock code.
:
:If this patch cures the PIIX problem, something I'm not at all convinced
:about, it should go in, if not only the comment should go in.
:
:Poul-Henning
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
Ok, I've tested Bruce's patch and it appeaars to mostly solve the problem.
I no longer get 'microuptime ... backwards' errors on a -current SMP
box.
However, I think to be complete we need to make it even less elegant.
The TC module is only flip-flopping between two time counters, which
means that it can flip-flop twice and the test will not work. We need
a generation count on the timecounter as well:
do {
tc = timecounter;
gen = tc->tc_generation;
*bt = tc->tc_offset;
bintime_addx(bt, tc->tc_scale * tco_delta(tc));
} while (tc != timecounter || tc->tc_generation != gen);
There is also an issue on non-i386 machines. The timecounter swapping
code requires a memory synchronization point after updating the
contents of the new timecounter but before setting the 'timecounter' global
to the new timecounter. If this is not done, non-i386 machines running
SMP may see the new timecounter structure but access pre-updated values
from it.
(i386 boxes do not have this problem because writes are ordered so the
inherent synchronication point at the end of the timer interrupt is
enough).
Is there a memory synchronization point macro available?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 -> 458.168882)
microuptime() went backwards (578.609995 -> 577.929801)
microuptime() went backwards (748.912755 -> 748.237402)
microuptime() went backwards (775.159625 -> 775.159612)
I also think this retry loop has to be done everywhere where the
timecounter structure is accessed directly.
-Matt
:Ok, I've tested Bruce's patch and it appeaars to mostly solve the problem.
:I no longer get 'microuptime ... backwards' errors on a -current SMP
:box.
:...
Index: kern/kern_tc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
retrieving revision 1.113
diff -u -r1.113 kern_tc.c
--- kern/kern_tc.c 7 Feb 2002 21:21:55 - 1.113
+++ kern/kern_tc.c 17 Feb 2002 20:41:47 -
@@ -107,9 +107,11 @@
{
struct timecounter *tc;
- tc = timecounter;
- *bt = tc->tc_offset;
- bintime_addx(bt, tc->tc_scale * tco_delta(tc));
+ do {
+ tc = timecounter;
+ *bt = tc->tc_offset;
+ bintime_addx(bt, tc->tc_scale * tco_delta(tc));
+ } while (tc != timecounter);
}
void
@@ -126,8 +128,10 @@
struct timecounter *tc;
ngetmicrotime++;
- tc = timecounter;
- *tvp = tc->tc_microtime;
+ do {
+ tc = timecounter;
+ *tvp = tc->tc_microtime;
+ } while (tc != timecounter);
}
void
@@ -136,8 +140,10 @@
struct timecounter *tc;
ngetnanotime++;
- tc = timecounter;
- *tsp = tc->tc_nanotime;
+ do {
+ tc = timecounter;
+ *tsp = tc->tc_nanotime;
+ } while (tc != timecounter);
}
void
@@ -166,8 +172,10 @@
struct timecounter *tc;
ngetmicrouptime++;
- tc = timecounter;
- bintime2timeval(&tc->tc_offset, tvp);
+ do {
+ tc = timecounter;
+ bintime2timeval(&tc->tc_offset, tvp);
+ } while (tc != timecounter);
}
void
@@ -176,8 +184,10 @@
struct timecounter *tc;
ngetnanouptime++;
- tc = timecounter;
- bintime2timespec(&tc->tc_offset, tsp);
+ do {
+ tc = timecounter;
+ bintime2timespec(&tc->tc_offset, tsp);
+ } while (tc != timecounter);
}
void
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message <[EMAIL PROTECTED]>, Matthew Dillon wri
tes:
>However, I think to be complete we need to make it even less elegant.
>The TC module is only flip-flopping between two time counters, which
>means that it can flip-flop twice and the test will not work. We need
>a generation count on the timecounter as well:
>
>do {
>tc = timecounter;
>gen = tc->tc_generation;
>*bt = tc->tc_offset;
>bintime_addx(bt, tc->tc_scale * tco_delta(tc));
>} while (tc != timecounter || tc->tc_generation != gen);
No, more like:
do {
tc = timecounter;
gen = tc->gen;
...
} while (gen != tc->gen);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message <[EMAIL PROTECTED]>, Matthew Dillon wri
tes:
>Whoop! I take it back. I'm still getting the errors:
>
>microuptime() went backwards (458.168990 -> 458.168882)
>microuptime() went backwards (578.609995 -> 577.929801)
>microuptime() went backwards (748.912755 -> 748.237402)
>microuptime() went backwards (775.159625 -> 775.159612)
>
>I also think this retry loop has to be done everywhere where the
>timecounter structure is accessed directly.
No, only where the timecounter hardware is read and the math
done. As far as I know, this is the only place.
As I said, I am far from convinced this is the solution to the problem
we are looking at with the PIIX timecounter.
Msmith has some magic code in sys/dev/acpi/acpi_timer.c which tries
to identify if the PIIX counter is broken or OK and I notice that
the mask seems to always be set to 24 bits even if the hardware
is 32 bits.
I am not sure I read his code right, but he seems to default to the
unsafe method, can you try this copy&pasted patch ?
Index: acpi_timer.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.11
diff -u -r1.11 acpi_timer.c
--- acpi_timer.c8 Jan 2002 06:45:56 - 1.11
+++ acpi_timer.c17 Feb 2002 20:48:23 -
@@ -138,7 +138,7 @@
if (getenv("debug.acpi.timer_test") != NULL)
acpi_timer_test();
-acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount;
+acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount_safe;
acpi_timer_timecounter.tc_frequency = acpi_timer_frequency;
tc_init(&acpi_timer_timecounter);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
Matt, Easy now, there is more depth to it than that... I have promised myself to get the timecounter paper written and I'll probably present it at BSDcon-euro-2002 in Amsterdam if they want to listen to me. For now, lets concentrate on the PIIX hardware because that's where the problem seems to be... Poul-Henning In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: >Ok, I've looked at the code more carefully and I understand how this >works now. However, it is not enough in an SMP environment. You >need a generation count in the timecounter structure and you also need >a synchronization point when you switch time counters or a process >running on a different cpu may wind up using a time counter that is being >actively updated. > >I'm experimenting with your patch now. I'll send email when I have >some test results. > > -Matt > >: >:I just wrote the following fix for some of the overflow problems. >: >:%%% >:Index: kern_tc.c >:=== >:RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v >:retrieving revision 1.113 >:diff -c -2 -r1.113 kern_tc.c >:... > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Expect buildworld instability
I'm about to begin the import of sendmail 8.12.2 into -CURRENT. While I am doing the important, it's likely that a buildworld will fail. I'll post again when I'm done (expected to take about 15 to 20 minutes). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness and rpm
whoever wrote: > Sorry work kept me from getting back to you immediately > following is the error i am getting > i cvsuped the src on February 7th > > > Version of my vfs_syscall > $FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.220 2002/02/01 18:27:16 alfred Exp Are you sure you actually built and installed the world & kernel after you cvsup'd? -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
> If this patch cures the PIIX problem, something I'm not at all convinced > about, it should go in, if not only the comment should go in. I would like to see "the PIIX problem" caught on camera, personally. We're aware of one errata for it already, and we work around it. If there's another problem, or ideally if someone has some relatively quick code to test it, that would be much better. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Expect buildworld instability
gshapiro> I'm about to begin the import of sendmail 8.12.2 into -CURRENT. gshapiro> While I am doing the important, it's likely that a buildworld gshapiro> will fail. I'll post again when I'm done (expected to take about gshapiro> 15 to 20 minutes). The import and infrastructure commits are complete. buildworld should be back to normal (I'm doing to a test run on a fresh checkout to be sure). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
:I would like to see "the PIIX problem" caught on camera, personally.
:We're aware of one errata for it already, and we work around it. If
:there's another problem, or ideally if someone has some relatively quick
:code to test it, that would be much better.
If the _safe version works I'll reinstrument the code to catch and
print the problem counter values.
Is the ACPI on a 16 or 32 bit bus? Idiot chip designers have made
'non-atomic counter carry' bugs endemic in the PC world. The standard
solution is to just read the counter twice and and loop if the top
17 bits have changed in order to avoid the carry problem entirely.
Something like this:
u_int32_t u1;
u_int32_t u2;
u1 = TIMER_READ;
u2 = TIMER_READ;
while ((u1 ^ u2) & 0x8000) {
u1 = u2;
u2 = TIMER_READ;
}
return(u2);
The solution you have in there will theoretically work as long as the
16-bit carry itself is synchronized (which it probably is), but it should
be possible to do it with only two timer reads in the best-case instead of
three.
I'll investigate further.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ACPI timer is screwed... (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
:I would like to see "the PIIX problem" caught on camera, personally.
:We're aware of one errata for it already, and we work around it. If
:there's another problem, or ideally if someone has some relatively quick
:code to test it, that would be much better.
Holy shit. We are screwed. It's a free-running counter with NO
synchronization whatsoever. None. Zip. Zero.
ACPI TIMER LSB MISREAD 128ababd 128abaa2 128abaa4
ACPI TIMER LSB MISREAD 128ea0cd 128ea0c9 128ea0cb
ACPI TIMER LSB MISREAD 129427fd 129425ff 12942801
So, for example: ABD AA2 AA4
ABD 10101001
^ probably should be a 0
AA2 101010100010
AA2 101010100100
Another example: 0CD 0C9 0CB
0CD 11001101
^ probably should be a 0
0C9 11001001
0CB 11001011
It looks like the hardware is using an adder with fast carry
(basically a forward looking carry calculation), which can result in a
later bit being set before the earlier bits are updated. However, if
this is the case then it is almost certain that you can catch the ripple
as well, or even catch the counter while the bit states are changing.
The only way to get a guarenteed accurate sample under these circumstances
is something like this, where you calculate a mask that results in
reasonable accurancy without causing the cpu to go into an infinite
loop and then read the timer until you get two samples that are the same:
u1 = TIMER_READ;
u2 = TIMER_READ;
while ((u1 ^ u2) & 0xFFF0) { mask must be chosen
u1 = u2;
u2 = TIMER_READ;
}
return(u2 & 0xFFF0) same mask here
Here are some more from my debug output:
ACPI TIMER LSB MISREAD 2cb0f97d 2cb0f961 2cb0f963
ACPI TIMER LSB MISREAD 2fad1ced 2fad1ce9 2fad1ceb
ACPI TIMER LSB MISREAD 33ed26ff 33ed2681 33ed2683
ACPI TIMER LSB MISREAD 34184d1d 34184d19 34184d1c
ACPI TIMER LSB MISREAD 344516ff 344516e1 344516e3
ACPI TIMER LSB MISREAD 392b2c6d 392b2c69 392b2c6b
ACPI TIMER LSB MISREAD 39c9073d 39c90739 39c9073b
ACPI TIMER LSB MISREAD 39f3161d 39f3161a 39f3161c
ACPI TIMER LSB MISREAD 3ad04bbf 3ad04bb1 3ad04bb3
ACPI TIMER LSB MISREAD 39f3161d 39f3161a 39f3161c
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI timer is screwed... (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
>
> :I would like to see "the PIIX problem" caught on camera, personally.
> :We're aware of one errata for it already, and we work around it. If
> :there's another problem, or ideally if someone has some relatively quick
> :code to test it, that would be much better.
>
> Holy shit. We are screwed. It's a free-running counter with NO
> synchronization whatsoever. None. Zip. Zero.
Sounds like we need to smack whoever made your chipset as well. Intel
learned their lesson (finally) with later revisions of the PIIX4. I'm
guessing you're running this against a ServerWorks system.
> It looks like the hardware is using an adder with fast carry
> (basically a forward looking carry calculation), which can result in a
> later bit being set before the earlier bits are updated. However, if
> this is the case then it is almost certain that you can catch the ripple
> as well, or even catch the counter while the bit states are changing.
Lame. Incredibly lame.
> The only way to get a guarenteed accurate sample under these circumstances
> is something like this, where you calculate a mask that results in
> reasonable accurancy without causing the cpu to go into an infinite
> loop and then read the timer until you get two samples that are the same:
>
> u1 = TIMER_READ;
> u2 = TIMER_READ;
> while ((u1 ^ u2) & 0xFFF0) { mask must be chosen
> u1 = u2;
> u2 = TIMER_READ;
> }
> return(u2 & 0xFFF0) same mask here
>
> Here are some more from my debug output:
Interesting. This would be reasonably robust in the ripple-counter case
we have to deal with on the old PIIX4. Have you tried implementing the
above yet, or measuring how much it costs?
At any rate, please let me know for sure whether you're running on a
ServerWorks board, and I'll see if I can't find a Big Stick to hit them
with.
Thanks,
Mike
--
To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to
the American public. - Theodore Roosevelt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ACPI patch (was Re: 'microuptime() went backwards ...' using ACPI...)
Ok, here is a patch that executes a brute-force solution to the
asynchronous counter problem.
Basically it figures out a mask and then the timer code loops until two
masked reads yield the same value, guarenteeing that we haven't caught
the timer during a carry.
On my system, the mask I got was: 0xFFFC which means I lost only 2
bits of accuracy in order to be able to retrieve accurate counter values.
This gives my particular box an approximately 1uS accuracy.
I think this may be the only safe way to do it. It looks like it is
possible to catch the ripple and/or fast-carry on *any* bit, with the
statistical chance of it occuring on higher bits dropping by 2x per bit.
My proposed (tested) patch is below. Mike?
acpi_timer0: <32-bit timer at 3.579545MHz mask fffc> port 0x808-0x80b on acpi0
-Matt
Index: acpi_timer.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.11
diff -u -r1.11 acpi_timer.c
--- acpi_timer.c8 Jan 2002 06:45:56 - 1.11
+++ acpi_timer.c17 Feb 2002 23:26:29 -
@@ -56,6 +56,7 @@
MODULE_NAME("TIMER")
static device_tacpi_timer_dev;
+static u_int32_t acpi_timer_mask;
struct resource*acpi_timer_reg;
#define TIMER_READ bus_space_read_4(rman_get_bustag(acpi_timer_reg), \
rman_get_bushandle(acpi_timer_reg),\
@@ -113,7 +114,7 @@
acpi_timer_identify(driver_t *driver, device_t parent)
{
device_t dev;
-char desc[40];
+char desc[48];
intrid;
FUNCTION_TRACE(__func__);
@@ -138,14 +139,32 @@
if (getenv("debug.acpi.timer_test") != NULL)
acpi_timer_test();
-acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount;
+acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount_safe;
acpi_timer_timecounter.tc_frequency = acpi_timer_frequency;
tc_init(&acpi_timer_timecounter);
-sprintf(desc, "%d-bit timer at 3.579545MHz", AcpiGbl_FADT->TmrValExt ? 32 : 24);
+for (acpi_timer_mask = 0x; acpi_timer_mask; acpi_timer_mask <<= 1) {
+ u_int32_t u1;
+ u_int32_t u2;
+ int count = 10;
+
+ u1 = TIMER_READ;
+ u2 = TIMER_READ;
+ while (count && ((u1 ^ u2) & acpi_timer_mask)) {
+ u1 = u2;
+ u2 = TIMER_READ;
+ --count;
+ }
+ if (count)
+ break;
+}
+acpi_timer_mask <<= 1;
+
+sprintf(desc, "%d-bit timer at 3.579545MHz mask %08x",
+ (AcpiGbl_FADT->TmrValExt ? 32 : 24), acpi_timer_mask);
device_set_desc_copy(dev, desc);
-#if 0
+#if 0
{
u_int64_t first;
@@ -192,16 +211,22 @@
static unsigned
acpi_timer_get_timecount_safe(struct timecounter *tc)
{
-unsigned u1, u2, u3;
+u_int32_t u1;
+u_int32_t u2;
+u1 = TIMER_READ;
u2 = TIMER_READ;
-u3 = TIMER_READ;
-do {
+while ((u1 ^ u2) & acpi_timer_mask) {
u1 = u2;
- u2 = u3;
- u3 = TIMER_READ;
-} while (u1 > u2 || u2 > u3);
-return (u2);
+ u2 = TIMER_READ;
+}
+#if 0 /* DEBUGGING */
+if (u2 < u1) {
+ u_int32_t u3 = TIMER_READ;
+ printf("ACPI TIMER LSB MISREAD %08x %08x %08x\n", u1, u2, u3);
+}
+#endif
+return(u2 & acpi_timer_mask);
}
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI timer is screwed... (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
:Sounds like we need to smack whoever made your chipset as well. Intel :learned their lesson (finally) with later revisions of the PIIX4. I'm :guessing you're running this against a ServerWorks system. atapci0: port 0x8b0-0x8bf at device 15.1 on pci0 Uh huh. It might be possible to detect the situation during init-time by explicitly looking for a reverse indexed time in a tight loop of maybe a thousand reads, but that would still leave us with a statistical chance of not guessing right. :Interesting. This would be reasonably robust in the ripple-counter case :we have to deal with on the old PIIX4. Have you tried implementing the :above yet, or measuring how much it costs? : :At any rate, please let me know for sure whether you're running on a :ServerWorks board, and I'll see if I can't find a Big Stick to hit them :with. : :Thanks, :Mike I haven't measured the cost (extra loops) but I expect it would stabilize in no more then one additional loop, which would be three counter reads total or roughly the same as your originaln _safe code in the worst case. I think we could default to the _safe version and then explicitly change it to use the fast version if we see specific chipsets which we know to be good. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI timer is screwed... (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: > >:I would like to see "the PIIX problem" caught on camera, personally. >:We're aware of one errata for it already, and we work around it. If >:there's another problem, or ideally if someone has some relatively quick >:code to test it, that would be much better. > >Holy shit. We are screwed. It's a free-running counter with NO >synchronization whatsoever. None. Zip. Zero. Yes, there is an errata for just that on early chipsets. Does the ..._slow patch I sent work for you ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI patch (was Re: 'microuptime() went backwards ...' using ACPI...)
> Ok, here is a patch that executes a brute-force solution to the > asynchronous counter problem. > > Basically it figures out a mask and then the timer code loops until two > masked reads yield the same value, guarenteeing that we haven't caught > the timer during a carry. > > On my system, the mask I got was: 0xFFFC which means I lost only 2 > bits of accuracy in order to be able to retrieve accurate counter values. > This gives my particular box an approximately 1uS accuracy. > > I think this may be the only safe way to do it. It looks like it is > possible to catch the ripple and/or fast-carry on *any* bit, with the > statistical chance of it occuring on higher bits dropping by 2x per bit. > > My proposed (tested) patch is below. Mike? I have some reservations about this, because I'm not sure that 10 successive reads will catch the ripple-counter problem that the old PIIX4s have. I think that if this code detects a need for the mask technique, it should set the handler to a function that will deal with the mask. If it doesn't, it should assume that we need the 'safe' function as it currently exists (I'm not sure why it's not the default, unless there's a log message to explain it, it must have been a mistake on my part). I'd also like to see the description include the number of bits, rather than the mask, if we are using a mask. Thanks for taking the time to track this one down. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: sendmail 8.12.2 imported
sendmail 8.12.2 has been imported into -CURRENT. sendmail 8.12 has been developed with two main topics in mind: enhanced security and better performance. sendmail is by default not set-user-ID root anymore which avoids potential local root exploits. See /etc/mail/README (after running mergemaster) for information about possible gotchas with this new version. For more information about the new functionality in 8.12, visit: http://www.sendmail.org/8.12.0.html /usr/src/contrib/sendmail/RELEASE_NOTES and /usr/src/contrib/sendmail/src/SECURITY may also be of interest. Finally, the default /etc/mail/sendmail.cf (based on /usr/src/etc/sendmail/freebsd.mc) no longer uses FEATURE(`relay_based_on_MX'). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI timer is screwed... (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
> >:I would like to see "the PIIX problem" caught on camera, personally. > >:We're aware of one errata for it already, and we work around it. If > >:there's another problem, or ideally if someone has some relatively quick > >:code to test it, that would be much better. > > > >Holy shit. We are screwed. It's a free-running counter with NO > >synchronization whatsoever. None. Zip. Zero. > > Yes, there is an errata for just that on early chipsets. > > Does the ..._slow patch I sent work for you ? Matt's problem (look-ahead carry) will break the three-read algorithm because it can generate a sequence of three reads that appear to be in succession, but which are all wrong. We need three different algorithms; "works", "ripple" and "look-ahead". Of those, "works" should be based exclusively off a list of known-good chipsets, "look-ahead" seems to be easily enough detected (but we should probably have a blacklist anyway) and "ripple" is hard to detect and should be the default case. I really, really hate hardware. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI patch (was Re: 'microuptime() went backwards ...' using ACPI...)
: :I have some reservations about this, because I'm not sure that 10 :successive reads will catch the ripple-counter problem that the old PIIX4s :have. Just goes to show that I need to document my code :-) Those reads are not detecting the ripple-counter problem, they are figuring out the mask required to guarentee that two successive reads will return the same counter value so the counter read in the later code doesn't end up in an infinite loop. i.e. on a slow cpu the mask might have to remove more bits because the counter increments a number of times between reads. On a fast cpu, fewer bits would have to be chopped off. That's all. :I'd also like to see the description include the number of bits, rather :than the mask, if we are using a mask. : :Thanks for taking the time to track this one down. Well, I don't want to spend too much time on it because this was incidental to other work I'm doing on -current. If you think it's worth comitting I'll commit it, otherwise you can use it as a template for your own fix/commit. It would be nice if some sort of solution were comitted to the tree relatively soon. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn'tthat be impossible?
On Sun, 17 Feb 2002, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > > >> This occurs both with and without the gettimeofday Giant-removal patch, so > >> I am fairly sure it has nothing to do with any of my current work. This is > >> running -current on a DELL2550 (2xCPUs), compiled with the SMP option. > > The Gian removal doesn't come anywhere near this. Yes it did. There were Giants in the path for all syscalls. > >The fact that the timecounter usually goes backwards by about 0.68 seconds > >is probably significant, but I can't quite explain it. > > >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > Well: > 2^32 / 3579545 = 1199.86 seconds. > 2^24 / 3579545 =4.68 seconds. > > So even assuming that ACPI reported a wrong width, four seconds should > still be enough to prevent a wraparound even though we cycle through > the timecounter ring in one second. No, there is only one seconds worth of of wraparaond, because recent changes annulled the slightly less recent fixes for loss of nanoseconds above the first 10^9 of them. Previously, the multiplication corresponding to the one in binuptime() overflowed at 2^32 nsec. Now it overflows at 2^64 in units of 2^-64 seconds. > >I just wrote the following fix for some of the overflow problems. > > It is true that if a process is not running for arbitrary long time > the timecounter may be modified underneat it, and bruce's patch is > actually a pretty elegant solution for that case. By all means > try it. Thanks :-). In other mail you said "it pessimize the timecounters elegant lockless design a fair bit". Here the fair bit only applies to the elegance. The pessimization at runtime is tiny. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn'tthat be impossible?
On Sun, 17 Feb 2002, Matthew Dillon wrote: > Ok, I've looked at the code more carefully and I understand how this > works now. However, it is not enough in an SMP environment. You > need a generation count in the timecounter structure and you also need > a synchronization point when you switch time counters or a process > running on a different cpu may wind up using a time counter that is being > actively updated. Er, the comment in patch says it needs a generation count. Unfortunately, we only have half a synchronization point now -- there is a sched_lock() in the update code but nothing in the code that reads the pointer. Maybe a large value of NTIMECOUNTER would help after all. We can afford to o miss a few timecounter changes if we have a lot of timecounter states. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...'using ACPI timer. Shouldn't that be impossible? )
On Sun, 17 Feb 2002, Matthew Dillon wrote:
> Whoop! I take it back. I'm still getting the errors:
>
> microuptime() went backwards (458.168990 -> 458.168882)
> microuptime() went backwards (578.609995 -> 577.929801)
> microuptime() went backwards (748.912755 -> 748.237402)
> microuptime() went backwards (775.159625 -> 775.159612)
>
> I also think this retry loop has to be done everywhere where the
> timecounter structure is accessed directly.
Yes, since the reads of all the relevant timecounter variables are
non-atomic.
> Index: kern/kern_tc.c
> ===
> RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
> retrieving revision 1.113
> diff -u -r1.113 kern_tc.c
> --- kern/kern_tc.c7 Feb 2002 21:21:55 - 1.113
> +++ kern/kern_tc.c17 Feb 2002 20:41:47 -
> @@ -126,8 +128,10 @@
> struct timecounter *tc;
>
> ngetmicrotime++;
> - tc = timecounter;
> - *tvp = tc->tc_microtime;
> + do {
> + tc = timecounter;
> + *tvp = tc->tc_microtime;
> + } while (tc != timecounter);
> }
>
> void
E.g., tc_mictrotime here is a timeval. It doesn't matter getting a stale
value (although getting a stale value increases the possible incoherency
of the get*() functions from 1/HZ to NTIMECOUNTER/HZ), but getting a
stale value that changed underneath the read would be bad.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
A quick, dumb, question...
Is there a single document, or small set of documents, that describes getting started kernel hacking on FreeBSD? How about a set of URLs? I would like something that tells me about (in no particular order) 1) debugging over the serial line, and remote debugging in general 2) Building for 5.0 on 4.x (if possible though I suspect I should not do this) 3) Best practices for dealing with my own versions of files while also working with cvsup. Those are a good start for now. BTW If none exists I will try to write this up in the form of a tutorial and post it at some point. Thanks, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A quick, dumb, question...
>Date: Sun, 17 Feb 2002 17:43:55 -0800
>From: "George V. Neville-Neil" <[EMAIL PROTECTED]>
>Is there a single document, or small set of documents, that describes getting
>started kernel hacking on FreeBSD? How about a set of URLs?
>I would like something that tells me about (in no particular order)
>1) debugging over the serial line, and remote debugging in general
You might start with
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html.
(Sorry about the line-wrapping.)
>2) Building for 5.0 on 4.x (if possible though I suspect I should not do this)
Sure: set up a 4.x system, clear /usr/src, populate /usr/src with
the HEAD of the tree ("cvs co"), then follow the instructions in
/usr/src/UPDATING.
>3) Best practices for dealing with my own versions of files while also
>working with cvsup.
What I do is use CVSup to mirror the CVS repository (vs. a "working
directory"), then use "cvs update" (well, after an initial "cvs co") to
update the sources. I do this within "script", so I get a record of
what was done, and I can grep the "typescript" file for various
weirdnesses, such as conflicts to be resolved.
(I also do the "make buildworld" & friends under script, so if something
weird happens during the build, I don't need to record it: that's been
done. Well, if it's a panic, that may not capture everything -- but a
serial console can be helpful in that case.)
(I've been tracking both -STABLE and -CURRENT daily, on each of a "build
machine" and my laptop, for several months. I've also been testing
patches for folks, so being able to revert patches or generate new ones
is a definite advantage of having the CVS repository handy.)
>Those are a good start for now.
Cheers,
david (links to my resume at http://www.catwhisker.org/~david)
--
David H. Wolfskill [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
+---[ Joerg Wunsch ]-- | Martin Blapp <[EMAIL PROTECTED]> wrote: | | > Suse's Copyright: | > | > /* Copyright (c) 1999 Thorsten Kukuk | >Author: Thorsten Kukuk <[EMAIL PROTECTED]> | | That would at least be a copyright violation. Not necessarily, some derived works are entitled to copyright protection in their own right, hard to prove you've changed it enough to get that though. Unauthorised relicensing of the invididual parts is a copyright violation, it's legal to contain BSDL code in a larger GPL'd work. The contained code still retains the original copyright and license. There is unfortunately a section of the GPL community who confuses this with the right to simply relicense BSDL code whenever you want, because it doesn't explicitly deny it. The FSF 'GPL compatible' licenses page makes this even more confusing (IMO). If you want to stop your BSDL code being used in GPL projects (not sure why you would want to), stick the advertising clause in, this then makes the BSDL GPL incompatible (according to the FSF). -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness and rpm
|whoever wrote: | |> Sorry work kept me from getting back to you immediately |> following is the error i am getting |> i cvsuped the src on February 7th | > |> > Version of my vfs_syscall |> $FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.220 2002/02/01 18:27:16 alfred Exp | |Are you sure you actually built and installed the world & kernel after |you cvsup'd? | |-- |Michael Nottebrock absolutely. I just checked again the kernel causing this trouble was built after cvsuping. And I am pretty sure I did the make world after cvsupping too. I dont know how to check for that though. Just out of curiosity should make world matter in this instance. is the said file used by some libraries also? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Witness and rpm
whoever wrote: > absolutely. > I just checked again the kernel causing this trouble was built after > cvsuping. And I am pretty sure I did the make world after > cvsupping too. I dont know how to check for that though. > Just out of curiosity should make world matter > in this instance. is the said file used by some libraries also? I just asked because I can't reproduce this anymore (I cvsup'd some six hours ago, rebuilt everything, with invariants and witness on, I even tried it with the port you reported, plus erasing and adding a few other random rpms). You might want to try cvsup'ing and updating everything again, make sure you are actually running the new kernel, and, if the problem persists, get a trace of the panic and report it to the mailing list. -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OK, who broke alpha this time? :-/
... sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "i8254" frequency 1193182 Hz ata0-slave: timeout waiting for interrupt ata0-slave: ATAPI identify failed acd0: CDROM at ata0-master PIO4 Waiting 2 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) ^T load: 0.16 cmd: init 8 [inode] 0.00u 0.00s 0% 416k ^T load: 0.16 cmd: init 8 [inode] 0.00u 0.00s 0% 416k [forever] http://people.freebsd.org/~peter/alphadmesg.txt It seems that locking has been hosed somehow. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OK, who broke alpha this time? :-/
On Sun, Feb 17, 2002 at 10:07:34PM -0800, Peter Wemm wrote: > ... > sio0 at port 0x3f8-0x3ff irq 4 on isa0 > sio0: type 16550A, console > sio0: interrupting at ISA irq 4 > sio1: reserved for low-level i/o > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > Timecounter "i8254" frequency 1193182 Hz > ata0-slave: timeout waiting for interrupt > ata0-slave: ATAPI identify failed > acd0: CDROM at ata0-master PIO4 > Waiting 2 seconds for SCSI devices to settle > Mounting root from ufs:/dev/da0a > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled > da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled > da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > ^T > load: 0.16 cmd: init 8 [inode] 0.00u 0.00s 0% 416k > ^T > load: 0.16 cmd: init 8 [inode] 0.00u 0.00s 0% 416k > [forever] > > http://people.freebsd.org/~peter/alphadmesg.txt > > It seems that locking has been hosed somehow. Just guessing: John Baldwin had enabled interrupt thread preemption some days ago. src/sys/alpha/alpha/interrupt.c rev 1.61 Maybe it also enabled some hidden bug. I hope to have one of my machines on -current later that day to compare. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
Andrew Kenneth Milton wrote: > There is unfortunately a section of the GPL community who confuses this > with the right to simply relicense BSDL code whenever you want, because it > doesn't explicitly deny it. The FSF 'GPL compatible' licenses page makes > this even more confusing (IMO). > > If you want to stop your BSDL code being used in GPL projects (not sure > why you would want to), stick the advertising clause in, this then makes > the BSDL GPL incompatible (according to the FSF). The FSF is wrong on "compatible". No matter what license is on the code, relicensing it under a different license without the author's written permission is not legal. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
+---[ Terry Lambert ]-- | Andrew Kenneth Milton wrote: | > There is unfortunately a section of the GPL community who confuses this | > with the right to simply relicense BSDL code whenever you want, because it | > doesn't explicitly deny it. The FSF 'GPL compatible' licenses page makes | > this even more confusing (IMO). | > | > If you want to stop your BSDL code being used in GPL projects (not sure | > why you would want to), stick the advertising clause in, this then makes | > the BSDL GPL incompatible (according to the FSF). | | The FSF is wrong on "compatible". They're only right in one circumstance. Using whole slabs of BSDL code standalone as part of the GPL project, i.e. no mixing of code, the GPL forbids that (since you can't relicense other people's code). | No matter what license is on the code, relicensing it | under a different license without the author's written | permission is not legal. Relicensing isn't the same as incorporating into a larger work cf: Apple OSX is not BSDL, but contains code that is. This is the situation under which BSDL code is 'compatible' with the GPL (the license of the whole does not breech any conditions of the license of the parts). If you were to get your hands on the OSX code, you could safely and legally distribute the BSDL portions under the BSDL. Same with any GPL project using BSDL code. I don't think the GPL actually permits this either, but, the FSF are the ones who tell you what your interpretation of their license is to be. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD unfinished NIS+ implementation in Linux ?
Andrew Kenneth Milton wrote: > | The FSF is wrong on "compatible". > > They're only right in one circumstance. Using whole slabs of BSDL code > standalone as part of the GPL project, i.e. no mixing of code, the GPL > forbids that (since you can't relicense other people's code). Yes, this is actually where it's legal: to put an aggregate copyright on a set of code, rather than changing the license on an individual file or a portion thereof. This is because the license in that case is on the basis of a collection copyright, which is a different thing than a copyright on an individual work of authorship, or of a derivative work. > | No matter what license is on the code, relicensing it > | under a different license without the author's written > | permission is not legal. > > Relicensing isn't the same as incorporating into a larger work cf: Apple > OSX is not BSDL, but contains code that is. This is the situation under which > BSDL code is 'compatible' with the GPL (the license of the whole does not > breech any conditions of the license of the parts). Yes, a collection copyright. > If you were to get your hands on the OSX code, you could safely and legally > distribute the BSDL portions under the BSDL. Same with any GPL project using > BSDL code. Except in the NIS+ case, where the original license _was_ allegedly changed from BSDL to GPL. > I don't think the GPL actually permits this either, but, the FSF > are the ones who tell you what your interpretation of their license > is to be. Actually, not. It is the author who determines that... which is why the FSF requires you to execute an assignment of rights to contribute code to GCC and other FSF projects and have the code accepted, lest your interpretation of the GPL differ from theirs, and result in legal difficulties. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
