Re: chromium 48 (64-bit) crashes on 5.9-beta and xfce-4.12
On Wed, Feb 03, 2016 at 08:35:29PM +0100, bian wrote: > Hi, > > running stock OpenBSD 5.9-beta, xfce-4.12p3, and chromium 48.0.2564.97 > (64-bit) from snapshots as of Feb. 2 I get get frequent chromium crashes > with resulting core dumps (about every 7-8 starts). This happens when > starting the browser. Once started it is stable. dmesg and output from gdb > on a chromium core dump can be found below. > > I have similar problems when using firefox-esr 38.6.0, also from snapshots > of the same date. Here the start typically goes well, but when switching to > another desktop, opening thunar (the file manager), and opening a text file > for editing, then chances are high that firefox crashes. This is, however > highly irregular and I haven't really found a reliable way to reproduce the > error. > > Both browsers have one extension installed, uBlock Origin, otherwise they > are stock. This crashing behaviour occurred also on obsd-5.8 and it was one > of my reasons for switching from 5.8 to 5.9-beta. > > Does anyone know what is going on here? I experienced this problem a few times, when starting the browser it used to crash. But it didn't happened anymore. However I'm not on last chromium, mine is 47.0.2526.111. All the rest seems to work normally.
Cannot Cleanly Exit FVWM / X Windows System
Hi Everyone! This is my first post to the mailing list as I am new to OpenBSD. I am running version 5.8 (amd64) on a Lenovo Thinkpad T450s with a fairly default installation. I have a few issues to sort out but my first concern is that I cannot exit out of FVWM. I launch it via the command startx while logged in as root. When I go to exit (left mouse click on the desktop > Exit), the system just hangs which requires me to forcefully power down the laptop. I am not using a login or display manager such as xdm(1) so I do not have an ~/.xinitrc or /etc/rc.conf.local file. During installation, I answered Yes to "Do you expect to run the X Window System?" and No to "Do you want the X Window System to be started by xdm(1)?" Any ideas or suggestions? Thanks in advance. Samir Parikh
Re: chromium 48 (64-bit) crashes on 5.9-beta and xfce-4.12
Hello, thanks for your prompt answer. I did not try without the uBlock Origin extension and I've read about the problem you describe. As per your suggestion I will resubmit the this entire thread to the bugs list. Best regards /birger On 2016-02-03 20:57, Mariano Baragiola wrote: Hello. On 02/03/16 16:35, bian wrote: Both browsers have one extension installed, uBlock Origin, otherwise they are stock. This crashing behaviour occurred also on obsd-5.8 and it was one of my reasons for switching from 5.8 to 5.9-beta. Have you tried opening them without uBlock Origin? There was a known error in 5.8 amd64 with Chromium and uBlock Origin, but the crash victim was the extension and not the browser, at least on my case (I found some people saying the entire browser was crashing). Maybe it is related in some way. Btw, I'm no longer experiencing the problem in 5.8-stable amd64. PS: This thread probably belongs to b...@openbsd.org. Cheers.
iwn WiFi slow in CURRENT
Hey, I recently upgraded 5.8 to CURRENT to test the new 802.11n WiFi additions which I am very excited about. I noticed that in CURRENT the WiFi throughput is much slower. The environment I am testing it in is at my university with wall-mounted Cisco APs (sorry, not very detailled). Trying to connect to the AP in 11n mode does not work. The OS then seems to fall back to "OFDM18 mode 11g" or "OFDM36 mode 11a". Both of these modes yield pretty slow throughput, less than 1MBit/s down and around 2MBit/s up. Previously, this was not a problem. Although 11n obviously did not work, I had usable throughput in the older modes. The chip is a Intel Centrino Advanced-N 6205. Is this expected due to ongoing work? Should I file a bug? Best regards Henrik
providing users with equal bandwidth
hello misc, i am using openbsd 5.8 amd64 on my apu 1d4 with success but i have one big problem. the queue mechanism in pf allows some traffic shaping but what i really need is to give users their share of the bandwidth. for this i need some connection based algorithm like sfq (linux) or cbq (mikrotik - routeros). i have read and searched around a lot but it seems not possible to do such a thing with pf. is it possible to arrange this kind of bandwith sharing with a proxy like relayd? does anybody have suggestions? all feedback is sincerely appreciated. regards to all.
Re: httpd logs errors to /var/log/messages rather than error.log?
Ping. Anyone else seeing the same thing? Should I take this to bugs@? Thanks, On Sun, January 31, 2016 11:10 pm, Joe Gidi wrote: > I noticed some odd behavior by httpd that isn't clear from reading the > httpd and httpd.conf man pages. > > I'm running the Jan 21 snapshot on an amd64 box. I have a very minimal > httpd.conf that contains no logging directives, so it should use the > default /var/www/logs/access.log and /var/www/logs/error.log files. The > access.log file is used as expected, but it appears that errors are ending > up in /var/log/messages rather than in error.log. > > For example, if I run the Qualys SSL Test ( > https://www.ssllabs.com/ssltest/ ) against my site, I see all of the > various SSL handshake attempts show up in /var/log/messages. error.log > remains an empty file. > > Am I misunderstanding something, or is the documentation out of sync with > httpd's actual behavior? > > Thanks, > > -- > Joe Gidi > j...@entropicblur.com > > "You cannot buy skill." -- Ross Seyfried > > -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: how to break /etc/weekly and your locate.database
On 02/03/16 11:51, Scott Bonds wrote: > I thought I was being clever by doing all of: > > * disabling root's password ok. > * disabling SSH login by root ok. > * setting root's shell to /sbin/nologin no. don't do that. > ... but I figure I should take the hint that su is > assumed to work, and if it doesn't, its possible other subtle > breakages in the system will happen. > > Thought I'd share. yep. There are an infinite number of ways to break a system, or at least a much larger number of ways to break than to improve things. You found one. Even the disabling the root password, something I've been doing for well over ten years on OpenBSD turned out to have some risks when doas replaced sudo, as the upgrade would break sudo, but doas wasn't configured yet. Nick.
how to break /etc/weekly and your locate.database
I thought I was being clever by doing all of: * disabling root's password * disabling SSH login by root * setting root's shell to /sbin/nologin su stopped working, but I don't use su, or so I thought, until I noticed my locate.database was always 41B aka empty. Turns out /etc/weekly *does* use su, specifically during the generation of /var/db/locate.database which is handy if you want to use the locate command at all. Changing root's shell back to /bin/ksh fixed the issue and I can use locate again. I could work around this specific (self-inflicted) problem by using a different script for generating my locate.database and put it in /etc/weekly.local, but I figure I should take the hint that su is assumed to work, and if it doesn't, its possible other subtle breakages in the system will happen. Thought I'd share.
Re: iwn WiFi slow in CURRENT
On Wed, Feb 03, 2016 at 04:10:22PM +0100, Henrik Friedrichsen wrote: > Hey, > > I recently upgraded 5.8 to CURRENT to test the new 802.11n WiFi > additions which I am very excited about. > > I noticed that in CURRENT the WiFi throughput is much slower. The > environment I am testing it in is at my university with wall-mounted > Cisco APs (sorry, not very detailled). Yes, there are still known problems with some APs. Many APs work fine, though. The details of why some APs don't work fine are still unclear. > Trying to connect to the AP in 11n mode does not work. The OS then seems > to fall back to "OFDM18 mode 11g" or "OFDM36 mode 11a". Both of these > modes yield pretty slow throughput, less than 1MBit/s down and around > 2MBit/s up. Does forcing 11g or 11a mode like this fix it? For 2GHz AP: ifconfig iwn0 mode 11g For 5GHz AP: ifconfig iwn0 mode 11a These commands should restore 5.8 behaviour even if the AP is bad in 11n mode. To go back to autoselecting a mode, run: ifconfig iwn0 -mode
chromium 48 (64-bit) crashes on 5.9-beta and xfce-4.12
Hi, running stock OpenBSD 5.9-beta, xfce-4.12p3, and chromium 48.0.2564.97 (64-bit) from snapshots as of Feb. 2 I get get frequent chromium crashes with resulting core dumps (about every 7-8 starts). This happens when starting the browser. Once started it is stable. dmesg and output from gdb on a chromium core dump can be found below. I have similar problems when using firefox-esr 38.6.0, also from snapshots of the same date. Here the start typically goes well, but when switching to another desktop, opening thunar (the file manager), and opening a text file for editing, then chances are high that firefox crashes. This is, however highly irregular and I haven't really found a reliable way to reproduce the error. Both browsers have one extension installed, uBlock Origin, otherwise they are stock. This crashing behaviour occurred also on obsd-5.8 and it was one of my reasons for switching from 5.8 to 5.9-beta. Does anyone know what is going on here? Best regards /birger OpenBSD 5.9-beta (GENERIC.MP) #1863: Sun Jan 24 21:35:42 MST 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4139388928 (3947MB) avail mem = 4009746432 (3823MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe9f80 (88 entries) bios0: vendor Hewlett-Packard version "786G1 v01.16" date 03/05/2009 bios0: Hewlett-Packard HP Compaq dc7900 Convertible Minitower acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR acpi0: wakeup devices COM1(S4) COM2(S4) PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz, 3159.12 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz, 3158.75 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG1) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 32 (PCX1) acpiprt4 at acpi0: bus -1 (PCX2) acpiprt5 at acpi0: bus 48 (PCX5) acpiprt6 at acpi0: bus -1 (PCX6) acpiprt7 at acpi0: bus 7 (HUB_) acpicpu0 at acpi0: !C2(500@17 mwait.3@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C2(500@17 mwait.3@0x10), C1(1000@1 mwait.1), PSS acpibtn0 at acpi0: PBTN cpu0: Enhanced SpeedStep 3159 MHz: speeds: 3166, 1998 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03 ppb0 at pci0 dev 1 function 0 "Intel Q45 PCIE" rev 0x03: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 2600 XT" rev 0x00 drm0 at radeondrm0 radeondrm0: msi "Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 1 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 15 bytes em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: msi, address 00:24:81:1f:f4:91 uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801JD USB" rev 0x02: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801JD USB" rev 0x02: apic 1 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801JD HD Audio" rev 0x02: msi azalia0: codecs: Analog Devices AD1884A audio0 at azalia0 ppb1 at pci0 dev 28 function 0
Re: iwn WiFi slow in CURRENT
On Wed, Feb 03, 2016 at 04:46:45PM +0100, Stefan Sperling wrote:
> On Wed, Feb 03, 2016 at 04:10:22PM +0100, Henrik Friedrichsen wrote:
> > Hey,
> >
> > I recently upgraded 5.8 to CURRENT to test the new 802.11n WiFi
> > additions which I am very excited about.
> >
> > I noticed that in CURRENT the WiFi throughput is much slower. The
> > environment I am testing it in is at my university with wall-mounted
> > Cisco APs (sorry, not very detailled).
>
> Yes, there are still known problems with some APs.
> Many APs work fine, though. The details of why some APs don't work fine
> are still unclear.
>
> > Trying to connect to the AP in 11n mode does not work. The OS then seems
> > to fall back to "OFDM18 mode 11g" or "OFDM36 mode 11a". Both of these
> > modes yield pretty slow throughput, less than 1MBit/s down and around
> > 2MBit/s up.
>
> Does forcing 11g or 11a mode like this fix it?
>
> For 2GHz AP:
> ifconfig iwn0 mode 11g
>
> For 5GHz AP:
> ifconfig iwn0 mode 11a
>
> These commands should restore 5.8 behaviour even if the AP is bad in 11n mode.
>
> To go back to autoselecting a mode, run:
>
> ifconfig iwn0 -mode
>
Does this diff help?
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.76
diff -u -p -r1.76 if_iwm.c
--- if_iwm.c25 Jan 2016 11:27:11 - 1.76
+++ if_iwm.c3 Feb 2016 18:23:17 -
@@ -4466,6 +4466,7 @@ iwm_mvm_sta_send_to_fw(struct iwm_softc
struct iwm_mvm_add_sta_cmd_v6 add_sta_cmd;
int ret;
uint32_t status;
+ struct ieee80211com *ic = >sc_ic;
memset(_sta_cmd, 0, sizeof(add_sta_cmd));
@@ -4480,6 +4481,35 @@ iwm_mvm_sta_send_to_fw(struct iwm_softc
add_sta_cmd.station_flags_msk
|= htole32(IWM_STA_FLG_FAT_EN_MSK | IWM_STA_FLG_MIMO_EN_MSK);
+ if (in->in_ni.ni_flags & IEEE80211_NODE_HT) {
+ add_sta_cmd.station_flags_msk
+ |= htole32(IWM_STA_FLG_MAX_AGG_SIZE_MSK |
+ IWM_STA_FLG_AGG_MPDU_DENS_MSK);
+
+ add_sta_cmd.station_flags
+ |= htole32(IWM_STA_FLG_MAX_AGG_SIZE_64K);
+ switch (ic->ic_ampdu_params & IEEE80211_AMPDU_PARAM_SS) {
+ case IEEE80211_AMPDU_PARAM_SS_2:
+ add_sta_cmd.station_flags
+ |= htole32(IWM_STA_FLG_AGG_MPDU_DENS_2US);
+ break;
+ case IEEE80211_AMPDU_PARAM_SS_4:
+ add_sta_cmd.station_flags
+ |= htole32(IWM_STA_FLG_AGG_MPDU_DENS_4US);
+ break;
+ case IEEE80211_AMPDU_PARAM_SS_8:
+ add_sta_cmd.station_flags
+ |= htole32(IWM_STA_FLG_AGG_MPDU_DENS_8US);
+ break;
+ case IEEE80211_AMPDU_PARAM_SS_16:
+ add_sta_cmd.station_flags
+ |= htole32(IWM_STA_FLG_AGG_MPDU_DENS_16US);
+ break;
+ default:
+ break;
+ }
+ }
+
status = IWM_ADD_STA_SUCCESS;
ret = iwm_mvm_send_add_sta_cmd_status(sc, _sta_cmd, );
if (ret)
@@ -6810,11 +6840,11 @@ iwm_attach(struct device *parent, struct
IEEE80211_C_SHPREAMBLE; /* short preamble supported */
/* No optional HT features supported for now, */
- ic->ic_htcaps = 0;
+ ic->ic_htcaps = IEEE80211_HTCAP_SMPS_DIS;
ic->ic_htxcaps = 0;
ic->ic_txbfcaps = 0;
ic->ic_aselcaps = 0;
- ic->ic_ampdu_params = IEEE80211_AMPDU_PARAM_SS_4;
+ ic->ic_ampdu_params = (IEEE80211_AMPDU_PARAM_SS_4 | 0x3 /* 64k */);
ic->ic_sup_rates[IEEE80211_MODE_11A] = ieee80211_std_rateset_11a;
ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.158
diff -u -p -r1.158 if_iwn.c
--- if_iwn.c25 Jan 2016 11:27:11 - 1.158
+++ if_iwn.c3 Feb 2016 18:42:49 -
@@ -456,11 +456,11 @@ iwn_attach(struct device *parent, struct
IEEE80211_C_PMGT; /* power saving supported */
/* No optional HT features supported for now, */
- ic->ic_htcaps = 0;
+ ic->ic_htcaps = IEEE80211_HTCAP_SMPS_DIS;
ic->ic_htxcaps = 0;
ic->ic_txbfcaps = 0;
ic->ic_aselcaps = 0;
- ic->ic_ampdu_params = IEEE80211_AMPDU_PARAM_SS_4;
+ ic->ic_ampdu_params = (IEEE80211_AMPDU_PARAM_SS_4 | 0x3 /* 64k */);
#ifdef notyet
if (sc->sc_flags & IWN_FLAG_HAS_11N) {
@@ -4920,10 +4920,15 @@ iwn_run(struct iwn_softc *sc)
memset(, 0, sizeof node);
IEEE80211_ADDR_COPY(node.macaddr, ni->ni_macaddr);
node.id = IWN_ID_BSS;
-#ifdef notyet
- node.htflags = htole32(IWN_AMDPU_SIZE_FACTOR(3) |
FYI: How to use Intel GPU of MacBookPro8,2 via EFI boot
With some EFI boot loader and kernel modifications it is possible to disable the power-hungry Radeon (by accessing GMUX) and use the Intel GPU of a MacBookPro8,2 with OpenBSD 5.9 snapshot. Details: https://photorhino.wordpress.com/2016/02/03/openbsd-on-a-macbookpro82-with-intel-gpu/
Re: chromium 48 (64-bit) crashes on 5.9-beta and xfce-4.12
Hello. On 02/03/16 16:35, bian wrote: > > Both browsers have one extension installed, uBlock Origin, otherwise > they are stock. This crashing behaviour occurred also on obsd-5.8 and it > was one of my reasons for switching from 5.8 to 5.9-beta. > Have you tried opening them without uBlock Origin? There was a known error in 5.8 amd64 with Chromium and uBlock Origin, but the crash victim was the extension and not the browser, at least on my case (I found some people saying the entire browser was crashing). Maybe it is related in some way. Btw, I'm no longer experiencing the problem in 5.8-stable amd64. PS: This thread probably belongs to b...@openbsd.org. Cheers.
