Linux 2.6.10-ac1

Linux 2.6.10-ac1

[Alan Cox]

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.

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

Re: Linux 2.6.10-ac1

[Bartlomiej Zolnierkiewicz]

> 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

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

Re: Linux 2.6.10-ac1

[Andreas Steinmetz]

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.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: Linux 2.6.10-ac1

[Bartlomiej Zolnierkiewicz]

On Mon, 27 Dec 2004 02:25:50 +0100, Andreas Steinmetz <ast@domdv.de> wrote:
> 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. :)

Re: Linux 2.6.10-ac1

[Alan Cox]

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.

Re: Linux 2.6.10-ac1

[Bartlomiej Zolnierkiewicz]

On Mon, 27 Dec 2004 14:28:53 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 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...

Re: Linux 2.6.10-ac1

[Ross Biro]

On Mon, 27 Dec 2004 02:40:45 +0100, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
> On Mon, 27 Dec 2004 02:25:50 +0100, Andreas Steinmetz <ast@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?

    Ross

Re: Linux 2.6.10-ac1

[Bartlomiej Zolnierkiewicz]

On Mon, 27 Dec 2004 09:45:54 -0500, Ross Biro <ross.biro@gmail.com> wrote:
> On Mon, 27 Dec 2004 02:40:45 +0100, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> > On Mon, 27 Dec 2004 02:25:50 +0100, Andreas Steinmetz <ast@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

Re: Linux 2.6.10-ac1

[Andreas Steinmetz]

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.
-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: Linux 2.6.10-ac1

[Bartlomiej Zolnierkiewicz]

On Mon, 27 Dec 2004 16:49:00 +0100, Andreas Steinmetz <ast@domdv.de> wrote:
> 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?

Re: Linux 2.6.10-ac1

[Andreas Steinmetz]

Bartlomiej Zolnierkiewicz wrote:
> 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 robotrap@domdv.de

Re: Linux 2.6.10-ac1

[Alan Cox]

On Llu, 2004-12-27 at 15:54, Bartlomiej Zolnierkiewicz wrote:
> 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

Re: Linux 2.6.10-ac1

[Rafael J. Wysocki]

On Monday, 27 of December 2004 02:25, Andreas Steinmetz wrote:
> 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"

Re: Linux 2.6.10-ac1

[Andreas Steinmetz]

Rafael J. Wysocki wrote:
> 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 robotrap@domdv.de

Re: Linux 2.6.10-ac1

[Alan Cox]

On Llu, 2004-12-27 at 00:57, Bartlomiej Zolnierkiewicz wrote:
> 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

Re: Linux 2.6.10-ac1

[Rogério Brito]

On Dec 27 2004, Alan Cox wrote:
> 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.

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 (hdc)
and an HP CD-Writer 9100 (hdd) both on the same VIA ide controller (ide1 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 UDMA33.
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 were
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 the
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-Writer
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 reliably.

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 for
chasing this strange situation.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - rbrito@ime.usp.br - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Linux 2.6.10-ac1

[Michal Schmidt]

Rogério Brito wrote:
> I have an Asus A7V motherboard with chipset VIA KT133 and it has 2 VIA 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 (ide1 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.

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 and,
> thus, I thought things would only get better.

I remember reading somewhere that one should not connect ATAPI devices 
to the Promise controller.

Michal

Re: Linux 2.6.10-ac1

[Alan Cox]

On Llu, 2004-12-27 at 20:43, Michal Schmidt wrote:
> > 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

Re: Linux 2.6.10-ac1

[Rogério Brito]

On Dec 28 2004, Alan Cox wrote:
> 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 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.

Is there any way to circumvent the limitations via software? I have already
upgraded the firmware of my motherboard (and, if I understood it correctly,
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 UDMA2.
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 cope
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 it
and paid a good deal of money). :-(


Thanks for all your feedback and suggestions, Rogério Brito.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - rbrito@ime.usp.br - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Linux 2.6.10-ac1

[Gene Heskett]

On Sunday 26 December 2004 18:31, Alan Cox wrote:
>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.

Re: Linux 2.6.10-ac1

[Gene Heskett]

On Sunday 26 December 2004 18:31, Alan Cox wrote:
>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.

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.

Re: Linux 2.6.10-ac1

[Alan Cox]

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 ..

Re: Linux 2.6.10-ac1

[Gene Heskett]

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.
>
>> 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.

Re: Linux 2.6.10-ac1

[Jan Dittmer]

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

Re: Linux 2.6.10-ac1

[Gene Heskett]

On Friday 31 December 2004 04:57, Jan Dittmer wrote:
>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.

Re: Linux 2.6.10-ac1

[Jan Dittmer]

Gene Heskett wrote:
> 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

[1] http://groups-beta.google.com/group/linux.kernel/browse_thread/thread/bbf1d32da11eb369/8b2300b83ac0ab9e?q=%22Restart+IP+invalid%22&_done=%2Fgroups%3Fq%3D%22Restart+IP+invalid%22%26hl%3Den%26lr%3D%26client%3Dfirefox%26rls%3Dorg.mozilla:en-US:unofficial%26sa%3DN%26tab%3Dwg%26&_doneTitle=Back+to+Search&&d#8b2300b83ac0ab9e

Re: Linux 2.6.10-ac1

[Gene Heskett]

On Friday 31 December 2004 07:38, Jan Dittmer wrote:
[...]
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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"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.