Hi,
I have got an INITIO 9100 UW SCSI Controller with an IBM
IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
Currently i have SUSE 10.1 (Kernel 2.6.16).
I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
driver
gets loaded during the installation process, yast reports that no hard
disk is found. I believe that this isnt a bug in suse's yast but a
problem
in the initio scsi driver because i also tried to install Fedora 8
(kernel 2.6.23) with the same problem.
I have seen the relevant thread "Conflict when loading initio driver"
and i suppose that the initio driver isnt fixed yet.
I can help testing the new patches in the initio driver if someone is
interested.
On Mon, 17 Dec 2007 11:39:47 +0200 "Filippos Papadopoulos" <[email protected]> wrote:
> Hi,
> I have got an INITIO 9100 UW SCSI Controller with an IBM
> IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
> Currently i have SUSE 10.1 (Kernel 2.6.16).
>
> I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
> OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
> driver
> gets loaded during the installation process, yast reports that no hard
> disk is found. I believe that this isnt a bug in suse's yast but a
> problem
> in the initio scsi driver because i also tried to install Fedora 8
> (kernel 2.6.23) with the same problem.
> I have seen the relevant thread "Conflict when loading initio driver"
> and i suppose that the initio driver isnt fixed yet.
> I can help testing the new patches in the initio driver if someone is
> interested.
initio doesn't seem to have a maintainer...
Are you able to identify any earlier kernel which worked OK?
Maybe it's a new device? If you can get the `lspci -vvxx' output
for that device we can take a look.
On Dec 17, 2007 1:18 PM, Andrew Morton <[email protected]> wrote:
>
> On Mon, 17 Dec 2007 11:39:47 +0200 "Filippos Papadopoulos" <[email protected]> wrote:
>
> > Hi,
> > I have got an INITIO 9100 UW SCSI Controller with an IBM
> > IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
> > Currently i have SUSE 10.1 (Kernel 2.6.16).
> >
> > I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
> > OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
> > driver
> > gets loaded during the installation process, yast reports that no hard
> > disk is found. I believe that this isnt a bug in suse's yast but a
> > problem
> > in the initio scsi driver because i also tried to install Fedora 8
> > (kernel 2.6.23) with the same problem.
> > I have seen the relevant thread "Conflict when loading initio driver"
> > and i suppose that the initio driver isnt fixed yet.
> > I can help testing the new patches in the initio driver if someone is
> > interested.
>
> initio doesn't seem to have a maintainer...
>
> Are you able to identify any earlier kernel which worked OK?
>
I have this PC configuration since 2002. The initio driver worked
perfectly with 2.4 kernel series.
With the release of 2.6 kernel series the driver had been marked as
BROKEN and fixed at 2.6.9
(see at http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582
Christoph Hellwig ->don't mark the initio 9100 driver broken)
> Maybe it's a new device? If you can get the `lspci -vvxx' output
> for that device we can take a look.
>
No its not a new device.
On Mon, Dec 17 2007 at 13:41 +0200, "Filippos Papadopoulos" <[email protected]> wrote:
> On Dec 17, 2007 1:18 PM, Andrew Morton <[email protected]> wrote:
>> On Mon, 17 Dec 2007 11:39:47 +0200 "Filippos Papadopoulos" <[email protected]> wrote:
>>
>>> Hi,
>>> I have got an INITIO 9100 UW SCSI Controller with an IBM
>>> IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
>>> Currently i have SUSE 10.1 (Kernel 2.6.16).
>>>
>>> I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
>>> OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
>>> driver
>>> gets loaded during the installation process, yast reports that no hard
>>> disk is found. I believe that this isnt a bug in suse's yast but a
>>> problem
>>> in the initio scsi driver because i also tried to install Fedora 8
>>> (kernel 2.6.23) with the same problem.
>>> I have seen the relevant thread "Conflict when loading initio driver"
>>> and i suppose that the initio driver isnt fixed yet.
>>> I can help testing the new patches in the initio driver if someone is
>>> interested.
>> initio doesn't seem to have a maintainer...
>>
>> Are you able to identify any earlier kernel which worked OK?
>>
>
> I have this PC configuration since 2002. The initio driver worked
> perfectly with 2.4 kernel series.
> With the release of 2.6 kernel series the driver had been marked as
> BROKEN and fixed at 2.6.9
> (see at http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582
> Christoph Hellwig ->don't mark the initio 9100 driver broken)
>
>
>> Maybe it's a new device? If you can get the `lspci -vvxx' output
>> for that device we can take a look.
>>
>
> No its not a new device.
> -
I have found one problem. Please try patch [2] below and report.
If it still fails try to enable debugging by setting with patch [1]
these values at top of drivers/scsi/initio.c. And send dmsgs.
Boaz
--------
patch [1]
--------
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 4c4465d..61edcd2 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -138,10 +138,10 @@ static struct pci_device_id i91u_pci_devices[] = {
};
MODULE_DEVICE_TABLE(pci, i91u_pci_devices);
-#define DEBUG_INTERRUPT 0
-#define DEBUG_QUEUE 0
-#define DEBUG_STATE 0
-#define INT_DISC 0
+#define DEBUG_INTERRUPT 1
+#define DEBUG_QUEUE 1
+#define DEBUG_STATE 1
+#define INT_DISC 1
/*--- forward references ---*/
static struct scsi_ctrl_blk *initio_find_busy_scb(struct initio_host * host, u16 tarlun);
-----------
patch [2]
-----------
git-diff --stat -p
drivers/scsi/initio.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 4c4465d..61595f6 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2616,6 +2616,7 @@ static void initio_build_scb(struct initio_host * host, struct scsi_ctrl_blk * c
scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) {
sg->data = cpu_to_le32((u32)sg_dma_address(sglist));
total_len += sg->len = cpu_to_le32((u32)sg_dma_len(sglist));
+ sg++;
}
cblk->buflen = (scsi_bufflen(cmnd) > total_len) ?
On Mon, Dec 17 2007 at 14:18 +0200, Boaz Harrosh <[email protected]> wrote:
> On Mon, Dec 17 2007 at 13:41 +0200, "Filippos Papadopoulos" <[email protected]> wrote:
>> On Dec 17, 2007 1:18 PM, Andrew Morton <[email protected]> wrote:
>>> On Mon, 17 Dec 2007 11:39:47 +0200 "Filippos Papadopoulos" <[email protected]> wrote:
>>>
>>>> Hi,
>>>> I have got an INITIO 9100 UW SCSI Controller with an IBM
>>>> IC35L036UWD210-0 scsi hard disk on a 32 bit x86 system.
>>>> Currently i have SUSE 10.1 (Kernel 2.6.16).
>>>>
>>>> I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
>>>> OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
>>>> driver
>>>> gets loaded during the installation process, yast reports that no hard
>>>> disk is found. I believe that this isnt a bug in suse's yast but a
>>>> problem
>>>> in the initio scsi driver because i also tried to install Fedora 8
>>>> (kernel 2.6.23) with the same problem.
>>>> I have seen the relevant thread "Conflict when loading initio driver"
>>>> and i suppose that the initio driver isnt fixed yet.
>>>> I can help testing the new patches in the initio driver if someone is
>>>> interested.
>>> initio doesn't seem to have a maintainer...
>>>
>>> Are you able to identify any earlier kernel which worked OK?
>>>
>> I have this PC configuration since 2002. The initio driver worked
>> perfectly with 2.4 kernel series.
>> With the release of 2.6 kernel series the driver had been marked as
>> BROKEN and fixed at 2.6.9
>> (see at http://www.gossamer-threads.com/lists/linux/kernel/482582?search_string=SCSI%20updates%20for%202.6.9;#482582
>> Christoph Hellwig ->don't mark the initio 9100 driver broken)
>>
>>
>>> Maybe it's a new device? If you can get the `lspci -vvxx' output
>>> for that device we can take a look.
>>>
>> No its not a new device.
>> -
>
> I have found one problem. Please try patch [2] below and report.
> If it still fails try to enable debugging by setting with patch [1]
> these values at top of drivers/scsi/initio.c. And send dmsgs.
>
> Boaz
>
I forgot to ask. 2.6.22 should work. If still fails could you try
this 2.6.22.xx kernel?
Boaz
> initio doesn't seem to have a maintainer...
>
> Are you able to identify any earlier kernel which worked OK?
>
> Maybe it's a new device? If you can get the `lspci -vvxx' output
> for that device we can take a look.
If I remember rightly the fixes for this went into the scsi tree a couple
of months ago. The patch is in the -mm tree as well. No idea why its
gotten stuck as an obvious one liner.
Alan
On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox <[email protected]> wrote:
>> initio doesn't seem to have a maintainer...
>>
>> Are you able to identify any earlier kernel which worked OK?
>>
>> Maybe it's a new device? If you can get the `lspci -vvxx' output
>> for that device we can take a look.
>
> If I remember rightly the fixes for this went into the scsi tree a couple
> of months ago. The patch is in the -mm tree as well. No idea why its
> gotten stuck as an obvious one liner.
>
> Alan
> -
You mean this one:
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf
It's only queued for 2.6.25 via scsi-misc.
I have found another bug. (See other mail in thread). I Will wait for testing
and submit a proper patch.
Boaz
On Mon, 17 Dec 2007 16:40:53 +0200
Boaz Harrosh <[email protected]> wrote:
> On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox <[email protected]> wrote:
> >> initio doesn't seem to have a maintainer...
> >>
> >> Are you able to identify any earlier kernel which worked OK?
> >>
> >> Maybe it's a new device? If you can get the `lspci -vvxx' output
> >> for that device we can take a look.
> >
> > If I remember rightly the fixes for this went into the scsi tree a couple
> > of months ago. The patch is in the -mm tree as well. No idea why its
> > gotten stuck as an obvious one liner.
> >
> > Alan
> > -
> You mean this one:
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf
>
> It's only queued for 2.6.25 via scsi-misc.
>
> I have found another bug. (See other mail in thread). I Will wait for testing
> and submit a proper patch.
That one yes - which really should have gone straight into the main tree
as the initio driver has been broken all the time it sits queued for
future patches. It can't make the problem any worse - the driver does not
work.
On Mon, 2007-12-17 at 14:36 +0000, Alan Cox wrote:
> On Mon, 17 Dec 2007 16:40:53 +0200
> Boaz Harrosh <[email protected]> wrote:
>
> > On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox <[email protected]> wrote:
> > >> initio doesn't seem to have a maintainer...
> > >>
> > >> Are you able to identify any earlier kernel which worked OK?
> > >>
> > >> Maybe it's a new device? If you can get the `lspci -vvxx' output
> > >> for that device we can take a look.
> > >
> > > If I remember rightly the fixes for this went into the scsi tree a couple
> > > of months ago. The patch is in the -mm tree as well. No idea why its
> > > gotten stuck as an obvious one liner.
> > >
> > > Alan
> > > -
> > You mean this one:
> > http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf
> >
> > It's only queued for 2.6.25 via scsi-misc.
> >
> > I have found another bug. (See other mail in thread). I Will wait for testing
> > and submit a proper patch.
>
> That one yes - which really should have gone straight into the main tree
> as the initio driver has been broken all the time it sits queued for
> future patches. It can't make the problem any worse - the driver does not
> work.
Well, the change log isn't very committal for "rush me immediately into
main line" plus, as far as I could dig out, there was no confirmation
that it actually worked. This way, I can now say please try the current
-mm kernel to the bug reporter and we get to see if this fixes the
problem.
James
On Mon, Dec 17 2007 at 17:03 +0200, James Bottomley <[email protected]> wrote:
> On Mon, 2007-12-17 at 14:36 +0000, Alan Cox wrote:
>> On Mon, 17 Dec 2007 16:40:53 +0200
>> Boaz Harrosh <[email protected]> wrote:
>>
>>> On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox <[email protected]> wrote:
>>>>> initio doesn't seem to have a maintainer...
>>>>>
>>>>> Are you able to identify any earlier kernel which worked OK?
>>>>>
>>>>> Maybe it's a new device? If you can get the `lspci -vvxx' output
>>>>> for that device we can take a look.
>>>> If I remember rightly the fixes for this went into the scsi tree a couple
>>>> of months ago. The patch is in the -mm tree as well. No idea why its
>>>> gotten stuck as an obvious one liner.
>>>>
>>>> Alan
>>>> -
>>> You mean this one:
>>> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf
>>>
>>> It's only queued for 2.6.25 via scsi-misc.
>>>
>>> I have found another bug. (See other mail in thread). I Will wait for testing
>>> and submit a proper patch.
>> That one yes - which really should have gone straight into the main tree
>> as the initio driver has been broken all the time it sits queued for
>> future patches. It can't make the problem any worse - the driver does not
>> work.
>
> Well, the change log isn't very committal for "rush me immediately into
> main line" plus, as far as I could dig out, there was no confirmation
> that it actually worked. This way, I can now say please try the current
> -mm kernel to the bug reporter and we get to see if this fixes the
> problem.
>
> James
>
Below fixes a deadly typo. Might as well be included in 2.6.24
Boaz
--------
>From fdf8ca414f9bb9a5a2cab602991cbac0b128ea65 Mon Sep 17 00:00:00 2001
From: Boaz Harrosh <[email protected]>
Date: Mon, 17 Dec 2007 18:04:11 +0200
Subject: [PATCH] initio: bugfix for accessors patch
patch: [SCSI] initio: convert to use the data buffer accessors
had a small but fatal bug. Fixed here.
Signed-off-by: Boaz Harrosh <[email protected]>
---
drivers/scsi/initio.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 769a7a8..01bf018 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2616,6 +2616,7 @@ static void initio_build_scb(struct initio_host * host, struct scsi_ctrl_blk * c
scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) {
sg->data = cpu_to_le32((u32)sg_dma_address(sglist));
total_len += sg->len = cpu_to_le32((u32)sg_dma_len(sglist));
+ ++sg;
}
cblk->buflen = (scsi_bufflen(cmnd) > total_len) ?
--
1.5.3.3
On Mon, Dec 17, 2007 at 06:08:59PM +0200, Boaz Harrosh wrote:
> Below fixes a deadly typo. Might as well be included in 2.6.24
You're sure ? scsi_for_each_sg includes a (sg)++ already...
> scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) {
> sg->data = cpu_to_le32((u32)sg_dma_address(sglist));
> total_len += sg->len = cpu_to_le32((u32)sg_dma_len(sglist));
> + ++sg;
> }
OG.
> Well, the change log isn't very committal for "rush me immediately into
> main line" plus, as far as I could dig out, there was no confirmation
> that it actually worked. This way, I can now say please try the current
Without that change it always tries to use zero as the memory/io address
of the device.
On Mon, Dec 17 2007 at 18:20 +0200, Olivier Galibert <[email protected]> wrote:
> On Mon, Dec 17, 2007 at 06:08:59PM +0200, Boaz Harrosh wrote:
>> Below fixes a deadly typo. Might as well be included in 2.6.24
>
> You're sure ? scsi_for_each_sg includes a (sg)++ already...
>
>
>> scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) {
>> sg->data = cpu_to_le32((u32)sg_dma_address(sglist));
>> total_len += sg->len = cpu_to_le32((u32)sg_dma_len(sglist));
>> + ++sg;
>> }
>
> OG.
> --
Don't mix up between the here sg that points to a driver specific struct sg_entry
and the here sglist which points to struct scatterlist, and is named sg inside
the scsi_for_each_sg() macro. Please inspect the full code, the patch does not
show the complete information. I admit it's confusing.
Boaz
On Dec 17, 2007 2:18 PM, Boaz Harrosh <[email protected]> wrote:
> I have found one problem. Please try patch [2] below and report.
> If it still fails try to enable debugging by setting with patch [1]
> these values at top of drivers/scsi/initio.c. And send dmsgs.
>
> Boaz
>
I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the
system hangs after some seconds when the initio driver loads.
I will try patch[1] next week to see what happens.
Would it be better to open a bug report at bugzilla?
>
> --------
> patch [1]
> --------
>
> diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
> index 4c4465d..61edcd2 100644
> --- a/drivers/scsi/initio.c
> +++ b/drivers/scsi/initio.c
> @@ -138,10 +138,10 @@ static struct pci_device_id i91u_pci_devices[] = {
> };
> MODULE_DEVICE_TABLE(pci, i91u_pci_devices);
>
> -#define DEBUG_INTERRUPT 0
> -#define DEBUG_QUEUE 0
> -#define DEBUG_STATE 0
> -#define INT_DISC 0
> +#define DEBUG_INTERRUPT 1
> +#define DEBUG_QUEUE 1
> +#define DEBUG_STATE 1
> +#define INT_DISC 1
>
> /*--- forward references ---*/
> static struct scsi_ctrl_blk *initio_find_busy_scb(struct initio_host * host, u16 tarlun);
>
>
> -----------
> patch [2]
> -----------
> git-diff --stat -p
> drivers/scsi/initio.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
> index 4c4465d..61595f6 100644
> --- a/drivers/scsi/initio.c
> +++ b/drivers/scsi/initio.c
> @@ -2616,6 +2616,7 @@ static void initio_build_scb(struct initio_host * host, struct scsi_ctrl_blk * c
> scsi_for_each_sg(cmnd, sglist, cblk->sglen, i) {
> sg->data = cpu_to_le32((u32)sg_dma_address(sglist));
> total_len += sg->len = cpu_to_le32((u32)sg_dma_len(sglist));
> + sg++;
> }
>
> cblk->buflen = (scsi_bufflen(cmnd) > total_len) ?
>
>
>
On Wed, Dec 19 2007 at 10:48 +0200, "Filippos Papadopoulos" <[email protected]> wrote:
> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[email protected]> wrote:
>> I have found one problem. Please try patch [2] below and report.
>> If it still fails try to enable debugging by setting with patch [1]
>> these values at top of drivers/scsi/initio.c. And send dmsgs.
>>
>> Boaz
>>
>
>
> I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the
> system hangs after some seconds when the initio driver loads.
> I will try patch[1] next week to see what happens.
>
Please first pull from scsi-rc-fixes git-tree first. it has a couple
of other fixes for initio plus patch[2] included.
(maybe its already in -mm tree I'm not sure).
If still don't work try enable debug with patch[1] and send messages
> Would it be better to open a bug report at bugzilla?
>
I would prefer linux-scsi ml
<snip>
Boaz
On Wed, Dec 19, 2007 at 10:48:27AM +0200, Filippos Papadopoulos wrote:
> Would it be better to open a bug report at bugzilla?
No, it wouldn't. Bugzilla is a place where bug reports go to be
ignored. Witness 9370 where despite my best efforts to move discussion
to the mailing list, it's been thoroughly ignored because the original
reporte insists on posting additional information there instead of to
the mailing list.
--
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 Wed, 2007-12-19 at 06:29 -0700, Matthew Wilcox wrote:
> On Wed, Dec 19, 2007 at 10:48:27AM +0200, Filippos Papadopoulos wrote:
> > Would it be better to open a bug report at bugzilla?
>
> No, it wouldn't. Bugzilla is a place where bug reports go to be
> ignored. Witness 9370 where despite my best efforts to move discussion
> to the mailing list, it's been thoroughly ignored because the original
> reporte insists on posting additional information there instead of to
> the mailing list.
That's a bit harsh on bugzilla. It is of use to people whose job it is
to track outstanding bugs.
However, Matthew is completely correct, it's useless for getting bugs
fixed *if* the information isn't on the mailing list. The reason for
using mailing list is the more eyes principle: if you email linux-scsi,
all the SCSI experts will see it, not just the one email listed as owner
in bugzilla. Likewise, as the bug goes through analysis, if it turns
out to be in a different area, that areas mailing list can be added to
the Cc list.
So, to get the best of both worlds, file a bugzilla and note the bugid.
Then email a complete report to the relevant list, but add [BUG <bugid>]
to the subject line and cc [email protected] If you do
this, bugzilla will keep track of the entire discussion as it progresses
and allow those who track bugs through bugzilla to get a pretty accurate
idea of the status. You should never need to touch bugzilla again once
the initial bug report is filed: all future information flow is via the
mailing lists.
James
On Wed, Dec 19, 2007 at 10:50:40AM -0600, James Bottomley wrote:
> So, to get the best of both worlds, file a bugzilla and note the bugid.
> Then email a complete report to the relevant list, but add [BUG <bugid>]
> to the subject line and cc [email protected] If you do
> this, bugzilla will keep track of the entire discussion as it progresses
> and allow those who track bugs through bugzilla to get a pretty accurate
> idea of the status. You should never need to touch bugzilla again once
> the initial bug report is filed: all future information flow is via the
> mailing lists.
The problem is that it appears to the casual observer as if they can
then add information to the bug through the web interface. But that
information will never be forwarded to the mailing list. Unless there's
a way of marking bugs as 'unchangable through the web interface' or 'all
messages appended to this bug need to be forwarded', Bugzilla just
doesn't fit our needs.
The Debian BTS fits our way of working much better. Perhaps somebody
should investigate a migration.
--
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 Dec 19, 2007 9:05 AM, Matthew Wilcox <[email protected]> wrote:
> On Wed, Dec 19, 2007 at 10:50:40AM -0600, James Bottomley wrote:
> > So, to get the best of both worlds, file a bugzilla and note the bugid.
> > Then email a complete report to the relevant list, but add [BUG <bugid>]
> > to the subject line and cc [email protected] If you do
> > this, bugzilla will keep track of the entire discussion as it progresses
> > and allow those who track bugs through bugzilla to get a pretty accurate
> > idea of the status. You should never need to touch bugzilla again once
> > the initial bug report is filed: all future information flow is via the
> > mailing lists.
>
> The problem is that it appears to the casual observer as if they can
> then add information to the bug through the web interface. But that
> information will never be forwarded to the mailing list. Unless there's
> a way of marking bugs as 'unchangable through the web interface' or 'all
> messages appended to this bug need to be forwarded', Bugzilla just
> doesn't fit our needs.
>
> The Debian BTS fits our way of working much better. Perhaps somebody
> should investigate a migration.
This is excellent observation by Matthew and James. There is no magic
in bugzilla not being loved, it is just "not the right set of features
for effective work on a problem". It doesn't support multiple
developer' collaboration well.
This distaste is not universal, since some people don't have a problem
with bugzilla as is, maybe those who tend to work on problems
"alone"...
But making it to be a workable tool for everyone is definitely worth it.
Any other favorite bugzillas that are nice to work with and that have
the advantage above?
>
> --
> 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."
> --
>
> 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/
>
On Thu, Dec 20, 2007 at 01:32:02AM -0800, Natalie Protasevich wrote:
> > The problem is that it appears to the casual observer as if they can
> > then add information to the bug through the web interface. But that
> > information will never be forwarded to the mailing list. Unless there's
> > a way of marking bugs as 'unchangable through the web interface' or 'all
> > messages appended to this bug need to be forwarded', Bugzilla just
> > doesn't fit our needs.
> >
> > The Debian BTS fits our way of working much better. Perhaps somebody
> > should investigate a migration.
>
> This is excellent observation by Matthew and James. There is no magic
> in bugzilla not being loved, it is just "not the right set of features
> for effective work on a problem". It doesn't support multiple
> developer' collaboration well.
Actually, Bugzilla *could* be configured so that, say, linux-scsi was
copied for all SCSI bugs (linux-scsi could just be added to the cc
list). The problem though is that Bugzilla will then proceed to cc
linux-scsi for all the Bugzilla state change details which might annoy
the denizens of the linux-scsi list.
But if new entries on the Bugzilla entry could be set to forward to
the appropriate mailing list with the messaging *looking* a lot more
like a mail message, I suspect it could be acceptable. One of the
advantages of the Debian BTS is that it's much more integrated into
the e-mail workflow. (Although it lacks the roll up and reporting
capabilities that are beloved by managers...)
But hey, it could be worse. We could have chosen the Sourceforge bug
tracker. :-)
- Ted
On Thu, 2007-12-20 at 01:32 -0800, Natalie Protasevich wrote:
> On Dec 19, 2007 9:05 AM, Matthew Wilcox <[email protected]> wrote:
> > On Wed, Dec 19, 2007 at 10:50:40AM -0600, James Bottomley wrote:
> > > So, to get the best of both worlds, file a bugzilla and note the bugid.
> > > Then email a complete report to the relevant list, but add [BUG <bugid>]
> > > to the subject line and cc [email protected] If you do
> > > this, bugzilla will keep track of the entire discussion as it progresses
> > > and allow those who track bugs through bugzilla to get a pretty accurate
> > > idea of the status. You should never need to touch bugzilla again once
> > > the initial bug report is filed: all future information flow is via the
> > > mailing lists.
> >
> > The problem is that it appears to the casual observer as if they can
> > then add information to the bug through the web interface. But that
> > information will never be forwarded to the mailing list. Unless there's
> > a way of marking bugs as 'unchangable through the web interface' or 'all
> > messages appended to this bug need to be forwarded', Bugzilla just
> > doesn't fit our needs.
> >
> > The Debian BTS fits our way of working much better. Perhaps somebody
> > should investigate a migration.
>
> This is excellent observation by Matthew and James. There is no magic
> in bugzilla not being loved, it is just "not the right set of features
> for effective work on a problem". It doesn't support multiple
> developer' collaboration well.
> This distaste is not universal, since some people don't have a problem
> with bugzilla as is, maybe those who tend to work on problems
> "alone"...
> But making it to be a workable tool for everyone is definitely worth it.
> Any other favorite bugzillas that are nice to work with and that have
> the advantage above?
We have actually been trying for over two years to get bugzilla fixed so
that it suits our email and list publishing workflow for fixing bugs. I
surmise that 90% of our problems with bugzilla could be solved if it
simply tipped a SCSI bug report onto the SCSI list when it was created
in such a way that all replies were gathered back into bugzilla.
Unfortunately, no-one who maintains our bugzilla has actually been able
to make this happen. The other 10% of the problem is that bugzilla
doesn't seem to have a way properly to integrate people who insist on
using its web interface to reply into the email flow.
James
On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote:
> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[email protected]> wrote:
>> I have found one problem. Please try patch [2] below and report.
>> If it still fails try to enable debugging by setting with patch [1]
>> these values at top of drivers/scsi/initio.c. And send dmsgs.
>>
>> Boaz
>>
>
>
> I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the
> system hangs after some seconds when the initio driver loads.
> I will try patch[1] next week to see what happens.
>
> Would it be better to open a bug report at bugzilla?
>
There is also a Fedora bug report against 2.6.23. The user has
applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from
2.6.24-rc plus the two additional fixes under discussion and it
hangs for him too.
https://bugzilla.redhat.com/show_bug.cgi?id=390531
On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote:
> On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote:
> > On Dec 17, 2007 2:18 PM, Boaz Harrosh <[email protected]> wrote:
> >> I have found one problem. Please try patch [2] below and report.
> >> If it still fails try to enable debugging by setting with patch [1]
> >> these values at top of drivers/scsi/initio.c. And send dmsgs.
> >>
> >> Boaz
> >>
> >
> >
> > I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the
> > system hangs after some seconds when the initio driver loads.
> > I will try patch[1] next week to see what happens.
> >
> > Would it be better to open a bug report at bugzilla?
> >
>
> There is also a Fedora bug report against 2.6.23. The user has
> applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from
> 2.6.24-rc plus the two additional fixes under discussion and it
> hangs for him too.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=390531
It really sounds like there's some problem applying the patches. The
consistent report throughout is this one:
initio: I/O port range 0x0 is busy.
Which should be fixed by 99f1f534922a2f2251ba05b14657a1c62882a80e. I
didn't actually find that in the bug thread anywhere, but maybe I missed
it?
James
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/21/2007 04:03 PM, James Bottomley wrote:
> On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote:
>> On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote:
>>> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[email protected]> wrote:
>>>> I have found one problem. Please try patch [2] below and report.
>>>> If it still fails try to enable debugging by setting with patch [1]
>>>> these values at top of drivers/scsi/initio.c. And send dmsgs.
>>>>
>>>> Boaz
>>>>
>>>
>>> I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the
>>> system hangs after some seconds when the initio driver loads.
>>> I will try patch[1] next week to see what happens.
>>>
>>> Would it be better to open a bug report at bugzilla?
>>>
>> There is also a Fedora bug report against 2.6.23. The user has
>> applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from
>> 2.6.24-rc plus the two additional fixes under discussion and it
>> hangs for him too.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=390531
>
> It really sounds like there's some problem applying the patches. The
> consistent report throughout is this one:
>
> initio: I/O port range 0x0 is busy.
>
> Which should be fixed by 99f1f534922a2f2251ba05b14657a1c62882a80e. I
> didn't actually find that in the bug thread anywhere, but maybe I missed
> it?
>
The "I/O port 0" bug just prints the message and the system continues
to run. It's only after that is fixed that the system just hangs on
boot shortly after loading the driver.
On Fri, 2007-12-21 at 17:43 -0500, Chuck Ebbert wrote:
> On 12/21/2007 04:03 PM, James Bottomley wrote:
> > On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote:
> >> On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote:
> >>> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[email protected]> wrote:
> >>>> I have found one problem. Please try patch [2] below and report.
> >>>> If it still fails try to enable debugging by setting with patch [1]
> >>>> these values at top of drivers/scsi/initio.c. And send dmsgs.
> >>>>
> >>>> Boaz
> >>>>
> >>>
> >>> I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the
> >>> system hangs after some seconds when the initio driver loads.
> >>> I will try patch[1] next week to see what happens.
> >>>
> >>> Would it be better to open a bug report at bugzilla?
> >>>
> >> There is also a Fedora bug report against 2.6.23. The user has
> >> applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from
> >> 2.6.24-rc plus the two additional fixes under discussion and it
> >> hangs for him too.
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=390531
> >
> > It really sounds like there's some problem applying the patches. The
> > consistent report throughout is this one:
> >
> > initio: I/O port range 0x0 is busy.
> >
> > Which should be fixed by 99f1f534922a2f2251ba05b14657a1c62882a80e. I
> > didn't actually find that in the bug thread anywhere, but maybe I missed
> > it?
> >
>
> The "I/O port 0" bug just prints the message and the system continues
> to run. It's only after that is fixed that the system just hangs on
> boot shortly after loading the driver.
That should happen unless the PCI BAR is genuinely misconfigured; it's
saying we got zero when we requested the starting address of BAR0. What
does lspci -vv show for this device?
James
First of all let me wish a happy new year.
I come back from the vacations and i compiled the initio driver with
#define DEBUG_INTERRUPT 1
#define DEBUG_QUEUE 1
#define DEBUG_STATE 1
#define INT_DISC 1
I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the initio
driver prints the following:
" scsi: Initio INI-9X00U/UW SCSI device driver
Find scb at c0c00000
Append pend scb c0c00000;"
After 3 seconds the whole system freezes there and i have to reboot.
P.S here is the info from 'lspci -vv' running 2.6.16.13 kernel:
"00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02)
Subsystem: Unknown device 9292:0202
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, Cache Line Size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at d000 [size=256]
Region 1: Memory at ef000000 (32-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at 50000000 [disabled] [size=128K]
"
On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote:
> First of all let me wish a happy new year.
> I come back from the vacations and i compiled the initio driver with
>
> #define DEBUG_INTERRUPT 1
> #define DEBUG_QUEUE 1
> #define DEBUG_STATE 1
> #define INT_DISC 1
>
> I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the initio
> driver prints the following:
>
> " scsi: Initio INI-9X00U/UW SCSI device driver
> Find scb at c0c00000
> Append pend scb c0c00000;"
>
> After 3 seconds the whole system freezes there and i have to reboot.
>
>
>
> P.S here is the info from 'lspci -vv' running 2.6.16.13 kernel:
>
> "00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02)
> Subsystem: Unknown device 9292:0202
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 32, Cache Line Size 08
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at d000 [size=256]
This proves the BAR0 to be non zero, but I also take it from your report
that the
initio: I/O port range 0x0 is busy.
message is also gone?
> Region 1: Memory at ef000000 (32-bit, non-prefetchable) [size=4K]
> [virtual] Expansion ROM at 50000000 [disabled] [size=128K]
> "
I think there's still one remaining bug from the sg_list conversion,
namely that cblk->sglen is never set, but it is used to count the number
of elements in the sg array. Could you try this patch (on top of
everything else) and see if the problem is finally fixed?
Thanks,
James
---
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 01bf018..d038459 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2603,6 +2603,7 @@ static void initio_build_scb(struct initio_host * host, struct scsi_ctrl_blk * c
nseg = scsi_dma_map(cmnd);
BUG_ON(nseg < 0);
if (nseg) {
+ cblk->sglen = nseg;
dma_addr = dma_map_single(&host->pci_dev->dev, &cblk->sglist[0],
sizeof(struct sg_entry) * TOTAL_SG_ENTRY,
DMA_BIDIRECTIONAL);
On Jan 11, 2008 7:16 AM, James Bottomley
<[email protected]> wrote:
>
> On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote:
> > First of all let me wish a happy new year.
> > I come back from the vacations and i compiled the initio driver with
> >
> > #define DEBUG_INTERRUPT 1
> > #define DEBUG_QUEUE 1
> > #define DEBUG_STATE 1
> > #define INT_DISC 1
> >
> > I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the initio
> > driver prints the following:
> >
> > " scsi: Initio INI-9X00U/UW SCSI device driver
> > Find scb at c0c00000
> > Append pend scb c0c00000;"
> >
> > After 3 seconds the whole system freezes there and i have to reboot.
> >
> >
> >
> > P.S here is the info from 'lspci -vv' running 2.6.16.13 kernel:
> >
> > "00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02)
> > Subsystem: Unknown device 9292:0202
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > ParErr- Stepping- SERR- FastB2B-
> > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> > >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> > Latency: 32, Cache Line Size 08
> > Interrupt: pin A routed to IRQ 11
> > Region 0: I/O ports at d000 [size=256]
>
> This proves the BAR0 to be non zero, but I also take it from your report
> that the
>
> initio: I/O port range 0x0 is busy.
>
> message is also gone?
>
I havent reported "initio: I/O port range 0x0 is busy."
> > Region 1: Memory at ef000000 (32-bit, non-prefetchable) [size=4K]
> > [virtual] Expansion ROM at 50000000 [disabled] [size=128K]
> > "
>
> I think there's still one remaining bug from the sg_list conversion,
> namely that cblk->sglen is never set, but it is used to count the number
> of elements in the sg array. Could you try this patch (on top of
> everything else) and see if the problem is finally fixed?
>
I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
> Thanks,
>
> James
>
> ---
> diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
> index 01bf018..d038459 100644
> --- a/drivers/scsi/initio.c
> +++ b/drivers/scsi/initio.c
> @@ -2603,6 +2603,7 @@ static void initio_build_scb(struct initio_host * host, struct scsi_ctrl_blk * c
> nseg = scsi_dma_map(cmnd);
> BUG_ON(nseg < 0);
> if (nseg) {
> + cblk->sglen = nseg;
> dma_addr = dma_map_single(&host->pci_dev->dev, &cblk->sglist[0],
> sizeof(struct sg_entry) * TOTAL_SG_ENTRY,
> DMA_BIDIRECTIONAL);
>
>
>
On Fri, 2008-01-11 at 11:54 +0200, Filippos Papadopoulos wrote:
> On Jan 11, 2008 7:16 AM, James Bottomley
> <[email protected]> wrote:
> >
> > On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote:
> > > First of all let me wish a happy new year.
> > > I come back from the vacations and i compiled the initio driver with
> > >
> > > #define DEBUG_INTERRUPT 1
> > > #define DEBUG_QUEUE 1
> > > #define DEBUG_STATE 1
> > > #define INT_DISC 1
> > >
> > > I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the initio
> > > driver prints the following:
> > >
> > > " scsi: Initio INI-9X00U/UW SCSI device driver
> > > Find scb at c0c00000
> > > Append pend scb c0c00000;"
> > >
> > > After 3 seconds the whole system freezes there and i have to reboot.
> > >
> > >
> > >
> > > P.S here is the info from 'lspci -vv' running 2.6.16.13 kernel:
> > >
> > > "00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02)
> > > Subsystem: Unknown device 9292:0202
> > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > ParErr- Stepping- SERR- FastB2B-
> > > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> > > >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> > > Latency: 32, Cache Line Size 08
> > > Interrupt: pin A routed to IRQ 11
> > > Region 0: I/O ports at d000 [size=256]
> >
> > This proves the BAR0 to be non zero, but I also take it from your report
> > that the
> >
> > initio: I/O port range 0x0 is busy.
> >
> > message is also gone?
> >
>
>
> I havent reported "initio: I/O port range 0x0 is busy."
Sorry ... we appear to have several reporters of different bugs in this
thread. That message was copied by Chuck Ebbert from a Red Hat
bugzilla ... I was assuming it was the same problem.
> > > Region 1: Memory at ef000000 (32-bit, non-prefetchable) [size=4K]
> > > [virtual] Expansion ROM at 50000000 [disabled] [size=128K]
> > > "
> >
> > I think there's still one remaining bug from the sg_list conversion,
> > namely that cblk->sglen is never set, but it is used to count the number
> > of elements in the sg array. Could you try this patch (on top of
> > everything else) and see if the problem is finally fixed?
> >
>
> I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
First off, has this driver ever worked for you in 2.6? Just booting
SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to
check a really old kernel would be helpful. If you can get it to work,
then we can proceed with a patch reversion regime based on the
assumption that the problem is a recent commit.
Thanks,
James
On Jan 11, 2008 5:44 PM, James Bottomley
<[email protected]> wrote:
> >
> > I havent reported "initio: I/O port range 0x0 is busy."
>
> Sorry ... we appear to have several reporters of different bugs in this
> thread. That message was copied by Chuck Ebbert from a Red Hat
> bugzilla ... I was assuming it was the same problem.
>
> > I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
>
> First off, has this driver ever worked for you in 2.6? Just booting
> SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to
> check a really old kernel would be helpful. If you can get it to work,
> then we can proceed with a patch reversion regime based on the
> assumption that the problem is a recent commit.
Yes it works under 2.6.16.13. See the beginning of this thread, i
mention there some things about newer versions.
>
> Thanks,
>
> James
>
>
>
On Fri, 2008-01-11 at 18:44 +0200, Filippos Papadopoulos wrote:
> On Jan 11, 2008 5:44 PM, James Bottomley
> <[email protected]> wrote:
> > >
> > > I havent reported "initio: I/O port range 0x0 is busy."
> >
> > Sorry ... we appear to have several reporters of different bugs in this
> > thread. That message was copied by Chuck Ebbert from a Red Hat
> > bugzilla ... I was assuming it was the same problem.
> >
> > > I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
> >
> > First off, has this driver ever worked for you in 2.6? Just booting
> > SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to
> > check a really old kernel would be helpful. If you can get it to work,
> > then we can proceed with a patch reversion regime based on the
> > assumption that the problem is a recent commit.
>
> Yes it works under 2.6.16.13. See the beginning of this thread, i
> mention there some things about newer versions.
Thanks, actually, I see this:
> I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
> OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
> drivergets loaded during the installation process, yast reports that no hard
> disk is found.
Could you try with a vanilla 2.6.22 kernel? The reason for all of this
is that 2.6.22 predates Alan's conversion of this driver (which was my
95% candidate for the source of the bug). I want you to try the vanilla
kernel just in case the opensuse one contains a backport.
Thanks,
James
> Yes it works under 2.6.16.13. See the beginning of this thread, i
> mention there some things about newer versions.
It worked (ish.. it has problems and always has had) before the big
updates, and according to my tester after the big update + two patches
that escaped somewhere in the process. Unfortunately my tester no longer
has the card to dig further.
The 0x0 bug was fixed a while ago but seems to have sat in -mm for a bit.
Don't know about further stuff.
On Fri, 2008-01-11 at 17:01 +0000, Alan Cox wrote:
> > Yes it works under 2.6.16.13. See the beginning of this thread, i
> > mention there some things about newer versions.
>
> It worked (ish.. it has problems and always has had) before the big
> updates, and according to my tester after the big update + two patches
> that escaped somewhere in the process. Unfortunately my tester no longer
> has the card to dig further.
>
> The 0x0 bug was fixed a while ago but seems to have sat in -mm for a bit.
> Don't know about further stuff.
The statement that OpenSuse 10.3, based on 2.6.22.5, also fails
indicates there may be something else that predates your reorganisation
at the root of this (depending on whether the vendor kernel contains a
back port or not). That's why I want to see what happens on this system
with a vanilla 2.6.22
James
On 01/11/2008 10:44 AM, James Bottomley wrote:
>>> This proves the BAR0 to be non zero, but I also take it from your report
>>> that the
>>>
>>> initio: I/O port range 0x0 is busy.
>>>
>>> message is also gone?
>>>
>>
>> I havent reported "initio: I/O port range 0x0 is busy."
>
> Sorry ... we appear to have several reporters of different bugs in this
> thread. That message was copied by Chuck Ebbert from a Red Hat
> bugzilla ... I was assuming it was the same problem.
>
Our reporter has applied patches since then and now reports the exact
same symptoms that Filippos does. (It just hangs after loading the driver.)
On 1/11/08, James Bottomley <[email protected]> wrote:
>
> On Fri, 2008-01-11 at 18:44 +0200, Filippos Papadopoulos wrote:
> > On Jan 11, 2008 5:44 PM, James Bottomley
> > <[email protected]> wrote:
> > > >
> > > > I havent reported "initio: I/O port range 0x0 is busy."
> > >
> > > Sorry ... we appear to have several reporters of different bugs in this
> > > thread. That message was copied by Chuck Ebbert from a Red Hat
> > > bugzilla ... I was assuming it was the same problem.
> > >
> > > > I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
> > >
> > > First off, has this driver ever worked for you in 2.6? Just booting
> > > SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to
> > > check a really old kernel would be helpful. If you can get it to work,
> > > then we can proceed with a patch reversion regime based on the
> > > assumption that the problem is a recent commit.
> >
> > Yes it works under 2.6.16.13. See the beginning of this thread, i
> > mention there some things about newer versions.
>
> Thanks, actually, I see this:
>
> > I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
> > OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
> > drivergets loaded during the installation process, yast reports that no hard
> > disk is found.
>
> Could you try with a vanilla 2.6.22 kernel? The reason for all of this
> is that 2.6.22 predates Alan's conversion of this driver (which was my
> 95% candidate for the source of the bug). I want you to try the vanilla
> kernel just in case the opensuse one contains a backport.
Yes you are right. I compiled the vanilla 2.6.22 and initio driver works.
Tell me if you want to apply any patch to it.
>
> Thanks,
>
> James
>
>
>
On Sun, 2008-01-13 at 14:28 +0200, Filippos Papadopoulos wrote:
> On 1/11/08, James Bottomley <[email protected]> wrote:
> >
> > On Fri, 2008-01-11 at 18:44 +0200, Filippos Papadopoulos wrote:
> > > On Jan 11, 2008 5:44 PM, James Bottomley
> > > <[email protected]> wrote:
> > > > >
> > > > > I havent reported "initio: I/O port range 0x0 is busy."
> > > >
> > > > Sorry ... we appear to have several reporters of different bugs in this
> > > > thread. That message was copied by Chuck Ebbert from a Red Hat
> > > > bugzilla ... I was assuming it was the same problem.
> > > >
> > > > > I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
> > > >
> > > > First off, has this driver ever worked for you in 2.6? Just booting
> > > > SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to
> > > > check a really old kernel would be helpful. If you can get it to work,
> > > > then we can proceed with a patch reversion regime based on the
> > > > assumption that the problem is a recent commit.
> > >
> > > Yes it works under 2.6.16.13. See the beginning of this thread, i
> > > mention there some things about newer versions.
> >
> > Thanks, actually, I see this:
> >
> > > I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
> > > OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
> > > drivergets loaded during the installation process, yast reports that no hard
> > > disk is found.
> >
> > Could you try with a vanilla 2.6.22 kernel? The reason for all of this
> > is that 2.6.22 predates Alan's conversion of this driver (which was my
> > 95% candidate for the source of the bug). I want you to try the vanilla
> > kernel just in case the opensuse one contains a backport.
>
>
> Yes you are right. I compiled the vanilla 2.6.22 and initio driver works.
> Tell me if you want to apply any patch to it.
That's good news ... at least we know where the issue lies; now the
problem comes: there are two candidate patches for this issue: Alan's
driver update patch and Tomo's accessors patch. Unfortunately, due to
merge conflicts the two are pretty hopelessly intertwined. I think I
already spotted one bug in the accessor conversion, so I'll look at that
again. Alan's also going to acquire an inito board and retest his
conversions.
I'm afraid it might be a while before we have anything for you to test.
James
On Tue, 15 Jan 2008 09:16:06 -0600
James Bottomley <[email protected]> wrote:
>
> On Sun, 2008-01-13 at 14:28 +0200, Filippos Papadopoulos wrote:
> > On 1/11/08, James Bottomley <[email protected]> wrote:
> > >
> > > On Fri, 2008-01-11 at 18:44 +0200, Filippos Papadopoulos wrote:
> > > > On Jan 11, 2008 5:44 PM, James Bottomley
> > > > <[email protected]> wrote:
> > > > > >
> > > > > > I havent reported "initio: I/O port range 0x0 is busy."
> > > > >
> > > > > Sorry ... we appear to have several reporters of different bugs in this
> > > > > thread. That message was copied by Chuck Ebbert from a Red Hat
> > > > > bugzilla ... I was assuming it was the same problem.
> > > > >
> > > > > > I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
> > > > >
> > > > > First off, has this driver ever worked for you in 2.6? Just booting
> > > > > SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to
> > > > > check a really old kernel would be helpful. If you can get it to work,
> > > > > then we can proceed with a patch reversion regime based on the
> > > > > assumption that the problem is a recent commit.
> > > >
> > > > Yes it works under 2.6.16.13. See the beginning of this thread, i
> > > > mention there some things about newer versions.
> > >
> > > Thanks, actually, I see this:
> > >
> > > > I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
> > > > OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
> > > > drivergets loaded during the installation process, yast reports that no hard
> > > > disk is found.
> > >
> > > Could you try with a vanilla 2.6.22 kernel? The reason for all of this
> > > is that 2.6.22 predates Alan's conversion of this driver (which was my
> > > 95% candidate for the source of the bug). I want you to try the vanilla
> > > kernel just in case the opensuse one contains a backport.
> >
> >
> > Yes you are right. I compiled the vanilla 2.6.22 and initio driver works.
> > Tell me if you want to apply any patch to it.
>
>
> That's good news ... at least we know where the issue lies; now the
> problem comes: there are two candidate patches for this issue: Alan's
> driver update patch and Tomo's accessors patch. Unfortunately, due to
> merge conflicts the two are pretty hopelessly intertwined. I think I
> already spotted one bug in the accessor conversion, so I'll look at that
> again. Alan's also going to acquire an inito board and retest his
> conversions.
>
> I'm afraid it might be a while before we have anything for you to test.
Can you try this patch?
Thanks,
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 01bf018..6891d2b 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2609,6 +2609,7 @@ static void initio_build_scb(struct initio_host * host, struct scsi_ctrl_blk * c
cblk->bufptr = cpu_to_le32((u32)dma_addr);
cmnd->SCp.dma_handle = dma_addr;
+ cblk->sglen = nseg;
cblk->flags |= SCF_SG; /* Turn on SG list flag */
total_len = 0;
On Wed, 2008-01-16 at 14:59 +0900, FUJITA Tomonori wrote:
> On Tue, 15 Jan 2008 09:16:06 -0600
> James Bottomley <[email protected]> wrote:
>
> >
> > On Sun, 2008-01-13 at 14:28 +0200, Filippos Papadopoulos wrote:
> > > On 1/11/08, James Bottomley <[email protected]> wrote:
> > > >
> > > > On Fri, 2008-01-11 at 18:44 +0200, Filippos Papadopoulos wrote:
> > > > > On Jan 11, 2008 5:44 PM, James Bottomley
> > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > I havent reported "initio: I/O port range 0x0 is busy."
> > > > > >
> > > > > > Sorry ... we appear to have several reporters of different bugs in this
> > > > > > thread. That message was copied by Chuck Ebbert from a Red Hat
> > > > > > bugzilla ... I was assuming it was the same problem.
> > > > > >
> > > > > > > I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
> > > > > >
> > > > > > First off, has this driver ever worked for you in 2.6? Just booting
> > > > > > SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to
> > > > > > check a really old kernel would be helpful. If you can get it to work,
> > > > > > then we can proceed with a patch reversion regime based on the
> > > > > > assumption that the problem is a recent commit.
> > > > >
> > > > > Yes it works under 2.6.16.13. See the beginning of this thread, i
> > > > > mention there some things about newer versions.
> > > >
> > > > Thanks, actually, I see this:
> > > >
> > > > > I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest
> > > > > OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio
> > > > > drivergets loaded during the installation process, yast reports that no hard
> > > > > disk is found.
> > > >
> > > > Could you try with a vanilla 2.6.22 kernel? The reason for all of this
> > > > is that 2.6.22 predates Alan's conversion of this driver (which was my
> > > > 95% candidate for the source of the bug). I want you to try the vanilla
> > > > kernel just in case the opensuse one contains a backport.
> > >
> > >
> > > Yes you are right. I compiled the vanilla 2.6.22 and initio driver works.
> > > Tell me if you want to apply any patch to it.
> >
> >
> > That's good news ... at least we know where the issue lies; now the
> > problem comes: there are two candidate patches for this issue: Alan's
> > driver update patch and Tomo's accessors patch. Unfortunately, due to
> > merge conflicts the two are pretty hopelessly intertwined. I think I
> > already spotted one bug in the accessor conversion, so I'll look at that
> > again. Alan's also going to acquire an inito board and retest his
> > conversions.
> >
> > I'm afraid it might be a while before we have anything for you to test.
>
> Can you try this patch?
>
> Thanks,
>
> diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
> index 01bf018..6891d2b 100644
> --- a/drivers/scsi/initio.c
> +++ b/drivers/scsi/initio.c
> @@ -2609,6 +2609,7 @@ static void initio_build_scb(struct initio_host * host, struct scsi_ctrl_blk * c
> cblk->bufptr = cpu_to_le32((u32)dma_addr);
> cmnd->SCp.dma_handle = dma_addr;
>
> + cblk->sglen = nseg;
>
> cblk->flags |= SCF_SG; /* Turn on SG list flag */
> total_len = 0;
We already tried a variant of this here:
http://marc.info/?l=linux-scsi&m=120002863806103&w=2
The answer was negative. Although I've saved the patch because it's
clearly one of the bugs.
James
Ok my attempt to get the card failed so we are going to have to do this
the hard way. See where this patch crashes and what it prints
(On top of the other patches)
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc8-mm1/drivers/scsi/initio.c linux-2.6.24-rc8-mm1/drivers/scsi/initio.c
--- linux.vanilla-2.6.24-rc8-mm1/drivers/scsi/initio.c 2008-01-19 14:22:43.000000000 +0000
+++ linux-2.6.24-rc8-mm1/drivers/scsi/initio.c 2008-01-21 14:54:48.000000000 +0000
@@ -2537,10 +2537,12 @@
struct Scsi_Host *dev = dev_id;
unsigned long flags;
int r;
-
+
+ printk("ISR\n");
spin_lock_irqsave(dev->host_lock, flags);
r = initio_isr((struct initio_host *)dev->hostdata);
spin_unlock_irqrestore(dev->host_lock, flags);
+ printk("ISR DONE %d\n", r);
if (r)
return IRQ_HANDLED;
else
@@ -2643,6 +2645,7 @@
struct initio_host *host = (struct initio_host *) cmd->device->host->hostdata;
struct scsi_ctrl_blk *cmnd;
+ printk("SCB QUEUE\n");
cmd->scsi_done = done;
cmnd = initio_alloc_scb(host);
@@ -2650,7 +2653,9 @@
return SCSI_MLQUEUE_HOST_BUSY;
initio_build_scb(host, cmnd, cmd);
+ printk("SCB EXEC\n");
initio_exec_scb(host, cmnd);
+ printk("SCB EXEC DONE\n");
return 0;
}
@@ -2766,6 +2771,8 @@
struct scsi_cmnd *cmnd; /* Pointer to SCSI request block */
struct initio_host *host;
struct scsi_ctrl_blk *cblk;
+
+ printk("SCB POST\n");
host = (struct initio_host *) host_mem;
cblk = (struct scsi_ctrl_blk *) cblk_mem;
@@ -2934,9 +2941,11 @@
pci_set_drvdata(pdev, shost);
+ printk("SAH\n");
error = scsi_add_host(shost, &pdev->dev);
if (error)
goto out_free_irq;
+ printk("SSH\n");
scsi_scan_host(shost);
return 0;
out_free_irq:
I get the following:
SAH
SSH
SCB Q
SCB EXEC
SCB EXEC DONE
After ~3 secs the system freezes.
On Jan 22, 2008 12:20 AM, Alan Cox <[email protected]> wrote:
> Ok my attempt to get the card failed so we are going to have to do this
> the hard way. See where this patch crashes and what it prints
>
> (On top of the other patches)
>
> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.24-rc8-mm1/drivers/scsi/initio.c linux-2.6.24-rc8-mm1/drivers/scsi/initio.c
> --- linux.vanilla-2.6.24-rc8-mm1/drivers/scsi/initio.c 2008-01-19 14:22:43.000000000 +0000
> +++ linux-2.6.24-rc8-mm1/drivers/scsi/initio.c 2008-01-21 14:54:48.000000000 +0000
> @@ -2537,10 +2537,12 @@
> struct Scsi_Host *dev = dev_id;
> unsigned long flags;
> int r;
> -
> +
> + printk("ISR\n");
> spin_lock_irqsave(dev->host_lock, flags);
> r = initio_isr((struct initio_host *)dev->hostdata);
> spin_unlock_irqrestore(dev->host_lock, flags);
> + printk("ISR DONE %d\n", r);
> if (r)
> return IRQ_HANDLED;
> else
> @@ -2643,6 +2645,7 @@
> struct initio_host *host = (struct initio_host *) cmd->device->host->hostdata;
> struct scsi_ctrl_blk *cmnd;
>
> + printk("SCB QUEUE\n");
> cmd->scsi_done = done;
>
> cmnd = initio_alloc_scb(host);
> @@ -2650,7 +2653,9 @@
> return SCSI_MLQUEUE_HOST_BUSY;
>
> initio_build_scb(host, cmnd, cmd);
> + printk("SCB EXEC\n");
> initio_exec_scb(host, cmnd);
> + printk("SCB EXEC DONE\n");
> return 0;
> }
>
> @@ -2766,6 +2771,8 @@
> struct scsi_cmnd *cmnd; /* Pointer to SCSI request block */
> struct initio_host *host;
> struct scsi_ctrl_blk *cblk;
> +
> + printk("SCB POST\n");
>
> host = (struct initio_host *) host_mem;
> cblk = (struct scsi_ctrl_blk *) cblk_mem;
> @@ -2934,9 +2941,11 @@
>
> pci_set_drvdata(pdev, shost);
>
> + printk("SAH\n");
> error = scsi_add_host(shost, &pdev->dev);
> if (error)
> goto out_free_irq;
> + printk("SSH\n");
> scsi_scan_host(shost);
> return 0;
> out_free_irq:
>
On Tue, 2008-01-22 at 19:50 +0200, Filippos Papadopoulos wrote:
> I get the following:
> SAH
> SSH
> SCB Q
> SCB EXEC
> SCB EXEC DONE
Actually, I suspect your issues should be fixed by this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e2d435ea4084022ab88efa74214accb45b1f9e92
Could you download 2.6.24 and try it out to see if they are?
Thanks,
James
On 1/25/08, James Bottomley <[email protected]> wrote:
>
> Actually, I suspect your issues should be fixed by this patch:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e2d435ea4084022ab88efa74214accb45b1f9e92
>
> Could you download 2.6.24 and try it out to see if they are?
>
> Thanks,
>
> James
>
Well, 2.6.24 fixes the problem.
Thanks to all of you!