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
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
>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
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...
Nigel Kukard <[email protected]> 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 <[email protected]>
Signed-off-by: OGAWA Hirofumi <[email protected]>
---
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);
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
On Thursday 28 October 2004 05:23, OGAWA Hirofumi wrote:
>Nigel Kukard <[email protected]> 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.
On Thursday 28 October 2004 07:14, Gene Heskett wrote:
>On Thursday 28 October 2004 05:23, OGAWA Hirofumi wrote:
>>Nigel Kukard <[email protected]> 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.
On Thursday 28 October 2004 07:14, Gene Heskett wrote:
>On Thursday 28 October 2004 05:23, OGAWA Hirofumi wrote:
>>Nigel Kukard <[email protected]> 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.
Nigel Kukard <[email protected]> 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 <[email protected]>
Gene Heskett <[email protected]> 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 <[email protected]>
could you shoot me the patch when you done plz :-)
Glad i could help!
-Nigel Kukard
Nigel Kukard <[email protected]> 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 <[email protected]>
[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 <[email protected]>
---
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++;
_
On Thursday 28 October 2004 09:21, OGAWA Hirofumi wrote:
>Gene Heskett <[email protected]> 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.
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.
Gene Heskett <[email protected]> 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 <[email protected]>
On Thursday 28 October 2004 15:50, OGAWA Hirofumi wrote:
>Gene Heskett <[email protected]> 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.
Gene Heskett <[email protected]> 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 <[email protected]>
On Thursday 28 October 2004 20:01, OGAWA Hirofumi wrote:
>Gene Heskett <[email protected]> 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.
On Friday 29 October 2004 00:50, Gene Heskett wrote:
>On Thursday 28 October 2004 20:01, OGAWA Hirofumi wrote:
>>Gene Heskett <[email protected]> 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.