* mount hanging 2.4.12
@ 2001-10-13 23:41 Ed Tomlinson
2001-10-13 23:55 ` Alexander Viro
2001-10-14 2:01 ` Alexander Viro
0 siblings, 2 replies; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-13 23:41 UTC (permalink / raw)
To: linux-kernel
Hi,
With kernel 2.4.12 I am having problems with mount hanging.
oscar% mount /fuji
oscar% cd /fuji
oscar% ls
dcim
oscar% cd
oscar% umount /fuji
oscar% mount /fuji
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
or too many mounted file systems
oscar% mount /fuji
and ps shows
oscar% ps -efl | grep mount
100 D root 876 793 0 69 0 - 368 down 19:28 pts/1 00:00:00 mount /fuji
000 S ed 943 886 0 71 0 - 341 pipe_w 19:31 pts/2 00:00:00 grep mount
With 2.4.10 and below I would get the wrong fs message too. The next mount would
work. One interesting thing. The second mount will work if the media has not
changed...
mount /fuji
umount /fuji
mount /fuji
will work but
mount /fuji
umount /fuji
<change media>
mount /fuji
hangs.
kern.log shows:
Oct 13 19:28:31 oscar kernel: usb-uhci.c: interrupt, status 2, frame# 1147
Oct 13 19:28:31 oscar kernel: I/O error: dev 08:01, sector 0
Oct 13 19:28:31 oscar kernel: FAT: unable to read boot sector
Oct 13 19:28:31 oscar kernel: VFS: Disk change detected on device sd(8,1)
Oct 13 19:28:31 oscar kernel: SCSI device sda: 131072 512-byte hdwr sectors (67 MB)
Oct 13 19:28:31 oscar kernel: sda: Write Protect is on
Oct 13 19:28:31 oscar kernel: sda: sda1
The device is a usb smartmedia reader using the sddr-09 support.
TIA
Ed Tomlinson
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-13 23:41 Ed Tomlinson
@ 2001-10-13 23:55 ` Alexander Viro
2001-10-14 0:16 ` Riley Williams
2001-10-14 2:01 ` Alexander Viro
1 sibling, 1 reply; 30+ messages in thread
From: Alexander Viro @ 2001-10-13 23:55 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
On Sat, 13 Oct 2001, Ed Tomlinson wrote:
> Hi,
>
> With kernel 2.4.12 I am having problems with mount hanging.
>
> oscar% mount /fuji
> oscar% cd /fuji
> oscar% ls
> dcim
> oscar% cd
> oscar% umount /fuji
> oscar% mount /fuji
> mount: wrong fs type, bad option, bad superblock on /dev/sda1,
> or too many mounted file systems
> oscar% mount /fuji
Lovely... What filesystem type do you have there?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-13 23:55 ` Alexander Viro
@ 2001-10-14 0:16 ` Riley Williams
2001-10-14 0:19 ` Alexander Viro
0 siblings, 1 reply; 30+ messages in thread
From: Riley Williams @ 2001-10-14 0:16 UTC (permalink / raw)
To: Alexander Viro; +Cc: Ed Tomlinson, linux-kernel
Hi Alexander.
On Sat, 13 Oct 2001, Alexander Viro wrote:
> On Sat, 13 Oct 2001, Ed Tomlinson wrote:
>> With kernel 2.4.12 I am having problems with mount hanging.
>>
>> oscar% mount /fuji
>> oscar% cd /fuji
>> oscar% ls
>> dcim
>> oscar% cd
>> oscar% umount /fuji
>> oscar% mount /fuji
>> mount: wrong fs type, bad option, bad superblock on /dev/sda1,
>> or too many mounted file systems
>> oscar% mount /fuji
> Lovely... What filesystem type do you have there?
He said in his original email that it was a USB SmartMedia reader,
which reads the SmartMedia cards used with FujiFilm digital cameras
(amongst others). The actual file system is determined by the cards
themselves and can't be changed.
I have a Fuji MX2700 digital camera myself, and a separate USB reader
for downloading it to computer (the inbuilt serial link is far too
slow), but I'm in the position that the only USB enabled computer in
the household is my wife's one which only runs Win98, and can't be
changed without incurring my wife's severe displeasure. As a result,
I'm not able to test anything USB out.
Best wishes from Riley.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 0:16 ` Riley Williams
@ 2001-10-14 0:19 ` Alexander Viro
0 siblings, 0 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 0:19 UTC (permalink / raw)
To: Riley Williams; +Cc: Ed Tomlinson, linux-kernel
On Sun, 14 Oct 2001, Riley Williams wrote:
> He said in his original email that it was a USB SmartMedia reader,
> which reads the SmartMedia cards used with FujiFilm digital cameras
> (amongst others). The actual file system is determined by the cards
> themselves and can't be changed.
Ahem. Which fs driver is used when it's successfully mounted?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
@ 2001-10-14 1:51 Ed Tomlinson
2001-10-14 2:02 ` Alexander Viro
0 siblings, 1 reply; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-14 1:51 UTC (permalink / raw)
To: linux-kernel; +Cc: Alexander Viro
>On Sun, 14 Oct 2001, Riley Williams wrote:
>> He said in his original email that it was a USB SmartMedia reader,
>> which reads the SmartMedia cards used with FujiFilm digital cameras
>> (amongst others). The actual file system is determined by the cards
>> themselves and can't be changed.
>Ahem. Which fs driver is used when it's successfully mounted?
fat. Would an strace help?
TIA
Ed Tomlinson
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-13 23:41 Ed Tomlinson
2001-10-13 23:55 ` Alexander Viro
@ 2001-10-14 2:01 ` Alexander Viro
2001-10-14 2:07 ` Ed Tomlinson
2001-10-14 2:36 ` Matthew Dharm
1 sibling, 2 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 2:01 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
On Sat, 13 Oct 2001, Ed Tomlinson wrote:
> Oct 13 19:28:31 oscar kernel: usb-uhci.c: interrupt, status 2, frame# 1147
> Oct 13 19:28:31 oscar kernel: I/O error: dev 08:01, sector 0
> Oct 13 19:28:31 oscar kernel: FAT: unable to read boot sector
> Oct 13 19:28:31 oscar kernel: VFS: Disk change detected on device sd(8,1)
> Oct 13 19:28:31 oscar kernel: SCSI device sda: 131072 512-byte hdwr sectors (67 MB)
> Oct 13 19:28:31 oscar kernel: sda: Write Protect is on
> Oct 13 19:28:31 oscar kernel: sda: sda1
>
> The device is a usb smartmedia reader using the sddr-09 support.
OK, looks like:
a) ->check_media_change() is screwed for that device.
b) we are hanging on something interesting. It isn't ->s_umount
and it's very unlikely to be ->s_lock or mount_sem. What it might be,
though... I suspect that ->bd_sem is screwed.
Could you reproduce the hang and then do Alt-Sysrq-T? That should
give you stack traces. I'm especially interested in stack trace of hung
mount(8). It's nice to know that it ends on down(), but knowing what had
called that down() would help big way.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 1:51 Ed Tomlinson
@ 2001-10-14 2:02 ` Alexander Viro
2001-10-14 3:55 ` Brian Landsberger
2001-10-14 8:09 ` Ookhoi
0 siblings, 2 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 2:02 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
On Sat, 13 Oct 2001, Ed Tomlinson wrote:
>
> >On Sun, 14 Oct 2001, Riley Williams wrote:
>
> >> He said in his original email that it was a USB SmartMedia reader,
> >> which reads the SmartMedia cards used with FujiFilm digital cameras
> >> (amongst others). The actual file system is determined by the cards
> >> themselves and can't be changed.
>
> >Ahem. Which fs driver is used when it's successfully mounted?
>
> fat. Would an strace help?
It might, but another thing I'd like to see is stack trace of hung mount.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 2:01 ` Alexander Viro
@ 2001-10-14 2:07 ` Ed Tomlinson
2001-10-14 2:36 ` Alexander Viro
2001-10-14 2:36 ` Matthew Dharm
1 sibling, 1 reply; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-14 2:07 UTC (permalink / raw)
To: Alexander Viro; +Cc: linux-kernel
On October 13, 2001 10:01 pm, Alexander Viro wrote:
> On Sat, 13 Oct 2001, Ed Tomlinson wrote:
> > Oct 13 19:28:31 oscar kernel: usb-uhci.c: interrupt, status 2, frame#
> > 1147 Oct 13 19:28:31 oscar kernel: I/O error: dev 08:01, sector 0
> > Oct 13 19:28:31 oscar kernel: FAT: unable to read boot sector
> > Oct 13 19:28:31 oscar kernel: VFS: Disk change detected on device sd(8,1)
> > Oct 13 19:28:31 oscar kernel: SCSI device sda: 131072 512-byte hdwr
> > sectors (67 MB) Oct 13 19:28:31 oscar kernel: sda: Write Protect is on
> > Oct 13 19:28:31 oscar kernel: sda: sda1
> >
> > The device is a usb smartmedia reader using the sddr-09 support.
>
> OK, looks like:
> a) ->check_media_change() is screwed for that device.
> b) we are hanging on something interesting. It isn't ->s_umount
> and it's very unlikely to be ->s_lock or mount_sem. What it might be,
> though... I suspect that ->bd_sem is screwed.
>
> Could you reproduce the hang and then do Alt-Sysrq-T? That should
> give you stack traces. I'm especially interested in stack trace of hung
> mount(8). It's nice to know that it ends on down(), but knowing what had
> called that down() would help big way.
I left it hung just in case... Should have the same pid as the original report.
Ed
ksymoops 2.4.3 on i586 2.4.12. Options used
-V (default)
-k 20011013192239.ksyms (specified)
-l 20011013192239.modules (specified)
-o /lib/modules/2.4.12/ (default)
-m /boot/System.map-2.4.12 (default)
ac97_codec: AC97 Audio codec, id: 0x4352:0x5903 (Cirrus Logic CS4297)
init S D3FDFF24 3096 1 0 2767 3 (NOTLB)
Using defaults from ksymoops -t elf32-i386 -a i386
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0132aa6>]
[<c0106d53>]
keventd S FFFFFFFF 6252 2 1 7 (L-TLB)
Call Trace: [<c011ca8b>] [<c010568c>]
ksoftirqd_CPU S D3FCE000 5660 3 0 4 1 (L-TLB)
Call Trace: [<c011624e>] [<c010568c>]
kswapd S D3FCC000 5360 4 0 5 3 (L-TLB)
Call Trace: [<c0126ad6>] [<c010568c>]
bdflush S 00000286 6564 5 0 6 4 (L-TLB)
Call Trace: [<c0110379>] [<c0130293>] [<c010568c>]
kupdated S D3FC9FC8 5256 6 0 5 (L-TLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c013031a>] [<c010568c>]
khubd S 00000282 5804 7 1 18 2 (L-TLB)
Call Trace: [<c01aa68a>] [<c0110379>] [<c01aa6cf>] [<c010568c>]
kreiserfsd S D2DADFB4 5596 18 1 60 7 (L-TLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c01103ce>] [<c0166b37>] [<c010568c>]
mdrecoveryd S D283A000 0 60 1 215 18 (L-TLB)
Call Trace: [<d69970a6>] [<c010568c>]
usb-storage-0 S D3048D80 12 214 1 227 215 (L-TLB)
Call Trace: [<c0105c2d>] [<c0105ce3>] [<d6b0549d>] [<d6b03214>] [<c0105683>]
[<c010568c>] [<d6b06f4c>]
scsi_eh_0 S D19A7FDC 0 215 1 214 60 (L-TLB)
Call Trace: [<c0105c2d>] [<c0105ce3>] [<d6a1e323>] [<d6a1cc67>] [<c010568c>]
syslogd S 7FFFFFFF 0 227 1 231 214 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
watchdog S D176FF8C 4796 231 1 2914 235 227 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c01191c9>] [<c0106d53>]
klogd R D1822000 0 235 1 241 231 (NOTLB)
Call Trace: [<c01122b4>] [<c01452a3>] [<c012c9c5>] [<c0106d53>]
portmap S 7FFFFFFF 5660 241 1 245 235 (NOTLB)
Call Trace: [<c010fcdf>] [<c01392b7>] [<c01392ec>] [<c01394ed>] [<c01b3b5b>]
[<c0106d53>]
named S D1519F24 4796 245 1 279 241 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
dhcpd-2.2.x S 7FFFFFFF 0 279 1 297 245 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
inetd S 7FFFFFFF 0 297 1 302 279 (NOTLB)
Call Trace: [<c01c7e59>] [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>]
[<c0106d53>]
klisa S D120FF24 5684 302 1 313 297 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
lpd S 7FFFFFFF 4796 313 1 326 302 (NOTLB)
Call Trace: [<c010fcdf>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
rpc.statd S 7FFFFFFF 2656 326 1 329 313 (NOTLB)
Call Trace: [<c01c7e59>] [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>]
[<c0106d53>]
pipsecd S D0E79F24 5104 329 1 469 326 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
master S D081DF24 4688 469 1 2890 499 329 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
qmgr S D0213F24 4688 471 469 472 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
tlsmgr S D0203F24 4688 472 469 2206 471 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
pppd S 7FFFFFFF 644 499 1 505 469 (NOTLB)
Call Trace: [<c010fcdf>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
rinetd S 7FFFFFFF 0 505 1 507 499 (NOTLB)
Call Trace: [<c010fcdf>] [<c0138b51>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
rwhod S 7FFFFFFF 4720 507 1 509 512 505 (NOTLB)
Call Trace: [<c010fcdf>] [<c01541e3>] [<c01b6cc2>] [<c01b6dde>] [<c01dbcf9>]
[<c01e1085>] [<c01b2661>] [<c01b33e7>] [<c01550b6>] [<c015515b>] [<c0155ec9>]
[<c01b3b07>] [<c0106d53>]
rwhod S D0091F8C 608 509 507 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c01191c9>] [<c0106d53>]
nmbd S CFF59F24 4596 512 1 514 515 507 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
nmbd S CFF3C000 6368 514 512 (NOTLB)
Call Trace: [<c0133d6c>] [<c0133e43>] [<c012c9c5>] [<c0106d53>]
smbd S 7FFFFFFF 5280 515 1 1760 522 512 (NOTLB)
Call Trace: [<c010fcdf>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
sshd S 7FFFFFFF 4796 522 1 526 515 (NOTLB)
Call Trace: [<c01c7e59>] [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>]
[<c0106d53>]
xfs S CFC29F24 5308 526 1 530 522 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
xfs-xtt S CFA13F24 5180 530 1 540 526 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
xringd S 00000286 0 540 1 547 530 (NOTLB)
Call Trace: [<c0110379>] [<c018141c>] [<c011e9ce>] [<c010f518>] [<c010f3b8>]
[<c0170979>] [<c01383f6>] [<c0106d53>]
squid S 00000000 6100 547 1 552 662 540 (NOTLB)
Call Trace: [<c011523e>] [<c0106d53>]
squid S CE779F28 4464 552 547 580 (NOTLB)
Call Trace: [<c01b29dd>] [<c010fd3a>] [<c010fc7c>] [<c01392ec>] [<c01394ed>]
[<c012c5fb>] [<c0106d53>]
squidGuard S 7FFFFFFF 4688 553 552 556 (NOTLB)
Call Trace: [<c010fcdf>] [<c01ca68f>] [<c01cab7f>] [<c01e1085>] [<c01b2661>]
[<c01b2770>] [<c012c9c5>] [<c0106d53>]
squidGuard S 7FFFFFFF 188 556 552 559 553 (NOTLB)
Call Trace: [<c010fcdf>] [<c01ca68f>] [<c01cab7f>] [<c01e1085>] [<c01b2661>]
[<c01b2770>] [<c012c9c5>] [<c0106d53>]
squidGuard S 7FFFFFFF 4624 559 552 560 556 (NOTLB)
Call Trace: [<c010fcdf>] [<c01ca68f>] [<c01cab7f>] [<c01e1085>] [<c01b2661>]
[<c01b2770>] [<c012c9c5>] [<c0106d53>]
squidGuard S 7FFFFFFF 5312 560 552 580 559 (NOTLB)
Call Trace: [<c010fcdf>] [<c01ca68f>] [<c01cab7f>] [<c01e1085>] [<c01b2661>]
[<c01b2770>] [<c012c9c5>] [<c0106d53>]
unlinkd S CE432000 4868 580 552 560 (NOTLB)
Call Trace: [<c0133d6c>] [<c0133e43>] [<c012c9c5>] [<c0106d53>]
cron S CE01DF8C 0 662 1 670 547 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c01191c9>] [<c0106d53>]
_upsd S CDA3DF24 5252 670 1 672 662 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
bkupsd S 00000202 5308 672 1 681 670 (NOTLB)
Call Trace: [<c0181b7f>] [<c0181be8>] [<c0181ebc>] [<c016fe02>] [<c012cffd>]
[<c0134a87>] [<c012d174>] [<c012c2bd>] [<c012c1d3>] [<c012c505>] [<c0106d53>]
zsh S D2C75FB0 4624 681 1 702 682 672 (NOTLB)
Call Trace: [<c0105f17>] [<c0106d53>]
zsh S D1AA3FB0 4 682 1 692 683 681 (NOTLB)
Call Trace: [<c0105f17>] [<c0106d53>]
getty S 7FFFFFFF 0 683 1 684 682 (NOTLB)
Call Trace: [<c010fcdf>] [<c0172dbd>] [<c016f036>] [<c012c9c5>] [<c0106d53>]
getty S 7FFFFFFF 4 684 1 685 683 (NOTLB)
Call Trace: [<c010fcdf>] [<c0172dbd>] [<c016f036>] [<c012c9c5>] [<c0106d53>]
getty S 7FFFFFFF 2332 685 1 686 684 (NOTLB)
Call Trace: [<c010fcdf>] [<c0172dbd>] [<c016f036>] [<c012c9c5>] [<c0106d53>]
getty S 7FFFFFFF 140 686 1 687 685 (NOTLB)
Call Trace: [<c010fcdf>] [<c0172dbd>] [<c016f036>] [<c012c9c5>] [<c0106d53>]
getty S 7FFFFFFF 0 687 1 701 686 (NOTLB)
Call Trace: [<c010fcdf>] [<c0172dbd>] [<c016f036>] [<c012c9c5>] [<c0106d53>]
ssh S 7FFFFFFF 4384 692 682 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
gpm S CD4B5F8C 388 701 1 727 687 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c01191c9>] [<c0106d53>]
zsh S D129DFB0 4 702 681 703 (NOTLB)
Call Trace: [<c0105f17>] [<c0106d53>]
startx S 00000000 5016 703 702 711 (NOTLB)
Call Trace: [<c011523e>] [<c0106d53>]
xinit S 00000000 2940 711 703 716 (NOTLB)
Call Trace: [<c011523e>] [<c0106d53>]
XFree86 S CD3D5F24 388 712 711 716 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
sh S 00000000 5356 716 711 717 712 (NOTLB)
Call Trace: [<c011523e>] [<c0106d53>]
kde2 S 00000000 5016 717 716 756 (NOTLB)
Call Trace: [<c011523e>] [<c0106d53>]
kdeinit S 7FFFFFFF 0 724 1 2831 760 755 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S 7FFFFFFF 4544 727 1 730 701 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S 7FFFFFFF 5472 730 1 733 727 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S CAEB5F24 5136 733 1 755 730 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
artsd S CA1D9F24 4688 753 724 758 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S 7FFFFFFF 5160 755 1 724 733 (NOTLB)
Call Trace: [<c010fcdf>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
ksmserver S 7FFFFFFF 0 756 717 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S 7FFFFFFF 5052 758 724 2808 753 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S 7FFFFFFF 5472 760 1 763 762 724 (NOTLB)
Call Trace: [<c010fcdf>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S C8B33F24 5272 762 1 765 760 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
cat S 7FFFFFFF 0 763 760 (NOTLB)
Call Trace: [<c010fcdf>] [<c0172dbd>] [<c016f036>] [<c012c9c5>] [<c0106d53>]
kdeinit S 7FFFFFFF 4796 765 1 773 762 (NOTLB)
Call Trace: [<c010fcdf>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kmix S C851FF24 0 773 1 776 765 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S C7499F24 0 776 1 786 773 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
kdeinit S 7FFFFFFF 0 786 1 806 776 (NOTLB)
Call Trace: [<c010fcdf>] [<c01b29dd>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
xmm S C5B8BF24 0 806 1 808 786 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c0138cd4>] [<c013906c>] [<c0106d53>]
newsplex S C516FF8C 8 808 1 809 876 806 (NOTLB)
Call Trace: [<c010fd3a>] [<c010fc7c>] [<c01191c9>] [<c0106d53>]
Warning (Oops_read): Code line not seen, dumping what data is available
Proc; init
>>EIP; d3fdff24 <_end+13d38cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0132aa6 <sys_stat64+62/70>
Trace; c0106d52 <system_call+32/40>
Proc; keventd
>>EIP; fffffffe <END_OF_CODE+2946e218/????> <=====
Trace; c011ca8a <context_thread+ee/194>
Trace; c010568c <kernel_thread+28/38>
Proc; ksoftirqd_CPU
>>EIP; d3fce000 <_end+13d26db8/1655edb8> <=====
Trace; c011624e <ksoftirqd+76/b0>
Trace; c010568c <kernel_thread+28/38>
Proc; kswapd
>>EIP; d3fcc000 <_end+13d24db8/1655edb8> <=====
Trace; c0126ad6 <kswapd+82/bc>
Trace; c010568c <kernel_thread+28/38>
Proc; bdflush
>>EIP; 00000286 Before first symbol <=====
Trace; c0110378 <interruptible_sleep_on+3c/50>
Trace; c0130292 <bdflush+9a/a0>
Trace; c010568c <kernel_thread+28/38>
Proc; kupdated
>>EIP; d3fc9fc8 <_end+13d22d80/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c013031a <kupdate+82/f4>
Trace; c010568c <kernel_thread+28/38>
Proc; khubd
>>EIP; 00000282 Before first symbol <=====
Trace; c01aa68a <usb_hub_events+296/2a8>
Trace; c0110378 <interruptible_sleep_on+3c/50>
Trace; c01aa6ce <usb_hub_thread+32/48>
Trace; c010568c <kernel_thread+28/38>
Proc; kreiserfsd
>>EIP; d2dadfb4 <_end+12b06d6c/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c01103ce <interruptible_sleep_on_timeout+42/58>
Trace; c0166b36 <reiserfs_journal_commit_thread+8e/c8>
Trace; c010568c <kernel_thread+28/38>
Proc; mdrecoveryd
>>EIP; d283a000 <_end+12592db8/1655edb8> <=====
Trace; d69970a6 <[md]md_thread+d6/144>
Trace; c010568c <kernel_thread+28/38>
Proc; usb-storage-0
>>EIP; d3048d80 <_end+12da1b38/1655edb8> <=====
Trace; c0105c2c <__down_interruptible+58/c4>
Trace; c0105ce2 <__down_failed_interruptible+6/c>
Trace; d6b0549c <[usb-storage].text.end+11e/1a2>
Trace; d6b03214 <[usb-storage]usb_stor_control_thread+0/2f4>
Trace; c0105682 <kernel_thread+1e/38>
Trace; c010568c <kernel_thread+28/38>
Trace; d6b06f4c <[usb-storage]usb_stor_sense_notready+0/14>
Proc; scsi_eh_0
>>EIP; d19a7fdc <_end+11700d94/1655edb8> <=====
Trace; c0105c2c <__down_interruptible+58/c4>
Trace; c0105ce2 <__down_failed_interruptible+6/c>
Trace; d6a1e322 <[scsi_mod]RCSid+462/ca0>
Trace; d6a1cc66 <[scsi_mod].text.end+88/102>
Trace; c010568c <kernel_thread+28/38>
Proc; syslogd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; watchdog
>>EIP; d176ff8c <_end+114c8d44/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c01191c8 <sys_nanosleep+104/17c>
Trace; c0106d52 <system_call+32/40>
Proc; klogd
>>EIP; d1822000 <_end+1157adb8/1655edb8> <=====
Trace; c01122b4 <do_syslog+c4/2c8>
Trace; c01452a2 <kmsg_read+e/14>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; portmap
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01392b6 <do_poll+82/d8>
Trace; c01392ec <do_poll+b8/d8>
Trace; c01394ec <sys_poll+1e0/2e4>
Trace; c01b3b5a <sys_socketcall+1ba/1d4>
Trace; c0106d52 <system_call+32/40>
Proc; named
>>EIP; d1519f24 <_end+11272cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; dhcpd-2.2.x
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; inetd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c01c7e58 <tcp_poll+2c/140>
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; klisa
>>EIP; d120ff24 <_end+10f68cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; lpd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; rpc.statd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c01c7e58 <tcp_poll+2c/140>
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; pipsecd
>>EIP; d0e79f24 <_end+10bd2cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; master
>>EIP; d081df24 <_end+10576cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; qmgr
>>EIP; d0213f24 <_end+ff6ccdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; tlsmgr
>>EIP; d0203f24 <_end+ff5ccdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; pppd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; rinetd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0138b50 <do_select+1c/1dc>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; rwhod
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01541e2 <reiserfs_update_sd+166/174>
Trace; c01b6cc2 <wait_for_packet+d2/140>
Trace; c01b6dde <skb_recv_datagram+ae/c4>
Trace; c01dbcf8 <udp_recvmsg+58/21c>
Trace; c01e1084 <inet_recvmsg+3c/54>
Trace; c01b2660 <sock_recvmsg+3c/bc>
Trace; c01b33e6 <sys_recvfrom+a2/fc>
Trace; c01550b6 <reiserfs_truncate_file+be/16c>
Trace; c015515a <reiserfs_truncate_file+162/16c>
Trace; c0155ec8 <reiserfs_file_release+338/35c>
Trace; c01b3b06 <sys_socketcall+166/1d4>
Trace; c0106d52 <system_call+32/40>
Proc; rwhod
>>EIP; d0091f8c <_end+fdead44/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c01191c8 <sys_nanosleep+104/17c>
Trace; c0106d52 <system_call+32/40>
Proc; nmbd
>>EIP; cff59f24 <_end+fcb2cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; nmbd
>>EIP; cff3c000 <_end+fc94db8/1655edb8> <=====
Trace; c0133d6c <pipe_wait+7c/a4>
Trace; c0133e42 <pipe_read+ae/1f8>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; smbd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; sshd
>>EIP; 7ffffffe Before first symbol <=====
Trace; c01c7e58 <tcp_poll+2c/140>
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; xfs
>>EIP; cfc29f24 <_end+f982cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; xfs-xtt
>>EIP; cfa13f24 <_end+f76ccdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; xringd
>>EIP; 00000286 Before first symbol <=====
Trace; c0110378 <interruptible_sleep_on+3c/50>
Trace; c018141c <rs_ioctl+160/324>
Trace; c011e9ce <handle_mm_fault+86/b8>
Trace; c010f518 <do_page_fault+160/498>
Trace; c010f3b8 <do_page_fault+0/498>
Trace; c0170978 <tty_ioctl+350/388>
Trace; c01383f6 <sys_ioctl+16a/184>
Trace; c0106d52 <system_call+32/40>
Proc; squid
>>EIP; 00000000 Before first symbol
Trace; c011523e <sys_wait4+362/394>
Trace; c0106d52 <system_call+32/40>
Proc; squid
>>EIP; ce779f28 <_end+e4d2ce0/1655edb8> <=====
Trace; c01b29dc <sock_poll+20/28>
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c01392ec <do_poll+b8/d8>
Trace; c01394ec <sys_poll+1e0/2e4>
Trace; c012c5fa <filp_close+5a/64>
Trace; c0106d52 <system_call+32/40>
Proc; squidGuard
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01ca68e <tcp_data_wait+e2/13c>
Trace; c01cab7e <tcp_recvmsg+40e/76c>
Trace; c01e1084 <inet_recvmsg+3c/54>
Trace; c01b2660 <sock_recvmsg+3c/bc>
Trace; c01b2770 <sock_read+84/90>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; squidGuard
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01ca68e <tcp_data_wait+e2/13c>
Trace; c01cab7e <tcp_recvmsg+40e/76c>
Trace; c01e1084 <inet_recvmsg+3c/54>
Trace; c01b2660 <sock_recvmsg+3c/bc>
Trace; c01b2770 <sock_read+84/90>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; squidGuard
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01ca68e <tcp_data_wait+e2/13c>
Trace; c01cab7e <tcp_recvmsg+40e/76c>
Trace; c01e1084 <inet_recvmsg+3c/54>
Trace; c01b2660 <sock_recvmsg+3c/bc>
Trace; c01b2770 <sock_read+84/90>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; squidGuard
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01ca68e <tcp_data_wait+e2/13c>
Trace; c01cab7e <tcp_recvmsg+40e/76c>
Trace; c01e1084 <inet_recvmsg+3c/54>
Trace; c01b2660 <sock_recvmsg+3c/bc>
Trace; c01b2770 <sock_read+84/90>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; unlinkd
>>EIP; ce432000 <_end+e18adb8/1655edb8> <=====
Trace; c0133d6c <pipe_wait+7c/a4>
Trace; c0133e42 <pipe_read+ae/1f8>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; cron
>>EIP; ce01df8c <_end+dd76d44/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c01191c8 <sys_nanosleep+104/17c>
Trace; c0106d52 <system_call+32/40>
Proc; _upsd
>>EIP; cda3df24 <_end+d796cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; bkupsd
>>EIP; 00000202 Before first symbol <=====
Trace; c0181b7e <block_til_ready+1f6/2b8>
Trace; c0181be8 <block_til_ready+260/2b8>
Trace; c0181ebc <rs_open+114/1cc>
Trace; c016fe02 <tty_open+1fe/370>
Trace; c012cffc <get_chrfops+68/c8>
Trace; c0134a86 <permission+2a/30>
Trace; c012d174 <chrdev_open+40/54>
Trace; c012c2bc <dentry_open+e0/184>
Trace; c012c1d2 <filp_open+42/4c>
Trace; c012c504 <sys_open+34/b8>
Trace; c0106d52 <system_call+32/40>
Proc; zsh
>>EIP; d2c75fb0 <_end+129ced68/1655edb8> <=====
Trace; c0105f16 <sys_rt_sigsuspend+e2/100>
Trace; c0106d52 <system_call+32/40>
Proc; zsh
>>EIP; d1aa3fb0 <_end+117fcd68/1655edb8> <=====
Trace; c0105f16 <sys_rt_sigsuspend+e2/100>
Trace; c0106d52 <system_call+32/40>
Proc; getty
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0172dbc <read_chan+37c/6d4>
Trace; c016f036 <tty_read+aa/cc>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; getty
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0172dbc <read_chan+37c/6d4>
Trace; c016f036 <tty_read+aa/cc>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; getty
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0172dbc <read_chan+37c/6d4>
Trace; c016f036 <tty_read+aa/cc>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; getty
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0172dbc <read_chan+37c/6d4>
Trace; c016f036 <tty_read+aa/cc>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; getty
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0172dbc <read_chan+37c/6d4>
Trace; c016f036 <tty_read+aa/cc>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; ssh
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; gpm
>>EIP; cd4b5f8c <_end+d20ed44/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c01191c8 <sys_nanosleep+104/17c>
Trace; c0106d52 <system_call+32/40>
Proc; zsh
>>EIP; d129dfb0 <_end+10ff6d68/1655edb8> <=====
Trace; c0105f16 <sys_rt_sigsuspend+e2/100>
Trace; c0106d52 <system_call+32/40>
Proc; startx
>>EIP; 00000000 Before first symbol
Trace; c011523e <sys_wait4+362/394>
Trace; c0106d52 <system_call+32/40>
Proc; xinit
>>EIP; 00000000 Before first symbol
Trace; c011523e <sys_wait4+362/394>
Trace; c0106d52 <system_call+32/40>
Proc; XFree86
>>EIP; cd3d5f24 <_end+d12ecdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; sh
>>EIP; 00000000 Before first symbol
Trace; c011523e <sys_wait4+362/394>
Trace; c0106d52 <system_call+32/40>
Proc; kde2
>>EIP; 00000000 Before first symbol
Trace; c011523e <sys_wait4+362/394>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; caeb5f24 <_end+ac0ecdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; artsd
>>EIP; ca1d9f24 <_end+9f32cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; ksmserver
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; c8b33f24 <_end+888ccdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; cat
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0172dbc <read_chan+37c/6d4>
Trace; c016f036 <tty_read+aa/cc>
Trace; c012c9c4 <sys_read+94/cc>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kmix
>>EIP; c851ff24 <_end+8278cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; c7499f24 <_end+71f2cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; kdeinit
>>EIP; 7ffffffe Before first symbol <=====
Trace; c010fcde <schedule_timeout+16/90>
Trace; c01b29dc <sock_poll+20/28>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; xmm
>>EIP; c5b8bf24 <_end+58e4cdc/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c0138cd4 <do_select+1a0/1dc>
Trace; c013906c <sys_select+334/474>
Trace; c0106d52 <system_call+32/40>
Proc; newsplex
>>EIP; c516ff8c <_end+4ec8d44/1655edb8> <=====
Trace; c010fd3a <schedule_timeout+72/90>
Trace; c010fc7c <process_timeout+0/4c>
Trace; c01191c8 <sys_nanosleep+104/17c>
Trace; c0106d52 <system_call+32/40>
1 warning issued. Results may not be reliable.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 2:01 ` Alexander Viro
2001-10-14 2:07 ` Ed Tomlinson
@ 2001-10-14 2:36 ` Matthew Dharm
2001-10-14 2:41 ` Ed Tomlinson
1 sibling, 1 reply; 30+ messages in thread
From: Matthew Dharm @ 2001-10-14 2:36 UTC (permalink / raw)
To: Alexander Viro; +Cc: Ed Tomlinson, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
Media change is broken for the SDDR-09 driver. That's why it's
experimental, among other reasons.
Don't worry about that, but if you've got a non-media change related
problem, then I would look at that.
Matt
On Sat, Oct 13, 2001 at 10:01:06PM -0400, Alexander Viro wrote:
>
>
> On Sat, 13 Oct 2001, Ed Tomlinson wrote:
>
> > Oct 13 19:28:31 oscar kernel: usb-uhci.c: interrupt, status 2, frame# 1147
> > Oct 13 19:28:31 oscar kernel: I/O error: dev 08:01, sector 0
> > Oct 13 19:28:31 oscar kernel: FAT: unable to read boot sector
> > Oct 13 19:28:31 oscar kernel: VFS: Disk change detected on device sd(8,1)
> > Oct 13 19:28:31 oscar kernel: SCSI device sda: 131072 512-byte hdwr sectors (67 MB)
> > Oct 13 19:28:31 oscar kernel: sda: Write Protect is on
> > Oct 13 19:28:31 oscar kernel: sda: sda1
> >
> > The device is a usb smartmedia reader using the sddr-09 support.
>
> OK, looks like:
> a) ->check_media_change() is screwed for that device.
> b) we are hanging on something interesting. It isn't ->s_umount
> and it's very unlikely to be ->s_lock or mount_sem. What it might be,
> though... I suspect that ->bd_sem is screwed.
>
> Could you reproduce the hang and then do Alt-Sysrq-T? That should
> give you stack traces. I'm especially interested in stack trace of hung
> mount(8). It's nice to know that it ends on down(), but knowing what had
> called that down() would help big way.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
NYET! The evil stops here!
-- Pitr
User Friendly, 6/22/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 2:07 ` Ed Tomlinson
@ 2001-10-14 2:36 ` Alexander Viro
0 siblings, 0 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 2:36 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
On Sat, 13 Oct 2001, Ed Tomlinson wrote:
> I left it hung just in case... Should have the same pid as the original report.
Umm... I don't see it there...
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 2:36 ` Matthew Dharm
@ 2001-10-14 2:41 ` Ed Tomlinson
2001-10-14 3:25 ` Matthew Dharm
0 siblings, 1 reply; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-14 2:41 UTC (permalink / raw)
To: Matthew Dharm, Alexander Viro; +Cc: linux-kernel
On October 13, 2001 10:36 pm, Matthew Dharm wrote:
> Media change is broken for the SDDR-09 driver. That's why it's
> experimental, among other reasons.
>
> Don't worry about that, but if you've got a non-media change related
> problem, then I would look at that.
Actually media change _worked_ with previous kernels, 2.4.10 and below.
I would get an error from one mount and the second would work. Not
real clean but it did work...
Ed Tomlinson
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 2:41 ` Ed Tomlinson
@ 2001-10-14 3:25 ` Matthew Dharm
0 siblings, 0 replies; 30+ messages in thread
From: Matthew Dharm @ 2001-10-14 3:25 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Alexander Viro, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
Odd... it's not supposed to. There's no code to generate a media changed
event, and the units don't generate them.
Maybe you have a strange unit that does generate media-change. Odd.
The SDDR-09 code hasn't change since .10, so if it worked then, I _guess_
it should work now.
Matt
On Sat, Oct 13, 2001 at 10:41:08PM -0400, Ed Tomlinson wrote:
> On October 13, 2001 10:36 pm, Matthew Dharm wrote:
> > Media change is broken for the SDDR-09 driver. That's why it's
> > experimental, among other reasons.
> >
> > Don't worry about that, but if you've got a non-media change related
> > problem, then I would look at that.
>
> Actually media change _worked_ with previous kernels, 2.4.10 and below.
> I would get an error from one mount and the second would work. Not
> real clean but it did work...
>
> Ed Tomlinson
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
C: They kicked your ass, didn't they?
S: They were cheating!
-- The Chief and Stef
User Friendly, 11/19/1997
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 2:02 ` Alexander Viro
@ 2001-10-14 3:55 ` Brian Landsberger
2001-10-14 5:11 ` Alexander Viro
2001-10-14 8:09 ` Ookhoi
1 sibling, 1 reply; 30+ messages in thread
From: Brian Landsberger @ 2001-10-14 3:55 UTC (permalink / raw)
Cc: linux-kernel
I've noticed this happening once in a while on my CF loader (Sandisk
Imagemate) on and off again ever since 2.4.9. FAT filesystem,
usb-storage.
On Sat, 2001-10-13 at 19:02, Alexander Viro wrote:
>
>
> On Sat, 13 Oct 2001, Ed Tomlinson wrote:
>
> >
> > >On Sun, 14 Oct 2001, Riley Williams wrote:
> >
> > >> He said in his original email that it was a USB SmartMedia reader,
> > >> which reads the SmartMedia cards used with FujiFilm digital cameras
> > >> (amongst others). The actual file system is determined by the cards
> > >> themselves and can't be changed.
> >
> > >Ahem. Which fs driver is used when it's successfully mounted?
> >
> > fat. Would an strace help?
>
> It might, but another thing I'd like to see is stack trace of hung mount.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
[not found] <20011014034101.1955DB623@oscar.casa.dyndns.org>
@ 2001-10-14 5:08 ` Alexander Viro
2001-10-14 5:26 ` IDE/SCSI Lockup syzygy
2001-10-14 5:46 ` mount hanging 2.4.12 Alexander Viro
0 siblings, 2 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 5:08 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
Deadlocks on lock_super(). I don't see any changes in that
area, though...
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 3:55 ` Brian Landsberger
@ 2001-10-14 5:11 ` Alexander Viro
0 siblings, 0 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 5:11 UTC (permalink / raw)
To: Brian Landsberger; +Cc: linux-kernel
On 13 Oct 2001, Brian Landsberger wrote:
> I've noticed this happening once in a while on my CF loader (Sandisk
> Imagemate) on and off again ever since 2.4.9. FAT filesystem,
> usb-storage.
OK, folks, How about strace of the stuff that happen there? Preferably -
timestamped, to match with relevant part of syslog...
^ permalink raw reply [flat|nested] 30+ messages in thread
* IDE/SCSI Lockup
2001-10-14 5:08 ` mount hanging 2.4.12 Alexander Viro
@ 2001-10-14 5:26 ` syzygy
2001-10-14 5:46 ` mount hanging 2.4.12 Alexander Viro
1 sibling, 0 replies; 30+ messages in thread
From: syzygy @ 2001-10-14 5:26 UTC (permalink / raw)
To: linux-kernel
I use a Maxtor 27gig 92720U8 on my primary IDE channel (alone) and a TEAC
IDE 24x CD rom on the secondary channel. I also use an Adaptec 7890/1
with a 2 ibm hard drives and a scanner,dvd,burner. My machine hangs solid
on various occasions. The common thread is using the IDE drive (which is
just MP3 storage)... I have tried using hdparm -d 0 on the drive but it
still locks up. It is very inconsistant when it locks up. My first idea
was to try large data transfers. I did things like write all of my memory
to disk to try and get it to lock up. It didn't... It seems to lock up
most under multiple simultaneous accesses. The one repeatable killer I
found however was multiCD (a backup solution that builds an image file
from a source directory and then burns that image to CD-Rs) I was using
it to backup the MP3s to cds. the images were being created on my scsi
drive. This is why I am suspicious that its the interaction of the
two. This IS an SMP box. The drive has also been known to cause
problems... I experianced similar lockups on my old P166 that used to
house this drive - but they went away when I seperated it from the Quantum
Fireball that it was sharing a chain with.
I understand this might just be a hardware issue but I'd like to really
pin it on that before I go complain to Maxtor. Not to mention the drive
is old so they will likely tell me to jump in a lake.
Kernel 2.4.7 btw...
Keith Baker
Email: Syzygy@pubnix.org
IM: t3chie
Tele: 631-786-3495
Life is a sexually transmitted disease with 100% mortality.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 5:08 ` mount hanging 2.4.12 Alexander Viro
2001-10-14 5:26 ` IDE/SCSI Lockup syzygy
@ 2001-10-14 5:46 ` Alexander Viro
2001-10-14 12:11 ` Ed Tomlinson
2001-10-14 13:48 ` Chris Mason
1 sibling, 2 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 5:46 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel
On Sun, 14 Oct 2001, Alexander Viro wrote:
> Deadlocks on lock_super(). I don't see any changes in that
> area, though...
Erm, wait... What patches do you have applied? After a second look
at your objdump it seems that you've got spinlocks turned into semaphores.
What the hell is going on there?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 2:02 ` Alexander Viro
2001-10-14 3:55 ` Brian Landsberger
@ 2001-10-14 8:09 ` Ookhoi
1 sibling, 0 replies; 30+ messages in thread
From: Ookhoi @ 2001-10-14 8:09 UTC (permalink / raw)
To: Alexander Viro; +Cc: Ed Tomlinson, linux-kernel
> > >> He said in his original email that it was a USB SmartMedia reader,
> > >> which reads the SmartMedia cards used with FujiFilm digital cameras
> > >> (amongst others). The actual file system is determined by the cards
> > >> themselves and can't be changed.
> >
> > >Ahem. Which fs driver is used when it's successfully mounted?
> >
> > fat. Would an strace help?
>
> It might, but another thing I'd like to see is stack trace of hung mount.
I have the same with sony memorystick. Load usb/scsi/fat modules, mount,
umount, mount again but it fails. I just unload and load all the
relevant modules again and I can read the stick again. This is with
2.4.6-ac2 for example.
Ookhoi
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 5:46 ` mount hanging 2.4.12 Alexander Viro
@ 2001-10-14 12:11 ` Ed Tomlinson
2001-10-14 13:48 ` Chris Mason
1 sibling, 0 replies; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-14 12:11 UTC (permalink / raw)
To: Alexander Viro, Chris Mason; +Cc: linux-kernel
On October 14, 2001 01:46 am, Alexander Viro wrote:
> On Sun, 14 Oct 2001, Alexander Viro wrote:
> > Deadlocks on lock_super(). I don't see any changes in that
> > area, though...
>
> Erm, wait... What patches do you have applied? After a second look
> at your objdump it seems that you've got spinlocks turned into semaphores.
> What the hell is going on there?
OK this rings a bell. I use reiserfs and LVM (1.01-rc4). For snapshots to
work Chris Mason created a VFS locking patch - I am using the version below.
Suspect this is what is doing the down.
Chris, I will forward a few messages other messages to give you the context.
Ed
--- 0.11/fs/super.c Fri, 05 Oct 2001 14:39:50 -0400 root (linux/d/45_super.c 1.1.2.1.2.1 644)
+++ 0.12/fs/super.c Fri, 05 Oct 2001 23:52:55 -0400 root (linux/d/45_super.c 1.1.2.1.2.2 644)
@@ -54,6 +56,8 @@
LIST_HEAD(super_blocks);
spinlock_t sb_lock = SPIN_LOCK_UNLOCKED;
+static DECLARE_MUTEX(lockfs_sem);
+
/*
* Handling of filesystem drivers list.
* Rules:
@@ -333,6 +337,19 @@
sb->s_op->write_super(sb);
unlock_super(sb);
}
+
+static inline void write_super_lockfs(struct super_block *sb)
+{
+ lock_super(sb);
+ if (sb->s_root && sb->s_op) {
+ if (sb->s_dirt && sb->s_op->write_super)
+ sb->s_op->write_super(sb);
+ if (sb->s_op->write_super_lockfs) {
+ sb->s_op->write_super_lockfs(sb);
+ }
+ }
+ unlock_super(sb);
+}
/*
* Note: check the dirty flag before waiting, so we don't
@@ -368,6 +385,39 @@
spin_unlock(&sb_lock);
}
+/*
+ * Note: don't check the dirty flag before waiting, we want the lock
+ * to happen every time this is called. dev must be non-zero
+ */
+void sync_supers_lockfs(kdev_t dev)
+{
+ struct super_block * sb;
+
+ down(&lockfs_sem);
+ if (dev) {
+ sb = get_super(dev);
+ if (sb) {
+ write_super_lockfs(sb);
+ drop_super(sb);
+ }
+ }
+}
+
+void unlockfs(kdev_t dev)
+{
+ struct super_block * sb;
+
+ if (dev) {
+ sb = get_super(dev);
+ if (sb) {
+ if (sb->s_op && sb->s_op->unlockfs)
+ sb->s_op->unlockfs(sb) ;
+ drop_super(sb);
+ }
+ }
+ up(&lockfs_sem);
+}
+
/**
* get_super - get the superblock of a device
* @dev: device to get the superblock for
@@ -591,6 +641,7 @@
if (!s)
goto out1;
down_write(&s->s_umount);
+ down(&lockfs_sem) ;
error = -EBUSY;
restart:
@@ -603,11 +654,13 @@
if (old->s_type != fs_type ||
((flags ^ old->s_flags) & MS_RDONLY)) {
spin_unlock(&sb_lock);
+ up(&lockfs_sem);
put_super(s);
goto out1;
}
if (!grab_super(old))
goto restart;
+ up(&lockfs_sem);
put_super(s);
blkdev_put(bdev, BDEV_FS);
path_release(&nd);
@@ -628,6 +681,9 @@
if (!fs_type->read_super(s, data, 0))
goto out_fail;
unlock_super(s);
+
+ up(&lockfs_sem);
+
get_filesystem(fs_type);
path_release(&nd);
return s;
@@ -741,6 +797,7 @@
sb->s_count -= S_BIAS;
spin_unlock(&sb_lock);
+ down(&lockfs_sem);
down_write(&sb->s_umount);
lock_kernel();
sb->s_root = NULL;
@@ -757,6 +814,7 @@
if (sop->put_super)
sop->put_super(sb);
}
+ up(&lockfs_sem);
/* Forget any remaining inodes */
if (invalidate_inodes(sb)) {
Index: 0.11/fs/buffer.c
--- 0.11/fs/buffer.c Fri, 05 Oct 2001 14:39:50 -0400 root (linux/i/46_buffer.c 1.1.2.1.7.1 644)
+++ 0.12/fs/buffer.c Fri, 05 Oct 2001 23:52:55 -0400 root (linux/i/46_buffer.c 1.1.2.1.7.2 644)
@@ -359,6 +359,34 @@
fsync_dev(dev);
}
+int fsync_dev_lockfs(kdev_t dev)
+{
+ /* you are not allowed to try locking all the filesystems
+ ** on the system, your chances of getting through without
+ ** total deadlock are slim to none.
+ */
+ if (!dev)
+ return fsync_dev(dev) ;
+
+ sync_buffers(dev, 0);
+
+ lock_kernel();
+ /* note, the FS might need to start transactions to
+ ** sync the inodes, or the quota, no locking until
+ ** after these are done
+ */
+ sync_inodes(dev);
+ DQUOT_SYNC(dev);
+ /* if inodes or quotas could be dirtied during the
+ ** sync_supers_lockfs call, the FS is responsible for getting
+ ** them on disk, without deadlocking against the lock
+ */
+ sync_supers_lockfs(dev) ;
+ unlock_kernel();
+
+ return sync_buffers(dev, 1) ;
+}
+
asmlinkage long sys_sync(void)
{
fsync_dev(0);
Index: 0.11/drivers/md/lvm.c
--- 0.11/drivers/md/lvm.c Sun, 23 Sep 2001 20:11:16 -0400 root (linux/i/c/30_lvm.c 1.1.2.1 644)
+++ 0.12/drivers/md/lvm.c Fri, 05 Oct 2001 23:52:55 -0400 root (linux/i/c/30_lvm.c 1.1.2.1.2.1 644)
@@ -161,9 +161,6 @@
#define MAJOR_NR LVM_BLK_MAJOR
#define DEVICE_OFF(device)
-/* lvm_do_lv_create calls fsync_dev_lockfs()/unlockfs() */
-/* #define LVM_VFS_ENHANCEMENT */
-
#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>
@@ -2301,12 +2298,8 @@
if (lv_ptr->lv_access & LV_SNAPSHOT) {
lv_t *org = lv_ptr->lv_snapshot_org, *last;
- /* sync the original logical volume */
- fsync_dev(org->lv_dev);
-#ifdef LVM_VFS_ENHANCEMENT
/* VFS function call to sync and lock the filesystem */
fsync_dev_lockfs(org->lv_dev);
-#endif
down(&org->lv_snapshot_sem);
org->lv_access |= LV_SNAPSHOT_ORG;
@@ -2326,12 +2319,10 @@
else
set_device_ro(lv_ptr->lv_dev, 1);
-#ifdef LVM_VFS_ENHANCEMENT
-/* VFS function call to unlock the filesystem */
+ /* VFS function call to unlock the filesystem */
if (lv_ptr->lv_access & LV_SNAPSHOT) {
unlockfs(lv_ptr->lv_snapshot_org->lv_dev);
}
-#endif
lv_ptr->vg = vg_ptr;
Index: 0.11/kernel/ksyms.c
--- 0.11/kernel/ksyms.c Fri, 05 Oct 2001 14:39:50 -0400 root (linux/n/c/22_ksyms.c 1.1.2.1.7.1 644)
+++ 0.12/kernel/ksyms.c Fri, 05 Oct 2001 23:52:55 -0400 root (linux/n/c/22_ksyms.c 1.1.2.1.7.2 644)
@@ -178,6 +178,8 @@
EXPORT_SYMBOL(invalidate_inode_pages);
EXPORT_SYMBOL(truncate_inode_pages);
EXPORT_SYMBOL(fsync_dev);
+EXPORT_SYMBOL(fsync_dev_lockfs);
+EXPORT_SYMBOL(unlockfs);
EXPORT_SYMBOL(fsync_no_super);
EXPORT_SYMBOL(permission);
EXPORT_SYMBOL(vfs_permission);
Index: 0.11/include/linux/fs.h
--- 0.11/include/linux/fs.h Fri, 05 Oct 2001 14:39:50 -0400 root (linux/f/d/9_fs.h 1.1.2.1.8.1 644)
+++ 0.12/include/linux/fs.h Fri, 05 Oct 2001 23:52:55 -0400 root (linux/f/d/9_fs.h 1.1.2.1.8.2 644)
@@ -1182,6 +1182,7 @@
extern int sync_buffers(kdev_t, int);
extern void sync_dev(kdev_t);
extern int fsync_dev(kdev_t);
+extern int fsync_dev_lockfs(kdev_t);
extern int fsync_super(struct super_block *);
extern int fsync_no_super(kdev_t);
extern void sync_inodes_sb(struct super_block *);
@@ -1193,6 +1194,8 @@
extern void filemap_fdatasync(struct address_space *);
extern void filemap_fdatawait(struct address_space *);
extern void sync_supers(kdev_t);
+extern void sync_supers_lockfs(kdev_t);
+extern void unlockfs(kdev_t);
extern int bmap(struct inode *, int);
extern int notify_change(struct dentry *, struct iattr *);
extern int permission(struct inode *, int);
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 5:46 ` mount hanging 2.4.12 Alexander Viro
2001-10-14 12:11 ` Ed Tomlinson
@ 2001-10-14 13:48 ` Chris Mason
2001-10-14 14:23 ` Ed Tomlinson
2001-10-14 15:55 ` Ed Tomlinson
1 sibling, 2 replies; 30+ messages in thread
From: Chris Mason @ 2001-10-14 13:48 UTC (permalink / raw)
To: Alexander Viro, Ed Tomlinson; +Cc: linux-kernel
On Sunday, October 14, 2001 01:46:19 AM -0400 Alexander Viro
<viro@math.psu.edu> wrote:
>
>
> On Sun, 14 Oct 2001, Alexander Viro wrote:
>
>> Deadlocks on lock_super(). I don't see any changes in that
>> area, though...
>
>
> Erm, wait... What patches do you have applied? After a second look
> at your objdump it seems that you've got spinlocks turned into semaphores.
> What the hell is going on there?
Ed, does this hang happen without the new reiserfs snapshot locking patch
applied?
-chris
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 13:48 ` Chris Mason
@ 2001-10-14 14:23 ` Ed Tomlinson
2001-10-14 15:55 ` Ed Tomlinson
1 sibling, 0 replies; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-14 14:23 UTC (permalink / raw)
To: Chris Mason; +Cc: Alexander Viro, linux-kernel
On October 14, 2001 09:48 am, you wrote:
> On Sunday, October 14, 2001 01:46:19 AM -0400 Alexander Viro
>
> <viro@math.psu.edu> wrote:
> > On Sun, 14 Oct 2001, Alexander Viro wrote:
> >> Deadlocks on lock_super(). I don't see any changes in that
> >> area, though...
> >
> > Erm, wait... What patches do you have applied? After a second look
> > at your objdump it seems that you've got spinlocks turned into
> > semaphores. What the hell is going on there?
>
> Ed, does this hang happen without the new reiserfs snapshot locking patch
> applied?
I have not tried it Chris, Al seem puzzled about what was locking.
Then I remembers you seeming a little leary of using a sem in the vfs
locking stuff...
I will backout the vfs locking stuff and see what happens.
Ed
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 13:48 ` Chris Mason
2001-10-14 14:23 ` Ed Tomlinson
@ 2001-10-14 15:55 ` Ed Tomlinson
2001-10-14 16:30 ` Chris Mason
2001-10-14 16:30 ` Alexander Viro
1 sibling, 2 replies; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-14 15:55 UTC (permalink / raw)
To: Chris Mason, Alexander Viro, Matthew Dharm; +Cc: linux-kernel
On October 14, 2001 09:48 am, Chris Mason wrote:
> On Sunday, October 14, 2001 01:46:19 AM -0400 Alexander Viro
>
> <viro@math.psu.edu> wrote:
> > On Sun, 14 Oct 2001, Alexander Viro wrote:
> >> Deadlocks on lock_super(). I don't see any changes in that
> >> area, though...
> >
> > Erm, wait... What patches do you have applied? After a second look
> > at your objdump it seems that you've got spinlocks turned into
> > semaphores. What the hell is going on there?
>
> Ed, does this hang happen without the new reiserfs snapshot locking patch
> applied?
Hi with the vfs locking patch removed it works.
oscar# mount /fuji
usb-uhci.c: interrupt, status 3, frame# 1622
SCSI device sda: 131072 512-byte hdwr sectors (67 MB)
sda: Write Protect is on
sda: sda1
oscar# ls /fuji
dcim
oscar# umount /fuji
oscar# umount /fuji
umount: /fuji: not mounted
oscar# mount /fuji
usb-uhci.c: interrupt, status 2, frame# 1448
I/O error: dev 08:01, sector 0
FAT: unable to read boot sector
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
or too many mounted file systems
SCSI device sda: 131072 512-byte hdwr sectors (67 MB)
sda: Write Protect is on
sda: sda1
oscar# cat /proc/mounts
/dev/root.old /initrd ext2 rw 0 0
/dev/root / reiserfs rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/lv/misc /misc reiserfs rw 0 0
/dev/hda2 /boot ext2 rw 0 0
/dev/hda1 /w98 vfat ro 0 0
none /proc/bus/usb usbdevfs rw 0 0
tmpfs /tmp tmpfs rw 0 0
/dev/hda4 /root2 ext2 ro 0 0
oscar# mount /fuji
oscar# ls /fuji
dcim
oscar#
Chris, what I suspect is happening is that the mount with the error leaves
the sem locked. After this any mount commant hangs - not just ones for the
USB card read (ie. loop mount to build an initrd fails too..)
Ed
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 15:55 ` Ed Tomlinson
@ 2001-10-14 16:30 ` Chris Mason
2001-10-14 16:32 ` Alexander Viro
2001-10-14 16:30 ` Alexander Viro
1 sibling, 1 reply; 30+ messages in thread
From: Chris Mason @ 2001-10-14 16:30 UTC (permalink / raw)
To: Ed Tomlinson, Alexander Viro, Matthew Dharm; +Cc: linux-kernel
On Sunday, October 14, 2001 11:55:20 AM -0400 Ed Tomlinson
<tomlins@CAM.ORG> wrote:
>
> Chris, what I suspect is happening is that the mount with the error leaves
> the sem locked. After this any mount commant hangs - not just ones for
> the USB card read (ie. loop mount to build an initrd fails too..)
Yup, I see the, I'll send a new patch a little later today.
-chris
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 15:55 ` Ed Tomlinson
2001-10-14 16:30 ` Chris Mason
@ 2001-10-14 16:30 ` Alexander Viro
1 sibling, 0 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 16:30 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Chris Mason, Matthew Dharm, linux-kernel
On Sun, 14 Oct 2001, Ed Tomlinson wrote:
> Hi with the vfs locking patch removed it works.
OK... How about URL of the patch in question?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 16:30 ` Chris Mason
@ 2001-10-14 16:32 ` Alexander Viro
2001-10-14 16:41 ` Chris Mason
2001-10-15 8:18 ` Chris Mason
0 siblings, 2 replies; 30+ messages in thread
From: Alexander Viro @ 2001-10-14 16:32 UTC (permalink / raw)
To: Chris Mason; +Cc: Ed Tomlinson, Matthew Dharm, linux-kernel
On Sun, 14 Oct 2001, Chris Mason wrote:
>
>
> On Sunday, October 14, 2001 11:55:20 AM -0400 Ed Tomlinson
> <tomlins@CAM.ORG> wrote:
> >
> > Chris, what I suspect is happening is that the mount with the error leaves
> > the sem locked. After this any mount commant hangs - not just ones for
> > the USB card read (ie. loop mount to build an initrd fails too..)
>
> Yup, I see the, I'll send a new patch a little later today.
Cc: it to me, OK?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 16:32 ` Alexander Viro
@ 2001-10-14 16:41 ` Chris Mason
2001-10-15 8:18 ` Chris Mason
1 sibling, 0 replies; 30+ messages in thread
From: Chris Mason @ 2001-10-14 16:41 UTC (permalink / raw)
To: Alexander Viro; +Cc: Ed Tomlinson, Matthew Dharm, linux-kernel
On Sunday, October 14, 2001 12:32:33 PM -0400 Alexander Viro
<viro@math.psu.edu> wrote:
>
>
> On Sun, 14 Oct 2001, Chris Mason wrote:
>
>>
>>
>> On Sunday, October 14, 2001 11:55:20 AM -0400 Ed Tomlinson
>> <tomlins@CAM.ORG> wrote:
>> >
>> > Chris, what I suspect is happening is that the mount with the error
>> > leaves the sem locked. After this any mount commant hangs - not just
>> > ones for the USB card read (ie. loop mount to build an initrd fails
>> > too..)
>>
>> Yup, I see the, I'll send a new patch a little later today.
>
> Cc: it to me, OK?
Sure, I was holding off on a cc to linux-kernel because I really don't like
it though ;-) This is the LVM locking patch, so before making a snapshot
LVM wants to flush the FS and block new transactions.
LVM does this:
lockfs(dev) ;
make snapshot
unlockfs(dev) ;
This can happen while dev is either mounted or unmounted. If dev was
unmounted when the lockfs was called, I'd like to make sure nobody can
mount it before the unlockfs is done. I did this with a new semaphore in
fs/super.c, but I'd rather find something cleaner...
-chris
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-14 16:32 ` Alexander Viro
2001-10-14 16:41 ` Chris Mason
@ 2001-10-15 8:18 ` Chris Mason
2001-10-15 11:50 ` Ed Tomlinson
2001-10-15 15:37 ` Hans-Peter Jansen
1 sibling, 2 replies; 30+ messages in thread
From: Chris Mason @ 2001-10-15 8:18 UTC (permalink / raw)
To: Alexander Viro; +Cc: Ed Tomlinson, Matthew Dharm, linux-kernel
[ bad lvm<->reiserfs locking patch causes hangs ]
Ok, here's an updated patch, one liner fix from the original.
-chris
Index: 0.41/fs/super.c
--- 0.41/fs/super.c Thu, 11 Oct 2001 09:27:57 -0400 root (linux/d/45_super.c 1.1.2.1.4.1.2.1 644)
+++ 0.42/fs/super.c Mon, 15 Oct 2001 03:42:49 -0400 root (linux/d/45_super.c 1.1.2.1.4.1.2.2 644)
@@ -54,6 +54,8 @@
LIST_HEAD(super_blocks);
spinlock_t sb_lock = SPIN_LOCK_UNLOCKED;
+static DECLARE_MUTEX(lockfs_sem);
+
/*
* Handling of filesystem drivers list.
* Rules:
@@ -322,6 +324,19 @@
sb->s_op->write_super(sb);
unlock_super(sb);
}
+
+static inline void write_super_lockfs(struct super_block *sb)
+{
+ lock_super(sb);
+ if (sb->s_root && sb->s_op) {
+ if (sb->s_dirt && sb->s_op->write_super)
+ sb->s_op->write_super(sb);
+ if (sb->s_op->write_super_lockfs) {
+ sb->s_op->write_super_lockfs(sb);
+ }
+ }
+ unlock_super(sb);
+}
/*
* Note: check the dirty flag before waiting, so we don't
@@ -357,6 +372,39 @@
spin_unlock(&sb_lock);
}
+/*
+ * Note: don't check the dirty flag before waiting, we want the lock
+ * to happen every time this is called. dev must be non-zero
+ */
+void sync_supers_lockfs(kdev_t dev)
+{
+ struct super_block * sb;
+
+ down(&lockfs_sem);
+ if (dev) {
+ sb = get_super(dev);
+ if (sb) {
+ write_super_lockfs(sb);
+ drop_super(sb);
+ }
+ }
+}
+
+void unlockfs(kdev_t dev)
+{
+ struct super_block * sb;
+
+ if (dev) {
+ sb = get_super(dev);
+ if (sb) {
+ if (sb->s_op && sb->s_op->unlockfs)
+ sb->s_op->unlockfs(sb) ;
+ drop_super(sb);
+ }
+ }
+ up(&lockfs_sem);
+}
+
/**
* get_super - get the superblock of a device
* @dev: device to get the superblock for
@@ -578,6 +626,7 @@
if (!s)
goto out1;
down_write(&s->s_umount);
+ down(&lockfs_sem) ;
error = -EBUSY;
restart:
@@ -590,11 +639,13 @@
if (old->s_type != fs_type ||
((flags ^ old->s_flags) & MS_RDONLY)) {
spin_unlock(&sb_lock);
+ up(&lockfs_sem);
put_super(s);
goto out1;
}
if (!grab_super(old))
goto restart;
+ up(&lockfs_sem);
put_super(s);
blkdev_put(bdev, BDEV_FS);
path_release(&nd);
@@ -615,6 +666,9 @@
if (!fs_type->read_super(s, data, flags & MS_VERBOSE ? 1 : 0))
goto out_fail;
unlock_super(s);
+
+ up(&lockfs_sem);
+
get_filesystem(fs_type);
path_release(&nd);
return s;
@@ -623,6 +677,7 @@
s->s_dev = 0;
s->s_bdev = 0;
s->s_type = NULL;
+ up(&lockfs_sem) ;
unlock_super(s);
spin_lock(&sb_lock);
list_del(&s->s_list);
@@ -728,6 +783,7 @@
sb->s_count -= S_BIAS;
spin_unlock(&sb_lock);
+ down(&lockfs_sem);
down_write(&sb->s_umount);
lock_kernel();
sb->s_root = NULL;
@@ -744,6 +800,7 @@
if (sop->put_super)
sop->put_super(sb);
}
+ up(&lockfs_sem);
/* Forget any remaining inodes */
if (invalidate_inodes(sb)) {
Index: 0.41/fs/buffer.c
--- 0.41/fs/buffer.c Sun, 14 Oct 2001 10:34:39 -0400 root (linux/i/46_buffer.c 1.1.2.1.9.1.4.1 644)
+++ 0.42/fs/buffer.c Mon, 15 Oct 2001 03:42:49 -0400 root (linux/i/46_buffer.c 1.1.2.1.9.1.4.2 644)
@@ -359,6 +359,34 @@
fsync_dev(dev);
}
+int fsync_dev_lockfs(kdev_t dev)
+{
+ /* you are not allowed to try locking all the filesystems
+ ** on the system, your chances of getting through without
+ ** total deadlock are slim to none.
+ */
+ if (!dev)
+ return fsync_dev(dev) ;
+
+ sync_buffers(dev, 0);
+
+ lock_kernel();
+ /* note, the FS might need to start transactions to
+ ** sync the inodes, or the quota, no locking until
+ ** after these are done
+ */
+ sync_inodes(dev);
+ DQUOT_SYNC(dev);
+ /* if inodes or quotas could be dirtied during the
+ ** sync_supers_lockfs call, the FS is responsible for getting
+ ** them on disk, without deadlocking against the lock
+ */
+ sync_supers_lockfs(dev) ;
+ unlock_kernel();
+
+ return sync_buffers(dev, 1) ;
+}
+
asmlinkage long sys_sync(void)
{
fsync_dev(0);
Index: 0.41/drivers/md/lvm.c
--- 0.41/drivers/md/lvm.c Sun, 23 Sep 2001 20:11:16 -0400 root (linux/i/c/30_lvm.c 1.1.2.1 644)
+++ 0.42/drivers/md/lvm.c Mon, 15 Oct 2001 03:42:49 -0400 root (linux/i/c/30_lvm.c 1.1.2.1.9.1 644)
@@ -161,9 +161,6 @@
#define MAJOR_NR LVM_BLK_MAJOR
#define DEVICE_OFF(device)
-/* lvm_do_lv_create calls fsync_dev_lockfs()/unlockfs() */
-/* #define LVM_VFS_ENHANCEMENT */
-
#include <linux/config.h>
#include <linux/version.h>
#include <linux/module.h>
@@ -2301,12 +2298,8 @@
if (lv_ptr->lv_access & LV_SNAPSHOT) {
lv_t *org = lv_ptr->lv_snapshot_org, *last;
- /* sync the original logical volume */
- fsync_dev(org->lv_dev);
-#ifdef LVM_VFS_ENHANCEMENT
/* VFS function call to sync and lock the filesystem */
fsync_dev_lockfs(org->lv_dev);
-#endif
down(&org->lv_snapshot_sem);
org->lv_access |= LV_SNAPSHOT_ORG;
@@ -2326,12 +2319,10 @@
else
set_device_ro(lv_ptr->lv_dev, 1);
-#ifdef LVM_VFS_ENHANCEMENT
/* VFS function call to unlock the filesystem */
if (lv_ptr->lv_access & LV_SNAPSHOT) {
unlockfs(lv_ptr->lv_snapshot_org->lv_dev);
}
-#endif
lv_ptr->vg = vg_ptr;
Index: 0.41/kernel/ksyms.c
--- 0.41/kernel/ksyms.c Sun, 14 Oct 2001 10:34:39 -0400 root (linux/n/c/22_ksyms.c 1.1.2.1.9.1.4.1 644)
+++ 0.42/kernel/ksyms.c Mon, 15 Oct 2001 03:42:49 -0400 root (linux/n/c/22_ksyms.c 1.1.2.1.9.1.4.2 644)
@@ -178,6 +178,8 @@
EXPORT_SYMBOL(invalidate_inode_pages);
EXPORT_SYMBOL(truncate_inode_pages);
EXPORT_SYMBOL(fsync_dev);
+EXPORT_SYMBOL(fsync_dev_lockfs);
+EXPORT_SYMBOL(unlockfs);
EXPORT_SYMBOL(fsync_no_super);
EXPORT_SYMBOL(permission);
EXPORT_SYMBOL(vfs_permission);
Index: 0.41/include/linux/fs.h
--- 0.41/include/linux/fs.h Sun, 14 Oct 2001 10:34:39 -0400 root (linux/f/d/9_fs.h 1.1.2.1.10.1.2.2 644)
+++ 0.42/include/linux/fs.h Mon, 15 Oct 2001 03:42:49 -0400 root (linux/f/d/9_fs.h 1.1.2.1.10.1.2.2.1.1 644)
@@ -1185,6 +1185,7 @@
extern int sync_buffers(kdev_t, int);
extern void sync_dev(kdev_t);
extern int fsync_dev(kdev_t);
+extern int fsync_dev_lockfs(kdev_t);
extern int fsync_super(struct super_block *);
extern int fsync_no_super(kdev_t);
extern void sync_inodes_sb(struct super_block *);
@@ -1196,6 +1197,8 @@
extern void filemap_fdatasync(struct address_space *);
extern void filemap_fdatawait(struct address_space *);
extern void sync_supers(kdev_t);
+extern void sync_supers_lockfs(kdev_t);
+extern void unlockfs(kdev_t);
extern int bmap(struct inode *, int);
extern int notify_change(struct dentry *, struct iattr *);
extern int permission(struct inode *, int);
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-15 8:18 ` Chris Mason
@ 2001-10-15 11:50 ` Ed Tomlinson
2001-10-15 15:37 ` Hans-Peter Jansen
1 sibling, 0 replies; 30+ messages in thread
From: Ed Tomlinson @ 2001-10-15 11:50 UTC (permalink / raw)
To: Chris Mason, Alexander Viro; +Cc: Matthew Dharm, linux-kernel
On October 15, 2001 04:18 am, Chris Mason wrote:
> [ bad lvm<->reiserfs locking patch causes hangs ]
>
> Ok, here's an updated patch, one liner fix from the original.
An important line though. It now works.
mount /fuji
umount /fuji
change media
mount /fuji (which gets an I/0 error reading the boot sector)
mount /fuji
This is using usb-storage and sddr-09 support.
Thanks Everyone
Ed Tomlinson
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-15 8:18 ` Chris Mason
2001-10-15 11:50 ` Ed Tomlinson
@ 2001-10-15 15:37 ` Hans-Peter Jansen
2001-10-15 16:00 ` Chris Mason
1 sibling, 1 reply; 30+ messages in thread
From: Hans-Peter Jansen @ 2001-10-15 15:37 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-kernel
Hi Chris,
I discovered some mount problems/hangs when playing with dvds,
so I gave your patch a try, but it does not apply properly on
2.4.12. Can you shred some light on this:
drypatch -p1 < /home/hp/Downloads/linux/patch/fslock-2.4.12.dif
patching file fs/super.c
Hunk #2 succeeded at 324 with fuzz 2.
Hunk #3 succeeded at 372 with fuzz 2.
Hunk #4 FAILED at 626.
Hunk #5 FAILED at 639.
Hunk #6 FAILED at 666.
Hunk #7 FAILED at 677.
Hunk #8 FAILED at 783.
Hunk #9 FAILED at 800.
6 out of 9 hunks FAILED -- saving rejects to file fs/super.c.rej
patching file fs/buffer.c
Hunk #1 succeeded at 359 with fuzz 1.
patching file drivers/md/lvm.c
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
Thanks in advance,
Hans-Peter
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: mount hanging 2.4.12
2001-10-15 15:37 ` Hans-Peter Jansen
@ 2001-10-15 16:00 ` Chris Mason
0 siblings, 0 replies; 30+ messages in thread
From: Chris Mason @ 2001-10-15 16:00 UTC (permalink / raw)
To: Hans-Peter Jansen; +Cc: linux-kernel
On Monday, October 15, 2001 05:37:49 PM +0200 Hans-Peter Jansen <hpj@urpla.net> wrote:
>
> Hi Chris,
>
> I discovered some mount problems/hangs when playing with dvds,
> so I gave your patch a try, but it does not apply properly on
> 2.4.12. Can you shred some light on this:
The patch was against 2.4.13-pre2 + lvm 1.0.1rc4, it is used for
journaled filesystem snapshots on lvm, so it should not help
the dvd case at all (sorry) . It fixed Ed Tomlinson's problem because
he was using a buggy previous version of the patch.
-chris
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2001-10-15 16:00 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20011014034101.1955DB623@oscar.casa.dyndns.org>
2001-10-14 5:08 ` mount hanging 2.4.12 Alexander Viro
2001-10-14 5:26 ` IDE/SCSI Lockup syzygy
2001-10-14 5:46 ` mount hanging 2.4.12 Alexander Viro
2001-10-14 12:11 ` Ed Tomlinson
2001-10-14 13:48 ` Chris Mason
2001-10-14 14:23 ` Ed Tomlinson
2001-10-14 15:55 ` Ed Tomlinson
2001-10-14 16:30 ` Chris Mason
2001-10-14 16:32 ` Alexander Viro
2001-10-14 16:41 ` Chris Mason
2001-10-15 8:18 ` Chris Mason
2001-10-15 11:50 ` Ed Tomlinson
2001-10-15 15:37 ` Hans-Peter Jansen
2001-10-15 16:00 ` Chris Mason
2001-10-14 16:30 ` Alexander Viro
2001-10-14 1:51 Ed Tomlinson
2001-10-14 2:02 ` Alexander Viro
2001-10-14 3:55 ` Brian Landsberger
2001-10-14 5:11 ` Alexander Viro
2001-10-14 8:09 ` Ookhoi
-- strict thread matches above, loose matches on Subject: below --
2001-10-13 23:41 Ed Tomlinson
2001-10-13 23:55 ` Alexander Viro
2001-10-14 0:16 ` Riley Williams
2001-10-14 0:19 ` Alexander Viro
2001-10-14 2:01 ` Alexander Viro
2001-10-14 2:07 ` Ed Tomlinson
2001-10-14 2:36 ` Alexander Viro
2001-10-14 2:36 ` Matthew Dharm
2001-10-14 2:41 ` Ed Tomlinson
2001-10-14 3:25 ` Matthew Dharm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox