Re: Qlogic Fiber Channel
Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit : > > From my point of view, this driver is sadly broken. The fun part is that > > the qlogic driver is certainly based on this one too (look at the code, > > the drivers differs not so much). > > And if the other one is stable someone should spend the time merging the > two. That what I would like to try but It seems impossible without an IP-enhanced firmware. I could try with the old firmware but I believe that the new code from QLogic use some features that are only in recent firmware. > > > IMHO the qlogicfc driver should be removed from the kernel tree and > > perhaps replaced by the last qlogic one. We then lost the IP support > > but this is a broken support. > > For 2.5 that may wellk make sense. Personally I'd prefer someone worked > out > why the qlogicfc driver behaves as it does. It sounds like two small bugs > nothing more > > 1.That the FC event code wasnt updated from 2.2 so now runs > with IRQ's off when it didnt expect it > > 2.That someone has a slight glitch in the queue handling. This driver is already buggy under kernel 2.2. This driver is a well known source of problems in the GFS mailing lists. I believe that the better thing to do is to use the qlogic driver. If we manage to get a recent IP-enhanced firmware we could rewrite the missing IP code. Half of the job is already done in the source of this driver. I didn't manage to reach the good person from qlogic. Perhaps someone would have better results. Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: Qlogic Fiber Channel
The qlogicfc driver is based on the chris loveland work. You can find outdated information here : http://www.iol.unh.edu/consortiums/fc/linux/qlogic.html From my point of view, this driver is sadly broken. The fun part is that the qlogic driver is certainly based on this one too (look at the code, the drivers differs not so much). If you don't need IP support then keep using the qlogic driver which is far better. I'm pretty sure that they have a working IP enhanced version but for an unknow reason this one is not released. And without the IP-enhanced firmware we can do nothing. I've unsuccessfully tried to get information from qlogic and others a few weeks ago. IMHO the qlogicfc driver should be removed from the kernel tree and perhaps replaced by the last qlogic one. We then lost the IP support but this is a broken support. The qlogicfc driver blocks the kernel each time a FC event occured and is know to failed under heavy load (not so heavy, under load IMHO). Christophe On Fri, 29 Jun 2001 12:52:53 Mike Black wrote: > I have been running successfully with qla2x00src-4.15Beta.tgz for several > months now over several kernel versions up to 2.4.5. > When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD > MISTAKE!!! > > #1 - My system had crashed (for a different reason) and when the raid5 > was > resyncing and e2fsck happening at the same time the kernel locked with > messages from qlogicfc.o: > qlogicfc0: no handle slots, this should not happen. > hostdata->queue is 2a, inptr: 74 > I was able to repeat this several times so it's a consistent error. > Waiting for the raid resync to finish did allow this complete -- but now > when I come in the next morning the console is locked up and no network > access either. So I reset it. Checked the logs and here it is again: > Jun 29 03:39:21 yeti kernel: qlogicfc0 : no handle slots, this should not > happen. > Jun 29 03:39:21 yeti kernel: hostdata->queued is 36, in_ptr: 13 > This was during a tape backup. > > So I'm switching back to qla2x00src-4.15Beta.tgz -- which does the resync > and e2fsck just fine together BTW. > Jun 29 06:22:47 yeti kernel: qla2x00: detect() found an HBA > Jun 29 06:22:47 yeti kernel: qla2x00: VID=1077 DID=2100 SSVID=0 SSDID=0 > > Only problem is I don't see this package on qlogic's website anymore and > their "beta" directory is empty now. I'm waiting to see what their tech > support says. > > > Michael D. Black Principal Engineer > [EMAIL PROTECTED] 321-676-2923,x203 > http://www.csihq.com Computer Science Innovations > http://www.csihq.com/~mike My home page > FAX 321-676-2355 > > - > 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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: Qlogic Fiber Channel
The qlogicfc driver is based on the chris loveland work. You can find outdated information here : http://www.iol.unh.edu/consortiums/fc/linux/qlogic.html From my point of view, this driver is sadly broken. The fun part is that the qlogic driver is certainly based on this one too (look at the code, the drivers differs not so much). If you don't need IP support then keep using the qlogic driver which is far better. I'm pretty sure that they have a working IP enhanced version but for an unknow reason this one is not released. And without the IP-enhanced firmware we can do nothing. I've unsuccessfully tried to get information from qlogic and others a few weeks ago. IMHO the qlogicfc driver should be removed from the kernel tree and perhaps replaced by the last qlogic one. We then lost the IP support but this is a broken support. The qlogicfc driver blocks the kernel each time a FC event occured and is know to failed under heavy load (not so heavy, under load IMHO). Christophe On Fri, 29 Jun 2001 12:52:53 Mike Black wrote: I have been running successfully with qla2x00src-4.15Beta.tgz for several months now over several kernel versions up to 2.4.5. When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD MISTAKE!!! #1 - My system had crashed (for a different reason) and when the raid5 was resyncing and e2fsck happening at the same time the kernel locked with messages from qlogicfc.o: qlogicfc0: no handle slots, this should not happen. hostdata-queue is 2a, inptr: 74 I was able to repeat this several times so it's a consistent error. Waiting for the raid resync to finish did allow this complete -- but now when I come in the next morning the console is locked up and no network access either. So I reset it. Checked the logs and here it is again: Jun 29 03:39:21 yeti kernel: qlogicfc0 : no handle slots, this should not happen. Jun 29 03:39:21 yeti kernel: hostdata-queued is 36, in_ptr: 13 This was during a tape backup. So I'm switching back to qla2x00src-4.15Beta.tgz -- which does the resync and e2fsck just fine together BTW. Jun 29 06:22:47 yeti kernel: qla2x00: detect() found an HBA Jun 29 06:22:47 yeti kernel: qla2x00: VID=1077 DID=2100 SSVID=0 SSDID=0 Only problem is I don't see this package on qlogic's website anymore and their beta directory is empty now. I'm waiting to see what their tech support says. Michael D. Black Principal Engineer [EMAIL PROTECTED] 321-676-2923,x203 http://www.csihq.com Computer Science Innovations http://www.csihq.com/~mike My home page FAX 321-676-2355 - 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/ -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: Qlogic Fiber Channel
Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit : From my point of view, this driver is sadly broken. The fun part is that the qlogic driver is certainly based on this one too (look at the code, the drivers differs not so much). And if the other one is stable someone should spend the time merging the two. That what I would like to try but It seems impossible without an IP-enhanced firmware. I could try with the old firmware but I believe that the new code from QLogic use some features that are only in recent firmware. IMHO the qlogicfc driver should be removed from the kernel tree and perhaps replaced by the last qlogic one. We then lost the IP support but this is a broken support. For 2.5 that may wellk make sense. Personally I'd prefer someone worked out why the qlogicfc driver behaves as it does. It sounds like two small bugs nothing more 1.That the FC event code wasnt updated from 2.2 so now runs with IRQ's off when it didnt expect it 2.That someone has a slight glitch in the queue handling. This driver is already buggy under kernel 2.2. This driver is a well known source of problems in the GFS mailing lists. I believe that the better thing to do is to use the qlogic driver. If we manage to get a recent IP-enhanced firmware we could rewrite the missing IP code. Half of the job is already done in the source of this driver. I didn't manage to reach the good person from qlogic. Perhaps someone would have better results. Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: Is this still the linux-kernel list?
Hi great David; Normally I would have just ignored your mail but one of your so great points seems to fit with one of my recent post (perhaps you thought about others) and I would like to give you my opinion about it. On Wed, 13 Jun 2001 08:11:33 David Lang wrote: > now we have the 'code from this company or anyone working there is not > acceptable (now matter how well written) and may not even be looked at' > > this sure doesn't seem like the same list that I have been reading for > the > last four years. > > remember guys, it's supposed to be about the code. As long as the code is > under an acceptable license who it's from or what it's going to touch > isn't supposed to be the issue, the issue is supposed to be 'is this code > an improvement (in performance, style, algorithm, etc combined)' if it is > it makes it in. I've recently send two mails about the isp2200 qlogic driver (qlogicfc) included in the kernel. Two facts: The qlogicfc driver in the kernel is outdated. Qlogic provides a newer one. The main difference is that qlogic disable the IP support for an unknown reason. The IP support is a usefull feature but the status of this driver is IMHO "broken". I think we should replace it by the newer from qlogic or remove it. The only thing that the IP feature does it to influence customers to buy the qlogic card for a feature which reveals to be not available when you start using it. That's what I've done and I know that I'm not the only one. It's interesting to know that this "IP over FC" feature is provided by other cards. From a more general point of view. I fully disagree with your "only code matters" approch. I strongly believe in the Free Software goal and It seems to be the case of many linux kernel hackers. The kernel must IMHO be DFSG compliant. Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: Is this still the linux-kernel list?
Hi great David; Normally I would have just ignored your mail but one of your so great points seems to fit with one of my recent post (perhaps you thought about others) and I would like to give you my opinion about it. On Wed, 13 Jun 2001 08:11:33 David Lang wrote: now we have the 'code from this company or anyone working there is not acceptable (now matter how well written) and may not even be looked at' this sure doesn't seem like the same list that I have been reading for the last four years. remember guys, it's supposed to be about the code. As long as the code is under an acceptable license who it's from or what it's going to touch isn't supposed to be the issue, the issue is supposed to be 'is this code an improvement (in performance, style, algorithm, etc combined)' if it is it makes it in. I've recently send two mails about the isp2200 qlogic driver (qlogicfc) included in the kernel. Two facts: The qlogicfc driver in the kernel is outdated. Qlogic provides a newer one. The main difference is that qlogic disable the IP support for an unknown reason. The IP support is a usefull feature but the status of this driver is IMHO broken. I think we should replace it by the newer from qlogic or remove it. The only thing that the IP feature does it to influence customers to buy the qlogic card for a feature which reveals to be not available when you start using it. That's what I've done and I know that I'm not the only one. It's interesting to know that this IP over FC feature is provided by other cards. From a more general point of view. I fully disagree with your only code matters approch. I strongly believe in the Free Software goal and It seems to be the case of many linux kernel hackers. The kernel must IMHO be DFSG compliant. Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
rawIO documentation
I'm looking for a documentation about rawIO, directIO. Has anybody good URLs for me ? Thanks, Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
rawIO documentation
I'm looking for a documentation about rawIO, directIO. Has anybody good URLs for me ? Thanks, Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
qlogicfc driver
My previous mail about Qlogic Fiber Channel driver didn't get so many attention. The QLogic support is like a wall. You can't use a normal e-mail. Instead of that you should use a http form. And the answer you get is anonymous and IMHO a standart one. "... Please check our site periodically for driver updates. QLogic CSG Product Support " I know that they have a working IP enhanced driver, DOCs are distributed under NDA and the IP-enhanced firmware also. What we have in the kernel today is a nearly broken driver with an obscure firmware. I believe that this situation only tell (lie) people "this card is supported under linux" and so they buy this hardware. That's what I've done. I'm ready to spend time to modify the driver but I'm not fluent in firmware microcode reading and I've not managed to find documentations. There's no maintener for it and Chris Loveland is unreachable. If somebody has a valid email address for Chris Loveland, Please send it to me. If somebody can give me a email address for a HUMAN person working for QLogic (I hate their e-support What about removing this driver ? Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
qlogicfc driver
My previous mail about Qlogic Fiber Channel driver didn't get so many attention. The QLogic support is like a wall. You can't use a normal e-mail. Instead of that you should use a http form. And the answer you get is anonymous and IMHO a standart one. ... Please check our site periodically for driver updates. QLogic CSG Product Support I know that they have a working IP enhanced driver, DOCs are distributed under NDA and the IP-enhanced firmware also. What we have in the kernel today is a nearly broken driver with an obscure firmware. I believe that this situation only tell (lie) people this card is supported under linux and so they buy this hardware. That's what I've done. I'm ready to spend time to modify the driver but I'm not fluent in firmware microcode reading and I've not managed to find documentations. There's no maintener for it and Chris Loveland is unreachable. If somebody has a valid email address for Chris Loveland, Please send it to me. If somebody can give me a email address for a HUMAN person working for QLogic (I hate their e-support What about removing this driver ? Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
Fiber Channel Driver
Hi,
I'm currently trying the Fiber Channel driver for the isp2x00 chip.
This driver supports both SCSI and IP.
I've some questions about the implementation.
I've made some unsuccessfull internet search.
The better URL I've found is the following one :
http://www.iol.unh.edu/consortiums/fc/linux/qlogic.html
This URL points Chris Loveland ([EMAIL PROTECTED]) as the maintener.
But the mail address is no more valid.
(reason: 550 <[EMAIL PROTECTED]>... User unknown)
Has someone a more acurate e-mail address?
The driver (qlogicfc.c qlogicfc.h qlogicfc_asm.c) provide a firmware
(v1.17.30). I know this is a recuring lkml subject but it comes in a
microcode form and so it's hard to know what it does. I would greatly
appreciate if someone can indicate me some documents.
Moreover this firmware (copyrigth-ed by QLogic) differs from the one
currently distributed by Qlogic (v1.19.16).
Qlogic provides a driver which as-is doen't support IP. In the source we
can see that everything is there to support it. In the makefile we see that
we can build all with IP support but two files are missing. They certainly
do what they want with their drivers (why hide a driver?) but what estonish
me is that they have two firmware versions : one special for IP support
(and
this is one of the missing files).
So Why I'm so interrested in the firmware ?
Because I believe the QLogic driver is better implemented. I can see that
this driver is an evolution from the one actually in the kernel.
The driver in the kernel have some strange things like :
-> X seconds busy loop (when using the driver, the system sometimes lock
during few seconds).
-> Re-entrance in functions that IMHO don't support that:
qlogicfc.c:isp2x00_queuecommand()
-> Some interesting comments like the one who introduces
isp2x00_mbox_command().
/*
* currently, this is only called during initialization or abort/reset,
* at which times interrupts are disabled, so polling is OK, I guess...
*/
static int isp2x00_mbox_command(struct Scsi_Host *host, u_short param[])
{
...
while (--loop_count && inw(host->io_port + HOST_HCCR) & 0x0080)
barrier();
...
isp2x00_intr_handler(host->irq, host, NULL);
...
}
So I started to modify the code to use a thread to queue commands and to
avoid locking the kernel with busy loop.
I'm on the way but I've since found that this is what does the QLogic
driver (except that they hide the IP support). I would like to take part of
the code (under GPL) but I'm not sure that the firmware (older version)
would allow that.
Any Remarqs, Suggestions Links would be good.
Thank you,
Christophe
--
Christophe Barbé
Software Engineer - [EMAIL PROTECTED]
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com
-
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.19 and LFS patch?
Sistina (www.sistina.com) provides one in its last GFS release (v4.1). This pach IIRC is based on the SUSE one. Christophe On Wed, 30 May 2001 23:54:16 David Hajek wrote: > Hi, > > where can I get large file system (LFS) patch > for 2.2.19? > > > Thanks. > > -- > David Hajek > [EMAIL PROTECTED]GSM: +420 604 352968 > - System going down in 5 minutes. > - > 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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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.19 and LFS patch?
Sistina (www.sistina.com) provides one in its last GFS release (v4.1). This pach IIRC is based on the SUSE one. Christophe On Wed, 30 May 2001 23:54:16 David Hajek wrote: Hi, where can I get large file system (LFS) patch for 2.2.19? Thanks. -- David Hajek [EMAIL PROTECTED]GSM: +420 604 352968 - System going down in 5 minutes. - 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/ -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
Fiber Channel Driver
Hi,
I'm currently trying the Fiber Channel driver for the isp2x00 chip.
This driver supports both SCSI and IP.
I've some questions about the implementation.
I've made some unsuccessfull internet search.
The better URL I've found is the following one :
http://www.iol.unh.edu/consortiums/fc/linux/qlogic.html
This URL points Chris Loveland ([EMAIL PROTECTED]) as the maintener.
But the mail address is no more valid.
(reason: 550 [EMAIL PROTECTED]... User unknown)
Has someone a more acurate e-mail address?
The driver (qlogicfc.c qlogicfc.h qlogicfc_asm.c) provide a firmware
(v1.17.30). I know this is a recuring lkml subject but it comes in a
microcode form and so it's hard to know what it does. I would greatly
appreciate if someone can indicate me some documents.
Moreover this firmware (copyrigth-ed by QLogic) differs from the one
currently distributed by Qlogic (v1.19.16).
Qlogic provides a driver which as-is doen't support IP. In the source we
can see that everything is there to support it. In the makefile we see that
we can build all with IP support but two files are missing. They certainly
do what they want with their drivers (why hide a driver?) but what estonish
me is that they have two firmware versions : one special for IP support
(and
this is one of the missing files).
So Why I'm so interrested in the firmware ?
Because I believe the QLogic driver is better implemented. I can see that
this driver is an evolution from the one actually in the kernel.
The driver in the kernel have some strange things like :
- X seconds busy loop (when using the driver, the system sometimes lock
during few seconds).
- Re-entrance in functions that IMHO don't support that:
qlogicfc.c:isp2x00_queuecommand()
- Some interesting comments like the one who introduces
isp2x00_mbox_command().
/*
* currently, this is only called during initialization or abort/reset,
* at which times interrupts are disabled, so polling is OK, I guess...
*/
static int isp2x00_mbox_command(struct Scsi_Host *host, u_short param[])
{
...
while (--loop_count inw(host-io_port + HOST_HCCR) 0x0080)
barrier();
...
isp2x00_intr_handler(host-irq, host, NULL);
...
}
So I started to modify the code to use a thread to queue commands and to
avoid locking the kernel with busy loop.
I'm on the way but I've since found that this is what does the QLogic
driver (except that they hide the IP support). I would like to take part of
the code (under GPL) but I'm not sure that the firmware (older version)
would allow that.
Any Remarqs, Suggestions Links would be good.
Thank you,
Christophe
--
Christophe Barbé
Software Engineer - [EMAIL PROTECTED]
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com
-
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: fifo behaviour is broken in 2.4.4
DSel=0 DScale=0 PME- > > 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M > Mobility AGP 2x (rev 64) (prog-if 00 [VGA]) > Subsystem: Dell Computer Corporation: Unknown device 009e > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping+ SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR-Latency: 66 (2000ns min), cache line size 08 > Interrupt: pin A routed to IRQ 11 > Region 0: Memory at fd00 (32-bit, non-prefetchable) > [size=16M] > Region 1: I/O ports at 2000 [size=256] > Region 2: Memory at fc00 (32-bit, non-prefetchable) [size=4K] > Expansion ROM at [disabled] [size=128K] > Capabilities: [50] AGP version 1.0 > Status: RQ=255 SBA+ 64bit- FW- Rate=x1,x2 > Command: RQ=0 SBA- AGP- 64bit- FW- Rate= > Capabilities: [5c] Power Management version 1 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > 02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) > Subsystem: Xircom Cardbus Ethernet 10/100 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR-Latency: 64 (5000ns min, 1ns max) > Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at 1800 [size=128] > Region 1: Memory at 1480 (32-bit, non-prefetchable) [size=2K] > Region 2: Memory at 14800800 (32-bit, non-prefetchable) [size=2K] > Expansion ROM at 1440 [size=16K] > Capabilities: [dc] Power Management version 1 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=2 PME- > > 02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) > (prog-if 02 [16550]) > Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR-Interrupt: pin A routed to IRQ 11 > Region 0: I/O ports at 1880 [size=8] > Region 1: Memory at 14801000 (32-bit, non-prefetchable) [size=2K] > Region 2: Memory at 14801800 (32-bit, non-prefetchable) [size=2K] > Expansion ROM at 14404000 [size=16K] > Capabilities: [dc] Power Management version 1 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=2 PME- > > > > [7.6] /proc/scsi/scsi NA > > [7.7] - > > > [8.] Method in [6.] tested on 2.4.3 and Solaris 2.6 both work as > expected. > > > Cheers, > Dean. > > -- > Dean.A.Darlison > [EMAIL PROTECTED] > Dasco Ltd. > http://www.dasco.ltd.uk/ > - > 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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: fifo behaviour is broken in 2.4.4
: RQ=0 SBA- AGP- 64bit- FW- Rate=none Capabilities: [5c] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03) Subsystem: Xircom Cardbus Ethernet 10/100 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: 64 (5000ns min, 1ns max) Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 1800 [size=128] Region 1: Memory at 1480 (32-bit, non-prefetchable) [size=2K] Region 2: Memory at 14800800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 1440 [size=16K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 02:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem (rev 03) (prog-if 02 [16550]) Subsystem: Xircom CBEM56G-100 Ethernet + 56k Modem 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- Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 1880 [size=8] Region 1: Memory at 14801000 (32-bit, non-prefetchable) [size=2K] Region 2: Memory at 14801800 (32-bit, non-prefetchable) [size=2K] Expansion ROM at 14404000 [size=16K] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- [7.6] /proc/scsi/scsi NA [7.7] - [8.] Method in [6.] tested on 2.4.3 and Solaris 2.6 both work as expected. Cheers, Dean. -- Dean.A.Darlison [EMAIL PROTECTED] Dasco Ltd. http://www.dasco.ltd.uk/ - 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/ -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: sk_buff destructor in 2.2.18
I believe you and It's sure that I have not tested all cases. So do you see a way to use a private data buffer ? Christophe On Wed, 23 May 2001 16:55:57 Andi Kleen wrote: > On Wed, May 23, 2001 at 04:50:28PM +0200, christophe barbé wrote: > > I don't know about socket but I allocate myself the skbuff and I set > the > > destructor (and previously the pointer value is NULL). So I don't > overwrite > > a destructor. > > That just means you didn't test all cases; e.g. not TCP or UDP > send/receive. > > > > > > > I believe net/core/sock.c is not involved in my problem but I can be > wrong. > > What is worrying me is that I don't know who clones my skbuff and why. > > skbuffs are cloned all over the stack for various reasons. > > > > To said everything, I know who clones my skbuff because it causes a > oops > > when it tries to free my buffer If I use my destructor. > > Because you're mistakely using a private field. > > > -Andi > - > 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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: sk_buff destructor in 2.2.18
I don't know about socket but I allocate myself the skbuff and I set the destructor (and previously the pointer value is NULL). So I don't overwrite a destructor. I believe net/core/sock.c is not involved in my problem but I can be wrong. What is worrying me is that I don't know who clones my skbuff and why. To said everything, I know who clones my skbuff because it causes a oops when it tries to free my buffer If I use my destructor. Christophe On Wed, 23 May 2001 16:40:36 Andi Kleen wrote: > On Wed, May 23, 2001 at 04:37:58PM +0200, christophe barbé wrote: > > It seems to not be the case, because my destructor is called. > > It is called, but you overwrote the kernel destructor and therefore > broke the socket memory accounting completely; causing all kinds of > problems. > > > Could you point me the code where you think this method is already > used? > > net/core/sock.c > > > -Andi > > - > 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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: sk_buff destructor in 2.2.18
It seems to not be the case, because my destructor is called. Could you point me the code where you think this method is already used? Thank you for your answer, Christophe On Wed, 23 May 2001 16:27:39 Andi Kleen wrote: > On Wed, May 23, 2001 at 04:16:54PM +0200, christophe barbé wrote: > > Hi all, > > > > I'm trying to figure out how to use the destructor function in the > skbuff > > object. > > I've read (the source code and) the alan cox's article from > linuxjournal > > but it refers to linux 2.0. > > Perhaps someone can tell me what's wrong in the following : > > You can't use the destructor; it is already used by the main stack for > socket > memory management. > > -Andi > - > 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/ > -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
sk_buff destructor in 2.2.18
Hi all, I'm trying to figure out how to use the destructor function in the skbuff object. I've read (the source code and) the alan cox's article from linuxjournal but it refers to linux 2.0. Perhaps someone can tell me what's wrong in the following : Normally the rx code of a network driver do the following code : allocate a skbuff skb=dev_alloc_skb(length); if (skb==NULL) ... fill data skb_put(skb,length); memcpy((void *)skb->data, buf,length); end so on ... In my case, I own the incomming buffer so I would like to use it directly without copying data. I've written a new allocation function. And use the destructor to free my buffer (replacing it on a free list). First I imagine something is wrong because the destructor is called before kfree_skbmem() so If I don't lie to skb->cloned (I set it to 1), an unexpected skb->head occured. I think the destructor method is provided to free privates data not the main data. But I can't see an another way to do it. Secondly, When my destructor function is called, the cloned flag is already set (and datarefp indicates also that data is referenced elsewhere). When is a skbuff cloned? Is there a way to avoid this? Where can I register a function to free (= replace it in my list) the data buffer? Thank you, Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
sk_buff destructor in 2.2.18
Hi all, I'm trying to figure out how to use the destructor function in the skbuff object. I've read (the source code and) the alan cox's article from linuxjournal but it refers to linux 2.0. Perhaps someone can tell me what's wrong in the following : Normally the rx code of a network driver do the following code : allocate a skbuff skb=dev_alloc_skb(length); if (skb==NULL) ... fill data skb_put(skb,length); memcpy((void *)skb-data, buf,length); end so on ... In my case, I own the incomming buffer so I would like to use it directly without copying data. I've written a new allocation function. And use the destructor to free my buffer (replacing it on a free list). First I imagine something is wrong because the destructor is called before kfree_skbmem() so If I don't lie to skb-cloned (I set it to 1), an unexpected skb-head occured. I think the destructor method is provided to free privates data not the main data. But I can't see an another way to do it. Secondly, When my destructor function is called, the cloned flag is already set (and datarefp indicates also that data is referenced elsewhere). When is a skbuff cloned? Is there a way to avoid this? Where can I register a function to free (= replace it in my list) the data buffer? Thank you, Christophe -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: sk_buff destructor in 2.2.18
It seems to not be the case, because my destructor is called. Could you point me the code where you think this method is already used? Thank you for your answer, Christophe On Wed, 23 May 2001 16:27:39 Andi Kleen wrote: On Wed, May 23, 2001 at 04:16:54PM +0200, christophe barbé wrote: Hi all, I'm trying to figure out how to use the destructor function in the skbuff object. I've read (the source code and) the alan cox's article from linuxjournal but it refers to linux 2.0. Perhaps someone can tell me what's wrong in the following : You can't use the destructor; it is already used by the main stack for socket memory management. -Andi - 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/ -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: sk_buff destructor in 2.2.18
I don't know about socket but I allocate myself the skbuff and I set the destructor (and previously the pointer value is NULL). So I don't overwrite a destructor. I believe net/core/sock.c is not involved in my problem but I can be wrong. What is worrying me is that I don't know who clones my skbuff and why. To said everything, I know who clones my skbuff because it causes a oops when it tries to free my buffer If I use my destructor. Christophe On Wed, 23 May 2001 16:40:36 Andi Kleen wrote: On Wed, May 23, 2001 at 04:37:58PM +0200, christophe barbé wrote: It seems to not be the case, because my destructor is called. It is called, but you overwrote the kernel destructor and therefore broke the socket memory accounting completely; causing all kinds of problems. Could you point me the code where you think this method is already used? net/core/sock.c -Andi - 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/ -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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: sk_buff destructor in 2.2.18
I believe you and It's sure that I have not tested all cases. So do you see a way to use a private data buffer ? Christophe On Wed, 23 May 2001 16:55:57 Andi Kleen wrote: On Wed, May 23, 2001 at 04:50:28PM +0200, christophe barbé wrote: I don't know about socket but I allocate myself the skbuff and I set the destructor (and previously the pointer value is NULL). So I don't overwrite a destructor. That just means you didn't test all cases; e.g. not TCP or UDP send/receive. I believe net/core/sock.c is not involved in my problem but I can be wrong. What is worrying me is that I don't know who clones my skbuff and why. skbuffs are cloned all over the stack for various reasons. To said everything, I know who clones my skbuff because it causes a oops when it tries to free my buffer If I use my destructor. Because you're mistakely using a private field. -Andi - 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/ -- Christophe Barbé Software Engineer - [EMAIL PROTECTED] Lineo France - Lineo High Availability Group 42-46, rue Médéric - 92110 Clichy - France phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01 http://www.lineo.com - 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/
