* Re: Change proposal for consistent "skb->pkt_type" after re-injection
From: Henrik Nordstrom @ 2004-06-30 10:43 UTC (permalink / raw)
To: Christian Riechmann; +Cc: netfilter-devel, bus
In-Reply-To: <20040629094835.GA3141@rie.rie.priv>
On Tue, 29 Jun 2004, Christian Riechmann wrote:
> Apparantly the skb->pkt_type is set very early within one of the
> kernel IP routines passed by the broadcasted or multicasted packet
> BEFORE iptables gave it to the user space program and the
> modified (now TCP packet with a host address) packet is re-injected
> into the kernel processing.
Correct, and ip_queue does not have an option to let the userspace return
a new packet type. But there is other iptables modules allowing you to do
this kind of thing either before or after the packet is sent to ip_queue.
> One - bad - solution for this problem could be to delete the above
> test within the TCP functions, but this would produce difficulties,
> if some people (hacker?) would send IP/TCP packets with multicast or
> broadcast addresses.
Deleting these tests from TCP would cause serious problems. These tests
exists there for good reasons.
> As a better solution I would propose, that the processing initiated
> by ipq_set_verdict should update the packet type (skb->pkt_type)
> according to the re-injected packet.
How would it know? The packet type is dictated by how the packet arrived
to the box, not the IP content.
But honestly I would recommend reinjecting the packets via a TUN device.
This way a whole can of problems is avioded with very little complexity. I
would even get the encapsulated packets out of the kernel via the same TUN
device and just use iptables to have them routed there but that it me.
Regards
Henrik
^ permalink raw reply
* [BUG FIX] fork_init() OOM bug on big highmem machine
From: Coywolf Qi Hunt @ 2004-06-30 10:43 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: linux-kernel, akpm, rmk+lkml
In-Reply-To: <40E03F71.8010902@greatcn.org>
Coywolf Qi Hunt wrote:
> Hello all,
>
> On machine with 16G(or 8G if 4k stacks) or more memory, high
> max_threads could let system run out of low memory.
> This patch decides max_threads by the amount of low memory instead of
> the total physical memory.
> Systems without high memory would not be affected.
This patch should be ok by taking ``max_low_pfn - min_low_pfn'' and also
becomes more accurate.
On those systems where physical RAM doesn't start at address 0, we
should initialize min_low_pfn.
Anyway min_low_pfn is already defined on all platforms. The bug of
forgetting min_low_pfn initialization
on those platforms isn't more severe than this bug.
====================================================================
diff -rup linux-2.6.7/init/main.c linux-2.6.7-cy/init/main.c
--- linux-2.6.7/init/main.c Wed Jun 9 00:07:40 2004
+++ linux-2.6.7-cy/init/main.c Thu Jun 17 04:55:54 2004
@@ -467,7 +467,7 @@ asmlinkage void __init start_kernel(void
if (efi_enabled)
efi_enter_virtual_mode();
#endif
- fork_init(num_physpages);
+ fork_init(max_low_pfn - min_low_pfn);
proc_caches_init();
buffer_init();
unnamed_dev_init();
diff -rup linux-2.6.7/kernel/fork.c linux-2.6.7-cy/kernel/fork.c
--- linux-2.6.7/kernel/fork.c Wed Jun 9 00:07:40 2004
+++ linux-2.6.7-cy/kernel/fork.c Mon Jun 28 22:55:50 2004
@@ -224,8 +224,8 @@ void __init fork_init(unsigned long memp
/*
* The default maximum number of threads is set to a safe
- * value: the thread structures can take up at most half
- * of memory.
+ * value: the thread structures can take up at most 1/8
+ * of low memory.
*/
max_threads = mempages / (THREAD_SIZE/PAGE_SIZE) / 8;
/*
--
Coywolf Qi Hunt
Admin of http://GreatCN.org and http://LoveCN.org
^ permalink raw reply
* Re: Tree issues, fsck output
From: mjt @ 2004-06-30 10:43 UTC (permalink / raw)
To: Vitaly Fertman; +Cc: reiserfs-list, sikkh
In-Reply-To: <20040630094225.GN4990@nysv.org>
On Wed, Jun 30, 2004 at 12:42:25PM +0300, Markus Törnqvist wrote:
>
>I'm taking a debugfs.reiser4 -P /dev/hda1 now.
>Then I will run additional stuff, but it still seems like the FS is ok....
Yeah, I have the metadata dump now, and I will send it to you if you
feel you need it, but the additional fsck reported clean results.
I will proceed to compiling a new kernel, with an older auto-snap.
Thanks!
--
mjt
^ permalink raw reply
* Re: config.in fix
From: Keir Fraser @ 2004-06-30 10:42 UTC (permalink / raw)
To: Jody Belka; +Cc: xen-devel
In-Reply-To: <20040630103002.GA9527@faith.gentoo.org>
> I'm doing really badly here at sending in patches until someone
> else mentions the problem. sorry about that. anyway, included is
> a patch for config.in to fix the problem with the scsi menu.
Thanks. I'll push the change once bkbits.net returns to life.
-- Keir
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
^ permalink raw reply
* Re: apache rule to make it write in directory
From: Pascal Hahn @ 2004-06-30 10:41 UTC (permalink / raw)
To: SELinux
Russell Coker wrote:
> On Fri, 25 Jun 2004 16:35, Pascal Hahn <p.hahn@laufwerka.de> wrote:
>
>
>> heres my output i get from avc messages:
>>
>> /Jun 16 13:39:36 lboxx avc: denied { write } for pid=3161
>> exe=/usr/sbin/apache2 path=/var/www/localhost/lwa/infos/auth.tmp
>> dev=hdc6 ino=96389 scontext=system_u:system_r:httpd_t
>> tcontext=system_u:object_r:httpd_sys_content_t tclass=file
>>
>
>
> Try the following:
> file_type_auto_trans(httpd_t, httpd_sys_content_t,
> httpd_sys_script_rw_t, file)
>
>
>
Hi there,
I inserted the rule but get the following error although:
Jun 30 12:45:30 lboxx avc: denied { write } for pid=3190
exe=/usr/sbin/apache2 name=ip.tmp dev=hdc6 ino=96390
scontext=system_u:system_r:httpd_t
tcontext=system_u:object_r:httpd_sys_content_t tclass=file
Jun 30 12:45:30 lboxx avc: denied { setattr } for pid=3190
exe=/usr/sbin/apache2 name=ip.tmp dev=hdc6 ino=96390
scontext=system_u:system_r:httpd_t
tcontext=system_u:object_r:httpd_sys_content_t tclass=file
I just need file creation, chmodding, reading and writing on this folder
and all its subolders.
Thanks,
Pascal Hahn
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: /proc/net/ip_conntrack
From: Henrik Nordstrom @ 2004-06-30 10:38 UTC (permalink / raw)
To: Daniel Corrêa de Azevedo; +Cc: netfilter-devel
In-Reply-To: <20040629203549.M8283@linkexpress.com.br>
On Tue, 29 Jun 2004, Daniel Corrêa de Azevedo wrote:
> I wonder if any one could help me with figuring out a way to write to the
> proc file "/proc/net/ip_conntrack".
You can't. It is not a file, it is a window into the connection tracking
function of the kernel showing you what is going on "right now". This
window is bulletproof and you cant take things out or put things in via
this window, only look at how they look.
> What I need is to replicate this file
> from one computer to another.
See discussions on conntrack replication/syncronisation. There is an
ongoing (not yet finished) project implementing this kind of function.
There is a whole lot more involved than just "copying".
Regards
Henrik
^ permalink raw reply
* Re: dnat problems
From: Antony Stone @ 2004-06-30 10:34 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20040630100418.6D70F5B783@gollum.dreamhost.com>
On Wednesday 30 June 2004 11:04 am, Per Frödeberg wrote:
> i´ve got a firewall with the following configuration:
>
> internet: eth0, 1.2.3.4
> lan: eth1, 192.168.0.1
>
> on my lan there are several computers attached that are not supposed to use
> the firewall for internet-access.
> they are routed to different internal networks, so they do not (and should
> not) know about ip 1.2.3.4
>
> what i want to do is to forward traffic from my public internetaddress (on
> eth0) to a specific machine on the lan,
> lets say 192.168.0.2. normally i just DNAT it like:
> "iptables -t nat -A PREROUTING -p TCP -i eth0 --dport [port] -j DNAT
> --to-destination 192.168.0.2:[port]"
>
> but now since 192.168.0.2 does not know about 1.2.3.4 packets will not find
> the way back. so my question is, how
> do i do that? in some way i want to forward traffic through eth0 -> eth1 ->
> 192.168.0.2 on a specific port
> and back the same way.
Add a default route on 192.168.0.2 via gateway 192.168.0.1, and restrict the
traffic through the firewall so that it accepts the DNATted packets *to*
192.168.0.2 and allows replies, but will not allow new connections *from*
192.168.0.2.
eg:
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -d 192.168.0.2 -p tcp --dport xxx -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport xxx -j DNAT --to
192.168.0.2
Regards,
Antony.
--
If the human brain were so simple that we could understand it,
we'd be so simple that we couldn't.
Please reply to the list;
please don't CC me.
^ permalink raw reply
* Re: Preemption of the OS system call due to expiration of the time-sl ice for: a) SCHED_NORMAL (aka SCHED_OTHER) b) SCHED_RR
From: Ingo Molnar @ 2004-06-30 10:35 UTC (permalink / raw)
To: Povolotsky, Alexander
Cc: 'linux-kernel@vger.kernel.org',
'andrebalsa@altern.org', 'Richard E. Gooch',
'rml@tech9.net', 'akpm@osdl.org',
'Con Kolivas'
In-Reply-To: <313680C9A886D511A06000204840E1CF08F42FAE@whq-msgusr-02.pit.comms.marconi.com>
* Povolotsky, Alexander <Alexander.Povolotsky@marconi.com> wrote:
> Con - thanks for your kind answers !
>
> Preemption (due to the expiration of the time-slice) of the process,
> while it executes OS system call, - by another process (of equal or
> higher priority) when running under following scheduling policies:
>
> a) SCHED_NORMAL (aka SCHED_OTHER)
> b) SCHED_RR
>
> Is it possible in Linux 2.6 ? Linux 2.4 ?
this is possible in 2.6 in CONFIG_PREEMPT is on. There's no guaranteed
latency due to non-preemptability of interrupts and critical sections
but the practical latencies are well below 1 msec. A bad driver or some
rare codepath we missed could introduce long latencies - but these are
usually easy to fix.
The core 2.6 kernel itself is very latency-friendly, in a very
controlled hardware environment utilizing well-reviewed userspace code,
a slimmed down kernel, no block IO and no high-rate interrupt source
(other than the interrupt source the application cares about) i'd say
it's quite close to hard-RT: all kernel functions have bound latency,
'all' you have to take care of are latencies introduced by hardware
interrupts.
in 2.4 kernel-preemption is done too in lots of places conditionally
(cooperatively), by kernel code. Unlike 2.6 there's no forced preemption
of kernel code.
Ingo
^ permalink raw reply
* pci on ppc
From: Marco Schramel @ 2004-06-30 10:33 UTC (permalink / raw)
To: PPC_LINUX
Hi,
my kernel does not boot with the kernel option "CONFIG_PCI". (System MPC8270 (PQ2FADS), 2.4.25 denx kernel, eldk 3.0).
Without the pci option it can boot without problems.
UBoot supports my pci. It shows the bridge and the cards i put in.
What i have to attend in the kernel for the 82xx?
Where the function "m8260_setup_arch()" (m8260_setup.c) is called ?? With the pci option the kernel does not call this function.
Thanks a lot
Marco
---------
Marco Schramel
R&D
Bartec GmbH
Schulstr. 30
94239 Gotteszell, Germany
www.bartec.de
Marco.Schramel@go.bartec.de
Phone: +49 (0)9929/301332
Fax: +49 (0)9929/301112
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* config.in fix
From: Jody Belka @ 2004-06-30 10:30 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
I'm doing really badly here at sending in patches until someone
else mentions the problem. sorry about that. anyway, included is
a patch for config.in to fix the problem with the scsi menu.
--
Jody Belka
knew (at) pimb (dot) org
[-- Attachment #2: config.in.patch --]
[-- Type: text/plain, Size: 1149 bytes --]
--- 1019/linux-2.4.26-xen-sparse/arch/xen/config.in Fri Jun 25 15:03:01 2004
+++ 1009/linux-2.4.26-xen-sparse/arch/xen/config.in Wed Jun 23 23:33:08 2004
@@ -173,17 +173,21 @@
define_bool CONFIG_BLK_DEV_HD n
fi
endmenu
+else
+ define_bool CONFIG_NETDEVICES y
+fi
- mainmenu_option next_comment
- comment 'SCSI support'
+mainmenu_option next_comment
+comment 'SCSI support'
- tristate 'SCSI support' CONFIG_SCSI
+tristate 'SCSI support' CONFIG_SCSI
- if [ "$CONFIG_SCSI" != "n" ]; then
- source drivers/scsi/Config.in
- fi
- endmenu
+if [ "$CONFIG_SCSI" != "n" ]; then
+ source drivers/scsi/Config.in
+fi
+endmenu
+if [ "$CONFIG_XEN_PHYSDEV_ACCESS" = "y" ]; then
source drivers/message/fusion/Config.in
source drivers/ieee1394/Config.in
@@ -234,18 +238,6 @@
#
source drivers/input/Config.in
else
- define_bool CONFIG_NETDEVICES y
-
- mainmenu_option next_comment
- comment 'SCSI support'
-
- tristate 'SCSI support' CONFIG_SCSI
-
- if [ "$CONFIG_SCSI" != "n" ]; then
- source drivers/scsi/Config.in
- fi
- endmenu
-
#
# Block device driver configuration
#
^ permalink raw reply
* TCP RST problem
From: christophe.varoqui @ 2004-06-30 10:27 UTC (permalink / raw)
To: netdev
Hello,
I got a strange problem :
A weblogic app reply to a POST request by a 302 redirect. As soon as the "302"
fragments are sent, the server emits a TCP RST. The client is then unable to do
its consecutive GET ordered by the redirect : it shows a "404".
Facts :
This behaviour is reproductible on vanilla lk 2.4.26, latest redhat EL kernel
and various Linux distros.
This behaviour is not reproductible with Windows NT/XP weblogic servers and
Tru64 servers.
This behaviour shows only when using Internet Explorer at the client side :
relyably with IE5, IE5.1, IE5.5 and less relyably with IE6. Mozilla browsers
don't ever trigger the RST. Latest IE Service Packs seem to solve the problem
too, but I don't have the leasure to force the upgrade on a *really* big client
park (+4000 PC).
Masking the Weblogic server behind a proxy or a LVS load-balancer mostly solve
the issue : RST get triggered less than 1 hit out of 50.
Droping the outgoing RST packets on the weblogic server fixes the problem 100%,
but may induce other problems.
Questions :
Does anyone have insights to share about how to solve the problem "cleanly" on
the server side, or simply an explanation of the phenomenon ?
What perturbations can I expect from filtering the outgoing RST on these
servers, given they will take hits from slow WAN clients ?
regards,
cvaroqui
--
^ permalink raw reply
* irq 11: nobody cared? (usb?)
From: Meelis Roos @ 2004-06-30 10:25 UTC (permalink / raw)
To: Linux Kernel list
Just got this from 2.6.7 + BK as of 20040629.
irq 11: nobody cared!
Stack pointer is garbage, not printing trace
handlers:
[<e09960b0>] (usb_hcd_irq+0x0/0x60 [usbcore])
[<c02684b0>] (e100_intr+0x0/0x110)
Disabling IRQ #11
First boot of the same kernel ran fine for a day, then USB mouse hung
(replug cured it). Then on next reboot it disabled irq 11 and e100 and
one usb port along with it (mouse is in another usb port and worked
fine). I rebooted it again and now it's working fine again.
I looked into the logs of the first accident and it's mostly the same (a
couple of X restarts to check whether it revives the mouse):
irq 11: nobody cared!
Stack pointer is garbage, not printing tracehandlers:
[__crc_xprt_create_proto+526825/4343765] (usb_hcd_irq+0x0/0x60 [usbcore])
[e100_intr+0/272] (e100_intr+0x0/0x110)
Disabling IRQ #11
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:03:00.0 into 4x mode
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:03:00.0 into 4x mode
usb 1-2: USB disconnect, address 2
usb 2-2: new low speed USB device using address 2
input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1f.4-2
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: apache rule to make it write in directory
From: Pascal Hahn @ 2004-06-30 10:24 UTC (permalink / raw)
To: SELinux
Russell Coker wrote:
> On Fri, 25 Jun 2004 16:35, Pascal Hahn <p.hahn@laufwerka.de> wrote:
>
>
>> heres my output i get from avc messages:
>>
>> /Jun 16 13:39:36 lboxx avc: denied { write } for pid=3161
>> exe=/usr/sbin/apache2 path=/var/www/localhost/lwa/infos/auth.tmp
>> dev=hdc6 ino=96389 scontext=system_u:system_r:httpd_t
>> tcontext=system_u:object_r:httpd_sys_content_t tclass=file
>>
>
>
> Try the following:
> file_type_auto_trans(httpd_t, httpd_sys_content_t,
> httpd_sys_script_rw_t, file)
>
>
>
Hi there,
I inserted the rule but get the following error although:
Jun 30 12:45:30 lboxx avc: denied { write } for pid=3190
exe=/usr/sbin/apache2 name=ip.tmp dev=hdc6 ino=96390
scontext=system_u:system_r:httpd_t
tcontext=system_u:object_r:httpd_sys_content_t tclass=file
Jun 30 12:45:30 lboxx avc: denied { setattr } for pid=3190
exe=/usr/sbin/apache2 name=ip.tmp dev=hdc6 ino=96390
scontext=system_u:system_r:httpd_t
tcontext=system_u:object_r:httpd_sys_content_t tclass=file
I just need file creation, chmodding, reading and writing on this folder
and all its subolders.
Thanks,
Pascal Hahn
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)
From: David Woodhouse @ 2004-06-30 10:23 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linux-emb
In-Reply-To: <40E1E94B.9060204@mvista.com>
On Tue, 2004-06-29 at 15:12 -0700, Mark A. Greer wrote:
> You mean in the arch/ppc/boot/simple code, right? You may need to do
> something like what is in arch/ppc/boot/simple/misc-ev64260.S to move
> the dev windows for your uart (if you're using an external uart). I
> successfully change the internal registers base addr on the ev64260.
No, the UART is fine (except if we play with its windows as discussed
later). It's the GT64360 which isn't where it should be. I'm told that
sometimes they don't accept being moved more than once -- and I'm happy
enough with it at 0xEFF00000 where it starts off anyway; it's just that
I inherited the default setting of 0xF1000000 for
CONFIG_GT64x60_NEW_BASE.
> >Automatic detection of the chip type still isn't working, because it
> >tries to work it out from its own PCI ident, but the MV64360 doesn't
> >seem to appear on the PCI bus -- there _is_ no device 0.
>
> Strange...according to the manual, you figure it out the same way no
> matter what bridge it is and it works for the 260 on my ev64260. Are
> you sure your setup_info is correct?
Well I can see all the other devices on the PCI bus, and when I boot the
2.4 kernel it doesn't seem to have a device 0 either. So yes, fairly
sure. I'm staring at the docs trying to find out if there's a bit in a
register somewhere which makes the chip hide from its own PCI buses.
> >The memory windows aren't right -- you have base_bits == 20 but those 20
> >bits actually hold bits 16-35 of the address. That's not a typo, so
> >setting base_bits to 16 seems to be the correct thing to do unless we're
> >going to handle 'extended address mode'.
>
> Yes, 20 bits in the reg starting at bit 0 (LSB) correspond to bits
> 35:16 of the window. As long as the 'base' you pass into
> mv64x60_set_32bit_window() is correct, it should work I think (or be
> close)--but, of course, I haven't tested it yet :)
>
> Would you turn on DEBUG and send me the dump (along with your
> setup_info) or give me a reg dump from you bdi (or whatever) or a dump
> of what's in __log_buf.
It used to say this:
set 32bit window: 4, base: 0xe0010000, size: 0x10000, other: 0x0
shift right val: 0xe0010000, num_bits: 20 == 0xe0010
would change base_reg from 0000e001 to 000e0010
... and then nothing else, because it had just broken the UART.
Now with base_bits == 16 it says this:
set 32bit window: 4, base: 0xe0010000, size: 0x10000, other: 0x0
shift right val: 0xe0010000, num_bits: 16 == 0xe001
would change base_reg from 0000e001 to 0000e001
> >Also we disable all the memory windows for I/O and only re-enable them
> >later. That breaks if we actually try to access any of the I/O in the
> >meantime -- which we do if we enable MV64x60 debugging, because it keeps
> >calling printk() :)
>
> Well, I've been burned in the past by "dangling windows" so I was
> trying to be as safe as possible. BTW, prink() isn't atually the
> issue since console_init() isn't called for some time after
> setup_arch().
It's definitely printk. I don't have a hardware debugger so I don't like
waiting till console_init() - I register a console in platform_init().
> Okay, I think we're in agreement. Just to make sure, the solution is
> to add an array to setup_info that contains the dev bus window ranges
> and have the core code set those up when its setting up the PCI
> windows. Agree?
Possibly. Although it seems like overkill -- we could live with just a
bitmap of those windows we want the init to leave as they were -- we
don't need it to set _everything_ up for us; just not destroy the
windows we're actually using right now.
> >I could register my console later, I suppose, and live without printk
> >until after setup_arch()... but that sucks.
>
> You must have some other issue. printk() isn't going to actually try
> to access the uart/mpsc until console_init() is called in
> start_kernel().
Console_init() is just an earlier round of initcalls than the normal
ones, and there's absolutely no need to wait that long. For debugging
early boot crashes, add something like this to gen550_dbg.c and call
gen550_console_register() in platform_init()...
#include <linux/console.h>
static void gen550_console_write(struct console *con, const char *s, unsigned n) {
unsigned int progress_debugport;
int i;
progress_debugport = serial_init(1, NULL);
for(i=0; i<n; i++) {
if (s[i] == 10)
serial_putc(progress_debugport, 13);
serial_putc(progress_debugport, s[i]);
}
}
struct console gen550_console = {
.name = "gen550",
.write = gen550_console_write,
.flags = CON_PRINTBUFFER,
.index = -1
};
void gen550_console_register(void)
{
register_console(&gen550_console);
}
--
dwmw2
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: i810_audio MMIO patch
From: Herbert Xu @ 2004-06-30 10:22 UTC (permalink / raw)
To: John Linville; +Cc: linux-kernel, jgarzik
In-Reply-To: <200406292031.i5TKVgbX023358@savage.devel.redhat.com>
John Linville <linville@redhat.com> wrote:
>
> @@ -452,12 +452,34 @@ struct i810_card {
> /* extract register offset from codec struct */
> #define IO_REG_OFF(codec) (((struct i810_card *) codec->private_data)->ac97_id_map[codec->id])
>
> -#define GET_CIV(port) MODULOP2(inb((port) + OFF_CIV), SG_LEN)
> -#define GET_LVI(port) MODULOP2(inb((port) + OFF_LVI), SG_LEN)
> +#define I810_IOREAD(size, type, card, off) \
> +({ \
> + type val; \
> + if (card->use_mmio) val=read##size(card->iobase_mmio+off); \
> + else val=in##size(card->iobase+off); \
> + val; \
> +})
Please indent I810_IOWRITE and this like normal code.
> @@ -716,9 +738,9 @@ static inline unsigned i810_get_dma_addr
How about making card a local variable where it's used over and over again
as in this function?
> @@ -2798,7 +2819,8 @@ static int i810_ac97_power_up_bus(struct
> * before we start doing DMA stuff
> */
> /* see i810_ac97_init for the next 7 lines (jsaw) */
> - inw(card->ac97base);
> + if (card->use_mmio) readw(card->ac97base_mmio);
> + else inw(card->ac97base);
Please indent these ones too.
> @@ -3141,6 +3162,11 @@ static int __devinit i810_probe(struct p
> }
> }
>
> + if (!(card->use_mmio) && !(card->iobase)) {
> + printk(KERN_ERR "i810_audio: No I/O resources available.\n");
> + goto out_mem;
> + }
> +
To be safe we should check card->ac97base as well.
Otherwise the patch looks good.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* problems with CF card reader, kernel 2.6.7
From: Sean Champ @ 2004-06-30 10:16 UTC (permalink / raw)
To: linux-kernel
Hello,
I'm having some troubles with a USB-based 6-in-1 "smart media" reader,
in kernel 2.6.7.
While using kernel 2.6.6, a couple of days ago, I was able to mount a
CF card in the reader, successfully, and to move all of the files off
of it. Then, I unmounted the chip, removed it from the reader, and
tried to mount another. That, it seems, is when the problems started.
I've only been able to mount a card in the reader once, in the past
few days (and that was done with an install of MSWindows'98, which
seems to be having its own problems about things, such that it's about
as useless as ever.)
I've hoped that I might be able to help, at least, in offering som
debug data, about whatever might be wrong with the software side of
things.
So, I compiled the usb-storage module, in my 2.6.7 kernel, with the
extra debugging flag turned on. I started a little debugging session,
then -- using 'logger' to record notes to the syslog, before each
action with the reader (e.g.: plugging the reader in; plugging the
card into the reader; unplugging each). I've included the syslog
output, below. My own notes were added by user "sc"
If I would need to provide any more information (e.g.: boot-time
'dmesg' output; other shell-command output; names of motherbord/usb
components, etc), so that this might make more sense, then I'll be
more than glad to send it along.
Thank you!
--
Sean Champ
Here's what I can think to include of syslog messages about the
hardware
(I'd be glad to include more hardware-identification info, if it would
be of help. I'm not terribly sure of all of what's in the box,
really, but Gateway should still have a record of it.)
Jun 28 21:17:02 tokamak kernel: ACPI disabled because your bios is from 1995 and too old
{...}
Jun 28 21:17:02 tokamak kernel: CPU: After generic identify, caps: 008021bf 808029bf 00000000 00000000
Jun 28 21:17:02 tokamak kernel: CPU: After vendor identify, caps: 008021bf 808029bf 00000000 00000000
Jun 28 21:17:02 tokamak kernel: CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
Jun 28 21:17:02 tokamak kernel: CPU: After all inits, caps: 008021bf 808029bf 00000000 00000002
Jun 28 21:17:02 tokamak kernel: CPU: AMD-K6(tm) 3D processor stepping 0c
{...}
Jun 28 21:17:02 tokamak kernel: PCI: Using ALI IRQ Router
Jun 28 21:17:02 tokamak kernel: PCI: Using IRQ router ALI [10b9/1533] at 0000:00:07.0
Jun 28 21:17:02 tokamak kernel: PCI: IRQ 0 for device 0000:00:0e.0 doesn't match PIRQ mask - try pci=usepirqmask
{...}
Jun 28 21:17:02 tokamak kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Jun 28 21:17:02 tokamak kernel: ALI15X3: IDE controller at PCI slot 0000:00:0e.0
Jun 28 21:17:02 tokamak kernel: PCI: Hardcoded IRQ 14 for device 0000:00:0e.0
Jun 28 21:17:02 tokamak kernel: ALI15X3: chipset revision 193
Jun 28 21:17:02 tokamak kernel: ALI15X3: not 100%% native mode: will probe irqs later
Here's the syslog output from the debugging session, for when I did
the following:
1) attached the card-reader to the USB root hub
2) put a usable CF card in the reader
3) tried to mount partition 1 from the CF card
4) failed
5) removed the CF card
6) unplugged the reader
Jun 29 23:17:59 tokamak sc: MARK
Jun 29 23:18:08 tokamak sc: attaching IWill 6-in-1 card reader
Jun 29 23:18:14 tokamak kernel: hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
Jun 29 23:18:15 tokamak kernel: hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad?
Jun 29 23:18:15 tokamak kernel: usb 1-2: new full speed USB device using address 3
Jun 29 23:18:15 tokamak kernel: usb-storage: USB Mass Storage device detected
Jun 29 23:18:15 tokamak kernel: usb-storage: altsetting is 0, id_index is 92
Jun 29 23:18:15 tokamak kernel: usb-storage: -- associate_dev
Jun 29 23:18:15 tokamak kernel: usb-storage: Transport: Bulk
Jun 29 23:18:15 tokamak kernel: usb-storage: Protocol: Transparent SCSI
Jun 29 23:18:15 tokamak kernel: usb-storage: Endpoints: In: 0xd3fe5994 Out: 0xd3fe59a8 Int: 0x00000000 (Period 0)
Jun 29 23:18:15 tokamak kernel: usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00 len=1
Jun 29 23:18:16 tokamak kernel: usb-storage: GetMaxLUN command result is 1, data is 3
Jun 29 23:18:16 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:16 tokamak kernel: scsi1 : SCSI emulation for USB Mass Storage devices
Jun 29 23:18:16 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:16 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:16 tokamak kernel: usb-storage: Command INQUIRY (6 bytes)
Jun 29 23:18:16 tokamak kernel: usb-storage: 12 00 00 00 24 00
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0xc L 36 F 128 Trg 0 LUN 0 CL 6
Jun 29 23:18:16 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:16 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:16 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:16 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes
Jun 29 23:18:16 tokamak kernel: usb-storage: Status code 0; transferred 36/36
Jun 29 23:18:16 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:16 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:16 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:16 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:16 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0xc R 0 Stat 0x0
Jun 29 23:18:16 tokamak kernel: usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
Jun 29 23:18:16 tokamak kernel: usb-storage: scsi cmd done, result=0x0
Jun 29 23:18:16 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:16 tokamak kernel: Vendor: 6-in-1 Model: CF/MD Rev: 0202
Jun 29 23:18:16 tokamak kernel: Type: Direct-Access ANSI SCSI revision: 02
Jun 29 23:18:16 tokamak kernel: Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
Jun 29 23:18:16 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:16 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:16 tokamak kernel: usb-storage: Command INQUIRY (6 bytes)
Jun 29 23:18:16 tokamak kernel: usb-storage: 12 20 00 00 24 00
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0xd L 36 F 128 Trg 0 LUN 1 CL 6
Jun 29 23:18:16 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:16 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:16 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:16 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes
Jun 29 23:18:16 tokamak kernel: usb-storage: Status code 0; transferred 36/36
Jun 29 23:18:16 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:16 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:16 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:16 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:17 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:17 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:17 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:17 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0xd R 0 Stat 0x0
Jun 29 23:18:17 tokamak kernel: usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
Jun 29 23:18:17 tokamak kernel: usb-storage: scsi cmd done, result=0x0
Jun 29 23:18:17 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:17 tokamak kernel: Vendor: 6-in-1 Model: SM Rev: 0202
Jun 29 23:18:17 tokamak kernel: Type: Direct-Access ANSI SCSI revision: 02
Jun 29 23:18:17 tokamak kernel: Attached scsi generic sg2 at scsi1, channel 0, id 0, lun 1, type 0
Jun 29 23:18:17 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:17 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:17 tokamak kernel: usb-storage: Command INQUIRY (6 bytes)
Jun 29 23:18:17 tokamak kernel: usb-storage: 12 40 00 00 24 00
Jun 29 23:18:17 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0xe L 36 F 128 Trg 0 LUN 2 CL 6
Jun 29 23:18:17 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:17 tokamak scsi.agent[1797]: disk at /devices/pci0000:00/0000:00:02.0/usb1/1-2/1-2:1.0/host1/1:0:0:0
Jun 29 23:18:17 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:17 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:17 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:17 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes
Jun 29 23:18:17 tokamak kernel: usb-storage: Status code 0; transferred 36/36
Jun 29 23:18:17 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:17 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:17 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:17 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:17 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:17 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:17 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:17 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0xe R 0 Stat 0x0
Jun 29 23:18:17 tokamak kernel: usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
Jun 29 23:18:17 tokamak kernel: usb-storage: scsi cmd done, result=0x0
Jun 29 23:18:17 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:17 tokamak kernel: Vendor: 6-in-1 Model: SD/MMC Rev: 0202
Jun 29 23:18:17 tokamak kernel: Type: Direct-Access ANSI SCSI revision: 02
Jun 29 23:18:18 tokamak kernel: Attached scsi generic sg3 at scsi1, channel 0, id 0, lun 2, type 0
Jun 29 23:18:18 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:18 tokamak kernel: usb-storage: Command INQUIRY (6 bytes)
Jun 29 23:18:18 tokamak kernel: usb-storage: 12 60 00 00 24 00
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0xf L 36 F 128 Trg 0 LUN 3 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 36/36
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0xf R 0 Stat 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
Jun 29 23:18:18 tokamak kernel: usb-storage: scsi cmd done, result=0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:18 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:18 tokamak kernel: Vendor: 6-in-1 Model: MS Rev: 0202
Jun 29 23:18:18 tokamak scsi.agent[1815]: disk at /devices/pci0000:00/0000:00:02.0/usb1/1-2/1-2:1.0/host1/1:0:0:1
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:18 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:18 tokamak kernel: usb-storage: 00 00 00 00 00 00
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x10 L 0 F 0 Trg 0 LUN 0 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x10 R 0 Stat 0x1
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:18 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000010 L 18 F 128 Trg 0 LUN 0 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000010 R 0 Stat 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:18 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:18 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:18 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:18 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:18 tokamak kernel: usb-storage: 00 00 00 00 00 00
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x11 L 0 F 0 Trg 0 LUN 0 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x11 R 0 Stat 0x1
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:18 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000011 L 18 F 128 Trg 0 LUN 0 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: Type: Direct-Access ANSI SCSI revision: 02
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:18 tokamak usb.agent[1774]: usb-storage: already loaded
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000011 R 0 Stat 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:18 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:18 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:18 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:18 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:18 tokamak kernel: usb-storage: 00 00 00 00 00 00
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x12 L 0 F 0 Trg 0 LUN 0 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x12 R 0 Stat 0x1
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:18 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000012 L 18 F 128 Trg 0 LUN 0 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000012 R 0 Stat 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:18 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:18 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:18 tokamak kernel: Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
Jun 29 23:18:18 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:18 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:18 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:18 tokamak kernel: usb-storage: 00 20 00 00 00 00
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x13 L 0 F 0 Trg 0 LUN 1 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x13 R 0 Stat 0x1
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:18 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000013 L 18 F 128 Trg 0 LUN 1 CL 6
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:18 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:18 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:18 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:18 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:18 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000013 R 0 Stat 0x0
Jun 29 23:18:19 tokamak scsi.agent[1838]: disk at /devices/pci0000:00/0000:00:02.0/usb1/1-2/1-2:1.0/host1/1:0:0:2
Jun 29 23:18:18 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 20 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x14 L 0 F 0 Trg 0 LUN 1 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x14 R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000014 L 18 F 128 Trg 0 LUN 1 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000014 R 0 Stat 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 20 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x15 L 0 F 0 Trg 0 LUN 1 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x15 R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000015 L 18 F 128 Trg 0 LUN 1 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000015 R 0 Stat 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: Attached scsi removable disk sdb at scsi1, channel 0, id 0, lun 1
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 40 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x16 L 0 F 0 Trg 0 LUN 2 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x16 R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000016 L 18 F 128 Trg 0 LUN 2 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000016 R 0 Stat 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 40 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x17 L 0 F 0 Trg 0 LUN 2 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x17 R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000017 L 18 F 128 Trg 0 LUN 2 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000017 R 0 Stat 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 40 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x18 L 0 F 0 Trg 0 LUN 2 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x18 R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000018 L 18 F 128 Trg 0 LUN 2 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000018 R 0 Stat 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: Attached scsi removable disk sdc at scsi1, channel 0, id 0, lun 2
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 60 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x19 L 0 F 0 Trg 0 LUN 3 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x19 R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000019 L 18 F 128 Trg 0 LUN 3 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000019 R 0 Stat 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 60 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x1a L 0 F 0 Trg 0 LUN 3 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x1a R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x8000001a L 18 F 128 Trg 0 LUN 3 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x8000001a R 0 Stat 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:19 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:19 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:19 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:19 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:19 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:19 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:18:19 tokamak kernel: usb-storage: 00 60 00 00 00 00
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x1b L 0 F 0 Trg 0 LUN 3 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:19 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:19 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x1b R 0 Stat 0x1
Jun 29 23:18:19 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:18:19 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:18:19 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x8000001b L 18 F 128 Trg 0 LUN 3 CL 6
Jun 29 23:18:19 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:18:20 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:18:20 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:20 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:18:20 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:18:20 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:18:20 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:20 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:18:20 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:18:20 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:18:20 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:18:20 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:18:20 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:18:20 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x8000001b R 0 Stat 0x0
Jun 29 23:18:20 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:18:20 tokamak kernel: usb-storage: -- code: 0x70, key: 0x2, ASC: 0x3a, ASCQ: 0x0
Jun 29 23:18:20 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: Attached scsi removable disk sdd at scsi1, channel 0, id 0, lun 3
Jun 29 23:18:20 tokamak kernel: Attached scsi generic sg4 at scsi1, channel 0, id 0, lun 3, type 0
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad LUN (0:4)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad target number (1:0)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad target number (2:0)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad target number (3:0)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad target number (4:0)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad target number (5:0)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad target number (6:0)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:18:20 tokamak kernel: usb-storage: Bad target number (7:0)
Jun 29 23:18:20 tokamak kernel: usb-storage: scsi cmd done, result=0x40000
Jun 29 23:18:20 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:18:20 tokamak kernel: USB Mass Storage device found at 3
Jun 29 23:18:21 tokamak scsi.agent[1883]: disk at /devices/pci0000:00/0000:00:02.0/usb1/1-2/1-2:1.0/host1/1:0:0:3
Jun 29 23:18:32 tokamak sc: done: card reader attached
Jun 29 23:18:39 tokamak sc: plugging cf chip into card reader
Jun 29 23:19:01 tokamak sc: mounting cf chip : sda1
Jun 29 23:19:04 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:19:04 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:19:04 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:19:04 tokamak kernel: usb-storage: 00 00 00 00 00 00
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x24 L 0 F 0 Trg 0 LUN 0 CL 6
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:19:04 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x24 R 0 Stat 0x1
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transport indicates command failure
Jun 29 23:19:04 tokamak kernel: usb-storage: Issuing auto-REQUEST_SENSE
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x80000024 L 18 F 128 Trg 0 LUN 0 CL 6
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 18 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 18/18
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk data transfer result 0x0
Jun 29 23:19:04 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x80000024 R 0 Stat 0x0
Jun 29 23:19:04 tokamak kernel: usb-storage: -- Result from auto-sense is 0
Jun 29 23:19:04 tokamak kernel: usb-storage: -- code: 0x70, key: 0x6, ASC: 0x28, ASCQ: 0x0
Jun 29 23:19:04 tokamak kernel: usb-storage: (Unknown Key): (unknown ASC/ASCQ)
Jun 29 23:19:04 tokamak kernel: usb-storage: scsi cmd done, result=0x2
Jun 29 23:19:04 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:19:04 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:19:04 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:19:04 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:19:04 tokamak kernel: usb-storage: 00 00 00 00 00 00
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x25 L 0 F 0 Trg 0 LUN 0 CL 6
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:19:04 tokamak kernel: usb-storage: Attempting to get CSW...
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 13/13
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk status result = 0
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk Status S 0x53425355 T 0x25 R 0 Stat 0x0
Jun 29 23:19:04 tokamak kernel: usb-storage: scsi cmd done, result=0x0
Jun 29 23:19:04 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:19:04 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:19:04 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:19:04 tokamak kernel: usb-storage: Command READ_CAPACITY (10 bytes)
Jun 29 23:19:04 tokamak kernel: usb-storage: 25 00 00 00 00 00 00 00 00 00
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x26 L 8 F 128 Trg 0 LUN 0 CL 10
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:19:04 tokamak kernel: usb-storage: Status code 0; transferred 31/31
Jun 29 23:19:04 tokamak kernel: usb-storage: -- transfer complete
Jun 29 23:19:04 tokamak kernel: usb-storage: Bulk command transfer result=0
Jun 29 23:19:04 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
Jun 29 23:19:34 tokamak kernel: usb-storage: command_abort called
Jun 29 23:19:34 tokamak kernel: usb-storage: usb_stor_stop_transport called
Jun 29 23:19:34 tokamak kernel: usb-storage: -- cancelling URB
Jun 29 23:19:34 tokamak kernel: usb-storage: Status code -104; transferred 0/8
Jun 29 23:19:34 tokamak kernel: usb-storage: -- transfer cancelled
Jun 29 23:19:34 tokamak kernel: usb-storage: Bulk data transfer result 0x4
Jun 29 23:19:34 tokamak kernel: usb-storage: -- command was aborted
Jun 29 23:19:34 tokamak kernel: usb-storage: usb_stor_Bulk_reset called
Jun 29 23:19:34 tokamak kernel: usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
Jun 29 23:19:54 tokamak kernel: usb-storage: Timeout -- cancelling URB
Jun 29 23:19:54 tokamak kernel: usb-storage: Soft reset failed: -104
Jun 29 23:19:54 tokamak kernel: usb-storage: scsi command aborted
Jun 29 23:19:54 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:19:54 tokamak kernel: usb-storage: queuecommand called
Jun 29 23:19:54 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:19:54 tokamak kernel: usb-storage: Command TEST_UNIT_READY (6 bytes)
Jun 29 23:19:54 tokamak kernel: usb-storage: 00 00 00 00 00 00
Jun 29 23:19:54 tokamak kernel: usb-storage: Bulk Command S 0x43425355 T 0x26 L 0 F 0 Trg 0 LUN 0 CL 6
Jun 29 23:19:54 tokamak kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 29 23:20:04 tokamak kernel: usb-storage: command_abort called
Jun 29 23:20:04 tokamak kernel: usb-storage: usb_stor_stop_transport called
Jun 29 23:20:04 tokamak kernel: usb-storage: -- cancelling URB
Jun 29 23:20:04 tokamak kernel: usb-storage: Status code -104; transferred 0/31
Jun 29 23:20:04 tokamak kernel: usb-storage: -- transfer cancelled
Jun 29 23:20:04 tokamak kernel: usb-storage: Bulk command transfer result=4
Jun 29 23:20:04 tokamak kernel: usb-storage: -- command was aborted
Jun 29 23:20:04 tokamak kernel: usb-storage: usb_stor_Bulk_reset called
Jun 29 23:20:04 tokamak kernel: usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
Jun 29 23:20:04 tokamak kernel: usb-storage: Soft reset failed: -110
Jun 29 23:20:04 tokamak kernel: usb-storage: scsi command aborted
Jun 29 23:20:04 tokamak kernel: usb-storage: *** thread sleeping.
Jun 29 23:20:04 tokamak kernel: usb-storage: device_reset called
Jun 29 23:20:04 tokamak kernel: usb-storage: usb_stor_Bulk_reset called
Jun 29 23:20:04 tokamak kernel: usb-storage: usb_stor_control_msg: rq=ff rqtype=21 value=0000 index=00 len=0
Jun 29 23:20:04 tokamak kernel: usb-storage: Soft reset failed: -110
Jun 29 23:20:04 tokamak kernel: usb-storage: bus_reset called
Jun 29 23:20:04 tokamak kernel: usb 1-2: reset full speed USB device using address 3
Jun 29 23:20:05 tokamak kernel: usb 1-2: device not accepting address 3, error -110
Jun 29 23:20:05 tokamak kernel: usb-storage: usb_reset_device returns -19
Jun 29 23:20:05 tokamak kernel: scsi: Device offlined - not ready after error recovery: host 1 channel 0 id 0 lun 0
Jun 29 23:20:05 tokamak kernel: scsi1 (0:0): rejecting I/O to offline device
Jun 29 23:20:05 tokamak kernel: scsi1 (0:0): rejecting I/O to offline device
Jun 29 23:20:05 tokamak kernel: sda : READ CAPACITY failed.
Jun 29 23:20:05 tokamak kernel: sda : status=0, message=00, host=5, driver=04
Jun 29 23:20:05 tokamak kernel: sda : sense not available.
Jun 29 23:20:05 tokamak kernel: sda: assuming Write Enabled
Jun 29 23:20:05 tokamak kernel: sda: assuming drive cache: write through
Jun 29 23:20:40 tokamak sc: done: failure: 'mount' message was "mount: /dev/sda1 is not a vaid block device"
Jun 29 23:25:55 tokamak sc: removing cf chip from reader
Jun 29 23:26:08 tokamak sc: unplugging card reader
Jun 29 23:26:11 tokamak kernel: usb 1-2: USB disconnect, address -1
Jun 29 23:26:11 tokamak kernel: usb-storage: storage_disconnect() called
Jun 29 23:26:11 tokamak kernel: usb-storage: usb_stor_stop_transport called
Jun 29 23:26:11 tokamak kernel: usb-storage: -- dissociate_dev
Jun 29 23:26:11 tokamak kernel: usb-storage: -- sending exit command to thread
Jun 29 23:26:11 tokamak kernel: usb-storage: *** thread awakened.
Jun 29 23:26:11 tokamak kernel: usb-storage: -- exit command received
Jun 29 23:26:11 tokamak kernel: usb-storage: -- usb_stor_release_resources finished
^ permalink raw reply
* Re: Kernel 2.6.5 - iptables 1.2.9 problems
From: Karl Lattimer @ 2004-06-30 10:06 UTC (permalink / raw)
To: Juan Hernandez; +Cc: netfilter
In-Reply-To: <40DC4F0E.5040609@kanux.com>
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
Hi IP-Tables isn't outputting any error messages at all. Heres my
script. Or there abouts.
The problems i am getting are the port forwards for 4662 and 4672 arn't
working correctly. I'm getting port forwards adding themselves in for
ports 5800,5900,3372,6502,1025,1026,42 and 366. As you can see these
rules don't exist in the firewall, there is also an nmap scan output
attached of the ports which are open/filtered.
Connection tracking is working fine and when i add some rules in to open
ports up sometimes it doesn't work sometimes it does.
Thanks
Karl
On Fri, 2004-06-25 at 17:13, Juan Hernandez wrote:
> Could you copy and pase some logging?
>
> Juan
> Karl Lattimer wrote:
>
> >Hi, I've got a firewall script I've which i've been using for 2 years
> >now on redhat 7.3 and redhat 9, after upgrading to fedora core 2 the
> >script is misbehaving slightly. Some of my port forwards don't work
> >correctly and some of my port blocking/opening doesn't work correctly.
> >
> >Any ideas what may be causing this?
> >
> >Thanks
> >
> >Karl
> >
> >
> >
> >
[-- Attachment #2: firewall.debug.sh --]
[-- Type: application/x-shellscript, Size: 10398 bytes --]
[-- Attachment #3: nmap.firewall.txt --]
[-- Type: text/plain, Size: 2131 bytes --]
(The 1557 ports scanned but not shown below are in state: closed)
Port State Service
1/tcp filtered tcpmux
2/tcp filtered compressnet
3/tcp filtered compressnet
4/tcp filtered unknown
5/tcp filtered rje
6/tcp filtered unknown
7/tcp filtered echo
8/tcp filtered unknown
9/tcp filtered discard
10/tcp filtered unknown
11/tcp filtered systat
12/tcp filtered unknown
13/tcp filtered daytime
14/tcp filtered unknown
15/tcp filtered netstat
16/tcp filtered unknown
17/tcp filtered qotd
18/tcp filtered msp
19/tcp filtered chargen
20/tcp filtered ftp-data
21/tcp filtered ftp
22/tcp open ssh
23/tcp filtered telnet
24/tcp filtered priv-mail
25/tcp open smtp
42/tcp open nameserver
110/tcp open pop-3
135/tcp filtered loc-srv
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
143/tcp open imap2
366/tcp open odmr
445/tcp filtered microsoft-ds
465/tcp open smtps
993/tcp open imaps
995/tcp open pop3s
1025/tcp open NFS-or-IIS
1026/tcp open LSA-or-nterm
3372/tcp open msdtc
5800/tcp open vnc-http
5900/tcp open vnc
6502/tcp open netop-rc
No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.00%P=i386-redhat-linux-gnu%D=6/30%Time=40E28D7F%O=22%C=26)
TSeq(Class=RI%gcd=1%SI=185E3A%IPID=Z%TS=1000HZ)
TSeq(Class=RI%gcd=3%SI=81693%IPID=Z%TS=1000HZ)
TSeq(Class=RI%gcd=1%SI=18513E%IPID=Z%TS=1000HZ)
T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(Resp=N)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=F%ULEN=134%DAT=E)
^ permalink raw reply
* dnat problems
From: Per Frödeberg @ 2004-06-30 10:04 UTC (permalink / raw)
To: netfilter
hi, i am new on the list, so here comes a newbie question i guess. i hope
thats ok.
i´ve got a firewall with the following configuration:
internet: eth0, 1.2.3.4
lan: eth1, 192.168.0.1
on my lan there are several computers attached that are not supposed to use
the firewall for internet-access.
they are routed to different internal networks, so they do not (and should
not) know about ip 1.2.3.4.5.
what i want to do is to forward traffic from my public internetaddress (on
eth0) to a specific machine on the lan,
lets say 192.168.0.2. normally i just DNAT it like:
"iptables -t nat -A PREROUTING -p TCP -i eth0 --dport [port] -j DNAT
--to-destination 192.168.0.2:[port]"
but now since 192.168.0.2 does not know about 1.2.3.4 packets will not find
the way back. so my question is, how
do i do that? in some way i want to forward traffic through eth0 -> eth1 ->
192.168.0.2 on a specific port
and back the same way.
hope you understand the problem.
huge thanks,
per
^ permalink raw reply
* [ALSA - driver 0000351]: Too large I/O port region requested for gameport
From: noreply @ 2004-06-30 10:02 UTC (permalink / raw)
To: alsa-devel
The following bug has been SUBMITTED.
======================================================================
https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000351
======================================================================
Reported By: wiget
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Bug ID: 351
Category: PCI - cmipci
Reproducibility: always
Severity: tweak
Priority: normal
Status: assigned
Distribution: PLD Linux
Kernel Version: 2.6.6-0.28
======================================================================
Date Submitted: 06-30-2004 12:02 CEST
Last Modified: 06-30-2004 12:02 CEST
======================================================================
Summary: Too large I/O port region requested for gameport
Description:
In me system gameport is available on 0x201, but on 0x208-0x20f I have "pnp
00:0b". In cmipci.c for gameport is reserved 8 ioports (0x200-0x208 or
0x201-0x209), but only first ioport is used by analog joystick driver
(gameport_read() from include/linux/gameport.h use inb() if gameport
driver doesn't define gameport->read()).
Attached patch change request_region() calls for gameport to reserve only
one ioport.
======================================================================
Bug History
Date Modified Username Field Change
======================================================================
06-30-04 12:02 wiget New Bug
06-30-04 12:02 wiget File Added: cmipci-joystick.patch
06-30-04 12:02 wiget Distribution => PLD Linux
06-30-04 12:02 wiget Kernel Version => 2.6.6-0.28
======================================================================
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
^ permalink raw reply
* Re: [uml-devel] bad panic "Kernel stack overflow" - demo exploit
From: azu @ 2004-06-30 10:04 UTC (permalink / raw)
To: user-mode-linux-devel
In-Reply-To: <200406291604.51726.blaisorblade_spam@yahoo.it>
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]
BlaisorBlade wrote:
> Alle 13:39, lunedì 28 giugno 2004, azu ha scritto:
>
>>Hi,
>
>
>>I triggered the following panic from userspace in skas mode
>>by mapping pages above 0xa0000000 ...
>
>
>>The check is useless in skas-mode (kernel faults get filtered
>>in segv() before handle_page_fault() is called),
>>so I added an ifdef for tt mode.
>
>
> This is a more sensible version of the patch (with runtime checking instead
> that compile time), if I did not overlook anything: it must be an if(mode_tt).
> I always compile in TT mode and normally don't use it (and sometimes UML does
> not compile otherwise), and the patch must still work.
>
>
> However, I don't think this is the proper fix: please elaborate a bit more.
> Segv() works the same way under TT and SKAS, and I think that more likely
> there were an actual stack overflow (try to increase
> CONFIG_KERNEL_STACK_ORDER and try to re-get the panic).
>
Paolo, your patch is the better one :-)
But it wasn't a stack overflow ...
Due to "overlapping" address spaces in skas mode,
it is possible to trigger the panic:
A userpage with the same address as current + 4096
must be valid in the vma, but not (yet) mapped to
the user:
0) addr = 0xa0000000
1) mmap a zero page to addr (valid vma) readwrite
2) fork -> mapping is now readonly
3) child writes to page
4) IF addr == current + 4096 THEN panic
5) addr += 4096
6) goto 1)
I wrote a small demo app to trigger the problem.
Limit your UML memory to 16MB or so to trigger the panic faster.
-Alex
[-- Attachment #2: trigger.c --]
[-- Type: text/x-csrc, Size: 961 bytes --]
/*
* trigger.c - triggers panic("Kernel stack overflow") in UML
*
* 20040630, azu@sysgo.de
*/
#include <stdio.h>
#include <setjmp.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#define LOW 0xa0000000
#define HIGH 0xb0000000
int main(int argc, char **argv)
{
unsigned long addr;
int fd;
fd = open("/dev/zero", O_RDWR);
printf("This may take some time ... one more cup of coffee ...\n");
for(addr = LOW; addr < HIGH; addr += 0x1000)
{
pid_t p;
if(mmap((void*)addr, 0x1000, PROT_READ, MAP_SHARED | MAP_FIXED, fd, 0) == MAP_FAILED)
printf("mmap failed\n");
p = fork();
if(p == -1)
printf("fork failed\n");
if(p == 0)
{
/* child context */
int *p = (int *)addr;
volatile int x;
x = *p;
return 0;
}
/* father context */
waitpid(p, 0, 0);
if(munmap((void*)addr, 0x1000) == -1)
printf("munmap failed\n");
}
close(fd);
printf("done\n");
}
^ permalink raw reply
* Re: can't mount root... devfs???
From: Ian Pratt @ 2004-06-30 9:59 UTC (permalink / raw)
To: James Harper; +Cc: Keir Fraser, xen-devel@lists.sourceforge.net, Ian.Pratt
In-Reply-To: <DD0CE8C1-59F4-40CE-9DDB-FD1BE32BD52C@mimectl>
> devfs is alive and well in 2.6. there is a udev(?) scheme i think which accomplishes the same sort of thing via a different mechanism, but that is about the extent of my knowledge on it and is probably wrong anyway!!!
>
> it is the kernel failing to mount /dev/sda7, not userspace. It also fails if I specify root as 0807, so I guess it isn't a devfs issue on dom1. Dom0 also is using devfs, /dev/sda7 is a symlink to /dev/scsi/host0/bus0/target5/lun0/part7, which is in turn of the right major and minor number. Would xen be failing to work out the device numbers because of the symlink?
Possibly, though we always used to look through links; don't know
about the new tools, but this could be the issue. Could you try a
devfs dom0 and standard dom1?
> After my next reboot i'll try making /dev/sda7 a proper device node. After dom1 crashes and burns, I don't seem to be able to kill it (xm destroy 1), or create it again, so I have to reboot. doh.
Is this with the latest repo? I think some changes that went in
last night finally got this functionality working again.
> Also, make menuconfig for xenU flashes an error on the screen but otherwise works unless I try to look in SCSI where I get this message:
> Menuconfig has encountered a possible error in one of the kernel's
> configuration files and is unable to continue. Here is the
> error
There's something broken with the arch/xen/config.in but I just
can't spot it. The error messages from the Linux config system
are so spectacularly unhelpful that it's impossible to
debug. Fortunately, the error message doesn't actually seem to
obviously break anything, though I have noticed xconfig do
strange things if you ever visit the SCSI config pages.
I think we need to revert to the standard i386 one, and then just
add back in the Xen specific options.
Anyone fancy a really boring but important job? ;-)
Ian
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
^ permalink raw reply
* [BUG FIX] [ARM/ARM26] find_memend_and_nodes bug fix
From: Coywolf Qi Hunt @ 2004-06-30 9:56 UTC (permalink / raw)
To: Russell King; +Cc: linux-kernel, akpm
In-Reply-To: <20040629115830.A24951@flint.arm.linux.org.uk>
Russell King wrote:
>On Tue, Jun 29, 2004 at 06:48:14PM +0800, Coywolf Qi Hunt wrote:
>
>
>>Russell King wrote:
>>Actually there's physical DRAM offset: PHY_OFFSET, defined on ARM only.
>>max_low_pfn happens to be the same as `num_lowpages'.
>>These assignments seems illogical in naming. But just happen to let this
>>patch work. Other platforms may still break.
>>
>>
>
>That may be a bug actually. Looking at ll_rw_blk.c:
>
> unsigned long bounce_pfn = dma_addr >> PAGE_SHIFT;
> if (bounce_pfn < blk_max_low_pfn) {
>
> blk_max_low_pfn = max_low_pfn;
>
>dma_addr are physical addresses, so bounce_pfn is referenced to a PFN0
>equal to physical address 0. This implies that blk_max_low_pfn is
>likewise, as is max_low_pfn.
>
>
>
>>[coywolf@everest ~/linux-2.6.7/arch]$ grep max_low_pfn arm* -rn
>>arm/mm/init.c:235: max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET);
>>
>>
>
>However, here, max_low_pfn of zero corresponds with the PFN of
>PHYS_OFFSET. We have something with two different origins being
>compared, which is nonsense. So something is wrong somewhere,
>and my money is on max_low_pfn.
>
>
>
The bug may get into panic when there's still enough memory for block i/o.
Here's the patch with also a BUG_ON improvement.
=======================================================================
diff -Nrup linux-2.6.7/arch/arm/mm/init.c linux-2.6.7-cy2/arch/arm/mm/init.c
--- linux-2.6.7/arch/arm/mm/init.c 2004-06-29 23:03:30.000000000 -0500
+++ linux-2.6.7-cy2/arch/arm/mm/init.c 2004-06-30 04:32:42.215999091 -0500
@@ -231,9 +231,10 @@ find_memend_and_nodes(struct meminfo *mi
* This doesn't seem to be used by the Linux memory
* manager any more. If we can get rid of it, we
* also get rid of some of the stuff above as well.
+ *
+ * blk_max_low_pfn depends on this. -- coywolf
*/
- max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET);
- max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET);
+ max_low_pfn = max_pfn = memend_pfn;
return bootmem_pages;
}
diff -Nrup linux-2.6.7/arch/arm26/mm/init.c linux-2.6.7-cy2/arch/arm26/mm/init.c
--- linux-2.6.7/arch/arm26/mm/init.c 2004-05-09 21:33:20.000000000 -0500
+++ linux-2.6.7-cy2/arch/arm26/mm/init.c 2004-06-30 03:59:51.000000000 -0500
@@ -160,9 +160,7 @@ find_memend_and_nodes(struct meminfo *mi
np->bootmap_pages = 0;
- if (mi->bank->size == 0) {
- BUG();
- }
+ BUG_ON(mi->bank->size == 0)
/*
* Get the start and end pfns for this bank
@@ -183,9 +181,10 @@ find_memend_and_nodes(struct meminfo *mi
* This doesn't seem to be used by the Linux memory
* manager any more. If we can get rid of it, we
* also get rid of some of the stuff above as well.
+ *
+ * blk_max_low_pfn depends on this. -- coywolf
*/
- max_low_pfn = memend_pfn - PFN_DOWN(PHYS_OFFSET);
- max_pfn = memend_pfn - PFN_DOWN(PHYS_OFFSET);
+ max_low_pfn = max_pfn = memend_pfn;
mi->end = memend_pfn << PAGE_SHIFT;
}
--
Coywolf Qi Hunt
Admin of http://GreatCN.org and http://LoveCN.org
^ permalink raw reply
* Re: can't mount root... devfs???
From: Keir Fraser @ 2004-06-30 9:57 UTC (permalink / raw)
To: James Harper; +Cc: Keir Fraser, xen-devel@lists.sourceforge.net
In-Reply-To: <DD0CE8C1-59F4-40CE-9DDB-FD1BE32BD52C@mimectl>
Turns out devfs is obsolete in 2.6 to be replaced by udev, which is
supposed to be rather nicer to work with. I don't think I'll be trying
to emulate /dev/scsi/host0/bus0/target5/lun0/part7 style names with
the Xen backend driver.
As for your DOM0 issue, what do you get if you run
'/sbin/sfdisk -d /dev/sda' ?
You should get lines of the form:
/dev/sda3 : start= 16948575, size=16836120, Id=83, bootable
Perhaps you are getting the primary devfs names, in which case we can
fix by modifying our matching regexp.
-- Keir
> devfs is alive and well in 2.6. there is a udev(?) scheme i think which accomplishes the same sort of thing via a different mechanism, but that is about the extent of my knowledge on it and is probably wrong anyway!!!
>
> it is the kernel failing to mount /dev/sda7, not userspace. It also fails if I specify root as 0807, so I guess it isn't a devfs issue on dom1. Dom0 also is using devfs, /dev/sda7 is a symlink to /dev/scsi/host0/bus0/target5/lun0/part7, which is in turn of the right major and minor number. Would xen be failing to work out the device numbers because of the symlink?
>
> After my next reboot i'll try making /dev/sda7 a proper device node. After dom1 crashes and burns, I don't seem to be able to kill it (xm destroy 1), or create it again, so I have to reboot. doh.
>
> Also, make menuconfig for xenU flashes an error on the screen but otherwise works unless I try to look in SCSI where I get this message:
>
> Menuconfig has encountered a possible error in one of the kernel's
> configuration files and is unable to continue. Here is the error
> report:
> Q> scripts/Menuconfig: line 832: MCmenu53: command not found
> Please report this to the maintainer <mec@shout.net>. You may also
> send a problem report to <linux-kernel@vger.kernel.org>.
> Please indicate the kernel version you are trying to configure and
> which menu you were trying to enter when this error occurred.
>
> James
>
>
>
>
>
> From: Keir Fraser
> Sent: Wed 30/06/2004 4:43 PM
> To: James Harper
> Cc: xen-devel@lists.sourceforge.net
> Subject: Re: [Xen-devel] can't mount root... devfs???
>
>
> > Domain1 is now not booting anymore, and the boot console tells me it's because it can't mount /dev/sda7.
> >
> > My config files says sda7 maps to /dev/sda7 eg:
> >
> > disk = [ 'phy:sda7,sda7,w' ]
> > root = "/dev/sda7 ro"
> >
> > My only thought is that maybe devfs is confusing the issue... eg there are no scsi devices so sda7 doesn't appear in /dev.
> >
> > Can anyone confirm/deny this?
>
> We make no effort to make 'logical' devices appear in devfs --- if
> it doesn't happen automatically then code needs to be added to do it
> manually.
>
> Is devfs still alive in 2.6, or have they moved to some other scheme?
>
> -- Keir
\x1f -=- MIME -=- \x1f\f
--_03EC8C21-3324-4C90-85C6-3C4D454655EF_
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
devfs is alive and well in 2.6. there is a udev(?) scheme i think which acc=
omplishes the same sort of thing via a different mechanism, but that is abo=
ut the extent of my knowledge on it and is probably wrong anyway!!!
it is the kernel failing to mount /dev/sda7, not userspace. It also fails i=
f I specify root as 0807, so I guess it isn't a devfs issue on dom1. Dom0 a=
lso is using devfs, /dev/sda7 is a symlink to /dev/scsi/host0/bus0/target5/=
lun0/part7, which is in turn of the right major and minor number. Would xen=
be failing to work out the device numbers because of the symlink?
After my next reboot i'll try making /dev/sda7 a proper device node. After =
dom1 crashes and burns, I don't seem to be able to kill it (xm destroy 1), =
or create it again, so I have to reboot. doh.
Also, make menuconfig for xenU flashes an error on the screen but otherwise=
works unless I try to look in SCSI where I get this message:
Menuconfig has encountered a possible error in one of the kernel's
configuration files and is unable to continue. Here is the error
report:
Q> scripts/Menuconfig: line 832: MCmenu53: command not found
Please report this to the maintainer <mec@shout.net>. You may also
send a problem report to <linux-kernel@vger.kernel.org>.
Please indicate the kernel version you are trying to configure and
which menu you were trying to enter when this error occurred.
James
From: Keir Fraser
Sent: Wed 30/06/2004 4:43 PM
To: James Harper
Cc: xen-devel@lists.sourceforge.net
Subject: Re: [Xen-devel] can't mount root... devfs???
> Domain1 is now not booting anymore, and the boot console tells me it's be=
cause it can't mount /dev/sda7.
>=20
> My config files says sda7 maps to /dev/sda7 eg:
>=20
> disk =3D [ 'phy:sda7,sda7,w' ]
> root =3D "/dev/sda7 ro"
>=20
> My only thought is that maybe devfs is confusing the issue... eg there ar=
e no scsi devices so sda7 doesn't appear in /dev.
>=20
> Can anyone confirm/deny this?
We make no effort to make 'logical' devices appear in devfs --- if
it doesn't happen automatically then code needs to be added to do it
manually.
Is devfs still alive in 2.6, or have they moved to some other scheme?
-- Keir
--_03EC8C21-3324-4C90-85C6-3C4D454655EF_
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText89384 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>devfs is alive a=
nd well in 2.6. there is a udev(?) scheme i think which accomplishes the sa=
me sort of thing via a different mechanism, but that is about the extent of=
my knowledge on it and is probably wrong anyway!!!</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>it is the kernel failing to moun=
t /dev/sda7, not userspace. It also fails if I specify root as 0807, so I g=
uess it isn't a devfs issue on dom1. Dom0 also is using devfs, /dev/sda7 is=
a symlink to /dev/scsi/host0/bus0/target5/lun0/part7, which is in turn of =
the right major and minor number. Would xen be failing to work out the devi=
ce numbers because of the symlink?</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>After my next reboot i'll try ma=
king /dev/sda7 a proper device node. After dom1 crashes and burns, I don't =
seem to be able to kill it (xm destroy 1), or create it again, so I have to=
reboot. doh.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Also, make menuconfig for xenU f=
lashes an error on the screen but otherwise works unless I try to look in S=
CSI where I get this message:</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2><BR>Menuconfig has encountered a=
possible error in one of the kernel's<BR>configuration files and is unable=
to continue. Here is the error<BR>report:</DIV>
<DIV dir=3Dltr> Q> scripts/Menuconfig: line 832: MCmenu53: command =
not found</DIV>
<DIV dir=3Dltr>Please report this to the maintainer <<A href=3D"mailto:m=
ec@shout.net" target=3D_blank>mec@shout.net</A>>. You may also<BR>=
send a problem report to <<A href=3D"mailto:linux-kernel@vger.kernel.org=
" target=3D_blank>linux-kernel@vger.kernel.org</A>>.</DIV>
<DIV dir=3Dltr>Please indicate the kernel version you are trying to configu=
re and<BR>which menu you were trying to enter when this error occurred.</DI=
V>
<DIV dir=3Dltr></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>James</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Keir Fraser<BR><B>Sent:</B> Wed 3=
0/06/2004 4:43 PM<BR><B>To:</B> James Harper<BR><B>Cc:</B> xen-devel@lists.=
sourceforge.net<BR><B>Subject:</B> Re: [Xen-devel] can't mount root... devf=
s???<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">> Domain1 is now not booting a=
nymore, and the boot console tells me it's because it can't mount /dev/sda7=
.
>=20
> My config files says sda7 maps to /dev/sda7 eg:
>=20
> disk =3D [ 'phy:sda7,sda7,w' ]
> root =3D "/dev/sda7 ro"
>=20
> My only thought is that maybe devfs is confusing the issue... eg there=
are no scsi devices so sda7 doesn't appear in /dev.
>=20
> Can anyone confirm/deny this?
We make no effort to make 'logical' devices appear in devfs --- if
it doesn't happen automatically then code needs to be added to do it
manually.
Is devfs still alive in 2.6, or have they moved to some other scheme?
-- Keir
</PRE></DIV></BODY></HTML>
--_03EC8C21-3324-4C90-85C6-3C4D454655EF_--
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
^ permalink raw reply
* pdflush uses all cpu-time with 2.6.7 and slow media
From: Georg Chini @ 2004-06-30 9:55 UTC (permalink / raw)
To: linux-kernel
Hello,
there seems to be a problem with pdflush and
slow media in 2.6.7. I'm using the packet-writing patch
maintained by Peter Osterlund to write to dvd+rw.
When I copy large files to the dvd, pdflush
starts using all cpu-time up to a point where
the system hangs completely. I found a posting here
with a similar problem concerning nfs and pdflush
(28.04.2004, Brent Cook). This thread mentions,
that the problem is not observable in 2.6.5.
So I tried 2.6.5 and everything works fine if
I set dirty_ratio in /proc/sys/vm to 15. With
the default value of 40 there are still some problems,
but it is way better than 2.6.7-bk12. BTW my machine
is a dual PIII.
Any idea what might cause the problem? Any more
information I should give?
As I'm not on the list, please CC to me in your replies.
Thanks in advance
Georg Chini
^ permalink raw reply
* [U-Boot-Users] Add support for TQM5200 board
From: Martin Krause @ 2004-06-30 9:55 UTC (permalink / raw)
To: u-boot
Hello all,
this patch adds support for the TQM5200 module family (with a MPC5200 CPU).
* Patch by Martin Krause, 30 June 2004:
Add support for TQM5200 board
Best regards,
Martin Krause
------------------------------------------------------------------
Martin Krause
TQ-Systems GmbH
Gut Delling, M?hlstr. 2, 82229 Seefeld, Germany
Email: martin.krause at tqs.de
http://www.tq-group.com
<<tqm5200.tar.gz>> <<patch_u-boot_tqm5200_2004-06-29_all_mkr>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tqm5200.tar.gz
Type: application/x-gzip
Size: 12280 bytes
Desc: tqm5200.tar.gz
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040630/c227be17/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_u-boot_tqm5200_2004-06-29_all_mkr
Type: application/octet-stream
Size: 7284 bytes
Desc: patch_u-boot_tqm5200_2004-06-29_all_mkr
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040630/c227be17/attachment.obj
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.