Re: update pms driver
Date: Tue, 30 Nov 2010 21:33:41 +0500
From: Alexandr Shadchin alexandr.shadc...@gmail.com
On Mon, Nov 29, 2010 at 10:08:22PM +, Nicholas Marriott wrote:
Well, I don't use it so I don't have strong feelings about it, but it
does work for PS/2 mice and it seems that it would be useful for anyone
using wsmoused (although there probably aren't many people).
Would it be so hard to leave it, and if it is really not needed remove
it entirely as a separate change?
Otherwise aside from the char - signed char change I mentioned the diff
is fine with me.
1) fix char - signed char
2) Returned WSMOUSEIO_SRES
--
Alexandr Shadchin
Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.14
diff -u -p -r1.14 pms.c
--- pms.c 15 Nov 2010 20:25:31 - 1.14
+++ pms.c 30 Nov 2010 16:26:20 -
@@ -52,14 +66,38 @@ struct pms_softc {/* driver status inf
#define PMS_STATE_SUSPENDED 2
int poll;
- int intelli;
int inputstate;
- u_int buttons, oldbuttons; /* mouse button status */
- signed char dx, dy;
+
+ struct pms_protocol protocol;
+
+ unsigned char packet[8];
Small, and perhaps even irrelevant nit: we tend to use 'u_char'
instead of 'unsigned char' in BSD-specific interfaces. Saves a few
bytes in the source file and is consistent with the usage of 'u_int'
in this file.
Feel free to ignore.
Reminder: friends invited you to join Select2gether.
Dear Tech, Lucia Bassano sent a request to add you as a contact on Select2gether. Just a friendly reminder to join Lucia Bassano's network, follow the link below: Join Lucia Bassano's Network Thanks, Lucia Bassano You can remove yourself from Lucia Bassano's network at any time. If you do not wish to receive this type of email from Select2gether in the future, please click here to unsubscribe. Select2gether, 555 Bryant st #444, Palo Alto, CA, 94301 [demime 1.01d removed an attachment of type image/png which had a name of logo-s2g.png] [demime 1.01d removed an attachment of type image/jpeg which had a name of avatar_216db91edbfff7e2ccae7575a88a1399.jpg]
Vacante si proprietati
Daca aveti probleme cu vizionarea acestui email dati [click aici] pentru a vizualiza varianta online! [IMAGE] [IMAGE] Newsletter 30.11.2010 [IMAGE] CaseFaraIntermediari.roUrmariti-ne pe Facebook!Urmariti-ne pe Twitter!Urmariti-ne pe Blogger! Ultimele anunturi adaugate Vezi toate anunturile [IMAGE] [IMAGE] Teren - Vasilati, Calarasi Teren - Vasilati, Calarasi 7.500 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Spatiu comercial - Vitan Mall, Bucuresti Spatiu comercial - Vitan Mall, Bucuresti negociabil VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Casa si teren aferent - Vasilati, Calarasi Casa si teren aferent - Vasilati, Calarasi 28.500 EUR VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Vila Bontas - Predeal, Brasov Vila Bontas - Predeal, Brasov negociabil VANZARE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Vila 14 camere - Foisorul de Foc Vila 14 camere - Foisorul de Foc 6.000 EUR/luna INCHIRIERE DETALII ; [IMAGE] [IMAGE] Publica si tu un anunt! [IMAGE] Stiri Imobiliare Vezi toate stirile [IMAGE] [IMAGE] Doldora Bazaar-ul lui Gica Popescu se deschide pe 2 decembrie Doldora Bazaar-ul lui Gica Popescu se deschide pe 2 decembrie Fostul fotbalist Gica Popescu inaugureazA pe 2 decembrie Doldora Bazaar, cu mai mult de o luna intarziere. Investitia nn centrul comercial se ridica la 10 milioane de euro. Initial, Gica Popescu anuntase deschiderea Doldora Bazaar pentru jumatatea lunii octombrie. Complexul are o ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Incepe constructia celui de-al 12 mall din Bucuresti, in Pajura Incepe constructia celui de-al 12 mall din Bucuresti, in Pajura Fondurile de investitii canadiene CD Capital Partners si Benevo Capital Corportation, intr-un parteneriat de tip joint-venture, au anuntat inceperea lucrarilor de demolare a fostei fabrici de textile Dacia din Bucurestii Noi, pentru a elibera terenul de 5 ha ce va fi ! utilizat pentru constructia ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Dumitru Bucsaru a inceput a treia faza din Green City, desi sta cu 250 de vile nevandute Dumitru Bucsaru a inceput a treia faza din Green City, desi sta cu 250 de vile nevandute Dezvoltatorul imobiliar Green City Construct, controlat de familia omului de afaceri Dumitru Bucsaru, acE#ionarul echipei de fotbal Unirea Urziceni, a decis sa inceapa constructia celei de-a treia faze a car! tierului de vile din comuna 1 Decembrie, chiar daca a vandut doar jumatate din locuintele ...[CITESTE TOT] [IMAGE] [IMAGE] Oferte turistice Vezi toate ofertele [IMAGE] [IMAGE] Pensiunea Coroana Reginei - Bran, Brasov Pensiunea Coroana Reginei - Bran, Brasov negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Vila Nina - Campina Pensiunea Vila Nina - Campina negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Mimi - Moieciu, Bran Pensiunea Mimi - Moieciu, Bran negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Pensiunea Ana Aria - Moieciu de Jos, Brasov Pensiunea Ana Aria - Moieciu de Jos, Brasov negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Hotel Acvila - Moieciu, Bran Hotel Acvila - Moieciu, Bran negociabil INCHIRIERE DETALII ; [IMAGE] [IMAGE] Publica si tu un anunt! Stiri economice Vezi toate stirile [IMAGE] [IMAGE] Femeile vor avea pensii mai mici decat barbatii! Afla de ce! Femeile vor avea pensii mai mici decat barbatii! Afla de ce! In incercarea de a-i face pe plac presedintelui Basescu, puterea a votat astazi in Comisia de Munca din Camera Deputatilor ca femeile se vor pensiona la 63 de ani, fata de 65 cat prevedea legea inainte de a fi retrimisa in Parlament. Ceea ce ar putea parea o prevedere favora! bila femeilor, este de ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Primaria Capitalei construieste 13 crese Primaria Capitalei construieste 13 crese Primaria Municipiului Bucuresti deruleaza un program de construire a 13 crese la standarde europene, care vor putea prelua deficitul actual de aproximativ 1.200 de locuri existent la nivelul capacitatii de cazare oferit de stat in aceasta directie, anunta AGERPRES. Primele sase crese ...[CITESTE TOT] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Tot mai multi romani doneaza sange pentru bonurile de masa pe care le primesc Tot mai multi romani doneaza sange pentru bonurile de masa pe care le primesc Tot mai multi romani se indreapta catre centrele de transfuzie pentru cele sapte bonuri de masa pe care le primesc in schimbul sangelui donat, anunta Antena3.ro In preajma sarbatorilor se formeaza adevarate cozi la centrele de tranfuzie, in judetul Gorj au donat sange aproape 450 de persoane ...[CITESTE TOT] [IMAGE] [IMAGE] Scoala romaneasca Vezi toate scolile [IMAGE] [IMAGE] Scoala Nr, 205 Scoala Nr, 205 Aleea Compozitorilor DETALII ; [IMAGE] [IMAGE] [IMAGE] [IMAGE] Gradinita Rainbow Kids Gradinita Rainbow Kids
Re: ZTE MF112 HSUPA - report and patch for usbdevs, umsm.c
j...@goblin.cx (Jonathan Gray), 2010.11.29 (Mon) 23:20 (CET): On Mon, Nov 29, 2010 at 05:25:38PM +0100, MERIGHI Marcus wrote: disclaimer: David Coppa told me to post this to tech@ so this is not a case of cross posting. bought a ZTE MF112 today for my girlfriends ms win notebook. Took the chance to test it on OpenBSD. Without the patches below the thingy attaches as umsm for a second, detaches and re-attaches as umass. After patching it attaches as umsm0, umsm1, umsm2, umsm3 and ucom0, ucom1, ucom2. does it come back as the same id? the other ZTE devices apparently come back differently. since I'm not sure what your question is aiming at I did the attach and patch dance once more and saved usbdevs -v: on a snapshot of today, ergo before patching: first: umsm0 attach port 2 addr 2: full speed, power 500 mA, config 1, ZTE WCDMA Technologies MSM(0x2000), ZTE,Incorporated(0x19d2), rev 0.00, iSerialNumber P671A2ZTED01 umsm0 detach umass0 attach: port 2 addr 2: full speed, power 500 mA, config 1, ZTE WCDMA Technologies MSM(0x0117), ZTE,Incorporated(0x19d2), rev 0.00, iSerialNumber P671A2ZTED01 after updating src to -current today and patching: umsm0 attach port 2 addr 2: full speed, power 500 mA, config 1, ZTE WCDMA Technologies MSM(0x2000), ZTE,Incorporated(0x19d2), rev 0.00, iSerialNumber P671A2ZTED01 umsm0 detach umsm0 attach port 2 addr 2: full speed, power 500 mA, config 1, ZTE WCDMA Technologies MSM(0x0117), ZTE,Incorporated(0x19d2), rev 0.00, iSerialNumber P671A2ZTED01 ucom0 attach umsm1 attach ucom1 attach umsm2 attach ucom2 attach umsm3 attach bye, marcus
apmd action scripts
Hi tech@ !
A couple of times now I didn't notice when my laptop battery reached the 0%
remaining capacity. I am not aware of any tool in base that could issue
a beep or nice sound in case of critical battery.
Currently, apmd reports battery and power events to syslog.
Below is a patch to let apmd report battery state, battery life and
power state as parameters to an action script (/etc/apm/powerchange).
This makes the powerup and powerdown scripts obsolete.
I also included my powerchange script as an example.
Any feedback is welcome.
Holger
;-se
Index: apmd.8
===
RCS file: /cvs/src/usr.sbin/apmd/apmd.8,v
retrieving revision 1.43
diff -u -r1.43 apmd.8
--- apmd.8 28 Oct 2010 18:21:20 - 1.43
+++ apmd.8 1 Dec 2010 21:55:38 -
@@ -153,32 +153,29 @@
in the requested state after running the configuration script and
flushing the buffer cache.
.Pp
-Actions can be configured for the following five transitions:
+Actions can be configured for the following four transitions:
suspend,
standby,
resume,
-powerup,
and
-powerdown.
+powerchange.
The suspend and standby actions are run prior to
.Nm
performing any other actions (such as disk syncs) and entering the new
state.
-The resume program is run after resuming from a stand-by or
-suspended state.
-The powerup and powerdown programs are run after the power status (AC
-connected or not) changes, as well as after a resume (if the power
-status changed in the mean time).
+The resume action is run after resuming from a stand-by or suspended state.
+The powerchange action is run after a change of the power status (AC
+connected or not) or the battery status (remaining capacity),
+as well as after a resume (if the power status changed in the mean time).
.Sh FILES
-.Bl -tag -width /etc/apm/powerdownXX -compact
+.Bl -tag -width /etc/apm/powerchangeXX -compact
.It /dev/apmctl
Default device used to control the APM kernel driver.
.Pp
.It /etc/apm/suspend
.It /etc/apm/standby
.It /etc/apm/resume
-.It /etc/apm/powerup
-.It /etc/apm/powerdown
+.It /etc/apm/powerchange
These files contain the host's customized actions.
Each file must be an executable binary or shell script.
A single program or script can be used to control all transitions
@@ -187,9 +184,13 @@
suspend,
standby,
resume,
-powerup,
or
-powerdown.
+powerchange.
+.Nm
+passes three arguments (numeric values) to the powerchange script:
+the battery state (0=high, 1=low, 2=critical, 4=abscent),
+remaining battery life (0-100 in %)
+and power state (0=AC disconnected, 1=AC connected).
.Pp
.It /var/run/apmdev
Default
Index: apmd.c
===
RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.56
diff -u -r1.56 apmd.c
--- apmd.c 2 Apr 2010 04:12:46 - 1.56
+++ apmd.c 1 Dec 2010 21:55:38 -
@@ -81,7 +81,7 @@
void stand_by(int ctl_fd);
void setperf(int new_perf);
void sigexit(int signo);
-void do_etc_file(const char *file);
+void do_etc_file(const char *file, struct apm_power_info *pinfo);
void sockunlink(void);
/* ARGSUSED */
@@ -472,7 +472,7 @@
void
suspend(int ctl_fd)
{
- do_etc_file(_PATH_APM_ETC_SUSPEND);
+ do_etc_file(_PATH_APM_ETC_SUSPEND,NULL);
sync();
sleep(1);
ioctl(ctl_fd, APM_IOC_SUSPEND, 0);
@@ -481,7 +481,7 @@
void
stand_by(int ctl_fd)
{
- do_etc_file(_PATH_APM_ETC_STANDBY);
+ do_etc_file(_PATH_APM_ETC_STANDBY,NULL);
sync();
sleep(1);
ioctl(ctl_fd, APM_IOC_STANDBY, 0);
@@ -495,7 +495,8 @@
const char *fname = apmdev;
int ctl_fd, sock_fd, ch, suspends, standbys, resumes;
int statonly = 0;
- int powerstatus = 0, powerbak = 0, powerchange = 0;
+ int powerstatus = 0, powerstatus_old = 0;
+ int batstatus = 0, batstatus_old = 0;
int noacsleep = 0;
struct timespec ts = {TIMO, 0}, sts = {0, 0};
struct apm_power_info pinfo;
@@ -636,11 +637,8 @@
apmtimeout = 0;
/* wakeup for timeout: take status */
- powerbak = power_status(ctl_fd, 0, pinfo);
- if (powerstatus != powerbak) {
- powerstatus = powerbak;
- powerchange = 1;
- }
+ powerstatus_old = power_status(ctl_fd, 0, pinfo);
+ batstatus_old = pinfo.battery_life;
}
if (!rv)
@@ -653,10 +651,13 @@
APM_EVENT_INDEX(ev-data));
switch (APM_EVENT_TYPE(ev-data)) {
+ case APM_BATTERY_LOW:
+ batstatus_old = pinfo.battery_life;
+ break;
case APM_SUSPEND_REQ:
case APM_USER_SUSPEND_REQ:
Re: ZTE MF112 HSUPA - report and patch for usbdevs, umsm.c, umsm.4
On 2010/12/01 22:55, MERIGHI Marcus wrote:
Without the patches below the thingy attaches as umsm for a second,
detaches and re-attaches as umass.
After patching it attaches as umsm0, umsm1, umsm2, umsm3 and ucom0,
ucom1, ucom2.
does it come back as the same id? the other ZTE devices apparently
come back differently.
since I'm not sure what your question is aiming at I did the attach
and patch dance once more and saved usbdevs -v:
on a snapshot of today, ergo before patching:
first:
umsm0 attach
port 2 addr 2: full speed, power 500 mA, config 1,
ZTE WCDMA Technologies MSM(0x2000), ZTE,Incorporated(0x19d2),
rev 0.00, iSerialNumber P671A2ZTED01
that's alright then, the ID used for the initial attach is listed in usbdevs.
Index: share/man/man4/umsm.4
===
RCS file: /cvs/src/share/man/man4/umsm.4,v
retrieving revision 1.64
diff -u -r1.64 umsm.4
--- share/man/man4/umsm.4 12 Oct 2010 21:08:08 - 1.64
+++ share/man/man4/umsm.4 1 Dec 2010 21:46:18 -
@@ -92,6 +92,7 @@
.It Li Vodafone Mobile Broadband K3765 Ta Ta USB
.It Li ZTE MF633 Ta Ta USB
.It Li ZTE MF637 Ta Ta USB
+.It Li ZTE MF112 Ta Ta USB
.El
.Pp
Devices suspected of being compatible are:
Index: sys/dev/usb/umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.68
diff -u -r1.68 umsm.c
--- sys/dev/usb/umsm.c12 Oct 2010 21:08:08 - 1.68
+++ sys/dev/usb/umsm.c1 Dec 2010 21:46:59 -
@@ -159,6 +159,7 @@
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_K3565Z }, 0},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF633 }, 0},
{{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF637 }, 0},
+ {{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF112 }, DEV_UMASS4},
{{ USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_EXPRESSCARD }, 0},
{{ USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_MERLINV620 }, 0},
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.528
diff -u -r1.528 usbdevs
--- sys/dev/usb/usbdevs 30 Nov 2010 00:52:07 - 1.528
+++ sys/dev/usb/usbdevs 1 Dec 2010 21:47:03 -
@@ -3080,6 +3080,7 @@
product ZTE CDMA_MSM 0x0001 CDMA Technologies MSM modem
product ZTE MF6330x0016 ZTE MF633 USUPA USB modem
product ZTE MF6370x0031 ZTE MF637 HSUPA USB modem
+product ZTE MF1120x0117 ZTE MF112 HSUPA USB modem
product ZTE K3565Z 0x0063 ZTE K3565-Z USB MSM modem
product ZTE UMASS_INSTALLER20x0103 ZTE USB MSM installer
product ZTE UMASS_INSTALLER 0x2000 ZTE USB MSM installer
within each vendor section, usbdevs is sorted by product ID,
please keep it that way. otherwise ok with me.
pci1 at pchb0 Intel 5520 Host
Hi,
We have an Supermicro MBD-X8DTH-6 mainboard here. It has an
additional PCI bus behind the pchb0 host bridge. This diff from
mikeb@ makes OpenBSD detect the pci1 bus.
bluhm
Index: arch/i386/pci/pchb.c
===
RCS file: /mount/cvsdev/cvs/openbsd/src/sys/arch/i386/pci/pchb.c,v
retrieving revision 1.85
diff -u -p -r1.85 pchb.c
--- arch/i386/pci/pchb.c31 Aug 2010 17:13:46 - 1.85
+++ arch/i386/pci/pchb.c1 Dec 2010 22:15:14 -
@@ -113,6 +113,9 @@
#define AMD64HT_LDT_SEC_BUS_NUM(reg) (((reg) 8) 0xff)
+#define I825520_HB_IOHMISCSS 0x09c
+#define I825520_HB_IOHMISCSS_DUALIOH (125)
+
struct pchb_softc {
struct device sc_dev;
@@ -300,6 +303,19 @@ pchbattach(struct device *parent, struct
}
if (pbnum != 0)
doattach = 1;
+ break;
+ case PCI_PRODUCT_INTEL_825520_HB:
+ tag = pci_make_tag(pa-pa_pc, 0, 20, 0);
+ if (pci_conf_read(pa-pa_pc, tag, I825520_HB_IOHMISCSS)
+I825520_HB_IOHMISCSS_DUALIOH) {
+ /*
+* Intel doesn't properly document a way to
+* figure out the bus number, so we hardcode
+* it for now.
+*/
+ pbnum = 0x80;
+ doattach = 1;
+ }
break;
/* RNG */
case PCI_PRODUCT_INTEL_82810_HB:
OpenBSD 4.8-current (GENERIC.MP) #2: Wed Dec 1 23:15:34 CET 2010
bl...@g711.genua.de:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (GenuineIntel 686-class) 2.94
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT
real mem = 3211845632 (3063MB)
avail mem = 3149238272 (3003MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/04/10, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
bios0: vendor American Megatrends Inc. version 1.1b date 03/04/2010
bios0: Supermicro X8DTH-i/6/iF/6F
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG SPMI OEMB HPET SSDT EINJ BERT ERST HEST
acpi0: wakeup devices NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4)
NPE7(S4) NPE8(S4) NPE9(S4) NPEA(S4) P0P1(S4) USB0(S4) USB1(S4) USB2(S4)
USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) GBE_(S4) P0P4(S4)
P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) PS2K(S1) PS2M(S1) SLPB(S4)
NPE1(S4) NPE2(S4) NPE3(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE7(S4) NPE8(S4)
NPE9(S4) NPEA(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (GenuineIntel 686-class) 2.94
GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (GenuineIntel 686-class) 2.94
GHz
cpu2:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (GenuineIntel 686-class) 2.94
GHz
cpu3:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 8, remapped to apid 1
ioapic1 at mainbus0: apid 3 pa 0xfec8a000, version 20, 24 pins
ioapic1: misconfigured as apic 9, remapped to apid 3
ioapic2 at mainbus0: apid 5 pa 0xfec9a000, version 20, 24 pins
ioapic2: misconfigured as apic 10, remapped to apid 5
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (NPE1)
acpiprt2 at acpi0: bus -1 (NPE2)
acpiprt3 at acpi0: bus 2 (NPE3)
acpiprt4 at acpi0: bus -1 (NPE4)
acpiprt5 at acpi0: bus 3 (NPE5)
acpiprt6 at acpi0: bus -1 (NPE6)
acpiprt7 at acpi0: bus 4 (NPE7)
acpiprt8 at acpi0: bus -1 (NPE8)
acpiprt9 at acpi0: bus 5 (NPE9)
acpiprt10 at acpi0: bus -1 (NPEA)
acpiprt11 at acpi0: bus 6 (P0P1)
acpiprt12 at acpi0: bus -1 (P0P4)
acpiprt13 at acpi0: bus -1 (P0P5)
acpiprt14 at acpi0: bus -1 (P0P6)
acpiprt15 at acpi0: bus -1 (P0P7)
acpiprt16 at
recv buffer scaling doesn't work
here is the patch i have ended up using since the removal of the tcp sysctls. if something doesn't change, 4.9 will be an embarrassingly bad regression in network performance. at least with prevous releases, bumping the recvspace was an available workaround to sucky performance, but now the speedometer is permanently fixed at balls. i have tried fiddling with the tp-rfbuf_cnt so-so_rcv.sb_hiwat / 8 * 7 formula to no avail. my test link is ~6Mbit with ping times varying between 100 and 500ms. so basically, i get my piddly 16K, tick tock, tick tock, and then the counter is reset to 0 again. i can never get more than about 100K/s speeds, even after *hours* of downloading over the same connection. performance improves to close to 600K/s with patch, which is about as good as it gets. i know we aren't going to just crank the recvbuf to the max, so the patch is really just for show, but at the very least, please bring back some level of user control over recvbuf size. [the bump to autorcvbuf_inc doesn't do much, i know, that's left over from trying recvbuf smaller than the max]. Index: tcp_usrreq.c === RCS file: /home/tedu/cvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.105 diff -u -r1.105 tcp_usrreq.c --- tcp_usrreq.c10 Oct 2010 22:02:50 - 1.105 +++ tcp_usrreq.c2 Dec 2010 01:18:28 - @@ -112,14 +112,14 @@ extern struct baddynamicports baddynamicports; #ifndef TCP_SENDSPACE -#defineTCP_SENDSPACE 1024*16 +#defineTCP_SENDSPACE 1024*64 #endif u_int tcp_sendspace = TCP_SENDSPACE; #ifndef TCP_RECVSPACE -#defineTCP_RECVSPACE 1024*16 +#defineTCP_RECVSPACE 1024*256 #endif u_int tcp_recvspace = TCP_RECVSPACE; -u_int tcp_autorcvbuf_inc = 16 * 1024; +u_int tcp_autorcvbuf_inc = 64 * 1024; int *tcpctl_vars[TCPCTL_MAXID] = TCPCTL_VARS;
Re: recv buffer scaling doesn't work
On Wed, Dec 1, 2010 at 10:22 PM, Ben Aitchison b...@plain.co.nz wrote: In my own tests, when I got apalling speeds like that I discovered that the remote connection had timestamps turned off. not the problem here. I'm not sure why you're trying to both raise the starting point as well as the increment speed. As the normal cap is at 256k anyway. So it can't increment anywhere. that was just a left over. What I've been running with for a while is starting at 48k and raising by 32k increments. Which doesn't appear to be too bad internationally, and isn't quite as bad when timestamps aren't available. yeah I found bumping to 64k made a big difference too, but for my desktop, i have basically infinite memory, so there's little point trying to find the right number. i went to 256k just to measure the difference. but this isn't a long term fix. starting at 16k is ok, as long as we can get the window bigger. That said, you realise you can still set the socket buffer size in an application - like squid, and relayd both support built in hard coding of socket buffer size. for a server, maybe i'd do so. but i'm not going around patching all the client shit on my desktop (rebuild firefox!?) just for this.
maxdsiz tweaking (fwd)
reminder that i tested this and it works responses are more helpful than
yo this is awesome responses. :)
-- Forwarded message --
Date: Sun, 28 Nov 2010 18:51:45 -0500 (EST)
From: Ted Unangst ted.unan...@gmail.com
To: tech@openbsd.org
Subject: maxdsiz tweaking
What follows is a somewhat older mail I had forgotten about. It's
suddenly become more interesting to be because I was playing around with
jruby which requires a big heap size. It pisses me off to own a 3GB
laptop and only be able to use 1GB of that memory.
This does 2.5 things.
1. If uvm_mmap fails to find memory in the normal mmap area, go back
again and look for memory somewhere else (brk). We only do this after
failure, to preserve the brk space as long as possible.
2. Distinguish the two meanings of MAXDSIZ. Use BRKSIZ in more places (I
think this technically fixes a bug on vax) and add it to i386.
2.5. Up i386 MAXDSIZ to 2G.
End effect: You can fsck a much larger filesystem now. This doesn't
change memory layout or allocation policy for any existing program, but
will let you throw more memory at programs that don't currently run.
Index: arch/i386/include/vmparam.h
===
RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v
retrieving revision 1.43
diff -u -r1.43 vmparam.h
--- arch/i386/include/vmparam.h 16 Jun 2009 16:42:41 - 1.43
+++ arch/i386/include/vmparam.h 30 Jun 2010 02:17:34 -
@@ -63,7 +63,10 @@
#defineDFLDSIZ (64*1024*1024) /* initial data size
limit */
#endif
#ifndef MAXDSIZ
-#defineMAXDSIZ (1024*1024*1024)/* max data size */
+#defineMAXDSIZ (2U*1024*1024*1024 - 4096) /* max data
size */
+#endif
+#ifndef BRKSIZ
+#define BRKSIZ (1024*1024*1024)
#endif
#ifndefDFLSSIZ
#defineDFLSSIZ (4*1024*1024) /* initial stack size
limit */
Index: compat/svr4/svr4_misc.c
===
RCS file: /cvs/src/sys/compat/svr4/svr4_misc.c,v
retrieving revision 1.54
diff -u -r1.54 svr4_misc.c
--- compat/svr4/svr4_misc.c 25 May 2010 16:39:15 - 1.54
+++ compat/svr4/svr4_misc.c 30 Jun 2010 02:17:35 -
@@ -370,7 +370,7 @@
SCARG(mm, addr) = SCARG(uap, addr);
SCARG(mm, pos) = SCARG(uap, pos);
- rp = (void *) round_page((vaddr_t)p-p_vmspace-vm_daddr + MAXDSIZ);
+ rp = (void *) round_page((vaddr_t)p-p_vmspace-vm_daddr + BRKSIZ);
if ((SCARG(mm, flags) MAP_FIXED) == 0
SCARG(mm, addr) != 0 SCARG(mm, addr) rp)
SCARG(mm, addr) = rp;
@@ -404,7 +404,7 @@
SCARG(mm, addr) = SCARG(uap, addr);
SCARG(mm, pos) = SCARG(uap, pos);
- rp = (void *) round_page((vaddr_t)p-p_vmspace-vm_daddr + MAXDSIZ);
+ rp = (void *) round_page((vaddr_t)p-p_vmspace-vm_daddr + BRKSIZ);
if ((SCARG(mm, flags) MAP_FIXED) == 0
SCARG(mm, addr) != 0 SCARG(mm, addr) rp)
SCARG(mm, addr) = rp;
Index: dev/pci/drm/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915_drv.c,v
retrieving revision 1.86
diff -u -r1.86 i915_drv.c
--- dev/pci/drm/i915_drv.c 12 Jun 2010 16:51:36 - 1.86
+++ dev/pci/drm/i915_drv.c 30 Jun 2010 02:17:35 -
@@ -1307,7 +1307,7 @@
* We give our reference from object_lookup to the mmap, so only
* must free it in the case that the map fails.
*/
- addr = uvm_map_hint(curproc, VM_PROT_READ | VM_PROT_WRITE);
+ addr = uvm_map_hint(curproc, VM_PROT_READ | VM_PROT_WRITE, 0);
ret = uvm_map_p(curproc-p_vmspace-vm_map, addr, nsize, obj-uobj,
offset, 0, UVM_MAPFLAG(UVM_PROT_RW, UVM_PROT_RW,
UVM_INH_SHARE, UVM_ADV_RANDOM, 0), curproc);
Index: kern/exec_elf.c
===
RCS file: /cvs/src/sys/kern/exec_elf.c,v
retrieving revision 1.74
diff -u -r1.74 exec_elf.c
--- kern/exec_elf.c 29 Jun 2010 00:28:14 - 1.74
+++ kern/exec_elf.c 30 Jun 2010 02:17:35 -
@@ -391,7 +391,7 @@
* would (i.e. something safely out of the way).
*/
if (pos == ELFDEFNNAME(NO_ADDR)) {
- pos = uvm_map_hint(p, VM_PROT_EXECUTE);
+ pos = uvm_map_hint(p, VM_PROT_EXECUTE, 0);
}
pos = ELF_ROUND(pos, file_align);
Index: kern/kern_exec.c
===
RCS file: /cvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.112
diff -u -r1.112 kern_exec.c
--- kern/kern_exec.c18 May 2010 22:26:10 - 1.112
+++ kern/kern_exec.c30 Jun 2010 02:17:35 -
@@ -804,7 +804,7 @@
}
/* Just a hint to uvm_mmap where to put it. */
- p-p_sigcode = uvm_map_hint(p, VM_PROT_READ|VM_PROT_EXECUTE);
+ p-p_sigcode = uvm_map_hint(p,
Re: recv buffer scaling doesn't work
cc:ing as I don't know if I can actually post to tech@ In my own tests, when I got apalling speeds like that I discovered that the remote connection had timestamps turned off. I'm not sure why you're trying to both raise the starting point as well as the increment speed. As the normal cap is at 256k anyway. So it can't increment anywhere. What I've been running with for a while is starting at 48k and raising by 32k increments. Which doesn't appear to be too bad internationally, and isn't quite as bad when timestamps aren't available. I've also been running with the maximum boosted. It's only recently I looked at the sender side stuff. And I struggled to understand quite how it worked. To my mind having the default raised to 32768 at least makes sense. I want to look into things further myself, but I haven't got a seperate development environment setup yet. What I've been thinking about is that sometimes you want to increase the window size faster, and smoetimes slower. Depending on available bandwidth. But I never thought about any way for that. Like if I know a connection can do 30 megabit internationally with 200 msec ping. Then the window would need to be 6 megabits to fill the link if it was a single connection. But in the real world often there'll be 20+ connections so then window size would not want to be nearly that big. That said, you realise you can still set the socket buffer size in an application - like squid, and relayd both support built in hard coding of socket buffer size. My current pet peeve is that if you bounce a connection that came in with timestamps turned off, then you're initiating another connection with timestamps on then you can end up with one 1448 data packet, then one 12 byte data packet in quick sucession. Ben. On Wed, Dec 01, 2010 at 08:45:35PM -0500, Ted Unangst wrote: here is the patch i have ended up using since the removal of the tcp sysctls. if something doesn't change, 4.9 will be an embarrassingly bad regression in network performance. at least with prevous releases, bumping the recvspace was an available workaround to sucky performance, but now the speedometer is permanently fixed at balls. i have tried fiddling with the tp-rfbuf_cnt so-so_rcv.sb_hiwat / 8 * 7 formula to no avail. my test link is ~6Mbit with ping times varying between 100 and 500ms. so basically, i get my piddly 16K, tick tock, tick tock, and then the counter is reset to 0 again. i can never get more than about 100K/s speeds, even after *hours* of downloading over the same connection. performance improves to close to 600K/s with patch, which is about as good as it gets. i know we aren't going to just crank the recvbuf to the max, so the patch is really just for show, but at the very least, please bring back some level of user control over recvbuf size. [the bump to autorcvbuf_inc doesn't do much, i know, that's left over from trying recvbuf smaller than the max]. Index: tcp_usrreq.c === RCS file: /home/tedu/cvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.105 diff -u -r1.105 tcp_usrreq.c --- tcp_usrreq.c 10 Oct 2010 22:02:50 - 1.105 +++ tcp_usrreq.c 2 Dec 2010 01:18:28 - @@ -112,14 +112,14 @@ extern struct baddynamicports baddynamicports; #ifndef TCP_SENDSPACE -#define TCP_SENDSPACE 1024*16 +#define TCP_SENDSPACE 1024*64 #endif u_inttcp_sendspace = TCP_SENDSPACE; #ifndef TCP_RECVSPACE -#define TCP_RECVSPACE 1024*16 +#define TCP_RECVSPACE 1024*256 #endif u_inttcp_recvspace = TCP_RECVSPACE; -u_inttcp_autorcvbuf_inc = 16 * 1024; +u_inttcp_autorcvbuf_inc = 64 * 1024; int *tcpctl_vars[TCPCTL_MAXID] = TCPCTL_VARS;
Re: better matching of boot devices on amd64
i386 doesn't have this bug?
the boot loader passes a variable that identifies the disk its
booting off made up of a bunch of fields like adapter, controller,
disk, and partition offsets, plus a table of all the disks it can
see which includes this id and a checksum.
the kernel goes through and checksums the disks and then maps that
back to the id associated with that disk, and then compares some
of the fields in those ids against the boot disks id to figure out
which disk its on.
the problem is we overflow one of those fields (the disk id one).
since the other fields are set to 0 by the boot loader, this doesnt
really matter that much. however, since those fields are now
significant because of the overflow, we should compare them too.
this prevents sd16 being matched as the boot disk after sd0 on my
system with 25 disks attached.
sorry if this explanation sucks.
ok?
Index: dkcsum.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/dkcsum.c,v
retrieving revision 1.15
diff -u -p -r1.15 dkcsum.c
--- dkcsum.c 10 Dec 2008 23:41:19 - 1.15
+++ dkcsum.c 2 Dec 2010 05:08:25 -
@@ -71,10 +71,13 @@ dkcsumattach(void)
#ifdef DEBUG
printf(dkcsum: bootdev=%#x\n, bootdev);
- for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++)
- if (bdi-bios_number 0x80)
- printf(dkcsum: BIOS drive %#x checksum is %#x\n,
- bdi-bios_number, bdi-checksum);
+ for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++) {
+ if (bdi-bios_number 0x80) {
+ printf(dkcsum: BIOS drive %#x bsd_dev=%#x
+ checksum=%#x\n, bdi-bios_number, bdi-bsd_dev,
+ bdi-checksum);
+ }
+ }
#endif
pribootdev = altbootdev = 0;
@@ -180,7 +183,9 @@ dkcsumattach(void)
*/
/* B_TYPE dependent hd unit counting bootblocks */
- if ((B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
+ if ((B_ADAPTOR(bootdev) == B_ADAPTOR(hit-bsd_dev))
+ (B_CONTROLLER(bootdev) == B_CONTROLLER(hit-bsd_dev))
+ (B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
(B_UNIT(bootdev) == B_UNIT(hit-bsd_dev))) {
int type, ctrl, adap, part, unit;
Re: better matching of boot devices on amd64
it's the same code, so yes, it does.
i'll fix it and commit it if/when this diff gets oked.
dlg
On 02/12/2010, at 3:21 PM, Theo de Raadt wrote:
i386 doesn't have this bug?
the boot loader passes a variable that identifies the disk its
booting off made up of a bunch of fields like adapter, controller,
disk, and partition offsets, plus a table of all the disks it can
see which includes this id and a checksum.
the kernel goes through and checksums the disks and then maps that
back to the id associated with that disk, and then compares some
of the fields in those ids against the boot disks id to figure out
which disk its on.
the problem is we overflow one of those fields (the disk id one).
since the other fields are set to 0 by the boot loader, this doesnt
really matter that much. however, since those fields are now
significant because of the overflow, we should compare them too.
this prevents sd16 being matched as the boot disk after sd0 on my
system with 25 disks attached.
sorry if this explanation sucks.
ok?
Index: dkcsum.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/dkcsum.c,v
retrieving revision 1.15
diff -u -p -r1.15 dkcsum.c
--- dkcsum.c 10 Dec 2008 23:41:19 - 1.15
+++ dkcsum.c 2 Dec 2010 05:08:25 -
@@ -71,10 +71,13 @@ dkcsumattach(void)
#ifdef DEBUG
printf(dkcsum: bootdev=%#x\n, bootdev);
-for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++)
-if (bdi-bios_number 0x80)
-printf(dkcsum: BIOS drive %#x checksum is %#x\n,
-bdi-bios_number, bdi-checksum);
+for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++) {
+if (bdi-bios_number 0x80) {
+printf(dkcsum: BIOS drive %#x bsd_dev=%#x
+checksum=%#x\n, bdi-bios_number, bdi-bsd_dev,
+bdi-checksum);
+}
+}
#endif
pribootdev = altbootdev = 0;
@@ -180,7 +183,9 @@ dkcsumattach(void)
*/
/* B_TYPE dependent hd unit counting bootblocks */
-if ((B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
+if ((B_ADAPTOR(bootdev) == B_ADAPTOR(hit-bsd_dev))
+(B_CONTROLLER(bootdev) == B_CONTROLLER(hit-bsd_dev))
+(B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
(B_UNIT(bootdev) == B_UNIT(hit-bsd_dev))) {
int type, ctrl, adap, part, unit;
