Re: Scheduler question
On 04/02/2011, at 13:26, Daniel O'Connor wrote: > I only have about 10 milliseconds of buffering (96kbyte FIFO, 8Mbyte/sec) in > the hardware, however I have about 128Mb of USB requests queued up to libusb. > hps@ informed me that libusb will only queue 16kbyte (2msec) in the kernel at > one time although I have increased this. We have upped the hardware FIFO size to 768kb, which is 91msec at 8Mb/sec, although due to the fact we only start reading out when it's 1/6th full the effective buffer is 75msec. It does seem much more resilient to CPU load, however heavy disk activity on the same drive still stalls it for too long :( Given the large buffering in the program it does seem very odd that it would stall for long enough unless both threads are slept while one is waiting for disk IO (which seems like a bug to me). BTW I have changed to -current (without WITNESS). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sched_setscheduler() behaviour changed??
On Thu, Feb 17, 2011 at 10:50:06AM +0100, Mats Lindberg wrote: > All, > I have been using a small program /rt) that utilize the sched_setscheduler() > syscall to set the scheduling policy of a process to SCHED_RR. Been running > it FBSD 5.x and 6.x. Now when migrating to FBSD 8.1 I get EPERM back at me. > used to be able to run it like e.g. > > ./rt -sr -p2 -- prog > > which started in SCHED_RR policy with priority 2. > > now in FBSD 8.1 I get EPERM > > But If I do > > rtprio 10 ./rt -sr -p2 -- prog > > it I dont get EPERM. > > I'm always root when doing this. > > My problem is that I have customers that need to run their old 5.x 6.x > applications 'as is' in 8.1 whithout changing anything. > > Does anyone know if there is a workaround? > sysctl? kernel hint? kernel config? reverting to 4BSD scheduler? If you want help from the list, you should provide some data to diagnose the issue. Obviously, we cannot read the sources of your rt utility. At least, you can provide ktrace/kdump output for start. pgppBPgaCVFOS.pgp Description: PGP signature
Re: problem with build mcelog
On 02/11/2011 11:31 PM, John Baldwin wrote: On Friday, February 11, 2011 7:48:39 am venom wrote: Hello. i am trying build mcelog FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 04:15:56 UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 # fetch http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz # tar -xf mcelog-1.0pre2.tar.gz # cd mcelog-1.0pre2 # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c Oops, I just updated mcelog.patch and it should work fine now. |--- //depot/vendor/mcelog/tsc.c2010-03-05 20:24:22.0 |+++ //depot/projects/mcelog/tsc.c2010-03-05 21:09:24.0 -- Patching file tsc.c using Plan A... Hunk #1 succeeded at 15. Hunk #2 succeeded at 52. Hunk #3 succeeded at 75. Hunk #4 succeeded at 156. done 12:12:46 ~/temp/MCE/mcelog-1.0pre2 # gmake FREEBSD=yes Makefile:92: .depend: No such file or directory cc -MM -I. p4.c k8.c mcelog.c dmi.c tsc.c core2.c bitfield.c intel.c nehalem.c dunnington.c tulsa.c config.c memutil.c msg.c eventloop.c leaky-bucket.c memdb.c server.c client.c cache.c rbtree.c memstream.c > .depend.X && mv .depend.X .depend cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o mcelog.o mcelog.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o p4.o p4.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o k8.o k8.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o dmi.o dmi.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o tsc.o tsc.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o core2.o core2.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o bitfield.o bitfield.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o intel.o intel.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o nehalem.o nehalem.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o dunnington.o dunnington.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o tulsa.o tulsa.c cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wstrict-prototypes -Wformat-security -Wmissing-declarations -Wdeclaration-after-statement -o config.o config.c config.c:135: error: static declaration of 'getline' follows non-static declaration /usr/include/stdio.h:370: error: previous declaration of 'getline' was here gmake: *** [config.o] Error 1 # -- Vladimir Laskov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sched_setscheduler() behaviour changed??
On 17 February 2011 12:50, Mats Lindberg wrote: > All, > I have been using a small program /rt) that utilize the sched_setscheduler() > syscall to set the scheduling policy of a process to SCHED_RR. Been running > it FBSD 5.x and 6.x. Now when migrating to FBSD 8.1 I get EPERM back at me. > used to be able to run it like e.g. >> ./rt -sr -p2 -- prog > > which started in SCHED_RR policy with priority 2. > > now in FBSD 8.1 I get EPERM > > But If I do >> rtprio 10 ./rt -sr -p2 -- prog > > it I dont get EPERM. > > I'm always root when doing this. > > My problem is that I have customers that need to run their old 5.x 6.x > applications 'as is' in 8.1 whithout changing anything. > [just thinking aloud] Perhaps, you might have stumbled upon the change in sched_setscheduler() restricting permission to superuser: src/sys/posix4/p1003_1b.c#rev1.24.2.1 MFC revision 1.27. Don't allow non-root user to set a scheduler policy. @@ -195,6 +195,10 @@ int sched_setscheduler(struct thread *td struct thread *targettd; struct proc *targetp; + /* Don't allow non root user to set a scheduler policy */ + if (suser(td) != 0) + return (EPERM); + e = copyin(uap->param, &sched_param, sizeof(sched_param)); if (e) return (e); -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: problem with build mcelog
On 18 February 2011 14:13, venom wrote: > On 02/11/2011 11:31 PM, John Baldwin wrote: >> >> On Friday, February 11, 2011 7:48:39 am venom wrote: >>> >>> Hello. >>> >>> i am trying build mcelog >>> >>> >>> FreeBSD 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Fri Jan 14 >>> 04:15:56 >>> UTC 2011 root@freebsd:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> >>> # fetch >>> http://ftp2.pl.freebsd.org/pub/FreeBSD/distfiles/mcelog-1.0pre2.tar.gz >>> # tar -xf mcelog-1.0pre2.tar.gz >>> # cd mcelog-1.0pre2 >>> # fetch http://people.freebsd.org/~jhb/mcelog/mcelog.patch >>> # fetch http://people.freebsd.org/~jhb/mcelog/memstream.c >> >> Oops, I just updated mcelog.patch and it should work fine now. >> > > |--- //depot/vendor/mcelog/tsc.c 2010-03-05 20:24:22.0 > |+++ //depot/projects/mcelog/tsc.c 2010-03-05 21:09:24.0 > -- > Patching file tsc.c using Plan A... > Hunk #1 succeeded at 15. > Hunk #2 succeeded at 52. > Hunk #3 succeeded at 75. > Hunk #4 succeeded at 156. > done > 12:12:46 ~/temp/MCE/mcelog-1.0pre2 > # gmake FREEBSD=yes > Makefile:92: .depend: No such file or directory > cc -MM -I. p4.c k8.c mcelog.c dmi.c tsc.c core2.c bitfield.c intel.c > nehalem.c dunnington.c tulsa.c config.c memutil.c msg.c eventloop.c > leaky-bucket.c memdb.c server.c client.c cache.c rbtree.c memstream.c > > .depend.X && mv .depend.X .depend > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o mcelog.o mcelog.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o p4.o p4.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o k8.o k8.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o dmi.o dmi.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o tsc.o tsc.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o core2.o core2.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o bitfield.o > bitfield.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o intel.o intel.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o nehalem.o nehalem.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o dunnington.o > dunnington.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o tulsa.o tulsa.c > cc -c -g -Os -Wall -Wextra -Wno-missing-field-initializers > -Wno-unused-parameter -Wstrict-prototypes -Wformat-security > -Wmissing-declarations -Wdeclaration-after-statement -o config.o config.c > config.c:135: error: static declaration of 'getline' follows non-static > declaration > /usr/include/stdio.h:370: error: previous declaration of 'getline' was here > gmake: *** [config.o] Error 1 > A local getline() needs the FreeBSD version check. %%% --- config.c.olg2011-02-18 14:57:52.0 +0300 +++ config.c2011-02-18 15:07:59.0 +0300 @@ -18,6 +18,9 @@ Author: Andi Kleen */ #define _GNU_SOURCE 1 +#ifdef __FreeBSD__ +# include +#endif #include #include #include @@ -126,7 +129,7 @@ return s; } -#ifdef __FreeBSD__ +#if (defined __FreeBSD__) && (__FreeBSD_version < 800067) /* * Newer versions do have getline(), so this should use a version test * at some point. %%% -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
spontaneous reboot - ptrace
> First, do you have a console output during the run ? Is it possible > that machine paniced ? If not, were there any kernel messages before> > reboot ? > > Second, what is the process you are dumping ? Can you show at least > the procstat -v output for the process ? Sorry for this late response but my earlier response appears to have been consumed by the email reflector. I'm getting an NMI. And the trouble appears to be when trying to read via ptrace memory segments of type KVME_TYPE_DEVICE. The app in quesion allocates a large number of large memory buffers and maps them into virtual address space. Not all segments cause the NMI however. Small sampling of the virtual memory map. PID STARTEND PRT RES PRES REF SHD FL TP PATH 931 0x40 0x1773000 r-x 4239 5053 2 1 CN vn /mnt/dia g/problemchild 931 0x1872000 0x2ef2000 rw- 4160 1 0 C- vn /mnt/dia g/problemchld 931 0x2ef2000 0x670 rw- 117650 1 0 C- df 9310x8018720000x8018a2000 r-x 480 57 28 CN vn /libexec /ld-elf.so.1 9310x8018a20000x8018b3000 rw- 150 1 0 C- df 9310x8018b30000x801924000 rw- 1130 1698 0 -- dv 9310x8019240000x801925000 rw-10 1698 0 -- dv 9310x8019250000x801926000 rw-10 1698 0 -- dv 9310x8019260000x801927000 rw-10 1698 0 -- dv 9310x8019270000x801928000 rw-10 1698 0 -- dv 9310x8019280000x80192a000 rw-20 1698 0 -- dv 9310x80192a0000x80192b000 rw-10 1698 0 -- dv 9310x80192b0000x80192c000 rw-10 1698 0 -- dv 9310x80192c0000x80192d000 rw-10 1698 0 -- dv 9310x80192d0000x80192e000 rw-10 1698 0 -- dv 9310x80192e0000x80193 rw-20 1698 0 -- dv 9310x801930x801932000 rw-20 1698 0 -- dv 9310x8019320000x801993000 rw- 970 1698 0 -- dv 9310x8019930000x8019a rw- 130 1698 0 -- dv 9310x8019a0x8019a1000 rw-10 1698 0 -- dv 9310x802ab70000x802bb7000 ---00 1 0 CN df 9310x0x802bb700x0x802bd6000 rw- 170 1 0 C- vn /lib/lib c.so.7 9310x802bd60000x802bf1000 rw- 180 1 0 C- df 9310x802bf10000x802bfd000 r-x9 14 2 1 CN vn /lib/lib gcc_s.so.1 9310x802bfd0000x802cfc000 ---00 1 0 CN df 9310x802cfc0000x802cfe000 rw-20 1 0 CN vn /lib/lib gcc_s.so.1 9310x802cfe0000x802cff000 rw-10 1698 0 -- dv 9310x802cff0000x802d0 rw-10 1698 0 -- dv 9310x802d00x802e0 rw- 1320 1 0 C- df 9310x802e00x802f0 rw- 1090 1 0 C- df 9310x802f00x802f91000 rw- 1450 1698 0 -- dv 9310x802f910000x802fb2000 rw- 330 1698 0 -- dv 9310x802fb20000x802fd3000 rw- 330 1698 0 -- dv 9310x802fd30000x802ff5000 rw- 340 1698 0 -- dv 9310x802ff50000x802ff6000 rw-10 1698 0 -- dv ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: spontaneous reboot - ptrace
On Fri, Feb 18, 2011 at 03:58:05AM -0800, Dr. Baud wrote: > > > > First, do you have a console output during the run ? Is it possible > > that machine paniced ? If not, were there any kernel messages before> > > reboot ? > > > > Second, what is the process you are dumping ? Can you show at least > > the procstat -v output for the process ? > > Sorry for this late response but my earlier response appears to have been > consumed by the email reflector. > > I'm getting an NMI. And the trouble appears to be when trying to > read via ptrace memory segments of type KVME_TYPE_DEVICE. The app in > quesion allocates a large number of large memory buffers and maps them > into virtual address space. Not all segments cause the NMI however. > Small sampling of the virtual memory map. You did not provided exact console output on the panic, despite requested. What is the device that was mmaped ? Obviously, this is your problem. Can you gather all required information ? > > PID STARTEND PRT RES PRES REF SHD FL TP PATH > 931 0x40 0x1773000 r-x 4239 5053 2 1 CN vn > /mnt/dia > g/problemchild > 931 0x1872000 0x2ef2000 rw- 4160 1 0 C- vn > /mnt/dia > g/problemchld > 931 0x2ef2000 0x670 rw- 117650 1 0 C- df > 9310x8018720000x8018a2000 r-x 480 57 28 CN vn > /libexec > /ld-elf.so.1 > 9310x8018a20000x8018b3000 rw- 150 1 0 C- df > 9310x8018b30000x801924000 rw- 1130 1698 0 -- dv > 9310x8019240000x801925000 rw-10 1698 0 -- dv > 9310x8019250000x801926000 rw-10 1698 0 -- dv > 9310x8019260000x801927000 rw-10 1698 0 -- dv > 9310x8019270000x801928000 rw-10 1698 0 -- dv > 9310x8019280000x80192a000 rw-20 1698 0 -- dv > 9310x80192a0000x80192b000 rw-10 1698 0 -- dv > 9310x80192b0000x80192c000 rw-10 1698 0 -- dv > 9310x80192c0000x80192d000 rw-10 1698 0 -- dv > 9310x80192d0000x80192e000 rw-10 1698 0 -- dv > 9310x80192e0000x80193 rw-20 1698 0 -- dv > 9310x801930x801932000 rw-20 1698 0 -- dv > 9310x8019320000x801993000 rw- 970 1698 0 -- dv > 9310x8019930000x8019a rw- 130 1698 0 -- dv > 9310x8019a0x8019a1000 rw-10 1698 0 -- dv > > > > 9310x802ab70000x802bb7000 ---00 1 0 CN df > 9310x0x802bb700x0x802bd6000 rw- 170 1 0 C- vn > /lib/lib > c.so.7 > 9310x802bd60000x802bf1000 rw- 180 1 0 C- df > 9310x802bf10000x802bfd000 r-x9 14 2 1 CN vn > /lib/lib > gcc_s.so.1 > 9310x802bfd0000x802cfc000 ---00 1 0 CN df > 9310x802cfc0000x802cfe000 rw-20 1 0 CN vn > /lib/lib > gcc_s.so.1 > 9310x802cfe0000x802cff000 rw-10 1698 0 -- dv > 9310x802cff0000x802d0 rw-10 1698 0 -- dv > 9310x802d00x802e0 rw- 1320 1 0 C- df > 9310x802e00x802f0 rw- 1090 1 0 C- df > 9310x802f00x802f91000 rw- 1450 1698 0 -- dv > 9310x802f910000x802fb2000 rw- 330 1698 0 -- dv > 9310x802fb20000x802fd3000 rw- 330 1698 0 -- dv > 9310x802fd30000x802ff5000 rw- 340 1698 0 -- dv > 9310x802ff50000x802ff6000 rw-10 1698 0 -- dv > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" pgp5NxCNGfhpX.pgp Description: PGP signature
Re: sched_setscheduler() behaviour changed??
Sergey,
thanks for your comment - however it was my own mistake
in rt.c ...
static void setSchedPolicy( int policy )
{
struct sched_param schedParam = { 0 };
TRY(sched_getparam(0, &schedParam),-1);
switch ( policy )
{
case SCHED_RR:
case SCHED_FIFO:
schedParam.sched_priority = MAX(1,schedParam.sched_priority);
break;
default:;
}
TRY(sched_setscheduler(0,policy,&schedParam),-1);
}
...
the sched_getparam() is called in SCHED_OTHER policy, where I would get a
negative or at least acceptable prio value in FBSD 5.x and 6.x
in FBSD 8.1 I got 63 which of course gives me EPERM cause I'm out of range.
Again thanks
2011/2/18 Sergey Kandaurov
> On 17 February 2011 12:50, Mats Lindberg
> wrote:
> > All,
> > I have been using a small program /rt) that utilize the
> sched_setscheduler()
> > syscall to set the scheduling policy of a process to SCHED_RR. Been
> running
> > it FBSD 5.x and 6.x. Now when migrating to FBSD 8.1 I get EPERM back at
> me.
> > used to be able to run it like e.g.
> >> ./rt -sr -p2 -- prog
> >
> > which started in SCHED_RR policy with priority 2.
> >
> > now in FBSD 8.1 I get EPERM
> >
> > But If I do
> >> rtprio 10 ./rt -sr -p2 -- prog
> >
> > it I dont get EPERM.
> >
> > I'm always root when doing this.
> >
> > My problem is that I have customers that need to run their old 5.x 6.x
> > applications 'as is' in 8.1 whithout changing anything.
> >
>
> [just thinking aloud]
>
> Perhaps, you might have stumbled upon the change in
> sched_setscheduler() restricting permission to superuser:
>
> src/sys/posix4/p1003_1b.c#rev1.24.2.1
> MFC revision 1.27.
>Don't allow non-root user to set a scheduler policy.
>
> @@ -195,6 +195,10 @@ int sched_setscheduler(struct thread *td
>struct thread *targettd;
>struct proc *targetp;
>
> + /* Don't allow non root user to set a scheduler policy */
> + if (suser(td) != 0)
> + return (EPERM);
> +
>e = copyin(uap->param, &sched_param, sizeof(sched_param));
>if (e)
>return (e);
>
>
> --
> wbr,
> pluknet
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ichsmb - correct locking strategy?
Hi, I try to figure out locking strategy in FreeBSD and found 'ichsmb' device. There is a mutex which protects smb bus (ichsmb device). For example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is locked and a command is written to bus, then unbounded (but with timeout) sleep is done (mutex is unlocked during sleep). After sleep a word is read from bus and the mutex is unlocked. 1. If an use of the device IS NOT serialized by layers around then more calls to this function (or others) can be started or even done before the first one is finished. The mutex don't protect sms bus. 2. If an use of the device IS serialized by layers around then the mutex is useless. Moreover, I don't mension interrupt routine which uses the mutex and smb bus too. Am I right? Or did I miss something? Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Sleepable locks with priority propagation?
Hi, I deal with devices (i2c bus, flash memory), which are quite slow, i.e. some or mostly all operations on it are quite slow. One must wait for it for rather long time. Use of DELAY() is too expensive and an inactive (so called unbound) wait isn't permited with mutexes. So, no priority propagation locking primitive could be exploited. Typical simple operation (which must be locked) is following: HW_LOCK write request (fast) wait for processing (quite slow) read response (fast) HW_UNLOCK Here, use of mutex with mtx_sleep() is impossible, as mutex is unlocked during (unbound) sleep and somebody can start new operation. An response which is read after sleep could be incorrect. Well, I deal with a hardware, so all sleeps on it could be infinite. It's driver writer responsibility to ensure that all situations which can lead to infinite waits are treated correctly and can't happen. The waits (if no error happen on hardware, what must be treat anyway) could be rather long (but with known limits from specification). Long but not unbounded. I lack of a locking primitive with priority propagation on which inactive waits are permited. I'm not too much familiar with locking implementation strategy in FreeBSD, but am I one and only who needs such a lock? Or such lock is not permitted for really good reasons? Well, I know that only KASSERT in mtx_init() (mutex can't be made SLEEPABLE) and witness in mtx_sleep() (can't sleep on UNSLEEPABLE locks) quard the whole stuff. But should I hack it and use mutex as a locking primitive I need? (Of course, I will always use it with timeout.) Thanks for any response, Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ichsmb - correct locking strategy?
On Friday 18 February 2011 15:10:47 Svatopluk Kraus wrote: > Hi, > > I try to figure out locking strategy in FreeBSD and found 'ichsmb' > device. There is a mutex which protects smb bus (ichsmb device). For > example in ichsmb_readw() in sys/dev/ichsmb/ichsmb.c, the mutex is > locked and a command is written to bus, then unbounded (but with > timeout) sleep is done (mutex is unlocked during sleep). After sleep a > word is read from bus and the mutex is unlocked. > > 1. If an use of the device IS NOT serialized by layers around then > more calls to this function (or others) can be started or even done > before the first one is finished. The mutex don't protect sms bus. > > 2. If an use of the device IS serialized by layers around then the > mutex is useless. > > Moreover, I don't mension interrupt routine which uses the mutex and > smb bus too. > > Am I right? Or did I miss something? man sx ? struct sx ? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Can vm_mmap()/vm_map_remove() be called with giant held? (linuxolator dvb patches)
I have finally got back to this and did the style and vm_map_remove()
return value handling fixes, updated the patches in-place:
http://people.freebsd.org/~nox/dvb/linux-dvb.patch
(for head)
http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch
(for 8.)
On Sun, Jan 30, 2011 at 12:54:48AM +0100, Juergen Lock wrote:
> On Sat, Jan 29, 2011 at 10:51:05PM +0200, Kostik Belousov wrote:
> > On Sat, Jan 29, 2011 at 09:10:00PM +0100, Juergen Lock wrote:
> > > Hi!
> > >
> > > I was kinda hoping to be able to post a correct patch in public but
> > > getting an answer to ${Subject} seems to be more difficult than I
> > > thought... :) So, does anyone here know? copyout_map() and
> > You do not need Giant locked for vm_map* functions.
> >
> The question was more do I need to drop it first before calling them...
>
> > > copyout_unmap() are copied from ksyms_map() from sys/dev/ksyms/ksyms.c
> > > - should there maybe be global versions instead of two static copies
> > > each, and what would be good names? And giant is taken by linux_ioctl()
> > Would you make a patch for this ?
> >
> Heh if you want me to... Where should they go and are my name choices ok?
>
I haven't done this yet so people can keep patching linux.ko in-place
without having to build a new kernel too...
> > > in the same source file before calling the parts I added. So here
> > > comes the patch, it is to add support for dvb ioctls to the linuxolator
> > > as discussed on -emulation earlier in this thread:
> > >
> > >
> > > http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-January/011575.html
> > >
> > > (patch also at:
> > >
> > > http://people.freebsd.org/~nox/dvb/linux-dvb.patch
> > >
> > > and a version for 8, which is what I tested with w_scan on dvb-s2
> > > and dvb-t, and Andrew Gallatin also tested it with SageTV:
> > >
> > > http://people.freebsd.org/~nox/dvb/linux-dvb-8.patch
> > >
> > > )
> > >
> > > + /*
> > > + * Map somewhere after heap in process memory.
> > > + */
> > > + PROC_LOCK(td->td_proc);
> > > + *addr = round_page((vm_offset_t)vms->vm_daddr +
> > > + lim_max(td->td_proc, RLIMIT_DATA));
> > > + PROC_UNLOCK(td->td_proc);
> > Are you sure that this is needed ? Why not leave the address selection
> > to the VM ?
> >
> I don't know, maybe sys/dev/ksyms/ksyms.c has a reason?
How would I leave the address selection to the VM? Just trying
to initialize *addr to (vm_offset_t)NULL there caused the patch to
stop working.
Thanx, :)
Juergen
Here is the new version for head:
Index: src/sys/compat/linux/linux_ioctl.c
===
RCS file: /home/scvs/src/sys/compat/linux/linux_ioctl.c,v
retrieving revision 1.167
diff -u -p -r1.167 linux_ioctl.c
--- src/sys/compat/linux/linux_ioctl.c 30 Dec 2010 02:18:04 - 1.167
+++ src/sys/compat/linux/linux_ioctl.c 18 Feb 2011 20:10:32 -
@@ -59,6 +59,14 @@ __FBSDID("$FreeBSD: src/sys/compat/linux
#include
#include
#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
#include
#include
@@ -83,6 +91,9 @@ __FBSDID("$FreeBSD: src/sys/compat/linux
#include
#include
+#include
+#include
+
CTASSERT(LINUX_IFNAMSIZ == IFNAMSIZ);
static linux_ioctl_function_t linux_ioctl_cdrom;
@@ -97,6 +108,7 @@ static linux_ioctl_function_t linux_ioct
static linux_ioctl_function_t linux_ioctl_drm;
static linux_ioctl_function_t linux_ioctl_sg;
static linux_ioctl_function_t linux_ioctl_v4l;
+static linux_ioctl_function_t linux_ioctl_dvb;
static linux_ioctl_function_t linux_ioctl_special;
static linux_ioctl_function_t linux_ioctl_fbsd_usb;
@@ -124,6 +136,8 @@ static struct linux_ioctl_handler sg_han
{ linux_ioctl_sg, LINUX_IOCTL_SG_MIN, LINUX_IOCTL_SG_MAX };
static struct linux_ioctl_handler video_handler =
{ linux_ioctl_v4l, LINUX_IOCTL_VIDEO_MIN, LINUX_IOCTL_VIDEO_MAX };
+static struct linux_ioctl_handler dvb_handler =
+{ linux_ioctl_dvb, LINUX_IOCTL_DVB_MIN, LINUX_IOCTL_DVB_MAX };
static struct linux_ioctl_handler fbsd_usb =
{ linux_ioctl_fbsd_usb, FBSD_LUSB_MIN, FBSD_LUSB_MAX };
@@ -139,6 +153,7 @@ DATA_SET(linux_ioctl_handler_set, privat
DATA_SET(linux_ioctl_handler_set, drm_handler);
DATA_SET(linux_ioctl_handler_set, sg_handler);
DATA_SET(linux_ioctl_handler_set, video_handler);
+DATA_SET(linux_ioctl_handler_set, dvb_handler);
DATA_SET(linux_ioctl_handler_set, fbsd_usb);
struct handler_element
@@ -2989,6 +3004,255 @@ linux_ioctl_special(struct thread *td, s
}
/*
+ * Map some anonymous memory in user space of size sz, rounded up to the page
+ * boundary.
+ */
+static int
+copyout_map(struct thread *td, vm_offset_t *addr, size_t sz)
+{
+ struct vmspace *vms;
+ int error;
+ vm_size_t size;
+
+ vms = td->td_proc->p_vmspace;
+
+ /*
+* Map somewhere after heap in process memory.
+*/
+ PROC_LOCK(td->td_proc);
+ *addr = round_page((vm_offset_t)vms->vm_da
