Hiya,
I'm using the 2.6.14.5 kernel and i notice that the system freezes
sometimes, within 24 hours usually, a total freeze, no mouse/keyb
reaction. Also i notice that apps crash randomly sometimes.
What can i do to investigate this ?
(none of the above problems occur when windows XP pro is used)
Thanks
Trilight wrote:
>Hiya,
>
>I'm using the 2.6.14.5 kernel and i notice that the system freezes
>sometimes, within 24 hours usually, a total freeze, no mouse/keyb
>reaction. Also i notice that apps crash randomly sometimes.
>
>What can i do to investigate this ?
>
>(none of the above problems occur when windows XP pro is used)
>
>Thanks
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
I'd start running memtestx86, just to be sure that there's no bad
memory, i've had a simular problem & turned out i had a defective memory
dimm. The problem didn't show up in windows in the same manner as it did
in linux.
On 12/30/05, Trilight <[email protected]> wrote:
> Hiya,
>
> I'm using the 2.6.14.5 kernel and i notice that the system freezes
> sometimes, within 24 hours usually, a total freeze, no mouse/keyb
> reaction. Also i notice that apps crash randomly sometimes.
>
When did this start to happen? Was it OK with a previous kernel
version? if it was ok with a previous version, then what was that
version?
Was it OK before you added a particular piece of hardware? If so, what
hardware? Have you tried removing that hardware to see if the problem
goes away?
> What can i do to investigate this ?
>
A few things you can try :
1) Start by providing some more info. Some details on your
hardware/software. Something like the following + whatever else you
consider relevant :
- name and version of your Linux distribution
- output of the scripts/ver_linux script found in the kernel source
- your kernels .config file
- full dmesg output after boot
- Motherboard name/model
- output of cat /proc/cpuinfo
- output of cat /proc/meminfo
- output of lspci -vv
- output of lsusb
2) Tell us what you have already tried in order to try and resolve the
problem, including your results with the various things you've tried.
3) Try building/running a kernel with the various debug options found
in the kernel hacking section turned on and see if that results in
more details in dmesg/logs etc and provide the extra info if any.
4) Try building a 2.6.15-rc7-git4 kernel with the same config and see
if that one also has problems.
Make sure your hardware is OK, CPU not overheating, RAM is OK (run
memtest86 with all tests enabled overnight) etc.
Try removing all extra hardware components in your system you don't
need for the system to boot and see if the problem then goes away. If
it does, try adding back hardware one piece at a time and re-test,
find out if it's related to a certain piece of hardware or a specific
driver.
That's all I can think of atm. With more info provided (as pr the list
above) perhaps someone else can point to more (or better) things to
try.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jesper Juhl wrote:
> On 12/30/05, Trilight <[email protected]> wrote:
>
>>Hiya,
>>
>>I'm using the 2.6.14.5 kernel and i notice that the system freezes
>>sometimes, within 24 hours usually, a total freeze, no mouse/keyb
>>reaction. Also i notice that apps crash randomly sometimes.
>>
>
> When did this start to happen? Was it OK with a previous kernel
> version? if it was ok with a previous version, then what was that
> version?
> Was it OK before you added a particular piece of hardware? If so, what
> hardware? Have you tried removing that hardware to see if the problem
> goes away?
>
>
>>What can i do to investigate this ?
>>
>
> A few things you can try :
>
> 1) Start by providing some more info. Some details on your
> hardware/software. Something like the following + whatever else you
> consider relevant :
> - name and version of your Linux distribution
> - output of the scripts/ver_linux script found in the kernel source
> - your kernels .config file
> - full dmesg output after boot
> - Motherboard name/model
> - output of cat /proc/cpuinfo
> - output of cat /proc/meminfo
> - output of lspci -vv
> - output of lsusb
>
> 2) Tell us what you have already tried in order to try and resolve the
> problem, including your results with the various things you've tried.
>
> 3) Try building/running a kernel with the various debug options found
> in the kernel hacking section turned on and see if that results in
> more details in dmesg/logs etc and provide the extra info if any.
>
> 4) Try building a 2.6.15-rc7-git4 kernel with the same config and see
> if that one also has problems.
>
> Make sure your hardware is OK, CPU not overheating, RAM is OK (run
> memtest86 with all tests enabled overnight) etc.
>
> Try removing all extra hardware components in your system you don't
> need for the system to boot and see if the problem then goes away. If
> it does, try adding back hardware one piece at a time and re-test,
> find out if it's related to a certain piece of hardware or a specific
> driver.
<..>
Thanks for the advise !
About the memory test, i did that, 7 full passes, no errors, it's 512mb
ecc memory btw. I'm going to let it, when i go to sleep, run the whole
night.
hardware:
System is a dell precision workstation 650, dual xeon 2.4ghz w/HT, intel
E7505 motherboard.
distro: debian sarge
kernel: vanilla 2.6.14.5
for the rest there is nothing special to see in dmesg output, lspci or
with lsusb. cpuinfo shows everything what it should show.
Memoinfo:
MemTotal: 512528 kB
MemFree: 8760 kB
Buffers: 2656 kB
Cached: 236216 kB
SwapCached: 2052 kB
Active: 390480 kB
Inactive: 54756 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 512528 kB
LowFree: 8760 kB
SwapTotal: 4883680 kB
SwapFree: 4864064 kB
Dirty: 112 kB
Writeback: 0 kB
Mapped: 388988 kB
Slab: 23320 kB
CommitLimit: 5139944 kB
Committed_AS: 518952 kB
PageTables: 1912 kB
VmallocTotal: 515796 kB
VmallocUsed: 25496 kB
VmallocChunk: 487120 kB
Other findings;
- all kernels had the same issue, except (not 100 % sure) 2.4.2X kernels
- tried acpi=noirq without success and many many other acpi options &
combo's
- nvidia binary driver replaced by kernel nv driver but without success
I have no reason to suspect the tvcard which is a terratec value with a
bt878 chip, support in the kernel. But on the other hand it could be the
tvcard, but i see no relation to anything with it. I tried also using
DAC snoop in the bios but no good.
None of the issue's occur when using windows xp pro/rhel enterprise 4
I'm going to let the memory test on for the whole night, i'll also
compile the kernel with debugging options on. But i don't think the
debugging options will matter since nothing is logged when the freeze
occurs.
Greetz,
Mark
Mark v Wolher wrote:
>
> Jesper Juhl wrote:
>
>>On 12/30/05, Trilight <[email protected]> wrote:
>>
>>
>>>Hiya,
>>>
>>>I'm using the 2.6.14.5 kernel and i notice that the system freezes
>>>sometimes, within 24 hours usually, a total freeze, no mouse/keyb
>>>reaction. Also i notice that apps crash randomly sometimes.
>>>
>>
>>When did this start to happen? Was it OK with a previous kernel
>>version? if it was ok with a previous version, then what was that
>>version?
>>Was it OK before you added a particular piece of hardware? If so, what
>>hardware? Have you tried removing that hardware to see if the problem
>>goes away?
>>
>>
>>
>>>What can i do to investigate this ?
>>>
>>
>>A few things you can try :
>>
>>1) Start by providing some more info. Some details on your
>>hardware/software. Something like the following + whatever else you
>>consider relevant :
>> - name and version of your Linux distribution
>> - output of the scripts/ver_linux script found in the kernel source
>> - your kernels .config file
>> - full dmesg output after boot
>> - Motherboard name/model
>> - output of cat /proc/cpuinfo
>> - output of cat /proc/meminfo
>> - output of lspci -vv
>> - output of lsusb
>>
>>2) Tell us what you have already tried in order to try and resolve the
>>problem, including your results with the various things you've tried.
>>
>>3) Try building/running a kernel with the various debug options found
>>in the kernel hacking section turned on and see if that results in
>>more details in dmesg/logs etc and provide the extra info if any.
>>
>>4) Try building a 2.6.15-rc7-git4 kernel with the same config and see
>>if that one also has problems.
>>
>>Make sure your hardware is OK, CPU not overheating, RAM is OK (run
>>memtest86 with all tests enabled overnight) etc.
>>
>>Try removing all extra hardware components in your system you don't
>>need for the system to boot and see if the problem then goes away. If
>>it does, try adding back hardware one piece at a time and re-test,
>>find out if it's related to a certain piece of hardware or a specific
>>driver.
>
>
> <..>
>
> Thanks for the advise !
>
> About the memory test, i did that, 7 full passes, no errors, it's 512mb
> ecc memory btw. I'm going to let it, when i go to sleep, run the whole
> night.
>
> hardware:
>
> System is a dell precision workstation 650, dual xeon 2.4ghz w/HT, intel
> E7505 motherboard.
>
> distro: debian sarge
> kernel: vanilla 2.6.14.5
>
> for the rest there is nothing special to see in dmesg output, lspci or
> with lsusb. cpuinfo shows everything what it should show.
>
> Memoinfo:
>
> MemTotal: 512528 kB
> MemFree: 8760 kB
> Buffers: 2656 kB
> Cached: 236216 kB
> SwapCached: 2052 kB
> Active: 390480 kB
> Inactive: 54756 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 512528 kB
> LowFree: 8760 kB
> SwapTotal: 4883680 kB
> SwapFree: 4864064 kB
> Dirty: 112 kB
> Writeback: 0 kB
> Mapped: 388988 kB
> Slab: 23320 kB
> CommitLimit: 5139944 kB
> Committed_AS: 518952 kB
> PageTables: 1912 kB
> VmallocTotal: 515796 kB
> VmallocUsed: 25496 kB
> VmallocChunk: 487120 kB
>
>
> Other findings;
>
> - all kernels had the same issue, except (not 100 % sure) 2.4.2X kernels
> - tried acpi=noirq without success and many many other acpi options &
> combo's
> - nvidia binary driver replaced by kernel nv driver but without success
>
> I have no reason to suspect the tvcard which is a terratec value with a
> bt878 chip, support in the kernel. But on the other hand it could be the
> tvcard, but i see no relation to anything with it. I tried also using
> DAC snoop in the bios but no good.
>
> None of the issue's occur when using windows xp pro/rhel enterprise 4
>
> I'm going to let the memory test on for the whole night, i'll also
> compile the kernel with debugging options on. But i don't think the
> debugging options will matter since nothing is logged when the freeze
> occurs.
>
I'm not sure what to make of this, but it looks like only 1 cpu is kept
busy with interrupts:
CPU0 CPU1 CPU2 CPU3
0: 1033372 0 0 0 IO-APIC-edge timer
1: 10346 0 0 0 IO-APIC-edge i8042
7: 0 0 0 0 IO-APIC-edge parport0
8: 4795679 0 0 0 IO-APIC-edge rtc
9: 0 0 0 0 IO-APIC-level acpi
14: 29 0 0 0 IO-APIC-edge ide0
15: 21 0 0 0 IO-APIC-edge ide1
169: 12646 0 0 0 IO-APIC-level eth0
177: 166090 0 0 0 IO-APIC-level bttv0
185: 59 0 0 0 IO-APIC-level
uhci_hcd:usb4
193: 76030 0 0 0 IO-APIC-level ide2, ide3
201: 5 0 0 0 IO-APIC-level
ehci_hcd:usb1
209: 681735 0 0 0 IO-APIC-level
uhci_hcd:usb2, nvidia
217: 465677 0 0 0 IO-APIC-level
uhci_hcd:usb3
225: 0 0 0 0 IO-APIC-level Intel
82801DB-ICH4
233: 33792 0 0 0 IO-APIC-level EMU10K1
NMI: 0 0 0 0
LOC: 1033319 1033572 1033571 1033570
ERR: 0
MIS: 0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> I'm not sure what to make of this, but it looks like only 1 cpu is kept
> busy with interrupts:
> CPU0 CPU1 CPU2 CPU3
> 0: 1033372 0 0 0 IO-APIC-edge timer
Install the 'irqbalance' package.
Folkert van Heusden
- --
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. http://www.vanheusden.com/multitail/
- ----------------------------------------------------------------------
Get your PGP/GPG key signed at http://www.biglumber.com!
- ----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iIMEARECAEMFAkO1ZLc8Gmh0dHA6Ly93d3cudmFuaGV1c2Rlbi5jb20vZGF0YS1z
aWduaW5nLXdpdGgtcGdwLXBvbGljeS5odG1sAAoJEDAZDowfKNiu5fQAnjADr74k
mv3NRwMfK/FEksDN23/mAJ9RVa4g9EBCPp8ax6EjXXRbXf9ayw==
=v050
-----END PGP SIGNATURE-----
Folkert van Heusden wrote:
>
>>>I'm not sure what to make of this, but it looks like only 1 cpu is kept
>>>busy with interrupts:
>>> CPU0 CPU1 CPU2 CPU3
>>> 0: 1033372 0 0 0 IO-APIC-edge timer
>
>
> Install the 'irqbalance' package.
>
>
<..>
Thanks ! I installed it now, it asked me something about a "one shot
mode" but i chose no. Correct me if i should choose the other mode.
Should i reboot for this to take effect ? Cause i still see the 0's
under the other cpu's.
Appreciate the help !
> >>>I'm not sure what to make of this, but it looks like only 1 cpu is kept
> >>>busy with interrupts:
> >>> CPU0 CPU1 CPU2 CPU3
> >>> 0: 1033372 0 0 0 IO-APIC-edge timer
> > Install the 'irqbalance' package.
> <..>
> Thanks ! I installed it now, it asked me something about a "one shot
> mode" but i chose no. Correct me if i should choose the other mode.
> Should i reboot for this to take effect ? Cause i still see the 0's
> under the other cpu's.
Not one-shot
reboot? depends on your distribution
try /usr/sbin/irqbalance from bash
Folkert van Heusden
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at http://www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
Folkert van Heusden wrote:
>>>>>I'm not sure what to make of this, but it looks like only 1 cpu is kept
>>>>>busy with interrupts:
>>>>> CPU0 CPU1 CPU2 CPU3
>>>>> 0: 1033372 0 0 0 IO-APIC-edge timer
>>>
>>>Install the 'irqbalance' package.
>>
>><..>
>>Thanks ! I installed it now, it asked me something about a "one shot
>>mode" but i chose no. Correct me if i should choose the other mode.
>>Should i reboot for this to take effect ? Cause i still see the 0's
>>under the other cpu's.
>
>
> Not one-shot
> reboot? depends on your distribution
> try /usr/sbin/irqbalance from bash
>
>
> Folkert van Heusden
>
Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
and after a restart with irqbalance i see the cpu's show numbers !
I guess MSI was preventing them ? But does that means because of MSI
that performance was lower in some way ?
Here is the current cat:
CPU0 CPU1 CPU2 CPU3
0: 59805 40023 42523 38141 IO-APIC-edge timer
1: 984 840 795 413 IO-APIC-edge i8042
7: 0 0 0 0 IO-APIC-edge parport0
8: 204851 189535 184425 184454 IO-APIC-edge rtc
9: 0 0 0 0 IO-APIC-level acpi
14: 21 0 0 0 IO-APIC-edge ide0
15: 13 0 0 0 IO-APIC-edge ide1
16: 2206 0 0 0 IO-APIC-level eth0
17: 9681 4489 6747 10672 IO-APIC-level bttv0
18: 48 16 0 0 IO-APIC-level
uhci_hcd:usb4
19: 5889 9693 22604 1560 IO-APIC-level ide2, ide3
20: 5 0 0 0 IO-APIC-level
ehci_hcd:usb1
21: 16563 25276 23860 19548 IO-APIC-level
uhci_hcd:usb2, nvidia
22: 33248 15866 13468 33568 IO-APIC-level
uhci_hcd:usb3
23: 0 0 0 0 IO-APIC-level Intel
82801DB-ICH4
24: 0 0 0 0 IO-APIC-level EMU10K1
NMI: 0 0 0 0
LOC: 180380 180126 180378 180377
ERR: 0
MIS: 0
> Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
> and after a restart with irqbalance i see the cpu's show numbers !
> I guess MSI was preventing them ? But does that means because of MSI
> that performance was lower in some way ?
did you also restart with only irqbalance activated?
Folkert van Heusden
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at http://www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
Folkert van Heusden wrote:
>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
>>and after a restart with irqbalance i see the cpu's show numbers !
>>I guess MSI was preventing them ? But does that means because of MSI
>>that performance was lower in some way ?
>
>
> did you also restart with only irqbalance activated?
>
>
> Folkert van Heusden
>
Yes, when MSI was disabled i had irq-balancing in the kernel on, i
rebooted without the irqbalance daemon and it showed no reaction on the
cpu's. When i enabled the irqbalance daemon then i got finally reaction
from the cpu's.
I'm also curious if this will solve those random freezes...which somehow
i suspect have to do with the tvcard and maybe having MSI on.
Mark v Wolher wrote:
> Folkert van Heusden wrote:
>
>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
>>>and after a restart with irqbalance i see the cpu's show numbers !
>>>I guess MSI was preventing them ? But does that means because of MSI
>>>that performance was lower in some way ?
>>
>>
>>did you also restart with only irqbalance activated?
>>
>>
>>Folkert van Heusden
>>
>
>
> Yes, when MSI was disabled i had irq-balancing in the kernel on, i
> rebooted without the irqbalance daemon and it showed no reaction on the
> cpu's. When i enabled the irqbalance daemon then i got finally reaction
> from the cpu's.
>
> I'm also curious if this will solve those random freezes...which somehow
> i suspect have to do with the tvcard and maybe having MSI on.
>
:( just got a total freeze, number 2 today. This time i noticed the
mouse started to go very slow and 2 seconds later all was frozen.
Maybe it's because of vmware ... i will not use vmware and see how it goes.
Mark v Wolher wrote:
> Mark v Wolher wrote:
>
>>Folkert van Heusden wrote:
>>
>>
>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
>>>>and after a restart with irqbalance i see the cpu's show numbers !
>>>>I guess MSI was preventing them ? But does that means because of MSI
>>>>that performance was lower in some way ?
>>>
>>>
>>>did you also restart with only irqbalance activated?
>>>
>>>
>>>Folkert van Heusden
>>>
>>
>>
>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
>>rebooted without the irqbalance daemon and it showed no reaction on the
>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
>>from the cpu's.
>>
>>I'm also curious if this will solve those random freezes...which somehow
>>i suspect have to do with the tvcard and maybe having MSI on.
>>
>
>
> :( just got a total freeze, number 2 today. This time i noticed the
> mouse started to go very slow and 2 seconds later all was frozen.
>
> Maybe it's because of vmware ... i will not use vmware and see how it goes.
> -
Some new info, i just noticed this in the logs:
Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
OFLOW FBUS OCERR*
Dec 30 22:21:24 localhost last message repeated 5 times
Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
But vmware is not active at this moment, i'll not use vmware and see if
a freeze occurs, i'll test up to 24 hours.
I can swear it might have to do with the tvcard with tv on and vmware at
the same time also active. Or maybe just 1 of them. I'm even considering
to buy tomorrow a new tvcard and see if it makes any difference.
On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
> Mark v Wolher wrote:
> > Mark v Wolher wrote:
> >
> >>Folkert van Heusden wrote:
> >>
> >>
> >>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
> >>>>and after a restart with irqbalance i see the cpu's show numbers !
> >>>>I guess MSI was preventing them ? But does that means because of MSI
> >>>>that performance was lower in some way ?
> >>>
> >>>
> >>>did you also restart with only irqbalance activated?
> >>>
> >>>
> >>>Folkert van Heusden
> >>>
> >>
> >>
> >>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
> >>rebooted without the irqbalance daemon and it showed no reaction on the
> >>cpu's. When i enabled the irqbalance daemon then i got finally reaction
> >>from the cpu's.
> >>
> >>I'm also curious if this will solve those random freezes...which somehow
> >>i suspect have to do with the tvcard and maybe having MSI on.
> >>
> >
> >
> > :( just got a total freeze, number 2 today. This time i noticed the
> > mouse started to go very slow and 2 seconds later all was frozen.
> >
> > Maybe it's because of vmware ... i will not use vmware and see how it goes.
> > -
>
>
> Some new info, i just noticed this in the logs:
>
>
> Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
> OFLOW FBUS OCERR*
> Dec 30 22:21:24 localhost last message repeated 5 times
> Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
> irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
> Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
> Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
>
>
> But vmware is not active at this moment, i'll not use vmware and see if
> a freeze occurs, i'll test up to 24 hours.
>
> I can swear it might have to do with the tvcard with tv on and vmware at
> the same time also active. Or maybe just 1 of them. I'm even considering
> to buy tomorrow a new tvcard and see if it makes any difference.
It does not matter whether VMWare is active at the moment. Any bug
report where a binary module has been loaded, active or not, is tainted.
Can you reproduce with a 100% clean kernel?
Lee
Lee Revell wrote:
> On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
>
>>Mark v Wolher wrote:
>>
>>>Mark v Wolher wrote:
>>>
>>>
>>>>Folkert van Heusden wrote:
>>>>
>>>>
>>>>
>>>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
>>>>>>and after a restart with irqbalance i see the cpu's show numbers !
>>>>>>I guess MSI was preventing them ? But does that means because of MSI
>>>>>>that performance was lower in some way ?
>>>>>
>>>>>
>>>>>did you also restart with only irqbalance activated?
>>>>>
>>>>>
>>>>>Folkert van Heusden
>>>>>
>>>>
>>>>
>>>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
>>>>rebooted without the irqbalance daemon and it showed no reaction on the
>>>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
>>>
>>>>from the cpu's.
>>>
>>>>I'm also curious if this will solve those random freezes...which somehow
>>>>i suspect have to do with the tvcard and maybe having MSI on.
>>>>
>>>
>>>
>>>:( just got a total freeze, number 2 today. This time i noticed the
>>>mouse started to go very slow and 2 seconds later all was frozen.
>>>
>>>Maybe it's because of vmware ... i will not use vmware and see how it goes.
>>>-
>>
>>
>>Some new info, i just noticed this in the logs:
>>
>>
>>Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
>>OFLOW FBUS OCERR*
>>Dec 30 22:21:24 localhost last message repeated 5 times
>>Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
>>irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
>>Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
>>Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
>>
>>
>>But vmware is not active at this moment, i'll not use vmware and see if
>>a freeze occurs, i'll test up to 24 hours.
>>
>>I can swear it might have to do with the tvcard with tv on and vmware at
>>the same time also active. Or maybe just 1 of them. I'm even considering
>>to buy tomorrow a new tvcard and see if it makes any difference.
>
>
> It does not matter whether VMWare is active at the moment. Any bug
> report where a binary module has been loaded, active or not, is tainted.
>
> Can you reproduce with a 100% clean kernel?
>
> Lee
>
Hi Lee,
But unloading all vmware modules should be good enough ? And how about
the binary module of nvidia ? It's active ofcourse else i'd not be able
to use all the features i normally use.
Eitherway, several kernels back also made no difference for this issue.
So right now, i'm leaning on the experience i have with working with
this system and trying to isolate things i suspect, before i go to more
radical steps :)
And again, under windows 2k server, xp pro, redhat enterprise and
freebsd i never had these issues.
On Fri, 2005-12-30 at 22:47 +0100, Mark v Wolher wrote:
> Lee Revell wrote:
> > On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
> >
> >>Mark v Wolher wrote:
> >>
> >>>Mark v Wolher wrote:
> >>>
> >>>
> >>>>Folkert van Heusden wrote:
> >>>>
> >>>>
> >>>>
> >>>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
> >>>>>>and after a restart with irqbalance i see the cpu's show numbers !
> >>>>>>I guess MSI was preventing them ? But does that means because of MSI
> >>>>>>that performance was lower in some way ?
> >>>>>
> >>>>>
> >>>>>did you also restart with only irqbalance activated?
> >>>>>
> >>>>>
> >>>>>Folkert van Heusden
> >>>>>
> >>>>
> >>>>
> >>>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
> >>>>rebooted without the irqbalance daemon and it showed no reaction on the
> >>>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
> >>>
> >>>>from the cpu's.
> >>>
> >>>>I'm also curious if this will solve those random freezes...which somehow
> >>>>i suspect have to do with the tvcard and maybe having MSI on.
> >>>>
> >>>
> >>>
> >>>:( just got a total freeze, number 2 today. This time i noticed the
> >>>mouse started to go very slow and 2 seconds later all was frozen.
> >>>
> >>>Maybe it's because of vmware ... i will not use vmware and see how it goes.
> >>>-
> >>
> >>
> >>Some new info, i just noticed this in the logs:
> >>
> >>
> >>Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
> >>OFLOW FBUS OCERR*
> >>Dec 30 22:21:24 localhost last message repeated 5 times
> >>Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
> >>irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
> >>Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
> >>Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
> >>
> >>
> >>But vmware is not active at this moment, i'll not use vmware and see if
> >>a freeze occurs, i'll test up to 24 hours.
> >>
> >>I can swear it might have to do with the tvcard with tv on and vmware at
> >>the same time also active. Or maybe just 1 of them. I'm even considering
> >>to buy tomorrow a new tvcard and see if it makes any difference.
> >
> >
> > It does not matter whether VMWare is active at the moment. Any bug
> > report where a binary module has been loaded, active or not, is tainted.
> >
> > Can you reproduce with a 100% clean kernel?
> >
> > Lee
> >
>
> Hi Lee,
>
> But unloading all vmware modules should be good enough ? And how about
> the binary module of nvidia ? It's active ofcourse else i'd not be able
> to use all the features i normally use.
>
> Eitherway, several kernels back also made no difference for this issue.
>
> So right now, i'm leaning on the experience i have with working with
> this system and trying to isolate things i suspect, before i go to more
> radical steps :)
>
> And again, under windows 2k server, xp pro, redhat enterprise and
> freebsd i never had these issues.
>
No, it's not good enough to unload them and no, the nvidia module
absolutely cannot have been loaded. Binary modules can do ANYTHING and
we have NO IDEA what they are up to, how could you possibly think such a
system would be debuggable?
Please, search the LKML archives, this has come up again and again and
again and still people post bug reports with binary only modules and
expect them to be debuggable.
Lee
Lee Revell wrote:
> On Fri, 2005-12-30 at 22:47 +0100, Mark v Wolher wrote:
>
>>Lee Revell wrote:
>>
>>>On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
>>>
>>>
>>>>Mark v Wolher wrote:
>>>>
>>>>
>>>>>Mark v Wolher wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Folkert van Heusden wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
>>>>>>>>and after a restart with irqbalance i see the cpu's show numbers !
>>>>>>>>I guess MSI was preventing them ? But does that means because of MSI
>>>>>>>>that performance was lower in some way ?
>>>>>>>
>>>>>>>
>>>>>>>did you also restart with only irqbalance activated?
>>>>>>>
>>>>>>>
>>>>>>>Folkert van Heusden
>>>>>>>
>>>>>>
>>>>>>
>>>>>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
>>>>>>rebooted without the irqbalance daemon and it showed no reaction on the
>>>>>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
>>>>>
>>>>>>from the cpu's.
>>>>>
>>>>>
>>>>>>I'm also curious if this will solve those random freezes...which somehow
>>>>>>i suspect have to do with the tvcard and maybe having MSI on.
>>>>>>
>>>>>
>>>>>
>>>>>:( just got a total freeze, number 2 today. This time i noticed the
>>>>>mouse started to go very slow and 2 seconds later all was frozen.
>>>>>
>>>>>Maybe it's because of vmware ... i will not use vmware and see how it goes.
>>>>>-
>>>>
>>>>
>>>>Some new info, i just noticed this in the logs:
>>>>
>>>>
>>>>Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
>>>>OFLOW FBUS OCERR*
>>>>Dec 30 22:21:24 localhost last message repeated 5 times
>>>>Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
>>>>irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
>>>>Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
>>>>Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
>>>>
>>>>
>>>>But vmware is not active at this moment, i'll not use vmware and see if
>>>>a freeze occurs, i'll test up to 24 hours.
>>>>
>>>>I can swear it might have to do with the tvcard with tv on and vmware at
>>>>the same time also active. Or maybe just 1 of them. I'm even considering
>>>>to buy tomorrow a new tvcard and see if it makes any difference.
>>>
>>>
>>>It does not matter whether VMWare is active at the moment. Any bug
>>>report where a binary module has been loaded, active or not, is tainted.
>>>
>>>Can you reproduce with a 100% clean kernel?
>>>
>>>Lee
>>>
>>
>>Hi Lee,
>>
>>But unloading all vmware modules should be good enough ? And how about
>>the binary module of nvidia ? It's active ofcourse else i'd not be able
>>to use all the features i normally use.
>>
>>Eitherway, several kernels back also made no difference for this issue.
>>
>>So right now, i'm leaning on the experience i have with working with
>>this system and trying to isolate things i suspect, before i go to more
>>radical steps :)
>>
>>And again, under windows 2k server, xp pro, redhat enterprise and
>>freebsd i never had these issues.
>>
>
>
> No, it's not good enough to unload them and no, the nvidia module
> absolutely cannot have been loaded. Binary modules can do ANYTHING and
> we have NO IDEA what they are up to, how could you possibly think such a
> system would be debuggable?
>
> Please, search the LKML archives, this has come up again and again and
> again and still people post bug reports with binary only modules and
> expect them to be debuggable.
>
> Lee
>
>
>
>
>
Well Lee, you might be right indeed, but i see only some one who has
something against binary modules and assuming they're always to blame.
I do not agree with this and i will proceed from simple to advanced in
solving this problem, not start thinking difficult while the problem
might be solved by a simple move. :)
On Fri, 2005-12-30 at 22:57 +0100, Mark v Wolher wrote:
> Lee Revell wrote:
> > On Fri, 2005-12-30 at 22:47 +0100, Mark v Wolher wrote:
> >
> >>Lee Revell wrote:
> >>
> >>>On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
> >>>
> >>>
> >>>>Mark v Wolher wrote:
> >>>>
> >>>>
> >>>>>Mark v Wolher wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Folkert van Heusden wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
> >>>>>>>>and after a restart with irqbalance i see the cpu's show numbers !
> >>>>>>>>I guess MSI was preventing them ? But does that means because of MSI
> >>>>>>>>that performance was lower in some way ?
> >>>>>>>
> >>>>>>>
> >>>>>>>did you also restart with only irqbalance activated?
> >>>>>>>
> >>>>>>>
> >>>>>>>Folkert van Heusden
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
> >>>>>>rebooted without the irqbalance daemon and it showed no reaction on the
> >>>>>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
> >>>>>
> >>>>>>from the cpu's.
> >>>>>
> >>>>>
> >>>>>>I'm also curious if this will solve those random freezes...which somehow
> >>>>>>i suspect have to do with the tvcard and maybe having MSI on.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>:( just got a total freeze, number 2 today. This time i noticed the
> >>>>>mouse started to go very slow and 2 seconds later all was frozen.
> >>>>>
> >>>>>Maybe it's because of vmware ... i will not use vmware and see how it goes.
> >>>>>-
> >>>>
> >>>>
> >>>>Some new info, i just noticed this in the logs:
> >>>>
> >>>>
> >>>>Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
> >>>>OFLOW FBUS OCERR*
> >>>>Dec 30 22:21:24 localhost last message repeated 5 times
> >>>>Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
> >>>>irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
> >>>>Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
> >>>>Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
> >>>>
> >>>>
> >>>>But vmware is not active at this moment, i'll not use vmware and see if
> >>>>a freeze occurs, i'll test up to 24 hours.
> >>>>
> >>>>I can swear it might have to do with the tvcard with tv on and vmware at
> >>>>the same time also active. Or maybe just 1 of them. I'm even considering
> >>>>to buy tomorrow a new tvcard and see if it makes any difference.
> >>>
> >>>
> >>>It does not matter whether VMWare is active at the moment. Any bug
> >>>report where a binary module has been loaded, active or not, is tainted.
> >>>
> >>>Can you reproduce with a 100% clean kernel?
> >>>
> >>>Lee
> >>>
> >>
> >>Hi Lee,
> >>
> >>But unloading all vmware modules should be good enough ? And how about
> >>the binary module of nvidia ? It's active ofcourse else i'd not be able
> >>to use all the features i normally use.
> >>
> >>Eitherway, several kernels back also made no difference for this issue.
> >>
> >>So right now, i'm leaning on the experience i have with working with
> >>this system and trying to isolate things i suspect, before i go to more
> >>radical steps :)
> >>
> >>And again, under windows 2k server, xp pro, redhat enterprise and
> >>freebsd i never had these issues.
> >>
> >
> >
> > No, it's not good enough to unload them and no, the nvidia module
> > absolutely cannot have been loaded. Binary modules can do ANYTHING and
> > we have NO IDEA what they are up to, how could you possibly think such a
> > system would be debuggable?
> >
> > Please, search the LKML archives, this has come up again and again and
> > again and still people post bug reports with binary only modules and
> > expect them to be debuggable.
> >
> > Lee
> >
> >
> >
> >
> >
>
> Well Lee, you might be right indeed, but i see only some one who has
> something against binary modules and assuming they're always to blame.
> I do not agree with this and i will proceed from simple to advanced in
> solving this problem, not start thinking difficult while the problem
> might be solved by a simple move. :)
>
No I'm not assuming they are to blame, the point is that without the
source code we can't prove they aren't.
What if the vmware or nvidia module did something wrong that just
happened to work by chance in older kernels? We have no way to prove
that this is not happening.
Lee
Lee Revell wrote:
> On Fri, 2005-12-30 at 22:57 +0100, Mark v Wolher wrote:
>
>>Lee Revell wrote:
>>
>>>On Fri, 2005-12-30 at 22:47 +0100, Mark v Wolher wrote:
>>>
>>>
>>>>Lee Revell wrote:
>>>>
>>>>
>>>>>On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Mark v Wolher wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Mark v Wolher wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Folkert van Heusden wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
>>>>>>>>>>and after a restart with irqbalance i see the cpu's show numbers !
>>>>>>>>>>I guess MSI was preventing them ? But does that means because of MSI
>>>>>>>>>>that performance was lower in some way ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>did you also restart with only irqbalance activated?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Folkert van Heusden
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
>>>>>>>>rebooted without the irqbalance daemon and it showed no reaction on the
>>>>>>>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
>>>>>>>
>>>>>>>>from the cpu's.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I'm also curious if this will solve those random freezes...which somehow
>>>>>>>>i suspect have to do with the tvcard and maybe having MSI on.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>:( just got a total freeze, number 2 today. This time i noticed the
>>>>>>>mouse started to go very slow and 2 seconds later all was frozen.
>>>>>>>
>>>>>>>Maybe it's because of vmware ... i will not use vmware and see how it goes.
>>>>>>>-
>>>>>>
>>>>>>
>>>>>>Some new info, i just noticed this in the logs:
>>>>>>
>>>>>>
>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
>>>>>>OFLOW FBUS OCERR*
>>>>>>Dec 30 22:21:24 localhost last message repeated 5 times
>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
>>>>>>irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
>>>>>>
>>>>>>
>>>>>>But vmware is not active at this moment, i'll not use vmware and see if
>>>>>>a freeze occurs, i'll test up to 24 hours.
>>>>>>
>>>>>>I can swear it might have to do with the tvcard with tv on and vmware at
>>>>>>the same time also active. Or maybe just 1 of them. I'm even considering
>>>>>>to buy tomorrow a new tvcard and see if it makes any difference.
>>>>>
>>>>>
>>>>>It does not matter whether VMWare is active at the moment. Any bug
>>>>>report where a binary module has been loaded, active or not, is tainted.
>>>>>
>>>>>Can you reproduce with a 100% clean kernel?
>>>>>
>>>>>Lee
>>>>>
>>>>
>>>>Hi Lee,
>>>>
>>>>But unloading all vmware modules should be good enough ? And how about
>>>>the binary module of nvidia ? It's active ofcourse else i'd not be able
>>>>to use all the features i normally use.
>>>>
>>>>Eitherway, several kernels back also made no difference for this issue.
>>>>
>>>>So right now, i'm leaning on the experience i have with working with
>>>>this system and trying to isolate things i suspect, before i go to more
>>>>radical steps :)
>>>>
>>>>And again, under windows 2k server, xp pro, redhat enterprise and
>>>>freebsd i never had these issues.
>>>>
>>>
>>>
>>>No, it's not good enough to unload them and no, the nvidia module
>>>absolutely cannot have been loaded. Binary modules can do ANYTHING and
>>>we have NO IDEA what they are up to, how could you possibly think such a
>>>system would be debuggable?
>>>
>>>Please, search the LKML archives, this has come up again and again and
>>>again and still people post bug reports with binary only modules and
>>>expect them to be debuggable.
>>>
>>>Lee
>>>
>>>
>>>
>>>
>>>
>>
>>Well Lee, you might be right indeed, but i see only some one who has
>>something against binary modules and assuming they're always to blame.
>>I do not agree with this and i will proceed from simple to advanced in
>>solving this problem, not start thinking difficult while the problem
>>might be solved by a simple move. :)
>>
>
>
> No I'm not assuming they are to blame, the point is that without the
> source code we can't prove they aren't.
>
> What if the vmware or nvidia module did something wrong that just
> happened to work by chance in older kernels? We have no way to prove
> that this is not happening.
>
> Lee
>
>
>
Yes, "what if" .. that means anything could be the cause, even a
cockroach in the box causing circuit to fail when it moves hehe
So don't worry, first i'll do these very simple tests and see what
effect they have and later go to more radical moves and strip all binary
modules and so on. This is only the initial point where i start to look
for common problems and people can give their advise in general.
On Fri, 2005-12-30 at 23:05 +0100, Mark v Wolher wrote:
> Lee Revell wrote:
> > On Fri, 2005-12-30 at 22:57 +0100, Mark v Wolher wrote:
> >
> >>Lee Revell wrote:
> >>
> >>>On Fri, 2005-12-30 at 22:47 +0100, Mark v Wolher wrote:
> >>>
> >>>
> >>>>Lee Revell wrote:
> >>>>
> >>>>
> >>>>>On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Mark v Wolher wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Mark v Wolher wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Folkert van Heusden wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
> >>>>>>>>>>and after a restart with irqbalance i see the cpu's show numbers !
> >>>>>>>>>>I guess MSI was preventing them ? But does that means because of MSI
> >>>>>>>>>>that performance was lower in some way ?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>did you also restart with only irqbalance activated?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>Folkert van Heusden
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
> >>>>>>>>rebooted without the irqbalance daemon and it showed no reaction on the
> >>>>>>>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
> >>>>>>>
> >>>>>>>>from the cpu's.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>I'm also curious if this will solve those random freezes...which somehow
> >>>>>>>>i suspect have to do with the tvcard and maybe having MSI on.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>:( just got a total freeze, number 2 today. This time i noticed the
> >>>>>>>mouse started to go very slow and 2 seconds later all was frozen.
> >>>>>>>
> >>>>>>>Maybe it's because of vmware ... i will not use vmware and see how it goes.
> >>>>>>>-
> >>>>>>
> >>>>>>
> >>>>>>Some new info, i just noticed this in the logs:
> >>>>>>
> >>>>>>
> >>>>>>Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
> >>>>>>OFLOW FBUS OCERR*
> >>>>>>Dec 30 22:21:24 localhost last message repeated 5 times
> >>>>>>Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
> >>>>>>irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
> >>>>>>Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
> >>>>>>Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
> >>>>>>
> >>>>>>
> >>>>>>But vmware is not active at this moment, i'll not use vmware and see if
> >>>>>>a freeze occurs, i'll test up to 24 hours.
> >>>>>>
> >>>>>>I can swear it might have to do with the tvcard with tv on and vmware at
> >>>>>>the same time also active. Or maybe just 1 of them. I'm even considering
> >>>>>>to buy tomorrow a new tvcard and see if it makes any difference.
> >>>>>
> >>>>>
> >>>>>It does not matter whether VMWare is active at the moment. Any bug
> >>>>>report where a binary module has been loaded, active or not, is tainted.
> >>>>>
> >>>>>Can you reproduce with a 100% clean kernel?
> >>>>>
> >>>>>Lee
> >>>>>
> >>>>
> >>>>Hi Lee,
> >>>>
> >>>>But unloading all vmware modules should be good enough ? And how about
> >>>>the binary module of nvidia ? It's active ofcourse else i'd not be able
> >>>>to use all the features i normally use.
> >>>>
> >>>>Eitherway, several kernels back also made no difference for this issue.
> >>>>
> >>>>So right now, i'm leaning on the experience i have with working with
> >>>>this system and trying to isolate things i suspect, before i go to more
> >>>>radical steps :)
> >>>>
> >>>>And again, under windows 2k server, xp pro, redhat enterprise and
> >>>>freebsd i never had these issues.
> >>>>
> >>>
> >>>
> >>>No, it's not good enough to unload them and no, the nvidia module
> >>>absolutely cannot have been loaded. Binary modules can do ANYTHING and
> >>>we have NO IDEA what they are up to, how could you possibly think such a
> >>>system would be debuggable?
> >>>
> >>>Please, search the LKML archives, this has come up again and again and
> >>>again and still people post bug reports with binary only modules and
> >>>expect them to be debuggable.
> >>>
> >>>Lee
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>Well Lee, you might be right indeed, but i see only some one who has
> >>something against binary modules and assuming they're always to blame.
> >>I do not agree with this and i will proceed from simple to advanced in
> >>solving this problem, not start thinking difficult while the problem
> >>might be solved by a simple move. :)
> >>
> >
> >
> > No I'm not assuming they are to blame, the point is that without the
> > source code we can't prove they aren't.
> >
> > What if the vmware or nvidia module did something wrong that just
> > happened to work by chance in older kernels? We have no way to prove
> > that this is not happening.
> >
> > Lee
> >
> >
> >
>
> Yes, "what if" .. that means anything could be the cause, even a
> cockroach in the box causing circuit to fail when it moves hehe
> So don't worry, first i'll do these very simple tests and see what
> effect they have and later go to more radical moves and strip all binary
> modules and so on. This is only the initial point where i start to look
> for common problems and people can give their advise in general.
Removing binary modules is not a radical step - it's the first thing you
should try if you have a problem with the kernel.
Basically you are asking for help with an unsupported configuration. In
general people on LKML will be more helpful if you take the time to find
out what the bug reporting guidelines are before posting.
Lee
Lee Revell wrote:
> On Fri, 2005-12-30 at 23:05 +0100, Mark v Wolher wrote:
>
>>Lee Revell wrote:
>>
>>>On Fri, 2005-12-30 at 22:57 +0100, Mark v Wolher wrote:
>>>
>>>
>>>>Lee Revell wrote:
>>>>
>>>>
>>>>>On Fri, 2005-12-30 at 22:47 +0100, Mark v Wolher wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Lee Revell wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Fri, 2005-12-30 at 22:30 +0100, Mark v Wolher wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Mark v Wolher wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Mark v Wolher wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Folkert van Heusden wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>Hmm, i disabled MSI in the kernel, irq-balancing is on in the kernel,
>>>>>>>>>>>>and after a restart with irqbalance i see the cpu's show numbers !
>>>>>>>>>>>>I guess MSI was preventing them ? But does that means because of MSI
>>>>>>>>>>>>that performance was lower in some way ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>did you also restart with only irqbalance activated?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Folkert van Heusden
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Yes, when MSI was disabled i had irq-balancing in the kernel on, i
>>>>>>>>>>rebooted without the irqbalance daemon and it showed no reaction on the
>>>>>>>>>>cpu's. When i enabled the irqbalance daemon then i got finally reaction
>>>>>>>>>
>>>>>>>>>>from the cpu's.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>I'm also curious if this will solve those random freezes...which somehow
>>>>>>>>>>i suspect have to do with the tvcard and maybe having MSI on.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>:( just got a total freeze, number 2 today. This time i noticed the
>>>>>>>>>mouse started to go very slow and 2 seconds later all was frozen.
>>>>>>>>>
>>>>>>>>>Maybe it's because of vmware ... i will not use vmware and see how it goes.
>>>>>>>>>-
>>>>>>>>
>>>>>>>>
>>>>>>>>Some new info, i just noticed this in the logs:
>>>>>>>>
>>>>>>>>
>>>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: OCERR @ 1fde0000,bits: HSYNC
>>>>>>>>OFLOW FBUS OCERR*
>>>>>>>>Dec 30 22:21:24 localhost last message repeated 5 times
>>>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: timeout: drop=0
>>>>>>>>irq=41296/41296, risc=1fde001c, bits: HSYNC OFLOW
>>>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: reset, reinitialize
>>>>>>>>Dec 30 22:21:24 localhost kernel: bttv0: PLL: 28636363 => 35468950 . ok
>>>>>>>>
>>>>>>>>
>>>>>>>>But vmware is not active at this moment, i'll not use vmware and see if
>>>>>>>>a freeze occurs, i'll test up to 24 hours.
>>>>>>>>
>>>>>>>>I can swear it might have to do with the tvcard with tv on and vmware at
>>>>>>>>the same time also active. Or maybe just 1 of them. I'm even considering
>>>>>>>>to buy tomorrow a new tvcard and see if it makes any difference.
>>>>>>>
>>>>>>>
>>>>>>>It does not matter whether VMWare is active at the moment. Any bug
>>>>>>>report where a binary module has been loaded, active or not, is tainted.
>>>>>>>
>>>>>>>Can you reproduce with a 100% clean kernel?
>>>>>>>
>>>>>>>Lee
>>>>>>>
>>>>>>
>>>>>>Hi Lee,
>>>>>>
>>>>>>But unloading all vmware modules should be good enough ? And how about
>>>>>>the binary module of nvidia ? It's active ofcourse else i'd not be able
>>>>>>to use all the features i normally use.
>>>>>>
>>>>>>Eitherway, several kernels back also made no difference for this issue.
>>>>>>
>>>>>>So right now, i'm leaning on the experience i have with working with
>>>>>>this system and trying to isolate things i suspect, before i go to more
>>>>>>radical steps :)
>>>>>>
>>>>>>And again, under windows 2k server, xp pro, redhat enterprise and
>>>>>>freebsd i never had these issues.
>>>>>>
>>>>>
>>>>>
>>>>>No, it's not good enough to unload them and no, the nvidia module
>>>>>absolutely cannot have been loaded. Binary modules can do ANYTHING and
>>>>>we have NO IDEA what they are up to, how could you possibly think such a
>>>>>system would be debuggable?
>>>>>
>>>>>Please, search the LKML archives, this has come up again and again and
>>>>>again and still people post bug reports with binary only modules and
>>>>>expect them to be debuggable.
>>>>>
>>>>>Lee
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>Well Lee, you might be right indeed, but i see only some one who has
>>>>something against binary modules and assuming they're always to blame.
>>>>I do not agree with this and i will proceed from simple to advanced in
>>>>solving this problem, not start thinking difficult while the problem
>>>>might be solved by a simple move. :)
>>>>
>>>
>>>
>>>No I'm not assuming they are to blame, the point is that without the
>>>source code we can't prove they aren't.
>>>
>>>What if the vmware or nvidia module did something wrong that just
>>>happened to work by chance in older kernels? We have no way to prove
>>>that this is not happening.
>>>
>>>Lee
>>>
>>>
>>>
>>
>>Yes, "what if" .. that means anything could be the cause, even a
>>cockroach in the box causing circuit to fail when it moves hehe
>>So don't worry, first i'll do these very simple tests and see what
>>effect they have and later go to more radical moves and strip all binary
>>modules and so on. This is only the initial point where i start to look
>>for common problems and people can give their advise in general.
>
>
> Removing binary modules is not a radical step - it's the first thing you
> should try if you have a problem with the kernel.
>
> Basically you are asking for help with an unsupported configuration. In
> general people on LKML will be more helpful if you take the time to find
> out what the bug reporting guidelines are before posting.
>
> Lee
>
>
>
Thank you for your input, but sometimes thinking out of the box gives a
solution instead of hiding behind "guidelines".
On Friday 30 December 2005 22:16, Mark v Wolher wrote:
[snip]
> >
> > Basically you are asking for help with an unsupported configuration. In
> > general people on LKML will be more helpful if you take the time to find
> > out what the bug reporting guidelines are before posting.
> >
> > Lee
>
> Thank you for your input, but sometimes thinking out of the box gives a
> solution instead of hiding behind "guidelines".
I'm surprised Lee fed you this long, but the cold hard fact of the matter is
that you are posting to the Linux kernel mailing lists, and you will comply
with these guidelines if you expect help.
I'm sure the problem might not be with VMWare, but there is absolutely nothing
stopping you from switching nvidia with nv, not loading nvidia/vmware
modules, then running the TV card doing *something else* for a few hours. If
you do not detect lockups, contact VMWare. They will probably do the exact
opposite of what Lee has done and suggest non-VMWare parts of the system are
at fault.
However, unlike VMWare or NVIDIA, we can actually debug problems if you use
source-available modules. Thinking outside of the box here is irrelevant -- a
problem requires logical procedure to gain a solution. Any engineer will tell
you the same thing. Ordinarily, this is test, observe, retest, and all Lee is
suggesting is that you do *not* load the proprietary modules.
Try it before responding to this email, so you do not have to write another.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan wrote:
> On Friday 30 December 2005 22:16, Mark v Wolher wrote:
> [snip]
>
>>>Basically you are asking for help with an unsupported configuration. In
>>>general people on LKML will be more helpful if you take the time to find
>>>out what the bug reporting guidelines are before posting.
>>>
>>>Lee
>>
>>Thank you for your input, but sometimes thinking out of the box gives a
>>solution instead of hiding behind "guidelines".
>
>
> I'm surprised Lee fed you this long, but the cold hard fact of the matter is
> that you are posting to the Linux kernel mailing lists, and you will comply
> with these guidelines if you expect help.
>
> I'm sure the problem might not be with VMWare, but there is absolutely nothing
> stopping you from switching nvidia with nv, not loading nvidia/vmware
> modules, then running the TV card doing *something else* for a few hours. If
> you do not detect lockups, contact VMWare. They will probably do the exact
> opposite of what Lee has done and suggest non-VMWare parts of the system are
> at fault.
>
> However, unlike VMWare or NVIDIA, we can actually debug problems if you use
> source-available modules. Thinking outside of the box here is irrelevant -- a
> problem requires logical procedure to gain a solution. Any engineer will tell
> you the same thing. Ordinarily, this is test, observe, retest, and all Lee is
> suggesting is that you do *not* load the proprietary modules.
>
> Try it before responding to this email, so you do not have to write another.
>
I already switched nvidia for the nv driver in the kernel. Also disabled
by unloading all modules.
You're saying i should then see what happens after doing the above ...
This is exactly what i'm now doing, tvcard is active (tv) and i'm doing
some work as usual. I get the feeling some people consider everyone who
is a bit different in approach as either some newbie or an idiot, well
wake up, sometimes by looking from a different view at a problem it can
be solved. This doesn't mean i don't appreciate the advise of Lee or
yours, i only ask for some patience. It's not like the world is going
under if we don't solve this in an hour with traditional logic. :)
And at this point the system is still working, i'm increasing the load
by making it crush numbers, doing a full virusscan and so on.
On Friday 30 December 2005 23:42, Mark v Wolher wrote:
> Alistair John Strachan wrote:
> > On Friday 30 December 2005 22:16, Mark v Wolher wrote:
> > [snip]
> >
> >>>Basically you are asking for help with an unsupported configuration. In
> >>>general people on LKML will be more helpful if you take the time to find
> >>>out what the bug reporting guidelines are before posting.
> >>>
> >>>Lee
> >>
> >>Thank you for your input, but sometimes thinking out of the box gives a
> >>solution instead of hiding behind "guidelines".
> >
> > I'm surprised Lee fed you this long, but the cold hard fact of the matter
> > is that you are posting to the Linux kernel mailing lists, and you will
> > comply with these guidelines if you expect help.
> >
> > I'm sure the problem might not be with VMWare, but there is absolutely
> > nothing stopping you from switching nvidia with nv, not loading
> > nvidia/vmware modules, then running the TV card doing *something else*
> > for a few hours. If you do not detect lockups, contact VMWare. They will
> > probably do the exact opposite of what Lee has done and suggest
> > non-VMWare parts of the system are at fault.
> >
> > However, unlike VMWare or NVIDIA, we can actually debug problems if you
> > use source-available modules. Thinking outside of the box here is
> > irrelevant -- a problem requires logical procedure to gain a solution.
> > Any engineer will tell you the same thing. Ordinarily, this is test,
> > observe, retest, and all Lee is suggesting is that you do *not* load the
> > proprietary modules.
> >
> > Try it before responding to this email, so you do not have to write
> > another.
>
> I already switched nvidia for the nv driver in the kernel. Also disabled
> by unloading all modules.
As Lee already explained, "unloading" is insufficient. If you continue to
argue that it is sufficient, then you are only exposing your own ignorance of
the issues at hand. Please physically delete the modules so that they cannot
ever be loaded by the kernel during or after bootup, then reboot the machine
before testing.
> You're saying i should then see what happens after doing the above ...
> This is exactly what i'm now doing, tvcard is active (tv) and i'm doing
> some work as usual. I get the feeling some people consider everyone who
> is a bit different in approach as either some newbie or an idiot, well
> wake up, sometimes by looking from a different view at a problem it can
> be solved. This doesn't mean i don't appreciate the advise of Lee or
> yours, i only ask for some patience. It's not like the world is going
> under if we don't solve this in an hour with traditional logic. :)
Feel free to try any method you like, but the method myself and Lee have
stated is the only one acceptable on this list.
> And at this point the system is still working, i'm increasing the load
> by making it crush numbers, doing a full virusscan and so on.
This is good news -- you stand a better chance of achieving the stability you
require by eliminating variables. VMWare and NVIDIA are useful softwares, and
I would not deny that, but they are closed source and thus any conflicts
resulting from their use are not necessary LKML material (however, if the
interaction is generic and is as a result of a kernel bug, then the
maintainer would very much like to hear it).
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan wrote:
> On Friday 30 December 2005 23:42, Mark v Wolher wrote:
>
>>Alistair John Strachan wrote:
>>
>>>On Friday 30 December 2005 22:16, Mark v Wolher wrote:
>>>[snip]
>>>
>>>
>>>>>Basically you are asking for help with an unsupported configuration. In
>>>>>general people on LKML will be more helpful if you take the time to find
>>>>>out what the bug reporting guidelines are before posting.
>>>>>
>>>>>Lee
>>>>
>>>>Thank you for your input, but sometimes thinking out of the box gives a
>>>>solution instead of hiding behind "guidelines".
>>>
>>>I'm surprised Lee fed you this long, but the cold hard fact of the matter
>>>is that you are posting to the Linux kernel mailing lists, and you will
>>>comply with these guidelines if you expect help.
>>>
>>>I'm sure the problem might not be with VMWare, but there is absolutely
>>>nothing stopping you from switching nvidia with nv, not loading
>>>nvidia/vmware modules, then running the TV card doing *something else*
>>>for a few hours. If you do not detect lockups, contact VMWare. They will
>>>probably do the exact opposite of what Lee has done and suggest
>>>non-VMWare parts of the system are at fault.
>>>
>>>However, unlike VMWare or NVIDIA, we can actually debug problems if you
>>>use source-available modules. Thinking outside of the box here is
>>>irrelevant -- a problem requires logical procedure to gain a solution.
>>>Any engineer will tell you the same thing. Ordinarily, this is test,
>>>observe, retest, and all Lee is suggesting is that you do *not* load the
>>>proprietary modules.
>>>
>>>Try it before responding to this email, so you do not have to write
>>>another.
>>
>>I already switched nvidia for the nv driver in the kernel. Also disabled
>>by unloading all modules.
>
>
> As Lee already explained, "unloading" is insufficient. If you continue to
> argue that it is sufficient, then you are only exposing your own ignorance of
> the issues at hand. Please physically delete the modules so that they cannot
> ever be loaded by the kernel during or after bootup, then reboot the machine
> before testing.
>
>
>>You're saying i should then see what happens after doing the above ...
>>This is exactly what i'm now doing, tvcard is active (tv) and i'm doing
>>some work as usual. I get the feeling some people consider everyone who
>>is a bit different in approach as either some newbie or an idiot, well
>>wake up, sometimes by looking from a different view at a problem it can
>>be solved. This doesn't mean i don't appreciate the advise of Lee or
>>yours, i only ask for some patience. It's not like the world is going
>>under if we don't solve this in an hour with traditional logic. :)
>
>
> Feel free to try any method you like, but the method myself and Lee have
> stated is the only one acceptable on this list.
>
>
>>And at this point the system is still working, i'm increasing the load
>>by making it crush numbers, doing a full virusscan and so on.
>
>
> This is good news -- you stand a better chance of achieving the stability you
> require by eliminating variables. VMWare and NVIDIA are useful softwares, and
> I would not deny that, but they are closed source and thus any conflicts
> resulting from their use are not necessary LKML material (however, if the
> interaction is generic and is as a result of a kernel bug, then the
> maintainer would very much like to hear it).
>
Okay, i have something interesting now, i only had the nvidia module
loaded so my x-configuration starts up as usual. (not saying the nvidia
module is flawless, i'm sure it still contains bugs)
But here is the crash info, this time it was mozilla, i think this
speaks more hehe :
Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
Dec 31 00:55:28 localhost kernel: SMP
Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia
Dec 31 00:55:28 localhost kernel: CPU: 2
Dec 31 00:55:28 localhost kernel: EIP: 0060:[exit_mmap+323/400]
Tainted: PF VLI
Dec 31 00:55:28 localhost kernel: EFLAGS: 00010202 (2.6.14.5)
Dec 31 00:55:28 localhost kernel: eax: 00000071 ebx: 00000000 ecx:
c9b02660 edx: dff65e00
Dec 31 00:55:28 localhost kernel: esi: 00000000 edi: 00000007 ebp:
de48d0c0 esp: cb4b5dfc
Dec 31 00:55:28 localhost kernel: ds: 007b es: 007b ss: 0068
Dec 31 00:55:28 localhost kernel: Process mozilla-bin (pid: 22417,
threadinfo=cb4b4000 task=c9f25030)
Dec 31 00:55:28 localhost kernel: Stack: c9b02628 00000000 00000000 00000000
ffffffff cb4b5e1c 00000000 c1411600
Dec 31 00:55:28 localhost kernel: 000070a6 de48d080 de48d0c4 c9f254dc
00000009 c0162d68 de48d080 c9f25030
Dec 31 00:55:28 localhost kernel: cb4b4000 c0167b7b de48d080 00000009
00000009 cb4b4000 00000001 00000009
Dec 31 00:55:28 localhost kernel: Call Trace:
Dec 31 00:55:28 localhost kernel: [mmput+56/160]
Dec 31 00:55:28 localhost kernel: [do_exit+235/1040]
Dec 31 00:55:28 localhost kernel: [do_group_exit+64/176]
Dec 31 00:55:28 localhost kernel: [get_signal_to_deliver+560/832]
Dec 31 00:55:28 localhost kernel: [do_signal+143/288]
Dec 31 00:55:28 localhost kernel: [free_task+39/48]
Dec 31 00:55:28 localhost kernel: [pg0+548271682/1066550272]
Dec 31 00:55:28 localhost kernel: [pg0+550504623/1066550272]
Dec 31 00:55:28 localhost kernel: [__do_softirq+214/240]
Dec 31 00:55:28 localhost kernel: [do_notify_resume+55/64]
Dec 31 00:55:28 localhost kernel: [work_notifysig+19/37]
Dec 31 00:55:28 localhost kernel: Code: 00 85 f6 74 14 8d 76 00 8b 5e 0c 89
34 24 e8 45 d7 ff ff 85 db 89 de 75 ef 8b bf 94 00 00 00 85 ff 75 08 83 c4
24 5b 5e 5f 5d c3 <0f> 0b a6 08 73 e3 57 c0 eb ee c7 43 08 00 00 00 00 8b 03
89 04
Dec 31 00:55:28 localhost kernel: <1>Fixing recursive fault but reboot is
needed!
And i appreciate your time and bother.
On Saturday 31 December 2005 00:20, Mark v Wolher wrote:
[snip]
> >
> > This is good news -- you stand a better chance of achieving the stability
> > you require by eliminating variables. VMWare and NVIDIA are useful
> > softwares, and I would not deny that, but they are closed source and thus
> > any conflicts resulting from their use are not necessary LKML material
> > (however, if the interaction is generic and is as a result of a kernel
> > bug, then the maintainer would very much like to hear it).
>
> Okay, i have something interesting now, i only had the nvidia module
> loaded so my x-configuration starts up as usual. (not saying the nvidia
> module is flawless, i'm sure it still contains bugs)
> But here is the crash info, this time it was mozilla, i think this
> speaks more hehe :
>
> Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
> Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
> Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
> Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
> Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
> Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
> Dec 31 00:55:28 localhost kernel: SMP
> Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia
Steady and sure progress. Now, the trace below doesn't explicitly mention any
nvidia symbols, but this line must disappear before anybody will bother to
read your report.
Remove the module. This does not mean unload, this means "never load in the
first place". Then reproduce the problem. If you are successful, send a new
email (not pinned to this thread) with a subject a la "kernel BUG at
mm/mmap.c:2214". State that the kernel is not tainted.
At this point all you can do is wait. Good luck!
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan wrote:
> On Saturday 31 December 2005 00:20, Mark v Wolher wrote:
> [snip]
>
>>>This is good news -- you stand a better chance of achieving the stability
>>>you require by eliminating variables. VMWare and NVIDIA are useful
>>>softwares, and I would not deny that, but they are closed source and thus
>>>any conflicts resulting from their use are not necessary LKML material
>>>(however, if the interaction is generic and is as a result of a kernel
>>>bug, then the maintainer would very much like to hear it).
>>
>>Okay, i have something interesting now, i only had the nvidia module
>>loaded so my x-configuration starts up as usual. (not saying the nvidia
>>module is flawless, i'm sure it still contains bugs)
>>But here is the crash info, this time it was mozilla, i think this
>>speaks more hehe :
>>
>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
>>Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
>>Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
>>Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
>>Dec 31 00:55:28 localhost kernel: SMP
>>Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia
>
>
> Steady and sure progress. Now, the trace below doesn't explicitly mention any
> nvidia symbols, but this line must disappear before anybody will bother to
> read your report.
>
> Remove the module. This does not mean unload, this means "never load in the
> first place". Then reproduce the problem. If you are successful, send a new
> email (not pinned to this thread) with a subject a la "kernel BUG at
> mm/mmap.c:2214". State that the kernel is not tainted.
>
> At this point all you can do is wait. Good luck!
>
Well, i guess i'll have to do that to be sure. But i must say that i did
try the nv module and de-installed the nvidia binary module. It didn't
matter, the system froze but didn't leave anything in the logs, this
time it did. Doesn't that help at all ?
I'll try again, put nv up and wait for a something to happen. If some
one has in the meantime more advise or maybe even could check out of
curiousity why it says kernel BUG i'd appreciate it ofcourse.
On Saturday 31 December 2005 00:42, Mark v Wolher wrote:
> Alistair John Strachan wrote:
> > On Saturday 31 December 2005 00:20, Mark v Wolher wrote:
> > [snip]
> >
> >>>This is good news -- you stand a better chance of achieving the
> >>> stability you require by eliminating variables. VMWare and NVIDIA are
> >>> useful softwares, and I would not deny that, but they are closed source
> >>> and thus any conflicts resulting from their use are not necessary LKML
> >>> material (however, if the interaction is generic and is as a result of
> >>> a kernel bug, then the maintainer would very much like to hear it).
> >>
> >>Okay, i have something interesting now, i only had the nvidia module
> >>loaded so my x-configuration starts up as usual. (not saying the nvidia
> >>module is flawless, i'm sure it still contains bugs)
> >>But here is the crash info, this time it was mozilla, i think this
> >>speaks more hehe :
> >>
> >>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
> >>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
> >>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
> >>Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
> >>Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
> >>Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
> >>Dec 31 00:55:28 localhost kernel: SMP
> >>Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia
> >
> > Steady and sure progress. Now, the trace below doesn't explicitly mention
> > any nvidia symbols, but this line must disappear before anybody will
> > bother to read your report.
> >
> > Remove the module. This does not mean unload, this means "never load in
> > the first place". Then reproduce the problem. If you are successful, send
> > a new email (not pinned to this thread) with a subject a la "kernel BUG
> > at mm/mmap.c:2214". State that the kernel is not tainted.
> >
> > At this point all you can do is wait. Good luck!
>
> Well, i guess i'll have to do that to be sure. But i must say that i did
> try the nv module and de-installed the nvidia binary module. It didn't
> matter, the system froze but didn't leave anything in the logs, this
> time it did. Doesn't that help at all ?
>
> I'll try again, put nv up and wait for a something to happen. If some
> one has in the meantime more advise or maybe even could check out of
> curiousity why it says kernel BUG i'd appreciate it ofcourse.
Probably upwards of 95% of BUGs in mm/ are due to defective memory in the
system running the kernel. However, since you claim to have run other OSes
successfully on this configuration, I did not suggest it.
However, I would highly recommend running memtest86 at least twice on the
machine if you cannot track down the source of the problem.
It is always worth eliminating hardware.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan wrote:
> On Saturday 31 December 2005 00:42, Mark v Wolher wrote:
>
>>Alistair John Strachan wrote:
>>
>>>On Saturday 31 December 2005 00:20, Mark v Wolher wrote:
>>>[snip]
>>>
>>>
>>>>>This is good news -- you stand a better chance of achieving the
>>>>>stability you require by eliminating variables. VMWare and NVIDIA are
>>>>>useful softwares, and I would not deny that, but they are closed source
>>>>>and thus any conflicts resulting from their use are not necessary LKML
>>>>>material (however, if the interaction is generic and is as a result of
>>>>>a kernel bug, then the maintainer would very much like to hear it).
>>>>
>>>>Okay, i have something interesting now, i only had the nvidia module
>>>>loaded so my x-configuration starts up as usual. (not saying the nvidia
>>>>module is flawless, i'm sure it still contains bugs)
>>>>But here is the crash info, this time it was mozilla, i think this
>>>>speaks more hehe :
>>>>
>>>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
>>>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
>>>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
>>>>Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
>>>>Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
>>>>Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
>>>>Dec 31 00:55:28 localhost kernel: SMP
>>>>Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia
>>>
>>>Steady and sure progress. Now, the trace below doesn't explicitly mention
>>>any nvidia symbols, but this line must disappear before anybody will
>>>bother to read your report.
>>>
>>>Remove the module. This does not mean unload, this means "never load in
>>>the first place". Then reproduce the problem. If you are successful, send
>>>a new email (not pinned to this thread) with a subject a la "kernel BUG
>>>at mm/mmap.c:2214". State that the kernel is not tainted.
>>>
>>>At this point all you can do is wait. Good luck!
>>
>>Well, i guess i'll have to do that to be sure. But i must say that i did
>>try the nv module and de-installed the nvidia binary module. It didn't
>>matter, the system froze but didn't leave anything in the logs, this
>>time it did. Doesn't that help at all ?
>>
>>I'll try again, put nv up and wait for a something to happen. If some
>>one has in the meantime more advise or maybe even could check out of
>>curiousity why it says kernel BUG i'd appreciate it ofcourse.
>
>
> Probably upwards of 95% of BUGs in mm/ are due to defective memory in the
> system running the kernel. However, since you claim to have run other OSes
> successfully on this configuration, I did not suggest it.
>
> However, I would highly recommend running memtest86 at least twice on the
> machine if you cannot track down the source of the problem.
>
> It is always worth eliminating hardware.
>
Indeed, i'm going soon to get some sleep but leave memtest86 running for
the night and when i wake up then i'll see if something is reported.
It's 2x256 pc2100 ECC memory. I also expect next week monday or tuesday
new memory, which i can use to replace this memory and exclude that
eitherway.
Thanks !
Mark v Wolher wrote:
> Alistair John Strachan wrote:
>
>>On Saturday 31 December 2005 00:42, Mark v Wolher wrote:
>>
>>
>>>Alistair John Strachan wrote:
>>>
>>>
>>>>On Saturday 31 December 2005 00:20, Mark v Wolher wrote:
>>>>[snip]
>>>>
>>>>
>>>>
>>>>>>This is good news -- you stand a better chance of achieving the
>>>>>>stability you require by eliminating variables. VMWare and NVIDIA are
>>>>>>useful softwares, and I would not deny that, but they are closed source
>>>>>>and thus any conflicts resulting from their use are not necessary LKML
>>>>>>material (however, if the interaction is generic and is as a result of
>>>>>>a kernel bug, then the maintainer would very much like to hear it).
>>>>>
>>>>>Okay, i have something interesting now, i only had the nvidia module
>>>>>loaded so my x-configuration starts up as usual. (not saying the nvidia
>>>>>module is flawless, i'm sure it still contains bugs)
>>>>>But here is the crash info, this time it was mozilla, i think this
>>>>>speaks more hehe :
>>>>>
>>>>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
>>>>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
>>>>>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
>>>>>Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
>>>>>Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
>>>>>Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
>>>>>Dec 31 00:55:28 localhost kernel: SMP
>>>>>Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia
>>>>
>>>>Steady and sure progress. Now, the trace below doesn't explicitly mention
>>>>any nvidia symbols, but this line must disappear before anybody will
>>>>bother to read your report.
>>>>
>>>>Remove the module. This does not mean unload, this means "never load in
>>>>the first place". Then reproduce the problem. If you are successful, send
>>>>a new email (not pinned to this thread) with a subject a la "kernel BUG
>>>>at mm/mmap.c:2214". State that the kernel is not tainted.
>>>>
>>>>At this point all you can do is wait. Good luck!
>>>
>>>Well, i guess i'll have to do that to be sure. But i must say that i did
>>>try the nv module and de-installed the nvidia binary module. It didn't
>>>matter, the system froze but didn't leave anything in the logs, this
>>>time it did. Doesn't that help at all ?
>>>
>>>I'll try again, put nv up and wait for a something to happen. If some
>>>one has in the meantime more advise or maybe even could check out of
>>>curiousity why it says kernel BUG i'd appreciate it ofcourse.
>>
>>
>>Probably upwards of 95% of BUGs in mm/ are due to defective memory in the
>>system running the kernel. However, since you claim to have run other OSes
>>successfully on this configuration, I did not suggest it.
>>
>>However, I would highly recommend running memtest86 at least twice on the
>>machine if you cannot track down the source of the problem.
>>
>>It is always worth eliminating hardware.
>>
>
>
> Indeed, i'm going soon to get some sleep but leave memtest86 running for
> the night and when i wake up then i'll see if something is reported.
> It's 2x256 pc2100 ECC memory. I also expect next week monday or tuesday
> new memory, which i can use to replace this memory and exclude that
> eitherway.
>
> Thanks !
>
>
>
>
g'morning !
the memtest86 went 40 times over the memory, no errors detected.
On 12/31/05, Mark v Wolher <[email protected]> wrote:
>
> g'morning !
>
> the memtest86 went 40 times over the memory, no errors detected.
>
Give memtest86+ a spin (http://www.memtest.org/) as well. memtest86 is
good, but I've found in the past that memtest86+ sometimes finds
errors that memtest86 does not, so giving both a sin fo an extended
period of time is usually a good idea.
Also, make sure you enable all the tests of both tools.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On 12/31/05, Mark v Wolher <[email protected]> wrote:
> Alistair John Strachan wrote:
> > On Saturday 31 December 2005 00:20, Mark v Wolher wrote:
> > [snip]
> >
> >>>This is good news -- you stand a better chance of achieving the stability
> >>>you require by eliminating variables. VMWare and NVIDIA are useful
> >>>softwares, and I would not deny that, but they are closed source and thus
> >>>any conflicts resulting from their use are not necessary LKML material
> >>>(however, if the interaction is generic and is as a result of a kernel
> >>>bug, then the maintainer would very much like to hear it).
> >>
> >>Okay, i have something interesting now, i only had the nvidia module
> >>loaded so my x-configuration starts up as usual. (not saying the nvidia
> >>module is flawless, i'm sure it still contains bugs)
> >>But here is the crash info, this time it was mozilla, i think this
> >>speaks more hehe :
> >>
The fact that it happens to be mozilla that crashes this time says
*nothing at all* as long as you have binary only modules loaded that
may have messed up the kernel without any way for us to debug that.
> >>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 061f0c08.
> >>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 06b96000.
> >>Dec 31 00:55:28 localhost kernel: mm/memory.c:106: bad pgd 18000bf8.
> >>Dec 31 00:55:28 localhost kernel: ------------[ cut here ]------------
> >>Dec 31 00:55:28 localhost kernel: kernel BUG at mm/mmap.c:2214!
> >>Dec 31 00:55:28 localhost kernel: invalid operand: 0000 [#1]
> >>Dec 31 00:55:28 localhost kernel: SMP
> >>Dec 31 00:55:28 localhost kernel: Modules linked in: nvidia
> >
> >
> > Steady and sure progress. Now, the trace below doesn't explicitly mention any
> > nvidia symbols, but this line must disappear before anybody will bother to
> > read your report.
> >
> > Remove the module. This does not mean unload, this means "never load in the
> > first place". Then reproduce the problem. If you are successful, send a new
Agreed. As long as nvidia or vmware binary only modules have even been
loaded once, what state the kernel is in is a complete unknown.
To be useful, all testing you do *must* happen without both the nvidia
and vmware modules ever having been loaded. As soon as you load one of
them for even a second any further testing becomes irrelevant.
> > email (not pinned to this thread) with a subject a la "kernel BUG at
> > mm/mmap.c:2214". State that the kernel is not tainted.
> >
> > At this point all you can do is wait. Good luck!
> >
>
> Well, i guess i'll have to do that to be sure. But i must say that i did
> try the nv module and de-installed the nvidia binary module. It didn't
> matter, the system froze but didn't leave anything in the logs, this
> time it did. Doesn't that help at all ?
>
Not really, since anything it leaves in the logs may have been caused
by the binary only module(s), but we have no way to find out, so the
info is next to useless as long as binary only modules are loaded - it
may be correct or it may be wrong, but we have no way to know.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On 12/30/05, Mark v Wolher <[email protected]> wrote:
>
> Thanks for the advise !
>
> About the memory test, i did that, 7 full passes, no errors, it's 512mb
> ecc memory btw. I'm going to let it, when i go to sleep, run the whole
> night.
>
> hardware:
>
> System is a dell precision workstation 650, dual xeon 2.4ghz w/HT, intel
> E7505 motherboard.
>
> distro: debian sarge
> kernel: vanilla 2.6.14.5
>
> for the rest there is nothing special to see in dmesg output, lspci or
> with lsusb. cpuinfo shows everything what it should show.
>
I was not asking if /you/ thought there was any interresting info in
dmesg, I asked for the dmesg outut so that everyone else on the list
reading your email would be able to get some details about your system
from the output.
The same goes for lsci, lsusb, /proc/cpuinfo, ver_linux output, the
kernel .config etc. We don't have your system nor a kernel build
exactely like yours, so we need those details to be able to help you
better, wether or not you think it is relevant to provide that info is
irrelevant, please just provide the info you are asked for if you want
people to try and help you.
> Memoinfo:
>
> MemTotal: 512528 kB
> MemFree: 8760 kB
> Buffers: 2656 kB
> Cached: 236216 kB
> SwapCached: 2052 kB
> Active: 390480 kB
> Inactive: 54756 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 512528 kB
> LowFree: 8760 kB
> SwapTotal: 4883680 kB
> SwapFree: 4864064 kB
> Dirty: 112 kB
> Writeback: 0 kB
> Mapped: 388988 kB
> Slab: 23320 kB
> CommitLimit: 5139944 kB
> Committed_AS: 518952 kB
> PageTables: 1912 kB
> VmallocTotal: 515796 kB
> VmallocUsed: 25496 kB
> VmallocChunk: 487120 kB
>
Thanks.
>
> Other findings;
>
> - all kernels had the same issue, except (not 100 % sure) 2.4.2X kernels
> - tried acpi=noirq without success and many many other acpi options &
> combo's
> - nvidia binary driver replaced by kernel nv driver but without success
>
> I have no reason to suspect the tvcard which is a terratec value with a
> bt878 chip, support in the kernel. But on the other hand it could be the
> tvcard, but i see no relation to anything with it. I tried also using
> DAC snoop in the bios but no good.
>
If you suspect it at all, even slightly, then why not try and remove
it from the equation by simply taking the card out of the machine for
a while?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jesper Juhl wrote:
> On 12/31/05, Mark v Wolher <[email protected]> wrote:
>
>>g'morning !
>>
>>the memtest86 went 40 times over the memory, no errors detected.
>>
>
> Give memtest86+ a spin (http://www.memtest.org/) as well. memtest86 is
> good, but I've found in the past that memtest86+ sometimes finds
> errors that memtest86 does not, so giving both a sin fo an extended
> period of time is usually a good idea.
> Also, make sure you enable all the tests of both tools.
Hi Jesper,
Oh i thought they were the same, i used memtest86+ which comes with
debian and not the "older" memtest86.
Right now i booted the kernel with nomce since one never knows with dell
machines as i saw on some redhat list. Furthermore i installed the
microcode32 utility which loaded new microcode in the cpu. So i'm now
going to continue put some good load on the system, tv on and so on, see
what happens.
On 12/31/05, Mark v Wolher <[email protected]> wrote:
> Jesper Juhl wrote:
> > On 12/31/05, Mark v Wolher <[email protected]> wrote:
> >
> >>g'morning !
> >>
> >>the memtest86 went 40 times over the memory, no errors detected.
> >>
> >
> > Give memtest86+ a spin (http://www.memtest.org/) as well. memtest86 is
> > good, but I've found in the past that memtest86+ sometimes finds
> > errors that memtest86 does not, so giving both a sin fo an extended
> > period of time is usually a good idea.
> > Also, make sure you enable all the tests of both tools.
>
> Hi Jesper,
>
> Oh i thought they were the same, i used memtest86+ which comes with
> debian and not the "older" memtest86.
>
> Right now i booted the kernel with nomce since one never knows with dell
Surpressing MCE's (Machine Check Exceptions) is a really bad idea
usually. MCE's indicate a hardware problem, so unless it's known that
a certain MCE is reported wrongly they should *not* be ignored.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.14.5-grsec
# Fri Dec 30 19:44:17 2005
#
CONFIG_X86=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_CPUSETS is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_EMBEDDED is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_BKL is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
# CONFIG_IRQBALANCE is not set
# CONFIG_REGPARM is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_PHYSICAL_START=0x100000
# CONFIG_KEXEC is not set
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
CONFIG_ACPI_CONTAINER=m
#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG_CPU is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_ADVANCED=y
#
# TCP congestion control
#
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_WESTWOOD=y
CONFIG_TCP_CONG_HTCP=y
CONFIG_TCP_CONG_HSTCP=y
CONFIG_TCP_CONG_HYBLA=y
CONFIG_TCP_CONG_VEGAS=y
CONFIG_TCP_CONG_SCALABLE=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_TUNNEL=y
CONFIG_IPV6_TUNNEL=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CONNTRACK_NETLINK=y
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
# CONFIG_IP_NF_NETBIOS_NS is not set
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_STEALTH=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_DCCP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_MATCH_CONNMARK=y
CONFIG_IP_NF_MATCH_CONNBYTES=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_MATCH_STRING=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_TARGET_NFQUEUE=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_IP_NF_TARGET_CONNMARK=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_TARGET_NFQUEUE=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m
#
# DCCP Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID3=m
CONFIG_IP_DCCP_TFRC_LIB=m
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=y
CONFIG_NET_EMATCH_NBYTE=y
CONFIG_NET_EMATCH_U32=y
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_PEDIT=y
CONFIG_NET_ACT_SIMP=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_PNPACPI=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_PDC202XX_FORCE=y
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA24XX is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
#
# Fusion MPT device support
#
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set
# CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set
# CONFIG_IEEE1394_EXPORT_FULL_API is not set
#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
# CONFIG_IEEE1394_OHCI1394 is not set
#
# Protocol Drivers
#
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_RAWIO=m
# CONFIG_IEEE1394_CMP is not set
#
# I2O device support
#
CONFIG_I2O=y
CONFIG_I2O_EXT_ADAPTEC=y
# CONFIG_I2O_CONFIG is not set
# CONFIG_I2O_BUS is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
CONFIG_SHAPER=m
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=y
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=y
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
CONFIG_I2C_PIIX4=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
#
# Multimedia Capabilities Port drivers
#
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y
#
# Video For Linux
#
#
# Video Adapters
#
CONFIG_VIDEO_BT848=y
# CONFIG_VIDEO_SAA6588 is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_BUF=y
CONFIG_VIDEO_BTCX=y
CONFIG_VIDEO_IR=y
CONFIG_VIDEO_TVEEPROM=y
#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SOFT_CURSOR=y
# CONFIG_FB_MACMODES is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=y
CONFIG_FB_VESA=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_FB_HGA is not set
CONFIG_FB_NVIDIA=m
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set
#
# Logo configuration
#
# CONFIG_LOGO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
CONFIG_SOUND=y
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_AC97_BUS=y
#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_BT87X=y
# CONFIG_SND_BT87X_OVERCLOCK is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
CONFIG_SND_EMU10K1=y
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_HDA_INTEL is not set
#
# USB devices
#
CONFIG_SND_USB_AUDIO=y
# CONFIG_SND_USB_USX2Y is not set
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_OBSOLETE_OSS_USB_DRIVER is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_ITMTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
CONFIG_USB_PWC=m
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=y
# CONFIG_MMC_WBSD is not set
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# SN Devices
#
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
CONFIG_MINIX_FS=y
CONFIG_ROMFS_FS=y
CONFIG_INOTIFY=y
CONFIG_QUOTA=y
CONFIG_QFMT_V1=y
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_RELAYFS_FS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Profiling support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_TEST=y
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
#
# Library routines
#
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y
Mark v Wolher wrote:
> Jesper Juhl wrote:
>
>>On 12/31/05, Mark v Wolher <[email protected]> wrote:
>>
>>
>>>Jesper Juhl wrote:
>>>
>>>
>>>>On 12/31/05, Mark v Wolher <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>>>g'morning !
>>>>>
>>>>>the memtest86 went 40 times over the memory, no errors detected.
>>>>>
>>>>
>>>>Give memtest86+ a spin (http://www.memtest.org/) as well. memtest86 is
>>>>good, but I've found in the past that memtest86+ sometimes finds
>>>>errors that memtest86 does not, so giving both a sin fo an extended
>>>>period of time is usually a good idea.
>>>>Also, make sure you enable all the tests of both tools.
>>>
>>>Hi Jesper,
>>>
>>>Oh i thought they were the same, i used memtest86+ which comes with
>>>debian and not the "older" memtest86.
>>>
>>>Right now i booted the kernel with nomce since one never knows with dell
>>
>>
>>Surpressing MCE's (Machine Check Exceptions) is a really bad idea
>>usually. MCE's indicate a hardware problem, so unless it's known that
>>a certain MCE is reported wrongly they should *not* be ignored.
>
>
> Hi Jesper,
>
> Yes, i rather not disable it, but since i found some reports also
> related to dell machines which somehow do not follow always the standard
> this caused false exceptions on them. I'll re-enable it, and see if the
> update of the intel microcode made a difference. I have now only the nv
> module loaded. If a crash occurs i'll open the box and remove the tvcard.
>
> Also, i wonder, i downloaded the DSDT table from the bios and when i
> recompiled it with IASL from intel it showed 7 errors, one of them
> related to DMA. It is known that alot of companies like Dell use
> microsoft compilers which easily skip such errors or not report them,
> this is what i read.
>
> I'm pasting the DSDT errors occured during recompile, who knows, this
> could also a help a little bit.
>
> DSDT Table / Recompile:
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20050930 [Dec 15 2005]
> Copyright (C) 2000 - 2005 Intel Corporation
> Supports ACPI Specification Revision 3.0
>
> dsdt.dsl 338: Notify (\_SB.PCI0.USB0, 0x02)
> Error 1061 - Object does not exist ^ (\_SB.PCI0.USB0)
>
> dsdt.dsl 351: Notify (\_SB.PCI0.USB1, 0x02)
> Error 1061 - Object does not exist ^ (\_SB.PCI0.USB1)
>
> dsdt.dsl 364: Notify (\_SB.PCI0.USB2, 0x02)
> Error 1061 - Object does not exist ^ (\_SB.PCI0.USB2)
>
> dsdt.dsl 377: Notify (\_SB.PCI0, 0x02)
> Error 1061 - Object does not exist ^ (\_SB.PCI0)
>
> dsdt.dsl 384: Notify (\_SB.PCI0.PCI4, 0x02)
> Error 1061 - Object does not exist ^ (\_SB.PCI0.PCI4)
>
> dsdt.dsl 400: Notify (\_SB.PCI0.ISA.KBD, 0x02)
> Error 1061 - Object does not exist ^ (\_SB.PCI0.ISA.KBD)
>
> dsdt.dsl 1784: Device (DMA)
> Error 1094 - ^ syntax error, unexpected
> PARSEOP_DMA, expecting PARSEOP_NAMESEG or PARSEOP_NAMESTRING
>
> ASL Input: dsdt.dsl - 3096 lines, 93624 bytes, 515 keywords
> Compilation complete. 7 Errors, 0 Warnings, 0 Remarks, 53 Optimizations
>
>
> ====
>
> LSUSB:
> Bus 004 Device 002: ID 0d8c:0001 C-Media Electronics, Inc.
> Bus 004 Device 001: ID 0000:0000
> Bus 003 Device 003: ID 051d:0002 American Power Conversion Back-UPS Pro
> 500/1000/1500
> Bus 003 Device 002: ID 046d:c00e Logitech, Inc. Optical Mouse
> Bus 003 Device 001: ID 0000:0000
> Bus 002 Device 001: ID 0000:0000
> Bus 001 Device 001: ID 0000:0000
>
>
> =====
>
> cat /proc/meminfo:
>
> MemTotal: 512548 kB
> MemFree: 10684 kB
> Buffers: 17252 kB
> Cached: 221508 kB
> SwapCached: 10120 kB
> Active: 355392 kB
> Inactive: 49652 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 512548 kB
> LowFree: 10684 kB
> SwapTotal: 4883680 kB
> SwapFree: 4739048 kB
> Dirty: 132 kB
> Writeback: 0 kB
> Mapped: 347756 kB
> Slab: 49344 kB
> CommitLimit: 5139952 kB
> Committed_AS: 635544 kB
> PageTables: 2108 kB
> VmallocTotal: 515796 kB
> VmallocUsed: 25556 kB
> VmallocChunk: 486608 kB
>
> =====
>
> cat /proc/cpuinfo:
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 9
> cpu MHz : 2392.630
> cache size : 512 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
> bogomips : 4791.93
>
> processor : 1
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 9
> cpu MHz : 2392.630
> cache size : 512 KB
> physical id : 0
> siblings : 2
> core id : 0
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
> bogomips : 4784.99
>
> processor : 2
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 9
> cpu MHz : 2392.630
> cache size : 512 KB
> physical id : 3
> siblings : 2
> core id : 3
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
> bogomips : 4785.12
>
> processor : 3
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Xeon(TM) CPU 2.40GHz
> stepping : 9
> cpu MHz : 2392.630
> cache size : 512 KB
> physical id : 3
> siblings : 2
> core id : 3
> cpu cores : 1
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
> bogomips : 4785.12
>
> =====
>
> lspci -v:
> 0000:00:00.0 Host bridge: Intel Corporation E7505 Memory Controller Hub
> (rev 03)
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, fast devsel, latency 0
> Memory at e8000000 (32-bit, prefetchable) [size=128M]
> Capabilities: [40] #09 [0104]
> Capabilities: [a0] AGP version 3.0
>
> 0000:00:01.0 PCI bridge: Intel Corporation E7505/E7205 PCI-to-AGP Bridge
> (rev 03) (prog-if 00 [Normal decode])
> Flags: bus master, 66MHz, fast devsel, latency 64
> Memory at e0000000 (32-bit, prefetchable) [size=128M]
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
> Memory behind bridge: fc000000-fdffffff
> Prefetchable memory behind bridge: f0000000-f7ffffff
> Capabilities: [60] #0e [0035]
>
> 0000:00:02.0 PCI bridge: Intel Corporation E7505 Hub Interface B
> PCI-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
> Flags: bus master, 66MHz, fast devsel, latency 64
> Bus: primary=00, secondary=02, subordinate=04, sec-latency=0
> I/O behind bridge: 0000e000-0000efff
> Memory behind bridge: fe300000-fe6fffff
>
> 0000:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, medium devsel, latency 0, IRQ 21
> I/O ports at ff80 [size=32]
>
> 0000:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, medium devsel, latency 0, IRQ 22
> I/O ports at ff60 [size=32]
>
> 0000:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, medium devsel, latency 0, IRQ 18
> I/O ports at ff40 [size=32]
>
> 0000:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M)
> USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, medium devsel, latency 0, IRQ 20
> Memory at fe700800 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Capabilities: [58] #0a [2080]
>
> 0000:00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81)
> (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=05, subordinate=05, sec-latency=32
> I/O behind bridge: 0000d000-0000dfff
> Memory behind bridge: fe100000-fe2fffff
> Prefetchable memory behind bridge: f8000000-f80fffff
>
> 0000:00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC
> Interface Bridge (rev 01)
> Flags: bus master, medium devsel, latency 0
> 0000:00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE
> Controller (rev 01) (prog-if 8a [Master SecP PriP])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, medium devsel, latency 0, IRQ 18
> I/O ports at <unassigned>
> I/O ports at <unassigned>
> I/O ports at <unassigned>
> I/O ports at <unassigned>
> I/O ports at ffa0 [size=16]
> Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
>
> 0000:00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM
> (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
> Subsystem: Dell: Unknown device 012c
> Flags: medium devsel, IRQ 4
> I/O ports at cc80 [size=32]
>
> 0000:00:1f.5 Multimedia audio controller: Intel Corporation
> 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, medium devsel, latency 0, IRQ 23
> I/O ports at c800 [size=256]
> I/O ports at cc40 [size=64]
> Memory at fe700400 (32-bit, non-prefetchable) [size=512]
> Memory at fe700000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
>
> 0000:01:00.0 VGA compatible controller: nVidia Corporation NV34GL
> [Quadro FX 500/600 PCI] (rev a1) (prog-if 00 [VGA])
> Subsystem: nVidia Corporation: Unknown device 01ba
> Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 21
> Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
> Memory at f0000000 (32-bit, prefetchable) [size=128M]
> Expansion ROM at fd000000 [disabled] [size=128K]
> Capabilities: [60] Power Management version 2
> Capabilities: [44] AGP version 3.0
>
> 0000:02:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
> (prog-if 20 [IO(X)-APIC])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, 66MHz, fast devsel, latency 0
> Memory at fe3ff000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [50] PCI-X non-bridge device.
>
> 0000:02:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge
> (rev 04) (prog-if 00 [Normal decode])
> Flags: bus master, 66MHz, fast devsel, latency 64
> Bus: primary=02, secondary=03, subordinate=03, sec-latency=48
> I/O behind bridge: 0000e000-0000efff
> Memory behind bridge: fe500000-fe6fffff
> Capabilities: [50] PCI-X bridge device.
>
> 0000:02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
> (prog-if 20 [IO(X)-APIC])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, 66MHz, fast devsel, latency 0
> Memory at fe3fe000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [50] PCI-X non-bridge device.
>
> 0000:02:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge
> (rev 04) (prog-if 00 [Normal decode])
> Flags: bus master, 66MHz, fast devsel, latency 64
> Bus: primary=02, secondary=04, subordinate=04, sec-latency=64
> Capabilities: [50] PCI-X bridge device.
>
> 0000:03:0d.0 Mass storage controller: Promise Technology, Inc. 20269
> (rev 02) (prog-if 85)
> Subsystem: Promise Technology, Inc. Ultra133TX2
> Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 19
> I/O ports at ecf8 [size=8]
> I/O ports at ecf0 [size=4]
> I/O ports at ece0 [size=8]
> I/O ports at ecd8 [size=4]
> I/O ports at ecc0 [size=16]
> Memory at fe5fc000 (32-bit, non-prefetchable) [size=16K]
> Expansion ROM at fe600000 [disabled] [size=16K]
> Capabilities: [60] Power Management version 1
>
> 0000:03:0e.0 Ethernet controller: Intel Corporation 82545EM Gigabit
> Ethernet Controller (Copper) (rev 01)
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
> Memory at fe5c0000 (64-bit, non-prefetchable) [size=128K]
> I/O ports at ec80 [size=64]
> Capabilities: [dc] Power Management version 2
> Capabilities: [e4] PCI-X non-bridge device.
> Capabilities: [f0] Message Signalled Interrupts: 64bit+
> Queue=0/0 Enable-
>
> 0000:05:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A
> IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
> Subsystem: Dell: Unknown device 012c
> Flags: bus master, medium devsel, latency 64, IRQ 4
> Memory at fe1ff800 (32-bit, non-prefetchable) [size=2K]
> Memory at fe1f8000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [44] Power Management version 2
>
> 0000:05:0d.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
> (rev 07)
> Subsystem: Creative Labs SBLive! 5.1 Model SB0100
> Flags: bus master, medium devsel, latency 64, IRQ 24
> I/O ports at dce0 [size=32]
> Capabilities: [dc] Power Management version 1
>
> 0000:05:0d.1 Input device controller: Creative Labs SB Live! MIDI/Game
> Port (rev 07)
> Subsystem: Creative Labs Gameport Joystick
> Flags: bus master, medium devsel, latency 64
> I/O ports at dcd8 [size=8]
> Capabilities: [dc] Power Management version 1
>
> 0000:05:0e.0 Multimedia video controller: Brooktree Corporation Bt878
> Video Capture (rev 02)
> Subsystem: TERRATEC Electronic GmbH: Unknown device 1134
> Flags: bus master, medium devsel, latency 64, IRQ 17
> Memory at f80ff000 (32-bit, prefetchable) [size=4K]
>
> 0000:05:0e.1 Multimedia controller: Brooktree Corporation Bt878 Audio
> Capture (rev 02)
> Subsystem: TERRATEC Electronic GmbH: Unknown device 1134
> Flags: bus master, medium devsel, latency 64, IRQ 10
> Memory at f80fe000 (32-bit, prefetchable) [size=4K]
>
>
> ====
>
> ver_linux script output:
> If some fields are empty or look unusual you may have an old version.
> Compare to the current minimal requirements in Documentation/Changes.
>
> Linux sigma-9 2.6.14.5 #5 SMP Fri Dec 30 19:50:12 CET 2005 i686 GNU/Linux
>
> Gnu C 3.3.5
> Gnu make 3.80
> binutils 2.15
> util-linux 2.12p
> mount 2.12p
> module-init-tools 3.2-pre1
> e2fsprogs 1.37
> reiserfsprogs line
> reiser4progs line
> PPP 2.4.3
> nfs-utils 1.0.6
> Linux C Library 2.3.2
> Dynamic linker (ldd) 2.3.2
> Procps 3.2.1
> Net-tools 1.60
> Console-tools 0.2.3
> Sh-utils 5.2.1
> udev 056
> Modules Loaded nv
>
>
> ====
>
> results of memtest86+ after 40 passes with all tests enabled: no errors
>
> ====
>
> cat /proc/interrupts:
> CPU0 CPU1 CPU2 CPU3
> 0: 501324 492735 492754 492100 IO-APIC-edge timer
> 1: 2555 2761 2861 2451 IO-APIC-edge i8042
> 7: 0 0 0 0 IO-APIC-edge parport0
> 8: 2369118 2386295 2363140 2356586 IO-APIC-edge rtc
> 9: 0 0 0 0 IO-APIC-level acpi
> 14: 21 0 0 0 IO-APIC-edge ide0
> 15: 13 0 0 0 IO-APIC-edge ide1
> 16: 28924 0 0 0 IO-APIC-level eth0
> 17: 97407 105474 103650 103304 IO-APIC-level bttv0
> 18: 48 4 0 7 IO-APIC-level
> uhci_hcd:usb4
> 19: 28880 54020 48433 23791 IO-APIC-level ide2, ide3
> 20: 6 0 1 0 IO-APIC-level
> ehci_hcd:usb1
> 21: 398859 319390 317707 425780 IO-APIC-level
> uhci_hcd:usb2, nv
> 22: 200970 244113 220837 191613 IO-APIC-level
> uhci_hcd:usb3
> 23: 0 0 0 0 IO-APIC-level Intel
> 82801DB-ICH4
> 24: 9460 9468 12491 8706 IO-APIC-level EMU10K1
> NMI: 0 0 0 0
> LOC: 1978858 1979111 1979110 1979109
> ERR: 0
> MIS: 0
>
>
> ====
>
> 2.6.14.5 vanilla kernel .config file see attachment
>
> ====
>
> I hope this gives more complete picture of the current running setup.
>
>
Ok, got some more data now, i did recompile the kernel with alot of
debugging options turned on in kernel hacking section.
Maybe because of those debugging options the system won't freeze quickly
but rather display the errors and continue to run, because of
detect_soft_lockups and nmi watchdog i think.
Here is new data, this time it had to do with bttv:
Dec 31 16:11:35 localhost kernel: Unable to handle kernel paging request at
virtual address d162e000
Dec 31 16:11:35 localhost kernel: printing eip:
Dec 31 16:11:35 localhost kernel: c036037a
Dec 31 16:11:35 localhost kernel: *pgd = 46063
Dec 31 16:11:35 localhost kernel: *pmd = 46063
Dec 31 16:11:35 localhost kernel: *pte = 1162e000
Dec 31 16:11:35 localhost kernel: Oops: 0002 [#1]
Dec 31 16:11:35 localhost kernel: SMP DEBUG_PAGEALLOC
Dec 31 16:11:35 localhost kernel: Modules linked in: nv
Dec 31 16:11:35 localhost kernel: CPU: 2
Dec 31 16:11:35 localhost kernel: EIP: 0060:[bttv_risc_packed+394/432]
Not tainted VLI
Dec 31 16:11:35 localhost kernel: EFLAGS: 00210202 (2.6.14.5)
Dec 31 16:11:35 localhost kernel: eax: 14000008 ebx: d5ce9800 ecx:
d162e000 edx: 00000008
Dec 31 16:11:35 localhost kernel: esi: 00000008 edi: 000000ff ebp:
cd06dde8 esp: cd06ddd0
Dec 31 16:11:35 localhost kernel: ds: 007b es: 007b ss: 0068
Dec 31 16:11:35 localhost kernel: Process xawtv (pid: 31110,
threadinfo=cd06c000 task=ca871aa0)
Dec 31 16:11:35 localhost kernel: Stack: df80bbf8 c3b25fbc 00000fd0 00000c00
000d8000 c3b25ef8 cd06de40 c0361b0b
Dec 31 16:11:35 localhost kernel: c06ccba0 c3b25fbc d5ce8000 00000c00
00000c00 00000c00 00000120 000001b1
Dec 31 16:11:35 localhost kernel: 00000008 c3b25f1c c06cd168 00000000
cd06de40 c037022a df80bbf8 c3b25f1c
Dec 31 16:11:35 localhost kernel: Call Trace:
Dec 31 16:11:35 localhost kernel: [show_stack+127/160]
Dec 31 16:11:35 localhost kernel: [show_registers+347/448]
Dec 31 16:11:35 localhost kernel: [die+256/384]
Dec 31 16:11:35 localhost kernel: [do_page_fault+1084/2083]
Dec 31 16:11:35 localhost kernel: [error_code+79/96]
Dec 31 16:11:35 localhost kernel: [bttv_buffer_risc+1371/1696]
Dec 31 16:11:35 localhost kernel: [bttv_prepare_buffer+268/464]
Dec 31 16:11:35 localhost kernel: [buffer_prepare+69/80]
Dec 31 16:11:35 localhost kernel: [videobuf_read_zerocopy+108/304]
Dec 31 16:11:35 localhost kernel: [videobuf_read_one+522/560]
Dec 31 16:11:35 localhost kernel: [bttv_read+272/352]
Dec 31 16:11:35 localhost kernel: [vfs_read+213/432]
Dec 31 16:11:35 localhost kernel: [sys_read+75/128]
Dec 31 16:11:35 localhost kernel: [syscall_call+7/11]
Dec 31 16:11:35 localhost kernel: Code: 00 0d 00 00 00 10 89 01 8b 43 08 83
c1 04 89 01 8b 43 0c 83 c1 04 83 c3 10 29 c2 8b 43 0c 39 c2 77 df 89 d0 89
d6 0d 00 00 00 14 <89> 01 8b 43 08 83 c1 04 89 01 83 c1 04 eb 8a 8d b4 26 00
00 00
On Sat, 2005-12-31 at 16:18 +0100, Mark v Wolher wrote:
> Dec 31 16:11:35 localhost kernel: Modules linked in: nv
I think you forged this oops... there's no "nv" module for nvidia cards.
Arjan van de Ven wrote:
> On Sat, 2005-12-31 at 16:18 +0100, Mark v Wolher wrote:
>
>>Dec 31 16:11:35 localhost kernel: Modules linked in: nv
>
>
> I think you forged this oops... there's no "nv" module for nvidia cards.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
eh mate, i was copy/pasting the info and making notes, i didn't see i
wrote nv there. (I keep a detailed log of what i did, notes, drivers,
what disabled/never loaded etc)
Don't judge to quickly and have some trust in people mate.
So for your information, no nvidia binary module was loaded
(uninstalled it) and only the kernel part is used.
Mark v Wolher wrote:
> Mark v Wolher wrote:
>
>>Jesper Juhl wrote:
>>
>>
>>>On 12/31/05, Mark v Wolher <[email protected]> wrote:
>>>
>>>
>>>
>>>>Jesper Juhl wrote:
>>>>
>>>>
>>>>
>>>>>On 12/31/05, Mark v Wolher <[email protected]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>g'morning !
>>>>>>
>>>>>>the memtest86 went 40 times over the memory, no errors detected.
>>>>>>
>>>>>
>>>>>Give memtest86+ a spin (http://www.memtest.org/) as well. memtest86 is
>>>>>good, but I've found in the past that memtest86+ sometimes finds
>>>>>errors that memtest86 does not, so giving both a sin fo an extended
>>>>>period of time is usually a good idea.
>>>>>Also, make sure you enable all the tests of both tools.
>>>>
>>>>Hi Jesper,
>>>>
>>>>Oh i thought they were the same, i used memtest86+ which comes with
>>>>debian and not the "older" memtest86.
>>>>
>>>>Right now i booted the kernel with nomce since one never knows with dell
>>>
>>>
>>>Surpressing MCE's (Machine Check Exceptions) is a really bad idea
>>>usually. MCE's indicate a hardware problem, so unless it's known that
>>>a certain MCE is reported wrongly they should *not* be ignored.
>>
>>
>>Hi Jesper,
>>
>>Yes, i rather not disable it, but since i found some reports also
>>related to dell machines which somehow do not follow always the standard
>>this caused false exceptions on them. I'll re-enable it, and see if the
>>update of the intel microcode made a difference. I have now only the nv
>>module loaded. If a crash occurs i'll open the box and remove the tvcard.
>>
>>Also, i wonder, i downloaded the DSDT table from the bios and when i
>>recompiled it with IASL from intel it showed 7 errors, one of them
>>related to DMA. It is known that alot of companies like Dell use
>>microsoft compilers which easily skip such errors or not report them,
>>this is what i read.
>>
>>I'm pasting the DSDT errors occured during recompile, who knows, this
>>could also a help a little bit.
>>
>>DSDT Table / Recompile:
>>
>>Intel ACPI Component Architecture
>>ASL Optimizing Compiler version 20050930 [Dec 15 2005]
>>Copyright (C) 2000 - 2005 Intel Corporation
>>Supports ACPI Specification Revision 3.0
>>
>>dsdt.dsl 338: Notify (\_SB.PCI0.USB0, 0x02)
>>Error 1061 - Object does not exist ^ (\_SB.PCI0.USB0)
>>
>>dsdt.dsl 351: Notify (\_SB.PCI0.USB1, 0x02)
>>Error 1061 - Object does not exist ^ (\_SB.PCI0.USB1)
>>
>>dsdt.dsl 364: Notify (\_SB.PCI0.USB2, 0x02)
>>Error 1061 - Object does not exist ^ (\_SB.PCI0.USB2)
>>
>>dsdt.dsl 377: Notify (\_SB.PCI0, 0x02)
>>Error 1061 - Object does not exist ^ (\_SB.PCI0)
>>
>>dsdt.dsl 384: Notify (\_SB.PCI0.PCI4, 0x02)
>>Error 1061 - Object does not exist ^ (\_SB.PCI0.PCI4)
>>
>>dsdt.dsl 400: Notify (\_SB.PCI0.ISA.KBD, 0x02)
>>Error 1061 - Object does not exist ^ (\_SB.PCI0.ISA.KBD)
>>
>>dsdt.dsl 1784: Device (DMA)
>>Error 1094 - ^ syntax error, unexpected
>>PARSEOP_DMA, expecting PARSEOP_NAMESEG or PARSEOP_NAMESTRING
>>
>>ASL Input: dsdt.dsl - 3096 lines, 93624 bytes, 515 keywords
>>Compilation complete. 7 Errors, 0 Warnings, 0 Remarks, 53 Optimizations
>>
>>
>>====
>>
>>LSUSB:
>>Bus 004 Device 002: ID 0d8c:0001 C-Media Electronics, Inc.
>>Bus 004 Device 001: ID 0000:0000
>>Bus 003 Device 003: ID 051d:0002 American Power Conversion Back-UPS Pro
>>500/1000/1500
>>Bus 003 Device 002: ID 046d:c00e Logitech, Inc. Optical Mouse
>>Bus 003 Device 001: ID 0000:0000
>>Bus 002 Device 001: ID 0000:0000
>>Bus 001 Device 001: ID 0000:0000
>>
>>
>>=====
>>
>>cat /proc/meminfo:
>>
>>MemTotal: 512548 kB
>>MemFree: 10684 kB
>>Buffers: 17252 kB
>>Cached: 221508 kB
>>SwapCached: 10120 kB
>>Active: 355392 kB
>>Inactive: 49652 kB
>>HighTotal: 0 kB
>>HighFree: 0 kB
>>LowTotal: 512548 kB
>>LowFree: 10684 kB
>>SwapTotal: 4883680 kB
>>SwapFree: 4739048 kB
>>Dirty: 132 kB
>>Writeback: 0 kB
>>Mapped: 347756 kB
>>Slab: 49344 kB
>>CommitLimit: 5139952 kB
>>Committed_AS: 635544 kB
>>PageTables: 2108 kB
>>VmallocTotal: 515796 kB
>>VmallocUsed: 25556 kB
>>VmallocChunk: 486608 kB
>>
>>=====
>>
>>cat /proc/cpuinfo:
>>
>>processor : 0
>>vendor_id : GenuineIntel
>>cpu family : 15
>>model : 2
>>model name : Intel(R) Xeon(TM) CPU 2.40GHz
>>stepping : 9
>>cpu MHz : 2392.630
>>cache size : 512 KB
>>physical id : 0
>>siblings : 2
>>core id : 0
>>cpu cores : 1
>>fdiv_bug : no
>>hlt_bug : no
>>f00f_bug : no
>>coma_bug : no
>>fpu : yes
>>fpu_exception : yes
>>cpuid level : 2
>>wp : yes
>>flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
>>cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
>>bogomips : 4791.93
>>
>>processor : 1
>>vendor_id : GenuineIntel
>>cpu family : 15
>>model : 2
>>model name : Intel(R) Xeon(TM) CPU 2.40GHz
>>stepping : 9
>>cpu MHz : 2392.630
>>cache size : 512 KB
>>physical id : 0
>>siblings : 2
>>core id : 0
>>cpu cores : 1
>>fdiv_bug : no
>>hlt_bug : no
>>f00f_bug : no
>>coma_bug : no
>>fpu : yes
>>fpu_exception : yes
>>cpuid level : 2
>>wp : yes
>>flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
>>cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
>>bogomips : 4784.99
>>
>>processor : 2
>>vendor_id : GenuineIntel
>>cpu family : 15
>>model : 2
>>model name : Intel(R) Xeon(TM) CPU 2.40GHz
>>stepping : 9
>>cpu MHz : 2392.630
>>cache size : 512 KB
>>physical id : 3
>>siblings : 2
>>core id : 3
>>cpu cores : 1
>>fdiv_bug : no
>>hlt_bug : no
>>f00f_bug : no
>>coma_bug : no
>>fpu : yes
>>fpu_exception : yes
>>cpuid level : 2
>>wp : yes
>>flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
>>cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
>>bogomips : 4785.12
>>
>>processor : 3
>>vendor_id : GenuineIntel
>>cpu family : 15
>>model : 2
>>model name : Intel(R) Xeon(TM) CPU 2.40GHz
>>stepping : 9
>>cpu MHz : 2392.630
>>cache size : 512 KB
>>physical id : 3
>>siblings : 2
>>core id : 3
>>cpu cores : 1
>>fdiv_bug : no
>>hlt_bug : no
>>f00f_bug : no
>>coma_bug : no
>>fpu : yes
>>fpu_exception : yes
>>cpuid level : 2
>>wp : yes
>>flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
>>cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
>>bogomips : 4785.12
>>
>>=====
>>
>>lspci -v:
>>0000:00:00.0 Host bridge: Intel Corporation E7505 Memory Controller Hub
>>(rev 03)
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, fast devsel, latency 0
>> Memory at e8000000 (32-bit, prefetchable) [size=128M]
>> Capabilities: [40] #09 [0104]
>> Capabilities: [a0] AGP version 3.0
>>
>>0000:00:01.0 PCI bridge: Intel Corporation E7505/E7205 PCI-to-AGP Bridge
>>(rev 03) (prog-if 00 [Normal decode])
>> Flags: bus master, 66MHz, fast devsel, latency 64
>> Memory at e0000000 (32-bit, prefetchable) [size=128M]
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
>> Memory behind bridge: fc000000-fdffffff
>> Prefetchable memory behind bridge: f0000000-f7ffffff
>> Capabilities: [60] #0e [0035]
>>
>>0000:00:02.0 PCI bridge: Intel Corporation E7505 Hub Interface B
>>PCI-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
>> Flags: bus master, 66MHz, fast devsel, latency 64
>> Bus: primary=00, secondary=02, subordinate=04, sec-latency=0
>> I/O behind bridge: 0000e000-0000efff
>> Memory behind bridge: fe300000-fe6fffff
>>
>>0000:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
>>(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, medium devsel, latency 0, IRQ 21
>> I/O ports at ff80 [size=32]
>>
>>0000:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
>>(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, medium devsel, latency 0, IRQ 22
>> I/O ports at ff60 [size=32]
>>
>>0000:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM
>>(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, medium devsel, latency 0, IRQ 18
>> I/O ports at ff40 [size=32]
>>
>>0000:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M)
>>USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, medium devsel, latency 0, IRQ 20
>> Memory at fe700800 (32-bit, non-prefetchable) [size=1K]
>> Capabilities: [50] Power Management version 2
>> Capabilities: [58] #0a [2080]
>>
>>0000:00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81)
>>(prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Bus: primary=00, secondary=05, subordinate=05, sec-latency=32
>> I/O behind bridge: 0000d000-0000dfff
>> Memory behind bridge: fe100000-fe2fffff
>> Prefetchable memory behind bridge: f8000000-f80fffff
>>
>>0000:00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC
>>Interface Bridge (rev 01)
>> Flags: bus master, medium devsel, latency 0
>>0000:00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE
>>Controller (rev 01) (prog-if 8a [Master SecP PriP])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, medium devsel, latency 0, IRQ 18
>> I/O ports at <unassigned>
>> I/O ports at <unassigned>
>> I/O ports at <unassigned>
>> I/O ports at <unassigned>
>> I/O ports at ffa0 [size=16]
>> Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
>>
>>0000:00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM
>>(ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
>> Subsystem: Dell: Unknown device 012c
>> Flags: medium devsel, IRQ 4
>> I/O ports at cc80 [size=32]
>>
>>0000:00:1f.5 Multimedia audio controller: Intel Corporation
>>82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, medium devsel, latency 0, IRQ 23
>> I/O ports at c800 [size=256]
>> I/O ports at cc40 [size=64]
>> Memory at fe700400 (32-bit, non-prefetchable) [size=512]
>> Memory at fe700000 (32-bit, non-prefetchable) [size=256]
>> Capabilities: [50] Power Management version 2
>>
>>0000:01:00.0 VGA compatible controller: nVidia Corporation NV34GL
>>[Quadro FX 500/600 PCI] (rev a1) (prog-if 00 [VGA])
>> Subsystem: nVidia Corporation: Unknown device 01ba
>> Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 21
>> Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
>> Memory at f0000000 (32-bit, prefetchable) [size=128M]
>> Expansion ROM at fd000000 [disabled] [size=128K]
>> Capabilities: [60] Power Management version 2
>> Capabilities: [44] AGP version 3.0
>>
>>0000:02:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
>>(prog-if 20 [IO(X)-APIC])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, 66MHz, fast devsel, latency 0
>> Memory at fe3ff000 (32-bit, non-prefetchable) [size=4K]
>> Capabilities: [50] PCI-X non-bridge device.
>>
>>0000:02:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge
>>(rev 04) (prog-if 00 [Normal decode])
>> Flags: bus master, 66MHz, fast devsel, latency 64
>> Bus: primary=02, secondary=03, subordinate=03, sec-latency=48
>> I/O behind bridge: 0000e000-0000efff
>> Memory behind bridge: fe500000-fe6fffff
>> Capabilities: [50] PCI-X bridge device.
>>
>>0000:02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
>>(prog-if 20 [IO(X)-APIC])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, 66MHz, fast devsel, latency 0
>> Memory at fe3fe000 (32-bit, non-prefetchable) [size=4K]
>> Capabilities: [50] PCI-X non-bridge device.
>>
>>0000:02:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge
>>(rev 04) (prog-if 00 [Normal decode])
>> Flags: bus master, 66MHz, fast devsel, latency 64
>> Bus: primary=02, secondary=04, subordinate=04, sec-latency=64
>> Capabilities: [50] PCI-X bridge device.
>>
>>0000:03:0d.0 Mass storage controller: Promise Technology, Inc. 20269
>>(rev 02) (prog-if 85)
>> Subsystem: Promise Technology, Inc. Ultra133TX2
>> Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 19
>> I/O ports at ecf8 [size=8]
>> I/O ports at ecf0 [size=4]
>> I/O ports at ece0 [size=8]
>> I/O ports at ecd8 [size=4]
>> I/O ports at ecc0 [size=16]
>> Memory at fe5fc000 (32-bit, non-prefetchable) [size=16K]
>> Expansion ROM at fe600000 [disabled] [size=16K]
>> Capabilities: [60] Power Management version 1
>>
>>0000:03:0e.0 Ethernet controller: Intel Corporation 82545EM Gigabit
>>Ethernet Controller (Copper) (rev 01)
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
>> Memory at fe5c0000 (64-bit, non-prefetchable) [size=128K]
>> I/O ports at ec80 [size=64]
>> Capabilities: [dc] Power Management version 2
>> Capabilities: [e4] PCI-X non-bridge device.
>> Capabilities: [f0] Message Signalled Interrupts: 64bit+
>>Queue=0/0 Enable-
>>
>>0000:05:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A
>>IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
>> Subsystem: Dell: Unknown device 012c
>> Flags: bus master, medium devsel, latency 64, IRQ 4
>> Memory at fe1ff800 (32-bit, non-prefetchable) [size=2K]
>> Memory at fe1f8000 (32-bit, non-prefetchable) [size=16K]
>> Capabilities: [44] Power Management version 2
>>
>>0000:05:0d.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
>>(rev 07)
>> Subsystem: Creative Labs SBLive! 5.1 Model SB0100
>> Flags: bus master, medium devsel, latency 64, IRQ 24
>> I/O ports at dce0 [size=32]
>> Capabilities: [dc] Power Management version 1
>>
>>0000:05:0d.1 Input device controller: Creative Labs SB Live! MIDI/Game
>>Port (rev 07)
>> Subsystem: Creative Labs Gameport Joystick
>> Flags: bus master, medium devsel, latency 64
>> I/O ports at dcd8 [size=8]
>> Capabilities: [dc] Power Management version 1
>>
>>0000:05:0e.0 Multimedia video controller: Brooktree Corporation Bt878
>>Video Capture (rev 02)
>> Subsystem: TERRATEC Electronic GmbH: Unknown device 1134
>> Flags: bus master, medium devsel, latency 64, IRQ 17
>> Memory at f80ff000 (32-bit, prefetchable) [size=4K]
>>
>>0000:05:0e.1 Multimedia controller: Brooktree Corporation Bt878 Audio
>>Capture (rev 02)
>> Subsystem: TERRATEC Electronic GmbH: Unknown device 1134
>> Flags: bus master, medium devsel, latency 64, IRQ 10
>> Memory at f80fe000 (32-bit, prefetchable) [size=4K]
>>
>>
>>====
>>
>>ver_linux script output:
>>If some fields are empty or look unusual you may have an old version.
>>Compare to the current minimal requirements in Documentation/Changes.
>>
>>Linux sigma-9 2.6.14.5 #5 SMP Fri Dec 30 19:50:12 CET 2005 i686 GNU/Linux
>>
>>Gnu C 3.3.5
>>Gnu make 3.80
>>binutils 2.15
>>util-linux 2.12p
>>mount 2.12p
>>module-init-tools 3.2-pre1
>>e2fsprogs 1.37
>>reiserfsprogs line
>>reiser4progs line
>>PPP 2.4.3
>>nfs-utils 1.0.6
>>Linux C Library 2.3.2
>>Dynamic linker (ldd) 2.3.2
>>Procps 3.2.1
>>Net-tools 1.60
>>Console-tools 0.2.3
>>Sh-utils 5.2.1
>>udev 056
>>Modules Loaded nv
>>
>>
>>====
>>
>>results of memtest86+ after 40 passes with all tests enabled: no errors
>>
>>====
>>
>>cat /proc/interrupts:
>> CPU0 CPU1 CPU2 CPU3
>> 0: 501324 492735 492754 492100 IO-APIC-edge timer
>> 1: 2555 2761 2861 2451 IO-APIC-edge i8042
>> 7: 0 0 0 0 IO-APIC-edge parport0
>> 8: 2369118 2386295 2363140 2356586 IO-APIC-edge rtc
>> 9: 0 0 0 0 IO-APIC-level acpi
>> 14: 21 0 0 0 IO-APIC-edge ide0
>> 15: 13 0 0 0 IO-APIC-edge ide1
>> 16: 28924 0 0 0 IO-APIC-level eth0
>> 17: 97407 105474 103650 103304 IO-APIC-level bttv0
>> 18: 48 4 0 7 IO-APIC-level
>>uhci_hcd:usb4
>> 19: 28880 54020 48433 23791 IO-APIC-level ide2, ide3
>> 20: 6 0 1 0 IO-APIC-level
>>ehci_hcd:usb1
>> 21: 398859 319390 317707 425780 IO-APIC-level
>>uhci_hcd:usb2, nv
>> 22: 200970 244113 220837 191613 IO-APIC-level
>>uhci_hcd:usb3
>> 23: 0 0 0 0 IO-APIC-level Intel
>>82801DB-ICH4
>> 24: 9460 9468 12491 8706 IO-APIC-level EMU10K1
>>NMI: 0 0 0 0
>>LOC: 1978858 1979111 1979110 1979109
>>ERR: 0
>>MIS: 0
>>
>>
>>====
>>
>>2.6.14.5 vanilla kernel .config file see attachment
>>
>>====
>>
>>I hope this gives more complete picture of the current running setup.
>>
>>
>
>
> Ok, got some more data now, i did recompile the kernel with alot of
> debugging options turned on in kernel hacking section.
>
> Maybe because of those debugging options the system won't freeze quickly
> but rather display the errors and continue to run, because of
> detect_soft_lockups and nmi watchdog i think.
>
> Here is new data, this time it had to do with bttv:
>
> Dec 31 16:11:35 localhost kernel: Unable to handle kernel paging request at
> virtual address d162e000
> Dec 31 16:11:35 localhost kernel: printing eip:
> Dec 31 16:11:35 localhost kernel: c036037a
> Dec 31 16:11:35 localhost kernel: *pgd = 46063
> Dec 31 16:11:35 localhost kernel: *pmd = 46063
> Dec 31 16:11:35 localhost kernel: *pte = 1162e000
> Dec 31 16:11:35 localhost kernel: Oops: 0002 [#1]
> Dec 31 16:11:35 localhost kernel: SMP DEBUG_PAGEALLOC
> Dec 31 16:11:35 localhost kernel: Modules linked in: nv
> Dec 31 16:11:35 localhost kernel: CPU: 2
> Dec 31 16:11:35 localhost kernel: EIP: 0060:[bttv_risc_packed+394/432]
> Not tainted VLI
> Dec 31 16:11:35 localhost kernel: EFLAGS: 00210202 (2.6.14.5)
> Dec 31 16:11:35 localhost kernel: eax: 14000008 ebx: d5ce9800 ecx:
> d162e000 edx: 00000008
> Dec 31 16:11:35 localhost kernel: esi: 00000008 edi: 000000ff ebp:
> cd06dde8 esp: cd06ddd0
> Dec 31 16:11:35 localhost kernel: ds: 007b es: 007b ss: 0068
> Dec 31 16:11:35 localhost kernel: Process xawtv (pid: 31110,
> threadinfo=cd06c000 task=ca871aa0)
> Dec 31 16:11:35 localhost kernel: Stack: df80bbf8 c3b25fbc 00000fd0 00000c00
> 000d8000 c3b25ef8 cd06de40 c0361b0b
> Dec 31 16:11:35 localhost kernel: c06ccba0 c3b25fbc d5ce8000 00000c00
> 00000c00 00000c00 00000120 000001b1
> Dec 31 16:11:35 localhost kernel: 00000008 c3b25f1c c06cd168 00000000
> cd06de40 c037022a df80bbf8 c3b25f1c
> Dec 31 16:11:35 localhost kernel: Call Trace:
> Dec 31 16:11:35 localhost kernel: [show_stack+127/160]
> Dec 31 16:11:35 localhost kernel: [show_registers+347/448]
> Dec 31 16:11:35 localhost kernel: [die+256/384]
> Dec 31 16:11:35 localhost kernel: [do_page_fault+1084/2083]
> Dec 31 16:11:35 localhost kernel: [error_code+79/96]
> Dec 31 16:11:35 localhost kernel: [bttv_buffer_risc+1371/1696]
> Dec 31 16:11:35 localhost kernel: [bttv_prepare_buffer+268/464]
> Dec 31 16:11:35 localhost kernel: [buffer_prepare+69/80]
> Dec 31 16:11:35 localhost kernel: [videobuf_read_zerocopy+108/304]
> Dec 31 16:11:35 localhost kernel: [videobuf_read_one+522/560]
> Dec 31 16:11:35 localhost kernel: [bttv_read+272/352]
> Dec 31 16:11:35 localhost kernel: [vfs_read+213/432]
> Dec 31 16:11:35 localhost kernel: [sys_read+75/128]
> Dec 31 16:11:35 localhost kernel: [syscall_call+7/11]
> Dec 31 16:11:35 localhost kernel: Code: 00 0d 00 00 00 10 89 01 8b 43 08 83
> c1 04 89 01 8b 43 0c 83 c1 04 83 c3 10 29 c2 8b 43 0c 39 c2 77 df 89 d0 89
> d6 0d 00 00 00 14 <89> 01 8b 43 08 83 c1 04 89 01 83 c1 04 eb 8a 8d b4 26 00
> 00 00
>
>
>
>
(please don't see nv as any module, a copy/paste accident of mine while
commenting my log)
I just had xchat crash, nothing in the log, it just disappeared.
The system is now very slow but i guess that's because of the debugging
options enabled.
On Sat, Dec 31, 2005 at 04:18:38PM +0100, Mark v Wolher wrote:
...
> Here is new data, this time it had to do with bttv:
>
> Dec 31 16:11:35 localhost kernel: Unable to handle kernel paging request at
> virtual address d162e000
> Dec 31 16:11:35 localhost kernel: printing eip:
> Dec 31 16:11:35 localhost kernel: c036037a
> Dec 31 16:11:35 localhost kernel: *pgd = 46063
> Dec 31 16:11:35 localhost kernel: *pmd = 46063
> Dec 31 16:11:35 localhost kernel: *pte = 1162e000
> Dec 31 16:11:35 localhost kernel: Oops: 0002 [#1]
> Dec 31 16:11:35 localhost kernel: SMP DEBUG_PAGEALLOC
> Dec 31 16:11:35 localhost kernel: Modules linked in: nv
> Dec 31 16:11:35 localhost kernel: CPU: 2
> Dec 31 16:11:35 localhost kernel: EIP: 0060:[bttv_risc_packed+394/432]
Can you try how many seconds it takes to get Oops/crash when you start
pressing 'v' in xawtv (video capture on/off).
For me, not very many.
This happens with every 2.6 kernel. And my hardware is OK.
> Not tainted VLI
> Dec 31 16:11:35 localhost kernel: EFLAGS: 00210202 (2.6.14.5)
> Dec 31 16:11:35 localhost kernel: eax: 14000008 ebx: d5ce9800 ecx:
> d162e000 edx: 00000008
> Dec 31 16:11:35 localhost kernel: esi: 00000008 edi: 000000ff ebp:
> cd06dde8 esp: cd06ddd0
> Dec 31 16:11:35 localhost kernel: ds: 007b es: 007b ss: 0068
> Dec 31 16:11:35 localhost kernel: Process xawtv (pid: 31110,
> threadinfo=cd06c000 task=ca871aa0)
> Dec 31 16:11:35 localhost kernel: Stack: df80bbf8 c3b25fbc 00000fd0 00000c00
> 000d8000 c3b25ef8 cd06de40 c0361b0b
> Dec 31 16:11:35 localhost kernel: c06ccba0 c3b25fbc d5ce8000 00000c00
> 00000c00 00000c00 00000120 000001b1
> Dec 31 16:11:35 localhost kernel: 00000008 c3b25f1c c06cd168 00000000
> cd06de40 c037022a df80bbf8 c3b25f1c
> Dec 31 16:11:35 localhost kernel: Call Trace:
> Dec 31 16:11:35 localhost kernel: [show_stack+127/160]
> Dec 31 16:11:35 localhost kernel: [show_registers+347/448]
> Dec 31 16:11:35 localhost kernel: [die+256/384]
> Dec 31 16:11:35 localhost kernel: [do_page_fault+1084/2083]
> Dec 31 16:11:35 localhost kernel: [error_code+79/96]
> Dec 31 16:11:35 localhost kernel: [bttv_buffer_risc+1371/1696]
> Dec 31 16:11:35 localhost kernel: [bttv_prepare_buffer+268/464]
> Dec 31 16:11:35 localhost kernel: [buffer_prepare+69/80]
> Dec 31 16:11:35 localhost kernel: [videobuf_read_zerocopy+108/304]
> Dec 31 16:11:35 localhost kernel: [videobuf_read_one+522/560]
> Dec 31 16:11:35 localhost kernel: [bttv_read+272/352]
> Dec 31 16:11:35 localhost kernel: [vfs_read+213/432]
> Dec 31 16:11:35 localhost kernel: [sys_read+75/128]
> Dec 31 16:11:35 localhost kernel: [syscall_call+7/11]
> Dec 31 16:11:35 localhost kernel: Code: 00 0d 00 00 00 10 89 01 8b 43 08 83
> c1 04 89 01 8b 43 0c 83 c1 04 83 c3 10 29 c2 8b 43 0c 39 c2 77 df 89 d0 89
> d6 0d 00 00 00 14 <89> 01 8b 43 08 83 c1 04 89 01 83 c1 04 eb 8a 8d b4 26 00
> 00 00
--
Sami Farin wrote:
> On Sat, Dec 31, 2005 at 04:18:38PM +0100, Mark v Wolher wrote:
> ...
>
>>Here is new data, this time it had to do with bttv:
>>
>>Dec 31 16:11:35 localhost kernel: Unable to handle kernel paging request at
>>virtual address d162e000
>>Dec 31 16:11:35 localhost kernel: printing eip:
>>Dec 31 16:11:35 localhost kernel: c036037a
>>Dec 31 16:11:35 localhost kernel: *pgd = 46063
>>Dec 31 16:11:35 localhost kernel: *pmd = 46063
>>Dec 31 16:11:35 localhost kernel: *pte = 1162e000
>>Dec 31 16:11:35 localhost kernel: Oops: 0002 [#1]
>>Dec 31 16:11:35 localhost kernel: SMP DEBUG_PAGEALLOC
>>Dec 31 16:11:35 localhost kernel: Modules linked in: nv
>>Dec 31 16:11:35 localhost kernel: CPU: 2
>>Dec 31 16:11:35 localhost kernel: EIP: 0060:[bttv_risc_packed+394/432]
>
>
> Can you try how many seconds it takes to get Oops/crash when you start
> pressing 'v' in xawtv (video capture on/off).
> For me, not very many.
>
> This happens with every 2.6 kernel. And my hardware is OK.
>
>
>>Not tainted VLI
>>Dec 31 16:11:35 localhost kernel: EFLAGS: 00210202 (2.6.14.5)
>>Dec 31 16:11:35 localhost kernel: eax: 14000008 ebx: d5ce9800 ecx:
>>d162e000 edx: 00000008
>>Dec 31 16:11:35 localhost kernel: esi: 00000008 edi: 000000ff ebp:
>>cd06dde8 esp: cd06ddd0
>>Dec 31 16:11:35 localhost kernel: ds: 007b es: 007b ss: 0068
>>Dec 31 16:11:35 localhost kernel: Process xawtv (pid: 31110,
>>threadinfo=cd06c000 task=ca871aa0)
>>Dec 31 16:11:35 localhost kernel: Stack: df80bbf8 c3b25fbc 00000fd0 00000c00
>>000d8000 c3b25ef8 cd06de40 c0361b0b
>>Dec 31 16:11:35 localhost kernel: c06ccba0 c3b25fbc d5ce8000 00000c00
>>00000c00 00000c00 00000120 000001b1
>>Dec 31 16:11:35 localhost kernel: 00000008 c3b25f1c c06cd168 00000000
>>cd06de40 c037022a df80bbf8 c3b25f1c
>>Dec 31 16:11:35 localhost kernel: Call Trace:
>>Dec 31 16:11:35 localhost kernel: [show_stack+127/160]
>>Dec 31 16:11:35 localhost kernel: [show_registers+347/448]
>>Dec 31 16:11:35 localhost kernel: [die+256/384]
>>Dec 31 16:11:35 localhost kernel: [do_page_fault+1084/2083]
>>Dec 31 16:11:35 localhost kernel: [error_code+79/96]
>>Dec 31 16:11:35 localhost kernel: [bttv_buffer_risc+1371/1696]
>>Dec 31 16:11:35 localhost kernel: [bttv_prepare_buffer+268/464]
>>Dec 31 16:11:35 localhost kernel: [buffer_prepare+69/80]
>>Dec 31 16:11:35 localhost kernel: [videobuf_read_zerocopy+108/304]
>>Dec 31 16:11:35 localhost kernel: [videobuf_read_one+522/560]
>>Dec 31 16:11:35 localhost kernel: [bttv_read+272/352]
>>Dec 31 16:11:35 localhost kernel: [vfs_read+213/432]
>>Dec 31 16:11:35 localhost kernel: [sys_read+75/128]
>>Dec 31 16:11:35 localhost kernel: [syscall_call+7/11]
>>Dec 31 16:11:35 localhost kernel: Code: 00 0d 00 00 00 10 89 01 8b 43 08 83
>>c1 04 89 01 8b 43 0c 83 c1 04 83 c3 10 29 c2 8b 43 0c 39 c2 77 df 89 d0 89
>>d6 0d 00 00 00 14 <89> 01 8b 43 08 83 c1 04 89 01 83 c1 04 eb 8a 8d b4 26 00
>>00 00
>
>
Hi Sami,
That caused also a crash, i kept pressing the v key and within 15
seconds it crashed, then i saw the crash-info appear in the log and when
i clicked on mozilla then it crashed too but without crahs info and
system froze totally.
Below the crash info:
Dec 31 17:38:32 localhost kernel: Unable to handle kernel paging request
at virtual address c8111000
Dec 31 17:38:32 localhost kernel: printing eip:
Dec 31 17:38:32 localhost kernel: c036037a
Dec 31 17:38:32 localhost kernel: *pgd = 21063
Dec 31 17:38:32 localhost kernel: *pmd = 21063
Dec 31 17:38:32 localhost kernel: *pte = 8111000
Dec 31 17:38:32 localhost kernel: Oops: 0002 [#4]
Dec 31 17:38:32 localhost kernel: SMP DEBUG_PAGEALLOC
Dec 31 17:38:32 localhost kernel: Modules linked in:
Dec 31 17:38:32 localhost kernel: CPU: 3
Dec 31 17:38:32 localhost kernel: EIP:
0060:[bttv_risc_packed+394/432] Not tainted VLI
Dec 31 17:38:32 localhost kernel: EFLAGS: 00210202 (2.6.14.5)
Dec 31 17:38:32 localhost kernel: eax: 14000008 ebx: d3a09800 ecx:
c8111000 edx: 00000008
Dec 31 17:38:32 localhost kernel: esi: 00000008 edi: 000000ff ebp:
d3c0be38 esp: d3c0be20
Dec 31 17:38:32 localhost kernel: ds: 007b es: 007b ss: 0068
Dec 31 17:38:32 localhost kernel: Process xawtv (pid: 1703,
threadinfo=d3c0a000 task=cfba2aa0)
Dec 31 17:38:32 localhost kernel: Stack: df80bbf8 c6a5cfbc 00000fd0
00000c00 000d8000 c6a5cef8 d3c0be90 c0361b0b
Dec 31 17:38:32 localhost kernel: c06ccba0 c6a5cfbc d3a08000
00000c00 00000c00 00000c00 00000120 000001b1
Dec 31 17:38:32 localhost kernel: 00000008 c6a5cf1c c06cd168
00000000 d3c0be90 c037022a df80bbf8 c6a5cf1c
Dec 31 17:38:32 localhost kernel: Call Trace:
Dec 31 17:38:32 localhost kernel: [show_stack+127/160]
Dec 31 17:38:32 localhost kernel: [show_registers+347/448]
Dec 31 17:38:32 localhost kernel: [die+256/384]
Dec 31 17:38:32 localhost kernel: [do_page_fault+1084/2083]
Dec 31 17:38:32 localhost kernel: [error_code+79/96]
Dec 31 17:38:32 localhost kernel: [bttv_buffer_risc+1371/1696]
Dec 31 17:38:32 localhost kernel: [bttv_prepare_buffer+268/464]
Dec 31 17:38:32 localhost kernel: [buffer_prepare+69/80]
Dec 31 17:38:32 localhost kernel: [videobuf_read_zerocopy+108/304]
Dec 31 17:38:32 localhost kernel: [videobuf_read_one+522/560]
Dec 31 17:38:32 localhost kernel: [bttv_read+272/352]
Dec 31 17:38:32 localhost kernel: [vfs_read+213/432]
Dec 31 17:38:32 localhost kernel: [sys_read+75/128]
Dec 31 17:38:32 localhost kernel: [syscall_call+7/11]
Dec 31 17:38:32 localhost kernel: Code: 00 0d 00 00 00 10 89 01 8b 43 08
83 c1 04 89 01 8b 43 0c 83 c1 04 83 c3 10 29 c2 8b 43 0c 39 c2 77 df 89
d0 89 d
On Sat, Dec 31, 2005 at 05:48:41PM +0100, Mark v Wolher wrote:
> Sami Farin wrote:
...
> > Can you try how many seconds it takes to get Oops/crash when you start
> > pressing 'v' in xawtv (video capture on/off).
> > For me, not very many.
> >
> > This happens with every 2.6 kernel. And my hardware is OK.
...
> Hi Sami,
>
> That caused also a crash, i kept pressing the v key and within 15
> seconds it crashed, then i saw the crash-info appear in the log and when
> i clicked on mozilla then it crashed too but without crahs info and
> system froze totally.
Now if someone could figure out how to find the bug in bttv.
My opinion/guess is that's where the bug is, not in buggy PCI hardware,
as somebody said several months ago.
--
Sami Farin wrote:
> On Sat, Dec 31, 2005 at 05:48:41PM +0100, Mark v Wolher wrote:
>
>>Sami Farin wrote:
>
> ...
>
>>>Can you try how many seconds it takes to get Oops/crash when you start
>>>pressing 'v' in xawtv (video capture on/off).
>>>For me, not very many.
>>>
>>>This happens with every 2.6 kernel. And my hardware is OK.
>
> ...
>
>>Hi Sami,
>>
>>That caused also a crash, i kept pressing the v key and within 15
>>seconds it crashed, then i saw the crash-info appear in the log and when
>>i clicked on mozilla then it crashed too but without crahs info and
>>system froze totally.
>
>
> Now if someone could figure out how to find the bug in bttv.
> My opinion/guess is that's where the bug is, not in buggy PCI hardware,
> as somebody said several months ago.
>
I agree, i filled a report also on bugzilla. Also i have to mention that
when using xp pro no crashes/freezes occur, not even under heavy load
and tv on.
On Sat, Dec 31, 2005 at 07:43:43PM +0100, Jiri Slaby wrote:
> >Hi Sami,
> >
> >That caused also a crash, i kept pressing the v key and within 15
> >seconds it crashed, then i saw the crash-info appear in the log and when
> >i clicked on mozilla then it crashed too but without crahs info and
> >system froze totally.
> >
> >Below the crash info:
> >
> >Dec 31 17:38:32 localhost kernel: Unable to handle kernel paging request
> >at virtual address c8111000
> >Dec 31 17:38:32 localhost kernel: printing eip:
> >Dec 31 17:38:32 localhost kernel: c036037a
> >Dec 31 17:38:32 localhost kernel: *pgd = 21063
> >Dec 31 17:38:32 localhost kernel: *pmd = 21063
> >Dec 31 17:38:32 localhost kernel: *pte = 8111000
> >Dec 31 17:38:32 localhost kernel: Oops: 0002 [#4]
> [snip]
> Could you try the attached patch?
>
> --
> diff --git a/drivers/media/video/bttv-risc.c b/drivers/media/video/bttv-risc.c
> --- a/drivers/media/video/bttv-risc.c
> +++ b/drivers/media/video/bttv-risc.c
> @@ -53,7 +53,7 @@ bttv_risc_packed(struct bttv *btv, struc
> /* estimate risc mem: worst case is one write per page border +
> one write per scan line + sync + jump (all 2 dwords) */
> instructions = (bpl * lines) / PAGE_SIZE + lines;
> - instructions += 2;
> + instructions += 4;
> if ((rc = btcx_riscmem_alloc(btv->c.pci,risc,instructions*8)) < 0)
> return rc;
This patch has the effect that xawtv crashed system two times faster
than earlier... now we're at two seconds.
--
Jiri Slaby wrote:
>>Hi Sami,
>>
>>That caused also a crash, i kept pressing the v key and within 15
>>seconds it crashed, then i saw the crash-info appear in the log and when
>>i clicked on mozilla then it crashed too but without crahs info and
>>system froze totally.
>>
>>Below the crash info:
>>
>>Dec 31 17:38:32 localhost kernel: Unable to handle kernel paging request
>>at virtual address c8111000
>>Dec 31 17:38:32 localhost kernel: printing eip:
>>Dec 31 17:38:32 localhost kernel: c036037a
>>Dec 31 17:38:32 localhost kernel: *pgd = 21063
>>Dec 31 17:38:32 localhost kernel: *pmd = 21063
>>Dec 31 17:38:32 localhost kernel: *pte = 8111000
>>Dec 31 17:38:32 localhost kernel: Oops: 0002 [#4]
>
> [snip]
> Could you try the attached patch?
>
> --
> diff --git a/drivers/media/video/bttv-risc.c b/drivers/media/video/bttv-risc.c
> --- a/drivers/media/video/bttv-risc.c
> +++ b/drivers/media/video/bttv-risc.c
> @@ -53,7 +53,7 @@ bttv_risc_packed(struct bttv *btv, struc
> /* estimate risc mem: worst case is one write per page border +
> one write per scan line + sync + jump (all 2 dwords) */
> instructions = (bpl * lines) / PAGE_SIZE + lines;
> - instructions += 2;
> + instructions += 4;
> if ((rc = btcx_riscmem_alloc(btv->c.pci,risc,instructions*8)) < 0)
> return rc;
>
>
>
Hi Jiri,
Tried it but it seems to crash indeed faster, and this time it didn't
leave traces in the log.
Appreciate your help eitherway !
Mark v Wolher wrote:
> Jiri Slaby wrote:
>
>>>Hi Sami,
>>>
>>>That caused also a crash, i kept pressing the v key and within 15
>>>seconds it crashed, then i saw the crash-info appear in the log and when
>>>i clicked on mozilla then it crashed too but without crahs info and
>>>system froze totally.
>>>
>>>Below the crash info:
>>>
>>>Dec 31 17:38:32 localhost kernel: Unable to handle kernel paging request
>>>at virtual address c8111000
>>>Dec 31 17:38:32 localhost kernel: printing eip:
>>>Dec 31 17:38:32 localhost kernel: c036037a
>>>Dec 31 17:38:32 localhost kernel: *pgd = 21063
>>>Dec 31 17:38:32 localhost kernel: *pmd = 21063
>>>Dec 31 17:38:32 localhost kernel: *pte = 8111000
>>>Dec 31 17:38:32 localhost kernel: Oops: 0002 [#4]
>>
>>[snip]
>>Could you try the attached patch?
>>
>>--
>>diff --git a/drivers/media/video/bttv-risc.c b/drivers/media/video/bttv-risc.c
>>--- a/drivers/media/video/bttv-risc.c
>>+++ b/drivers/media/video/bttv-risc.c
>>@@ -53,7 +53,7 @@ bttv_risc_packed(struct bttv *btv, struc
>> /* estimate risc mem: worst case is one write per page border +
>> one write per scan line + sync + jump (all 2 dwords) */
>> instructions = (bpl * lines) / PAGE_SIZE + lines;
>>- instructions += 2;
>>+ instructions += 4;
>> if ((rc = btcx_riscmem_alloc(btv->c.pci,risc,instructions*8)) < 0)
>> return rc;
>>
>>
>>
>
>
>
> Hi Jiri,
>
> Tried it but it seems to crash indeed faster, and this time it didn't
> leave traces in the log.
>
> Appreciate your help eitherway !
> -
Hiya all,
First of all happy new year ! :-)
I might have discovered something interesting which might be responsible
for all those lockups/freezes/crashes !
Right now, i'm putting a huge load on the system, disk i/o, swapping
high, virusscan, number crushing with ssh-keygen moduli etc ...
5 hours passed with this load and no single crash/freeze/lockup happened
! Normally with all this load sooner or later something would have
happened.
What did i do ?
I disabled bttv support in the kernel, so no tv for me at this moment.
I'm planning to let this run for at least another 5 hours with heavy
load and see if still nothing happens...
Keeping you informed.
Mark
Mark v Wolher wrote:
> Mark v Wolher wrote:
>
>>Jiri Slaby wrote:
>>
>>
>>>>Hi Sami,
>>>>
>>>>That caused also a crash, i kept pressing the v key and within 15
>>>>seconds it crashed, then i saw the crash-info appear in the log and when
>>>>i clicked on mozilla then it crashed too but without crahs info and
>>>>system froze totally.
>>>>
>>>>Below the crash info:
>>>>
>>>>Dec 31 17:38:32 localhost kernel: Unable to handle kernel paging request
>>>>at virtual address c8111000
>>>>Dec 31 17:38:32 localhost kernel: printing eip:
>>>>Dec 31 17:38:32 localhost kernel: c036037a
>>>>Dec 31 17:38:32 localhost kernel: *pgd = 21063
>>>>Dec 31 17:38:32 localhost kernel: *pmd = 21063
>>>>Dec 31 17:38:32 localhost kernel: *pte = 8111000
>>>>Dec 31 17:38:32 localhost kernel: Oops: 0002 [#4]
>>>
>>>[snip]
>>>Could you try the attached patch?
>>>
>>>--
>>>diff --git a/drivers/media/video/bttv-risc.c b/drivers/media/video/bttv-risc.c
>>>--- a/drivers/media/video/bttv-risc.c
>>>+++ b/drivers/media/video/bttv-risc.c
>>>@@ -53,7 +53,7 @@ bttv_risc_packed(struct bttv *btv, struc
>>> /* estimate risc mem: worst case is one write per page border +
>>> one write per scan line + sync + jump (all 2 dwords) */
>>> instructions = (bpl * lines) / PAGE_SIZE + lines;
>>>- instructions += 2;
>>>+ instructions += 4;
>>> if ((rc = btcx_riscmem_alloc(btv->c.pci,risc,instructions*8)) < 0)
>>> return rc;
>>>
>>>
>>>
>>
>>
>>
>>Hi Jiri,
>>
>>Tried it but it seems to crash indeed faster, and this time it didn't
>>leave traces in the log.
>>
>>Appreciate your help eitherway !
>>-
>
>
>
> Hiya all,
>
> First of all happy new year ! :-)
>
>
> I might have discovered something interesting which might be responsible
> for all those lockups/freezes/crashes !
>
> Right now, i'm putting a huge load on the system, disk i/o, swapping
> high, virusscan, number crushing with ssh-keygen moduli etc ...
>
> 5 hours passed with this load and no single crash/freeze/lockup happened
> ! Normally with all this load sooner or later something would have
> happened.
>
> What did i do ?
>
> I disabled bttv support in the kernel, so no tv for me at this moment.
> I'm planning to let this run for at least another 5 hours with heavy
> load and see if still nothing happens...
>
> Keeping you informed.
>
> Mark
>
>
>
>
Still no crashes or irregular things happened ! Will let it go for a few
more hours. This test is being done with the binary nvidia module loaded
and bttv disabled. The next test will be nv for X instead of the binary
module with bttv enabled, if crashes and such start to occur then it's
very likely that the problem sits in the bttv code.
On Sun, Jan 01, 2006 at 02:06:06PM +0100, Mark v Wolher wrote:
...
> 5 hours passed with this load and no single crash/freeze/lockup happened
> ! Normally with all this load sooner or later something would have
> happened.
>
> What did i do ?
>
> I disabled bttv support in the kernel, so no tv for me at this moment.
I noticed this very same thing 1,5 years ago.
As a matter of fact, I haven't used bttv during the last ~two months
(except the "test" yesterday), and I haven't gotten crashes when
not using bttv.
> I'm planning to let this run for at least another 5 hours with heavy
> load and see if still nothing happens...
>
> Keeping you informed.
>
> Mark
--
Mark v Wolher wrote:
> Mark v Wolher wrote:
>
>>Mark v Wolher wrote:
>>
>>
>>>Jiri Slaby wrote:
>>>
>>>
>>>
>>>>>Hi Sami,
>>>>>
>>>>>That caused also a crash, i kept pressing the v key and within 15
>>>>>seconds it crashed, then i saw the crash-info appear in the log and when
>>>>>i clicked on mozilla then it crashed too but without crahs info and
>>>>>system froze totally.
>>>>>
>>>>>Below the crash info:
>>>>>
>>>>>Dec 31 17:38:32 localhost kernel: Unable to handle kernel paging request
>>>>>at virtual address c8111000
>>>>>Dec 31 17:38:32 localhost kernel: printing eip:
>>>>>Dec 31 17:38:32 localhost kernel: c036037a
>>>>>Dec 31 17:38:32 localhost kernel: *pgd = 21063
>>>>>Dec 31 17:38:32 localhost kernel: *pmd = 21063
>>>>>Dec 31 17:38:32 localhost kernel: *pte = 8111000
>>>>>Dec 31 17:38:32 localhost kernel: Oops: 0002 [#4]
>>>>
>>>>[snip]
>>>>Could you try the attached patch?
>>>>
>>>>--
>>>>diff --git a/drivers/media/video/bttv-risc.c b/drivers/media/video/bttv-risc.c
>>>>--- a/drivers/media/video/bttv-risc.c
>>>>+++ b/drivers/media/video/bttv-risc.c
>>>>@@ -53,7 +53,7 @@ bttv_risc_packed(struct bttv *btv, struc
>>>> /* estimate risc mem: worst case is one write per page border +
>>>> one write per scan line + sync + jump (all 2 dwords) */
>>>> instructions = (bpl * lines) / PAGE_SIZE + lines;
>>>>- instructions += 2;
>>>>+ instructions += 4;
>>>> if ((rc = btcx_riscmem_alloc(btv->c.pci,risc,instructions*8)) < 0)
>>>> return rc;
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>Hi Jiri,
>>>
>>>Tried it but it seems to crash indeed faster, and this time it didn't
>>>leave traces in the log.
>>>
>>>Appreciate your help eitherway !
>>>-
>>
>>
>>
>>Hiya all,
>>
>>First of all happy new year ! :-)
>>
>>
>>I might have discovered something interesting which might be responsible
>>for all those lockups/freezes/crashes !
>>
>>Right now, i'm putting a huge load on the system, disk i/o, swapping
>>high, virusscan, number crushing with ssh-keygen moduli etc ...
>>
>>5 hours passed with this load and no single crash/freeze/lockup happened
>>! Normally with all this load sooner or later something would have
>>happened.
>>
>>What did i do ?
>>
>>I disabled bttv support in the kernel, so no tv for me at this moment.
>>I'm planning to let this run for at least another 5 hours with heavy
>>load and see if still nothing happens...
>>
>>Keeping you informed.
>>
>>Mark
>>
>>
>>
>>
>
>
> Still no crashes or irregular things happened ! Will let it go for a few
> more hours. This test is being done with the binary nvidia module loaded
> and bttv disabled. The next test will be nv for X instead of the binary
> module with bttv enabled, if crashes and such start to occur then it's
> very likely that the problem sits in the bttv code.
>
>
>
>
Okay, here are the test results:
- heavy load + nvidia (binary module) + bttv with grabdisplay = crash
- heavy load + nv (not tainted kernel) + bttv with grabdisplay = crash
- heavy load + nvidia (binary module) + bttv with overlay = OK
- heavy load + nv (not tainted kernel) + bttv with overlay = OK
Adding vmware on top of it will cause the system sooner to freeze/crash
(using grabdisplay)
So what you think guys ?
Mark v Wolher wrote:
>> Still no crashes or irregular things happened ! Will let it go for a few
>> more hours. This test is being done with the binary nvidia module loaded
>> and bttv disabled. The next test will be nv for X instead of the binary
>> module with bttv enabled, if crashes and such start to occur then it's
>> very likely that the problem sits in the bttv code.
>
>
>Okay, here are the test results:
>
>
>- heavy load + nvidia (binary module) + bttv with grabdisplay = crash
>- heavy load + nv (not tainted kernel) + bttv with grabdisplay = crash
>
>- heavy load + nvidia (binary module) + bttv with overlay = OK
>- heavy load + nv (not tainted kernel) + bttv with overlay = OK
>
>Adding vmware on top of it will cause the system sooner to freeze/crash
>(using grabdisplay)
>
>So what you think guys ?
Hi,
we still think that there is a problem in bttv_risc_packed in computing
estimated size. My patch was bad, I see it now, but still don't understand, how
it is computed and how it should be:
instructions = (bpl * lines) / PAGE_SIZE + lines;
instructions += 2;
and here it crashes (the first line, the (*rp)) -- actually after while loop.
*(rp++)=cpu_to_le32(BT848_RISC_WRITE|BT848_RISC_EOL|todo);
*(rp++)=cpu_to_le32(sg_dma_address(sg));
So, Mauro (or somebody from list), have you any idea, what could be wrong?
thanks,
--
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
Jiri Slaby wrote:
> Mark v Wolher wrote:
>
>>>Still no crashes or irregular things happened ! Will let it go for a few
>>>more hours. This test is being done with the binary nvidia module loaded
>>>and bttv disabled. The next test will be nv for X instead of the binary
>>>module with bttv enabled, if crashes and such start to occur then it's
>>>very likely that the problem sits in the bttv code.
>>
>>
>>Okay, here are the test results:
>>
>>
>>- heavy load + nvidia (binary module) + bttv with grabdisplay = crash
>>- heavy load + nv (not tainted kernel) + bttv with grabdisplay = crash
>>
>>- heavy load + nvidia (binary module) + bttv with overlay = OK
>>- heavy load + nv (not tainted kernel) + bttv with overlay = OK
>>
>>Adding vmware on top of it will cause the system sooner to freeze/crash
>>(using grabdisplay)
>>
>>So what you think guys ?
>
> Hi,
> we still think that there is a problem in bttv_risc_packed in computing
> estimated size. My patch was bad, I see it now, but still don't understand, how
> it is computed and how it should be:
> instructions = (bpl * lines) / PAGE_SIZE + lines;
> instructions += 2;
> and here it crashes (the first line, the (*rp)) -- actually after while loop.
> *(rp++)=cpu_to_le32(BT848_RISC_WRITE|BT848_RISC_EOL|todo);
> *(rp++)=cpu_to_le32(sg_dma_address(sg));
> So, Mauro (or somebody from list), have you any idea, what could be wrong?
>
> thanks,
Well, i'd like to help in any way i can, but i'm not really a programmer :(
It seems also that xawtv on nvidia cards (using either nvidia binary
module or nv), at least, somehow doesn't know how to use the hardware to
scale the image in overlay mode. So if you use tvtime which i just
installed and running it is now fullscreen in overlay mode using the
card hardware (quite technical stuff so i'm not sure what else to say).
But back to grabdisplay, this causes the freezes/crashes, especially
under heavy load it'll happen very quick. It seems maybe that other
hardware combinations maybe do not suffer quickly from these things or
ppl with other videocards maybe (?)
It seems to be a combination of factors which might lead to these
issue's, maybe some bug in the bttv code, combined with nvidia cards for
example and xawtv using grabdisplay causes the freezes/crashes.
I'm now currently using tvtime instead of xawtv, overlay mode (i hope),
fullscreen which is basically why i had to use grabdisplay with xawtv in
the first place. I'm putting now alot of load on the system and hope
this is the solution (for now) ...
> >Okay, here are the test results:
> >- heavy load + nvidia (binary module) + bttv with grabdisplay = crash
> >- heavy load + nv (not tainted kernel) + bttv with grabdisplay = crash
> >- heavy load + nvidia (binary module) + bttv with overlay = OK
> >- heavy load + nv (not tainted kernel) + bttv with overlay = OK
> >Adding vmware on top of it will cause the system sooner to freeze/crash
> >(using grabdisplay)
> >So what you think guys?
Just to add:
something else is fishy: when I start iptraf (or some other traffic
dumper) my system hangs up. repeatable. also with a bttv card which is
occasionally used for grabbing videotext pages
Folkert van Heusden
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at http://www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
Folkert van Heusden wrote:
>>>Okay, here are the test results:
>>>- heavy load + nvidia (binary module) + bttv with grabdisplay = crash
>>>- heavy load + nv (not tainted kernel) + bttv with grabdisplay = crash
>>>- heavy load + nvidia (binary module) + bttv with overlay = OK
>>>- heavy load + nv (not tainted kernel) + bttv with overlay = OK
>>>Adding vmware on top of it will cause the system sooner to freeze/crash
>>>(using grabdisplay)
>>>So what you think guys?
>
>
> Just to add:
> something else is fishy: when I start iptraf (or some other traffic
> dumper) my system hangs up. repeatable. also with a bttv card which is
> occasionally used for grabbing videotext pages
>
>
> Folkert van Heusden
>
That could be an irq sharing issue i think. Do you use also grabdisplay
instead of overlay mode ?
Em Dom, 2006-01-01 ?s 19:49 +0100, Mark v Wolher escreveu:
> > So, Mauro (or somebody from list), have you any idea, what could be
> wrong?
hmm.. have you sent the patch to the list?
> >
> > thanks,
Cheers,
Mauro.
Mauro Carvalho Chehab wrote:
>Em Dom, 2006-01-01 às 19:49 +0100, Mark v Wolher escreveu:
>> So, Mauro (or somebody from list), have you any idea, what could be
>> wrong?
> hmm.. have you sent the patch to the list?
Yes, it was only a (bad) try to solve the problem. The point is, that there is
some weird problem in the estimating, or something (number of loops?).
The oops and the patch are on lkml site in this thread, I would give you a
link, but lkml seems to be down for me.
[the patch helps in some way, but didn't solve the problem]
all the best,
--
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
Jiri Slaby wrote:
> Mauro Carvalho Chehab wrote:
>
>>Em Dom, 2006-01-01 ? s 19:49 +0100, Mark v Wolher escreveu:
>>
>>>So, Mauro (or somebody from list), have you any idea, what could be
>>>wrong?
>>
>> hmm.. have you sent the patch to the list?
>
> Yes, it was only a (bad) try to solve the problem. The point is, that there is
> some weird problem in the estimating, or something (number of loops?).
>
> The oops and the patch are on lkml site in this thread, I would give you a
> link, but lkml seems to be down for me.
> [the patch helps in some way, but didn't solve the problem]
>
> all the best,
But i wonder, can you think of something why grabdisplay causes crashes
and overlay doesn't ? This needed patch, would it solve this problem too ?
Thanks
> > Just to add:
> > something else is fishy: when I start iptraf (or some other traffic
> > dumper) my system hangs up. repeatable. also with a bttv card which is
> > occasionally used for grabbing videotext pages
>
> That could be an irq sharing issue i think.
Nope.
> Do you use also grabdisplay instead of overlay mode?
No, I grab videotext pages.
Folkert van Heusden
--
Try MultiTail! Multiple windows with logfiles, filtered with regular
expressions, colored output, etc. etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Get your PGP/GPG key signed at http://www.biglumber.com!
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, http://www.vanheusden.com
Folkert van Heusden wrote:
>>>Just to add:
>>>something else is fishy: when I start iptraf (or some other traffic
>>>dumper) my system hangs up. repeatable. also with a bttv card which is
>>>occasionally used for grabbing videotext pages
>>
>>That could be an irq sharing issue i think.
>
>
> Nope.
>
>
>>Do you use also grabdisplay instead of overlay mode?
>
>
> No, I grab videotext pages.
>
>
> Folkert van Heusden
>
small update:
using tvtime and i put a heavy load on the system there are still no
random crashes or freezes happened.
I've found many reports that xawtv might cause system instability, some
say with overlay others say grabdisplay (in my case grabdisplay). But
when i use overlay mode in xawtv then i cannot get a real fullscreen.
Tried all the recommended parameters to xawtv to get it to real
fullscreen but somehow it doesn't, only in grabdisplay. Now i'm using
tvtime and things work perfect (unless i'm speaking too early, but i'll
leave it also for the whole night running a heavy load + tv on anyway)
I hope some one can comment on these issue's and especially if the bttv
code has to do with all this ?
On Sun, 2006-01-01 at 22:38 +0100, Mark v Wolher wrote:
> I hope some one can comment on these issue's and especially if the
> bttv code has to do with all this ?
>
I think you've established that the bttv driver is almost certainly the
problem.
Lee
Lee Revell wrote:
> On Sun, 2006-01-01 at 22:38 +0100, Mark v Wolher wrote:
>
>>I hope some one can comment on these issue's and especially if the
>>bttv code has to do with all this ?
>>
>
>
> I think you've established that the bttv driver is almost certainly the
> problem.
>
> Lee
>
sounds like some progress hehe I'm glad with this since there is nothing
more annoying then a box which can crash randomly. If any one would like
to test things or code and i can be of any help just let me know.
> But i wonder, can you think of something why grabdisplay causes crashes
> and overlay doesn't ? This needed patch, would it solve this problem too ?
Grabdisplay causes (roughly) twice the traffic. Overlay mode runs the TV
stream straight into the graphics card, peer-to-peer, while grabdisplay
streams into RAM, lets the CPU read from there, scale, and push into the
graphics card.
Pure overlay mode also produces zero CPU load.
On Llu, 2006-01-02 at 00:20 +0100, Peter Missel wrote:
> Grabdisplay causes (roughly) twice the traffic. Overlay mode runs the TV
> stream straight into the graphics card, peer-to-peer, while grabdisplay
> streams into RAM, lets the CPU read from there, scale, and push into the
> graphics card.
> Pure overlay mode also produces zero CPU load.
Grab display also stresses the main memory bus and bus arbitration logic
which caused problems on some older chipsets many of which handled
overlay mode fine. Equally some other older chipsets couldn't get
PCI<->PCI right but worked for main memory.
BT8x8's are very good for finding chipset problems.
Em Seg, 2006-01-02 ?s 22:29 +0000, Alan Cox escreveu:
> On Llu, 2006-01-02 at 00:20 +0100, Peter Missel wrote:
> Grab display also stresses the main memory bus and bus arbitration logic
> which caused problems on some older chipsets many of which handled
> overlay mode fine.
One common pci quirk is to increase latency timer. You may try to
increase it using an userspace tool (like powertweak or sysctl).
Please try to increase latency and give us some feedback. BTTV driver
is capable of using linux/drivers/pci/quirks.c info and honor it.
Cheers,
Mauro.
Jiri Slaby wrote:
>Mark v Wolher wrote:
>>> Still no crashes or irregular things happened ! Will let it go for a few
>>> more hours. This test is being done with the binary nvidia module loaded
>>> and bttv disabled. The next test will be nv for X instead of the binary
>>> module with bttv enabled, if crashes and such start to occur then it's
>>> very likely that the problem sits in the bttv code.
>>
>>
>>Okay, here are the test results:
>>
>>
>>- heavy load + nvidia (binary module) + bttv with grabdisplay = crash
>>- heavy load + nv (not tainted kernel) + bttv with grabdisplay = crash
>>
>>- heavy load + nvidia (binary module) + bttv with overlay = OK
>>- heavy load + nv (not tainted kernel) + bttv with overlay = OK
>>
>>Adding vmware on top of it will cause the system sooner to freeze/crash
>>(using grabdisplay)
>>
>>So what you think guys ?
>Hi,
>we still think that there is a problem in bttv_risc_packed in computing
>estimated size. My patch was bad, I see it now, but still don't understand, how
>it is computed and how it should be:
> instructions = (bpl * lines) / PAGE_SIZE + lines;
> instructions += 2;
>and here it crashes (the first line, the (*rp)) -- actually after while loop.
> *(rp++)=cpu_to_le32(BT848_RISC_WRITE|BT848_RISC_EOL|todo);
> *(rp++)=cpu_to_le32(sg_dma_address(sg));
>So, Mauro (or somebody from list), have you any idea, what could be wrong?
Mark, could you try the Duncan's patch, it seems, that's it:
http://lkml.org/lkml/diff/2006/1/25/59/1
regards,
--
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E