From normalbloke at gmail.com Mon Dec 1 00:17:58 2008 From: normalbloke at gmail.com (Patrick Collins) Date: Mon Dec 1 00:18:05 2008 Subject: TS-7200 Support Message-ID: Hello FreeBSD gurus, Would someone please give me an update on where we are with FreeBSD support for the TS-7200. I own one of these things and would like to run my favourite operating system on it for a project I have been thinking about for some time. If you think it should work then a pointer to a kernel configuration file would be of great benefit. This is not a one off hobby type activity but hopefully a real project that would see quite a number of these things in an embedded system. I know Linux is quite well supported on this device but I really don't want to go this way if I can avoid it. Thanks. Patrick Collins From mike at mikebrancato.com Mon Dec 1 11:36:39 2008 From: mike at mikebrancato.com (Michael Brancato) Date: Mon Dec 1 11:36:46 2008 Subject: Support for Cortex A8 Message-ID: <4934392A.3000207@mikebrancato.com> Does FreeBSD/ARM currently work on ARMv7? I was thinking of using it on an OMAP3530. http://focus.ti.com/general/docs/gencontent.tsp?contentId=36915 Regards, -- Mike Brancato, CISSP From tinderbox at freebsd.org Tue Dec 2 01:23:42 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 01:23:54 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20081202092339.5174373039@freebsd-current.sentex.ca> TB --- 2008-12-02 09:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 09:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-12-02 09:00:00 - cleaning the object tree TB --- 2008-12-02 09:00:31 - cvsupping the source tree TB --- 2008-12-02 09:00:31 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-12-02 09:00:39 - building world TB --- 2008-12-02 09:00:39 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 09:00:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 09:00:39 - TARGET=arm TB --- 2008-12-02 09:00:39 - TARGET_ARCH=arm TB --- 2008-12-02 09:00:39 - TZ=UTC TB --- 2008-12-02 09:00:39 - __MAKE_CONF=/dev/null TB --- 2008-12-02 09:00:39 - cd /src TB --- 2008-12-02 09:00:39 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 09:00:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/gr_util.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/hexdump.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/humanize_number.c cc -O -pipe -DLIBC_SCCS -DINET6 -I/src/lib/libutil -I/src/lib/libutil/../libc/gen/ -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/lib/libutil/kinfo_getfile.c cc1: warnings being treated as errors /src/lib/libutil/kinfo_getfile.c: In function 'kinfo_getfile': /src/lib/libutil/kinfo_getfile.c:45: warning: cast increases required alignment of target type /src/lib/libutil/kinfo_getfile.c:60: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libutil. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 09:23:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 09:23:39 - ERROR: failed to build world TB --- 2008-12-02 09:23:39 - 1079.20 user 133.81 system 1418.43 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Tue Dec 2 07:01:16 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Dec 2 07:01:30 2008 Subject: [head tinderbox] failure on arm/arm Message-ID: <20081202150113.1242B73039@freebsd-current.sentex.ca> TB --- 2008-12-02 14:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 14:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2008-12-02 14:00:00 - cleaning the object tree TB --- 2008-12-02 14:00:20 - cvsupping the source tree TB --- 2008-12-02 14:00:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2008-12-02 14:00:29 - building world TB --- 2008-12-02 14:00:29 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 14:00:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 14:00:29 - TARGET=arm TB --- 2008-12-02 14:00:29 - TARGET_ARCH=arm TB --- 2008-12-02 14:00:29 - TZ=UTC TB --- 2008-12-02 14:00:29 - __MAKE_CONF=/dev/null TB --- 2008-12-02 14:00:29 - cd /src TB --- 2008-12-02 14:00:29 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 14:00:33 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 15:01:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 15:01:12 - ERROR: failed to build world TB --- 2008-12-02 15:01:12 - 2845.97 user 342.51 system 3672.18 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From gjb at semihalf.com Fri Dec 19 06:30:09 2008 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Dec 19 06:30:20 2008 Subject: Multiple virtual mappings considered harmful on ARM Message-ID: <494BAA90.7000801@semihalf.com> Hi, I've investigated lately problem with data corruption when copying big files on ARM machine. Below are my findings. 1. High level scenario. Problem occurs during copying of big files (~300MB and more). Calculated MD5 checksums for original and copied files are different. Chunks of data which get corrupted have always 32 bytes in length i.e. cache line length. 2. Root cause. The root cause of the problem is additional virtual mapping of read/write buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), cluster_wbuild(). Buffers for sequential read/write operation are concatenated and sent to device as one big buffer. Concatenation of buffers uses pmap_qenter(), which puts *additional* mapping in the KVA for physical area already mapped. For each buffer we extract pages it contains and then all the pages from all the buffers are mapped into new virtual address of new buffer. So we end up with at least two virtual addresses for each page. Such scenario on systems with virtual cache (most ARMs) leads to serious problems: we can have unflushed modified data pertaining to the same physical pages cached in separate cache blocks: data written back first (associated with virtual mapping #1) is potentially overwritten by data associated with virtual mapping #2 when its cache content is written back later, or vice versa. 3. Workaround for FFS read/write problems - avoid clustered reading/writing on ARM: # mount -o noclusterr -o noclusterw /dev/da0a /mnt/ 4. More general solution. This is the second time we indentified a problem of the same nature related to multiple virtual mapping on ARM, and are wondering about some more general solution that would prevent us from such problems (very subtle and hard to nail down) in the future. We were thinking at least about an extension to DIAGNOSTIC that would detect such attempts or so. Any other suggestions or comments welcome. From gjb at semihalf.com Fri Dec 19 06:57:00 2008 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Fri Dec 19 06:57:06 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <200812191452.mBJEqnaM040259@casselton.net> References: <200812191452.mBJEqnaM040259@casselton.net> Message-ID: <494BB647.2060807@semihalf.com> Mark Tinguely wrote: > > which version of FreeBSD (7 or -current). > It is -current. pozdrawiam, Grzesiek From tinguely at casselton.net Fri Dec 19 07:03:42 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Fri Dec 19 07:03:54 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BAA90.7000801@semihalf.com> Message-ID: <200812191452.mBJEqnaM040259@casselton.net> > I've investigated lately problem with data corruption when copying big files > on ARM machine. Below are my findings. ... which version of FreeBSD (7 or -current). --Mark Tinguely. From tinguely at casselton.net Fri Dec 19 08:11:29 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Fri Dec 19 08:11:35 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BB647.2060807@semihalf.com> Message-ID: <200812191611.mBJGBRna044291@casselton.net> Looking at the pmap code real quick, I think the original authors assumed quick kernel entries were not shared. Since they can be, we should have to add pv_entrys and the cache vac/fix process on the pmap_kenter_internal called routines too. I am still thinking the ARM code should revolve to FreeBSD style (recursive page tables, make SMP ready, etc). --Mark. From imp at bsdimp.com Fri Dec 19 08:48:47 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Dec 19 08:48:54 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BAA90.7000801@semihalf.com> References: <494BAA90.7000801@semihalf.com> Message-ID: <20081219.094732.461359941.imp@bsdimp.com> In message: <494BAA90.7000801@semihalf.com> Grzegorz Bernacki writes: : 2. Root cause. ... : So we end up with at least two virtual addresses for each page. ... : 4. More general solution. : This is the second time we indentified a problem of the same nature related to : multiple virtual mapping on ARM, and are wondering about some more general : solution that would prevent us from such problems (very subtle and hard to : nail down) in the future. We were thinking at least about an extension to : DIAGNOSTIC that would detect such attempts or so. Any other suggestions or : comments welcome. I think this is an excellent idea. MIPS will need this too, since it too suffers from the virtual aliasing problem. Warner From xcllnt at mac.com Fri Dec 19 10:30:40 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Dec 19 10:30:46 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <494BAA90.7000801@semihalf.com> References: <494BAA90.7000801@semihalf.com> Message-ID: On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > 2. Root cause. > The root cause of the problem is additional virtual mapping of read/ > write > buffers at cluster read/write (sys/kern/vfs_cluster.c, > cluster_rbuild(), > cluster_wbuild(). Buffers for sequential read/write operation are > concatenated > and sent to device as one big buffer. Concatenation of buffers uses > pmap_qenter(), which puts *additional* mapping in the KVA for > physical area > already mapped. For each buffer we extract pages it contains and > then all the > pages from all the buffers are mapped into new virtual address of > new buffer. > So we end up with at least two virtual addresses for each page. Could this also affect I-cache coherency by virtue of not flushing the D-cache properly before synchronizing the I-cache, as you mention reading? -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Fri Dec 19 10:45:52 2008 From: xcllnt at mac.com (Marcel Moolenaar) Date: Fri Dec 19 10:46:01 2008 Subject: Support for FPA float on LE ARM Message-ID: <4CEE2ADA-1827-463B-8174-C2204C05442D@mac.com> All, As mentioned before, we (read: Juniper) need support for FPA floating-point. FPA is like VFP, except that it's always stored in big-endian. For ARMEB this obviously is exactly the same as VFP, but for ARMEL this needs a tweak. See attached patch. Does this make sense? -- Marcel Moolenaar xcllnt@mac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fpa-fbsd.diff Type: application/octet-stream Size: 3399 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20081219/656c601c/fpa-fbsd.obj -------------- next part -------------- From sam at errno.com Fri Dec 19 20:14:41 2008 From: sam at errno.com (Sam Leffler) Date: Fri Dec 19 20:14:48 2008 Subject: HEADS UP: Cambria support committed Message-ID: <494C6BD7.3050708@errno.com> I just committed support for Gateworks Cambria boards (IXP435) to HEAD. This has major changes for IXP425 users so beware. I know that ARM_USE_SMALL_ALLOC is broken by this (on IXP425 at least); it will be fixed. I think the trampoline code also needs fixups to deal with PHYSADDR changing from 0x10000000 to 0. Sam From nwhitehorn at freebsd.org Sat Dec 20 07:34:05 2008 From: nwhitehorn at freebsd.org (Nathan Whitehorn) Date: Sat Dec 20 07:34:11 2008 Subject: Code review request: boards on AT91 In-Reply-To: <20EB52EA-EA95-42A4-9319-7838F0128447@semihalf.com> References: <20081125.104452.535842403.imp@bsdimp.com> <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> <492C74CE.4090808@freebsd.org> <20EB52EA-EA95-42A4-9319-7838F0128447@semihalf.com> Message-ID: <494D0C23.9050509@freebsd.org> Rafa? Jaworowski wrote: > On 2008-11-25, at 22:57, Nathan Whitehorn wrote: > >> Rafa? Jaworowski wrote: >>> On 2008-11-25, at 18:44, M. Warner Losh wrote: >>> >>> >>>> If anybody wants me to write up where I'm going with this, or answer >>>> any question, please feel free to ask. Also, comments would be nice. >>> >>> I was dreaming once about all-generic initarm() that would have >>> KOBJ-based dispatcher, but am not sure this wouldn't cause some >>> chicken-and-egg issues as some parts of the infrastructure might not >>> be available at such early stages, but didn't investigate this too >>> close, any thoughts? But anyways, even a simple scheme with common >>> logic and function ptrs, which each platform variation would >>> implement their own routines (or use generic), would improve the ARM >>> init code significantly. >> I am about to commit a patch in order to provide Open Firmware >> modularization using KOBJ (coincidentally, this should make >> supporting FDTs much easier). In order to this, I had to make KOBJ >> behave itself when invoked almost at the very beginning of the boot >> process on both PowerPC and SPARC, so you shouldn't have any trouble >> putting this in very early boot on ARM either once this hits the tree. > > Oh, very interesting news, thanks a lot -- I'll definitely look at > your code. This was revision 186347 that I finally committed yesterday. -Nathan From jmg at funkthat.com Wed Dec 24 20:17:42 2008 From: jmg at funkthat.com (John-Mark Gurney) Date: Wed Dec 24 20:17:48 2008 Subject: TS-7200 Support In-Reply-To: References: Message-ID: <20081225040622.GN34842@funkthat.com> Patrick Collins wrote this message on Mon, Dec 01, 2008 at 17:57 +1000: > Would someone please give me an update on where we are with FreeBSD > support for the TS-7200. I own one of these things and would like to > run my favourite operating system on it for a project I have been > thinking about for some time. If you think it should work then a > pointer to a kernel configuration file would be of great benefit. This > is not a one off hobby type activity but hopefully a real project that > would see quite a number of these things in an embedded system. > > I know Linux is quite well supported on this device but I really don't > want to go this way if I can avoid it. I had it netbooting and getting to multiuser mode with decent device support, though no RTC iirc... The problem I had was that I discovered an ethernet frame (that may be specific to my network) that would never be transmitted... I talked to TS and tried to file a support request w/ Cirrus Logic on the issue, but got no where trying to figure out why a DNS packet wouldn't transmit... I could boot multiuser over nfs after aborting sendmail's DNS query... see: http://people.freebsd.org/~jmg/dmesg.ts7200 Though it hasn't been integrated w/ the recent work that's happened on arm in the last couple years... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From imp at bsdimp.com Tue Dec 30 01:45:51 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Dec 30 01:45:57 2008 Subject: Fw: Cirrus EP93xx MaverickCrunch GCC 4.3.2 patches Message-ID: <20081229.184339.1791045642.imp@bsdimp.com> FYI. I've not evaluated these patches, but thought people here might be interested in them. Warner -------------- next part -------------- An embedded message was scrubbed... From: "Martin Guy" Subject: Cirrus EP93xx MaverickCrunch GCC 4.3.2 patches Date: Tue, 30 Dec 2008 01:04:14 +0000 Size: 3657 Url: http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20081230/42f37d23/attachment.eml From support at steampowered.com Tue Dec 30 06:59:17 2008 From: support at steampowered.com (Steam Support) Date: Tue Dec 30 06:59:27 2008 Subject: Steam Account Status Message-ID: <200812300639.BHV39475@rg5.comporium.net> Hello Steam user, It has been brought to our attention that multiple IP addresses are accessing your account. The Steam EULA clearly states that there is to be NO SHARING of accounts. If you believe someone has illegally accessed your account, please verify your account information here. In addition to this security breach, a possible cheating infraction may be issued for the following reason(s): VAC has detected an unknown application modifying the following game(s): ------------------------------- Counter Strike: Source ------------------------------- It is strongly recommended that you verify your account so that we can restrict the unauthorized IP addresses. Failure to react may result in your account's termination. You may verify your account at http://support.steampowered.com/verify.htm Regards, The Steam Support Team -Valve This notification has been sent to the e-mail address you provided when you created your Steam account. For information on Valve's privacy policy, please visit http://www.valvesoftware.com/privacy.htm From gjb at semihalf.com Wed Dec 31 11:18:48 2008 From: gjb at semihalf.com (Grzegorz Bernacki) Date: Wed Dec 31 11:18:54 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: References: <494BAA90.7000801@semihalf.com> Message-ID: <495B5531.8040604@semihalf.com> Marcel Moolenaar wrote: > > On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > >> 2. Root cause. >> The root cause of the problem is additional virtual mapping of read/write >> buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), >> cluster_wbuild(). Buffers for sequential read/write operation are >> concatenated >> and sent to device as one big buffer. Concatenation of buffers uses >> pmap_qenter(), which puts *additional* mapping in the KVA for physical >> area >> already mapped. For each buffer we extract pages it contains and then >> all the >> pages from all the buffers are mapped into new virtual address of new >> buffer. >> So we end up with at least two virtual addresses for each page. > > Could this also affect I-cache coherency by virtue of not > flushing the D-cache properly before synchronizing the > I-cache, as you mention reading? > I am not sure. I can't think of scenario which might lead to I-cache incoherency. Have you experienced any issues with I-cache which might be related described problem? pozdrawiam, Grzesiek From tinguely at casselton.net Wed Dec 31 14:32:18 2008 From: tinguely at casselton.net (Mark Tinguely) Date: Wed Dec 31 14:32:29 2008 Subject: Multiple virtual mappings considered harmful on ARM In-Reply-To: <495B5531.8040604@semihalf.com> Message-ID: <200812311432.mBVEWF6O047499@casselton.net> > Marcel Moolenaar wrote: > > > > On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > > > >> 2. Root cause. > >> The root cause of the problem is additional virtual mapping of read/write > >> buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), > >> cluster_wbuild(). Buffers for sequential read/write operation are > >> concatenated > >> and sent to device as one big buffer. Concatenation of buffers uses > >> pmap_qenter(), which puts *additional* mapping in the KVA for physical > >> area > >> already mapped. For each buffer we extract pages it contains and then > >> all the > >> pages from all the buffers are mapped into new virtual address of new > >> buffer. > >> So we end up with at least two virtual addresses for each page. > > > > Could this also affect I-cache coherency by virtue of not > > flushing the D-cache properly before synchronizing the > > I-cache, as you mention reading? > > > > I am not sure. I can't think of scenario which might lead to I-cache incoherency. > Have you experienced any issues with I-cache which might be related described problem? > > pozdrawiam, > Grzesiek If would be surprised for you to see an I-cache problems. pmap_qenter() writes back any managed cache pages (already under the control of a pv_entry) and then calls pmap_kenter_internal(), which tries to writeback and invalid any previously mapped pages. At the end of the pmap_qenter() the caches are clean. The problem is the new mapping is added with cache turned on, and the old mapping's page table caching is not modified either, so if either side modifies the page, there can be this caching problem. I think that the pmap_kenter_internal() should become a special kind of managed page (controlled by a pv_entry and a special flag, (I called PVF_UNMAN) that runs through the pmap_fix_cache(), so the mappings for the shared page should have the cache turned off. There are special checks The less obvious question is should PG_UNMANAGED pages be simularly managed? Or put another way, could the PG_UNMANAGED page be remapped by the I/O caching programs? My guts says yes. Doing so also forces BUS_DMA_COHERENT pages to turn off the caches on the share page. I have a crude workup of my idea, but I have to admit, I don't have the equipment to even try to compile it. There concerns about pv_entry use increase, there is lock issues, performance, and even could we cause a problem trying get a pv_entry at the wrong time, such as interrupt. Maybe the kernel pv_entrys need to come from a special pool. I have some crude ideas to flush the caches less often in the ARM11's virtual index / physical tag caches and ideas for the multicore physical index / physical tag cache. --Mark Tinguely