Jay,
Yes, I'm currently using the server with be2iscsi, non-multipath, and
against an IET target. The problem seems to mainly occur when the
traffic being passed is very low. I'll post a wireshark dump in a
couple of hours.
Thanks,
Seth
On 12 July 2011 19:40, jayamohan.kallic...@emulex.com
Seth,
The CQ Error 13 is done mostly when a Fin is received. If the same problem
can be repro'd on iet , can you pl capture the wireshark trace on the target.
That would be very helpful.
Also, if NOP's are being sent ,then, I would assume the traffic is low and
wireshark would not drop
On 07/04/2011 08:34 AM, Seth Simons wrote:
Yep, I do see those. I figured they were from the iscsi layer. Is it
worth validating the configuration first *without* using multipath?
It's fairly trivial to disable. The only reason i've not tried this
yet is that the same problem happened when
Mike,
Thanks for the speedy reply!
The hung task warnings are saying that some IO has taken longer than the
hung task timeout value which looks like it is 2 miniutes for you.
Are you doing any type of port down/up type of test?
Nope, just the following:
- Power on blade
- be2iscsi BIOS logs
Unfortunately there's very little technical documentation. This is one
of HP's 'low end' SANs. I'll see if HP support has anything to say
about it.
I'm not really having luck with be2iscsi, now that i've managed to get
it to login to the target, I'm getting the following kernel panic
after around
On 07/01/2011 08:57 AM, Seth Simons wrote:
Unfortunately there's very little technical documentation. This is one
of HP's 'low end' SANs. I'll see if HP support has anything to say
about it.
I'm not really having luck with be2iscsi, now that i've managed to get
it to login to the target,
On 06/29/2011 09:28 AM, Seth Simons wrote:
I've managed to get this target to work now. The steps I had to take were:
- Use the latest 2.6.39 kernel and open-iscsi userland (to make be2iscsi work)
- Disable the 'Load Balancing' feature on the HP P4300s (to make the
target behave itself)
On 06/30/2011 06:48 PM, Mike Christie wrote:
On 06/29/2011 09:28 AM, Seth Simons wrote:
I've managed to get this target to work now. The steps I had to take were:
- Use the latest 2.6.39 kernel and open-iscsi userland (to make be2iscsi
work)
- Disable the 'Load Balancing' feature on the HP
On 06/30/2011 08:59 PM, Mike Christie wrote:
On 06/30/2011 06:48 PM, Mike Christie wrote:
On 06/29/2011 09:28 AM, Seth Simons wrote:
I've managed to get this target to work now. The steps I had to take were:
- Use the latest 2.6.39 kernel and open-iscsi userland (to make be2iscsi
work)
-
I've managed to get this target to work now. The steps I had to take were:
- Use the latest 2.6.39 kernel and open-iscsi userland (to make be2iscsi work)
- Disable the 'Load Balancing' feature on the HP P4300s (to make the
target behave itself)
Confusingly, the 'load balancing' option on the
Interesting news: I have just tried using a different iscsi target,
the linux IET included with Debian, and am able to discover using
sendtargets and also to login to the targets using the be2iscsi
driver. I am now fiddling with the target to see if I can figure out
what it's doing wrong. In case
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Thursday, June 16, 2011 3:22 PM
To: open-iscsi@googlegroups.com
Cc: Seth Simons; Kallickal, Jayamohan
Subject: Re: unable to login to targets with be2iscsi
On 06/16/2011 02:31 PM, Seth Simons wrote:
...and
Hi,
As suggested, I'm trying iscsistart -b. The be2iscsi module is already
loaded at this point. The iscsi_tcp stuff is irrelevant, that's just
what i've used to get the system booted so I can capture more detailed
log output.
At the moment i'm in a debian initramfs, which is being booted by the
On 06/16/2011 01:27 PM, Seth Simons wrote:
Hi,
As suggested, I'm trying iscsistart -b. The be2iscsi module is already
loaded at this point. The iscsi_tcp stuff is irrelevant, that's just
what i've used to get the system booted so I can capture more detailed
log output.
At the moment i'm
Ah, normally you need iscsid running when iscsiadm is run. I think
normally people just run iscsistart in the initramfs, then when the
system runs on the real root we start iscsid and do discovery.
Do you just get an error about not being able to connect to iscsid and
that the default
On 06/16/2011 01:58 PM, Seth Simons wrote:
i've not tried, as these are meant to be diskless machines. I'll give
it a go with usb stick or something similar. I expect a similar
Ok, try it by turning off the bios boot support. So do not run
iscsistart. Just start iscsid and run the iscsiadm
On 06/16/2011 02:31 PM, Seth Simons wrote:
...and here's some wireshark dumps showing this happen, from server
reboot until the initramfs prompt. From this point, i ran iscsistart
-f followed by iscsistart -b.
Did you take the trace from the box running the initiator or some other
box on the
On 06/16/2011 02:54 PM, Mike Christie wrote:
On 06/16/2011 02:31 PM, Seth Simons wrote:
...and here's some wireshark dumps showing this happen, from server
reboot until the initramfs prompt. From this point, i ran iscsistart
-f followed by iscsistart -b.
Did you take the trace from the box
On 06/16/2011 02:31 PM, Seth Simons wrote:
...and here's some wireshark dumps showing this happen, from server
reboot until the initramfs prompt. From this point, i ran iscsistart
-f followed by iscsistart -b.
Jay,
Did you see the wireshark trace in the previous mail? The problem starts
in
Hi Mike,
Thanks for the speedy reply!
I've set the initiator name the same in the bios and in the OS. Do
they *have* to be different? I can see the logic in having each
transport have a different name, but it seems not to be the case with
the other qlogic iscsi HBAs i'm using.
As for Log
I'll make a trace shortly. The only reason iscsi_tcp is loaded is so that
the target can boot its OS and run an iscsiadm discovery. As far as I
understand it, iscsiadm still can't discover if there's no route to the
target.
On Jun 9, 2011 6:15 PM, jayamohan.kallic...@emulex.com wrote:
Thanks for
On 06/09/2011 02:38 AM, Seth Simons wrote:
Hi Mike,
Thanks for the speedy reply!
I've set the initiator name the same in the bios and in the OS. Do
they *have* to be different? I can see the logic in having each
No. For things like boot they will actually be the same.
I was just trying
Oh yeah, to be able to use be2iscsi for root like below you must use
be2iscsi for the initial boot (the bios int13 boot). So in the bios
screens for be2iscsi, set the target you want to boot from, boot from
it, then the commands below will use that same info for root boot.
On 06/09/2011 01:12 PM,
On 06/09/2011 12:34 PM, jayamohan.kallic...@emulex.com wrote:
I'll make a trace shortly. The only reason iscsi_tcp is loaded is so that the
target can boot its OS and run an iscsiadm discovery. As far as I understand
it, iscsiadm still can't discover if there's no route to the target.
I'll make a trace shortly. The only reason iscsi_tcp is loaded is so that the
target can boot its OS and run an iscsiadm discovery. As far as I understand
it, iscsiadm still can't discover if there's no route to the target.
We do not need a IP route for discovery thru be2iscsi. Pl use the
Thanks for the speedy reply!
I've set the initiator name the same in the bios and in the OS. Do
they *have* to be different? I can see the logic in having each
transport have a different name, but it seems not to be the case with
the other qlogic iscsi HBAs i'm using.
There is no requirement on
On 06/08/2011 11:58 AM, Seth Tunstall wrote:
I also see the following errors in syslog:
[ 4635.562395] (beiscsi_process_cq():1953):CQ Error 13, reset CID
0xd00...
Is this the first line of the log or is there anything else?
It looks like 13 is:
#define CXN_KILLED_FIN_RCVD 13
27 matches
Mail list logo
