Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
On 09/09/16 13:20, Deucher, Alexander wrote: -Original Message- From: Koenig, Christian Sent: Friday, September 09, 2016 4:16 AM To: Mark Fortescue; Koenig, Christian; David Airlie Cc: Deucher, Alexander; linux-kernel@vger.kernel.org; dri- de...@lists.freedesktop.org Subject: Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel interface and DP-2 is a DVI interface (which I can connect to my monitor if testing this is useful). There are no displayport connectors. Yeah, but from the driver point of view there are only DP connectors on the chip. The LVDS and DVI are probably realized with external DP to whatever converter ICs. That would explain why some similar boards have 24bit LVDS and others only 18bit LVDS. It could be that this is actually a configuration we don't support yet with radeon and/or the display stack. E.g. that the connector only uses the displayport LVDS lanes, but not actual the displayport protocol to train those lanes. Instead it rather expects a fixed training which is configured somewhere in the BIOS. Anyway Alex needs to take a look, he knows displayport much better than I do (and hates it passionately :). Generally these sorts of setups are supported by exposing an LVDS or eDP connector rather than a regular DP. In the case of LVDS and eDP, we have code to fallback to a hardcoded EDID in the vbios if DDC is not available. I'll take a closer look when I'm back. Alex Thanks Alex, I look forward to hearing from you when you have finished recovering from your holiday and the associated work backlog :). I raised a bug (https://bugs.freedesktop.org/show_bug.cgi?id=97637) - probably on the wrong component but fixing that should be easy. It has a more complete copy of the Opps. Regards Mark. Cheers, Christian. Am 08.09.2016 um 13:18 schrieb Mark Fortescue: On 08/09/16 11:25, Christian König wrote: Am 08.09.2016 um 11:09 schrieb Mark Fortescue: Hi Christian, Thank you for the feedback. On 08/09/16 08:14, Christian König wrote: Am 07.09.2016 um 19:38 schrieb Mark Fortescue: On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel Oops because Connector 0 (LCD Panel interface) does not have DDC. I'm not an expert on this, but that is really odd cause even LCD Panels should have a DDC interface. Ubuntu 16.04 LTS Kernel (4.4 series): ... [ 8.262990] [drm] ib test on ring 5 succeeded [ 8.288897] [drm] Radeon Display Connectors [ 8.293175] [drm] Connector 0: [ 8.296252] [drm] DP-1 Especially since the BIOS claims that this is a displayport connector and there is no physical way to have a DP without an DDC as far as I know. Please open a bug report on FDO and attach you BIOS image. FDO ? I am not familiar with this. Please can you enlighten me. See here: http://bugs.freedesktop.org/ I do not have a BIOS image so will need some assistance in understanding what is required here and how I extract the BIOS information you are after. Sorry my fault. Mullins is an APU, so you don't have a dedicated video BIOS. As usually I didn't got enough sleep :) But please open up a bug report anyway. Know the problem of being awake too long :). I will raise a bug. On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel interface and DP-2 is a DVI interface (which I can connect to my monitor if testing this is useful). There are no displayport connectors. Yeah, but from the driver point of view there are only DP connectors on the chip. The LVDS and DVI are probably realized with external DP to whatever converter ICs. That would explain why some similar boards have 24bit LVDS and others only 18bit LVDS. On industrial motherboards, I have noticed that it is not uncommon to hard code the information for the LCD panel into the BIOS so no DDC is required. In this case, there is no LCD panel connected to the interface anyway. That is correct and as far as I know well supported by Radeon, but the crux is there should still be a DDC channel even if there isn't anything attached to it. See with displayport you got four LVDS channels to submit the actual picture and an AUX channel to configure and query the device. The DDC is just represented as certain packets over the AUX channel. If the AUX channel doesn't work or isn't connect then the link training wouldn't be possible as well and so you wouldn't be able to get any picture on the LVDS. Interesting. See http://www.commell.com.tw/product/SBC/LV-683.HTM for more information on the board. Looking at the web site, there is a BIOS image available form Commell if that is of use. Alex clearly needs to take a look on this. I think for the time being you could hack together a patch which just ignores DP connectors during probing if they don't have an associated DDC instead of changing the code everywhere the DDC object is required. I will try to find the time to look
Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
On 09/09/16 13:20, Deucher, Alexander wrote: -Original Message- From: Koenig, Christian Sent: Friday, September 09, 2016 4:16 AM To: Mark Fortescue; Koenig, Christian; David Airlie Cc: Deucher, Alexander; linux-kernel@vger.kernel.org; dri- de...@lists.freedesktop.org Subject: Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel interface and DP-2 is a DVI interface (which I can connect to my monitor if testing this is useful). There are no displayport connectors. Yeah, but from the driver point of view there are only DP connectors on the chip. The LVDS and DVI are probably realized with external DP to whatever converter ICs. That would explain why some similar boards have 24bit LVDS and others only 18bit LVDS. It could be that this is actually a configuration we don't support yet with radeon and/or the display stack. E.g. that the connector only uses the displayport LVDS lanes, but not actual the displayport protocol to train those lanes. Instead it rather expects a fixed training which is configured somewhere in the BIOS. Anyway Alex needs to take a look, he knows displayport much better than I do (and hates it passionately :). Generally these sorts of setups are supported by exposing an LVDS or eDP connector rather than a regular DP. In the case of LVDS and eDP, we have code to fallback to a hardcoded EDID in the vbios if DDC is not available. I'll take a closer look when I'm back. Alex Thanks Alex, I look forward to hearing from you when you have finished recovering from your holiday and the associated work backlog :). I raised a bug (https://bugs.freedesktop.org/show_bug.cgi?id=97637) - probably on the wrong component but fixing that should be easy. It has a more complete copy of the Opps. Regards Mark. Cheers, Christian. Am 08.09.2016 um 13:18 schrieb Mark Fortescue: On 08/09/16 11:25, Christian König wrote: Am 08.09.2016 um 11:09 schrieb Mark Fortescue: Hi Christian, Thank you for the feedback. On 08/09/16 08:14, Christian König wrote: Am 07.09.2016 um 19:38 schrieb Mark Fortescue: On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel Oops because Connector 0 (LCD Panel interface) does not have DDC. I'm not an expert on this, but that is really odd cause even LCD Panels should have a DDC interface. Ubuntu 16.04 LTS Kernel (4.4 series): ... [ 8.262990] [drm] ib test on ring 5 succeeded [ 8.288897] [drm] Radeon Display Connectors [ 8.293175] [drm] Connector 0: [ 8.296252] [drm] DP-1 Especially since the BIOS claims that this is a displayport connector and there is no physical way to have a DP without an DDC as far as I know. Please open a bug report on FDO and attach you BIOS image. FDO ? I am not familiar with this. Please can you enlighten me. See here: http://bugs.freedesktop.org/ I do not have a BIOS image so will need some assistance in understanding what is required here and how I extract the BIOS information you are after. Sorry my fault. Mullins is an APU, so you don't have a dedicated video BIOS. As usually I didn't got enough sleep :) But please open up a bug report anyway. Know the problem of being awake too long :). I will raise a bug. On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel interface and DP-2 is a DVI interface (which I can connect to my monitor if testing this is useful). There are no displayport connectors. Yeah, but from the driver point of view there are only DP connectors on the chip. The LVDS and DVI are probably realized with external DP to whatever converter ICs. That would explain why some similar boards have 24bit LVDS and others only 18bit LVDS. On industrial motherboards, I have noticed that it is not uncommon to hard code the information for the LCD panel into the BIOS so no DDC is required. In this case, there is no LCD panel connected to the interface anyway. That is correct and as far as I know well supported by Radeon, but the crux is there should still be a DDC channel even if there isn't anything attached to it. See with displayport you got four LVDS channels to submit the actual picture and an AUX channel to configure and query the device. The DDC is just represented as certain packets over the AUX channel. If the AUX channel doesn't work or isn't connect then the link training wouldn't be possible as well and so you wouldn't be able to get any picture on the LVDS. Interesting. See http://www.commell.com.tw/product/SBC/LV-683.HTM for more information on the board. Looking at the web site, there is a BIOS image available form Commell if that is of use. Alex clearly needs to take a look on this. I think for the time being you could hack together a patch which just ignores DP connectors during probing if they don't have an associated DDC instead of changing the code everywhere the DDC object is required. I will try to find the time to look
Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
On 08/09/16 11:25, Christian König wrote: Am 08.09.2016 um 11:09 schrieb Mark Fortescue: Hi Christian, Thank you for the feedback. On 08/09/16 08:14, Christian König wrote: Am 07.09.2016 um 19:38 schrieb Mark Fortescue: On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel Oops because Connector 0 (LCD Panel interface) does not have DDC. I'm not an expert on this, but that is really odd cause even LCD Panels should have a DDC interface. Ubuntu 16.04 LTS Kernel (4.4 series): ... [ 8.262990] [drm] ib test on ring 5 succeeded [ 8.288897] [drm] Radeon Display Connectors [ 8.293175] [drm] Connector 0: [ 8.296252] [drm] DP-1 Especially since the BIOS claims that this is a displayport connector and there is no physical way to have a DP without an DDC as far as I know. Please open a bug report on FDO and attach you BIOS image. FDO ? I am not familiar with this. Please can you enlighten me. See here: http://bugs.freedesktop.org/ I do not have a BIOS image so will need some assistance in understanding what is required here and how I extract the BIOS information you are after. Sorry my fault. Mullins is an APU, so you don't have a dedicated video BIOS. As usually I didn't got enough sleep :) But please open up a bug report anyway. Know the problem of being awake too long :). I will raise a bug. On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel interface and DP-2 is a DVI interface (which I can connect to my monitor if testing this is useful). There are no displayport connectors. Yeah, but from the driver point of view there are only DP connectors on the chip. The LVDS and DVI are probably realized with external DP to whatever converter ICs. That would explain why some similar boards have 24bit LVDS and others only 18bit LVDS. On industrial motherboards, I have noticed that it is not uncommon to hard code the information for the LCD panel into the BIOS so no DDC is required. In this case, there is no LCD panel connected to the interface anyway. That is correct and as far as I know well supported by Radeon, but the crux is there should still be a DDC channel even if there isn't anything attached to it. See with displayport you got four LVDS channels to submit the actual picture and an AUX channel to configure and query the device. The DDC is just represented as certain packets over the AUX channel. If the AUX channel doesn't work or isn't connect then the link training wouldn't be possible as well and so you wouldn't be able to get any picture on the LVDS. Interesting. See http://www.commell.com.tw/product/SBC/LV-683.HTM for more information on the board. Looking at the web site, there is a BIOS image available form Commell if that is of use. Alex clearly needs to take a look on this. I think for the time being you could hack together a patch which just ignores DP connectors during probing if they don't have an associated DDC instead of changing the code everywhere the DDC object is required. I will try to find the time to look at this in more detail. GPU/DRM is not something I have done any real work on in the past so I do not know how it all fits together. The overkill on the code changes is the result, as that way I don't need to understand where and why the helper function (radeon_dp_getsinktype) gets called or what other code paths can be executed that could fail. I will wait for Alex to have a think about it and respond before I do any more - that way I can finish the work I am paid to do first :). Regards, Christian. Regards Mark. Alex can probably take a look when he's back from vacation. Regards, Christian. [ 8.298791] [drm] Encoders: [ 8.301770] [drm] DFP1: INTERNAL_UNIPHY [ 8.305973] [drm] Connector 1: [ 8.309043] [drm] DP-2 [ 8.311598] [drm] HPD2 [ 8.314169] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 8.321609] [drm] Encoders: [ 8.324589] [drm] DFP2: INTERNAL_UNIPHY [ 8.328793] [drm] Connector 2: [ 8.331856] [drm] VGA-1 [ 8.342947] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4 [ 8.350341] [drm] Encoders: [ 8.353310] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 8.358195] BUG: unable to handle kernel NULL pointer dereference at 0409 [ 8.409733] [] radeon_dp_getsinktype+0x1a/0x30 [radeon] [ 8.416805] PGD 0 [ 8.418841] Oops: [#1] SMP ... This patch prevents Kernel failures due to a connector not having a DDC interface by changing the code so that ddc_bus is always checked before use. The problem was first identified using the uBuntu MATE 14.04 LTS (3.16 series kernels) but not dealt with at that time. On attempting to install uBuntu MATE 16.04 LTS (4.4 series kernels), it became clear that using various workarounds to allow the issue to be ignored were not viable so more effort was put in to sorting the issue resulting in this patch. See https://bugs.launchpad.net/bugs/1587885 for more details. Signed-off-by: Mark Fortescue <m...@thurn
Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
On 08/09/16 11:25, Christian König wrote: Am 08.09.2016 um 11:09 schrieb Mark Fortescue: Hi Christian, Thank you for the feedback. On 08/09/16 08:14, Christian König wrote: Am 07.09.2016 um 19:38 schrieb Mark Fortescue: On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel Oops because Connector 0 (LCD Panel interface) does not have DDC. I'm not an expert on this, but that is really odd cause even LCD Panels should have a DDC interface. Ubuntu 16.04 LTS Kernel (4.4 series): ... [ 8.262990] [drm] ib test on ring 5 succeeded [ 8.288897] [drm] Radeon Display Connectors [ 8.293175] [drm] Connector 0: [ 8.296252] [drm] DP-1 Especially since the BIOS claims that this is a displayport connector and there is no physical way to have a DP without an DDC as far as I know. Please open a bug report on FDO and attach you BIOS image. FDO ? I am not familiar with this. Please can you enlighten me. See here: http://bugs.freedesktop.org/ I do not have a BIOS image so will need some assistance in understanding what is required here and how I extract the BIOS information you are after. Sorry my fault. Mullins is an APU, so you don't have a dedicated video BIOS. As usually I didn't got enough sleep :) But please open up a bug report anyway. Know the problem of being awake too long :). I will raise a bug. On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel interface and DP-2 is a DVI interface (which I can connect to my monitor if testing this is useful). There are no displayport connectors. Yeah, but from the driver point of view there are only DP connectors on the chip. The LVDS and DVI are probably realized with external DP to whatever converter ICs. That would explain why some similar boards have 24bit LVDS and others only 18bit LVDS. On industrial motherboards, I have noticed that it is not uncommon to hard code the information for the LCD panel into the BIOS so no DDC is required. In this case, there is no LCD panel connected to the interface anyway. That is correct and as far as I know well supported by Radeon, but the crux is there should still be a DDC channel even if there isn't anything attached to it. See with displayport you got four LVDS channels to submit the actual picture and an AUX channel to configure and query the device. The DDC is just represented as certain packets over the AUX channel. If the AUX channel doesn't work or isn't connect then the link training wouldn't be possible as well and so you wouldn't be able to get any picture on the LVDS. Interesting. See http://www.commell.com.tw/product/SBC/LV-683.HTM for more information on the board. Looking at the web site, there is a BIOS image available form Commell if that is of use. Alex clearly needs to take a look on this. I think for the time being you could hack together a patch which just ignores DP connectors during probing if they don't have an associated DDC instead of changing the code everywhere the DDC object is required. I will try to find the time to look at this in more detail. GPU/DRM is not something I have done any real work on in the past so I do not know how it all fits together. The overkill on the code changes is the result, as that way I don't need to understand where and why the helper function (radeon_dp_getsinktype) gets called or what other code paths can be executed that could fail. I will wait for Alex to have a think about it and respond before I do any more - that way I can finish the work I am paid to do first :). Regards, Christian. Regards Mark. Alex can probably take a look when he's back from vacation. Regards, Christian. [ 8.298791] [drm] Encoders: [ 8.301770] [drm] DFP1: INTERNAL_UNIPHY [ 8.305973] [drm] Connector 1: [ 8.309043] [drm] DP-2 [ 8.311598] [drm] HPD2 [ 8.314169] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 8.321609] [drm] Encoders: [ 8.324589] [drm] DFP2: INTERNAL_UNIPHY [ 8.328793] [drm] Connector 2: [ 8.331856] [drm] VGA-1 [ 8.342947] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4 0x64e4 [ 8.350341] [drm] Encoders: [ 8.353310] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 8.358195] BUG: unable to handle kernel NULL pointer dereference at 0409 [ 8.409733] [] radeon_dp_getsinktype+0x1a/0x30 [radeon] [ 8.416805] PGD 0 [ 8.418841] Oops: [#1] SMP ... This patch prevents Kernel failures due to a connector not having a DDC interface by changing the code so that ddc_bus is always checked before use. The problem was first identified using the uBuntu MATE 14.04 LTS (3.16 series kernels) but not dealt with at that time. On attempting to install uBuntu MATE 16.04 LTS (4.4 series kernels), it became clear that using various workarounds to allow the issue to be ignored were not viable so more effort was put in to sorting the issue resulting in this patch. See https://bugs.launchpad.net/bugs/1587885 for more details. Signed-off-by: Mark Fortescue Tested-by: Mark
Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
Hi Christian,
Thank you for the feedback.
On 08/09/16 08:14, Christian König wrote:
Am 07.09.2016 um 19:38 schrieb Mark Fortescue:
On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel
Oops because Connector 0 (LCD Panel interface) does not have DDC.
I'm not an expert on this, but that is really odd cause even LCD Panels
should have a DDC interface.
Ubuntu 16.04 LTS Kernel (4.4 series):
...
[ 8.262990] [drm] ib test on ring 5 succeeded
[ 8.288897] [drm] Radeon Display Connectors
[ 8.293175] [drm] Connector 0:
[ 8.296252] [drm] DP-1
Especially since the BIOS claims that this is a displayport connector
and there is no physical way to have a DP without an DDC as far as I know.
Please open a bug report on FDO and attach you BIOS image.
FDO ? I am not familiar with this. Please can you enlighten me.
I do not have a BIOS image so will need some assistance in understanding
what is required here and how I extract the BIOS information you are after.
On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
interface and DP-2 is a DVI interface (which I can connect to my monitor
if testing this is useful). There are no displayport connectors.
On industrial motherboards, I have noticed that it is not uncommon to
hard code the information for the LCD panel into the BIOS so no DDC is
required. In this case, there is no LCD panel connected to the interface
anyway.
See http://www.commell.com.tw/product/SBC/LV-683.HTM for more
information on the board. Looking at the web site, there is a BIOS image
available form Commell if that is of use.
Alex can probably take a look when he's back from vacation.
Regards,
Christian.
[ 8.298791] [drm] Encoders:
[ 8.301770] [drm] DFP1: INTERNAL_UNIPHY
[ 8.305973] [drm] Connector 1:
[ 8.309043] [drm] DP-2
[ 8.311598] [drm] HPD2
[ 8.314169] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448
0x644c 0x644c
[ 8.321609] [drm] Encoders:
[ 8.324589] [drm] DFP2: INTERNAL_UNIPHY
[ 8.328793] [drm] Connector 2:
[ 8.331856] [drm] VGA-1
[ 8.342947] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0
0x64e4 0x64e4
[ 8.350341] [drm] Encoders:
[ 8.353310] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 8.358195] BUG: unable to handle kernel NULL pointer dereference at
0409
[ 8.409733] [] radeon_dp_getsinktype+0x1a/0x30 [radeon]
[ 8.416805] PGD 0
[ 8.418841] Oops: [#1] SMP
...
This patch prevents Kernel failures due to a connector not having a
DDC interface by changing the code so that ddc_bus is always checked
before use.
The problem was first identified using the uBuntu MATE 14.04 LTS (3.16
series kernels) but not dealt with at that time. On attempting to
install uBuntu MATE 16.04 LTS (4.4 series kernels), it became clear
that using various workarounds to allow the issue to be ignored were
not viable so more effort was put in to sorting the issue resulting in
this patch. See https://bugs.launchpad.net/bugs/1587885 for more details.
Signed-off-by: Mark Fortescue <m...@thurning-instruments.co.uk>
Tested-by: Mark Fortescue <m...@thurning-instruments.co.uk>
---
Looks like Thunderbird may have made a mess of the patch when pasting
the contents into the mail message - my alternate mail client (pine)
also has strict line length handling and trashes non-MIME encoded
patches.
This may not be the correct approach to solving the issue but it is
clean in that it ensures that ddc_bus is never used when NULL
regardless of how the code ended up at the point of use.
If it helps with back porting, I have patches for the uBuntu 14.04 LTS
[3.13 series], uBuntu MATE 14.04 LTS [3.16 series] and uBuntu 16.04
LTS [4.4 series] kernels.
Test Hardware:
Commell LV-683 Mini-ITX with onboard AMD Dual-core G-T56N
4G Ram, 2x1TB Disk, HANNS-G HC194D 1280x1024 LCD (VGA).
4.8.0-rc5 with patch boots without error.
drivers/gpu/drm/radeon/atombios_dp.c | 60 ---
drivers/gpu/drm/radeon/radeon_connectors.c | 46 +++---
drivers/gpu/drm/radeon/radeon_dp_mst.c |9 ++
drivers/gpu/drm/radeon/radeon_i2c.c|3
4 files changed, 73 insertions(+), 45 deletions(-)
Patch:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index cead089a..98b3c0e 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -232,6 +232,9 @@ void radeon_dp_aux_init(struct radeon_connector
*radeon_connector)
struct radeon_device *rdev = dev->dev_private;
int ret;
+if (!radeon_connector->ddc_bus)
+return;
+
radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
if (ASIC_IS_DCE5(rdev)) {
@@ -364,6 +367,9 @@ u8 radeon_dp_getsinktype(struct radeon_connector
*radeon_connector)
struct drm_device *dev = radeon_connector->base.dev;
struct radeon_device *rdev = dev->dev_private;
+if (!radeon_connector-&
Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
Hi Christian,
Thank you for the feedback.
On 08/09/16 08:14, Christian König wrote:
Am 07.09.2016 um 19:38 schrieb Mark Fortescue:
On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel
Oops because Connector 0 (LCD Panel interface) does not have DDC.
I'm not an expert on this, but that is really odd cause even LCD Panels
should have a DDC interface.
Ubuntu 16.04 LTS Kernel (4.4 series):
...
[ 8.262990] [drm] ib test on ring 5 succeeded
[ 8.288897] [drm] Radeon Display Connectors
[ 8.293175] [drm] Connector 0:
[ 8.296252] [drm] DP-1
Especially since the BIOS claims that this is a displayport connector
and there is no physical way to have a DP without an DDC as far as I know.
Please open a bug report on FDO and attach you BIOS image.
FDO ? I am not familiar with this. Please can you enlighten me.
I do not have a BIOS image so will need some assistance in understanding
what is required here and how I extract the BIOS information you are after.
On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
interface and DP-2 is a DVI interface (which I can connect to my monitor
if testing this is useful). There are no displayport connectors.
On industrial motherboards, I have noticed that it is not uncommon to
hard code the information for the LCD panel into the BIOS so no DDC is
required. In this case, there is no LCD panel connected to the interface
anyway.
See http://www.commell.com.tw/product/SBC/LV-683.HTM for more
information on the board. Looking at the web site, there is a BIOS image
available form Commell if that is of use.
Alex can probably take a look when he's back from vacation.
Regards,
Christian.
[ 8.298791] [drm] Encoders:
[ 8.301770] [drm] DFP1: INTERNAL_UNIPHY
[ 8.305973] [drm] Connector 1:
[ 8.309043] [drm] DP-2
[ 8.311598] [drm] HPD2
[ 8.314169] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448
0x644c 0x644c
[ 8.321609] [drm] Encoders:
[ 8.324589] [drm] DFP2: INTERNAL_UNIPHY
[ 8.328793] [drm] Connector 2:
[ 8.331856] [drm] VGA-1
[ 8.342947] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0
0x64e4 0x64e4
[ 8.350341] [drm] Encoders:
[ 8.353310] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 8.358195] BUG: unable to handle kernel NULL pointer dereference at
0409
[ 8.409733] [] radeon_dp_getsinktype+0x1a/0x30 [radeon]
[ 8.416805] PGD 0
[ 8.418841] Oops: [#1] SMP
...
This patch prevents Kernel failures due to a connector not having a
DDC interface by changing the code so that ddc_bus is always checked
before use.
The problem was first identified using the uBuntu MATE 14.04 LTS (3.16
series kernels) but not dealt with at that time. On attempting to
install uBuntu MATE 16.04 LTS (4.4 series kernels), it became clear
that using various workarounds to allow the issue to be ignored were
not viable so more effort was put in to sorting the issue resulting in
this patch. See https://bugs.launchpad.net/bugs/1587885 for more details.
Signed-off-by: Mark Fortescue
Tested-by: Mark Fortescue
---
Looks like Thunderbird may have made a mess of the patch when pasting
the contents into the mail message - my alternate mail client (pine)
also has strict line length handling and trashes non-MIME encoded
patches.
This may not be the correct approach to solving the issue but it is
clean in that it ensures that ddc_bus is never used when NULL
regardless of how the code ended up at the point of use.
If it helps with back porting, I have patches for the uBuntu 14.04 LTS
[3.13 series], uBuntu MATE 14.04 LTS [3.16 series] and uBuntu 16.04
LTS [4.4 series] kernels.
Test Hardware:
Commell LV-683 Mini-ITX with onboard AMD Dual-core G-T56N
4G Ram, 2x1TB Disk, HANNS-G HC194D 1280x1024 LCD (VGA).
4.8.0-rc5 with patch boots without error.
drivers/gpu/drm/radeon/atombios_dp.c | 60 ---
drivers/gpu/drm/radeon/radeon_connectors.c | 46 +++---
drivers/gpu/drm/radeon/radeon_dp_mst.c |9 ++
drivers/gpu/drm/radeon/radeon_i2c.c|3
4 files changed, 73 insertions(+), 45 deletions(-)
Patch:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index cead089a..98b3c0e 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -232,6 +232,9 @@ void radeon_dp_aux_init(struct radeon_connector
*radeon_connector)
struct radeon_device *rdev = dev->dev_private;
int ret;
+if (!radeon_connector->ddc_bus)
+return;
+
radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
if (ASIC_IS_DCE5(rdev)) {
@@ -364,6 +367,9 @@ u8 radeon_dp_getsinktype(struct radeon_connector
*radeon_connector)
struct drm_device *dev = radeon_connector->base.dev;
struct radeon_device *rdev = dev->dev_private;
+if (!radeon_connector->ddc_bus)
+return 0;
+
return radeon_dp_encoder_service(rdev
[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel Oops
because Connector 0 (LCD Panel interface) does not have DDC.
Ubuntu 16.04 LTS Kernel (4.4 series):
...
[ 8.262990] [drm] ib test on ring 5 succeeded
[ 8.288897] [drm] Radeon Display Connectors
[ 8.293175] [drm] Connector 0:
[ 8.296252] [drm] DP-1
[ 8.298791] [drm] Encoders:
[ 8.301770] [drm] DFP1: INTERNAL_UNIPHY
[ 8.305973] [drm] Connector 1:
[ 8.309043] [drm] DP-2
[ 8.311598] [drm] HPD2
[ 8.314169] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c
0x644c
[ 8.321609] [drm] Encoders:
[ 8.324589] [drm] DFP2: INTERNAL_UNIPHY
[ 8.328793] [drm] Connector 2:
[ 8.331856] [drm] VGA-1
[ 8.342947] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4
0x64e4
[ 8.350341] [drm] Encoders:
[ 8.353310] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 8.358195] BUG: unable to handle kernel NULL pointer dereference at
0409
[ 8.409733] [] radeon_dp_getsinktype+0x1a/0x30 [radeon]
[ 8.416805] PGD 0
[ 8.418841] Oops: [#1] SMP
...
This patch prevents Kernel failures due to a connector not having a DDC
interface by changing the code so that ddc_bus is always checked before use.
The problem was first identified using the uBuntu MATE 14.04 LTS (3.16
series kernels) but not dealt with at that time. On attempting to
install uBuntu MATE 16.04 LTS (4.4 series kernels), it became clear that
using various workarounds to allow the issue to be ignored were not
viable so more effort was put in to sorting the issue resulting in this
patch. See https://bugs.launchpad.net/bugs/1587885 for more details.
Signed-off-by: Mark Fortescue <m...@thurning-instruments.co.uk>
Tested-by: Mark Fortescue <m...@thurning-instruments.co.uk>
---
Looks like Thunderbird may have made a mess of the patch when pasting
the contents into the mail message - my alternate mail client (pine)
also has strict line length handling and trashes non-MIME encoded patches.
This may not be the correct approach to solving the issue but it is
clean in that it ensures that ddc_bus is never used when NULL regardless
of how the code ended up at the point of use.
If it helps with back porting, I have patches for the uBuntu 14.04 LTS
[3.13 series], uBuntu MATE 14.04 LTS [3.16 series] and uBuntu 16.04 LTS
[4.4 series] kernels.
Test Hardware:
Commell LV-683 Mini-ITX with onboard AMD Dual-core G-T56N
4G Ram, 2x1TB Disk, HANNS-G HC194D 1280x1024 LCD (VGA).
4.8.0-rc5 with patch boots without error.
drivers/gpu/drm/radeon/atombios_dp.c | 60 ---
drivers/gpu/drm/radeon/radeon_connectors.c | 46 +++---
drivers/gpu/drm/radeon/radeon_dp_mst.c |9 ++
drivers/gpu/drm/radeon/radeon_i2c.c|3
4 files changed, 73 insertions(+), 45 deletions(-)
Patch:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index cead089a..98b3c0e 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -232,6 +232,9 @@ void radeon_dp_aux_init(struct radeon_connector
*radeon_connector)
struct radeon_device *rdev = dev->dev_private;
int ret;
+ if (!radeon_connector->ddc_bus)
+ return;
+
radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
if (ASIC_IS_DCE5(rdev)) {
@@ -364,6 +367,9 @@ u8 radeon_dp_getsinktype(struct radeon_connector
*radeon_connector)
struct drm_device *dev = radeon_connector->base.dev;
struct radeon_device *rdev = dev->dev_private;
+ if (!radeon_connector->ddc_bus)
+ return 0;
+
return radeon_dp_encoder_service(rdev, ATOM_DP_ACTION_GET_SINK_TYPE, 0,
radeon_connector->ddc_bus->rec.i2c_id,
0);
}
@@ -376,6 +382,9 @@ static void radeon_dp_probe_oui(struct
radeon_connector *radeon_connector)
if (!(dig_connector->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
return;
+ if (!radeon_connector->ddc_bus)
+ return;
+
if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI,
buf, 3) == 3)
DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
buf[0], buf[1], buf[2]);
@@ -391,6 +400,9 @@ bool radeon_dp_getdpcd(struct radeon_connector
*radeon_connector)
u8 msg[DP_DPCD_SIZE];
int ret, i;
+ if (!radeon_connector->ddc_bus)
+ return false;
+
for (i = 0; i < 7; i++) {
ret = drm_dp_dpcd_read(_connector->ddc_bus->aux,
DP_DPCD_REV, msg,
DP_DPCD_SIZE);
@@ -428,24 +440,26 @@ int radeon_dp_get_panel_mode(struct drm_encoder
*encoder,
dig_connector = radeon_connector->con_priv;
- if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
-
[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel Oops
because Connector 0 (LCD Panel interface) does not have DDC.
Ubuntu 16.04 LTS Kernel (4.4 series):
...
[ 8.262990] [drm] ib test on ring 5 succeeded
[ 8.288897] [drm] Radeon Display Connectors
[ 8.293175] [drm] Connector 0:
[ 8.296252] [drm] DP-1
[ 8.298791] [drm] Encoders:
[ 8.301770] [drm] DFP1: INTERNAL_UNIPHY
[ 8.305973] [drm] Connector 1:
[ 8.309043] [drm] DP-2
[ 8.311598] [drm] HPD2
[ 8.314169] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c
0x644c
[ 8.321609] [drm] Encoders:
[ 8.324589] [drm] DFP2: INTERNAL_UNIPHY
[ 8.328793] [drm] Connector 2:
[ 8.331856] [drm] VGA-1
[ 8.342947] [drm] DDC: 0x64d8 0x64d8 0x64dc 0x64dc 0x64e0 0x64e0 0x64e4
0x64e4
[ 8.350341] [drm] Encoders:
[ 8.353310] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 8.358195] BUG: unable to handle kernel NULL pointer dereference at
0409
[ 8.409733] [] radeon_dp_getsinktype+0x1a/0x30 [radeon]
[ 8.416805] PGD 0
[ 8.418841] Oops: [#1] SMP
...
This patch prevents Kernel failures due to a connector not having a DDC
interface by changing the code so that ddc_bus is always checked before use.
The problem was first identified using the uBuntu MATE 14.04 LTS (3.16
series kernels) but not dealt with at that time. On attempting to
install uBuntu MATE 16.04 LTS (4.4 series kernels), it became clear that
using various workarounds to allow the issue to be ignored were not
viable so more effort was put in to sorting the issue resulting in this
patch. See https://bugs.launchpad.net/bugs/1587885 for more details.
Signed-off-by: Mark Fortescue
Tested-by: Mark Fortescue
---
Looks like Thunderbird may have made a mess of the patch when pasting
the contents into the mail message - my alternate mail client (pine)
also has strict line length handling and trashes non-MIME encoded patches.
This may not be the correct approach to solving the issue but it is
clean in that it ensures that ddc_bus is never used when NULL regardless
of how the code ended up at the point of use.
If it helps with back porting, I have patches for the uBuntu 14.04 LTS
[3.13 series], uBuntu MATE 14.04 LTS [3.16 series] and uBuntu 16.04 LTS
[4.4 series] kernels.
Test Hardware:
Commell LV-683 Mini-ITX with onboard AMD Dual-core G-T56N
4G Ram, 2x1TB Disk, HANNS-G HC194D 1280x1024 LCD (VGA).
4.8.0-rc5 with patch boots without error.
drivers/gpu/drm/radeon/atombios_dp.c | 60 ---
drivers/gpu/drm/radeon/radeon_connectors.c | 46 +++---
drivers/gpu/drm/radeon/radeon_dp_mst.c |9 ++
drivers/gpu/drm/radeon/radeon_i2c.c|3
4 files changed, 73 insertions(+), 45 deletions(-)
Patch:
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index cead089a..98b3c0e 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -232,6 +232,9 @@ void radeon_dp_aux_init(struct radeon_connector
*radeon_connector)
struct radeon_device *rdev = dev->dev_private;
int ret;
+ if (!radeon_connector->ddc_bus)
+ return;
+
radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
if (ASIC_IS_DCE5(rdev)) {
@@ -364,6 +367,9 @@ u8 radeon_dp_getsinktype(struct radeon_connector
*radeon_connector)
struct drm_device *dev = radeon_connector->base.dev;
struct radeon_device *rdev = dev->dev_private;
+ if (!radeon_connector->ddc_bus)
+ return 0;
+
return radeon_dp_encoder_service(rdev, ATOM_DP_ACTION_GET_SINK_TYPE, 0,
radeon_connector->ddc_bus->rec.i2c_id,
0);
}
@@ -376,6 +382,9 @@ static void radeon_dp_probe_oui(struct
radeon_connector *radeon_connector)
if (!(dig_connector->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
return;
+ if (!radeon_connector->ddc_bus)
+ return;
+
if (drm_dp_dpcd_read(_connector->ddc_bus->aux, DP_SINK_OUI,
buf, 3) == 3)
DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
buf[0], buf[1], buf[2]);
@@ -391,6 +400,9 @@ bool radeon_dp_getdpcd(struct radeon_connector
*radeon_connector)
u8 msg[DP_DPCD_SIZE];
int ret, i;
+ if (!radeon_connector->ddc_bus)
+ return false;
+
for (i = 0; i < 7; i++) {
ret = drm_dp_dpcd_read(_connector->ddc_bus->aux,
DP_DPCD_REV, msg,
DP_DPCD_SIZE);
@@ -428,24 +440,26 @@ int radeon_dp_get_panel_mode(struct drm_encoder
*encoder,
dig_connector = radeon_connector->con_priv;
- if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
- /* DP bridge chips */
- if (drm_dp_dpcd_readb(_connector->d
[PATCH] Re: [SPARC32] NULL pointer derefference
Hi David,
I have formulated a patch that prevents the update_mmu_cache from doing
enything if there is no context available. This apears to have no
immediate, undesirable side effects.
This worked better than the alternative of setting up a context to work with.
Can you for see any issues in doing this?
If not, can you check+apply the attached (un-mangled) patch.
diff -ruNpd linux-2.6/arch/sparc/mm/sun4c.c linux-test/arch/sparc/mm/sun4c.c
--- linux-2.6/arch/sparc/mm/sun4c.c 2007-07-30 03:19:15.0 +0100
+++ linux-test/arch/sparc/mm/sun4c.c2007-07-31 08:28:13.0 +0100
@@ -1999,6 +2029,9 @@ void sun4c_update_mmu_cache(struct vm_ar
unsigned long flags;
int pseg;
+ if (vma->vm_mm->context == NO_CONTEXT)
+ return;
+
local_irq_save(flags);
address &= PAGE_MASK;
if ((pseg = sun4c_get_segmap(address)) == invalid_segment) {
Regards
Mark Fortescue.From: Mark Fortescue <[EMAIL PROTECTED]>
This deals with a sun4c issue caused by commit
b6a2fea39318e43fee84fa7b0b90d68bed92d2ba:
mm: variable length argument support.
The new way the code works means that sun4c_update_mmu_cache gets called before
a context
has been selected, which results in invalid operation of the underling mm code.
Simply ignoring update requests when there is no valid context solves the
problem.
Signed-off-by Mark Fortescue <[EMAIL PROTECTED]>
---
This worked better than the alternative of setting up a context to work with.
I definatly need to spend some time writting up the sun4c MMU and how Linux
code uses it.
diff -ruNpd -x '.[a-z]*' linux-2.6/arch/sparc/mm/sun4c.c
linux-test/arch/sparc/mm/sun4c.c
--- linux-2.6/arch/sparc/mm/sun4c.c 2007-07-30 03:19:15.0 +0100
+++ linux-test/arch/sparc/mm/sun4c.c2007-07-31 08:28:13.0 +0100
@@ -1999,6 +2029,9 @@ void sun4c_update_mmu_cache(struct vm_ar
unsigned long flags;
int pseg;
+ if (vma->vm_mm->context == NO_CONTEXT)
+ return;
+
local_irq_save(flags);
address &= PAGE_MASK;
if ((pseg = sun4c_get_segmap(address)) == invalid_segment) {
[PATCH] Re: [SPARC32] NULL pointer derefference
Hi David,
I have formulated a patch that prevents the update_mmu_cache from doing
enything if there is no context available. This apears to have no
immediate, undesirable side effects.
This worked better than the alternative of setting up a context to work with.
Can you for see any issues in doing this?
If not, can you check+apply the attached (un-mangled) patch.
diff -ruNpd linux-2.6/arch/sparc/mm/sun4c.c linux-test/arch/sparc/mm/sun4c.c
--- linux-2.6/arch/sparc/mm/sun4c.c 2007-07-30 03:19:15.0 +0100
+++ linux-test/arch/sparc/mm/sun4c.c2007-07-31 08:28:13.0 +0100
@@ -1999,6 +2029,9 @@ void sun4c_update_mmu_cache(struct vm_ar
unsigned long flags;
int pseg;
+ if (vma-vm_mm-context == NO_CONTEXT)
+ return;
+
local_irq_save(flags);
address = PAGE_MASK;
if ((pseg = sun4c_get_segmap(address)) == invalid_segment) {
Regards
Mark Fortescue.From: Mark Fortescue [EMAIL PROTECTED]
This deals with a sun4c issue caused by commit
b6a2fea39318e43fee84fa7b0b90d68bed92d2ba:
mm: variable length argument support.
The new way the code works means that sun4c_update_mmu_cache gets called before
a context
has been selected, which results in invalid operation of the underling mm code.
Simply ignoring update requests when there is no valid context solves the
problem.
Signed-off-by Mark Fortescue [EMAIL PROTECTED]
---
This worked better than the alternative of setting up a context to work with.
I definatly need to spend some time writting up the sun4c MMU and how Linux
code uses it.
diff -ruNpd -x '.[a-z]*' linux-2.6/arch/sparc/mm/sun4c.c
linux-test/arch/sparc/mm/sun4c.c
--- linux-2.6/arch/sparc/mm/sun4c.c 2007-07-30 03:19:15.0 +0100
+++ linux-test/arch/sparc/mm/sun4c.c2007-07-31 08:28:13.0 +0100
@@ -1999,6 +2029,9 @@ void sun4c_update_mmu_cache(struct vm_ar
unsigned long flags;
int pseg;
+ if (vma-vm_mm-context == NO_CONTEXT)
+ return;
+
local_irq_save(flags);
address = PAGE_MASK;
if ((pseg = sun4c_get_segmap(address)) == invalid_segment) {
Re: [SPARC32] NULL pointer derefference
Hi David, One possible issue is sequencing, perhaps the stack argument copy is occuring before the new context is setup properly on sun4c. I think it is somthing related to this but too much has changed for me to work out what is going on. At present, I don't have a good enough understanding of the virtual memory system and how it interracts with the sun4c mmu. The original code did a job lot of pte stuf in install_arg_page. The new code seems to replace this using get_user_pages but I have not worked out how get_user_pages gets to the point at which it allocated pte's i.e. maps the stack memory it is about to put the arguments into. Another issue might be the new flush_cache_page() call in this new code in fs/exec.c, there are now cases where flush_cache_page() will be called on kernel addresses, and sun4c's implementation might not like that at all. I commented out the flush_cache_page callmade in the new code. This had no effect on the problem. Other tests have shown it is breaking earlier than this. I am going to try to narrow down exactly where the pointer gets messed up as this should help. Regards Mark Fortescue. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SPARC32] NULL pointer derefference
Hi David,
Thanks for the comments.
On Sun, 29 Jul 2007, David Miller wrote:
From: Mark Fortescue <[EMAIL PROTECTED]>
Date: Mon, 30 Jul 2007 03:18:42 +0100 (BST)
Unfortunatly Sparc32 sun4c low level memory management apears to be
incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
mm: variable length argument support.
For some reason, this commit corrupts the memory used by the low level
context/pte handling ring buffers in arch/sparc/mm/sun4c (in
add_ring_ordered, head->next becomes set to a NULL pointer).
I had a quick look at http://www.linux-mm.org to see if there were any
diagrams that show what is going on in the memory management systems, to
see if there was something that I could use to help me work out what is
going on, but I could not see any.
One possible issue is sequencing, perhaps the stack argument copy
is occuring before the new context is setup properly on sun4c.
I will see if I can generate some debug code to check out this posibility.
Another issue might be the new flush_cache_page() call in this
new code in fs/exec.c, there are now cases where flush_cache_page()
will be called on kernel addresses, and sun4c's implementation might
not like that at all.
I backed the commit out of my latest git pull (app 2am this morning) and I
end up with a working kernel so this confirms that is is somthing
specific to this patch.
I will try adding in a flush_cache_page() at an appropriate point on the
pre-commit version of the code to see if that makes a mess of things.
Regards
Mark Fortescue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [SPARC32] NULL pointer derefference
Hi David, Thanks for the comments. On Sun, 29 Jul 2007, David Miller wrote: From: Mark Fortescue [EMAIL PROTECTED] Date: Mon, 30 Jul 2007 03:18:42 +0100 (BST) Unfortunatly Sparc32 sun4c low level memory management apears to be incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba mm: variable length argument support. For some reason, this commit corrupts the memory used by the low level context/pte handling ring buffers in arch/sparc/mm/sun4c (in add_ring_ordered, head-next becomes set to a NULL pointer). I had a quick look at http://www.linux-mm.org to see if there were any diagrams that show what is going on in the memory management systems, to see if there was something that I could use to help me work out what is going on, but I could not see any. One possible issue is sequencing, perhaps the stack argument copy is occuring before the new context is setup properly on sun4c. I will see if I can generate some debug code to check out this posibility. Another issue might be the new flush_cache_page() call in this new code in fs/exec.c, there are now cases where flush_cache_page() will be called on kernel addresses, and sun4c's implementation might not like that at all. I backed the commit out of my latest git pull (app 2am this morning) and I end up with a working kernel so this confirms that is is somthing specific to this patch. I will try adding in a flush_cache_page() at an appropriate point on the pre-commit version of the code to see if that makes a mess of things. Regards Mark Fortescue. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SPARC32] NULL pointer derefference
Hi David, One possible issue is sequencing, perhaps the stack argument copy is occuring before the new context is setup properly on sun4c. I think it is somthing related to this but too much has changed for me to work out what is going on. At present, I don't have a good enough understanding of the virtual memory system and how it interracts with the sun4c mmu. The original code did a job lot of pte stuf in install_arg_page. The new code seems to replace this using get_user_pages but I have not worked out how get_user_pages gets to the point at which it allocated pte's i.e. maps the stack memory it is about to put the arguments into. Another issue might be the new flush_cache_page() call in this new code in fs/exec.c, there are now cases where flush_cache_page() will be called on kernel addresses, and sun4c's implementation might not like that at all. I commented out the flush_cache_page callmade in the new code. This had no effect on the problem. Other tests have shown it is breaking earlier than this. I am going to try to narrow down exactly where the pointer gets messed up as this should help. Regards Mark Fortescue. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SPARC32] NULL pointer derefference
Hi All,
Unfortunatly Sparc32 sun4c low level memory management apears to be
incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
mm: variable length argument support.
For some reason, this commit corrupts the memory used by the low level
context/pte handling ring buffers in arch/sparc/mm/sun4c (in
add_ring_ordered, head->next becomes set to a NULL pointer).
I had a quick look at http://www.linux-mm.org to see if there were any
diagrams that show what is going on in the memory management systems, to
see if there was something that I could use to help me work out what is
going on, but I could not see any.
Can any one help?
Regards
Mark Fortescue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)
On Sun, 29 Jul 2007, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 07:26:29PM +0100, Mark Fortescue wrote: ... I am going to try to cherry pick a set of commits to see if I can't get a better idear of where the memory corruption on sun4c is coming from. Build problems sue to the DMA changes make git bisecting un-usable untill I have found out which patches fix the DMA build issues. You have any known-good kernel? Boot back into this kernel for bisecting and compiling the kernels for bisecting there. As I said, bisecting does not work if you can't build the kernel because of un-defined symbols spanning most of the revisions you are interested in. I have isolated the revisions that do not build so I should be able to cerry pick a commit/commits that fixes the build issues. Once done, I will be able to investigate the original issue. If it were practical to do a build test on all supported platforms before submitting patches then this would not be so much of an issue but ... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)
On Sun, 29 Jul 2007, Krzysztof Helt wrote: On Sun, 29 Jul 2007 00:21:06 +0100 (BST) Mark Fortescue <[EMAIL PROTECTED]> wrote: Hi Krzysztof, There have been lots of changes to the DMA system (git bisect is not viable form my working 2.6.22 kernel as the dma changes kill the build for over half the posible commits to check). It could be a side effect of these changes. It is not DMA I suppose. It does not happen in any specific place. It is easy to trigger by loading and unloading the sunlance module, but it hangs linux in other places (init process, console login). It happens only in SMP. If it happens in the sunlance module it happens in sparc_lance_probe_one() (in probing function). I thought it is due to openprom accesses so I commented them out (and put hardcoded values there). No real change. It is always in the probe_one method before any DMA is started. Sometimes it drops me to the prom prompt. I am not very experienced so I was able only to find (ctrace) that the prompt was called in the method spwin_bad_ustack_from_kernel() which got there from mna_handler (misaligned access) through kernel_unaligned_trap(). I don't know which function triggered the unaligned access. The %o register values sent to the kernel_unaligned_trap() are outside addresses from System.map and outside addresses of loaded (or just loaded the sunlance) modules. This is where I need help. How can I find where the misaligned access happened? The is a memory corruption issue on Sparc32 - sun4c (I am going to try and track it done over the next few days). It sounds like it may affect more than just sun4c issue. Try going back to v2.6.22 and then appling f61698e6489f229f9fcfe29e68f228389a772993 - memset.S error, 196bffa5dc3181897bd32e41415ec0db8dbab5e7 - entry.S delay loops, f3c681c028846bd5d39f563909409832a295ca69 - Serial Console Locking (My last working kernel is v2.6.22 Commit eb6bf6bfb580afaf1e1a1d30cba17a078530cf4 with the first of the above two patches applied and some additional ones that fix verious sun partition/UFS filing sustem issues). I am going to try to cherry pick a set of commits to see if I can't get a better idear of where the memory corruption on sun4c is coming from. Build problems sue to the DMA changes make git bisecting un-usable untill I have found out which patches fix the DMA build issues. Regards, Krzysztof - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)
On Sun, 29 Jul 2007, Krzysztof Helt wrote: On Sun, 29 Jul 2007 00:21:06 +0100 (BST) Mark Fortescue [EMAIL PROTECTED] wrote: Hi Krzysztof, There have been lots of changes to the DMA system (git bisect is not viable form my working 2.6.22 kernel as the dma changes kill the build for over half the posible commits to check). It could be a side effect of these changes. It is not DMA I suppose. It does not happen in any specific place. It is easy to trigger by loading and unloading the sunlance module, but it hangs linux in other places (init process, console login). It happens only in SMP. If it happens in the sunlance module it happens in sparc_lance_probe_one() (in probing function). I thought it is due to openprom accesses so I commented them out (and put hardcoded values there). No real change. It is always in the probe_one method before any DMA is started. Sometimes it drops me to the prom prompt. I am not very experienced so I was able only to find (ctrace) that the prompt was called in the method spwin_bad_ustack_from_kernel() which got there from mna_handler (misaligned access) through kernel_unaligned_trap(). I don't know which function triggered the unaligned access. The %o register values sent to the kernel_unaligned_trap() are outside addresses from System.map and outside addresses of loaded (or just loaded the sunlance) modules. This is where I need help. How can I find where the misaligned access happened? The is a memory corruption issue on Sparc32 - sun4c (I am going to try and track it done over the next few days). It sounds like it may affect more than just sun4c issue. Try going back to v2.6.22 and then appling f61698e6489f229f9fcfe29e68f228389a772993 - memset.S error, 196bffa5dc3181897bd32e41415ec0db8dbab5e7 - entry.S delay loops, f3c681c028846bd5d39f563909409832a295ca69 - Serial Console Locking (My last working kernel is v2.6.22 Commit eb6bf6bfb580afaf1e1a1d30cba17a078530cf4 with the first of the above two patches applied and some additional ones that fix verious sun partition/UFS filing sustem issues). I am going to try to cherry pick a set of commits to see if I can't get a better idear of where the memory corruption on sun4c is coming from. Build problems sue to the DMA changes make git bisecting un-usable untill I have found out which patches fix the DMA build issues. Regards, Krzysztof - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)
On Sun, 29 Jul 2007, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 07:26:29PM +0100, Mark Fortescue wrote: ... I am going to try to cherry pick a set of commits to see if I can't get a better idear of where the memory corruption on sun4c is coming from. Build problems sue to the DMA changes make git bisecting un-usable untill I have found out which patches fix the DMA build issues. You have any known-good kernel? Boot back into this kernel for bisecting and compiling the kernels for bisecting there. As I said, bisecting does not work if you can't build the kernel because of un-defined symbols spanning most of the revisions you are interested in. I have isolated the revisions that do not build so I should be able to cerry pick a commit/commits that fixes the build issues. Once done, I will be able to investigate the original issue. If it were practical to do a build test on all supported platforms before submitting patches then this would not be so much of an issue but ... cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SPARC32] NULL pointer derefference
Hi All, Unfortunatly Sparc32 sun4c low level memory management apears to be incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba mm: variable length argument support. For some reason, this commit corrupts the memory used by the low level context/pte handling ring buffers in arch/sparc/mm/sun4c (in add_ring_ordered, head-next becomes set to a NULL pointer). I had a quick look at http://www.linux-mm.org to see if there were any diagrams that show what is going on in the memory management systems, to see if there was something that I could use to help me work out what is going on, but I could not see any. Can any one help? Regards Mark Fortescue. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add in SunOS 4.1.x compatible mode for UFS
Hi Evgeniy,
On Wed, 25 Jul 2007, Evgeniy Dushistov wrote:
Looks good.
Just a few minor things:
On Wed, Jul 25, 2007 at 06:27:46PM +0100, Mark Fortescue wrote:
Macros have been put in to alow suport for the old static table Cylinder
Groups
but this implementation does not use them yet.
But why add them to patch?
Two reasons, one to remind me that more work is needed and two so I do not
loose them before I get around to writing any code that uses them.
+ /* Sort out mod used on SunOS 4.1.3 for fs_state */
+ uspi->s_postblformat = fs32_to_cpu(sb, usb3->fs_postblformat);
+ if (((flags & UFS_ST_MASK) == UFS_ST_SUNOS) &&
+ (uspi->s_postblformat != UFS_42POSTBLFMT))
+ {
+ flags &= ~UFS_ST_MASK;
+ flags |= UFS_ST_SUN;
+ }
+
Documentation/CodingStyle: if () {
Opps. I have been looking at code too long. I normally use/prefer a
different codding standard. This one slipped through.
switch (UFS_SB(sb)->s_flags & UFS_ST_MASK) {
+ case UFS_ST_SUNOS:
+ if (fs32_to_cpu(sb, usb3->fs_postblformat == UFS_42POSTBLFMT))
Really should be so?
May be you mean:
fs32_to_cpu(sb, usb3->fs_postblformat) == UFS_42POSTBLFMT ?
^
Opps. Yes, the bracket does need moving.
--
/Evgeniy
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please find attached a patch with corrected coding stype and bracket
location.
Regards
Mark Fortescue.From: Mark Fortescue <[EMAIL PROTECTED]>
Add in support for SunOS 4.1.x flavor of BSD 4.2 UFS filing system
Macros have been put in to alow suport for the old static table Cylinder Groups
but this implementation does not use them yet.
This also fixes Solaris UFS filing system access by disabling fast symbolic
links as Sun's version of UFS does not support on-disk fast symbolic links.
Signed-off-by: Mark Fortescue <[EMAIL PROTECTED]>
---
Tested by:
Ppartitioning a new disk using SunOS 4.1.1, creating a UFS filing system on
one of the partitions and writing some files to the filing system.
Using Linux-2.6.22 (patched) to read the files and then write a shed load of
files to the UFS partition.
Using SunOS 4.1.1 to verify the filing system is OK and to check the files.
The test host is a sun4c SS1 Clone.
diff -ruNpd -x .git -x .gitignore -x .mailmap linux-2.6/fs/ufs/super.c
linux-test/fs/ufs/super.c
--- linux-2.6/fs/ufs/super.c2007-07-25 14:46:15.0 +0100
+++ linux-test/fs/ufs/super.c 2007-07-25 14:26:48.0 +0100
@@ -285,7 +285,7 @@ void ufs_warning (struct super_block * s
}
enum {
- Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_44bsd,
+ Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_sunos,
Opt_type_44bsd,
Opt_type_ufs2, Opt_type_hp, Opt_type_nextstepcd, Opt_type_nextstep,
Opt_type_openstep, Opt_onerror_panic, Opt_onerror_lock,
Opt_onerror_umount, Opt_onerror_repair, Opt_err
@@ -295,6 +295,7 @@ static match_table_t tokens = {
{Opt_type_old, "ufstype=old"},
{Opt_type_sunx86, "ufstype=sunx86"},
{Opt_type_sun, "ufstype=sun"},
+ {Opt_type_sunos, "ufstype=sunos"},
{Opt_type_44bsd, "ufstype=44bsd"},
{Opt_type_ufs2, "ufstype=ufs2"},
{Opt_type_ufs2, "ufstype=5xbsd"},
@@ -338,6 +339,10 @@ static int ufs_parse_options (char * opt
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_SUN);
break;
+ case Opt_type_sunos:
+ ufs_clear_opt (*mount_options, UFSTYPE);
+ ufs_set_opt (*mount_options, UFSTYPE_SUNOS);
+ break;
case Opt_type_44bsd:
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_44BSD);
@@ -654,7 +659,7 @@ static int ufs_fill_super(struct super_b
}
sbi->s_uspi = uspi =
- kmalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
+ kzalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
if (!uspi)
goto failed;
uspi->s_dirblksize = UFS_SECTOR_SIZE;
@@ -691,10 +696,21 @@ static int ufs_fill_super(struct super_b
uspi->s_fshift = 10;
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
- uspi->s_maxsymlinklen = 56;
+ uspi->s_maxsymlinklen = 0; /* Not supported on disk */
flags |= UFS_DE_OLD | UFS_UID_EFT | UFS_ST_SUN | UFS_CG_SUN;
break;
+ case UFS_MOUNT
[PATCH] Add in SunOS 4.1.x compatible mode for UFS
Add in support for SunOS 4.1.x flavor of BSD 4.2 UFS filing system
Macros have been put in to alow suport for the old static table Cylinder Groups
but this implementation does not use them yet.
This also fixes Solaris UFS filing system access by disabling fast symbolic
links as this does not apear to be compatible with Solaris UFS.
Tested by:
Ppartitioning a new disk using SunOS 4.1.1, creating a UFS filing system on
one of the partitions and writing some files to the filing system.
Using Linux-2.6.22 (patched) to read the files and then write a shed load of
files to the UFS partition.
Using SunOS 4.1.1 to verify the filing system is OK and to check the files.
The test host is a sun4c SS1 Clone.
The patch has been attached to prevent it getting mangled.
Regards
Mark Fortescue.From: Mark Fortescue <[EMAIL PROTECTED]>
Add in support for SunOS 4.1.x flavor of BSD 4.2 UFS filing system
Macros have been put in to alow suport for the old static table Cylinder Groups
but this implementation does not use them yet.
This also fixes Solaris UFS filing system access by disabling fast symbolic
links as Sun's version of UFS does not support on-disk fast symbolic links.
Signed-off-by: Mark Fortescue <[EMAIL PROTECTED]>
---
Tested by:
Ppartitioning a new disk using SunOS 4.1.1, creating a UFS filing system on
one of the partitions and writing some files to the filing system.
Using Linux-2.6.22 (patched) to read the files and then write a shed load of
files to the UFS partition.
Using SunOS 4.1.1 to verify the filing system is OK and to check the files.
The test host is a sun4c SS1 Clone.
diff -ruNpd -x .git -x .gitignore -x .mailmap linux-2.6/fs/ufs/super.c
linux-test/fs/ufs/super.c
--- linux-2.6/fs/ufs/super.c2007-07-25 14:46:15.0 +0100
+++ linux-test/fs/ufs/super.c 2007-07-25 14:26:48.0 +0100
@@ -285,7 +285,7 @@ void ufs_warning (struct super_block * s
}
enum {
- Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_44bsd,
+ Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_sunos,
Opt_type_44bsd,
Opt_type_ufs2, Opt_type_hp, Opt_type_nextstepcd, Opt_type_nextstep,
Opt_type_openstep, Opt_onerror_panic, Opt_onerror_lock,
Opt_onerror_umount, Opt_onerror_repair, Opt_err
@@ -295,6 +295,7 @@ static match_table_t tokens = {
{Opt_type_old, "ufstype=old"},
{Opt_type_sunx86, "ufstype=sunx86"},
{Opt_type_sun, "ufstype=sun"},
+ {Opt_type_sunos, "ufstype=sunos"},
{Opt_type_44bsd, "ufstype=44bsd"},
{Opt_type_ufs2, "ufstype=ufs2"},
{Opt_type_ufs2, "ufstype=5xbsd"},
@@ -338,6 +339,10 @@ static int ufs_parse_options (char * opt
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_SUN);
break;
+ case Opt_type_sunos:
+ ufs_clear_opt (*mount_options, UFSTYPE);
+ ufs_set_opt (*mount_options, UFSTYPE_SUNOS);
+ break;
case Opt_type_44bsd:
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_44BSD);
@@ -654,7 +659,7 @@ static int ufs_fill_super(struct super_b
}
sbi->s_uspi = uspi =
- kmalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
+ kzalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
if (!uspi)
goto failed;
uspi->s_dirblksize = UFS_SECTOR_SIZE;
@@ -691,10 +696,21 @@ static int ufs_fill_super(struct super_b
uspi->s_fshift = 10;
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
- uspi->s_maxsymlinklen = 56;
+ uspi->s_maxsymlinklen = 0; /* Not supported on disk */
flags |= UFS_DE_OLD | UFS_UID_EFT | UFS_ST_SUN | UFS_CG_SUN;
break;
+ case UFS_MOUNT_UFSTYPE_SUNOS:
+ UFSD(("ufstype=sunos\n"))
+ uspi->s_fsize = block_size = 1024;
+ uspi->s_fmask = ~(1024 - 1);
+ uspi->s_fshift = 10;
+ uspi->s_sbsize = super_block_size = 2048;
+ uspi->s_sbbase = 0;
+ uspi->s_maxsymlinklen = 0; /* Not supported on disk */
+ flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_SUNOS | UFS_CG_SUN;
+ break;
+
case UFS_MOUNT_UFSTYPE_SUNx86:
UFSD("ufstype=sunx86\n");
uspi->s_fsize = block_size = 1024;
@@ -702,7 +718,7 @@ static int ufs_fill_super(struct super_b
uspi->s_fshift = 10;
uspi->s_sbsize = super_block_size = 2048;
uspi->s_sbbase = 0;
- uspi->s_maxsymlinklen
[PATCH] Add in SunOS 4.1.x compatible mode for UFS
Add in support for SunOS 4.1.x flavor of BSD 4.2 UFS filing system
Macros have been put in to alow suport for the old static table Cylinder Groups
but this implementation does not use them yet.
This also fixes Solaris UFS filing system access by disabling fast symbolic
links as this does not apear to be compatible with Solaris UFS.
Tested by:
Ppartitioning a new disk using SunOS 4.1.1, creating a UFS filing system on
one of the partitions and writing some files to the filing system.
Using Linux-2.6.22 (patched) to read the files and then write a shed load of
files to the UFS partition.
Using SunOS 4.1.1 to verify the filing system is OK and to check the files.
The test host is a sun4c SS1 Clone.
The patch has been attached to prevent it getting mangled.
Regards
Mark Fortescue.From: Mark Fortescue [EMAIL PROTECTED]
Add in support for SunOS 4.1.x flavor of BSD 4.2 UFS filing system
Macros have been put in to alow suport for the old static table Cylinder Groups
but this implementation does not use them yet.
This also fixes Solaris UFS filing system access by disabling fast symbolic
links as Sun's version of UFS does not support on-disk fast symbolic links.
Signed-off-by: Mark Fortescue [EMAIL PROTECTED]
---
Tested by:
Ppartitioning a new disk using SunOS 4.1.1, creating a UFS filing system on
one of the partitions and writing some files to the filing system.
Using Linux-2.6.22 (patched) to read the files and then write a shed load of
files to the UFS partition.
Using SunOS 4.1.1 to verify the filing system is OK and to check the files.
The test host is a sun4c SS1 Clone.
diff -ruNpd -x .git -x .gitignore -x .mailmap linux-2.6/fs/ufs/super.c
linux-test/fs/ufs/super.c
--- linux-2.6/fs/ufs/super.c2007-07-25 14:46:15.0 +0100
+++ linux-test/fs/ufs/super.c 2007-07-25 14:26:48.0 +0100
@@ -285,7 +285,7 @@ void ufs_warning (struct super_block * s
}
enum {
- Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_44bsd,
+ Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_sunos,
Opt_type_44bsd,
Opt_type_ufs2, Opt_type_hp, Opt_type_nextstepcd, Opt_type_nextstep,
Opt_type_openstep, Opt_onerror_panic, Opt_onerror_lock,
Opt_onerror_umount, Opt_onerror_repair, Opt_err
@@ -295,6 +295,7 @@ static match_table_t tokens = {
{Opt_type_old, ufstype=old},
{Opt_type_sunx86, ufstype=sunx86},
{Opt_type_sun, ufstype=sun},
+ {Opt_type_sunos, ufstype=sunos},
{Opt_type_44bsd, ufstype=44bsd},
{Opt_type_ufs2, ufstype=ufs2},
{Opt_type_ufs2, ufstype=5xbsd},
@@ -338,6 +339,10 @@ static int ufs_parse_options (char * opt
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_SUN);
break;
+ case Opt_type_sunos:
+ ufs_clear_opt (*mount_options, UFSTYPE);
+ ufs_set_opt (*mount_options, UFSTYPE_SUNOS);
+ break;
case Opt_type_44bsd:
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_44BSD);
@@ -654,7 +659,7 @@ static int ufs_fill_super(struct super_b
}
sbi-s_uspi = uspi =
- kmalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
+ kzalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
if (!uspi)
goto failed;
uspi-s_dirblksize = UFS_SECTOR_SIZE;
@@ -691,10 +696,21 @@ static int ufs_fill_super(struct super_b
uspi-s_fshift = 10;
uspi-s_sbsize = super_block_size = 2048;
uspi-s_sbbase = 0;
- uspi-s_maxsymlinklen = 56;
+ uspi-s_maxsymlinklen = 0; /* Not supported on disk */
flags |= UFS_DE_OLD | UFS_UID_EFT | UFS_ST_SUN | UFS_CG_SUN;
break;
+ case UFS_MOUNT_UFSTYPE_SUNOS:
+ UFSD((ufstype=sunos\n))
+ uspi-s_fsize = block_size = 1024;
+ uspi-s_fmask = ~(1024 - 1);
+ uspi-s_fshift = 10;
+ uspi-s_sbsize = super_block_size = 2048;
+ uspi-s_sbbase = 0;
+ uspi-s_maxsymlinklen = 0; /* Not supported on disk */
+ flags |= UFS_DE_OLD | UFS_UID_OLD | UFS_ST_SUNOS | UFS_CG_SUN;
+ break;
+
case UFS_MOUNT_UFSTYPE_SUNx86:
UFSD(ufstype=sunx86\n);
uspi-s_fsize = block_size = 1024;
@@ -702,7 +718,7 @@ static int ufs_fill_super(struct super_b
uspi-s_fshift = 10;
uspi-s_sbsize = super_block_size = 2048;
uspi-s_sbbase = 0;
- uspi-s_maxsymlinklen = 56;
+ uspi-s_maxsymlinklen = 0; /* Not supported on disk */
flags |= UFS_DE_OLD | UFS_UID_EFT | UFS_ST_SUNx86 | UFS_CG_SUN;
break;
@@ -893,6 +909,15
Re: [PATCH] Add in SunOS 4.1.x compatible mode for UFS
Hi Evgeniy,
On Wed, 25 Jul 2007, Evgeniy Dushistov wrote:
Looks good.
Just a few minor things:
On Wed, Jul 25, 2007 at 06:27:46PM +0100, Mark Fortescue wrote:
Macros have been put in to alow suport for the old static table Cylinder
Groups
but this implementation does not use them yet.
But why add them to patch?
Two reasons, one to remind me that more work is needed and two so I do not
loose them before I get around to writing any code that uses them.
+ /* Sort out mod used on SunOS 4.1.3 for fs_state */
+ uspi-s_postblformat = fs32_to_cpu(sb, usb3-fs_postblformat);
+ if (((flags UFS_ST_MASK) == UFS_ST_SUNOS)
+ (uspi-s_postblformat != UFS_42POSTBLFMT))
+ {
+ flags = ~UFS_ST_MASK;
+ flags |= UFS_ST_SUN;
+ }
+
Documentation/CodingStyle: if () {
Opps. I have been looking at code too long. I normally use/prefer a
different codding standard. This one slipped through.
switch (UFS_SB(sb)-s_flags UFS_ST_MASK) {
+ case UFS_ST_SUNOS:
+ if (fs32_to_cpu(sb, usb3-fs_postblformat == UFS_42POSTBLFMT))
Really should be so?
May be you mean:
fs32_to_cpu(sb, usb3-fs_postblformat) == UFS_42POSTBLFMT ?
^
Opps. Yes, the bracket does need moving.
--
/Evgeniy
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please find attached a patch with corrected coding stype and bracket
location.
Regards
Mark Fortescue.From: Mark Fortescue [EMAIL PROTECTED]
Add in support for SunOS 4.1.x flavor of BSD 4.2 UFS filing system
Macros have been put in to alow suport for the old static table Cylinder Groups
but this implementation does not use them yet.
This also fixes Solaris UFS filing system access by disabling fast symbolic
links as Sun's version of UFS does not support on-disk fast symbolic links.
Signed-off-by: Mark Fortescue [EMAIL PROTECTED]
---
Tested by:
Ppartitioning a new disk using SunOS 4.1.1, creating a UFS filing system on
one of the partitions and writing some files to the filing system.
Using Linux-2.6.22 (patched) to read the files and then write a shed load of
files to the UFS partition.
Using SunOS 4.1.1 to verify the filing system is OK and to check the files.
The test host is a sun4c SS1 Clone.
diff -ruNpd -x .git -x .gitignore -x .mailmap linux-2.6/fs/ufs/super.c
linux-test/fs/ufs/super.c
--- linux-2.6/fs/ufs/super.c2007-07-25 14:46:15.0 +0100
+++ linux-test/fs/ufs/super.c 2007-07-25 14:26:48.0 +0100
@@ -285,7 +285,7 @@ void ufs_warning (struct super_block * s
}
enum {
- Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_44bsd,
+ Opt_type_old, Opt_type_sunx86, Opt_type_sun, Opt_type_sunos,
Opt_type_44bsd,
Opt_type_ufs2, Opt_type_hp, Opt_type_nextstepcd, Opt_type_nextstep,
Opt_type_openstep, Opt_onerror_panic, Opt_onerror_lock,
Opt_onerror_umount, Opt_onerror_repair, Opt_err
@@ -295,6 +295,7 @@ static match_table_t tokens = {
{Opt_type_old, ufstype=old},
{Opt_type_sunx86, ufstype=sunx86},
{Opt_type_sun, ufstype=sun},
+ {Opt_type_sunos, ufstype=sunos},
{Opt_type_44bsd, ufstype=44bsd},
{Opt_type_ufs2, ufstype=ufs2},
{Opt_type_ufs2, ufstype=5xbsd},
@@ -338,6 +339,10 @@ static int ufs_parse_options (char * opt
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_SUN);
break;
+ case Opt_type_sunos:
+ ufs_clear_opt (*mount_options, UFSTYPE);
+ ufs_set_opt (*mount_options, UFSTYPE_SUNOS);
+ break;
case Opt_type_44bsd:
ufs_clear_opt (*mount_options, UFSTYPE);
ufs_set_opt (*mount_options, UFSTYPE_44BSD);
@@ -654,7 +659,7 @@ static int ufs_fill_super(struct super_b
}
sbi-s_uspi = uspi =
- kmalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
+ kzalloc (sizeof(struct ufs_sb_private_info), GFP_KERNEL);
if (!uspi)
goto failed;
uspi-s_dirblksize = UFS_SECTOR_SIZE;
@@ -691,10 +696,21 @@ static int ufs_fill_super(struct super_b
uspi-s_fshift = 10;
uspi-s_sbsize = super_block_size = 2048;
uspi-s_sbbase = 0;
- uspi-s_maxsymlinklen = 56;
+ uspi-s_maxsymlinklen = 0; /* Not supported on disk */
flags |= UFS_DE_OLD | UFS_UID_EFT | UFS_ST_SUN | UFS_CG_SUN;
break;
+ case UFS_MOUNT_UFSTYPE_SUNOS:
+ UFSD((ufstype=sunos\n))
+ uspi-s_fsize = block_size = 1024;
+ uspi-s_fmask = ~(1024 - 1);
+ uspi-s_fshift = 10
Re: [PATCH] Mark sparc and sparc64 as not having virt_to_bus
Hi All,
Currently, sun4c (and sun4m) do NOT support the FDC driver as a module.
I did look at it but decided there were better issues to resolve at the
time.
A fix for this issue would either envolve a lot of work moving the low
level assembly interrupt handler from arch/sparc/kernel/entry.S to the
floppy driver module, or the exporting of a number of variables and
functions used by the handler so that they can be picked up by the floppy
driver module.
Moving the low level handeler would be better from the point of view of
modular code.
Regards
Mark Fortescue.
On Wed, 18 Jul 2007, Stephen Rothwell wrote:
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/sparc/Kconfig |3 +++
arch/sparc64/Kconfig |3 +++
include/asm-sparc64/io.h |5 -
3 files changed, 6 insertions(+), 5 deletions(-)
This is part of a rash attempt to make allmodconfig builds work for sparc
and sparc64 :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 73df711..603d83a 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -21,6 +21,9 @@ config GENERIC_ISA_DMA
bool
default y
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+
source "init/Kconfig"
menu "General machine setup"
diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
index b84b6af..df6ee71 100644
--- a/arch/sparc64/Kconfig
+++ b/arch/sparc64/Kconfig
@@ -62,6 +62,9 @@ config AUDIT_ARCH
bool
default y
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+
choice
prompt "Kernel page size"
default SPARC64_PAGE_SIZE_8KB
diff --git a/include/asm-sparc64/io.h b/include/asm-sparc64/io.h
index ad595b6..9565a89 100644
--- a/include/asm-sparc64/io.h
+++ b/include/asm-sparc64/io.h
@@ -14,11 +14,6 @@
#define __SLOW_DOWN_IO do { } while (0)
#define SLOW_DOWN_IOdo { } while (0)
-extern unsigned long virt_to_bus_not_defined_use_pci_map(volatile void *addr);
-#define virt_to_bus virt_to_bus_not_defined_use_pci_map
-extern unsigned long bus_to_virt_not_defined_use_pci_map(volatile void *addr);
-#define bus_to_virt bus_to_virt_not_defined_use_pci_map
-
/* BIO layer definitions. */
extern unsigned long kern_base, kern_size;
#define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)
--
1.5.2.3
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Mark sparc and sparc64 as not having virt_to_bus
Hi All,
Currently, sun4c (and sun4m) do NOT support the FDC driver as a module.
I did look at it but decided there were better issues to resolve at the
time.
A fix for this issue would either envolve a lot of work moving the low
level assembly interrupt handler from arch/sparc/kernel/entry.S to the
floppy driver module, or the exporting of a number of variables and
functions used by the handler so that they can be picked up by the floppy
driver module.
Moving the low level handeler would be better from the point of view of
modular code.
Regards
Mark Fortescue.
On Wed, 18 Jul 2007, Stephen Rothwell wrote:
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/sparc/Kconfig |3 +++
arch/sparc64/Kconfig |3 +++
include/asm-sparc64/io.h |5 -
3 files changed, 6 insertions(+), 5 deletions(-)
This is part of a rash attempt to make allmodconfig builds work for sparc
and sparc64 :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 73df711..603d83a 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -21,6 +21,9 @@ config GENERIC_ISA_DMA
bool
default y
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+
source init/Kconfig
menu General machine setup
diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
index b84b6af..df6ee71 100644
--- a/arch/sparc64/Kconfig
+++ b/arch/sparc64/Kconfig
@@ -62,6 +62,9 @@ config AUDIT_ARCH
bool
default y
+config ARCH_NO_VIRT_TO_BUS
+ def_bool y
+
choice
prompt Kernel page size
default SPARC64_PAGE_SIZE_8KB
diff --git a/include/asm-sparc64/io.h b/include/asm-sparc64/io.h
index ad595b6..9565a89 100644
--- a/include/asm-sparc64/io.h
+++ b/include/asm-sparc64/io.h
@@ -14,11 +14,6 @@
#define __SLOW_DOWN_IO do { } while (0)
#define SLOW_DOWN_IOdo { } while (0)
-extern unsigned long virt_to_bus_not_defined_use_pci_map(volatile void *addr);
-#define virt_to_bus virt_to_bus_not_defined_use_pci_map
-extern unsigned long bus_to_virt_not_defined_use_pci_map(volatile void *addr);
-#define bus_to_virt bus_to_virt_not_defined_use_pci_map
-
/* BIO layer definitions. */
extern unsigned long kern_base, kern_size;
#define page_to_phys(page) (page_to_pfn(page) PAGE_SHIFT)
--
1.5.2.3
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I have sucessfully tested the attached patch on Sparc32:sun4c.
Is there any chance of this getting sufficiantly tested on other
architectures to get in into v2.6.22 ?
Regards
Mark Fortescue.From: Mark Fortescue <[EMAIL PROTECTED]>, David Woodhouse <[EMAIL PROTECTED]>
Verious alignment fixes in the SLAB alocator that increased the size
of the RedZone words failed to ensure that RedZone word 2 is aligned
on a 64bit boundary. This resulted in random invalid instruction
occourances on Sparc32 (sun4c).
These additional changes should ensure that the RedZone words are
correctly aligned on a 64bit boundary for architectures that require this.
Signed-off-by: Mark Fortescue <[EMAIL PROTECTED]>
---
Tested on Sparc32:sun4c
Additional testing desirable on PowerPC32, Sparc64, PowerPC64 and any
other platforms where alignment changes may be of concirn.
--- linux-2.6/mm/slab.c 2007-07-03 19:09:48.0 +0100
+++ linux-test/mm/slab.c2007-07-04 04:14:15.0 +0100
@@ -137,6 +137,7 @@
/* Shouldn't this be in a header file somewhere? */
#defineBYTES_PER_WORD sizeof(void *)
+#defineRED_ZONE_ALIGN (max(__alignof__(void *),
__alignof(unsigned long long)) - 1)
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -547,7 +548,7 @@ static unsigned long long *dbg_redzone2(
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2178,7 +2179,8 @@ kmem_cache_create (const char *name, siz
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + 3 * BYTES_PER_WORD))
+ if (size < 4096 || fls(size - 1) == fls(size-1 + 2 * sizeof(unsigned
long long) +
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
flags |= SLAB_POISON;
@@ -2197,9 +2199,9 @@ kmem_cache_create (const char *name, siz
* unaligned accesses for some archs when redzoning is used, and makes
* sure any on-slab bufctl's are also correctly aligned.
*/
- if (size & (BYTES_PER_WORD - 1)) {
- size += (BYTES_PER_WORD - 1);
- size &= ~(BYTES_PER_WORD - 1);
+ if (size & RED_ZONE_ALIGN) {
+ size += RED_ZONE_ALIGN;
+ size &= ~RED_ZONE_ALIGN;
}
/* calculate the final buffer alignment: */
@@ -2261,9 +2263,14 @@ kmem_cache_create (const char *name, siz
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE
+ && BYTES_PER_WORD < __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David, Another related point that may also need to be considered is that I think I am correct in saying that on ARM and on the 64bit platforms, sizeof (unsigned long long) is 16 (128bits). Should the RedZone words be specified as __u64 not the unsigned long long used or does the alignment need to be that of unsigned long long ? Regards Mark Fortescue. On Tue, 3 Jul 2007, David Woodhouse wrote: On Wed, 2007-07-04 at 04:27 +0100, Mark Fortescue wrote: I tried the previous patch and it looks like it fixes the issue however one of the test builds I did caused depmod to use up all available memory (40M - kernel memory) before taking out the kernel with the oom killer. At present, I do not know if it is a depmod issue or a kernel issue. I will have to do some more tests later on to day. That's almost certain to be an unrelated issue. I have looked at the latest patch below and am I am still not sure about two areas. Please take a look at my offering based on your latest patch (included here to it will probably get mangled). Note the change to lines 2178 to 2185. I have also changed/moved the alignment of size (see lines 2197 to 2206) based on your changes. The first looks correct; well spotted. The second is just cosmetic but also seems correct. I might be inclined to make the #define 'RED_ZONE_ALIGN' and use it in the other places too. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David, Another related point that may also need to be considered is that I think I am correct in saying that on ARM and on the 64bit platforms, sizeof (unsigned long long) is 16 (128bits). Should the RedZone words be specified as __u64 not the unsigned long long used or does the alignment need to be that of unsigned long long ? Regards Mark Fortescue. On Tue, 3 Jul 2007, David Woodhouse wrote: On Wed, 2007-07-04 at 04:27 +0100, Mark Fortescue wrote: I tried the previous patch and it looks like it fixes the issue however one of the test builds I did caused depmod to use up all available memory (40M - kernel memory) before taking out the kernel with the oom killer. At present, I do not know if it is a depmod issue or a kernel issue. I will have to do some more tests later on to day. That's almost certain to be an unrelated issue. I have looked at the latest patch below and am I am still not sure about two areas. Please take a look at my offering based on your latest patch (included here to it will probably get mangled). Note the change to lines 2178 to 2185. I have also changed/moved the alignment of size (see lines 2197 to 2206) based on your changes. The first looks correct; well spotted. The second is just cosmetic but also seems correct. I might be inclined to make the #define 'RED_ZONE_ALIGN' and use it in the other places too. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I have sucessfully tested the attached patch on Sparc32:sun4c.
Is there any chance of this getting sufficiantly tested on other
architectures to get in into v2.6.22 ?
Regards
Mark Fortescue.From: Mark Fortescue [EMAIL PROTECTED], David Woodhouse [EMAIL PROTECTED]
Verious alignment fixes in the SLAB alocator that increased the size
of the RedZone words failed to ensure that RedZone word 2 is aligned
on a 64bit boundary. This resulted in random invalid instruction
occourances on Sparc32 (sun4c).
These additional changes should ensure that the RedZone words are
correctly aligned on a 64bit boundary for architectures that require this.
Signed-off-by: Mark Fortescue [EMAIL PROTECTED]
---
Tested on Sparc32:sun4c
Additional testing desirable on PowerPC32, Sparc64, PowerPC64 and any
other platforms where alignment changes may be of concirn.
--- linux-2.6/mm/slab.c 2007-07-03 19:09:48.0 +0100
+++ linux-test/mm/slab.c2007-07-04 04:14:15.0 +0100
@@ -137,6 +137,7 @@
/* Shouldn't this be in a header file somewhere? */
#defineBYTES_PER_WORD sizeof(void *)
+#defineRED_ZONE_ALIGN (max(__alignof__(void *),
__alignof(unsigned long long)) - 1)
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -547,7 +548,7 @@ static unsigned long long *dbg_redzone2(
if (cachep-flags SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep-buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep-buffer_size -
sizeof(unsigned long long));
}
@@ -2178,7 +2179,8 @@ kmem_cache_create (const char *name, siz
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size 4096 || fls(size - 1) == fls(size-1 + 3 * BYTES_PER_WORD))
+ if (size 4096 || fls(size - 1) == fls(size-1 + 2 * sizeof(unsigned
long long) +
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags SLAB_DESTROY_BY_RCU))
flags |= SLAB_POISON;
@@ -2197,9 +2199,9 @@ kmem_cache_create (const char *name, siz
* unaligned accesses for some archs when redzoning is used, and makes
* sure any on-slab bufctl's are also correctly aligned.
*/
- if (size (BYTES_PER_WORD - 1)) {
- size += (BYTES_PER_WORD - 1);
- size = ~(BYTES_PER_WORD - 1);
+ if (size RED_ZONE_ALIGN) {
+ size += RED_ZONE_ALIGN;
+ size = ~RED_ZONE_ALIGN;
}
/* calculate the final buffer alignment: */
@@ -2261,9 +2263,14 @@ kmem_cache_create (const char *name, siz
}
if (flags SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags SLAB_RED_ZONE
+BYTES_PER_WORD __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG defined(CONFIG_DEBUG_PAGEALLOC)
if (size = malloc_sizes[INDEX_L3 + 1].cs_size
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I tried the previous patch and it looks like it fixes the issue however
one of the test builds I did caused depmod to use up all available memory
(40M - kernel memory) before taking out the kernel with the oom killer.
At present, I do not know if it is a depmod issue or a kernel issue.
I will have to do some more tests later on to day.
I have looked at the latest patch below and am I am still not sure about
two areas. Please take a look at my offering based on your latest
patch (included here to it will probably get mangled).
Note the change to lines 2178 to 2185. I have also changed/moved the
alignment of size (see lines 2197 to 2206) based on your changes.
--- linux-2.6/mm/slab.c 2007-07-03 19:09:48.0 +0100
+++ linux-test/mm/slab.c2007-07-04 04:14:15.0 +0100
@@ -137,6 +137,7 @@
/* Shouldn't this be in a header file somewhere? */
#defineBYTES_PER_WORD sizeof(void *)
+#define RED_ZONE_ALIGN_MASK(max(__alignof__(void *), __alignof(unsigned
long long)) - 1)
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -547,7 +548,7 @@ static unsigned long long *dbg_redzone2(
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2178,7 +2179,8 @@ kmem_cache_create (const char *name, siz
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + 3 * BYTES_PER_WORD))
+ if (size < 4096 || fls(size - 1) == fls(size-1 + 2 * sizeof(unsigned
long long) +
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
flags |= SLAB_POISON;
@@ -2197,9 +2199,9 @@ kmem_cache_create (const char *name, siz
* unaligned accesses for some archs when redzoning is used, and makes
* sure any on-slab bufctl's are also correctly aligned.
*/
- if (size & (BYTES_PER_WORD - 1)) {
- size += (BYTES_PER_WORD - 1);
- size &= ~(BYTES_PER_WORD - 1);
+ if (size & RED_ZONE_ALIGN_MASK) {
+ size += RED_ZONE_ALIGN_MASK;
+ size &= ~RED_ZONE_ALIGN_MASK;
}
/* calculate the final buffer alignment: */
@@ -2261,9 +2263,14 @@ kmem_cache_create (const char *name, siz
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE
+ && BYTES_PER_WORD < __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
---
Let me know if you would like an un-mangled copy of the patch as an
attachement.
Regards
Mark Fortescue.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 23:47 +0100, Mark Fortescue wrote:
Hi David,
I will try out your patch shortly.
Thanks.
I may be wrong about the size calculations but if you take a look at lines
2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
these need to be changed to match the changes to the RedZone words.
Failing to change these means that 32bit aligned access of the 64bit
RedZone words is still posible and this will kill sun4c.
Why do we need more than the existing:
if (flags & SLAB_RED_ZONE || flags & SLAB_STORE_USER)
ralign = __alignof__(unsigned long long);
For the 64bit RedZone word to be 64bit aligned (required by sun4c), the
User word must be 64bit aligned. I don't see where in your patch, this is
enforced.
Where __alignof__(long long) > BYTES_PER_WORD my patch should lead to
this layout (32-bit words):
[ redzone1 bits 63-32 ]
[ redzone1 bits 31-0 ]
[... object ... ]
[... object ... ]
[ redzone2 bits 63-32 ]
[ redzone2 bits 31-0 ]
[unused ]
[ user word ]
The
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I will try out your patch shortly.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
problem.
Surely, it can. You just have to tell the compiler that it's not
properly aligned, and it'll emit code to cope. Hence the suggestion that
you use 'unsigned long long __attribute__((aligned(BYTES_PER_WORD))'.
But it's probably better just to make sure it remains aligned; you're
right.
In addition, having looked at the size calculations, it looks to me as if
not all of them got updated to handle 64bit redzone words.
Really? Other than the alignment of the second redzone, what's wrong?
Remember that the 'user word' is still not necessarily 64-bit. And in
fact I suspect that's what is causing the problem -- your object _size_
will be aligned to 8 bytes, including the user word, and then we look
for the second redzone word 12 bytes before the end of the object.
Yes, the user word is a 32bit word and this is part of the issue.
I may be wrong about the size calculations but if you take a look at lines
2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
these need to be changed to match the changes to the RedZone words.
Failing to change these means that 32bit aligned access of the 64bit
RedZone words is still posible and this will kill sun4c.
For the 64bit RedZone word to be 64bit aligned (required by sun4c), the
User word must be 64bit aligned. I don't see where in your patch, this is
enforced.
Does this fix it?
diff --git a/mm/slab.c b/mm/slab.c
index 6d65cf4..3b15671 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -547,7 +547,7 @@ static unsigned long long *dbg_redzone2(struct kmem_cache
*cachep, void *objp)
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep->buffer_size -
sizeof(unsigned long long));
}
@@ -2262,9 +2262,14 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
}
if (flags & SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags & SLAB_RED_ZONE
+ && BYTES_PER_WORD < __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG && defined(CONFIG_DEBUG_PAGEALLOC)
if (size >= malloc_sizes[INDEX_L3 + 1].cs_size
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David, The problem is that sun4c Sparc32 can't handle un-aligned variables so having a 64bit readzone word that is not aligned on a 64bit boundary is a problem. In addition, having looked at the size calculations, it looks to me as if not all of them got updated to handle 64bit redzone words. This may be part of the problem. By making BYTES_PER_WORD 64bit aligned (Sparc32) this is nolonger an issue. Regards Mark Fortescue. On Tue, 3 Jul 2007, David Woodhouse wrote: On Tue, 2007-07-03 at 19:57 +0100, Mark Fortescue wrote: Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment issues but does not ensure that all 64bit alignment requirements of sparc32 are met. Tests have shown that the redzone2 word can become misallignd. Oops, sorry about that. I'm not sure about your patch though -- I think I'd prefer to keep the redzone misaligned (and hence _right_ next to the real data), and just deal with it. typedef unsigned long long __aligned__((BYTES_PER_WORD)) redzone_t; -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi all,
I have tested a solution to the random invalid instruction occourances on
sparc32 (sun4c). I have attached the patch as my mail client messes up
patch files.
The problem apears to be an alignment error of the redzone2 word, caused
by the userword not being forced onto a 64bit boundary. My solution is to
increase the size of the user word (BYTES_PER_WORD) to 64bits in order to
force the correct alignment of the user word (and hence the redzone2
word). My solution also works on platforms where sizeof(unsigned long
long) is 128bits and requires 128bit alignment.
Regards
Mark Fortescue.
On Tue, 3 Jul 2007, Mark Fortescue wrote:
Hi all,
I think I have found the cause of the problem.
Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment
issues but does not ensure that all 64bit alignment requirements of sparc32
are met. Tests have shown that the redzone2 word can become misallignd.
I am currently working on a posible fix.
Regards
Mark Fortescue.
On Tue, 3 Jul 2007, Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.22-rc7.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Hugh Dickins 2
Andi Kleen 1
Andrew Morton 1
Benjamin Herrenschmidt 1
Bj?rn Steinbrink 1
Bjorn Helgaas 1
Jean Delvare 1
Olaf Hering1
Siddha, Suresh B 1
Trent Piepho 1
Ville Syrj?l? 1
FS
Subject: 2.6.22-rc4-git5 reiserfs: null ptr deref.
References : http://lkml.org/lkml/2007/6/13/322
Submitter : Randy Dunlap <[EMAIL PROTECTED]>
Handled-By : Vladimir V. Saveliev <[EMAIL PROTECTED]>
Status : problem is being debugged
IDE
Subject: 2.6.22-rcX: hda: lost interrupt
References : http://lkml.org/lkml/2007/6/29/121
Submitter : David Chinner <[EMAIL PROTECTED]>
Status : unknown
Sparc64
Subject: random invalid instruction occourances on sparc32 (sun4c)
References : http://lkml.org/lkml/2007/6/17/111
Submitter : Mark Fortescue <[EMAIL PROTECTED]>
Status : problem is being debugged
Subject: 2.6.22-rc broke X on Ultra5
References : http://lkml.org/lkml/2007/5/22/78
Submitter : Mikael Pettersson <[EMAIL PROTECTED]>
Handled-By : David Miller <[EMAIL PROTECTED]>
Status : problem is being debugged
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Fortescue <[EMAIL PROTECTED]>
Verious alignment fixes in the SLAB alocator that increased the size
of the RedZone words failed to ensure that RedZone word 2 is aligned
on a 64bit boundary. This has resulted in random invalid instruction
occourances on Sparc32 (sun4c).
By increasing the size of the User Word (BYTES_PER_WORD) to 64bits
seams to ensure that correct alignment is maintained but assumes that:
sizeof (void *) <= sizeof (unsigned dlong long)
Signed-off-by: Mark Fortescue <[EMAIL PROTECTED]>
---
Alternative solutions would involve correcting the size caculations on
lines 2175 to 2275 and may also involve additional changes to the
calculations to get a pointer to the RedZone Word 2.
--- linux-2.6/mm/slab.c 2007-07-03 17:35:07.0 +0100
+++ linux-test/mm/slab.c2007-07-03 19:05:19.0 +0100
@@ -136,7 +136,8 @@
#endif
/* Shouldn't this be in a header file somewhere? */
-#defineBYTES_PER_WORD sizeof(void *)
+/* Fix alignment of redzone2. Assumes sizeof (void*) <= sizeof (unsigned long
long) */
+#defineBYTES_PER_WORD sizeof(unsigned long long)
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -538,7 +539,7 @@ static unsigned long long *dbg_redzone1(
{
BUG_ON(!(cachep->flags & SLAB_RED_ZONE));
return (unsigned long long*) (objp + obj_offset(cachep) -
- sizeof(unsigned long long));
+ BYTES_PER_WORD);
}
static unsigned long long *dbg_redzone2(struct kmem_cache *cachep, void *objp)
@@ -546,10 +547,9 @@ static unsigned long long *dbg_redzone2(
BUG_ON(!(cachep->flags & SLAB_RED_ZONE));
if (cachep->flags & SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep->buffer_size -
- sizeof(unsigned long long) -
- BYTES_PER_WORD);
+
Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi all, I think I have found the cause of the problem. Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment issues but does not ensure that all 64bit alignment requirements of sparc32 are met. Tests have shown that the redzone2 word can become misallignd. I am currently working on a posible fix. Regards Mark Fortescue. On Tue, 3 Jul 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc7. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Hugh Dickins 2 Andi Kleen 1 Andrew Morton 1 Benjamin Herrenschmidt 1 Björn Steinbrink 1 Bjorn Helgaas 1 Jean Delvare 1 Olaf Hering1 Siddha, Suresh B 1 Trent Piepho 1 Ville Syrjälä 1 FS Subject: 2.6.22-rc4-git5 reiserfs: null ptr deref. References : http://lkml.org/lkml/2007/6/13/322 Submitter : Randy Dunlap <[EMAIL PROTECTED]> Handled-By : Vladimir V. Saveliev <[EMAIL PROTECTED]> Status : problem is being debugged IDE Subject: 2.6.22-rcX: hda: lost interrupt References : http://lkml.org/lkml/2007/6/29/121 Submitter : David Chinner <[EMAIL PROTECTED]> Status : unknown Sparc64 Subject: random invalid instruction occourances on sparc32 (sun4c) References : http://lkml.org/lkml/2007/6/17/111 Submitter : Mark Fortescue <[EMAIL PROTECTED]> Status : problem is being debugged Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <[EMAIL PROTECTED]> Handled-By : David Miller <[EMAIL PROTECTED]> Status : problem is being debugged Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi all, I think I have found the cause of the problem. Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment issues but does not ensure that all 64bit alignment requirements of sparc32 are met. Tests have shown that the redzone2 word can become misallignd. I am currently working on a posible fix. Regards Mark Fortescue. On Tue, 3 Jul 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc7. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Hugh Dickins 2 Andi Kleen 1 Andrew Morton 1 Benjamin Herrenschmidt 1 Björn Steinbrink 1 Bjorn Helgaas 1 Jean Delvare 1 Olaf Hering1 Siddha, Suresh B 1 Trent Piepho 1 Ville Syrjälä 1 FS Subject: 2.6.22-rc4-git5 reiserfs: null ptr deref. References : http://lkml.org/lkml/2007/6/13/322 Submitter : Randy Dunlap [EMAIL PROTECTED] Handled-By : Vladimir V. Saveliev [EMAIL PROTECTED] Status : problem is being debugged IDE Subject: 2.6.22-rcX: hda: lost interrupt References : http://lkml.org/lkml/2007/6/29/121 Submitter : David Chinner [EMAIL PROTECTED] Status : unknown Sparc64 Subject: random invalid instruction occourances on sparc32 (sun4c) References : http://lkml.org/lkml/2007/6/17/111 Submitter : Mark Fortescue [EMAIL PROTECTED] Status : problem is being debugged Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Status : problem is being debugged Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi all,
I have tested a solution to the random invalid instruction occourances on
sparc32 (sun4c). I have attached the patch as my mail client messes up
patch files.
The problem apears to be an alignment error of the redzone2 word, caused
by the userword not being forced onto a 64bit boundary. My solution is to
increase the size of the user word (BYTES_PER_WORD) to 64bits in order to
force the correct alignment of the user word (and hence the redzone2
word). My solution also works on platforms where sizeof(unsigned long
long) is 128bits and requires 128bit alignment.
Regards
Mark Fortescue.
On Tue, 3 Jul 2007, Mark Fortescue wrote:
Hi all,
I think I have found the cause of the problem.
Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment
issues but does not ensure that all 64bit alignment requirements of sparc32
are met. Tests have shown that the redzone2 word can become misallignd.
I am currently working on a posible fix.
Regards
Mark Fortescue.
On Tue, 3 Jul 2007, Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.22-rc7.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Hugh Dickins 2
Andi Kleen 1
Andrew Morton 1
Benjamin Herrenschmidt 1
Bj?rn Steinbrink 1
Bjorn Helgaas 1
Jean Delvare 1
Olaf Hering1
Siddha, Suresh B 1
Trent Piepho 1
Ville Syrj?l? 1
FS
Subject: 2.6.22-rc4-git5 reiserfs: null ptr deref.
References : http://lkml.org/lkml/2007/6/13/322
Submitter : Randy Dunlap [EMAIL PROTECTED]
Handled-By : Vladimir V. Saveliev [EMAIL PROTECTED]
Status : problem is being debugged
IDE
Subject: 2.6.22-rcX: hda: lost interrupt
References : http://lkml.org/lkml/2007/6/29/121
Submitter : David Chinner [EMAIL PROTECTED]
Status : unknown
Sparc64
Subject: random invalid instruction occourances on sparc32 (sun4c)
References : http://lkml.org/lkml/2007/6/17/111
Submitter : Mark Fortescue [EMAIL PROTECTED]
Status : problem is being debugged
Subject: 2.6.22-rc broke X on Ultra5
References : http://lkml.org/lkml/2007/5/22/78
Submitter : Mikael Pettersson [EMAIL PROTECTED]
Handled-By : David Miller [EMAIL PROTECTED]
Status : problem is being debugged
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Fortescue [EMAIL PROTECTED]
Verious alignment fixes in the SLAB alocator that increased the size
of the RedZone words failed to ensure that RedZone word 2 is aligned
on a 64bit boundary. This has resulted in random invalid instruction
occourances on Sparc32 (sun4c).
By increasing the size of the User Word (BYTES_PER_WORD) to 64bits
seams to ensure that correct alignment is maintained but assumes that:
sizeof (void *) = sizeof (unsigned dlong long)
Signed-off-by: Mark Fortescue [EMAIL PROTECTED]
---
Alternative solutions would involve correcting the size caculations on
lines 2175 to 2275 and may also involve additional changes to the
calculations to get a pointer to the RedZone Word 2.
--- linux-2.6/mm/slab.c 2007-07-03 17:35:07.0 +0100
+++ linux-test/mm/slab.c2007-07-03 19:05:19.0 +0100
@@ -136,7 +136,8 @@
#endif
/* Shouldn't this be in a header file somewhere? */
-#defineBYTES_PER_WORD sizeof(void *)
+/* Fix alignment of redzone2. Assumes sizeof (void*) = sizeof (unsigned long
long) */
+#defineBYTES_PER_WORD sizeof(unsigned long long)
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -538,7 +539,7 @@ static unsigned long long *dbg_redzone1(
{
BUG_ON(!(cachep-flags SLAB_RED_ZONE));
return (unsigned long long*) (objp + obj_offset(cachep) -
- sizeof(unsigned long long));
+ BYTES_PER_WORD);
}
static unsigned long long *dbg_redzone2(struct kmem_cache *cachep, void *objp)
@@ -546,10 +547,9 @@ static unsigned long long *dbg_redzone2(
BUG_ON(!(cachep-flags SLAB_RED_ZONE));
if (cachep-flags SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep-buffer_size -
- sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ 2 * BYTES_PER_WORD);
return (unsigned long long *) (objp + cachep-buffer_size -
- sizeof(unsigned
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David, The problem is that sun4c Sparc32 can't handle un-aligned variables so having a 64bit readzone word that is not aligned on a 64bit boundary is a problem. In addition, having looked at the size calculations, it looks to me as if not all of them got updated to handle 64bit redzone words. This may be part of the problem. By making BYTES_PER_WORD 64bit aligned (Sparc32) this is nolonger an issue. Regards Mark Fortescue. On Tue, 3 Jul 2007, David Woodhouse wrote: On Tue, 2007-07-03 at 19:57 +0100, Mark Fortescue wrote: Commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66 partially fixed alignment issues but does not ensure that all 64bit alignment requirements of sparc32 are met. Tests have shown that the redzone2 word can become misallignd. Oops, sorry about that. I'm not sure about your patch though -- I think I'd prefer to keep the redzone misaligned (and hence _right_ next to the real data), and just deal with it. typedef unsigned long long __aligned__((BYTES_PER_WORD)) redzone_t; -- dwmw2 - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I will try out your patch shortly.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 22:25 +0100, Mark Fortescue wrote:
The problem is that sun4c Sparc32 can't handle un-aligned variables so
having a 64bit readzone word that is not aligned on a 64bit boundary is a
problem.
Surely, it can. You just have to tell the compiler that it's not
properly aligned, and it'll emit code to cope. Hence the suggestion that
you use 'unsigned long long __attribute__((aligned(BYTES_PER_WORD))'.
But it's probably better just to make sure it remains aligned; you're
right.
In addition, having looked at the size calculations, it looks to me as if
not all of them got updated to handle 64bit redzone words.
Really? Other than the alignment of the second redzone, what's wrong?
Remember that the 'user word' is still not necessarily 64-bit. And in
fact I suspect that's what is causing the problem -- your object _size_
will be aligned to 8 bytes, including the user word, and then we look
for the second redzone word 12 bytes before the end of the object.
Yes, the user word is a 32bit word and this is part of the issue.
I may be wrong about the size calculations but if you take a look at lines
2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
these need to be changed to match the changes to the RedZone words.
Failing to change these means that 32bit aligned access of the 64bit
RedZone words is still posible and this will kill sun4c.
For the 64bit RedZone word to be 64bit aligned (required by sun4c), the
User word must be 64bit aligned. I don't see where in your patch, this is
enforced.
Does this fix it?
diff --git a/mm/slab.c b/mm/slab.c
index 6d65cf4..3b15671 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -547,7 +547,7 @@ static unsigned long long *dbg_redzone2(struct kmem_cache
*cachep, void *objp)
if (cachep-flags SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep-buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep-buffer_size -
sizeof(unsigned long long));
}
@@ -2262,9 +2262,14 @@ kmem_cache_create (const char *name, size_t size, size_t
align,
}
if (flags SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags SLAB_RED_ZONE
+BYTES_PER_WORD __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG defined(CONFIG_DEBUG_PAGEALLOC)
if (size = malloc_sizes[INDEX_L3 + 1].cs_size
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Sparc32: random invalid instruction occourances on sparc32 (sun4c)
Hi David,
I tried the previous patch and it looks like it fixes the issue however
one of the test builds I did caused depmod to use up all available memory
(40M - kernel memory) before taking out the kernel with the oom killer.
At present, I do not know if it is a depmod issue or a kernel issue.
I will have to do some more tests later on to day.
I have looked at the latest patch below and am I am still not sure about
two areas. Please take a look at my offering based on your latest
patch (included here to it will probably get mangled).
Note the change to lines 2178 to 2185. I have also changed/moved the
alignment of size (see lines 2197 to 2206) based on your changes.
--- linux-2.6/mm/slab.c 2007-07-03 19:09:48.0 +0100
+++ linux-test/mm/slab.c2007-07-04 04:14:15.0 +0100
@@ -137,6 +137,7 @@
/* Shouldn't this be in a header file somewhere? */
#defineBYTES_PER_WORD sizeof(void *)
+#define RED_ZONE_ALIGN_MASK(max(__alignof__(void *), __alignof(unsigned
long long)) - 1)
#ifndef cache_line_size
#define cache_line_size() L1_CACHE_BYTES
@@ -547,7 +548,7 @@ static unsigned long long *dbg_redzone2(
if (cachep-flags SLAB_STORE_USER)
return (unsigned long long *)(objp + cachep-buffer_size -
sizeof(unsigned long long) -
- BYTES_PER_WORD);
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long)));
return (unsigned long long *) (objp + cachep-buffer_size -
sizeof(unsigned long long));
}
@@ -2178,7 +2179,8 @@ kmem_cache_create (const char *name, siz
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size 4096 || fls(size - 1) == fls(size-1 + 3 * BYTES_PER_WORD))
+ if (size 4096 || fls(size - 1) == fls(size-1 + 2 * sizeof(unsigned
long long) +
+ max(BYTES_PER_WORD,
__alignof__(unsigned long long
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags SLAB_DESTROY_BY_RCU))
flags |= SLAB_POISON;
@@ -2197,9 +2199,9 @@ kmem_cache_create (const char *name, siz
* unaligned accesses for some archs when redzoning is used, and makes
* sure any on-slab bufctl's are also correctly aligned.
*/
- if (size (BYTES_PER_WORD - 1)) {
- size += (BYTES_PER_WORD - 1);
- size = ~(BYTES_PER_WORD - 1);
+ if (size RED_ZONE_ALIGN_MASK) {
+ size += RED_ZONE_ALIGN_MASK;
+ size = ~RED_ZONE_ALIGN_MASK;
}
/* calculate the final buffer alignment: */
@@ -2261,9 +2263,14 @@ kmem_cache_create (const char *name, siz
}
if (flags SLAB_STORE_USER) {
/* user store requires one word storage behind the end of
-* the real object.
+* the real object. But if the second red zone must be
+* aligned 'better' than that, allow for it.
*/
- size += BYTES_PER_WORD;
+ if (flags SLAB_RED_ZONE
+BYTES_PER_WORD __alignof__(unsigned long long))
+ size += __alignof__(unsigned long long);
+ else
+ size += BYTES_PER_WORD;
}
#if FORCED_DEBUG defined(CONFIG_DEBUG_PAGEALLOC)
if (size = malloc_sizes[INDEX_L3 + 1].cs_size
---
Let me know if you would like an un-mangled copy of the patch as an
attachement.
Regards
Mark Fortescue.
On Tue, 3 Jul 2007, David Woodhouse wrote:
On Tue, 2007-07-03 at 23:47 +0100, Mark Fortescue wrote:
Hi David,
I will try out your patch shortly.
Thanks.
I may be wrong about the size calculations but if you take a look at lines
2174 to 2188 and 2207 to 2203, reading the comments suggest to me that
these need to be changed to match the changes to the RedZone words.
Failing to change these means that 32bit aligned access of the 64bit
RedZone words is still posible and this will kill sun4c.
Why do we need more than the existing:
if (flags SLAB_RED_ZONE || flags SLAB_STORE_USER)
ralign = __alignof__(unsigned long long);
For the 64bit RedZone word to be 64bit aligned (required by sun4c), the
User word must be 64bit aligned. I don't see where in your patch, this is
enforced.
Where __alignof__(long long) BYTES_PER_WORD my patch should lead to
this layout (32-bit words):
[ redzone1 bits 63-32 ]
[ redzone1 bits 31-0 ]
[... object ... ]
[... object ... ]
[ redzone2 bits 63-32 ]
[ redzone2 bits 31-0 ]
[unused ]
[ user word ]
The user word is a 32-bit value; there's no requirement for _it_ to be
aligned.
Hm, actually I think my
Re: [1/2] 2.6.22-rc6: known regressions
Hi All, I have done some more work on the sun4c Sparc32 random invalid instruction occourances. The issue only affects the SLAB allocator. The SLUB and SLOB allocators both work OK but SLOB is dreadfully slow making it totally impractical for use on my sun4c. Isolating the problem to the SLAB allocator should make it a bit easier to track down the problem. It may be desirable to put a comment into Kconfig to indicate that the SLAB allocator is currently broaken for sun4c but that SLUB works well as I dought that I will have found/fixed the problem before 2.6.22. Regards Mark Fortescue. On Mon, 25 Jun 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc6. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions *STATISTICS* (a.k.a. list of aces) NameRegressions fixed since 21-Jun-2007 Andi Kleen 1 Hugh Dickins 1 Jean Delvare 1 Sparc64 Subject: random invalid instruction occourances on sparc32 (sun4c) References : http://lkml.org/lkml/2007/6/17/111 Submitter : Mark Fortescue <[EMAIL PROTECTED]> Status : problem is being debugged Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <[EMAIL PROTECTED]> Handled-By : David Miller <[EMAIL PROTECTED]> Status : problem is being debugged x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita <[EMAIL PROTECTED]> Status : Unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.22-rc6: known regressions
Hi All, I have done some more work on the sun4c Sparc32 random invalid instruction occourances. The issue only affects the SLAB allocator. The SLUB and SLOB allocators both work OK but SLOB is dreadfully slow making it totally impractical for use on my sun4c. Isolating the problem to the SLAB allocator should make it a bit easier to track down the problem. It may be desirable to put a comment into Kconfig to indicate that the SLAB allocator is currently broaken for sun4c but that SLUB works well as I dought that I will have found/fixed the problem before 2.6.22. Regards Mark Fortescue. On Mon, 25 Jun 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc6. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions *STATISTICS* (a.k.a. list of aces) NameRegressions fixed since 21-Jun-2007 Andi Kleen 1 Hugh Dickins 1 Jean Delvare 1 Sparc64 Subject: random invalid instruction occourances on sparc32 (sun4c) References : http://lkml.org/lkml/2007/6/17/111 Submitter : Mark Fortescue [EMAIL PROTECTED] Status : problem is being debugged Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Status : problem is being debugged x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita [EMAIL PROTECTED] Status : Unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi all, I have been investigating the random invalid instruction occourances on sparc32 (sun4c) and identified that the problem was introduced pre-v2.6.22-rc1. v2.6.21 is OK. The first time I have observed the issue so far is after commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66: Increase slab redzone to 64bits. Prior to this commit there apears to be a problem with the memory management (depmod -a causes the system to run out of memory!) that may be masking the issue. As a result of this, I am going to try to find the 'last known good' commit after v2.6.21 to see if this helps narrow down the cause. Regards Mark Fortescue. On Thu, 14 Jun 2007, William Lee Irwin III wrote: On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote: They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. This sounds like it may be addressed by benh's ptep_set_access_flags() fixes. Those fixes are still in -mm, hopefully to hit mainline by 2.6.22. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi all, I have been investigating the random invalid instruction occourances on sparc32 (sun4c) and identified that the problem was introduced pre-v2.6.22-rc1. v2.6.21 is OK. The first time I have observed the issue so far is after commit b46b8f19c9cd435ecac4d9d12b39d78c137ecd66: Increase slab redzone to 64bits. Prior to this commit there apears to be a problem with the memory management (depmod -a causes the system to run out of memory!) that may be masking the issue. As a result of this, I am going to try to find the 'last known good' commit after v2.6.21 to see if this helps narrow down the cause. Regards Mark Fortescue. On Thu, 14 Jun 2007, William Lee Irwin III wrote: On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote: They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. This sounds like it may be addressed by benh's ptep_set_access_flags() fixes. Those fixes are still in -mm, hopefully to hit mainline by 2.6.22. -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Benh's ptep_set_access_flags() patch needs to be applied in order to get
anyware with sun4c for all kernels >= linux-2.6.15. If not applied, you
will be lucky to get sash running as your init and even that will have
very limitit capabilities before it locks up the processor (power up
reset required).
It has been applied to both the kernels I used for testing so this
problem is independent of the ptep_set_access_flags patch but that
does not mean that it is not a related issue.
I will try to get some testing done over the weekend to narrow down
when the random illegal instructions first occour.
If I start with 2.6.21 then if that is OK, then I should be able to narow
the issue down without too much trouble. If it is between 2.6.20 and
2.6.21 then it will be a right pig as there are a large number of commits
that don't compile for sun4c between these two. What I am hoping is that
it occours in the 2.6.22-rc2 as per the x86_64.
I am going to have to put a 'reset' button onto my test system as power up
resets are bad news on this old hardware and almost all kernel failures
result in a processor lockup. I have even had to make BUG reports 'panic'
as thoes that I have during kernel fault location had are terminal to a
sun4c (they cause a processor lockup).
Regards
Mark Fortescue.
On Thu, 14 Jun 2007, William Lee Irwin III wrote:
On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote:
They apear as soon as simpleinit starts up. Somtimes I get to a login
prompt before seeing any. Other times, commands in the simpleinit rc
script fail.
They do apear to be random. If a command failes, you re-run the command
and it is OK. Commands seen to fail are basic (depmod, rm cat ..).
The test I did use the same binaries with both the OK and problem kernels
so it is not a change to the application code, it is definatly a kernel
issue.
This sounds like it may be addressed by benh's ptep_set_access_flags()
fixes. Those fixes are still in -mm, hopefully to hit mainline by 2.6.22.
-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi All, They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. Regards Mark Fortescue. On Wed, 13 Jun 2007, William Lee Irwin III wrote: On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote: The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Very interesting. Any hints as to how to test or how long to wait before the illegal instructions happen? -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi All, They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. Regards Mark Fortescue. On Wed, 13 Jun 2007, William Lee Irwin III wrote: On Wed, Jun 13, 2007 at 11:25:20PM +0100, Mark Fortescue wrote: The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Very interesting. Any hints as to how to test or how long to wait before the illegal instructions happen? -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Benh's ptep_set_access_flags() patch needs to be applied in order to get anyware with sun4c for all kernels = linux-2.6.15. If not applied, you will be lucky to get sash running as your init and even that will have very limitit capabilities before it locks up the processor (power up reset required). It has been applied to both the kernels I used for testing so this problem is independent of the ptep_set_access_flags patch but that does not mean that it is not a related issue. I will try to get some testing done over the weekend to narrow down when the random illegal instructions first occour. If I start with 2.6.21 then if that is OK, then I should be able to narow the issue down without too much trouble. If it is between 2.6.20 and 2.6.21 then it will be a right pig as there are a large number of commits that don't compile for sun4c between these two. What I am hoping is that it occours in the 2.6.22-rc2 as per the x86_64. I am going to have to put a 'reset' button onto my test system as power up resets are bad news on this old hardware and almost all kernel failures result in a processor lockup. I have even had to make BUG reports 'panic' as thoes that I have during kernel fault location had are terminal to a sun4c (they cause a processor lockup). Regards Mark Fortescue. On Thu, 14 Jun 2007, William Lee Irwin III wrote: On Thu, Jun 14, 2007 at 11:30:25AM +0100, Mark Fortescue wrote: They apear as soon as simpleinit starts up. Somtimes I get to a login prompt before seeing any. Other times, commands in the simpleinit rc script fail. They do apear to be random. If a command failes, you re-run the command and it is OK. Commands seen to fail are basic (depmod, rm cat ..). The test I did use the same binaries with both the OK and problem kernels so it is not a change to the application code, it is definatly a kernel issue. This sounds like it may be addressed by benh's ptep_set_access_flags() fixes. Those fixes are still in -mm, hopefully to hit mainline by 2.6.22. -- wli - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi all, The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Regards Mark Fortescue. On Wed, 13 Jun 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Networking Subject: commit 9093bbb2d96d0184f037cea9b4e952a44ebe7c32 broke the bonding driver References : http://lkml.org/lkml/2007/6/13/65 Submitter : Dan Aloni <[EMAIL PROTECTED]> Handled-By : Stephen Hemminger <[EMAIL PROTECTED]> Status : Unknown Sparc64 Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <[EMAIL PROTECTED]> Handled-By : David Miller <[EMAIL PROTECTED]> Status : problem is being debugged Suspend Subject: hibernate(?) fails totally - regression References : http://lkml.org/lkml/2007/6/1/401 Submitter : David Greaves <[EMAIL PROTECTED]> Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Caused-By : Tejun Heo <[EMAIL PROTECTED]> commit 9666f4009c22f6520ac3fb8a19c9e32ab973e828 Status : problem is being debugged TTY Subject: OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 http://bugzilla.kernel.org/show_bug.cgi?id=8473 http://bugzilla.kernel.org/show_bug.cgi?id=8574 Submitter : Alex Riesen <[EMAIL PROTECTED]> Status : problem is being debugged x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita <[EMAIL PROTECTED]> Status : Unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/2] 2.6.22-rc4: known regressions v3
Hi all, The random seg faults on x86_64 is interesting as I have been getting random illegal instruction faults on sparc (sun4c) with 2.6.22-rc3. I have not yet tried to track it down. All I know at present is that it is not a problem on 2.6.20.9. Regards Mark Fortescue. On Wed, 13 Jun 2007, Michal Piotrowski wrote: Hi all, Here is a list of some known regressions in 2.6.22-rc4. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Networking Subject: commit 9093bbb2d96d0184f037cea9b4e952a44ebe7c32 broke the bonding driver References : http://lkml.org/lkml/2007/6/13/65 Submitter : Dan Aloni [EMAIL PROTECTED] Handled-By : Stephen Hemminger [EMAIL PROTECTED] Status : Unknown Sparc64 Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson [EMAIL PROTECTED] Handled-By : David Miller [EMAIL PROTECTED] Status : problem is being debugged Suspend Subject: hibernate(?) fails totally - regression References : http://lkml.org/lkml/2007/6/1/401 Submitter : David Greaves [EMAIL PROTECTED] Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED] commit 9666f4009c22f6520ac3fb8a19c9e32ab973e828 Status : problem is being debugged TTY Subject: OOPS (NULL pointer dereference) in v2.6.22-rc3 References : http://lkml.org/lkml/2007/6/1/389 http://bugzilla.kernel.org/show_bug.cgi?id=8473 http://bugzilla.kernel.org/show_bug.cgi?id=8574 Submitter : Alex Riesen [EMAIL PROTECTED] Status : problem is being debugged x86-64 Subject: x86-64 2.6.22-rc2 random segfaults References : http://lkml.org/lkml/2007/5/24/275 Submitter : Ioan Ionita [EMAIL PROTECTED] Status : Unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
Hi all,
I have added a from line, comment and signed-off-by line to the attached
patch file.
Regards
Mark Fortescue.
On Mon, 7 May 2007, David Miller wrote:
Regards
Mark Fortescue.
From: Mark Fortescue <[EMAIL PROTECTED]>
Date: Sun, 29 Apr 2007 23:00:29 +0100 (BST)
I have altered the patch as advised and I have attached it to prevent my
email client from making a mess of it.
The attached patch changes the interrupt enable sequence for the sunzilog
driver so that interrupts are not enabled untill after the interrupt
handler has been installed. If this is not done, some SS1 and SS2 sun4c
systems panic on un-handled interrupt before the handler gets installed
preventing boot.
It also adds in support for the ESCC version of the zilog chips. The ESCC
detection works but the FIFO enable may cause issues with modem and
receive character status. My interpretation of the SCC manual and the code
is that it sould be OK.
Your patch looks good, thanks for working on this. As other's
have mentioned you should provide a proper "Signed-off-by: "
line with your patch changelog as describe in
linux/Documentation/SubmittingPatches.
I wonder if there is a way to get rid of all of that MIE twiddling
logic during the probe.
The chicken-and-egg problem in this driver is that we need to get
all the chips mostly functional before we let the IRQ handler get
at the chips in the sunzilog_irq_chain. That list is setup very
early, so it isn't a datastructure problem.
One thing we could do is check in the IRQ handler is skip chips
which don't have their registers mapped yet.
But that'd put silly logic in the fast path of this driver, whereas
your solution does all of this out-of-line. So your patch is
probably the best.
Please resubmit with the proper "Signed-off-by: " line and I will
apply your patch, thanks!
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Fortescue <[EMAIL PROTECTED]>
This patch changes the interrupt enable sequence for the sunzilog driver
so that interrupts are not enabled untill after the interrupt handler has
been installed. If this is not done, some SS1 and SS2 sun4c systems panic
on un-handled interrupt before the handler gets installed preventing boot.
It also adds in support for the ESCC version of the zilog chips. The
changes mean that the FIFO will be enabled for ESCC versions of the
SCC UART. My interpretation of the SCC manual and the existing interrupt
handler code is that it sould be able to make good use of the FIFO without
issues.
Signed-off-by: Mark Fortescue <[EMAIL PROTECTED]>
---
diff -ruNpd linux-2.6.20.9/drivers/serial/sunzilog.c
linux-test/drivers/serial/sunzilog.c
--- linux-2.6.20.9/drivers/serial/sunzilog.c2007-04-28 15:02:39.0
+0100
+++ linux-test/drivers/serial/sunzilog.c2007-04-28 14:54:49.0
+0100
@@ -93,6 +100,8 @@ struct uart_sunzilog_port {
#define SUNZILOG_FLAG_REGS_HELD0x0040
#define SUNZILOG_FLAG_TX_STOPPED 0x0080
#define SUNZILOG_FLAG_TX_ACTIVE0x0100
+#define SUNZILOG_FLAG_ESCC 0x0200
+#define SUNZILOG_FLAG_ISR_HANDLER 0x0400
unsigned int cflag;
@@ -175,9 +184,11 @@ static void sunzilog_clear_fifo(struct z
/* This function must only be called when the TX is not busy. The UART
* port lock must be held and local interrupts disabled.
*/
-static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
+static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
{
int i;
+ int escc;
+ unsigned char r15;
/* Let pending transmits finish. */
for (i = 0; i < 1000; i++) {
@@ -230,11 +241,25 @@ static void __load_zsregs(struct zilog_c
write_zsreg(channel, R14, regs[R14]);
/* External status interrupt control. */
- write_zsreg(channel, R15, regs[R15]);
+ write_zsreg(channel, R15, (regs[R15] | WR7pEN) & ~FIFOEN);
+
+ /* ESCC Extension Register */
+ r15 = read_zsreg(channel, R15);
+ if (r15 & 0x01) {
+ write_zsreg(channel, R7, regs[R7p]);
+
+ /* External status interrupt and FIFO control. */
+ write_zsreg(channel, R15, regs[R15] & ~WR7pEN);
+ escc = 1;
+ } else {
+/* Clear FIFO bit case it is an issue */
+ regs[R15] &= ~FIFOEN;
+ escc = 0;
+ }
/* Reset external status interrupts. */
- write_zsreg(channel, R0, RES_EXT_INT);
- write_zsreg(channel, R0, RES_EXT_INT);
+ write_zsreg(channel, R0, RES_EXT_INT); /* First Latch */
+ write_zsreg(channel, R0, RES_EXT_INT); /* Second Latch */
/* Rewrite R3/R5, this time without enable
[PATCH] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
Hi all,
I have added a from line, comment and signed-off-by line to the attached
patch file.
Regards
Mark Fortescue.
On Mon, 7 May 2007, David Miller wrote:
Regards
Mark Fortescue.
From: Mark Fortescue [EMAIL PROTECTED]
Date: Sun, 29 Apr 2007 23:00:29 +0100 (BST)
I have altered the patch as advised and I have attached it to prevent my
email client from making a mess of it.
The attached patch changes the interrupt enable sequence for the sunzilog
driver so that interrupts are not enabled untill after the interrupt
handler has been installed. If this is not done, some SS1 and SS2 sun4c
systems panic on un-handled interrupt before the handler gets installed
preventing boot.
It also adds in support for the ESCC version of the zilog chips. The ESCC
detection works but the FIFO enable may cause issues with modem and
receive character status. My interpretation of the SCC manual and the code
is that it sould be OK.
Your patch looks good, thanks for working on this. As other's
have mentioned you should provide a proper Signed-off-by:
line with your patch changelog as describe in
linux/Documentation/SubmittingPatches.
I wonder if there is a way to get rid of all of that MIE twiddling
logic during the probe.
The chicken-and-egg problem in this driver is that we need to get
all the chips mostly functional before we let the IRQ handler get
at the chips in the sunzilog_irq_chain. That list is setup very
early, so it isn't a datastructure problem.
One thing we could do is check in the IRQ handler is skip chips
which don't have their registers mapped yet.
But that'd put silly logic in the fast path of this driver, whereas
your solution does all of this out-of-line. So your patch is
probably the best.
Please resubmit with the proper Signed-off-by: line and I will
apply your patch, thanks!
-
To unsubscribe from this list: send the line unsubscribe sparclinux in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Fortescue [EMAIL PROTECTED]
This patch changes the interrupt enable sequence for the sunzilog driver
so that interrupts are not enabled untill after the interrupt handler has
been installed. If this is not done, some SS1 and SS2 sun4c systems panic
on un-handled interrupt before the handler gets installed preventing boot.
It also adds in support for the ESCC version of the zilog chips. The
changes mean that the FIFO will be enabled for ESCC versions of the
SCC UART. My interpretation of the SCC manual and the existing interrupt
handler code is that it sould be able to make good use of the FIFO without
issues.
Signed-off-by: Mark Fortescue [EMAIL PROTECTED]
---
diff -ruNpd linux-2.6.20.9/drivers/serial/sunzilog.c
linux-test/drivers/serial/sunzilog.c
--- linux-2.6.20.9/drivers/serial/sunzilog.c2007-04-28 15:02:39.0
+0100
+++ linux-test/drivers/serial/sunzilog.c2007-04-28 14:54:49.0
+0100
@@ -93,6 +100,8 @@ struct uart_sunzilog_port {
#define SUNZILOG_FLAG_REGS_HELD0x0040
#define SUNZILOG_FLAG_TX_STOPPED 0x0080
#define SUNZILOG_FLAG_TX_ACTIVE0x0100
+#define SUNZILOG_FLAG_ESCC 0x0200
+#define SUNZILOG_FLAG_ISR_HANDLER 0x0400
unsigned int cflag;
@@ -175,9 +184,11 @@ static void sunzilog_clear_fifo(struct z
/* This function must only be called when the TX is not busy. The UART
* port lock must be held and local interrupts disabled.
*/
-static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
+static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
{
int i;
+ int escc;
+ unsigned char r15;
/* Let pending transmits finish. */
for (i = 0; i 1000; i++) {
@@ -230,11 +241,25 @@ static void __load_zsregs(struct zilog_c
write_zsreg(channel, R14, regs[R14]);
/* External status interrupt control. */
- write_zsreg(channel, R15, regs[R15]);
+ write_zsreg(channel, R15, (regs[R15] | WR7pEN) ~FIFOEN);
+
+ /* ESCC Extension Register */
+ r15 = read_zsreg(channel, R15);
+ if (r15 0x01) {
+ write_zsreg(channel, R7, regs[R7p]);
+
+ /* External status interrupt and FIFO control. */
+ write_zsreg(channel, R15, regs[R15] ~WR7pEN);
+ escc = 1;
+ } else {
+/* Clear FIFO bit case it is an issue */
+ regs[R15] = ~FIFOEN;
+ escc = 0;
+ }
/* Reset external status interrupts. */
- write_zsreg(channel, R0, RES_EXT_INT);
- write_zsreg(channel, R0, RES_EXT_INT);
+ write_zsreg(channel, R0, RES_EXT_INT); /* First Latch */
+ write_zsreg(channel, R0, RES_EXT_INT); /* Second Latch */
/* Rewrite R3/R5, this time without enables masked. */
write_zsreg(channel, R3, regs[R3]);
@@ -242,6 +267,8 @@ static
[TESTING NEEDED] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
Hi All,
This patch changes the interrupt enable sequence for the sunzilog driver
so that interrupts are not enabled untill after the interrupt handler has
been installed. If this is not done, some SS1 and SS2 sun4c systems panic
on un-handled interrupt before the handler gets installed preventing boot.
It also adds in support for the ESCC version of the zilog chips. The ESCC
detection works but the FIFO enable may cause issues with modem and
receive character status. My interpretation of the SCC manual and the code
is that it sould be OK.
###
I have been unable to fully test this patch as a kernel bug (introduced in
the transition from linux-2.6.14 to 2.6.15) prevents my SS1 clone and SS2
from doing anything more than running sash and even that is liable to
crash. They fail with a soft lockup, and in the 2.6.20.x kernels that are
relevent to this driver patch that I have tested, prevent a serial BREAK
from getting back to the boot prom so a power up reset is required.
---
diff -ruNpd linux-2.6.20.9/drivers/serial/sunzilog.c
linux-test/drivers/serial/sunzilog.c
--- linux-2.6.20.9/drivers/serial/sunzilog.c2007-04-28 15:02:39.0
+0100
+++ linux-test/drivers/serial/sunzilog.c2007-04-28 14:54:49.0
+0100
@@ -10,6 +10,13 @@
* work there.
*
* Copyright (C) 2002, 2006 David S. Miller ([EMAIL PROTECTED])
+ *
+ * Thu Apr 19 02:59:49 BST 2007
+ * Mark Fortescue ([EMAIL PROTECTED])
+ *
+ * Change R9 handling to ensure interrupts disabled when no
+ * interrupt handler else it breaks sun4c Sparcstations.
+ * Add in handling for ESCC chips (enables FIFO).
*/
#include
@@ -93,6 +100,8 @@ struct uart_sunzilog_port {
#define SUNZILOG_FLAG_REGS_HELD0x0040
#define SUNZILOG_FLAG_TX_STOPPED 0x0080
#define SUNZILOG_FLAG_TX_ACTIVE0x0100
+#define SUNZILOG_FLAG_ESCC 0x0200
+#define SUNZILOG_FLAG_ISR_HANDLER 0x0400
unsigned int cflag;
@@ -175,9 +184,11 @@ static void sunzilog_clear_fifo(struct z
/* This function must only be called when the TX is not busy. The UART
* port lock must be held and local interrupts disabled.
*/
-static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
+static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
{
int i;
+ int escc;
+ unsigned char r15;
/* Let pending transmits finish. */
for (i = 0; i < 1000; i++) {
@@ -230,11 +241,25 @@ static void __load_zsregs(struct zilog_c
write_zsreg(channel, R14, regs[R14]);
/* External status interrupt control. */
- write_zsreg(channel, R15, regs[R15]);
+ write_zsreg(channel, R15, (regs[R15] | WR7pEN) & ~FIFOEN);
+
+ /* ESCC Extension Register */
+ r15 = read_zsreg(channel, R15);
+ if (r15 & 0x01) {
+ write_zsreg(channel, R7, regs[R7p]);
+
+ /* External status interrupt and FIFO control. */
+ write_zsreg(channel, R15, regs[R15] & ~WR7pEN);
+ escc = 1;
+ } else {
+/* Clear FIFO bit case it is an issue */
+ regs[R15] &= ~FIFOEN;
+ escc = 0;
+ }
/* Reset external status interrupts. */
- write_zsreg(channel, R0, RES_EXT_INT);
- write_zsreg(channel, R0, RES_EXT_INT);
+ write_zsreg(channel, R0, RES_EXT_INT); /* First Latch */
+ write_zsreg(channel, R0, RES_EXT_INT); /* Second Latch */
/* Rewrite R3/R5, this time without enables masked. */
write_zsreg(channel, R3, regs[R3]);
@@ -242,6 +267,8 @@ static void __load_zsregs(struct zilog_c
/* Rewrite R1, this time without IRQ enabled masked. */
write_zsreg(channel, R1, regs[R1]);
+
+ return escc;
}
/* Reprogram the Zilog channel HW registers with the copies found in the
@@ -732,7 +759,7 @@ static void sunzilog_enable_ms(struct ua
up->curregs[R15] = new_reg;
/* NOTE: Not subject to 'transmitter active' rule. */
- write_zsreg(channel, R15, up->curregs[R15]);
+ write_zsreg(channel, R15, up->curregs[R15] & ~WR7pEN);
}
}
@@ -862,44 +889,44 @@ sunzilog_convert_to_zs(struct uart_sunzi
up->curregs[R14] = BRSRC | BRENAB;
/* Character size, stop bits, and parity. */
- up->curregs[3] &= ~RxN_MASK;
- up->curregs[5] &= ~TxN_MASK;
+ up->curregs[R3] &= ~RxN_MASK;
+ up->curregs[R5] &= ~TxN_MASK;
switch (cflag & CSIZE) {
case CS5:
- up->curregs[3] |= Rx5;
- up->curregs[5] |= Tx5;
+ up->curregs[R3] |= Rx5;
+ up->curregs[R5] |= Tx5;
up->parity_mask = 0x1f;
break;
case CS6:
- up->curregs[3] |= Rx6;
- up->curregs[5] |= Tx6;
+ up->
[TESTING NEEDED] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
Hi All,
This patch changes the interrupt enable sequence for the sunzilog driver
so that interrupts are not enabled untill after the interrupt handler has
been installed. If this is not done, some SS1 and SS2 sun4c systems panic
on un-handled interrupt before the handler gets installed preventing boot.
It also adds in support for the ESCC version of the zilog chips. The ESCC
detection works but the FIFO enable may cause issues with modem and
receive character status. My interpretation of the SCC manual and the code
is that it sould be OK.
###
I have been unable to fully test this patch as a kernel bug (introduced in
the transition from linux-2.6.14 to 2.6.15) prevents my SS1 clone and SS2
from doing anything more than running sash and even that is liable to
crash. They fail with a soft lockup, and in the 2.6.20.x kernels that are
relevent to this driver patch that I have tested, prevent a serial BREAK
from getting back to the boot prom so a power up reset is required.
---
diff -ruNpd linux-2.6.20.9/drivers/serial/sunzilog.c
linux-test/drivers/serial/sunzilog.c
--- linux-2.6.20.9/drivers/serial/sunzilog.c2007-04-28 15:02:39.0
+0100
+++ linux-test/drivers/serial/sunzilog.c2007-04-28 14:54:49.0
+0100
@@ -10,6 +10,13 @@
* work there.
*
* Copyright (C) 2002, 2006 David S. Miller ([EMAIL PROTECTED])
+ *
+ * Thu Apr 19 02:59:49 BST 2007
+ * Mark Fortescue ([EMAIL PROTECTED])
+ *
+ * Change R9 handling to ensure interrupts disabled when no
+ * interrupt handler else it breaks sun4c Sparcstations.
+ * Add in handling for ESCC chips (enables FIFO).
*/
#include linux/module.h
@@ -93,6 +100,8 @@ struct uart_sunzilog_port {
#define SUNZILOG_FLAG_REGS_HELD0x0040
#define SUNZILOG_FLAG_TX_STOPPED 0x0080
#define SUNZILOG_FLAG_TX_ACTIVE0x0100
+#define SUNZILOG_FLAG_ESCC 0x0200
+#define SUNZILOG_FLAG_ISR_HANDLER 0x0400
unsigned int cflag;
@@ -175,9 +184,11 @@ static void sunzilog_clear_fifo(struct z
/* This function must only be called when the TX is not busy. The UART
* port lock must be held and local interrupts disabled.
*/
-static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
+static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
{
int i;
+ int escc;
+ unsigned char r15;
/* Let pending transmits finish. */
for (i = 0; i 1000; i++) {
@@ -230,11 +241,25 @@ static void __load_zsregs(struct zilog_c
write_zsreg(channel, R14, regs[R14]);
/* External status interrupt control. */
- write_zsreg(channel, R15, regs[R15]);
+ write_zsreg(channel, R15, (regs[R15] | WR7pEN) ~FIFOEN);
+
+ /* ESCC Extension Register */
+ r15 = read_zsreg(channel, R15);
+ if (r15 0x01) {
+ write_zsreg(channel, R7, regs[R7p]);
+
+ /* External status interrupt and FIFO control. */
+ write_zsreg(channel, R15, regs[R15] ~WR7pEN);
+ escc = 1;
+ } else {
+/* Clear FIFO bit case it is an issue */
+ regs[R15] = ~FIFOEN;
+ escc = 0;
+ }
/* Reset external status interrupts. */
- write_zsreg(channel, R0, RES_EXT_INT);
- write_zsreg(channel, R0, RES_EXT_INT);
+ write_zsreg(channel, R0, RES_EXT_INT); /* First Latch */
+ write_zsreg(channel, R0, RES_EXT_INT); /* Second Latch */
/* Rewrite R3/R5, this time without enables masked. */
write_zsreg(channel, R3, regs[R3]);
@@ -242,6 +267,8 @@ static void __load_zsregs(struct zilog_c
/* Rewrite R1, this time without IRQ enabled masked. */
write_zsreg(channel, R1, regs[R1]);
+
+ return escc;
}
/* Reprogram the Zilog channel HW registers with the copies found in the
@@ -732,7 +759,7 @@ static void sunzilog_enable_ms(struct ua
up-curregs[R15] = new_reg;
/* NOTE: Not subject to 'transmitter active' rule. */
- write_zsreg(channel, R15, up-curregs[R15]);
+ write_zsreg(channel, R15, up-curregs[R15] ~WR7pEN);
}
}
@@ -862,44 +889,44 @@ sunzilog_convert_to_zs(struct uart_sunzi
up-curregs[R14] = BRSRC | BRENAB;
/* Character size, stop bits, and parity. */
- up-curregs[3] = ~RxN_MASK;
- up-curregs[5] = ~TxN_MASK;
+ up-curregs[R3] = ~RxN_MASK;
+ up-curregs[R5] = ~TxN_MASK;
switch (cflag CSIZE) {
case CS5:
- up-curregs[3] |= Rx5;
- up-curregs[5] |= Tx5;
+ up-curregs[R3] |= Rx5;
+ up-curregs[R5] |= Tx5;
up-parity_mask = 0x1f;
break;
case CS6:
- up-curregs[3] |= Rx6;
- up-curregs[5] |= Tx6;
+ up-curregs[R3] |= Rx6;
+ up-curregs[R5] |= Tx6;
up-parity_mask = 0x3f
Re: [TESTING NEEDED] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
I have altered the patch as advised and I have attached it to prevent my
email client from making a mess of it.
The attached patch changes the interrupt enable sequence for the sunzilog
driver so that interrupts are not enabled untill after the interrupt
handler has been installed. If this is not done, some SS1 and SS2 sun4c
systems panic on un-handled interrupt before the handler gets installed
preventing boot.
It also adds in support for the ESCC version of the zilog chips. The ESCC
detection works but the FIFO enable may cause issues with modem and
receive character status. My interpretation of the SCC manual and the code
is that it sould be OK.
---
Regards
Mark Fortescue.diff -ruNpd linux-2.6.20.9/drivers/serial/sunzilog.c
linux-test/drivers/serial/sunzilog.c
--- linux-2.6.20.9/drivers/serial/sunzilog.c2007-04-28 15:02:39.0
+0100
+++ linux-test/drivers/serial/sunzilog.c2007-04-28 14:54:49.0
+0100
@@ -93,6 +100,8 @@ struct uart_sunzilog_port {
#define SUNZILOG_FLAG_REGS_HELD0x0040
#define SUNZILOG_FLAG_TX_STOPPED 0x0080
#define SUNZILOG_FLAG_TX_ACTIVE0x0100
+#define SUNZILOG_FLAG_ESCC 0x0200
+#define SUNZILOG_FLAG_ISR_HANDLER 0x0400
unsigned int cflag;
@@ -175,9 +184,11 @@ static void sunzilog_clear_fifo(struct z
/* This function must only be called when the TX is not busy. The UART
* port lock must be held and local interrupts disabled.
*/
-static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
+static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
{
int i;
+ int escc;
+ unsigned char r15;
/* Let pending transmits finish. */
for (i = 0; i < 1000; i++) {
@@ -230,11 +241,25 @@ static void __load_zsregs(struct zilog_c
write_zsreg(channel, R14, regs[R14]);
/* External status interrupt control. */
- write_zsreg(channel, R15, regs[R15]);
+ write_zsreg(channel, R15, (regs[R15] | WR7pEN) & ~FIFOEN);
+
+ /* ESCC Extension Register */
+ r15 = read_zsreg(channel, R15);
+ if (r15 & 0x01) {
+ write_zsreg(channel, R7, regs[R7p]);
+
+ /* External status interrupt and FIFO control. */
+ write_zsreg(channel, R15, regs[R15] & ~WR7pEN);
+ escc = 1;
+ } else {
+/* Clear FIFO bit case it is an issue */
+ regs[R15] &= ~FIFOEN;
+ escc = 0;
+ }
/* Reset external status interrupts. */
- write_zsreg(channel, R0, RES_EXT_INT);
- write_zsreg(channel, R0, RES_EXT_INT);
+ write_zsreg(channel, R0, RES_EXT_INT); /* First Latch */
+ write_zsreg(channel, R0, RES_EXT_INT); /* Second Latch */
/* Rewrite R3/R5, this time without enables masked. */
write_zsreg(channel, R3, regs[R3]);
@@ -242,6 +267,8 @@ static void __load_zsregs(struct zilog_c
/* Rewrite R1, this time without IRQ enabled masked. */
write_zsreg(channel, R1, regs[R1]);
+
+ return escc;
}
/* Reprogram the Zilog channel HW registers with the copies found in the
@@ -732,7 +759,7 @@ static void sunzilog_enable_ms(struct ua
up->curregs[R15] = new_reg;
/* NOTE: Not subject to 'transmitter active' rule. */
- write_zsreg(channel, R15, up->curregs[R15]);
+ write_zsreg(channel, R15, up->curregs[R15] & ~WR7pEN);
}
}
@@ -862,44 +889,44 @@ sunzilog_convert_to_zs(struct uart_sunzi
up->curregs[R14] = BRSRC | BRENAB;
/* Character size, stop bits, and parity. */
- up->curregs[3] &= ~RxN_MASK;
- up->curregs[5] &= ~TxN_MASK;
+ up->curregs[R3] &= ~RxN_MASK;
+ up->curregs[R5] &= ~TxN_MASK;
switch (cflag & CSIZE) {
case CS5:
- up->curregs[3] |= Rx5;
- up->curregs[5] |= Tx5;
+ up->curregs[R3] |= Rx5;
+ up->curregs[R5] |= Tx5;
up->parity_mask = 0x1f;
break;
case CS6:
- up->curregs[3] |= Rx6;
- up->curregs[5] |= Tx6;
+ up->curregs[R3] |= Rx6;
+ up->curregs[R5] |= Tx6;
up->parity_mask = 0x3f;
break;
case CS7:
- up->curregs[3] |= Rx7;
- up->curregs[5] |= Tx7;
+ up->curregs[R3] |= Rx7;
+ up->curregs[R5] |= Tx7;
up->parity_mask = 0x7f;
break;
case CS8:
default:
- up->curregs[3] |= Rx8;
- up->curregs[5] |= Tx8;
+ up->curregs[R3] |= Rx8;
+ up->curregs[R5] |= Tx8;
up->parity_mask = 0xff;
break;
};
- up->curregs[4] &= ~0x0c;
+ up->curregs[R4] &= ~0x0c;
if (cflag & CSTOPB)
-
Re: [TESTING NEEDED] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
I have altered the patch as advised and I have attached it to prevent my
email client from making a mess of it.
The attached patch changes the interrupt enable sequence for the sunzilog
driver so that interrupts are not enabled untill after the interrupt
handler has been installed. If this is not done, some SS1 and SS2 sun4c
systems panic on un-handled interrupt before the handler gets installed
preventing boot.
It also adds in support for the ESCC version of the zilog chips. The ESCC
detection works but the FIFO enable may cause issues with modem and
receive character status. My interpretation of the SCC manual and the code
is that it sould be OK.
---
Regards
Mark Fortescue.diff -ruNpd linux-2.6.20.9/drivers/serial/sunzilog.c
linux-test/drivers/serial/sunzilog.c
--- linux-2.6.20.9/drivers/serial/sunzilog.c2007-04-28 15:02:39.0
+0100
+++ linux-test/drivers/serial/sunzilog.c2007-04-28 14:54:49.0
+0100
@@ -93,6 +100,8 @@ struct uart_sunzilog_port {
#define SUNZILOG_FLAG_REGS_HELD0x0040
#define SUNZILOG_FLAG_TX_STOPPED 0x0080
#define SUNZILOG_FLAG_TX_ACTIVE0x0100
+#define SUNZILOG_FLAG_ESCC 0x0200
+#define SUNZILOG_FLAG_ISR_HANDLER 0x0400
unsigned int cflag;
@@ -175,9 +184,11 @@ static void sunzilog_clear_fifo(struct z
/* This function must only be called when the TX is not busy. The UART
* port lock must be held and local interrupts disabled.
*/
-static void __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
+static int __load_zsregs(struct zilog_channel __iomem *channel, unsigned char
*regs)
{
int i;
+ int escc;
+ unsigned char r15;
/* Let pending transmits finish. */
for (i = 0; i 1000; i++) {
@@ -230,11 +241,25 @@ static void __load_zsregs(struct zilog_c
write_zsreg(channel, R14, regs[R14]);
/* External status interrupt control. */
- write_zsreg(channel, R15, regs[R15]);
+ write_zsreg(channel, R15, (regs[R15] | WR7pEN) ~FIFOEN);
+
+ /* ESCC Extension Register */
+ r15 = read_zsreg(channel, R15);
+ if (r15 0x01) {
+ write_zsreg(channel, R7, regs[R7p]);
+
+ /* External status interrupt and FIFO control. */
+ write_zsreg(channel, R15, regs[R15] ~WR7pEN);
+ escc = 1;
+ } else {
+/* Clear FIFO bit case it is an issue */
+ regs[R15] = ~FIFOEN;
+ escc = 0;
+ }
/* Reset external status interrupts. */
- write_zsreg(channel, R0, RES_EXT_INT);
- write_zsreg(channel, R0, RES_EXT_INT);
+ write_zsreg(channel, R0, RES_EXT_INT); /* First Latch */
+ write_zsreg(channel, R0, RES_EXT_INT); /* Second Latch */
/* Rewrite R3/R5, this time without enables masked. */
write_zsreg(channel, R3, regs[R3]);
@@ -242,6 +267,8 @@ static void __load_zsregs(struct zilog_c
/* Rewrite R1, this time without IRQ enabled masked. */
write_zsreg(channel, R1, regs[R1]);
+
+ return escc;
}
/* Reprogram the Zilog channel HW registers with the copies found in the
@@ -732,7 +759,7 @@ static void sunzilog_enable_ms(struct ua
up-curregs[R15] = new_reg;
/* NOTE: Not subject to 'transmitter active' rule. */
- write_zsreg(channel, R15, up-curregs[R15]);
+ write_zsreg(channel, R15, up-curregs[R15] ~WR7pEN);
}
}
@@ -862,44 +889,44 @@ sunzilog_convert_to_zs(struct uart_sunzi
up-curregs[R14] = BRSRC | BRENAB;
/* Character size, stop bits, and parity. */
- up-curregs[3] = ~RxN_MASK;
- up-curregs[5] = ~TxN_MASK;
+ up-curregs[R3] = ~RxN_MASK;
+ up-curregs[R5] = ~TxN_MASK;
switch (cflag CSIZE) {
case CS5:
- up-curregs[3] |= Rx5;
- up-curregs[5] |= Tx5;
+ up-curregs[R3] |= Rx5;
+ up-curregs[R5] |= Tx5;
up-parity_mask = 0x1f;
break;
case CS6:
- up-curregs[3] |= Rx6;
- up-curregs[5] |= Tx6;
+ up-curregs[R3] |= Rx6;
+ up-curregs[R5] |= Tx6;
up-parity_mask = 0x3f;
break;
case CS7:
- up-curregs[3] |= Rx7;
- up-curregs[5] |= Tx7;
+ up-curregs[R3] |= Rx7;
+ up-curregs[R5] |= Tx7;
up-parity_mask = 0x7f;
break;
case CS8:
default:
- up-curregs[3] |= Rx8;
- up-curregs[5] |= Tx8;
+ up-curregs[R3] |= Rx8;
+ up-curregs[R5] |= Tx8;
up-parity_mask = 0xff;
break;
};
- up-curregs[4] = ~0x0c;
+ up-curregs[R4] = ~0x0c;
if (cflag CSTOPB)
- up-curregs[4] |= SB2;
+
Re: Can't use SYSFS for "Proprietry" driver modules !!!.
Hi Greg, If you read the Linux Kernel header file "linux/module.h", there is a section about Licenses. If "Proprietary" licences are not leagal, then why are they supported ? The implication of providing support for them in the header file is that it is leagal to create and supply them. I am porting a driver to Linux for a third party. I do not know if they whish to release the Linux driver under GPL so I have assumed (because of the nature of the hardware) that they do not whish to. I will discus this matter with them when I have finnished the driver. The use of header files to build a propriatory object files/binaries or the use of GCC to compile such a file does not breach GPL as if it did, GCC and GLIBC would not be available for non GPL platforms and it would not be posible to provide propriatory code for use in a Linux/GNU environment. The Linux Kernel internal APIs are not mensioned in the Kernel GPL so it can be argued quite reasonably that the APIs are not coverd by the GPL. With regard to derived work - mensioned in a number of responses, a new driver ported from MS Windows is derived from the Windows Driver not the Linux Kernel. If it can be shown that there are sections of code in the new driver that have been coppied from other Linux drivers, then there is a good argument with regard to derived code but it would still be very difficult to prove that this code had not been written totally independantly from the Linux drivers containing the same or similar code. In addition the driver is being built as a module, out side of the kernel source tree and as a result can be considered to be separate enterty to the kernel. If it was required to be built into the kernel as apposed to being a Kernel Module then it would be totally different and the driver would need to be GPL. The hardware that this driver is being written for is low volume, very specialised (with regard to its application). The driver will only be of interest to thoes who have or can aford to purchase this hardware and are in an appropriate buisiness sector. Given this, I see little point in making the driver GPL as the code will be of little interest to anyone who will not already have access to it through the supplier of the hardware it is written for. For thoes writing Linux drivers, there are a number of Books that can be read on this subject. The Linux Kernel used with the driver will be probably purchesed independently as part of a standard Linux distribution. As I am not changing any of that code, I am not in breach of the GPL associated with that code. A device driver may or may not be derived from other drivers in the Linux Kernel. In this case it is not so it is not covered by the Kernel GPL. If the customer requires a linux kernel then I will be quite happy to provide one configured to meet their requirements with all the source code (as available from the various ftp mirrors) and any private patches I may have applied, as per the terms and conditions in the "COPYING" file in the kernel source tree. I wait with interest for your comments. Regards Mark Fortescue. On Sat, 26 Mar 2005, Greg KH wrote: > On Sat, Mar 26, 2005 at 05:52:20PM +, Mark Fortescue wrote: > > > > I am writing a "Proprietry" driver module for a "Proprietry" PCI card and > > I have found that I can't use SYSFS on Linux-2.6.10. > > > > Why ?. > > What ever gave you the impression that it was legal to create a > "Proprietry" kernel driver for Linux in the first place. I seriously > encourage you to consult your company's legal department if you insist > on attempting to do this, as they will be contacted by others after your > driver is released. > > > I am not modifing the Kernel/SYSFS code so I should be able, to use all > > the SYSFS/internal kernel function calls without hinderence. > > I'm sorry, but as you have found out, that is not possible. > > > I believe that this sort of idiocy is what helps Microsoft hold on to its > > manopoly and as shuch hinders hardware/software development in all areas > > and should be chanaged in a way that promotes diversified software > > development. > > If your company does not agree with the current license of the Linux > kernel, which prevents you from creating "Proprietry" drivers, then do > not write or create such drivers in the first place. We (the kernel > community) are not forcing you to write a Linux driver. > > However, if you do wish to create a Linux driver, you _must_ abide by > the legal requirements of the kernel, which I feel, along with every IP > lawyer I have ever consulted, that it is not allowed to create a non-GPL > compatible kernel module. > > Good luck, > > greg k-h > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can't use SYSFS for Proprietry driver modules !!!.
Hi Greg, If you read the Linux Kernel header file linux/module.h, there is a section about Licenses. If Proprietary licences are not leagal, then why are they supported ? The implication of providing support for them in the header file is that it is leagal to create and supply them. I am porting a driver to Linux for a third party. I do not know if they whish to release the Linux driver under GPL so I have assumed (because of the nature of the hardware) that they do not whish to. I will discus this matter with them when I have finnished the driver. The use of header files to build a propriatory object files/binaries or the use of GCC to compile such a file does not breach GPL as if it did, GCC and GLIBC would not be available for non GPL platforms and it would not be posible to provide propriatory code for use in a Linux/GNU environment. The Linux Kernel internal APIs are not mensioned in the Kernel GPL so it can be argued quite reasonably that the APIs are not coverd by the GPL. With regard to derived work - mensioned in a number of responses, a new driver ported from MS Windows is derived from the Windows Driver not the Linux Kernel. If it can be shown that there are sections of code in the new driver that have been coppied from other Linux drivers, then there is a good argument with regard to derived code but it would still be very difficult to prove that this code had not been written totally independantly from the Linux drivers containing the same or similar code. In addition the driver is being built as a module, out side of the kernel source tree and as a result can be considered to be separate enterty to the kernel. If it was required to be built into the kernel as apposed to being a Kernel Module then it would be totally different and the driver would need to be GPL. The hardware that this driver is being written for is low volume, very specialised (with regard to its application). The driver will only be of interest to thoes who have or can aford to purchase this hardware and are in an appropriate buisiness sector. Given this, I see little point in making the driver GPL as the code will be of little interest to anyone who will not already have access to it through the supplier of the hardware it is written for. For thoes writing Linux drivers, there are a number of Books that can be read on this subject. The Linux Kernel used with the driver will be probably purchesed independently as part of a standard Linux distribution. As I am not changing any of that code, I am not in breach of the GPL associated with that code. A device driver may or may not be derived from other drivers in the Linux Kernel. In this case it is not so it is not covered by the Kernel GPL. If the customer requires a linux kernel then I will be quite happy to provide one configured to meet their requirements with all the source code (as available from the various ftp mirrors) and any private patches I may have applied, as per the terms and conditions in the COPYING file in the kernel source tree. I wait with interest for your comments. Regards Mark Fortescue. On Sat, 26 Mar 2005, Greg KH wrote: On Sat, Mar 26, 2005 at 05:52:20PM +, Mark Fortescue wrote: I am writing a Proprietry driver module for a Proprietry PCI card and I have found that I can't use SYSFS on Linux-2.6.10. Why ?. What ever gave you the impression that it was legal to create a Proprietry kernel driver for Linux in the first place. I seriously encourage you to consult your company's legal department if you insist on attempting to do this, as they will be contacted by others after your driver is released. I am not modifing the Kernel/SYSFS code so I should be able, to use all the SYSFS/internal kernel function calls without hinderence. I'm sorry, but as you have found out, that is not possible. I believe that this sort of idiocy is what helps Microsoft hold on to its manopoly and as shuch hinders hardware/software development in all areas and should be chanaged in a way that promotes diversified software development. If your company does not agree with the current license of the Linux kernel, which prevents you from creating Proprietry drivers, then do not write or create such drivers in the first place. We (the kernel community) are not forcing you to write a Linux driver. However, if you do wish to create a Linux driver, you _must_ abide by the legal requirements of the kernel, which I feel, along with every IP lawyer I have ever consulted, that it is not allowed to create a non-GPL compatible kernel module. Good luck, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't use SYSFS for "Proprietry" driver modules !!!.
Hi, I am writing a "Proprietry" driver module for a "Proprietry" PCI card and I have found that I can't use SYSFS on Linux-2.6.10. Why ?. I am not modifing the Kernel/SYSFS code so I should be able, to use all the SYSFS/internal kernel function calls without hinderence. In order to be able to use SYSFS to debug the driver during development the way I would like to be able to do, I will have to temporally change the module licence line to "GPL". When the development is finnished I will then need to remove all the code that accesses the SYSFS stuf in the Kernel and change the module back to a "Proprietry" licence in order to comply with other requirements. This will then hinder any debugging if future issues arise. I believe that this sort of idiocy is what helps Microsoft hold on to its manopoly and as shuch hinders hardware/software development in all areas and should be chanaged in a way that promotes diversified software development. Regards Mark Fortescue. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Can't use SYSFS for Proprietry driver modules !!!.
Hi, I am writing a Proprietry driver module for a Proprietry PCI card and I have found that I can't use SYSFS on Linux-2.6.10. Why ?. I am not modifing the Kernel/SYSFS code so I should be able, to use all the SYSFS/internal kernel function calls without hinderence. In order to be able to use SYSFS to debug the driver during development the way I would like to be able to do, I will have to temporally change the module licence line to GPL. When the development is finnished I will then need to remove all the code that accesses the SYSFS stuf in the Kernel and change the module back to a Proprietry licence in order to comply with other requirements. This will then hinder any debugging if future issues arise. I believe that this sort of idiocy is what helps Microsoft hold on to its manopoly and as shuch hinders hardware/software development in all areas and should be chanaged in a way that promotes diversified software development. Regards Mark Fortescue. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues.
Hi, Sorry for the trouble. I have worked out what is going on. I have been using Cygwin, but I has assumed incorrectly that MS WindowsXP SP2, like MS Windows 2000, honered mixed case filenames correctly. This is not the case making MS WindowsXP SP2 Pro non POSIX complient (what a supprise). A quick google search sugests that I am not the only person to have issues with this. Is there any chance that at some point in the future, the kernel filenames will be changed so that dumb OS like MS Windows don't mess it all up ? Regards Mark Fortescue. On Fri, 25 Feb 2005, Tim Schmielau wrote: > On Fri, 25 Feb 2005, Mark Fortescue wrote: > > > The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be > > correct. I had some errors during patching so I generated a diff against a > > freshly downloaded linux-2.6.10 kernel. See the steps below: > > > > 1) bzcat linux-2.6.8.1.tar.bz2 | tar -xf - > > 2) cd linux-2.6.8.1 > > 3) bzcat ../patch-2.6.8.1.bz2 | patch -R -p1 > > This gives a 2.6.8 kernel. > > > > 4) bzcat ../patch-2.6.9.bz2 | patch -p1 > > This should give a 2.6.9 kernel. The patch has two errors: > > ./net/ipv4/netfilter/ipt_ecn.c.rej > > ./net/ipv4/netfilter/ipt_tcpmss.c.rej > > > > 5) bzcat ../patch-2.6.10.bz2 | patch -p1 -f > > This should give a 2.6.10 kernel. The patch has three erros: > > ./include/linux/netfilter_ipv4/ipt_connmark.h.rej > > ./net/ipv4/netfilter/ipt_connmark.c.rej > > ./net/ipv6/netfilter/ip6t_MARK.c.rej > > 6) cd ..; mv linux-2.6.8.1 linux-2.6.10p > > 7) bzcat linux-2.6.10.tar.bz2 | tar -xf - > > 8) diff -rupN linux-2.6.10p linux-2.6.10 | tee patch-2.6.10.err > > Yes, these steps should work. Actually, I just checked (copy & paste the > commands from your mail), and it works for me. > > Are you sure your files are ok? md5sums for my copies of the files are > > cffcd2919d9c8ef793ce1ac07a440eda linux-2.6.10.tar.bz2 > 98f93075c7c24e681eaf7e70783af5e4 linux-2.6.8.1.tar.gz > 98b7db13a3f13199a48e89a79d2ee388 patch-2.6.10.bz2 > 824b7d88ab2fabc031f1a6c1e6e288ee patch-2.6.8.1.bz2 > fe744cdcd31b97b803e51ad785520489 patch-2.6.9.bz2 > > Are you sure your filesystem works ok? Not out of quota? > > Tim > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues.
e,
- const struct ipt_ip *ip,
87,92
- info->invert, hotdrop);
- }
-
- static int
- checkentry(const char *tablename,
- const struct ipt_ip *ip,
diff -rupN linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.orig
linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.orig
--- linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.orig 2004-08-14
11:56:25.0 +0100
+++ linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.orig1970-01-01
00:00:00.0 +
@@ -1,67 +0,0 @@
-/* Kernel module to match NFMARK values. */
-
-/* (C) 1999-2001 Marc Boucher <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-
-#include
-#include
-
-#include
-#include
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Netfilter Core Team <[EMAIL PROTECTED]>");
-MODULE_DESCRIPTION("ip6tables mark match");
-
-static int
-match(const struct sk_buff *skb,
- const struct net_device *in,
- const struct net_device *out,
- const void *matchinfo,
- int offset,
- const void *hdr,
- u_int16_t datalen,
- int *hotdrop)
-{
- const struct ip6t_mark_info *info = matchinfo;
-
- return ((skb->nfmark & info->mask) == info->mark) ^ info->invert;
-}
-
-static int
-checkentry(const char *tablename,
- const struct ip6t_ip6 *ip,
- void *matchinfo,
- unsigned int matchsize,
- unsigned int hook_mask)
-{
- if (matchsize != IP6T_ALIGN(sizeof(struct ip6t_mark_info)))
- return 0;
-
- return 1;
-}
-
-static struct ip6t_match mark_match = {
- .name = "mark",
- .match = ,
- .checkentry = ,
- .me = THIS_MODULE,
-};
-
-static int __init init(void)
-{
- return ip6t_register_match(_match);
-}
-
-static void __exit fini(void)
-{
- ip6t_unregister_match(_match);
-}
-
-module_init(init);
-module_exit(fini);
diff -rupN linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.rej
linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.rej
--- linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.rej2005-02-25
16:06:04.78125 +
+++ linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.rej 1970-01-01
00:00:00.0 +
@@ -1,21 +0,0 @@
-***
-*** 20,28
-
- static unsigned int
- target(struct sk_buff **pskb,
--unsigned int hooknum,
- const struct net_device *in,
- const struct net_device *out,
- const void *targinfo,
- void *userinfo)
- {
20,28
-
- static unsigned int
- target(struct sk_buff **pskb,
- const struct net_device *in,
- const struct net_device *out,
-+unsigned int hooknum,
- const void *targinfo,
- void *userinfo)
- {
Regards
Mark Fortescue.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues.
(mark_match);
-}
-
-static void __exit fini(void)
-{
- ip6t_unregister_match(mark_match);
-}
-
-module_init(init);
-module_exit(fini);
diff -rupN linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.rej
linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.rej
--- linux-2.6.10p/net/ipv6/netfilter/ip6t_MARK.c.rej2005-02-25
16:06:04.78125 +
+++ linux-2.6.10/net/ipv6/netfilter/ip6t_MARK.c.rej 1970-01-01
00:00:00.0 +
@@ -1,21 +0,0 @@
-***
-*** 20,28
-
- static unsigned int
- target(struct sk_buff **pskb,
--unsigned int hooknum,
- const struct net_device *in,
- const struct net_device *out,
- const void *targinfo,
- void *userinfo)
- {
20,28
-
- static unsigned int
- target(struct sk_buff **pskb,
- const struct net_device *in,
- const struct net_device *out,
-+unsigned int hooknum,
- const void *targinfo,
- void *userinfo)
- {
Regards
Mark Fortescue.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.6.8.1 to linux-2.6.10: Kernel Patching Issues.
Hi, Sorry for the trouble. I have worked out what is going on. I have been using Cygwin, but I has assumed incorrectly that MS WindowsXP SP2, like MS Windows 2000, honered mixed case filenames correctly. This is not the case making MS WindowsXP SP2 Pro non POSIX complient (what a supprise). A quick google search sugests that I am not the only person to have issues with this. Is there any chance that at some point in the future, the kernel filenames will be changed so that dumb OS like MS Windows don't mess it all up ? Regards Mark Fortescue. On Fri, 25 Feb 2005, Tim Schmielau wrote: On Fri, 25 Feb 2005, Mark Fortescue wrote: The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be correct. I had some errors during patching so I generated a diff against a freshly downloaded linux-2.6.10 kernel. See the steps below: 1) bzcat linux-2.6.8.1.tar.bz2 | tar -xf - 2) cd linux-2.6.8.1 3) bzcat ../patch-2.6.8.1.bz2 | patch -R -p1 This gives a 2.6.8 kernel. 4) bzcat ../patch-2.6.9.bz2 | patch -p1 This should give a 2.6.9 kernel. The patch has two errors: ./net/ipv4/netfilter/ipt_ecn.c.rej ./net/ipv4/netfilter/ipt_tcpmss.c.rej 5) bzcat ../patch-2.6.10.bz2 | patch -p1 -f This should give a 2.6.10 kernel. The patch has three erros: ./include/linux/netfilter_ipv4/ipt_connmark.h.rej ./net/ipv4/netfilter/ipt_connmark.c.rej ./net/ipv6/netfilter/ip6t_MARK.c.rej 6) cd ..; mv linux-2.6.8.1 linux-2.6.10p 7) bzcat linux-2.6.10.tar.bz2 | tar -xf - 8) diff -rupN linux-2.6.10p linux-2.6.10 | tee patch-2.6.10.err Yes, these steps should work. Actually, I just checked (copy paste the commands from your mail), and it works for me. Are you sure your files are ok? md5sums for my copies of the files are cffcd2919d9c8ef793ce1ac07a440eda linux-2.6.10.tar.bz2 98f93075c7c24e681eaf7e70783af5e4 linux-2.6.8.1.tar.gz 98b7db13a3f13199a48e89a79d2ee388 patch-2.6.10.bz2 824b7d88ab2fabc031f1a6c1e6e288ee patch-2.6.8.1.bz2 fe744cdcd31b97b803e51ad785520489 patch-2.6.9.bz2 Are you sure your filesystem works ok? Not out of quota? Tim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
