Hi, author of gocryptfs here, an encrypted overlay
filesystem written in Go.
A gocryptfs user reported [1] hitting EINTR errors
when gocryptfs is used on a cifs mount.
I wrote a minimal reproducer, getdents.go [2], that runs
getdents64 in a loop and I can reproduce the issue easily.
I additionall
On 25.04.18 17:34, Marc Kleine-Budde wrote:
Applied to linux-can-next.
Thanks,
Marc
Marc, is the patch supposed to show up on
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/
or am I looking at the wrong tree?
Thanks,
Jakob
On 24.04.18 15:33, JeffyChen wrote:
[ 36.076577] WARNING: CPU: 1 PID: 83 at
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1004
vop_crtc_atomic_flush+0x1c0/0x1c8
this looks like an issue recently reported by heiko, we found that might
due to an unbalanced irq disable in vop driver.
my test pa
On 24.04.18 14:37, JeffyChen wrote:
right, i think it's a known issue, as the iommu failed to get clks:
[ 1.525153] rk_iommu ff8f3f00.iommu: Failed to get clk 'iface': -2
[ 1.525316] rk_iommu: probe of ff8f3f00.iommu failed with error -2
[ 1.525484] rk_iommu ff903f00.iommu: Failed to ge
I am working on getting HDMI output enabled in mainline Linux for our
RK3399-Q7 module. It works fine on v4.16, but testing with v4.17-rc2 I
get this, and the screen stays black:
[7.142712] alloc_contig_range: [7f061, 7f062) PFNs busy
[7.148862] alloc_contig_range: [7f066, 7f067) PFNs
keep the "restarted" message at dbg for now
as the "bus-off" message should be enough for the user to
notice and investigate the problem.
Signed-off-by: Jakob Unterwurzacher
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/can/dev.c | 2 +-
Elshuber
Signed-off-by: Jakob Unterwurzacher
Signed-off-by: Philipp Tomsich
Acked-by: Wolfgang Grandegger
---
Documentation/networking/can_ucan_protocol.rst | 332 +
Documentation/networking/index.rst |1 +
drivers/net/can/usb/Kconfig| 10 +
drivers/net/can
; "context_array" to prevent confusion
* add __func__ to all errors and warnings, and to info where it made sense
Jakob Unterwurzacher (1):
can: ucan: add driver for Theobroma Systems UCAN devices
Documentation/networking/can_ucan_protocol.rst | 332 +
Documentation/networking/ind
d __func__ to all errors and warnings, and to info where it made sense
Jakob Unterwurzacher (1):
can: ucan: add driver for Theobroma Systems UCAN devices
Documentation/networking/can_ucan_protocol.rst | 315 +
Documentation/networking/index.rst |1 +
drivers/net/can/usb/Kco
Elshuber
Signed-off-by: Jakob Unterwurzacher
Signed-off-by: Philipp Tomsich
---
Documentation/networking/can_ucan_protocol.rst | 315 +
Documentation/networking/index.rst |1 +
drivers/net/can/usb/Kconfig| 10 +
drivers/net/can/usb/Makefile
On 23.03.18 11:04, Wolfgang Grandegger wrote:
But I'm open to other suggestions (use a fixed "ucan: " prefix?) or to
drop it entirely if you think it is not worth it.
But there is already a device prefix, e.g.:
peak_usb 1-6:1.0: PEAK-System PCAN-USB adapter hwrev 28 serial (1
ch
On 23.03.18 09:32, Wolfgang Grandegger wrote:
* add __func__ to all errors and warnings, and to info where it made sense
The final output messages in the driver should especially be useful for
the end user... and not the developer! This is also true for the
function names. You already use more
errors and warnings, and to info where it made sense
Jakob Unterwurzacher (1):
can: ucan: add driver for Theobroma Systems UCAN devices
Documentation/networking/can_ucan_protocol.rst | 315 +
Documentation/networking/index.rst |1 +
drivers/net/can/usb/Kconfig
Elshuber
Signed-off-by: Jakob Unterwurzacher
Signed-off-by: Philipp Tomsich
---
Documentation/networking/can_ucan_protocol.rst | 315 +
Documentation/networking/index.rst |1 +
drivers/net/can/usb/Kconfig| 10 +
drivers/net/can/usb/Makefile
On 21.03.18 21:52, John Fastabend wrote:
Can you try this,
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index d4907b5..1e596bd 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -30,6 +30,7 @@ struct qdisc_rate_table {
enum qdisc_state_t {
On 21.03.18 19:43, John Fastabend wrote:
Thats my theory at least. Are you able to test a patch if I generate
one to fix this?
Yes, no problem.
I just tested with the flag change you suggested (see below, I had to
keep TCQ_F_CPUSTATS to prevent a crash) and I have NOT seen OOO so far.
Thank
On 16.03.18 11:26, Jakob Unterwurzacher wrote:
On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each
other. The test tool sends UDP packets containing a counter and
listens on the other interface, it is available at
https://github.com
On 19.03.18 13:32, Paolo Abeni wrote:
Is not clear to me if you can reproduce the bug with the vanilla
kernel, or if you need some out-of-tree nic driver. Can you please
clarify which NIC/driver are you using?
Yes I reproduced it with a vanilla kernel. I use two off-the-shelf USB
NICs, lsusb
On 15.03.18 23:30, John Fastabend wrote:
I have reproduced it using two USB network cards connected to each other. The
test tool sends UDP packets containing a counter and listens on the other
interface, it is available at
https://github.com/jakob-tsd/pfifo_stress/blob/master/pfifo_stress.py
On 14.03.18 05:03, John Fastabend wrote:
On 03/13/2018 11:35 AM, Dave Taht wrote:
On Tue, Mar 13, 2018 at 11:24 AM, Jakob Unterwurzacher
wrote:
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction
On 14.03.18 11:04, Wolfgang Grandegger wrote:
(000.000443) can0 2034 [8] 00 0C 00 00 00 00 78 00 ERRORFRAME
controller-problem{rx-error-warning,tx-error-warning}
transceiver-status
no-acknowledgement-on-tx
error-counter-tx-rx{{120}{0}}
(000.000444) can0 2034 [
On 14.03.18 11:04, Wolfgang Grandegger wrote:
controller-problem{rx-error-warning,tx-error-warning,rx-error-passive,tx-error-passive}
Just,
controller-problem{rx-error-passive,tx-error-passive}
Ok.
(1b) cable gets connected:
(000.000883) can0 2034 [8] 00 3C 00 00
On 14.03.18 05:03, John Fastabend wrote:
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on Linux
v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of packets are
delivered out-of-order.
Is the stress-testing tool available somewhere? What type of packets
are bein
On 14.03.18 10:46, Wolfgang Grandegger wrote:
We do count them, as errors!
This is what happens when you transmit a single CAN frame with nothing
connected: "TX errors" shoots up but "RX packets" stays zero.
This is handled not consistent in the existing CAN drivers. In flexcan
all and c_can (
On 14.03.18 10:25, Wolfgang Grandegger wrote:
Counting the state changes is one thing but you should also generate
error messages for them.
The usual test here is:
$ candump -td -e any,0:0,#
should report proper state changes, if you send messages with
1. no cable connected
2. CAN hi
On 14.03.18 10:17, Wolfgang Grandegger wrote:
Counting the state changes is one thing but you should also generate
error messages for them.
We do for BUS-OFF already (see below), but not for other states - will
do in v3.
+ /* we switched into a worse state */
+ up->can.state = n
On 14.03.18 10:11, Wolfgang Grandegger wrote:
+ /* handle error frames */
+ canid = le32_to_cpu(m->msg.can_msg.id);
+ if (canid & CAN_ERR_FLAG) {
+ ucan_handle_error_frame(up, m, canid);
+ /* drop frame if berr-reporting is off */
+ if (!(up->can.ctrlmode & CAN_CTRLM
On 14.03.18 08:51, Marc Kleine-Budde wrote:
+ memcpy(cf->data, m->msg.can_msg.data, cf->can_dlc);
+
+ /* don't count error frames as real packets */
+ if (!(canid & CAN_ERR_FLAG)) {
+ stats->rx_packets++;
+ stats->rx_bytes += cf->can_dlc;
+
During stress-testing our "ucan" USB/CAN adapter SocketCAN driver on
Linux v4.16-rc4-383-ged58d66f60b3 we observed that a small fraction of
packets are delivered out-of-order.
We have tracked the problem down to the driver interface level, and it
seems that the driver's net_device_ops.ndo_star
This email addresses open questions from the v1 review cycle.
Three emails are answered, you can skip to sections
by searching for the header text:
* On 07.02.18 08:17, Wolfgang Grandegger wrote
* On 09.02.18 11:40, Marc Kleine-Budde wrote
* On 06.02.18 12:58, Andri Yngvason wrote
Best regards,
Elshuber
Signed-off-by: Jakob Unterwurzacher
Signed-off-by: Philipp Tomsich
---
Documentation/networking/can_ucan_protocol.rst | 315 +
Documentation/networking/index.rst |1 +
drivers/net/can/usb/Kconfig| 10 +
drivers/net/can/usb/Makefile
completion message has been added.
A few questions and review comments are still open. I will post an
email gathering all answers in a reply to this cover letter.
Jakob Unterwurzacher (1):
can: ucan: add driver for Theobroma Systems UCAN devices
Documentation/networking/can_ucan_protocol.rst
On 13.03.18 18:44, Marc Kleine-Budde wrote:
On 03/13/2018 06:35 PM, Jakob Unterwurzacher wrote:
[...]
Please mark all multibyte values going over the USB as either le or be.
This is documented in can_ucan_protocol.rst,
All multi-byte integers are encoded as Little Endian.
but it&#
On 13.03.18 18:42, Dr. Philipp Tomsich wrote:
On 13 Mar 2018, at 18:40, Jakob Unterwurzacher
wrote:
+/* get the urb context */
+if (WARN_ON(!context))
+return;
Can this happen?
Not unless there is a bug in the code. But we want to get a message
before dereferencing a
A user running a Haskell program [1] noticed a problem with fuse's
readdirplus: when it is interrupted by a signal, it skips one
directory entry.
The problem is most apparent with Haskell as it uses
SIGVTALRM to interrupt it's own green threads.
A minimal reproducer in C, "ls-count.c", is availab
> On 16. Oct 2017, at 13:19, Fabio Estevam wrote:
>
>> I think I see a way to fix this without adding a DTS property, I’ll send out
>> a patch later this afternoon.
>
> Ok, great.
Hi Fabio, I think I found a way to get our use-case working with just DTS
configuration
for simple-audio-card.
> On 16. Oct 2017, at 12:51, Fabio Estevam wrote:
>
> Hi Jakob,
>
> On Mon, Oct 16, 2017 at 7:46 AM, Jakob Unterwurzacher
> wrote:
>> Hi Fabio, that’s interesting.
>>
>> Looks like the fsl,imx-audio-sgtl5000 sound card driver that is used on the
>&g
]
>
> Hi Jakob,
>
> arch/arm/boot/dts/imx51-babbage.dts has SYS_MCLK generated by an external
> fixed oscillator and it works fine.
>
> Do you really need this new property?
> From: Jakob Unterwurzacher
> Sent: Friday, October 6, 2017 5:34:44 AM
> To: l
First of all, thanks for your replies!
On 02.11.2016 00:51, Hugh Dickins wrote:
> I don't think that there will be much appetite for changing the
> kernel's VFS to prevent that. I hope that gocryptfs can provide
> the serialization that it needs for itself, or otherwise handle
> those zeroes with
tmpfs seems to be incorrectly returning 0-bytes when reading from
a file that is concurrently being truncated.
This is causing crashes in gocryptfs, a cryptographic FUSE overlay,
when it reads a nonce from disk that should absolutely positively
never be all-zero.
I have written a reproducer in C
On 12.04.2016 13:09, Tejun Heo wrote:
>>
>> Probably you want to look into:
>> https://lkml.org/lkml/2016/3/10/21
>>
>> The patch mentioned above solves the issue for me.
>
> Heh, I tracked it down to wb_over_bg_thresh() and fell asleep. Yeah,
> that is the right fix.
Works wonderfully now, than
On 30.03.2016 20:47, Tejun Heo wrote:
> Hmmm... cgroup writeback support shouldn't affect fuse at all as the
> backing device doesn't enable cgroup support. I probably made some
> silly mistake. Is there a simple reproducer I can play with?
Hi Tejun! A simple reproducer is at https://github.com/
On 16.03.2016 10:44, Miklos Szeredi wrote:
> On Tue, Mar 15, 2016 at 8:55 AM, Jakob Unterwurzacher
> wrote:
>> Just for anybody finding this thread: This still happens in v4.4, it
>> just took longer to trigger.
>>
>> I have posted more details to linux-kerne
I have noticed an annoying regression that was introduced in 4.2 and is
still there in 4.4. mmap writes to FUSE filesystems are throttled down
to basically zero.
Reproducer: https://github.com/rfjakob/mmapwrite , testing against encfs:
$ mmapwrite /tmp/encfs-mnt/foo
1 ..
44 matches
Mail list logo
