Re: Switch mfii(4) to msi, testing required.
ok by me.
On 05/08/2013, at 7:04 PM, Christiano F. Haesbaert
wrote:
> On Thu, Jun 06, 2013 at 12:54:31PM +0200, Christiano F. Haesbaert wrote:
>> Hi,
>>
>> We would like to switch mfii(4) to msi, there is a family of supermicro
>> X9 motherboards with incorrect ioapic routing, so they only work properly
>> though msi.
>>
>> If you have a system with a mfii(4) device, please give this diff a spin
>> and report back.
>>
>> So far I was able to test on:
>>
>> Supermicro X9DRH + Symbios Logic MegaRAID SAS2208
>> Fujitsu primergy RX300 S7 + Symbios Logic MegaRAID SAS2208
>>
>> Index: dev/pci/mfii.c
>> ===
>> RCS file: /cvs/src/sys/dev/pci/mfii.c,v
>> retrieving revision 1.12
>> diff -d -u -p -r1.12 mfii.c
>> --- dev/pci/mfii.c 25 Aug 2012 07:03:04 - 1.12
>> +++ dev/pci/mfii.c 6 Jun 2013 10:47:23 -
>> @@ -307,7 +307,7 @@ mfii_attach(struct device *parent, struc
>> /* disable interrupts */
>> mfii_write(sc, MFI_OMSK, 0x);
>>
>> -if (pci_intr_map(pa, &ih) != 0) {
>> +if (pci_intr_map_msi(pa, &ih) != 0 && pci_intr_map(pa, &ih) != 0) {
>> printf(": unable to map interrupt\n");
>> goto pci_unmap;
>> }
>
> So far I've received only one report where this diff makes it possible
> to use the Supermicro branded AOC-S2208-H8iR LSI SAS 2208, where the
> apic routing is probably busted too.
>
> We're reaching the point where we'll see more machines with wrong apic
> routing since most newer chips are only being tested with MSI enabled.
> This is one case of it.
>
> I'd like to commit this after release.
>
Inline assembly is hard...
The atomic_setbits_int() and atomic_clearbits_int() implementations use stwcx., which touches the condition code register. This means we need to tell GCC that it gets clobbered. Fixes issues with uvm_page_physload() which currently gets miscompiled. ok? Index: atomic.h === RCS file: /cvs/src/sys/arch/powerpc/include/atomic.h,v retrieving revision 1.4 diff -u -p -r1.4 atomic.h --- atomic.h23 Mar 2011 16:54:36 - 1.4 +++ atomic.h5 Aug 2013 22:34:00 - @@ -17,7 +17,7 @@ atomic_setbits_int(__volatile unsigned i " or %0, %1, %0 \n" " stwcx. %0, 0, %2 \n" " bne-1b \n" - " sync" : "=&r" (tmp) : "r" (v), "r" (uip) : "memory"); + " sync" : "=&r" (tmp) : "r" (v), "r" (uip) : "cc", "memory"); } static __inline void @@ -30,7 +30,7 @@ atomic_clearbits_int(__volatile unsigned " andc%0, %0, %1 \n" " stwcx. %0, 0, %2 \n" " bne-1b \n" - " sync" : "=&r" (tmp) : "r" (v), "r" (uip) : "memory"); + " sync" : "=&r" (tmp) : "r" (v), "r" (uip) : "cc", "memory"); } #endif /* defined(_KERNEL) */
Re: OpenBSD-current on MacBookPro9,2 Xorg acpilk-ed
Hi Milan, Moving this to tech@; the S/N ratio on misc@ is too low, and this is a techinical issue. > I've installed OpenBSD-current to MacBookPro 9,2 (Mid-2012). It seems to be > working without problems. Howoever Xorg locks after some random time at > acpilk (process state in top). > So I've decided to debug it. Set ddb.console=1 in /etc/sysctl.conf, however > was unable to jump to ddb debugger with ddb.trigger: > > # sysctl ddb.console > ddb.console=1 > # sysctl ddb.trigger=1 > sysctl: ddb.trigger: Operation not supported by device > > I'm connected from another OpenBSD box via ssh. Kernel is GENERIC.MP and > have ddb enabled. > I'm obviously doing something wrong, could someone please push me a bit? > > Thanks a lot, sysctl ddb.trigger only works if you're at securelevel 0, or if you're on the console. Anyway, X hanging on acpilk is interesting. If that happens again, can you send us the output of "ps -axk -Owchan"? Also, do the brightness keys on your machine work?
termcap.5 (typo)
mismatch, possibly left out typo? Index: termcap.5 === RCS file: /cvs/obsd/src/share/termtypes/termcap.5,v retrieving revision 1.26 diff -u -p -u -p -r1.26 termcap.5 --- termcap.5 3 Sep 2011 22:59:08 - 1.26 +++ termcap.5 5 Aug 2013 18:59:06 - @@ -813,7 +813,7 @@ are sent as two-digit integers. Thus its .Sy \&cm capability is -.Dq Li cm=6\eE&%r%2c%2Y . +.Dq Li cm=6\eE&a%r%2c%2Y . .Pp The Datamedia 2500 needs the current row and column sent encoded in binary using
in6_delayed_cksum: fix ICMPv6 checksum calculation
in6_delayed_cksum() incorrectly assumes that the ICMPv6 header or
checksum field is in the first mbuf of an mbuf chain before setting it
to 0. This diff fixes it.
OK?
Index: ip6_output.c
===
RCS file: /cvs/src/sys/netinet6/ip6_output.c,v
retrieving revision 1.143
diff -U5 -p -r1.143 ip6_output.c
--- ip6_output.c31 Jul 2013 15:41:52 - 1.143
+++ ip6_output.c5 Aug 2013 02:44:43 -
@@ -3174,22 +3174,21 @@ ip6_randomid_init(void)
*/
void
in6_delayed_cksum(struct mbuf *m, u_int8_t nxt)
{
int nxtp, offset;
- u_int16_t csum;
+ u_int16_t csum = 0;
offset = ip6_lasthdr(m, 0, IPPROTO_IPV6, &nxtp);
if (offset <= 0 || nxtp != nxt)
/* If the desired next protocol isn't found, punt. */
return;
- if (nxt == IPPROTO_ICMPV6) {
- struct icmp6_hdr *icmp6;
- icmp6 = (struct icmp6_hdr *)(mtod(m, caddr_t) + offset);
- icmp6->icmp6_cksum = 0;
- }
+ if (nxt == IPPROTO_ICMPV6)
+ if (m_copyback(m, offset + offsetof(struct icmp6_hdr,
icmp6_cksum),
+ sizeof(csum), &csum, M_NOWAIT))
+ return;
csum = (u_int16_t)(in6_cksum(m, nxt, offset, m->m_pkthdr.len - offset));
switch (nxt) {
case IPPROTO_TCP:
in_proto_cksum_out: fix ICMP checksum calculation
in_proto_cksum_out() currently calculates ICMP checksums like this:
hlen = ip->ip_hl << 2;
icp = (struct icmp *)(mtod(m, caddr_t) + hlen);
icp->icmp_cksum = 0;
icp->icmp_cksum = in4_cksum(m, 0, hlen,
ntohs(ip->ip_len) - hlen);
However this won't work if the ICMP header or ICMP checksum field is not
in the first mbuf of an mbuf chain.
The diff below fixes this as follows:
- Instead of fixing this in in_proto_cksum_out() itself, call
in_delayed_cksum() which also uses in4_cksum() and includes a check to
see if the checksum field is in the first mbuf. Modify
in_delayed_cksum() to recognize ICMP accordingly.
- In in_delayed_cksum(), set the ICMP checksum to 0 to prepare for
calculation (this makes it match what in6_delayed_cksum() does).
- While here, move the UDP zero checksum check to the switch statement
to remove the duplicate IPPROTO_UDP check (also to match
in6_delayed_cksum()).
OK?
[On a related note, in6_delayed_cksum() also makes an incorrect
assumption about the ICMPv6 header/checksum field being in the first
mbuf; I'll send the fix in a separate mail.]
Index: ip_output.c
===
RCS file: /cvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.244
diff -U5 -p -r1.244 ip_output.c
--- ip_output.c 31 Jul 2013 15:41:52 - 1.244
+++ ip_output.c 5 Aug 2013 02:44:20 -
@@ -2058,25 +2058,35 @@ ip_mloopback(struct ifnet *ifp, struct m
*/
void
in_delayed_cksum(struct mbuf *m)
{
struct ip *ip;
- u_int16_t csum, offset;
+ u_int16_t csum = 0, offset;
ip = mtod(m, struct ip *);
offset = ip->ip_hl << 2;
+
+ if (ip->ip_p == IPPROTO_ICMP)
+ if (m_copyback(m, offset + offsetof(struct icmp, icmp_cksum),
+ sizeof(csum), &csum, M_NOWAIT))
+ return;
+
csum = in4_cksum(m, 0, offset, m->m_pkthdr.len - offset);
- if (csum == 0 && ip->ip_p == IPPROTO_UDP)
- csum = 0x;
switch (ip->ip_p) {
case IPPROTO_TCP:
offset += offsetof(struct tcphdr, th_sum);
break;
case IPPROTO_UDP:
offset += offsetof(struct udphdr, uh_sum);
+ if (csum == 0)
+ csum = 0x;
+ break;
+
+ case IPPROTO_ICMP:
+ offset += offsetof(struct icmp, icmp_cksum);
break;
default:
return;
}
@@ -2101,17 +2111,9 @@ in_proto_cksum_out(struct mbuf *m, struc
ifp->if_bridgeport != NULL) {
in_delayed_cksum(m);
m->m_pkthdr.csum_flags &= ~M_UDP_CSUM_OUT; /* Clear */
}
} else if (m->m_pkthdr.csum_flags & M_ICMP_CSUM_OUT) {
- struct ip *ip = mtod(m, struct ip *);
- int hlen;
- struct icmp *icp;
-
- hlen = ip->ip_hl << 2;
- icp = (struct icmp *)(mtod(m, caddr_t) + hlen);
- icp->icmp_cksum = 0;
- icp->icmp_cksum = in4_cksum(m, 0, hlen,
- ntohs(ip->ip_len) - hlen);
+ in_delayed_cksum(m);
m->m_pkthdr.csum_flags &= ~M_ICMP_CSUM_OUT; /* Clear */
}
}
tgammal(3) fix
The 80-bit extended precision version of tgammal(3) has the tgamma(+-0) == +-Inf corner case wrong. ok? Index: src/ld80/e_tgammal.c === RCS file: /home/cvs/src/lib/libm/src/ld80/e_tgammal.c,v retrieving revision 1.2 diff -u -p -r1.2 e_tgammal.c --- src/ld80/e_tgammal.c20 Jul 2011 21:02:51 - 1.2 +++ src/ld80/e_tgammal.c5 Aug 2013 10:14:28 - @@ -229,6 +229,8 @@ if(x == INFINITY) return(INFINITY); if(x == -INFINITY) return(x - x); +if( x == 0.0L ) + return( 1.0L / x ); q = fabsl(x); if( q > 13.0L )
Re: Switch mfii(4) to msi, testing required.
On Thu, Jun 06, 2013 at 12:54:31PM +0200, Christiano F. Haesbaert wrote:
> Hi,
>
> We would like to switch mfii(4) to msi, there is a family of supermicro
> X9 motherboards with incorrect ioapic routing, so they only work properly
> though msi.
>
> If you have a system with a mfii(4) device, please give this diff a spin
> and report back.
>
> So far I was able to test on:
>
> Supermicro X9DRH + Symbios Logic MegaRAID SAS2208
> Fujitsu primergy RX300 S7 + Symbios Logic MegaRAID SAS2208
>
> Index: dev/pci/mfii.c
> ===
> RCS file: /cvs/src/sys/dev/pci/mfii.c,v
> retrieving revision 1.12
> diff -d -u -p -r1.12 mfii.c
> --- dev/pci/mfii.c25 Aug 2012 07:03:04 - 1.12
> +++ dev/pci/mfii.c6 Jun 2013 10:47:23 -
> @@ -307,7 +307,7 @@ mfii_attach(struct device *parent, struc
> /* disable interrupts */
> mfii_write(sc, MFI_OMSK, 0x);
>
> - if (pci_intr_map(pa, &ih) != 0) {
> + if (pci_intr_map_msi(pa, &ih) != 0 && pci_intr_map(pa, &ih) != 0) {
> printf(": unable to map interrupt\n");
> goto pci_unmap;
> }
So far I've received only one report where this diff makes it possible
to use the Supermicro branded AOC-S2208-H8iR LSI SAS 2208, where the
apic routing is probably busted too.
We're reaching the point where we'll see more machines with wrong apic
routing since most newer chips are only being tested with MSI enabled.
This is one case of it.
I'd like to commit this after release.
