I finally got a chance to test 3.6-rc1 after having my GoFlex Net
support patch accepted for the 3.6 release train. Included in 3.6-rc1
was an update for Kirkwoods switching SATA to DT which was not part of
my original testing. It seems something with this change has
partially broken the GoFlex and a couple other Kirkwood based devices.
The key factor is the number of SATA ports defined in the dts:
sata at 80000 {
status = "okay";
nr-ports = <2>;
};
If set at the correct number for my device, 2, my GFN does not
complete kernel init, hanging here:
<SNIP>
[ 15.287832] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 15.296545] jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
[ 15.303202] msgmni has been set to 240
[ 15.308503] Block layer SCSI generic (bsg) driver version 0.4 loaded (major )
[ 15.316021] io scheduler noop registered
[ 15.320149] io scheduler deadline registered
[ 15.324558] io scheduler cfq registered (default)
[ 15.329462] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
[ 15.335962] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
[ 15.376751] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[ 15.416736] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
[ 15.456735] mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
[ 15.496734] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
[ 15.506309] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 15.509111] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[ 15.509141] console [ttyS0] enabled, bootconsole disabled
[ 15.518967] brd: module loaded
[ 15.524991] loop: module loaded
[ 15.528584] sata_mv sata_mv.0: cannot get optional clkdev
[ 15.534180] sata_mv sata_mv.0: slots 32 ports 2
If you set nr-ports to 1 the unit boots cleanly, save for only
detecting one functional SATA port. Another user has confirmed this
behavior on an Iomega IX2-200.
I bounced this off Andrew before bringing it to the list proper. His
initial hunch puts the culprit in or around:
#if defined(CONFIG_HAVE_CLK)
hpriv->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(hpriv->clk))
dev_notice(&pdev->dev, "cannot get optional clkdev\n");
else
clk_prepare_enable(hpriv->clk);
for (port = 0; port < n_ports; port++) {
char port_number[16];
sprintf(port_number, "%d", port);
hpriv->port_clks[port] = clk_get(&pdev->dev, port_number);
if (!IS_ERR(hpriv->port_clks[port]))
clk_prepare_enable(hpriv->port_clks[port]);
}
#endif
I haven't had a chance to play with this yet to see if I can figure it
out, something about having the second port enabled seems to be
mucking with the clocks on Kirkwoods.
Joshua Coombs
From: Aaro Koskinen <aaro.koskinen@iki.fi> Date: 2012-08-15 00:25:48
Him
On Tue, Aug 14, 2012 at 07:59:00PM -0400, Josh Coombs wrote:
I finally got a chance to test 3.6-rc1 after having my GoFlex Net
support patch accepted for the 3.6 release train. Included in 3.6-rc1
was an update for Kirkwoods switching SATA to DT which was not part of
my original testing. It seems something with this change has
partially broken the GoFlex and a couple other Kirkwood based devices.
The key factor is the number of SATA ports defined in the dts:
sata at 80000 {
status = "okay";
nr-ports = <2>;
};
If set at the correct number for my device, 2, my GFN does not
complete kernel init, hanging here:
<SNIP>
[ 15.287832] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 15.296545] jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
[ 15.303202] msgmni has been set to 240
[ 15.308503] Block layer SCSI generic (bsg) driver version 0.4 loaded (major )
[ 15.316021] io scheduler noop registered
[ 15.320149] io scheduler deadline registered
[ 15.324558] io scheduler cfq registered (default)
[ 15.329462] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
[ 15.335962] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
[ 15.376751] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[ 15.416736] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
[ 15.456735] mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
[ 15.496734] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
[ 15.506309] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 15.509111] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[ 15.509141] console [ttyS0] enabled, bootconsole disabled
[ 15.518967] brd: module loaded
[ 15.524991] loop: module loaded
[ 15.528584] sata_mv sata_mv.0: cannot get optional clkdev
[ 15.534180] sata_mv sata_mv.0: slots 32 ports 2
If you set nr-ports to 1 the unit boots cleanly, save for only
detecting one functional SATA port. Another user has confirmed this
behavior on an Iomega IX2-200.
Try booting with "coherent_pool=1M" (or bigger) kernel parameter. I think
with the recent DMA mapping changes, the default 256 KB coherent pool may
be too small, mv_xor and sata_mv together needs more. (I'm not sure how
it actually worked before commit e9da6e9905e639b0f842a244bc770b48ad0523e9,
but it seems this is the cuase).
It should be noted that dma_pool_alloc() uses GFP_ATOMIC always, and if
drivers exhaust the coherent pool already during the boot that function
just keeps looping forever. Users only see boot hanging with no clue
what to do. I would say it's quite a poor error handling...
A.
On Tue, Aug 14, 2012 at 8:25 PM, Aaro Koskinen [off-list ref] wrote:
Him
On Tue, Aug 14, 2012 at 07:59:00PM -0400, Josh Coombs wrote:
quoted
I finally got a chance to test 3.6-rc1 after having my GoFlex Net
support patch accepted for the 3.6 release train. Included in 3.6-rc1
was an update for Kirkwoods switching SATA to DT which was not part of
my original testing. It seems something with this change has
partially broken the GoFlex and a couple other Kirkwood based devices.
The key factor is the number of SATA ports defined in the dts:
sata at 80000 {
status = "okay";
nr-ports = <2>;
};
If set at the correct number for my device, 2, my GFN does not
complete kernel init, hanging here:
<SNIP>
[ 15.287832] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 15.296545] jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
[ 15.303202] msgmni has been set to 240
[ 15.308503] Block layer SCSI generic (bsg) driver version 0.4 loaded (major )
[ 15.316021] io scheduler noop registered
[ 15.320149] io scheduler deadline registered
[ 15.324558] io scheduler cfq registered (default)
[ 15.329462] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
[ 15.335962] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
[ 15.376751] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[ 15.416736] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
[ 15.456735] mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
[ 15.496734] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
[ 15.506309] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 15.509111] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[ 15.509141] console [ttyS0] enabled, bootconsole disabled
[ 15.518967] brd: module loaded
[ 15.524991] loop: module loaded
[ 15.528584] sata_mv sata_mv.0: cannot get optional clkdev
[ 15.534180] sata_mv sata_mv.0: slots 32 ports 2
If you set nr-ports to 1 the unit boots cleanly, save for only
detecting one functional SATA port. Another user has confirmed this
behavior on an Iomega IX2-200.
Try booting with "coherent_pool=1M" (or bigger) kernel parameter. I think
with the recent DMA mapping changes, the default 256 KB coherent pool may
be too small, mv_xor and sata_mv together needs more. (I'm not sure how
it actually worked before commit e9da6e9905e639b0f842a244bc770b48ad0523e9,
but it seems this is the cuase).
It should be noted that dma_pool_alloc() uses GFP_ATOMIC always, and if
drivers exhaust the coherent pool already during the boot that function
just keeps looping forever. Users only see boot hanging with no clue
what to do. I would say it's quite a poor error handling...
A.
I can confirm that fixes my GoFlex. Would this justify raising the
default for Kirkwoods, or just for specific devices within the family?
Josh C
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2012-08-17 12:47:02
Hi Aaro,
On Wednesday, August 15, 2012 2:26 AM Aaro Koskinen wrote:
On Tue, Aug 14, 2012 at 07:59:00PM -0400, Josh Coombs wrote:
quoted
I finally got a chance to test 3.6-rc1 after having my GoFlex Net
support patch accepted for the 3.6 release train. Included in 3.6-rc1
was an update for Kirkwoods switching SATA to DT which was not part of
my original testing. It seems something with this change has
partially broken the GoFlex and a couple other Kirkwood based devices.
The key factor is the number of SATA ports defined in the dts:
sata at 80000 {
status = "okay";
nr-ports = <2>;
};
If set at the correct number for my device, 2, my GFN does not
complete kernel init, hanging here:
<SNIP>
[ 15.287832] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 15.296545] jffs2: version 2.2. (NAND) ?C 2001-2006 Red Hat, Inc.
[ 15.303202] msgmni has been set to 240
[ 15.308503] Block layer SCSI generic (bsg) driver version 0.4 loaded (major )
[ 15.316021] io scheduler noop registered
[ 15.320149] io scheduler deadline registered
[ 15.324558] io scheduler cfq registered (default)
[ 15.329462] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
[ 15.335962] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
[ 15.376751] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[ 15.416736] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
[ 15.456735] mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
[ 15.496734] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
[ 15.506309] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 15.509111] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
[ 15.509141] console [ttyS0] enabled, bootconsole disabled
[ 15.518967] brd: module loaded
[ 15.524991] loop: module loaded
[ 15.528584] sata_mv sata_mv.0: cannot get optional clkdev
[ 15.534180] sata_mv sata_mv.0: slots 32 ports 2
If you set nr-ports to 1 the unit boots cleanly, save for only
detecting one functional SATA port. Another user has confirmed this
behavior on an Iomega IX2-200.
Try booting with "coherent_pool=1M" (or bigger) kernel parameter. I think
with the recent DMA mapping changes, the default 256 KB coherent pool may
be too small, mv_xor and sata_mv together needs more. (I'm not sure how
it actually worked before commit e9da6e9905e639b0f842a244bc770b48ad0523e9,
but it seems this is the cuase).
It should be noted that dma_pool_alloc() uses GFP_ATOMIC always, and if
drivers exhaust the coherent pool already during the boot that function
just keeps looping forever. Users only see boot hanging with no clue
what to do. I would say it's quite a poor error handling...
Thanks for the report, I will improve error handling and add a possibility for
setting the default pool size by platform/board setup code. I'm sorry for a late
response.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center