Re: Initiator name missing
You have a older version. Just rm the old setup files: rm /etc/iscsi/nodes rm /etc/iscsi/send_targets or your version/distro might put it in /var/lib rm /var/lib/iscsi/nodes rm /var/lib/iscsisend_targets Also make sure that in iscsid.conf both the discovery username/password and node username/password settings are removed. On Jan 4, 2013, at 6:37 PM, Jeff Bye jeff...@gogoluckey.com wrote: 2.0-871 is what I'm running Jeff On Fri, Jan 4, 2013 at 4:17 PM, Jeff Bye jeff...@gogoluckey.com wrote: I tried all of the commands and none of them worked for me: deadlineserver@deadlineserver ~ $ iscsiadm -m discoverydb -t st -p 10.10.0.1:3260 -o delete iscsiadm -m discovery [ -hV ] [ -d debug_level ] [-P printlevel] [ -t type -p ip:port -I ifaceN ... [ -l ] ] | [ -p ip:port ] [ -o operation ] [ -n name ] [ -v value ] iscsiadm -m node [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -L all,manual,automatic ] [ -U all,manual,automatic ] [ -S ] [ [ -T targetname -p ip:port -I ifaceN ] [ -l | -u | -R | -s] ] [ [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m session [ -hV ] [ -d debug_level ] [ -P printlevel] [ -r sessionid | sysfsdir [ -R | -u | -s ] [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m iface [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -I ifacename ] [ [ -o operation ] [ -n name ] [ -v value ] ] iscsiadm -m fw [ -l ] iscsiadm -m host [ -P printlevel ] [ -H hostno ] iscsiadm -k priority I checked man iscsiadm and found: -m, --mode op specify the mode. op must be one of discovery, node, fw, host iface or session. If no other options are specified: for discovery and node, all of their respective records are displayed; for session, all active sessions and connections are displayed; for fw, all boot firmware values are displayed; for host, all iSCSI hosts are displayed; and for iface, all ifaces setup in /etc/iscsi/ifaces are displayed. Am I running the wrong version perhaps? Jeff On Thu, Jan 3, 2013 at 7:05 PM, Mike Christie micha...@cs.wisc.edu wrote: The iscsid.conf values are the defaults one used to setup the port/node/target db. If you clear the iscsid.conf values, you would still need to update the db ones for it to take effect on existing targets you have already setup. For the discovery values you can either delete the old discovery record: iscsiadm -m discoverydb -t st -p ip -o delete When you run the discovery command next, then it will use the iscsid.conf settings to create the discovery record. or if your tools does not support that command you can clear the chap settings iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.username -v iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.password -v iscsiadm -m discoverydb -t st -p ip -o update -n discovery.sendtargets.auth.authmethod -v none On 01/03/2013 01:46 PM, Jeff Bye wrote: Hey! I've been out of town for a couple of weeks. Hope you had a chance to take some time off as well :) It seems that the username and password I had initially set up is still being used, however in iscsid.conf CHAP is set to none and any other information has been commented. Does this only affect the target side? Jeff When I had it running on a windows machine (a temporary setup) we kept it open and On Fri, Dec 21, 2012 at 1:32 AM, Mike Christie micha...@cs.wisc.edu mailto:micha...@cs.wisc.edu wrote: On 12/20/2012 06:54 PM, GGL wrote: deadlineserver@deadlineserver / $ sudo iscsiadm -m discovery -t sendtargets -p 10.10.0.1 iscsiadm: Login authentication failed with target Yeah, this is a CHAP failure. Is it turned off on the target too? Could you run sudo iscsiadm -m discovery -t sendtargets -p 10.10.0.1 -d 8 and send all the output? Also while running this command run: tcpdump -w iscsi.discovery.out -i your_eth_device and then send that iscsi.discovery.out file. It will show us what the target is sending on the wire too. Both of those files will have passwords in them if you have CHAP settings still being used, so send me them in private or edit out the values if you do not want them on the open. -- Jeff Bye Graphics Coordinator Liberty Post 12910 Culver Blvd. Suite G Los Angeles, CA 90066 (310) 314-3900 x247 -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- Jeff Bye Graphics Coordinator Liberty Post 12910 Culver Blvd. Suite G Los Angeles,
[PATCH 0/5] kfifo cleanup and log based kfifo API
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc/init. This may introduce
several potential issues.
First, the kfifo size is not what we want. Say, if we want to
allocate a kfifo with size of 127 elements. Then in the end, we can
only hold 64 elements. Here is a similar example at
drivers/hid/hid-logitech-dj.c:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do something like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Second, kfifo_init used a pre-allocated buffer, and the actual
buffer size is determined in caller side, while the actual kfifo
buffer size is maintained in kfifo_init, which will be rounded down
power of 2 without notifying to caller. Take the example of code at
drivers/scsi/libiscsi.c:
/* If the user passed an items pointer, he wants a copy of
* the array. */
if (items)
num_arrays++;
q-pool = kzalloc(num_arrays * max * sizeof(void*), GFP_KERNEL);
if (q-pool == NULL)
return -ENOMEM;
kfifo_init(q-queue, (void*)q-pool, max * sizeof(void*));
for (i = 0; i max; i++) {
q-pool[i] = kzalloc(item_size, GFP_KERNEL);
if (q-pool[i] == NULL) {
q-max = i;
goto enomem;
}
kfifo_in(q-queue, (void*)q-pool[i], sizeof(void*));
}
Assume max is not power of 2, this piece of code will not work! As
it assumes the kfifo will hold max elements, but actually it can
only hold rounddown_power_of_2(max).
My proposal is to replace kfifo_init with kfifo_alloc, where it
allocate buffer and maintain fifo size inside kfifo. Then we can
remove buggy kfifo_init.
After we change the kfifo_alloc to be a log API, all above issue
will be gone as said by Stefani.
Here is the patch summary:
patch 1 is a cleanup patch to cleanup the unneeded type check.
patch 2 and 3 turn the only 2 users of kfifo_init to kfifo_alloc
patch 4 remove kfifo_init
patch 5 log based kfifo API
Thanks!
--yliu
Cc: Stefani Seibold stef...@seibold.net
Cc: Andrew Morton a...@linux-foundation.org
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: iscsi list open-iscsi@googlegroups.com
Cc: Mike Christie micha...@cs.wisc.edu
---
Yuanhan Liu (5):
kfifo: remove unnecessary type check
libsrp: replace kfifo_init with kfifo_alloc
libiscsi: replace kfifo_init with kfifo_alloc
kfifo: remove kfifo_init
kfifo: log based kfifo API
arch/arm/plat-omap/Kconfig |2 +-
arch/arm/plat-omap/mailbox.c|6 +-
arch/powerpc/sysdev/fsl_rmu.c |2 +-
drivers/char/sonypi.c |9 ++-
drivers/hid/hid-logitech-dj.c |7 +-
drivers/iio/industrialio-event.c|2 +-
drivers/iio/kfifo_buf.c |3 +-
drivers/infiniband/hw/cxgb3/cxio_resource.c |8 ++-
drivers/media/i2c/cx25840/cx25840-ir.c |9 ++-
drivers/media/pci/cx23885/cx23888-ir.c |9 ++-
drivers/media/pci/meye/meye.c |6 +-
drivers/media/pci/meye/meye.h |2 +
drivers/media/rc/ir-raw.c |7 +-
drivers/memstick/host/r592.h|2 +-
drivers/mmc/card/sdio_uart.c|4 +-
drivers/mtd/sm_ftl.c|5 +-
drivers/net/wireless/libertas/main.c|4 +-
drivers/net/wireless/rt2x00/rt2x00dev.c |5 +-
drivers/pci/pcie/aer/aerdrv_core.c |3 +-
drivers/platform/x86/fujitsu-laptop.c |5 +-
drivers/platform/x86/sony-laptop.c |6 +-
drivers/rapidio/devices/tsi721.c|5 +-
drivers/scsi/libiscsi.c | 59
drivers/scsi/libiscsi_tcp.c |6 +-
drivers/scsi/libsrp.c | 22 +++---
drivers/staging/omapdrm/omap_plane.c|5 +-
drivers/tty/n_gsm.c |4 +-
drivers/tty/nozomi.c|5 +-
drivers/tty/serial/ifx6x60.c|2 +-
[PATCH 3/5] libiscsi: replace kfifo_init with kfifo_alloc
kfifo_init will use a pre-allocated buffer as fifo buffer; the buffer
size is determinted at caller side. While, kfifo will maintain a real
kfifo buffer size(rounddown power of 2 aligned). So, the two size may
not be equal.
So, if max is not power of 2, this code will not work. As it assume the
kfifo is able to hold max elments, but it is able to hold less than max
only.
To be safe, we should use kfifo_alloc instead, though it will not
address this issue. But a later patch to refactor kfifo_alloc to be a
log API will fix it.
Besides that, I refactored the code a bit with the style used in
libsrp.c: allocated items once by kcalloc.
Cc: Mike Christie micha...@cs.wisc.edu
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: iscsi list open-iscsi@googlegroups.com
Cc: Stefani Seibold stef...@seibold.net
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
drivers/scsi/libiscsi.c | 59 ---
include/scsi/libiscsi.h |4 +-
2 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 82c3fd4..8e60f1f 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2485,51 +2485,52 @@ EXPORT_SYMBOL_GPL(iscsi_eh_recover_target);
int
iscsi_pool_init(struct iscsi_pool *q, int max, void ***items, int item_size)
{
- int i, num_arrays = 1;
-
- memset(q, 0, sizeof(*q));
+ int i;
+ int ret;
+ void *item;
- q-max = max;
+ ret = -ENOMEM;
+ q-pool = kcalloc(max, item_size, GFP_KERNEL);
+ if (!q-pool)
+ goto err_out;
- /* If the user passed an items pointer, he wants a copy of
-* the array. */
- if (items)
- num_arrays++;
- q-pool = kzalloc(num_arrays * max * sizeof(void*), GFP_KERNEL);
- if (q-pool == NULL)
- return -ENOMEM;
+ ret = kfifo_alloc(q-queue, max * sizeof(void *), GFP_KERNEL);
+ if (ret 0)
+ goto free_pool;
- kfifo_init(q-queue, (void*)q-pool, max * sizeof(void*));
-
- for (i = 0; i max; i++) {
- q-pool[i] = kzalloc(item_size, GFP_KERNEL);
- if (q-pool[i] == NULL) {
- q-max = i;
- goto enomem;
+ q-items_ptr = NULL;
+ /* If the user passed an items pointer, he wants a copy of the array */
+ if (items) {
+ q-items_ptr = kcalloc(max, sizeof(void *), GFP_KERNEL);
+ if (!q-items_ptr) {
+ ret = -ENOMEM;
+ goto free_fifo;
}
- kfifo_in(q-queue, (void*)q-pool[i], sizeof(void*));
+ *items = q-items_ptr;
}
- if (items) {
- *items = q-pool + max;
- memcpy(*items, q-pool, max * sizeof(void *));
+ for (i = 0, item = q-pool; i max; i++, item += item_size) {
+ kfifo_in(q-queue, item, sizeof(void *));
+ if (q-items_ptr)
+ q-items_ptr[i] = item;
}
return 0;
-enomem:
- iscsi_pool_free(q);
- return -ENOMEM;
+free_fifo:
+ kfifo_free(q-queue);
+free_pool:
+ kfree(q-pool);
+err_out:
+ return ret;
}
EXPORT_SYMBOL_GPL(iscsi_pool_init);
void iscsi_pool_free(struct iscsi_pool *q)
{
- int i;
-
- for (i = 0; i q-max; i++)
- kfree(q-pool[i]);
kfree(q-pool);
+ kfree(q-items_ptr);
+ kfifo_free(q-queue);
}
EXPORT_SYMBOL_GPL(iscsi_pool_free);
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 6e33386..c4262c6 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -231,8 +231,8 @@ struct iscsi_conn {
struct iscsi_pool {
struct kfifoqueue; /* FIFO Queue */
- void**pool; /* Pool of elements */
- int max;/* Max number of elements */
+ void*pool; /* Pool of elements */
+ void**items_ptr;/* element pointers */
};
/* Session's states */
--
1.7.7.6
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 5/5] kfifo: log based kfifo API
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Cc: Stefani Seibold stef...@seibold.net
Cc: Andrew Morton a...@linux-foundation.org
Cc: linux-o...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: libertas-...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: open-iscsi@googlegroups.com
Cc: linux-s...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: linux-ser...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: d...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
arch/arm/plat-omap/Kconfig |2 +-
arch/arm/plat-omap/mailbox.c|6 +++-
arch/powerpc/sysdev/fsl_rmu.c |2 +-
drivers/char/sonypi.c |9 ---
drivers/hid/hid-logitech-dj.c |7 +++--
drivers/iio/industrialio-event.c|2 +-
drivers/iio/kfifo_buf.c |3 +-
drivers/infiniband/hw/cxgb3/cxio_resource.c |8 --
drivers/media/i2c/cx25840/cx25840-ir.c |9 +--
drivers/media/pci/cx23885/cx23888-ir.c |9 +--
drivers/media/pci/meye/meye.c |6 +---
drivers/media/pci/meye/meye.h |2 +
drivers/media/rc/ir-raw.c |7 +++--
drivers/memstick/host/r592.h|2 +-
drivers/mmc/card/sdio_uart.c|4 ++-
drivers/mtd/sm_ftl.c|5 +++-
drivers/net/wireless/libertas/main.c|4 ++-
drivers/net/wireless/rt2x00/rt2x00dev.c |5 +--
drivers/pci/pcie/aer/aerdrv_core.c |3 +-
drivers/platform/x86/fujitsu-laptop.c |5 ++-
drivers/platform/x86/sony-laptop.c |6 ++--
drivers/rapidio/devices/tsi721.c|5 ++-
drivers/scsi/libiscsi_tcp.c |6 +++-
drivers/staging/omapdrm/omap_plane.c|5 +++-
drivers/tty/n_gsm.c |4 ++-
drivers/tty/nozomi.c|5 +--
drivers/tty/serial/ifx6x60.c|2 +-
drivers/tty/serial/ifx6x60.h|3 +-
drivers/tty/serial/kgdb_nmi.c |7 +++--
drivers/usb/host/fhci.h |4 ++-
drivers/usb/serial/cypress_m8.c |4 +-
drivers/usb/serial/io_ti.c |4 +-
drivers/usb/serial/ti_usb_3410_5052.c |7 +++--
drivers/usb/serial/usb-serial.c |2 +-
include/linux/kfifo.h | 31 +--
include/linux/rio.h |1 +
include/media/lirc_dev.h|4 ++-
kernel/kfifo.c |9 +--
mm/memory-failure.c |3 +-
net/dccp/probe.c|6 +++-
net/sctp/probe.c|6 +++-
samples/kfifo/bytestream-example.c |8 +++---
samples/kfifo/dma-example.c |5 ++-
samples/kfifo/inttype-example.c |7 +++--
samples/kfifo/record-example.c |6 ++--
45 files changed, 142 insertions(+), 108 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 665870d..7eda02c 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -124,7 +124,7 @@ config OMAP_MBOX_FWK
DSP, IVA1.0 and IVA2 in OMAP1/2/3.
config OMAP_MBOX_KFIFO_SIZE
- int Mailbox kfifo default buffer size (bytes)
+ int Mailbox kfifo default buffer size (bytes,
Antw: [PATCH 0/5] kfifo cleanup and log based kfifo API
Yuanhan Liu yuanhan@linux.intel.com schrieb am 08.01.2013 um 15:57 in Nachricht 1357657073-27352-1-git-send-email-yuanhan@linux.intel.com: [...] My proposal is to replace kfifo_init with kfifo_alloc, where it allocate buffer and maintain fifo size inside kfifo. Then we can remove buggy kfifo_init. [...] Spontaneously I feel that emitting a critical message if the requested size is not a power of two would be a good idea, as well as (in that case) rounding up to the next power of two instead of rounding down seems not too stupid ;-) Sorry, I'm not deeply into recent kernel development. Regards, Ulrich -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Antw: [PATCH 0/5] kfifo cleanup and log based kfifo API
On Tue, Jan 08, 2013 at 04:03:17PM +0100, Ulrich Windl wrote: Yuanhan Liu yuanhan@linux.intel.com schrieb am 08.01.2013 um 15:57 in Nachricht 1357657073-27352-1-git-send-email-yuanhan@linux.intel.com: [...] My proposal is to replace kfifo_init with kfifo_alloc, where it allocate buffer and maintain fifo size inside kfifo. Then we can remove buggy kfifo_init. [...] Spontaneously I feel that emitting a critical message if the requested size is not a power of two would be a good idea, Hi Ulrich, If we can emit all such critical message at compile time, it would be good then. But we can't, as fifo size is runtime determinated in quite many cases. as well as (in that case) rounding up to the next power of two instead of rounding down seems not too stupid ;-) There are 2 issues, first, you just can't round the fifo size up to power of 2 for kfifo_init as fifo buffer is allocated outside. And if you do, you may access memory outside the buffer. Second, round up to power of 2 inside kfifo_alloc and DECLARE_KFIFO is simple and should work. But it wastes memory(by allocating more memory) without notifing caller. So, per discussed with Stefani, we better to change the API be log aware to root fix this kind of potential issue. Thanks. --yliu -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Problem with auto-starup on Debian 6
I'm having problem configuring open-iscsi on Debian 6 to automatically start-up. I've configured everything and if I manually run *invoke-rc.d open-iscsi restart* then it runs fine! However after a simple reboot, nothing happens. This is the log in the daemon.log / syslog: Jan 8 11:31:51 ssdkvm iscsid: iSCSI logger with pid=1985 started! Jan 8 11:31:52 ssdkvm iscsid: transport class version 2.0-870. iscsid version 2.0-871 Jan 8 11:31:52 ssdkvm iscsid: iSCSI daemon with pid=1986 started! Jan 8 11:31:53 ssdkvm iscsid: connection1:0 is operational now . Jan 8 11:32:18 ssdkvm iscsid: transport class version 2.0-870. iscsid version 2.0-871 Jan 8 11:32:18 ssdkvm iscsid: iSCSI daemon with pid=929 started! *Jan 8 11:32:18 ssdkvm iscsid: cannot make a connection to 2a00:. (-1,101)* * * Why is this happening? Is the network not up when this line is present? (possibly because of IPv6?) How can I fix it? Remove the line from rcS.d and append *invoke-rc.d open-iscsi start *to rc.local? Regards, Zsolt -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/gMNaQs8I6lsJ. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 5/5] kfifo: log based kfifo API
Dmitry Torokhov dmitry.torok...@gmail.com wrote:
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct
dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct
dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order,
GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Why don't you simply change __kfifo_alloc to round the allocation up
instead of down?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dmitry,
I agree. I don't see the benefit in pushing up the change to a kfifo internal
decision/problem to many different places in the kernel.
Regards,
Andy
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 5/5] kfifo: log based kfifo API
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Why don't you simply change __kfifo_alloc to round the allocation up
instead of down?
Thanks.
--
Dmitry
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: Problem with auto-starup on Debian 6
On 01/08/2013 05:39 AM, zsolt@gmail.com wrote: I'm having problem configuring open-iscsi on Debian 6 to automatically start-up. I've configured everything and if I manually run *invoke-rc.d open-iscsi restart* then it runs fine! However after a simple reboot, nothing happens. This is the log in the daemon.log / syslog: Jan 8 11:31:51 ssdkvm iscsid: iSCSI logger with pid=1985 started! Jan 8 11:31:52 ssdkvm iscsid: transport class version 2.0-870. iscsid version 2.0-871 Jan 8 11:31:52 ssdkvm iscsid: iSCSI daemon with pid=1986 started! Jan 8 11:31:53 ssdkvm iscsid: connection1:0 is operational now . Jan 8 11:32:18 ssdkvm iscsid: transport class version 2.0-870. iscsid version 2.0-871 Jan 8 11:32:18 ssdkvm iscsid: iSCSI daemon with pid=929 started! *Jan 8 11:32:18 ssdkvm iscsid: cannot make a connection to 2a00:. (-1,101)* * * Why is this happening? Is the network not up when this line is present? Probably. It might be coming up. 101 is ENETUNREACH Network is unreachable, so the networking might be coming up while is also starting up. It might be that by the time you can log in and run commands, the network is up so your invoke call then works. Does Your iscsid.conf have the setting initial_login_retry_max? You can try increasing this. Make sure that you have disabled remove invalid portals that are not going to come up or we will wait on them, and also remember to run iscsiadm -o update to update the existing settings with the new value or rerun the discovery command. (possibly because of IPv6?) How can I fix it? Remove the line from rcS.d and append *invoke-rc.d open-iscsi start *to rc.local? Regards, Zsolt -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/gMNaQs8I6lsJ. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
