Re: Fan mode management in acpithinkpad(4)
On 14 May 2011 c. 02:38:32 Owain Ainsworth wrote:
No actual comment on the diff right now, but please spell
``disengaged'' correctly.
Fixed version, including man page update purpose, is below.
--
Best wishes,
Vadim Zhukov
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Index: sys/dev/acpi/acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.26
diff -u -p -r1.26 acpithinkpad.c
--- sys/dev/acpi/acpithinkpad.c 27 Apr 2011 20:55:42 - 1.26
+++ sys/dev/acpi/acpithinkpad.c 14 May 2011 06:43:22 -
@@ -71,11 +71,21 @@
#defineTHINKPAD_POWER_CHANGED 0x6030
#defineTHINKPAD_SWITCH_WIRELESS0x7000
-#define THINKPAD_NSENSORS 9
-#define THINKPAD_NTEMPSENSORS 8
+#define THINKPAD_NSENSORS 10
+#define THINKPAD_NTEMPSENSORS 8
+
+#define THINKPAD_SENSOR_FANRPM (THINKPAD_NTEMPSENSORS + 0)
+#define THINKPAD_SENSOR_FANMODE(THINKPAD_NTEMPSENSORS + 1)
#define THINKPAD_ECOFFSET_FANLO0x84
#define THINKPAD_ECOFFSET_FANHI0x85
+#define THINKPAD_ECOFFSET_FANMODE 0x2f
+
+#define THINKPAD_FANMODE_AUTO 0x80
+#define THINKPAD_FANMODE_DISENGAGED0x40
+
+/* critical temperature mark, in Celsius */
+#define THINKPAD_TEMP_OUCH 80
struct acpithinkpad_softc {
struct devicesc_dev;
@@ -103,7 +113,7 @@ int thinkpad_volume_mute(struct acpithin
intthinkpad_brightness_up(struct acpithinkpad_softc *);
intthinkpad_brightness_down(struct acpithinkpad_softc *);
-voidthinkpad_sensor_attach(struct acpithinkpad_softc *sc);
+voidthinkpad_sensor_attach(struct acpithinkpad_softc *);
voidthinkpad_sensor_refresh(void *);
struct cfattach acpithinkpad_ca = {
@@ -156,8 +166,12 @@ thinkpad_sensor_attach(struct acpithinkp
}
/* Add fan probe */
- sc-sc_sens[i].type = SENSOR_FANRPM;
- sensor_attach(sc-sc_sensdev, sc-sc_sens[i]);
+ sc-sc_sens[THINKPAD_SENSOR_FANRPM].type = SENSOR_FANRPM;
+ sensor_attach(sc-sc_sensdev, sc-sc_sens[THINKPAD_SENSOR_FANRPM]);
+
+ /* Add fan mode indicator */
+ sc-sc_sens[THINKPAD_SENSOR_FANMODE].type = SENSOR_INTEGER;
+ sensor_attach(sc-sc_sensdev, sc-sc_sens[THINKPAD_SENSOR_FANMODE]);
sensordev_install(sc-sc_sensdev);
}
@@ -166,9 +180,11 @@ void
thinkpad_sensor_refresh(void *arg)
{
struct acpithinkpad_softc *sc = arg;
- u_int8_t lo, hi, i;
- int64_t tmp;
+ u_int8_t lo, hi, i, mode;
+ int64_t tmp, maxtmp = -127;/* minimal correct value, see below */
+ enum sensor_status ss;
char sname[5];
+ const char *desc;
/* Refresh sensor readings */
for (i=0; iTHINKPAD_NTEMPSENSORS; i++) {
@@ -176,14 +192,41 @@ thinkpad_sensor_refresh(void *arg)
aml_evalinteger(sc-sc_acpi, sc-sc_ec-sc_devnode,
sname, 0, 0, tmp);
sc-sc_sens[i].value = (tmp * 100) + 27315;
- if (tmp 127 || tmp -127)
+ if (tmp 127 || tmp -127) {
sc-sc_sens[i].flags = SENSOR_FINVALID;
+ sc-sc_sens[i].status = SENSOR_S_UNKNOWN;
+ }
+ if ((sc-sc_sens[i].flags SENSOR_FINVALID) == SENSOR_FINVALID)
+ continue;
+ if (tmp maxtmp)
+ maxtmp = tmp;
+ if (tmp THINKPAD_TEMP_OUCH)
+ sc-sc_sens[i].status = SENSOR_S_CRIT;
+ else
+ sc-sc_sens[i].status = SENSOR_S_OK;
}
/* Read fan RPM */
acpiec_read(sc-sc_ec, THINKPAD_ECOFFSET_FANLO, 1, lo);
acpiec_read(sc-sc_ec, THINKPAD_ECOFFSET_FANHI, 1, hi);
- sc-sc_sens[i].value = ((hi 8L) + lo);
+ sc-sc_sens[THINKPAD_SENSOR_FANRPM].value = ((hi 8L) + lo);
+
+ /* Update fan mode based on max temperature seen */
+ if (maxtmp THINKPAD_TEMP_OUCH) {
+ mode = THINKPAD_FANMODE_DISENGAGED;
+ desc = disengaged;
+ ss = SENSOR_S_CRIT;
+ } else {
+ mode = THINKPAD_FANMODE_AUTO;
+ desc = auto;
+ ss = SENSOR_S_OK;
+ }
+ acpiec_write(sc-sc_ec, THINKPAD_ECOFFSET_FANMODE, 1, mode);
+ sc-sc_sens[THINKPAD_SENSOR_FANMODE].value = mode;
+ sc-sc_sens[THINKPAD_SENSOR_FANMODE].status = ss;
+ snprintf(sc-sc_sens[THINKPAD_SENSOR_FANMODE].desc,
+ sizeof(sc-sc_sens[THINKPAD_SENSOR_FANMODE]),
+ fan mode: %s, desc);
}
void
Index: share/man/man4/acpithinkpad.4
===
RCS file: /cvs/src/share/man/man4/acpithinkpad.4,v
retrieving revision 1.2
diff -u -p -r1.2 acpithinkpad.4
---
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
List: openbsd-tech Subject:impact of unaligned partitions/slices on 4kB sector drives (wd10ears) From: Robert robert () openbsd ! pap ! st Date: 2010-01-06 22:54:34 Message-ID: 20100106235434.55963d32 () openbsd ! pap ! st Hello, i did some measurements on the impact that unaligned partitions/slices have on the new harddrives that use ondisk 4kB sectors and export them as 512B sectors. [1] My tests were done on a Western Digital WD10EARS. [2] CONCLUSION: Having unaligned partition/slices on those disks leads to noticable performance penalty under realworld workloads. IMPLICATIONS: 1. The rounding of unit sizes to cylinder boundaries by disklabel has to be evaluated. 2. A FAQ entry for the advanced format disks is needed to tell people to set the XP jumper. (more on that later) If disklabel is not modified, that entry would also have to explain the alignement implications and how to use a calculator. TEST RESULTS: - sequential write/read speeds --- dd bs | aligned | unaligned | wd10eads* | | | 4k write | 97433116 | 86349673 | 80762241 (bytes/sec) 64k w | 101273894 | 85616298 | 81234814 1m w | 98291974 | 79201231 | 83113302 | | | 4k read | 103706513 | 104434701 | 82723667 64k r | 105136468 | 104453140 | 85552816 1m r | 104228605 | 104921901 | 85650289 (* wd10eads is the previous generation to the wd10ears with 32mb cache and usual 512B ondisk sectors. Disk is in a different system! That system is not idle so actual numbers might be higher.) - extracting a source tree --- aligned : 6m26.31s unaligned : 14m30.30s - build kernel / make obj / make build --- | aligned | unaligned kernel | 2m27.94s | 2m48.12s make obj | 0m28.51s | 1m01.41s make build | 36m07.27s | 70m51.58s EXPLANAITIONS (or whatever :): Those numbers are kinda scary. I would not have expected such bad results for the builds from my earlier sequential rw tests i sent to misc@. (Just to make it clear, if the partition/slices are not aligned, the disk has to read every 4k sector it wants to write to, before it can actually do that. The 64MB of cache help to elevate that up to some point.) This drive has a XP legacy jumper. (Same as WD15EARS and WD20EARS.) It is intended to be used for Windows XP systems with a single partition over the whole drive. XP uses the same 63 sector offset as OpenBSD does. Setting this jumper, transparently alignes the 63 sectors infront of a 4k sector boundary. When that jumper is set, slices inside the partition only have to be multiples of 8 big. The issue is with disklables rounding down to the nearest cylinder boundary. This will mess up the nice multiplication by 1024, which would lead to a size divisable by 8. The rounding down is always done when using units, but not when requesting a size without a unit/in sectors. So slices can be aligned that way by hand. That rounding to cylinders is not needed, afaik. So without that, a simple rtfaq! set the damn jumper! would be enough, to get the best performance out of such harddisks. Below you can find more info about my test setup and the test outputs. Cheers, - Robert [1] http://www.wdc.com/advformat [2] http://www.wdc.com/en/products/products.asp?driveidv3 TESTS: aligned == XP jumper set unaligned == XP jumper NOT set* (* without the jumper, the partition/slices are off by one 512B sector.) I installed a snapshot i had on hand (see dmesg) and went from there. (Fresh installl without the jumper.) Source-tree used is -current from some hours ago. I sync'ed before every test. disk layout and ramdisk was the same in both scenarios. - dmesg --- OpenBSD 4.6-current (GENERIC.MP) #40: Tue Dec 29 01:02:20 MST 2009 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3488088064 (3326MB) avail mem = 3388391424 (3231MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0730 (61 entries) bios0: vendor American Megatrends Inc. version 1104 date 09/11/2009 bios0: ASUSTeK Computer INC. P5QL-E acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC MCFG OEMB HPET OSFR acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) UAR1(S4) PS2K(S4) PS2M(S4) EUSB(S4) \ USBE(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) GBEC(S4) USB0(S4) USB1(S4) \ use rev 1.10/21.00 addr 2 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 modifier keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 vscsi0 at root scsibus4 at vscsi0: 256 targets softraid0 at root root on sd0a swap on sd0b dump on sd0b (( fwiw, jacob: that azalia is just disabled. the iic0 should be an asus ai booster. still have to modify the live driver for that soundblaster 5.1 vx. )) - fdisk --- Disk: sd0 geometry: 121601/255/63 [1953525168
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 03:43:23AM -0500, Abel Abraham Camarillo Ojeda wrote: (( If you read this far, have a cookie and wonder with me about that quick extraction... The system this drive is in has the same board, but everything else is slower and not idle when meassured...)) I'm starting to get angry about the _horrible_ performance on this drive (WD10EARS-00Y), some developer ever got a chance to see something about this? 4.8 and newer should install on the disk fine (when reinitialzing the disk), respecting 4k boundaries. Alas, if your disk has been installed using an older version, the boundaries probably won't align. Updating won't be enough because it keep the old mbr and disklabel. -Otto The original message is at: http://marc.info/?l=openbsd-techm=126281899324219w=2 (I wasn't subscribed to this list back then) Thanks. OpenBSD 4.9-current (kobj) #0: Sun May 1 14:32:33 CDT 2011 root@maetel.00z:/usr/kobj real mem = 1608056832 (1533MB) avail mem = 1551196160 (1479MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfd400 (50 entries) bios0: vendor American Megatrends Inc. version V1.3 date 11/15/2010 bios0: MSI MS-7623 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PSKE(S4) PSMS(S4) ECIR(S4) PS2K(S3) PS2M(S3) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X4 955 Processor, 3200.77 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Phenom(tm) II X4 955 Processor, 3200.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE2) acpiprt3 at acpi0: bus -1 (PCE3) acpiprt4 at acpi0: bus -1 (PCE4) acpiprt5 at acpi0: bus 2 (PCE5) acpiprt6 at acpi0: bus -1 (PCE6) acpiprt7 at acpi0: bus -1 (PCE7) acpiprt8 at acpi0: bus -1 (PCE9) acpiprt9 at acpi0: bus -1 (PCEA) acpiprt10 at acpi0: bus -1 (PCEB) acpiprt11 at acpi0: bus -1 (PCEC) acpiprt12 at acpi0: bus 3 (P0PC) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpicpu2 at acpi0: PSS acpicpu3 at acpi0: PSS acpibtn0 at acpi0: PWRB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD RS780 Host rev 0x00 ppb0 at pci0 dev 1 function 0 AMD RS780 PCIE rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 5 function 0 vendor ATI, unknown product 0x9616 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at pci0 dev 5 function 0 AMD RS780 PCIE rev 0x00: apic 4 int 17 pci2 at ppb1 bus 2 alc0 at pci2 dev 0 function 0 Attansic Technology
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On 14/05/2011, at 6:43 PM, Abel Abraham Camarillo Ojeda wrote: I'm starting to get angry about the _horrible_ performance on this drive (WD10EARS-00Y), some developer ever got a chance to see something about this? don't get angry, it's just a disk. we changed the default alignment of partitions on all disks to mitigate this problem. the only issue you may have with a default install on one of these drives is a small fragment size on the ffs partitions. i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. huggz, dlg The original message is at: http://marc.info/?l=openbsd-techm=126281899324219w=2 (I wasn't subscribed to this list back then) Thanks. OpenBSD 4.9-current (kobj) #0: Sun May 1 14:32:33 CDT 2011 root@maetel.00z:/usr/kobj real mem = 1608056832 (1533MB) avail mem = 1551196160 (1479MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfd400 (50 entries) bios0: vendor American Megatrends Inc. version V1.3 date 11/15/2010 bios0: MSI MS-7623 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PSKE(S4) PSMS(S4) ECIR(S4) PS2K(S3) PS2M(S3) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X4 955 Processor, 3200.77 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Phenom(tm) II X4 955 Processor, 3200.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Phenom(tm) II X4 955 Processor, 3200.16 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DN OW cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE2) acpiprt3 at acpi0: bus -1 (PCE3) acpiprt4 at acpi0: bus -1 (PCE4) acpiprt5 at acpi0: bus 2 (PCE5) acpiprt6 at acpi0: bus -1 (PCE6) acpiprt7 at acpi0: bus -1 (PCE7) acpiprt8 at acpi0: bus -1 (PCE9) acpiprt9 at acpi0: bus -1 (PCEA) acpiprt10 at acpi0: bus -1 (PCEB) acpiprt11 at acpi0: bus -1 (PCEC) acpiprt12 at acpi0: bus 3 (P0PC) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpicpu2 at acpi0: PSS acpicpu3 at acpi0: PSS acpibtn0 at acpi0: PWRB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD RS780 Host rev 0x00 ppb0 at pci0 dev 1 function 0 AMD RS780 PCIE rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 5 function 0 vendor ATI, unknown product 0x9616 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 4:08 AM, David Gwynne l...@animata.net wrote: i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. Yes, this is exactly the last thing I remember about this topic. huggz, dlg This isn't my boot disk, it's the storage disk, I'm going to re-disklabel, and newfs it; Do I also need to do something with fdisk? I'm not sure... Thanks.
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 04:15:51AM -0500, Abel Abraham Camarillo Ojeda wrote: On Sat, May 14, 2011 at 4:08 AM, David Gwynne l...@animata.net wrote: i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. Yes, this is exactly the last thing I remember about this topic. huggz, dlg This isn't my boot disk, it's the storage disk, I'm going to re-disklabel, and newfs it; Do I also need to do something with fdisk? I'm not sure... Yes, that is recommended. If yo use the whole disk for OpenBSd, fdisk -i will do. -Otto
Re: impact of unaligned partitions/slices on 4kB sector drives (wd10ears)
On Sat, May 14, 2011 at 4:22 AM, Otto Moerbeek o...@drijf.net wrote: On Sat, May 14, 2011 at 04:15:51AM -0500, Abel Abraham Camarillo Ojeda wrote: On Sat, May 14, 2011 at 4:08 AM, David Gwynne l...@animata.net wrote: i have had a look at querying disks for their physical and logical block alignments and offsets, but the the WD??EARS-00? drives dont report this info. according to western digital, the next generation of these drives (WD??EARS-11? iirc) are supposed to report them. if i ever find a disk that does report the physical to logical alignment, i might have a look at having the system make use of those values. Yes, this is exactly the last thing I remember about this topic. huggz, dlg This isn't my boot disk, it's the storage disk, I'm going to re-disklabel, and newfs it; Do I also need to do something with fdisk? I'm not sure... Yes, that is recommended. If yo use the whole disk for OpenBSd, As I do. fdisk -i will do. B B B B -Otto Ok.
Save/restore MSI capaility during suspend/restore
Another small piece of the puzzle. I'd appreciate it if people could
give this a quick test on their machines. If you have working
suspend/resume, please make sure it doesn't break with this diff.
Index: pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.89
diff -u -p -r1.89 pci.c
--- pci.c 12 Apr 2011 20:29:35 - 1.89
+++ pci.c 14 May 2011 09:58:57 -
@@ -63,6 +63,10 @@ struct pci_dev {
pcireg_t pd_int;
pcireg_t pd_map[NMAPREG];
pcireg_t pd_mask[NMAPREG];
+ pcireg_t pd_msi_mc;
+ pcireg_t pd_msi_ma;
+ pcireg_t pd_msi_mau32;
+ pcireg_t pd_msi_md;
int pd_pmcsr_state;
};
@@ -215,8 +219,8 @@ void
pci_suspend(struct pci_softc *sc)
{
struct pci_dev *pd;
- pcireg_t bhlc;
- int i;
+ pcireg_t bhlc, reg;
+ int off, i;
LIST_FOREACH(pd, sc-sc_devs, pd_next) {
/*
@@ -239,6 +243,22 @@ pci_suspend(struct pci_softc *sc)
pd-pd_int = pci_conf_read(sc-sc_pc, pd-pd_tag,
PCI_INTERRUPT_REG);
+ if (pci_get_capability(sc-sc_pc, pd-pd_tag,
+ PCI_CAP_MSI, off, reg)) {
+ pd-pd_msi_ma = pci_conf_read(sc-sc_pc, pd-pd_tag,
+ off + PCI_MSI_MA);
+ if (reg PCI_MSI_MC_C64) {
+ pd-pd_msi_mau32 = pci_conf_read(sc-sc_pc,
+ pd-pd_tag, off + PCI_MSI_MAU32);
+ pd-pd_msi_md = pci_conf_read(sc-sc_pc,
+ pd-pd_tag, off + PCI_MSI_MD64);
+ } else {
+ pd-pd_msi_md = pci_conf_read(sc-sc_pc,
+ pd-pd_tag, off + PCI_MSI_MD32);
+ }
+ pd-pd_msi_mc = reg;
+ }
+
if (pci_dopm) {
/* Place the device into D3. */
pd-pd_pmcsr_state = pci_get_powerstate(sc-sc_pc,
@@ -254,7 +274,7 @@ pci_resume(struct pci_softc *sc)
{
struct pci_dev *pd;
pcireg_t bhlc, reg;
- int i;
+ int off, i;
LIST_FOREACH(pd, sc-sc_devs, pd_next) {
/*
@@ -284,6 +304,23 @@ pci_resume(struct pci_softc *sc)
pd-pd_bhlc);
pci_conf_write(sc-sc_pc, pd-pd_tag, PCI_INTERRUPT_REG,
pd-pd_int);
+
+ if (pci_get_capability(sc-sc_pc, pd-pd_tag,
+ PCI_CAP_MSI, off, reg)) {
+ pci_conf_write(sc-sc_pc, pd-pd_tag,
+ off + PCI_MSI_MA, pd-pd_msi_ma);
+ if (reg PCI_MSI_MC_C64) {
+ pci_conf_write(sc-sc_pc, pd-pd_tag,
+ off + PCI_MSI_MAU32, pd-pd_msi_mau32);
+ pci_conf_write(sc-sc_pc, pd-pd_tag,
+ off + PCI_MSI_MD64, pd-pd_msi_md);
+ } else {
+ pci_conf_write(sc-sc_pc, pd-pd_tag,
+ off + PCI_MSI_MD32, pd-pd_msi_md);
+ }
+ pci_conf_write(sc-sc_pc, pd-pd_tag,
+ off + PCI_MSI_MC, pd-pd_msi_mc);
+ }
}
}
Re: A step towards support for Message Signaled Interrupts
Mark Kettenis wrote: Index: pci.c === RCS file: /cvs/src/sys/dev/pci/pci.c,v retrieving revision 1.89 diff -u -p -r1.89 pci.c --- pci.c 12 Apr 2011 20:29:35 - 1.89 +++ pci.c 13 May 2011 21:05:11 - @@ -167,6 +167,7 @@ pciattach(struct device *parent, struct sc-sc_memt = pba-pba_memt; sc-sc_dmat = pba-pba_dmat; sc-sc_pc = pba-pba_pc; + sc-sc_flags = sc-sc_flags; sc-sc_ioex = pba-pba_ioex; sc-sc_memex = pba-pba_memex; sc-sc_pmemex = pba-pba_pmemex; This looks weird (assigning a value to oneself): sc-sc_flags = sc-sc_flags; Were you trying to do something like ? sc-sc_flags = pba-pba_flags; Or maybe I just don't have a clue.
Re: Save/restore MSI capaility during suspend/restore
Date: Sat, 14 May 2011 12:02:45 +0200 (CEST) From: Mark Kettenis mark.kette...@xs4all.nl Another small piece of the puzzle. I'd appreciate it if people could give this a quick test on their machines. If you have working suspend/resume, please make sure it doesn't break with this diff. Index: pci.c === RCS file: /cvs/src/sys/dev/pci/pci.c,v retrieving revision 1.89 diff -u -p -r1.89 pci.c --- pci.c 12 Apr 2011 20:29:35 - 1.89 +++ pci.c 14 May 2011 09:58:57 - Just a warning. This diff won't compile without the changes I just committed to pcireg.h. Might take a couple of hourse for that change to show up at your favourite anoncvs mirror.
Re: Bus Pirate: bus hacking tool for hardware developers
On Fri, May 13, 2011 at 11:43:53AM +0200, Jasper Lievisse Adriaanse wrote: On Thu, May 12, 2011 at 06:00:53PM +, Jona Joachim wrote: Hi, I just wanted to share this board that I discovered today: http://dangerousprototypes.com/bus-pirate-manual/ It's an uftdi(4) board that gives you access to the following bus protocols: 1-Wire, I2C, SPI, JTAG, RS-232, MIDI, ... http://dangerousprototypes.com/docs/Features_overview I remember the photos of Theo soldering the I2C temperature chips to his RAM, so I thought some of you might find this interesting. Note: I haven't tested it yet but I read some very good critics Best regards, Jona -- Worse is better Richard P. Gabriel I got a buspirate last week and I hope to have a port ready next week with some nice utils, like an SPI sniffer and stuff like that :) Nice :) I bought one yesterday and am waiting for it. Cheers, Jona -- Worse is better Richard P. Gabriel
Re: amd64 pmap diff to g/c ifdef _LP64
On Sat, Apr 16, 2011 at 11:52:34AM -0400, Brad wrote: On 08/04/11 6:27 PM, Brad wrote: On Thu, Apr 07, 2011 at 09:00:45PM -0400, Brad wrote: Some _LP64 ifdef's leftover from rev 1.1. They appear to be unnecessary since this code is only for amd64 anyway and thus a 64-bit arch. Index: pmap.c === RCS file: /home/cvs/src/sys/arch/amd64/amd64/pmap.c,v retrieving revision 1.61 diff -u -p -r1.61 pmap.c --- pmap.c 14 Mar 2011 00:05:46 - 1.61 +++ pmap.c 8 Apr 2011 19:31:04 - @@ -289,10 +289,8 @@ extern paddr_t msgbuf_paddr; extern vaddr_t idt_vaddr; /* we allocate IDT early */ extern paddr_t idt_paddr; -#ifdef _LP64 extern vaddr_t lo32_vaddr; extern vaddr_t lo32_paddr; -#endif vaddr_t virtual_avail; extern int end; @@ -649,7 +647,8 @@ pmap_bootstrap(paddr_t first_avail, padd idt_paddr = first_avail;/* steal a page */ first_avail += 2 * PAGE_SIZE; -#ifdef _LP64 +#if defined(MULTIPROCESSOR) || \ +(NACPI 0 !defined(SMALL_KERNEL)) /* * Grab a page below 4G for things that need it (i.e. * having an initial %cr3 for the MP trampoline). @@ -659,6 +658,7 @@ pmap_bootstrap(paddr_t first_avail, padd lo32_paddr = first_avail; first_avail += PAGE_SIZE; #endif + /* * init the global lists. */ ok by me -- Ariane
Re: Remove the freelist member from vm_physseg
On Fri, May 13, 2011 at 11:36:48PM +0100, Owain Ainsworth wrote:
On Mon, May 09, 2011 at 10:15:23PM +0100, Owain Ainsworth wrote:
On Mon, May 09, 2011 at 07:22:01PM +0100, Owain Ainsworth wrote:
The new world order of pmemrange makes this data completely redundant
(being dealt with by the pmemrange constraints instead). Remove all code
that messes with the freelist.
While touching every caller of uvm_page_physload() anyway, add the flags
argument to all callers (all but one is 0 and that one already used
PHYSLOAD_DEVICE) and remove the macro magic to allow callers to continue
without it.
Should shrink the code a bit, as well.
My machine room is still in a mess, so this has only had the build
testing on i386 and amd64. I'd appreciate if people could check the
others since it'll be a while before I can get all my machines properly
set up.
ok?
matthew@ kindly pointed out two cases there I had missed the flags
addition.
So i have verified that this builds on:
alpha
amd64
armish
beagle
hppa
hppa64
i386
landisk
loongson
macppc
octeon
palm
socppc
sparc
sparc64
zaurus
gumstix didn't pass config let alone build but that seems to be a
problem in GENERIC.
So that leaves only the m88k-arch, m68k-arch and vax kernels untested (and
there is no way I can verify them really).
Any comments? ok?
Freelist death, I like. Ok.
diff --git arch/alpha/alpha/machdep.c arch/alpha/alpha/machdep.c
index 2a5a8de..216a681 100644
--- arch/alpha/alpha/machdep.c
+++ arch/alpha/alpha/machdep.c
@@ -559,7 +559,7 @@ nobootinfo:
0x%lx / 0x%lx\n, pfn0, kernstartpfn);
#endif
uvm_page_physload(pfn0, kernstartpfn,
- pfn0, kernstartpfn, VM_FREELIST_DEFAULT);
+ pfn0, kernstartpfn, 0);
}
#ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
@@ -573,7 +573,7 @@ nobootinfo:
0x%lx / 0x%lx\n, kernendpfn, pfn1);
#endif
uvm_page_physload(kernendpfn, pfn1,
- kernendpfn, pfn1, VM_FREELIST_DEFAULT);
+ kernendpfn, pfn1, 0);
}
} else {
/*
@@ -583,8 +583,7 @@ nobootinfo:
printf(Loading cluster %d: 0x%lx / 0x%lx\n, i,
pfn0, pfn1);
#endif
- uvm_page_physload(pfn0, pfn1, pfn0, pfn1,
- VM_FREELIST_DEFAULT);
+ uvm_page_physload(pfn0, pfn1, pfn0, pfn1, 0);
}
#ifdef _PMAP_MAY_USE_PROM_CONSOLE
}
diff --git arch/alpha/include/vmparam.h arch/alpha/include/vmparam.h
index 24fb644..5ff1c06 100644
--- arch/alpha/include/vmparam.h
+++ arch/alpha/include/vmparam.h
@@ -125,9 +125,6 @@
#defineVM_PHYSSEG_STRATVM_PSTRAT_BSEARCH
#defineVM_PHYSSEG_NOADD/* no more after
vm_mem_init */
-#defineVM_NFREELIST1
-#defineVM_FREELIST_DEFAULT 0
-
/*
* pmap-specific data stored in the vm_physmem[] array.
*/
diff --git arch/amd64/amd64/machdep.c arch/amd64/amd64/machdep.c
index 9ca1a7a..bc728a3 100644
--- arch/amd64/amd64/machdep.c
+++ arch/amd64/amd64/machdep.c
@@ -1360,7 +1360,6 @@ init_x86_64(paddr_t first_avail)
for (x = 0; x mem_cluster_cnt; x++) {
paddr_t seg_start = mem_clusters[x].start;
paddr_t seg_end = seg_start + mem_clusters[x].size;
- int seg_type;
if (seg_start first_avail) seg_start = first_avail;
if (seg_start seg_end) continue;
@@ -1368,20 +1367,12 @@ init_x86_64(paddr_t first_avail)
physmem += atop(mem_clusters[x].size);
- /* XXX - Should deal with 4GB boundary */
- if (seg_start = (1UL32))
- seg_type = VM_FREELIST_HIGH;
- else if (seg_end = 16*1024*1024)
- seg_type = VM_FREELIST_LOW;
- else
- seg_type = VM_FREELIST_DEFAULT;
-
#if DEBUG_MEMLOAD
printf(loading 0x%lx-0x%lx (0x%lx-0x%lx)\n,
seg_start, seg_end, atop(seg_start), atop(seg_end));
#endif
uvm_page_physload(atop(seg_start), atop(seg_end),
- atop(seg_start), atop(seg_end), seg_type);
+ atop(seg_start), atop(seg_end), 0);
}
#if DEBUG_MEMLOAD
printf(avail_start = 0x%lx\n, avail_start);
diff --git arch/amd64/include/vmparam.h arch/amd64/include/vmparam.h
index 494416f..bc22bac 100644
--- arch/amd64/include/vmparam.h
+++ arch/amd64/include/vmparam.h
@@ -110,11 +110,6 @@
#define VM_PHYSSEG_STRAT VM_PSTRAT_BIGFIRST
#define VM_PHYSSEG_NOADD /* can't add RAM after vm_mem_init */
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Sat, May 14, 2011 at 06:26:57PM +0300, Sviatoslav Chagaev wrote:
Then the only thing that remains -- is to add clipping in mix_badd().
Yes, if the other diff goes in, handling clipping makes sense.
This will give aucat all the bits and pieces to meet the requirements
of all kinds of users.
(Tested on i386 and amd64 with 16 and 24 bits ADATA)
Index: aproc.c
===
RCS file: /cvs/src/usr.bin/aucat/aproc.c,v
retrieving revision 1.64
diff -u -p -r1.64 aproc.c
--- aproc.c 28 Apr 2011 07:20:03 - 1.64
+++ aproc.c 14 May 2011 14:42:58 -
@@ -617,6 +617,11 @@ mix_badd(struct abuf *ibuf, struct abuf
unsigned i, j, cc, istart, inext, onext, ostart;
unsigned scount, icount, ocount;
int vol;
+#if ADATA_BITS = 16
+ register int data;
+#else
+ register long long data;
+#endif
it's ok this to be an int in both cases, since ints are 32-bit
an samples are at most 24-bit.
#ifdef DEBUG
if (debug_level = 4) {
@@ -673,7 +678,13 @@ mix_badd(struct abuf *ibuf, struct abuf
idata += istart;
for (i = scount; i 0; i--) {
for (j = cc; j 0; j--) {
- *odata += ADATA_MUL(*idata, vol);
+ data = *odata;
+ data += ADATA_MUL(*idata, vol);
+ if (data -ADATA_UNIT)
+ data = -ADATA_UNIT;
+ else if (data (ADATA_UNIT-2))
+ data = (ADATA_UNIT-2);
^^
ADATA_UNIT - 1
samles are in the -ADATA_UNIT .. (ADATA_UNIT - 1) range
+ *odata = (adata_t) data;
idata++;
odata++;
}
-- Alexandre
Re: mixerctl(1) diff: sort output
On Mon, 9 May 2011 14:55:36 +0200 Alexandre Ratchov a...@caoua.org wrote: On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote: On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser jake...@sdf.lonestar.org wrote: On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: * sorted output looks cleaner, prettier; * it's easier to find the variable you're looking for in a sorted output; * hierarchical variable names yet unordered? doesn't make sense; * this way mixerctl's behaviour will be closer to other *ctl programs which output variables in an ordered fashion (audioctl, sysctl, wsconsctl). these are all matters of opinion, except for hierarchical variable names which is not technically the case here. Okay, but what about making mixerctl more similar to other *ctl? sysctl is a tree, while the mixer is not a tree. It's not either a linear bunch of strings. You are talking about how it's implemented. For all I care -- it can have neural networks inside of it. Each next layer of software provides a higher level abstraction. Device specific audio driver - device independent audio driver - mixerctl/audioctl. I always thought that the idea behind the *ctl programs is to provide a way to configure totally different things in a similar manner. Therefore *ctl programs should behave as similarily as possible. Sorting it doesn't make much sense imho. Furthermore, sorting mixctl as strings is easy with sort(1) so it's not absolutely necessary; mixerctl is the only *ctl program for which I use | sort all the time. while it would kill the widget order exposed by the driver. Both you and Jacob Meuser mentioned this, but what is this information useful for? I already can figure out which widgets are related just by looking at the names of the variables. -- Alexandre Excerpt from mixerctl(1) manpage: ... EXAMPLES Show possible values for all mixer variables, and their current settings: $ mixerctl -av inputs.mic=0,0 volume inputs.mic.mute=off [ off on ] inputs.cd=220,220 volume inputs.cd.mute=off [ off on ] inputs.dac=220,220 volume inputs.dac.mute=off [ off on ] record.record=220,220 volume record.record.source=mic [ mic cd dac ] monitor.monitor=0 volume ... Maybe the original author of mixerctl didn't think of adding sorting because on his computer the output looked more or less ordered.
Re: mixerctl(1) diff: sort output
On Mon, 9 May 2011 12:44:54 + Jacob Meuser jake...@sdf.lonestar.org wrote: On Mon, May 09, 2011 at 02:56:28PM +0300, Sviatoslav Chagaev wrote: On Mon, May 9, 2011 at 4:48 AM, Jacob Meuser jake...@sdf.lonestar.org wrote: On Mon, May 09, 2011 at 01:32:49AM +0300, Sviatoslav Chagaev wrote: * sorted output looks cleaner, prettier; * it's easier to find the variable you're looking for in a sorted output; * hierarchical variable names yet unordered? doesn't make sense; * this way mixerctl's behaviour will be closer to other *ctl programs which output variables in an ordered fashion (audioctl, sysctl, wsconsctl). these are all matters of opinion, except for hierarchical variable names which is not technically the case here. Okay, but what about making mixerctl more similar to other *ctl? *sigh* $ wsconsctl (blah) Permission denied $ usbhidctl usage: (blah) $ ikectl missing argument: $ gpioctl usage: (blah) or how about, what other *ctl program is almost entirely hardware dependent? mixerctl uses audio(4). audio manpage: audio, mixer - device-independent audio driver layer Before: note how the controls are grouped (mostly) by widget. please read azalia(4). I did notice that. Unfortunately, I can't access my amd64 machine right now. It has like 2 to 3 times the amount of variables shown here and I think I saw some vars there, for which I couldn't figure out by which criteria were they ordered. If mixerctl's intention is that the most important thing is the widget, then the widget's name should've been placed in front. I tried this just now, putting widget in front, then the mixer class -- it looks horrible, completely unscannable. Maybe the mixer class is the most important thing after all, since this is the most generic thing you can group various widgets by. ok then, why do some devices have 'outputs.dac' yet others have 'inputs.dac'? what is the difference to the user? which is more correct? why? I have absolutely no idea. I'm not an audio equipment manufacturer. I don't understand how are these questions even relevant. this has been the case since long before azalia(4). if you cannot explain this, then you just don't understand. s@d630:0:/usr/src/usr.bin/mixerctl$ mixerctl outputs.hp_source=dac-0:1 outputs.hp_dir=output outputs.hp_boost=off outputs.line-in_source=dac-2:3 outputs.line-in_dir=input outputs.mic_dir=input-vr80 outputs.spkr_source=dac-2:3 outputs.spkr_dir=none outputs.spkr_boost=off inputs.dac-2:3_mute=off inputs.dac-2:3=152,152 inputs.dac-0:1_mute=off inputs.dac-0:1=152,152 inputs.sel_source=mic outputs.sel=126,126 inputs.sel2_source=line-in outputs.sel2=126,126 inputs.sel3_source=sel inputs.sel3_sel=119,119 inputs.sel4_source=sel2 inputs.sel4_sel2=119,119 record.adc-0:1_source=sel3 record.adc-0:1_mute=off record.adc-2:3_source=sel4 record.adc-2:3_mute=off inputs.beep=85 and at the end are the pseudo controls. the ones most people are most interested in. so even if the rest of the controls scroll by when you do a simple mixerctl, you see these controls. Just by looking at these variables, I cannot distinguish which ones are pseudo and which aren't. This is an implementation detail, I think the user of an interface shouldn't have to care about implementation details. I cannot provide any evidence that most people are or are not interested in those pseudo vars, but I thought most of the time people are interested in something like play an mp3 file, watch a video, simple stuff like that. In this case one would probably be most interested in outputs, volume controls... as in, 'outputs.master' ... the one that's tied to the keyboard keys on laptops. this is by far the most important, most used mixer control. Suppose I have bought a new computer, can I predict where exactly these controls will pop up in the output? It's possible to adjust sorting and output these vars last, by modifying the cmp function. that is ridiculous. And I can argue that it is still easier to find what you're looking for when the output is sorted, especially considering that the output of mixerctl can vary widely between different computers. please do give an example of how sorting them makes finding what you're looking for easier. please. and it better be easier than piping through sort/grep. I'll repeat that you cannot rely on 'inputs' or 'outputs' having true meaning. sorry, but you can't. trust me on that one. Binary search. I might not remember the exact name of the variable. Why should I be suffering if someone has broken hardware? From all the computers I owned -- there wasn't a single time when vars were labeled incorrectly. Even if I have broken hardware, I will know this the first time I use it. No need to tell me that over and
Re: aucat(1) mixing: saturating-addition instead of add-and-divide-by-n_inputs
On Sat, 14 May 2011 17:55:06 +0200
Alexandre Ratchov a...@caoua.org wrote:
On Sat, May 14, 2011 at 06:26:57PM +0300, Sviatoslav Chagaev wrote:
Then the only thing that remains -- is to add clipping in mix_badd().
Yes, if the other diff goes in, handling clipping makes sense.
This will give aucat all the bits and pieces to meet the requirements
of all kinds of users.
(Tested on i386 and amd64 with 16 and 24 bits ADATA)
Index: aproc.c
===
RCS file: /cvs/src/usr.bin/aucat/aproc.c,v
retrieving revision 1.64
diff -u -p -r1.64 aproc.c
--- aproc.c 28 Apr 2011 07:20:03 - 1.64
+++ aproc.c 14 May 2011 14:42:58 -
@@ -617,6 +617,11 @@ mix_badd(struct abuf *ibuf, struct abuf
unsigned i, j, cc, istart, inext, onext, ostart;
unsigned scount, icount, ocount;
int vol;
+#if ADATA_BITS = 16
+ register int data;
+#else
+ register long long data;
+#endif
it's ok this to be an int in both cases, since ints are 32-bit
an samples are at most 24-bit.
#ifdef DEBUG
if (debug_level = 4) {
@@ -673,7 +678,13 @@ mix_badd(struct abuf *ibuf, struct abuf
idata += istart;
for (i = scount; i 0; i--) {
for (j = cc; j 0; j--) {
- *odata += ADATA_MUL(*idata, vol);
+ data = *odata;
+ data += ADATA_MUL(*idata, vol);
+ if (data -ADATA_UNIT)
+ data = -ADATA_UNIT;
+ else if (data (ADATA_UNIT-2))
+ data = (ADATA_UNIT-2);
^^
ADATA_UNIT - 1
samles are in the -ADATA_UNIT .. (ADATA_UNIT - 1) range
Sorry =(
+ *odata = (adata_t) data;
idata++;
odata++;
}
-- Alexandre
Add list all option to bioctl(8)
Hello all.
This patch actually consists of three parts, logically organized
one-by-one down there:
1. Add BIOCLISTCONTROLLERS ioctl to bio(4), allowing to enumerate all
registered controllers.
2. Add -A flag to bioctl(8) that enumerates all volumes accessible by
bio(4), and make this default behavior when no command parameters given.
3. Add such output of bioctl to daily(8), just before disks: subpart.
Feedback and, hopefully, commits are welcome. :) Especially
ioctl-related part needs to be reviewed, I'm surely missed something.
But it works. :)
--
Best wishes,
Vadim Zhukov
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Index: sys/dev/biovar.h
===
RCS file: /cvs/src/sys/dev/biovar.h,v
retrieving revision 1.39
diff -u -p -r1.39 biovar.h
--- sys/dev/biovar.h14 Apr 2011 02:41:40 - 1.39
+++ sys/dev/biovar.h14 May 2011 16:30:54 -
@@ -221,6 +221,17 @@ struct bioc_installboot {
void*bb_bootldr;
u_int32_t bb_bootblk_size;
u_int32_t bb_bootldr_size;
+};
+
+#define BIOCLISTCONTROLLERS _IOWR('B', 42, struct bioc_controllerlist)
+struct bioc_controller {
+ char bc_xname[16];
+};
+struct bioc_controllerlist {
+ /* max number of bioc_controller structs to fit in bcl_devs */
+ u_int32_t bcl_size;
+ /* pointer to destination buffer */
+ struct bioc_controller *bcl_list;
};
/* kernel and userspace defines */
Index: sys/dev/bio.c
===
RCS file: /cvs/src/sys/dev/bio.c,v
retrieving revision 1.12
diff -u -p -r1.12 bio.c
--- sys/dev/bio.c 22 Jan 2010 21:56:04 - 1.12
+++ sys/dev/bio.c 14 May 2011 16:30:54 -
@@ -74,7 +74,10 @@ bioioctl(dev_t dev, u_long cmd, caddr_t
{
struct bio_locate *locate;
struct bio_common *common;
+ struct bio_mapping *bm;
+ struct bioc_controllerlist *clist;
char name[16];
+ u_int32_t i;
int error;
switch (cmd) {
@@ -102,6 +105,26 @@ bioioctl(dev_t dev, u_long cmd, caddr_t
return (ENOENT);
return (bio_delegate_ioctl(
(struct bio_mapping *)common-bc_cookie, cmd, addr));
+
+ case BIOCLISTCONTROLLERS:
+ clist = (struct bioc_controllerlist *)addr;
+ i = 0;
+ error = 0;
+ LIST_FOREACH(bm, bios, bm_link) {
+ if (clist-bcl_list == NULL)
+ goto next_controller;
+ if (i = clist-bcl_size) {
+ error = ENOMEM;
+ goto next_controller;
+ }
+ copyoutstr(bm-bm_dev-dv_xname,
+ clist-bcl_list[i].bc_xname,
+ sizeof(bm-bm_dev-dv_xname), NULL);
+next_controller:
+ i++;
+ }
+ clist-bcl_size = i;
+ return (error);
default:
return (ENXIO);
Index: share/man/man4/bio.4
===
RCS file: /cvs/src/share/man/man4/bio.4,v
retrieving revision 1.29
diff -u -p -r1.29 bio.4
--- share/man/man4/bio.423 Aug 2010 00:58:49 - 1.29
+++ share/man/man4/bio.414 May 2011 16:30:54 -
@@ -147,6 +147,12 @@ Remove system disk (if present) and disa
volume.
.It Dv BIOCDISCIPLINE
Dispatch a discipline specific ioctl.
+.It Dv BIOCLISTCONTROLLERS
+Return list of all disk controllers registered in
+.Nm .
+Those names are suitable for
+.Dv BIOCLOCATE .
+Remember that there could be no volumes and disks on those controllers.
.El
.Sh FILES
.Bl -tag -width /dev/bio -compact
Index: sbin/bioctl/bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.99
diff -u -p -r1.99 bioctl.c
--- sbin/bioctl/bioctl.c4 Apr 2011 15:22:31 - 1.99
+++ sbin/bioctl/bioctl.c14 May 2011 16:30:54 -
@@ -57,7 +57,6 @@ struct locator {
void usage(void);
const char *str2locator(const char *, struct locator *);
-void cleanup(void);
intbio_parse_devlist(char *, dev_t *);
void bio_kdf_derive(struct sr_crypto_kdfinfo *,
struct sr_crypto_kdf_pbkdf2 *, char *, int);
@@ -65,7 +64,8 @@ void bio_kdf_generate(struct sr_crypto
void derive_key_pkcs(int, u_int8_t *, size_t, u_int8_t *,
size_t, char *, int);
-void bio_inq(char *);
+void bio_listall(void);
+void
ssh, consistent use of fcntl(2) with F_SETFD
Please review the diff.
Thanks
Index: usr.bin/ssh/authfd.c
===
RCS file: /cvs/src/usr.bin/ssh/authfd.c,v
retrieving revision 1.84
diff -p -u -r1.84 authfd.c
--- usr.bin/ssh/authfd.c31 Aug 2010 11:54:45 - 1.84
+++ usr.bin/ssh/authfd.c14 May 2011 17:57:48 -
@@ -108,7 +108,7 @@ ssh_get_authentication_socket(void)
return -1;
/* close on exec */
- if (fcntl(sock, F_SETFD, 1) == -1) {
+ if (fcntl(sock, F_SETFD, FD_CLOEXEC) == -1) {
close(sock);
return -1;
}
Index: usr.bin/ssh/monitor.c
===
RCS file: /cvs/src/usr.bin/ssh/monitor.c,v
retrieving revision 1.110
diff -p -u -r1.110 monitor.c
--- usr.bin/ssh/monitor.c 9 Sep 2010 10:45:45 - 1.110
+++ usr.bin/ssh/monitor.c 14 May 2011 17:57:48 -
@@ -1513,7 +1513,7 @@ mm_init_compression(struct mm_master *mm
/* XXX */
#define FD_CLOSEONEXEC(x) do { \
- if (fcntl(x, F_SETFD, 1) == -1) \
+ if (fcntl(x, F_SETFD, FD_CLOEXEC) == -1) \
fatal(fcntl(%d, F_SETFD), x); \
} while (0)
Index: usr.bin/ssh/serverloop.c
===
RCS file: /cvs/src/usr.bin/ssh/serverloop.c,v
retrieving revision 1.159
diff -p -u -r1.159 serverloop.c
--- usr.bin/ssh/serverloop.c28 May 2009 16:50:16 - 1.159
+++ usr.bin/ssh/serverloop.c14 May 2011 17:57:48 -
@@ -127,8 +127,8 @@ notify_setup(void)
{
if (pipe(notify_pipe) 0) {
error(pipe(notify_pipe) failed %s, strerror(errno));
- } else if ((fcntl(notify_pipe[0], F_SETFD, 1) == -1) ||
- (fcntl(notify_pipe[1], F_SETFD, 1) == -1)) {
+ } else if ((fcntl(notify_pipe[0], F_SETFD, FD_CLOEXEC) == -1) ||
+ (fcntl(notify_pipe[1], F_SETFD, FD_CLOEXEC) == -1)) {
error(fcntl(notify_pipe, F_SETFD) failed %s, strerror(errno));
close(notify_pipe[0]);
close(notify_pipe[1]);
Re: mixerctl(1) diff: sort output
On Sat, May 14, 2011 at 07:29:01PM +0300, Sviatoslav Chagaev wrote: On Mon, 9 May 2011 12:44:54 + Jacob Meuser jake...@sdf.lonestar.org wrote: ok then, why do some devices have 'outputs.dac' yet others have 'inputs.dac'? what is the difference to the user? which is more correct? why? I have absolutely no idea. I'm not an audio equipment manufacturer. I don't understand how are these questions even relevant. my point exactly. this has been the case since long before azalia(4). if you cannot explain this, then you just don't understand. you post a diff and assert that the class is the most important part of the name, but when confronted with an example of how the class is ambiguous, you cannot explain why. and it's not because you aren't a hardware manufacturer. I'm not a hardware mfg either. but I do work on OpenBSD's audio system. I have spent many, many hours reading the code, fixing issues, trying to figure out how to make things better. and I can confidently say that adding sorting to mixerctl is not the answer. in fact, that will make things worse, I guarantee it. Suppose I have bought a new computer, can I predict where exactly these controls will pop up in the output? all azalia(4) will have outputs.master very near the end. cannot say exactly, as it depends on what controls the hardware supports. please do give an example of how sorting them makes finding what you're looking for easier. please. and it better be easier than piping through sort/grep. I'll repeat that you cannot rely on 'inputs' or 'outputs' having true meaning. sorry, but you can't. trust me on that one. Binary search. I might not remember the exact name of the variable. Why should I be suffering if someone has broken hardware? From all the computers I owned -- there wasn't a single time when vars were labeled incorrectly. Even if I have broken hardware, I will know this the first time I use it. No need to tell me that over and over again. This will not fix my hardware. this is not an example, nor does it preclude using grep/sort. it's not about broken hardware. it's about inconsistent mixer(4) implementations, which is largely due to poor documentation of mixer(9). It doesn't matter how mixerctl and other *ctl are _implemented_. They should behave as similar as possible. I already showed how the *ctl programs do NOT behave similarly, even before you get to the listing of variables, if the *ctl programs even list variables. while I appreciate consistency, shooting yourself in the foot to be consistent is not a good idea. if you really want to fix the mixer(4) implementations, then you have to fix the mixer(4) implementations *in the low level drivers*. adding sorting in mixerctl will make that harder, because then the controls will not be in the same order as they are created by the drivers. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: mixerctl(1) diff: sort output
On Sat, May 14, 2011 at 07:02:21PM +0300, Sviatoslav Chagaev wrote: I always thought that the idea behind the *ctl programs is to provide a way to configure totally different things in a similar manner. Therefore *ctl programs should behave as similarily as possible. so where is your diff to add an abstraction layer to mixer(4), so that mixerctl output is the same for *every* device? that is the solution that would benefit everyone. adding sorting to mixerctl is stupid. it solves nothing and makes maintainence of audio drivers more difficult. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: mixerctl(1) diff: sort output
Hi. Sviatoslav Chagaev 0x1392 () gmail ! com I have absolutely no idea. I'm not an audio equipment manufacturer. I have used many consoles ... digital and analogue ones ... live and in studios. I also have an electronics background - digital and analogue ... and repaired many consoles. I've also used software mixing facilities. The model is always the same. As someone said in the aucat thread the principle of least surprise and this applies extremely in the professional audio world where it's expected that I can go to a venue and be able to work immediately with equipment I may have never seen before. As far as bussing goes there's an accepted way of doing things. In the analogue world this is limited by the layout of the circuits whereas in the digital there's a lot more flexibility but ... it's only in the most simple cases that a pure hierarchy is at work. I've never defined this before but this is from wikipedia and pretty much sums it up: In a group of related items, heterarchy is a state wherein any pair of items is likely to be related in two or more differing ways. Whereas hierarchies sort groups into progressively smaller categories and subcategories, heterarchies divide and unite groups variously, according to multiple concerns that emerge or recede from view according to perspective. http://en.wikipedia.org/wiki/Heterarchy A most pertinent point there to ordering output: ... heterarchies divide and unite groups variously, according to multiple concerns that emerge or recede from view according to perspective. This is exactly how mixing consoles (even simple analogue ones) and mixing software work and exactly how people who use them think - having more than one visual model in their head at a given time, usually assembling heterarchies into multiple hierarchies and often matrixing them as well. This also applies very strongly (I've omitted some of the flexibility which doesn't apply to the rigidity of bussing): A heterarchy may be ... subsumed to a hierarchy ...; the two kinds of structure are not mutually exclusive. In fact, each level in a hierarchical system is composed of a ... heterarchical group ... Even in consoles with very flexible bussing there's always a number of levels in a somewhat hierarchical structure - almost invariably more than one hierarchy is available and even in simple analogue consoles it's possible to move items so that they span different levels of a hierachy (or move into another hierarchy). Where we originally might have ... ___a___ | | _a_ _b_ | | | | ab c d It's pretty trivial to do ... _a | | | | _a_ | | | | | abc d ... or permutations thereof. Labelling of mixing consoles have been designed this way since day dot as a direct result of electronic bussing and continued right into software mixing on the principle of least surprise. Something else that's extremely relevant is that mixers (people who do mixing) label in this manner also - whether mentally or with a texta ... Usually likeness trumps everything. For instance I will bus all the violins into a violins group and bus all the cellos into the cello group and then bus them together into the strings group. On an analogue console (and a digital one in a simple layout) I will see this: S V C | | _ | __ | _ | | || | | v v vc c c On a digital console I might see this: S __V C__ _ | _ _ | _ | | | | | | v v v c c c That's how layout works from left to right but ... LIKE THINGS WILL ALWAYS BE GROUPED both on the console/software and in the models. Not in alphanumeric order - that's only useful when I have three trombones and I label them T1, T2, T3 ... One thing that is invariable though ... is that the input and the output of a particular channel are always grouped together unless they are specifically supposed to work as a team. For instance this ... channela - channelb - groupA (ab) - channelc - channeld - groupB (cd) - mainA (AB) - ... is always understood to mean ... - input channela output - - input channelb output - - input groupA (ab) output - - input channelc output - - input channeld output - - input groupB (cd) output - - input mainA (AB) output - ... it doesn't matter at all if you want to do this though ... - input channela output - - input channelb output - - input channelc output - - input channeld output - - input groupA (ab) output - - input groupB (cd) output - - input mainA (AB) output - ... but never this ... - input channela - input channelb - input channelc - input channeld - input groupA (ab) - input groupB (cd) - input mainA (AB) channela output - channelb output - channelc output - channeld
Re: mixerctl(1) diff: sort output
At the sake of running out of internet here's a little clarification ... ... this ... - input channela channela output - - input channelb channelb output - - input channelc channelc output - - input channeld channeld output - - input groupA (ab) groupA (ab) output - - input groupB (cd) groupB (cd) output - - input mainA (AB) mainA (AB) output - ... or this ... - input channela - input channelb - input channelc - input channeld channela output - channelb output - channelc output - channeld output - - input groupA (ab) - input groupB (cd) groupA (ab) output - groupB (cd) output - - input mainA (AB) mainA (AB) output - ... but never this ... - input channela - input channelb - input channelc - input channeld - input groupA (ab) - input groupB (cd) - input mainA (AB) channela output - channelb output - channelc output - channeld output - groupA (ab) output - groupB (cd) output - mainA (AB) output - ... and AFAICT mixerctl does it correctly. FYI it's not as amibiguous as it might appear and AFAICT the reasons that have been given are the correct ones. Best wishes.
Re: Bus Pirate: bus hacking tool for hardware developers
On Thu, 12 May 2011, Jona Joachim wrote: Hi, I just wanted to share this board that I discovered today: http://dangerousprototypes.com/bus-pirate-manual/ It's an uftdi(4) board that gives you access to the following bus protocols: 1-Wire, I2C, SPI, JTAG, RS-232, MIDI, ... http://dangerousprototypes.com/docs/Features_overview I have had one of these for a while and used it to test an SPI D/A. It works very nicely under OpenBSD. -d
Re: A step towards support for Message Signaled Interrupts
This diff completes the implementation of PCI flags, making sure [...] Hi! Forgive my ignorance, but is PR 6523 related to this? Should I try this with that machine? (http://marc.info/?l=openbsd-miscm=126840264605078w=2) Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
