Adding relevant people and lists to CC...
Honza
----- Forwarded message from Anders Henke <[email protected]> -----
Date: Thu, 29 Nov 2007 13:31:50 +0100
From: Anders Henke <[email protected]>
To: [email protected]
Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
User-Agent: Mutt/1.5.13 (2006-08-11)
On November 28 2007, Anders Henke wrote:
> As "everything is reported as being zero" is quite odd an Jan took a
> guess that it might be block-layer or driver-related, I've assumed
> that the driver is responsible for this; just out of the curiousity,
> I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
> driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
> vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
>
> I haven't yet fine-tested from which kernel release on the dpt_i2o driver
> behaves like this and spews out zeroed blocks when trying to mount
> the rootfs. Maybe this is just some timing issue.
I've started the fine-tests and can say so far that dpt_i2o from
2.6.22 is still fine. Test is simple:
anders@ista:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
... recompile the kernel, reboot: works.
2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
patch sets:
-one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
-one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
-one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
When applying the 2.6.23-rc1-based driver to "my" 2.6.31.1 kernel,
the "zero blocks"-symptom show up, so it's the "lucky" situation
that the smallest patch actually seams to be the broken one.
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer accessors
Stephen Rothwell
dpt_i2o depends on virt_to_bus
Fujita, would you please take a look at this?
I think that something's broken in there, leading to the dpt_i2o
sending out blocks of zeroes right after initialization, at least on
some specific controllers (in this case, Adaptec 2010S on Intel
SE7501WV2S-based boxes).
I don't have insight kernel driver development knowledge, so I'm
quite out of help right now. Nevertheless, I'll add the diff
from 2.6.22 to 2.6.23-rc1 in terms of dpt_i2o:
---cut
diff -Nur linux-2.6.22/drivers/scsi/dpt_i2o.c linux-2.6.23-rc1/drivers/scsi/dpt_i2o.c
--- linux-2.6.22/drivers/scsi/dpt_i2o.c 2007-07-09 01:32:17.000000000 +0200
+++ linux-2.6.23-rc1/drivers/scsi/dpt_i2o.c 2007-07-22 22:41:00.000000000 +0200
@@ -2078,12 +2078,13 @@
u32 *lenptr;
int direction;
int scsidir;
+ int nseg;
u32 len;
u32 reqlen;
s32 rcode;
memset(msg, 0 , sizeof(msg));
- len = cmd->request_bufflen;
+ len = scsi_bufflen(cmd);
direction = 0x00000000;
scsidir = 0x00000000; // DATA NO XFER
@@ -2140,21 +2141,21 @@
lenptr=mptr++; /* Remember me - fill in when we know */
reqlen = 14; // SINGLE SGE
/* Now fill in the SGList and command */
- if(cmd->use_sg) {
- struct scatterlist *sg = (struct scatterlist *)cmd->request_buffer;
- int sg_count = pci_map_sg(pHba->pDev, sg, cmd->use_sg,
- cmd->sc_data_direction);
+ nseg = scsi_dma_map(cmd);
+ BUG_ON(nseg < 0);
+ if (nseg) {
+ struct scatterlist *sg;
len = 0;
- for(i = 0 ; i < sg_count; i++) {
+ scsi_for_each_sg(cmd, sg, nseg, i) {
*mptr++ = direction|0x10000000|sg_dma_len(sg);
len+=sg_dma_len(sg);
*mptr++ = sg_dma_address(sg);
- sg++;
+ /* Make this an end of list */
+ if (i == nseg - 1)
+ mptr[-2] = direction|0xD0000000|sg_dma_len(sg);
}
- /* Make this an end of list */
- mptr[-2] = direction|0xD0000000|sg_dma_len(sg-1);
reqlen = mptr - msg;
*lenptr = len;
@@ -2163,16 +2164,8 @@
len, cmd->underflow);
}
} else {
- *lenptr = len = cmd->request_bufflen;
- if(len == 0) {
- reqlen = 12;
- } else {
- *mptr++ = 0xD0000000|direction|cmd->request_bufflen;
- *mptr++ = pci_map_single(pHba->pDev,
- cmd->request_buffer,
- cmd->request_bufflen,
- cmd->sc_data_direction);
- }
+ *lenptr = len = 0;
+ reqlen = 12;
}
/* Stick the headers on */
@@ -2232,7 +2225,7 @@
hba_status = detailed_status >> 8;
// calculate resid for sg
- cmd->resid = cmd->request_bufflen - readl(reply+5);
+ scsi_set_resid(cmd, scsi_bufflen(cmd) - readl(reply+5));
pHba = (adpt_hba*) cmd->device->host->hostdata[0];
---cut
Personally I guess that it's the large drop from lines 2164 on
that's broken, who replaces a mapping routine by some static assignment.
Regards,
Anders
--
1&1 Internet AG System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
On Thu, 29 Nov 2007 14:03:19 +0100
Jan Kara <[email protected]> wrote:
> Adding relevant people and lists to CC...
>
> Honza
>
> ----- Forwarded message from Anders Henke <[email protected]> -----
>
> Date: Thu, 29 Nov 2007 13:31:50 +0100
> From: Anders Henke <[email protected]>
> To: [email protected]
> Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
> User-Agent: Mutt/1.5.13 (2006-08-11)
>
> On November 28 2007, Anders Henke wrote:
> > As "everything is reported as being zero" is quite odd an Jan took a
> > guess that it might be block-layer or driver-related, I've assumed
> > that the driver is responsible for this; just out of the curiousity,
> > I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
> > driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
> > vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
> >
> > I haven't yet fine-tested from which kernel release on the dpt_i2o driver
> > behaves like this and spews out zeroed blocks when trying to mount
> > the rootfs. Maybe this is just some timing issue.
>
> I've started the fine-tests and can say so far that dpt_i2o from
> 2.6.22 is still fine. Test is simple:
>
> anders@ista:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
>
> ... recompile the kernel, reboot: works.
>
> 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
> patch sets:
> -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
> -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
> -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
>
> When applying the 2.6.23-rc1-based driver to "my" 2.6.31.1 kernel,
> the "zero blocks"-symptom show up, so it's the "lucky" situation
> that the smallest patch actually seams to be the broken one.
>
> According to the 2.6.23-rc1 short-form changelog, there is
> one major edit on the dpt_i2o driver:
>
> FUJITA Tomonori
>
> [SCSI] dpt_i2o: convert to use the data buffer accessors
>
> Stephen Rothwell
> dpt_i2o depends on virt_to_bus
>
> Fujita, would you please take a look at this?
Sorry about the bug. Can you try this?
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 8258506..1255b26 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
.this_id = 7,
.cmd_per_lun = 1,
.use_clustering = ENABLE_CLUSTERING,
- .use_sg_chaining = ENABLE_SG_CHAINING,
+ .use_sg_chaining = DISABLE_SG_CHAINING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
On Nov 29 2007, FUJITA Tomonori wrote:
> On Thu, 29 Nov 2007 14:03:19 +0100
> Jan Kara <[email protected]> wrote:
>
> > Adding relevant people and lists to CC...
> >
> > Honza
> >
> > ----- Forwarded message from Anders Henke <[email protected]> -----
> >
> > Date: Thu, 29 Nov 2007 13:31:50 +0100
> > From: Anders Henke <[email protected]>
> > To: [email protected]
> > Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
> > User-Agent: Mutt/1.5.13 (2006-08-11)
> >
> > On November 28 2007, Anders Henke wrote:
> > > As "everything is reported as being zero" is quite odd an Jan took a
> > > guess that it might be block-layer or driver-related, I've assumed
> > > that the driver is responsible for this; just out of the curiousity,
> > > I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
> > > driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
> > > vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
> > >
> > > I haven't yet fine-tested from which kernel release on the dpt_i2o driver
> > > behaves like this and spews out zeroed blocks when trying to mount
> > > the rootfs. Maybe this is just some timing issue.
> >
> > I've started the fine-tests and can say so far that dpt_i2o from
> > 2.6.22 is still fine. Test is simple:
> >
> > anders@ista:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
> >
> > ... recompile the kernel, reboot: works.
> >
> > 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
> > patch sets:
> > -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
> > -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
> > -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
> >
> > When applying the 2.6.23-rc1-based driver to "my" 2.6.31.1 kernel,
> > the "zero blocks"-symptom show up, so it's the "lucky" situation
> > that the smallest patch actually seams to be the broken one.
> >
> > According to the 2.6.23-rc1 short-form changelog, there is
> > one major edit on the dpt_i2o driver:
> >
> > FUJITA Tomonori
> >
> > [SCSI] dpt_i2o: convert to use the data buffer accessors
> >
> > Stephen Rothwell
> > dpt_i2o depends on virt_to_bus
> >
> > Fujita, would you please take a look at this?
>
> Sorry about the bug. Can you try this?
>
>
> diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
> index 8258506..1255b26 100644
> --- a/drivers/scsi/dpt_i2o.c
> +++ b/drivers/scsi/dpt_i2o.c
> @@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
> .this_id = 7,
> .cmd_per_lun = 1,
> .use_clustering = ENABLE_CLUSTERING,
> - .use_sg_chaining = ENABLE_SG_CHAINING,
> + .use_sg_chaining = DISABLE_SG_CHAINING,
> };
>
> static s32 adpt_scsi_register(adpt_hba* pHba)
The structure to patch does look different and doesn't include an
tag "use_sg_chaining":
---cut
static struct scsi_host_template adpt_template = {
.name = "dpt_i2o",
.proc_name = "dpt_i2o",
.proc_info = adpt_proc_info,
.info = adpt_info,
.queuecommand = adpt_queue,
.eh_abort_handler = adpt_abort,
.eh_device_reset_handler = adpt_device_reset,
.eh_bus_reset_handler = adpt_bus_reset,
.eh_host_reset_handler = adpt_reset,
.bios_param = adpt_bios_param,
.slave_configure = adpt_slave_configure,
.can_queue = MAX_TO_IOP_MESSAGES,
.this_id = 7,
.cmd_per_lun = 1,
.use_clustering = ENABLE_CLUSTERING,
};
static s32 adpt_scsi_register(adpt_hba* pHba)
---cut
Anders
--
1&1 Internet AG System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
On Thu, Nov 29, 2007 at 05:45:57PM +0100, Anders Henke wrote:
> On Nov 29 2007, FUJITA Tomonori wrote:
> > @@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
> > .this_id = 7,
> > .cmd_per_lun = 1,
> > .use_clustering = ENABLE_CLUSTERING,
> > - .use_sg_chaining = ENABLE_SG_CHAINING,
> > + .use_sg_chaining = DISABLE_SG_CHAINING,
> > };
> >
> > static s32 adpt_scsi_register(adpt_hba* pHba)
>
> The structure to patch does look different and doesn't include an
> tag "use_sg_chaining":
>
> .this_id = 7,
> .cmd_per_lun = 1,
> .use_clustering = ENABLE_CLUSTERING,
Just add the line
.use_sg_chaining = DISABLE_SG_CHAINING,
> };
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
On Thu, 29 Nov 2007 17:45:57 +0100
Anders Henke <[email protected]> wrote:
> On Nov 29 2007, FUJITA Tomonori wrote:
> > On Thu, 29 Nov 2007 14:03:19 +0100
> > Jan Kara <[email protected]> wrote:
> >
> > > Adding relevant people and lists to CC...
> > >
> > > Honza
> > >
> > > ----- Forwarded message from Anders Henke <[email protected]> -----
> > >
> > > Date: Thu, 29 Nov 2007 13:31:50 +0100
> > > From: Anders Henke <[email protected]>
> > > To: [email protected]
> > > Subject: Re: broken dpt_i2o in 2.6.23 (was: ext2_check_page: bad entry in directory)
> > > User-Agent: Mutt/1.5.13 (2006-08-11)
> > >
> > > On November 28 2007, Anders Henke wrote:
> > > > As "everything is reported as being zero" is quite odd an Jan took a
> > > > guess that it might be block-layer or driver-related, I've assumed
> > > > that the driver is responsible for this; just out of the curiousity,
> > > > I've manually replaced the dpt_i2o driver by the 2.6.19 one by copying
> > > > driver/scsi/dpt_i2o.c driver/scsi/dpti.h and driver/scsi/dpt/ into a
> > > > vanilla 2.6.23.1. kernel; using this kernel fixed the issue for me.
> > > >
> > > > I haven't yet fine-tested from which kernel release on the dpt_i2o driver
> > > > behaves like this and spews out zeroed blocks when trying to mount
> > > > the rootfs. Maybe this is just some timing issue.
> > >
> > > I've started the fine-tests and can say so far that dpt_i2o from
> > > 2.6.22 is still fine. Test is simple:
> > >
> > > anders@ista:/usr/src/linux-2.6.22/drivers/scsi/dpt$ cp -r dpt/ dpt_i2o.c dpti.h /usr/src/linux-2.6.23.1/drivers/scsi/
> > >
> > > ... recompile the kernel, reboot: works.
> > >
> > > 2.6.22 and 2.6.23 differ in terms of the dpt_i2o driver by two different
> > > patch sets:
> > > -one 2 Kb small set of patches from 2.6.22 to 2.6.22-rc1
> > > -one 7 Kb set of patches from 2.6.23-rc2 to 2.6.23-rc3
> > > -one 162 Kb set of patches from 2.6.23-rc9 to 2.6.23-rc10.
> > >
> > > When applying the 2.6.23-rc1-based driver to "my" 2.6.31.1 kernel,
> > > the "zero blocks"-symptom show up, so it's the "lucky" situation
> > > that the smallest patch actually seams to be the broken one.
> > >
> > > According to the 2.6.23-rc1 short-form changelog, there is
> > > one major edit on the dpt_i2o driver:
> > >
> > > FUJITA Tomonori
> > >
> > > [SCSI] dpt_i2o: convert to use the data buffer accessors
> > >
> > > Stephen Rothwell
> > > dpt_i2o depends on virt_to_bus
> > >
> > > Fujita, would you please take a look at this?
> >
> > Sorry about the bug. Can you try this?
> >
> >
> > diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
> > index 8258506..1255b26 100644
> > --- a/drivers/scsi/dpt_i2o.c
> > +++ b/drivers/scsi/dpt_i2o.c
> > @@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
> > .this_id = 7,
> > .cmd_per_lun = 1,
> > .use_clustering = ENABLE_CLUSTERING,
> > - .use_sg_chaining = ENABLE_SG_CHAINING,
> > + .use_sg_chaining = DISABLE_SG_CHAINING,
> > };
> >
> > static s32 adpt_scsi_register(adpt_hba* pHba)
>
> The structure to patch does look different and doesn't include an
> tag "use_sg_chaining":
Sorry, I misread your bug report. If you use 2.6.23, the sg chaining
is unrelated.
What architecture do you use?
Am 30.11.2007 schrieb FUJITA Tomonori:
> > > > According to the 2.6.23-rc1 short-form changelog, there is
> > > > one major edit on the dpt_i2o driver:
> > > >
> > > > FUJITA Tomonori
> > > >
> > > > [SCSI] dpt_i2o: convert to use the data buffer accessors
> > > >
> > > > Stephen Rothwell
> > > > dpt_i2o depends on virt_to_bus
> > > >
> > > > Fujita, would you please take a look at this?
> > >
> > > Sorry about the bug. Can you try this?
> > >
> > >
> > > diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
> > > index 8258506..1255b26 100644
> > > --- a/drivers/scsi/dpt_i2o.c
> > > +++ b/drivers/scsi/dpt_i2o.c
> > > @@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
> > > .this_id = 7,
> > > .cmd_per_lun = 1,
> > > .use_clustering = ENABLE_CLUSTERING,
> > > - .use_sg_chaining = ENABLE_SG_CHAINING,
> > > + .use_sg_chaining = DISABLE_SG_CHAINING,
> > > };
> > >
> > > static s32 adpt_scsi_register(adpt_hba* pHba)
> >
> > The structure to patch does look different and doesn't include an
> > tag "use_sg_chaining":
>
> Sorry, I misread your bug report. If you use 2.6.23, the sg chaining
> is unrelated.
>
> What architecture do you use?
"Mainstream" 32-bit-x86, the affected boxes are running Intel Xeons (P4)
at 2.66 or 2.8 GHz.
In between, I've ruled out that the static assignment isn't
source of the problem. And due to some manually made "make clean" which
didn't clean enough, I've also pointed out the wrong patch - sorry,
Fujita, definitely the right one which breaks my boxes is the dpt_i2o patch
from 2.6.23-rc2 to 2.6.23-rc3 (7 kb in Size) from Matthew Wilcox.
commit 55d9fcf57ba5ec427544fca7abc335cf3da78160
Author: Matthew Wilcox <[email protected]>
Date: Mon Jul 30 15:19:18 2007 -0600
[SCSI] dpt_i2o: convert to SCSI hotplug model
- Delete refereces to HOSTS_C
- Switch to module_init/module_exit instead of detect/release
- Don't pass around the host template and rename it to
adpt_template
- Switch from scsi_register/scsi_unregister to scsi_host_alloc,
scsi_add_host, scsi_scan_host and scsi_host_put.
Signed-off-by: Matthew Wilcox <[email protected]>
Acked-by: "Salyzyn, Mark" <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
"Definitely" as in
-applied the diff-patch onto 2.6.23.1 with a dpt_i2o from 2.6.23-rc1
to verify that booting failes.
-Recompiled a clean unpacked 2.6.23-rc2 to verify that the driver
from -rc2 still works.
-Recompiled a clean unpacked 2.6.23-rc3 to verify that the driver
from -rc3 breaks booting on my boxes.
So sorry for mispointing the bug to you, it's an issue for Matthew.
Anders
--
1&1 Internet AG System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
Am 29.11.2007 schrieb Matthew Wilcox:
> On Thu, Nov 29, 2007 at 05:45:57PM +0100, Anders Henke wrote:
> > On Nov 29 2007, FUJITA Tomonori wrote:
> > > @@ -3295,7 +3295,7 @@ static struct scsi_host_template adpt_template = {
> > > .this_id = 7,
> > > .cmd_per_lun = 1,
> > > .use_clustering = ENABLE_CLUSTERING,
> > > - .use_sg_chaining = ENABLE_SG_CHAINING,
> > > + .use_sg_chaining = DISABLE_SG_CHAINING,
> > > };
> > >
> > > static s32 adpt_scsi_register(adpt_hba* pHba)
> >
> > The structure to patch does look different and doesn't include an
> > tag "use_sg_chaining":
> >
> > .this_id = 7,
> > .cmd_per_lun = 1,
> > .use_clustering = ENABLE_CLUSTERING,
>
> Just add the line
> .use_sg_chaining = DISABLE_SG_CHAINING,
>
> > };
Just out of curiosity, I've tried 2.6.24-rc3 and patched the kernel
accordingly (DISABLE_SG_CHAINING): doesn't boot successfully,
same error as usual:
EXT2-fs error (device sda1): ext2_check_page: bad entry in directory #2:
rec_len is smaller than minimal - offset=0, inode=0, rec_len=0,
name_len=0
Warning: unable to open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
As sent in a parallel mail, I've found out that 2.6.23-rc2 works and
2.6.23-rc3 shows the same problems - so the problem has to be searched
in the dpt_i2o-changes made for 2.6.23-rc3.
Anders
--
1&1 Internet AG System Design
Brauerstrasse 48 v://49.721.91374.50
D-76135 Karlsruhe f://49.721.91374.225
Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren
On Fri, 2007-11-30 at 11:34 +0100, Anders Henke wrote:
> Am 30.11.2007 schrieb FUJITA Tomonori:
> > > > > According to the 2.6.23-rc1 short-form changelog, there is
> > > > > one major edit on the dpt_i2o driver:
> > > > >
> > > > > FUJITA Tomonori
> > > > >
> > > > > [SCSI] dpt_i2o: convert to use the data buffer accessors
> > > > >
> > > > > Stephen Rothwell
> > > > > dpt_i2o depends on virt_to_bus
> > > > >
> > > > > Fujita, would you please take a look at this?
> > > >
>
> In between, I've ruled out that the static assignment isn't
> source of the problem. And due to some manually made "make clean" which
> didn't clean enough, I've also pointed out the wrong patch - sorry,
> Fujita, definitely the right one which breaks my boxes is the dpt_i2o patch
> from 2.6.23-rc2 to 2.6.23-rc3 (7 kb in Size) from Matthew Wilcox.
>
> commit 55d9fcf57ba5ec427544fca7abc335cf3da78160
> Author: Matthew Wilcox <[email protected]>
> Date: Mon Jul 30 15:19:18 2007 -0600
>
> [SCSI] dpt_i2o: convert to SCSI hotplug model
I just noticed the same bug when I tried to update a 2.6.18 server to
2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init
segfaults, or can't be found .. anyway, driver/fs errors.
In the kernel config, under "processor type and features", I disabled
"64GB memory" support (changed to 4GB) and I also disabled "64 bit
Memory and IO resources" and the problem went away. Do you by any chance
happen to have those features enabled ?
The dpt_i2o driver is not 64-bit clean, it happens to work with
PAE/64-bit dma in earlier kernels but that might be by chance. Perhaps
the different initialization ordering exposes the problem.
I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have
added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that
driver. I intended to submit it for 2.6.25 or so ... if I have some time
later today or tomorrow I'll try that next to see if that makes a
difference.
Mike.
Miquel van Smoorenburg sez:
> I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have
> added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that
> driver. I intended to submit it for 2.6.25 or so ... if I
> have some time
> later today or tomorrow I'll try that next to see if that makes a
> difference.
Thanks, Mike, I will be watching your progress and offer my support! I
submitted a patch to move to 64 bit (which also drops the virt_to_bus
code) several years ago and it was rejected because of the focus on the
time to make i2o_block the driver of choice for this line of
controllers. I then reacted to the rejection by working with Markus
Lidel to move the 64 bit capabilities into the i2o driver.
Sincerely -- Mark Salyzyn
On Tue, 2007-12-11 at 15:40 +0100, Miquel van Smoorenburg wrote:
> I just noticed the same bug when I tried to update a 2.6.18 server to
> 2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init
> segfaults, or can't be found .. anyway, driver/fs errors.
>
> In the kernel config, under "processor type and features", I disabled
> "64GB memory" support (changed to 4GB) and I also disabled "64 bit
> Memory and IO resources" and the problem went away. Do you by any chance
> happen to have those features enabled ?
>
> The dpt_i2o driver is not 64-bit clean, it happens to work with
> PAE/64-bit dma in earlier kernels but that might be by chance. Perhaps
> the different initialization ordering exposes the problem.
>
> I got the 64-bit dpt_i2o driver from Adaptec some time ago, and I have
> added 64-bit support to the 2.6.23.1 dpt_i2o driver based on that
> driver. I intended to submit it for 2.6.25 or so ... if I have some time
> later today or tomorrow I'll try that next to see if that makes a
> difference.
I just recompiled 2.6.23.9 with the 64 bit patch for dpt_i2o and now it
boots just fine.
The patch is here:
http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch
It's not the final version - it needs a few cleanups before it can be
submitted, but perhaps you can test if it also works for you.
Mike.
ACK, patch looks good. Thanks for composing this patch. Glad to hear of
successful test results.
Sincerely -- Mark Salyzyn
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Miquel
> van Smoorenburg
. . .
>
> I just recompiled 2.6.23.9 with the 64 bit patch for dpt_i2o
> and now it
> boots just fine.
>
> The patch is here:
> http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch
>
> It's not the final version - it needs a few cleanups before it can be
> submitted, but perhaps you can test if it also works for you.
>
> Mike.