* 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
@ 2003-10-28 15:49 lkml-031028
2003-10-28 18:36 ` Hans Reiser
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: lkml-031028 @ 2003-10-28 15:49 UTC (permalink / raw)
To: linux-kernel
[1.] One line summary of the problem:
First time boot of 2.6.0test9 on a resierfs disk gives the error above.
(buffer layer error at fs/buffer.c:431)
[2.] Full description of the problem/report:
Compile kernel 2.6.0 test 9 from the Debian "unstable" package using
make-kpkg.
I have a single-filesystem 76Gb ResierFs filesystem. (reports as
"ReiserFS 3.6").
I usually run a customized 2.4.22 with debian patches and the preemptive
kernel patch.
First time I boot the 2.6.0 kernel I got the message quoted above,
The message repated twice in a row. Both instance seem itentical to
me. The message with the stack trace is copied as-is from the
output of dmesg below:
buffer layer error at fs/buffer.c:431
Call Trace:
[<c014f2b5>] __find_get_block_slow+0x85/0x120
[<c0150283>] __find_get_block+0x83/0xe0
[<c015030b>] __getblk+0x2b/0x60
[<c01503bf>] __bread+0x1f/0x40
[<c01a2132>] read_super_block+0x82/0x210
[<c01a2d95>] reiserfs_fill_super+0x555/0x5a0
[<c01d69b7>] snprintf+0x27/0x30
[<c017bce2>] disk_name+0x62/0xb0
[<c0154bc5>] sb_set_blocksize+0x25/0x60
[<c0154594>] get_sb_bdev+0x124/0x160
[<c01a2e4f>] get_super_block+0x2f/0x60
[<c01a2840>] reiserfs_fill_super+0x0/0x5a0
[<c01547ff>] do_kern_mount+0x5f/0xe0
[<c01695c8>] do_add_mount+0x78/0x150
[<c01698b4>] do_mount+0x124/0x170
[<c0169720>] copy_mount_options+0x80/0xf0
[<c0169c6f>] sys_mount+0xbf/0x140
[<c0462b9f>] do_mount_root+0x2f/0xa0
[<c0462c64>] mount_block_root+0x54/0x120
[<c0462d8e>] mount_root+0x5e/0x70
[<c0462dbd>] prepare_namespace+0x1d/0xe0
[<c01050d2>] init+0x32/0x160
[<c01050a0>] init+0x0/0x160
[<c01070c9>] kernel_thread_helper+0x5/0xc
block=16, b_blocknr=64
b_state=0x00000019, b_size=1024
buffer layer error at fs/buffer.c:431
Call Trace:
[<c014f2b5>] __find_get_block_slow+0x85/0x120
[<c01070c9>] kernel_thread_helper+0x5/0xc
[<c010970c>] dump_stack+0x1c/0x20
[<c0150283>] __find_get_block+0x83/0xe0
[<c014fec3>] __getblk_slow+0x23/0xf0
[<c015032f>] __getblk+0x4f/0x60
[<c01503bf>] __bread+0x1f/0x40
[<c01a2132>] read_super_block+0x82/0x210
[<c01a2d95>] reiserfs_fill_super+0x555/0x5a0
[<c01d69b7>] snprintf+0x27/0x30
[<c017bce2>] disk_name+0x62/0xb0
[<c0154bc5>] sb_set_blocksize+0x25/0x60
[<c0154594>] get_sb_bdev+0x124/0x160
[<c01a2e4f>] get_super_block+0x2f/0x60
[<c01a2840>] reiserfs_fill_super+0x0/0x5a0
[<c01547ff>] do_kern_mount+0x5f/0xe0
[<c01695c8>] do_add_mount+0x78/0x150
[<c01698b4>] do_mount+0x124/0x170
[<c0169720>] copy_mount_options+0x80/0xf0
[<c0169c6f>] sys_mount+0xbf/0x140
[<c0462b9f>] do_mount_root+0x2f/0xa0
[<c0462c64>] mount_block_root+0x54/0x120
[<c0462d8e>] mount_root+0x5e/0x70
[<c0462dbd>] prepare_namespace+0x1d/0xe0
[<c01050d2>] init+0x32/0x160
[<c01050a0>] init+0x0/0x160
[<c01070c9>] kernel_thread_helper+0x5/0xc
block=16, b_blocknr=64
b_state=0x00000019, b_size=1024
[3.] Keywords (i.e., modules, networking, kernel):
ReiserFS, 2.6.0test9
[4.] Kernel version (from /proc/version):
Linux version 2.6.0-test9-adelaide (root@picton) (gcc version 3.3.2
(Debian)) #1 Tue Oct 28 14:56:46 IST 2003
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
No "Oops" was generated.
[6.] A small shell script or example program which triggers the
problem (if possible)
N/A. It happens at boot time.
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Output of "sh scripts/ver_linux":
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux picton 2.6.0-test9-adelaide #1 Tue Oct 28 14:56:46 IST 2003 i686
GNU/Linux
Gnu C 3.3.2
Gnu make 3.80
binutils 2.14.90.0.6
util-linux 2.12
mount 2.12
module-init-tools 0.9.15-pre2
e2fsprogs 1.35-WIP
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.1.14
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0.91
Modules Loaded radeon snd_seq_oss snd_seq_midi_event snd_seq
snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer
snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd ipv6
[7.2.] Processor information (from /proc/cpuinfo):
output of "cat /proc/cpuinfo":
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2500+
stepping : 0
cpu MHz : 1830.378
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 3620.86
[7.3.] Module information (from /proc/modules):
output of "cat /proc/modules":
radeon 113644 - - Live 0xe0aad000
snd_seq_oss 36512 - - Live 0xe0a80000
snd_seq_midi_event 7616 - - Live 0xe09d8000
snd_seq 60880 - - Live 0xe0a70000
snd_pcm_oss 61604 - - Live 0xe0a20000
snd_mixer_oss 20608 - - Live 0xe09a4000
snd_intel8x0 25700 - - Live 0xe09c2000
snd_ac97_codec 54852 - - Live 0xe0a32000
snd_pcm 108708 - - Live 0xe0a41000
snd_timer 26564 - - Live 0xe09cc000
snd_page_alloc 12036 - - Live 0xe0999000
snd_mpu401_uart 7872 - - Live 0xe09a1000
snd_rawmidi 26112 - - Live 0xe09ba000
snd_seq_device 8200 - - Live 0xe099d000
snd 54020 - - Live 0xe09ab000
ipv6 250592 - - Live 0xe09e1000
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
output of "cat /proc/ioports":
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1c00-1c07 : nForce2 SMBus
2000-2007 : nForce2 SMBus
9000-9fff : PCI Bus #01
9000-907f : 0000:01:07.0
9000-907f : 0000:01:07.0
9400-947f : 0000:01:08.0
9400-947f : 0000:01:08.0
a000-afff : PCI Bus #02
a000-a0ff : 0000:02:00.0
b000-b0ff : 0000:00:06.0
b400-b47f : 0000:00:06.0
b400-b43f : NVidia nForce2 - Controller
c000-c01f : 0000:00:01.1
c400-c407 : 0000:00:04.0
f000-f00f : 0000:00:09.0
f000-f007 : ide0
f008-f00f : ide1
output of "cat /proc/iomem":
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-1ffeffff : System RAM
00100000-00357e42 : Kernel code
00357e43-0045f13f : Kernel data
1fff0000-1fff2fff : ACPI Non-volatile Storage
1fff3000-1fffffff : ACPI Tables
d0000000-d3ffffff : 0000:00:00.0
d4000000-dbffffff : PCI Bus #02
d4000000-d7ffffff : 0000:02:00.0
d8000000-dbffffff : 0000:02:00.1
dc000000-ddffffff : PCI Bus #02
dd000000-dd00ffff : 0000:02:00.0
dd010000-dd01ffff : 0000:02:00.1
de000000-dfffffff : PCI Bus #01
df000000-df00007f : 0000:01:07.0
df001000-df00107f : 0000:01:08.0
e0000000-e0000fff : 0000:00:04.0
e0001000-e0001fff : 0000:00:06.0
e0001000-e00011ff : NVidia nForce2 - AC'97
e0003000-e0003fff : 0000:00:02.0
e0004000-e0004fff : 0000:00:02.1
e0005000-e00050ff : 0000:00:02.2
e0005000-e00050ff : ehci_hcd
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved
[7.5.] PCI information ('lspci -vvv' as root)
output of "lspci -vvv" as root:
00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?)
(rev c1)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=64M]
Capabilities: <available only to root>
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
Subsystem: nVidia Corporation: Unknown device 0c17
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
Subsystem: nVidia Corporation: Unknown device 0c17
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
Subsystem: nVidia Corporation: Unknown device 0c17
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
Subsystem: nVidia Corporation: Unknown device 0c17
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
Subsystem: nVidia Corporation: Unknown device 0c17
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
Subsystem: Giga-byte Technology: Unknown device 0c11
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: <available only to root>
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
Subsystem: Giga-byte Technology: Unknown device 0c11
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at c000 [size=32]
Capabilities: <available only to root>
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev
a4) (prog-if 10 [OHCI])
Subsystem: Giga-byte Technology: Unknown device 5004
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e0003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev
a4) (prog-if 10 [OHCI])
Subsystem: Giga-byte Technology: Unknown device 5004
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 9
Region 0: Memory at e0004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev
a4) (prog-if 20 [EHCI])
Subsystem: Giga-byte Technology: Unknown device 5004
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin C routed to IRQ 5
Region 0: Memory at e0005000 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
Subsystem: Giga-byte Technology: Unknown device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at c400 [size=8]
Capabilities: <available only to root>
00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97
Audio Controler (MCP) (rev a1)
Subsystem: nVidia Corporation: Unknown device 4144
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at b000 [size=256]
Region 1: I/O ports at b400 [size=128]
Region 2: Memory at e0001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev
a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 00009000-00009fff
Memory behind bridge: de000000-dfffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2) (prog-if
8a [Master SecP PriP])
Subsystem: Giga-byte Technology: Unknown device 5002
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at f000 [size=16]
Capabilities: <available only to root>
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1) (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: 32
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d4000000-dbffffff
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
01:07.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 28)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
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: 32 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32
bytes)
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 9000 [size=128]
Region 1: Memory at df000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: <available only to root>
01:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 30)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
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: 32 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32
bytes)
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 9400 [size=128]
Region 1: Memory at df001000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: <available only to root>
02:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 If
[Radeon 9000] (rev 01) (prog-if 00 [VGA])
Subsystem: Giga-byte Technology: Unknown device 4010
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: 32 (2000ns min), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 9
Region 0: Memory at d4000000 (32-bit, prefetchable) [size=64M]
Region 1: I/O ports at a000 [size=256]
Region 2: Memory at dd000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: <available only to root>
02:00.1 Display controller: ATI Technologies Inc Radeon R250 [Radeon
9000] (Secondary) (rev 01)
Subsystem: Giga-byte Technology: Unknown device 4011
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: 32 (2000ns min), Cache Line Size: 0x08 (32 bytes)
Region 0: Memory at d8000000 (32-bit, prefetchable) [disabled]
[size=64M]
Region 1: Memory at dd010000 (32-bit, non-prefetchable)
[disabled] [size=64K]
Capabilities: <available only to root>
[7.6.] SCSI information (from /proc/scsi/scsi)
Not relevant. It's a "pure IDE" system.
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
Content of the files under /proc/fs/reiserfs/hda2:
===============> bitmap <=================
free_block: 2334
scan_bitmap: wait bmap retry stolen
journal_hintjournal_nohint
1167 0 1189 569
0 569 0
===============> journal <=================
jp_journal_1st_block: 18
jp_journal_dev: hda2[0]
jp_journal_size: 8192
jp_journal_trans_max: 1024
jp_journal_magic: 595152260
jp_journal_max_batch: 900
jp_journal_max_commit_age: 30
jp_journal_max_trans_age: 0
j_1st_reserved_block: 18
j_state: 0
j_trans_id: 1129213
j_mount_id: 73
j_start: 7409
j_len: 5
j_len_alloc: 5
j_wcount: 0
j_bcount: 12
j_first_unflushed_offset: 7197
j_last_flush_trans_id: 1129202
j_trans_start_time: 1067351133
j_journal_list_index: 38
j_list_bitmap_index: 0
j_must_wait: 0
j_next_full_flush: 0
j_next_async_flush: 0
j_cnode_used: 197
j_cnode_free: 16187
in_journal: 3015
in_journal_bitmap: 13993
in_journal_reusable: 2446
lock_journal: 189919
lock_journal_wait: 208
journal_begin: 94959
journal_relock_writers: 0
journal_relock_wcount: 1
mark_dirty: 143126
mark_dirty_already: 132341
mark_dirty_notjournal: 2352
restore_prepared: 386223
prepare: 163335
prepare_retry: 32078
===============> oidmap <=================
used: [ 1 .. 543d5 )
free: [ 543d5 .. 543d9 )
used: [ 543d9 .. 543da )
free: [ 543da .. 54484 )
used: [ 54484 .. 54485 )
free: [ 54485 .. 544ee )
used: [ 544ee .. 544ef )
free: [ 544ef .. 54587 )
used: [ 54587 .. 54588 )
free: [ 54588 .. 54692 )
used: [ 54692 .. 54693 )
free: [ 54693 .. 54696 )
used: [ 54696 .. 54697 )
free: [ 54697 .. 546b2 )
used: [ 546b2 .. 546b3 )
free: [ 546b3 .. 546b4 )
used: [ 546b4 .. 546b5 )
free: [ 546b5 .. 54857 )
used: [ 54857 .. 54858 )
free: [ 54858 .. 5485f )
used: [ 5485f .. 54860 )
free: [ 54860 .. 54919 )
used: [ 54919 .. 5491a )
free: [ 5491a .. 5492e )
used: [ 5492e .. 5492f )
free: [ 5492f .. 549b1 )
used: [ 549b1 .. 549b2 )
free: [ 549b2 .. 549b3 )
used: [ 549b3 .. 549b4 )
free: [ 549b4 .. 549b5 )
used: [ 549b5 .. 549b7 )
free: [ 549b7 .. 549b8 )
used: [ 549b8 .. 549b9 )
free: [ 549b9 .. 549bb )
used: [ 549bb .. 549bc )
free: [ 549bc .. 549e6 )
used: [ 549e6 .. 549e7 )
free: [ 549e7 .. 549ed )
used: [ 549ed .. 549ee )
free: [ 549ee .. 549ef )
used: [ 549ef .. 549f0 )
free: [ 549f0 .. 549f2 )
used: [ 549f2 .. 549f3 )
free: [ 549f3 .. 549f5 )
used: [ 549f5 .. 549f6 )
free: [ 549f6 .. 549f8 )
used: [ 549f8 .. 549f9 )
free: [ 549f9 .. 549fb )
used: [ 549fb .. 549fc )
free: [ 549fc .. 549fe )
used: [ 549fe .. 549ff )
free: [ 549ff .. 54a01 )
used: [ 54a01 .. 54a02 )
free: [ 54a02 .. 54a04 )
used: [ 54a04 .. 54a05 )
free: [ 54a05 .. 54a0c )
used: [ 54a0c .. 54a0d )
free: [ 54a0d .. 54a0e )
used: [ 54a0e .. 54a0f )
free: [ 54a0f .. 54a1c )
used: [ 54a1c .. 54a1d )
free: [ 54a1d .. 54a1e )
used: [ 54a1e .. 54a1f )
free: [ 54a1f .. 54a21 )
used: [ 54a21 .. 54a22 )
free: [ 54a22 .. 54a24 )
used: [ 54a24 .. 54a25 )
free: [ 54a25 .. 54a27 )
used: [ 54a27 .. 54a28 )
free: [ 54a28 .. 54a2a )
used: [ 54a2a .. 54a2b )
free: [ 54a2b .. 54a42 )
used: [ 54a42 .. 54a43 )
free: [ 54a43 .. 54a53 )
used: [ 54a53 .. 54a54 )
free: [ 54a54 .. 54a59 )
used: [ 54a59 .. 54a5a )
free: [ 54a5a .. 54a5c )
used: [ 54a5c .. 54a5d )
free: [ 54a5d .. 54a5f )
used: [ 54a5f .. 54a60 )
free: [ 54a60 .. 54a62 )
used: [ 54a62 .. 54a63 )
free: [ 54a63 .. 54a65 )
used: [ 54a65 .. 54a66 )
free: [ 54a66 .. 54a68 )
used: [ 54a68 .. 54a69 )
free: [ 54a69 .. 54a7d )
used: [ 54a7d .. 54a7e )
free: [ 54a7e .. 54a80 )
used: [ 54a80 .. 54a81 )
free: [ 54a81 .. 54aa1 )
used: [ 54aa1 .. 54aa2 )
free: [ 54aa2 .. 54aa4 )
used: [ 54aa4 .. 54aa5 )
free: [ 54aa5 .. 54aa7 )
used: [ 54aa7 .. 54aa8 )
free: [ 54aa8 .. 54aaa )
used: [ 54aaa .. 54aab )
free: [ 54aab .. 54aad )
used: [ 54aad .. 54aae )
free: [ 54aae .. 54ab5 )
used: [ 54ab5 .. 54ab6 )
free: [ 54ab6 .. 54abc )
used: [ 54abc .. 54abd )
free: [ 54abd .. 54ac6 )
used: [ 54ac6 .. 54ac7 )
free: [ 54ac7 .. 54acd )
used: [ 54acd .. 54ace )
free: [ 54ace .. 54ad0 )
used: [ 54ad0 .. 54ad1 )
free: [ 54ad1 .. 54ad5 )
used: [ 54ad5 .. 54ad6 )
free: [ 54ad6 .. 54ade )
used: [ 54ade .. 54adf )
free: [ 54adf .. 54b15 )
used: [ 54b15 .. 54b16 )
free: [ 54b16 .. 54b17 )
used: [ 54b17 .. 54b18 )
free: [ 54b18 .. 54b1a )
used: [ 54b1a .. 54b1b )
free: [ 54b1b .. 54b1d )
used: [ 54b1d .. 54b1e )
free: [ 54b1e .. 54b20 )
used: [ 54b20 .. 54b21 )
free: [ 54b21 .. 54b23 )
used: [ 54b23 .. 54b24 )
free: [ 54b24 .. 54b26 )
used: [ 54b26 .. 54b27 )
free: [ 54b27 .. 54b29 )
used: [ 54b29 .. 54b2a )
free: [ 54b2a .. 54b2c )
used: [ 54b2c .. 54b2d )
free: [ 54b2d .. 54b2f )
used: [ 54b2f .. 54b30 )
free: [ 54b30 .. 54b32 )
used: [ 54b32 .. 54b33 )
free: [ 54b33 .. 54b35 )
used: [ 54b35 .. 54b36 )
free: [ 54b36 .. 54b38 )
used: [ 54b38 .. 54b39 )
free: [ 54b39 .. 54b3b )
used: [ 54b3b .. 54b3c )
free: [ 54b3c .. 54b41 )
used: [ 54b41 .. 54b42 )
free: [ 54b42 .. 54b44 )
used: [ 54b44 .. 54b45 )
free: [ 54b45 .. 54b47 )
used: [ 54b47 .. 54b48 )
free: [ 54b48 .. 54c58 )
used: [ 54c58 .. 54c59 )
free: [ 54c59 .. 54cca )
used: [ 54cca .. 54ccb )
free: [ 54ccb .. 54ccc )
used: [ 54ccc .. 54ccd )
free: [ 54ccd .. ffffffff )
total: 156 [156/972] used: 345122 [exact]
===============> on-disk-super <=================
block_count: 19763966
free_blocks: 15854011
root_block: 2289297
blocksize: 4096
oid_maxsize: 972
oid_cursize: 156
umount_state: 2
magic: ReIsEr2Fs
fs_state: 0
hash: r5
tree_height: 5
bmap_nr: 604
version: 2
flags: 1[attrs_cleared]
reserved_for_journal: 0
===============> per-level <=================
level balances [sbk: reads fs_changed restarted] free
space items can_remove lnum rnum lbytes
rbytes get_neig get_neig_res need_l_neig need_r_neig
0 11340 188527 40 0
160895148 3115191 303 1725 1721
4455 5984 11343 3 125 117
1 148 188558 1 0
151553056 25614444 1 0 22
-148 -148 148 0 0 1
2 0 188558 0 0
65905960 29183073 0 0 0
0 0 0 0 0 0
3 0 188558 0 0
761774320 188558 0 0 0
0 0 0 0 0 0
4 0 0 0 0
0 0 0 0 0 0
0 0 0 0 0
===============> super <=================
state: REISERFS_VALID_FS
mount options: BORDER SMALL_TAILS LOG
gen. counter: 11340
s_kmallocs: 0
s_disk_reads: 0
s_disk_writes: 0
s_fix_nodes: 11344
s_do_balance: 11340
s_unneeded_left_neighbor: 0
s_good_search_by_key_reada: 0
s_bmaps: 0
s_bmaps_without_search: 0
s_direct2indirect: 35
s_indirect2direct: 583
max_hash_collisions: 0
breads: 0
bread_misses: 0
search_by_key: 188566
search_by_key_fs_changed: 41
search_by_key_restarted: 0
insert_item_restarted: 4
paste_into_item_restarted: 0
cut_from_item_restarted: 0
delete_solid_item_restarted: 0
delete_item_restarted: 0
leaked_oid: 0
leaves_removable: 0
===============> version <=================
3.6 format with checks off
[X.] Other notes, patches, fixes, workarounds:
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-28 15:49 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431" lkml-031028
@ 2003-10-28 18:36 ` Hans Reiser
2003-10-28 20:27 ` Oleg Drokin
2003-10-28 22:13 ` Andrew Morton
2 siblings, 0 replies; 37+ messages in thread
From: Hans Reiser @ 2003-10-28 18:36 UTC (permalink / raw)
To: lkml-031028, vs; +Cc: linux-kernel
Vladimir, please look into this tomorrow.
Hans
lkml-031028@amos.mailshell.com wrote:
> [1.] One line summary of the problem:
>
> First time boot of 2.6.0test9 on a resierfs disk gives the error above.
> (buffer layer error at fs/buffer.c:431)
>
> [2.] Full description of the problem/report:
>
> Compile kernel 2.6.0 test 9 from the Debian "unstable" package using
> make-kpkg.
> I have a single-filesystem 76Gb ResierFs filesystem. (reports as
> "ReiserFS 3.6").
> I usually run a customized 2.4.22 with debian patches and the preemptive
> kernel patch.
> First time I boot the 2.6.0 kernel I got the message quoted above,
> The message repated twice in a row. Both instance seem itentical to
> me. The message with the stack trace is copied as-is from the
> output of dmesg below:
>
> buffer layer error at fs/buffer.c:431
> Call Trace:
> [<c014f2b5>] __find_get_block_slow+0x85/0x120
> [<c0150283>] __find_get_block+0x83/0xe0
> [<c015030b>] __getblk+0x2b/0x60
> [<c01503bf>] __bread+0x1f/0x40
> [<c01a2132>] read_super_block+0x82/0x210
> [<c01a2d95>] reiserfs_fill_super+0x555/0x5a0
> [<c01d69b7>] snprintf+0x27/0x30
> [<c017bce2>] disk_name+0x62/0xb0
> [<c0154bc5>] sb_set_blocksize+0x25/0x60
> [<c0154594>] get_sb_bdev+0x124/0x160
> [<c01a2e4f>] get_super_block+0x2f/0x60
> [<c01a2840>] reiserfs_fill_super+0x0/0x5a0
> [<c01547ff>] do_kern_mount+0x5f/0xe0
> [<c01695c8>] do_add_mount+0x78/0x150
> [<c01698b4>] do_mount+0x124/0x170
> [<c0169720>] copy_mount_options+0x80/0xf0
> [<c0169c6f>] sys_mount+0xbf/0x140
> [<c0462b9f>] do_mount_root+0x2f/0xa0
> [<c0462c64>] mount_block_root+0x54/0x120
> [<c0462d8e>] mount_root+0x5e/0x70
> [<c0462dbd>] prepare_namespace+0x1d/0xe0
> [<c01050d2>] init+0x32/0x160
> [<c01050a0>] init+0x0/0x160
> [<c01070c9>] kernel_thread_helper+0x5/0xc
>
> block=16, b_blocknr=64
> b_state=0x00000019, b_size=1024
> buffer layer error at fs/buffer.c:431
> Call Trace:
> [<c014f2b5>] __find_get_block_slow+0x85/0x120
> [<c01070c9>] kernel_thread_helper+0x5/0xc
> [<c010970c>] dump_stack+0x1c/0x20
> [<c0150283>] __find_get_block+0x83/0xe0
> [<c014fec3>] __getblk_slow+0x23/0xf0
> [<c015032f>] __getblk+0x4f/0x60
> [<c01503bf>] __bread+0x1f/0x40
> [<c01a2132>] read_super_block+0x82/0x210
> [<c01a2d95>] reiserfs_fill_super+0x555/0x5a0
> [<c01d69b7>] snprintf+0x27/0x30
> [<c017bce2>] disk_name+0x62/0xb0
> [<c0154bc5>] sb_set_blocksize+0x25/0x60
> [<c0154594>] get_sb_bdev+0x124/0x160
> [<c01a2e4f>] get_super_block+0x2f/0x60
> [<c01a2840>] reiserfs_fill_super+0x0/0x5a0
> [<c01547ff>] do_kern_mount+0x5f/0xe0
> [<c01695c8>] do_add_mount+0x78/0x150
> [<c01698b4>] do_mount+0x124/0x170
> [<c0169720>] copy_mount_options+0x80/0xf0
> [<c0169c6f>] sys_mount+0xbf/0x140
> [<c0462b9f>] do_mount_root+0x2f/0xa0
> [<c0462c64>] mount_block_root+0x54/0x120
> [<c0462d8e>] mount_root+0x5e/0x70
> [<c0462dbd>] prepare_namespace+0x1d/0xe0
> [<c01050d2>] init+0x32/0x160
> [<c01050a0>] init+0x0/0x160
> [<c01070c9>] kernel_thread_helper+0x5/0xc
>
> block=16, b_blocknr=64
> b_state=0x00000019, b_size=1024
>
> [3.] Keywords (i.e., modules, networking, kernel):
>
> ReiserFS, 2.6.0test9
>
> [4.] Kernel version (from /proc/version):
>
> Linux version 2.6.0-test9-adelaide (root@picton) (gcc version 3.3.2
> (Debian)) #1 Tue Oct 28 14:56:46 IST 2003
>
> [5.] Output of Oops.. message (if applicable) with symbolic information
> resolved (see Documentation/oops-tracing.txt)
>
> No "Oops" was generated.
>
> [6.] A small shell script or example program which triggers the
> problem (if possible)
>
> N/A. It happens at boot time.
>
> [7.] Environment
> [7.1.] Software (add the output of the ver_linux script here)
>
> Output of "sh scripts/ver_linux":
>
> If some fields are empty or look unusual you may have an old version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux picton 2.6.0-test9-adelaide #1 Tue Oct 28 14:56:46 IST 2003 i686
> GNU/Linux
>
> Gnu C 3.3.2
> Gnu make 3.80
> binutils 2.14.90.0.6
> util-linux 2.12
> mount 2.12
> module-init-tools 0.9.15-pre2
> e2fsprogs 1.35-WIP
> Linux C Library 2.3.2
> Dynamic linker (ldd) 2.3.2
> Procps 3.1.14
> Net-tools 1.60
> Console-tools 0.2.3
> Sh-utils 5.0.91
> Modules Loaded radeon snd_seq_oss snd_seq_midi_event snd_seq
> snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm
> snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device
> snd ipv6
>
> [7.2.] Processor information (from /proc/cpuinfo):
>
> output of "cat /proc/cpuinfo":
>
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 6
> model : 10
> model name : AMD Athlon(tm) XP 2500+
> stepping : 0
> cpu MHz : 1830.378
> cache size : 512 KB
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
> bogomips : 3620.86
>
>
> [7.3.] Module information (from /proc/modules):
>
> output of "cat /proc/modules":
>
> radeon 113644 - - Live 0xe0aad000
> snd_seq_oss 36512 - - Live 0xe0a80000
> snd_seq_midi_event 7616 - - Live 0xe09d8000
> snd_seq 60880 - - Live 0xe0a70000
> snd_pcm_oss 61604 - - Live 0xe0a20000
> snd_mixer_oss 20608 - - Live 0xe09a4000
> snd_intel8x0 25700 - - Live 0xe09c2000
> snd_ac97_codec 54852 - - Live 0xe0a32000
> snd_pcm 108708 - - Live 0xe0a41000
> snd_timer 26564 - - Live 0xe09cc000
> snd_page_alloc 12036 - - Live 0xe0999000
> snd_mpu401_uart 7872 - - Live 0xe09a1000
> snd_rawmidi 26112 - - Live 0xe09ba000
> snd_seq_device 8200 - - Live 0xe099d000
> snd 54020 - - Live 0xe09ab000
> ipv6 250592 - - Live 0xe09e1000
>
> [7.4.] Loaded driver and hardware information (/proc/ioports,
> /proc/iomem)
>
> output of "cat /proc/ioports":
>
> 0000-001f : dma1
> 0020-0021 : pic1
> 0040-005f : timer
> 0060-006f : keyboard
> 0070-0077 : rtc
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0170-0177 : ide1
> 01f0-01f7 : ide0
> 0376-0376 : ide1
> 03c0-03df : vga+
> 03f6-03f6 : ide0
> 0cf8-0cff : PCI conf1
> 1c00-1c07 : nForce2 SMBus
> 2000-2007 : nForce2 SMBus
> 9000-9fff : PCI Bus #01
> 9000-907f : 0000:01:07.0
> 9000-907f : 0000:01:07.0
> 9400-947f : 0000:01:08.0
> 9400-947f : 0000:01:08.0
> a000-afff : PCI Bus #02
> a000-a0ff : 0000:02:00.0
> b000-b0ff : 0000:00:06.0
> b400-b47f : 0000:00:06.0
> b400-b43f : NVidia nForce2 - Controller
> c000-c01f : 0000:00:01.1
> c400-c407 : 0000:00:04.0
> f000-f00f : 0000:00:09.0
> f000-f007 : ide0
> f008-f00f : ide1
>
> output of "cat /proc/iomem":
>
> 00000000-0009fbff : System RAM
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000f0000-000fffff : System ROM
> 00100000-1ffeffff : System RAM
> 00100000-00357e42 : Kernel code
> 00357e43-0045f13f : Kernel data
> 1fff0000-1fff2fff : ACPI Non-volatile Storage
> 1fff3000-1fffffff : ACPI Tables
> d0000000-d3ffffff : 0000:00:00.0
> d4000000-dbffffff : PCI Bus #02
> d4000000-d7ffffff : 0000:02:00.0
> d8000000-dbffffff : 0000:02:00.1
> dc000000-ddffffff : PCI Bus #02
> dd000000-dd00ffff : 0000:02:00.0
> dd010000-dd01ffff : 0000:02:00.1
> de000000-dfffffff : PCI Bus #01
> df000000-df00007f : 0000:01:07.0
> df001000-df00107f : 0000:01:08.0
> e0000000-e0000fff : 0000:00:04.0
> e0001000-e0001fff : 0000:00:06.0
> e0001000-e00011ff : NVidia nForce2 - AC'97
> e0003000-e0003fff : 0000:00:02.0
> e0004000-e0004fff : 0000:00:02.1
> e0005000-e00050ff : 0000:00:02.2
> e0005000-e00050ff : ehci_hcd
> fec00000-fec00fff : reserved
> fee00000-fee00fff : reserved
> ffff0000-ffffffff : reserved
>
> [7.5.] PCI information ('lspci -vvv' as root)
>
> output of "lspci -vvv" as root:
>
> 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different
> version?) (rev c1)
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Region 0: Memory at d0000000 (32-bit, prefetchable) [size=64M]
> Capabilities: <available only to root>
>
> 00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1
> (rev c1)
> Subsystem: nVidia Corporation: Unknown device 0c17
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4
> (rev c1)
> Subsystem: nVidia Corporation: Unknown device 0c17
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3
> (rev c1)
> Subsystem: nVidia Corporation: Unknown device 0c17
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2
> (rev c1)
> Subsystem: nVidia Corporation: Unknown device 0c17
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5
> (rev c1)
> Subsystem: nVidia Corporation: Unknown device 0c17
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>
> 00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
> Subsystem: Giga-byte Technology: Unknown device 0c11
> Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Capabilities: <available only to root>
>
> 00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
> Subsystem: Giga-byte Technology: Unknown device 0c11
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin A routed to IRQ 5
> Region 0: I/O ports at c000 [size=32]
> Capabilities: <available only to root>
>
> 00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev
> a4) (prog-if 10 [OHCI])
> Subsystem: Giga-byte Technology: Unknown device 5004
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (750ns min, 250ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at e0003000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: <available only to root>
>
> 00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev
> a4) (prog-if 10 [OHCI])
> Subsystem: Giga-byte Technology: Unknown device 5004
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (750ns min, 250ns max)
> Interrupt: pin B routed to IRQ 9
> Region 0: Memory at e0004000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: <available only to root>
>
> 00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev
> a4) (prog-if 20 [EHCI])
> Subsystem: Giga-byte Technology: Unknown device 5004
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (750ns min, 250ns max)
> Interrupt: pin C routed to IRQ 5
> Region 0: Memory at e0005000 (32-bit, non-prefetchable)
> [size=256]
> Capabilities: <available only to root>
>
> 00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
> Controller (rev a1)
> Subsystem: Giga-byte Technology: Unknown device e000
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (250ns min, 5000ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=4K]
> Region 1: I/O ports at c400 [size=8]
> Capabilities: <available only to root>
>
> 00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97
> Audio Controler (MCP) (rev a1)
> Subsystem: nVidia Corporation: Unknown device 4144
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (500ns min, 1250ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at b000 [size=256]
> Region 1: I/O ports at b400 [size=128]
> Region 2: Memory at e0001000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: <available only to root>
>
> 00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge
> (rev a3) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B-
> Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
> I/O behind bridge: 00009000-00009fff
> Memory behind bridge: de000000-dfffffff
> Prefetchable memory behind bridge: fff00000-000fffff
> BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
>
> 00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
> (prog-if 8a [Master SecP PriP])
> Subsystem: Giga-byte Technology: Unknown device 5002
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0 (750ns min, 250ns max)
> Region 4: I/O ports at f000 [size=16]
> Capabilities: <available only to root>
>
> 00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1) (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: 32
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
> I/O behind bridge: 0000a000-0000afff
> Memory behind bridge: dc000000-ddffffff
> Prefetchable memory behind bridge: d4000000-dbffffff
> BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
>
> 01:07.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX
> [Cyclone] (rev 28)
> Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
> 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: 32 (2500ns min, 2500ns max), Cache Line Size: 0x08
> (32 bytes)
> Interrupt: pin A routed to IRQ 9
> Region 0: I/O ports at 9000 [size=128]
> Region 1: Memory at df000000 (32-bit, non-prefetchable)
> [size=128]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: <available only to root>
>
> 01:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX
> [Cyclone] (rev 30)
> Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
> 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: 32 (2500ns min, 2500ns max), Cache Line Size: 0x08
> (32 bytes)
> Interrupt: pin A routed to IRQ 5
> Region 0: I/O ports at 9400 [size=128]
> Region 1: Memory at df001000 (32-bit, non-prefetchable)
> [size=128]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: <available only to root>
>
> 02:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 If
> [Radeon 9000] (rev 01) (prog-if 00 [VGA])
> Subsystem: Giga-byte Technology: Unknown device 4010
> 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: 32 (2000ns min), Cache Line Size: 0x08 (32 bytes)
> Interrupt: pin A routed to IRQ 9
> Region 0: Memory at d4000000 (32-bit, prefetchable) [size=64M]
> Region 1: I/O ports at a000 [size=256]
> Region 2: Memory at dd000000 (32-bit, non-prefetchable)
> [size=64K]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: <available only to root>
>
> 02:00.1 Display controller: ATI Technologies Inc Radeon R250 [Radeon
> 9000] (Secondary) (rev 01)
> Subsystem: Giga-byte Technology: Unknown device 4011
> 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: 32 (2000ns min), Cache Line Size: 0x08 (32 bytes)
> Region 0: Memory at d8000000 (32-bit, prefetchable) [disabled]
> [size=64M]
> Region 1: Memory at dd010000 (32-bit, non-prefetchable)
> [disabled] [size=64K]
> Capabilities: <available only to root>
>
>
>
> [7.6.] SCSI information (from /proc/scsi/scsi)
>
> Not relevant. It's a "pure IDE" system.
>
> [7.7.] Other information that might be relevant to the problem
> (please look in /proc and include all information that you
> think to be relevant):
>
> Content of the files under /proc/fs/reiserfs/hda2:
>
> ===============> bitmap <=================
> free_block: 2334
> scan_bitmap: wait bmap retry stolen
> journal_hintjournal_nohint
> 1167 0 1189 569
> 0 569 0
> ===============> journal <=================
> jp_journal_1st_block: 18
> jp_journal_dev: hda2[0]
> jp_journal_size: 8192
> jp_journal_trans_max: 1024
> jp_journal_magic: 595152260
> jp_journal_max_batch: 900
> jp_journal_max_commit_age: 30
> jp_journal_max_trans_age: 0
> j_1st_reserved_block: 18
> j_state: 0
> j_trans_id: 1129213
> j_mount_id: 73
> j_start: 7409
> j_len: 5
> j_len_alloc: 5
> j_wcount: 0
> j_bcount: 12
> j_first_unflushed_offset: 7197
> j_last_flush_trans_id: 1129202
> j_trans_start_time: 1067351133
> j_journal_list_index: 38
> j_list_bitmap_index: 0
> j_must_wait: 0
> j_next_full_flush: 0
> j_next_async_flush: 0
> j_cnode_used: 197
> j_cnode_free: 16187
>
> in_journal: 3015
> in_journal_bitmap: 13993
> in_journal_reusable: 2446
> lock_journal: 189919
> lock_journal_wait: 208
> journal_begin: 94959
> journal_relock_writers: 0
> journal_relock_wcount: 1
> mark_dirty: 143126
> mark_dirty_already: 132341
> mark_dirty_notjournal: 2352
> restore_prepared: 386223
> prepare: 163335
> prepare_retry: 32078
> ===============> oidmap <=================
> used: [ 1 .. 543d5 )
> free: [ 543d5 .. 543d9 )
> used: [ 543d9 .. 543da )
> free: [ 543da .. 54484 )
> used: [ 54484 .. 54485 )
> free: [ 54485 .. 544ee )
> used: [ 544ee .. 544ef )
> free: [ 544ef .. 54587 )
> used: [ 54587 .. 54588 )
> free: [ 54588 .. 54692 )
> used: [ 54692 .. 54693 )
> free: [ 54693 .. 54696 )
> used: [ 54696 .. 54697 )
> free: [ 54697 .. 546b2 )
> used: [ 546b2 .. 546b3 )
> free: [ 546b3 .. 546b4 )
> used: [ 546b4 .. 546b5 )
> free: [ 546b5 .. 54857 )
> used: [ 54857 .. 54858 )
> free: [ 54858 .. 5485f )
> used: [ 5485f .. 54860 )
> free: [ 54860 .. 54919 )
> used: [ 54919 .. 5491a )
> free: [ 5491a .. 5492e )
> used: [ 5492e .. 5492f )
> free: [ 5492f .. 549b1 )
> used: [ 549b1 .. 549b2 )
> free: [ 549b2 .. 549b3 )
> used: [ 549b3 .. 549b4 )
> free: [ 549b4 .. 549b5 )
> used: [ 549b5 .. 549b7 )
> free: [ 549b7 .. 549b8 )
> used: [ 549b8 .. 549b9 )
> free: [ 549b9 .. 549bb )
> used: [ 549bb .. 549bc )
> free: [ 549bc .. 549e6 )
> used: [ 549e6 .. 549e7 )
> free: [ 549e7 .. 549ed )
> used: [ 549ed .. 549ee )
> free: [ 549ee .. 549ef )
> used: [ 549ef .. 549f0 )
> free: [ 549f0 .. 549f2 )
> used: [ 549f2 .. 549f3 )
> free: [ 549f3 .. 549f5 )
> used: [ 549f5 .. 549f6 )
> free: [ 549f6 .. 549f8 )
> used: [ 549f8 .. 549f9 )
> free: [ 549f9 .. 549fb )
> used: [ 549fb .. 549fc )
> free: [ 549fc .. 549fe )
> used: [ 549fe .. 549ff )
> free: [ 549ff .. 54a01 )
> used: [ 54a01 .. 54a02 )
> free: [ 54a02 .. 54a04 )
> used: [ 54a04 .. 54a05 )
> free: [ 54a05 .. 54a0c )
> used: [ 54a0c .. 54a0d )
> free: [ 54a0d .. 54a0e )
> used: [ 54a0e .. 54a0f )
> free: [ 54a0f .. 54a1c )
> used: [ 54a1c .. 54a1d )
> free: [ 54a1d .. 54a1e )
> used: [ 54a1e .. 54a1f )
> free: [ 54a1f .. 54a21 )
> used: [ 54a21 .. 54a22 )
> free: [ 54a22 .. 54a24 )
> used: [ 54a24 .. 54a25 )
> free: [ 54a25 .. 54a27 )
> used: [ 54a27 .. 54a28 )
> free: [ 54a28 .. 54a2a )
> used: [ 54a2a .. 54a2b )
> free: [ 54a2b .. 54a42 )
> used: [ 54a42 .. 54a43 )
> free: [ 54a43 .. 54a53 )
> used: [ 54a53 .. 54a54 )
> free: [ 54a54 .. 54a59 )
> used: [ 54a59 .. 54a5a )
> free: [ 54a5a .. 54a5c )
> used: [ 54a5c .. 54a5d )
> free: [ 54a5d .. 54a5f )
> used: [ 54a5f .. 54a60 )
> free: [ 54a60 .. 54a62 )
> used: [ 54a62 .. 54a63 )
> free: [ 54a63 .. 54a65 )
> used: [ 54a65 .. 54a66 )
> free: [ 54a66 .. 54a68 )
> used: [ 54a68 .. 54a69 )
> free: [ 54a69 .. 54a7d )
> used: [ 54a7d .. 54a7e )
> free: [ 54a7e .. 54a80 )
> used: [ 54a80 .. 54a81 )
> free: [ 54a81 .. 54aa1 )
> used: [ 54aa1 .. 54aa2 )
> free: [ 54aa2 .. 54aa4 )
> used: [ 54aa4 .. 54aa5 )
> free: [ 54aa5 .. 54aa7 )
> used: [ 54aa7 .. 54aa8 )
> free: [ 54aa8 .. 54aaa )
> used: [ 54aaa .. 54aab )
> free: [ 54aab .. 54aad )
> used: [ 54aad .. 54aae )
> free: [ 54aae .. 54ab5 )
> used: [ 54ab5 .. 54ab6 )
> free: [ 54ab6 .. 54abc )
> used: [ 54abc .. 54abd )
> free: [ 54abd .. 54ac6 )
> used: [ 54ac6 .. 54ac7 )
> free: [ 54ac7 .. 54acd )
> used: [ 54acd .. 54ace )
> free: [ 54ace .. 54ad0 )
> used: [ 54ad0 .. 54ad1 )
> free: [ 54ad1 .. 54ad5 )
> used: [ 54ad5 .. 54ad6 )
> free: [ 54ad6 .. 54ade )
> used: [ 54ade .. 54adf )
> free: [ 54adf .. 54b15 )
> used: [ 54b15 .. 54b16 )
> free: [ 54b16 .. 54b17 )
> used: [ 54b17 .. 54b18 )
> free: [ 54b18 .. 54b1a )
> used: [ 54b1a .. 54b1b )
> free: [ 54b1b .. 54b1d )
> used: [ 54b1d .. 54b1e )
> free: [ 54b1e .. 54b20 )
> used: [ 54b20 .. 54b21 )
> free: [ 54b21 .. 54b23 )
> used: [ 54b23 .. 54b24 )
> free: [ 54b24 .. 54b26 )
> used: [ 54b26 .. 54b27 )
> free: [ 54b27 .. 54b29 )
> used: [ 54b29 .. 54b2a )
> free: [ 54b2a .. 54b2c )
> used: [ 54b2c .. 54b2d )
> free: [ 54b2d .. 54b2f )
> used: [ 54b2f .. 54b30 )
> free: [ 54b30 .. 54b32 )
> used: [ 54b32 .. 54b33 )
> free: [ 54b33 .. 54b35 )
> used: [ 54b35 .. 54b36 )
> free: [ 54b36 .. 54b38 )
> used: [ 54b38 .. 54b39 )
> free: [ 54b39 .. 54b3b )
> used: [ 54b3b .. 54b3c )
> free: [ 54b3c .. 54b41 )
> used: [ 54b41 .. 54b42 )
> free: [ 54b42 .. 54b44 )
> used: [ 54b44 .. 54b45 )
> free: [ 54b45 .. 54b47 )
> used: [ 54b47 .. 54b48 )
> free: [ 54b48 .. 54c58 )
> used: [ 54c58 .. 54c59 )
> free: [ 54c59 .. 54cca )
> used: [ 54cca .. 54ccb )
> free: [ 54ccb .. 54ccc )
> used: [ 54ccc .. 54ccd )
> free: [ 54ccd .. ffffffff )
> total: 156 [156/972] used: 345122 [exact]
> ===============> on-disk-super <=================
> block_count: 19763966
> free_blocks: 15854011
> root_block: 2289297
> blocksize: 4096
> oid_maxsize: 972
> oid_cursize: 156
> umount_state: 2
> magic: ReIsEr2Fs
> fs_state: 0
> hash: r5
> tree_height: 5
> bmap_nr: 604
> version: 2
> flags: 1[attrs_cleared]
> reserved_for_journal: 0
> ===============> per-level <=================
> level balances [sbk: reads fs_changed restarted] free
> space items can_remove lnum rnum lbytes
> rbytes get_neig get_neig_res need_l_neig need_r_neig
> 0 11340 188527 40 0
> 160895148 3115191 303 1725 1721
> 4455 5984 11343 3 125 117
> 1 148 188558 1 0
> 151553056 25614444 1 0 22
> -148 -148 148 0 0 1
> 2 0 188558 0 0
> 65905960 29183073 0 0 0
> 0 0 0 0 0 0
> 3 0 188558 0 0
> 761774320 188558 0 0 0
> 0 0 0 0 0 0
> 4 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0
> ===============> super <=================
> state: REISERFS_VALID_FS
> mount options: BORDER SMALL_TAILS LOG
> gen. counter: 11340
> s_kmallocs: 0
> s_disk_reads: 0
> s_disk_writes: 0
> s_fix_nodes: 11344
> s_do_balance: 11340
> s_unneeded_left_neighbor: 0
> s_good_search_by_key_reada: 0
> s_bmaps: 0
> s_bmaps_without_search: 0
> s_direct2indirect: 35
> s_indirect2direct: 583
>
> max_hash_collisions: 0
> breads: 0
> bread_misses: 0
> search_by_key: 188566
> search_by_key_fs_changed: 41
> search_by_key_restarted: 0
> insert_item_restarted: 4
> paste_into_item_restarted: 0
> cut_from_item_restarted: 0
> delete_solid_item_restarted: 0
> delete_item_restarted: 0
> leaked_oid: 0
> leaves_removable: 0
> ===============> version <=================
> 3.6 format with checks off
>
>
>
>
> [X.] Other notes, patches, fixes, workarounds:
>
>
> -
> 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/
>
>
--
Hans
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-28 15:49 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431" lkml-031028
2003-10-28 18:36 ` Hans Reiser
@ 2003-10-28 20:27 ` Oleg Drokin
2003-10-28 22:13 ` Andrew Morton
2 siblings, 0 replies; 37+ messages in thread
From: Oleg Drokin @ 2003-10-28 20:27 UTC (permalink / raw)
To: linux-kernel, lkml-031028
lkml-031028@amos.mailshell.com wrote:
lamc> I have a single-filesystem 76Gb ResierFs filesystem. (reports as
lamc> "ReiserFS 3.6").
lamc> First time I boot the 2.6.0 kernel I got the message quoted above,
lamc> The message repated twice in a row. Both instance seem itentical to
lamc> me. The message with the stack trace is copied as-is from the
lamc> output of dmesg below:
lamc> buffer layer error at fs/buffer.c:431
lamc> block=16, b_blocknr=64
lamc> b_state=0x00000019, b_size=1024
Hm, this looks *very* strange to me.
Basically what happened is we (VFS) tried to look up a page that holds
block number 16 for the fs device, but the end result was page
that contained block number 64.
This looked a lot like if we have already changed device's block size,
but old buffers were not invalidated. So our 16th block of 4k size
resulted in a page containing 64th block of 1k size.
To verify this you can apply this simple patch below and see if
returned block size was different from current block size.
As of how this might have happened, I have not idea, but certainly
this have nothing to do with reiserfs itself.
===== fs/buffer.c 1.215 vs edited =====
--- 1.215/fs/buffer.c Tue Sep 30 04:12:02 2003
+++ edited/fs/buffer.c Tue Oct 28 21:26:23 2003
@@ -432,6 +432,7 @@
printk("block=%llu, b_blocknr=%llu\n",
(unsigned long long)block, (unsigned long long)bh->b_blocknr);
printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size);
+ printk("device blocksize: %d\n", 1<<bd_inode->i_blkbits);
out_unlock:
spin_unlock(&bd_mapping->private_lock);
page_cache_release(page);
Bye,
Oleg
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-28 15:49 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431" lkml-031028
2003-10-28 18:36 ` Hans Reiser
2003-10-28 20:27 ` Oleg Drokin
@ 2003-10-28 22:13 ` Andrew Morton
2003-10-28 22:15 ` Hans Reiser
` (2 more replies)
2 siblings, 3 replies; 37+ messages in thread
From: Andrew Morton @ 2003-10-28 22:13 UTC (permalink / raw)
To: lkml-031028; +Cc: linux-kernel, vs, Hans Reiser
lkml-031028@amos.mailshell.com wrote:
>
> [1.] One line summary of the problem:
>
> First time boot of 2.6.0test9 on a resierfs disk gives the error above.
> (buffer layer error at fs/buffer.c:431)
>
> ...
>
> block=16, b_blocknr=64
> b_state=0x00000019, b_size=1024
> buffer layer error at fs/buffer.c:431
ah-hah.
> Call Trace:
> [<c014f2b5>] __find_get_block_slow+0x85/0x120
> [<c01070c9>] kernel_thread_helper+0x5/0xc
> [<c010970c>] dump_stack+0x1c/0x20
> [<c0150283>] __find_get_block+0x83/0xe0
> [<c014fec3>] __getblk_slow+0x23/0xf0
> [<c015032f>] __getblk+0x4f/0x60
> [<c01503bf>] __bread+0x1f/0x40
> [<c01a2132>] read_super_block+0x82/0x210
> [<c01a2d95>] reiserfs_fill_super+0x555/0x5a0
> [<c01d69b7>] snprintf+0x27/0x30
> [<c017bce2>] disk_name+0x62/0xb0
> [<c0154bc5>] sb_set_blocksize+0x25/0x60
> [<c0154594>] get_sb_bdev+0x124/0x160
> [<c01a2e4f>] get_super_block+0x2f/0x60
> [<c01a2840>] reiserfs_fill_super+0x0/0x5a0
> [<c01547ff>] do_kern_mount+0x5f/0xe0
> [<c01695c8>] do_add_mount+0x78/0x150
> [<c01698b4>] do_mount+0x124/0x170
> [<c0169720>] copy_mount_options+0x80/0xf0
> [<c0169c6f>] sys_mount+0xbf/0x140
> [<c0462b9f>] do_mount_root+0x2f/0xa0
> [<c0462c64>] mount_block_root+0x54/0x120
> [<c0462d8e>] mount_root+0x5e/0x70
> [<c0462dbd>] prepare_namespace+0x1d/0xe0
> [<c01050d2>] init+0x32/0x160
> [<c01050a0>] init+0x0/0x160
> [<c01070c9>] kernel_thread_helper+0x5/0xc
I've been waiting a year for someone who can reproduce this.
The filesystem is trying to read the 4k block at offset 16*4k.
But someone had previously read the 1k block at offset 64*1k. It is an
alias of the 4k read.
We _should_ have shot down the four 1k-sized buffer_heads which are
attached to the offset=16 pagecache page before trying to read it with 4k
blocksize.
But for some reason, that page still has the 1k-sized buffer_heads.
This means that somehow, somewhere, we failed to successfully run
set_blocksize() against that disk.
Are you using initrd?
Could you please add this patch, and send the new dmesg output?
25-akpm/fs/block_dev.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff -puN fs/block_dev.c~a fs/block_dev.c
--- 25/fs/block_dev.c~a Tue Oct 28 14:11:20 2003
+++ 25-akpm/fs/block_dev.c Tue Oct 28 14:11:24 2003
@@ -50,17 +50,26 @@ int set_blocksize(struct block_device *b
{
int oldsize;
+ printk("%s: size=%d\n", __FUNCTION__, size);
+
/* Size must be a power of two, and between 512 and PAGE_SIZE */
- if (size > PAGE_SIZE || size < 512 || (size & (size-1)))
+ if (size > PAGE_SIZE || size < 512 || (size & (size-1))) {
+ printk("%s: EINVAL 1\n", __FUNCTION__);
return -EINVAL;
+ }
/* Size cannot be smaller than the size supported by the device */
- if (size < bdev_hardsect_size(bdev))
+ if (size < bdev_hardsect_size(bdev)) {
+ printk("%s: %d < %d\n", __FUNCTION__, size,
+ bdev_hardsect_size(bdev));
return -EINVAL;
+ }
oldsize = bdev->bd_block_size;
- if (oldsize == size)
+ if (oldsize == size) {
+ printk("%s: %d OK\n", __FUNCTION__, size);
return 0;
+ }
/* Ok, we're actually changing the blocksize.. */
sync_blockdev(bdev);
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-28 22:13 ` Andrew Morton
@ 2003-10-28 22:15 ` Hans Reiser
2003-10-29 6:56 ` lkml-031028
2003-10-29 17:44 ` lkml-031028
2 siblings, 0 replies; 37+ messages in thread
From: Hans Reiser @ 2003-10-28 22:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml-031028, linux-kernel, vs, flx, Alexander Zarochentcev
Thanks Andrew.
--
Hans
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-28 22:13 ` Andrew Morton
2003-10-28 22:15 ` Hans Reiser
@ 2003-10-29 6:56 ` lkml-031028
2003-10-29 17:44 ` lkml-031028
2 siblings, 0 replies; 37+ messages in thread
From: lkml-031028 @ 2003-10-29 6:56 UTC (permalink / raw)
To: linux-kernel
On Tue, Oct 28, 2003 at 02:13:29PM -0800, Andrew Morton wrote:
> I've been waiting a year for someone who can reproduce this.
Looks like it's reproducible right now - I got exactly the same
message when I boot again later.
I'll try not to move things too much so I can test this more.
(You don't think it's critical, do you?)
> Are you using initrd?
Nope. Just plain old /boot/vmlinuz on a simple IDE disk with
a single ReiserFS partition and ReiserFS code compiled into
the kernel.
> Could you please add this patch, and send the new dmesg output?
Will do it gladly, when I'm back home tonight.
Thanks for everything,
--Amos
PS I'm not on lkml, so please keep me cc'ed about this.
>
>
> 25-akpm/fs/block_dev.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff -puN fs/block_dev.c~a fs/block_dev.c
> --- 25/fs/block_dev.c~a Tue Oct 28 14:11:20 2003
> +++ 25-akpm/fs/block_dev.c Tue Oct 28 14:11:24 2003
> @@ -50,17 +50,26 @@ int set_blocksize(struct block_device *b
> {
> int oldsize;
>
> + printk("%s: size=%d\n", __FUNCTION__, size);
> +
> /* Size must be a power of two, and between 512 and PAGE_SIZE */
> - if (size > PAGE_SIZE || size < 512 || (size & (size-1)))
> + if (size > PAGE_SIZE || size < 512 || (size & (size-1))) {
> + printk("%s: EINVAL 1\n", __FUNCTION__);
> return -EINVAL;
> + }
>
> /* Size cannot be smaller than the size supported by the device */
> - if (size < bdev_hardsect_size(bdev))
> + if (size < bdev_hardsect_size(bdev)) {
> + printk("%s: %d < %d\n", __FUNCTION__, size,
> + bdev_hardsect_size(bdev));
> return -EINVAL;
> + }
>
> oldsize = bdev->bd_block_size;
> - if (oldsize == size)
> + if (oldsize == size) {
> + printk("%s: %d OK\n", __FUNCTION__, size);
> return 0;
> + }
>
> /* Ok, we're actually changing the blocksize.. */
> sync_blockdev(bdev);
>
> _
>
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-28 22:13 ` Andrew Morton
2003-10-28 22:15 ` Hans Reiser
2003-10-29 6:56 ` lkml-031028
@ 2003-10-29 17:44 ` lkml-031028
2003-10-29 20:31 ` Andrew Morton
2 siblings, 1 reply; 37+ messages in thread
From: lkml-031028 @ 2003-10-29 17:44 UTC (permalink / raw)
To: linux-kernel
Hi,
Here are the results (output of dmesg) from booting a kernel with this
patch:
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=4096
buffer layer error at fs/buffer.c:431
Call Trace:
[<c014f2b5>] __find_get_block_slow+0x85/0x120
[<c0150283>] __find_get_block+0x83/0xe0
[<c015030b>] __getblk+0x2b/0x60
[<c01503bf>] __bread+0x1f/0x40
[<c01a2172>] read_super_block+0x82/0x210
[<c01a2dd5>] reiserfs_fill_super+0x555/0x5a0
[<c01d69f7>] snprintf+0x27/0x30
[<c0154bc0>] set_blocksize+0xd0/0x110
[<c0154c25>] sb_set_blocksize+0x25/0x60
[<c0154594>] get_sb_bdev+0x124/0x160
[<c01a2e8f>] get_super_block+0x2f/0x60
[<c01a2880>] reiserfs_fill_super+0x0/0x5a0
[<c01547ff>] do_kern_mount+0x5f/0xe0
[<c0169608>] do_add_mount+0x78/0x150
[<c01698f4>] do_mount+0x124/0x170
[<c0169760>] copy_mount_options+0x80/0xf0
[<c0169caf>] sys_mount+0xbf/0x140
[<c0478b9f>] do_mount_root+0x2f/0xa0
[<c0478c64>] mount_block_root+0x54/0x120
[<c0478d8e>] mount_root+0x5e/0x70
[<c0478dbd>] prepare_namespace+0x1d/0xe0
[<c01050d2>] init+0x32/0x160
[<c01050a0>] init+0x0/0x160
[<c01070c9>] kernel_thread_helper+0x5/0xc
block=16, b_blocknr=64
b_state=0x00000019, b_size=1024
buffer layer error at fs/buffer.c:431
Call Trace:
[<c014f2b5>] __find_get_block_slow+0x85/0x120
[<c01070c9>] kernel_thread_helper+0x5/0xc
[<c010970c>] dump_stack+0x1c/0x20
[<c0150283>] __find_get_block+0x83/0xe0
[<c014fec3>] __getblk_slow+0x23/0xf0
[<c015032f>] __getblk+0x4f/0x60
[<c01503bf>] __bread+0x1f/0x40
[<c01a2172>] read_super_block+0x82/0x210
[<c01a2dd5>] reiserfs_fill_super+0x555/0x5a0
[<c01d69f7>] snprintf+0x27/0x30
[<c0154bc0>] set_blocksize+0xd0/0x110
[<c0154c25>] sb_set_blocksize+0x25/0x60
[<c0154594>] get_sb_bdev+0x124/0x160
[<c01a2e8f>] get_super_block+0x2f/0x60
[<c01a2880>] reiserfs_fill_super+0x0/0x5a0
[<c01547ff>] do_kern_mount+0x5f/0xe0
[<c0169608>] do_add_mount+0x78/0x150
[<c01698f4>] do_mount+0x124/0x170
[<c0169760>] copy_mount_options+0x80/0xf0
[<c0169caf>] sys_mount+0xbf/0x140
[<c0478b9f>] do_mount_root+0x2f/0xa0
[<c0478c64>] mount_block_root+0x54/0x120
[<c0478d8e>] mount_root+0x5e/0x70
[<c0478dbd>] prepare_namespace+0x1d/0xe0
[<c01050d2>] init+0x32/0x160
[<c01050a0>] init+0x0/0x160
[<c01070c9>] kernel_thread_helper+0x5/0xc
block=16, b_blocknr=64
b_state=0x00000019, b_size=1024
found reiserfs format "3.6" with standard journal
Thanks,
--Amos
Andrew Morton wrote:
> lkml-031028@amos.mailshell.com wrote:
>
>>[1.] One line summary of the problem:
>>
>>First time boot of 2.6.0test9 on a resierfs disk gives the error above.
>>(buffer layer error at fs/buffer.c:431)
>>
>>...
>>
>>block=16, b_blocknr=64
>>b_state=0x00000019, b_size=1024
>>buffer layer error at fs/buffer.c:431
>
>
> ah-hah.
>
>
>>Call Trace:
>> [<c014f2b5>] __find_get_block_slow+0x85/0x120
>> [<c01070c9>] kernel_thread_helper+0x5/0xc
>> [<c010970c>] dump_stack+0x1c/0x20
>> [<c0150283>] __find_get_block+0x83/0xe0
>> [<c014fec3>] __getblk_slow+0x23/0xf0
>> [<c015032f>] __getblk+0x4f/0x60
>> [<c01503bf>] __bread+0x1f/0x40
>> [<c01a2132>] read_super_block+0x82/0x210
>> [<c01a2d95>] reiserfs_fill_super+0x555/0x5a0
>> [<c01d69b7>] snprintf+0x27/0x30
>> [<c017bce2>] disk_name+0x62/0xb0
>> [<c0154bc5>] sb_set_blocksize+0x25/0x60
>> [<c0154594>] get_sb_bdev+0x124/0x160
>> [<c01a2e4f>] get_super_block+0x2f/0x60
>> [<c01a2840>] reiserfs_fill_super+0x0/0x5a0
>> [<c01547ff>] do_kern_mount+0x5f/0xe0
>> [<c01695c8>] do_add_mount+0x78/0x150
>> [<c01698b4>] do_mount+0x124/0x170
>> [<c0169720>] copy_mount_options+0x80/0xf0
>> [<c0169c6f>] sys_mount+0xbf/0x140
>> [<c0462b9f>] do_mount_root+0x2f/0xa0
>> [<c0462c64>] mount_block_root+0x54/0x120
>> [<c0462d8e>] mount_root+0x5e/0x70
>> [<c0462dbd>] prepare_namespace+0x1d/0xe0
>> [<c01050d2>] init+0x32/0x160
>> [<c01050a0>] init+0x0/0x160
>> [<c01070c9>] kernel_thread_helper+0x5/0xc
>
>
> I've been waiting a year for someone who can reproduce this.
>
> The filesystem is trying to read the 4k block at offset 16*4k.
>
> But someone had previously read the 1k block at offset 64*1k. It is an
> alias of the 4k read.
>
> We _should_ have shot down the four 1k-sized buffer_heads which are
> attached to the offset=16 pagecache page before trying to read it with 4k
> blocksize.
>
> But for some reason, that page still has the 1k-sized buffer_heads.
>
> This means that somehow, somewhere, we failed to successfully run
> set_blocksize() against that disk.
>
> Are you using initrd?
>
> Could you please add this patch, and send the new dmesg output?
>
>
> 25-akpm/fs/block_dev.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff -puN fs/block_dev.c~a fs/block_dev.c
> --- 25/fs/block_dev.c~a Tue Oct 28 14:11:20 2003
> +++ 25-akpm/fs/block_dev.c Tue Oct 28 14:11:24 2003
> @@ -50,17 +50,26 @@ int set_blocksize(struct block_device *b
> {
> int oldsize;
>
> + printk("%s: size=%d\n", __FUNCTION__, size);
> +
> /* Size must be a power of two, and between 512 and PAGE_SIZE */
> - if (size > PAGE_SIZE || size < 512 || (size & (size-1)))
> + if (size > PAGE_SIZE || size < 512 || (size & (size-1))) {
> + printk("%s: EINVAL 1\n", __FUNCTION__);
> return -EINVAL;
> + }
>
> /* Size cannot be smaller than the size supported by the device */
> - if (size < bdev_hardsect_size(bdev))
> + if (size < bdev_hardsect_size(bdev)) {
> + printk("%s: %d < %d\n", __FUNCTION__, size,
> + bdev_hardsect_size(bdev));
> return -EINVAL;
> + }
>
> oldsize = bdev->bd_block_size;
> - if (oldsize == size)
> + if (oldsize == size) {
> + printk("%s: %d OK\n", __FUNCTION__, size);
> return 0;
> + }
>
> /* Ok, we're actually changing the blocksize.. */
> sync_blockdev(bdev);
>
> _
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-29 17:44 ` lkml-031028
@ 2003-10-29 20:31 ` Andrew Morton
2003-10-29 21:49 ` Oleg Drokin
0 siblings, 1 reply; 37+ messages in thread
From: Andrew Morton @ 2003-10-29 20:31 UTC (permalink / raw)
To: lkml-031028; +Cc: linux-kernel
lkml-031028@amos.mailshell.com wrote:
>
> Here are the results (output of dmesg) from booting a kernel with this
> patch:
>
> set_blocksize: size=1024
> set_blocksize: 1024 OK
> set_blocksize: size=1024
> set_blocksize: 1024 OK
> set_blocksize: size=1024
> set_blocksize: 1024 OK
> set_blocksize: size=1024
> set_blocksize: 1024 OK
> set_blocksize: size=4096
> buffer layer error at fs/buffer.c:431
hm, that didn't tell us much :(
Could you add Oleg's patch as well?
--- 25/fs/buffer.c~extra-buffer-diags Wed Oct 29 12:13:40 2003
+++ 25-akpm/fs/buffer.c Wed Oct 29 12:14:58 2003
@@ -428,6 +428,7 @@ __find_get_block_slow(struct block_devic
printk("block=%llu, b_blocknr=%llu\n",
(unsigned long long)block, (unsigned long long)bh->b_blocknr);
printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size);
+ printk("device blocksize: %d\n", 1 << bd_inode->i_blkbits);
out_unlock:
spin_unlock(&bd_mapping->private_lock);
page_cache_release(page);
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-29 20:31 ` Andrew Morton
@ 2003-10-29 21:49 ` Oleg Drokin
2003-10-29 22:19 ` Andrew Morton
0 siblings, 1 reply; 37+ messages in thread
From: Oleg Drokin @ 2003-10-29 21:49 UTC (permalink / raw)
To: linux-kernel, akpm
Hello!
Andrew Morton <akpm@osdl.org> wrote:
>> Here are the results (output of dmesg) from booting a kernel with this
>> patch:
>> set_blocksize: size=4096
>> buffer layer error at fs/buffer.c:431
AM> hm, that didn't tell us much :(
AM> Could you add Oleg's patch as well?
Actually it will say that device's block size is 4096 (confirming
last set_blocksize was at least partially succesful), but what
it does not tell us is how those buffers have survived after blocksize
was changed and all buffers were invalidated.
(These buffers are there because reiserfs first reads that offset (in bytes)
with whatever current blocksize is, except they should have been invalidated of
course).
Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
everything, truncate_inode_pages() should have done this.
So probably this page means do_invalidate_page() ... -> try_to_free_buffers()
have failed for whatever reason.
We did not write there yet, so this is not PageWriteback case.
But if the read is still going on, I guess we won't free the page/buffers?
Or am I missing some wait_on_buffer()?
But anyway that might explains buffers being still in page, but not such
a page present in a mapping. (except if we have not pickup this page from a list
of free pages not looking that it still have stale buffers)
Bye,
Oleg
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-29 21:49 ` Oleg Drokin
@ 2003-10-29 22:19 ` Andrew Morton
2003-10-30 6:22 ` lkml-031028
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Andrew Morton @ 2003-10-29 22:19 UTC (permalink / raw)
To: Oleg Drokin; +Cc: linux-kernel, lkml-031028
Oleg Drokin <green@linuxhacker.ru> wrote:
>
> Hello!
>
> Andrew Morton <akpm@osdl.org> wrote:
> >> Here are the results (output of dmesg) from booting a kernel with this
> >> patch:
> >> set_blocksize: size=4096
> >> buffer layer error at fs/buffer.c:431
> AM> hm, that didn't tell us much :(
> AM> Could you add Oleg's patch as well?
>
> Actually it will say that device's block size is 4096 (confirming
> last set_blocksize was at least partially succesful),
Assuming that the printk is for the correct filesystem, yes.
> but what
> it does not tell us is how those buffers have survived after blocksize
> was changed and all buffers were invalidated.
Well reiserfs shouldn't be doing this:
bh = sb_bread (s, offset / s->s_blocksize);
...
sb_set_blocksize (s, sb_blocksize(rs));
brelse (bh);
but still, truncate_inode_pages() should be removing all those pages
unconditionally.
> (These buffers are there because reiserfs first reads that offset (in bytes)
> with whatever current blocksize is, except they should have been invalidated of
> course).
> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
> everything, truncate_inode_pages() should have done this.
yup.
> So probably this page means do_invalidate_page() ... -> try_to_free_buffers()
> have failed for whatever reason.
See the pinned buffer, above.
> We did not write there yet, so this is not PageWriteback case.
> But if the read is still going on, I guess we won't free the page/buffers?
> Or am I missing some wait_on_buffer()?
> But anyway that might explains buffers being still in page, but not such
> a page present in a mapping. (except if we have not pickup this page from a list
> of free pages not looking that it still have stale buffers)
Yes, the page should have been removed from the mapping.
Amos, could you add this as well?
25-akpm/mm/truncate.c | 8 ++++++++
1 files changed, 8 insertions(+)
diff -puN mm/truncate.c~truncate_inode_pages-check mm/truncate.c
--- 25/mm/truncate.c~truncate_inode_pages-check Wed Oct 29 14:13:43 2003
+++ 25-akpm/mm/truncate.c Wed Oct 29 14:15:06 2003
@@ -174,6 +174,14 @@ void truncate_inode_pages(struct address
}
pagevec_release(&pvec);
}
+
+ if (lstart == 0) {
+ WARN_ON(mapping->nrpages);
+ WARN_ON(!list_empty(&mapping->clean_pages));
+ WARN_ON(!list_empty(&mapping->dirty_pages));
+ WARN_ON(!list_empty(&mapping->locked_pages));
+ WARN_ON(!list_empty(&mapping->io_pages));
+ }
}
EXPORT_SYMBOL(truncate_inode_pages);
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-29 22:19 ` Andrew Morton
@ 2003-10-30 6:22 ` lkml-031028
2003-10-30 6:51 ` lkml-031028
2003-11-02 7:17 ` Herbert Xu
2 siblings, 0 replies; 37+ messages in thread
From: lkml-031028 @ 2003-10-30 6:22 UTC (permalink / raw)
To: linux-kernel
Andrew Morton wrote:
> Oleg Drokin <green@linuxhacker.ru> wrote:
>
>>Hello!
>>
>>Andrew Morton <akpm@osdl.org> wrote:
>>
>>>>Here are the results (output of dmesg) from booting a kernel with this
>>>>patch:
>>>>set_blocksize: size=4096
>>>>buffer layer error at fs/buffer.c:431
>>
>>AM> hm, that didn't tell us much :(
>>AM> Could you add Oleg's patch as well?
>>
>>Actually it will say that device's block size is 4096 (confirming
>>last set_blocksize was at least partially succesful),
>
>
> Assuming that the printk is for the correct filesystem, yes.
I have only one filesystem - this one large ReiserFS, if that's
the question. Here is "fdisk -l":
Disk /dev/hda: 81.9 GB, 81963220480 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 1 122 979933+ 82 Linux swap
/dev/hda2 123 9964 79055865 83 Linux
> Amos, could you add this as well?
I'm compiling ther kernel with this patch (and Andrew's previous two
patches) as I write this.
Thanks,
--Amos
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-29 22:19 ` Andrew Morton
2003-10-30 6:22 ` lkml-031028
@ 2003-10-30 6:51 ` lkml-031028
2003-11-02 7:17 ` Herbert Xu
2 siblings, 0 replies; 37+ messages in thread
From: lkml-031028 @ 2003-10-30 6:51 UTC (permalink / raw)
To: linux-kernel
Andrew Morton wrote:
> Amos, could you add this as well?
Here are the results from a kernel compiled with all your patches (3
so far).
The WARN_ON stuff doesn't seem to emit anything (looked for "Badness").
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=1024
set_blocksize: 1024 OK
set_blocksize: size=4096
buffer layer error at fs/buffer.c:431
Call Trace:
[<c014ff44>] __find_get_block_slow+0x94/0x150
[<c0150f43>] __find_get_block+0x83/0xe0
[<c0150fcb>] __getblk+0x2b/0x60
[<c015107f>] __bread+0x1f/0x40
[<c01a3532>] read_super_block+0x82/0x210
[<c01a4195>] reiserfs_fill_super+0x555/0x5a0
[<c01d7eb7>] snprintf+0x27/0x30
[<c0155880>] set_blocksize+0xd0/0x110
[<c01558e5>] sb_set_blocksize+0x25/0x60
[<c0155254>] get_sb_bdev+0x124/0x160
[<c01a424f>] get_super_block+0x2f/0x60
[<c01a3c40>] reiserfs_fill_super+0x0/0x5a0
[<c01554bf>] do_kern_mount+0x5f/0xe0
[<c016a7c8>] do_add_mount+0x78/0x150
[<c016aab4>] do_mount+0x124/0x170
[<c016a920>] copy_mount_options+0x80/0xf0
[<c016ae6f>] sys_mount+0xbf/0x140
[<c047cb9f>] do_mount_root+0x2f/0xa0
[<c047cc64>] mount_block_root+0x54/0x120
[<c047cd8e>] mount_root+0x5e/0x70
[<c047cdbd>] prepare_namespace+0x1d/0xe0
[<c01050d2>] init+0x32/0x160
[<c01050a0>] init+0x0/0x160
[<c01070c9>] kernel_thread_helper+0x5/0xc
block=16, b_blocknr=64
b_state=0x00000019, b_size=1024
device blocksize: 4096
buffer layer error at fs/buffer.c:431
Call Trace:
[<c014ff44>] __find_get_block_slow+0x94/0x150
[<c01070c9>] kernel_thread_helper+0x5/0xc
[<c010970c>] dump_stack+0x1c/0x20
[<c0150f43>] __find_get_block+0x83/0xe0
[<c0150b73>] __getblk_slow+0x23/0xf0
[<c0150fef>] __getblk+0x4f/0x60
[<c015107f>] __bread+0x1f/0x40
[<c01a3532>] read_super_block+0x82/0x210
[<c01a4195>] reiserfs_fill_super+0x555/0x5a0
[<c01d7eb7>] snprintf+0x27/0x30
[<c0155880>] set_blocksize+0xd0/0x110
[<c01558e5>] sb_set_blocksize+0x25/0x60
[<c0155254>] get_sb_bdev+0x124/0x160
[<c01a424f>] get_super_block+0x2f/0x60
[<c01a3c40>] reiserfs_fill_super+0x0/0x5a0
[<c01554bf>] do_kern_mount+0x5f/0xe0
[<c016a7c8>] do_add_mount+0x78/0x150
[<c016aab4>] do_mount+0x124/0x170
[<c016a920>] copy_mount_options+0x80/0xf0
[<c016ae6f>] sys_mount+0xbf/0x140
[<c047cb9f>] do_mount_root+0x2f/0xa0
[<c047cc64>] mount_block_root+0x54/0x120
[<c047cd8e>] mount_root+0x5e/0x70
[<c047cdbd>] prepare_namespace+0x1d/0xe0
[<c01050d2>] init+0x32/0x160
[<c01050a0>] init+0x0/0x160
[<c01070c9>] kernel_thread_helper+0x5/0xc
block=16, b_blocknr=64
b_state=0x00000019, b_size=1024
device blocksize: 4096
found reiserfs format "3.6" with standard journal
hub 1-0:1.0: debounce: port 3: delay 100ms stable 4 status 0x501
ehci_hcd 0000:00:02.2: port 3 full speed --> companion
ehci_hcd 0000:00:02.2: GetStatus port 3 status 003001 POWER OWNER
sig=se0 CONNECT
Reiserfs journal params: device hda2, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
reiserfs: checking transaction log (hda2) for (hda2)
Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 404k freed
set_blocksize: size=4096
Thanks,
--Amos
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-10-29 22:19 ` Andrew Morton
2003-10-30 6:22 ` lkml-031028
2003-10-30 6:51 ` lkml-031028
@ 2003-11-02 7:17 ` Herbert Xu
2003-11-02 7:33 ` Andrew Morton
2 siblings, 1 reply; 37+ messages in thread
From: Herbert Xu @ 2003-11-02 7:17 UTC (permalink / raw)
To: Andrew Morton, Oleg Drokin, linux-kernel
Andrew Morton <akpm@osdl.org> wrote:
>
>> (These buffers are there because reiserfs first reads that offset (in bytes)
>> with whatever current blocksize is, except they should have been invalidated of
>> course).
>> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
>> everything, truncate_inode_pages() should have done this.
>
> yup.
The person who had the problem is actually using the Debian tree which
carried over a patch from 2.4 that removed the truncate_inode_pages
call in set_blocksize. So I appologise for the noise.
However, may I ask what is preventing us from achieving the goal that
the page cache backed buffer heads can be resized without throwing away
the pages?
In particular, aside from the buffer_error() call, is there any problems
with not throwing the pages away upon a resize?
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 7:17 ` Herbert Xu
@ 2003-11-02 7:33 ` Andrew Morton
2003-11-02 9:18 ` Oleg Drokin
2003-11-02 9:27 ` Herbert Xu
0 siblings, 2 replies; 37+ messages in thread
From: Andrew Morton @ 2003-11-02 7:33 UTC (permalink / raw)
To: Herbert Xu; +Cc: green, linux-kernel
Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Andrew Morton <akpm@osdl.org> wrote:
> >
> >> (These buffers are there because reiserfs first reads that offset (in bytes)
> >> with whatever current blocksize is, except they should have been invalidated of
> >> course).
> >> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
> >> everything, truncate_inode_pages() should have done this.
> >
> > yup.
>
> The person who had the problem is actually using the Debian tree which
> carried over a patch from 2.4 that removed the truncate_inode_pages
> call in set_blocksize. So I appologise for the noise.
aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
any other changes?
> However, may I ask what is preventing us from achieving the goal that
> the page cache backed buffer heads can be resized without throwing away
> the pages?
That _should_ work. The pagecache pages should be in such a state that all
buffers are freeable and yes, we can leave the pagecache there. But this
could cause problems if the device was repartitioned in between, or if it
was hotswapped. I don't think we shoot down pagecache anywhere else for
this.
truncate_inode_pages() will unconditionally remove the pages from
pagecache: they're gone. So if some poorly behaved piece of code
(reiserfs's read_super_block()) holds a reference against a buffer, that
piece of code ends up owning the page - the VFS has lost interest in it.
This is almost always very bad - if truncate_inode_pages() against a
blockdev fails to cleanly remove all pages then it often means memory
leakage or data corruption. I would like to have a warning which detects
this case but I never got around to it.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 7:33 ` Andrew Morton
@ 2003-11-02 9:18 ` Oleg Drokin
2003-11-02 9:27 ` Herbert Xu
1 sibling, 0 replies; 37+ messages in thread
From: Oleg Drokin @ 2003-11-02 9:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: Herbert Xu, linux-kernel
Hello!
On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
> > >> (These buffers are there because reiserfs first reads that offset (in bytes)
> > >> with whatever current blocksize is, except they should have been invalidated of
> > >> course).
> > >> Even if invalidate_bdev() -> invalidate_inode_pages() have not cleaned
> > >> everything, truncate_inode_pages() should have done this.
> > > yup.
> > The person who had the problem is actually using the Debian tree which
> > carried over a patch from 2.4 that removed the truncate_inode_pages
> > call in set_blocksize. So I appologise for the noise.
Sigh.
> truncate_inode_pages() will unconditionally remove the pages from
> pagecache: they're gone. So if some poorly behaved piece of code
> (reiserfs's read_super_block()) holds a reference against a buffer, that
> piece of code ends up owning the page - the VFS has lost interest in it.
Here's the patch against reiserfs in 2.6 (2.4 does not need it as this bit
of code is different and correct there).
===== fs/reiserfs/super.c 1.69 vs edited =====
--- 1.69/fs/reiserfs/super.c Tue Sep 23 07:16:25 2003
+++ edited/fs/reiserfs/super.c Sun Nov 2 11:11:36 2003
@@ -942,6 +942,7 @@
{
struct buffer_head * bh;
struct reiserfs_super_block * rs;
+ int fs_blocksize;
bh = sb_bread (s, offset / s->s_blocksize);
@@ -961,8 +962,9 @@
//
// ok, reiserfs signature (old or new) found in at the given offset
//
- sb_set_blocksize (s, sb_blocksize(rs));
+ fs_blocksize = sb_blocksize(rs);
brelse (bh);
+ sb_set_blocksize (s, fs_blocksize);
bh = sb_bread (s, offset / s->s_blocksize);
if (!bh) {
Bye,
Oleg
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 7:33 ` Andrew Morton
2003-11-02 9:18 ` Oleg Drokin
@ 2003-11-02 9:27 ` Herbert Xu
2003-11-02 9:40 ` Andrew Morton
2003-11-02 11:50 ` Hans Reiser
1 sibling, 2 replies; 37+ messages in thread
From: Herbert Xu @ 2003-11-02 9:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
>
> aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
> any other changes?
Yes we are. You can find the changes in
http://http.us.debian.org/debian/pool/main/k/kernel-source-2.6.0-test9/
> That _should_ work. The pagecache pages should be in such a state that all
> buffers are freeable and yes, we can leave the pagecache there. But this
> could cause problems if the device was repartitioned in between, or if it
> was hotswapped. I don't think we shoot down pagecache anywhere else for
> this.
Yes, however it should be safe to stop set_blocksize from calling
truncate_inode_pages, right?
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 9:27 ` Herbert Xu
@ 2003-11-02 9:40 ` Andrew Morton
2003-11-02 9:54 ` Herbert Xu
2003-11-02 11:50 ` Hans Reiser
1 sibling, 1 reply; 37+ messages in thread
From: Andrew Morton @ 2003-11-02 9:40 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-kernel
Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
> >
> > aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
> > any other changes?
>
> Yes we are. You can find the changes in
>
> http://http.us.debian.org/debian/pool/main/k/kernel-source-2.6.0-test9/
Where are the separated patches?
That's 170k of stuff you're sitting on. Is there any plan to get it synced
up?
> > That _should_ work. The pagecache pages should be in such a state that all
> > buffers are freeable and yes, we can leave the pagecache there. But this
> > could cause problems if the device was repartitioned in between, or if it
> > was hotswapped. I don't think we shoot down pagecache anywhere else for
> > this.
>
> Yes, however it should be safe to stop set_blocksize from calling
> truncate_inode_pages, right?
No, because _something_ has to rub out the wrong-sized buffer_heads. One
could add some new function which walks the pagecache and removes the
buffer_heads from the pages, leaving the pages there. There doesn't seem a
lot of point in it though?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 9:40 ` Andrew Morton
@ 2003-11-02 9:54 ` Herbert Xu
2003-11-02 11:54 ` Hans Reiser
0 siblings, 1 reply; 37+ messages in thread
From: Herbert Xu @ 2003-11-02 9:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]
On Sun, Nov 02, 2003 at 01:40:11AM -0800, Andrew Morton wrote:
>
> Where are the separated patches?
There are no separate patches. You can check the README.Debian file
for the details of the changes.
> That's 170k of stuff you're sitting on. Is there any plan to get it synced
> up?
I submit them as they come in. The bulk of the size comes from the
making IDE modules work which isn't right yet.
The rest of them which are suitable for general consumption have
been submitted previously. I will resend them later.
> No, because _something_ has to rub out the wrong-sized buffer_heads. One
> could add some new function which walks the pagecache and removes the
> buffer_heads from the pages, leaving the pages there. There doesn't seem a
> lot of point in it though?
Actually grow_dev_page will free the wrong-sized ones.
It seems that the only problem is that we don't check the size in
__find_get_block_slow(). So what about this patch?
The point of all this is to avoid unnecessary reads, and more importantly
preserve the contents of RAM disks when someone calls set_blocksize().
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: p --]
[-- Type: text/plain, Size: 1543 bytes --]
Index: kernel-source-2.5/fs/buffer.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/fs/buffer.c,v
retrieving revision 1.1.1.15
diff -u -r1.1.1.15 buffer.c
--- kernel-source-2.5/fs/buffer.c 8 Oct 2003 19:24:14 -0000 1.1.1.15
+++ kernel-source-2.5/fs/buffer.c 2 Nov 2003 09:54:07 -0000
@@ -400,7 +400,7 @@
* private_lock is contended then so is mapping->page_lock).
*/
static struct buffer_head *
-__find_get_block_slow(struct block_device *bdev, sector_t block, int unused)
+__find_get_block_slow(struct block_device *bdev, sector_t block, int size)
{
struct inode *bd_inode = bdev->bd_inode;
struct address_space *bd_mapping = bd_inode->i_mapping;
@@ -419,6 +419,8 @@
if (!page_has_buffers(page))
goto out_unlock;
head = page_buffers(page);
+ if (head->b_size != size)
+ goto out_unlock;
bh = head;
do {
if (bh->b_blocknr == block) {
Index: kernel-source-2.5/fs/block_dev.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/fs/block_dev.c,v
retrieving revision 1.1.1.15
retrieving revision 1.15
diff -u -r1.1.1.15 -r1.15
--- kernel-source-2.5/fs/block_dev.c 8 Oct 2003 19:24:53 -0000 1.1.1.15
+++ kernel-source-2.5/fs/block_dev.c 11 Oct 2003 06:29:24 -0000 1.15
@@ -66,7 +66,7 @@
sync_blockdev(bdev);
bdev->bd_block_size = size;
bdev->bd_inode->i_blkbits = blksize_bits(size);
- kill_bdev(bdev);
+ invalidate_bdev(bdev, 1);
return 0;
}
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 9:27 ` Herbert Xu
2003-11-02 9:40 ` Andrew Morton
@ 2003-11-02 11:50 ` Hans Reiser
2003-11-02 20:33 ` Herbert Xu
1 sibling, 1 reply; 37+ messages in thread
From: Hans Reiser @ 2003-11-02 11:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: Andrew Morton, linux-kernel
Herbert Xu wrote:
>On Sat, Nov 01, 2003 at 11:33:54PM -0800, Andrew Morton wrote:
>
>
>>aargh. I thought Debian's 2.6 kernels were unmodified. Are they carrying
>>any other changes?
>>
>>
>
>Yes we are. You can find the changes in
>
>http://http.us.debian.org/debian/pool/main/k/kernel-source-2.6.0-test9/
>
>
>
>
Why are you guys modifying the official kernel? Are you seeking
advantage over the other distros or? This was one of the nice things
about debian, that it didn't have unofficial destabilizing stuff in the
kernel like the other distros.
--
Hans
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 9:54 ` Herbert Xu
@ 2003-11-02 11:54 ` Hans Reiser
2003-11-02 21:09 ` Herbert Xu
0 siblings, 1 reply; 37+ messages in thread
From: Hans Reiser @ 2003-11-02 11:54 UTC (permalink / raw)
To: Herbert Xu; +Cc: Andrew Morton, linux-kernel
Herbert Xu wrote:
>On Sun, Nov 02, 2003 at 01:40:11AM -0800, Andrew Morton wrote:
>
>
>>Where are the separated patches?
>>
>>
>
>There are no separate patches. You can check the README.Debian file
>for the details of the changes.
>
>
>
>>That's 170k of stuff you're sitting on. Is there any plan to get it synced
>>up?
>>
>>
>
>I submit them as they come in. The bulk of the size comes from the
>making IDE modules work which isn't right yet.
>
>The rest of them which are suitable for general consumption have
>been submitted previously. I will resend them later.
>
>
Why in the world do you guys do this? Andrew and Marcelo do a good job,
and I haven't heard much complaint about patches being ignored by them,
so follow the leader. If you have patches you need, send them to them.
--
Hans
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 11:50 ` Hans Reiser
@ 2003-11-02 20:33 ` Herbert Xu
0 siblings, 0 replies; 37+ messages in thread
From: Herbert Xu @ 2003-11-02 20:33 UTC (permalink / raw)
To: Hans Reiser; +Cc: Andrew Morton, linux-kernel
On Sun, Nov 02, 2003 at 02:50:17PM +0300, Hans Reiser wrote:
>
> Why are you guys modifying the official kernel? Are you seeking
> advantage over the other distros or? This was one of the nice things
> about debian, that it didn't have unofficial destabilizing stuff in the
> kernel like the other distros.
I don't know where you got the idea that Debian used to distribute the
kernel as it is. Just like every other distribution, we have always
needed (mostly small) changes to the vanilla kernel.
We do send those changes suitable for general consumption to the
upstream maintainers. Whether they are accepted is an entirely
different question.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 11:54 ` Hans Reiser
@ 2003-11-02 21:09 ` Herbert Xu
2003-11-03 10:20 ` Stephan von Krawczynski
0 siblings, 1 reply; 37+ messages in thread
From: Herbert Xu @ 2003-11-02 21:09 UTC (permalink / raw)
To: Hans Reiser; +Cc: Andrew Morton, linux-kernel
On Sun, Nov 02, 2003 at 02:54:45PM +0300, Hans Reiser wrote:
>
> Why in the world do you guys do this? Andrew and Marcelo do a good job,
> and I haven't heard much complaint about patches being ignored by them,
> so follow the leader. If you have patches you need, send them to them.
Andrew and Marcelo do an excellent job. I have never said otherwise
nor attempted to infer that.
The reasons that we need patches are mostly the same as other distributions:
1. Our release schedule is different from the vanilla kernels.
When we release a kernel based on a vanilla release there may be bug
fixes that are going to be in the next vanilla release that we can
apply straight away.
2. Our goals are different from the vanilla kernel.
Some issues are not critical to the vanilla kernel, e.g., IDE modules
but are release-critical for us.
3. Licensing problems.
This is specific to Debian. For anything to be included in our release,
it has to pass the DFSG. The vanilla kernel does not have this
restriction so we may need to remove bits before it's suitable for us.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-02 21:09 ` Herbert Xu
@ 2003-11-03 10:20 ` Stephan von Krawczynski
2003-11-04 8:10 ` Hans Reiser
0 siblings, 1 reply; 37+ messages in thread
From: Stephan von Krawczynski @ 2003-11-03 10:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: reiser, akpm, linux-kernel
On Mon, 3 Nov 2003 08:09:42 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:
Forgive my comments unrelated to the primary topic, but I think additional
voices may do something good to your general idea of a distro.
> On Sun, Nov 02, 2003 at 02:54:45PM +0300, Hans Reiser wrote:
> >
> > Why in the world do you guys do this? Andrew and Marcelo do a good job,
> > and I haven't heard much complaint about patches being ignored by them,
> > so follow the leader. If you have patches you need, send them to them.
>
> Andrew and Marcelo do an excellent job. I have never said otherwise
> nor attempted to infer that.
>
> The reasons that we need patches are mostly the same as other distributions:
>
> 1. Our release schedule is different from the vanilla kernels.
>
> When we release a kernel based on a vanilla release there may be bug
> fixes that are going to be in the next vanilla release that we can
> apply straight away.
Release cycle of vanilla kernels has become short/acceptable again, so it
should be possible to pick one up inside your timeframe. And yes, there will
always be another bug, so if you go hunting for only the next bugfix, you will
probably be releasing never again.
> 2. Our goals are different from the vanilla kernel.
>
> Some issues are not critical to the vanilla kernel, e.g., IDE modules
> but are release-critical for us.
You are talking about an additional _feature_. Why don't you try to make it an
accepted and implemented feature in the vanilla kernels? Sure this may take a
bit more time, but the community wins as a whole. I cannot see the point in
_separation_ regarding GPL'ed software.
> 3. Licensing problems.
>
> This is specific to Debian. For anything to be included in our release,
> it has to pass the DFSG. The vanilla kernel does not have this
> restriction so we may need to remove bits before it's suitable for us.
Uh? Do you place licensing restrictions on a GPL'ed kernel??
I really send prayers for the day distros will stop building own kernels for
they only reduce the installed test base for kernels as a whole by splitting it
up in numerous kernel versions...
Regards,
Stephan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-03 10:20 ` Stephan von Krawczynski
@ 2003-11-04 8:10 ` Hans Reiser
2003-11-04 21:03 ` Debian Kernels was: " Mike Fedyk
0 siblings, 1 reply; 37+ messages in thread
From: Hans Reiser @ 2003-11-04 8:10 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Herbert Xu, akpm, linux-kernel
Stephan von Krawczynski wrote:
>
>
>I really send prayers for the day distros will stop building own kernels for
>they only reduce the installed test base for kernels as a whole by splitting it
>up in numerous kernel versions...
>
>Regards,
>Stephan
>
>
>
>
>
Amen. Since Debian is a not for profit organization, it really should
not be doing this.
--
Hans
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-04 21:03 ` Debian Kernels was: " Mike Fedyk
@ 2003-11-04 9:54 ` Hans Reiser
2003-11-04 23:49 ` Stephan von Krawczynski
1 sibling, 0 replies; 37+ messages in thread
From: Hans Reiser @ 2003-11-04 9:54 UTC (permalink / raw)
To: Mike Fedyk; +Cc: Stephan von Krawczynski, Herbert Xu, akpm, linux-kernel
Mike Fedyk wrote:
> Just because Debian is
>
>completely OSS and maintained mostly by unpaid volunteers, that shouldn't keep
>them from having a seperate tree like everyone else.
>
>
Yes it should. They have less fiscal motivation to horde software than
other distros, and a distro having it's own tree is a mild version of
software hording in which you don't do anything legally to stop others
from copying your code but you don't do the work necessary for them to
share in it either.
--
Hans
^ permalink raw reply [flat|nested] 37+ messages in thread
* Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-04 8:10 ` Hans Reiser
@ 2003-11-04 21:03 ` Mike Fedyk
2003-11-04 9:54 ` Hans Reiser
2003-11-04 23:49 ` Stephan von Krawczynski
0 siblings, 2 replies; 37+ messages in thread
From: Mike Fedyk @ 2003-11-04 21:03 UTC (permalink / raw)
To: Hans Reiser; +Cc: Stephan von Krawczynski, Herbert Xu, akpm, linux-kernel
> Stephan von Krawczynski wrote:
> >I really send prayers for the day distros will stop building own kernels
> >for
> >they only reduce the installed test base for kernels as a whole by
> >splitting it
> >up in numerous kernel versions...
On Tue, Nov 04, 2003 at 12:10:45AM -0800, Hans Reiser wrote:
> Amen. Since Debian is a not for profit organization, it really should
> not be doing this.
Ok guys, this has gotten pretty far OT.
Being a debian user since Dec 1998 (first and only distro), I might be able
to explain some things.
Debian is not trying to relicense any GPLed code, but it does have another
guide it follows as to what it will include in a Debian release; the DFSG -
Debian Free Software Guide.
Some licenses that are considered compatible with the GPL on LKML are not in
the DFSG. I believe the latest one is the GNU Documentation License, but
that's still being argued about...
I have been using official Debian packages for everything except for the
kernel. First because I wanted to test the -pre, -mm, -aa, and other
kernels, and second that I didn't like the vesafb that was turned on by
default.
I'd love to see the 'initrd on cramfs' patch merged into the vanilla kernel
though. :)
Now, let's try to get it back On Topic...
There was a bug in one of the released Debian kernels, and do you think this
hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
completely OSS and maintained mostly by unpaid volunteers, that shouldn't keep
them from having a seperate tree like everyone else.
I'd like to see each vendor tree as small as possible. And Debian's may be
the smallest vendor tree AFAIK they haven't merged XFS into their 2.4 tree.
But think about this. Linus wants to see features have a large user base
before merging many outside kernel projects, and vendor kernels are one way
to show a project is popular.
It's bad enough that there are over 5 other distros based on Debian, and
only now are any of them contributing back to the installer, and maybe we
will get some hardware detection out of Knoppix!
So, has this bug been fixed? And if not, what other patches are needed to
test more?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-04 21:03 ` Debian Kernels was: " Mike Fedyk
2003-11-04 9:54 ` Hans Reiser
@ 2003-11-04 23:49 ` Stephan von Krawczynski
2003-11-05 0:05 ` Mike Fedyk
2003-11-16 13:05 ` Pavel Machek
1 sibling, 2 replies; 37+ messages in thread
From: Stephan von Krawczynski @ 2003-11-04 23:49 UTC (permalink / raw)
To: Mike Fedyk; +Cc: reiser, herbert, akpm, linux-kernel
On Tue, 4 Nov 2003 13:03:10 -0800
Mike Fedyk <mfedyk@matchmail.com> wrote:
> There was a bug in one of the released Debian kernels, and do you think this
> hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
> completely OSS and maintained mostly by unpaid volunteers, that shouldn't
> keep them from having a seperate tree like everyone else.
Just to avoid a false impression: I am in no way against debian project nor do
I say there is anything specifically bad about it. I am generally disliking
distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
Hat may find arguments for that which are commercially backed, debian on the
other hand can hardly argue commercially. From the community point of view it
is just nonsense. It means more work and less useable feedback.
Bugs is distro kernels are (always) the sole fault of their respective
maintainers because they actively decided _not_ to follow the mainstream and
made bogus patches. Why waste the appreciated work of (unpaid) debian
volunteers in this area? There are tons of other work left with far more
relevance for users than bleeding edge kernel patches...
And if you really insist to pick up the tough pieces around kernel then find
out why 2.4.20 is the last stable netfilter implementation... for sure far more
relevant than loadable module ide code in 2.6.0-testX.
Regards,
Stephan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-04 23:49 ` Stephan von Krawczynski
@ 2003-11-05 0:05 ` Mike Fedyk
2003-11-16 13:05 ` Pavel Machek
1 sibling, 0 replies; 37+ messages in thread
From: Mike Fedyk @ 2003-11-05 0:05 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: reiser, herbert, akpm, linux-kernel
On Wed, Nov 05, 2003 at 12:49:56AM +0100, Stephan von Krawczynski wrote:
> On Tue, 4 Nov 2003 13:03:10 -0800
> Mike Fedyk <mfedyk@matchmail.com> wrote:
>
> > There was a bug in one of the released Debian kernels, and do you think this
> > hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
> > completely OSS and maintained mostly by unpaid volunteers, that shouldn't
> > keep them from having a seperate tree like everyone else.
>
> Just to avoid a false impression: I am in no way against debian project nor do
> I say there is anything specifically bad about it. I am generally disliking
> distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
> Hat may find arguments for that which are commercially backed, debian on the
> other hand can hardly argue commercially. From the community point of view it
> is just nonsense. It means more work and less useable feedback.
> Bugs is distro kernels are (always) the sole fault of their respective
> maintainers because they actively decided _not_ to follow the mainstream and
> made bogus patches. Why waste the appreciated work of (unpaid) debian
> volunteers in this area? There are tons of other work left with far more
> relevance for users than bleeding edge kernel patches...
I agree with you for the most part.
Herbert did say he submitted patches for the parts that were ready. He
didn't say if he was working with Bart and Alan on the IDE changes though.
I haven't seen any messages from him on lkml with "patch" in the subject,
but that doesn't mean he's not working with the maintianers.
Herb, what do you have to say on this?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 13:05 ` Pavel Machek
@ 2003-11-16 3:55 ` Hans Reiser
2003-11-16 14:15 ` Stephan von Krawczynski
1 sibling, 0 replies; 37+ messages in thread
From: Hans Reiser @ 2003-11-16 3:55 UTC (permalink / raw)
To: Pavel Machek
Cc: Stephan von Krawczynski, Mike Fedyk, herbert, akpm, linux-kernel
Pavel Machek wrote:
>Hi!
>
>
>
>>>There was a bug in one of the released Debian kernels, and do you think this
>>>hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
>>>completely OSS and maintained mostly by unpaid volunteers, that shouldn't
>>>keep them from having a seperate tree like everyone else.
>>>
>>>
>>Just to avoid a false impression: I am in no way against debian project nor do
>>I say there is anything specifically bad about it. I am generally disliking
>>distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
>>Hat may find arguments for that which are commercially backed, debian on the
>>other hand can hardly argue commercially. From the community point of view it
>>is just nonsense. It means more work and less useable feedback.
>>Bugs is distro kernels are (always) the sole fault of their respective
>>maintainers because they actively decided _not_ to follow the mainstream and
>>made bogus patches. Why waste the appreciated work of (unpaid) debian
>>volunteers in this area? There are tons of other work left with far more
>>relevance for users than bleeding edge kernel patches...
>>
>>
>
>
>Debian is distibution; distributions are _expected_ to fix bugs (etc)
>in their packages.
>
>
not in their packages, but in their packaging, and to submit bug fixes
to the maintainers.
>If distribution had all packages unmodified, it would be useless...
>
>
not at all.
>So I'd expect all distros to have at least some changes in their
>kernel... the same way I expect distros to have some patches in
>midnight commander etc.
>
>Of course it is good to keep the .diff as small as possible.
> Pavel
>
>
I just want to say that I would happily do 10 times as much work to keep
things working for debian, but not using the vanilla kernel is a mistake
for debian, just as changing, say, xmms without involving the xmms
maintainer would be a mistake and more likely to cause bugs for users.
Just because SuSE and RedHat have lots of money doesn't mean that debian
should ape their mistakes.
--
Hans
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-04 23:49 ` Stephan von Krawczynski
2003-11-05 0:05 ` Mike Fedyk
@ 2003-11-16 13:05 ` Pavel Machek
2003-11-16 3:55 ` Hans Reiser
2003-11-16 14:15 ` Stephan von Krawczynski
1 sibling, 2 replies; 37+ messages in thread
From: Pavel Machek @ 2003-11-16 13:05 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Mike Fedyk, reiser, herbert, akpm, linux-kernel
Hi!
> > There was a bug in one of the released Debian kernels, and do you think this
> > hasn't happened with Redhat, SuSe, or Mandrake? Just because Debian is
> > completely OSS and maintained mostly by unpaid volunteers, that shouldn't
> > keep them from having a seperate tree like everyone else.
>
> Just to avoid a false impression: I am in no way against debian project nor do
> I say there is anything specifically bad about it. I am generally disliking
> distros' ideas of having _own_ kernels. Commercial companies like SuSE or Red
> Hat may find arguments for that which are commercially backed, debian on the
> other hand can hardly argue commercially. From the community point of view it
> is just nonsense. It means more work and less useable feedback.
> Bugs is distro kernels are (always) the sole fault of their respective
> maintainers because they actively decided _not_ to follow the mainstream and
> made bogus patches. Why waste the appreciated work of (unpaid) debian
> volunteers in this area? There are tons of other work left with far more
> relevance for users than bleeding edge kernel patches...
Debian is distibution; distributions are _expected_ to fix bugs (etc)
in their packages.
If distribution had all packages unmodified, it would be useless...
So I'd expect all distros to have at least some changes in their
kernel... the same way I expect distros to have some patches in
midnight commander etc.
Of course it is good to keep the .diff as small as possible.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 13:05 ` Pavel Machek
2003-11-16 3:55 ` Hans Reiser
@ 2003-11-16 14:15 ` Stephan von Krawczynski
2003-11-16 17:05 ` Pavel Machek
1 sibling, 1 reply; 37+ messages in thread
From: Stephan von Krawczynski @ 2003-11-16 14:15 UTC (permalink / raw)
To: Pavel Machek; +Cc: mfedyk, reiser, herbert, akpm, linux-kernel
On Sun, 16 Nov 2003 14:05:58 +0100
Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
> [...]
> > Just to avoid a false impression: I am in no way against debian project nor
> > do I say there is anything specifically bad about it. I am generally
> > disliking distros' ideas of having _own_ kernels. Commercial companies like
> > SuSE or Red Hat may find arguments for that which are commercially backed,
> > debian on the other hand can hardly argue commercially. From the community
> > point of view it is just nonsense. It means more work and less useable
> > feedback. Bugs is distro kernels are (always) the sole fault of their
> > respective maintainers because they actively decided _not_ to follow the
> > mainstream and made bogus patches. Why waste the appreciated work of
> > (unpaid) debian volunteers in this area? There are tons of other work left
> > with far more relevance for users than bleeding edge kernel patches...
>
>
> Debian is distibution; distributions are _expected_ to fix bugs (etc)
> in their packages.
I am just of the opposite opinion. It is a project maintainers' job to fix
bugs. A distributions' job is to _distribute_ packages in its pure sense.
Obviously people creating a distribution run across bugs while checking out the
projects to pack into their distro. So I very well agree they should do
_something_ about it, BUT this "something" is _not_ creating more or less
useful patches for their (and their customers) use, but get in contact with the
project maintainer and hand them the patches, look for their approval and
_then_ move the project into their distro. There is no sense in creating a
debian patched pppd, a SuSE patched pppd and a RH-patched pppd, altogether
different from the projects basic pppd. (This is not a real example, but only a
clarification of what I'd say is _the wrong way_ (tm))
> If distribution had all packages unmodified, it would be useless...
Just contrary I'd state that this would be the "perfect world", because this
would mean all projects are in perfect shape and all patches have gone to the
respective maintainers.
> So I'd expect all distros to have at least some changes in their
> kernel... the same way I expect distros to have some patches in
> midnight commander etc.
So you say midnight commanders' maintainer is an a**hole, or what?
If you think some project needs patches, then please talk to its maintainer (if
any), or get involved and become its maintainer...
I do think though, that there should be something in between, namely a place
where projects are hosted that (currently) have no maintainer, but where one
can send patches that are needed for some reason. This is a bit of a political
question, maybe OSDL can be such a place. Whatever the place is, it should be
independent to a degree.
> Of course it is good to keep the .diff as small as possible.
diffsize small is wanted.
diffsize zero is unwanted.
What kind of a logic is that?
Forgive me Pavel, that does not sound thoughtful to me.
Regards,
Stephan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 14:15 ` Stephan von Krawczynski
@ 2003-11-16 17:05 ` Pavel Machek
2003-11-16 17:27 ` Valdis.Kletnieks
2003-11-16 17:30 ` Stephan von Krawczynski
0 siblings, 2 replies; 37+ messages in thread
From: Pavel Machek @ 2003-11-16 17:05 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: mfedyk, reiser, herbert, akpm, linux-kernel
Hi!
> > If distribution had all packages unmodified, it would be useless...
>
> Just contrary I'd state that this would be the "perfect world", because this
> would mean all projects are in perfect shape and all patches have gone to the
> respective maintainers.
Okay, in the perfect world we'd have just one distribution with all
packages unmodified. Well.. but we are not there yet.
> > So I'd expect all distros to have at least some changes in their
> > kernel... the same way I expect distros to have some patches in
> > midnight commander etc.
>
> So you say midnight commanders' maintainer is an a**hole, or what?
> If you think some project needs patches, then please talk to its
Debian having diffs vs. vanilla midnight does not mean anything
negative about its maintainer: Debian well may want different default
config, for example (F3 viewer bindings came to mind).
> > Of course it is good to keep the .diff as small as possible.
>
> diffsize small is wanted.
> diffsize zero is unwanted.
> What kind of a logic is that?
>
> Forgive me Pavel, that does not sound thoughtful to me.
If there's bug in the package, I expect Debian to fix the bug and then
forward bugfix to the maintainer.
Distribution does not want to wait for maintainer to ACK, especially
if its security-related bug.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 17:05 ` Pavel Machek
@ 2003-11-16 17:27 ` Valdis.Kletnieks
2003-11-16 17:40 ` Stephan von Krawczynski
2003-11-16 17:30 ` Stephan von Krawczynski
1 sibling, 1 reply; 37+ messages in thread
From: Valdis.Kletnieks @ 2003-11-16 17:27 UTC (permalink / raw)
To: Pavel Machek
Cc: Stephan von Krawczynski, mfedyk, reiser, herbert, akpm, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
On Sun, 16 Nov 2003 18:05:09 +0100, Pavel Machek said:
> Okay, in the perfect world we'd have just one distribution with all
> packages unmodified. Well.. but we are not there yet.
Then why do we have a -mm kernel and a -ac kernel and a.....?
It's interesting that we've apparently decided that Andrew Morton or
Alan Cox or any of the other -initial kernel streams are allowed to have
different goals (and thus different code to achieve those goals) but
we seem to think that distributions are not allowed to do the same thing...
-exec-shield is OK if it shows up in Andrew's stuff, but not when it's
in the RedHat from whence it came? What's wrong with THAT?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 17:05 ` Pavel Machek
2003-11-16 17:27 ` Valdis.Kletnieks
@ 2003-11-16 17:30 ` Stephan von Krawczynski
1 sibling, 0 replies; 37+ messages in thread
From: Stephan von Krawczynski @ 2003-11-16 17:30 UTC (permalink / raw)
To: Pavel Machek; +Cc: mfedyk, reiser, herbert, akpm, linux-kernel
On Sun, 16 Nov 2003 18:05:09 +0100
Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > > If distribution had all packages unmodified, it would be useless...
> >
> > Just contrary I'd state that this would be the "perfect world", because
> > this would mean all projects are in perfect shape and all patches have gone
> > to the respective maintainers.
>
> Okay, in the perfect world we'd have just one distribution with all
> packages unmodified. Well.. but we are not there yet.
Well, why not head into the right direction at least? If we didn't try that
before we would probably have never left caves ...
> > So you say midnight commanders' maintainer is an a**hole, or what?
> > If you think some project needs patches, then please talk to its
>
> Debian having diffs vs. vanilla midnight does not mean anything
> negative about its maintainer: Debian well may want different default
> config, for example (F3 viewer bindings came to mind).
Separate config diffs from original packages into new <project-config> package.
This way one can at least try to merge a new version of some rpm with a
standard distro config. diffs don't do that all to well.
> > > Of course it is good to keep the .diff as small as possible.
> >
> > diffsize small is wanted.
> > diffsize zero is unwanted.
> > What kind of a logic is that?
> >
> > Forgive me Pavel, that does not sound thoughtful to me.
>
> If there's bug in the package, I expect Debian to fix the bug and then
> forward bugfix to the maintainer.
Sorry, if there is a bug in the package I expect the maintainer to fix it and
the distributor to help him (tell him about the problem, send patch
suggestions, whatever...).
> Distribution does not want to wait for maintainer to ACK, especially
> if its security-related bug.
This is probably one reason why quite a significant amount of
distro-patches/addons are quite questionable (at least). The distro-people
cannot accept that they see only their part of the whole picture and only
_think_ that they know perfectly well what joe-average-user wants, has and
needs. In fact they mostly have no idea.
Debian could be a real win in this area if they only avoid others'
super-smartness.
Regards,
Stephan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 17:27 ` Valdis.Kletnieks
@ 2003-11-16 17:40 ` Stephan von Krawczynski
2003-11-16 18:38 ` Valdis.Kletnieks
0 siblings, 1 reply; 37+ messages in thread
From: Stephan von Krawczynski @ 2003-11-16 17:40 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: pavel, mfedyk, reiser, herbert, akpm, linux-kernel
On Sun, 16 Nov 2003 12:27:36 -0500
Valdis.Kletnieks@vt.edu wrote:
> On Sun, 16 Nov 2003 18:05:09 +0100, Pavel Machek said:
>
> > Okay, in the perfect world we'd have just one distribution with all
> > packages unmodified. Well.. but we are not there yet.
>
> Then why do we have a -mm kernel and a -ac kernel and a.....?
>
> It's interesting that we've apparently decided that Andrew Morton or
> Alan Cox or any of the other -initial kernel streams are allowed to have
> different goals (and thus different code to achieve those goals) but
> we seem to think that distributions are not allowed to do the same thing...
There is quite a simple difference in -XX kernel and a distro-patch. People
have to actively decide to use some patched kernel for whatever their reason
may be. A distro on the other hand floods the average user with patched
versions _without_ the users' active decision.
Please keep in mind that a lot of users are not capable of compiling/installing
a new kernel. Those who are have a free decision, those who are not have simply
no choice.
> -exec-shield is OK if it shows up in Andrew's stuff, but not when it's
> in the RedHat from whence it came? What's wrong with THAT?
s.a.
Regards,
Stephan
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 17:40 ` Stephan von Krawczynski
@ 2003-11-16 18:38 ` Valdis.Kletnieks
2003-11-16 22:54 ` Stephan von Krawczynski
0 siblings, 1 reply; 37+ messages in thread
From: Valdis.Kletnieks @ 2003-11-16 18:38 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
On Sun, 16 Nov 2003 18:40:12 +0100, Stephan von Krawczynski said:
> There is quite a simple difference in -XX kernel and a distro-patch. People
> have to actively decide to use some patched kernel for whatever their reason
> may be. A distro on the other hand floods the average user with patched
> versions _without_ the users' active decision.
Take it the other direction - people *also* actively choose a distro based
on some reason (to be honest, a major reason I ended up in RedHat/Fedora
rather than some other Linux distro or even a *bsd was because at the time
I needed a *nix with an X server that supported the i810 chipset, they were
the only ones shipping one pre-built).
On the flip side, I freely admit that the vast majority of things Andrew
puts in his kernel basically get flooded to me, because installing the
entire -mm patch is a lot easier than installing half of it....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Debian Kernels was: 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431"
2003-11-16 18:38 ` Valdis.Kletnieks
@ 2003-11-16 22:54 ` Stephan von Krawczynski
0 siblings, 0 replies; 37+ messages in thread
From: Stephan von Krawczynski @ 2003-11-16 22:54 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
On Sun, 16 Nov 2003 13:38:44 -0500
Valdis.Kletnieks@vt.edu wrote:
> On Sun, 16 Nov 2003 18:40:12 +0100, Stephan von Krawczynski said:
>
> > There is quite a simple difference in -XX kernel and a distro-patch. People
> > have to actively decide to use some patched kernel for whatever their
> > reason may be. A distro on the other hand floods the average user with
> > patched versions _without_ the users' active decision.
>
> Take it the other direction - people *also* actively choose a distro based
> on some reason (to be honest, a major reason I ended up in RedHat/Fedora
> rather than some other Linux distro or even a *bsd was because at the time
> I needed a *nix with an X server that supported the i810 chipset, they were
> the only ones shipping one pre-built).
Well, this is a good point to explain that some people choose their favourite
distro based on completely other criteria one might expect. I choose mine
because it was a european company and I found it acceptable to make a
"political decision" rather than a pure technical one. In a market that is as
imbalanced as IT towards US companies it sounded like the right thing to do for
me.
Unfortunately US companies have this special capability of reducing your choice
as a customer right down to (almost) zero - which is of course their simple
right in a free market environment.
And this is about the point where the debian project enters my picture ...
> On the flip side, I freely admit that the vast majority of things Andrew
> puts in his kernel basically get flooded to me, because installing the
> entire -mm patch is a lot easier than installing half of it....
Which is about my argument placed on a higher level of user experience ;-)
Regards,
Stephan
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2003-11-16 22:54 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-28 15:49 2.6.0test9 Reiserfs boot time "buffer layer error at fs/buffer.c:431" lkml-031028
2003-10-28 18:36 ` Hans Reiser
2003-10-28 20:27 ` Oleg Drokin
2003-10-28 22:13 ` Andrew Morton
2003-10-28 22:15 ` Hans Reiser
2003-10-29 6:56 ` lkml-031028
2003-10-29 17:44 ` lkml-031028
2003-10-29 20:31 ` Andrew Morton
2003-10-29 21:49 ` Oleg Drokin
2003-10-29 22:19 ` Andrew Morton
2003-10-30 6:22 ` lkml-031028
2003-10-30 6:51 ` lkml-031028
2003-11-02 7:17 ` Herbert Xu
2003-11-02 7:33 ` Andrew Morton
2003-11-02 9:18 ` Oleg Drokin
2003-11-02 9:27 ` Herbert Xu
2003-11-02 9:40 ` Andrew Morton
2003-11-02 9:54 ` Herbert Xu
2003-11-02 11:54 ` Hans Reiser
2003-11-02 21:09 ` Herbert Xu
2003-11-03 10:20 ` Stephan von Krawczynski
2003-11-04 8:10 ` Hans Reiser
2003-11-04 21:03 ` Debian Kernels was: " Mike Fedyk
2003-11-04 9:54 ` Hans Reiser
2003-11-04 23:49 ` Stephan von Krawczynski
2003-11-05 0:05 ` Mike Fedyk
2003-11-16 13:05 ` Pavel Machek
2003-11-16 3:55 ` Hans Reiser
2003-11-16 14:15 ` Stephan von Krawczynski
2003-11-16 17:05 ` Pavel Machek
2003-11-16 17:27 ` Valdis.Kletnieks
2003-11-16 17:40 ` Stephan von Krawczynski
2003-11-16 18:38 ` Valdis.Kletnieks
2003-11-16 22:54 ` Stephan von Krawczynski
2003-11-16 17:30 ` Stephan von Krawczynski
2003-11-02 11:50 ` Hans Reiser
2003-11-02 20:33 ` Herbert Xu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).