on(card, TCODE_WRITE_QUADLET_REQUEST,
> device->node_id, generation, device->max_speed,
> - CSR_REGISTER_BASE + CSR_BROADCAST_CHANNEL,
> + CSR_REGISTER_BASE | CSR_BROADCAST_CHANNEL,
>
c(sizeof(*e) + request->length, GFP_KERNEL);
> if (e == NULL)
> return -ENOMEM;
There is already a length check for asynchronous stream requests.
It happens in ioctl_send_stream_packet().
--
Stefan Richter
-==--=-= --== ---=-
http://arcgraph.de/sr/
urn -EINVAL;
-
- cb = iso_callback;
break;
case FW_ISO_CONTEXT_RECEIVE_MULTICHANNEL:
- cb = (fw_iso_callback_t)iso_mc_callback;
break;
default:
@@ -990,9 +984,15 @@ static int ioctl_create_iso_context(struct client *client,
union ioctl_arg *arg)
}
context = fw_iso_context_create(client->device->card, a->type,
- a->channel, a->speed, a->header_size, cb, client);
+ a->channel, a->speed, a->header_size, NULL, client);
if (IS_ERR(context))
return PTR_ERR(context);
+
+ if (a->type == FW_ISO_CONTEXT_RECEIVE_MULTICHANNEL)
+ context->callback.mc = iso_mc_callback;
+ else
+ context->callback.sc = iso_callback;
+
if (client->version < FW_CDEV_VERSION_AUTO_FLUSH_ISO_OVERFLOW)
context->drop_overflow_headers = true;
--
Stefan Richter
-==--=-- -=-= ==--=
http://arcgraph.de/sr/
ers/firewire/core-topology.c
> index 7db234d3fbdd..82c67e900aad 100644
> --- a/drivers/firewire/core-topology.c
> +++ b/drivers/firewire/core-topology.c
> @@ -67,6 +67,7 @@ static u32 *count_ports(u32 *sid, int *total_port_count,
> int *child_port_count)
> switch (port_type) {
>
ncy
Geert Uytterhoeven (1):
firewire: Remove depends on HAS_DMA in case of platform dependency
drivers/firewire/Kconfig | 1 -
1 file changed, 1 deletion(-)
Thanks,
--
Stefan Richter
-==---== ---= --=-=
http://arcgraph.de/sr/
/firewire/Kconfig
> +++ b/drivers/firewire/Kconfig
> @@ -1,5 +1,4 @@
> menu "IEEE 1394 (FireWire) support"
> - depends on HAS_DMA
> depends on PCI || COMPILE_TEST
> # firewire-core does not depend on PCI but is
> # not useful without PCI controller driver
--
Stefan Richter
-==---=- ==-- ---==
http://arcgraph.de/sr/
/firewire/Kconfig
> +++ b/drivers/firewire/Kconfig
> @@ -1,5 +1,4 @@
> menu "IEEE 1394 (FireWire) support"
> - depends on HAS_DMA
> depends on PCI || COMPILE_TEST
> # firewire-core does not depend on PCI but is
> # not useful without PCI controller driver
--
Stefan Richter
-==---=- ==-- ---==
http://arcgraph.de/sr/
atch and (b) clean out my mailbox and update my mail
sorting filters (long overdue after my mail service provider changed
backends).
Again sorry, and thank you for your extraordinary patience.
--
Stefan Richter
-==---=- =--= =--=-
http://arcgraph.de/sr/
atch and (b) clean out my mailbox and update my mail
sorting filters (long overdue after my mail service provider changed
backends).
Again sorry, and thank you for your extraordinary patience.
--
Stefan Richter
-==---=- =--= =--=-
http://arcgraph.de/sr/
394: allow user-configured MTU of up to 4096 bytes
Hector Martin (1):
firewire-ohci: work around oversized DMA reads on JMicron controllers
Stefan Richter (1):
firewire: net: max MTU off by one
drivers/firewire/net.c | 7 ++-
drivers/firewire/ohci.c | 8 +++-
2 files c
394: allow user-configured MTU of up to 4096 bytes
Hector Martin (1):
firewire-ohci: work around oversized DMA reads on JMicron controllers
Stefan Richter (1):
firewire: net: max MTU off by one
drivers/firewire/net.c | 7 ++-
drivers/firewire/ohci.c | 8 +++-
2 files c
On Jan 11 Hector Martin 'marcan' wrote:
> On 2017-11-13 06:05, Stefan Richter wrote:
> > Thanks Hector for the troubleshooting and for the patch.
> > Thanks Clemens for the review.
> >
> > It's been a while since I last reviewed and tested kernel patches, and
> >
On Jan 11 Hector Martin 'marcan' wrote:
> On 2017-11-13 06:05, Stefan Richter wrote:
> > Thanks Hector for the troubleshooting and for the patch.
> > Thanks Clemens for the review.
> >
> > It's been a while since I last reviewed and tested kernel patches, and
> >
issue 0x20-byte DMA reads
> > +* for descriptors, even 0x10-byte ones. This can cause page faults when
> > +* an IOMMU is in use and the oversized read crosses a page boundary.
> > + * Work around this by always leaving at least 0x10 bytes of padding.
> > +*/
> > + desc->buffer_size = PAGE_SIZE - offset - 0x10;
> > desc->buffer_bus = bus_addr + offset;
> > desc->used = 0;
> >
--
Stefan Richter
-=== =-== -==--
http://arcgraph.de/sr/
ors, even 0x10-byte ones. This can cause page faults when
> > +* an IOMMU is in use and the oversized read crosses a page boundary.
> > +* Work around this by always leaving at least 0x10 bytes of padding.
> > +*/
> > + desc->buffer_size = PAGE_SIZE - offset - 0x10;
> > desc->buffer_bus = bus_addr + offset;
> > desc->used = 0;
> >
--
Stefan Richter
-=== =-== -==--
http://arcgraph.de/sr/
t)
> + fclose(input);
> return -1;
> }
> }
When we return from main(), all files are closed implicitly.
--
Stefan Richter
-=== =--= ==-=-
http://arcgraph.de/sr/
ose(input);
> return -1;
> }
> }
When we return from main(), all files are closed implicitly.
--
Stefan Richter
-=== =--= ==-=-
http://arcgraph.de/sr/
On Nov 14 Ben Hutchings wrote:
> 3.2.84-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Stefan Richter <stef...@s5r6.in-berlin.de>
>
> commit 667121ace9dbafb368618dbabcf07901c962ddac upstream.
[...
On Nov 14 Ben Hutchings wrote:
> 3.2.84-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Stefan Richter
>
> commit 667121ace9dbafb368618dbabcf07901c962ddac upstream.
[...]
> [bwh: Backported to 3.2: fwnet_receive_b
Please tell us what your compile error was (and on what platform), so that
we can find out which dependency was really missing, if any.
--
Stefan Richter
-==- =-== -===-
http://arcgraph.de/sr/
Please tell us what your compile error was (and on what platform), so that
we can find out which dependency was really missing, if any.
--
Stefan Richter
-==- =-== -===-
http://arcgraph.de/sr/
-over-1394 encapsulation headers could trigger
buffer overflows (CVE 2016-8633).
- IP-over-1394 link fragmentation headers were read and written
incorrectly, breaking fragmented RX/TX with other OS's stacks.
Stefan Richter (2):
firewire: net: guard against rx buffer overflows
fir
-over-1394 encapsulation headers could trigger
buffer overflows (CVE 2016-8633).
- IP-over-1394 link fragmentation headers were read and written
incorrectly, breaking fragmented RX/TX with other OS's stacks.
Stefan Richter (2):
firewire: net: guard against rx buffer overflows
fir
The latest max_mtu patch missed that datagram_size is actually one less
than the datagram's Total Length.
Fixes: 357f4aae859b ("firewire: net: really fix maximum possible MTU")
Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
---
To be applied after net-next was m
The latest max_mtu patch missed that datagram_size is actually one less
than the datagram's Total Length.
Fixes: 357f4aae859b ("firewire: net: really fix maximum possible MTU")
Signed-off-by: Stefan Richter
---
To be applied after net-next was merged.
drivers/firewire/net.c | 7 +
orked around by setting a small enough MTU.)
Cc: sta...@vger.kernel.org
Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
---
drivers/firewire/net.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -73,1
orked around by setting a small enough MTU.)
Cc: sta...@vger.kernel.org
Signed-off-by: Stefan Richter
---
drivers/firewire/net.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -73,13 +73,13 @@ struct rfc2734_header
<eyal.it...@gmail.com>
Cc: sta...@vger.kernel.org
Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
---
drivers/firewire/net.c | 51 -
1 file changed, 35 insertions(+), 16 deletions(-)
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net
: sta...@vger.kernel.org
Signed-off-by: Stefan Richter
---
drivers/firewire/net.c | 51 -
1 file changed, 35 insertions(+), 16 deletions(-)
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -578,6 +578,9 @@ static int fwnet_incoming_packet
-next git tree, hence this patch will wait until net-next was
merged.
Patches 1+2/3 are already pushed out to linux1394.git "testing" and
"for-next" branches, but I still like to get review comments before I
send a pull request.
--
Stefan Richter
-==- =-== ---=-
h
-next git tree, hence this patch will wait until net-next was
merged.
Patches 1+2/3 are already pushed out to linux1394.git "testing" and
"for-next" branches, but I still like to get review comments before I
send a pull request.
--
Stefan Richter
-==- =-== ---=-
h
mum datagram size /with/ link fragmentation is 0xfff = 4095
for unicast and broadcast. This is because the RFC 2734 fragment
encapsulation header field for datagram size is only 12 bits wide.
Fixes: 5d48f00d836a('firewire: net: fix maximum possible MTU')
Signed-off-by: Stefan Richter <stef..
mum datagram size /with/ link fragmentation is 0xfff = 4095
for unicast and broadcast. This is because the RFC 2734 fragment
encapsulation header field for datagram size is only 12 bits wide.
Fixes: 5d48f00d836a('firewire: net: fix maximum possible MTU')
Signed-off-by: Stefan Richter
---
drivers/firew
Fixes: d894be57ca92('ethernet: use net core MTU range checking in more drivers')
CC: Jarod Wilson <ja...@redhat.com>
CC: Thomas Falcon <tlfal...@linux.vnet.ibm.com>
Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
---
drivers/net/ethernet/broadcom/sb1250-mac.c |
Fixes: d894be57ca92('ethernet: use net core MTU range checking in more drivers')
CC: Jarod Wilson
CC: Thomas Falcon
Signed-off-by: Stefan Richter
---
drivers/net/ethernet/broadcom/sb1250-mac.c | 2 +-
drivers/net/ethernet/ibm/ibmveth.c | 2 +-
2 files changed, 2 insertions(+), 2
was affected by this, changing
the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
RX remains unaffected.
CC: net...@vger.kernel.org
CC: linux1394-de...@lists.sourceforge.net
CC: Jarod Wilson <ja...@redhat.com>
Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
---
v2: use
was affected by this, changing
the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
RX remains unaffected.
CC: net...@vger.kernel.org
CC: linux1394-de...@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
---
v2: use ETH_DATA_LEN, add comment
drivers/firewire/net.c | 9
was affected by this, changing
the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
RX remains unaffected.
CC: net...@vger.kernel.org
CC: linux1394-de...@lists.sourceforge.net
CC: Jarod Wilson <ja...@redhat.com>
Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
---
driv
was affected by this, changing
the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
RX remains unaffected.
CC: net...@vger.kernel.org
CC: linux1394-de...@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
---
drivers/firewire/net.c | 8 +---
1 file changed, 1 insertion
ng in misc drivers')
CC: net...@vger.kernel.org
CC: linux1394-de...@lists.sourceforge.net
CC: Jarod Wilson <ja...@redhat.com>
Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
---
drivers/firewire/net.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/dr
ng in misc drivers')
CC: net...@vger.kernel.org
CC: linux1394-de...@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
---
drivers/firewire/net.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 84
Adding Cc: linux1394-devel, dropping several Ccs, no additional comment.
On Oct 22 Stefan Richter wrote:
> On Oct 20 Jarod Wilson wrote:
> > firewire-net:
> > - set min/max_mtu
> > - remove fwnet_change_mtu
> [...]
> > --- a/drivers/firewire/net.c
&g
Adding Cc: linux1394-devel, dropping several Ccs, no additional comment.
On Oct 22 Stefan Richter wrote:
> On Oct 20 Jarod Wilson wrote:
> > firewire-net:
> > - set min/max_mtu
> > - remove fwnet_change_mtu
> [...]
> > --- a/drivers/firewire/net.c
&g
u should be initialized to 1500, not less. But such a change
should be done in a separate patch.
--
Stefan Richter
-==- =-=- =-==-
http://arcgraph.de/sr/
u should be initialized to 1500, not less. But such a change
should be done in a separate patch.
--
Stefan Richter
-==- =-=- =-==-
http://arcgraph.de/sr/
On Oct 22 Stefan Richter wrote:
> On Oct 19 Jarod Wilson wrote:
> > On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > > On Oct 19 Sabrina Dubroca wrote:
> > > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
[...]
> > > > > @@ -14
On Oct 22 Stefan Richter wrote:
> On Oct 19 Jarod Wilson wrote:
> > On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > > On Oct 19 Sabrina Dubroca wrote:
> > > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
[...]
> > > > > @@ -14
> The 8191 was simply transplanted from right here. I think altering the
> value should be the subject of a separate patch.
You transplanted the value but dropped the comment. Though Denis' reply
sounds like the comment should have been /* FIXME, set by RxDMAFrameLen */.
--
Stefan Richter
-==- =-=- =-==-
http://arcgraph.de/sr/
^^^
> The 8191 was simply transplanted from right here. I think altering the
> value should be the subject of a separate patch.
You transplanted the value but dropped the comment. Though Denis' reply
sounds like the comment should have been /* FIXME, set by RxDMAFrameLen */.
--
Stefan Richter
-==- =-=- =-==-
http://arcgraph.de/sr/
On Oct 19 Jarod Wilson wrote:
> On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > On Oct 19 Sabrina Dubroca wrote:
> > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
> > > [...]
> > > > diff --git a/drivers/firewire/net.c b/drivers/firewi
On Oct 19 Jarod Wilson wrote:
> On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > On Oct 19 Sabrina Dubroca wrote:
> > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
> > > [...]
> > > > diff --git a/drivers/firewire/net.c b/drivers/firewi
find the maximum speed and size that is supported by all potential
listeners). This limits the payload to 512 bytes.
Unicast packets are transmitted via IEEE 1394 asynchronous write request
packets at optimum speed. In most cases, this means that 2048 bytes
payload is possible, in some cases 4
find the maximum speed and size that is supported by all potential
listeners). This limits the payload to 512 bytes.
Unicast packets are transmitted via IEEE 1394 asynchronous write request
packets at optimum speed. In most cases, this means that 2048 bytes
payload is possible, in some cases 4
firewire: nosy: do not ignore errors in ioremap_nocache()
drivers/firewire/nosy.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
Thanks.
--
Stefan Richter
-==- =-=- =---=
http://arcgraph.de/sr/
firewire: nosy: do not ignore errors in ioremap_nocache()
drivers/firewire/nosy.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
Thanks.
--
Stefan Richter
-==- =-=- =---=
http://arcgraph.de/sr/
On Oct 12 l...@kernel.org wrote:
[...]
> Signed-off-by: Stefan Richter <stef...@s5r6.in-berlin.de>
> [lizf: Backported to 3.4: use dev_notice() instead of ohci_notice()]
> Signed-off-by: Zefan Li <lize...@huawei.com>
> ---
> drivers/firewire/ohci.c | 5 +
>
On Oct 12 l...@kernel.org wrote:
[...]
> Signed-off-by: Stefan Richter
> [lizf: Backported to 3.4: use dev_notice() instead of ohci_notice()]
> Signed-off-by: Zefan Li
> ---
> drivers/firewire/ohci.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/d
_start_pcl, lynx->rcv_start_pcl_bus);
@@ -685,7 +685,7 @@ fail_deallocate:
lynx->rcv_buffer, lynx->rcv_buffer_bus);
iounmap(lynx->registers);
-fail_deallocate2:
+fail_deallocate_lynx:
kfree(lynx);
fail_disable:
--
Stefan Richter
-==- =-=- -=--=
http://arcgraph.de/sr/
_start_pcl_bus);
@@ -685,7 +685,7 @@ fail_deallocate:
lynx->rcv_buffer, lynx->rcv_buffer_bus);
iounmap(lynx->registers);
-fail_deallocate2:
+fail_deallocate_lynx:
kfree(lynx);
fail_disable:
--
Stefan Richter
-==- =-=- -=--=
http://arcgraph.de/sr/
+ goto stop_broadcast;
> }
[...]
> @@ -1166,8 +1166,7 @@ static int fwnet_broadcast_start(struct
> fwnet_device *dev) dev->broadcast_state = FWNET_BROADCAST_RUNNING;
>
> return 0;
> -
> - failed:
> + stop_broadcast:
> __fwnet_broadcas
; }
[...]
> @@ -1166,8 +1166,7 @@ static int fwnet_broadcast_start(struct
> fwnet_device *dev) dev->broadcast_state = FWNET_BROADCAST_RUNNING;
>
> return 0;
> -
> - failed:
> + stop_broadcast:
> __fwnet_broadcast_stop(dev);
> return retval;
>
gt;
> INIT_LIST_HEAD(>fi_list);
> fi = fwnet_frag_new(new, frag_off, frag_len);
> - if (fi == NULL)
> + if (!fi)
> goto free_new;
[...]
--
Stefan Richter
-==- =--= ==---
http://arcgraph.de/sr/
);
> fi = fwnet_frag_new(new, frag_off, frag_len);
> - if (fi == NULL)
> + if (!fi)
> goto free_new;
[...]
--
Stefan Richter
-==- =--= ==---
http://arcgraph.de/sr/
reader that dev->broadcast_rcv_buffer_ptrs is an array,
but possibly at the cost of superfluous code. Is gcc's optimizer
able to resolve kmalloc_array's check at compile time as always
false, such that the superfluous code is eliminated as dead code?
I believe I know answers to this but prefer to hear what you as the patch
author think about it.
--
Stefan Richter
-==- =--= ==---
http://arcgraph.de/sr/
possibly at the cost of superfluous code. Is gcc's optimizer
able to resolve kmalloc_array's check at compile time as always
false, such that the superfluous code is eliminated as dead code?
I believe I know answers to this but prefer to hear what you as the patch
author think about it.
--
Stefan Richter
-==- =--= ==---
http://arcgraph.de/sr/
On May 06 Daniel Vetter wrote:
> On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote:
[...]
> > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s)
>
> This one failed in both runs. Can you please retest with just that using
>
> # kms_frontbuffer_track
On May 06 Daniel Vetter wrote:
> On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote:
[...]
> > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s)
>
> This one failed in both runs. Can you please retest with just that using
>
> # kms_frontbuffer_track
On May 08 Stefan Richter wrote:
> On May 05 Zanoni, Paulo R wrote:
> > If you don't want to keep carrying a manual revert, you can just boot
> > with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> > it would be good to know in case you still somehow see
On May 08 Stefan Richter wrote:
> On May 05 Zanoni, Paulo R wrote:
> > If you don't want to keep carrying a manual revert, you can just boot
> > with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> > it would be good to know in case you still somehow see
pected, i915.enable_fbc=0 works fine.
No freeze within 2.5 days uptime; tested on v4.6-rc6.
--
Stefan Richter
-==- -=-= -=---
http://arcgraph.de/sr/
pected, i915.enable_fbc=0 works fine.
No freeze within 2.5 days uptime; tested on v4.6-rc6.
--
Stefan Richter
-==- -=-= -=---
http://arcgraph.de/sr/
t this sometime soon.
--
Stefan Richter
-==- -=-= --==-
http://arcgraph.de/sr/
t this sometime soon.
--
Stefan Richter
-==- -=-= --==-
http://arcgraph.de/sr/
On May 05 Zanoni, Paulo R wrote:
> Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> > Oh, and in case you - the person reading this commit message - found
> > this commit through git bisect, please do the following:
> > - Check your dmesg and s
On May 05 Zanoni, Paulo R wrote:
> Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> > Oh, and in case you - the person reading this commit message - found
> > this commit through git bisect, please do the following:
> > - Check your dmesg and s
On May 05 Stefan Richter wrote:
> Quoting the changelog of the commit:
[...]
> - Download intel-gpu-tools, compile it, and run:
>$ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 |
> tee fbc.txt
>Then send us the fbc.txt file, especiall
On May 05 Stefan Richter wrote:
> Quoting the changelog of the commit:
[...]
> - Download intel-gpu-tools, compile it, and run:
>$ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 |
> tee fbc.txt
>Then send us the fbc.txt file, especiall
On May 05 Stefan Richter wrote:
> Quoting the changelog of the commit:
[...]
> - Boot with drm.debug=0xe, reproduce the problem, then send us the
>dmesg file.
>
> I can try this, but I am skeptical about getting any useful kernel
> messages from before the hang.
On May 05 Stefan Richter wrote:
> Quoting the changelog of the commit:
[...]
> - Boot with drm.debug=0xe, reproduce the problem, then send us the
>dmesg file.
>
> I can try this, but I am skeptical about getting any useful kernel
> messages from before the hang.
On Apr 30 Stefan Richter wrote:
> On Apr 29 Stefan Richter wrote:
> > On Apr 26 Stefan Richter wrote:
> > > v4.6-rc solidly hangs after a short while after boot, login to X11, and
> > > doing nothing much remarkable on the just brought up X desktop.
> > >
On Apr 30 Stefan Richter wrote:
> On Apr 29 Stefan Richter wrote:
> > On Apr 26 Stefan Richter wrote:
> > > v4.6-rc solidly hangs after a short while after boot, login to X11, and
> > > doing nothing much remarkable on the just brought up X desktop.
> > >
On Apr 29 Stefan Richter wrote:
> On Apr 26 Stefan Richter wrote:
> > v4.6-rc solidly hangs after a short while after boot, login to X11, and
> > doing nothing much remarkable on the just brought up X desktop.
> >
> > Hardware: x86-64, E3-1245 v3 (Haswell),
> &g
On Apr 29 Stefan Richter wrote:
> On Apr 26 Stefan Richter wrote:
> > v4.6-rc solidly hangs after a short while after boot, login to X11, and
> > doing nothing much remarkable on the just brought up X desktop.
> >
> > Hardware: x86-64, E3-1245 v3 (Haswell),
> &g
On Apr 26 Stefan Richter wrote:
> v4.6-rc solidly hangs after a short while after boot, login to X11, and
> doing nothing much remarkable on the just brought up X desktop.
>
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> usin
On Apr 26 Stefan Richter wrote:
> v4.6-rc solidly hangs after a short while after boot, login to X11, and
> doing nothing much remarkable on the just brought up X desktop.
>
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> usin
On Apr 27 Stefan Richter wrote:
> On Apr 27 Stefan Richter wrote:
> > Today I booted a 2nd time into v4.6-rc5, and loaded netconsole shortly
> > after boot and xdm login to try capturing an oops. But throughout 5 hours
> > uptime now, the hang was not reproduced.
>
&
On Apr 27 Stefan Richter wrote:
> On Apr 27 Stefan Richter wrote:
> > Today I booted a 2nd time into v4.6-rc5, and loaded netconsole shortly
> > after boot and xdm login to try capturing an oops. But throughout 5 hours
> > uptime now, the hang was not reproduced.
>
&
On Apr 27 Stefan Richter wrote:
> Today I booted a 2nd time into v4.6-rc5, and loaded netconsole shortly
> after boot and xdm login to try capturing an oops. But throughout 5 hours
> uptime now, the hang was not reproduced.
...and 20 minutes after this post went out, th
On Apr 27 Stefan Richter wrote:
> Today I booted a 2nd time into v4.6-rc5, and loaded netconsole shortly
> after boot and xdm login to try capturing an oops. But throughout 5 hours
> uptime now, the hang was not reproduced.
...and 20 minutes after this post went out, th
On Apr 26 Stefan Richter wrote:
> v4.6-rc solidly hangs after a short while after boot, login to X11, and
> doing nothing much remarkable on the just brought up X desktop.
>
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> usin
On Apr 26 Stefan Richter wrote:
> v4.6-rc solidly hangs after a short while after boot, login to X11, and
> doing nothing much remarkable on the just brought up X desktop.
>
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> usin
On Apr 26 Stefan Richter wrote:
> v4.6-rc solidly hangs after a short while after boot, login to X11, and
> doing nothing much remarkable on the just brought up X desktop.
>
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> usin
On Apr 26 Stefan Richter wrote:
> v4.6-rc solidly hangs after a short while after boot, login to X11, and
> doing nothing much remarkable on the just brought up X desktop.
>
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> usin
On Apr 26 Stefan Richter wrote:
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> using integrated Intel graphics (HD P4600, i915 driver),
> C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
> Intel LAN (i
On Apr 26 Stefan Richter wrote:
> Hardware: x86-64, E3-1245 v3 (Haswell),
> mainboard Supermicro X10SAE,
> using integrated Intel graphics (HD P4600, i915 driver),
> C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
> Intel LAN (i
(simplify the hardware, run
netconsole, bisect). In practice I cannot do so for the the time being
due to lack of spare time. That's also the reason why I did not already
send a report when I tested v4.6-rc2, and why I did not boot v4.6-rc[25]
more than once yet.
--
Stefan Richter
(simplify the hardware, run
netconsole, bisect). In practice I cannot do so for the the time being
due to lack of spare time. That's also the reason why I did not already
send a report when I tested v4.6-rc2, and why I did not boot v4.6-rc[25]
more than once yet.
--
Stefan Richter
ove a last forgotten one.
Tina Ruchandani (1):
firewire: nosy: Replace timeval with timespec64
drivers/firewire/nosy.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--
Stefan Richter
-==- --== ==--=
http://arcgraph.de/sr/
ove a last forgotten one.
Tina Ruchandani (1):
firewire: nosy: Replace timeval with timespec64
drivers/firewire/nosy.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--
Stefan Richter
-==- --== ==--=
http://arcgraph.de/sr/
>>>> 'struct timeval' from the kernel (that would help identify cases
>>>> where the code is actually broken).
>>>>
>>>> Signed-off-by: Tina Ruchandani <ruchandani.t...@gmail.com>
[...]
> Reviewed-by: Arnd Bergmann <a...@arndb.
1 - 100 of 2238 matches
Mail list logo
