October 2012 - kernelnewbies@kernelnewbies.org

Regarding KGDB setup over serial cable
by Vivek Panwar Oct. 19, 2012

Oct. 19, 2012

Hi All, I am making a setup for kernel debugging over Null modem serial cable , i am trying to make it work on x86 arch machine.I have a straight serial DB9 cable(Having both female ports) which i converted into NULL MODEM CABLE bye doing below rework: *Pin of port #1....goes to....Pin of port #2 2 RxD <-------------> TxD 3 3 TxD <-------------> RxD 2 5 GND <-------------> GND 5 Please check pin connections ones and let me know if i am doing wrong. I have connected NULL MODEM serial (both female port) cable between two machines via USB to serial coverter cable.I have check the connection between two machine through MINICOM and its works fine.Till this point i didnt face any issue , now lets come to the next point. * 1) Download stable kernel 3.4.9 (kernel having inbuilt KGDB support) 2) run make menuconfig command and did the below changes to enable KGDB a) CONFIG_HAVE_ARCH_KGDB=y b) CONFIG_KGDB=y c) CONFIG_KGDB_SERIAL_CONSOLE=y* *3) compiled the kernel image successfully * *4) make modules 5) make modules_install 6) make install 7) update grub Below is the grub update detail from grub.cfg file in which i have added following rule for the kernel to wait for the GDB connection establish : *kgdbwait kgdb8250=ttyUSB0,115200,kgdboc=ttyUSB0,115200* menuentry 'Ubuntu, with Linux 3.4.9' --class ubuntu --class gnu-linux --class gnu --class os { recordfail set gfxpayload=$linux_gfx_mode insmod part_msdos insmod ext2 set root='(/dev/sda,msdos1)' search --no-floppy --fs-uuid --set=root 6ef7b91e-7416-4908-97ba-bfb212081a68 linux /boot/vmlinuz-3.4.9 root=/dev/sda1 ro quiet splash vt.handoff=7 *kgdbwait kgdb8250=ttyUSB0,115200,kgdboc=ttyUSB0,115200* } Booted my machine with the above kernel but i am getting kernel panic not the below message which we expected to get waiting for gdb connection ........ Please suggest me the right procedure for make this set up work , i am very new to Linux. Thanks in advance Thanks Vivek **

2 7

another kernel tutorial: tasklets
by Robert P. J. Day Oct. 19, 2012

Oct. 19, 2012

http://www.crashcourse.ca/wiki/index.php/Tasklets next up ... work queues. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

Regarding udevadm
by Rahul Bedarkar Oct. 18, 2012

Oct. 18, 2012

Hi, I am using udevadm info to get information about connected block devices. I have attached usb device and disabled auto mounting of it. I can see kernel logs that device is added and node is created. But when I use udevadm info --export-db, I can't see device info of /dev/sdb1 If I use udevadm monitor --kernel to monitor kernel udev events, I can see KERNEL[1419.590316] remove /block/sdb/sdb1 (block) KERNEL[1419.622381] remove /block/sdb (block) KERNEL[1430.528523] add /block/sdb (block) KERNEL[1430.564808] add /block/sdb/sdb1 (block) Why /dev/sdb1 is not getting displayed in case udevadm info ? Thanks, Rahul B.

1 0

looking for current, online kernel-related tutorials
by Robert P. J. Day Oct. 18, 2012

Oct. 18, 2012

a *very* wide-ranging post, but i'm currently trying to collect any well-written and *current* tutorials on *any* aspect of kernel programming, device drivers and related stuff like that there -- especially those that come with working, hands-on examples. the biggest drawback with a lot of the online tutorials and the in-kernel Documentation content is that much of it is simply out-of-date and finding really good tutorials is a bit of a challenge, so if anyone has suggestions for things like that (or has written such things), by all means, post pointers to them and i'll start making a list. and what's in it for you? i'm starting some wiki pages for as many topics as i can think of: http://www.crashcourse.ca/wiki/index.php/Kernel_topics for now, things will be fairly concise, i just want to collect the content. these wiki pages will be permanently publicly available, so it's not like i'm asking anyone to do the work, at which point i'll take the results and keep them for myself. in addition, the *eventual* goal is to incorporate the results in some updated linux kernel programming courseware, which will all be released under the creative commons license so, again, at no point will any of this content suddenly disappear. at the moment, i'm working with karim yaghmour of opersys.com, who recently open-sourced all his courseware -- http://www.opersys.com/training -- and i'm working on updating the two linux courses for the 3.x kernel. when those linux course manuals are updated, they will be posted and will still be under the creative commons license. in the end, i may reorganize the wiki content if i come up with a more accessible structure, but it will never disappear. so if you know of any excellent tutorials out there, let me know, and i'll add that to the wiki where everyone can take advantage. and now, back to work ... rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

5 9

How do I know what is the patch's parent?
by Yang Chengwei Oct. 18, 2012

Oct. 18, 2012

Hi List, I have a question when I try to apply kernel patches from mailing list. The question is how can I know it's parent so it can be apply without conflicts? -- Thanks, Chengwei

2 1

simple scsi device mapper module
by Dmitry Filippov Oct. 18, 2012

Oct. 18, 2012

Hi, Recently i've started with development of kernel module, which uses existing block devices/partitions as backend and represents itself as scsi disk. i've found good start point - scsi_debug module which is in official kernel tree under drivers/scsi/ i suppose you are aware about this module. So in fact it is low level scsi adapter which represents itself as scsi disk /dev/sd? on the system and uses RAM as backend storage. actually what i need! so my general idea was to use this it as base and do some changes in IO. scsi_debug IO is trivial. It allocates memory by vmalloc() in __init to fake_storep pointer. and then use it in IO. but the problem appeared for me to rewrite these places of fake_storep usage to write/read to existing block device. i've investigated of how device mapper achieve this. - by generic block layer. the key tool is submit_bio(). Well, submit_bio is not difficult and i was able to read and write bios to/from block device. How writing is done in scsi_debug: scsi_debug has .queuecommand = scsi_debug_queuecommand which switch scsi command to READ/WRITE_6/10/12/16/32 and calls resp_read/write() they both call do_device_access() and it in turn fetch_to_dev_buffer or fill_from_dev_buffer if read or write required. both them use scsi_sg_copy_to_buffer or sg_copy_from_buffer... so these functions eventually fetch/fill scsi response buffer from existing fake RAM storage. all seems to be fine and clear before trying to replace RAM storage by real block device. the problem is that then we are in scsi_debug_queuecommand we can not block(sleep). any attempt to call function that may block causes oops. or even hang. with BUG: sleeping function called from invalid context because of upstream scsi layers holds locks while handling request as for example scsi_dispatch_cmd from drivers/scsi/scsi.c: ... spin_lock_irqsave(host->host_lock, flags); ... in case of scsi WRITE command i have workaround. i can simply allocate some temporary buffer with GFP_ATOMIC to handle write request (its max size 512K - scsi mid layer breaks request to low level adapter in these chunks). pass this buffer to scsi_sg_copy_to_buffer - it will fill my temporary buffer without blocking. then setup workqueue work and actual submit_bio() to block device will be handled later from thread context where such operations are normal. the problem is with response to READ. scsi_debug just uses sg_copy_from_buffer from RAM storage - where data is always uptodate. but in my case i need to read data from block device by submit_bio first and only after this can use buffer updated to pass it to sg_copy_from_buffer... I still don't have idea how to accomplish this. does anyone have any idea? thank you in advance for any suggestions or criticism. thanks, Dmitry

2 1

Re: Online tutorial on system calls
by m k Oct. 18, 2012

Oct. 18, 2012

Hi Robert, I have just joined the mailing list and very new to Kernel so this tutorial is something I'm sure I'll find very useful. Thanks! Cheers M On Thu, Oct 18, 2012 at 3:00 AM, <kernelnewbies-request(a)kernelnewbies.org>wrote: > Send Kernelnewbies mailing list submissions to > kernelnewbies(a)kernelnewbies.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > or, via email, send a message with subject or body 'help' to > kernelnewbies-request(a)kernelnewbies.org > > You can reach the person managing the list at > kernelnewbies-owner(a)kernelnewbies.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Kernelnewbies digest..." > > > Today's Topics: > > 1. quick online tutorial on system calls (Robert P. J. Day) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Oct 2012 10:56:05 -0400 (EDT) > From: "Robert P. J. Day" <rpjday(a)crashcourse.ca> > Subject: quick online tutorial on system calls > To: Kernel Newbies <kernelnewbies(a)kernelnewbies.org> > Message-ID: <alpine.DEB.2.02.1210171053160.27774@oneiric> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > another in an ongoing series of things i'm just throwing together, > mostly to document stuff for my own benefit to use later in courseware > when i figure out what to do with it. here's a summary i wrote this > morning on system calls, which turned out to be longer than i'd > planned (it just kind of got away from me): > > http://www.crashcourse.ca/wiki/index.php/System_calls > > but a lot of it is just cutting and pasting kernel source for > explanatory purposes. feedback welcome. > > rday > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== > > > > ------------------------------ > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies(a)kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > End of Kernelnewbies Digest, Vol 23, Issue 25 > ********************************************* >

1 0

Re: scsi adapter module over block device - need help
by Greg Freemyer Oct. 17, 2012

Oct. 17, 2012

Sorry, dropped kernelnewbies somehow. Please keep them in cc. Your message and my reply below. On Wed, Oct 17, 2012 at 6:46 PM, Greg Freemyer <greg.freemyer(a)gmail.com> wrote: > On Wed, Oct 17, 2012 at 12:06 PM, Dmitry Filippov <filippovd20(a)gmail.com> wrote: >> Greg, >> >> thank you for reply! >> Yeah there is a kind of analogy to network stack in scsi stack. >> >> the are 3 layers in scsi stack: >> upper layer (sg, sd, sr, st drivers) that implements high level abstraction >> middle layer which routes scsi commnads/requests to low level drivers >> low layer - actually host adapters. low level drivers which registers >> within scsi stack, gets scsi commands from mid layer and perform >> actual actions on device. >> >> so from file system any syscall reaches vfs layer first, and then to >> upper scsi layer. >> >> thanks, >> Dmitry > > vfs actually talks to the block i/o layer which may or may not include > multiple device mapper layers. Device mapper (DM) can of course > implement logical volumes and/or some raid levels by combining > multiple block devices. It can also do block translations etc. > > (There is also the MD layer, but I don't really know how it fits in. > DM is a newer subsystem and has a cleaner architecture I believe, but > it doesn't offer as many raid levels as MD does. You can have both DM > and MD in use together if appropriate.) > > At the bottom of the stack there is also a scsi-physical layer: much > like IP can travel over multiple physical media (Ethernet, T1/E1, > etc.) scsi can traverse lots of different physical media. > > And then in some cases there is a translation layer below that. SAT > (SCSI / ATA Translation) is the best known and typically implemented > in external USB carriers. > > So it's more like: > > syscall -> > vfs -> > (block layer <-> device mapper <-> MD) -> > scsi upper layer -> > scsi mid layer -> > scsi low layer -> > scsi physical (eg. Parallel, SAS, USB) -> > translation (eg. SAT) > > Notice how I showed the block layer, device mapper, and MD on one > line. That's because they really interact a lot and potentially have > multiple layers of DM / MD translations. > > Also, I don't show libata in the above stack. If you want to talk to > a SATA drive, then you'll want to understand how it fits in. > > (If you don't know, libata is NOT a full fledged block driver. It was > shoe horned into the above SCSI stack. That's why it's /dev/sdx now > and not /dev/hda like it was 10 years ago. The /dev/hda (legacy IDE) > block driver stack is still in kernel, but it no longer accepts major > updates. (deprecated? I think that's right.)) > > But all that's the linux kernel structure. > > There are also scsi layers defined in the SCSI specs. If you're going > to work with SCSI you will want to be somewhat familiar with the > specs. t10 is the SCSI standards body. Take a look a this > architectural chart: > > http://www.t10.org/scsi-3.htm > > Note that it is the architecture of the specs, and not necessarily the > architecture of kernel. > > I think libata fits into that architecture just below the SAM level, > so it is a sibling of parallel SCSI, SAS, FC, iSCSI, USB, etc. > > Again, that is not really the optimal way for libata to work, but it > prevents having to write unique upper layers for libata. libata has > been around as long as the 2.6 kernel at least (it was in 2.4 too, but > was less important). > > It has been a goal of the libata developers to become a full fledged > block driver for all these years, but I don't think they've made much > progress on that. I suspect it's too much work for little gain. > > == > Now with that basic info in place, back to your original desire: > > "I want to write module that implements SCSI-disk logic, keeping its > data on block device." > > To me, that sounds like libata. Libata is a kernel module that sits > under the SCSI upper/mid layers and translates scsi commands to ATA > commands and then sends those commands to a ATA controller (both SATA > and PATA controllers are supported). > > But, it sounds like you want to be able to issue your writes as SCSI > requests? Is that right? If so, that almost sounds like iSCSI with a > built-in loopback network. > > Maybe you can elaborate using more specific terminology? > > FYI: If I were you, I would want to create a new DM (device mapper) > module that could tie in directly at the block layer of the linux > kernel. It would be able to accept block i/o commands from the block > layer, manipulate those commands, then re-issue them to the block > layer so they could be pushed down into the actual block stack (ie. > SCSI). > > All the infrastructure is already in place to do that. > > Thus, while you say you want to write a SCSI module, I think a Device > Mapper module makes far more sense to do what you want. And you're > not forcing your concept on to the kernel. Instead your taking the > kernel's design and leveraging it. > > Hope that helps > Greg

1 0

Regarding high mem
by Kshemendra KP Oct. 17, 2012

Oct. 17, 2012

On x86 kernel is normally split into 3GB (user) : 1 GB (Kernel) spaces. Kernel can only directly manipulate 1 GB (around 889 MB) from the PAGE_OFFSET (0xC0000000). The user space memofy below PAGE_OFFSET kernel can't directly access, it considers this memory as high memory. Kernel needs to kmap()/kmap_atomic() map user page and access that region. If the memory is above 4 GB with page extension, it is clear that kernel can't access it as kernel uses "void *" and/or "unsigned long" to hold the address. But it is not clear for me why kernel's can't directly access memory below PAGE_OFFSET ( 0-3GB) directly. Regards Kshemendra

4 5

quick online tutorial on system calls
by Robert P. J. Day Oct. 17, 2012

Oct. 17, 2012

another in an ongoing series of things i'm just throwing together, mostly to document stuff for my own benefit to use later in courseware when i figure out what to do with it. here's a summary i wrote this morning on system calls, which turned out to be longer than i'd planned (it just kind of got away from me): http://www.crashcourse.ca/wiki/index.php/System_calls but a lot of it is just cutting and pasting kernel source for explanatory purposes. feedback welcome. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2