Re: uvm_fault with bwi on i386 when scanning or bringing up.
Date: Sun, 1 Mar 2015 16:50:27 -0330
From: Michael lesniewskis...@gmail.com
uvm_fault(0xd6508004, 0x0, 0, 1) - e
kernel: page fault trap, code=0
Stopped at 0:uvm_fault(0xd6508004, 0x0, 0, 1) - e
kernel: page fault trap, code=0
Stopped at db_read_bytes+0x17: movzbl 0(%esi,%ecx,1),%eax
I think this is how a null-pointer call shows up in ddb.
Does the diff below help?
Index: bwi.c
===
RCS file: /cvs/src/sys/dev/ic/bwi.c,v
retrieving revision 1.116
diff -u -p -r1.116 bwi.c
--- bwi.c 10 Feb 2015 23:25:46 - 1.116
+++ bwi.c 4 Mar 2015 14:03:23 -
@@ -1234,7 +1234,7 @@ bwi_mac_init(struct bwi_mac *mac)
/*
* Initialize TX stats if the current MAC uses that
*/
- if (mac-mac_flags BWI_MAC_F_HAS_TXSTATS) {
+ if (mac-mac_flags BWI_MAC_F_HAS_TXSTATS sc-sc_init_txstats) {
error = sc-sc_init_txstats(sc);
if (error) {
printf(%s: can't initialize TX stats ring\n,
@@ -2368,7 +2368,7 @@ bwi_mac_shutdown(struct bwi_mac *mac)
struct bwi_softc *sc = mac-mac_sc;
int i;
- if (mac-mac_flags BWI_MAC_F_HAS_TXSTATS)
+ if (mac-mac_flags BWI_MAC_F_HAS_TXSTATS sc-sc_free_txstats)
sc-sc_free_txstats(sc);
sc-sc_free_rx_ring(sc);
Re: panic: lapic_set_lvt at boot
From: enuhtac enuhtac_li...@gmx.de
Date: Sun, 8 Feb 2015 11:17:47 + (UTC)
The first sign during the boot process of garbage in the
ACPI_MADT_LAPIC_NMI
structures mentioned by me earlier are these lines:
acpimadt0: bogus nmi for apid 0
acpimadt0: bogus nmi for apid 2
Here the kernel detects wrong values in the flags fields and removes the
corresponding ACPI_MADT_LAPIC_NMI entries. A third entry (for apid 1) goes
through unnoticed because by chance the flag values are spec conform.
Nevertheless the lint entry is bogus which causes the kernel panic later
on.
The ehci_sync_hc: tsleep() = 35 is probably also a follow up error
of the faulty LAPIC setup because the USB driver is waiting for some
interrupt to occur which never happens.
Still I do not know what to do to fix this issue.
Only pin 0 and 1 make sense, so here is a diff that checks for those
values and declares the entry bogus if the pin value is anything else.
Does this fix your problem?
Index: acpimadt.c
===
RCS file: /home/cvs/src/sys/dev/acpi/acpimadt.c,v
retrieving revision 1.30
diff -u -p -r1.30 acpimadt.c
--- acpimadt.c 9 Dec 2014 06:58:29 - 1.30
+++ acpimadt.c 8 Feb 2015 23:38:47 -
@@ -359,7 +359,8 @@ acpimadt_attach(struct device *parent, s
map-ioapic_pin = pin;
map-flags = entry-madt_lapic_nmi.flags;
- if (!acpimadt_cfg_intr(entry-madt_lapic_nmi.flags,
map-redir)) {
+ if ((pin != 0 pin != 1) ||
+ !acpimadt_cfg_intr(entry-madt_lapic_nmi.flags,
map-redir)) {
printf(%s: bogus nmi for apid %d\n,
self-dv_xname, map-cpu_id);
mp_nintrs--;
Re: bce(4) - descriptor error
Date: Thu, 22 Jan 2015 18:04:44 +0100 From: Stefan Sperling s...@stsp.name On Thu, Jan 22, 2015 at 11:34:47AM -0500, John Merriam wrote: So, what could be the problem then? Theoretically it did work as of the 1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This message: http://marc.info/?l=openbsd-techm=130217668909255 seems to verify that it did actually work at one point. It looks as if some ring descriptor data is still being allocated with bus_dmamem_alloc(). That function probably doesn't respect the mapping constraints bce(4) hardware requires. This diff makes bce use the same memory allocation APIs as bwi(4) is using. Some bwi devices have the same 1GB problem and I know the bwi code works fine with such devices. So perhaps applying the same approach to bce will fix your issue. I'd really prefer it if we'd solve this issue by promoting _bus_dmamem_alloc_range() to a first class citizen. I'll try to recover an old diff that did this tonight. No harm in testing this diff though to verify that it indeed solves the issue.
Re: bce(4) - descriptor error
Date: Thu, 22 Jan 2015 19:38:42 +0100 (CET)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Thu, 22 Jan 2015 18:04:44 +0100
From: Stefan Sperling s...@stsp.name
On Thu, Jan 22, 2015 at 11:34:47AM -0500, John Merriam wrote:
So, what could be the problem then? Theoretically it did work as of the
1.35 if_bce.c revision which seems to have shipped in OpenBSD 5.0. This
message:
http://marc.info/?l=openbsd-techm=130217668909255
seems to verify that it did actually work at one point.
It looks as if some ring descriptor data is still being allocated with
bus_dmamem_alloc(). That function probably doesn't respect the mapping
constraints bce(4) hardware requires.
This diff makes bce use the same memory allocation APIs as bwi(4) is
using. Some bwi devices have the same 1GB problem and I know the bwi
code works fine with such devices. So perhaps applying the same approach
to bce will fix your issue.
I'd really prefer it if we'd solve this issue by promoting
_bus_dmamem_alloc_range() to a first class citizen. I'll try to
recover an old diff that did this tonight.
No harm in testing this diff though to verify that it indeed solves
the issue.
So here is the alternative diff. Only amd64/i386 are actually
implemented, but those are the only platforms we support bce(4) on.
Index: dev/pci/if_bce.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bce.c,v
retrieving revision 1.40
diff -u -p -r1.40 if_bce.c
--- dev/pci/if_bce.c22 Dec 2014 02:28:51 - 1.40
+++ dev/pci/if_bce.c22 Jan 2015 20:38:05 -
@@ -315,8 +315,9 @@ bce_attach(struct device *parent, struct
* XXX PAGE_SIZE is wasteful; we only need 1KB + 1KB, but
* due to the limition above. ??
*/
- if ((error = bus_dmamem_alloc(sc-bce_dmatag, 2 * PAGE_SIZE,
- PAGE_SIZE, 2 * PAGE_SIZE, seg, 1, rseg, BUS_DMA_NOWAIT))) {
+ if ((error = bus_dmamem_alloc_range(sc-bce_dmatag, 2 * PAGE_SIZE,
+ PAGE_SIZE, 2 * PAGE_SIZE, seg, 1, rseg, BUS_DMA_NOWAIT,
+ (bus_addr_t)0, (bus_addr_t)0x3fff))) {
printf(: unable to alloc space for ring descriptors,
error = %d\n, error);
uvm_km_free(kernel_map, (vaddr_t)sc-bce_data,
Index: arch/amd64/amd64/bus_dma.c
===
RCS file: /home/cvs/src/sys/arch/amd64/amd64/bus_dma.c,v
retrieving revision 1.46
diff -u -p -r1.46 bus_dma.c
--- arch/amd64/amd64/bus_dma.c 16 Nov 2014 12:30:56 - 1.46
+++ arch/amd64/amd64/bus_dma.c 22 Jan 2015 20:38:05 -
@@ -424,7 +424,7 @@ _bus_dmamem_alloc(bus_dma_tag_t t, bus_s
* memory under the 4gig boundary.
*/
return (_bus_dmamem_alloc_range(t, size, alignment, boundary,
- segs, nsegs, rsegs, flags, (paddr_t)0, (paddr_t)0x));
+ segs, nsegs, rsegs, flags, (bus_addr_t)0, (bus_addr_t)0x));
}
/*
@@ -662,7 +662,7 @@ _bus_dmamap_load_buffer(bus_dma_tag_t t,
int
_bus_dmamem_alloc_range(bus_dma_tag_t t, bus_size_t size, bus_size_t alignment,
bus_size_t boundary, bus_dma_segment_t *segs, int nsegs, int *rsegs,
-int flags, paddr_t low, paddr_t high)
+int flags, bus_addr_t low, bus_addr_t high)
{
paddr_t curaddr, lastaddr;
struct vm_page *m;
Index: arch/amd64/include/bus.h
===
RCS file: /home/cvs/src/sys/arch/amd64/include/bus.h,v
retrieving revision 1.31
diff -u -p -r1.31 bus.h
--- arch/amd64/include/bus.h29 Mar 2014 18:09:28 - 1.31
+++ arch/amd64/include/bus.h22 Jan 2015 20:38:05 -
@@ -594,6 +594,9 @@ struct bus_dma_tag {
*/
int (*_dmamem_alloc)(bus_dma_tag_t, bus_size_t, bus_size_t,
bus_size_t, bus_dma_segment_t *, int, int *, int);
+ int (*_dmamem_alloc_range)(bus_dma_tag_t, bus_size_t, bus_size_t,
+ bus_size_t, bus_dma_segment_t *, int, int *, int,
+ bus_addr_t, bus_addr_t);
void(*_dmamem_free)(bus_dma_tag_t,
bus_dma_segment_t *, int);
int (*_dmamem_map)(bus_dma_tag_t, bus_dma_segment_t *,
@@ -622,6 +625,9 @@ struct bus_dma_tag {
#definebus_dmamem_alloc(t, s, a, b, sg, n, r, f) \
(*(t)-_dmamem_alloc)((t), (s), (a), (b), (sg), (n), (r), (f))
+#definebus_dmamem_alloc_range(t, s, a, b, sg, n, r, f, l, h) \
+ (*(t)-_dmamem_alloc_range)((t), (s), (a), (b), (sg), \
+ (n), (r), (f), (l), (h))
#definebus_dmamem_free(t, sg, n) \
(*(t)-_dmamem_free)((t), (sg), (n))
#definebus_dmamem_map(t, sg, n, s, k, f) \
@@ -686,6 +692,6 @@ paddr_t _bus_dmamem_mmap(bus_dma_tag_t t
int_bus_dmamem_alloc_range(bus_dma_tag_t tag, bus_size_t size
Re: Missing video console after install
Date: Tue, 13 Jan 2015 13:13:59 -0600 From: Tony Asleson tony.asle...@gmail.com pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82855GM Host rev 0x02 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xe800, size 0x40 Intel 82855GM Memory rev 0x02 at pci0 dev 0 function 1 not configured Intel 82855GM Config rev 0x02 at pci0 dev 0 function 3 not configured ppb0 at pci0 dev 1 function 0 Intel 82855GME AGP rev 0x02 pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 Intel 82855GM Video rev 0x02 intagp0 at vga1 agp1 at intagp0: aperture at 0xd800, size 0x800 inteldrm0 at vga1 drm0 at inteldrm0 Oh, that is interesting. You have agp0 and agp1. Given that the aperture on agp0 (the real AGP bridge) is 4M, I suspect inteldrm(4) gets confused and tries to use agp0 instead of agp1. To confirm this, can you try the following: 1. Boot with the -c options, i.e. trype bsd -c at the boot prompt. 2. Disable intelagp, i.e. yupe disable intelagp at the UKC prompt. 3. Type quit at the UKC prompt.
Re: RSDT corruption, acpidump problems
From: Kasper Steensig Jensen ksj...@student.aau.dk
Date: Thu, 8 Jan 2015 15:38:12 +
On Debian I also got the error Wrong checksum for XDST,
I can still read the battery on Debian which I can't on OpenBSD.
I also found the return NULL that I am hitting in
sys/dev/acpi.c:acpi_maptable()
It is the 4th NULL which is in the codeblock:
if (acpi_checksum(hdr, len)) {
acpi_unmap(handle);
return NULL;
}
It is definitely the checksum that something is wrong with,
I don't know how to fix it though.
By commenting the code segmenting out which makes it ignore the checksum
I could get apm to detect my battery and batterylife.
This is bad practice and I would like not to do it this way but it makes it
work.
Is it possible that my laptop doesn't live up to the ACPI specs or something?
Yes, it certainly looks like the BIOS in this machine violates the
ACPI spec. Nothing new there; engineering standards are pretty low in
this areea :(. People suspect that Windows doesn't verify these
checksums. And it seems Linux and FreeBSD only print a warning if the
checksum fails.
Can you test the diff below? Please send me a complete dmesg, and let
me know if there are any remaining problem with that machine.
Thanks,
Mark
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.278
diff -u -p -r1.278 acpi.c
--- acpi.c 18 Dec 2014 16:31:50 - 1.278
+++ acpi.c 10 Jan 2015 20:49:32 -
@@ -1042,10 +1042,9 @@ acpi_maptable(struct acpi_softc *sc, pad
if (acpi_map(addr, len, handle))
return NULL;
hdr = (struct acpi_table_header *)handle.va;
- if (acpi_checksum(hdr, len)) {
- acpi_unmap(handle);
- return NULL;
- }
+ if (acpi_checksum(hdr, len))
+ printf(\n%s: %s checksum error, DEVNAME(sc), sig);
+
if ((sig memcmp(sig, hdr-signature, 4)) ||
(oem memcmp(oem, hdr-oemid, 6)) ||
(tbl memcmp(tbl, hdr-oemtableid, 8))) {
Re: RSDT corruption, acpidump problems
From: Kasper Steensig Jensen ksj...@student.aau.dk Date: Tue, 6 Jan 2015 21:23:53 + On 2015/01/05 15:17, Kasper Steensig Jensen wrote: acpidump not working because corrupted RSDT. When the command acpidump -o mydump is run it gives the error apidump: RSDT is corrupted ACPI has been tested and is working on Debian, FreeBSD Can you get an acpidump from FreeBSD? so it can't be a problem with the laptop. Yes it can, but these other OS might be ignoring it. UKC disable mpbios 53 mpbios0 disabled why? Can you get an acpidump from FreeBSD? FreeBSD is currently not installed on the laptop but would a Debian acpidump be good enough? I can install FreeBSD if it's required. Might be. I'm not really familliar with the Linux acpidump tool, but if it dumps all the tables in raw format, it might be useful. The mailing lists will strip attachments, so best if you put it on a webserver somewhere from where we can download it. Anyway, what we need to figure out is why mapping the RSDT table fails. If you happen to have some hacking skills you could try to figure out which return NULL in sys/dev/acpi.c:acpi_maptable() you're hitting on that laptop.
Re: Thinkpad X230 resets at pckbd0 attach
Date: Tue, 30 Dec 2014 23:01:34 +0100 From: Alexander Bluhm alexander.bl...@gmx.net On Tue, Dec 30, 2014 at 10:06:09PM +0100, Martin Pieuchot wrote: Is it your console keyboard? I have only the keyboard that is build into the thinkpad. That is my console. No additional keyboard or serial connected. I have placed printf into all functions you mentiond. Normal output is now: func pckbc_attach_slot, line 269: start func pckbc_attach_slot, line 272: call config_found_sm pckbd0 at pckbc0 (kbd slot)func pckbdattach, line 370: start func pckbdattach, line 373: call pckbd_is_console func pckbdattach, line 380: call pckbd_set_xtscancode func pckbd_set_xtscancode, line 192: start func pckbd_set_xtscancode, line 283: end func pckbdattach, line 389: call pckbc_poll_cmd func pckbdattach, line 411: call pckbc_set_inputhandler func pckbc_isa_intr_establish, line 186: start func isa_intr_establish, line 307: start func isa_intr_establish, line 325: call intr_establish func intr_establish, line 339: start func intr_establish, line 457: end pckbc0: using irq 1 for kbd slot func pckbc_isa_intr_establish, line 196: end func pckbdattach, line 425: call config_found wskbd0 at pckbd0: console keyboard, using wsdisplay0 func pckbdattach, line 427: end func pckbc_attach_slot, line 287: end I am waiting for the next reset... Unfortunately there is no guarantee that the last few lines printed to dmesg actually survive the reboot. The printing will help a bit to narrow things down, but the reset might still happen after a line that doesn't show up in the retained dmesg. Serial console would help...
Re: readgptlabel() fails on incorrect size passed to free()
Date: Sat, 20 Dec 2014 14:17:04 +0100 From: David Imhoff dimhoff_de...@xs4all.nl Hi, When trying to get GPT working on the current OpenBSD snapshot I ran into a kernel crash. This is caused because the readgptlabel() passes an incorrect size to the last free() call in the function. The size is stored in a variable 'gpsz'. However this variable is defined twice, in the function scope and in the for scope. This is obviously incorrect. The patch below fixes this. Absolutely! Thanks, I've committed your diff. Index: sys/kern/subr_disk.c === RCS file: /cvs/src/sys/kern/subr_disk.c,v retrieving revision 1.174 diff -u -p -r1.174 subr_disk.c --- sys/kern/subr_disk.c 16 Dec 2014 18:30:04 - 1.174 +++ sys/kern/subr_disk.c 20 Dec 2014 13:14:41 - @@ -650,7 +650,6 @@ readgptlabel(struct buf *bp, void (*stra uint32_t ghsize; uint32_t ghpartsize; uint32_t ghpartnum; - size_t gpsz; /* read header record */ bp-b_blkno = DL_BLKTOSEC(lp, part_blkno) * DL_BLKSPERSEC(lp);
Re: Panic on removal of PCMCIA card 4 ports USB on HP avilion ze4300
Date: Wed, 17 Dec 2014 14:48:27 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
Hello Tilo,
Thanks for the report, diff below fixes it for me, could you try it?
Index: ehci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.171
diff -u -p -r1.171 ehci.c
--- ehci.c9 Dec 2014 07:05:06 - 1.171
+++ ehci.c17 Dec 2014 12:25:00 -
@@ -542,8 +542,8 @@ ehci_intr1(struct ehci_softc *sc)
sc-sc_bus.intr_context++;
sc-sc_bus.no_intrs++;
if (eintrs EHCI_STS_HSE) {
- printf(%s: unrecoverable error, controller halted\n,
-sc-sc_bus.bdev.dv_xname);
+ printf(%s: host controller halted\n,
+ sc-sc_bus.bdev.dv_xname);
sc-sc_bus.dying = 1;
sc-sc_bus.intr_context--;
return (1);
Martin, I think the real bug is slightly above this chunk. Upon
surprise unplug of the controller, we're supposed to hit the following
if-statement:
intrs = EHCI_STS_INTRS(EOREAD4(sc, EHCI_USBSTS));
if (intrs == 0x) {
sc-sc_bus.dying = 1;
return (0);
}
But if you look at the definition of EHCI_STS_INTRS(), you quickly
realize that code is unreachable. There's a similar problem in uhci(4).
The idea here is that reading a register from hardware that isn't
present will return 0x. It's best to check as many bits as
possible to distinguish this condition from the case where the
hardware genuinly has these bits set.
Untested diff below attempts to fix this.
Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.171
diff -u -p -r1.171 ehci.c
--- ehci.c 9 Dec 2014 07:05:06 - 1.171
+++ ehci.c 17 Dec 2014 14:30:16 -
@@ -524,11 +524,12 @@ ehci_intr1(struct ehci_softc *sc)
return (0);
}
- intrs = EHCI_STS_INTRS(EOREAD4(sc, EHCI_USBSTS));
+ intrs = EOREAD4(sc, EHCI_USBSTS);
if (intrs == 0x) {
sc-sc_bus.dying = 1;
return (0);
}
+ intrs = EHCI_STS_INTRS(intrs);
if (!intrs)
return (0);
Index: uhci.c
===
RCS file: /cvs/src/sys/dev/usb/uhci.c,v
retrieving revision 1.133
diff -u -p -r1.133 uhci.c
--- uhci.c 9 Dec 2014 07:05:06 - 1.133
+++ uhci.c 17 Dec 2014 14:30:16 -
@@ -1020,13 +1020,14 @@ uhci_intr1(struct uhci_softc *sc)
int status;
int ack;
- status = UREAD2(sc, UHCI_STS) UHCI_STS_ALLINTRS;
- if (status == 0)/* The interrupt was not for us. */
- return (0);
- if (status == 0x) {
+ status = UREAD2(sc, UHCI_STS);
+ if (status == 0x) {
sc-sc_bus.dying = 1;
return (0);
}
+ status = UHCI_STS_ALLINTRS;
+ if (status == 0)/* The interrupt was not for us. */
+ return (0);
#ifdef UHCI_DEBUG
if (uhcidebug 15) {
Re: AlphaServer DS10L hangs on boot
Date: Fri, 28 Nov 2014 23:13:05 +0100 From: Tobias Ulmer tobi...@tmux.org pci0 at tsp0 bus 0 0:9:0: io address conflict 0x10100/0x80 0:9:0: mem address conflict 0x10a1000/0x400 0:11:0: io address conflict 0x10180/0x80 0:11:0: mem address conflict 0x10a1400/0x400 0:13:0: io address conflict 0x1f0/0x10 0:13:0: io address conflict 0x3f4/0x4 0:13:0: io address conflict 0x170/0x10 0:13:0: io address conflict 0x374/0x4 0:13:0: io address conflict 0x10210/0x10 0:17:0: io address conflict 0x1/0x100 0:17:0: mem address conflict 0x10a/0x1000 Already fixed. Wait for a new kernel.
Re: panic: lapic_set_lvt at boot
Date: Sun, 19 Oct 2014 17:59:29 +0200 From: Julien Dehaese jdeha...@gmail.com Hi, I'm trying to get openbsd running on an Intel Baytrail motherboard with a SSD disk. Motherboard is Asrock Q1900-ITX, 4GB RAM Kingston SSD model : SV300S37A60G Steps to reproduce: - performed standard install of openbsd 5.6-current (19/10/2014) - today. All went well during the install until the first reboot after install. - during the first reboot after install, openbsd raises a panic : lapic_set_lvt - ran the trace and ps when debugger prompt appeared. Same error occurs at each reboot. Does a GENERIC (non-MP) kernel boot on the machine? The installer should have installed one as bsd.sp, which you can specify at the boot prompt. If that kernel boots, can you send use acpidump(8) output for this machine? Thanks, Mark
Re: X -configure Caught Signal 11
Date: Tue, 14 Oct 2014 15:45:28 +0200 (CEST) From: j...@navratil.cz autoconfiguration start X, but touchpad is not working fully, The reason for need for manual configuration is, that touchpad dosn't support right click, middle click and movement (click + movement) The -configure option is known to be broken. We have not spent much effort on fixing it, as the option simply isn't useful these days. It won't help you solve your touchpad issue. Take a look at the xinput(1) manual page instead. Cheers, Mark
Re: rc.shutdown: No powerdown
From: Theo de Raadt dera...@cvs.openbsd.org Date: Mon, 21 Jul 2014 14:32:16 -0600 running i386-current I noticed that despite having set powerdown=YES in rc.shutdown the system halts with Press any key to reboot. $ cat /etc/rc.shutdown | grep power powerdown=YES # set to YES for powerdown Did the logic change here? Yes, the logic changed. /etc/rc no longer evaluates other scripts, pulling in damage to it's variable space. Use halt -p or shutdown -p if you want to power down. I understand that there is contention over powerdown vs non-powerdown, but perhaps bringing this to the fore will result in a big decision about what to do. Any reason not to turn this into a rc.conf.local setting?
Re: Asus Eee PC 1000 hangs on 27th Jun 2014 snapshot
Date: Sun, 13 Jul 2014 12:44:12 +0200
From: Alexander Schrijver a...@flupzor.nl
On Sat, Jul 12, 2014 at 02:29:52PM +0200, Mark Kettenis wrote:
One thing to try is to change the parameter passed to the INIT AML
call in acpiasus_init() from 0x40 to something else. I'd start with
trying 0.
Just a small update: i've tried 0x00, 0x01, 0x04, 0x10, 0x400, 0x4000 and all
give me a blank screen.
Does the diff below fix things?
Index: dsdt.c
===
RCS file: /home/cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.212
diff -u -p -r1.212 dsdt.c
--- dsdt.c 12 Jul 2014 18:48:17 - 1.212
+++ dsdt.c 20 Jul 2014 09:37:30 -
@@ -2311,7 +2311,8 @@ aml_rwgas(struct aml_value *rgn, int bpo
aml_bufcpy(vbit, 0, tbit, bpos, blen);
} else {
/* Write bits to opregion */
- if (AML_FIELD_UPDATE(flag) == AML_FIELD_PRESERVE) {
+ if (AML_FIELD_UPDATE(flag) == AML_FIELD_PRESERVE
+ (bpos != 0 || blen != tlen)) {
acpi_gasio(acpi_softc, ACPI_IOREAD, type, pi.addr,
sz, tlen 3, tbit);
} else if (AML_FIELD_UPDATE(flag) == AML_FIELD_WRITEASONES) {
Re: Asus Eee PC 1000 hangs on 27th Jun 2014 snapshot
Date: Sat, 12 Jul 2014 13:49:02 +0200 From: Alexander Schrijver a...@flupzor.nl On Fri, Jul 11, 2014 at 01:47:59PM +0300, Paul Irofti wrote: On Fri, Jul 11, 2014 at 08:15:47AM +0200, Alexander Schrijver wrote: On Thu, Jul 10, 2014 at 05:42:54AM +0100, Mikolaj Kucharski wrote: Looking at the lines printed, my impression was that acpiasus0 at acpi0 is the last line before screen goes blank, so I've disabled acpiasus and it did help and machine boots fine. Here is dmesg from that boot: I'm seeing the exact same thing. When I disable acpiasus my machine boots fine as well. I've sent the acpidumps privately to Mark because the list strips them. Can you try the following diff and let me know what happens: With this diff the system boots fine. I'll try to see if I can trace this further. One thing to try is to change the parameter passed to the INIT AML call in acpiasus_init() from 0x40 to something else. I'd start with trying 0.
Re: Asus Eee PC 1000 hangs on 27th Jun 2014 snapshot
Date: Sun, 6 Jul 2014 22:52:21 +0200 From: Alexander Schrijver a...@flupzor.nl On Sun, Jul 06, 2014 at 08:40:53PM +0200, Alexander Schrijver wrote: I have the same problem with my Asus Eee PC 901. When I disabled acpi during boot, using UKC, it booted fine. dmesg below. I'm now building the kernel from -current source. I'll go backwards from there. I've tracked it down to this commit: revision 1.259 date: 2014/06/23 18:47:41; author: kettenis; state: Exp; lines: +22 -27; SystemMemory is used to access memory mapped registers on some machines, so we must use the bus_space(9) API to access it instead of memcpy(9). Also make sure we properly align access to fields that need more than byte alignment. ok guenther@ Thanks, please send me acpidump -o output, and indicate at exactly what the last dmesg line is that gets prited. Might be necessary to disable inteldrm to pin that down. Thanks, Mark
Re: Asus Eee PC 1000 hangs on 27th Jun 2014 snapshot
Date: Sun, 29 Jun 2014 00:25:44 +0100 (IST) From: miko...@kucharski.name Just upgraded my Asus Eee PC 1000 to the latest snapshot and it hungs around time when console changes to higher resolution. Machine stays with blank screen forever. After disabling acpi0 during boot up I'm able to start the machine. Below I'm inlining dmesgs from previous working snapshot and from broken one with acpi0 disabled. Does a kernel built from current sources show the same problem? If so, can you find out what commit broke things?
Re: Blank screen when X is started after suspend/resume
Date: Thu, 5 Jun 2014 23:26:24 -0400 (AMT) From: dud...@gmail.com Synopsis:If X is started anytime after resume, screen goes blank Category:system amd64 Environment: System : OpenBSD 5.5 Details : OpenBSD 5.5-current (GENERIC.MP) #166: Tue Jun 3 21:09:08 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: If X is started anytime after suspend/resume, screen goes blank in ttyC4 and stays off (even backlight is off), but X keeps responsive as I am able to leave it by pressing blindly CMS-q in cwm. It's possible to change terminals and the other ttyC# work fine. Restarting X doesn't help. /var/log/message and Xorg.0.log shows nothing unusual. How-To-Repeat: Suspend (zzz or lid), resume, startx. Fix: Only rebooting allows use X again. Suspend/resume after X is already started works fine. Starting X before suspend/resume also works fine. Known problem. Almost certainly a bug in the (Linux) drm code. Not obvious where though. Not really high on my priority list to fix this though. Kinda hope that this will disappear all by itself at some point if/when we update the drm code to a more recent version.
Re: radeondrm: losing console, X initially garbled
Date: Sun, 23 Mar 2014 14:37:49 +0100 From: Thomas Pfaff tpf...@tp76.info When this machine boots up it switches successfully to radeondrm but when X starts the display gets garbled [1]. Switching to the console and back again fixes the issue [2] but now the console is blank with the cursor blinking top left corner. It still accepts input though, and the X display is still fine. Without at least your Xorg.0.log there is not much we can do for you.
Re: ehci: kernel diagnostic assertion (reg 0x3) == 0 failed
Date: Sun, 23 Mar 2014 17:53:47 +0100 (CET) From: Donovan Watteau tso...@gmail.com ehci0 at pci0 dev 3 function 3 SiS 7002 USB rev 0x00: apic 2 int 23 panic: kernel diagnostic assertion (reg 0x3) == 0 failed: file ../../../ arch/amd64/pci/pci_machdep.c, line 272 Stopped atDebugger+0x5: leave Debugger() at Debugger+0x5 panic() at panic+0xee __assert() at __assert+0x21 pci_conf_read() at pci_conf_read+0xdd ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b ehci_pci_attach() at ehci_pci_attach+0x22a config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x447 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc end trace frame: 0x81edce80, count: 0 RUN AT LEASE 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger() at Debugger+0x5 panic() at panic+0xee __assert() at __assert+0x21 pci_conf_read() at pci_conf_read+0xdd ehci_pci_takecontroller() at ehci_pci_takecontroller+0x6b ehci_pci_attach() at ehci_pci_attach+0x22a config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x447 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc mainbus_attach() at mainbus_attach+0x163 config_attach() at config_attach+0x1bc cpu_configure() at cpu_configure+0x17 main() at main+0x41c end trace frame: 0x0, count: -14 ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *0 -1 0 0 7 0x200 swapper ddb Can you send the output of pcidump -vxx from that machine?
Re: radeondrm: losing console, X initially garbled
Date: Sun, 23 Mar 2014 16:57:37 +0100 From: Thomas Pfaff tpf...@tp76.info On Sun, 23 Mar 2014 16:46:52 +0100 (CET) Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sun, 23 Mar 2014 14:37:49 +0100 From: Thomas Pfaff tpf...@tp76.info When this machine boots up it switches successfully to radeondrm but when X starts the display gets garbled [1]. Switching to the console and back again fixes the issue [2] but now the console is blank with the cursor blinking top left corner. It still accepts input though, and the X display is still fine. Without at least your Xorg.0.log there is not much we can do for you. Oops, sorry about that! [16.186] (==) Using config file: /etc/xorg.conf So what's in your config file? My bet is that you're forcing Xorg to use the vesa(4) driver there. That doesn't quite work anymore now that we have KMS. If this was the only reason you created an xorg.conf, delete it. Otherwise remove that the lines that configure the vesa(4) driver. The radeon(4) driver should work with your hardware now.
Re: volume keys not working on thinkpad x201
Date: Sun, 23 Mar 2014 14:51:24 -0400 From: Ted Unangst t...@tedunangst.com On Sun, Mar 23, 2014 at 18:24, Miod Vallat wrote: Slamming outputs.master=255 would be way worse than the current situation. There are sounds, like the beep made when suspending and resuming, that do not go through sndiod. Maxing out the hardware volume is not a viable option. suspend/resume and text console beeps usually run through pcppi(4), which volume is not necessarily controlled by the audio device (especially on systems without onboard audio devices). There is no easy way to have the volume settings shown by mixerctl apply to this. And, to the best of my knowledge, the kernel has no way to know whether the pcppi wave generator goes through the audio device, or directly reaches the speaker. All true. Since we're talking about thinkpads, I will note that outputs.master does control the volume of the beeper because in this particular case it is wired up that way on most models I'm familiar with. I don't expect or ask that mixerctl work with the beeper, just pointing out that we cannot assume the opposite, that the audio mixer won't affect the beeper. Note that on some machines where the beeper goes through the hardware mixer, there is an inputs.beep that controls its (relative) volume.
Re: volume keys not working on thinkpad x201
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=relo.ch; s=relo.ch-dec2013; t=1395521365; bh=KDZL4Qy+ccBjd0+xefXm0iLbwWEZHI4Iu3fQGzrl1iA=; h=Date:Message-Id:To:Subject:From:Cc:Reply-To; b=NKOibw5wzjqXx1J8o4fy1FLpQ6+FfabL0zr7kgluhyyV/jBfAeNDqqQpTZr5lmniW NAvlaE2xKhxMYenj8BYRGzES8CuQpxh+reyn21jT39vrQJMRSRVCUcnN3E9BxN9zCC Wa576rtfPkhvnlhVmIpXEn2gep88dpTwk3F0558o= Date: Sat, 22 Mar 2014 21:49:19 +0100 (CET) From: remi.loche...@relo.ch With the snapshot from March 22 the volume keys on my ThinkPad x201 do not work anymore. mixerctl still works. Before I was running the snapshot from Feb 3 with which the volume keys worked. The volume keys still work. What changed is that the volume keys no longer control the hardware mixer directly anymore when you're running X. Instead the volume key events are passed to whatever X application is running. If you're running mplayer, you'll see that the volume keys still control the volume and give you feedback on the screen. If you run gnome, you'll see something similar. The problem you might experience is that the x201 boots up with the hardware mixer set to a fairly low level. And the software volume control in most X applications won't change it so you won't be able to go any higher by just pressing the volume keys.
Re: pipe a force quirk = intagp: binding into stolen memory!
Date: Tue, 4 Mar 2014 13:14:43 +0100 From: Marcus MERIGHI mcmer-open...@tor.at pinging to make sure it's not lost accidentally (but intentionally :-) Bleah, your original report fell through the cracks here. Does the diff below help? Index: agp_i810.c === RCS file: /home/cvs/src/sys/dev/pci/agp_i810.c,v retrieving revision 1.82 diff -u -p -r1.82 agp_i810.c --- agp_i810.c 20 Feb 2014 22:18:22 - 1.82 +++ agp_i810.c 4 Mar 2014 22:45:35 - @@ -442,6 +442,9 @@ agp_i810_attach(struct device *parent, s printf(: no preallocated video memory\n); #endif + /* XXX */ + isc-stolen = 0; + /* GATT address is already in there, make sure it's enabled */ gatt-ag_physical = READ4(AGP_I810_PGTBL_CTL) ~1; break;
Re: Bad return value for getpwnam_r et al
Date: Mon, 24 Feb 2014 16:51:42 +0100
From: Ingo Schwarze schwa...@usta.de
Hi Stuart,
Stuart Henderson wrote on Sun, Feb 23, 2014 at 02:22:47PM +:
btw, here are results from a search for getpw(nam|uid)_r in unpacked
ports source, after removing a bunch of autoconf checks etc.
Wow, these are nearly a hundred ports. It is not feasible to audit
all that. Besides, my patches also imply slight changes to the
behaviour of getgr{nam,gid}_r() (when called with errno already set)
and to getpw{nam,uid}() (which may now set errno even when finding
a match and will no longer set errno with the third patch in that
case). So your list is too long for a complete audit even though
it is incomplete.
Anyway, i looked at seven examples from your list, choosing ports
from different categories. The results are, if i read the code
correctly:
- I found no cases where my patches might break something.
- One of the seven ports would be significantly improved (postfix).
- Three ports get minor improvements (gdm, glib2, ruby).
- For three ports, it makes no difference (gmake, postgres, gnutls).
- Nearly all changes in behaviour are due to the first patch -
change of the return values - and among these, nearly all
are due to changing the return value from 1 to 0 when not
finding a match, but when there is no error.
- The errno variable and the exact return value (as opposed to
merely whether it's 0 or non-0) are rarely looked at.
- For detailed results, look at the very end of this mail.
Even after unlock, i don't think it would be reasonable to try to
evaluate all the consequences of the changes. After unlock, we
should just commit all the changes such that libc behaves reasonably,
then watch out for any fallout.
What do we commit now?
After this review, i'd say:
* PLEASE somebody give me an OK just for the first patch.
It actually improves various ports.
It doesn't look like it's going to break stuff.
(Theo said he is not opposed to fixing part of this,
but cannot look at the details right now.)
* Let's not commit the second patch
(avoid errno clobbering as suggested by guenther@).
It doesn't seem to matter much, so let's avoid any risk.
* Let's not commit the third patch
(let getpw*_r() not touch errno as suggested by kettenis@).
Even though i didn't find any port where this might matter,
i still consider it more risky than the first two patches.
Here is the first patch, again.
While I agree this is a step in the right direction, and probably not
going to break stuff, I'm not sure this is the time to change this.
It does change the behaviour, and some ports will end up in codepaths
that have not been tested on OpenBSD.
Index: getpwent.c
===
RCS file: /cvs/src/lib/libc/gen/getpwent.c,v
retrieving revision 1.48
diff -u -p -r1.48 getpwent.c
--- getpwent.c15 Nov 2013 22:32:55 - 1.48
+++ getpwent.c19 Feb 2014 16:36:48 -
@@ -708,8 +708,12 @@ getpwnam_r(const char *name, struct pass
{
struct passwd *pwret = NULL;
int flags = 0, *flagsp;
+ int my_errno = 0;
+ int saved_errno;
_THREAD_PRIVATE_MUTEX_LOCK(pw);
+ saved_errno = errno;
+ errno = 0;
if (!_pw_db !__initdb())
goto fail;
@@ -733,8 +737,12 @@ getpwnam_r(const char *name, struct pass
fail:
if (pwretp)
*pwretp = pwret;
+ if (pwret == NULL)
+ my_errno = errno;
+ if (!errno)
+ errno = saved_errno;
_THREAD_PRIVATE_MUTEX_UNLOCK(pw);
- return (pwret ? 0 : 1);
+ return (my_errno);
}
struct passwd *
@@ -753,8 +761,12 @@ getpwuid_r(uid_t uid, struct passwd *pw,
{
struct passwd *pwret = NULL;
int flags = 0, *flagsp;
+ int my_errno = 0;
+ int saved_errno;
_THREAD_PRIVATE_MUTEX_LOCK(pw);
+ saved_errno = errno;
+ errno = 0;
if (!_pw_db !__initdb())
goto fail;
@@ -778,8 +790,12 @@ getpwuid_r(uid_t uid, struct passwd *pw,
fail:
if (pwretp)
*pwretp = pwret;
+ if (pwret == NULL)
+ my_errno = errno;
+ if (!errno)
+ errno = saved_errno;
_THREAD_PRIVATE_MUTEX_UNLOCK(pw);
- return (pwret ? 0 : 1);
+ return (my_errno);
}
struct passwd *
Index: getgrent.c
===
RCS file: /cvs/src/lib/libc/gen/getgrent.c,v
retrieving revision 1.38
diff -u -p -r1.38 getgrent.c
--- getgrent.c17 Apr 2013 17:40:35 - 1.38
+++ getgrent.c19 Feb 2014 16:36:49 -
@@ -134,6 +134,7 @@ getgrnam_r(const char *name, struct grou
if (bufsize GETGR_R_SIZE_MAX)
return ERANGE;
errnosave = errno;
+ errno = 0;
*result = getgrnam_gs(name, grp, (struct
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
Date: Sun, 23 Feb 2014 13:31:10 + From: Stuart Henderson st...@openbsd.org On 2014/02/23 10:40, Remi Locherer wrote: On Sat, Feb 22, 2014 at 07:14:01PM +0100, Mark Kettenis wrote: From: Theo de Raadt dera...@cvs.openbsd.org Date: Sat, 22 Feb 2014 09:55:41 -0700 This menas the acpitz bug must be found, and fixed. You need to reach out to an acpi hacker, like pirofti, to help diagnose the AML issue which underlies this. I had a quick look at the AML and it looks is if the embedded controller is involved in reading the temperature. Perhaps SMM is touching it behind our back, so I looked at the global lock code again that is supposed to protect against that happening. Noticed that acpiec(4) tries to acquire the global lock, but doesn't actually check whether it got it. The diff below fixes this by unifying the code that checks for recursion and does the spinning. Might fix things, or might lock up the machine solidly. Only one way to find out... Thanks for having a look. I didn't notice any difference after I applied your patch: - no lock up - same wrong value for acpitz0 - battery not detected - no diff in dmesg (beside the build time of the kernel) If this doesn't help, you should check whether memory at the following addresses: 0xDAF7CE18 0xDAF9EF18 0xDAF7ADC0 0xDAF79F98 isn't actually marked as available by the BIOS. ACPI apparently stored important data at those addresses, but if OpenBSD thinks that memory is available and overwrites things, bad things will happen. I believe the easiest way to find out is to type machine memory at the boot prompt. I can't see the first few lines of the machine memory output. Is there a way to scroll back or use some sort of paging? Since I'm not sure how to interprete the numbers I uploaded a photo from the output: http://picpaste.com/samsung900X3F-machine-memory.png Remi I think you've got enough of it; the addresses above are covered by this region Region 11: type 4 at 0xdaeef000 for 704KB $ moo 0xdaeef000+(704*1024) 0xdaf9f0003673812992 i.e. marked as available. Well Type 4 is ACPI NVS, which means it isn't regarded as free memory by OpenBSD. Everything seems to point into the direction of a bug in apciec(4).
Re: [solved] strange artefacts with inteldrm on samsung 900X3F
Date: Thu, 20 Feb 2014 22:49:41 +0100 From: Remi Locherer remi.loche...@relo.ch I installed the snapshot from February 17 and the artefacts in X are gone. X now works fine on the Samsung 900X3F. Thanks! On Mon, Oct 28, 2013 at 08:36:14AM +0100, Remi Locherer wrote: Synopsis: strange artefacts with inteldrm on samsung 900X3F Environment: System : OpenBSD 5.4 Details : OpenBSD 5.4-current (GENERIC.MP) #92: Sat Oct 26 20:22:52 MDT 2013 Heh, well, some significant fixes went in since then ;) Glad it's working.
Re: panic: pmap_tmpunmap_pa: our pte invalid?
Date: Thu, 6 Feb 2014 23:53:49 + From: Stuart Henderson st...@openbsd.org On 2014/02/06 20:26, Tim van der Molen wrote: Occasionally, after running startx I get a panic. Handtyped ddb output and dmesg below. Try a newer kernel, pretty sure this is the bug that kettenis fixed in sys/dev/pci/drm/i915/i915_gem.c 1.69. This is not in snapshots yet afaik. Unfortunately, this probably won't fix the issue. The problem here is that copyin/out can sleep if a page needs to be faulted in. The fast path code called from i915_gem_shmem_pwrite() is written with the assumption that this doesn't happen. I could simply disable the fast path code here, but there might be a better solution. Still thinking about it...
Re: Issues on Acer Aspire E1 572G
When I tested again bsd.rd after the acpi issue was fixed, I noticed that my laptop experiences the issue only when I touch the touchpad. If I pay attention not to touch the touchpad while typing, the keyboard works correctly and the kernel doesn't print any error message. 2014/1/6 Brad Smith b...@comstyle.com: On 22/12/13 10:13 AM, mark rowland wrote: I'm having some issues running OpenBSD on my notebook Acer Aspire E1 572G. 1) During the installation of 5.4 weird things happened with the keyboard: typing with the keyboard was slow, sometimes typed characters were repeated, the kernel gave several times the error message pckbcintr: no dev for slot 1. In [1] you can find the output of dmesg from the 5.4 install media. I had the same issue during the installation of the latest snapshot. After installation the keyboard works fine though. I have never seen this issue before, but I just installed a ThinkPad T440s and it experiences this same issue. Searching via Google shows this isn't new and it happens on both amd64 and i386. It appears that this only affects the RAMDISK media for some reason. http://www.darwinsys.com/openbsd/laptops.html http://daemonforums.org/showthread.php?t=2846 http://openbsd.7691.n7.nabble.com/Dell-Latitude-E6420-issues-not-working-td60545.html
Re: Issues on Acer Aspire E1 572G
I found a bug in brightness control. According to wsconsctl, display brightness is initially set to 90%: # wsconsctl | grep brightness wsconsctl: Use explicit arg to view keyboard.map. display.brightness=90.00% # If I lower the brightness, wsconsctl says it has lowered it: # wsconsctl display.brightness=10 display.brightness - 10.00% # wsconsctl | grep brightness wsconsctl: Use explicit arg to view keyboard.map. display.brightness=10.00% # But even if wsconsctl says that now brightness has been set to 10%, the brightness of my display has not changed. Same thing if try to change the brightness in Xorg with xbacklight: $ xrandr --prop Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 eDP1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm [...] BACKLIGHT: 90 range: (0, 100) Backlight: 90 range: (0, 100) scaling mode: Full aspect supported: None, Full, Center, Full aspect Broadcast RGB: Full supported: Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on 1366x768 60.0*+ 1024x768 60.0 800x60060.3 56.2 640x48059.9 [...] $ xbacklight -set 10% $ xrandr --prop Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 eDP1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 194mm [...] BACKLIGHT: 10 range: (0, 100) Backlight: 10 range: (0, 100) scaling mode: Full aspect supported: None, Full, Center, Full aspect Broadcast RGB: Full supported: Full, Limited 16:235 audio: auto supported: force-dvi, off, auto, on 1366x768 60.0*+ 1024x768 60.0 800x60060.3 56.2 640x48059.9 [...] $ According to xrandr brightness has been changed, but this is wrong. The brightness of my display did not change. In case the issue is related to acpi, here I uploaded a dmesg from a -current kernel built with ACPI_DEBUG: https://drive.google.com/file/d/0B5nVEarf-0aCeUVvQWdiUjRJYW8/edit?usp=sharing
Re: Issues on Acer Aspire E1 572G
Thank you, the patch fixed the audio issue. 2013/12/30 Jonathan Gray j...@jsg.id.au: On Sun, Dec 29, 2013 at 10:24:27PM +0100, mark rowland wrote: I did a fresh install of the latest snapshot, audio is still buggy. try this: Index: azalia.c === RCS file: /cvs/src/sys/dev/pci/azalia.c,v retrieving revision 1.208 diff -u -p -r1.208 azalia.c --- azalia.c6 Dec 2013 21:03:03 - 1.208 +++ azalia.c30 Dec 2013 02:27:09 - @@ -463,6 +463,7 @@ azalia_configure_pci(azalia_t *az) case PCI_PRODUCT_INTEL_6SERIES_HDA: case PCI_PRODUCT_INTEL_7SERIES_HDA: case PCI_PRODUCT_INTEL_8SERIES_HDA: + case PCI_PRODUCT_INTEL_8SERIES_LP_HDA: reg = azalia_pci_read(az-pc, az-tag, INTEL_PCIE_NOSNOOP_REG); reg = INTEL_PCIE_NOSNOOP_MASK;
Re: Issues on Acer Aspire E1 572G
I did a fresh install of the latest snapshot, audio is still buggy. I'm attaching a dmesg of the default kernel, a dmesg of a kernel I built after adding the option AZALIA_DEBUG, the output of mixerctl and the output of audioctl. After more testing, I could replicate the following steps: 1) I boot OpenBSD on my machine and login 2) I try to play some .ogg file with ogg123 or some .wav file with aucat -i, but I hear a grinding sound and in audioctl play.samples remains 0. 3) I try to play again the file and I hear nothing. Also ogg123/aucat seems stuck, thus I kill the process. 4) I stop sndiod and it is not very responsive: # /etc/rc.d/sndiod stop sndiod(failed) # /etc/rc.d/sndiod stop sndiod(ok) # ps aux | grep sndiod _sndio 19767 0.0 0.0 680 984 ?? SEs 8:27PM0:00.05 (sndiod) # After some time (10-15 secs) it finally exits, then I restart it: # /etc/rc.d/sndiod start sndiod(ok) # 5) I try to play again the file. If the machine is idle, I hear a noise that is different from the grinding sound I heard in step 2. If concurrently I'm doing some work (building the kernel or running ls -R /) I hear the audio (a bit distorted) of the .ogg/.wav file and audioctl shows that play.samples is increasing. With sndiod not running (disabled in /etc/rc.conf.local), I could replicate the following steps: 1) I boot OpenBSD on my machine and login. 2) I try to play some .wav file with aucat -i, I hear a grinding sound and play.sample remains 0. After some time the sound stops, aucat seems stuck, I kill it. 3) I try to play again the file. If the machine is idle I hear noise, if I am doing some work I hear the audio (a bit distorted) of the .wav file and play.samples increases. -- [dmesg of default kernel] OpenBSD 5.4-current (GENERIC.MP) #222: Fri Dec 27 22:33:50 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80clock_battery real mem = 6304821248 (6012MB) avail mem = 6128795648 (5844MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6e60 (27 entries) bios0: vendor Insyde Corp. version V2.10 date 10/07/2013 bios0: Acer Aspire E1-572G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI FPDT MSDM ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP SSDT SSDT SSDT SSDT acpi0: wakeup devices P0P1(S4) EHC1(S3) XHC_(S3) HDEF(S4) TPD4(S4) TPD7(S0) TPD8(S0) PXSX(S4) RP03(S4) PEGP(S4) PEGA(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEG0(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2295.04 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2294.70 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2294.70 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2294.70 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus -1 (RP01) acpiprt3
Re: Issues on Acer Aspire E1 572G
I encountered a new issue, audio appears to be broken: if I watch a
video on Youtube with Firefox, instead of hearing the audio of the
video
I hear a grinding sound. The same happens if I play a .wav file with
aucat. At the end of the message are the output of audioctl and
mixerctl.
As suggested by the faq, I did this test:
# audioctl play.{seek,samples,errors}
play.seek=0
play.samples=0
play.errors=0
# cat /dev/audio /dev/zero
[1] 11754
# audioctl play.{seek,samples,errors}
play.seek=57600
play.samples=0
play.errors=0
# audioctl play.{seek,samples,errors}
play.seek=57600
play.samples=0
play.errors=0
# audioctl play.{seek,samples,errors}
play.seek=57600
play.samples=0
play.errors=0
# kill %1
# fg %1
cat /dev/audio /dev/zero
Terminated
#
The faq say that since I'm sending zeroes to the device, I shouldn't
hear anything, but I hear noise.
---
[audioctl]
name=HD-Audio
version=1.0
config=azalia1
encodings=slinear_le:16:2:1,slinear_le:20:4:1,slinear_le:24:4:1
properties=full_duplex,independent
full_duplex=0
fullduplex=0
blocksize=9600
hiwat=6
lowat=4
output_muted=0
monitor_gain=0
mode=
play.rate=48000
play.channels=2
play.precision=16
play.bps=2
play.msb=1
play.encoding=slinear_le
play.gain=126
play.balance=32
play.port=0x0
play.avail_ports=0x0
play.seek=0
play.samples=0
play.eof=0
play.pause=0
play.error=0
play.waiting=0
play.open=0
play.active=0
play.buffer_size=65536
play.block_size=9600
play.errors=0
record.rate=48000
record.channels=2
record.precision=16
record.bps=2
record.msb=1
record.encoding=slinear_le
record.gain=124
record.balance=32
record.port=0x0
record.avail_ports=0x0
record.seek=0
record.samples=0
record.eof=0
record.pause=0
record.error=0
record.waiting=0
record.open=0
record.active=0
record.buffer_size=65536
record.block_size=9600
record.errors=0
[mixerctl]
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off [ off on ]
record.adc-0:1=124,124
record.adc-2:3_mute=off [ off on ]
record.adc-2:3=124,124
inputs.mix_source= { mic }
inputs.mix_mic=120,120
inputs.mix2_source=dac-2:3,mix { dac-2:3 mix }
inputs.mix3_source=dac-0:1,mix { dac-0:1 mix }
outputs.spkr_source=mix2 [ mix2 ]
outputs.spkr_mute=off [ off on ]
outputs.spkr_eapd=on [ off on ]
inputs.mic=85,85
outputs.mic_dir=input-vr80 [ none output input input-vr0 input-vr50
input-vr80 input-vr100 ]
outputs.hp_source=mix3 [ mix2 mix3 ]
outputs.hp_mute=off [ off on ]
outputs.hp_boost=off [ off on ]
record.adc-2:3_source=mic,mix { mic mix }
record.adc-0:1_source=mic,mix { mic mix }
outputs.hp_sense=unplugged [ unplugged plugged ]
outputs.spkr_muters=hp { hp }
outputs.master=126,126
outputs.master.mute=off [ off on ]
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp { dac-2:3 dac-0:1 spkr mic hp }
record.volume=124,124
record.volume.mute=off [ off on ]
record.volume.slaves=adc-0:1,adc-2:3 { adc-0:1 adc-2:3 mic }
Re: T410i: resume broken with amd64/bsd.mp and revision 1.249 of acpi.c
Date: Mon, 23 Dec 2013 10:41:53 +0100 From: Dawe dawed...@gmx.de Hi, revision 1.249 (restore hw.setperf...) of acpi.c makes resume hang on my T410i running the amd64 mp kernel. The sp kernel is still able to resume the machine after suspending. With the mp kernel the console screen is restored and the power led and the moon-shaped led start to blink rapidly but don't stop anymore. There's no keyboard interaction possible. Going back to revision 1.248 makes the mp kernel resume again. Thanks for the report. Interesting to see that the sp kernel doesn't show the issue. That might give me some clue to what's going wrong here. I've reverted the commit for now.
Re: Issues on Acer Aspire E1 572G
Date: Sun, 22 Dec 2013 16:13:54 +0100 From: mark rowland markro...@gmail.com I'm having some issues running OpenBSD on my notebook Acer Aspire E1 572G. You should run -current on new hardware like that.
Re: Issues on Acer Aspire E1 572G
Date: Mon, 23 Dec 2013 03:55:14 +1100
From: Jonathan Gray j...@jsg.id.au
2) As you can read from dmesg, both wired (BCM57786) and wireless lan
(Atheros 956x) don't get recognized.
Broadcom BCM57786 rev 0x01 at pci1 dev 0 function 0 not configured
That is perhaps manageable with a minor diff to bge?
Might be as simple as the diff below. The chip documentation doesn't
mention any differences between the BCM57785 and BCM57786.
Index: if_bge.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.343
diff -u -p -r1.343 if_bge.c
--- if_bge.c6 Dec 2013 21:03:03 - 1.343
+++ if_bge.c22 Dec 2013 17:28:10 -
@@ -306,6 +306,7 @@ const struct pci_matchid bge_devices[] =
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM57780 },
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM57781 },
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM57785 },
+ { PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM57786 },
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM57788 },
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM57790 },
{ PCI_VENDOR_BROADCOM, PCI_PRODUCT_BROADCOM_BCM57791 },
@@ -2522,6 +2523,7 @@ bge_attach(struct device *parent, struct
case PCI_PRODUCT_BROADCOM_BCM57766:
case PCI_PRODUCT_BROADCOM_BCM57781:
case PCI_PRODUCT_BROADCOM_BCM57785:
+ case PCI_PRODUCT_BROADCOM_BCM57786:
case PCI_PRODUCT_BROADCOM_BCM57791:
case PCI_PRODUCT_BROADCOM_BCM57795:
sc-bge_chipid = pci_conf_read(pc, pa-pa_tag,
Re: Issues on Acer Aspire E1 572G
@Jonathan: I built a new kernel from -current after applying your patch, but I didn't find any difference. The console framebuffer works, X11 works (and it uses inteldrm as expected), but the kernel gives those error messages. Thanks for the clarification about the Radeon HD 8670, I wasn't sure about the support status of that gpu on OpenBSD because man radeon says that the HD 8000 series is supported. @Kettenis: Thanks, I applied your patch and wired lan now works. bge0 at pci1 dev 0 function 0 Broadcom BCM57786 rev 0x01, unknown BCM57766 (0x57766001): msi, address 20:1a:06:6f:72:2e brgphy0 at bge0 phy 1: BCM57765 10/100/1000baseT PHY, rev. 1 Here is the output of dmesg from a -current system with applied both Jonathan's and Kettenis' patches: OpenBSD 5.4-current (GENERIC.MP) #0: Sun Dec 22 20:07:06 CET 2013 r...@foo.my.domain:/home/tmp/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80clock_battery real mem = 6304821248 (6012MB) avail mem = 6128795648 (5844MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6e60 (27 entries) bios0: vendor Insyde Corp. version V2.10 date 10/07/2013 bios0: Acer Aspire E1-572G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI FPDT MSDM ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP SSDT SSDT SSDT SSDT acpi0: wakeup devices P0P1(S4) EHC1(S3) XHC_(S3) HDEF(S4) TPD4(S4) TPD7(S0) TPD8(S0) PXSX(S4) RP03(S4) PEGP(S4) PEGA(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEG0(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2295.05 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2294.70 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2294.70 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2294.70 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus -1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus 1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06)### AML PARSE ERROR (0xde89): Undefined name: AR08 error evaluating: \\_SB_.PCI0.RP06._PRT : no PCI interrupt routing table acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiec0 at acpi0 acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpicpu2 at acpi0: C1, PSS acpicpu3 at acpi0: C1, PSS acpibat0 at acpi0: BAT1 model x serial xx type Lion oem SANYO acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 2295 MHz: speeds: 2401, 2400, 2300, 2200, 2000, 1900, 1800, 1700, 1500, 1400, 1300, 1200, 1100, 900, 800, 768 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0
Re: Issues on Acer Aspire E1 572G
Intel 8 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured Intel 8 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured azalia1 at pci0 dev 27 function 0 Intel 8 Series HD Audio rev 0x04: msi azalia1: codecs: Realtek/0x0282 audio0 at azalia1 ppb0 at pci0 dev 28 function 0 Intel 8 Series PCIE rev 0xe4: msi pci1 at ppb0 bus 1 bge0 at pci1 dev 0 function 0 Broadcom BCM57786 rev 0x01, unknown BCM57766 (0x57766001): msi, address 20:1a:06:6f:72:2e brgphy0 at bge0 phy 1: BCM57765 10/100/1000baseT PHY, rev. 1 sdhc0 at pci1 dev 0 function 1 Broadcom SD Host Controller rev 0x01: apic 2 int 19 sdhc0 at 0x10: can't map registers ppb1 at pci0 dev 28 function 3 Intel 8 Series PCIE rev 0xe4: msi pci2 at ppb1 bus 2 vendor Atheros, unknown product 0x0036 (class network subclass miscellaneous, rev 0x01) at pci2 dev 0 function 0 not configured ppb2 at pci0 dev 28 function 4 Intel 8 Series PCIE rev 0xe4: msi pci3 at ppb2 bus 3 ATI Radeon HD 8670A rev 0x00 at pci3 dev 0 function 0 not configured ehci0 at pci0 dev 29 function 0 Intel 8 Series USB rev 0x04: apic 2 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 Intel 8 Series LPC rev 0x04 ahci0 at pci0 dev 31 function 2 Intel 8 Series AHCI rev 0x04: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, TOSHIBA MQ01ABD0, AX00 SCSI3 0/direct fixed naa. sd0: 715404MB, 512 bytes/sector, 1465149168 sectors cd0 at scsibus0 targ 1 lun 0: MATSHITA, DVD-RAM UJ8D2Q, 1.10 ATAPI 5/cdrom removable ichiic0 at pci0 dev 31 function 3 Intel 8 Series SMBus rev 0x04: apic 2 int 18 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-12800 SO-DIMM spdmem1 at iic0 addr 0x52: 4GB DDR3 SDRAM PC3-12800 SO-DIMM isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pms0: Synaptics touchpad, firmware 7.5 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 uhub1 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.04 addr 2 umass0 at uhub1 port 3 configuration 1 interface 0 SanDisk Cruzer Edge rev 2.00/2.01 addr 3 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SanDisk, Cruzer Edge, 2.01 SCSI4 0/direct fixed serial. sd1: 15267MB, 512 bytes/sector, 31266816 sectors uvideo0 at uhub1 port 8 configuration 1 interface 0 SunplusIT INC. HD WebCam rev 2.00/0.12 addr 4 video0 at uvideo0 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd1a (4ff907173ab0f7ac.a) swap on sd1b dump on sd1b 2013/12/22 mark rowland markro...@gmail.com: @Jonathan: I built a new kernel from -current after applying your patch, but I didn't find any difference. The console framebuffer works, X11 works (and it uses inteldrm as expected), but the kernel gives those error messages. Thanks for the clarification about the Radeon HD 8670, I wasn't sure about the support status of that gpu on OpenBSD because man radeon says that the HD 8000 series is supported. @Kettenis: Thanks, I applied your patch and wired lan now works. bge0 at pci1 dev 0 function 0 Broadcom BCM57786 rev 0x01, unknown BCM57766 (0x57766001): msi, address 20:1a:06:6f:72:2e brgphy0 at bge0 phy 1: BCM57765 10/100/1000baseT PHY, rev. 1 Here is the output of dmesg from a -current system with applied both Jonathan's and Kettenis' patches: OpenBSD 5.4-current (GENERIC.MP) #0: Sun Dec 22 20:07:06 CET 2013 r...@foo.my.domain:/home/tmp/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80clock_battery real mem = 6304821248 (6012MB) avail mem = 6128795648 (5844MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6e60 (27 entries) bios0: vendor Insyde Corp. version V2.10 date 10/07/2013 bios0: Acer Aspire E1-572G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI FPDT MSDM ASF! HPET APIC MCFG SSDT BOOT ASPT DBGP SSDT SSDT SSDT SSDT acpi0: wakeup devices P0P1(S4) EHC1(S3) XHC_(S3) HDEF(S4) TPD4(S4) TPD7(S0) TPD8(S0) PXSX(S4) RP03(S4) PEGP(S4) PEGA(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEG0(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2295.05 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium
Re: X fails - unable to map mmio BAR
Date: Fri, 13 Dec 2013 20:25:34 +0100
From: Steven Mestdagh ste...@openbsd.org
I'm unable to start X (using automatic config) with the intel driver, looks
like an issue in drm. Maybe the Intel HD Graphics 4600 is not supported yet
as this is a rather new board?
I suspect it is. pcidump -vx would tell us more.
The xf86-video-intel driver we have is a little bit out of date. You
could try a newer version. Use the Makefile.bsd-wrapper Grab:
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/snapshot/xf86-video-intel-2.99.906.tar.gz
# tar xfz xf86-video-intel-2.99.906.tar.gz
# cp Makefile.bsd-wrapper xf86-video-intel-2.99.906
# cd xf86-video-intel-2.99.906
# make -f Makefile.bsd-wrapper obj
# env XENOCARA_RERUN_AUTOCONF=Yes make -f Makefile.bsd-wrapper build
You will need to the right versions of the GNU autotols installed; see
/usr/xenocara/README for more details.
---
# $OpenBSD: Makefile.bsd-wrapper,v 1.5 2008/03/25 23:41:50 matthieu Exp $
.include bsd.xconf.mk
.if ${XENOCARA_BUILD_DRI:L} != yes
CONFIGURE_ARGS+= --disable-dri
.endif
CONFIGURE_ARGS+= --with-xorg-module-dir=${LIBDIR}/modules
.include bsd.xorg.mk
[demime 1.01d removed an attachment of type application/octet-stream which had
a name of Makefile.bsd-wrapper]
Re: net80211 panic: bogus xmit rate 9 setup
Date: Sat, 30 Nov 2013 17:42:21 +0100 From: Stefan Sperling s...@openbsd.org I have already fixed a similar problem before: revision 1.72 date: 2012/08/17 14:49:17; author: stsp; state: Exp; lines: +2 -1; Fix possible panic while switching from STA mode into hostap/ibss modes. ieee80211_create_ibss() resets the set of supported rates but failed to update the index into the rate set array accordingly. If the rate configured during STA operation didn't belong to the newly configured rate set the system ran into an assertion (bogus xmit rate %u setup) while trying to create the IBSS. ok fgsch@ I ran into this panic again with a cardbus ral (rt2560). This time it happened while in ibss mode in a mixed B/G network. There are additional cases where the rate set is changed but the index into the array is not. I hope the diff below fixes them. ok kettenis@ Index: ieee80211_node.c === RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v retrieving revision 1.79 diff -u -p -r1.79 ieee80211_node.c --- ieee80211_node.c 21 Nov 2013 16:16:08 - 1.79 +++ ieee80211_node.c 30 Nov 2013 15:28:20 - @@ -909,6 +909,7 @@ ieee80211_find_txnode(struct ieee80211co return NULL; /* XXX no rate negotiation; just dup */ ni-ni_rates = ic-ic_bss-ni_rates; + ni-ni_txrate = 0; if (ic-ic_newassoc) (*ic-ic_newassoc)(ic, ni, 1); } @@ -1041,6 +1042,7 @@ ieee80211_find_rxnode(struct ieee80211co IEEE80211_ADDR_COPY(ni-ni_bssid, (bssid != NULL) ? bssid : zero); ni-ni_rates = ic-ic_bss-ni_rates; + ni-ni_txrate = 0; if (ic-ic_newassoc) (*ic-ic_newassoc)(ic, ni, 1);
Re: kernel panic radeon HD 8570D
[ A kernel panic is *always* a bug and should therefore be reported to
bugs@; many developers only read misc@ for its amusement value ]
uvm_fault(0xfe823cb0c468, 0x278, 0, 1) - e
kernel: page fault trap, code=0
Stopped at radeon_vm_bo_add+0xaa: movq 0x278(%r15), %rax
Does the diff below help?
On a related note I know that fan control has been enabled on linux
3.13 for this and other radeon cards, would it be possible to
eventually port it?
Yes. If the graphics stack has stabilized a bit further we'll look
into synching to a more recent Linux codebase.
Index: drmP.h
===
RCS file: /home/cvs/src/sys/dev/pci/drm/drmP.h,v
retrieving revision 1.153
diff -u -p -r1.153 drmP.h
--- drmP.h 19 Nov 2013 19:14:09 - 1.153
+++ drmP.h 22 Nov 2013 20:42:49 -
@@ -638,12 +638,17 @@ struct drm_driver_info {
int (*get_vblank_timestamp)(struct drm_device *, int, int *,
struct timeval *, unsigned);;
- /*
-* driver-specific constructor for gem objects to set up private data.
-* returns 0 on success.
+ /**
+* Driver-specific constructor for drm_gem_objects, to set up
+* obj-driver_private.
+*
+* Returns 0 on success.
*/
- int (*gem_init_object)(struct drm_obj *);
- void(*gem_free_object)(struct drm_obj *);
+ int (*gem_init_object) (struct drm_obj *obj);
+ void (*gem_free_object) (struct drm_obj *obj);
+ int (*gem_open_object) (struct drm_obj *, struct drm_file *);
+ void (*gem_close_object) (struct drm_obj *, struct drm_file *);
+
int (*gem_fault)(struct drm_obj *, struct uvm_faultinfo *, off_t,
vaddr_t, vm_page_t *, int, int, vm_prot_t, int);
Index: drm_drv.c
===
RCS file: /home/cvs/src/sys/dev/pci/drm/drm_drv.c,v
retrieving revision 1.116
diff -u -p -r1.116 drm_drv.c
--- drm_drv.c 2 Nov 2013 22:58:10 - 1.116
+++ drm_drv.c 22 Nov 2013 20:35:49 -
@@ -1536,7 +1536,9 @@ drm_gem_handle_create(struct drm_file *f
struct drm_obj *obj,
u32 *handlep)
{
- struct drm_handle *han;
+ struct drm_device *dev = obj-dev;
+ struct drm_handle *han;
+ int ret;
if ((han = drm_calloc(1, sizeof(*han))) == NULL)
return -ENOMEM;
@@ -1556,6 +1558,14 @@ again:
drm_gem_object_handle_reference(obj);
+ if (dev-driver-gem_open_object) {
+ ret = dev-driver-gem_open_object(obj, file_priv);
+ if (ret) {
+ drm_gem_handle_delete(file_priv, *handlep);
+ return ret;
+ }
+ }
+
return 0;
}
@@ -1565,6 +1575,7 @@ again:
int
drm_gem_handle_delete(struct drm_file *filp, u32 handle)
{
+ struct drm_device *dev;
struct drm_obj *obj;
struct drm_handle *han, find;
@@ -1575,13 +1586,16 @@ drm_gem_handle_delete(struct drm_file *f
mtx_leave(filp-table_lock);
return -EINVAL;
}
-
obj = han-obj;
+ dev = obj-dev;
+
SPLAY_REMOVE(drm_obj_tree, filp-obj_tree, han);
mtx_leave(filp-table_lock);
drm_free(han);
+ if (dev-driver-gem_close_object)
+ dev-driver-gem_close_object(obj, filp);
drm_gem_object_handle_unreference_unlocked(obj);
return 0;
Index: radeon/radeon_kms.c
===
RCS file: /home/cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.11
diff -u -p -r1.11 radeon_kms.c
--- radeon/radeon_kms.c 17 Nov 2013 13:41:26 - 1.11
+++ radeon/radeon_kms.c 22 Nov 2013 20:39:57 -
@@ -217,10 +217,8 @@ static struct drm_driver_info kms_driver
.irq_handler = radeon_driver_irq_handler_kms,
.gem_init_object = radeon_gem_object_init,
.gem_free_object = radeon_gem_object_free,
-#ifdef notyet
.gem_open_object = radeon_gem_object_open,
.gem_close_object = radeon_gem_object_close,
-#endif
.gem_size = sizeof(struct radeon_bo),
.dma_ioctl = radeon_dma_ioctl_kms,
.dumb_create = radeon_mode_dumb_create,
Re: pp_free () from /usr/X11R6/lib/modules/dri/r600_dri.so
Alf, it's probably a good idea to send this bug report upstream. See: http://www.mesa3d.org/bugs.html for instructions.
Re: shuttle DS47 - RTL8168 no link / lladdr
So far so good! I applied the patch, build the new kernel and I can confirm my NICs are now recognized and working. -- Mark 2013/10/11 Mark m...@m021.nl Thanks for the quick reply i'll give it a try next week! 2013/10/11 Stuart Henderson st...@openbsd.org On 2013/10/11 11:09, Stuart Henderson wrote: On 2013/10/11 00:23, m...@m021.nl wrote: Synopsis: Realtek 8168 ethernet not working Category: bugs Environment: System : OpenBSD 5.3 Details : OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013 dera...@amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: OpenBSD does recognize the NIC as Realtek 8168 but the NIC will have no valid mac-address and even if set, the NIC won't work. How-To-Repeat: Install OpenBSD on hardware with the RTL8186 chipset Fix: Realtek has new drivers available on there website (http://www.realtek.com.tw) -- Perhaps someone with the knowlage of how to compile and embed them into OpenBSD kernel can create a fix for this problem. you could maybe try this.. it's reduced/converted from a diff at http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044569.html ignore this and try jsg's diff instead.
Re: shuttle DS47 - RTL8168 no link / lladdr
Thanks for the quick reply i'll give it a try next week! 2013/10/11 Stuart Henderson st...@openbsd.org On 2013/10/11 11:09, Stuart Henderson wrote: On 2013/10/11 00:23, m...@m021.nl wrote: Synopsis: Realtek 8168 ethernet not working Category: bugs Environment: System : OpenBSD 5.3 Details : OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013 dera...@amd64.openbsd.org: /usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: OpenBSD does recognize the NIC as Realtek 8168 but the NIC will have no valid mac-address and even if set, the NIC won't work. How-To-Repeat: Install OpenBSD on hardware with the RTL8186 chipset Fix: Realtek has new drivers available on there website (http://www.realtek.com.tw) -- Perhaps someone with the knowlage of how to compile and embed them into OpenBSD kernel can create a fix for this problem. you could maybe try this.. it's reduced/converted from a diff at http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044569.html ignore this and try jsg's diff instead.
Re: SUID Bit does not set effective user-id
The problem appears to have been nosuid set on the file location. Copying the file to /usr/bin at first appeared to fail to solve the problem, but once I re-set the SUID bit on the newly copied file the expected behaviour appeared. Thanks! //Mark On Mon, Sep 23, 2013 at 2:52 PM, Philip Guenther guent...@sendmail.comwrote: On Mon, 23 Sep 2013, Mark Dittmer wrote: I know that OpenBSD has striven to limit the number of setuid binaries in its suite of software for security reasons. However, I am not under the impression that the SUID Bit no longer affects the effective user-id when the binary is run -- this would mean that the bit does nothing, and even the few setuid programs left in OpenBSD would not work correctly. Is the binary located on a filesystem mounted with the nosuid flag? Philip Guenther
Re: OpenBSD 5.4-beta (GENERIC) #19: Sun Jul 7 15:01:51 MDT 2013 can't works with my usb keyb, usb optical mouse, usb camera and usb modems
Can you show the dmesg with acpi enabled but acpimadt disabled?
Re: OpenBSD 5.4-beta (GENERIC) #19: Sun Jul 7 15:01:51 MDT 2013 can't works with my usb keyb, usb optical mouse, usb camera and usb modems
Date: Wed, 24 Jul 2013 00:26:57 +0500 From: dmitry.sensei dmitry.sen...@gmail.com Can I use BOOT_CONFIG(8) to retrieve needed dmesg output? If I can then I can show dmesg :) Ok? Yes.
Re: OpenBSD 5.4-beta (GENERIC) #19: Sun Jul 7 15:01:51 MDT 2013 can't works with my usb keyb, usb optical mouse, usb camera and usb modems
Date: Wed, 10 Jul 2013 11:10:59 +0200 From: Martin Pieuchot mpieuc...@nolizard.org On 09/07/13(Tue) 19:36, dmitry.sensei wrote: Description: OpenBSD 5.4-beta #19 from Sun Jul 7 15:01:51 MDT 2013 can't works with my usb keyb, usb optical mouse, usb camera and usb modems, though versions of 5.3 until Jul 06 is quite normally works with its. Are you sure a kernel from Jul 06 doesn't have this regression? Your dmesg below is from *Jun 24*. It's Theo's acpi vs. apm diff that's in snaps: OpenBSD 5.4-beta (GENERIC) #19: Sun Jul 7 15:01:51 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC ... mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/01/05, BIOS32 rev. 0 @ 0xfb4b0, SMBIOS rev. 2.3 @ 0xf (38 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 02/01/2005 acpi0 at bios0: rev 0 versus: OpenBSD 5.3-current (RAMDISK_CD) #6: Mon Jun 24 13:00:16 MDT 2013 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/01/05, BIOS32 rev. 0 @ 0xfb4b0, SMBIOS rev. 2.3 @ 0xf (38 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 02/01/2005 apm0 at bios0: Power Management spec V1.2 acpi at bios0 function 0x0 not configured Interrupt routing is basically broken with ACPI on these NVidious machines.
Re: Sun Ultra 45 freezes at fsck
From: pekka pekka.niira...@pp5.inet.fi Date: Tue, 28 May 2013 22:51:32 +0300 On 5/28/13 12:53 AM, slhac tivist wrote: If it's good when you hard boot, then maybe an rc.* script is causing problems? Maybe you could figure it by elimination. Reboot flushes the cache and then executes the rc.d scripts... I copied rc.conf as rc.conf.local and set all services except sshd to NO. It did not help. I suspect it may be related to serial console because when I attach USB keyboard before boot I lose the console output as soon as I should get the logon prompt. There are PROM settings for this combination which I have to investigate. I have only XVR-2500 display cards which are not supported and therefore I am stuck. To be continued... Right. Might be a problem with the FIFO on the serial port: com0 at ebus0 addr 80-87 ivec 0x7c8: ns16550a, 16 byte fifo com0: console com1 at ebus0 addr 0-7 ivec 0x7c8: ns16550a, 16 byte fifo com1: probed fifo depth: 0 bytes The 2nd serial port is detected as an ns16550a compatible chip, which should provide a 16 byte FIFO, but then we pobe it and find that it doesn't work. We don't run the probe on the console since it typically generates some random garbage on the other end. But it is likely the FIFO doesn't work there either. And that might cause issues. Can you post the eeprom -p output for this machine? If your hacking skills are up to it, you could experiment with adding a line like: sc-sc_uarttype = COM_UART_16550; to sys/arch/sparc64/dev/com_ebus.c:com_ebus_attach.c, right before the com_attach_subr() call.
Re: sparc64: Ultra 60 Bad system call
Date: Sun, 19 May 2013 14:16:51 +0200 From: Tobias Ulmer tobi...@tmux.org Current from tonight explodes with Bad system call yet the snapshot from May 13th works just fine? Kernel out-of-sync with userland. OpenBSD 5.2-current (GENERIC.MP) #0: Sun May 19 03:59:29 CEST 2013 tobi...@calcium.tmux.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP If that really says 5.2-current, then I guess you built a kernel from a rather stale tree ;).
Re: Follow Up - First Bug Report Submittal - Re: Unable to install OBSD on new Toshiba Laptop
Date: Fri, 19 Apr 2013 11:38:31 +0200 From: Peter Hessler phess...@theapt.org There was a commit from earlier today about making sure ACPI only runs on the primary cpu. This may (but is unlikely) to be related to your issues, so please try an updated snap with a date of April 19 or more recent. Guys, stop it please. This is a known bug. There even is a diff to fix it that's been floating around. But since the ACPI standard is so ambiguous it's not obvious that fix is correct. And since nobody seems to be willing to dig any deeper, the diff has been dropped onto the floor. Somebody please pick it up?
Re: DVI output not detected with kms
Date: Sat, 6 Apr 2013 16:19:02 +0200
From: Matthieu Herrb matthieu.he...@laas.fr
On Mon, Apr 01, 2013 at 12:24:39PM +0200, Mark Kettenis wrote:
Date: Mon, 1 Apr 2013 10:09:27 +0200
From: Matthieu Herrb matthieu.he...@laas.fr
On Sun, Mar 31, 2013 at 11:51:55AM +0200, Mark Kettenis wrote:
Date: Fri, 29 Mar 2013 15:22:57 +0100
Ralf, Matthieu,
Yesterday I committed some changes that fix some issues in the SDVO
code. For my setup, whhere HDMI output is provided over SDVO this
still isn't enough to give me output. For that I need some further
changes. But I'm interested to see if what's now in -current works
for you. Could you send me a dmesg from a kernel with DRMDEBUG enabled?
Hi Mark,
I've tried with intel_svdo.c 1.6 and the bitbang timing patch, my
system still doesn't work. Below is dmesg with DRMDEBUG defined and
Xorg.0.log.
To bad. Perhaps the timings in the I2C bit-banging code need to be
adjusted a bit more. Can you play with that a bit?
Hi, yes adjusting timing a bit more makes my machine work. I first
doubled all values like you suggested, then tried to go back to
smaller values.
This seems to be the minimal set of value that makes my machine work:
Did some more digging, and realized that the i2c protocol has a
mechanism for slave devices to slow down the master. Our current code
doesn't handle that, but here's a diff (mostly stolen from NetBSD)
that does. Works for my SDVO setups. Can you give this a go?
Index: pci/drm/i915/intel_display.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_display.c,v
retrieving revision 1.5
diff -u -p -r1.5 intel_display.c
--- pci/drm/i915/intel_display.c17 Apr 2013 20:04:04 - 1.5
+++ pci/drm/i915/intel_display.c18 Apr 2013 21:40:21 -
@@ -2598,8 +2598,8 @@ i9xx_update_plane(struct drm_crtc *crtc,
intel_crtc-dspaddr_offset = linear_offset;
}
- DRM_DEBUG_KMS(Writing base %08X %08lX %d %d %d\n,
- obj-gtt_offset, linear_offset, x, y, fb-pitches[0]);
+// DRM_DEBUG_KMS(Writing base %08X %08lX %d %d %d\n,
+// obj-gtt_offset, linear_offset, x, y, fb-pitches[0]);
I915_WRITE(DSPSTRIDE(plane), fb-pitches[0]);
if (INTEL_INFO(dev)-gen = 4) {
I915_MODIFY_DISPBASE(DSPSURF(plane),
Index: i2c/i2c_bitbang.c
===
RCS file: /cvs/src/sys/dev/i2c/i2c_bitbang.c,v
retrieving revision 1.3
diff -u -p -r1.3 i2c_bitbang.c
--- i2c/i2c_bitbang.c 13 Jan 2006 23:56:46 - 1.3
+++ i2c/i2c_bitbang.c 18 Apr 2013 21:40:21 -
@@ -54,6 +54,27 @@
#defineOUTPUT ops-ibo_bits[I2C_BIT_OUTPUT] /* SDA is
output */
#defineINPUT ops-ibo_bits[I2C_BIT_INPUT]/* SDA is input
*/
+#define SCL_BAIL_COUNT 1000
+
+int i2c_wait_for_scl(void *, i2c_bitbang_ops_t);
+
+int
+i2c_wait_for_scl(void *v, i2c_bitbang_ops_t ops)
+{
+ int bail = 0;
+
+ while(((BB_READ SCL) == 0) bail SCL_BAIL_COUNT) {
+ delay(1);
+ bail++;
+ }
+ if (bail == SCL_BAIL_COUNT) {
+ i2c_bitbang_send_stop(v, 0, ops);
+ return (EIO);
+ }
+
+ return (0);
+}
+
/*ARGSUSED*/
int
i2c_bitbang_send_start(void *v, int flags, i2c_bitbang_ops_t ops)
@@ -64,6 +85,8 @@ i2c_bitbang_send_start(void *v, int flag
BB_SET(SDA | SCL);
delay(5); /* bus free time (4.7 uS) */
BB_SET( SCL);
+ if (i2c_wait_for_scl(v, ops) != 0)
+ return (EIO);
delay(4); /* start hold time (4.0 uS) */
BB_SET(0);
delay(5); /* clock low time (4.7 uS) */
@@ -115,6 +138,8 @@ i2c_bitbang_read_byte(void *v, uint8_t *
for (i = 0; i 8; i++) {
val = 1;
BB_SET(SDA | SCL);
+ if (i2c_wait_for_scl(v, ops) != 0)
+ return (EIO);
delay(4); /* clock high time (4.0 uS) */
if (BB_READ SDA)
val |= 1;
@@ -127,6 +152,8 @@ i2c_bitbang_read_byte(void *v, uint8_t *
BB_SET(bit );
delay(1); /* data setup time (250 nS) */
BB_SET(bit | SCL);
+ if (i2c_wait_for_scl(v, ops) != 0)
+ return (EIO);
delay(4); /* clock high time (4.0 uS) */
BB_SET(bit );
delay(5); /* clock low time (4.7 uS) */
@@ -157,6 +184,8 @@ i2c_bitbang_write_byte(void *v, uint8_t
BB_SET(bit );
delay(1); /* data setup time (250 nS) */
BB_SET(bit | SCL);
+ if (i2c_wait_for_scl(v, ops) != 0)
+ return (EIO);
delay(4); /* clock high time (4.0 uS
Re: queue(3): Unacounted dependency on NULL
Date: Sun, 31 Mar 2013 00:16:16 -0700 From: Philip Guenther guent...@sendmail.com On Sat, 30 Mar 2013, Andres Perera wrote: freebsd has _null.h ...but their sys/queue.h doesn't include it. There are two questions here: 1) should sys/queue.h be standalone or does it require NULL to be defined separately? 2) if the latter, what should the manpage say? Currently, FreeBSD and OpenBSD agree about (1): some sys/queue.h macros require NULL to be defined before they are used but the header does not define itself define NULL. Neither do OS X and Linux. NetBSD really seems to be the odd one out here. Regarding (2): an internal header like their sys/_null.h should never be included directly by an application, so it certainly doesn't belong in the manpage. That leaves three options: a) document in queue(3) that some macros may require NULL to be defined b) make sys/queue.h define NULL c) stop using NULL in sys/queue.h In a BSD world the answer is a) and the way to document it would be to add an #include sys/types.h to the SYNPOSIS. It was already pointed out that sys/types.h doesn't always define NULL, but frankly, what the hell are you doing if you compile with -D_POSIX_SOURCE but include non-POSIX stuff like sys/queue.h. But I guess we could add some text that suggest to include sys/types.h or stddef.h. b) would encourage writing unportable code. But it would probably make things a littlew bit easier for the ports people. c) wouldn't be terribly helpful either. The examples in queue(3) use NULL. It explicitly documents SLIST_END(), LIST_END(), SIMPLEQ_END() and TAILQ_END() macros as explanding to NULL. And on top of that getting something like NULL right for C++ takes some effort. So my vote goes to a).
Re: DVI output not detected with kms
Date: Sun, 31 Mar 2013 13:48:39 +0200
From: Ralf Horstmann r...@ackstorm.de
* Mark Kettenis mark.kette...@xs4all.nl [2013-03-31 11:51]:
Ralf, Matthieu,
Yesterday I committed some changes that fix some issues in the SDVO
code. For my setup, whhere HDMI output is provided over SDVO this
still isn't enough to give me output. For that I need some further
changes. But I'm interested to see if what's now in -current works
for you. Could you send me a dmesg from a kernel with DRMDEBUG enabled?
Still doesn't detect the DVI output, but different error messsage now:
Thanks Ralf, looks like your system needs the I2C bit-banging as well.
I committed the necessary code earlier today. Make sure ypou have
revision 1.6 of sys/dev/pci/drm/i915/intel_sdvo.c. If that still
doesn't work, try the attached diff as well.
Index: i2c_bitbang.c
===
RCS file: /cvs/src/sys/dev/i2c/i2c_bitbang.c,v
retrieving revision 1.3
diff -u -p -r1.3 i2c_bitbang.c
--- i2c_bitbang.c 13 Jan 2006 23:56:46 - 1.3
+++ i2c_bitbang.c 31 Mar 2013 17:56:47 -
@@ -62,11 +62,11 @@ i2c_bitbang_send_start(void *v, int flag
BB_DIR(OUTPUT);
BB_SET(SDA | SCL);
- delay(5); /* bus free time (4.7 uS) */
+ delay(6); /* bus free time (4.7 uS) */
BB_SET( SCL);
- delay(4); /* start hold time (4.0 uS) */
+ delay(5); /* start hold time (4.0 uS) */
BB_SET(0);
- delay(5); /* clock low time (4.7 uS) */
+ delay(6); /* clock low time (4.7 uS) */
return (0);
}
@@ -79,7 +79,7 @@ i2c_bitbang_send_stop(void *v, int flags
BB_DIR(OUTPUT);
BB_SET( SCL);
- delay(4); /* stop setup time (4.0 uS) */
+ delay(5); /* stop setup time (4.0 uS) */
BB_SET(SDA | SCL);
return (0);
@@ -115,11 +115,11 @@ i2c_bitbang_read_byte(void *v, uint8_t *
for (i = 0; i 8; i++) {
val = 1;
BB_SET(SDA | SCL);
- delay(4); /* clock high time (4.0 uS) */
+ delay(5); /* clock high time (4.0 uS) */
if (BB_READ SDA)
val |= 1;
BB_SET(SDA );
- delay(5); /* clock low time (4.7 uS) */
+ delay(6); /* clock low time (4.7 uS) */
}
bit = (flags I2C_F_LAST) ? SDA : 0;
@@ -127,13 +127,13 @@ i2c_bitbang_read_byte(void *v, uint8_t *
BB_SET(bit );
delay(1); /* data setup time (250 nS) */
BB_SET(bit | SCL);
- delay(4); /* clock high time (4.0 uS) */
+ delay(5); /* clock high time (4.0 uS) */
BB_SET(bit );
- delay(5); /* clock low time (4.7 uS) */
+ delay(6); /* clock low time (4.7 uS) */
BB_DIR(INPUT);
BB_SET(SDA );
- delay(5);
+ delay(6);
if ((flags (I2C_F_STOP | I2C_F_LAST)) == (I2C_F_STOP | I2C_F_LAST))
(void) i2c_bitbang_send_stop(v, flags, ops);
@@ -157,20 +157,20 @@ i2c_bitbang_write_byte(void *v, uint8_t
BB_SET(bit );
delay(1); /* data setup time (250 nS) */
BB_SET(bit | SCL);
- delay(4); /* clock high time (4.0 uS) */
+ delay(5); /* clock high time (4.0 uS) */
BB_SET(bit );
- delay(5); /* clock low time (4.7 uS) */
+ delay(6); /* clock low time (4.7 uS) */
}
BB_DIR(INPUT);
BB_SET(SDA );
- delay(5);
+ delay(6);
BB_SET(SDA | SCL);
- delay(4);
+ delay(5);
error = (BB_READ SDA) ? EIO : 0;
BB_SET(SDA );
- delay(5);
+ delay(6);
if (flags I2C_F_STOP)
(void) i2c_bitbang_send_stop(v, flags, ops);
Re: DVI output not detected with kms
Date: Fri, 29 Mar 2013 13:24:58 +1100
From: Jonathan Gray j...@jsg.id.au
On Fri, Mar 29, 2013 at 12:33:32PM +1100, Jonathan Gray wrote:
On Thu, Mar 28, 2013 at 09:38:20AM +0100, Ralf Horstmann wrote:
Hi,
with current snapshot (i386) the DVI output of the docking station of
my Fujitsu Lifebook T4215 is not detected anymore. Under Linux (Debian
kernel 3.2) it's detected as DVI1. With older OpenBSD versions it was
detected as TMDS-1.
VGA on the docking station works fine as well as directly attached to the
laptop. In contrast to VGA, there is no DVI output at the laptop, only at
the
docking station.
Cheers,
Ralf
It sounds like your docking station has a SDVO output, which
apparently requires bitbanging for gmbus which we don't
yet do.
Looking over the sdvo code it seems part of the i2c code
is wrong, try this:
That diff isn't quite right either. The following should be
equivalent to what Linux is doing. Can't test this myself
unfortunately.
Index: intel_sdvo.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_sdvo.c,v
retrieving revision 1.2
diff -u -p -r1.2 intel_sdvo.c
--- intel_sdvo.c19 Mar 2013 03:58:10 - 1.2
+++ intel_sdvo.c29 Mar 2013 15:52:38 -
@@ -392,10 +392,11 @@ intel_sdvo_write_sdvox(struct intel_sdvo
bool
intel_sdvo_read_byte(struct intel_sdvo *intel_sdvo, u8 addr, u8 *ch)
{
- uint8_t cmd = 0;
+ uint8_t cmd = addr;
iic_acquire_bus(intel_sdvo-i2c, 0);
- iic_exec(intel_sdvo-i2c, I2C_OP_READ_WITH_STOP, addr, cmd, 1, ch, 1,
0);
+ iic_exec(intel_sdvo-i2c, I2C_OP_READ_WITH_STOP,
+intel_sdvo-slave_addr, cmd, 1, ch, 1, 0);
iic_release_bus(intel_sdvo-i2c, 0);
return true;
@@ -571,7 +572,6 @@ intel_sdvo_write_cmd(struct intel_sdvo *
u8 *buf, status;
struct i2c_msg *msgs;
int i, ret = true, x;
- uint8_t c = 0;
/* Would be simpler to allocate both in one go ? */
buf = (u8 *)malloc(args_len * 2 + 2, M_DRM,
@@ -589,14 +589,14 @@ intel_sdvo_write_cmd(struct intel_sdvo *
intel_sdvo_debug_write(intel_sdvo, cmd, args, args_len);
for (i = 0; i args_len; i++) {
- msgs[i].op = I2C_OP_WRITE_WITH_STOP;
+ msgs[i].op = I2C_OP_WRITE;
msgs[i].addr = intel_sdvo-slave_addr;
msgs[i].len = 2;
msgs[i].buf = buf + 2 *i;
buf[2*i + 0] = SDVO_I2C_ARG_0 - i;
buf[2*i + 1] = ((u8*)args)[i];
}
- msgs[i].op = I2C_OP_WRITE_WITH_STOP;
+ msgs[i].op = I2C_OP_WRITE;
msgs[i].addr = intel_sdvo-slave_addr;
msgs[i].len = 2;
msgs[i].buf = buf + 2*i;
@@ -605,7 +605,7 @@ intel_sdvo_write_cmd(struct intel_sdvo *
/* the following two are to read the response */
status = SDVO_I2C_CMD_STATUS;
- msgs[i+1].op = I2C_OP_WRITE_WITH_STOP;
+ msgs[i+1].op = I2C_OP_WRITE;
msgs[i+1].addr = intel_sdvo-slave_addr;
msgs[i+1].len = 1;
msgs[i+1].buf = status;
@@ -618,7 +618,7 @@ intel_sdvo_write_cmd(struct intel_sdvo *
iic_acquire_bus(intel_sdvo-i2c, 0);
for (x = 0; x i+3; x++) {
ret = iic_exec(intel_sdvo-i2c, msgs[x].op, msgs[x].addr,
- c, 1, msgs[x].buf, msgs[x].len, 0);
+ NULL, 0, msgs[x].buf, msgs[x].len, 0);
if (ret) {
DRM_DEBUG_KMS(sdvo i2c transfer failed\n);
ret = false;
Re: ldomctl fails to build configuration
Date: Thu, 14 Feb 2013 12:10:32 -0500
From: Andrew Hamilton ahami...@tjhsst.edu
gzipped tarball is attached.
Hi Andrew,
Thanks for the info. Figured out what's wrong with the
factory-default config on you machine. And since it is harmless and
easy to detect, figured out a workaround for the problem. Patch
below. Sorry it took me a while to find the time to look into this.
Cheers,
Mark
Index: config.c
===
RCS file: /cvs/src/usr.sbin/ldomctl/config.c,v
retrieving revision 1.14
diff -u -p -r1.14 config.c
--- config.c8 Dec 2012 18:45:26 - 1.14
+++ config.c26 Feb 2013 22:54:45 -
@@ -592,8 +592,16 @@ hvmd_init_endpoint(struct md *md, struct
if (resource_id = max_guest_ldcs)
errx(1, resource_id larger than max_guest_ldcs);
- if (ldc_endpoints[resource_id])
+ if (ldc_endpoints[resource_id]) {
+ /*
+* Some machine descriptions seem to have duplicate
+* arcs. Fortunately, these can be easily detected
+* and ignored.
+*/
+ if (ldc_endpoints[resource_id]-hv_node == node)
+ return;
errx(1, duplicate resource_id);
+ }
endpoint = xzalloc(sizeof(*endpoint));
endpoint-target_guest = -1;
Re: conflicting types for 'getline'
Date: Thu, 03 Jan 2013 16:10:02 -0500 From: Todd C. Miller todd.mil...@courtesan.com On Thu, 03 Jan 2013 13:42:06 EST, Todd C. Miller wrote: On Wed, 02 Jan 2013 20:03:32 -0430, Andres Perera wrote: `gcc -ansi` defines __STRICT_ANSI which could be checked before setting __POSIX_VISIBLE = 200809 in sys/cdefs.h It probably makes the most sense to simply convert __STRICT_ANSI to _ANSI_SOURCE. Something like this for example. - todd Index: sys/sys/cdefs.h === RCS file: /home/cvs/openbsd/src/sys/sys/cdefs.h,v retrieving revision 1.34 diff -u -r1.34 cdefs.h --- sys/sys/cdefs.h 14 Aug 2012 20:11:37 - 1.34 +++ sys/sys/cdefs.h 3 Jan 2013 21:06:44 - @@ -357,9 +357,17 @@ #endif /* - * _ANSI_SOURCE means to expose ANSI C89 interfaces only. + * GCC defines __STRICT_ANSI when -ansi, -std=c89 or -std=c99 is specified. + * In the case of -std=c99, __STDC_VERSION__ will be set to 199901. + */ +#if defined(__STRICT_ANSI) !defined(_ANSI_SOURCE) +# define _ANSI_SOURCE1 +#endif I don't think we should define _ANSI_SOURCE in our headers; I've had the following diff in one of my trees for a while. There's some fallout in xenocara/dist/Mesa though. And I suspect there will be some ports issues as well. So we probably want to leave this alone until after the next release. Index: cdefs.h === RCS file: /cvs/src/sys/sys/cdefs.h,v retrieving revision 1.34 diff -u -p -r1.34 cdefs.h --- cdefs.h 14 Aug 2012 20:11:37 - 1.34 +++ cdefs.h 25 Jan 2013 19:01:57 - @@ -361,8 +361,8 @@ * If the user defines it in addition to one of the POSIX or XOPEN * macros, assume the POSIX/XOPEN macro(s) should take precedence. */ -#if defined(_ANSI_SOURCE) !defined(__POSIX_VISIBLE) \ -!defined(__XPG_VISIBLE) +#if (defined(_ANSI_SOURCE) || defined(__STRICT_ANSI__)) \ +!defined(__POSIX_VISIBLE) !defined(__XPG_VISIBLE) # define __POSIX_VISIBLE 0 # define __XPG_VISIBLE 0 # define __ISO_C_VISIBLE 1990 @@ -385,7 +385,8 @@ * macros is defined or if the user explicitly asks for them. */ #if !defined(_BSD_SOURCE) \ - (defined(_ANSI_SOURCE) || defined(__XPG_VISIBLE) || defined(__POSIX_VISIBLE)) + (defined(_ANSI_SOURCE) || defined(__STRICT_ANSI__) || \ +defined(__XPG_VISIBLE) || defined(__POSIX_VISIBLE)) # define __BSD_VISIBLE 0 #endif
Re: I found a 14-year old bug.
Date: Wed, 21 Nov 2012 13:55:31 +0100 From: Peter pe...@haas-en-berg.nl http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html Did you actually read that? In particular the paragraph that starts with The problem with typewriters...?
Re: pchb0 problems after upgrade to 5.1
Date: Mon, 12 Nov 2012 17:01:16 +0200 From: =?UTF-8?Q?K=C4=81rlis_Mi=C4=B7elsons?= karlis.mikels...@lf.lv Hello, After upgrading one computer to OpenBSD 5.1, it stops booting. Booting can only be completed if I enter ddb command continue. Updating this box to 5.2 didn't solve the problem. It seems to be same bug reported here: http://marc.info/?t=13274181113r=1w=2 Can you try the following diff? Index: agp_intel.c === RCS file: /cvs/src/sys/dev/pci/agp_intel.c,v retrieving revision 1.19 diff -u -p -r1.19 agp_intel.c --- agp_intel.c 24 Oct 2011 15:42:33 - 1.19 +++ agp_intel.c 13 Nov 2012 13:13:14 - @@ -262,7 +262,6 @@ agp_intel_attach(struct device *parent, default: reg = pci_conf_read(isc-isc_pc, isc-isc_tag, AGP_INTEL_ERRCMD); - reg |= 0x7000; /* Ack ERRSTS bits 8-10*/ pci_conf_write(isc-isc_pc, isc-isc_tag, AGP_INTEL_ERRCMD, reg); } @@ -381,7 +380,6 @@ agp_intel_restore(struct agp_intel_softc default: tmp = pci_conf_read(isc-isc_pc, isc-isc_tag, AGP_INTEL_ERRCMD); - tmp |= 0x7000; /* Ack ERRSTS bits 8-10*/ pci_conf_write(isc-isc_pc, isc-isc_tag, AGP_INTEL_ERRCMD, tmp); break;
Re: Wrong destinatino APIC-ID in i386 MSI messages
Hi,
there are machines (in particular those based on AMD CPUs) where
the APIC-ID of the boot CPU's LAPIC is not zero. Instead APIC-ID zero
is apparently assigned to the first IO-APIC. AFAICS we will mis-route
MSI interrupts on such a machine.
The symptom (apart from MSI interrupts not working) would be a LAPIC
error interrupt where the LAPIC complains that there is a interrupt
message that noone cares about.
Below's a suggested patch for discussion. However, I cannot test it on
the critical machines right now. I did verify that it does not break
MSIs on a conventional machine, though.
The amd64 codebase already gets this right. While there are
significant difference in the interrupt handling code between both
platforms, I do prefer to keep the code as similar as possible. So
I'd prefer the diff below over yours.
Index: pci_machdep.c
===
RCS file: /cvs/src/sys/arch/i386/pci/pci_machdep.c,v
retrieving revision 1.68
diff -u -p -r1.68 pci_machdep.c
--- pci_machdep.c 4 Dec 2011 20:08:09 - 1.68
+++ pci_machdep.c 21 Sep 2012 09:50:33 -
@@ -780,7 +780,7 @@ pci_intr_establish(pci_chipset_tag_t pc,
if (ih.line APIC_INT_VIA_MSG) {
struct intrhand *ih;
- pcireg_t reg;
+ pcireg_t reg, addr;
int off, vec;
if (pci_get_capability(pc, tag, PCI_CAP_MSI, off, reg) == 0)
@@ -807,12 +807,14 @@ pci_intr_establish(pci_chipset_tag_t pc,
apic_intrhand[vec] = ih;
idt_vec_set(vec, apichandler[vec 0xf]);
+ addr = 0xfee0UL | (cpu_info_primary.apicid 12);
+
if (reg PCI_MSI_MC_C64) {
- pci_conf_write(pc, tag, off + PCI_MSI_MA, 0xfee0);
+ pci_conf_write(pc, tag, off + PCI_MSI_MA, addr);
pci_conf_write(pc, tag, off + PCI_MSI_MAU32, 0);
pci_conf_write(pc, tag, off + PCI_MSI_MD64, vec);
} else {
- pci_conf_write(pc, tag, off + PCI_MSI_MA, 0xfee0);
+ pci_conf_write(pc, tag, off + PCI_MSI_MA, addr);
pci_conf_write(pc, tag, off + PCI_MSI_MD32, vec);
}
pci_conf_write(pc, tag, off, reg | PCI_MSI_MC_MSIE);
Re: Wrong destinatino APIC-ID in i386 MSI messages
Date: Fri, 21 Sep 2012 15:00:12 +0200 From: Christian Ehrhardt open...@c--e.de Hi, On Fri, Sep 21, 2012 at 11:53:23AM +0200, Mark Kettenis wrote: there are machines (in particular those based on AMD CPUs) where the APIC-ID of the boot CPU's LAPIC is not zero. Instead APIC-ID zero is apparently assigned to the first IO-APIC. AFAICS we will mis-route MSI interrupts on such a machine. The symptom (apart from MSI interrupts not working) would be a LAPIC error interrupt where the LAPIC complains that there is a interrupt message that noone cares about. Below's a suggested patch for discussion. However, I cannot test it on the critical machines right now. I did verify that it does not break MSIs on a conventional machine, though. The amd64 codebase already gets this right. While there are significant difference in the interrupt handling code between both platforms, I do prefer to keep the code as similar as possible. So I'd prefer the diff below over yours. Fine with me. Let me add that I just verified that on one particular machine that I have here: - MSIs do not work with unmodified 5.1 code installed from CD. - MSIs work with (my version of) the patch applied. Can you commit this? Commit... and run.
quota(1) and DUIDs
Is quota(1) working with DUIDs (on i386)? On a non-DUID system it reports ok: # quota abc Disk quotas for user abc (uid 1001): Filesystem KBytesquota limit gracefiles quota limit grace / 16 100 150 100 0 On two DUID systems it doesn't: # quota abc Disk quotas for user abc (uid 1001): none Same config on all 3 machines. Can anyone check? Quotas themselves work ok on all machines. Thats to say restrictions ARE implemented. I'm using a snap from a couple of days ago on vms. mark
Re: Intel WiFi Link 130
From: X-user x-user2...@yandex.ru
Cc: bugs@openbsd.org bugs@openbsd.org
93c93,95
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_100_2 }
---
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_100_2 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_1 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_130_2 }
And does it actually work?
Re: IBM X3100 M4 server, extent_alloc_region: region lies outside extent
Date: Sun, 5 Aug 2012 12:54:39 +0200 From: Mike Belopuhov m...@crypt.org.ru On Sat, Aug 04, 2012 at 11:33 +0200, Mike Belopuhov wrote: On Fri, Aug 03, 2012 at 18:03 -, r...@kooleconsulting.nl wrote: Just tried it, but the result is identical. Is there a way to obtain more useful debugging output? I'm willing to put in testing effort here as I have two of these and strongly prefer to run OpenBSD on them. yes. please find a diff below. it should allow you to boot the kernel so that we can do pcidump and acpidump. you can get the kernel installed by ftp from bsd.rd. please also collect the output of machine memory from the boot prompt and the dmesg whith the diff i've provided since it has some debugging output. I've been working on this with Rick and it looks like I've found the culprit, but I'd like others, especially Mark, to take a closer look at my findings. So my theory is that IBM or whoever they've entrusted with doing that have programmed SMBus function BARs incorrectly. This is what pcidump shows us (device 0:31:3: Intel 6 Series SMBus): 0x0010: 81b4 3050 And this is how we interpret it: 0x0010: BAR mem 64bit addr: 0x305081b0/0x0100 We do so because of that '4' which tells us: it's a 64 bit address. Right. But in fact the 0x3050 part is an IO BAR and it's not marked as such! IO BAR must have a type of '1' so it must be 0x3051. Now 0x81b0 is in fact a 32-bit address and must have a type '0'. So all in all it should say: 0x0010: 81b0 3051 and it will be interpreted as 0x0010: BAR mem 32bit addr: 0x81b0/0x0100 0x0014: BAR io addr: 0x3050/some lenght Well, the chipset docs document the BAR at 0x10/0x14 as 64-bit, so I really think its just the BIOS that's confused and believes that 0x10 is a 32-bit mmio BAR and 0x14 is an io BAR. According to the chipset docs the io BAR lives at 0x20: 0x0020: BAR io addr: 0xefa0/0x0020 I think there's nothing we can do about it as it's clearly their fault. But having said that, does anyone know of any other option? Or maybe my analysis is wrong? It is ;). But I agree that the BIOS is busted. We should probably handle this in a more graceful manner. Best thing is probably to add explicit checks for ex_start and ex_end, and clear the BAR if it falls outside that range, just like we do when we encounter a mem address conflict. I'll see if I can cook up a diff for that.
Re: OpenBSD 5.1/i386 cas driver issue
Date: Wed, 16 May 2012 20:37:55 -0600 From: James Shaw sim...@gmail.com Well, that worked partway. Now each card is sharing MACs across 4 ports. Example: cas0 at pci3 dev 0 function 0 NS Saturn rev 0x30: apic 5 int 5, address 00:03:ba:da:fa:6a cas1 at pci3 dev 1 function 0 NS Saturn rev 0x30: apic 5 int 15, address 00:03:ba:da:fa:6a cas2 at pci4 dev 2 function 0 NS Saturn rev 0x30: apic 5 int 13, address 00:03:ba:da:fa:6a cas3 at pci4 dev 3 function 0 NS Saturn rev 0x30: apic 5 int 14, address 00:03:ba:da:fa:6a cas4 at pci6 dev 0 function 0 NS Saturn rev 0x30: apic 5 int 6, address 00:03:ba:95:80:e9 cas5 at pci6 dev 1 function 0 NS Saturn rev 0x30: apic 5 int 14, address 00:03:ba:95:80:e9 cas6 at pci7 dev 2 function 0 NS Saturn rev 0x30: apic 5 int 15, address 00:03:ba:95:80:e9 cas7 at pci7 dev 3 function 0 NS Saturn rev 0x30: apic 5 int 13, address 00:03:ba:95:80:e9 The hme(4) drivers solves that issue with: sc-sc_arpcom.ac_enaddr[5] += hpa-pa_device; We probably should do that for cas(4) as well, at least for the quad cards.
Re: ACPI broken on ThinkPad T400s
Date: Thu, 3 May 2012 22:43:59 +0200
From: Rafael Sadowski raf...@sizeofvoid.org
On Sat Apr 07, 2012 at 01:24:28PM +0200, Rafael Sadowski wrote:
On Sat Apr 07, 2012 at 12:08:50PM +0200, Rafael Sadowski wrote:
Hey devs,
the last 3-4 weeks I'm in trouble with ACPI. I get evil bugs like:
-- After resume from suspend my X11 is really slow (switching between
tmux windows)
-- After resume from suspend my whole system freezes.
-- Last night I build some big ports. Result after one hour:
hw.sensors.acpitz{0,1}.temp0 by 100 C and auto shutdown. (In 3 your of
using OpenBSD with Thinkpad T400s I never had such problems.)
I am grateful for any advice. I will help to debug it!
best regards
Rafael
I built a new /bsd with the sources from Mar 28. ACPI works fine, now I
think it will help to find the bug(s).
Rafael
-current (with new X11) is still broken on Thinkpad T400s :-(
Identify the exact commit that broke your machine.
Re: ACPI: Should not the arithmetic operations on AML virtual machine be unsigned?
From: Christophe =?ISO-8859-1?Q?Sta=EFesse?= chas...@skynet.be
Hello :-)
Here are the diff -u. I've used the 5.0-RELEASE sys.tar.gz to compile
the kernel.
dsdt.c : aml_evalexpr now operates with 64-bit unsigned integers as it
should. (quick hack, not throughoutly tested).
--- dsdt.c.old2012-03-06 10:28:54.0 +0100
+++ dsdt.c2012-03-06 11:04:15.0 +0100
@@ -63,7 +63,7 @@
const void *);
u_int64_taml_convradix(u_int64_t, int, int);
-int64_t aml_evalexpr(int64_t, int64_t, int);
+u_int64_taml_evalexpr(u_int64_t, u_int64_t, int);
int aml_lsb(u_int64_t);
int aml_msb(u_int64_t);
@@ -1099,10 +1099,10 @@
}
/* Evaluate Math operands */
-int64_t
-aml_evalexpr(int64_t lhs, int64_t rhs, int opcode)
+u_int64_t
+aml_evalexpr(u_int64_t lhs, u_int64_t rhs, int opcode)
{
- int64_t res = 0;
+ u_int64_t res = 0;
switch (opcode) {
/* Math operations */
I've committed this diff. It seems the acpi code is totally confused
about the signedness of its integers.
Alternatively, a more general way to remove the superfluous backslash is
to make it directly in aml_searchname but that doesn't seem to make any
difference in my case:
--- dsdt.c.old2012-03-06 10:28:54.0 +0100
+++ dsdt.c2012-03-06 11:05:01.0 +0100
@@ -4085,7 +4085,7 @@
int i;
dnprintf(25,Searchname: %s:%s = , aml_nodename(root), vname);
- if (*name == AMLOP_ROOTCHAR) {
+ while (*name == AMLOP_ROOTCHAR) {
root = aml_root;
name++;
}
I think this diff makes more sense. From the relevant section of the
document it isn't clear if double slashes are allowed. I'd say not,
but the example of the ECDT table shows a string with a double slash.
That's probably a mistake, but I can't see a downside of interpreting
multiple slashes as a single slash here.
Do unless another developer objects, I'll commit that.
Thanks,
Mark
Re: Intel PRO/1000 PF em() network card not working with MSI on Dell R610
Date: Tue, 14 Feb 2012 21:34:50 +1100 From: Jonathan Gray j...@jsg.id.au This appears to be a silicon level flaw: From Intel 82571EB/82572EI Ethernet Controller Specification Update: 63. Byte Enables 2 and 3 Are Not Set on MSI Writes Problem: MSI (format code definition Message Signal Interrupts) writes on the 82571EB will not have the upper two Byte Enables (BE) set. Implication: The PCI specification requires Byte Enables 2 and 3 to be set even though that data will always be zero. Because the 82571/82572 does not set these Byte Enables, MSI writes fail to generate interrupts on systems with chipsets that have been designed to require these Bytes Enables to be set. This errata only applies when MSI is supported and enabled by the system and OS. Workaround: None, As long as MSI is being used, Byte Enables 2 and 3 will not be set. Status: No Fix. -- So it seems to be safe we should not try to enable MSI on 82571/82572 at all. ok kettenis@ Index: if_em.c === RCS file: /cvs/src/sys/dev/pci/if_em.c,v retrieving revision 1.261 diff -u -p -r1.261 if_em.c --- if_em.c 5 Oct 2011 02:52:09 - 1.261 +++ if_em.c 14 Feb 2012 10:27:03 - @@ -329,8 +329,11 @@ em_attach(struct device *parent, struct /* Determine hardware revision */ em_identify_hardware(sc); - /* Only use MSI on the newer PCIe parts */ - if (sc-hw.mac_type em_82571) + /* + * Only use MSI on the newer PCIe parts, with the exception + * of 82571/82572 due to Byte Enables 2 and 3 Are Not Set errata + */ + if (sc-hw.mac_type = em_82572) sc-osdep.em_pa.pa_flags = ~PCI_FLAGS_MSI_ENABLED; /* Parameters (to be read from user) */
Re: USB doesn't work after suspend on ThinkPad x201
From: Alexey E. Suslikov alexey.susli...@gmail.com Date: Fri, 3 Feb 2012 15:41:23 + (UTC) Theo de Raadt deraadt at cvs.openbsd.org writes: --- pcidump_before Tue Jan 31 18:10:04 2012 +++ pcidump_after Tue Jan 31 18:33:01 2012 @@ -159,7 +159,7 @@ 0x0014: 0x0018: Primary Bus: 0 Secondary Bus: 2 Subordinate Bus: 2 Secondary Latency Timer: 00 - 0x001c: I/O Base: f0 I/O Limit: 00 Secondary Status: 2000 + 0x001c: I/O Base: f0 I/O Limit: 00 Secondary Status: 0x0020: Memory Base: f240 Memory Limit: f240 0x0024: Prefetch Memory Base: fff1 Prefetch Memory Limit: 0001 0x0028: Prefetch Memory Base Upper 32 Bits: That is unrelated. If I'm not mistaken, PCI_COMMAND_STATUS_REG is saved in pci.c/pci_suspend. Also, there is a special note: /* * Only handle header type 0 here; PCI-PCI bridges and * CardBus bridges need special handling, which will * be done in their specific drivers. */ Given pcidump diffs above, isn't it because Secondary Status Register wasn't saved during suspend (I haven't found any in ppb.c/ppbactivate)? The status bits can't be restored; they can only be cleared.
Re: OpenBSD 5.0 panic on boot Dell R710
Date: Fri, 23 Dec 2011 08:33:52 +0100 From: Oliver Seufer open...@seufer.de The systeme has 20 network ports (5x4 ports), maybe that makes a difference. That is almost certainly the problem. You might have more luck running amd64 on that box.
Re: Sandybridge cannot return to console
Known problem. Unlikely to get fixed anytime soon as the Linux KMS (kernel) code on which our Xorg driver is based doesn't even seem to attempt to ever restore test mode. At least X now works at the native panel resolution doesn't it?
Re: OpenBSD/amd64 -current SD card slot cannot access SD cards Lenovo ThinkPad Edge E420
Date: Fri, 23 Dec 2011 00:21:22 -0500 From: Brian Callahan kors...@gmail.com Yeah, that magic code I sent you seems to change the PCI ID of the device from 5U823 into 5U822. Will be fixed. Meanwhile, a cold boot should fix that issue.
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 (bge device unknown)
Date: Fri, 23 Dec 2011 14:43:52 +0400 From: Wesley M. open...@e-solutions.re Hi, So i installed a fresh OpenBSD 4.9 to try to patch the files : brgphy.c and miidevs I have the following error when compiling : ... D_KERNEL -c ../../../../dev/mii/brgphy.c ../../../../dev/mii/brgphy.c:177: error: 'MII_MODEL_xxBROADCOM3_BCM57765' undeclared here (not in a function) ../../../../dev/mii/brgphy.c:178: error: 'MII_STR_xxBROADCOM3_BCM57765' undeclared here (not in a function) *** Error code 1 # cd /usr/src/sys/dev/mii # make
Re: OpenBSD/amd64 -current SD card slot cannot access SD cards Lenovo ThinkPad Edge E420
Date: Thu, 15 Dec 2011 22:21:19 -0500
From: Brian Callahan kors...@gmail.com
On my Lenovo ThinkPad Edge E420, when inserting an SD card into its
built-in card slot, I am presented with a random number of the
following five error messages:
sdmmc0: can't supply bus power
sdmmc0: can't enable card
sdmmc0: can't set mem RCA
sdmmc0: can't identify card
sdmmc0: no functions
Does the following diff work?
Index: sdhc_pci.c
===
RCS file: /cvs/src/sys/dev/pci/sdhc_pci.c,v
retrieving revision 1.11
diff -u -p -r1.11 sdhc_pci.c
--- sdhc_pci.c 31 Jul 2011 16:55:01 - 1.11
+++ sdhc_pci.c 16 Dec 2011 21:53:12 -
@@ -98,11 +98,42 @@ sdhc_pci_attach(struct device *parent, s
/* Some RICOH controllers lack a capability register. */
if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_RICOH
- PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823)
+ PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823) {
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xf8);
+ reg = ~0xff00;
+ reg |= 0xfc00;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xf8, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0x150);
+ reg = ~0x00ff;
+ reg |= 0x0010;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0x150, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xf8);
+ reg = ~0xff00;
+ reg |= 0x;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xf8, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xfc);
+ reg = ~0x00ff;
+ reg |= 0x0001;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xfc, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xe0);
+ reg = ~0xff00;
+ reg |= 0x3200;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xe1, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xfc);
+ reg = ~0x00ff;
+ reg |= 0x;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xfc, reg);
+
caps = (0x21 SDHC_BASE_FREQ_SHIFT) |
(0x21 SDHC_TIMEOUT_FREQ_SHIFT) |
SDHC_TIMEOUT_FREQ_UNIT | SDHC_VOLTAGE_SUPP_3_3V |
SDHC_DMA_SUPPORT;
+ }
if (pci_intr_map(pa, ih)) {
printf(: can't map interrupt\n);
Re: OpenBSD/amd64 -current SD card slot cannot access SD cards Lenovo ThinkPad Edge E420
Date: Fri, 16 Dec 2011 17:46:30 -0500
From: Brian Callahan kors...@gmail.com
sdhc0 at pci3 dev 0 function 0 Ricoh 5U823 SD/MMC rev 0x04panic:
kernel diagnostic assertion (reg 0x3) == 0 failed: file
../../../../arch/amd64/pci/pci_machdep.c, line 298
Ugh, I made a typo there. This one should work better.
Index: sdhc_pci.c
===
RCS file: /cvs/src/sys/dev/pci/sdhc_pci.c,v
retrieving revision 1.11
diff -u -p -r1.11 sdhc_pci.c
--- sdhc_pci.c 31 Jul 2011 16:55:01 - 1.11
+++ sdhc_pci.c 16 Dec 2011 22:52:15 -
@@ -98,11 +98,42 @@ sdhc_pci_attach(struct device *parent, s
/* Some RICOH controllers lack a capability register. */
if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_RICOH
- PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823)
+ PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_RICOH_R5U823) {
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xf8);
+ reg = ~0xff00;
+ reg |= 0xfc00;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xf8, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0x150);
+ reg = ~0x00ff;
+ reg |= 0x0010;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0x150, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xf8);
+ reg = ~0xff00;
+ reg |= 0x;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xf8, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xfc);
+ reg = ~0x00ff;
+ reg |= 0x0001;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xfc, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xe0);
+ reg = ~0xff00;
+ reg |= 0x3200;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xe0, reg);
+
+ reg = pci_conf_read(pa-pa_pc, pa-pa_tag, 0xfc);
+ reg = ~0x00ff;
+ reg |= 0x;
+ pci_conf_write(pa-pa_pc, pa-pa_tag, 0xfc, reg);
+
caps = (0x21 SDHC_BASE_FREQ_SHIFT) |
(0x21 SDHC_TIMEOUT_FREQ_SHIFT) |
SDHC_TIMEOUT_FREQ_UNIT | SDHC_VOLTAGE_SUPP_3_3V |
SDHC_DMA_SUPPORT;
+ }
if (pci_intr_map(pa, ih)) {
printf(: can't map interrupt\n);
Re: X hangs with radeon drm ever since the introduction of intr_shared_edge into i386
Date: Mon, 5 Dec 2011 16:21:23 -0500 From: Stuart Cassoff s...@bell.net Ever since the commit of 2011/04/15 (http://marc.info/?l=openbsd-cvsm=130291453723298) which enables intr_shared_edge, X will hang on startup if radeom drm is enabled. I have tested many kernels and have pinpointed it to this. I am able to make it work with the snapshots of Dec 1, 2011 and kernel as of today, Dec 5, 2011, with the small change detailed below. What happens if you disable esa(4)?
Re: X hangs with radeon drm ever since the introduction of intr_shared_edge into i386
Date: Tue, 6 Dec 2011 08:00:57 -0500
From: Stuart Cassoff s...@bell.net
On 12/06/11 06:28, Mark Kettenis wrote:
Date: Mon, 5 Dec 2011 16:21:23 -0500
From: Stuart Cassoff s...@bell.net
Ever since the commit of 2011/04/15
(http://marc.info/?l=openbsd-cvsm=130291453723298) which
enables intr_shared_edge, X will hang on startup if radeom drm
is enabled. I have tested many kernels and have pinpointed it
to this. I am able to make it work with the snapshots of Dec
1, 2011 and kernel as of today, Dec 5, 2011, with the small
change detailed below.
What happens if you disable esa(4)?
With esa(4) disabled, X will start up just fine, kernel snapshot of Dec 1,
2011.
Great! Can you try the attached diff?
Index: esa.c
===
RCS file: /cvs/src/sys/dev/pci/esa.c,v
retrieving revision 1.23
diff -u -p -u -p -r1.23 esa.c
--- esa.c 3 Apr 2011 15:36:02 - 1.23
+++ esa.c 6 Dec 2011 14:51:04 -
@@ -874,7 +874,7 @@ esa_intr(void *hdl)
u_int32_t diff;
u_int32_t play_blksize, play_bufsize;
u_int32_t rec_blksize, rec_bufsize;
- int i;
+ int i, claimed = 0;
status = bus_space_read_1(iot, ioh, ESA_HOST_INT_STATUS);
if (status == 0xff)
@@ -901,6 +901,7 @@ esa_intr(void *hdl)
break;
}
bus_space_write_1(iot, ioh, ESA_HW_VOL_COUNTER_MASTER, 0x88);
+ claimed = 1;
}
if (status ESA_ASSP_INT_PENDING) {
@@ -945,9 +946,10 @@ esa_intr(void *hdl)
}
}
}
+ claimed = 1;
}
- return (1);
+ return (claimed);
}
int
Re: old i386 P1 breakage post 5/28/2011
I'd prefer to fix it with the diff below, to help the diffability with the amd64 codebase. Index: pci_machdep.c === RCS file: /cvs/src/sys/arch/i386/pci/pci_machdep.c,v retrieving revision 1.64 diff -u -p -r1.64 pci_machdep.c --- pci_machdep.c 13 Oct 2011 18:09:33 - 1.64 +++ pci_machdep.c 4 Dec 2011 19:24:43 - @@ -212,6 +212,13 @@ pci_attach_hook(struct device *parent, s return; /* +* Machines that use the non-standard method of generating PCI +* configuration cycles are way too old to support MSI. +*/ + if (pci_mode == 2) + return; + + /* * In order to decide whether the system supports MSI we look * at the host bridge, which should be device 0 function 0 on * bus 0. It is better to not enable MSI on systems that
Re: schizo0: pci bus A error - when playing audio
Date: Sat, 29 Oct 2011 19:38:10 +0200 From: Tobias Ulmer tobi...@tmux.org schizo0: pci bus A error More stuff should be printed on the console after that. Please provide that information, since it will tell us what is happening.
Re: Intel Centrino Advanced-N 6205 not working
From: Rinaldini Julien julien.rinald...@heig-vd.ch Date: Mon, 22 Aug 2011 20:17:01 + OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP Oh, you defenitely certainly want to run -current on an x220. Do your yourself a favour and install a snapshot rightaway. It won't fix the wireless (you still need my diff for that) but at least it'll give you wired networking.
Re: Intel Centrino Advanced-N 6205 not working
From: Rinaldini Julien julien.rinald...@heig-vd.ch
Date: Mon, 22 Aug 2011 20:17:01 +
Hi,
I have a thinkpad x220 with a Intel Centrino Advanced-N 6205 wireless card.
I installed the iwn firmware as it is said in the manpage.
ifconfig see my card but when I try to up it with ifconfig iwn0 up I got
some error. Here is my dmesg, see at end for information related to iwn:
Here's the diff I'm currently running with. It adds some missing code
and disables some of the run-time calibration. But it seems to work
reasonably well.
Some of this is probably going to end up in the tree soon. Still need
to figure out why the firmware doesn't like the run-time calibration
commands...
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.110
diff -u -p -r1.110 if_iwn.c
--- if_iwn.c16 Jun 2011 19:48:22 - 1.110
+++ if_iwn.c22 Aug 2011 20:49:30 -
@@ -207,6 +207,7 @@ int iwn_send_sensitivity(struct iwn_sof
intiwn_set_pslevel(struct iwn_softc *, int, int, int);
intiwn_send_temperature_offset(struct iwn_softc *);
intiwn_send_btcoex(struct iwn_softc *);
+intiwn5000_runtime_calib(struct iwn_softc *);
intiwn_config(struct iwn_softc *);
intiwn_scan(struct iwn_softc *, uint16_t);
intiwn_auth(struct iwn_softc *);
@@ -263,6 +264,7 @@ voidiwn_hw_stop(struct iwn_softc *);
intiwn_init(struct ifnet *);
void iwn_stop(struct ifnet *, int);
+#define IWN_DEBUG
#ifdef IWN_DEBUG
#define DPRINTF(x) do { if (iwn_debug 0) printf x; } while (0)
#define DPRINTFN(n, x) do { if (iwn_debug = (n)) printf x; } while (0)
@@ -2333,9 +2335,11 @@ iwn_notif_intr(struct iwn_softc *sc)
*/
DPRINTF((beacons missed %d/%d\n,
letoh32(miss-consecutive), letoh32(miss-total)));
+#if 0
if (ic-ic_state == IEEE80211_S_RUN
letoh32(miss-consecutive) 5)
(void)iwn_init_sensitivity(sc);
+#endif
break;
}
case IWN_UC_READY:
@@ -3733,6 +3737,7 @@ void
iwn_collect_noise(struct iwn_softc *sc,
const struct iwn_rx_general_stats *stats)
{
+#if 0
struct iwn_ops *ops = sc-ops;
struct iwn_calib_state *calib = sc-calib;
uint32_t val;
@@ -3768,13 +3773,14 @@ iwn_collect_noise(struct iwn_softc *sc,
#ifdef notyet
/* XXX Disable RX chains with no antennas connected. */
- sc-rxon.rxchain = htole16(IWN_RXCHAIN_SEL(sc-chainmask));
+ sc-rxon.rxchain = htole16(IWN_RXCHAIN_SEL(sc-chainmask);
(void)iwn_cmd(sc, IWN_CMD_RXON, sc-rxon, sc-rxonsz, 1);
#endif
/* Enable power-saving mode if requested by user. */
if (sc-sc_ic.ic_flags IEEE80211_F_PMGTON)
(void)iwn_set_pslevel(sc, 0, 3, 1);
+#endif
}
int
@@ -4126,6 +4132,18 @@ iwn_send_btcoex(struct iwn_softc *sc)
}
int
+iwn5000_runtime_calib(struct iwn_softc *sc)
+{
+ struct iwn5000_calib_config cmd;
+
+ memset(cmd, 0, sizeof cmd);
+ cmd.ucode.once.enable = 0x;
+ cmd.ucode.once.start = IWN5000_CALIB_DC;
+ DPRINTF((configuring runtime calibration\n));
+ return iwn_cmd(sc, IWN5000_CMD_CALIB_CONFIG, cmd, sizeof(cmd), 0);
+}
+
+int
iwn_config(struct iwn_softc *sc)
{
struct iwn_ops *ops = sc-ops;
@@ -4145,6 +4163,17 @@ iwn_config(struct iwn_softc *sc)
}
}
+ if (sc-hw_type == IWN_HW_REV_TYPE_6050 ||
+ sc-hw_type == IWN_HW_REV_TYPE_6005) {
+ /* Configure runtime DC calibration. */
+ error = iwn5000_runtime_calib(sc);
+ if (error != 0) {
+ printf(%s: could not configure runtime calibration\n,
+ sc-sc_dev.dv_xname);
+ return error;
+ }
+ }
+
/* Configure valid TX chains for =5000 Series. */
if (sc-hw_type != IWN_HW_REV_TYPE_4965) {
txmask = htole32(sc-txchainmask);
@@ -5345,6 +5374,8 @@ iwn_read_firmware_tlv(struct iwn_softc *
case IWN_FW_TLV_BOOT_TEXT:
fw-boot.text = ptr;
fw-boot.textsz = len;
+ break;
+ case IWN_FW_TLV_PHY_CALIB_SIZE:
break;
default:
DPRINTF((TLV type %d not handled\n,
Index: if_iwnreg.h
===
RCS file: /cvs/src/sys/dev/pci/if_iwnreg.h,v
retrieving revision 1.42
diff -u -p -r1.42 if_iwnreg.h
--- if_iwnreg.h 9 Jan 2011 15:45:37 - 1.42
+++ if_iwnreg.h 22 Aug 2011 20:49:30 -
@@ -727,6 +727,8 @@ struct iwn5000_wimax_coex {
struct iwn5000_calib_elem {
Re: kernel/6631: DDB during boot on Dell Dimension E521
Can you send me pcidump -vxx output for that machine?
Re: kernel/6631: DDB during boot on Dell Dimension E521
The following reply was made to PR kernel/6631; it has been noted by GNATS.
From: Mark Kettenis mark.kette...@xs4all.nl
To: and...@afresh1.com
Cc: gn...@openbsd.org
Subject: Re: kernel/6631: DDB during boot on Dell Dimension E521
Date: Thu, 9 Jun 2011 23:13:09 +0200 (CEST)
Date: Thu, 9 Jun 2011 12:50:55 -0700
From: Andrew Fresh and...@afresh1.com
On Thu, Jun 09, 2011 at 09:26:04PM +0200, Mark Kettenis wrote:
Can you send me pcidump -vxx output for that machine?
Sure can.
0:0:5: NVIDIA C51 Memory
0x: Vendor ID: 10de Product ID: 02ff
0x0004: Command: 0006 Status ID: 00b0
0x0008: Class: 05 Subclass: 00 Interface: 00 Revision: a2
0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS:
0x002c: Subsystem Vendor ID: 10de Product ID: 02ff
0x0030: Expansion ROM Base Address:
0x0038:
0x003c: Interrupt Pin: 00 Line: ff Min Gnt: 00 Max Lat: 00
0x0044: Capability 0x00: Reserved
0x: 02ff10de 00b6 05a2 0080
0x0010:
0x0020: 02ff10de
0x0030: 0044 00ff
0x0040: 0017 00fefe00 00fefe00 00fefe00
That PCI device has a broken Capabilities List. Can you try the diff
below?
Index: pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.92
diff -u -p -r1.92 pci.c
--- pci.c 30 May 2011 19:09:46 - 1.92
+++ pci.c 9 Jun 2011 21:10:22 -
@@ -564,10 +564,13 @@ pci_get_capability(pci_chipset_tag_t pc,
ofs = PCI_CAPLIST_PTR(pci_conf_read(pc, tag, ofs));
while (ofs != 0) {
-#ifdef DIAGNOSTIC
+ /*
+ * Some devices, like parts of the NVIDIA C51 chipset,
+ * have a broken Capabilities List. So we need to do
+ * a sanity check here.
+ */
if ((ofs 3) || (ofs 0x40))
- panic(pci_get_capability);
-#endif
+ return (0);
reg = pci_conf_read(pc, tag, ofs);
if (PCI_CAPLIST_CAP(reg) == capid) {
if (offset)
Re: sparc64 (sun v215) panics on bringing up intel Pro 1000- mt (em0) device
From: Joel Wiramu Pauling j...@aenertia.net Date: Fri, 3 Jun 2011 23:58:06 +1200 Thanks guys, on first glance this appears to have fixed the panic on up. Thanks for testing; the fix has been committed to -current. Not being C inclined can anyone offer an explanation? The old code was doing an unaligned access, which isn't allowed on sparc64, but happens to work i386/amd64 (even though it isn't supposed to).
Re: kernel/6621: hang during shutdown
The following reply was made to PR kernel/6621; it has been noted by GNATS. From: Mark Kettenis mark.kette...@xs4all.nl To: r...@thrush.com Cc: gn...@openbsd.org, b...@cvs.openbsd.org, r...@x2.thrush.com Subject: Re: kernel/6621: hang during shutdown Date: Thu, 2 Jun 2011 11:56:55 +0200 (CEST) The only useful information in your report is that .xz file. Next time, use something in base to compress it.
Re: system/6607: Network device em0 detaches when transferring large files
Date: Fri, 20 May 2011 09:48:22 -0500 From: cstol...@hushmail.com Thank you very much, Mark and Marco. Mark was 100% correct: Disabling ASPM made the problem go away. Do you mean your BIOS has an option to disable ASPM?
Re: system/6607: Network device em0 detaches when transferring large files
The following reply was made to PR system/6607; it has been noted by GNATS. From: Mark Kettenis mark.kette...@xs4all.nl To: cstol...@hushmail.com Cc: m...@mailq.de, gn...@openbsd.org, b...@cvs.openbsd.org Subject: Re: system/6607: Network device em0 detaches when transferring large files Date: Fri, 20 May 2011 17:01:30 +0200 (CEST) Date: Fri, 20 May 2011 09:48:22 -0500 From: cstol...@hushmail.com Thank you very much, Mark and Marco. Mark was 100% correct: Disabling ASPM made the problem go away. Do you mean your BIOS has an option to disable ASPM?
Re: system/6607: Network device em0 detaches when transferring large files
Spontanious detach usually is related to issues with Active State Power Management (ASPM). Indeed it seems there is an errata for the Intel 82573 that affects the 82574 as well. I don't have time to write a diff for this right now. But perhaps somebody else can pick this up.
Re: system/6607: Network device em0 detaches when transferring large files
The following reply was made to PR system/6607; it has been noted by GNATS. From: Mark Kettenis mark.kette...@xs4all.nl To: stol...@vinson.dyndns.info Cc: gn...@openbsd.org, b...@cvs.openbsd.org, cstol...@hushmail.com Subject: Re: system/6607: Network device em0 detaches when transferring large files Date: Thu, 19 May 2011 13:37:15 +0200 (CEST) Spontanious detach usually is related to issues with Active State Power Management (ASPM). Indeed it seems there is an errata for the Intel 82573 that affects the 82574 as well. I don't have time to write a diff for this right now. But perhaps somebody else can pick this up.
Re: ppc/6565: macppc doesn't exit X nicely
The following reply was made to PR ppc/6565; it has been noted by GNATS. From: Mark Kettenis mark.kette...@xs4all.nl To: n...@holland-consulting.net Cc: gn...@openbsd.org Subject: Re: ppc/6565: macppc doesn't exit X nicely Date: Thu, 17 Feb 2011 15:00:40 +0100 (CET) Happens on sparc64 too. In fact I'm sure this will happen on anything that isn't i386/amd64. This really is a bug in the Xorg xf86-video-ati driver. Please report this upstream.
Re: kernel/6539: panic: pool_do_get(mcl2k): free list modified
Does the diff below help? Index: if_sis.c === RCS file: /cvs/src/sys/dev/pci/if_sis.c,v retrieving revision 1.101 diff -u -p -r1.101 if_sis.c --- if_sis.c31 Aug 2010 17:13:44 - 1.101 +++ if_sis.c14 Feb 2011 12:30:32 - @@ -1272,6 +1272,11 @@ sis_newbuf(struct sis_softc *sc, struct c-sis_mbuf = m_new; c-sis_ptr = htole32(c-map-dm_segs[0].ds_addr); + + bus_dmamap_sync(sc-sc_dmat, sc-sc_listmap, + ((caddr_t)c - sc-sc_listkva), sizeof(struct sis_desc), + BUS_DMASYNC_PREWRITE); + c-sis_ctl = htole32(ETHER_MAX_DIX_LEN); bus_dmamap_sync(sc-sc_dmat, sc-sc_listmap,
Re: sparc64/6557: DMA error with ral(4)
The following reply was made to PR sparc64/6557; it has been noted by GNATS. From: Mark Kettenis mark.kette...@xs4all.nl To: t...@daybefore.net Cc: gn...@openbsd.org Subject: Re: sparc64/6557: DMA error with ral(4) Date: Sun, 13 Feb 2011 21:47:44 +0100 (CET) Does the diff below help? Index: rt2661.c === RCS file: /cvs/src/sys/dev/ic/rt2661.c,v retrieving revision 1.63 diff -u -p -r1.63 rt2661.c --- rt2661.c 7 Sep 2010 16:21:42 - 1.63 +++ rt2661.c 13 Feb 2011 20:46:16 - @@ -1004,19 +1004,19 @@ rt2661_tx_dma_intr(struct rt2661_softc * !(letoh32(desc-flags) RT2661_TX_VALID)) break; - bus_dmamap_sync(sc-sc_dmat, data-map, 0, - data-map-dm_mapsize, BUS_DMASYNC_POSTWRITE); - bus_dmamap_unload(sc-sc_dmat, data-map); - m_freem(data-m); - data-m = NULL; - /* node reference is released in rt2661_tx_intr() */ - /* descriptor is no longer valid */ desc-flags = ~htole32(RT2661_TX_VALID); bus_dmamap_sync(sc-sc_dmat, txq-map, txq-next * RT2661_TX_DESC_SIZE, RT2661_TX_DESC_SIZE, BUS_DMASYNC_PREWRITE); + + bus_dmamap_sync(sc-sc_dmat, data-map, 0, + data-map-dm_mapsize, BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc-sc_dmat, data-map); + m_freem(data-m); + data-m = NULL; + /* node reference is released in rt2661_tx_intr() */ DPRINTFN(15, (tx dma done q=%p idx=%u\n, txq, txq-next));
Re: i386/6540: panic on boot in pci_make_tag
Just committed the patch below which should fix this.
Index: i386/pci/pci_machdep.c
===
RCS file: /cvs/src/sys/arch/i386/pci/pci_machdep.c,v
retrieving revision 1.56
diff -u -p -r1.56 pci_machdep.c
--- i386/pci/pci_machdep.c 4 Jan 2011 21:17:49 - 1.56
+++ i386/pci/pci_machdep.c 9 Jan 2011 11:10:28 -
@@ -126,6 +126,7 @@ bus_addr_t pci_mcfg_addr;
int pci_mcfg_min_bus, pci_mcfg_max_bus;
bus_space_tag_t pci_mcfgt = I386_BUS_SPACE_MEM;
bus_space_handle_t pci_mcfgh[256];
+void pci_mcfg_map_bus(int);
struct mutex pci_conf_lock = MUTEX_INITIALIZER(IPL_HIGH);
@@ -224,15 +225,6 @@ pci_make_tag(pci_chipset_tag_t pc, int b
{
pcitag_t tag;
- if (pci_mcfg_addr) {
- if (bus pci_mcfg_min_bus || bus pci_mcfg_max_bus ||
- device = 32 || function = 8)
- panic(pci_make_tag: bad request);
-
- tag.mode1 = (bus 20) | (device 15) | (function 12);
- return tag;
- }
-
switch (pci_mode) {
case 1:
if (bus = 256 || device = 32 || function = 8)
@@ -259,16 +251,6 @@ pci_make_tag(pci_chipset_tag_t pc, int b
void
pci_decompose_tag(pci_chipset_tag_t pc, pcitag_t tag, int *bp, int *dp, int
*fp)
{
- if (pci_mcfg_addr) {
- if (bp != NULL)
- *bp = (tag.mode1 20) 0xff;
- if (dp != NULL)
- *dp = (tag.mode1 15) 0x1f;
- if (fp != NULL)
- *fp = (tag.mode1 12) 0x7;
- return;
- }
-
switch (pci_mode) {
case 1:
if (bp != NULL)
@@ -294,12 +276,28 @@ pci_decompose_tag(pci_chipset_tag_t pc,
int
pci_conf_size(pci_chipset_tag_t pc, pcitag_t tag)
{
- if (pci_mcfg_addr)
- return PCIE_CONFIG_SPACE_SIZE;
+ int bus;
+
+ if (pci_mcfg_addr) {
+ pci_decompose_tag(pc, tag, bus, NULL, NULL);
+ if (bus = pci_mcfg_min_bus bus = pci_mcfg_max_bus)
+ return PCIE_CONFIG_SPACE_SIZE;
+ }
return PCI_CONFIG_SPACE_SIZE;
}
+void
+pci_mcfg_map_bus(int bus)
+{
+ if (pci_mcfgh[bus])
+ return;
+
+ if (bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus 20), 1 20,
+ 0, pci_mcfgh[bus]))
+ panic(pci_conf_read: cannot map mcfg space);
+}
+
pcireg_t
pci_conf_read(pci_chipset_tag_t pc, pcitag_t tag, int reg)
{
@@ -308,13 +306,12 @@ pci_conf_read(pci_chipset_tag_t pc, pcit
if (pci_mcfg_addr) {
pci_decompose_tag(pc, tag, bus, NULL, NULL);
- if (pci_mcfgh[bus] == 0
- bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus 20),
- 1 20, 0, pci_mcfgh[bus]))
- panic(pci_conf_read: cannot map mcfg space);
- data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
- (tag.mode1 0x000ff000) | reg);
- return data;
+ if (bus = pci_mcfg_min_bus bus = pci_mcfg_max_bus) {
+ pci_mcfg_map_bus(bus);
+ data = bus_space_read_4(pci_mcfgt, pci_mcfgh[bus],
+ (tag.mode1 0x000ff00) 4 | reg);
+ return data;
+ }
}
PCI_CONF_LOCK();
@@ -345,13 +342,12 @@ pci_conf_write(pci_chipset_tag_t pc, pci
if (pci_mcfg_addr) {
pci_decompose_tag(pc, tag, bus, NULL, NULL);
- if (pci_mcfgh[bus] == 0
- bus_space_map(pci_mcfgt, pci_mcfg_addr + (bus 20),
- 1 20, 0, pci_mcfgh[bus]))
- panic(pci_conf_write: cannot map mcfg space);
- bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
- (tag.mode1 0x000ff000) | reg, data);
- return;
+ if (bus = pci_mcfg_min_bus bus = pci_mcfg_max_bus) {
+ pci_mcfg_map_bus(bus);
+ bus_space_write_4(pci_mcfgt, pci_mcfgh[bus],
+ (tag.mode1 0x000ff00) 4 | reg, data);
+ return;
+ }
}
PCI_CONF_LOCK();
Index: amd64/pci/pci_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/pci/pci_machdep.c,v
retrieving revision 1.38
diff -u -p -r1.38 pci_machdep.c
--- amd64/pci/pci_machdep.c 4 Jan 2011 21:17:49 - 1.38
+++ amd64/pci/pci_machdep.c 9 Jan 2011 11:10:28 -
@@ -108,6 +108,7 @@ bus_addr_t pci_mcfg_addr;
int pci_mcfg_min_bus, pci_mcfg_max_bus;
bus_space_tag_t pci_mcfgt = X86_BUS_SPACE_MEM;
bus_space_handle_t pci_mcfgh[256];
+void pci_mcfg_map_bus(int);
struct mutex pci_conf_lock = MUTEX_INITIALIZER(IPL_HIGH);
@@ -170,14 +171,6 @@ pci_make_tag(pci_chipset_tag_t pc, int b
if (bus = 256 || device = 32 || function = 8)
Re: Panic caused by nVidia MPC61 Ethernet adapter.
Date: Fri, 7 Jan 2011 18:25:08 -0700
From: Travis King ona...@lavabit.com
nfe0 at pci0 dev 7 function 0 NVIDIA MCP61 LAN rev 0xa2: apic 1 int 5
(irq 5), address 40:61:86:cc:1c:eb
rlphy0 at nfe0 phy 0: RTL8201L 10/100 PHY, rev. 1
rlphy1 at nfe0 phy 1: RTL8201L 10/100 PHY, rev. 1
rlphy2 at nfe0 phy 2: RTL8201L 10/100 PHY, rev. 1
Looks like the PHY on that interface is a bit messed up and responds
to all addresses on the MII bus. Does the attached diff help?
Index: if_nfe.c
===
RCS file: /cvs/src/sys/dev/pci/if_nfe.c,v
retrieving revision 1.96
diff -u -p -r1.96 if_nfe.c
--- if_nfe.c7 Sep 2010 16:21:45 - 1.96
+++ if_nfe.c8 Jan 2011 10:30:26 -
@@ -368,8 +368,7 @@ nfe_attach(struct device *parent, struct
ifmedia_init(sc-sc_mii.mii_media, 0, nfe_ifmedia_upd,
nfe_ifmedia_sts);
- mii_attach(self, sc-sc_mii, 0x, MII_PHY_ANY,
- MII_OFFSET_ANY, 0);
+ mii_attach(self, sc-sc_mii, 0x, MII_PHY_ANY, 0, 0);
if (LIST_FIRST(sc-sc_mii.mii_phys) == NULL) {
printf(%s: no PHY found!\n, sc-sc_dev.dv_xname);
ifmedia_add(sc-sc_mii.mii_media, IFM_ETHER | IFM_MANUAL,
Re: kernel/6531: wd(4) LBA48 hard disk problem and fix on Apple Macintosh MacBook Pro
Date: Wed, 29 Dec 2010 19:19:32 +0100 From: Mathias Schmocker s...@smat.ch wd0c: id not found reading fsbn 268435440 of 268435440-268435455 (wd0 bn 268435440; cn 16709 tn 85 sn 0), retrying wd0c: id not found reading fsbn 268435455 of 268435440-268435455 (wd0 bn 268435455; cn 16709 tn 85 sn 15), retrying wd0c: id not found reading fsbn 268435455 of 268435440-268435455 (wd0 bn 268435455; cn 16709 tn 85 sn 15) Hmm, the block numbers there suggest that there is actually a problem with reading the last sector that is still addressable with 32 bits. We really want to avoid using LBA48 addressing if we don't have to use it. On some Acer Labs pciide(4) controllers DMA with LBA48 addresses is broken and we have to use PIO instead, which is horribly slow. Can you try the diff below instead of your origional diff? Index: wd.c === RCS file: /cvs/src/sys/dev/ata/wd.c,v retrieving revision 1.95 diff -u -p -r1.95 wd.c --- wd.c22 Sep 2010 01:18:57 - 1.95 +++ wd.c29 Dec 2010 18:52:54 - @@ -548,7 +548,7 @@ __wdstart(struct wd_softc *wd, struct bu nblks = bp-b_bcount / wd-sc_dk.dk_label-d_secsize; if ((wd-sc_flags WDF_LBA48) /* use LBA48 only if really need */ - ((wd-sc_wdc_bio.blkno + nblks - 1 LBA48_THRESHOLD) || + ((wd-sc_wdc_bio.blkno + nblks - 1 = LBA48_THRESHOLD) || (nblks 0xff))) wd-sc_wdc_bio.flags |= ATA_LBA48; if (wd-sc_flags WDF_LBA)
Re: kernel/6531: wd(4) LBA48 hard disk problem and fix on Apple Macintosh MacBook Pro
Can you try a -current kernel? It has some changes that make pciide(4) do DMA. That makes disk I/O much faster and might actually fix the issue as well.
Re: kernel/6531: wd(4) LBA48 hard disk problem and fix on Apple Macintosh MacBook Pro
The following reply was made to PR kernel/6531; it has been noted by GNATS. From: Mark Kettenis mark.kette...@xs4all.nl To: s...@smat.ch Cc: gn...@openbsd.org, b...@cvs.openbsd.org Subject: Re: kernel/6531: wd(4) LBA48 hard disk problem and fix on Apple Macintosh MacBook Pro Date: Tue, 28 Dec 2010 16:29:22 +0100 (CET) Can you try a -current kernel? It has some changes that make pciide(4) do DMA. That makes disk I/O much faster and might actually fix the issue as well.
Re: kernel/6524: vge(4) goes dead under load on recent snapshots
The following reply was made to PR kernel/6524; it has been noted by GNATS.
From: Mark Kettenis mark.kette...@xs4all.nl
To: o...@bartula.de
Cc: gn...@openbsd.org, b...@cvs.openbsd.org
Subject: Re: kernel/6524: vge(4) goes dead under load on recent snapshots
Date: Thu, 16 Dec 2010 11:54:35 +0100 (CET)
Does this diff fix the issue?
Index: if_vge.c
===
RCS file: /cvs/src/sys/dev/pci/if_vge.c,v
retrieving revision 1.48
diff -u -p -r1.48 if_vge.c
--- if_vge.c 27 Aug 2010 17:08:00 - 1.48
+++ if_vge.c 16 Dec 2010 10:52:53 -
@@ -915,6 +915,9 @@ vge_newbuf(struct vge_softc *sc, int idx
#define VGE_RXCHUNK 4
sc-vge_rx_consumed++;
if (sc-vge_rx_consumed == VGE_RXCHUNK) {
+ bus_dmamap_sync(sc-sc_dmat, rxmap, 0,
+ rxmap-dm_mapsize, BUS_DMASYNC_PREWRITE);
+
for (i = idx; i != idx - sc-vge_rx_consumed; i--)
sc-vge_ldata.vge_rx_list[i].vge_sts |=
htole32(VGE_RDSTS_OWN);
Re: amd64/6480: Activating bluetooth causes repeatable kernel panic on amd64 snapshots
I believe somebody passed that around on a list before, but there are other malloc bugs in bt code. Doesn't mean this diff shouldn't go in. So this diff is ok kettenis@; please commit this miod. On Tue, Nov 16, 2010 at 2:09 PM, Miod Vallat m...@online.fr wrote: http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=6480 Concerning PR 6480 I need to add: it's caused by the btconfig ubt* up commmand, at least on my machine. And it happens on i386, too. Please try the following diff. Miod Index: uhci.c === RCS file: /cvs/src/sys/dev/usb/uhci.c,v retrieving revision 1.84 diff -u -p -r1.84 uhci.c --- uhci.c 23 Oct 2010 15:42:09 - 1.84 +++ uhci.c 18 Nov 2010 19:10:13 - @@ -2757,7 +2757,9 @@ uhci_device_setintr(uhci_softc_t *sc, st upipe-u.intr.npoll = npoll; upipe-u.intr.qhs = - malloc(npoll * sizeof(uhci_soft_qh_t *), M_USBHC, M_WAITOK); + malloc(npoll * sizeof(uhci_soft_qh_t *), M_USBHC, M_NOWAIT); + if (upipe-u.intr.qhs == NULL) + return (USBD_NOMEM); /* * Figure out which offset in the schedule that has most
