similar to: 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

That's right -- nouveau currently requires 4k page sizes to work. This is a software limitation, not a hardware one though. On Dec 1, 2016 5:13 PM, "Jeremy Linton" <jeremy.linton at arm.com> wrote: Hi, I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau driver failed to claim the device with : [drm] Initialized nouveau 0000:01:00.0: NVIDIA G94 (094100a1)

On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > That's right -- nouveau currently requires 4k page sizes to work. This is a > software limitation, not a hardware one though. Looking at the trace I wonder - is the limitation in Nouveau or in TTM? > > > On Dec 1, 2016 5:13 PM, "Jeremy Linton" <jeremy.linton at arm.com> wrote:

3.62 is shaping up to be the "let's get rid of hardcoded limits" release. I got inspired by Bryan Perry's post about people still wanting to be able to use the CLI, so I have implemented putting labels in high memory, therefore avoiding the 64K total limit. This is now released as 3.62-pre7. If you happen to have a use case for this, I would be interested in finding out

-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -------------- next part -------------- >From 8f22ca1afb619762ad66eae46afd194bdd7f3224 Mon Sep 17

Ian Reed wrote: > It explains why libopusfile requires the last 64K to calculate the > duration, but again, I don't need libopusfile to get the duration for > me, I only want it to allow me to seek within parts of the file that > have already been downloaded. Unfortunately, this is not currently supported. > Is there a reason libopusfile forces the retrieval of the last 64K

Hi All, I have "converted" the openssh code into a Windows DLL and everything "works" up until around 64k of data packets is received from the host. What I see from extensive debugging is that select() never reports that there is more data to read. I was hoping someone could give me a clue as to what to try next??? I believe the Winsock receive buffer defaults to 64k, but

http://bugzilla.mindrot.org/show_bug.cgi?id=916 Summary: SFTP over SSH died after roughly 20MB when asking for >64k chunks Product: Portable OpenSSH Version: 3.8.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=916 ------- Additional Comments From dtucker at zip.com.au 2005-01-27 18:05 ------- Does the patch in bug #896 resolve the problem? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

On Thursday, January 22, 2004 9:55 PM, Jess Magnaye [SMTP:jess@arretni.com] wrote: > in telco world, there's like 64kbps per channel and voice can be > carried on a 16kbps channel. is it possible to configure asterisk to > make 4 extensions (ATAs example), to call out using single FXO port > at the same time? if that is possible, then is it also possible to > make t1-pri to

I'm trying to pass a 65K DATA call in one channel on my Digium TE411P to another channel on a different span. Any idea what could keep this call from going through? -- Accepting call from '' to '5444' on channel 0/1, span 1 -- Executing Goto("Zap/1-1", "sendto-definity|5444|1") in new stack -- Goto (sendto-definity,5444,1) -- Executing

Hi All, We are using MAX TNT to for some T1 PRI interconnects. I'm seeing the voice channels connect at 56K. Does anyone have the DS0 channels connecting at 64K for voice, if so what is the parameter to select 56k or 64k channels? I'm not having any issues that I know of, just wanted to bounce this off the group for a sanity check. Thanks. JR -- JR Richardson Engineering for the

On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer <michel at daenzer.net> wrote: > On 07/12/16 06:39 PM, Alexandre Courbot wrote: >> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>> That's right -- nouveau currently requires 4k page sizes to work. This is a >>> software limitation, not a hardware one though. >> >>

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Mon, 23 Jan 2017 21:37:52 +0200 > I don't have any guests with PAGE_SIZE > 64k but the > code seems to be clearly broken in that case > as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need > more than 8 bit and so the code in mergeable_ctx_to_buf_address > does not give us the actual true size. > > Cc:

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Tue, 24 Jan 2017 21:53:13 +0200 > I didn't realise. Why can't we? I thought that adjust_header is an > optional feature that userspace can test for, so no rush. No, we want the base set of XDP features to be present in all drivers supporting XDP.

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Tue, 24 Jan 2017 22:45:37 +0200 > On Tue, Jan 24, 2017 at 03:09:59PM -0500, David Miller wrote: >> From: "Michael S. Tsirkin" <mst at redhat.com> >> Date: Tue, 24 Jan 2017 21:53:13 +0200 >> >> > I didn't realise. Why can't we? I thought that adjust_header is an >> >

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Tue, 24 Jan 2017 23:07:51 +0200 > On Tue, Jan 24, 2017 at 03:53:31PM -0500, David Miller wrote: >> From: "Michael S. Tsirkin" <mst at redhat.com> >> Date: Tue, 24 Jan 2017 22:45:37 +0200 >> >> > On Tue, Jan 24, 2017 at 03:09:59PM -0500, David Miller wrote: >> >> From:

On Tue, Jan 24, 2017 at 04:10:46PM -0500, David Miller wrote: > This works in the regimen that XDP packets always live in exactly one > page. That will be needed to mmap the RX ring into userspace, and it > helps make adjust_header trivial as well. I think the point was to avoid resets across xdp attach/detach. If we are doing resets now, we could do whatever buffering we want. We

On Tue, Jan 24, 2017 at 08:07:40PM -0800, Alexei Starovoitov wrote: > On Tue, Jan 24, 2017 at 7:48 PM, John Fastabend > <john.fastabend at gmail.com> wrote: > > > > It is a concern on my side. I want XDP and Linux stack to work > > reasonably well together. > > btw the micro benchmarks showed that page per packet approach > that xdp took in mlx4 should be

On Tue, Jan 24, 2017 at 7:48 PM, John Fastabend <john.fastabend at gmail.com> wrote: > > It is a concern on my side. I want XDP and Linux stack to work > reasonably well together. btw the micro benchmarks showed that page per packet approach that xdp took in mlx4 should be 10% slower vs normal operation for tcp/ip stack. We thought that for our LB use case it will be an acceptable

As the minimum block size to discard in qcow2 is 64K, any point in fstrimming smaller contiguous blocks? TIA, Y.