On Aug 29, 2014, at 1:27 PM, David Young wrote:
> bus_msi(9) gives MI code access to doorbells: MI code uses it to
> establish a doorbell -> interrupt handler mapping and find out the
> doorbell's physical address.
>
> All the code to map the doorbell's physaddr into a PCI busaddr, to
> program
On Sat, Jun 07, 2014 at 08:36:47AM +1000, matthew green wrote:
>
> let's not forget my favourite mis-feature of MSI/MSI-X:
>
> if you misconfigure the address, interrupts might cause main memory to
> be corrupted. i've seen this happen, and it was rather difficult to
> diagnose the real culprit.
On Fri, 29 Aug 2014, Emmanuel Dreyfus wrote:
Terry Moore wrote:
But it's running at gen1. I strongly suspect that the benchmark case was
gen2 (since the ixg is capable of it).
gen1 vs gen2 is 2.5 Gb.s bs 5 Gb/s?
Gen 1 is capable of only 2.5GT/s (gigatransfers per second). Gen 2 is
capable
Terry Moore wrote:
> But it's running at gen1. I strongly suspect that the benchmark case was
> gen2 (since the ixg is capable of it).
gen1 vs gen2 is 2.5 Gb.s bs 5 Gb/s?
> Is the ixg in an expansion slot or integrated onto the main board?
In a slot.
--
Emmanuel Dreyfus
http://hcpnet.free.fr
> On Friday, August 29, 2014 11:51, Emmanuel Dreyfus wrote:
>
> On Fri, Aug 29, 2014 at 08:48:51AM -0400, Terry Moore wrote:
> > Still, you should check whether you have the right number of the right
> > generation of PCIe lanes connected to the ixg.
>
> I found this, but the result does not make
On Fri, Aug 29, 2014 at 08:48:51AM -0400, Terry Moore wrote:
> Still, you should check whether you have the right number of the right
> generation of PCIe lanes connected to the ixg.
I found this, but the result does not make sense: negociated > max ...
Link Capabilities Ragister (0xAC): 0x00027
On Aug 29, 12:33pm, Edgar =?iso-8859-1?B?RnXf?= wrote:
} Subject: Re: Unallocated inode
} Btw.: Has anyone tried to import my mpt(4) enhancements? I had several
} crashes of the disc firmware / controller hick-ups that were caught by
} my patch (I later updated the firmware and had no crashes si
> Hello. If the patches you're talking about are the ones we worked on
> for the mpt(4) driver, they were committed around February of this year.
Ah, thanks. I'll have a look at what you committed.
> -Original Message-
> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
> Behalf Of Emmanuel Dreyfus
> Sent: Thursday, August 28, 2014 23:55
> To: Terry Moore; 'Christos Zoulas'
> Cc: tech-kern@netbsd.org
> Subject: Re: ixg(4) performances
>
> Terry Moore wrote:
>
> does anyone have any idea what might be causing them?
> This appears similar to issues reported previously:
> http://mail-index.netbsd.org/tech-kern/2013/10/19/msg015770.html
In my case, they were most probably caused by the disc firmware crashing,
the MPT SAS controller locking up and mpt(4) no
In article <20140829065646.GA2351@slave.private>,
Paul Ripke wrote:
>I'm currently running kernel:
>NetBSD slave 6.1_STABLE NetBSD 6.1_STABLE (SLAVE) #4: Fri May 23
>23:42:30 EST 2014
>stix@slave:/home/netbsd/netbsd-6/obj.amd64/home/netbsd/netbsd-6/src/sys/arch/amd64/compile/SLAVE
> amd64
>Built
On Fri, Aug 29, 2014 at 04:56:46PM +1000, Paul Ripke wrote:
> I'm currently running kernel:
> NetBSD slave 6.1_STABLE NetBSD 6.1_STABLE (SLAVE) #4: Fri May 23 23:42:30 EST
> 2014
> stix@slave:/home/netbsd/netbsd-6/obj.amd64/home/netbsd/netbsd-6/src/sys/arch/amd64/compile/SLAVE
> amd64
> Built fro
12 matches
Mail list logo
