* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Jaap-Jan Boor @ 2006-03-06 12:21 UTC (permalink / raw)
To: Mathieu Deschamps; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <200603031008.20075.mathieu.deschamps@com2gether.net>
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
On Fri, 2006-03-03 at 10:08 +0100, Mathieu Deschamps wrote:
> Hi,
>
> "When preparing a flash partition for JFFS2, it is recommended to put
> cleanmarkers to the erased blocks.
> This might be done my means of "-j" option of the "flash_eraseall" MTD
> utility. Otherwise, JFFS2 will re-erase the blocks
> which contain all 0xFF and have no cleanmarker. This is an unneeded wasting of
> time."
>
> Source : http://www.linux-mtd.infradead.org/faq/jffs2.html
>
> does this may be relevant ?
This is correct, however flash_eraseall does also (as it's
name suggests, erase all flash blocks, which takes
some time on NOR flash. If you 'know' the flash is erased,
it's not needed.
I used flash_eraseall to write the cleanmarkers, but without
erasing blocks (and called that utility cleanmark)
Jaap-Jan
>
>
>
> Best Regards,
>
>
> Mathieu Deschamps.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1513 bytes --]
^ permalink raw reply
* Problem: NIC transmit timeouts
From: PaNiC @ 2006-03-06 12:28 UTC (permalink / raw)
To: linux-kernel
1. The problem is that the outbound interface in a Sun Enterprise 250
running maquerade gets transmit timeouts frequently.
2. I get the error "NETDEV WATCHDOG: eth0: transmit timed out" and a
couple of seconds later the interface jumps back up again. This
seems only to happen after masquerading and packet forwarding is
activated. When i have momentary traffic going in or out (web browsing
for instance) it happens mostly. It does not happen as often when
downloading large files, but will surely happen with somewhat heavy
traffic going in and out for instance while talking on Skype. I tried
reversing the interfaces so that the outbound would be the inbound and
vice versa, mostly to exclude a hardware problem. This moved the
timeouts again to the outbound interface. This was while using kernel
2.4.27. The same problem appears with 2.6.8 and 2.6.15.4 which i am
currently using. Though not as often as with 2.4.27. I have googled
immensely but have only found people with the same problem, no
solutions.
4. Linux version 2.6.15.4 (root@kronos) (gcc version 3.3.5 (Debian
1:3.3.5-13))
7. Sun Enterprise 250, UltrasparcII-400, Debian 3.1,
7.1
Linux kronos 2.6.15.4 #2 SMP Mon Feb 27 17:48:33 CET 2006 sparc64
GNU/Linux
Gnu C 3.3.5
Gnu make 3.80
binutils 2.15
util-linux 2.12p
mount 2.12p
module-init-tools 3.2-pre1
e2fsprogs 1.37
reiserfsprogs line
reiser4progs line
PPP 2.4.3
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.2.1
Net-tools 1.60
Kbd 83:
Sh-utils 5.2.1
Modules Loaded isofs
7.2
cpu : TI UltraSparc II (BlackBird)
fpu : UltraSparc II integrated FPU
promlib : Version 3 Revision 16
prom : 3.16.1
type : sun4u
ncpus probed : 1
ncpus active : 1
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0Bogo : 798.72
Cpu0ClkTck : 0000000017d78400
MMU Type : Spitfire
State:
CPU0: online
7.3
isofs 34376 0 - Live 0x0000000010000000
7.4
ioports:
1fe02000000-1fe0200ffff : PSYCHO0 PBMA
1fe02010000-1fe0201ffff : PSYCHO0 PBMB
1fe02011000-1fe020110ff : 0001:00:03.0
1fe02011000-1fe020110ff : sym53c8xx
1fe02011400-1fe020114ff : 0001:00:03.1
1fe02011400-1fe020114ff : sym53c8xx
iomem:
1ff00000000-1ff7fffffff : PSYCHO0 PBMA
1ff000a0000-1ff000bffff : Video RAM area
1ff000c0000-1ff000c7fff : Video ROM
1ff000f0000-1ff000fffff : System ROM
1ff80000000-1ffffffffff : PSYCHO0 PBMB
1ff800a0000-1ff800bffff : Video RAM area
1ff800c0000-1ff800c7fff : Video ROM
1ff800f0000-1ff800fffff : System ROM
1ff81000000-1ff81ffffff : 0001:01:00.0
1ff82000000-1ff827fffff : 0001:01:00.0
1ff83000000-1ff83ffffff : 0001:01:00.0
1ff84000000-1ff84007fff : 0001:01:00.1
1ff84000000-1ff84007fff : sunhme
1ff85000000-1ff85ffffff : 0001:01:01.0
1ff86000000-1ff867fffff : 0001:01:01.0
1ff87000000-1ff87ffffff : 0001:01:01.0
1ff88000000-1ff88007fff : 0001:01:01.1
1ff88000000-1ff88007fff : sunhme
1ff89000000-1ff89ffffff : 0001:01:02.0
1ff8a000000-1ff8a7fffff : 0001:01:02.0
1ff8b000000-1ff8bffffff : 0001:01:02.0
1ff8c000000-1ff8c007fff : 0001:01:02.1
1ff8c000000-1ff8c007fff : sunhme
1ff8d000000-1ff8dffffff : 0001:00:01.0
1ff8e000000-1ff8effffff : 0001:00:01.1
1ff8f000000-1ff8fffffff : 0001:01:00.1
1ff90000000-1ff90007fff : 0001:01:03.1
1ff90000000-1ff90007fff : sunhme
1ff90100000-1ff90107fff : 0001:00:01.1
1ff90100000-1ff90107fff : sunhme
1ff90108000-1ff901080ff : 0001:00:03.0
1ff90108000-1ff901080ff : sym53c8xx
1ff9010a000-1ff9010afff : 0001:00:03.0
1ff9010a000-1ff9010afff : sym53c8xx
1ff9010c000-1ff9010c0ff : 0001:00:03.1
1ff9010c000-1ff9010c0ff : sym53c8xx
1ff9010e000-1ff9010efff : 0001:00:03.1
1ff9010e000-1ff9010efff : sym53c8xx
1ff91000000-1ff91ffffff : 0001:01:01.1
1ff92000000-1ff92ffffff : 0001:01:02.1
1ff93000000-1ff93ffffff : 0001:01:03.1
1fff0000000-1fff0ffffff : 0001:00:01.0
1fff0000000-1fff00fffff : flashprom
1fff1000000-1fff17fffff : 0001:00:01.0
1fff1000000-1fff1001fff : eeprom
1fff1200000-1fff120007f : se
1fff1300398-1fff1300399 : ecpp
1fff13043bc-1fff13043cb : ecpp
1fff13062f8-1fff13062ff : su
1fff13083f8-1fff13083ff : su
1fff1400000-1fff140007f : se
1fff1500000-1fff1500007 : sc
1fff1504000-1fff1504002 : SUNW,pll
1fff1600000-1fff1600003 : SUNW,envctrltwo
1fff1700000-1fff170000f : ecpp
1fff1724000-1fff1724003 : power
1fff1726000-1fff1726003 : auxio
1fff1728000-1fff1728003 : auxio
1fff172a000-1fff172a003 : auxio
1fff172c000-1fff172c003 : auxio
1fff172f000-1fff172f003 : auxio
7.5
0000:80:00.0 Host bridge: Sun Microsystems Computer Corp. Psycho PCI
Bus Module
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 64
0001:00:00.0 Host bridge: Sun Microsystems Computer Corp. Psycho PCI Bus
Module
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 64
0001:00:01.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 6250ns max), Cache Line Size: 0x10 (64
bytes)
Region 0: Memory at 000001fff0000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at 000001fff1000000 (32-bit, non-prefetchable)
[size=8M]
Expansion ROM at 000000008d000000 [disabled] [size=16M]
0001:00:01.1 Ethernet controller: Sun Microsystems Computer Corp. Happy
Meal (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 1250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin ? routed to IRQ 8038560
Region 0: Memory at 000001ff90100000 (32-bit, non-prefetchable)
[size=32K]
Expansion ROM at 000000008e000000 [disabled] [size=16M]
0001:00:02.0 PCI bridge: Digital Equipment Corporation DECchip 21153
(rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64, Cache Line Size: 0x10 (64 bytes)
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 00001000-00000fff
Memory behind bridge: 00100000-100fffff
Prefetchable memory behind bridge:
fffffffffff00000-0000000000000000
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=220mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
0001:00:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875
(rev 14)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr+ Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 17 (4250ns min, 16000ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin A routed to IRQ 8038528
Region 0: I/O ports at 2011000 [size=256]
Region 1: Memory at 000001ff90108000 (32-bit, non-prefetchable)
[size=256]
Region 2: Memory at 000001ff9010a000 (32-bit, non-prefetchable)
[size=4K]
0001:00:03.1 SCSI storage controller: LSI Logic / Symbios Logic 53c875
(rev 14)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 17 (4250ns min, 16000ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin B routed to IRQ 8038720
Region 0: I/O ports at 2011400 [size=256]
Region 1: Memory at 000001ff9010c000 (32-bit, non-prefetchable)
[size=256]
Region 2: Memory at 000001ff9010e000 (32-bit, non-prefetchable)
[size=4K]
0001:01:00.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 6250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin A routed to IRQ 0
Region 0: Memory at 000001ff81000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at 000001ff82000000 (32-bit, non-prefetchable)
[size=8M]
Expansion ROM at 0000000083000000 [disabled] [size=16M]
0001:01:00.1 Ethernet controller: Sun Microsystems Computer Corp. Happy
Meal (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 1250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin B routed to IRQ 8038048
Region 0: Memory at 000001ff84000000 (32-bit, non-prefetchable)
[size=32K]
Expansion ROM at 000000008f000000 [disabled] [size=16M]
0001:01:01.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 6250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin A routed to IRQ 0
Region 0: Memory at 000001ff85000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at 000001ff86000000 (32-bit, non-prefetchable)
[size=8M]
Expansion ROM at 0000000087000000 [disabled] [size=16M]
0001:01:01.1 Ethernet controller: Sun Microsystems Computer Corp. Happy
Meal (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 1250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin B routed to IRQ 8038080
Region 0: Memory at 000001ff88000000 (32-bit, non-prefetchable)
[size=32K]
Expansion ROM at 0000000091000000 [disabled] [size=16M]
0001:01:02.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 6250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin A routed to IRQ 0
Region 0: Memory at 000001ff89000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at 000001ff8a000000 (32-bit, non-prefetchable)
[size=8M]
Expansion ROM at 000000008b000000 [disabled] [size=16M]
0001:01:02.1 Ethernet controller: Sun Microsystems Computer Corp. Happy
Meal (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 1250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin B routed to IRQ 8038112
Region 0: Memory at 000001ff8c000000 (32-bit, non-prefetchable)
[size=32K]
Expansion ROM at 0000000092000000 [disabled] [size=16M]
0001:01:03.1 Ethernet controller: Sun Microsystems Computer Corp. Happy
Meal (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 10 (2500ns min, 1250ns max), Cache Line Size: 0x10 (64
bytes)
Interrupt: pin B routed to IRQ 8038016
Region 0: Memory at 000001ff90000000 (32-bit, non-prefetchable)
[size=32K]
Expansion ROM at 0000000093000000 [disabled] [size=16M]
7.6
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST318203LSUN18G Rev: 034A
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
Vendor: PIONEER Model: CD-ROM DR-U16S Rev: 1.01
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 09 Lun: 00
Vendor: IBM-PCCO Model: DDRS-39130Y !# Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 10 Lun: 00
Vendor: IBM-PCCO Model: DDRS-39130Y !# Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 11 Lun: 00
Vendor: IBM-PCCO Model: DDRS-39130Y !# Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 12 Lun: 00
Vendor: IBM-PCCO Model: DDRS-39130Y !# Rev: S97B
Type: Direct-Access ANSI SCSI revision: 02
7.7 Interfaces are a Sun Happy Meal and a Sun quad interface.
I will be thankful for any light on this. If i can do anything to help,
i will.
Thanks for your time.
Best regards
Jonas Bengtsson
^ permalink raw reply
* Re: does the linux support rootfs on vfat?
From: Stuart Longland @ 2006-03-06 12:36 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <50c9a2250603042217l475e84pc9ab7ce87c40eb76@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]
(Gah... I meant this to be sent publically, not just privately ;-)
zhuzhenhua wrote:
> if in my product based ide disk, i want to it to support the
> u-disk(with vfat fs), and can i set the root fs as vfat too?
> if use vfat as rootfs, what's disadvantage of the selection?
In theory, you could... BUT... FAT32 (and every other FAT variant) lacks:
- Ownership metadata (uid/gid fields)
- Permissions (mode: read/write/execute/sticky/suid/sgid)
- Links (both hard-links and symbolic links)
... probably character devices, block devices, pipes and other numerous
devices that 99.999999% of distributions rely on.
Now, there is UMSDOS, which uses additional special files to emulate
these on top of a standard MS-DOS filesystem ... mind you, it predates
VFAT by many years, and so I'm not sure what it's support is like for
long filenames. I also haven't seen it in the kernel File System menu
for some time now.
I'd recommend using an external initrd... or an initramfs-based kernel.
That way it's just one or two files, not one or two hundred. ;-)
--
Stuart Longland (aka Redhatter) .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer '.'` :
. . . . . . . . . . . . . . . . . . . . . . .'.'
http://dev.gentoo.org/~redhatter :.'
International Asperger's Year (1906 ~ 2006)
http://dev.gentoo.org/~redhatter/iay
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [RFC] Encrypting file system
From: Mario 'BitKoenig' Holbe @ 2006-03-06 12:17 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0603061600540.16555@vattikonda.junta.iitk.ac.in>
V Bhanu Chandra <vbhanu.lkml@gmail.com> wrote:
> I am thinking of designing and implementing a new native encrypting
> file system for the linux kernel as a part of a student / research
> project. Unlike dm-crypt/loop-AES/cryptoloop, I plan to target
> slightly more ambitious user specifications such as: per-file random
> secret encryption keys which are in-turn encrypted using the public
> keys of all users having access to that filesystem object (a copy
...
> Any comments / guidance / suggestions are most welcome and solicitated.
Since you are talking about an encrypting filesystems but only
referencing encrypting block devices... Have you had a look at encfs
and/or StegFS already?
At least one of the encrypting block devices you mentioned (I don't
remember which one) already has the ability to have multiple keys.
regards
Mario
--
I have great faith in fools; self-confidence my friends call it.
-- Edgar Allan Poe
^ permalink raw reply
* Re: 2.6.16-rc5-mm2 compile error in urb.c
From: Helge Hafting @ 2006-03-06 12:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, gregkh, Tilman Schmidt
In-Reply-To: <20060306012141.5d8ca46f.akpm@osdl.org>
Andrew Morton wrote:
>Helge Hafting <helge.hafting@aitel.hist.no> wrote:
>
>
>>Compiling 2.6.16-rc5-mm2 stopped here:
>>
>> CC drivers/usb/core/urb.o
>>drivers/usb/core/urb.c: In function ___usb_alloc_urb___:
>>drivers/usb/core/urb.c:65: error: dereferencing pointer to incomplete type
>>drivers/usb/core/urb.c: In function ___usb_submit_urb___:
>>drivers/usb/core/urb.c:329: error: dereferencing pointer to incomplete type
>>make[3]: *** [drivers/usb/core/urb.o] Error 1
>>make[2]: *** [drivers/usb/core] Error 2
>>make[1]: *** [drivers/usb] Error 2
>>make: *** [drivers] Error 2
>>
>>
>>
>
>I guess this is gregkh-usb-usb-reduce-syslog-clutter.patch trying to
>dereference THIS_MODULE when the driver is being built into vmlinux. I
>suggest you revert that patch, thanks.
>
>
Thanks. Reverting this gave me a kernel that compiled and booted.
Helge Hafting
^ permalink raw reply
* Re: 4 disks: RAID-6 or RAID-10 ..
From: Gordon Henderson @ 2006-03-06 12:14 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-raid
In-Reply-To: <440B5ABF.6000702@tmr.com>
On Sun, 5 Mar 2006, Bill Davidsen wrote:
> I agree, but it's easier to configure to keep going with a dead drive
> than fan in many enclosures. You seem to have more heat tolerance and
> monitoring than many installations. And you have done testing on the
> heat issues, another unusual thing.
I got caught out a few years ago with a case-fan failing, and I've seen a
1U box almost catch-fire, so I'm very paranoid now! I'm also fortunate in
that the data centre I use allows me to host tower style PCs rather than
the usual 1 or 2U boxes, so I can build boxes with lots of room inside
that don't auto-roast on fan failure!
Although in a few months time I'll be looking to host some stuff
elsewhere, where space is at a premium, and therefore it's going to be 1
or 2U based servers, so it'll be an intersting diversion...
Cheers,
Gordon
^ permalink raw reply
* Re: [Xenomai-core] About the versioning scheme in the repository
From: Gilles Chanteperdrix @ 2006-03-06 12:13 UTC (permalink / raw)
To: Romain Lenglet; +Cc: xenomai
In-Reply-To: <200603061720.16842.rlenglet@domain.hid>
Romain Lenglet wrote:
> ...
> > > The current xenomai-svn package would then have version
> > > 2.0.93+svn20060306 (or something like that).
> >
> > Adding the atomic commit number would be useful.
>
> Good idea, that makes more sense.
Please do not forget to re-run bootstrap when modifying config/version.
--
Gilles Chanteperdrix.
^ permalink raw reply
* realtime-preempt patch-2.6.15-rt18 issues
From: Rui Nuno Capela @ 2006-03-06 12:11 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]
Hi, Ingo,
I think I would let you know that I'm still on 2.6.15-rt16, which works
great for the most purposes, on all of my boxes.
My problem is that the current/latest of the realtime-preempt patch,
2.6.15-rt18, has some showstoppers, at least for my day-to-day usage.
First one, and I think this is a return of an old buglet. Its the one that
occurs every time an usb-storage device is unplugged (e.g. a usb flash
stick). Once that happens, the usb subsystem gets seriously crippled.
Here goes a sample dmesg output of this occurrence (the complete listing
is attached, as is the corresponding kernel .config).
...
usb 2-1: new full speed USB device using ohci_hcd and address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
Vendor: USB 2.0 Model: Flash Disk Rev: 2.00
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
usb-storage: device scan complete
usb 2-1: USB disconnect, address 2
slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all
objects
[<c0144603>] kmem_cache_destroy+0x83/0xf8 (8)
[<c020b1d6>] scsi_destroy_command_freelist+0x4e/0x5a (12)
[<c020be67>] scsi_host_dev_release+0x4e/0x71 (12)
[<c01f0fef>] device_release+0x14/0x39 (12)
[<c01a2c9b>] kobject_cleanup+0x3e/0x5e (4)
[<c01a2cbb>] kobject_release+0x0/0x8 (8)
[<e05327ac>] usb_stor_control_thread+0x0/0x183 [usb_storage] (8)
[<c01a3432>] kref_put+0x3a/0x44 (4)
[<e053290e>] usb_stor_control_thread+0x162/0x183 [usb_storage] (12)
[<c027a8a1>] schedule+0xd4/0xf5 (32)
[<c01230df>] kthread+0x63/0x8f (20)
[<c012307c>] kthread+0x0/0x8f (12)
[<c0100d59>] kernel_thread_helper+0x5/0xb (16)
The second issue seems to be related to the RTC and is not strictly
specific to -rt18. AFAICT, my experience goes far as the ALSA MIDI
sequencer is concerned (snd-seq-midi) and it badly shows whenever the RTC
timer is used (snd-rtctimer), moreover if its used by default (i.e.
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y).
As it seems specific to -rt18, the ALSA sequencer event queueing is
perfectly non-functional if the RTC timer is used. On -rt16, and probably
before, the use of snd-rtctimer is suspiciously related to some complete
and instantaneous system lockups that I was experiencing more than many
times, while doing some MIDI sequencing; it always occurred almost exactly
on queue timer stop/start instants. Once I got rid of the rtctimer,
everything seems to get back to normal, that is, no hard-freezes to date.
My current configurations tries to avoid the RTC use in any circunstance.
So I think RTC is still an open issue, and it has indeed surfaced here and
there, specially regarding the RT patch usage in the Linux Audio/MIDI
niche.
Hope I can help in anyway.
Cheers,
--
rncbc aka Rui Nuno Capela
rncbc@rncbc.org
[-- Attachment #2: dmesg-2.6.15.4-rt18.1.gz --]
[-- Type: application/x-gzip-compressed, Size: 5152 bytes --]
[-- Attachment #3: config-2.6.15.4-rt18.1.gz --]
[-- Type: application/x-gzip-compressed, Size: 9785 bytes --]
^ permalink raw reply
* Re: Possible bug in serial driver 8250/8250-fourport
From: Colin Laplace @ 2006-03-06 12:04 UTC (permalink / raw)
To: malk; +Cc: linux-serial
In-Reply-To: <20060303191701.48315.qmail@sidehack.sat.gweep.net>
Hello,
Thank you for your reply. Please find my answers below :
> Did you try monitoring /proc/tty/driver/serial for the ports in question
> (byte counts in and out, and any errors (framing, parity, etc)) are in
> there, you can confirm your setserial settings there too, account for all
> bytes in and out.
The number of bytes sent to TX doesn't increase when the problem occurs.
4: uart:16550A port:0000D100 irq:177 tx:99925 rx:558 RTS|DTR
> Also -- do you have software or hardware flow control going?
> i.e. how are your tty's configured? sounds like they should be a
> raw setup -- if canonical mode or otherwise are consuming characters
> that should normally pass through to your equipment it may cause
> problems. I have no clue what protocol your music equipment speaks.
> Might be worthwhile sending your code snippet that configures your ttys
> and if hardware flow control is involved etc.
I use the following code to open and configure the serial ports :
port->fd = open(port->device, O_RDWR | O_NONBLOCK, 0);
if (port->fd < 0) {
fprintf(stderr, "Cannot open %s: ", port->device);
perror("midiseq");
return -errno;
}
cflag = B38400 | CREAD | CSIZE | CS8 | HUPCL;
if (tcgetattr(port->fd, &tio) < 0)
perror("tcgetattr");
cfmakeraw(&tio);
tio.c_lflag |= NOFLSH;
tio.c_iflag |= IGNBRK | IGNPAR;
tio.c_cflag |= cflag;
tio.c_cc[VEOL] = 0; /* '\r'; */
tio.c_cc[VERASE] = 0;
tio.c_cc[VKILL] = 0;
tio.c_cc[VMIN] = 0;
tio.c_cc[VTIME] = 0;
if (tcsetattr(port->fd, TCSANOW, &tio) < 0)
perror("tcsetattr");
> The serial and tty layer (I've found) have been very robust for a bunch
> of multiport stuff I've been doing in the last 6 months (albeit a 2.4
> kernel). The tty stuff really has to work right as a lot of stuff
> besides just serial ports are tty based (duh).
I didn't have this problem on 2.4 kernel. But for some reasons (preemptive
kernel, optimized i/o scheduling...) i need to stick with 2.6.
If you need other information please let me know.
Greetings,
Colin
> Good luck w/ your project.
>
> > Hello,
> >
> > I am writing to this list because i am now clueless on a problem i am
> > having with writing data on a serial port, and now the only thing i can
> > think of is a serial driver bug.
> > The situation is the following :
> > I have a NetMos Technology PCI 9845 Multi-I/O Controller (rev 01), which
> > has four ports. Each of its ports are connected as follow :
> > - port 1 TX connected to a Midi Chipset DREAM SAM9708 port 1
> > port 1 RX connected to FATAR midi keyboard
> > - port 2 TX connected to a Midi Chipset DREAM SAM9708 port 2
> > - port 3 connected to an external midi in/out (1)
> > - port 4 connected to an external midi in/out (2)
> >
> > This configuration has been tested on both kernel 2.6.10 with 8250
> > module, and 2.6.15 with 8250-fourport module, the problem arises on both.
> > Each of the serial ports are configured this way :
> > setserial /dev/tts/$id uart 16550A port 0x$addr irq $irq
> > ^fourport spd_cust divisor 8 low_latency
> >
> > The problem is as follow :
> > When playing MIDI data over port 1, sometimes the output just stops, the
> > data doesn't go anymore to the Dream 1 port. Then (and that's the strange
> > part), if we press a key of the FATAR keyboard (connected to the same
> > serial port but on RX), all the data that was not played comes out all of
> > a sudden, and the playback continues to be output normally. This problem
> > does *NOT* happen on any of the other serial ports, only on the one where
> > TX is connected to the dream 1 and RX to the FATAR midi keyboard.
> > I have been trying with both snd-serialmidi alsa driver, as well with a
> > homemade user-land program which drives midi events to the serial port,
> > and the problems happens on both ways. Also, very important to note : NO
> > error messages are given by write() calls when the problem arises, nor do
> > i get kernel messages.
> >
> > This situation happens very often. If you need any other information
> > please let me know. I would really appreciate any feedback you could have
> > about this matter.
> >
> > Best regards,
> > Colin Laplace
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-serial"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Longer...Harder bgdz
From: Mitzi Rowell @ 2006-03-06 11:55 UTC (permalink / raw)
To: linux-net
Suffering from short penniss?
Introduce revolution "Longz" formula which
gauranteees sizes increase or moneey baack.
Users reported:
- 2 inches extra in size
- 3x pleasurable orgasms
- 27% thicker
Why waiting?
http://thunder14.goodbiz.info
g7QDbO
^ permalink raw reply
* Longer...Harder bgdz
From: Mitzi Rowell @ 2006-03-06 11:55 UTC (permalink / raw)
To: linux-net
Suffering from short penniss?
Introduce revolution "Longz" formula which
gauranteees sizes increase or moneey baack.
Users reported:
- 2 inches extra in size
- 3x pleasurable orgasms
- 27% thicker
Why waiting?
http://thunder14.goodbiz.info
g7QDbO
^ permalink raw reply
* regarding booting 2.6.8 kernel in osk5912
From: naga rajan @ 2006-03-06 12:02 UTC (permalink / raw)
To: linux-omap-open-source
Hi all,
i am involved in "Building linux for the omap 5912 using
2.6.8.rc3" kernel.
i created uImage by following steps
*make omap_osk_5912_defconfig
make uImage*
*
* ## Booting image at 00100000 ...
Image Name: Linux-2.6.8-rc3-omap1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 857676 Bytes = 837.6 kB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux done, booting the kernel.
Then, it hung up.
can anyone over come this problem ?
^ permalink raw reply
* Re: raid5 performance question
From: Gordon Henderson @ 2006-03-06 11:59 UTC (permalink / raw)
To: Raz Ben-Jehuda(caro); +Cc: Linux RAID Mailing List
In-Reply-To: <5d96567b0603060346r768a0ee1i8d8170cf9ba4bac1@mail.gmail.com>
On Mon, 6 Mar 2006, Raz Ben-Jehuda(caro) wrote:
> Neil Hello .
> I have a performance question.
>
> I am using raid5 stripe size 1024K over 4 disks.
> I am benchmarking it with an asynchronous tester.
> This tester submits 100 IOs of size of 1024 K --> as the stripe size.
> It reads raw io from the device, no file system is involved.
>
> I am making the following comparsion:
>
> 1. Reading 4 disks at the same time using 1 MB buffer in random manner.
> 2. Reading 1 raid5 device using 1MB buffer in random manner.
>
> I am getting terrible results in scenario 2. if scenario 1 gives 120 MB/s from
> 4 disks, the raid5 device gives 35 MB/s .
> it is like i am reading a single disk , but by looking at iostat i can
> see that all
> disks are active but with low throughput.
>
> Any idea ?
Is this reading the block device direct, or via a filesystem? If the
latter, what filesystem?
If ext2/3 have you tried mkfs with a stride option?
See:
http://www.tldp.org/HOWTO/Software-RAID-HOWTO-5.html#ss5.11
Gordon
^ permalink raw reply
* Re: [PATCH 00/11] reiserfs: xattr rework
From: Jan Kara @ 2006-03-06 11:59 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: ReiserFS List, E. Gryaznova
In-Reply-To: <4408C080.4070600@suse.com>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jan Kara wrote:
> >> The data journaling mode can be set as a flag associated with the inode.
> >> Currently, i_data_log is set in REISERFS_I(inode)->i_flags. I add
> >> i_data_ordered in one of my later patches. They can be tested easily
> >> with reiserfs_file_data_{log,ordered}. There's no reason that one
> >> couldn't be moved up and made a prerequisite for the first patch.
> > Fine. So we can just set proper journaling flags in reiserfs_quota_on
> > and then honor them in the internal writing functions.
>
> Ok, how do the attached patches look to you? The internal I/O changes
> need to be applied after the journaled xattr patch or we get an Oops
> trying to start a transaction without calling reiserfs_write_lock()
> first. I've modified the first patch in the xattr series to abstract out
> the fp->f_op->{read,write} calls to an xattr_{read,write} pair of
> functions. This makes it easier to move to the internal i/o code later.
> I've included it for clarity, but that is the only change.
The patch looks fine. Just two minor comments:
<snip>
> diff -ruNpX ../dontdiff linux-2.6.15-staging1/fs/reiserfs/super.c linux-2.6.15-staging2/fs/reiserfs/super.c
> --- linux-2.6.15-staging1/fs/reiserfs/super.c 2006-03-03 17:09:01.000000000 -0500
> +++ linux-2.6.15-staging2/fs/reiserfs/super.c 2006-03-03 17:09:04.000000000 -0500
> @@ -1949,6 +1949,109 @@ static int reiserfs_statfs(struct super_
> return 0;
> }
>
> +#if defined(CONFIG_QUOTA) || defined(CONFIG_REISERFS_FS_XATTR)
> +/* Read data from quotafile - avoid pagecache and such because we cannot afford
> + * acquiring the locks... As quota files are never truncated and quota code
> + * itself serializes the operations (and noone else should touch the files)
> + * we don't have to be afraid of races */
Update here the comment to reflect that we use this function also for
xattrs now - I suppose those files cannot be truncated either and that
xattr code serializes the operations there.
> +ssize_t reiserfs_internal_read(struct inode *inode, char *data, size_t len,
> + loff_t off)
<snip>
> +/* Write to quotafile (we know the transaction is already started and has
> + * enough credits) */
Here again update the comment...
> +ssize_t reiserfs_internal_write(struct inode *inode, const char *data,
> + size_t len, loff_t off)
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
^ permalink raw reply
* Odd start of the day memory layout
From: Mathieu Ropert @ 2006-03-06 11:59 UTC (permalink / raw)
To: xen-devel
Hi,
i found myself in presence of an odd start of the day memory layout
using Xen 3.0.1 testing on x86-64.
Quoting from <public/xen.h>:
" * 4. This the order of bootstrap elements in the initial virtual region:
* a. relocated kernel image
* b. initial ram disk [mod_start, mod_len]
* c. list of allocated page frames [mfn_list, nr_pages]
* d. bootstrap page tables [pt_base, CR3 (x86)]
* e. start_info_t structure [register ESI (x86)]
* f. bootstrap stack [register ESP (x86)]"
But when i run my domU kernel (homemade), i found myself with start_info
struct BETWEEN pt_base and end of page tables (pt_base + (nr_pt_frames
<< PAGE_SHIFT).
Is it intended?
Regards,
Mathieu
^ permalink raw reply
* Re: Coverity Open Source Defect Scan of Linux
From: Gene Heskett @ 2006-03-06 11:57 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <440C16E4.4050303@stud.feec.vutbr.cz>
On Monday 06 March 2006 06:03, Michal Schmidt wrote:
>Bernd Petrovitsch wrote:
>> > > analysis back to the developers of those projects. Linux is one
>> > > of the
>>
>> ^^^^^
>> should have been "The Linux kernel"
>
>Why? Are you afraid of confusion with Linux the washing powder?
>
If there is indeed a linux washing powder, where might it be obtained?
I get a bad case of contact dermatitus when I use the regular stuff from
M$.
>Michal
>-
>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/
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply
* [KJ][Patch] remove request_region from matroxfb_base.c
From: Darren Jenkins\ @ 2006-03-06 11:57 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
G'day list
matroxfb_base.c calles request_region() without checking it's return
value @ 1737.
After getting advice from Petr Vandrovec it seems that this memory
region isn't actually used in matroxfb_base.c, it was just reserved to
stop vesafb and matrox being loaded on the same head. After looking at
vesafb.c is seems that this doesn't work, as vesafb doesn't check the
return value of request_region either.
So the patch below removes the request_region call because it doesn't
actually do anything anymore.
Thanks again for your explanation Petr.
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
--- linux-2.6.16-rc5/drivers/video/matrox/matroxfb_base.c.orig 2006-03-06 21:36:54.000000000 +1100
+++ linux-2.6.16-rc5/drivers/video/matrox/matroxfb_base.c 2006-03-06 22:42:17.000000000 +1100
@@ -1733,8 +1733,6 @@ static int initMatrox2(WPMINFO struct bo
}
#endif /* CONFIG_MTRR */
- if (!ACCESS_FBINFO(devflags.novga))
- request_region(0x3C0, 32, "matrox");
matroxfb_g450_connect(PMINFO2);
ACCESS_FBINFO(hw_switch->reset(PMINFO2));
[-- Attachment #2: Type: text/plain, Size: 168 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Re: [PATCH 0/5] Permit NFS superblock sharing [try #3]
From: David Howells @ 2006-03-06 11:55 UTC (permalink / raw)
To: Andrew Morton
Cc: David Howells, torvalds, steved, trond.myklebust, aviro,
linux-fsdevel, linux-cachefs, nfsv4, linux-kernel
In-Reply-To: <20060304041647.6894ca62.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
> The same happens with just #1 and #2 applied. The .config is at
> http://www.zip.com.au/~akpm/linux/patches/stuff/config-vmm.
Just #1 and #2? That's decidedly odd.
Also odd is that it's _nfsd_ that's affected, not nfs. It also affects
binfmt_misc, so it appears that it's something to do with get_sb_single(), and
looking at that function, I can sort of see why it might be. I'll look into it further.
> The kernel won't compile with just patch #1 applied. Patches shouldn't go
> into git in that manner.
It's easier to review them in that manner. If you don't think git is up to it,
then combine them.
David
^ permalink raw reply
* Re: [PATCH] Busy inodes after unmount, be more verbose in generic_shutdown_super
From: Jan Blunck @ 2006-03-06 11:56 UTC (permalink / raw)
To: Neil Brown
Cc: linux-kernel, Andrew Morton, Olaf Hering, Kirill Korotaev,
Al Viro
In-Reply-To: <17419.53761.295044.78549@cse.unsw.edu.au>
On Mon, Mar 06, Neil Brown wrote:
> On Thursday March 2, neilb@suse.de wrote:
> >
> >
> > Hi,
> > This mail relates to the thread with the same subject which can be
> > found at
> >
> > http://lkml.org/lkml/2006/1/16/279
> >
> > I would like to propose an alternate patch for the problem.
> ....
> >
> > Comments? Please :-?
>
> Somewhere in among the comments (thanks), I realised that I was only
> closing half the race. I had tried to make sure there were no stray
> references to any dentries, but there is still the inode which is
> being iput which can cause problem.
>
> The following patch takes a totally different approach, is based on an
> idea from Jan Kara, and is much less intrusive.
>
> We:
> - keep track of "who" is calling prune_dcache, and when a filesystem
> is being unmounted (s_root == NULL) we only allow the unmount thread
> to prune dentries.
> - keep track of how many dentries are in the process of having
> dentry_iput called on them for pruning
> - don't allow umount to proceed until that count hits zero
> - bias the count this way and that to make sure we get a wake_up at
> the right time
> - reuse 's_wait_unfrozen' to wait on the iput to complete.
>
> Again, I'm very keen on feedback. This race is very hard to trigger,
> so code review is the only real way to evaluate that patch.
>
Just ask Olaf. Afaik he was the one who triggered it frequently.
This are two different problems which you adress with this and your first
patch. This one is to prevent busy inodes on umouny, the first one was to get
the reference counting on dentries right.
Neil, did you actually read my patch for this one?!
http://marc.theaimsgroup.com/?l=linux-kernel&m=114123870406751&w=2
> diff ./fs/super.c~current~ ./fs/super.c
> --- ./fs/super.c~current~ 2006-03-06 16:54:59.000000000 +1100
> +++ ./fs/super.c 2006-03-06 16:57:19.000000000 +1100
> @@ -230,7 +230,18 @@ void generic_shutdown_super(struct super
> struct super_operations *sop = sb->s_op;
>
> if (root) {
> + spin_lock(&dcache_lock);
> + /* disable stray dputs */
> sb->s_root = NULL;
> +
> + /* trigger a wake_up */
> + sb->s_pending_iputs --;
> + spin_unlock(&dcache_lock);
> + wait_event(sb->s_wait_unfrozen,
> + sb->s_pending_iputs < 0);
> + /* avoid further wakeups */
> + sb->s_pending_iputs = 65000;
> +
> shrink_dcache_parent(root);
> shrink_dcache_anon(&sb->s_anon);
> dput(root);
>
What I don't like, is that you are serializing the work of shrink_dcache_*
although they could work in parallel on different processors.
Regards,
Jan
--
Jan Blunck jblunck@suse.de
SuSE LINUX AG - A Novell company
Maxfeldstr. 5 +49-911-74053-608
D-90409 Nürnberg http://www.suse.de
^ permalink raw reply
* Longer...Harder bgdz
From: Mitzi Rowell @ 2006-03-06 11:55 UTC (permalink / raw)
To: linux-net
Suffering from short penniss?
Introduce revolution "Longz" formula which
gauranteees sizes increase or moneey baack.
Users reported:
- 2 inches extra in size
- 3x pleasurable orgasms
- 27% thicker
Why waiting?
http://thunder14.goodbiz.info
g7QDbO
^ permalink raw reply
* Re: [PATCH] Busy inodes after unmount, be more verbose in generic_shutdown_super
From: Kirill Korotaev @ 2006-03-06 11:56 UTC (permalink / raw)
To: Neil Brown
Cc: linux-kernel, Andrew Morton, Olaf Hering, Jan Blunck,
Kirill Korotaev, Al Viro
In-Reply-To: <17419.53761.295044.78549@cse.unsw.edu.au>
>>Comments? Please :-?
ok :) see inline.
> Somewhere in among the comments (thanks), I realised that I was only
> closing half the race. I had tried to make sure there were no stray
> references to any dentries, but there is still the inode which is
> being iput which can cause problem.
>
> The following patch takes a totally different approach, is based on an
> idea from Jan Kara, and is much less intrusive.
>
> We:
> - keep track of "who" is calling prune_dcache, and when a filesystem
> is being unmounted (s_root == NULL) we only allow the unmount thread
> to prune dentries.
> - keep track of how many dentries are in the process of having
> dentry_iput called on them for pruning
> - don't allow umount to proceed until that count hits zero
> - bias the count this way and that to make sure we get a wake_up at
> the right time
> - reuse 's_wait_unfrozen' to wait on the iput to complete.
>
> Again, I'm very keen on feedback. This race is very hard to trigger,
> so code review is the only real way to evaluate that patch.
hmm... It's not that very hard. I suppose no one ever tried except us.
We have a test which does mounts/umounts and lots of other activity
which makes memory pressure. AFAIR, it takes us ~3 hours to trigger this
bug on SMP.
In general your patch is still does what mine do, so I will be happy if
any of this is commited mainstream. In future, please, keep the
reference to original authors, this will also make sure that I'm on CC
if something goes wrong.
Thanks,
Kiril
> Signed-off-by: Neil Brown <neilb@suse.de>
>
> ### Diffstat output
> ./fs/dcache.c | 17 +++++++++++++----
> ./fs/super.c | 11 +++++++++++
> ./include/linux/fs.h | 2 ++
> 3 files changed, 26 insertions(+), 4 deletions(-)
>
> diff ./fs/dcache.c~current~ ./fs/dcache.c
> --- ./fs/dcache.c~current~ 2006-03-06 16:54:59.000000000 +1100
> +++ ./fs/dcache.c 2006-03-06 16:55:33.000000000 +1100
> @@ -366,6 +366,7 @@ static inline void prune_one_dentry(stru
> {
> struct dentry * parent;
>
> + dentry->d_sb->s_pending_iputs ++;
> __d_drop(dentry);
> list_del(&dentry->d_u.d_child);
> dentry_stat.nr_dentry--; /* For d_free, below */
> @@ -375,6 +376,9 @@ static inline void prune_one_dentry(stru
> if (parent != dentry)
> dput(parent);
> spin_lock(&dcache_lock);
> + dentry->d_sb->s_pending_iputs --;
> + if (dentry->d_sb->s_pending_iputs < 0)
> + wake_up(&dentry->d_sb->s_wait_unfrozen);
> }
>
> /**
> @@ -390,7 +394,7 @@ static inline void prune_one_dentry(stru
> * all the dentries are in use.
> */
>
> -static void prune_dcache(int count)
> +static void prune_dcache(int count, struct dentry *parent)
> {
> spin_lock(&dcache_lock);
> for (; count ; count--) {
> @@ -407,6 +411,11 @@ static void prune_dcache(int count)
> dentry_stat.nr_unused--;
> dentry = list_entry(tmp, struct dentry, d_lru);
>
> + if (dentry->d_sb->s_root == NULL &&
> + (parent == NULL ||
> + parent->d_sb != dentry->d_sb))
> + continue;
<<<<
- we select some dentries in select_parent and then try to prune N
dentries. But this can be other N dentries :/ It's not the problem with
your code, but... adding 'parent' arg to prune_dcache() makes me feel
the same as with 'found' arg: you don't use it actually right way. You
don't prune only its children, you see? It is better to pass 'sb' arg then.
> +
> spin_lock(&dentry->d_lock);
> /*
> * We found an inuse dentry which was not removed from
> @@ -635,7 +644,7 @@ void shrink_dcache_parent(struct dentry
> int found;
>
> while ((found = select_parent(parent)) != 0)
> - prune_dcache(found);
> + prune_dcache(found, parent);
> }
>
> /**
> @@ -673,7 +682,7 @@ void shrink_dcache_anon(struct hlist_hea
> }
> }
> spin_unlock(&dcache_lock);
> - prune_dcache(found);
> + prune_dcache(found, NULL);
> } while(found);
> }
>
> @@ -694,7 +703,7 @@ static int shrink_dcache_memory(int nr,
> if (nr) {
> if (!(gfp_mask & __GFP_FS))
> return -1;
> - prune_dcache(nr);
> + prune_dcache(nr, NULL);
> }
> return (dentry_stat.nr_unused / 100) * sysctl_vfs_cache_pressure;
> }
>
> diff ./fs/super.c~current~ ./fs/super.c
> --- ./fs/super.c~current~ 2006-03-06 16:54:59.000000000 +1100
> +++ ./fs/super.c 2006-03-06 16:57:19.000000000 +1100
> @@ -230,7 +230,18 @@ void generic_shutdown_super(struct super
> struct super_operations *sop = sb->s_op;
>
> if (root) {
> + spin_lock(&dcache_lock);
> + /* disable stray dputs */
> sb->s_root = NULL;
> +
> + /* trigger a wake_up */
> + sb->s_pending_iputs --;
> + spin_unlock(&dcache_lock);
> + wait_event(sb->s_wait_unfrozen,
> + sb->s_pending_iputs < 0);
> + /* avoid further wakeups */
> + sb->s_pending_iputs = 65000;
<<< its ulgy... :( why don't you do wait after shrink's and dput(root)
below?
> +
> shrink_dcache_parent(root);
> shrink_dcache_anon(&sb->s_anon);
> dput(root);
>
> diff ./include/linux/fs.h~current~ ./include/linux/fs.h
> --- ./include/linux/fs.h~current~ 2006-03-06 16:54:59.000000000 +1100
> +++ ./include/linux/fs.h 2006-03-06 12:49:55.000000000 +1100
> @@ -833,6 +833,8 @@ struct super_block {
> struct hlist_head s_anon; /* anonymous dentries for (nfs) exporting */
> struct list_head s_files;
>
> + int s_pending_iputs;
> +
> struct block_device *s_bdev;
> struct list_head s_instances;
> struct quota_info s_dquot; /* Diskquota specific options */
>
^ permalink raw reply
* [U-Boot-Users] does someone add YAFFS2 support in uboot?
From: Wolfgang Denk @ 2006-03-06 11:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <50c9a2250603060308t3f7e4c35w37ed5362f9b8006e@mail.gmail.com>
In message <50c9a2250603060308t3f7e4c35w37ed5362f9b8006e@mail.gmail.com> you wrote:
>
> if put the kernel in a sperate partition, i think it may waste some
> space, because you must keep the partition larger than the size of
> kernel.
Yes, you may lose a few 100 kB. But you get a lot of additionally
flexibility (like being able to update kernel and root file system
independently from each other). And if your system does not allow for
100 or 200 kB now when you start designing the system you have MAJOR
problems anyway as your application software will need MUCH more
reserve.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Just about every computer on the market today runs Unix, except the
Mac (and nobody cares about it). - Bill Joy 6/21/85
^ permalink raw reply
* raid5 performance question
From: Raz Ben-Jehuda(caro) @ 2006-03-06 11:46 UTC (permalink / raw)
To: Linux RAID Mailing List; +Cc: Neil Brown
Neil Hello .
I have a performance question.
I am using raid5 stripe size 1024K over 4 disks.
I am benchmarking it with an asynchronous tester.
This tester submits 100 IOs of size of 1024 K --> as the stripe size.
It reads raw io from the device, no file system is involved.
I am making the following comparsion:
1. Reading 4 disks at the same time using 1 MB buffer in random manner.
2. Reading 1 raid5 device using 1MB buffer in random manner.
I am getting terrible results in scenario 2. if scenario 1 gives 120 MB/s from
4 disks, the raid5 device gives 35 MB/s .
it is like i am reading a single disk , but by looking at iostat i can
see that all
disks are active but with low throughput.
Any idea ?
Thank you.
--
Raz
^ permalink raw reply
* [lm-sensors] [PATCH 1/1] i2c: m41txx driver for ST i2c RTC chips
From: Jean Delvare @ 2006-03-06 11:45 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20060217011359.GA16247@mag.az.mvista.com>
Hi Mark, Rudolf,
First of all, Mark, I'm very sorry I did not reply earlier, as you're
always doing such a good job. I'm just too busy with many other stuff
:( and I need to take some time for myself from times to times too.
I see that Rudolf has been reviewing your code, thanks Rudolf.
> > Thanks for taking the time to look at it.
>
> Lets wait when Jean will have some little time to look into it.
I won't have the time to review it completely, but I'd just have one
question/suggestion: Mark, why did you rename the driver from m41t00 to
m41txx? I understand that the driver now supports more than one device,
but almost all our i2c and hwmon drivers so, and we still usually stick
to the name of the first supported device. This works just fine.
The problem I see with the renaming is that it makes reviewing the
changes much more difficult. As a matter of fact, I did not review your
patch, in part for that reason :( Then it can confuse some source
control systems (such as quilt, which I use) or at least make them less
convenient to use.
It'll also make things harder for the users (they may need to update
some configuration files, which won't be compatible between old and new
kernels.) Last, I doubt that your driver actually covers all 100 devices
from m41t00 to m41t99 ;) and if any of these chips isn't compatible
enough to be supported by your driver, you'll be in trouble to find a
name for the new driver...
So I'd suggest that you do not rename the driver, it it's not too late.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: crash / kernel 2.6.15.3 / reiserfs 3.6 (bugreport)
From: Vitaly Fertman @ 2006-03-06 11:45 UTC (permalink / raw)
To: reiserfs-list; +Cc: zotyalpb
In-Reply-To: <123901c63fd3$280cba90$0301a8c0@foobar>
On Sunday 05 March 2006 00:32, zotyalpb wrote:
> Hi
>
> I have an amd64 box with debian/sarge.
> it has two reiserfs, one for the root (sda1 - 36G), and one for home (md0 -
> 500G / raid10).
>
> Since a week it randomly crashes. I got reiserfs panic in the syslog, and
> the md0 is not responding, but the sda is working fine.
> I have to reboot to make it working again.
would you run reiserfsck on md0 please?
it looks like an fs corruption.
> Mar 4 18:04:38 free kernel: REISERFS: panic (device Null superblock):
> vs-8025: set_entry_sizes: (mode==p, insert_size==56), invalid length of
> directory item
> Mar 4 18:04:38 free kernel: ----------- [cut here ] --------- [please bite
> here ] ---------
> Mar 4 18:04:38 free kernel: Kernel BUG at fs/reiserfs/prints.c:362
> Mar 4 18:04:38 free kernel: invalid operand: 0000 [1] SMP
> Mar 4 18:04:38 free kernel: CPU 0
> Mar 4 18:04:39 free kernel: Modules linked in: nfs nfsd exportfs lockd
> sunrpc iptable_filter ip_tables 8250 serial_core generic i2c_nforce2 dm_mod
> w83627hf hwmon_vid i2c_isa 3c59x sata_sil
> Mar 4 18:04:39 free kernel: Pid: 962, comm: convert Not tainted 2.6.15.3 #5
> Mar 4 18:04:39 free kernel: RIP: 0010:[reiserfs_panic+193/234]
> <ffffffff801c8547>{reiserfs_panic+193}
> Mar 4 18:04:39 free kernel: RSP: 0018:ffff810021147638 EFLAGS: 00010296
> Mar 4 18:04:39 free kernel: RAX: 0000000000000087 RBX: ffffffff80362ca7
> RCX: ffffffff803d5768
> Mar 4 18:04:39 free kernel: RDX: ffffffff803d5768 RSI: 0000000000000246
> RDI: ffffffff803d5760
> Mar 4 18:04:39 free kernel: RBP: 0000000000000108 R08: ffffffff803d5768
> R09: 0000000000000000
> Mar 4 18:04:39 free kernel: R10: 0000000100000000 R11: 0000000000000246
> R12: 0000000000000000
> Mar 4 18:04:39 free kernel: R13: 0000000000000240 R14: 0000000000000001
> R15: ffff81004aea2d40
> Mar 4 18:04:39 free kernel: FS: 00002aaaacac3170(0000)
> GS:ffffffff8048c800(0000) knlGS:0000000000000000
> Mar 4 18:04:39 free kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> Mar 4 18:04:39 free kernel: CR2: 00002aaaaad51090 CR3: 000000001be9d000
> CR4: 00000000000006e0
> Mar 4 18:04:39 free kernel: Process convert (pid: 962, threadinfo
> ffff810021146000, task ffff81001a2487b0)
> Mar 4 18:04:39 free kernel: Stack: 0000003000000020 ffff810021147728
> ffff810021147658 0000000000000000
> Mar 4 18:04:39 free kernel: ffff81007e3e9800 ffffffff801d47a6
> 0000000000000070 0000000000000038
> Mar 4 18:04:39 free kernel: 0000000000011020 0000000000011008
> Mar 4 18:04:39 free kernel: Call Trace:<ffffffff801d47a6>{get_cnode+24}
> <ffffffff801ca6d7>{leaf_copy_items_entirely+1011}
> Mar 4 18:04:39 free kernel: <ffffffff801d47a6>{get_cnode+24}
> <ffffffff801d85a8>{journal_mark_dirty+373}
> Mar 4 18:04:39 free kernel:
> <ffffffff801cc6f1>{leaf_delete_items_entirely+565}
> <ffffffff801da9d6>{direntry_create_vi+480}
> Mar 4 18:04:39 free kernel:
> <ffffffff801c084d>{create_virtual_node+817}
> <ffffffff801c279a>{ip_check_balance+839}
> Mar 4 18:04:39 free kernel: <ffffffff801c447b>{fix_nodes+547}
> <ffffffff801d2fb7>{reiserfs_paste_into_item+301}
> Mar 4 18:04:39 free kernel:
> <ffffffff801b75e1>{reiserfs_add_entry+781}
> <ffffffff801bbd5c>{reiserfs_new_inode+1274}
> Mar 4 18:04:39 free kernel:
> <ffffffff801dd77b>{__reiserfs_permission+373}
> <ffffffff801b78f8>{reiserfs_create+346}
> Mar 4 18:04:39 free kernel: <ffffffff8017f1ec>{vfs_create+225}
> <ffffffff8017f5c3>{open_namei+383}
> Mar 4 18:04:39 free kernel: <ffffffff8017050f>{filp_open+26}
> <ffffffff80170693>{get_unused_fd+108}
> Mar 4 18:04:39 free kernel: <ffffffff80170804>{do_sys_open+59}
> <ffffffff8010d76a>{system_call+126}
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel: Code: 0f 0b 68 70 32 36 80 c2 6a 01 48 c7 c7 e0
> f6 36 80 4d 85 e4
> Mar 4 18:04:39 free kernel: RIP <ffffffff801c8547>{reiserfs_panic+193} RSP
> <ffff810021147638>
> Mar 4 18:04:39 free kernel: Badness in do_exit at kernel/exit.c:796
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel: Call Trace:<ffffffff801329cd>{do_exit+75}
> <ffffffff8010f20b>{die_nmi+0}
> Mar 4 18:04:39 free kernel: <ffffffff8010f58f>{do_invalid_op+145}
> <ffffffff801c8547>{reiserfs_panic+193}
> Mar 4 18:04:39 free kernel: <ffffffff801305a3>{printk+141}
> <ffffffff8010e4a5>{error_exit+0}
> Mar 4 18:04:39 free kernel: <ffffffff801c8547>{reiserfs_panic+193}
> <ffffffff801c8547>{reiserfs_panic+193}
> Mar 4 18:04:39 free kernel: <ffffffff801d47a6>{get_cnode+24}
> <ffffffff801ca6d7>{leaf_copy_items_entirely+1011}
> Mar 4 18:04:39 free kernel: <ffffffff801d47a6>{get_cnode+24}
> <ffffffff801d85a8>{journal_mark_dirty+373}
> Mar 4 18:04:39 free kernel:
> <ffffffff801cc6f1>{leaf_delete_items_entirely+565}
> <ffffffff801da9d6>{direntry_create_vi+480}
> Mar 4 18:04:39 free kernel:
> <ffffffff801c084d>{create_virtual_node+817}
> <ffffffff801c279a>{ip_check_balance+839}
> Mar 4 18:04:39 free kernel: <ffffffff801c447b>{fix_nodes+547}
> <ffffffff801d2fb7>{reiserfs_paste_into_item+301}
> Mar 4 18:04:39 free kernel:
> <ffffffff801b75e1>{reiserfs_add_entry+781}
> <ffffffff801bbd5c>{reiserfs_new_inode+1274}
> Mar 4 18:04:39 free kernel:
> <ffffffff801dd77b>{__reiserfs_permission+373}
> <ffffffff801b78f8>{reiserfs_create+346}
> Mar 4 18:04:39 free kernel: <ffffffff8017f1ec>{vfs_create+225}
> <ffffffff8017f5c3>{open_namei+383}
> Mar 4 18:04:39 free kernel: <ffffffff8017050f>{filp_open+26}
> <ffffffff80170693>{get_unused_fd+108}
> Mar 4 18:04:39 free kernel: <ffffffff80170804>{do_sys_open+59}
> <ffffffff8010d76a>{system_call+126}
> Mar 4 18:04:39 free kernel:
> Mar 4 18:04:39 free kernel: ReiserFS: sda1: warning: clm-2100: nesting info
> a different FS
>
> ...
>
> Mar 4 22:32:38 free kernel: REISERFS: panic (device Null superblock):
> vs-8025: set_entry_sizes: (mode==p, insert_size==32), invalid length of
> directory item
> Mar 4 22:32:38 free kernel: ----------- [cut here ] --------- [please bite
> here ] ---------
> Mar 4 22:32:38 free kernel: Kernel BUG at fs/reiserfs/prints.c:362
> Mar 4 22:32:38 free kernel: invalid operand: 0000 [1] SMP
> Mar 4 22:32:38 free kernel: CPU 0
> Mar 4 22:32:38 free kernel: Modules linked in: nfs nfsd exportfs lockd
> sunrpc iptable_filter ip_tables 8250 serial_core generic i2c_nforce2 dm_mod
> w83627hf hwmon_vid i2c_isa 3c59x sata_sil
> Mar 4 22:32:38 free kernel: Pid: 31265, comm: apache Not tainted 2.6.15.3
> #5
> Mar 4 22:32:38 free kernel: RIP: 0010:[reiserfs_panic+193/234]
> <ffffffff801c8547>{reiserfs_panic+193}
> Mar 4 22:32:38 free kernel: RSP: 0018:ffff81006717b238 EFLAGS: 00010296
> Mar 4 22:32:38 free kernel: RAX: 0000000000000087 RBX: ffffffff80362ca7
> RCX: ffffffff803d5768
> Mar 4 22:32:38 free kernel: RDX: ffffffff803d5768 RSI: 0000000000000246
> RDI: ffffffff803d5760
> Mar 4 22:32:38 free kernel: RBP: 0000000000000108 R08: ffffffff803d5768
> R09: 0000000000000000
> Mar 4 22:32:38 free kernel: R10: 0000000100000000 R11: 0000000000000246
> R12: 0000000000000000
> Mar 4 22:32:38 free kernel: R13: 0000000000000240 R14: 0000000000000001
> R15: ffff810040e3a1e8
> Mar 4 22:32:38 free kernel: FS: 00002aaaab5d3a40(0000)
> GS:ffffffff8048c800(0000) knlGS:0000000000000000
> Mar 4 22:32:38 free kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 000000008005003b
> Mar 4 22:32:38 free kernel: CR2: 00002aaaafb61000 CR3: 000000006cea5000
> CR4: 00000000000006e0
> Mar 4 22:32:38 free kernel: Process apache (pid: 31265, threadinfo
> ffff81006717a000, task ffff81003d84e240)
> Mar 4 22:32:38 free kernel: Stack: 0000003000000020 ffff81006717b328
> ffff81006717b258 ffff81006574d018
> Mar 4 22:32:38 free kernel: ffff8100255df018 0000000000000001
> 0000000000000070 0000000000000020
> Mar 4 22:32:38 free kernel: 0000000000011008 0000000000010ff0
> Mar 4 22:32:38 free kernel: Call
> Trace:<ffffffff801d85a8>{journal_mark_dirty+373}
> <ffffffff801cc464>{leaf_cut_from_buffer+1271}
> Mar 4 22:32:38 free kernel:
> <ffffffff801da9d6>{direntry_create_vi+480}
> <ffffffff801c084d>{create_virtual_node+817}
> Mar 4 22:32:38 free kernel: <ffffffff801c279a>{ip_check_balance+839}
> <ffffffff801b5b94>{balance_leaf+10822}
> Mar 4 22:32:38 free kernel: <ffffffff801c447b>{fix_nodes+547}
> <ffffffff801d2fb7>{reiserfs_paste_into_item+301}
> Mar 4 22:32:38 free kernel:
> <ffffffff801b75e1>{reiserfs_add_entry+781}
> <ffffffff80143896>{autoremove_wake_function+0}
> Mar 4 22:32:38 free kernel: <ffffffff801b8a56>{reiserfs_rename+489}
> <ffffffff80173530>{bh_lru_install+217}
> Mar 4 22:32:38 free kernel: <ffffffff8015aced>{activate_page+154}
> <ffffffff80143922>{wake_up_bit+14}
> Mar 4 22:32:38 free kernel: <ffffffff801d0304>{search_by_key+4205}
> <ffffffff80180ca3>{vfs_rename_other+196}
> Mar 4 22:32:38 free kernel: <ffffffff8018101c>{vfs_rename+803}
> <ffffffff80181294>{sys_rename+377}
> Mar 4 22:32:38 free kernel: <ffffffff8010d76a>{system_call+126}
> Mar 4 22:32:38 free kernel:
> Mar 4 22:32:38 free kernel: Code: 0f 0b 68 70 32 36 80 c2 6a 01 48 c7 c7 e0
> f6 36 80 4d 85 e4
> Mar 4 22:32:38 free kernel: RIP <ffffffff801c8547>{reiserfs_panic+193} RSP
> <ffff81006717b238>
> Mar 4 22:32:38 free kernel: Badness in do_exit at kernel/exit.c:796
> Mar 4 22:32:38 free kernel:
> Mar 4 22:32:38 free kernel: Call Trace:<ffffffff801329cd>{do_exit+75}
> <ffffffff8010f20b>{die_nmi+0}
> Mar 4 22:32:38 free kernel: <ffffffff8010f58f>{do_invalid_op+145}
> <ffffffff801c8547>{reiserfs_panic+193}
> Mar 4 22:32:38 free kernel: <ffffffff80152ff6>{mempool_alloc+42}
> <ffffffff80296460>{ata_scsi_rw_xlat+0}
> Mar 4 22:32:38 free kernel: <ffffffff801305a3>{printk+141}
> <ffffffff8010e4a5>{error_exit+0}
> Mar 4 22:32:38 free kernel: <ffffffff801c8547>{reiserfs_panic+193}
> <ffffffff801c8547>{reiserfs_panic+193}
> Mar 4 22:32:38 free kernel:
> <ffffffff801d85a8>{journal_mark_dirty+373}
> <ffffffff801cc464>{leaf_cut_from_buffer+1271}
> Mar 4 22:32:38 free kernel:
> <ffffffff801da9d6>{direntry_create_vi+480}
> <ffffffff801c084d>{create_virtual_node+817}
> Mar 4 22:32:38 free kernel: <ffffffff801c279a>{ip_check_balance+839}
> <ffffffff801b5b94>{balance_leaf+10822}
> Mar 4 22:32:38 free kernel: <ffffffff801c447b>{fix_nodes+547}
> <ffffffff801d2fb7>{reiserfs_paste_into_item+301}
> Mar 4 22:32:38 free kernel:
> <ffffffff801b75e1>{reiserfs_add_entry+781}
> <ffffffff80143896>{autoremove_wake_function+0}
> Mar 4 22:32:38 free kernel: <ffffffff801b8a56>{reiserfs_rename+489}
> <ffffffff80173530>{bh_lru_install+217}
> Mar 4 22:32:38 free kernel: <ffffffff8015aced>{activate_page+154}
> <ffffffff80143922>{wake_up_bit+14}
> Mar 4 22:32:38 free kernel: <ffffffff801d0304>{search_by_key+4205}
> <ffffffff80180ca3>{vfs_rename_other+196}
> Mar 4 22:32:38 free kernel: <ffffffff8018101c>{vfs_rename+803}
> <ffffffff80181294>{sys_rename+377}
> Mar 4 22:32:38 free kernel: <ffffffff8010d76a>{system_call+126}
> Mar 4 22:32:38 free kernel: ReiserFS: sda1: warning: clm-2100: nesting info
> a different FS
>
>
>
> sincerely,
> zotyalpb
>
>
>
--
Vitaly
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.