Menu
▾
▴
Re: [Iscsitarget-devel] Kernel bug or?
|
From: EpsiloN E. <ep...@gm...> - 2012-07-19 12:18:07
|
Thanks for the reply, I was really able to install ietd from SVN. Now server is up and running, hope this issue is now from past. Thanks again. Regards, Igor. On Thu, Jul 19, 2012 at 9:35 AM, Arne Redlich <arn...@go...>wrote: > 2012/7/19 EpsiloN EpsiloN <ep...@gm...>: > > Hi, > > > > In parallel I raised same question on QuakeNet #debian channel. After > some > > research of iscsi_trgt.ko ix found : > > > > 16:19 <@ix> i checked on you iscsi problem and unfotunately it's not one > of > > the easily fixed ones | the BUG is caused be disk_check_ua > > 17:11 <@ix> hard to tell. disk_check_ua tries to fetch a unit attention > > structure from a linked list and disk_check_ua does not expect that > there is > > no such > > structure. which is why it's using the fetched ua without > > checking, hence NULL pointer deref when there is no such structure | i > don't > > know much > > about the scsi subsystem, but my best guess would be that > newer > > kernels also might not always deliver an ua | you could try to handle the > > case > > that there is no ua > > > > Hopes this info will be helpful on correcting the bug. > > Did you try the code from svn? I.e. > > svn co https://iscsitarget.svn.sourceforge.net/svnroot/iscsitargetiscsitarget > > and then build the code in branches/1.4.20 > . > > HTH, > Arne > > > Some time after I upgraded kernel to 3.2.0-0.bpo.2-686-pae. This went > fine, > > without any problems. But there is a problem with adding DKMS: > > > > DKMS make.log for iscsitarget-1.4.20.2 for kernel 3.2.0-0.bpo.2-686-pae > > (i686) > > make: Entering directory `/usr/src/linux-headers-3.2.0-0.bpo.2-686-pae' > > LD /var/lib/dkms/iscsitarget/1.4.20.2/build/built-in.o > > LD /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/built-in.o > > CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/tio.o > > CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.o > > CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/nthread.o > > CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.o > > /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.c: In function > > ‘worker_thread’: > > /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.c:75: error: > > implicit declaration of function ‘copy_io_context’ > > make[4]: *** [/var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.o] > > Error 1 > > make[3]: *** [/var/lib/dkms/iscsitarget/1.4.20.2/build/kernel] Error 2 > > make[2]: *** [_module_/var/lib/dkms/iscsitarget/1.4.20.2/build] Error 2 > > make[1]: *** [sub-make] Error 2 > > make: *** [all] Error 2 > > make: Leaving directory `/usr/src/linux-headers-3.2.0-0.bpo.2-686-pae' > > > > Any ideas how to solve this issue? Hope to you feedback, thanks. > > > > Regards, > > Igor. > > > > > > > > On Mon, Jul 16, 2012 at 3:34 PM, EpsiloN EpsiloN <ep...@gm...> > wrote: > >> > >> Hi, > >> > >> I measured IO for some time before and after I tuned (packet elevator > >> disabled, extended surface scan delay, write cache 100%, enabled device > >> write cache) HP SmartArray. During measurements I didn't find any > problems > >> with IO again before and after. > >> > >> Here are my results taken after SmartArtay tuning: > >> > >> # sar > >> 12:00:01 AM CPU %usr %nice %sys %iowait %steal > >> %irq %soft %guest %idle > >> Average: all 0.01 0.00 1.64 0.00 0.00 > >> 0.02 0.52 0.00 97.81 > >> > >> 12:00:01 AM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s > >> pgscand/s pgsteal/s %vmeff > >> Average: 17.21 6512.16 72.98 0.00 1730.86 0.00 > >> 0.00 0.00 0.00 > >> > >> 12:00:01 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit > >> %commit > >> Average: 2846544 258640 8.33 114553 77173 488793 > >> 13.6 > >> > >> 12:00:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s > >> txcmp/s rxmcst/s > >> Average: lo 0.00 0.00 0.00 0.00 0.00 > >> 0.00 0.00 > >> Average: eth2 112.56 0.14 35.88 0.01 0.00 > >> 0.00 0.00 > >> Average: eth3 4840.63 0.14 31.34 0.01 0.00 > >> 0.00 0.00 > >> Average: eth0 15.56 2509.20 6.05 55.30 0.00 > >> 0.00 0.02 > >> Average: eth1 12.15 0.14 0.96 0.01 0.00 > >> 0.00 0.02 > >> > >> 12:00:01 AM IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s > >> txcarr/s rxfram/s rxfifo/s txfifo/s > >> Average: lo 0.00 0.00 0.00 0.00 0.00 > >> 0.00 0.00 0.00 0.00 > >> Average: eth2 0.00 0.00 0.00 0.00 0.00 > >> 0.00 0.00 0.00 0.00 > >> Average: eth3 0.00 0.00 0.00 0.00 0.00 > >> 0.00 0.00 0.00 0.00 > >> Average: eth0 0.00 0.00 0.00 0.00 0.00 > >> 0.00 0.00 0.00 0.00 > >> Average: eth1 0.00 0.00 0.00 0.00 0.00 > >> 0.00 0.00 0.00 0.00 > >> > >> After this tuning server worked for a week, maybe a little bit more and > >> stuck again: > >> > >> # messages > >> Jul 14 11:23:46 ISCSI kernel: [951754.937998] BUG: unable to handle > kernel > >> NULL pointer dereference at 00000010 > >> > >> Any idea what can be done? Upgrade to newest kernel? Just to remind, > right > >> now I am using Debian 6.0.5 with 2.6.32-5-686 kernel. > >> > >> > >> > >> > >> Another interesting thing that Debian changes MAC addressed of of the > >> interfaces: > >> > >> # daemon.log > >> Jul 14 01:16:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.12 > -> > >> 192.168.10.9 > >> Jul 14 01:26:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.9 -> > >> 192.168.10.8 > >> Jul 14 01:36:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.8 -> > >> 192.168.10.12 > >> Jul 14 01:46:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.12 > -> > >> 192.168.10.9 > >> Jul 14 03:26:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.9 -> > >> 192.168.10.8 > >> Jul 14 03:36:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.8 -> > >> 192.168.10.12 > >> Jul 14 03:46:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.12 > -> > >> 192.168.10.12 > >> Jul 14 03:56:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.12 > -> > >> 192.168.10.9 > >> Jul 14 04:06:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.9 -> > >> 192.168.10.12 > >> Jul 14 04:16:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.12 > -> > >> 192.168.10.9 > >> Jul 14 04:26:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.9 -> > >> 192.168.10.8 > >> Jul 14 04:36:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.8 -> > >> 192.168.10.12 > >> Jul 14 05:36:56 ISCSI ntpd[2355]: 192.168.10.3 interface 192.168.10.12 > -> > >> 192.168.10.12 > >> > >> # dmesg > >> [ 8.700280] udev[591]: renamed network interface eth0 to eth0-eth2 > >> [ 8.700754] udev[592]: renamed network interface eth1 to eth1-eth3 > >> [ 8.708680] udev[562]: renamed network interface eth2 to eth0 > >> [ 8.709146] udev[565]: renamed network interface eth3 to eth1 > >> [ 8.750784] udev[591]: renamed network interface eth0-eth2 to eth2 > >> [ 8.751307] udev[592]: renamed network interface eth1-eth3 to eth3 > >> > >> This some kind of "Layer 2 fail-over". My server has 4 physical NICs > and 4 > >> IPs assigned to ethX interfaces. I take three cables off and was able > still > >> ping all four IP addreses. My ARP table showed that a;; server's IP > adressed > >> now resolve to same MAC, MAC of the remained interface. Is this some > kind on > >> normal behavior? > >> > >> Regards, > >> Igor. > >> > >> > >> > >> On Fri, Jun 29, 2012 at 2:45 PM, EpsiloN EpsiloN <ep...@gm...> > >> wrote: > >>> > >>> Hello, > >>> > >>> Thanks for the replies. > >>> So I will measure the IO that filesystem is requesting and IO that I > get > >>> from RAID controller. > >>> And create as many targets as possible. I will let you know about > >>> results. > >>> > >>> Regards, > >>> Igor. > >>> > >>> > >>> On Fri, Jun 29, 2012 at 1:45 PM, Emmanuel Florac < > ef...@in...> > >>> wrote: > >>>> > >>>> Le Thu, 28 Jun 2012 19:59:34 +0300 > >>>> Pasi Kärkkäinen <pa...@ik...> écrivait: > >>>> > >>>> > IETD shouldn't crash anyway.. > >>>> > > >>>> > >>>> Sure. As I said, he triggered a bug. However as he's using the > standard > >>>> Debian port, his best bet is a workaround rather than switching to > >>>> trunk and recompile (without any warranty that this particular bug has > >>>> been squashed). > >>>> > >>>> -- > >>>> > ------------------------------------------------------------------------ > >>>> Emmanuel Florac | Direction technique > >>>> | Intellique > >>>> | <ef...@in...> > >>>> | +33 1 78 94 84 02 > >>>> > ------------------------------------------------------------------------ > >>> > >>> > >> > > > |
