I am using kernel 2.6.17.14, and would like to use newer versions for the wireless code but I get file corruption with any kernel
more recent than this. My system uses a SiS645DX chipset (it is a rebadged CLEVO D400E) with 5513 IDE.
I get this corruption with read/writes, i.e using "cp", "dd", when compiling software, writing to CD, etc etc. An example:
cp ../Changelog-2.6.18 .
diff Changelog-2.6.18 ../Changelog-2.6.18
16377c16377
< LD .top_vmlinux1
---
> LD .tmp_vmlinux1
23954c23954
< Date: Mon Jul 1% 04:45:11 2006 -0700
---
> Date: Mon Jul 10 04:45:11 2006 -0700
24955c24955
< This is generally useful, but partacularly helps see if it is the same sector
---
> This is generally useful, but particularly helps see if it is the same sector
31879c31879
< [MMC] sdhci: version bump cdhci
---
> [MMC] sdhci: version bump sdhci
42955c42955
< Replace `he temp makefile hacks with proper CONFIG entries, which are also
---
> Replace the temp makefile hacks with proper CONFIG entries, which are also
49050c49050
< and this task is(already holding:
---
> and this task is already holding:
[output clipped]
I would suspect a memory problem but memtest86+ gives no errors despite numerous passes, and I get no errors in older kernels. Does
anyone have any idea what changed in 2.6.18 to cause such an error?
I have tried some obvious things (see thread on linuxquestions.org:
http://www.linuxquestions.org/questions/showthread.php?t=578200), but I don't understand enough about the kernel to get any further.
Neil.
Hi Neil,
On 9/30/07, Neil Romig <[email protected]> wrote:
> I would suspect a memory problem but memtest86+ gives no errors despite numerous
> passes, and I get no errors in older kernels. Does anyone have any idea what changed in
> 2.6.18 to cause such an error?
I don't but you can try to isolate the changeset introducing the
corruption with git-bisect:
http://kernel.org/pub/software/scm/git/docs/v1.3.3/howto/isolate-bugs-with-bisect.txt
So, in your case, you do:
<clone Linux mainline git repository>
# git bisect start
# git bisect bad v2.6.18
# git bisect good v2.6.17
then
<recompile and test>
<git bisect [good|bad] depending on results>
<repeat until you've narrowed down the changeset>
Also, please remember to send your .config when reporting bugs as
described in REPORTING-BUGS.
Pekka
00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host & Memory & AGP Controller (rev 01)
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 64
Memory at e8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [c0] AGP version 2.0
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 99
Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
I/O behind bridge: 00009000-00009fff
Memory behind bridge: ec100000-ec1fffff
Prefetchable memory behind bridge: f0000000-f7ffffff
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL Media IO] (rev 14)
Flags: bus master, medium devsel, latency 0
00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
Flags: medium devsel
I/O ports at 8100 [size=32]
00:02.3 FireWire (IEEE 1394): Silicon Integrated Systems [SiS] FireWire Controller (prog-if 10 [OHCI])
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 64, IRQ 9
Memory at ec000000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at 34000000 [disabled] [size=128K]
Capabilities: [64] Power Management version 2
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master])
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 128, IRQ 11
I/O ports at 1000 [size=16]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS7012 PCI Audio Accelerator (rev a0)
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 173, IRQ 5
I/O ports at 1400 [size=256]
I/O ports at 1080 [size=128]
Capabilities: [48] Power Management version 2
00:03.0 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 0f) (prog-if 10 [OHCI])
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at ec001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
00:03.1 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 0f) (prog-if 10 [OHCI])
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 64, IRQ 9
Memory at ec002000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
00:03.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 0f) (prog-if 10 [OHCI])
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 64, IRQ 9
Memory at ec003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
00:03.3 USB Controller: Silicon Integrated Systems [SiS] SiS7002 USB 2.0 (prog-if 20 [EHCI])
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 64, IRQ 9
Memory at ec004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 2
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: CLEVO/KAPOK Computer: Unknown device 0400
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at 1800 [size=256]
Memory at ec005000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
00:0c.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, medium devsel, latency 64, IRQ 5
Memory at 34020000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 30000000-31fff000 (prefetchable)
Memory window 1: 32000000-33fff000 (prefetchable)
I/O window 0: 00001c00-00001cff
I/O window 1: 00002000-000020ff
16-bit legacy interface ports at 0001
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000] (rev 01) (prog-if 00 [VGA])
Subsystem: CLEVO/KAPOK Computer: Unknown device 0403
Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 11
Memory at f0000000 (32-bit, prefetchable) [size=128M]
I/O ports at 9000 [size=256]
Memory at ec100000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at ec120000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
On 09/30/2007 11:40 AM, Neil Romig wrote:
> I am using kernel 2.6.17.14, and would like to use newer versions for
> the wireless code but I get file corruption with any kernel more recent
> than this. My system uses a SiS645DX chipset (it is a rebadged CLEVO
> D400E) with 5513 IDE.
>
> I get this corruption with read/writes, i.e using "cp", "dd", when
> compiling software, writing to CD, etc etc. An example:
>
> cp ../Changelog-2.6.18 .
> diff Changelog-2.6.18 ../Changelog-2.6.18
>
> 16377c16377
> < LD .top_vmlinux1
> ---
>> LD .tmp_vmlinux1
> 23954c23954
> < Date: Mon Jul 1% 04:45:11 2006 -0700
> ---
>> Date: Mon Jul 10 04:45:11 2006 -0700
Is there some pattern to the corruption, like maybe it occurs once every
N bytes in the file?
Hi Neil,
On 10/3/07, Neil Romig <[email protected]> wrote:
> Thanks for your help on this. I have narrowed it down to commit
> "c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
> __copy_from_user_ll()". This fits with the errors I'm getting, so now I need
> to find out if I can safely ignore this patch, or does it have to be modified?
> This is my first Linux bug in many years of simply using it, so I'm a little
> nervous!
Just to make sure, if you disable CONFIG_X86_INTEL_USERCOPY, the
corruption goes away?
Pekka Enberg wrote:
> Hi Neil,
>
> On 10/3/07, Neil Romig <[email protected]> wrote:
>> Thanks for your help on this. I have narrowed it down to commit
>> "c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
>> __copy_from_user_ll()". This fits with the errors I'm getting, so now I need
>> to find out if I can safely ignore this patch, or does it have to be modified?
>> This is my first Linux bug in many years of simply using it, so I'm a little
>> nervous!
>
> Just to make sure, if you disable CONFIG_X86_INTEL_USERCOPY, the
> corruption goes away?
>
It took some fiddling to disable (edit arch/i386/Kconfig.cpu) but that has fixed it. Many thanks!
Does this need to be reported as a bug? Or should the kernel config scripts be changed to enable this option to be easily turned off?
Neil.
Hi Neil,
On 10/3/07, Neil Romig <[email protected]> wrote:
> > > Thanks for your help on this. I have narrowed it down to commit
> > > "c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
> > > __copy_from_user_ll()". This fits with the errors I'm getting, so now I need
> > > to find out if I can safely ignore this patch, or does it have to be modified?
> > > This is my first Linux bug in many years of simply using it, so I'm a little
> > > nervous!
A some point in time, I wrote:
> > Just to make sure, if you disable CONFIG_X86_INTEL_USERCOPY, the
> > corruption goes away?
On 10/3/07, Neil Romig <[email protected]> wrote:
> It took some fiddling to disable (edit arch/i386/Kconfig.cpu) but that has fixed it.
> Many thanks!
>
> Does this need to be reported as a bug? Or should the kernel config scripts be
> changed to enable this option to be easily turned off?
Looks like a bug to me. Can we have your /proc/cpuinfo too?
Pekka
On Wed, 3 Oct 2007, Pekka Enberg wrote:
> Hi Neil,
>
> On 10/3/07, Neil Romig <[email protected]> wrote:
> > > > Thanks for your help on this. I have narrowed it down to commit
> > > > "c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
> > > > __copy_from_user_ll()". This fits with the errors I'm getting, so now I need
> > > > to find out if I can safely ignore this patch, or does it have to be modified?
> > > > This is my first Linux bug in many years of simply using it, so I'm a little
> > > > nervous!
>
> A some point in time, I wrote:
> > > Just to make sure, if you disable CONFIG_X86_INTEL_USERCOPY, the
> > > corruption goes away?
>
> On 10/3/07, Neil Romig <[email protected]> wrote:
> > It took some fiddling to disable (edit arch/i386/Kconfig.cpu) but that has fixed it.
> > Many thanks!
> >
> > Does this need to be reported as a bug? Or should the kernel config scripts be
> > changed to enable this option to be easily turned off?
>
> Looks like a bug to me. Can we have your /proc/cpuinfo too?
I doubt it's a CPU bug. It's more likely a chipset or motherboard bug
around the CPU. The patterns for the original "cp" corruption that Neil
posted seem to be:
File offset correct corrupt
decimal hex
======== ========
642470 0009cda6 'm' 0x6D 'o' 0x6f
972198 000ed5a6 'i' 0x69 'a' 0x61
1243686 0012fa26 's' 0x73 'c' 0x63
1676846 0019962e 't' 0x74 '`' 0x64
1907974 001d1d06 ' ' 0x20 '(' 0x28
...
and since it's apparently about using the uncached accesses, it's
interesting that the low three bits are identical in all those corruptions
(they also seem to be single-bit errors in the actual byte-value, although
the bit is not the same). If the external bus is 64 bits (?), that would
say that it's one particular byte lane that is dodgy.
I would bet that the reason the intel-optimized memcpy triggers this is
that the non-temporal stores just means that you go out directly on the
bus, and it probably just shows a weakness in the chipset or bus that
doesn't show with the normal cacheline accesses.
Linus
Hi Linus,
On 10/3/07, Linus Torvalds <[email protected]> wrote:
> I would bet that the reason the intel-optimized memcpy triggers this is
> that the non-temporal stores just means that you go out directly on the
> bus, and it probably just shows a weakness in the chipset or bus that
> doesn't show with the normal cacheline accesses.
But that should show up with memtest too, no?
Pekka
On Wed, 3 Oct 2007, Pekka Enberg wrote:
>
> On 10/3/07, Linus Torvalds <[email protected]> wrote:
> > I would bet that the reason the intel-optimized memcpy triggers this is
> > that the non-temporal stores just means that you go out directly on the
> > bus, and it probably just shows a weakness in the chipset or bus that
> > doesn't show with the normal cacheline accesses.
>
> But that should show up with memtest too, no?
Not unless memtest uses non-temporal stores with the same (or similar)
access patterns.
The thing is, the CPU cache hides a *lot* of activity from the chipset,
and changes the access patterns radically.
With normal cached accesses, you'd normally see just the "fill cacheline"
and "write out cacheline" pattern. With movnt, you'd see non-cacheline
accesses to memory. If the chipset was tested under mostly normal loads,
the movnt cases have been getting a lot less coverage.
Now, I do agree that it certainly *can* be a CPU bug too. I doubt it,
though.
I'd check the power supply (brownouts cause random corruption, and it
might have a "peak power pattern" thing to it), and it's worth re-seating
any DIMM's etc. And it's definitely worth going into the BIOS setup screen
and making sure that nothing is even close to debatable (ie take RAM
timings down to non-aggressive levels, make sure bus frequencies and
multipliers are not even close to borderline, etc etc).
Linus
On Wed, 3 Oct 2007 22:35:24 +0300
"Pekka Enberg" <[email protected]> wrote:
> Hi Linus,
>
> On 10/3/07, Linus Torvalds <[email protected]> wrote:
> > I would bet that the reason the intel-optimized memcpy triggers this is
> > that the non-temporal stores just means that you go out directly on the
> > bus, and it probably just shows a weakness in the chipset or bus that
> > doesn't show with the normal cacheline accesses.
>
> But that should show up with memtest too, no?
Not neccessarily. The old VIA memory copying bug only showed up with
prefetching and mmx store patterns. That was a hardware flaw that took
extreme memory utilisation to show up - so it does occur but thats not to
say it is the cause
Alan
Hi,
From: Linus Torvalds <[email protected]>
> On Wed, 3 Oct 2007, Pekka Enberg wrote:
> >
> > On 10/3/07, Linus Torvalds <[email protected]> wrote:
> > > I would bet that the reason the intel-optimized memcpy triggers this is
> > > that the non-temporal stores just means that you go out directly on the
> > > bus, and it probably just shows a weakness in the chipset or bus that
> > > doesn't show with the normal cacheline accesses.
> >
> > But that should show up with memtest too, no?
>
> Not unless memtest uses non-temporal stores with the same (or similar)
> access patterns.
>
> The thing is, the CPU cache hides a *lot* of activity from the chipset,
> and changes the access patterns radically.
>
> With normal cached accesses, you'd normally see just the "fill cacheline"
> and "write out cacheline" pattern. With movnt, you'd see non-cacheline
> accesses to memory. If the chipset was tested under mostly normal loads,
> the movnt cases have been getting a lot less coverage.
I'm not so sure whether it is chipset's bug or not.
The movnt does have the WC (write combining) semantics and
bypass the hardware cache to store the data.
http://www.intel.com/products/processor/manuals/index.htm
Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 1: Basic Architecture
Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide
Thanks in advance,
Hiro
Linus Torvalds wrote:
>
> On Wed, 3 Oct 2007, Pekka Enberg wrote:
>> On 10/3/07, Linus Torvalds <[email protected]> wrote:
>>> I would bet that the reason the intel-optimized memcpy triggers this is
>>> that the non-temporal stores just means that you go out directly on the
>>> bus, and it probably just shows a weakness in the chipset or bus that
>>> doesn't show with the normal cacheline accesses.
>> But that should show up with memtest too, no?
>
> Not unless memtest uses non-temporal stores with the same (or similar)
> access patterns.
>
> The thing is, the CPU cache hides a *lot* of activity from the chipset,
> and changes the access patterns radically.
>
> With normal cached accesses, you'd normally see just the "fill cacheline"
> and "write out cacheline" pattern. With movnt, you'd see non-cacheline
> accesses to memory. If the chipset was tested under mostly normal loads,
> the movnt cases have been getting a lot less coverage.
>
> Now, I do agree that it certainly *can* be a CPU bug too. I doubt it,
> though.
>
> I'd check the power supply (brownouts cause random corruption, and it
> might have a "peak power pattern" thing to it), and it's worth re-seating
> any DIMM's etc. And it's definitely worth going into the BIOS setup screen
> and making sure that nothing is even close to debatable (ie take RAM
> timings down to non-aggressive levels, make sure bus frequencies and
> multipliers are not even close to borderline, etc etc).
I didn't see what CPU this was, but there was this nasty erratum on some
Athlon 64/Opteron processors. I was trying to debug a problem someone
else mentioned a while ago (and which I could duplicate on my system)
where doing huge memsets in userspace (which glibc uses non-temporal
stores for) repeatedly would cause a system lockup or crash. Amazingly
enough after I upgraded the CPU from my old Athlon 64 3500+ to a new X2
4200+ the problem went away..
At the time I looked into whether this workaround could be applied in
the kernel if the BIOS failed to, but it seemed that accesses to the MSR
they mentioned failed, so I don't know what the story is..
from
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf
Erratum 97: 128-Bit Streaming Stores May Cause Coherency Failure
Description: Under a specific set of internal pipeline conditions, stale
data may be left in the L1 cache when a 128-bit streaming store (MOVNT*)
to a writeback (WB) memory type misses in the L1 data cache and both L1
and L2 TLBs.
Potential Effect on System
Memory coherence failures leading to unpredictable operation.
Suggested Workaround
BIOS should set DC_CFG.DIS_CNV_WC_SSO (bit 3 of MSR 0xC001_1022). The
performance effects of setting this bit are limited to streaming stores
to the write-combining (WC) memory type, a case expected to rarely occur
in actual usage. No loss of performance occurs in the general case (WB
memory type).
This workaround must not be applied to processors prior to revision C0.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Wed, 3 Oct 2007, Robert Hancock wrote:
>
> Erratum 97: 128-Bit Streaming Stores May Cause Coherency Failure
The Intel-optimized memcpy doesn't use the SSE registers, just regular
32-bit integer nontemporal stores (movnti). The reason is that the SSE
state save is too expensive to be worth it.
So it's not that. Also, considering that it was a single-bit error in all
the cases I saw, I wouldn't expect it to be a cache coherency problem,
which I'd expect to corrupt a whole cacheline or possibly at least a whole
access.
That said, bit corruption can be just about anything. It's certainly not
impossible that it's a CPU bug.
But my first guess would be slightly dodgy motherboard, possibly coupled
with a chipset that simply isn't very tolerant to any timing errors. If
the motherboard traces to the DDR aren't impedance-matched, or if the
traces don't have the same length, or if the capacitors that are supposed
to handle spikes in burst current aren't up to snuff, you'll just get
noisy lines.
And at some point, noisy lines means that you go from reliable operation
to "oh, that bit didn't make it correctly".
Lowering the front-side bus frequency or altering the memory timings can
help (ie doing things like running DDR-333 at DDR-266). Making sure that
your power supply isn't even close to its limits is good. And choosing a
motherboard and chipsets from a reliable manufacturer is more than a good
idea.
The reason why it's interesting that the errors seemed to happen in the
same byte-lane is that I think it's common policy to route data lines on
the same layer, and matching trace length per group is very important,
because you do signal clocking per-group, afaik. But on the other hand,
multiple layers on the board are expensive, so people try to minimize
them, and maybe you end up routing through a via to another layer - which
then makes timing and capacitance harder.
Or there aren't ground lines close enough, or the data lines are too close
to other lines and you get cross-talk etc etc.
No, I've not done board design, and I don't know what I'm talking about,
but look at the interesting zig-zagging the data (and address) lines often
do on the board. It often looks totally crazy ("why doesn't that line just
go straight?"), but the thing is that the groups all need to have the same
length, but the pins are all at different points, so you can't make the
lines straight, or some of them would be much shorter than others.
And if something is border-line, it may work all of the time - *until* you
hit specific patterns that cause lots of lines to wiggle around, and then
a capacitor won't handle the extra current draw from switching, or
cross-talk between lines hits you, and what used to work doesn't work any
more.
I wish we all had ECC memory. That gets rid of a lot of worries.
Linus
Linux version 2.6.22.9 (root@romig) (gcc version 3.4.3) #1 Wed Oct 3 19:14:10 BST 2007
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000d0000 - 00000000000d8000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fdf0000 (usable)
BIOS-e820: 000000001fdf0000 - 000000001fdfb000 (ACPI data)
BIOS-e820: 000000001fdfb000 - 000000001fe00000 (ACPI NVS)
BIOS-e820: 000000001fe00000 - 0000000020000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
509MB LOWMEM available.
Entering add_active_range(0, 0, 130544) 0 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 130544
early_node_map[1] active PFN ranges
0: 0 -> 130544
On node 0 totalpages: 130544
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 987 pages used for memmap
Normal zone: 125461 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP 000F72D0, 0014 (r0 PTLTD )
ACPI: RSDT 1FDF79CA, 0028 (r1 PTLTD RSDT 6040000 LTP 0)
ACPI: FACP 1FDFAF8C, 0074 (r1 SiS M650 6040000 PTL F4240)
ACPI: DSDT 1FDF79F2, 359A (r1 Clevo 650M 6040000 MSFT 100000D)
ACPI: FACS 1FDFBFC0, 0040
ACPI: PM-Timer IO Port: 0x8008
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Built 1 zonelists. Total pages: 129525
Kernel command line: root=/dev/sda6 vga=778
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 2666.381 MHz processor.
Console: colour VGA+ 132x43
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 514160k/522176k available (1982k kernel code, 7464k reserved, 710k data, 136k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xffff8000 - 0xfffff000 ( 28 kB)
vmalloc : 0xe0800000 - 0xffff6000 ( 503 MB)
lowmem : 0xc0000000 - 0xdfdf0000 ( 509 MB)
.init : 0xc03a4000 - 0xc03c6000 ( 136 kB)
.data : 0xc02efab4 - 0xc03a168c ( 710 kB)
.text : 0xc0100000 - 0xc02efab4 (1982 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 5334.34 BogoMIPS (lpj=2667171)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000 00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: bfebf9ff 00000000 00000000 0000b080 00004400 00000000 00000000
Compat vDSO mapped to ffffe000.
CPU: Intel Genuine Intel(R) CPU 2.66GHz stepping 09
Checking 'hlt' instruction... OK.
ACPI: Core revision 20070126
ACPI: setting ELCR to 0800 (from 0a20)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd9c8, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Enabling SiS 96x SMBus.
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs *9)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs *11)
ACPI: PCI Interrupt Link [LNKF] (IRQs *9)
ACPI: PCI Interrupt Link [LNKG] (IRQs *9)
ACPI: PCI Interrupt Link [LNKH] (IRQs 9) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 2.21 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: 00:04: ioport range 0x8000-0x808f has been reserved
pnp: 00:04: ioport range 0x8090-0x80ff has been reserved
pnp: 00:04: ioport range 0x8100-0x811f has been reserved
pnp: 00:04: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:04: ioport range 0xfe00-0xfe00 has been reserved
Time: tsc clocksource has been installed.
pnp: 00:04: iomem range 0xd0000-0xd3fff could not be reserved
pnp: 00:04: iomem range 0xd8000-0xdbfff has been reserved
pnp: 00:04: iomem range 0xfec00000-0xfecfffff could not be reserved
pnp: 00:04: iomem range 0xfee00000-0xfeefffff could not be reserved
PCI: Bridge: 0000:00:01.0
IO window: 9000-9fff
MEM window: ec100000-ec1fffff
PREFETCH window: f0000000-f7ffffff
PCI: Bus 2, cardbus bridge: 0000:00:0c.0
IO window: 00001c00-00001cff
IO window: 00002000-000020ff
PREFETCH window: 30000000-33ffffff
MEM window: 34000000-37ffffff
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
NTFS driver 2.1.28 [Flags: R/O].
io scheduler noop registered
io scheduler cfq registered (default)
Boot video device is 0000:01:00.0
ACPI: AC Adapter [ADP0] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
input: Sleep Button (CM) as /class/input/input2
ACPI: Sleep Button (CM) [SLPB]
input: Lid Switch as /class/input/input3
ACPI: Lid Switch [LID]
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THM0] (60 C)
Non-volatile memory driver v1.2
8139too Fast Ethernet driver 0.9.28
PCI: Enabling device 0000:00:0a.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
eth0: RealTek RTL8139 at 0xe080a000, 00:90:f5:24:ff:0b, IRQ 11
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
pata_sis 0000:00:02.5: version 0.5.1
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:02.5[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
scsi0 : pata_sis
scsi1 : pata_sis
ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011000 irq 14
ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011008 irq 15
ata1.00: ATA-6: FUJITSU MHT2060AT, 009A, max UDMA/100
ata1.00: 117210240 sectors, multi 16: LBA
ata1.00: configured for UDMA/100
ata2.00: ATAPI: SONY CD-RW/DVD-ROM CRX830E, JYK1, max UDMA/33
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHT2060A 009A PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: CD-ROM SONY CD-RW CRX830E JYK1 PQ: 0 ANSI: 5
scsi 1:0:0:0: Attached scsi generic sg1 type 5
PCI: Enabling device 0000:00:03.3 (0000 -> 0002)
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 9
PCI: setting IRQ 9 as level-triggered
ACPI: PCI Interrupt 0000:00:03.3[D] -> Link [LNKH] -> GSI 9 (level, low) -> IRQ 9
ehci_hcd 0000:00:03.3: EHCI Host Controller
ehci_hcd 0000:00:03.3: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:03.3
ehci_hcd 0000:00:03.3: irq 9, io mem 0xec004000
ehci_hcd 0000:00:03.3: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKE] -> GSI 11 (level, low) -> IRQ 11
ohci_hcd 0000:00:03.0: OHCI Host Controller
ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:03.0: irq 11, io mem 0xec001000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:03.1[B] -> Link [LNKF] -> GSI 9 (level, low) -> IRQ 9
ohci_hcd 0000:00:03.1: OHCI Host Controller
ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:03.1: irq 9, io mem 0xec002000
usb 1-2: new high speed USB device using ehci_hcd and address 2
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:03.2[C] -> Link [LNKG] -> GSI 9 (level, low) -> IRQ 9
ohci_hcd 0000:00:03.2: OHCI Host Controller
ohci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 4
ohci_hcd 0000:00:03.2: irq 9, io mem 0xec003000
usb 1-2: configuration #1 chosen from 1 choice
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 2-2: new full speed USB device using ohci_hcd and address 2
usb 2-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input4
Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
PCI: Enabling device 0000:00:02.7 (0000 -> 0001)
ACPI: PCI Interrupt 0000:00:02.7[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
input: PS/2 Mouse as /class/input/input5
input: AlpsPS/2 ALPS GlidePoint as /class/input/input6
intel8x0_measure_ac97_clock: measured 50494 usecs
intel8x0: clocking to 48000
ALSA device list:
#0: SiS SI7012 with ALC200,200P at irq 5
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <[email protected]>
ieee80211_crypt: registered algorithm 'NULL'
ieee80211_crypt: registered algorithm 'WEP'
Using IPI Shortcut mode
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 136k freed
usb 1-2: reset high speed USB device using ehci_hcd and address 2
zd1211rw 1-2:1.0: firmware version 4725
zd1211rw 1-2:1.0: zd1211b chip 0586:3410 v4810 high 00-13-49 AL2230_RF pa0 g---S
zd1211rw 1-2:1.0: eth1
usbcore: registered new interface driver zd1211rw
Adding 497972k swap on /dev/sda8. Priority:1 extents:1 across:497972k
NTFS volume version 3.1.
SoftMAC: Open Authentication completed with 00:13:49:a0:1e:f9