Re: Multiple stability issues with r208557, r208809 on amd64
On Tue, Jun 8, 2010 at 4:59 PM, Xin LI wrote: > Do you mean between the two revisions or something? I committed > r208557 which doesn't seem likely to cause any runtime issue; 208809 > is isp(4) change which is not part of your kernel... > > [delp...@delta] /usr/src> svn log -r 208557 > > r208557 | delphij | 2010-05-25 15:19:51 -0700 (Tue, 25 May 2010) | 4 lines > > Grammar nits. > > Submitted by: b. f. > > > [delp...@delta] /usr/src> svn diff -c 208557 > Index: release/doc/en_US.ISO8859-1/relnotes/article.sgml > === > --- release/doc/en_US.ISO8859-1/relnotes/article.sgml (revision 208556) > +++ release/doc/en_US.ISO8859-1/relnotes/article.sgml (revision 208557) > @@ -327,7 +327,7 @@ > based on libarchive, have replaced the GNU > Binutils versions of these utilities. > > - BSD-licensed version of &man.bc.1; and &man.dc.1; has > + BSD-licensed versions of &man.bc.1; and &man.dc.1; have > replaced their GNU counterparts. > > &man.chflags.1; now supports a > -v flag for > @@ -378,7 +378,7 @@ > disable the use of TCP options. > > &man.nc.1;'s -o switch has been deprecated. > - It will be removed in future release. > + It will be removed in a future release. > > The &man.ping6.8; utility now returns 2 > when the packet transmission was successful but no responses Hi Xin! Well, I hope that that wouldn't cause my machine to tank (otherwise it likes to be a grammar nazi too much :P)... What I was trying to identify is a general trend in terms of evaluation of different versions of CURRENT; somewhere after the code revision that I noted (r206173), the code appears to be regressing more and more to the point where CURRENT has become completely unusable to me in a development scenario, other than just a throwaway NFS rootfs, s.t. recent code changes need to be thoroughly inspected and the regression / multiple regressions needs to be root caused before 9.0-RELEASE, otherwise this will definitely gate multiple people from upgrading to newer versions of FreeBSD. This probably is somewhat related to the locking changes, and the fact that several drivers might have been broken before, but because there were safeguards around certain sections of code, or because it was operating at a slow enough rate, the system itself appeared sane and happy from the outside. But that's probably just useless conjecture anyhow... I realize that CURRENT is supposed to be relatively in flux and it's primarily for development and evaluation, but I thought that the whole point of having development branches was to avoid the scenario where the software itself was completely unusable on dev boxes so that several folks could work in parallel with [relatively] minor conflicts between each others' changes. Part of the reason why I've avoided passing along pkg_install patches -- I want to make sure that I do my job in testing things to a large degree so I don't break other peoples' machines unnecessarily (and I'm sure that the bulk majority of developers on the project feel the same as well). Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Multiple stability issues with r208557, r208809 on amd64
Do you mean between the two revisions or something? I committed r208557 which doesn't seem likely to cause any runtime issue; 208809 is isp(4) change which is not part of your kernel... [delp...@delta] /usr/src> svn log -r 208557 r208557 | delphij | 2010-05-25 15:19:51 -0700 (Tue, 25 May 2010) | 4 lines Grammar nits. Submitted by: b. f. [delp...@delta] /usr/src> svn diff -c 208557 Index: release/doc/en_US.ISO8859-1/relnotes/article.sgml === --- release/doc/en_US.ISO8859-1/relnotes/article.sgml (revision 208556) +++ release/doc/en_US.ISO8859-1/relnotes/article.sgml (revision 208557) @@ -327,7 +327,7 @@ based on libarchive, have replaced the GNU Binutils versions of these utilities. -BSD-licensed version of &man.bc.1; and &man.dc.1; has +BSD-licensed versions of &man.bc.1; and &man.dc.1; have replaced their GNU counterparts. &man.chflags.1; now supports a -v flag for @@ -378,7 +378,7 @@ disable the use of TCP options. &man.nc.1;'s -o switch has been deprecated. - It will be removed in future release. + It will be removed in a future release. The &man.ping6.8; utility now returns 2 when the packet transmission was successful but no responses -- Xin LI http://www.delphij.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: patch submission for multiple branches
On Tue, Jun 8, 2010 at 3:05 PM, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, Tom, > > On 2010/06/08 14:42, Tom Couch wrote: >> I have updated the twa driver (src/sys/dev/twa) and generated patches >> against RELENG_7 and RELENG_8. >> I submitted the patches separately in PR 147694 (RELENG_7) and PR 147695 >> (RELENG_8). >> PR 147694 has been closed as a duplicate of PR 147695. > > It would be nice if you would explicitly mention RELENG_7 next time if > you use the PR system. > >> What happens to the patch for RELENG_7 (PR 147694)? >> What is the proper way to submit patches for multiple branches? > > I'll take care for this. I have reopened 147694. > > Many thanks for the continued support to FreeBSD! Yes, indeed :D. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: patch submission for multiple branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Tom, On 2010/06/08 14:42, Tom Couch wrote: > I have updated the twa driver (src/sys/dev/twa) and generated patches > against RELENG_7 and RELENG_8. > I submitted the patches separately in PR 147694 (RELENG_7) and PR 147695 > (RELENG_8). > PR 147694 has been closed as a duplicate of PR 147695. It would be nice if you would explicitly mention RELENG_7 next time if you use the PR system. > What happens to the patch for RELENG_7 (PR 147694)? > What is the proper way to submit patches for multiple branches? I'll take care for this. I have reopened 147694. Many thanks for the continued support to FreeBSD! Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBCAAGBQJMDr7CAAoJEATO+BI/yjfBFMwH+wRs1u0uZKDb3nobRM1S9gv+ u9Qgr3YaSH03+IiwrclmOsskEuN4GQPhUWFiTUKilCw9ud1W4WXBMO0NE62rPErg 8KhyYAwC3KTuPxgzrGqn70CDySVQJ68vdcv8hzmZo5k3mES4vOvdGokZWWkf50kH +TlccUjHESUkou8CUojpaL/JNTJ0lgN/uvE0XSFXZm8lCNMTC3KTZrZhJ0WNvWpJ MbJnqGFn7CXP1ovob0mEiYnTnx7um9biqPZUk4pyTuFqNkb2RejylGNyPrS4iqPO bBA5hayhdbOQUfdjmYi2q/KAS65IyEbl6AXcr3cre4Y++7mN9ZLBYiVbVnYDm2s= =ScAN -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Multiple stability issues with r208557, r208809 on amd64
Hi, I'm noticing a lot more LORs nowadays and my development box is livelocking a lot. The cases I've seen with LORs are: 1. When unplugging a Dell USB keyboard with a USB hub on r208557; this wasn't reproducible on r208809 though. 2. Creating DOS floppies in a build environment (chroot) for $work on r208557 and r208809; I don't have any information other than that apart from the fact that the issue is transient. 3. scp'ing a small ISO to a Solaris box creates a reproducible panic with r208809 with bce(4) (noted below) because GIANT is held and it attempts to acquire another lock [seen in the WITNESS enabled kernel]. 4. panic from ddb is broken (doesn't sync and boot -- also demonstrated in below pictures) in the WITNESS enabled kernel. 5. Hangs at reboot seen on both revisions. The most stable version I've been able to deal with is r206173 on all of my desktops and my build server -- all of which are amd64 with 12GB and 8GB respectively and differing processor configurations (but they're all W and X series Xeon procs with SMT support) :(... I'll provide more data if needed. Thanks, -Garrett PS The images can be found here: http://s303.photobucket.com/albums/nn159/yaneurabeya/CURRENT%20instability%20July%202010/ cpu HAMMER ident TAMESHI_CURRENT makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_JOURNAL # Enable UFS softupdates journaling options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32# Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #optionsKDTRACE_FRAME # Ensure frames are compiled in #optionsKDTRACE_HOOKS # Kernel DTrace hooks options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # ATA and ATAPI devices device ata device atadisk # ATA disk
patch submission for multiple branches
I have updated the twa driver (src/sys/dev/twa) and generated patches against RELENG_7 and RELENG_8. I submitted the patches separately in PR 147694 (RELENG_7) and PR 147695 (RELENG_8). PR 147694 has been closed as a duplicate of PR 147695. What happens to the patch for RELENG_7 (PR 147694)? What is the proper way to submit patches for multiple branches? Tom Couch ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: New event timers infrastructure
Brandon Gooch wrote: > I'm giving http://people.freebsd.org/~mav/et.20100607.patch a go right now... > > After patching and recompiling the kernel, I'm up and running. > > What information/feedback would you like to see from us users? As always: what is working and especially what is not. What timers detected on system, what are used, are all of them running, and if not, does system automatically falls back to different ones, is there any problems with choosing timers manually in different combinations, does suspend/resume still working... -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
VM ware crash with current...
Hi all: I am getting a mysterious crash on my vmware machine running head. http://people.freebsd.org/~rrs/crash1.png and http://people.freebsd.org/~rrs/crash2.png are snapshots. If I run the same kernel with one core.. no problem Note also this does NOT have SCTP in it.. I took it out to make sure it was not one of my issues ;-) Basically I logged in .. did a ps then cleared the screen type sync and then left it. After about 15-20 minutes this crash appears. I did a svn update this morning.. so its real fresh.. oh yeah, witness/invariant and deadlock detection is all on.. R -- Randall Stewart 803-317-4952 (cell) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: New event timers infrastructure
On Tue, Jun 8, 2010 at 9:40 AM, Alexander Motin wrote: > Brandon Gooch wrote: >> Alexander, do you feel that the code is at a stage where meaningful >> user testing can occur? > > I think yes. I've touched a lot of legacy code, so it would be nice to > know what I may have broken. For example, i8254 and RTC drivers now more > dependent on attaching to PnP/ACPI reported hardware. I am not sure if > there still any legacy system which not doing that. The oldest system I > have tested was P-III Celeron. Unluckily my small development SSD is too > "large" for my Pentium board's BIOS. :) > > There is still work planned, but I hope it won't require major changes > in already written code. > > -- > Alexander Motin > I'm giving http://people.freebsd.org/~mav/et.20100607.patch a go right now... After patching and recompiling the kernel, I'm up and running. What information/feedback would you like to see from us users? -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ports/139483: x11-fm/thunar name is in lowercase while package name is in uppercase
> I agree with you that this is a bit inconsistent and this had > been done right in the first place when the port was created. > But changing it now - I fear to much problems which may occur by very less > gain on th eother hand and this is why I'll not change the package name. I also agree with You mate, backward compatibility is very important, but so is consistency, at least from logical point of view. Maybe we should 'leave it as it is' for next 'BIG' release, or at least till next 'POINT' release (like 8.1-RELEASE for example), and the put all needed info in RELEASE NOTES, that during restructuring the PORTS tree infrastructure all ports were changes to _lowercase_ to make ports tree more consistent and logical, or at least a single package can be lowercase/UPPERCASE in its 'world' treated the same, (lowercase or UPPERCASE but not other). The same of course goes to many other ports, like TeTeX* ports, there are no tetex* ports of course, but using TeTeX name can be VERY misleading ... and I am a long time FreeBSD user/admin. With all respect to TeX 'way' of writing, it should be lowercase. I do not want to 'force' or should I use more appreciate word like 'bring back to order' word, to make it just better. I do not like all the mess in the Linux world, and its pity, that many of us are pointing Linux the mess while we are not 'clear' at the same time. Sorry for CC'ing that message into CURRENT/STABLE MLs, but I just feel that we need to do something about it, to make the FreeBSD (or ports) ecosystem better. For me this change does not mean much, I already KNOW that I must tyle TeTeX or Thunar in the CLI, but think about so many newcomers or just people who did not add that port earlier, its just not logical/consistent, to leave that case 'as is'. As I stated at the beginning, backward compatibility is also very important, so we may 'resolve' that problem in two ways generally, or maybe someone with bigger head then mine come with better solution. 1. Just rename ports to lowercase both in ports and packages with appreciate info in RELEASE NOTES, for some *-RELEASE (8.1-RELEASE comes into my mind of course, or some DOT ZERO release, that will be 9.0-RELEASE in 2012, which may be not so needed delay for that kind of annoucement). 2. Create BOTH lowercase/UPPERCASE/Various packages names both in ports (metaports) and packages (will take disk space), for some time and ANNOUNCE in RELEASE NOTES, that these 'other then lowercase' ports/packages are available only until next release. With all regards to developers/maintainers time, vermaden -- Najlepsza wyszukiwarka tanich lotow! Sprawdz >>> http://linkint.pl/f2726 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: New event timers infrastructure
Brandon Gooch wrote: > Alexander, do you feel that the code is at a stage where meaningful > user testing can occur? I think yes. I've touched a lot of legacy code, so it would be nice to know what I may have broken. For example, i8254 and RTC drivers now more dependent on attaching to PnP/ACPI reported hardware. I am not sure if there still any legacy system which not doing that. The oldest system I have tested was P-III Celeron. Unluckily my small development SSD is too "large" for my Pentium board's BIOS. :) There is still work planned, but I hope it won't require major changes in already written code. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: New event timers infrastructure
On Tue, Jun 8, 2010 at 12:24 AM, Tsuyoshi Ozawa wrote: > 2010/6/6, Alexander Motin : >> Hi. >> >> Most of x86 systems now has at least 4 types of event timers: i8254, >> RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily >> hardcoded and absolutely not scalable. I have reimplemented it, trying >> to solve these issues. >> >> I did such things: >> - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). >> It supports global and per-CPU timers, periodic and one-shot. Provides >> driver and consumer interfaces for choosing timers and operating them; >> - cleaned existing x86 event timer driver's code and modified it for >> new API (x86/isa/atrtc.c, x86/isa/clock.c, x86/x86/local_apic.c). LAPIC >> timer is now per-CPU and supports both periodic and one-shot modes; >> - extended HPET driver to support it's event timers in periodic and >> one-shot mode (dev/acpica/acpi_hpet.c). Support for per-CPU operation >> and FSB interrupts planned for later; >> - written mostly machine-independent mid-layer for managing any present >> timers to provide clocks needed for kernel (x86/x86/timeevents.c). It >> supports both global and per-CPU timers. Now it supports only periodic >> mode, but one-shot mode support planned for later. >> >> All this stuff deeply configurable via both loader tunables on boot and >> sysctls in real time: >> >> %sysctl kern.eventtimer >> kern.eventtimer.choice: LAPIC(500) HPET(400) HPET1(390) HPET2(390) >> i8254(100) RTC(0) >> kern.eventtimer.et.LAPIC.flags: 7 >> kern.eventtimer.et.LAPIC.frequency: 99752386 >> kern.eventtimer.et.LAPIC.quality: 500 >> kern.eventtimer.et.HPET.flags: 3 >> kern.eventtimer.et.HPET.frequency: 14318180 >> kern.eventtimer.et.HPET.quality: 400 >> kern.eventtimer.et.HPET1.flags: 3 >> kern.eventtimer.et.HPET1.frequency: 14318180 >> kern.eventtimer.et.HPET1.quality: 390 >> kern.eventtimer.et.HPET2.flags: 3 >> kern.eventtimer.et.HPET2.frequency: 14318180 >> kern.eventtimer.et.HPET2.quality: 390 >> kern.eventtimer.et.RTC.flags: 1 >> kern.eventtimer.et.RTC.frequency: 32768 >> kern.eventtimer.et.RTC.quality: 0 >> kern.eventtimer.et.i8254.flags: 1 >> kern.eventtimer.et.i8254.frequency: 1193182 >> kern.eventtimer.et.i8254.quality: 100 >> kern.eventtimer.timer2: NONE >> kern.eventtimer.timer1: i8254 >> kern.eventtimer.singlemul: 2 >> >> By default system chooses two timers with highest "quality" for >> hardclock and statclock/profclock. User may affect that choice via >> disabling unwanted drivers and/or via direct specification of wanted >> ones. It is possible to change timers on-flight via sysctls: >> >> %sysctl kern.eventtimer.timer1=hpet >> kern.eventtimer.timer1: i8254 -> HPET >> %sysctl kern.eventtimer.timer2=hpet1 >> kern.eventtimer.timer2: NONE -> HPET1 >> >> After every timer change, if two timers available, mid-layer >> cross-checks them, and if one of them is not functional - replaces it. >> >> If there is no second timer available, or user specified to not use it - >> mid-layer automatically increases rate of the first timer and divide >> it's frequency to satisfy system needs as good as possible. User may >> specify how fast he wish to run fist timer relative to hz by setting >> kern.eventtimer.singlemul tunable/sysctl. >> >> When profiling is active, mid-layer automatically rises respective timer >> frequency to about 8KHz (was 1KHz previously) and decreases it back on >> profiling end. >> >> All above was tested on i386 and amd64. XEN was not affected and builds >> fine. pc98 was slightly touched. It wasn't tested, but builds fine. It's >> pc98/cbus/clock.c needs respective rewrite to use new features. Other >> architectures are untouched, but if any of them may benefit from this >> functionality - it should be possible to share most of the code. >> >> Latest patches can be found here: >> http://people.freebsd.org/~mav/et.20100606.patch >> >> Known issues: >> - i8254 timer generates 18Hz interrupt rate when not used and not >> disabled. I haven't found a way to disable it's interrupt source while >> holding spinlock. >> - timer drivers code will need some more cleaning after interrupt >> handler will be able to return both argument and frame same time. >> >> Feedback is very appreciated. >> >> -- >> Alexander Motin >> > > This is excellent! > I'll try this to apply this patch and rewrite my old dynamic ticks code to > fit this event timer API . > > Thank you, Alexander ! > -- > Tsuyoshi Ozawa > > > 2010/06/07 7:03 "Alexander Motin" : > > Hi. > > Most of x86 systems now has at least 4 types of event timers: i8254, > RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily > hardcoded and absolutely not scalable. I have reimplemented it, trying > to solve these issues. > > I did such things: > - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). > It supports global and per-CPU timers, periodic and one-shot. Provides > driver and consumer interfaces for choosing timers and operating them; >
Re: RFC: New event timers infrastructure
2010/6/6, Alexander Motin : > Hi. > > Most of x86 systems now has at least 4 types of event timers: i8254, > RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily > hardcoded and absolutely not scalable. I have reimplemented it, trying > to solve these issues. > > I did such things: > - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). > It supports global and per-CPU timers, periodic and one-shot. Provides > driver and consumer interfaces for choosing timers and operating them; > - cleaned existing x86 event timer driver's code and modified it for > new API (x86/isa/atrtc.c, x86/isa/clock.c, x86/x86/local_apic.c). LAPIC > timer is now per-CPU and supports both periodic and one-shot modes; > - extended HPET driver to support it's event timers in periodic and > one-shot mode (dev/acpica/acpi_hpet.c). Support for per-CPU operation > and FSB interrupts planned for later; > - written mostly machine-independent mid-layer for managing any present > timers to provide clocks needed for kernel (x86/x86/timeevents.c). It > supports both global and per-CPU timers. Now it supports only periodic > mode, but one-shot mode support planned for later. > > All this stuff deeply configurable via both loader tunables on boot and > sysctls in real time: > > %sysctl kern.eventtimer > kern.eventtimer.choice: LAPIC(500) HPET(400) HPET1(390) HPET2(390) > i8254(100) RTC(0) > kern.eventtimer.et.LAPIC.flags: 7 > kern.eventtimer.et.LAPIC.frequency: 99752386 > kern.eventtimer.et.LAPIC.quality: 500 > kern.eventtimer.et.HPET.flags: 3 > kern.eventtimer.et.HPET.frequency: 14318180 > kern.eventtimer.et.HPET.quality: 400 > kern.eventtimer.et.HPET1.flags: 3 > kern.eventtimer.et.HPET1.frequency: 14318180 > kern.eventtimer.et.HPET1.quality: 390 > kern.eventtimer.et.HPET2.flags: 3 > kern.eventtimer.et.HPET2.frequency: 14318180 > kern.eventtimer.et.HPET2.quality: 390 > kern.eventtimer.et.RTC.flags: 1 > kern.eventtimer.et.RTC.frequency: 32768 > kern.eventtimer.et.RTC.quality: 0 > kern.eventtimer.et.i8254.flags: 1 > kern.eventtimer.et.i8254.frequency: 1193182 > kern.eventtimer.et.i8254.quality: 100 > kern.eventtimer.timer2: NONE > kern.eventtimer.timer1: i8254 > kern.eventtimer.singlemul: 2 > > By default system chooses two timers with highest "quality" for > hardclock and statclock/profclock. User may affect that choice via > disabling unwanted drivers and/or via direct specification of wanted > ones. It is possible to change timers on-flight via sysctls: > > %sysctl kern.eventtimer.timer1=hpet > kern.eventtimer.timer1: i8254 -> HPET > %sysctl kern.eventtimer.timer2=hpet1 > kern.eventtimer.timer2: NONE -> HPET1 > > After every timer change, if two timers available, mid-layer > cross-checks them, and if one of them is not functional - replaces it. > > If there is no second timer available, or user specified to not use it - > mid-layer automatically increases rate of the first timer and divide > it's frequency to satisfy system needs as good as possible. User may > specify how fast he wish to run fist timer relative to hz by setting > kern.eventtimer.singlemul tunable/sysctl. > > When profiling is active, mid-layer automatically rises respective timer > frequency to about 8KHz (was 1KHz previously) and decreases it back on > profiling end. > > All above was tested on i386 and amd64. XEN was not affected and builds > fine. pc98 was slightly touched. It wasn't tested, but builds fine. It's > pc98/cbus/clock.c needs respective rewrite to use new features. Other > architectures are untouched, but if any of them may benefit from this > functionality - it should be possible to share most of the code. > > Latest patches can be found here: > http://people.freebsd.org/~mav/et.20100606.patch > > Known issues: > - i8254 timer generates 18Hz interrupt rate when not used and not > disabled. I haven't found a way to disable it's interrupt source while > holding spinlock. > - timer drivers code will need some more cleaning after interrupt > handler will be able to return both argument and frame same time. > > Feedback is very appreciated. > > -- > Alexander Motin > This is excellent! I'll try this to apply this patch and rewrite my old dynamic ticks code to fit this event timer API . Thank you, Alexander ! -- Tsuyoshi Ozawa 2010/06/07 7:03 "Alexander Motin" : Hi. Most of x86 systems now has at least 4 types of event timers: i8254, RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily hardcoded and absolutely not scalable. I have reimplemented it, trying to solve these issues. I did such things: - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). It supports global and per-CPU timers, periodic and one-shot. Provides driver and consumer interfaces for choosing timers and operating them; - cleaned existing x86 event timer driver's code and modified it for new API (x86/isa/atrtc.c, x86/isa/clock.c, x86/x86/local_apic.c). LAPIC timer is now per-CPU and supports both periodic and
Panic on S3 suspend call.
Hi. Just noted that fresh HEAD i386 system panics on suspend request when build with INVARIANTS and WITNESS: panic: mutex ACPI global lock owned at ../../../kern/kern_event.c:1899 cpuid = 1 KDB: enter: panic [ thread pid 1047 tid 100138 ] Stopped at 0x408d29df: movl$0,0x40dded34 db> bt Tracing pid 1047 tid 100138 td 0x45fcb9c0 kdb_enter(40c75fe3,40c75fe3,40c74763,7c91fb1c,1,...) at 0x408d29df panic(40c74763,40c26898,40c70d4e,76b,7c91fb40,...) at 0x4089ec96 _mtx_assert(40da08a0,0,40c70d4e,76b,7c91fb70,...) at 0x4088e227 knlist_mtx_assert_unlocked(40da08a0,4088ed2c,40da08a0,45d377c0,3,...) at 0x4086b06e knote(45d377dc,0,0,921,0,...) at 0x4086b9ff acpi_ReqSleepState(456c3700,3,40c2633d,c76,0,...) at 0x404e8f4b acpiioctl(45793400,80045004,45d07810,3,45fcb9c0,...) at 0x404e9118 devfs_ioctl_f(45d820e0,80045004,45d07810,45d34a80,45fcb9c0,...) at 0x4081d1e8 kern_ioctl(45fcb9c0,3,80045004,45d07810,91fcec,...) at 0x408ebdbd ioctl(45fcb9c0,7c91fcec,0,40cb192e,0,...) at 0x408ebf47 syscallenter(45fcb9c0,7c91fce4,40b9fa00,40dcd190,0,...) at 0x408e0b23 syscall(7c91fd28) at 0x40b9f169 Xint0x80_syscall() at 0x40b7f49a --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28183173, esp = 0x3fbfeb1c, ebp = 0x3fbfebf8 --- db> -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ioapic_assign_cpu() on active level-triggered interrupt
Hi.
John Baldwin wrote:
> On Friday 04 June 2010 2:30:13 pm Alexander Motin wrote:
>> I am working on driver for HPET event timers. It works mostly fine,
>> except after some cases when ioapic_assign_cpu() called while timer is
>> active. Under interrupt rate of 10KHz it is enough a dozen cpuset runs
>> to break it (with 1KHz - few dozens). When it happens, I can see that
>> timer is still running, interrupt status register is changing, but no
>> interrupts received.
>>
>> Can somebody explain this behavior and propose some solution? Have
>> somebody seen it for regular PCI devices?
>
> It probably would be best to disable the source, however, you can't just re-
> enable it as it might already be disabled when you move it. It is also
> probably a bug that io_masked can be read w/o holding the icu_lock in
> ioapic_program_intpin(). I think the icu_lock should be pushed up to callers
> of ioapic_program_intpin(), and that you should explicitly do a simple write
> to mask the source a bit earlier. Something like this perhaps:
>
> Index: io_apic.c
> ===
> --- io_apic.c (revision 208714)
> +++ io_apic.c (working copy)
>
> If you find that you still need the DELAY(10), you could place it in the
> conditional block that masks the interrupt perhaps.
Thank you!
This patch seems to reduce stuck probability for level-triggered
interrupts, especially when printf works as DELAY() on bootverbose=1.
Without DELAY() and bootverbose I can trigger the issue by few dozens of
spuset runs. With DELAY() I still was able to do it twice, but only
after several hundreds of tries.
Also I have found that unconditional pre-disabling interrupt hurts RTC
timer. As I understand, IRQ8 is edge-triggered, and it's loss during
switch makes RTC timer stuck. I've tried to not mask edge-triggered
interrupts - and it helped. But even so I am able to hang RTC timer with
hundred cpusets, so may be we have to just choose between bad and worse.
Updated patch attached.
PS: For the global timers CPU binding is probably not so important, as
interrupts are any way redistributed to other CPUs. So I have found that
this issue can be workarounded by binding interrupts to BSP during
attach to avoid migration on SMP start.
--
Alexander Motin
--- io_apic.c.prev 2010-06-05 00:53:55.0 +0300
+++ io_apic.c 2010-06-08 09:21:56.0 +0300
@@ -261,16 +261,15 @@ ioapic_program_intpin(struct ioapic_ints
* If a pin is completely invalid or if it is valid but hasn't
* been enabled yet, just ensure that the pin is masked.
*/
+ mtx_assert(&icu_lock, MA_OWNED);
if (intpin->io_irq == IRQ_DISABLED || (intpin->io_irq < NUM_IO_INTS &&
intpin->io_vector == 0)) {
- mtx_lock_spin(&icu_lock);
low = ioapic_read(io->io_addr,
IOAPIC_REDTBL_LO(intpin->io_intpin));
if ((low & IOART_INTMASK) == IOART_INTMCLR)
ioapic_write(io->io_addr,
IOAPIC_REDTBL_LO(intpin->io_intpin),
low | IOART_INTMSET);
- mtx_unlock_spin(&icu_lock);
return;
}
@@ -312,14 +311,12 @@ ioapic_program_intpin(struct ioapic_ints
}
/* Write the values to the APIC. */
- mtx_lock_spin(&icu_lock);
intpin->io_lowreg = low;
ioapic_write(io->io_addr, IOAPIC_REDTBL_LO(intpin->io_intpin), low);
value = ioapic_read(io->io_addr, IOAPIC_REDTBL_HI(intpin->io_intpin));
value &= ~IOART_DEST;
value |= high;
ioapic_write(io->io_addr, IOAPIC_REDTBL_HI(intpin->io_intpin), value);
- mtx_unlock_spin(&icu_lock);
}
static int
@@ -352,6 +349,14 @@ ioapic_assign_cpu(struct intsrc *isrc, u
if (new_vector == 0)
return (ENOSPC);
+ /* Mask the old intpin if it is enabled while it is migrated. */
+ mtx_lock_spin(&icu_lock);
+ if (!intpin->io_masked && !intpin->io_edgetrigger) {
+ ioapic_write(io->io_addr, IOAPIC_REDTBL_LO(intpin->io_intpin),
+ intpin->io_lowreg | IOART_INTMSET);
+ DELAY(100);
+ }
+
intpin->io_cpu = apic_id;
intpin->io_vector = new_vector;
if (isrc->is_handlers > 0)
@@ -364,6 +369,8 @@ ioapic_assign_cpu(struct intsrc *isrc, u
intpin->io_vector);
}
ioapic_program_intpin(intpin);
+ mtx_unlock_spin(&icu_lock);
+
/*
* Free the old vector after the new one is established. This is done
* to prevent races where we could miss an interrupt.
@@ -399,9 +406,11 @@ ioapic_disable_intr(struct intsrc *isrc)
/* Mask this interrupt pin and free its APIC vector. */
vector = intpin->io_vector;
apic_disable_vector(intpin->io_cpu, vector);
+ mtx_lock_spin(&icu_lock);
intpin->io_
