Re: radeon drm regression (was Re: D-Link DGE-528T / re(4) regression)

2015-04-08 Thread Jonathan Gray
On Wed, Apr 08, 2015 at 07:14:57PM +0200, Daniel Jakots wrote:
 On Wed, 8 Apr 2015 20:03:00 +1000, j...@insec.sh wrote:
 
  but could you try it with the following patch applied?
 
 Sure, I updated my cvs src tree, patched it and made a new kernel.
 
 I booted on the new kernel then, but when usually the screen blink and
 then says:
 radeondrm0: 1680x1050
 wsdisplay0 at radeondrm0 mux 1: blah blah blah
 
 the screen simply goes off as if it doesn't receive any input anymore.

Is that with rev 1.4 of sys/dev/pci/drm/drm_linux.c ?



Re: D-Link DGE-528T / re(4) regression

2015-04-08 Thread jgs
On Tue, Apr 07, 2015 at 10:34:29PM +0200, Daniel Jakots wrote:
 Hi,
 
 I bought recently a D-Link DGE-528T because it was said in re(4)
 that it is working. 

this is probably due to my jumbo diff. i can't repro this problem on
my re(4)s, but could you try it with the following patch applied? i
missed fixing up RL_JUMBO_MTU_7K and i think your chip will use it.

Index: rtl81x9reg.h
===
RCS file: /cvs/src/sys/dev/ic/rtl81x9reg.h,v
retrieving revision 1.93
diff -u -p -u -r1.93 rtl81x9reg.h
--- rtl81x9reg.h20 Mar 2015 12:04:09 -  1.93
+++ rtl81x9reg.h8 Apr 2015 09:52:10 -
@@ -751,7 +751,7 @@ struct rl_stats {
 #define RL_JUMBO_MTU_6K\
((6 * 1024) - ETHER_HDR_LEN - ETHER_CRC_LEN - ETHER_VLAN_ENCAP_LEN)
 #define RL_JUMBO_MTU_7K\
-   (RL_JUMBO_FRAMELEN - ETHER_HDR_LEN - ETHER_CRC_LEN - 
ETHER_VLAN_ENCAP_LEN)
+   ((7 * 1024) - ETHER_HDR_LEN - ETHER_CRC_LEN - ETHER_VLAN_ENCAP_LEN)
 #define RL_JUMBO_MTU_9K\
((9 * 1024) - ETHER_HDR_LEN - ETHER_CRC_LEN - ETHER_VLAN_ENCAP_LEN)
 #define RL_MTU ETHERMTU

 
 I can get a lease dhcp but then connection doesn't work reliably.
 For instance, if I go with firefox on www.openbsd.org, all I get is:
 
 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 html
 head
 titleOpenBSD/title
 meta name=resource-type content=document
 meta http-equiv=Content-Type content=text/html;
 charset=iso-8859-1 meta name=description content=the main OpenBSD
 page meta name=keywords content=openbsd,main
 meta name=distribution content=global
 meta name=copyright content=This document copyright 1999-2014
 by OpenBSD. link rel=shortcut icon HREF=/favicon.ico
 TYPE=image/x-icon /head
 body text=#00 bgcolor=#ff topmargin=0 leftmargin=0
 marginheight=0 marginwidth=0 table width=10
 
 then there's some garbage and that's all that 'view source' shows.
 
 If I ssh my server running amd64 5.6 -stable, I get:
 
 ssh_dispatch_run_fatal: message authentication code incorrect
 
 but strangely enough, if I ssh my router (pcengines apu) running also
 amd64 5.6 -stable it works, the only difference is there I use ed25519
 keys whereas on my server it's a RSA key.
 
 I tested some kernel to see when the problem appears:
 - bsd.mp 19-Mar-2015 is working correctly (I mean, I don't have these
   problems at least)
 - bsd.mp 26-Mar-2015 isn't working
 
 The dmesg while I'm still running bsd.mp from 26t March snapshot
 (hint, it's re1, not re0, I don't use re0 because I have problem with
 that NIC):
 
 OpenBSD 5.7-current (GENERIC.MP) #896: Thu Mar 26 14:56:12 MDT 2015
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 2129526784 (2030MB)
 avail mem = 2061189120 (1965MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (39 entries)
 bios0: vendor Award Software International, Inc. version F6 date
 09/07/2007 bios0: Gigabyte Technology Co., Ltd. P35-DS3R
 acpi0 at bios0: rev 0
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP HPET MCFG APIC SSDT SSDT
 acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5)
 PEX5(S5) HUB0(S5) UAR1(S3) IGBE(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3)
 US31(S3) USB4(S3) USB5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24
 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr
 0xf000, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz, 3000.42 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,NXE,LONG,LAHF,PERF
 cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 333MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.2.0.0, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz, 3000.01 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,NXE,LONG,LAHF,PERF
 cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
 ioapic0: misconfigured as apic 0, remapped to apid 2
 acpiprt0 at acpi0: bus 0 (PCI0)
 acpiprt1 at acpi0: bus 2 (PEX0)
 acpiprt2 at acpi0: bus -1 (PEX1)
 acpiprt3 at acpi0: bus -1 (PEX2)
 acpiprt4 at acpi0: bus 3 (PEX3)
 acpiprt5 at acpi0: bus 4 (PEX4)
 acpiprt6 at acpi0: bus -1 (PEX5)
 acpiprt7 at acpi0: bus 5 (HUB0)
 acpicpu0 at acpi0: FVS, 3000, 2000 MHz
 acpicpu1 at acpi0: FVS, 3000, 2000 MHz
 acpibtn0 at acpi0: PWRB
 pci0 at mainbus0 bus 0
 pchb0 

Re: malo driver NMI after sending auth: Stopped at ieee80211_recv_auth+0x23

2015-04-08 Thread Stefan Sperling
On Tue, Apr 07, 2015 at 07:06:20PM -0500, Walter Daugherity wrote:
 Synopsis: malo driver NMI after sending auth: Stopped at 
 ieee80211_recv_auth+0x23
  This is a 90MHz Pentium (Compaq Deskpro XL 590) with a Netgear
 WG311v3 WiFi card which uses the malo driver.  On bootup the malo driver
 probes for a WiFi link but crashes with a NMI after sending auth.

I don't believe this is a problem with the malo(4) driver itself.
I have a malo(4) device which works just fine on -current amd64 and i386.

Can you please try this wifi card in a different machine?
If the card works there then this is not a problem with malo(4) but
something else, perhaps related to PCI.