[SOLVED] usb-storage + usb card-reader = klogd spamming logs
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
usb-storage + usb card-reader = klogd spamming logs
This is a stock install of Slack64-current, except for a 2.6.30 kernel.
Anyone else have/had the klogd daemon cause the HDD light to stay on? I don't think there's any actual writing going on, and the light stays on right from when klogd starts (init script) until forever, unless I kill klogd.
Sasha
UPDATE: I changed the thread title due to new information in posts further down.
Last edited by GrapefruiTgirl; 07-22-2009 at 08:27 PM.
Reason: Change thread title
Yep - I've had the same issue, but I don't yet know why. I could not even tell you that klogd is the problem - only that the hdd is spinning up and down constantly for no apparent reason. I'll have to check the next time it happens.
It's been a while since I compiled 2.6.30 kernel but I seem to remember there were some different options regarding ide/sata/scsi or maybe ahci/apci. I can't point you to any specifics but you might want to review those choices. Does dmesg, lspci, lsmod tell you anything useful?
Maybe try to create initrd.gz and boot up 2.6.29.6 (slackware generic) and see which modules load. Look also at the i2c. Hope these suggestions are useful and not too basic.
the source of the problem appears to lie in/about the kernel's usb-storage driver, which is spamming the kernel.log once per second with crap produced seemingly by non-stop querying of my usb-connected card reader.
Example:
Code:
---snip---
Jul 22 22:12:38 reactor kernel: usb-storage: *** thread sleeping.
Jul 22 22:12:38 reactor kernel: usb-storage: queuecommand called
Jul 22 22:12:38 reactor kernel: usb-storage: *** thread awakened.
Jul 22 22:12:38 reactor kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jul 22 22:12:38 reactor kernel: usb-storage: 00 00 00 00 00 00
Jul 22 22:12:38 reactor kernel: usb-storage: Bulk Command S 0x43425355 T 0x1867 L 0 F 0 Trg 0 LUN 2 CL 6
Jul 22 22:12:38 reactor kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jul 22 22:12:38 reactor kernel: usb-storage: Status code 0; transferred 31/31
Jul 22 22:12:38 reactor kernel: usb-storage: -- transfer complete
Jul 22 22:12:38 reactor kernel: usb-storage: Bulk command transfer result=0
Jul 22 22:12:38 reactor kernel: usb-storage: Attempting to get CSW...
Jul 22 22:12:38 reactor kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jul 22 22:12:39 reactor kernel: usb-storage: Status code 0; transferred 13/13
Jul 22 22:12:39 reactor kernel: usb-storage: -- transfer complete
Jul 22 22:12:39 reactor kernel: usb-storage: Bulk status result = 0
Jul 22 22:12:39 reactor kernel: usb-storage: Bulk Status S 0x53425355 T 0x1867 R 0 Stat 0x1
Jul 22 22:12:39 reactor kernel: usb-storage: -- transport indicates command failure
Jul 22 22:12:39 reactor kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jul 22 22:12:39 reactor kernel: usb-storage: Bulk Command S 0x43425355 T 0x1868 L 18 F 128 Trg 0 LUN 2 CL 6
Jul 22 22:12:39 reactor kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jul 22 22:12:39 reactor kernel: usb-storage: Status code 0; transferred 31/31
Jul 22 22:12:39 reactor kernel: usb-storage: -- transfer complete
Jul 22 22:12:39 reactor kernel: usb-storage: Bulk command transfer result=0
Jul 22 22:12:39 reactor kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries
Jul 22 22:12:39 reactor kernel: usb-storage: Status code 0; transferred 18/18
Jul 22 22:12:39 reactor kernel: usb-storage: -- transfer complete
Jul 22 22:12:39 reactor kernel: usb-storage: Bulk data transfer result 0x0
Jul 22 22:12:39 reactor kernel: usb-storage: Attempting to get CSW...
Jul 22 22:12:39 reactor kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jul 22 22:12:40 reactor kernel: usb-storage: Status code 0; transferred 13/13
Jul 22 22:12:40 reactor kernel: usb-storage: -- transfer corred 31/31
Jul 22 22:12:40 reactor kernel: usb-storage: -- transfer complete
Jul 22 22:12:40 reactor kernel: usb-storage: Bulk command transfer result=0
Jul 22 22:12:40 reactor kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 18 bytes, 1 entries
Jul 22 22:12:40 reactor kernel: usb-storage: Status code 0; transferred 18/18
Jul 22 22:12:40 reactor kernel: usb-storage: -- transfer complete
Jul 22 22:12:40 reactor kernel: usb-storage: Bulk data transfer result 0x0
Jul 22 22:12:40 reactor kernel: usb-storage: Attempting to get CSW...
Jul 22 22:12:40 reactor kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jul 22 22:12:40 reactor kernel: usb-storage: Status code 0; transferred 13/13
Jul 22 22:12:40 reactor kernel: usb-storage: -- transfer complete
Jul 22 22:12:40 reactor kernel: usb-storage: Bulk status result = 0
Jul 22 22:12:40 reactor kernel: usb-storage: Bulk Status S 0x53425355 T 0x1894 R 0 Stat 0x0
Jul 22 22:12:40 reactor kernel: usb-storage: -- Result from auto-sense is 0
Jul 22 22:12:40 reactor kernel: usb-storage: -- code: 0xf0, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jul 22 22:12:40 reactor kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jul 22 22:12:40 reactor kernel: usb-storage: scsi cmd done, result=0x2
Jul 22 22:12:40 reactor kernel: usb-storage: *** thread sleeping.
Jul 22 22:12:41 reactor kernel: usb-storage: queuecommand called
Jul 22 22:12:41 reactor kernel: usb-storage: *** thread awakened.
Jul 22 22:12:41 reactor kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
---snip---
I watched a tail -f /var/log/kernel for a few moments; this goes on forever, non-stop.
Note to self: look into this 'queuecommand' thing.
Any input appreciated, but meanwhile I'll be revisiting the kernel config just to be sure it isn't something I've put in there (don't think to -- I use basically the same kernel config on my 32bit Slack -- but who knows, there are *some* differences.)
Oh, and the card reader, is not being used -- it's empty all this time.
Moved: This thread is more suitable in the Linux Kernel forum and has been moved on your request to help your thread/question get the exposure it deserves.
I'll be revisiting the kernel config just to be sure it isn't something I've put in there (don't think to -- I use basically the same kernel config on my 32bit Slack -- but who knows, there are *some* differences.) Oh, and the card reader, is not being used -- it's empty all this time.
Check your kernel config for CONFIG_USB_DEBUG=y or CONFIG_USB_STORAGE_DEBUG=y ?
I have had a busy weekend so have not yet gotten to examine whether or not I have selected excessive debugging of the usb-storage system. It is on my short list of things to do. (Thanks unspawn)
@ r0b0 - thanks for that reminder - I am aware of the option to sync/not sync, and actually I usually have it set to sync right away, thereby minimizing the losses during a power outage or other rapid exit and indeed, in this case you are completely right: it won't fix the issue, but at least the drive wouldn't be going all the time. Interestingly though, *IF* I do have some excessive debugging going on, I would perhaps not have known it (or remembered I had set it) if I had not been syncing the log right away (if indeed I am). As this is a relatively stock install, I'd have thought that the logging would have already been set to 'not sync'
Will let you know what I find when I get the time to revisit my kernel config (kinda waiting for the next kernel patch )
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
and indeed, in this case you are completely right: it won't fix the issue, but at least the drive wouldn't be going all the time. Interestingly though, *IF* I do have some excessive debugging going on, I would perhaps not have known it (or remembered I had set it) if I had not been syncing the log right away (if indeed I am). As this is a relatively stock install, I'd have thought that the logging would have already been set to 'not sync'
)
