2.6.9bk6 msdos fs OOPS

2.6.9bk6 msdos fs OOPS

[Nigel Kukard]

I just got the below oops when i mounted a usb camera's SD-Card.

Could anyone share some light on the issue?

-Nigel


------------[ cut here ]------------
kernel BUG at fs/fat/cache.c:150!
invalid operand: 0000 [#1]
PREEMPT SMP
Modules linked in: smbfs autofs4 nls_cp437 msdos fat nfsd exportfs lockd 
sunrpc tsdev uhci_hcd parport_pc parport eth1394 nvidia ohci1394 
ieee1394 usbmouse usbkbd usbhid ehci_hcd ub ohci_hcd usbcore i2c_sis96x 
i2c_core pci_hotplug sis_agp agpgart evdev sis900 crc32 snd_als4000 
snd_sb_common snd_pcm snd_page_alloc snd_opl3_lib snd_timer snd_hwdep 
snd_mpu401_uart snd_rawmidi snd_seq_device snd
CPU:    0
EIP:    0060:[<f8cec268>]    Tainted: P      VLI
EFLAGS: 00010202   (2.6.9-bk6)
EIP is at fat_cache_add+0x108/0x130 [fat]
eax: 00000001   ebx: cc2672b8   ecx: cc2672b8   edx: d0bfdc01
esi: d0bfdc1c   edi: d8129798   ebp: d81297d4   esp: d0bfdbf8
ds: 007b   es: 007b   ss: 0068
Process eog (pid: 16973, threadinfo=d0bfd000 task=cd4eb540)
Stack: 00000001 d81297d4 f77af400 d8129798 d0bfdc54 f8cec902 d81297d4 
d0bfdc1c
        0001ffff 00000000 00000000 00000001 00000112 d8129798 f77af400 
00000028
        00000000 f8cec9d6 d81297d4 00000001 d0bfdc50 d0bfdc54 00000001 
00000112
Call Trace:
  [<f8cec902>] fat_get_cluster+0x112/0x1b0 [fat]
  [<f8cec9d6>] fat_bmap_cluster+0x36/0x80 [fat]
  [<f8cecb00>] fat_bmap+0xe0/0x1f0 [fat]
  [<c0119e12>] recalc_task_prio+0xd2/0x200
  [<f8ceeede>] fat_get_block+0x2e/0x160 [fat]
  [<c015e2e6>] block_read_full_page+0x166/0x330
  [<c013d7a6>] add_to_page_cache+0x46/0xe0
  [<c013d80c>] add_to_page_cache+0xac/0xe0
  [<f8cf093f>] fat_readpage+0xf/0x20 [fat]
  [<f8ceeeb0>] fat_get_block+0x0/0x160 [fat]
  [<c0144634>] read_pages+0x84/0x120
  [<c0141be3>] __alloc_pages+0x93/0x310
  [<c02896de>] avc_has_perm_noaudit+0xbe/0x1a0
  [<c0144a29>] do_page_cache_readahead+0x169/0x190
  [<c0144b9f>] page_cache_readahead+0x14f/0x1f0
  [<c013deec>] do_generic_mapping_read+0xfc/0x420
  [<c013e492>] __generic_file_aio_read+0x1a2/0x220
  [<c013e210>] file_read_actor+0x0/0xe0
  [<c013e61e>] generic_file_read+0xae/0xd0
  [<c0133610>] autoremove_wake_function+0x0/0x40
  [<c015aecb>] vfs_read+0x9b/0xf0
  [<c015b13d>] sys_read+0x3d/0x70
  [<c0105f47>] syscall_call+0x7/0xb
Code: 58 85 db 5a 74 32 8b 47 0c 48 89 47 0c 8b 04 24 39 00 75 2c 8b 34 
24 8b 0d 94 4d cf f8 56 51 e8 9f a0 45 c7 58 5a e9 54 ff ff ff <0f> 0b 
96 00 de 1b cf f8 e9 43 ff ff ff 8b 1c 24 e9 7c ff ff ff

Re: 2.6.9bk6 msdos fs OOPS

[Denis Vlasenko]

On Thursday 28 October 2004 10:00, Nigel Kukard wrote:
> I just got the below oops when i mounted a usb camera's SD-Card.
> 
> Could anyone share some light on the issue?
> 
> -Nigel
> 
> 
> ------------[ cut here ]------------
> kernel BUG at fs/fat/cache.c:150!
> invalid operand: 0000 [#1]
> PREEMPT SMP
> Modules linked in: smbfs autofs4 nls_cp437 msdos fat nfsd exportfs lockd 
> sunrpc tsdev uhci_hcd parport_pc parport eth1394 nvidia ohci1394 
                                                   ^^^^^^
> ieee1394 usbmouse usbkbd usbhid ehci_hcd ub ohci_hcd usbcore i2c_sis96x 
> i2c_core pci_hotplug sis_agp agpgart evdev sis900 crc32 snd_als4000 
> snd_sb_common snd_pcm snd_page_alloc snd_opl3_lib snd_timer snd_hwdep 
> snd_mpu401_uart snd_rawmidi snd_seq_device snd
> CPU:    0
> EIP:    0060:[<f8cec268>]    Tainted: P      VLI
                               ^^^^^^^^^^

Try to reproduce without it and/or
contact nvidia on the issue
--
vda

Re: 2.6.9bk6 msdos fs OOPS

[Nigel Kukard]

>Try to reproduce without it and/or
>contact nvidia on the issue
>--
>vda
>  
>

Problem is not related to the nvidia driver.

OOPS is 100% reproducable. I boot into X, and run    eog 
/mnt/camera/dcim/100cresi    and BANG.

I've reproduced it on 3 boxes I have, each with different usb adapter 
hardware and only 1 with the nvidia driver loaded.

It seems to be when eog (eye of gnome) loads thumbnails that this happens.


Regards
Nigel Kukard

Re: 2.6.9bk6 msdos fs OOPS

[Al Viro]

On Thu, Oct 28, 2004 at 07:00:49AM +0000, Nigel Kukard wrote:
> I just got the below oops when i mounted a usb camera's SD-Card.
> 
> Could anyone share some light on the issue?

Try to dd the contents of device to a file and loop-mount it.  If oops
remains, we would have something easier to deal with...

Re: 2.6.9bk6 msdos fs OOPS

[OGAWA Hirofumi]

Nigel Kukard <nkukard@lbsd.net> writes:

> OOPS is 100% reproducable. I boot into X, and run    eog
> /mnt/camera/dcim/100cresi    and BANG.

This is known problem. Can you please try the following patch?
Then, please send debugging output.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>



Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 fs/fat/cache.c |   41 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 40 insertions(+), 1 deletion(-)

diff -puN fs/fat/cache.c~fat-debug fs/fat/cache.c
--- linux-2.6.9-final-a/fs/fat/cache.c~fat-debug	2004-10-17 23:45:27.000000000 +0900
+++ linux-2.6.9-final-a-hirofumi/fs/fat/cache.c	2004-10-18 09:38:31.000000000 +0900
@@ -11,6 +11,7 @@
 #include <linux/fs.h>
 #include <linux/msdos_fs.h>
 #include <linux/buffer_head.h>
+#include <linux/sched.h>
 
 /* this must be > 0. */
 #define FAT_MAX_CACHE	8
@@ -20,6 +21,10 @@ struct fat_cache {
 	int nr_contig;	/* number of contiguous clusters */
 	int fcluster;	/* cluster number in the file. */
 	int dcluster;	/* cluster number on disk. */
+	char comm[16];
+	pid_t pid;
+	unsigned int id;
+	unsigned long long tsc;
 };
 
 struct fat_cache_id {
@@ -134,6 +139,36 @@ static struct fat_cache *fat_cache_merge
 	return NULL;
 }
 
+static void fat_cache_check(struct inode *inode, struct fat_cache_id *new)
+{
+	struct fat_cache *p;
+	unsigned long long tsc;
+
+	if (new->id == FAT_CACHE_VALID) {
+		list_for_each_entry(p, &MSDOS_I(inode)->cache_lru, cache_list) {
+			/* Find the same part as "new" in cluster-chain. */
+			if (p->fcluster == new->fcluster) {
+				BUG_ON(p->dcluster != new->dcluster);
+				goto dump_cache;
+			}
+		}
+	}
+	return;
+
+dump_cache:
+	rdtscll(tsc);
+	printk("%s: tsc %llu, comm %s, pid %d, id %u, "
+	       "contig %d, fclus %d, dclus %d\n",
+	       __FUNCTION__, tsc, current->comm, current->pid, new->id,
+	       new->nr_contig, new->fcluster, new->dcluster);
+	list_for_each_entry(p, &MSDOS_I(inode)->cache_lru, cache_list) {
+		printk("tsc %llu, comm %s, pid %d, id %u, "
+		       "contig %d, fclus %d, dclus %d\n",
+		       p->tsc, p->comm, p->pid, p->id,
+		       p->nr_contig, p->fcluster, p->dcluster);
+	}
+}
+
 static void fat_cache_add(struct inode *inode, struct fat_cache_id *new)
 {
 	struct fat_cache *cache, *tmp;
@@ -146,8 +181,8 @@ static void fat_cache_add(struct inode *
 	    new->id != MSDOS_I(inode)->cache_valid_id)
 		goto out;	/* this cache was invalidated */
 
+	fat_cache_check(inode, new);
 	cache = fat_cache_merge(inode, new);
-	BUG_ON(new->id == FAT_CACHE_VALID && cache != NULL);
 	if (cache == NULL) {
 		if (MSDOS_I(inode)->nr_caches < fat_max_cache(inode)) {
 			MSDOS_I(inode)->nr_caches++;
@@ -171,6 +206,10 @@ static void fat_cache_add(struct inode *
 		cache->nr_contig = new->nr_contig;
 	}
 out_update_lru:
+	strcpy(cache->comm, current->comm);
+	cache->pid = current->pid;
+	cache->id = new->id;
+	rdtscll(cache->tsc);
 	fat_cache_update_lru(inode, cache);
 out:
 	spin_unlock(&MSDOS_I(inode)->cache_lru_lock);

Re: 2.6.9bk6 msdos fs OOPS

[Nigel Kukard]

OGAWA Hirofumi wrote:

>This is known problem. Can you please try the following patch?
>Then, please send debugging output.
>
>Thanks.
>  
>
using 2.6.9-bk6...

fat_cache_check: tsc 239046359353, comm eog, pid 4293, id 0, contig 0, 
fclus 1, dclus 274
tsc 239046276777, comm eog, pid 4294, id 1, contig 2, fclus 1, dclus 274

Glad I can help... let me know if you need anything else.

Regards
Nigel Kukard

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Thursday 28 October 2004 05:23, OGAWA Hirofumi wrote:
>Nigel Kukard <nkukard@lbsd.net> writes:
>> OOPS is 100% reproducable. I boot into X, and run    eog
>> /mnt/camera/dcim/100cresi    and BANG.
>
>This is known problem. Can you please try the following patch?
>Then, please send debugging output.
>
>Thanks.

This still applies cleanly to 2.6.10-rc1-bk6, so I'm building it to 
test also.  I have an Olympus C-3020 that mounts as a vfat file 
system over usb.  It has been somewhat of a problem if the card has 
quite a few pix on it, I must copy, and delete, from the bottom of 
the dirlisting else it goes read-only on me.  When the build is done, 
I'll try mounting it to see if this also gives an Oops, then reboot 
and try again, and report the results.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Thursday 28 October 2004 07:14, Gene Heskett wrote:
>On Thursday 28 October 2004 05:23, OGAWA Hirofumi wrote:
>>Nigel Kukard <nkukard@lbsd.net> writes:
>>> OOPS is 100% reproducable. I boot into X, and run    eog
>>> /mnt/camera/dcim/100cresi    and BANG.
>>
>>This is known problem. Can you please try the following patch?
>>Then, please send debugging output.
>>
>>Thanks.
>
>This still applies cleanly to 2.6.10-rc1-bk6, so I'm building it to
>test also.  I have an Olympus C-3020 that mounts as a vfat file
>system over usb.  It has been somewhat of a problem if the card has
>quite a few pix on it, I must copy, and delete, from the bottom of
>the dirlisting else it goes read-only on me.  When the build is
> done, I'll try mounting it to see if this also gives an Oops, then
> reboot and try again, and report the results.

OGAWA;  I didn't notice I wasn't running gnome, but use kde.  I have 
been able to mount, read the empty card in it, and unmount it 3 times 
with no Oops with the unpatched 2.6.10-rc1-bk6 kernel.  Now I'll 
reboot and retest tour patch.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Thursday 28 October 2004 07:14, Gene Heskett wrote:
>On Thursday 28 October 2004 05:23, OGAWA Hirofumi wrote:
>>Nigel Kukard <nkukard@lbsd.net> writes:
>>> OOPS is 100% reproducable. I boot into X, and run    eog
>>> /mnt/camera/dcim/100cresi    and BANG.
>>
>>This is known problem. Can you please try the following patch?
>>Then, please send debugging output.
>>
>>Thanks.
>
>This still applies cleanly to 2.6.10-rc1-bk6, so I'm building it to
>test also.  I have an Olympus C-3020 that mounts as a vfat file
>system over usb.  It has been somewhat of a problem if the card has
>quite a few pix on it, I must copy, and delete, from the bottom of
>the dirlisting else it goes read-only on me.  When the build is
> done, I'll try mounting it to see if this also gives an Oops, then
> reboot and try again, and report the results.

After the reboot to a 2.6.10-rc1-bk6 plus your patch, its still fine, 
and except for the usual references to /dev/sda1 in the log when I 
turn it on or off, mounting it and scanning its directory doesn't 
generate any additional log info.  Was it supposed to?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.9bk6 msdos fs OOPS

[OGAWA Hirofumi]

Nigel Kukard <nkukard@lbsd.net> writes:

> fat_cache_check: tsc 239046359353, comm eog, pid 4293, id 0, contig 0,
> fclus 1, dclus 274
> tsc 239046276777, comm eog, pid 4294, id 1, contig 2, fclus 1, dclus 274

This file was accessed by multiple process surely. This state is valid.
The wrong is BUG_ON(). I'll remove it.

Thank you for helping debug.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.9bk6 msdos fs OOPS

[OGAWA Hirofumi]

Gene Heskett <gene.heskett@verizon.net> writes:

> After the reboot to a 2.6.10-rc1-bk6 plus your patch, its still fine, 
> and except for the usual references to /dev/sda1 in the log when I 
> turn it on or off, mounting it and scanning its directory doesn't 
> generate any additional log info.  Was it supposed to?

This bug is triggered by race condition. So, it may not happen.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.9bk6 msdos fs OOPS

[Nigel Kukard]

could you shoot me the patch when you done plz  :-)

Glad i could help!


-Nigel Kukard

Re: 2.6.9bk6 msdos fs OOPS

[OGAWA Hirofumi]

Nigel Kukard <nkukard@lbsd.net> writes:

> could you shoot me the patch when you done plz  :-)

The patch is following. I'm going to do my usual stress test for one
or two days.

Please CC to me if you found the problem.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>


[PATCH] FAT: remove wrong BUG_ON()

This is valid state if file was accessed by multiple processes at the
same time.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 fs/fat/cache.c |    1 -
 1 files changed, 1 deletion(-)

diff -puN fs/fat/cache.c~fat-cache-bug_on-fix fs/fat/cache.c
--- linux-2.6.10-rc1/fs/fat/cache.c~fat-cache-bug_on-fix	2004-10-28 01:52:38.000000000 +0900
+++ linux-2.6.10-rc1-hirofumi/fs/fat/cache.c	2004-10-28 01:52:45.000000000 +0900
@@ -147,7 +147,6 @@ static void fat_cache_add(struct inode *
 		goto out;	/* this cache was invalidated */
 
 	cache = fat_cache_merge(inode, new);
-	BUG_ON(new->id == FAT_CACHE_VALID && cache != NULL);
 	if (cache == NULL) {
 		if (MSDOS_I(inode)->nr_caches < fat_max_cache(inode)) {
 			MSDOS_I(inode)->nr_caches++;
_

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Thursday 28 October 2004 09:21, OGAWA Hirofumi wrote:
>Gene Heskett <gene.heskett@verizon.net> writes:
>> After the reboot to a 2.6.10-rc1-bk6 plus your patch, its still
>> fine, and except for the usual references to /dev/sda1 in the log
>> when I turn it on or off, mounting it and scanning its directory
>> doesn't generate any additional log info.  Was it supposed to?
>
>This bug is triggered by race condition. So, it may not happen.
>
>Thanks.

I see.  Apparently my lashup doesn't trigger it.

Now, how about its going read-only on me if I move (and delete) say 33 
pix at the head of the its directory listing?  Is this an M$ related 
fs bug in the camera?

Thats required some contortions like camera battery removal, reboot 
this machine, etc to alleviate and restore normal operations in the 
past.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Thursday 28 October 2004 11:24, Nigel Kukard wrote:
>could you shoot me the patch when you done plz  :-)
>
>Glad i could help!
>
>
>-Nigel Kukard

Its in the first message of this thread, Nigel.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.9bk6 msdos fs OOPS

[OGAWA Hirofumi]

Gene Heskett <gene.heskett@verizon.net> writes:

> Now, how about its going read-only on me if I move (and delete) say 33 
> pix at the head of the its directory listing?  Is this an M$ related 
> fs bug in the camera?
>
> Thats required some contortions like camera battery removal, reboot 
> this machine, etc to alleviate and restore normal operations in the 
> past.

Umm... When filesystem became to read-only, is there the messages from
kernel (output of dmesg)?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Thursday 28 October 2004 15:50, OGAWA Hirofumi wrote:
>Gene Heskett <gene.heskett@verizon.net> writes:
>> Now, how about its going read-only on me if I move (and delete)
>> say 33 pix at the head of the its directory listing?  Is this an
>> M$ related fs bug in the camera?
>>
>> Thats required some contortions like camera battery removal,
>> reboot this machine, etc to alleviate and restore normal
>> operations in the past.
>
>Umm... When filesystem became to read-only, is there the messages
> from kernel (output of dmesg)?

Not at the time, which is why I came to the conclusion it may be a bug 
in the camera software.  It checks in as version 1.0, and we all know 
no one trusts anything at version 1.0. :-)

I know now how to keep it from happening, so its not a showstopper for 
me.

Thanks OGAWA.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.9bk6 msdos fs OOPS

[OGAWA Hirofumi]

Gene Heskett <gene.heskett@verizon.net> writes:

> Not at the time, which is why I came to the conclusion it may be a bug 
> in the camera software.  It checks in as version 1.0, and we all know 
> no one trusts anything at version 1.0. :-)
>
> I know now how to keep it from happening, so its not a showstopper for 
> me.

Can you check the camera's entry of "cat /proc/mounts"?  Is it
something like, "/dev/sda1 /mnt vfat ro,..."?
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Thursday 28 October 2004 20:01, OGAWA Hirofumi wrote:
>Gene Heskett <gene.heskett@verizon.net> writes:
>> Not at the time, which is why I came to the conclusion it may be a
>> bug in the camera software.  It checks in as version 1.0, and we
>> all know no one trusts anything at version 1.0. :-)
>>
>> I know now how to keep it from happening, so its not a showstopper
>> for me.
>
>Can you check the camera's entry of "cat /proc/mounts"?  Is it
>something like, "/dev/sda1 /mnt vfat ro,..."?

Unforch, I just rebooted to 2.6.10-rc1-bk7, and something is now broken.
It's always plugged in, but as it eats batteries pretty bad, turned off.

When I turned it on, I got this in the logs:
Oct 29 00:36:03 coyote kernel: usb 3-2.2: new full speed USB device using address 7
Oct 29 00:36:04 coyote kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Oct 29 00:36:09 coyote scsi.agent[3339]: disk at /devices/pci0000:00/0000:00:02.1/usb3/3-2/3-2.2/3-2.2:1.0/host0/target0:0:0/0:0:0:0
Oct 29 00:36:09 coyote kernel:   Vendor: OLYMPUS   Model: C-3020ZOOM(U)     Rev: 1.00
Oct 29 00:36:09 coyote kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Oct 29 00:36:09 coyote kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
Oct 29 00:36:09 coyote kernel: SCSI device sda: 128000 512-byte hdwr sectors (66 MB)
Oct 29 00:36:09 coyote kernel: sda: assuming Write Enabled
Oct 29 00:36:09 coyote kernel: sda: assuming drive cache: write through
Oct 29 00:36:09 coyote kernel:  sda: sda1
Oct 29 00:36:09 coyote kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0

When I mounted it, the logs show:
Nothing.

The screen I mnounted it in gave this:
[root@coyote dlds-tgzs]# mount -t iso9660 /dev/camera /mnt/camera
mount: wrong fs type, bad option, bad superblock on /dev/camera,
       or too many mounted file systems

And:
[root@coyote dlds-tgzs]# ls -l /dev/camera
lrwxr-xr-x  1 root root 9 Nov 14  2003 /dev/camera -> /dev/sda1

So it appears that -bk7 is broken and I'll have to reboot back to
2.6.10-rc1-bk6 to get that info, and that will require the fscking
of about 200GB of drives, they will all check on the next reboot. :(

Att: Linus:  bk7 broke this, it worked fine at 2.6.10-rc1-bk6.  This
-bk7 kernel includes the patch that started this thread also, as did
the -bk6 test kernel under which it worked.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: 2.6.9bk6 msdos fs OOPS

[Gene Heskett]

On Friday 29 October 2004 00:50, Gene Heskett wrote:
>On Thursday 28 October 2004 20:01, OGAWA Hirofumi wrote:
>>Gene Heskett <gene.heskett@verizon.net> writes:
>>> Not at the time, which is why I came to the conclusion it may be
>>> a bug in the camera software.  It checks in as version 1.0, and
>>> we all know no one trusts anything at version 1.0. :-)
>>>
>>> I know now how to keep it from happening, so its not a
>>> showstopper for me.
>>
>>Can you check the camera's entry of "cat /proc/mounts"?  Is it
>>something like, "/dev/sda1 /mnt vfat ro,..."?

Now it says, after I'd cleared the loss of mind attack:
/dev/camera /mnt/camera vfat rw,nodiratime,fmask=0022,dmask=0022 0 0

>Unforch, I just rebooted to 2.6.10-rc1-bk7, and something is now
> broken. It's always plugged in, but as it eats batteries pretty
> bad, turned off.
>
>When I turned it on, I got this in the logs:
>Oct 29 00:36:03 coyote kernel: usb 3-2.2: new full speed USB device
> using address 7 Oct 29 00:36:04 coyote kernel: scsi0 : SCSI
> emulation for USB Mass Storage devices Oct 29 00:36:09 coyote
> scsi.agent[3339]: disk at
> /devices/pci0000:00/0000:00:02.1/usb3/3-2/3-2.2/3-2.2:1.0/host0/tar
>get0:0:0/0:0:0:0 Oct 29 00:36:09 coyote kernel:   Vendor: OLYMPUS  
> Model: C-3020ZOOM(U)     Rev: 1.00 Oct 29 00:36:09 coyote kernel:  
> Type:   Direct-Access                      ANSI SCSI revision: 02
> Oct 29 00:36:09 coyote kernel: Attached scsi generic sg0 at scsi0,
> channel 0, id 0, lun 0,  type 0 Oct 29 00:36:09 coyote kernel: SCSI
> device sda: 128000 512-byte hdwr sectors (66 MB) Oct 29 00:36:09
> coyote kernel: sda: assuming Write Enabled
>Oct 29 00:36:09 coyote kernel: sda: assuming drive cache: write
> through Oct 29 00:36:09 coyote kernel:  sda: sda1
>Oct 29 00:36:09 coyote kernel: Attached scsi removable disk sda at
> scsi0, channel 0, id 0, lun 0
>
>When I mounted it, the logs show:
>Nothing.
>
>The screen I mnounted it in gave this:
>[root@coyote dlds-tgzs]# mount -t iso9660 /dev/camera /mnt/camera
>mount: wrong fs type, bad option, bad superblock on /dev/camera,
>       or too many mounted file systems
>
And as everyone can see (you too Linus)  I had a brain fart there.  If 
I mount it as a vfat device, it all works
>And:
>[root@coyote dlds-tgzs]# ls -l /dev/camera
>lrwxr-xr-x  1 root root 9 Nov 14  2003 /dev/camera -> /dev/sda1
>
>So it appears that -bk7 is broken and I'll have to reboot back to
>2.6.10-rc1-bk6 to get that info, and that will require the fscking
>of about 200GB of drives, they will all check on the next reboot. :(
>
>Att: Linus:  bk7 broke this, it worked fine at 2.6.10-rc1-bk6.  This
>-bk7 kernel includes the patch that started this thread also, as did
>the -bk6 test kernel under which it worked.

Ignore me Linus, I was trying to do too many things at once.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.28% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.