Linux 2.6.10-ac1
Alan Cox
upstream along with a couple of small extra changes that are needed because
of changes in 2.6.10 base. In addition the generic IRQ work in 2.6.10 means
that the forward port of the irqpoll code now covers a lot more platforms.
While this has had a lot less testing than 2.6.9-ac16 it does contain much
better core USB and SCSI code so may in some cases be worth an early move.
Arjan van de Ven is now building RPMS of the kernel and those can be found
in the RPM subdirectory and should be yum-able. Expect the RPMS to lag the
diff a little as the RPM builds and tests do take time.
Key: o - only in -ac
* - already fixed upstream
X - discarded later as wrong
+ - ac specific (fix not relevant to non -ac)
2.6.10-ac1
o Revert AX.25 protocol breakage (Alan Cox)
o Remove bogus obsolete option junk from 2.6.10 (Alan Cox)
ide changes
| Options are often useful, so should be kept.
| Especially stuff like serialize
o Fix bogus dma_ naming in the 2.6.10 patch (Alan Cox)
o Initial CS5520 fixups for VDMA and 2.6.10
| Must set vdma flag before command issue
| ?? could we just set it at boot and leave it - probably (check)
Forward ported from 2.6.9-ac
o Smbfs improved parsing fixes (Chuck Ebhert)
o Fix several IDE drivers that assumed > 0 was (Alan Cox)
also an error return for pci probe functions
o Fix sys5 semaphore wakeups (Manfred Spraul)
o Suggest irqpoll when we get screaming irqs (Alan Cox)
o Fix reset problems with older 3c59x/3c90x (John Linville)
o Configurable 100/1Khz clock for x86 (James Bottomley)
| 100Hz is great for battery life
o Delkin cardbus IDE support (Mark Lord)
o IT8212 IDE support (Alan Cox)
o Add more AC97 table data
o Token ring locking fix
o Fix URL for lanana (Alexander Stohr)
o Add a 1620 byte slab cache for ethernet frames (Arjan van de Ven)
o EDD boot options (Matt Domsch)
o Don't probe legacy ISA ide2,3,4,5 on PCI boxes (Alan Cox)
o Restore PWC driver (Luc Saillard)
| Please port away from remap_page_range
o Fix AT2701FX AMD PCnet32 on fibre (Guido Guenther)
o Fix build of CS461x gameport (Adrian Bunk)
o Fix crash with aacraid double complete (Mark Salyzyn, Tom Coughlan,
Alan Cox)
o Fix getblk_slow hang (Chris Mason)
+ Fix SMP hang with IDE unregister (Mark Lord)
o Working IDE locking (Alan Cox)
| And a great deal of review by Bartlomiej
o Allow IDE to grab all unknown generic IDE (Alan Cox)
devices (boot with "all-generic-ide")
o More ATI IDE PCI identifiers (Enrico Scholza)
o Initial patch for ide_abort hang (Alan Cox)
o Fix serveral ide timing violations on reset (Alan Cox)
o Support CSB6-R Serverworks raid (Alan Cox)
o Teach ide-cd to use sense data for file system (Alan Cox)
requests
- This means you get better diagonstics on CD errors
- It means a partial I/O failure will get you back the ok sectors
- It may fix the problem some users have with ISO copying and ide-cd
o Lock ide-proc against driver unload (Alan Cox)
(very low severity)
o Fix ide /proc and legacy devices problem (Alan Cox)
o Watchdog support for early cobalt ALi hardware (Mike Waychison)
o Make sx8 naming follow LANANA (Jeremy Katz)
o Don't warn on scsi ioctl kmalloc fail (Arjan van de Ven)
o Fix Paul Laufer's email address (Paul Laufer)
o Fix misleading microcode message (Arjan van de Ven)
o Allow cross compile of x86_32 kernel on x86_64 (Arjan van de Ven)
o Kill "open failed" cdrom message. (Alan Cox)
| This is a natural event from code poking around
| doing CD detection etc
o Minor typo fix in cdrom driver (efalk@google)
o Add support for newer ALi AGP (Clear Zhang)
o Handle E7xxx boxes with USB legacy flaws (Alan Cox)
Cleanups in porting
o Draw ->taskfile hooks in the IDE layer (Alan Cox)
(->fixup replaces)
o Fix up IT8212 for 2.6.10 ide_use_dma cleanups (Alan Cox)
and other 2.6.10 cleaning
Dropped for now
o VIA extra quirk
o HP Cardbus routing fixup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Bartlomiej Zolnierkiewicz
> o Revert AX.25 protocol breakage (Alan Cox)
> o Remove bogus obsolete option junk from 2.6.10 (Alan Cox)
> ide changes
> | Options are often useful, so should be kept.
> | Especially stuff like serialize
IMHO this is counter productive.
Most of these options are pure braindamage (they were obsoleted to
verify what is what) and they paper over real bugs in core or host drivers.
What do you need 'serialize' option for?
> o Fix bogus dma_ naming in the 2.6.10 patch (Alan Cox)
It is on purpose, we really don't need 'ide_' prefix in ide_hwif_t.
The rest of ide_dma_* functions will lose ide_* prefix over time.
Bartlomiej
Andreas Steinmetz
> What do you need 'serialize' option for?
I didn't check if the problem is gone with 2.6.10 but there's boards
like my tyan 2885 which do need the serialize option to work properly
for add-on ide controllers.
From the X86-64 patch release notes of Andi Kleen:
Reports that dual Tyan S2885 and S2880 can lock up when multiple IDE
channels are stressed in parallel. "noapic" or "ideX=serialize" seems to
work around it. Andre Hedrick thinks it's a generic bug/race in the IDE
code.
Do you want to force people to disable the io-apic just because of
option removal? In my case the serialized devices are a disk and a
dvd-rw which is rarely used, so disabling the io-apic is a bad solution.
--
Andreas Steinmetz SPAMmers use robo...@domdv.de
Bartlomiej Zolnierkiewicz
> Bartlomiej Zolnierkiewicz wrote:
> > What do you need 'serialize' option for?
>
> I didn't check if the problem is gone with 2.6.10 but there's boards
> like my tyan 2885 which do need the serialize option to work properly
> for add-on ide controllers.
>
> From the X86-64 patch release notes of Andi Kleen:
>
> Reports that dual Tyan S2885 and S2880 can lock up when multiple IDE
> channels are stressed in parallel. "noapic" or "ideX=serialize" seems to
> work around it. Andre Hedrick thinks it's a generic bug/race in the IDE
> code.
>
> Do you want to force people to disable the io-apic just because of
> option removal? In my case the serialized devices are a disk and a
> dvd-rw which is rarely used, so disabling the io-apic is a bad solution.
No, I want them to fix the problem - whenever it is - ide or apic code. :)
Rafael J. Wysocki
> Bartlomiej Zolnierkiewicz wrote:
> > What do you need 'serialize' option for?
>
> I didn't check if the problem is gone with 2.6.10 but there's boards
> like my tyan 2885 which do need the serialize option to work properly
> for add-on ide controllers.
>
> From the X86-64 patch release notes of Andi Kleen:
>
> Reports that dual Tyan S2885 and S2880 can lock up when multiple IDE
> channels are stressed in parallel. "noapic" or "ideX=serialize" seems to
> work around it. Andre Hedrick thinks it's a generic bug/race in the IDE
> code.
Well, that's not the only case, I think. I am able to lock up an S2885-based
box by ripping audio CDs. The CDs go into /dev/hda, which is a LiteOn
DVD-ROM and the target is on /dev/sdb*, which is on a 3ware SATA RAID
controller. The machine locks up on one CD out of three (approx. 10 tracks
each), quite regularly (I use KAudioCreator). It does not lock up this way
in any other conditions, apparently.
> Do you want to force people to disable the io-apic just because of
> option removal? In my case the serialized devices are a disk and a
> dvd-rw which is rarely used, so disabling the io-apic is a bad solution.
AFAIK, you can't disable the io-apic on these boards.
Greets,
RJW
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
Ross Biro
<bzol...@gmail.com> wrote:
> On Mon, 27 Dec 2004 02:25:50 +0100, Andreas Steinmetz <a...@domdv.de> wrote:
> > Bartlomiej Zolnierkiewicz wrote:
> > > What do you need 'serialize' option for?
>
And what do you want them to do when the problem is in hardware?
Ross
Andreas Steinmetz
> AFAIK, you can't disable the io-apic on these boards.
Hmm, boot with noapic and /proc/interrupts only shows XT-PIC entries.
--
Andreas Steinmetz SPAMmers use robo...@domdv.de
Alan Cox
> > Do you want to force people to disable the io-apic just because of
> > option removal? In my case the serialized devices are a disk and a
> > dvd-rw which is rarely used, so disabling the io-apic is a bad solution.
>
> No, I want them to fix the problem - whenever it is - ide or apic code. :)
Or hardware, or SMM ....
There are some very complex obscure platform specific funnies that end
up solved by serialize that I doubt anyone will get to the bottom of
before all the worlds parallel ATA drives have turned to rust (and/or
sand).
It seems the gnome desktop disease[1] is spreading to some kernel
people. It's all init code, its cheap and it works. Making it automated
in more cases is great, but you'll never stamp out the need for the
manual one even if its to do the debug to get the automated case right.
Alan
[1] Removing configuration features people need before (if ever)
providing a working alternative that is automatic.
Alan Cox
> Most of these options are pure braindamage (they were obsoleted to
> verify what is what) and they paper over real bugs in core or host drivers.
>
> What do you need 'serialize' option for?
A whole range of quirky systems, probably in most cases buggy hardware,
BIOS firmware setup bugs and the like but they are there and end users
use them. Its __init code so it is free.
As to real bugs there is probably a good three to six months fixing
needed for the DMA timeout paths having been debugging them, along with
timer/irq races all over the place. I'd rather worry about the fact the
IDE eh code is totally hosed first and realistically needs an ide_eh
thread for error handling akin to the SCSI approach.
>
> > o Fix bogus dma_ naming in the 2.6.10 patch (Alan Cox)
>
> It is on purpose, we really don't need 'ide_' prefix in ide_hwif_t.
> The rest of ide_dma_* functions will lose ide_* prefix over time.
The current code uses
dma_ for DMA variables
ide_dma_ for functions
Its nice clean and logical. I'll consider moving my IDE code over to
your naming when the naming is consistent again (with or without the
ide_).
Alan
Bartlomiej Zolnierkiewicz
> On Mon, 27 Dec 2004 02:40:45 +0100, Bartlomiej Zolnierkiewicz
> <bzol...@gmail.com> wrote:
> > On Mon, 27 Dec 2004 02:25:50 +0100, Andreas Steinmetz <a...@domdv.de> wrote:
> > > Bartlomiej Zolnierkiewicz wrote:
> > > > What do you need 'serialize' option for?
> >
> > No, I want them to fix the problem - whenever it is - ide or apic code. :)
>
> And what do you want them to do when the problem is in hardware?
Workaround it if it is possible. If this is really a unfixable hardware problem
(hard to believe - other OS-es would be also bitten by the issue) shouldn't it
be workaround differently anyway by something like "ide=serialize_all" (which
is much saner from IDE POV than "idex=serialize") ?
The reason I want to remove some of IDE options is that otherwise I have to
add ~ 200 lines of ugly code for storing them in the temporary buffer (part of
dynamic ide_hwifs[] patch) and it still is wrong...
IDE option -> IDE core -> IDE host driver
while it really should be
IDE option -> IDE host driver
Bartlomiej
Bartlomiej Zolnierkiewicz
> On Llu, 2004-12-27 at 01:40, Bartlomiej Zolnierkiewicz wrote:
> > > Do you want to force people to disable the io-apic just because of
> > > option removal? In my case the serialized devices are a disk and a
> > > dvd-rw which is rarely used, so disabling the io-apic is a bad solution.
> >
> > No, I want them to fix the problem - whenever it is - ide or apic code. :)
>
> Or hardware, or SMM ....
>
> There are some very complex obscure platform specific funnies that end
> up solved by serialize that I doubt anyone will get to the bottom of
> before all the worlds parallel ATA drives have turned to rust (and/or
> sand).
>
> It seems the gnome desktop disease[1] is spreading to some kernel
> people. It's all init code, its cheap and it works. Making it automated
> in more cases is great, but you'll never stamp out the need for the
> manual one even if its to do the debug to get the automated case right.
>
> Alan
>
> [1] Removing configuration features people need before (if ever)
> providing a working alternative that is automatic.
I use KDE. 8)
Sigh, nothing got removed yet...
Andreas Steinmetz
> Workaround it if it is possible. If this is really a unfixable hardware problem
> (hard to believe - other OS-es would be also bitten by the issue) shouldn't it
> be workaround differently anyway by something like "ide=serialize_all" (which
> is much saner from IDE POV than "idex=serialize") ?
Bad. This would neatly kill my raid 5 setup performance wise. Call this
idea a big step sideways. Doing a ide2=serialize leaves all three disks
running without serialization unless the dvd-rw is used. Just to make it
clear:
ide0 -> onboard, 1 master (disk)
ide1 -> onboard, 1 master (disk)
ide2/3 -> pci, 2 master (disk,dvd-rw)
Your idea would serialize all ide accesses which would slow down all
disks not affected by the problem requiring serialization.
--
Andreas Steinmetz SPAMmers use robo...@domdv.de
Bartlomiej Zolnierkiewicz
> Bartlomiej Zolnierkiewicz wrote:
> > Workaround it if it is possible. If this is really a unfixable hardware problem
> > (hard to believe - other OS-es would be also bitten by the issue) shouldn't it
> > be workaround differently anyway by something like "ide=serialize_all" (which
> > is much saner from IDE POV than "idex=serialize") ?
>
> Bad. This would neatly kill my raid 5 setup performance wise. Call this
> idea a big step sideways. Doing a ide2=serialize leaves all three disks
> running without serialization unless the dvd-rw is used. Just to make it
> clear:
> ide0 -> onboard, 1 master (disk)
> ide1 -> onboard, 1 master (disk)
> ide2/3 -> pci, 2 master (disk,dvd-rw)
> Your idea would serialize all ide accesses which would slow down all
> disks not affected by the problem requiring serialization.
Ah, so the problem only affects native PCI IRQs.
Is it possible that it is a buggy IDE host driver not a generic IDE problem?
Andreas Steinmetz
> Ah, so the problem only affects native PCI IRQs.
> Is it possible that it is a buggy IDE host driver not a generic IDE problem?
No, I tried 3 different pci cards requiring three different drivers. The
problem appeared with all three the same way.
--
Andreas Steinmetz SPAMmers use robo...@domdv.de
Alan Cox
> Ah, so the problem only affects native PCI IRQs.
> Is it possible that it is a buggy IDE host driver not a generic IDE problem?
More likely it is a core problem. I'm still stomping 400nS timing
violations and you don't have all of those let alone the other locking
stuff. Nor are we anywhere remotely near fixing them. Blaming the host
driver at this point seems a bit early for any IDE bug.
There certainly are corner cases where APIC timing for PIII especially
would radically change behaviour. We also exercise IRQ masking far
harder than any other driver with IDE.
Alan
RogérioBrito
> A whole range of quirky systems, probably in most cases buggy hardwar=
e,
> BIOS firmware setup bugs and the like but they are there and end user=
s
> use them. Its __init code so it is free.
This discussion is highly interesting in light of the behaviour that I'=
m
seeing in my system.
I have an Asus A7V motherboard with chipset VIA KT133 and it has 2 VIA =
IDE
(vt82c686a) controllers and 2 Promise PDC20265 controllers.
I'm seeing an strange behaviour. Until yesterday I had a DVD reader (hd=
c)
and an HP CD-Writer 9100 (hdd) both on the same VIA ide controller (ide=
1 in
my system).
Unfortunately, with this setup, I could not burn a CD and read a CD-ROM=
of
archived files at the same time. As it was a nuisance, I decided to put=
the
CD-Writer on the Promise controller, which is an UDMA100 controller and=
,
thus, I thought things would only get better.
Both drives, when connected on the VIA controller, were able to use UDM=
A33.
Unfortunately, to my surprise, now only the drive on the VIA controller=
is
able to use UDMA -- in other words, the drive connected to the Promise
controller is not able to use DMA.
Right after booting Linux 2.6.10, I see the following, regarding the HP
CD-Writer:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=
- -
dumont:~# hdparm /dev/hdf
/dev/hdf:
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
HDIO_GETGEO failed: Invalid argument
dumont:~#
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=
- -
On the other hand, here is what hdparm -i says about the drive:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=
- -
dumont:~# hdparm -I /dev/hdf
/dev/hdf:
ATAPI CD-ROM, with removable media
Model Number: Hewlett-Packard CD-Writer Plus 9100
Serial Number: YM5950LDU4
Firmware Revision: 1.0c
Standards:
Likely used CD-ROM ATAPI-1
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=180ns IORDY flow control==
120ns
dumont:~#
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=
- -
In fact, things are so strange that if I disable the Promise controller
from the BIOS, the CD-Writer is completely ignored by Linux (like it we=
re
not there -- no traces of it in the dmesg log and no access to it).
I would welcome any help to these problems. Right now, I am compiling t=
he
2.6.10-ac1 kernel in the hope that it solves this problem (my computer =
is
very slow and it takes about 30min to compile a new kernel). I'm using
Debian's testing/sarge distribution.
Oh, BTW, trying to substitute (on the Promise Controller) the HP CD-Wri=
ter
with a vanilla CD-ROM drive that supports mdma2 also gives me similar
behaviour to that of the HP CD-Writer: it can only use PIO mode 4 relia=
bly.
Ripping audio with grip's built-in cdparanoia is painfully slow in this
case (and, unfortunately, my DVD reader is quite old right now and isn'=
t
able to read some CD Audio discs that I have). :-(
Any help is welcome.
Thanks in advance, Rogério Brito.
P.S.: Please let me know what further information would be important fo=
r
chasing this strange situation.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogério Brito - rbr...@ime.usp.br - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
Michal Schmidt
> I have an Asus A7V motherboard with chipset VIA KT133 and it has 2 VI=
A IDE
> (vt82c686a) controllers and 2 Promise PDC20265 controllers.
I used to have the same MB.
> I'm seeing an strange behaviour. Until yesterday I had a DVD reader (=
hdc)
> and an HP CD-Writer 9100 (hdd) both on the same VIA ide controller (i=
de1 in
> my system).
>
> Unfortunately, with this setup, I could not burn a CD and read a CD-R=
OM of
> archived files at the same time.
I think that's normal.
> As it was a nuisance, I decided to put the
> CD-Writer on the Promise controller, which is an UDMA100 controller a=
nd,
> thus, I thought things would only get better.
I remember reading somewhere that one should not connect ATAPI devices
to the Promise controller.
Michal
Alan Cox
> > Unfortunately, with this setup, I could not burn a CD and read a CD-ROM of
> > archived files at the same time.
>
> I think that's normal.
Correct - IDE lacks "disconnect" so when the bus is locked during
something like a CD verify during a burn you don't get access to the
other device.
> > As it was a nuisance, I decided to put the
> > CD-Writer on the Promise controller, which is an UDMA100 controller and,
> > thus, I thought things would only get better.
>
> I remember reading somewhere that one should not connect ATAPI devices
> to the Promise controller.
Again exactly right - some promise controllers don't support ATAPI DMA.
As a general rule:
Put disks on the host first so they avoid the PCI bus overhead and
dont fill it
Put CD burners on host if you can
Use external controllers for slower stuff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
RogérioBrito
> Correct - IDE lacks "disconnect" so when the bus is locked during
> something like a CD verify during a burn you don't get access to the
> other device.
Yes, that was the problem that I was trying to circumvent.
> > > As it was a nuisance, I decided to put the CD-Writer on the Promi=
se
> > > controller, which is an UDMA100 controller and, thus, I thought
> > > things would only get better.
> >
> > I remember reading somewhere that one should not connect ATAPI devi=
ces
> > to the Promise controller.
>
> Again exactly right - some promise controllers don't support ATAPI DM=
A.
Is there any way to circumvent the limitations via software? I have alr=
eady
upgraded the firmware of my motherboard (and, if I understood it correc=
tly,
it also upgraded the firmware of the Promise controller).
The funny thing is that right after the Power On Self Test, the devices=
are
probed and then the Promise controller says that the drive supports UDM=
A2.
Then, when Linux boots, I see this:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=
- -
PDC20265: IDE controller at PCI slot 0000:00:11.0
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt 0000:00:11.0[A] -> GSI 10 (level, low) -> IRQ 10
PDC20265: chipset revision 2
PDC20265: 100%% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
hdf: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=
- -
> As a general rule:
> Put disks on the host first so they avoid the PCI bus overhead and
> dont fill it
> Put CD burners on host if you can
> Use external controllers for slower stuff
Ok, so if this is indeed buggy hardware, one way to make the system not
slow to a crawl would be to have:
* on ide0 the first HD and the DVD reader;
* on ide1 the second HD and the CD-Writer.
Since both ide0 and ide1 are VIA controllers, they would be able to cop=
e
with DMA. It will be really a deception with this motherboard if I can'=
t
use the Promise controller (which claimed to be ATA/100 when I bought i=
t
and paid a good deal of money). :-(
Thanks for all your feedback and suggestions, Rogério Brito.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogério Brito - rbr...@ime.usp.br - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
Gene Heskett
>Linux 2.6.10-ac1 is a merge of the stuff that has not yet been
> accepted upstream along with a couple of small extra changes that
> are needed because of changes in 2.6.10 base. In addition the
> generic IRQ work in 2.6.10 means that the forward port of the
> irqpoll code now covers a lot more platforms.
Alan: Just a quick note to say that it appears my samba problem with
2.6.10 has been fixed by 2.6.10-ac1, I can now mount and unmount
samba shares very quickly, as in milliseconds.
[root@coyote root]# time service asmb restart
Stopping share gene:
Stopping share dlds:
Starting share gene:
Starting share dlds:
real 0m0.276s
user 0m0.062s
sys 0m0.024s
Thats at least a second faster than its ever been before here. Now to
see if amanda likes it, something thats an amandad killer got in
someplace in the mm series leading up to V0.33-04, and amandad would
turn into a zombie, spoiling a backup. I'll know in about 5 hours
how that worked. Repeated runs of amcheck seem to be fine.
[...]
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett
> accepted upstream along with a couple of small extra changes that
> are needed because of changes in 2.6.10 base. In addition the
> generic IRQ work in 2.6.10 means that the forward port of the
> irqpoll code now covers a lot more platforms.
Maybe I spoke too soon Alan, my logs are being flooded with
some sort of an error message that looks like it may be memory
related. There's a pair of half giggers in here, running at 333 fsb,
but they are supposedly rated for a 400 mhz fsb. Thats presumably
because I have turned on the MCE stuffs.
Dec 29 23:43:09 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:43:09 coyote kernel: Bank 2: d40040000000017a
Dec 29 23:43:24 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:43:24 coyote kernel: Bank 1: d400400000000152
Dec 29 23:43:24 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:43:24 coyote kernel: Bank 2: d40040000000017a
Dec 29 23:43:39 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:43:39 coyote kernel: Bank 1: 9400400000000152
Dec 29 23:43:39 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:43:39 coyote kernel: Bank 2: d40040000000017a
Dec 29 23:43:54 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:43:54 coyote kernel: Bank 1: d400400000000152
Dec 29 23:43:54 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:43:54 coyote kernel: Bank 2: d40040000000017a
Dec 29 23:44:09 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:44:09 coyote kernel: Bank 1: d400400000000152
Dec 29 23:44:09 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Dec 29 23:44:09 coyote kernel: Bank 2: d40040000000017a
And I've not seen that before. Does it have a simple and correct answer?
This memory was abused by memtest86 for about 18 hours before I rebooted
and started changing things around because it was a new motherboard
and video card, back in the spring. No errors were reported then.
Should I worry or just shut that stuff back off?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Alan Cox
> some sort of an error message that looks like it may be memory
> related. There's a pair of half giggers in here, running at 333 fsb,
> but they are supposedly rated for a 400 mhz fsb. Thats presumably
> because I have turned on the MCE stuffs.
MCE's generally come from the processor. To decode it you need to know
what CPU and then get the manuals out and decode the bits.
> Dec 29 23:44:09 coyote kernel: MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
> Dec 29 23:44:09 coyote kernel: Bank 2: d40040000000017a
>
> And I've not seen that before. Does it have a simple and correct answer?
Its unhappy about something, but whatever is causing it isn't fatal.
Previously its been unhappy but not telling you ..
Gene Heskett
Thanks for the reply Alan, I appreciate it.
>On Iau, 2004-12-30 at 05:05, Gene Heskett wrote:
>> some sort of an error message that looks like it may be memory
>> related. There's a pair of half giggers in here, running at 333
>> fsb, but they are supposedly rated for a 400 mhz fsb. Thats
>> presumably because I have turned on the MCE stuffs.
>
>MCE's generally come from the processor. To decode it you need to
> know what CPU and then get the manuals out and decode the bits.
>
>> Dec 29 23:44:09 coyote kernel: MCE: The hardware reports a non
>> fatal, correctable incident occurred on CPU 0. Dec 29 23:44:09
>> coyote kernel: Bank 2: d40040000000017a
>>
>> And I've not seen that before. Does it have a simple and correct
>> answer?
>
>Its unhappy about something, but whatever is causing it isn't fatal.
>Previously its been unhappy but not telling you ..
Thats what I thought too Alan, after I'd connected the dots, so I
turned the nonfatal exceptions off. I'll give memtest86 another
chance to break it sometime next week. This is NOT ecc memory that I
know of although I paid nearly $80 per half gig when I bought it last
spring. Theres a gig of it in here, and only two addresses were
being reported, one in each bank. If mapped directly, are those
addresses even in that gig of ram? Thats too big a hex number for my
calculator. Or is there a way to use the dmesg data to define that?
Dumb question, could this memory be on the video card? Its an ATI
9200SE 128 meg card, your basic $85 commodity card there days.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Jan Dittmer
> On Thursday 30 December 2004 18:38, Alan Cox wrote:
>
> Thanks for the reply Alan, I appreciate it.
>
>
>>On Iau, 2004-12-30 at 05:05, Gene Heskett wrote:
>>
>>>some sort of an error message that looks like it may be memory
>>>related. There's a pair of half giggers in here, running at 333
>>>fsb, but they are supposedly rated for a 400 mhz fsb. Thats
>>>presumably because I have turned on the MCE stuffs.
>>
>>MCE's generally come from the processor. To decode it you need to
>>know what CPU and then get the manuals out and decode the bits.
>>
Here is a tool for it: (parsemce.c)
http://www.kernel.org/pub/linux/kernel/people/davej/tools/
Though I do not know for which processors it is supposed to work.
Jan
Gene Heskett
>Gene Heskett wrote:
>> On Thursday 30 December 2004 18:38, Alan Cox wrote:
>>
>> Thanks for the reply Alan, I appreciate it.
>>
>>>On Iau, 2004-12-30 at 05:05, Gene Heskett wrote:
>>>>some sort of an error message that looks like it may be memory
>>>>related. There's a pair of half giggers in here, running at 333
>>>>fsb, but they are supposedly rated for a 400 mhz fsb. Thats
>>>>presumably because I have turned on the MCE stuffs.
>>>
>>>MCE's generally come from the processor. To decode it you need to
>>>know what CPU and then get the manuals out and decode the bits.
>
>Here is a tool for it: (parsemce.c)
>
>http://www.kernel.org/pub/linux/kernel/people/davej/tools/
>
>Though I do not know for which processors it is supposed to work.
>
>Jan
Well, I've played with it some, but it doesn't seem to see the MCE
events that are in fact in /var/log/messages.
[root@coyote root]# parsemce -i </var/log/messages
This file contains no MCE dump
[root@coyote root]# parsemce -f /var/log/messages
This file contains no MCE dump
If I feed it the lines with the numbers it reports something about an
invalid IP on restart.
[root@coyote root]# parsemce -e Bank 2: d40040000000017a -b Bank 2: -s
d40040000000017a
Status: (ba) Error IP valid
Restart IP invalid.
The exact same output is obtained from the Bank 1 message & numbers
too.
So I think I do not know how to use it. Or the severeity of the
report isn't high enough. The logfile is currently about 1.27 megs
but that doesn't seem to be a problem. I haven't seen any more of
them since I turned off the nonfatal exceptions in .config. The
logfile has several hundred K of samba errors from the plain 2.6.10
kernel.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Jan Dittmer
> If I feed it the lines with the numbers it reports something about an
> invalid IP on restart.
>
> [root@coyote root]# parsemce -e Bank 2: d40040000000017a -b Bank 2: -s
> d40040000000017a
> Status: (ba) Error IP valid
> Restart IP invalid.
>
> The exact same output is obtained from the Bank 1 message & numbers
> too.
Try
$ ./parsemce -e 0xba -b 2 -s d40040000000017a -a 0
Status: (ba) Error IP valid
Restart IP invalid.
parsebank(2): d40040000000017a @ 0
External tag parity error
Correctable ECC error
Address in addr register valid
Error enabled in control register
Error overflow
Memory heirarchy error
Request: Generic error
Transaction type : Generic
Memory/IO : I/O
See [1] for a possible explanation. I hope the link works. It's a message
from DaveJ about the same error:
"Looks like the L2 cache ECC checking spotted something going wrong,
and fixed it up. This can happen in cases where there is inadequate
cooling, power, or overclocking (or in rare circumstances, flaky CPUs)"
Jan
Gene Heskett
[...]
Thanks, now if I can remember that..
>Try
>
>$ ./parsemce -e 0xba -b 2 -s d40040000000017a -a 0
>Status: (ba) Error IP valid
>Restart IP invalid.
>parsebank(2): d40040000000017a @ 0
> External tag parity error
> Correctable ECC error
> Address in addr register valid
> Error enabled in control register
> Error overflow
> Memory heirarchy error
> Request: Generic error
> Transaction type : Generic
> Memory/IO : I/O
>
>See [1] for a possible explanation. I hope the link works. It's a
> message from DaveJ about the same error:
>"Looks like the L2 cache ECC checking spotted something going wrong,
>and fixed it up. This can happen in cases where there is inadequate
>cooling, power, or overclocking (or in rare circumstances, flaky
> CPUs)"
>
>Jan
Is 132F too hot for an XP-2800? Based on my experience with an
XP1400, which ran for several years well above 165F, I'd think not.
And its running at about 2150 mhz. My previous XP1400 ran, and is
running at 1400 mhz in a new board, ran near 170F in the old board,
but now in a Mach Speed board with a 233mhz fsb, its only running at
34C. There is a Zalman flower with a 4" fan turning at 1834 rpms on
this XP2800, and a glaciator on the XP1400 turning about 6 grand,
noisy.
This ones running setiathome of course, and so was the XP1400 when it
was in this machine.
>[1]
Yikes, I'll have to save this out, and make it all into one line with
vim & give it a try. ATM though, I've got a cold & headed back to
bed. Friggin miserable.
Thanks again.
> http://groups-beta.google.com/group/linux.kernel/browse_thread/thre
>ad/bbf1d32da11eb369/8b2300b83ac0ab9e?q=%22Restart+IP+invalid%22&_don
>e=%2Fgroups%3Fq%3D%22Restart+IP+invalid%22%26hl%3Den%26lr%3D%26clien
>t%3Dfirefox%26rls%3Dorg.mozilla:en-US:unofficial%26sa%3DN%26tab%3Dwg
>%26&_doneTitle=Back+to+Search&&d#8b2300b83ac0ab9e -
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majo...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.