Re: better audio defaults: please test
On 2021-11-04 16:21:12, Alexandre Ratchov wrote: > The current sndiod latency (minimum time between when the program > plays something and when sound reaches Joe's ears) is too large and > makes OpenBSD unpleasant to use for telephony, games, and makes > controls of video players slugish. > > [...] > > Please try to switch you system to 40ms buffers (i.e. 1920 samples at > the default 48kHz rate), for instance either apply diff below or > simply do: > > rcctl set sndiod flags -z 480 -b 1920 > rcctl restart sndiod > > then report any significant increase of stuttering, and what > software/hardware triggers it. If you think 20ms or 30ms (i.e. 960 and > 1440 sample buffers) are better, let me know as well. > I experienced stuttering while watching YouTube videos with "-z 480 -b 1920" when pegging all CPUs to 100% (building a large port like Firefox or building a kernel). I tried doubling it to "-z 960 -b 3840" and the stuttering went away. I then tried taking the middle and set "-z 720 -b 2880" and the audio was still OK. So it seems my system can't be set as low as 480/1920 but 720/2880 or higher works. This is on a: cpu0: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz, 3890.94 MHz, 06-9e-09 in a ThinkPad T470p running on: OpenBSD 7.0-current (GENERIC.MP) #93: Sat Nov 13 18:25:45 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Hopefully this information helps. Please let me know if you require any more information. -- Bryan
Re: Stuck in Needbuf state, trying to understand (6.7)
On 2020-06-27 19:29:31, Bob Beck wrote:
>
> No.
>
> I know *exactly* what needbuf is but to attempt to diagnose what your
> problem is we need exact details. especially:
>
> 1) The configuration of your system including all the details of the
> filesystems
> you have mounted, all options used, etc.
>
> 2) The script you are using to generate the problem (Not a paraphrasing of
> what
> you think the script does) What filesystems it is using.
>
Not the OP, but this problem sounds almost exactly like the bug I
reported last year.
There is a detailed list of steps I used to reproduce the bug in
the following bug report.
https://marc.info/?l=openbsd-bugs&m=156412299418191
I was even able to bisect and identify the commit which first
caused the breakage for me.
---8<---
CVSROOT:/cvs
Module name:src
Changes by: b...@cvs.openbsd.org2019/05/08 06:40:57
Modified files:
sys/kern : vfs_bio.c vfs_biomem.c
Log message:
Modify the buffer cache to always flip recovered DMA buffers high.
This also modifies the backoff logic to only back off what is requested
and not a "mimimum" amount. Tested by me, benno@, tedu@ anda ports build
by naddy@.
ok tedu@
---8<---
However, I have since migrated away from using vnd(4)s since I was
able to find other solutions that worked for my use cases. So I
may not be able to provide much additional information other than
what is contained in the above bug report.
--
Bryan
>
>
> On Sat, Jun 27, 2020 at 08:09:18PM -0400, sven falempin wrote:
> > On Fri, Jun 26, 2020 at 7:35 PM sven falempin
> > wrote:
> >
> > >
> > >
> > > On Fri, Jun 26, 2020 at 5:22 PM Stuart Henderson
> > > wrote:
> > >
> > >> On 2020/06/26 15:30, sven falempin wrote:
> > >> > behavior confirmed on current.
> > >> >
> > >> > Once the process stalls, ( could be anything writing to the vnconfig
> > >> disk,
> > >> > cp , umount )
> > >> > a few other calls like df , or ps, etc may hang, never the same
> > >> > sp or mp kernel, reproduced on today's snapshots.
> > >>
> > >> vnconfig is used as part of "make release", many builds are done every
> > >> week using this so it's not a general problem with vnconfig.
> > >>
> > >> Can you show some commands or a script to trigger the behaviour?
> > >>
> > >
> > > the perl script use the system to call :
> > >
> > > vnconfig.
> > > mount.
> > > umount. <- saw hanged
> > > cp.<- saw hanged
> > > tar.<- saw hanged
> > > svn up.<- saw hanged
> > > and dd.
> > > newfs.
> > >
> > > really nothing fancy, only stuff writing to disk got stuck.
> > >
> > > At one point it does a chroot but it never hangs near that , most of the
> > > time it hangs before.
> > >
> > > The script has been used like 1000 times on 6.0 and maybe twice more on
> > > 6.4.
> > >
> > > I have absolutely no idea what the 'needbuf' of top is .
> > >
> > > the script hangs at random position , always writing into vnconfig.
> > >
> > > I have no idea how to reproduce outside the perl script , so maybe it is
> > > related
> > > to some devious perl stdin/stdout buffer .
> > >
> > > Nevertheless there's like a 5% chance that's the script will work( slowly
> > > )
> > >
> > > Most of the system call are inside a routine to log
> > >
> > > sub debug_system {
> > > $logger->debug('running: '.join(' ', @_));
> > > return system(@_);
> > > }
> > >
> > > so i can easily put things inside to try to understand the issue.
> > >
> > > It is really a strange behavior, and the device must be shut down
> > > electrically.
> > > Something really odd, i run syslogd on a buffer, and syslogc buffer is
> > > stuck too
> > > when the device stuck (but it supposed to be mostly already allocated
> > > memory ).
> > >
> > > It's really like the vm does not want to give anymore bucket (<- i
> > > don't know what i m talking about here,
> > > but i looks like that anything that doesn't malloc is ok , computer reply
> > > to ping , can do a few things for a while , and then complete
> > > hang )
> > >
> > > I ran the 6.7 release on a VM somewhere and another device with many perl
> > > script and they work.
> > >
> > > Only this fails 95% of the time and is VERY VERY slow when ok.
> > > compared to what i saw in /usr/src the vnconfig is big , ( forgot to copy
> > > df -h ),
> > > like 2GB
> > >
> >
> >
> > i put ktrace in front of the perl system call
> >
> > An di was able to recover a 800MB trace
> >
> > $ kdump -f ./trace.out | tail -20
> > kdump: realloc: Cannot allocate memory
> > 25955 UNKNOWN(1634890859)
> > 72466 ? CALL syscall()
> >
> >
> > could that be of some use ?
> >
> >
> > --
> > --
> > -
> > Knowing is not enough; we must apply. Willing is not enough; we must do
>
>
Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority
On 2019-06-21 17:11:26, Martin Pieuchot wrote: > On 06/06/19(Thu) 15:16, Martin Pieuchot wrote: > > On 02/06/19(Sun) 16:41, Martin Pieuchot wrote: > > > On 01/06/19(Sat) 18:55, Martin Pieuchot wrote: > > > > Diff below exists mainly for documentation and test purposes. If > > > > you're not interested about how to break the scheduler internals in > > > > pieces, don't read further and go straight to testing! > > > > > > > > - First change is to stop calling tsleep(9) at PUSER. That makes > > > > it clear that all "sleeping priorities" are smaller than PUSER. > > > > That's important to understand for the diff below. `p_priority' > > > > is currently a placeholder for the "sleeping priority" and the > > > > "runnqueue priority". Both fields are separated by this diff. > > > > > > > > - When a thread goes to sleep, the priority argument of tsleep(9) is > > > > now recorded in `p_slpprio'. This argument can be considered as part > > > > of the sleep queue. Its purpose is to place the thread into a higher > > > > runqueue when awoken. > > > > > > > > - Currently, for stopped threads, `p_priority' correspond to > > > > `p_usrpri'. > > > > So setrunnable() has been untangled to place SSTOP and SSLEEP threads > > > > in the preferred queue without having to use `p_priority'. Note that > > > > `p_usrpri' is still recalculated *after* having called setrunqueue(). > > > > This is currently fine because setrunnable() is called with > > > > SCHED_LOCK() > > > > but it will be racy when we'll split it. > > > > > > > > - A new field, `p_runprio' has been introduced. It should be considered > > > > as part of the per-CPU runqueues. It indicates where a current thread > > > > is placed. > > > > > > > > - `spc_curpriority' is now updated at every context-switch. That means > > > >need_resched() won't be called after comparing an out-of-date value. > > > >At the same time, `p_usrpri' is initialized to the highest possible > > > >value for idle threads. > > > > > > > > - resched_proc() was calling need_resched() in the following conditions: > > > >- If the SONPROC thread has a higher priority that the current > > > > running thread (itself). > > > >- Twice in setrunnable() when we know that p_priority <= p_usrpri. > > > >- If schedcpu() considered that a thread, after updating its prio, > > > > should preempt the one running on the CPU pointed by `p_cpu'. > > > > > > > > The diff below simplify all of that by calling need_resched() when: > > > >- A thread is inserted in a CPU runqueue at a higher priority than > > > > the one SONPROC. > > > >- schedcpu() decides that a thread in SRUN state should preempt the > > > > one SONPROC. > > > > > > > > - `p_estcpu' `p_usrpri' and `p_slptime' which represent the "priority" > > > > of a thread are now updated while holding a per-thread mutex. As a > > > > result schedclock() and donice() no longer takes the SCHED_LOCK(), > > > > and schedcpu() almost never take it. > > > > > > > > - With this diff top(1) and ps(1) will report the "real" `p_usrpi' value > > > > when displaying priorities. This is helpful to understand what's > > > > happening: > > > > > > > > load averages: 0.99, 0.56, 0.25 two.lab.grenadille.net > > > > 23:42:10 > > > > 70 threads: 68 idle, 2 on processor > > > > up 0:09 > > > > CPU0: 0.0% user, 0.0% nice, 51.0% sys, 2.0% spin, 0.0% intr, 47.1% > > > > idle > > > > CPU1: 2.0% user, 0.0% nice, 51.0% sys, 3.9% spin, 0.0% intr, 43.1% > > > > idle > > > > Memory: Real: 47M/1005M act/tot Free: 2937M Cache: 812M Swap: 0K/4323M > > > > > > > > PID TID PRI NICE SIZE RES STATE WAIT TIMECPU > > > > COMMAND > > > > 81000 145101 7200K 1664K sleep/1 bored 1:15 36.96% > > > > softnet > > > > 47133 244097 730 2984K 4408K sleep/1 netio 1:06 35.06% cvs > > > > 64749 522184 660 176K 148K onproc/1 - 0:55 28.81% nfsd > > > > 21615 602473 12700K 1664K sleep/0 - 7:22 0.00% > > > > idle0 > > > > 12413 606242 12700K 1664K sleep/1 - 7:08 0.00% > > > > idle1 > > > > 85778 338258 500 4936K 7308K idle select0:10 0.00% ssh > > > > > > > > 22771 575513 500 176K 148K sleep/0 nfsd 0:02 0.00% > > > > nfsd > > > > > > > > > > > > > > > > - The removal of `p_priority' and the change that makes mi_switch() > > > > always update `spc_curpriority' might introduce some changes in > > > > behavior, especially with kernel threads that were not going through > > > > tsleep(9). We currently have some situations where the priority of > > > > the running thread isn't correctly reflected. This diff changes that > > > > which means we should be able to better understand where the problems > > > > are. > > > > > > > > I'd be interested in comments/tests/r
Re: [PATCH] systat reports inaccurate statistics for disk i/o speed
On 2019-01-19 16:09:05, Ted Unangst wrote:
> Bryan Linton wrote:
> > Hello tech@,
> >
> > I'd appreciate it if someone could review both this patch and my
> > analysis.
>
> There is no reason for etime to be a global. We can make it a local with the
> correct value in the two functions that use it, avoiding future problems as
> well.
>
I can confirm that your patch fixes the error as well, and is
probably the better option since it removes a global.
Thank you for reviewing everything.
--
Bryan
> Index: vmstat.c
> ===
> RCS file: /cvs/src/usr.bin/systat/vmstat.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 vmstat.c
> --- vmstat.c 17 Nov 2018 23:10:08 - 1.89
> +++ vmstat.c 19 Jan 2019 21:06:38 -
> @@ -97,7 +97,6 @@ int select_vm(void);
> int vm_keyboard_callback(int);
>
> static time_t t;
> -static double etime;
> static float hertz;
> static int nintr;
> static long *intrloc;
> @@ -336,6 +335,7 @@ showkre(void)
> u_int64_t inttotal, intcnt;
> int i, l, c;
> static int failcnt = 0, first_run = 0;
> + double etime;
>
> if (state == TIME) {
> if (!first_run) {
> @@ -676,7 +676,9 @@ copyinfo(struct Info *from, struct Info
> static void
> dinfo(int dn, int c)
> {
> - double words, atime;
> + double words, atime, etime;
> +
> + etime = naptime;
>
> c += DISKCOL;
Re: [PATCH] systat reports inaccurate statistics for disk i/o speed
On 2019-01-19 15:00:20, Otto Moerbeek wrote: > On Sat, Jan 19, 2019 at 09:30:12PM +0900, Bryan Linton wrote: > > > Hello tech@, > > > > I'd appreciate it if someone could review both this patch and my > > analysis. > > > > [...] > > > > ADDENDUM > > > > > > I'm curious why iostat.c uses cur.dk_*[dn] directly whereas > > vmstat.c adds 0.5 to it. > > rsum += cur.dk_rbytes[dn] / etime; > > rsum is a double. When adding a double to a double, there's no > rounding or truncation going on. > > > vs. > > words = (cur.dk_rbytes[dn] + cur.dk_wbytes[dn]) / 1024.0; > > putintmk((int)(words/etime + 0.5), DISKROW + 3, c, 5); > >^^ > > When converting a double (or float) to an int, truncation happens. So > add 0.5 to turn it into rounding. > Ah, OK. I get it now. > > Also, there are several casts in lines like > > putint((int)((float)cur.dk_seek[dn]/etime+0.5), DISKROW + 1, c, 5) > > > > I understand why the value would need to be cast to an (int), > > since putint() is expecting an int, but since etime is already a > > (double), wouldn't the C language's automatic type-promotion rules > > automatically promote everything to a (double) anyway? > > Those casts are indeed unneeded, > Thank you for taking the time to explain both of these! -- Bryan
[PATCH] systat reports inaccurate statistics for disk i/o speed
Hello tech@,
I'd appreciate it if someone could review both this patch and my
analysis.
PROBLEM
---
When running systat, the vmstat page shows inaccurate numbers for
disk i/o speed (likely only on multiprocessor systems) when
compared to both the iostat page, as well as the statistics
reported by dd.
To test this, open two xterms. Run "systat" in one, and
"systat iostat" in the other. Then run something like,
"dd if=/dev/zero of=zero.deleteme bs=64k" (or anything that will
generate a lot of disk i/o).
Observe that "systat" shows a different number for the reported
i/o speed et. al., whereas "systat iostat" and pressing ^T while
dd is running both return numbers in agreement with each other.
On my 4-core system, the numbers returned by "systat" for "seeks",
"xfers", and "speed" all appear to be exactly 4-times lower than
are indicated in "systat iostat" as well as the transfer rate
reported by dd.
TENTATIVE ANALYSIS
__
(I am not an expert on OpenBSD's internals, and did not dig all
the way into the depths of the kernel, so some of this analysis is
based on conjecture).
In /usr/src/usr.bin/systat/vmstat.c on line 349, (via some
printf() debugging) the variable "etime" appears to be set to the
sum total of time elapsed on ALL CPUs in the system.
etime = 0;
for (i = 0; i < CPUSTATES; i++) {
X(cpustats.cs_time);
etime += s.cpustats.cs_time[i];
}
This causes an error in calculations later on when it is used to
calculate disk i/o statistics in vmstat.c (but not in iostat).
vmstat.c:
/* # of K transferred */
words = (cur.dk_rbytes[dn] + cur.dk_wbytes[dn]) / 1024.0;
putint((int)((float)cur.dk_seek[dn]/etime+0.5), DISKROW + 1, c, 5);
putint((int)((float)(cur.dk_rxfer[dn] + cur.dk_wxfer[dn])/etime+0.5),
DISKROW + 2, c, 5);
putintmk((int)(words/etime + 0.5), DISKROW + 3, c, 5);
putfloat(atime/etime, DISKROW + 4, c, 5, 1, 1);
Compare the above to iostat.c, where
etime = naptime;
is set on line 143 before showtotal() prints the values.
for (dn = 0; dn < cur.dk_ndrive; dn++) {
rsum += cur.dk_rbytes[dn] / etime;
wsum += cur.dk_wbytes[dn] / etime;
rtsum += cur.dk_rxfer[dn] / etime;
wtsum += cur.dk_wxfer[dn] / etime;
mssum += ATIME(cur.dk_time, dn) / etime;
}
print_fld_str(FLD_IO_DEVICE, "Totals");
print_fld_size(FLD_IO_READ, rsum);
print_fld_size(FLD_IO_WRITE, wsum);
print_fld_size(FLD_IO_RTPS, rtsum);
print_fld_size(FLD_IO_WTPS, wtsum);
print_fld_float(FLD_IO_SEC, mssum, 1);
SOLUTION
Set "etime = naptime;" in vmstat.c as well, as indicated in the
attached patch.
ADDENDUM
I'm curious why iostat.c uses cur.dk_*[dn] directly whereas
vmstat.c adds 0.5 to it.
rsum += cur.dk_rbytes[dn] / etime;
vs.
words = (cur.dk_rbytes[dn] + cur.dk_wbytes[dn]) / 1024.0;
putintmk((int)(words/etime + 0.5), DISKROW + 3, c, 5);
^^
Also, there are several casts in lines like
putint((int)((float)cur.dk_seek[dn]/etime+0.5), DISKROW + 1, c, 5)
I understand why the value would need to be cast to an (int),
since putint() is expecting an int, but since etime is already a
(double), wouldn't the C language's automatic type-promotion rules
automatically promote everything to a (double) anyway?
Casting to a (float) would only seem to reduce precision, and then
since it's immediately being cast to an (int) anyway, is the
(float) cast really necessary? Removing it seems to cause no
immediately noticeable ill effects on my system.
I would appreciate any advice or explanation anyone can give regarding
the above.
Thank you.
--
Bryan
Index: vmstat.c
===
RCS file: /cvs/src/usr.bin/systat/vmstat.c,v
retrieving revision 1.89
diff -u -r1.89 vmstat.c
--- vmstat.c17 Nov 2018 23:10:08 - 1.89
+++ vmstat.c19 Jan 2019 11:37:33 -
@@ -678,6 +678,8 @@
{
double words, atime;
+ etime = naptime;
+
c += DISKCOL;
/* time busy in disk activity */
Re: [UPDATE] FreeType 2.9.1
On 2018-05-20 14:15:47, Matthieu Herrb wrote: > On Thu, Apr 26, 2018 at 01:01:33PM +0200, David Coppa wrote: > > > > Hi all, > > > > Attached you will find an update to the latest freetype (2.9.1). > > > > ok matthieu@. > > note that the uninialized memory access with some fonts reported by > Brian Lyton is supposed to be fixed in this release (and I can't > reproduce it anymore). > > So you may want to revert the change in src/base/ftutil.c rev 1.10. > Hello, I was the original reporter of the above bug. I can confirm that everything works fine on the following snapshot: OpenBSD 6.3-current (GENERIC.MP) #44: Tue May 22 22:13:37 MDT 2018 Thank you again to all who helped resolve it. -- Bryan
Re: Looking for testers for em(4) quirks patch
On 2018-04-03 18:53:16, Bryan Linton wrote: > On 2018-04-02 11:52:08, Stefan Fritsch wrote: > > Hi, > > > > We have seen problems with em on i219V and i219LM. For example, "Hardware > > Initialization Failed" if no cable is plugged in during boot, or watchdog > > timeouts / hangs until next boot if the cable is removed while data is > > transmitted. > > > > This patch adds a bunch of quirks and fixes from freebsd. > > > > It would be nice if people could give it a try on various em(4) hardware > > to check if there are any regressions. > > > > I'm running it on an > em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi, mac_type > 0x1d phy_type 0xb > in a Thinkpad T440p with no regressions seen so far. > > I'm not sure if anything here touches the I217-LM chip or not, but > given some of the quirks in your list, I'm hoping that it might > fix this bug that I've been experiencing for a while now. > > https://marc.info/?l=openbsd-bugs&m=150441840715439&w=2 > > It can take up to a week for it to show, so I'll run with the > patch for as long as I can and report back any findings. As > stated above, I haven't seen any regressions. > > So far so good! > Alas, it didn't fix the bug I described above, but it also hasn't caused any regressions or any other issues I can see. -- Bryan
Re: Looking for testers for em(4) quirks patch
On 2018-04-02 11:52:08, Stefan Fritsch wrote: > Hi, > > We have seen problems with em on i219V and i219LM. For example, "Hardware > Initialization Failed" if no cable is plugged in during boot, or watchdog > timeouts / hangs until next boot if the cable is removed while data is > transmitted. > > This patch adds a bunch of quirks and fixes from freebsd. > > It would be nice if people could give it a try on various em(4) hardware > to check if there are any regressions. > I'm running it on an em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi, mac_type 0x1d phy_type 0xb in a Thinkpad T440p with no regressions seen so far. I'm not sure if anything here touches the I217-LM chip or not, but given some of the quirks in your list, I'm hoping that it might fix this bug that I've been experiencing for a while now. https://marc.info/?l=openbsd-bugs&m=150441840715439&w=2 It can take up to a week for it to show, so I'll run with the patch for as long as I can and report back any findings. As stated above, I haven't seen any regressions. So far so good! -- Bryan
Re: [PATCH] Fix font rendering error in FreeType 2.8.1 update, memory allocation related?
On 2018-03-11 18:03:27, Matthieu Herrb wrote: > On Sun, Mar 11, 2018 at 11:58:50AM +0900, Bryan Linton wrote: > > [I sent a copy of this email to tech@ 24 hours ago and it hasn't > > shown up yet. Apologies if this ends up being a double-post.] > > > > Hello tech@ > > > > I'm not sure if it's bad form to crosspost this from bugs@ to > > tech@ or not, but I have a patch that fixes a font rendering issue > > with the new FreeType 2.8.1 update that went in last December. > > > > The beginning of the thread can be found at the following link. > > It also includes a screenshot (linked at the very bottom of the > > page) of how it manifests in an xterm. FWIW, I also see the same > > rendering issue in Firefox, so it's not just limited to the console: > > https://marc.info/?l=openbsd-bugs&m=151835980313045&w=2 > > > > I managed to bisect things, and found that this one-line diff > > fixes the issue for me. It's a reversion back to the line of code > > that was present in FreeType 2.8.0. > > Thanks for bisecting the problem which apparently only happens for > some specific fonts since I've not been able to reproduce it with any > other font nor have I seen other reports of similar issues. > > Did you try to report it upstreams ? (in the mean time Freetype 2.9 > has been released, but without change to this code. > I have not reported this to upstream yet. I see that you have already done so in my stead though. Thank you for doing so. > Reading the commit bd28952e23bcd268a623ea5202e1cde4a92defe4 from > upstreams they seem to assume that the memory allocated by > memory->alloc() is already zeroed. The original but report is > https://savannah.nongnu.org/bugs/?51816 > > Does an explicit zeroing like in the patch below also fix the issue > for you ? > Yes, I can confirm that your patch fixes this issue for me. Thank you very much for looking into this for me. -- Bryan
[PATCH] Fix font rendering error in FreeType 2.8.1 update, memory allocation related?
[I sent a copy of this email to tech@ 24 hours ago and it hasn't
shown up yet. Apologies if this ends up being a double-post.]
Hello tech@
I'm not sure if it's bad form to crosspost this from bugs@ to
tech@ or not, but I have a patch that fixes a font rendering issue
with the new FreeType 2.8.1 update that went in last December.
The beginning of the thread can be found at the following link.
It also includes a screenshot (linked at the very bottom of the
page) of how it manifests in an xterm. FWIW, I also see the same
rendering issue in Firefox, so it's not just limited to the console:
https://marc.info/?l=openbsd-bugs&m=151835980313045&w=2
I managed to bisect things, and found that this one-line diff
fixes the issue for me. It's a reversion back to the line of code
that was present in FreeType 2.8.0.
Please let me know if I can provide any further information or
test any patches. Now that OpenBSD has entered -beta status, I'd
like to do whatever I can to help resolve this before -release is
tagged if at all possible.
Thank you.
--
Bryan
Index: ftutil.c
===
RCS file: /cvs/xenocara/lib/freetype/src/base/ftutil.c,v
retrieving revision 1.9
diff -u -r1.9 ftutil.c
--- ftutil.c15 Dec 2017 19:29:12 - 1.9
+++ ftutil.c10 Mar 2018 00:18:11 -
@@ -143,7 +143,7 @@
{
FT_ASSERT( !block );
- block = memory->alloc( memory, new_count * item_size );
+ block = ft_mem_alloc( memory, new_count * item_size, &error );
if ( block == NULL )
error = FT_THROW( Out_Of_Memory );
}
[PATCH] ratecheck.9 - Fix variable names in EXAMPLES
Hello tech@,
I noticed that the EXAMPLE in the ratecheck.9 manual page declares
the following variables:
struct timeval drv_lasterr1time; /* time of last err1 message */
struct timeval drv_lasterr2time; /* time of last err2 message */
However the code later on actually uses the following ones:
drv_lasterr1notice
drv_lasterr2notice
This patch simply matches them up again.
--
Bryan
Index: ratecheck.9
===
RCS file: /cvs/src/share/man/man9/ratecheck.9,v
retrieving revision 1.11
diff -u -r1.11 ratecheck.9
--- ratecheck.9 3 Apr 2016 06:43:59 - 1.11
+++ ratecheck.9 29 Oct 2017 07:35:16 -
@@ -106,7 +106,7 @@
...
drv_err1count++;
- if (ratecheck(&drv_lasterr1notice,
+ if (ratecheck(&drv_lasterr1time,
&drv_errinterval)) {
printf("drv: %ld err1 errors occurred",
drv_err1count);
@@ -118,7 +118,7 @@
...
drv_err2count++;
- if (ratecheck(&drv_lasterr2notice,
+ if (ratecheck(&drv_lasterr2time,
&drv_errinterval)) {
printf("drv: %ld err2 errors occurred",
drv_err2count);
Re: [PATCH] intel_uncore.c - Horrible, ugly hack to avoid dmesg spam
On 2017-10-29 06:40:35, Miod Vallat wrote:
> > The patch below simply stops printing additional messages after 10
> > lines have been printed.
> >
>
> You might want to use ratecheck(9) rather than a simple limit.
>
Done. Thanks for the tip!
--
Bryan
Index: intel_uncore.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_uncore.c,v
retrieving revision 1.5
diff -u -r1.5 intel_uncore.c
--- intel_uncore.c 3 Sep 2017 13:38:58 - 1.5
+++ intel_uncore.c 29 Oct 2017 07:48:38 -
@@ -21,6 +21,8 @@
* IN THE SOFTWARE.
*/
+#include
+
#include "i915_drv.h"
#include "intel_drv.h"
#include "i915_vgpu.h"
@@ -51,6 +53,14 @@
"media",
};
+/*
+* The following globals are for rate-limiting the error message in
+* the intel_uncore_check_errors() function.
+*/
+struct timeval intel_uncore_lasterrtime;
+long intel_uncore_errcount;
+static struct timeval intel_uncore_errinterval = { 5, 0 }; /* 5 seconds */
+
const char *
intel_uncore_forcewake_domain_to_str(const enum forcewake_domain_id id)
{
@@ -1567,7 +1577,12 @@
if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
(__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM)) {
- DRM_ERROR("Unclaimed register before interrupt\n");
+ intel_uncore_errcount++;
+ if (ratecheck(&intel_uncore_lasterrtime,
+ &intel_uncore_errinterval)) {
+ DRM_ERROR("Unclaimed register before interrupt\n");
+ intel_uncore_errcount=0;
+ }
__raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
}
}
[PATCH] intel_uncore.c - Horrible, ugly hack to avoid dmesg spam
Hello tech@
First, I want to say that I'm in no way advocating that this patch
be committed to the tree. I'm sending it solely for the others
who have encountered the same issue I have. It's only purpose is
to suppress dmesg spam on boot and thereby speed up booting by
10-15 seconds, as well as to not flush out potentially important
information from the dmesg buffer.
This patch is ugly, hackish, and (poorly) paints over the underlying
problem. It may cause headaches and nausea in certain
individuals.
In brief, on boot, the system prints out a tremendous amount of
variations of the following error:
error: [drm:pid3322:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
This has been reported to occur on a Thinkpad T440p, Thinkpad T440s,
Dell M3800, and a Toshiba Portege R30-A.
The system otherwise works fine, so it doesn't appear that
whatever is causing the messages to print has any other
deleterious effects on the system.
Enough lines are printed out to completely fill the dmesg buffer
as such:
% dmesg | sort -n | uniq -c
6 error: [drm:pid22060:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
209 error: [drm:pid25769:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
3 error: [drm:pid25817:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
44 error: [drm:pid30074:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
402 error: [drm:pid3322:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
28 error: [drm:pid33672:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
5 error: [drm:pid39271:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
2 error: [drm:pid40435:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
2 error: [drm:pid5194:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
12 error: [drm:pid92159:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
1 pid92159:intel_uncore_check_errors] *ERROR* Unclaimed register before
interrupt
The patch below simply stops printing additional messages after 10
lines have been printed.
--
Bryan
Index: intel_uncore.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_uncore.c,v
retrieving revision 1.5
diff -u -r1.5 intel_uncore.c
--- intel_uncore.c 3 Sep 2017 13:38:58 - 1.5
+++ intel_uncore.c 14 Oct 2017 04:05:20 -
@@ -1565,9 +1565,17 @@
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ static long i =0;
+
if (HAS_FPGA_DBG_UNCLAIMED(dev) &&
(__raw_i915_read32(dev_priv, FPGA_DBG) & FPGA_DBG_RM_NOCLAIM)) {
- DRM_ERROR("Unclaimed register before interrupt\n");
+ if (i < 10)
+ DRM_ERROR("Unclaimed register before interrupt\n");
+ if (i == 10)
+ DRM_ERROR("Suspending printing of more unclaimed"
+ " register errors.\n");
+
__raw_i915_write32(dev_priv, FPGA_DBG, FPGA_DBG_RM_NOCLAIM);
+ i++;
}
}
[PATCH] Fix likely typo in if_iwm.c
I spotted what looks to be a typo in if_iwm.c given the context in
which it occurs. Patch attached. Apologies if I'm mistaken.
--
Bryan
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.211
diff -u -r1.211 if_iwm.c
--- if_iwm.c13 Aug 2017 18:08:03 - 1.211
+++ if_iwm.c23 Aug 2017 12:43:19 -
@@ -5643,7 +5643,7 @@
err = iwm_power_update_device(sc);
if (err) {
- printf("%s: could send power command (error %d)\n",
+ printf("%s: could not send power command (error %d)\n",
DEVNAME(sc), err);
return err;
}
@@ -6313,7 +6313,7 @@
err = iwm_power_update_device(sc);
if (err) {
- printf("%s: could send power command (error %d)\n",
+ printf("%s: could not send power command (error %d)\n",
DEVNAME(sc), err);
goto err;
}
Re: inteldrm(4) diff needs review and testing
On 2017-07-16 15:19:41, Mark Kettenis wrote: > Can somebody test the following diff on Ivy Bridge or Haswell (Intel > HD Graphics 2500/4000/4600/4700/5000/5100/5200)? > > When I added support for the command parser, I took a bit of a > shortcut and implemented the hash tables as a single linked list. > This diff fixes that. > > For the hash function I used a "mode (size-1)" approach that leaves > one of the hash table entries unused. Perhaps somebody with a CS > background has a better idea that isn't too complicated to implement? > I haven't noticed any regressions or other negative effects due to this patch on an HD 4600 in a Thinkpad T440p. One thing that may be worth mentioning, is that after the recent update to the DRM code, I get a lot of dmesg spam in the form of error: [drm:pid37898:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt after booting the system. They are present with and without your patch, so it must be due to a separate issue. They don't seem to be causing any negative effects (everything seems to be working just fine). After booting, the system sits for about 15-20 seconds printing these errors to the console as fast as the system can print them. After it's done, everything works normally so at least for me, it seems to be mostly a cosmetic issue. However, I'm not sure if it may be pointing to something that may affect other users. Both an actual dmesg and output from running "dmesg" are attached. As one can see, there are at least enough lines output to completely scroll the initial system dmesg out of the buffer. --- /var/run/dmesg.boot --- OpenBSD 6.1-current (GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS) #15: Mon Jul 17 02:21:03 JST 2017 shoshon...@shoshoni-m.shoshoni.info:/usr/src/sys/arch/amd64/compile/GENERIC.MP-PPPOE_TERM_UNKNOWN_SESSIONS real mem = 12539871232 (11958MB) avail mem = 12154036224 (11590MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbcc0d000 (67 entries) bios0: vendor LENOVO version "GLET85WW (2.39 )" date 09/29/2016 bios0: LENOVO 20AWS27D00 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA UEFI MSDM ASF! BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2594.38 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2594384360 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2593.99 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2593.99 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz, 2593.99 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20,
[PATCH] Clean up obsolete information in gettimeofday.2
Is this worth deleting now that struct timezone *tzp is no longer
used?
I was originally going to send a small diff changing only the line
that read, "If tp or tzp is NULL, the associated time information
will not be returned or set" since gettimeofday(&tv, NULL) works
exactly as one would expect.
I thought that it might be worth pruning this now, but if it's
still worth keeping the information around, I don't have strong
objection against keeping it either.
--
Bryan
Index: gettimeofday.2
===
RCS file: /cvs/src/lib/libc/sys/gettimeofday.2,v
retrieving revision 1.29
diff -u -r1.29 gettimeofday.2
--- gettimeofday.2 10 Sep 2015 17:55:21 - 1.29
+++ gettimeofday.2 29 Apr 2017 14:00:07 -
@@ -61,18 +61,14 @@
.Dq ticks .
If
.Fa tp
-or
-.Fa tzp
is
.Dv NULL ,
the associated time
information will not be returned or set.
.Pp
-The structures pointed to by
+The structure pointed to by
.Fa tp
-and
-.Fa tzp
-are defined in
+is defined in
.In sys/time.h
as:
.Bd -literal
@@ -80,20 +76,7 @@
time_t tv_sec; /* seconds since Jan. 1, 1970 */
suseconds_t tv_usec;/* and microseconds */
};
-
-struct timezone {
- int tz_minuteswest; /* of Greenwich */
- int tz_dsttime; /* type of dst correction to apply */
-};
.Ed
-.Pp
-The
-.Fa timezone
-structure indicates the local time zone
-(measured in minutes of time westward from Greenwich),
-and a flag that, if nonzero, indicates that
-Daylight Saving time applies locally during
-the appropriate part of the year.
.Pp
Only the superuser may set the time of day or time zone.
If the system securelevel is greater than 1 (see
Re: vmmap speed increase diff
On 2012-03-23 21:50:29, Ariane van der Steldt wrote: > Hi, > > With the recent introduction of vmmap, I introduced a slowdown which > affects programs with alot of memory (browsers for instance). First of > all, since I've heard very few complaints, thanks for putting up with > this. > > The reason for this e-mail is, that I have a diff. This diff should > make the new vmmap as fast as the old vmmap for large programs. If you > were hit by the slowdown or would like to test, please use the diff > below and let me know if there are any problems. > No problems so far on i386. This diff makes a world of difference in web browsers and ports/games/wesnoth which can eat up to 700 MB of RAM and usually hovers between 300 and 500 MB. Thanks for coming up with a fix so quickly. -- Bryan
Re: VIA EHCI controller workaround needs testing.
On 2009-06-30 06:26:48, Bryan Linton wrote:
> On 2009-06-29 22:08:00, Dale Rahn wrote:
> > On Mon, Jun 29, 2009 at 03:46:35PM -0400, Brad wrote:
> > > The following diff adds a workaround for an issue with the VIA VT6202
> > > EHCI controller hogging the PCI bus and causing poor performance for
> > > IDE and possibly other devices in the system.
> > >
> > > Please test if your system has a VIA VT6202 EHCI controller and
> > > provide a dmesg. If the workaround is being applied for the
> > > chipset you have then a message will be printed (this is temporary
> > > only to verify it is being applied for the appropriate revision
> > > of the chipset).
> > >
> > >
> > > >From Linux
> > >
> > >
> >
> > I tried out this patch, and found that the appropriate revision chip
> > is found in the thecus 2100 system (armish port). Initial testing showed
> > no performance difference.
> >
> > However, I looked at the diff more closely and found that it was wrong,
> > the original linux code would read/write one byte, however the OpenBSD
> > interface does word (32bit) reads and writes, howeve this register is
> > then misaligned.
> >
> > After changing the code to do 32 bit accesses and to set the correct bit
> > in the little endian 32 bit register, the system saw a signficant
> > performance
> > difference. dd if=/dev/zero of=file bs=1m saw a 10% speedup, and ftp
> > a file from the local network saw a 7% speedup.
> >
> > Arm has a smaller cache that other systems, so may be affected by a
> > busy memory bus more than other platforms.
> >
>
> I didn't see any change in running "dd if=/dev/zero of=file bs=1m" before
> or after the patch on an i386 system so your suspicions may be correct.
>
> No regresions or negative behavior seen yet.
>
>
> OpenBSD 4.6-beta (SHOSHONI) #24: Tue Jun 30 06:08:30 PDT 2009
> r...@shoshoni.shoshoni.info:/usr/src/sys/arch/i386/compile/SHOSHONI
> [...]
> ehci0 at pci0 dev 13 function 2 "VIA VT6202 USB" rev 0x63, applying VIA
> VT6202 workaround: irq 10
> [...]
>
Just a quick update.
I've been using this patch for about 3 weeks now and have not seen any
problems whatsoever.
ehci0 at pci0 dev 13 function 2 "VIA VT6202 USB" rev 0x63, applying VIA VT6202
workaround: irq 10
New dmesg just in case.
OpenBSD 4.6-current (SHOSHONI) #25: Thu Jul 23 05:34:25 PDT 2009
r...@shoshoni.shoshoni.info:/usr/src/sys/arch/i386/compile/SHOSHONI
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2 cache) 1.01
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 804786176 (767MB)
avail mem = 768827392 (733MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/23/02, BIOS32 rev. 0 @ 0xf0f80, SMBIOS
rev. 2.3 @ 0xf2940 (49 entries)
bios0: vendor Award Software, Inc. version "ASUS A7V ACPI BIOS Revision 1011"
date 04/23/2002
bios0: ASUSTeK Computer INC.
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1802
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1750/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:04:0 ("VIA VT82C686 ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xf400 0xd/0x4000!
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA VT8363 Host" rev 0x02
viaagp0 at pchb0: v2
agp0 at viaagp0: aperture at 0xe000, size 0x1000
ppb0 at pci0 dev 1 function 0 "VIA VT8363 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon X1300/X1550" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: irq 11
drm0 at radeondrm0
"ATI Radeon X1300/X1550 Sec" rev 0x00 at pci1 dev 0 function 1 not configured
pcib0 at pci0 dev 4 function 0 "VIA VT82C686 ISA" rev 0x22
pciide0 at pci0 dev 4 function 1 "VIA VT82C571 IDE" rev 0x10: ATA66, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 194481MB, 398297088 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom
removable
atapiscsi1 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi1: 2
Re: re(4) diff that needs testing
On 2009-07-22 23:18:18, Mark Kettenis wrote:
> This diff switches re(4) over to MCLGETI, bringing goodies like lower
> memory usage and livelock mitigation. Getting this right usually
> takes some effort. So please help me with getting this tested if you
> have any machines with re(4).
>
> Thanks,
>
> Mark
>
Been running it for a day with no problems.
re0 at pci0 dev 11 function 0 "Realtek 8169" rev 0x10: RTL8110S (0x0400), irq
10, address 00:e0:4c:77:5a:88
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0
OpenBSD 4.6-current (SHOSHONI) #25: Thu Jul 23 05:34:25 PDT 2009
r...@shoshoni.shoshoni.info:/usr/src/sys/arch/i386/compile/SHOSHONI
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2 cache) 1.01
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 804786176 (767MB)
avail mem = 768827392 (733MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/23/02, BIOS32 rev. 0 @ 0xf0f80, SMBIOS
rev. 2.3 @ 0xf2940 (49 entries)
bios0: vendor Award Software, Inc. version "ASUS A7V ACPI BIOS Revision 1011"
date 04/23/2002
bios0: ASUSTeK Computer INC.
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1802
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1750/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:04:0 ("VIA VT82C686 ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xf400 0xd/0x4000!
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA VT8363 Host" rev 0x02
viaagp0 at pchb0: v2
agp0 at viaagp0: aperture at 0xe000, size 0x1000
ppb0 at pci0 dev 1 function 0 "VIA VT8363 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon X1300/X1550" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: irq 11
drm0 at radeondrm0
"ATI Radeon X1300/X1550 Sec" rev 0x00 at pci1 dev 0 function 1 not configured
pcib0 at pci0 dev 4 function 0 "VIA VT82C686 ISA" rev 0x22
pciide0 at pci0 dev 4 function 1 "VIA VT82C571 IDE" rev 0x10: ATA66, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 194481MB, 398297088 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom
removable
atapiscsi1 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi1: 2 targets
cd1 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 4 function 2 "VIA VT83C572 USB" rev 0x10: irq 9
uhci1 at pci0 dev 4 function 3 "VIA VT83C572 USB" rev 0x10: irq 9
viaenv0 at pci0 dev 4 function 4 "VIA VT82C686 SMBus" rev 0x30: HWM disabled:
24-bit timer at 3579545Hz
rl0 at pci0 dev 9 function 0 "Accton MPX 5030/5038" rev 0x10: irq 9, address
00:e0:29:6b:73:e3
rlphy0 at rl0 phy 0: RTL internal PHY
emu0 at pci0 dev 10 function 0 "Creative Labs SoundBlaster Live" rev 0x07: irq 5
ac97: codec id 0x54524123 (TriTech Microelectronics TR28602)
audio0 at emu0
"Creative Labs PCI Gameport Joystick" rev 0x07 at pci0 dev 10 function 1 not
configured
re0 at pci0 dev 11 function 0 "Realtek 8169" rev 0x10: RTL8110S (0x0400), irq
10, address 00:e0:4c:77:5a:88
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0
sili0 at pci0 dev 12 function 0 "CMD Technology SiI3124 SATA" rev 0x02: irq 11
scsibus2 at sili0: 4 targets
sd0 at scsibus2 targ 3 lun 0: SCSI3 0/direct fixed
sd0: 715404MB, 512 bytes/sec, 1465149168 sec total
uhci2 at pci0 dev 13 function 0 "VIA VT83C572 USB" rev 0x61: irq 9
uhci3 at pci0 dev 13 function 1 "VIA VT83C572 USB" rev 0x61: irq 11
ehci0 at pci0 dev 13 function 2 "VIA VT6202 USB" rev 0x63, applying VIA VT6202
workaround: irq 10
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "VIA EHCI root hub" rev 2.00/1.00 addr 1
pciide1 at pci0 dev 17 function 0 "Promise PDC20265" rev 0x02: DMA, channel 0
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using irq 10 for native-PCI interrupt
pciide1: channel 0 disabled (no drives)
pciide1: channel 1 disabled (no drives)
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
spkr0 at pcppi0
lpt0 at isa0 port
Re: VIA EHCI controller workaround needs testing.
On 2009-06-29 22:08:00, Dale Rahn wrote:
> On Mon, Jun 29, 2009 at 03:46:35PM -0400, Brad wrote:
> > The following diff adds a workaround for an issue with the VIA VT6202
> > EHCI controller hogging the PCI bus and causing poor performance for
> > IDE and possibly other devices in the system.
> >
> > Please test if your system has a VIA VT6202 EHCI controller and
> > provide a dmesg. If the workaround is being applied for the
> > chipset you have then a message will be printed (this is temporary
> > only to verify it is being applied for the appropriate revision
> > of the chipset).
> >
> >
> > >From Linux
> >
> >
>
> I tried out this patch, and found that the appropriate revision chip
> is found in the thecus 2100 system (armish port). Initial testing showed
> no performance difference.
>
> However, I looked at the diff more closely and found that it was wrong,
> the original linux code would read/write one byte, however the OpenBSD
> interface does word (32bit) reads and writes, howeve this register is
> then misaligned.
>
> After changing the code to do 32 bit accesses and to set the correct bit
> in the little endian 32 bit register, the system saw a signficant performance
> difference. dd if=/dev/zero of=file bs=1m saw a 10% speedup, and ftp
> a file from the local network saw a 7% speedup.
>
> Arm has a smaller cache that other systems, so may be affected by a
> busy memory bus more than other platforms.
>
I didn't see any change in running "dd if=/dev/zero of=file bs=1m" before
or after the patch on an i386 system so your suspicions may be correct.
No regresions or negative behavior seen yet.
OpenBSD 4.6-beta (SHOSHONI) #24: Tue Jun 30 06:08:30 PDT 2009
r...@shoshoni.shoshoni.info:/usr/src/sys/arch/i386/compile/SHOSHONI
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2 cache) 1.01
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 804786176 (767MB)
avail mem = 768831488 (733MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 04/23/02, BIOS32 rev. 0 @ 0xf0f80, SMBIOS
rev. 2.3 @ 0xf2940 (49 entries)
bios0: vendor Award Software, Inc. version "ASUS A7V ACPI BIOS Revision 1011"
date 04/23/2002
bios0: ASUSTeK Computer INC.
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0x1802
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1750/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:04:0 ("VIA VT82C686 ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0xf400 0xd/0x4000!
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "VIA VT8363 Host" rev 0x02
viaagp0 at pchb0: v2
agp0 at viaagp0: aperture at 0xe000, size 0x1000
ppb0 at pci0 dev 1 function 0 "VIA VT8363 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon X1300/X1550" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: irq 11
drm0 at radeondrm0
"ATI Radeon X1300/X1550 Sec" rev 0x00 at pci1 dev 0 function 1 not configured
pcib0 at pci0 dev 4 function 0 "VIA VT82C686 ISA" rev 0x22
pciide0 at pci0 dev 4 function 1 "VIA VT82C571 IDE" rev 0x10: ATA66, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 194481MB, 398297088 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom
removable
atapiscsi1 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi1: 2 targets
cd1 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 4 function 2 "VIA VT83C572 USB" rev 0x10: irq 9
uhci1 at pci0 dev 4 function 3 "VIA VT83C572 USB" rev 0x10: irq 9
viaenv0 at pci0 dev 4 function 4 "VIA VT82C686 SMBus" rev 0x30: HWM disabled:
24-bit timer at 3579545Hz
rl0 at pci0 dev 9 function 0 "Accton MPX 5030/5038" rev 0x10: irq 9, address
00:e0:29:6b:73:e3
rlphy0 at rl0 phy 0: RTL internal PHY
emu0 at pci0 dev 10 function 0 "Creative Labs SoundBlaster Live" rev 0x07: irq 5
ac97: codec id 0x54524123 (TriTech Microelectronics TR28602)
audio0 at emu0
"Creative Labs PCI Gameport Joystick" rev 0x07 at pci0 dev 10 function 1 not
configured
re0 at pci0 dev 11 function 0 "Realtek 8169" rev 0x10: RTL8169S (0x0400), irq
10, address 00:e0:4c:77:5a:88
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0
sili0 at pci0 dev 12 function 0 "CMD Technology SiI3124 SATA" rev 0x02: irq 11
scsibus2 at sili0: 4 targets
sd0 at scsibus2
Re: New snapshots -> new installer
On 2009-05-06 15:21:44, Theo de Raadt wrote: > The newest snapshots that are headed out have a new install script based > on heavy modifications by a bunch of developers over the last 3 weeks. > > We would like to start getting feedback from people about these changes. > This is a really small nit, but when the install or upgrade script asks "Choose your keyboard type if it is nationalized" if you type in 6 characters and then hit backspace the screen displays "1234_6" where the underscore is the cursor. If you press backspace again it displays "123_ 6" etc. If you press enter when "1234_6" is displayed the error message says "kbd: unknown encoding 12345" so it seems to only be a display problem. Also, if you type in 7 or more characters (so it wraps to a new line) and press backspace to the beginning of the line, the cursor does not wrap back to the previous line. Like before, it still deletes the characters, as evidenced from what the kbd error message displays. Other than that I think the new installer is awesome. Thanks to all the people that made it happen.
