Re: Scheduler improvements
Hi, Seems to be a bit snappier, though more thorough testing needed. Many web pages became more usable after the patch (chrome as browser) and some gains in desktop too. System is amd64 @ Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz and 4G RAM. -- cheers, Ville
Re: Scheduler improvements
log2 should probably be scrapped, since you're reinventing ffs.
Re: Scheduler improvements
On 8 October 2012 11:24, Marc Espie es...@nerim.net wrote: log2 should probably be scrapped, since you're reinventing ffs. That is actually my code, back then I failed at finding an ffs. I'll try to have a look at the code this week.
Votre tapis d'entrée personnalisé
Le tapis logo pour mon entreacute;enbsp;? C'est bien fait pour moi ! Deacute;couvrez votre tapis comme s'il existait deacute;jagrave; ! Profitez de cette offre exceptionnelle valable jusqu'au 30 octobre 2012 -nbsp;10nbsp;% sur votre commande code promo P1031 Le Tapis chineacute; 60x85 cm c'est cadeau ! nbsp; tapis d'une valeur de 50 euro; pour toute commande supeacute;rieure agrave; 300 euro; Madame, Mademoiselle, Monsieur, Pour ne plus recevoir de courriels de notre part, veuillez utiliser ce lien. Un délai de 48 heures peut être nécessaire, en raison des envois déjà programmés et en cours. Veuillez, s'il vous plaît, ne pas répondre à ce courriel. Merci à vous.
new umsm(4) device
Hi. Recently I've bought new Huawei E352 modem. I'm using it for some time without any problems. ok to commit? Index: umsm.4 === RCS file: /cvs/src/share/man/man4/umsm.4,v retrieving revision 1.81 diff -u -r1.81 umsm.4 --- umsm.4 24 May 2012 09:08:38 - 1.81 +++ umsm.4 27 Sep 2012 13:19:40 - @@ -64,6 +64,7 @@ .It Li Huawei Mobile E181 Ta USB .It Li Huawei Mobile E182 Ta USB .It Li Huawei Mobile E220 Ta USB +.It Li Huawei Mobile E352 Ta USB .It Li Huawei Mobile E510 Ta USB .It Li Huawei Mobile E1750 Ta USB .It Li Huawei Mobile E1752 Ta USB
Re: add support for elantech touchpads to pms(4)
On 05/10/12(Fri) 20:40, Stefan Sperling wrote:
On Fri, Oct 05, 2012 at 01:52:08PM +0200, Martin Pieuchot wrote:
My first impression at looking the code is that the v2 and v3 use
totally different packet formats and I don't see a real benefit of
having only one entry in the protocol table if you need to check
for the hardware version in every function.
I would suggest to use 3 different entries in the protocol table and a
enable_elantech_common() function so you can get rid of the hw_version
check and the protocol-packetsize hack for the v1.
I got the same feeling when you set the absolute mode: every version
use different magic ps2 commands with different magic values, I'm not
sure adding generic read/write functions help to understand nor save
some lines of code.
Other than that, it looks to me that the flags ELANTECH_F_HW_V1_OLD and
ELANTECH_F_PARITY_REVERSED are redundant.
All good points. And the parity flag was even wrongly defined...
New version, hopefully better. Also fixes softc-elantech memory leak
in error paths (which synaptics and alps have, too, btw.)
Works for me with version 3, other versions still untested AFAIK.
I don't have any Elantech hardware to test but I can tell you that this
version doesn't introduce any regression with my ALPS touchpad. It could
be nice to hear from other touchpad owners too ;)
+int
+pms_ioctl_elantech(struct pms_softc *sc, u_long cmd, caddr_t data, int flag,
+struct proc *p)
+{
+ struct elantech_softc *elantech = sc-elantech;
+ struct wsmouse_calibcoords *wsmc = (struct wsmouse_calibcoords *)data;
+ int wsmode;
+
+ switch (cmd) {
+ case WSMOUSEIO_GTYPE:
+ *(u_int *)data = WSMOUSE_TYPE_SYNAPTICS;
Here you may want to define a WSMOUSE_TYPE_ELANTECH, it is used in the
synaptics(4) driver to describe which features are supported by this
touchpad, see xenocara/driver/xf86-input-synaptics/src/wsconscomm.c
But if you do so, you'll obviously need to rebuild the X driver too ;)
+void
+pms_proc_elantech_v3(struct pms_softc *sc)
+{
+ const u_char debounce_pkt[] = { 0xc4, 0xff, 0xff, 0x02, 0xff, 0xff };
+ struct elantech_softc *elantech = sc-elantech;
+ u_int buttons;
+ int fingers, x, y, w, z;
+
+ /* The hardware sends this packet when in debounce state.
+ * The packet should be ignored. */
+ if (!memcmp(sc-packet, debounce_pkt, sizeof(debounce_pkt)))
+ return;
+
+ buttons = ((sc-packet[0] 0x01 ? WSMOUSE_BUTTON(1) : 0) |
+ ((sc-packet[0] 0x02) ? WSMOUSE_BUTTON(3): 0));
+ x = y = z = 0;
+ w = -1; /* corresponds to no finger, see synaptics */
+ fingers = (sc-packet[0] 0xc0) 6;
+ if (fingers == 2) {
+ /* Two-finger touch causes two packets -- a head packet
+ * and a tail packet. */
+ if ((sc-packet[0] 0x0c) == 0x04
+ (sc-packet[3] 0xfc) == 0x02) {
+ /* head packet */
+ x = ((sc-packet[1] 0x0f) 8 | sc-packet[2]);
+ y = ((sc-packet[4] 0x0f) 8 | sc-packet[5]);
+ } else if ((sc-packet[0] 0x0c) == 0x0c
+ (sc-packet[3] 0xce) == 0x0c) {
+ /* tail packet */
+ x = ((sc-packet[1] 0x0f) 8 | sc-packet[2]);
+ y = ((sc-packet[4] 0x0f) 8 | sc-packet[5]);
Is it a typo or the 'x' and 'y' calculation are the same in both cases?
+ }
+ w = 0; /* force 2 fingers in synaptics */
This isn't related to your diff, but we should add defines for
w = {-1, 0, 3, 4} because these values come from the synaptics devices.
+ } else if (fingers == 1 || fingers == 3) {
+ x = (sc-packet[1] 0x0f) 8 | sc-packet[2];
+ y = ((sc-packet[4] 0x0f) 8) | sc-packet[5];
+ w = (fingers == 3 ? 1 : 4); /* values for synaptics */
+ }
Same here for the 'x' and 'y', maybe you just need to convert the value
you call 'fingers' to the corresponding 'w' (synaptics finger value).
+void
+elantech_send_input(struct pms_softc *sc, u_int buttons, int x, int y, int z,
+int w)
+ {
+ struct elantech_softc *elantech = sc-elantech;
+ int dx, dy;
+
+ if (elantech-wsmode == WSMOUSE_NATIVE) {
+ if ((x 0 y 0) || buttons)
I think this condition is always true, or does the elantech touchpads
generate packets without position nor buttons pressed? Plus in case of
the v3 if x or y are null you explicitly force them to their previous
know position.
+/* Hardware version 1 has hard-coded axis range values.
+ * X axis range is 0 to 576, Y axis range is 0 to 384.
+ * Edge offset accounts for bezel around the touchpad. */
+#define ELANTECH_V1_EDGE_OFFSET 32
+#define ELANTECH_V1_X_MIN (0 + ELANTECH_V1_EDGE_OFFSET)
+#define ELANTECH_V1_X_MAX (576 - ELANTECH_V1_EDGE_OFFSET)
+#define
Re: Scheduler improvements
On Sat, Oct 06, 2012 at 10:38:34PM +0200, Gregor Best wrote: Hi Alexandre, [...] This change is unclear for me; AFAIU, it removes the mechanism which makes processes wake up with a priority depending on what they are blocked on. [...] Where do you see that? The code I removed/changed simply calulated the queue from which to remove `p` and removed it from there (similar for insertion). That needed to be changed to modify the RB tree used as a new runqueue. [...] For instance processes waking up from poll(2) or audio read/write won't be prioritized any longer. If so, this would hurt audio and other interactive processes but would improve cpu-intesive bloatware. [...] They weren't prioritised with the old version of this code either. AFAIU, when a process waits for an event (with tsleep(9)), it provides the priority of the event it's waiting for (eg an audio interrupt). When the event occurs, the process is put in the runnable queue calculated from the priority. This way, interactive processes (i.e. waiting for external events) are prioritized during the event processing. This mechanism ensures audio and midi are usable without having to manually tweak priorities. Furthermore, priorities changed depending on what the process is doing. The most notable exception to above rule is the poll(2) implementation, which still ignores priorities; it may need to be fixed one day, but this is not the most urgent problem hurting interactive processes. [A -- Alexandre
Re: Scheduler improvements
On Oct 8, 2012 6:33 PM, Alexandre Ratchov a...@caoua.org wrote: On Sat, Oct 06, 2012 at 10:38:34PM +0200, Gregor Best wrote: Hi Alexandre, [...] This change is unclear for me; AFAIU, it removes the mechanism which makes processes wake up with a priority depending on what they are blocked on. [...] Where do you see that? The code I removed/changed simply calulated the queue from which to remove `p` and removed it from there (similar for insertion). That needed to be changed to modify the RB tree used as a new runqueue. [...] For instance processes waking up from poll(2) or audio read/write won't be prioritized any longer. If so, this would hurt audio and other interactive processes but would improve cpu-intesive bloatware. [...] They weren't prioritised with the old version of this code either. AFAIU, when a process waits for an event (with tsleep(9)), it provides the priority of the event it's waiting for (eg an audio interrupt). When the event occurs, the process is put in the runnable queue calculated from the priority. This way, interactive processes (i.e. waiting for external events) are prioritized during the event processing. This mechanism ensures audio and midi are usable without having to manually tweak priorities. Furthermore, priorities changed depending on what the process is doing. The most notable exception to above rule is the poll(2) implementation, which still ignores priorities; it may need to be fixed one day, but this is not the most urgent problem hurting interactive processes. [A -- Alexandre Ratchov is correct, when a process sleeps you specify the priority you should have when waking up. I think george was referring to the old version of his code. The 4.4 bsd scheduler relies heavily on these priority boosts, i still didnt have a look at George's code, but an equivalent mechanism is usually needed. On cfs scheduling for example the processes forces a new delta calculation and gets a fraction proportional to all other runnables processes.
Garmin GPS reciever
OK to add this one? Index: usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.589 diff -u -r1.589 usbdevs --- usbdevs 3 Oct 2012 08:04:23 - 1.589 +++ usbdevs 8 Oct 2012 16:42:11 - @@ -1890,6 +1890,7 @@ /* Garmin International products */ product GARMIN GPSMAP60CSX 0x0003 GPSmap 60Csx product GARMIN IQUE36000x0004 Ique 3600 +product GARMIN DAKOTA200x23c0 Dakota 20 product GARMIN GPSMAP62S 0x2459 GPSmap 62s /* GCT Semiconductor products */
Re: Scheduler improvements
On Mon, Oct 08, 2012 at 06:28:53PM +0200, Alexandre Ratchov wrote: [...] AFAIU, when a process waits for an event (with tsleep(9)), it provides the priority of the event it's waiting for (eg an audio interrupt). When the event occurs, the process is put in the runnable queue calculated from the priority. This way, interactive processes (i.e. waiting for external events) are prioritized during the event processing. [...] I haven't noticed any degradation in performance with media-stuff (quite the contrary, actually), but you have a point. I'll change the deadline-calculation to also take the sleep priority into account. Thanks for the explanation :) -- Gregor Best [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Scheduler improvements
On Mon, Oct 08, 2012 at 18:43, Christiano F. Haesbaert wrote: Ratchov is correct, when a process sleeps you specify the priority you should have when waking up. I think george was referring to the old version of his code. The 4.4 bsd scheduler relies heavily on these priority boosts, i still didnt have a look at George's code, but an equivalent mechanism is usually needed. On cfs scheduling for example the processes forces a new delta calculation and gets a fraction proportional to all other runnables processes. I've wondered how effective (or more importantly, accurate) these priorities are. Maintenance has been somewhat haphazard, e.g., I have no idea when the last use of PVFS was removed, but there aren't any left except for the definition in param.h.
Re: [PATCH] Enable NTFS support on loongson
On Thu, Oct 04, 2012 at 06:29:21PM -0400, Ted Unangst wrote: On Wed, Oct 03, 2012 at 22:26, Donovan Watteau wrote: Hello, The following diff enables NTFS support on loongson. I've been using it with external drives on my Yeeloong without any problem. Honestly, I think we should just enable it everywhere. You're unlikely to stick an ntfs disk in your vax, but vnd disk images are theoretically possible. The NTFS file system support would need to work on big endian systems before that would make sense. Indeed. Does someone want to take a shot at this?
Re: acpiec madness (HP laptop people pay attention to this one) - tested on some HP Compaq platforms
That diff will not go into the tree now, for the same reason it didn't
go in two years ago.
BECAUSE IT IS WRONG.
Two years ago Marco issued a patch in order to prevent incorrect
reading acpitz on HP Compaq (or any HP laptops with acpiec madness) by
adding some delays to have data prepared to read/write.
It has been tested and works perfectly fine on some HP laptops: 6510b,
8510p/w, 8710p/w.
Please add this patch into the source tree to have it by default.
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.43
diff -u -p -r1.43 acpiec.c
--- acpiec.c8 Aug 2010 17:25:41 - 1.43
+++ acpiec.c29 Sep 2010 04:24:13 -
@@ -92,7 +92,7 @@ void
acpiec_wait(struct acpiec_softc *sc, u_int8_t mask, u_int8_t val)
{
static int acpiecnowait;
- u_int8_tstat;
+ volatile u_int8_t stat;
dnprintf(40, %s: EC wait_ns for: %b == %02x\n,
DEVNAME(sc), (int)mask,
@@ -104,8 +104,14 @@ acpiec_wait(struct acpiec_softc *sc, u_i
if (cold || (stat EC_STAT_BURST))
delay(1);
else
- tsleep(acpiecnowait, PWAIT, acpiec, 1);
+ tsleep(acpiecnowait, PWAIT, ecstat, 1);
}
+
+ /* delay to make sure the data is actually ready */
+ if (cold)
+ delay(10);
+ else
+ tsleep(acpiecnowait, PWAIT, ecout, 1);
dnprintf(40, %s: EC wait_ns, stat: %b\n, DEVNAME(sc), (int)stat,
\20\x8IGN\x7SMI\x6SCI\05BURST\04CMD\03IGN\02IBF\01OBF);
Re: Scheduler improvements
On Sun, Oct 07, 2012 at 04:04:16PM +0200, Gregor Best wrote: [...] I don't think changing the idle loop like this is ok. You want to continue checking whether the runqueue is empty in between cpu_idle_enter() and cpu_idle_leave(). [...] Fair point. I'll change that :) Your diff doesn't pass userland compiles. You're adding a dependency on tree.h in proc.h. In kernel land on amd64, that's okay, since machine/param.h will pull machine/cpu.h which pulls sys/sched.h which now pulls sys/tree.h, but it definitely doesn't fly in userland... my build crashed burned in libc... assuming that's okay (not usually a kernel guy), you can go include sys/tree.h directly in proc.h... Please, please, please, don't vanish into the woods for the next 6 months. Try splitting up your diff and working them into pieces kernel hackers can work with...
Re: Scheduler improvements
On Mon, Oct 08, 2012 at 07:42:13PM +0200, Marc Espie wrote: [...] Your diff doesn't pass userland compiles. You're adding a dependency on tree.h in proc.h. In kernel land on amd64, that's okay, since machine/param.h will pull machine/cpu.h which pulls sys/sched.h which now pulls sys/tree.h, but it definitely doesn't fly in userland... my build crashed burned in libc... assuming that's okay (not usually a kernel guy), you can go include sys/tree.h directly in proc.h... [...] I think wrapping all the things that need sys/tree.h in #ifdef KERNEL should do the trick since they don't really make sense in userland anyway. Please, please, please, don't vanish into the woods for the next 6 months. [...] Since I now have way more space time on my hands than before, that should not be an issue anymore, don't worry :) Try splitting up your diff and working them into pieces kernel hackers can work with... [...] I will. Actually, the diff is a bunch of seperate git commits on my machine, so that shouldn't be too hard to do. -- Gregor Best
