Re: [PATCH 1/1 try#2] [INPUT] keypad driver: Added support for OpenCores Keyboard Controller
On Thu, Jan 31, 2008 at 01:18:22AM +0800, Bryan Wu wrote:
> +static irqreturn_t opencores_kbd_isr(int irq, void *dev_id)
> +{
> + unsigned char c;
> + struct platform_device *pdev = dev_id;
> + struct opencores_kbd *opencores_kbd = platform_get_drvdata(pdev);
> + struct input_dev *input = opencores_kbd->input;
> +
> + c = readb(opencores_kbd->addr_res->start);
> + input_report_key(input, c & 0x7f, c & 0x80 ? 0 : 1);
> + input_sync(input);
> +
> + return IRQ_HANDLED;
> +}
This looks utterly wrong: It assumes 1:1 mapping between Linux keycodes
and what the keyboard sends, which I can't believe is the case.
--
Vojtech Pavlik
Director SuSE Labs
--
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/
Re: [PATCH 1/1 try#2] [INPUT] keypad driver: Added support for OpenCores Keyboard Controller
On Tue, Feb 05, 2008 at 12:18:15PM +0100, Javier Herrero wrote:
> Dear Vojtech,
>
> I think that a 1:1 mapping between linux keycodes and what keyboard sends
> is right, because the scan code to key code conversion is already
> programmed and done inside the FPGA code.
And the FPGA code changes with different keyboards attached?
> Best regards,
>
> Javier
>
> Vojtech Pavlik escribió:
>> On Thu, Jan 31, 2008 at 01:18:22AM +0800, Bryan Wu wrote:
>>
>>> +static irqreturn_t opencores_kbd_isr(int irq, void *dev_id)
>>> +{
>>> + unsigned char c;
>>> + struct platform_device *pdev = dev_id;
>>> + struct opencores_kbd *opencores_kbd = platform_get_drvdata(pdev);
>>> + struct input_dev *input = opencores_kbd->input;
>>> +
>>> + c = readb(opencores_kbd->addr_res->start);
>>> + input_report_key(input, c & 0x7f, c & 0x80 ? 0 : 1);
>>> + input_sync(input);
>>> +
>>> + return IRQ_HANDLED;
>>> +}
>> This looks utterly wrong: It assumes 1:1 mapping between Linux keycodes
>> and what the keyboard sends, which I can't believe is the case.
>>
>
> --
>
> Javier HerreroEMAIL: [EMAIL PROTECTED]
> HV Sistemas S.L. PHONE: +34 949 336 806
> Los Charcones, 17AFAX: +34 949 336 792
> 19170 El Casar - Guadalajara - Spain WEB: http://www.hvsistemas.com
--
Vojtech Pavlik
Director SuSE Labs
--
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/
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote: > > For the symmetric key solution, I will try HMAC (Hash Message > > Authentication Code). It's already used in networking, hope the > > performance is not too bad to a big image. > > Kernel already supports crc32 of the hibernation image, you may want > to take a look how that is done. > > Maybe you want to replace crc32 with cryptographics hash (sha1?) and > then use only hash for more crypto? That way speed of whatever crypto > you do should not be an issue. Well, yes, one could skip the CRC when the signing is enabled to gain a little speedup. > Actually... > > Is not it as simple as storing hash of hibernation image into NVRAM > and then verifying the hash matches the value in NVRAM on next > startup? No encryption needed. First, there is no encryption going on. Only doing a HMAC (digest (hash) using a key) of the image. Second, since NVRAM is accessible through efivarsfs, storing the hash in NVRAM wouldn't prevent an attacker from modifying the hash to match a modified image. There is a reason why the key for the HMAC is stored in the NVRAM in a BootServices variable that isn't accessible from the OS and is write-protected on hardware level from the OS. > And that may even be useful for non-secure-boot people, as it ensures > you boot right image after resume, boot it just once, etc... The HMAC approach isn't much more complicated, and it gives you all these benefits even with secure boot disabled. -- Vojtech Pavlik Director SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 02:21:23PM +0200, Michal Marek wrote: > > Is not it as simple as storing hash of hibernation image into NVRAM > > and then verifying the hash matches the value in NVRAM on next > > startup? No encryption needed. > > I think that part of the exercise is to minimize the number of writes to > the NVRAM. The hash changes with every hibernation, obviously. The key should, too. -- Vojtech Pavlik Director SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote:
> > The only two problems I see are
> >
> > 1. The key isn't generational (any compromise obtains it). This
> > can be fixed by using a set of keys generated on each boot and
> > passing in both K_{N-1} and K_N
>
> I think this could be easily made optional, leaving the user with choice
> of faster or "safer" boot.
Ideally, the key should be regenerated on each true reboot and kept the
same if it is just a resume. Unfortunately, I don't see a way to
distinguish those before we call ExitBootServices().
The reasoning behind that is that in the case of a kernel compromise, a
suspended-and-resumed kernel will still be compromised, so there is no
value in passing it a new key. A freshly booted kernel, though, should
get a new key, exactly because the attacker could have obtained a key
from the previous, compromised one.
This speeds up the ususal suspend-and-resume cycle, but provides full
security once the user performs a full reboot.
The question that remains is how to tell in advance.
> > 2. No external agency other than the next kernel can do the
> > validation since the validating key has to be secret
>
> This is true, but as you said, the relevance of this seems to be rather
> questionable.
Indeed, it's hard to imagine a scenario that is also valid within the
secure boot threat model.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Load keys from signed PE binaries
On Thu, Feb 28, 2013 at 10:51:15PM +, Matthew Garrett wrote: > On Thu, Feb 28, 2013 at 11:48:06PM +0100, Jiri Kosina wrote: > > > Let me formulate my point more clearly -- Microsoft very likely going to > > sign hello world EFI PE binary, no matter the contents of .keylist > > section, as they don't give a damn about this section, as it has zero > > semantic value to them, right? > > > > They sign the binary. By signing the binary, they are *NOT* establishing > > cryptographic chain of trust to the key stored in .keylist, but your > > patchset seems to imply so. > > Mr Evil Blackhat's binary is then a mechanism for circumventing the > Windows trust mechanism, and as such his account is subject to > termination and his binary can be added to dbx. Why? Let's take a look on what would happen in this scenario: A PE binary, from Mr. Blackhat, doing nothing, in general, but containing a key in a section, was signed by MS on the grounds that the binary isn't harmful. By issuing the signature, MS is attesting that the binary is safe, but isn't saying anything about the data (key) embedded in it. It doesn't say the key comes from a trusted party. It just says "this isn't malware", and that's what their tools verify. Your shim loader (signed by MS) loads your Linux kernel. Your Linux kernel, then, based on the key-in-PE model decides to trust the key, although nobody really said it's to be trusted. Mr. Blackhat then can load his i_own_your_ring0.ko module signed by his key on your system, having obtained root access previously. You call Microsoft, telling them what Mr. Blackhat has done. They now can: a) Do what you want: Disable Mr. Blackhat's account and revoke the hash of his binary. But also: b) Say, "oh well, we're sorry this kills your security model, but it's enough for us that you already fully booted Linux to worry about Windows security, this affects only your distribution and we don't care". c) Decide your security model is flawed, because you're abusing their signature process to mean something else from what they intended and revoke your shim hash instead. And I don't think you can rely on MS doing 'a'. Particularly when there will be a large number of key-in-PE binaries signed by them at that point, with them not being able to tell by any analysis which of them are evil and which not. I would even say b) is most likely. > We'd check the binary hash against dbx and refuse to load it on > systems that have received the update, and Mr Evil Blackhat would have > to find a new bunch of identity documents to create a new account to > repeat the process. Yes, from the point it gets blacklisted, it's fairly clear. You're forced to reboot, but under the Secure Boot model, you have to do that on any system that used code whose hash has been revoked. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: idebus=xx on a ISA only 486
On Mon, Apr 16, 2001 at 10:42:12PM +1000, [EMAIL PROTECTED] wrote: > Hi, > This may be harmless but I noticed a warning msg when I went to > 2.4.3 on a ISA only 486 mobo. > > Feb 18 18:01:41 speedy kernel: ide: Assuming 50MHz system bus speed for > PIO modes; override with idebus=xx > > My first thought was to drop idebus to 8Mhz (I think this is the > ISA speed ?), > but using that > Feb 18 18:01:41 speedy kernel: Kernel command line: auto BOOT_IMAGE=243 > ro root=301 BOOT_FILE=/boot/vmlinuz-2.4.3 idebus=8 > Feb 18 18:01:41 speedy kernel: ide_setup: idebus=8 -- BAD BUS SPEED! > Expected value from 20 to 66 > > and then a quick grep/poke in the src gave this > > ./drivers/ide/ide.c > Version 5.50 allow values as small as 20 for idebus= > > and at line 350 it seems that its pci or nothing for the bus speed. > > the only deterministic problem (so far that I can directly attribute to > that kernel) with the > 2.4.3 booted kernel is that ssh2 locks up for random amounts of time at > randomish intervals. > > I can't seem to dig up other info on this problem, I am sorry if this is > the wrong place > to ask. If there are better places to be looking for this data I am > happy to RTFM there. > > Now trying 2.4.3-ac6 to see what happens there. idebus= isn't used in case there is no VL-BUS or PCI bus in your system. -- Vojtech Pavlik SuSE Labs - 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/
Re: ATA 100 & VIA and linux-2.4.3ac8
On Wed, Apr 18, 2001 at 10:21:53PM -0400, Manuel Ignacio Monge Garcia wrote: > El Mié 18 Abr 2001 15:16, escribiste: > > I don't know about other possible problems with the kernel, but you must > > use an 80 wire IDE cable for UDMA66/100 to work. > > > > > ---Primary IDE---Secondary IDE-- > > > Cable Type: 40w 40w > > > Strange thing. With previous version of kernel (2.4.1 I think), I > haven't got this problem. May be a bios detection problem? > > Extract from /usr/src/linux/drivers/ide/via82cxxx..c: > > * > * PIO 0-5, MWDMA 0-2, SWDMA 0-2 and UDMA 0-5 > * > * (this includes UDMA33, 66 and 100) modes. UDMA66 and higher modes are > * autoenabled only in case the BIOS has detected a 80 wire cable. To ignore > * the BIOS data and assume the cable is present, use 'ide0=ata66' or > * 'ide1=ata66' on the kernel command line. > * > > I've tried with ide0=ata100, but this options doesn't work. Try ide0=ata66 instead. The option should have been named ide0=80wire, but, well, "ata66" was chosen as the name, because that was it at the time. -- Vojtech Pavlik SuSE Labs - 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/
Re: ATA 100
On Thu, Apr 19, 2001 at 04:46:03PM +0200, David Balazic wrote: > Vojtech Pavlik ([EMAIL PROTECTED]) wrote : > > > On Wed, Apr 18, 2001 at 10:21:53PM -0400, Manuel Ignacio Monge Garcia wrote: > > > > > El Mié 18 Abr 2001 15:16, escribiste: > > > > I don't know about other possible problems with the kernel, but you must > > > > use an 80 wire IDE cable for UDMA66/100 to work. > > > > > > > > > ---Primary IDE---Secondary IDE-- > > > > > Cable Type: 40w 40w > > > > > > > > > Strange thing. With previous version of kernel (2.4.1 I think), I > > > haven't got this problem. May be a bios detection problem? > > > > > > Extract from /usr/src/linux/drivers/ide/via82cxxx..c: > > > > > > * > > > * PIO 0-5, MWDMA 0-2, SWDMA 0-2 and UDMA 0-5 > > > * > > > * (this includes UDMA33, 66 and 100) modes. UDMA66 and higher modes are > > > * autoenabled only in case the BIOS has detected a 80 wire cable. To ignore > > > * the BIOS data and assume the cable is present, use 'ide0=ata66' or > > > * 'ide1=ata66' on the kernel command line. > > > * > > > > > > I've tried with ide0=ata100, but this options doesn't work. > > > > Try ide0=ata66 instead. The option should have been named ide0=80wire, > > but, well, "ata66" was chosen as the name, because that was it at the > > time. > > Any chance of auto detecting this ? None. It's different on each (pre-686b) VIA motherboard. > I just hate when linux is relaying on the BIOS ... We don't have any other chance here. Actually we'll have to rely on the BIOS for even more in the next release of the driver to make it work on all boards out there. > BTW , why are there 666 CONFIG_.*IDE.*DMA.* switches ? Ask Andre. :) -- Vojtech Pavlik SuSE Labs - 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/
[patch] VIA 4.2x driver for 2.2 kernels
Hi Andre! You wanted my VIA driver for 2.2. Here is a patch that brings the very latest 4.2 driver to the 2.2 kernel. The patch is against the 2.2.19-pre13 kernel plus yours 1221 ide patch. Enjoy! -- Vojtech Pavlik SuSE Labs via-4.2x-for-2.2.19-pre13-ide1221.diff.bz2
Re: [IDE] meaningless #ifndef?
On Tue, Feb 20, 2001 at 05:45:52PM +, Hugh Dickins wrote:
> >
> > > from drivers/ide/ide-features.c:
> > >
> > > /*
> > > * All hosts that use the 80c ribbon mus use!
> > > */
> > > byte eighty_ninty_three (ide_drive_t *drive)
> > > {
> > > return ((byte) ((HWIF(drive)->udma_four) &&
> > > #ifndef CONFIG_IDEDMA_IVB
> > > (drive->id->hw_config & 0x4000) &&
> > > #endif /* CONFIG_IDEDMA_IVB */
> > > (drive->id->hw_config & 0x6000)) ? 1 : 0);
> > > }
> > >
> > > If i see well, then this is always same whether CONFIG_IDEDMA_IVB is
> > > defined or not.
> > > What's the clue?
> > The first is true only if bit 14 is set.
> > The second is true if either bit 13 or 14 is set.
> >
> > Togather they test for two bits.
> > The first test is exclusive to bit 14
> > The second test is inclusive of bits 13 and 14.
> Andre, please read through that code again, and through your reply.
> It seems to me that Poszar is absolutely right, and your reply is
> (once again) just saying "there's lots of confusion out there, so
> my code has to be confused too". Or do your &s and &&s behave
> differently from ours?
Well, the code looks weird. However, it doesn't behave the same when
CONFIG_IDEDMA_IVB is enabled or not. If it is not, normal case, it's
just:
(drive->id->hw_config & 0x6000)
If CONFIG_IDEDMA_IVB is enabled, it boils down to:
(drive->id->hw_config & 0x4000)
because the second bit test includes the earlier test already only
loosening it. Because of that, it's superfluous. And the code relies on
the compiler to optimize it out.
If written like:
#ifndef CONFIG_IDEDMA_IVB
#define IDE_UDMA_MASK 0x4000
#else
#define IDE_UDMA_MASK 0x6000
#endif /* CONFIG_IDEDMA_IVB */
byte eighty_ninty_three (ide_drive_t *drive)
{
return HWIF(drive)->udma_four &&
(drive->id->hw_config & IDE_UDMA_MASK);
}
it'd be probably somewhat clearer.
--
Vojtech Pavlik
SuSE Labs
-
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/
Re: hang on mount, 2.4.2-pre4, VIA
On Tue, Feb 20, 2001 at 10:16:22AM -0800, Dan Christian wrote: > Hello, > I just tried upgrading to 2.4.2-pre4 from 2.4.1 and get a hang when > mounting the file systems. I have the same problem with 2.4.1-ac18. > > The system is a single processor P3 and uses a VIA chipset (Tyan > something-or-other). DMA, multi-sector IO, and 32bit sync are enabled > using hdparm (just before the hang). Remove the hdparm command. It isn't needed. > There are two Ultra-66 drives > attached to one IDE channel and a CD-RW on a second IDE channel. > > The distribution is RH7 with recent security patches and modutils > 2.4.2. The kernel was built with kgcc. > > Has anybody else seen this? I assume these problems weren't present before? > I'm not on the list. Please CC me on any replies. What's your southbridge chip (lspci ...)? What are the drives (hdparm -i ...)? I can send you the VIA latest drivers if you are interested in trying whether they'll help. -- Vojtech Pavlik SuSE Labs - 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/
Re: [patch] VIA 4.2x driver for 2.2 kernels
On Tue, Feb 20, 2001 at 03:59:27PM -0800, Shane Wegner wrote: > > You wanted my VIA driver for 2.2. Here is a patch that brings the very > > latest 4.2 driver to the 2.2 kernel. The patch is against the > > 2.2.19-pre13 kernel plus yours 1221 ide patch. > > This drivers breaks with my HP 8110 CD-R drive. It's > sitting on primary slave of a Via 686B controler. When I > try to do a hdparm -d1 -u1 -k1 /dev/hdb, the kernel locks > up hard. Not even an oops. Reverting to the old driver > works fine. Don't do that. Use the kernel option to enable DMA instead. Hmm, I'll have to look into this anyway - many users seem to do that and it isn't as harmless as it looks (it worked by pure luck with the previous version). -- Vojtech Pavlik SuSE Labs - 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/
Re: [patch] VIA 4.2x driver for 2.2 kernels
On Tue, Feb 20, 2001 at 11:15:02PM -0800, Shane Wegner wrote: > On Wed, Feb 21, 2001 at 08:09:19AM +0100, Vojtech Pavlik wrote: > > On Tue, Feb 20, 2001 at 03:59:27PM -0800, Shane Wegner wrote: > > > > > > You wanted my VIA driver for 2.2. Here is a patch that brings the very > > > > latest 4.2 driver to the 2.2 kernel. The patch is against the > > > > 2.2.19-pre13 kernel plus yours 1221 ide patch. > > > > > > This drivers breaks with my HP 8110 CD-R drive. It's > > > sitting on primary slave of a Via 686B controler. When I > > > try to do a hdparm -d1 -u1 -k1 /dev/hdb, the kernel locks > > > up hard. Not even an oops. Reverting to the old driver > > > works fine. > > > > Don't do that. Use the kernel option to enable DMA instead. > > > > Hmm, I'll have to look into this anyway - many users seem to do that > > and it isn't as harmless as it looks (it worked by pure luck with > > the previous version). > Ok, can I still use -u1 -k1 -c1 on the drives or is it even > necessary anymore. If you enable automatic DMA in the kernel config, it isn't necessary at all. The VIA driver sets up everything. > Is the deprecation of -d1 VIA IDE > specific or does it apply to the entire subsystem. Well, in my opinion it was always a potentially dangerous option and so it remains. I'll update the VIA driver to make sure its not dangerous at least with it anymore. Scenario: 1) AutoDMA not enabled 2) VIA sets PIO mode on boot 3) User enables DMA -> IDE driver starts using dma 4) But VIA is still set to PIO mode I'll have to make the VIA driver check when IDE dma is enabled, test whether the chipset was already programmed for it and program the chipset for it if needed. -- Vojtech Pavlik SuSE Labs - 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/
Re: [patch] VIA 4.2x driver for 2.2 kernels
On Wed, Feb 21, 2001 at 11:05:33AM -0300, Rogerio Brito wrote: > On Feb 21 2001, Vojtech Pavlik wrote: > > On Tue, Feb 20, 2001 at 11:15:02PM -0800, Shane Wegner wrote: > > > Ok, can I still use -u1 -k1 -c1 on the drives or is it even > > > necessary anymore. > > > > If you enable automatic DMA in the kernel config, it isn't necessary > > at all. The VIA driver sets up everything. > > Ok. Please disregard my last message (this one contains > exactly what I was looking for). > > > 4) But VIA is still set to PIO mode > > Why does this happen? > > And what about the other options to hdparm (-u1 -k1 -c1)? Are > they potentially dangerous also? Well, I checked today and my fears were *not* confirmed. Actually the VIA driver will set up the chipset for UDMA even when UDMA won't be later used, so it's all OK. -- Vojtech Pavlik SuSE Labs - 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/
Re: Via UDMA5 3/4/5 is not functional!
On Thu, Feb 22, 2001 at 10:09:29AM +0200, Catalin BOIE wrote:
> Hi, guys!
>
> I want to report a problem.
>
> I have an Athlon 900MHz / 256 MB RAM, chipset: VIA VT82c686B, IBM
> harddrive (IBM-DTLA-307030).
>
> At first I tried kernel 2.2.16:
> - hdparm -u1 -d1 -X69 /dev/hda => I get 36MB/s
>
> Then I tried kernel 2.4.1. I issued exactly the same hdparm command.
> i got in syslog the message: "ide0: Speed warnings UDMA 3/4/5 is not
> functional"!
>
> What is the problem?
The 80-wire cable was not detected. Try this driver ...
--
Vojtech Pavlik
SuSE Labs
#ifndef _IDE_TIMING_H
#define _IDE_TIMING_H
/*
* $Id: ide-timing.h,v 2.1 2001/02/08 19:32:56 vojtech Exp $
*
* Copyright (c) 1999-2000 Vojtech Pavlik
*
* Sponsored by SuSE
*/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Should you need to contact me, the author, you can do so either by
* e-mail - mail your message to <[EMAIL PROTECTED]>, or by paper mail:
* Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
*/
#include
#include
#define XFER_PIO_5 0x0d
#define XFER_UDMA_SLOW 0x4f
struct ide_timing {
short mode;
short setup;/* t1 */
short act8b;/* t2 for 8-bit io */
short rec8b;/* t2i for 8-bit io */
short cyc8b;/* t0 for 8-bit io */
short active; /* t2 or tD */
short recover; /* t2i or tK */
short cycle;/* t0 */
short udma; /* t2CYCTYP/2 */
};
/*
* PIO 0-5, MWDMA 0-2 and UDMA 0-5 timings (in nanoseconds).
* These were taken from ATA/ATAPI-6 standard, rev 0a, except
* for PIO 5, which is a nonstandard extension.
*/
static struct ide_timing ide_timing[] = {
{ XFER_UDMA_5, 0, 0, 0, 0, 0, 0, 0, 20 },
{ XFER_UDMA_4, 0, 0, 0, 0, 0, 0, 0, 30 },
{ XFER_UDMA_3, 0, 0, 0, 0, 0, 0, 0, 45 },
{ XFER_UDMA_2, 0, 0, 0, 0, 0, 0, 0, 60 },
{ XFER_UDMA_1, 0, 0, 0, 0, 0, 0, 0, 80 },
{ XFER_UDMA_0, 0, 0, 0, 0, 0, 0, 0, 120 },
{ XFER_UDMA_SLOW, 0, 0, 0, 0, 0, 0, 0, 150 },
{ XFER_MW_DMA_2, 25, 0, 0, 0, 70, 25, 120, 0 },
{ XFER_MW_DMA_1, 45, 0, 0, 0, 80, 50, 150, 0 },
{ XFER_MW_DMA_0, 60, 0, 0, 0, 215, 215, 480, 0 },
{ XFER_SW_DMA_2, 60, 0, 0, 0, 120, 120, 240, 0 },
{ XFER_SW_DMA_1, 90, 0, 0, 0, 240, 240, 480, 0 },
{ XFER_SW_DMA_0, 120, 0, 0, 0, 480, 480, 960, 0 },
{ XFER_PIO_5, 20, 50, 30, 100, 50, 30, 100, 0 },
{ XFER_PIO_4, 25, 70, 25, 120, 70, 25, 120, 0 },
{ XFER_PIO_3, 30, 80, 70, 180, 80, 70, 180, 0 },
{ XFER_PIO_2, 30, 290, 40, 330, 100, 90, 240, 0 },
{ XFER_PIO_1, 50, 290, 93, 383, 125, 100, 383, 0 },
{ XFER_PIO_0, 70, 290, 240, 600, 165, 150, 600, 0 },
{ XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 960, 0 },
{ -1 }
};
#define IDE_TIMING_SETUP0x01
#define IDE_TIMING_ACT8B0x02
#define IDE_TIMING_REC8B0x04
#define IDE_TIMING_CYC8B0x08
#define IDE_TIMING_8BIT 0x0e
#define IDE_TIMING_ACTIVE 0x10
#define IDE_TIMING_RECOVER 0x20
#define IDE_TIMING_CYCLE0x40
#define IDE_TIMING_UDMA 0x80
#define IDE_TIMING_ALL 0xff
#define MIN(a,b)((a)<(b)?(a):(b))
#define MAX(a,b)((a)>(b)?(a):(b))
#define FIT(v,min,max) MAX(MIN(v,max),min)
#define ENOUGH(v,unit) (((v)-1)/(unit)+1)
#define EZ(v,unit) ((v)?ENOUGH(v,unit):0)
#define XFER_MODE 0xf0
#define XFER_UDMA_100 0x44
#define XFER_UDMA_660x42
#define XFER_UDMA 0x40
#define XFER_MWDMA 0x20
#define XFER_SWDMA 0x10
#define XFER_EPIO 0x01
#define XFER_PIO0x00
static short ide_find_best_mode(ide_drive_t *drive, int map)
{
struct hd_driveid *id = drive->id;
short best = 0;
if (!id)
return XFER_PIO_SLOW;
if ((map & XFER_UDMA) && (id->field_valid &
Re: [patch] VIA 4.2x driver for 2.2 kernels (fwd)
On Thu, Feb 22, 2001 at 12:20:55PM -0300, Rogerio Brito wrote: > This message was apparently intended to be sent to the list. > > > []s, Roger... > > - Forwarded message from Pozsar Balazs <[EMAIL PROTECTED]> - > > From: Pozsar Balazs <[EMAIL PROTECTED]> > To: Rogerio Brito <[EMAIL PROTECTED]> > Subject: Re: [patch] VIA 4.2x driver for 2.2 kernels > Date: Thu, 22 Feb 2001 01:04:27 +0100 (MET) > Message-ID: > > > The kernel doesn't seem to set 32bit io transfers by default. Is it > dangerous or unrecommended to set it with hdparm? It does: via82cxxx.c, line 536: hwif->drives[i].io_32bit = 1; Actually this seems to be required for correct operation in PIO modes. Anyway, it doesn't have an effect if DMA/UDMA modes are used - BusMastering is always 32bit. -- Vojtech Pavlik SuSE Labs - 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/
Re: DMA blues...System lockup on setting DMA mode using hdparam
On Fri, Feb 23, 2001 at 12:48:29PM -0800, Jasmeet Sidhu wrote: > Also, when I try and use the -k and the -K switches (keep settings after > reset), the programs says that it worked. However, after I restart the > system, these "flags" are set to 0 again. Is this normal? In other words: > hdparam -k /dev/hda > keepsettings = 0 (off) > # now lets set the -k option (keep settings after refresh). > hdparam -k1 /dev/hda > setting keep_settings to 1 (on) > keepsettings = 1 (on) > # noe lets restart the system and query again > hdparam -k /dev/hda > keepsettings = 0 (off) > > Is this normal? This only relates to a ide bus reset in case of a failure, not system reset. -- Vojtech Pavlik SuSE Labs - 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/
Re: ide / usb problem
On Mon, Feb 26, 2001 at 03:23:18PM -0500, Mark Hahn wrote: > > the cable length in mind. Anybody out there know if there's a max cable > > length for the ATA/100 spec?? > > 18", like *all* ide/ata cables. Actually the ATA/66 and ATA/100 cables are specified to be exactly 18", not longer, not shorter. -- Vojtech Pavlik SuSE Labs - 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/
Re: VT82C586B USB PCI card, Linux USB
On Sat, Mar 03, 2001 at 12:13:49AM -0500, Michael Rothwell wrote: > I have a USB PCI card, which shows up as this in `lspci`: > > 00:09.0 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 04) > > ... it appears that they tossed the whole southbridge chip onto a pci > board, and disabled everything but USB. No, they have a separate USB chip, but it has the same PCI ID as the builtin silicon in the southbridge. -- Vojtech Pavlik SuSE Labs - 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/
Re: Linux 2.4.2ac12
On Mon, Mar 05, 2001 at 04:37:00PM -0500, David Riley wrote: > Alan Cox wrote: > > 2.4.2-ac12 > > o Update VIA IDE driver to 3.21 (Vojtech Pavlik) > > |No UDMA66 on 82c686 > > Um... Does that include 686a? 82c686a is supposed to handle UDMA66... > Or is it a corruption issue again? UDMA66 seems to work fine on > mine... No corruptions yet. No, just the vt82c686. vt82c686a and vt82c686b are OK. -- Vojtech Pavlik SuSE Labs - 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/
Re: 2.4.2-ac12 unknown southbridge
On Tue, Mar 06, 2001 at 10:09:05AM +0100, Mike Galbraith wrote:
> The driver forget what it always called a vt82c596b before. Reverting
> the below brought it back on-line, and all seems well again. (hope I
> don't receive any unpleasant suprises.. I've not the foggiest clue what
> that number means;)
>
> - { "vt82c596b", PCI_DEVICE_ID_VIA_82C596, 0x12, 0x2f, VIA_UDMA_66 },
> + { "vt82c596b", PCI_DEVICE_ID_VIA_82C596, 0x10, 0x2f, VIA_UDMA_66 },
Can you verify it's a 596b and not 596a? Preferably by looking on the
chip? This change was brought in because I wasn't sure for the 10 and 11
revisions. 586a doesn't have a functional UDMA66 engine and causes
crashes if programmed to UDMA66.
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 11)
It's the revision number - 11 in your case.
--
Vojtech Pavlik
SuSE Labs
-
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/
Re: 2.4.2-ac12 unknown southbridge
On Tue, Mar 06, 2001 at 10:29:00AM +0100, Mike Galbraith wrote:
> On Tue, 6 Mar 2001, Vojtech Pavlik wrote:
>
> > On Tue, Mar 06, 2001 at 10:09:05AM +0100, Mike Galbraith wrote:
> >
> > > The driver forget what it always called a vt82c596b before. Reverting
> > > the below brought it back on-line, and all seems well again. (hope I
> > > don't receive any unpleasant suprises.. I've not the foggiest clue what
> > > that number means;)
> > >
> > > - { "vt82c596b", PCI_DEVICE_ID_VIA_82C596, 0x12, 0x2f, VIA_UDMA_66 },
> > > + { "vt82c596b", PCI_DEVICE_ID_VIA_82C596, 0x10, 0x2f, VIA_UDMA_66 },
> >
> > Can you verify it's a 596b and not 596a? Preferably by looking on the
> > chip? This change was brought in because I wasn't sure for the 10 and 11
> > revisions. 586a doesn't have a functional UDMA66 engine and causes
> > crashes if programmed to UDMA66.
>
> *blur* SQUINT (I _definitely_ need new glasses) it's a 596b.
>
> Probably dumb question wrt hdparm -i output...
>
> /dev/hda:
>
> Model=IBM-DJNA-352030, FwRev=J58OA30K, SerialNo=GQ0GQFP8740
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
> BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=off
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=39876480
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
>
> Why is it defaulting to udma4, and :) why the heck does it work?
Thanks. That means your change is correct. I'll send an update to Alan.
--
Vojtech Pavlik
SuSE Labs
-
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/
[preview] VIA IDE driver v3.11 with vt82c686b UDMA100 support
Hi!
For all of you who had problems getting the VIA IDE driver to work
correctly on the 686b, here is a driver that should work with those
chips, even in UDMA 100 mode. I've not tested it, because I don't have
the 686b myself. So it may eat your filesystem as well.
Good luck!
--
Vojtech Pavlik
SuSE Labs
#ifndef _IDE_TIMING_H
#define _IDE_TIMING_H
/*
* $Id: ide-timing.h,v 1.4 2000/10/02 20:48:56 vojtech Exp $
*
* Copyright (c) 1999-2000 Vojtech Pavlik
*
* Sponsored by SuSE
*/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Should you need to contact me, the author, you can do so either by
* e-mail - mail your message to <[EMAIL PROTECTED]>, or by paper mail:
* Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
*/
#include
#ifndef XFER_PIO_5
#define XFER_PIO_5 0x0d
#endif
struct ide_timing {
short mode;
short setup;/* t1 */
short act8b;/* t2 for 8-bit io */
short rec8b;/* t2i for 8-bit io */
short cyc8b;/* t0 for 8-bit io */
short active; /* t2 or tD */
short recover; /* t2i or tK */
short cycle;/* t0 */
short udma; /* t2CYCTYP/2 */
};
/*
* PIO 0-5, MWDMA 0-2 and UDMA 0-5 timings (in nanoseconds).
* These were taken from ATA/ATAPI-6 standard, rev 0a, except
* for PIO 5, which is a nonstandard extension.
*/
static struct ide_timing ide_timing[] = {
{ XFER_UDMA_5, 0, 0, 0, 0, 0, 0, 0, 20 },
{ XFER_UDMA_4, 0, 0, 0, 0, 0, 0, 0, 30 },
{ XFER_UDMA_3, 0, 0, 0, 0, 0, 0, 0, 45 },
{ XFER_UDMA_2, 0, 0, 0, 0, 0, 0, 0, 60 },
{ XFER_UDMA_1, 0, 0, 0, 0, 0, 0, 0, 80 },
{ XFER_UDMA_0, 0, 0, 0, 0, 0, 0, 0, 120 },
{ XFER_MW_DMA_2, 25, 0, 0, 0, 70, 25, 120, 0 },
{ XFER_MW_DMA_1, 45, 0, 0, 0, 80, 50, 150, 0 },
{ XFER_MW_DMA_0, 60, 0, 0, 0, 215, 215, 480, 0 },
{ XFER_SW_DMA_2, 60, 0, 0, 0, 120, 120, 240, 0 },
{ XFER_SW_DMA_1, 90, 0, 0, 0, 240, 240, 480, 0 },
{ XFER_SW_DMA_0, 120, 0, 0, 0, 480, 480, 960, 0 },
{ XFER_PIO_5, 20, 50, 30, 100, 50, 30, 100, 0 },
{ XFER_PIO_4, 25, 70, 25, 120, 70, 25, 120, 0 },
{ XFER_PIO_3, 30, 80, 70, 180, 80, 70, 180, 0 },
{ XFER_PIO_2, 30, 290, 40, 330, 100, 90, 240, 0 },
{ XFER_PIO_1, 50, 290, 93, 383, 125, 100, 383, 0 },
{ XFER_PIO_0, 70, 290, 240, 600, 165, 150, 600, 0 },
{ XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 960, 0 },
{ -1 }
};
#define IDE_TIMING_SETUP0x01
#define IDE_TIMING_ACT8B0x02
#define IDE_TIMING_REC8B0x04
#define IDE_TIMING_CYC8B0x08
#define IDE_TIMING_8BIT 0x0e
#define IDE_TIMING_ACTIVE 0x10
#define IDE_TIMING_RECOVER 0x20
#define IDE_TIMING_CYCLE0x40
#define IDE_TIMING_UDMA 0x80
#define IDE_TIMING_ALL 0xff
#define MIN(a,b)((a)<(b)?(a):(b))
#define MAX(a,b)((a)>(b)?(a):(b))
#define FIT(v,min,max) MAX(MIN(v,max),min)
#define ENOUGH(v,unit) (((v)-1)/(unit)+1)
#define EZ(v,unit) ((v)?ENOUGH(v,unit):0)
#define XFER_MODE 0xf0
#define XFER_UDMA_100 0x44
#define XFER_UDMA_660x42
#define XFER_UDMA 0x40
#define XFER_MWDMA 0x20
#define XFER_SWDMA 0x10
#define XFER_EPIO 0x01
#define XFER_PIO0x00
static short ide_find_best_mode(ide_drive_t *drive, int map)
{
struct hd_driveid *id = drive->id;
short best = 0;
if (!id)
return XFER_PIO_SLOW;
if ((map & XFER_UDMA) && (id->field_valid & 4)) { /* Want UDMA and UDMA
bitmap valid */
if ((map & XFER_UDMA_100) == XFER_UDMA_100)
if ((best = (id->dma_ultra & 0x0020) ? XFER_UDMA_5 : 0))
return best;
if ((map & XFER_UDMA_66) == XFER_UDMA_66)
if ((best = (id->dma_ultra & 0x0010) ? XFER_UDMA_4 :
(id->dma_
Re: USB Keyboards for x86/uhci in 2.4- kernels?
On Tue, Jan 09, 2001 at 11:55:14PM -0700, Benson Chow wrote: > Anyone tried using these beasts on a x86? > > Anyway, what's happening: In BIOS my USB keyboard works really poorly - > it almost seems scancodes get dropped left and right. Ok, so I don't mind > too much, i'm sure BIOS has a very limited driver. After booting > Microsoft's offerring, it would work fine after it installs its driver. > I also tried this same keyboard on a HPUX Visualize C3600 workstation and > it also works nicely. > > However linux would never fix this "scancode drop" syndrome even after > loading the hid or usbkbd driver. Both my Via uhci USB motherboard and > PIIX3 USB motherboard exhibit this usb keyboard strangeness > with the hid or usbkbd driver is installed. I think the PIIX3 > motherboard's bios doesnt handle USB properly so it doesn't even work in > BIOS setup. Any idea what's going on? Is there some other driver or > utility I need to install/run to get it working? Maybe just my bad bios? > > BTW: my USB Mouse, and USB Printer seem to work nicely in 2.4.0-release. > > USB KBD: NMB USB 104-key PC-Style > USB Mouse: Microsoft Intellimouse w/Intellieye 1.0, Logitech Optical Wheel > USB Printer: HP Deskjet 880C > USB Hub: Belkin 4-port > Intel 82437SB(?) PIIX3 and Via 82C686(?) USB controller > > Working: Stock HPUX10.2 HP Visualize C3600 PARISC2 Workstation > Working: Microsoft Windows 98 First Edition on the Via. What modules are loaded? What's in /proc/bus/usb/devices? What's in dmesg? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA problems on 2.4.0 with vt82c686a driver
Hi!
I'm the current maintainer of the VIA driver. I'm pretty sure the
version in 2.4.0 programs the chips correctly for harddrives at various
speeds, even leaving some margins where it shouldn't need to.
I think there is not any problem with Western Digital drives, I've got
many reports of them working OK with different chipsets, including those
made by VIA.
However, I'm getting many many problem reports on Abit KT7's. It might
be that this is a very popular board, but nevertheless, I think at least
its earlier revisions had trouble with UDMA transfers.
At least on one of these boards a drive did work correctly, without CRC
errors on the secondary interface, and gave constant errors on the
primary. All other known problem causes were eliminated.
I think it's Abit this time who's to blame.
-
Anyway, you can try disabling VIA support in kernel, and if BIOS sets up
things correctly, you should be able to use UDMA as well. If it works
then, it would mean that my driver is a problem. I'd like to hear in
either case.
Vojtech
On Thu, Jan 11, 2001 at 09:38:26AM -0500, dep wrote:
> On Thursday 11 January 2001 08:33 am, James Brents wrote:
>
> | Since this looks like either a chipset, drive, or driver problem, I
> | am submitting this.
> | I have recently started using DMA mode on my harddisk. However, I
> | occasionally (not often/constant, but sometimes) get CRC errors:
> | hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> | hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> welcome to the club. if you are given an answer off-list to this, i'd
> love a copy, because i've had the same issue for six months now. some
> have said that it's crosstalk in the cable -- in which case, all
> three of the 80-conductor cables i've tried are insufficiently
> shielded and we're in need of premium 80-conductor cables. and i
> found this in the november 200 linux journal, page 82, last
> paragraph, in an article on the ultimate linux box written by don
> marti:
>
> "earlier this year, kernel hacker andre hedrick, the maintainer of
> linux's ide driver, tracked a user's problem to the fact that western
> digital drives don't do error checking correctly. he posted to
> linux-kernel, 'wdc drives blow off the crc check of udma . . . . this
> is bad and stupid.' western digital fired back on their web site
> with, 'if there's a problem using these drives in linux the problem
> most likely lies with the software driver and not the hard drive
> itself.' i'm going to believe the kernel hacker over the hardware
> vendor and stay away from western digital drives for awhile."
>
> this suggests a.) that we need to gently pressure the w.d. people to
> come up with a fix or provide the specs necessary to fashion one --
> the latter being preferable -- and b.) that we need to figure out
> some sort of hack that does -- what? in my experience, these error
> messages actually signify nothing, but they're using up cycles. can
> they be safely supressed? beats me. but they sold a hell of a lot of
> these things.
>
> though i've noticed that the problem seems to be limited to those of
> us who have via chipset motherboards, suggesting that it is limited
> to that chipset, that chipset is ubiquitous, or via chipset
> motherboard owners are generally the complaining type. no idea which
> applies there, either.
>
> --
> dep
> --
> bipartisanship: an illogical construct not unlike the idea that
> if half the people like red and half the people like blue, the
> country's favorite color is purple.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA problems on 2.4.0 with vt82c686a driver
On Thu, Jan 11, 2001 at 09:41:55AM -0500, Mark Hahn wrote:
> > Since this looks like either a chipset, drive, or driver problem, I am
>
> no: the only entities involved with udma crc's are the drive,
> the controller (and the cable). the kernel is not involved in any way
> (except to configure udma, of course.)
Well, that's the part where it is really easy to cause crc errors. But I
believe I got that right in the driver. Tested successfully on many VIA
chipsets.
> > occasionally (not often/constant, but sometimes) get CRC errors:
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> nothing wrong here. occasional crc retries cause no performance impact.
Also it should be noted that they don't cause any corruption (*). The worst
thing they can do is disabling DMA if they happen many times in a short
period of time.
(*) - UDMA modes only. CRC errors are a big problem in PIO and
MWDMA/SWDMA modes.
> > After reading some archives in linux-kernel, I tried changing some
> > options. Then I changed out the 40 pin, 80 wire cable with a new one.
>
> great, since without the 80c cable, udma > 33 is illegal.
... note that he says 40pin, 80wire. That's the correct UDMA66 cable, it
has just 40 pins.
> is it safe to assume your cable is also 18" or less, with both ends
> plugged in (no stub)? you might be able to minimize CRC retries
> by changing where the cable runs. it's also conceivable that CRC
> errors would be caused by marginal power, bad trace layout on the
> motherboard,
Bad trace on the motherboard is what I suspect on KT7's. It could be
designed a little longer or shorter than the others and a marginal clock
skew can cause the crc errors. Or the trace can lead too close to some
source of e/m noise.
> and definitely by overclocking (PCI other than 33 MHz).
>
> > My main concern that I havnt beem able to find an answer for on any
> > archives or documentation, Can this cause file system corruption in any way?
>
> abosolutely not. udma checksums each transfer. when checksums don't match,
> the *hardware* retries the transfer (and incidentally reports the event,
> which Linux obligingly passes on to you.)
The software retries the transfer, the hardware just aborts. But it's
safe, anyways.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: AMD760/765 DDR Athlon testers needed....
Hi!
Hmm, seems like I've got that one covered a while ago already ...
though I must admit my code isn't tested yet.
Vojtech
On Thu, Jan 11, 2001 at 09:46:41AM -0800, Andre Hedrick wrote:
>
> Calling AMD Geeks^H^H^H^H^HUsers,
>
> I have one of these DDR boxes from AMD with the AMD760/765 cores, if you
> have one please let me know if you wnat to test this new code?
> It is only ATA66 limited and the DOCS I have do not have the ATA100
> timings.
>
> Cheers,
>
> Andre Hedrick
> Linux ATA Development
> Inspecting /boot/System.map
> Symbol table has incorrect version number.
>
> <6>Uniform Multi-Platform E-IDE driver Revision: 6.30
> <4>ide: Assuming 33MHz system bus speed for PIO modes
> <4>AMD7411: IDE controller on PCI bus 00 dev 39
> <4>AMD7411: chipset revision 1
> <4>AMD7411: not 100% native mode: will probe irqs later
> <4>ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> <4>ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
> <4>PDC20267: IDE controller on PCI bus 00 dev 58
> <4>PDC20267: chipset revision 2
> <4>PDC20267: not 100% native mode: will probe irqs later
> <4>PDC20267: ROM enabled at 0xe700
> <4>PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
> <4>ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pio
> <4>ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, hdh:pio
> <4>hda: QUANTUM FIREBALL CX13.0A, ATA DISK drive
> <4>hdb: QUANTUM FIREBALL CR4.3A, ATA DISK drive
> <4>hdc: ATAPI CD ROM DRIVE 50X MAX, ATAPI CDROM drive
> <4>hdd: HITACHI DVD-RAM GF-2000, ATAPI CDROM drive
> <4>ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> <4>ide1 at 0x170-0x177,0x376 on irq 15
> <4>hda: TF.1=x00 TF.2=x00 TF.3=x00 TF.4=x00 TF.5=x00 TF.6=x40 TF.7=xf8
> <6>hda: QUANTUM FIREBALL CX13.0A, 12416MB w/418kB Cache, CHS=25228/16/63, UDMA(33)
> <4>hdb: TF.1=x00 TF.2=x00 TF.3=x00 TF.4=x00 TF.5=x00 TF.6=x40 TF.7=xf8
> <6>hdb: QUANTUM FIREBALL CR4.3A, 4110MB w/418kB Cache, CHS=14848/9/63, UDMA(66)
> <4>hdc: ATAPI 50X CD-ROM drive, 128kB Cache, UDMA(33)
> <6>Uniform CD-ROM driver Revision: 3.11
> <4>hdd: ATAPI DVD-ROM DVD-R drive, 512kB Cache, UDMA(33)
--
Vojtech Pavlik
SuSE Labs
/*
* $Id: amd7409.c,v 1.4 2000/09/19 08:33:60 vojtech Exp $
*
* Copyright (c) 2000 Vojtech Pavlik
*
* Based on the work of:
* Andre Hedrick
*
* Sponsored by SuSE
*/
/*
* AMD755/756 IDE driver for Linux.
*
* UDMA66 and higher modes are autodetected only in case the BIOS has enabled
* them. To force UDMA66, use 'ide0=ata66' or 'ide1=ata66' on the kernel
* command line. You may also need to configure the kernel IDE driver to ignore
* byte93 UDMA66 enable bits if your drives don't use them correctly.
*/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Should you need to contact me, the author, you can do so either by
* e-mail - mail your message to <[EMAIL PROTECTED]>, or by paper mail:
* Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include "ide-timing.h"
#define AMD_IDE_ENABLE 0x40
#define AMD_IDE_CONFIG 0x41
#define AMD_CABLE_DETECT0x42
#define AMD_DRIVE_TIMING0x48
#define AMD_8BIT_TIMING 0x4e
#define AMD_ADDRESS_SETUP 0x4c
#define AMD_UDMA_TIMING 0x50
#define AMD_UDMA0x07
#define AMD_UDMA_33 0x01
#define AMD_UDMA_66 0x02
#define AMD_UDMA_1000x04
#define AMD_NO_SWDMA0x08
#define AMD_CABLE 0x10
#ifndef PCI_DEVICE_ID_AMD_VIPPL_7411
#define PCI_DEVICE_ID_AMD_VIPPL_74110x7411
#endif
/*
* AMD SouthBridge chips.
*/
static struct amd_ide_chip {
char *name;
unsigned short id;
unsigned char rev;
unsigned char flags;
} amd_ide_chips[] = {
{ "766 ViperPlus", PCI_DEVICE_ID_AMD_VIPPL_7411, 0x00, AMD_UDMA_100 |
AMD_CABLE },
{ "756/c4+ Viper&quo
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 10:55:22AM -0800, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Andre Hedrick <[EMAIL PROTECTED]> wrote: > > > >Well that "experimental patch" is designed to get out of the dreaded > >"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the > >Intel 440*X Chipset groups. Since it appears that their bug was copied > >but other chipset makers..you see the picture clearly, right? > > No. > > That experimental patch is _experimental_, and has not been reported by > anybody to fix anything at all. Also, the DMA timeout on PIIX4 seems to > have nothing at all to do with the very silent corruption on VIA. At > least nobody has reported any error messages being produced on the VIA > corruption cases. > > In short, let's leave it out of a stable kernel for now, and add > blacklisting of auto-DMA. Alan has a list. We can play around with > trying to _fix_ DMA on the VIA chipsets in 2.5.x (and possibly backport > the thing once it has been sufficiently battletested that people believe > it truly will work). I've got a vt82c586 here (bought it just for testing of this problem), and I wasn't able to create any corruption using that board and the 2.4 drivers. Does anyone still have any vt82c586 or vt82c586a the 2.4 VIA driver is corrupting data on? I'd like to hear about such reports so that I can start debugging (and perhaps get me one of those failing boards, they must be quite cheap these days). -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 ate my filesystem on rw-mount
On Fri, Jan 12, 2001 at 10:15:45AM +0100, Tobias Ringstrom wrote: > I've never seen anything like it before, which I'm happy for. The system > had been running a standard RedHat 7 kernel for days without any problems, > but who wants to run a 2.2 kernel? I compiled 2.4.0 for it, rebooted, and > blam! The RedHat init stripts got to the "remounting root read-write" > point, and just froze solid. > > Rebooting into RH7 failed, becauce inittab could not be found. In fact > the filesystem was completely messed up, with /dev empty, lots of device > nodes in /etc, and files missing all over the place. I had to reinstall > RH7 from scratch. > > I do not understand how this could happen during a remounting root rw. > Is the filesystem really that unstable? > > Am I right in suspecting DMA, which was enabled at the time? Any other > ideas? Is it a known problem? > > This is on a 450 MHz AMD-K6 with the following IDE controller: > > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) > > [I know this is not a very good trouble report, but it will have to do for > the time beeing. I hope to do more testing at a later time.] > > /Tobias > > PS. This is _not_ the same system that I reported IDE busy errors for. Wow. Ok, I'm maintaining the 2.4.0 VIA driver, so I'd like to know more about this: 1) What's the ISA bridge revision? 2) What's in /proc/ide/via? 3) What says hdparm -i on your devices? 4) If you mount your filesystem read-only, does it read garbage? Thanks. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 ate my filesystem on rw-mount
On Fri, Jan 12, 2001 at 12:23:21PM -0500, Martin Laberge wrote: > > > This is on a 450 MHz AMD-K6 with the following IDE controller: > > > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) > > > > There are several people who have reported that the 2.4.0 VIA IDE driver > > trashes hard disks like that. The 2.2 one also did this sometimes but only > > with specific chipset versions and if you have dma autotune on (thats why > > currently 2.2 refuses to do tuning on VP3) > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > I had exactly the same problem with my K6-350 and IDE VT82C586a > on a kernet 2.2.16. i just made a hdparm to enable DMA and poo > lost all data reinstall necessary from scratch Is this problem still present with 2.4.0? Well, you don't need to kill your data to test this - make sure the kernel is mounting the filesystems read only in the test. DMA will be probably enabled automatically for your drives. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:57:37AM -0800, Linus Torvalds wrote: > > I've got a vt82c586 here (bought it just for testing of this problem), > > and I wasn't able to create any corruption using that board and the 2.4 > > drivers. > > The fact that it works on one board doesn't mean that it works on _every_ > board. Of course. That's why I'm calling for bug reports. > This is, in fact, why I will _NOT_ accept anything but a simple auto-dma > disable for this problem for early 2.4.x. I hope that people will continue > to work on and debug this problem, but it's just been around for too long, > and it's obvious enough that it doesn't happen with all hardware that I > doubt there is any other reasonable solution that doesn't require some > _very_ extensive testing to verify. > > I'd love to see people who see these problems and are willing to test out > patches to fix it. But in parallel with that, I definitely want the 2.2.x > "disable auto-DMA" thing for the big public. We can enable it later if > some patch does seem to fix it for good. Sure. However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. That's because all VIA chipsets starting from vt82c586 to vt82c686b (UDMA100), share the same PCI ID. Would you prefer to filter just vt82c586 and vt82c586a as the comment in Alan's code says or simply unconditionally kill autodma on all of VIA chipsets, as Alan's code does? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
00 00 00 00 00 > | 40: 00 05 00 00 01 00 10 a0 21 00 c4 00 00 00 00 f3 > | 50: 24 00 00 00 00 00 a0 90 00 06 f7 00 10 00 00 00 > | 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | > | 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) >(prog-if 8a) > | Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > | Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- | Latency: 64 set > | Region 4: I/O ports at e000 > | 00: 06 11 71 05 07 00 80 02 06 8a 01 01 00 40 00 00 > | 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 20: 01 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 40: 0b f2 09 3a 69 00 f0 00 a8 a8 a8 a8 ff 00 ff ff > | 50: 03 03 03 03 00 00 00 00 a8 a8 a8 a8 00 00 00 00 > | 60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00 > | 70: 22 00 00 00 00 00 00 00 42 00 00 00 00 00 00 00 > | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00 > | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | > | 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02) > | Subsystem: Unknown device 0925:1234 > | Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > | Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- | Latency: 64 set, cache line size 08 > | Interrupt: pin D routed to IRQ 9 > | Region 4: I/O ports at e400 > | 00: 06 11 38 30 07 00 00 02 02 00 03 0c 08 40 00 00 > | 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 20: 01 e4 00 00 00 00 00 00 00 00 00 00 25 09 34 12 > | 30: 00 00 00 00 00 00 00 00 00 00 00 00 09 04 00 00 > | 40: 00 00 00 00 c6 00 11 18 00 00 00 00 00 00 00 00 > | 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | > | 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) > | Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- >SERR- FastB2B- > | Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- | 00: 06 11 40 30 00 00 80 02 10 00 80 06 00 00 00 00 > | 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 40: 40 88 09 00 78 38 00 00 01 60 00 00 00 00 00 00 > | 50: 00 7c ee 88 00 00 00 00 00 00 00 00 00 00 00 00 > | 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > | f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 04:52:00PM -0800, Linus Torvalds wrote: > > > On Fri, 12 Jan 2001, John Heil wrote: > > > On Sat, 13 Jan 2001, Alan Cox wrote: > > > > > Date: Sat, 13 Jan 2001 00:25:28 + (GMT) > > > From: Alan Cox <[EMAIL PROTECTED]> > > > To: Linus Torvalds <[EMAIL PROTECTED]> > > > Cc: Vojtech Pavlik <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > > Subject: Re: ide.2.4.1-p3.01112001.patch > > > > > > > what the bug is, and whether there is some other work-around, and whether > > > > it is 100% certain that it is just those two controllers (maybe the other > > > > ones are buggy too, but the 2.2.x tests basically cured their symptoms too > > > > and peopl ehaven't reported them because they are "fixed"). > > > > > > I've not seen reports on the later chips. If they had been buggy and then > > > fixed I'd have expected much unhappy ranting before the change > > > > The "fix" was an hdparm command like hdparm -X66 -m16c1d1 /dev/hda. > > Which I set for my VIA 686a on a Tyan mobo w a 1G Athlon. > > Careful. It may be that your fix just avoids the corruption because the > other changes make it ok - like the 16-sector multi-count thing maybe > hides a problem that might still exist - it just changes the "normal" > timing so that you won't ever see it in practice any more. > > These kinds of magic interactions is why I'm not at all happy about driver > changes until people really know what it was that caused it, and _know_ > that it's gone. > > Anyway, for you the problem apparently happened even on a 686a, but just > the 586 series. Correct? Yes, but this is a different problem. No corruption was happening here. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:47:41PM +, Alan Cox wrote: > > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets. > > That's because all VIA chipsets starting from vt82c586 to vt82c686b > > (UDMA100), share the same PCI ID. > > I have no reports of problems with the later stuff At least the one you sent to me is about 586b. Which is the later stuff. > > Would you prefer to filter just vt82c586 and vt82c586a as the comment in > > Alan's code says or simply unconditionally kill autodma on all of VIA > > chipsets, as Alan's code does? > > I'd take a 2.2 patch to cut down the range too I can make one for you, but first I'd like to find out what exactly are the problem cases. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 11:43:23PM +, Alan Cox wrote: > > I'd like to hear about such reports so that I can start debugging (and > > perhaps get me one of those failing boards, they must be quite cheap > > these days). > > This is one of the most precise reports I have > > |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The > |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is > |1.2 GB. Hdd is an IDE CDROM drive > > I think its significant that two reports I have are FIC PA-2013 but not all. > What combination of chips is on the 2013 ? As far as I know the same as on FIC VA-503+, that is vt82c598 north and vt82c586b south - the MVP3 chipset. I've got the VA-503+ here and it works really well. the 503+ and the 2013 differ only in form factor, one is Baby AT (503+) and the other is ATX. It's vt82c586b, and most probably 3041 silicon - the most bugless VIA southbridge I know of ... Weird. Could the person who reported it test the 2.4.0 kernel? I think the 2.2 drivers had some MVP3 (and 3041 silicon) related bugs. 3041 has some registers layed out differently from all other chips. Btw, this is not the 586 nor 586a, so changing the test to test for just these two probably won't be the right thing to do ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, Jan 13, 2001 at 02:43:30AM +, [EMAIL PROTECTED] wrote: > > |The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The > > |size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is > > |1.2 GB. Hdd is an IDE CDROM drive > > > > I think its significant that two reports I have are FIC PA-2013 but not all. > > What combination of chips is on the 2013 ? > > The FIC PA-2013 is one of the stranger types of MVP3. > (A mixture of 82c597 host bridge and 82c598 PCI bridge). 598 + 586b > As discussed some time ago on this list, there are some of these > boards, which initially seem to be an MVP3, but have the host bridge ID > set to an VP3. (Real reasoning behind this never figured out). Windows driver compatibility, so that VP3 drivers would work on MVP3 as well. > 2.4 has code in the pci quirks to disable the register which makes > the chip masquerade as a VP3, and forces it to identify itself as > an MVP3 part. I'm curious whether this has an interaction here. This doesn't do anything but change the ID so that Linux drivers are not confused anymore. This caused a lot of trouble in 2.2, especially with the old VIA IDE driver. > I have a list of known 'hybrid' boards, and known true (both halves) MVP3 > boards and also a collection of lspci -xxx outputs from a selection of > them. If anyone wants any of this stuff, shout and I'll put it up > for ftp/www. Actually, the definitions of what's a 'true VIA xxx chipset' change over time, as VIA upgrades the southbridges in the specs. You'll now fing that the VPX chipset is 587vpx + 586b, but when released the 587vpx was coupled with the old 586 south. Fortunately all these chips use PIIX-compatible extensions to the PCI bus, so they are all interchangeable to some degree. > I'm curious if all of the other boards in Alans bug reports also > fall into the stranger category. It's possible. I have a board (VA-503A), which has a masqueraded 598, which identifies itself as 597, and a 686a southbridge. This got the 2.2 ide driver completely confused, for example. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Fri, Jan 12, 2001 at 04:09:22PM -0800, Linus Torvalds wrote:
> On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
> >
> > However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
> > That's because all VIA chipsets starting from vt82c586 to vt82c686b
> > (UDMA100), share the same PCI ID.
> >
> > Would you prefer to filter just vt82c586 and vt82c586a as the comment in
> > Alan's code says or simply unconditionally kill autodma on all of VIA
> > chipsets, as Alan's code does?
>
> Right now, for 2.4.1, I'd rather have the patch to just do the same as
> 2.2.x. We can figure it out better when we get a better idea of exactly
> what the bug is, and whether there is some other work-around, and whether
> it is 100% certain that it is just those two controllers (maybe the other
> ones are buggy too, but the 2.2.x tests basically cured their symptoms too
> and peopl ehaven't reported them because they are "fixed").
>
> Linus
Ok, here goes the patch.
Note that with this patch, all VIA users will get IDE transferrates
about 3 MB/sec as opposed to about 20 MB/sec without it (and with
UDMA66).
This patch disables automatic DMA on all VIA chipsets, including the
ancient 82c561 for 486's, and up to the 686a UDMA66 chipset.
Also note that enabling the DMA later with hdparm -X66 -d1 or similar
command is not safe, and usually works by pure luck on VIA chipsets.
This however, would need some non-minor changes to the generic code to
fix.
But perhaps it's still worth ...
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-old/drivers/ide/ide-pci.c linux/drivers/ide/ide-pci.c
--- linux-old/drivers/ide/ide-pci.c Wed Jan 3 01:58:45 2001
+++ linux/drivers/ide/ide-pci.c Sat Jan 13 14:54:53 2001
@@ -663,7 +663,9 @@
if (IDE_PCI_DEVID_EQ(d->devid, DEVID_SIS5513) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_AEC6260) ||
IDE_PCI_DEVID_EQ(d->devid, DEVID_PIIX4NX) ||
- IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X))
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT34X) ||
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_VIA_IDE) ||
+ IDE_PCI_DEVID_EQ(d->devid, DEVID_VP_IDE))
autodma = 0;
if (autodma)
hwif->autodma = 1;
diff -urN linux-old/drivers/ide/via82cxxx.c linux/drivers/ide/via82cxxx.c
--- linux-old/drivers/ide/via82cxxx.c Tue Nov 7 20:02:24 2000
+++ linux/drivers/ide/via82cxxx.c Sat Jan 13 14:52:26 2001
@@ -602,7 +602,6 @@
#ifdef CONFIG_BLK_DEV_IDEDMA
if (hwif->dma_base) {
hwif->dmaproc = &via82cxxx_dmaproc;
- hwif->autodma = 1;
}
#endif /* CONFIG_BLK_DEV_IDEDMA */
}
Re: 2.4 ate my filesystem on rw-mount
On Sat, Jan 13, 2001 at 09:12:27AM +0100, Tobias Ringstrom wrote:
> > Wow. Ok, I'm maintaining the 2.4.0 VIA driver, so I'd like to know more
> > about this:
> >
> > 1) What's the ISA bridge revision?
>
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8501 (rev 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8501
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 1b)
> 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
> 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 0e)
> 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 20)
> 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super
>AC97/Audio] (rev 21)
> 00:0a.0 Ethernet controller: VIA Technologies, Inc. VT86C100A [Rhine 10/100] (rev 06)
> 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i7 (rev 5b)
Ok, your IDE chip is a vt82c686a/ce.
> > 2) What's in /proc/ide/via?
>
> It's not there since I disabled the VIA driver.
Ok. Could you send me this file when you boot with fs r-o?
> > 3) What says hdparm -i on your devices?
>
> /dev/hda:
>
> Model=SAMSUNG VG34323A (4.32GB), FwRev=GQ200, SerialNo=dW1921060033c8
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=14896/9/63, TrkSize=32256, SectSize=512, ECCbytes=21
> BuffType=DualPortCache, BuffSize=496kB, MaxMultSect=16, MultSect=off
> CurCHS=14896/9/63, CurSects=-531627904, LBA=yes, LBAsects=8446032
> IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: sdma0 sdma1 sdma2 *mdma0 mdma1 mdma2 udma0 udma1 *udma2
Looks good, too. An UDMA33 drive.
> > 4) If you mount your filesystem read-only, does it read garbage?
>
> Now here's a strange part, or possibly a crusial clue. When I booted a
> 2.4.0 kernel (from floppy using the excellent syslinux) with "ro
> init=/bin/sh", I could access the filesystem just fine. I could even
> remount the root filesystem rw, and there were no problems. But I did not
> write anything to the disk, since I was convinced that the problem was
> gone (this was the second try). After this I rebooted with
> ctrl-alt-delete, forgetting how bad an idea that is with init=/bin/sh,
> booted up the RH7 2.2.16 kernel, and fsck was run with no errors.
So far no problem. Rebooting with c-a-d with fs r-o is OK.
> Now I
> though all was well, rebooted from floppy again, but without the init=
> part, and poof, it hang.
Where? It could be a different reason than IDE setup ...
> More interesting may be that I had to turn the computer off and on again
> to get BIOS to find the hard drive. Repeated long reset button presses
> did not help. It is possible that it hung during BIOS hd detection - I
> wish I could remember.
I fear this isn't much of a clue, sorry.
> I suspect that I could have hung the drive with init=/bin/sh if I would
> have done some reading and writing to the device, besides ls.
Please try it. Best mke2fs your swap partition and try reading & writing
to that. You can mkswap it back after you finish.
> I think I can spend some more time today trying it out some more.
Please do. 'lspci -vvxxx' data for the case without a driver, with 2.4.0
driver and with 3.11 driver would help me find the problem.
Make sure you *don't* have any hdparm -d1 or hdparm -X66 or similar
stuff in your init scripts.
> I will
> also try your 3.11 driver, which seems to be an enormous cleanup.
the 2.1e driver is an enormous cleanup of the original driver from the
2.2 kernels. the 3.11 is an enormous cleanup of 2.1e, yes.
> Btw, do
> you have a home page for the VIA driver? A CVS perhaps? If not, please
> consider using sourceforge or something similar.
No, not yet, but working on that.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
VIA IDE corruption - anyone experiencing it with 2.4.0?
On Sat, Jan 13, 2001 at 06:03:11AM -0600, Thomas Molina wrote: > Are you looking for specific chipsets or configurations? Following is > my VP3/MVP3 chipset lspci output if you are gathering a group of > testers. I've enabled autoDMA at various points in the testing cycle > (not consistently) but haven't noticed any fs corruption. Ok. So what I'm exactly looking for: Cases of harddrive corruption (that is, trashing your fs, reading/writing bad data) on VIA chipsets. UDMA-caused CRC errors don't fall into this category, they're harmless to the data. Preferably with the driver from the 2.4.0 kernel. If possible, try also the VIA 3.11 driver posted to the list earlier. If you don't have it, I can e-mail it to you. Don't use any hdparm command in your init scripts (this is important) with the VIA driver and 2.4.0, setting the speed or dma usage with hdparm would interfere with the driver autotuning. If you fear to test, you can mount your fs readonly (no corruption can happen) and use your swap partition for read-write test. You can even mke2fs the swap for a while. Anyone who experienced this kind of problems with 2.4 and the VIA driver, please speak up, so I can fix it. I'm not currently looking for success reports, I've already got success reports for every type VIA IDE chip out there. I'll need the motherboard type and revision, lspci -vvxxx, dmesg, hdparm -i and /proc/ide/via listings ... Thanks. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
Hi!
This is not the case I'm looking for. You have a 686b, a chip that is
not supported in 2.4.0 yet. You can try the via 3.11 driver I posted a
while ago, it adds support for this chip, including UDMA100.
Thanks anyway,
Vojtech
On Sat, Jan 13, 2001 at 09:09:05AM -0800, Bryan O'Sullivan wrote:
> v> I can make one for you, but first I'd like to find out what exactly are
> v> the problem cases.
>
> I have a VT82C686 motherboard. It has one UDMA-100 slot and two
> regular IDE slots. I have an IBM DTTA-371440 (about 18 months old) as
> hda (only fat32 filesystems), and an IBM DTLA-307030 as hde
> (i.e. plugged into the UDMA-100 slot). I've never seen any problems
> with DMA on the newer drive, but if I turn on DMA and do anything with
> the older drive, I get stuff like this:
>
> /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 { DriveReady
>SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> The driver attempts to reset ide0 a few times, gets more of the above,
> then gives up with an I/O error.
>
> I've been seeing these problems as long as I've been tracking the 2.3
> series, up to and including 2.4.0. I can't boot a 2.2 kernel on this
> machine to compare, as it doesn't recognise hde (which is where Linux
> lives).
>
> Here's the output of lspci under 2.4.0, in case it's useful:
>
> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
> 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
> 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
> 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
> 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
> 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
> 00:09.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
> 00:09.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
> 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
> 00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08)
> 00:0b.1 Input device controller: Creative Labs SB Live! (rev 08)
> 00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device
>0d30 (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0150 (rev a3)
>
> If you need any more information, I can dig it out.
>
> http://www.tux.org/lkml/
Re: 2.4 ate my filesystem on rw-mount, getting closer
On Sat, Jan 13, 2001 at 11:36:13PM +0100, Tobias Ringstrom wrote:
> I have now tried the SAMSUNG VG34323A disk with two other controllers at
> home (Promise ATA100 an VIA vt82c686a rev 0x22, both on an ASUS A7V
> motherboard), and there are no problems to be found with DMA enabled.
> Streaming 10 MB/s without glitches.
So the drive *did* work on the vt82c686a in the A7V board? You tested it
both on the Promise and on the 686a? But doesn't work on the 686a in
your other board?
> However, writing to the SAMSUNG VG34323A disk with DMA enabled on either
> this machine [1] (at work, using the VIA IDE driver version 3.11)
>
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev 23)
> 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
>
> or this machine [2] (at work, using the VIA IDE driver version 2.1e)
>
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 1b)
> 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
What's the manufacturer/model of these boards? Just for record ...
What's the PCI bus speed? Or memory speed?
> I get exactly the following errors on both machines
>
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
>
> no matter what cable I use. When I get this, the machine does not recover
> most of the time, and I have to reset or power cycle.
It should be able to recover in a couple (up to 10) minutes ...
> This disc works
> flawlessly on two other IDE controllers, so I do not think that the disk
> is completely broken. It must be either these chipsets or the driver in
> combination with this disk. Note that I _can_ use another UDMA66 disk
> _with_ DMA enabled on both machine [1] and [2] above without problems.
> Also, 2.2.16-22 seems to work with DMA enabled on machine [1]. I have not
> tried 2.2.16-22 with DMA enabled on machine [2].
>
> The problem I reported at first, hence the nasty subject, was a hang and a
> nasty fs corruption when RH7 tried to remount the root fs read-write. I
> examined the RH7 init scripts, or more precisely /etc/rc.sysinit, and
> discovered, to my great disgust, that the stupid thing disables the dmesg
> output on the console very early in the script. It is thus entirely
> possible that I do get the above mentioned errors when the computer seems
> to hang, and my fs gets corrupted. I will fix the script tomorrow to see
> if my assumption is correct.
>
> SUMMARY: I have a disk that with DMA enabled give me CRC errors on two
> machines, but not on two other, independent on the cable. Both troubling
> machines do not recover from these errors. Linux 2.2.16-22 from RedHat
> works fine with DMA enabled on machine [1], [2] is unknown.
>
> I hope this makes things a lot clearer.
Yes, indeed it's much clearer now. Now to fix the bug, or at least be
able to track it closer, I'll need 'lspci -vvxxx' of the IDE pci device
in the following cases:
1) SAMSUNG VG34323A on VT82C596b/cf with RH 2.2.16-22 and DMA (working)
2) SAMSUNG VG34323A on VT82C686a/ce with RH 2.2.16-22 and DMA (working)
3) SAMSUNG VG34323A on VT82C596b/cf with 2.4.0+via3.11 and DMA,
(doesn't work, so fs readonly)
4) SAMSUNG VG34323A on VT82C686a/ce with 2.4.0+via3.11 and DMA,
(doesn't work, so fs readonly)
5) The other drive on VT82C596b/cf with 2.4.0+via3.11 and DMA (working)
6) The other drive on VT82C686a/ce with 2.4.0+via3.11 and DMA (working)
With these data I should be able to find out what's different between
the working and not working setups ...
My current theory: In UDMA, when reading, the drive provides the clock.
The IDE controller thus can read everything OK. When writing, the
controller provides the clock and for some reason the Samsung can't keep
up with the setting the driver selects for it. The question is why and
why the driver selects the incorrect (or just too tight?) value.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sun, Jan 14, 2001 at 12:40:58AM +0100, Andrzej Krzysztofowicz wrote: > > > 2.4 has code in the pci quirks to disable the register which makes > > > the chip masquerade as a VP3, and forces it to identify itself as > > > an MVP3 part. I'm curious whether this has an interaction here. > > > > This doesn't do anything but change the ID so that Linux drivers are not > > confused anymore. This caused a lot of trouble in 2.2, especially with > > the old VIA IDE driver. > [...] > > Fortunately all these chips use PIIX-compatible extensions to the PCI > > bus, so they are all interchangeable to some degree. > > > > > I'm curious if all of the other boards in Alans bug reports also > > > fall into the stranger category. > > > > It's possible. I have a board (VA-503A), which has a masqueraded 598, > > which identifies itself as 597, and a 686a southbridge. This got the > > 2.2 ide driver completely confused, for example. > > Maybe the VIA IDE chipset support option should depend on PCI quirks now ? No, in 2.4 the VIA IDE driver doesn't use this (northbridge) information anymore. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sat, Jan 13, 2001 at 08:41:00PM -0700, TimO wrote: > > Note that with this patch, all VIA users will get IDE transferrates > > about 3 MB/sec as opposed to about 20 MB/sec without it (and with > > UDMA66). > > > > Also note that enabling the DMA later with hdparm -X66 -d1 or similar > > command is not safe, and usually works by pure luck on VIA chipsets. > > This however, would need some non-minor changes to the generic code to > > fix. > > _ouch_ Will -X66 -d1c1m16 be as stable with this patch as version 2.1e > has been for me?? It has always (auto)set transfer speeds properly and > I have never seen corruption with my 686a -- 'cept when patching from > test11-pre7 to test12-pre1, and I'm pretty sure that was from other > factors. Well, can't tell. For some reason hdparm doesn't tell the VIA driver to update the timings in the chipset when changing modes. The fact that UDMA will start to work after this command is only due to that the VIA chips do have a built in filter for UDMA commands, notice the command sent to the harddrive, and switch the UDMA mode on. However the timings stay as were, as perhaps the BIOS set them up. So it may work or may not. As I said, getting it to work reliably needs changes in the generic code (hdparm should call the correct ioctl, and the ioctl must call the timing routine in the specific chipset code). If the patch I sent to Linus gets applied, I'll probably submit another one that will allow to override the no-dma rule by a kernel command line option, as Alan Cox suggested. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 ate my filesystem on rw-mount, getting closer
On Sun, Jan 14, 2001 at 09:45:09AM +0100, Tobias Ringstrom wrote: > On Sun, 14 Jan 2001, Vojtech Pavlik wrote: > > On Sat, Jan 13, 2001 at 11:36:13PM +0100, Tobias Ringstrom wrote: > > > > > I have now tried the SAMSUNG VG34323A disk with two other controllers at > > > home (Promise ATA100 an VIA vt82c686a rev 0x22, both on an ASUS A7V > > > motherboard), and there are no problems to be found with DMA enabled. > > > Streaming 10 MB/s without glitches. > > > > So the drive *did* work on the vt82c686a in the A7V board? You tested it > > both on the Promise and on the 686a? But doesn't work on the 686a in > > your other board? > > Yes, on both the Promise and on the 686a. But the device revisions are > different. The machine that does NOT work: > > 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 1b) > 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) > > The machine that works: > > 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) > 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) > > The one the works is a 1 GHz Athlon, and the other is an 800 MHz > Pentium-III. > > > > no matter what cable I use. When I get this, the machine does not recover > > > most of the time, and I have to reset or power cycle. > > > > It should be able to recover in a couple (up to 10) minutes ... > > Who waits 10 minutes for a timeout? Can it be lowered? It's not a 10 minute timeout, it's a shorter timeout retried many times. Not my code, though - this is generic PCI IDE code, and is a huge mess. > Expect another mail with the data you requested within a couple of hours. Thanks a lot. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 ate my filesystem on rw-mount, getting closer
On Sun, Jan 14, 2001 at 06:59:57PM +0100, Tobias Ringstrom wrote: > > I should also add that the 3.11 driver seems to make things better, but > not yet perfect. My intuition tells me that I get CRC errors much sooner > with 2.1e than with 3.11. > > Has the timings changed from 2.1e to 3.11, and would it be easy to modify > 3.11 to get extra safe/paranoid, but less high performance, timings? If you use 'idebus=40' or 'idebus=50', the driver will add an extra margin to the timings, trying to compensate for the 40 or 50 MHz PCI bus it will be tricked to think it's working with. This could add a data point, yes. > Some extra data: > * B seems to work in 2 with udma2 > * A seems to work in 2 with udma1, but not with udma2. UDMA1 is 22.2 MB/sec, UDMA2 is 33.3. UDMA0 is 16.6. Could you (if didn't already) send me the lspci -vvxxx after the -X65 (UDMA1) command, together with the one before? That also could tell something. > I wouldn't say it's rock solid, and I would not trust my data to any of > these combinations, but at least it not break immmediately (i.e. for less > than 1 GB written). Actually, the CRC messages are safe and only mean a data transfer is retried. That is, only if it doesn't fail every time. They happen on many boards and drives using UDMA even under normal correct operation :( > The worst combination is 2.4.0 with VIA 2.1e and A in 1. Going from 2.1e > to 3.11 helps, but it is still very bad. > > I'd really like to be more precise, but there are too many combinations to > try to try them all, and sometimes it fails right away, and sometimes > after several hundred megabytes. If 'fails after several hundred megabytes' only means a single CRC error which is recovered from correctly, then that actually means 'working and probably would work perfect with a shorter cable'. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ide.2.4.1-p3.01112001.patch
On Sun, Jan 14, 2001 at 08:38:23PM +0100, Jamie Lokier wrote: > > I think its significant that two reports I have are FIC PA-2013 but not all. > > What combination of chips is on the 2013 ? > > Reading through my mail logs, I know a board, either FIC PA-2011 or FIC > PA-2007 (I seem to have changed my mind somewhere in history) with a > 6.4G Quantum Fireball ST, 64MB RAM and an AMD K6-233. The chipset > reports as VIA VP2/97; sorry, I do not have access to get the PCI IDs. PA-2007 is indeed a VP2/97, a very nice board, with vt82c595+vt82c586b. > It locks up with DMA enabled, typically after a few hours, and has done > that since 2.1 kernel days. > > Unfortunately it locks up with Mandrake 7.2 which is not very old (based > on 2.2.17 kernels -- it's not my PC any more but I installed Mandrake on > it recently). > > Kernel option "ide=nodma" fixes this -- no lockups. > > After that "hdparm -X34 -d1" enables DMA and the board remains reliable. > I observed one lockup in several years, while X was starting so it could > have been X. -X34 does not change the results of "hdparm -t". > > Note that "hdparm -X34 -d1" enables old DMA, not UDMA. (The board was > advertised as UDMA capable but it isn't AFAIK). It should be able to do UDMA33. Is the board still available for some testing? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] VIA IDE driver v3.11 with vt82c686b UDMA100 support
Hi! The macro is defined as (in your symbols): (((t)-1)/(T)+1) The same macro is used both in 2.1e (2.4.0 driver) and in 3.11 (686b-capable driver). If you minimize the parentheses, you'll get: E = (t-1)/T + 1 Which gives the correct answer. We need E*T >= t. Vojtech On Wed, Jan 17, 2001 at 02:38:00PM -, Chandler, Alan wrote: > On Wed Jan 10 2001 - 06:45:24 EST Vojtech Pavlik <[EMAIL PROTECTED]> wrote > > >For all of you who had problems getting the VIA IDE driver to work > >correctly on the 686b, here is a driver that should work with those > >chips, even in UDMA 100 mode. I've not tested it, because I don't have > >the 686b myself. So it may eat your filesystem as well. > > Although not subscribed to the list (so please cc any comments to me at > [EMAIL PROTECTED]) , I have been tracking the various comments > with errors on VIA IDE drivers under 2.4.0 as I have been experiencing them > myself. > > I have been reading the code in vt82cxxx.c in the ide directory of the linux > source > to try and understand what was happening. One thing in the code has been > bugging me as > not right, and although the code attatched to the above message from Vojtech > seems to > sidestep the problem the underlying issue seems still to be there. > [Apologies I am > on a business trip to the US so I cannot access it directly] > > within the original code in 2.4.0 there is a table of timings for the > various transfer modes > (I assume they are in 10**-9 secs) - lets call any particular value t. > > There is then a piece of code that creates T = 1000/pci_bus_speed which I > assume is the time > of a bus-cycle in 10**-9 secs. > > There seems a calculation t/T to calculate the number of bus clocks needed > to meet the > timings above which will get loaded into the ide controller. There appears > to be a > macro called ENOUGH to do this and I am assuming it is called "ENOUGH" > because it tries to > be a little generous so that the timing is not tight. > > The calculation this macro does is (t-1)/(T+1) - AND THIS IS THE CRUX OF MY > POINT but this > seems to me to give a number TOO SMALL, not too large (as desired). > > I would like to change this (maybe to (t+1)/(T-1) to see if it fixes the > problem but > > a) I am not at home with access to a machine, and > b) If I am totally mistaken about this I might hose my disks > > It seemed more appropriate to seek the indulgence of this list to get > another opinions > as to whether I have misunderstood what the code is trying to do before > taking this step. > > I can be reached on [EMAIL PROTECTED] until approx 4:00pm EST 17th Jan or > [EMAIL PROTECTED] from Sat afternoon (UK time). > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: File System Corruption with 2.2.18
tion 0: > > Unknown mass storage controller: Promise Technology Unknown device > > (rev 1). > > Vendor id=105a. Device id=4d38. > > Medium devsel. IRQ 5. Master Capable. Latency=64. > > I/O at 0xb800 [0xb801]. > > I/O at 0xbc00 [0xbc01]. > > I/O at 0xc000 [0xc001]. > > I/O at 0xc400 [0xc401]. > > I/O at 0xc800 [0xc801]. > > Non-prefetchable 32 bit memory at 0xea00 [0xea00]. > > Bus 0, device 9, function 0: > > Unknown mass storage controller: Promise Technology Unknown device > > (rev 1). > > Vendor id=105a. Device id=4d38. > > Medium devsel. IRQ 10. Master Capable. Latency=64. > > I/O at 0xcc00 [0xcc01]. > > I/O at 0xd000 [0xd001]. > > I/O at 0xd400 [0xd401]. > > I/O at 0xd800 [0xd801]. > > I/O at 0xdc00 [0xdc01]. > > Non-prefetchable 32 bit memory at 0xea02 [0xea02]. > > Bus 0, device 10, function 0: > > Ethernet controller: 3Com 3C905B 100bTX (rev 36). > > Medium devsel. IRQ 11. Master Capable. Latency=64. Min > > Gnt=10.Max Lat=10. > > I/O at 0xe000 [0xe001]. > > Non-prefetchable 32 bit memory at 0xea04 [0xea04]. > > Bus 1, device 0, function 0: > > VGA compatible controller: NVidia/SGS Thomson Riva 128 (rev 16). > > Medium devsel. Fast back-to-back capable. IRQ 5. Master > > Capable. Latency=64. Min Gnt=3.Max Lat=1. > > Non-prefetchable 32 bit memory at 0xe400 [0xe400]. > > Prefetchable 32 bit memory at 0xe600 [0xe608]. > > > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > Andre Hedrick > Linux ATA Development -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: File System Corruption with 2.2.18
Hi!
Cute. Can it be run on say a swap partition?
Vojtech
On Wed, Jan 17, 2001 at 10:40:13AM -0800, Andre Hedrick wrote:
> I may have a new test tool but it is completely destructive the content on
> the drives. It walks the drives and fills every sector with a unique
> pattern and then you can read it back and checksum the contents.
>
> It does destroy the content on the drive, this is no worse than a random
> "File System Corruption " because it absolutely destroys or corrupts the
> original content for testing purposes.
>
>
> On Wed, 17 Jan 2001, Vojtech Pavlik wrote:
>
> > Hi!
> >
> > Ok, just for a test, before I finish the 2.2 version of the new VIA IDE
> > driver, could you try with the 2.4.0 kernel if it fixes the behavior?
> >
> > By the way, what motherboard is this?
> >
> > Andre: Thanks for sending this to me, this is the case I was looking for
> > - true data corruption on 2.2 kernel. Now I hope my new driver fixes
> > this.
> >
> > Vojtech
> >
> > On Wed, Jan 17, 2001 at 10:06:38AM -0800, Andre Hedrick wrote:
> > >
> > > Good Morning Vojtech!
> > >
> > > On Wed, 17 Jan 2001, Terrence Martin wrote:
> > >
> > > > I am having all sorts of nasty file corruption problems with 2.2.18
> > > > patched with
> > > > ide.2.2.18.1221.patch.gz
> > > > linux-2.2.18-reiserfs-3.5.29-patch.gz
> > > > raid-2.2.18-B0
> > > >
> > > > The corruption is occuring on my WDC AC28400R(I also had a problem with
> > > > a 13GB WDC as well which I swapped out last night). This is the only
> > > > hard drive that is on the onboard controller which is a VIA Technologies
> > > > VT 82C586 Apollo IDE (rev 6) chipset. The drive does share the IDE bus
> > > > with a internal ATAPI Zip drive. The cable I am using to connect the WDC
> > > > is a UDMA66 40pin 80 wire cable. I realize I do not have a UDMA66
> > > > controller, or disk, but I was having problems installing with a
> > > > standard 40 pin, 40 wire cable that the 80 wire seemed to alleviate.
> > > >
> > > > The other drives are my software RAID setup on 2 Promise PDC20262
> > > > controllers with 1 drive per interface for a total of 4 drives. These
> > > > drives are Quantum 13X(?) 13GB drives. I am running the default RH6.2
> > > > kernel right now for stability with no support for my promise
> > > > controllers and I am writing this from a remote site so not sure of
> > > > other distinguishing marks of the quantum HD's.
> > > >
> > > > So my question is does anyone have any idea what might cause ide dma
> > > > errors to occur when I use this kernel? As I mentioned file corruption
> > > > seems to only occur on the WDC drive(s) and manisfest itself as
> > > > executables suddenly becoming unreadable binary files, strange file
> > > > permissions on new files, and X windows going completely nuts when it
> > > > tries to start. I reboot back to the stock 2.2.14 with RH and everything
> > > > seems to work fine, excepting that I cannot access my RAID device of
> > > > course. :)
> > > >
> > > > I have had this problem across two mother boards(both VIA chipsets), two
> > > > CPU's, two WDC Hard drives and the cable swap. I have not swapped RAM.
> > > >
> > > > Thanks for any assistance/suggestions that you might be able to render.
> > > >
> > > > Regards
> > > > Terrence Martin
> > > >
> > > > P.S. More specific system information follows
> > > >
> > > > hdparm /dev/hda
> > > >
> > > > /dev/hda:
> > > > multcount= 0 (off)
> > > > I/O support = 0 (default 16-bit)
> > > > unmaskirq= 0 (off)
> > > > using_dma= 0 (off)
> > > > keepsettings = 0 (off)
> > > > nowerr = 0 (off)
> > > > readonly = 0 (off)
> > > > readahead= 8 (on)
> > > > geometry = 16383/16/63, sectors = 16514064, start = 0
> > > >
> > > > hdparm -i /dev/hda
> > > >
> > > > /dev/hda:
> > > >
> > > > Model=WDC AC28400R, FwRev=15.01J55, SerialNo=WD-WM6280172815
> > > > Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs
> > > > FmtGapReq }
> > > > RawCHS=16383/16/63, TrkSize=57600, SectSize=600,
Re: File System Corruption with 2.2.18
On Wed, Jan 17, 2001 at 11:53:36AM -0700, Terrence Martin wrote: > Vojtech Pavlik wrote: > > > Hi! > > > > Ok, just for a test, before I finish the 2.2 version of the new VIA IDE > > driver, could you try with the 2.4.0 kernel if it fixes the behavior? > > > > Hmm ok I will give it a try...this will have to wait for a few hours as I am at > work. btw, how easy is it to install 2.4.0 on a stock RH6.2 install? hehe :) RH 6.2? Uh. Well, you'll have to upgrade a couple packages I fear, if you want 2.4 as your default kernel. For just a testing run it should 'just work'. Well, maybe you'll need a newer gcc to compile it - I don't remember which version RH 6.2 uses. > > By the way, what motherboard is this? > > It is an FIC PA 2013 (1MB Cache Version) with a K6-3 400, it has a relatively > recent BIOS patch as well, perhaps 6 months ago. > > The other motherboard (also had corruption problems) was a California Graphics > Photon 100HC with a K6-2 300. Ok, thanks. > > > > Andre: Thanks for sending this to me, this is the case I was looking for > > - true data corruption on 2.2 kernel. Now I hope my new driver fixes > > this. > > So do I...:) > > Cheers, > > Terrence > > > > > > > > > Vojtech > > > > On Wed, Jan 17, 2001 at 10:06:38AM -0800, Andre Hedrick wrote: > > > > > > Good Morning Vojtech! > > > > > > On Wed, 17 Jan 2001, Terrence Martin wrote: > > > > > > > I am having all sorts of nasty file corruption problems with 2.2.18 > > > > patched with > > > > ide.2.2.18.1221.patch.gz > > > > linux-2.2.18-reiserfs-3.5.29-patch.gz > > > > raid-2.2.18-B0 > > > > > > > > The corruption is occuring on my WDC AC28400R(I also had a problem with > > > > a 13GB WDC as well which I swapped out last night). This is the only > > > > hard drive that is on the onboard controller which is a VIA Technologies > > > > VT 82C586 Apollo IDE (rev 6) chipset. The drive does share the IDE bus > > > > with a internal ATAPI Zip drive. The cable I am using to connect the WDC > > > > is a UDMA66 40pin 80 wire cable. I realize I do not have a UDMA66 > > > > controller, or disk, but I was having problems installing with a > > > > standard 40 pin, 40 wire cable that the 80 wire seemed to alleviate. > > > > > > > > The other drives are my software RAID setup on 2 Promise PDC20262 > > > > controllers with 1 drive per interface for a total of 4 drives. These > > > > drives are Quantum 13X(?) 13GB drives. I am running the default RH6.2 > > > > kernel right now for stability with no support for my promise > > > > controllers and I am writing this from a remote site so not sure of > > > > other distinguishing marks of the quantum HD's. > > > > > > > > So my question is does anyone have any idea what might cause ide dma > > > > errors to occur when I use this kernel? As I mentioned file corruption > > > > seems to only occur on the WDC drive(s) and manisfest itself as > > > > executables suddenly becoming unreadable binary files, strange file > > > > permissions on new files, and X windows going completely nuts when it > > > > tries to start. I reboot back to the stock 2.2.14 with RH and everything > > > > seems to work fine, excepting that I cannot access my RAID device of > > > > course. :) > > > > > > > > I have had this problem across two mother boards(both VIA chipsets), two > > > > CPU's, two WDC Hard drives and the cable swap. I have not swapped RAM. > > > > > > > > Thanks for any assistance/suggestions that you might be able to render. > > > > > > > > Regards > > > > Terrence Martin > > > > > > > > P.S. More specific system information follows > > > > > > > > hdparm /dev/hda > > > > > > > > /dev/hda: > > > > multcount= 0 (off) > > > > I/O support = 0 (default 16-bit) > > > > unmaskirq= 0 (off) > > > > using_dma= 0 (off) > > > > keepsettings = 0 (off) > > > > nowerr = 0 (off) > > > > readonly = 0 (off) > > > > readahead= 8 (on) > > > > geometry = 16383/16/63, sectors = 16514064, start = 0 > > > > > > > > hdparm -i /dev/hda > > > > > > > > /dev/hda: > > > > > >
Re: VIA chipset discussion
On Thu, Jan 18, 2001 at 11:42:25PM +, Howard Johnson wrote: > On Thu, Jan 18, 2001 at 06:32:39PM -0500, John O'Donnell wrote: > > Matthew Fredrickson wrote: > > > > I have the ASUS CUV4X. > > VIA vt82c686a (cf/cg) IDE UDMA66 controller on pci0:4.1 > > I also run DMA66 with no problems here. > > > > I never have seen any issues with the PS/2 mouse and X. > > I use the Logitech cordless wheel mouse. I use the "MouseManPlusPS/2" > > driver in XFree. When I was first setting this up (about a year ago) > > I had the problems you mention. I read an article on setting up your > > scroll wheel in X and it said to use the IMPS/2 setting. This was > > nothing but trouble, till I RTFM on XFree and mice and found my solution. > > Can you tell us what kind of mouse this is and how you have it set up in > > XFree. > > > > Let's take this mouse discussion off list as it has nuttin to do with > > the kernel > > Johnny O > > I'm seeing the same mouse problems... fine under 2.2.x, but jumps around under > a couple of 2.4.x releases (2.4.0-test6, IIRC, and 2.4.1-pre7). I find it odd > that if it isn't a kernel-related problem, that it's only manifesting itself > under 2.4. > > I'm running a slot A athlon on an abit KA7-100. My bet is ACPI/powermanagement messing with it ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[preview] Latest AMD & VIA IDE drivers with UDMA100 support
Hi Andre! I'm sending you (and others who might be interested) my latest VIA and IDE drivers. The VIA driver (v3.15) should have a complete support for UDMA100 on the vt82c686b chip, the AMD driver (v1.5) should have full UDMA100 support on the amd766 ViperPlus chip. They're also a little more foolproof with respect to the 'idebus' setting, which is quite a misnomer, btw. Care to try them out? Andre, you're the only one I know of having the 766 chip, so please test this driver, I'd like to know if it really works ... thanks. -- Vojtech Pavlik SuSE Labs via-amd-ide.tar.bz2
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, Jan 20, 2001 at 06:45:10PM +, Alan Chandler wrote: > On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote: > > >On Sat, 20 Jan 2001, Alan Chandler wrote: > > > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM > >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only > >> do UDMA mode 2. I am not overclocking or anything - all should be > >> running at default speeds with an Athlon 900. > >> > >> Just to be clear - I am NOT getting any errors when I switch back to > >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur > >> every few minutes when there is significant disk activity. > > > >But that kernel uses the stock driver that was the original second > >generation correct? > > > >Andre Hedrick > >Linux ATA Development > > > > Sorry, I realise now what I said was ambiguous. To be clear > > 2.2.17 - absolutely standard as shipped in debian - no errors > 2.4.0 - standard (downloaded tar.bz2) - ERRORS > 2.4.0 - as standard except for three files in tar.bz2 attachment to > Vojtech Pavlik's mail which were placed in drivers/ide directory - > ERRORS. > Alan Wonderful! A case where I can compare a working setup with a nonworking one! :) Could you please send me the usual stuff (dmesg, lspci -vvxxx, cat /proc/ide/via, hdparm -i /dev/hd*, hdparm -t /dev/hd*) for both the 2.2 case and the 2.4.0+VIA-latest case? That'll allow me to find the differences and possibly fix the new driver. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote: > Vojtech, I worry that the dynamic timing that you are calculating could > bite you. Well, I know this. But I fear hardcoded timings won't really help here, unles everyone out there ran their chipsets at 33 MHz, in which case the calculation gains the exact same results (you can compare that) as the hardcoded numbers for UDMA timings. > Timings are exact especially at modes 3/4/5 the margins go to > an effective zero for varition or wiggle room. The state diagrams from > Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it > constrained. You need to assume absolutes because the various board > makers screw up the skew tables by the PCB lane traces. > > By assuming only absolutes, all vendors that do bad designs will show and > the user can not and "should" not be allowed to hold the driver in a state > that can damage filesystems or lock the box. Since I have never addressed > this issue in public it is no obvious why I hardcoded timings and did not > let tehm float, but I hope it is clearer now. Ok, the VIA driver from clean 2.2.18 does nothing. It doesn't even use hardcoded timings. It doesn't touch any timing tables. It just blindly enables prefetch and writeback in the chips. The thing works because it relies on BIOS to set things up correctly, and this is often the case, yes. > chipset ---\ > | > \-IDC-header > > chipset ---+ >| >+--IDC-header > > These are nearly the same but the corners cause bounce and iCRC's Well, there are other ways the motherboard maker can screw up the traces, and often this happens: chipset \ | chipset --\ | | \-- header \ header So the different traces have different lengths and thus some bits arrive earlier than others to the header, causing the same CRC errors. Also it seems that some boards don't use exactly 33.3 MHz PCI clock, but something like 33.7 or even more, which causes some drives to fail with them if the chipset is set to the 0xe0 (2 pciclk/ideclk) value. This is because they use very cheap base 14MHz crystals. As I said before - if you leave 'idebus' at 33, the calculated timings are exactly the same as the hardcoded values would be (I think there is a difference in PIO2 mode, where the calculation gives a slightly larger active time and shorter recovery, but this is OK with the specs). And this is also why the cheaply made motherboards fail. (They don't care to make that VIA UDMA66 ide working correctly when they have a UDMA100 HPT370 onboard)? ... btw, if we ever implement UDMA slowdown code based on CRC errors, we should differentiate between CRC errors on read and CRC errors on write, because each are caused by a different problem ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset discussion
On Sun, Jan 21, 2001 at 03:04:37AM -0800, David D.W. Downey wrote: > > OK, currently at work so I don't have the affected system in front of > me. I'm doing this from memory.. > > My apologies to those that responded to me. I've been unable to work on > this issue for the last few days due to work. > > My particular board is the MSI 694D Pro Dual processor board. It uses the > VT82C686A chipset and the PDC20265 Promise ATA100. > > I'm running dual PIII-733s with 1GB of Corsair RAM. The board, CPUs, and > memory all run at 133MHz. The drives are > > ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA > hda: WDC WD153AA, ATA DISK drive > hda: 30064608 sectors (15393 MB) w/2048KiB Cache, CHS=1871/255/63, UDMA(66) > ide0: BM-DMA at 0xb000-0xb007, BIOS settings: hda:DMA, hdb:DMA > hdb: WDC WD300BB-00AUA1, ATA DISK drive > hdb: 58633344 sectors (30020 MB) w/2048KiB Cache, CHS=3649/255/63, UDMA(66) > Now to recap... > Kernel command line: BOOT_IMAGE=new ro root=304 idebus=66 hdc=ignore > ide_setup: hdc=ignore -- BAD OPTION Don't use "idebus=66". It's wrong. If you want to force UDMA66/UDMA100, the correct option is ide0=ata66. If you want to use idebus=, you should use idebus=33, because that's what your PCI bus most likely operates at. Also "hdc=ignore" doesn't work either. > ide1: BM-DMA at 0xb008-0xb00f, BIOS settings: hdc:DMA, hdd:pio > hdc: SAMSUNG CD-ROM SC-148F, ATAPI CDROM drive > hdc: ATAPI 48X CD-ROM drive, 128kB Cache, DMA > > I'm experiencing consistant kernel deaths when doing any type of heavy IO > as I stated earlier. I'm using the following as my test. > > dd if=/dev/hda4 of=/tmp/testdd.img bs=1024M count=2k > > It gets about 300MB into the file and pukes the kernel. What does the 'puking' exactly do? > I get lots of errors about disabling DMA within my logs. Just this? > No perosnally, I believe it's a problem with the VIA chipset > specifically. I've seen a couple of emails regarding the same type of > problem with various setups and the commonality is the VIA chipset. How is > this affecting it? I'm not quite sure. (This may already have been covered > but for the purpose of making sure that I'm not chasing numerous > possibilities I've ignored some of them.) I **THINK** it's a problem > specifically with the DMA support. The VIA chipsets are not easy to set up and the margins for error are too thin. > However, I do still get the kernel deaths even when using ATA33. I've > specifically noticed that if you install mixed drives (ATA33 + ATA66 + > ATA100) then the system will consistantly puke as well. Take out the ATA66 > drives and things stabilize for a bit then puke. I'm not sure if dropping > an ATA33 drive on there by itself is the solution even if it does > completely stabilize the machine. There is no reason for the ATA66 support > not to work since it's a combined controller that I'm sure the VIA driver > maintainer has looked at. (He emailed me but I forgot his name. Please > accept my apologies for not remembering, no disrespect is intended.) Me, most likely. > Is anyone out there with as close a match to my setup as possible wish to > help me with this? (I'm not discounting the mismatched setups, I just want > a baseline to go from. If someone with my setup is NOT ahving trouble then > I may need to look at something different). -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Via apollo KX133 ide bug in 2.4.x
On Sat, Jan 20, 2001 at 04:32:36PM -0500, safemode wrote: > Peter Horton wrote: > > > On Thu, Jan 20, 2000 at 08:38:12AM +, Peter Horton wrote: > > > > > > I think I'm suffering the same thing on my new Asus A7V. Yesterday I got a > > > single "error in bitmap, remounting read only" type error, and today I got > > > some files in /tmp that returned I/O error when stat()ed. I do have DMA > > > enabled, but only UDMA33. I've done several kernel compiles with no > > > problems at all so looks like something is on the edge. Think I might go > > > back to 2.2.x for a bit and see what happens, or maybe just remove the VIA > > > driver :-((. > > > > > > > I apologise for following up my own E-mail, but there is something I'm > > missing here (maybe a whole lot of something). Anyone know how come we're > > seeing silent corruption ... I thought this UDMA stuff was all checksummed > > ? If there error is outside the data I assume the driver would notice ? > > > > P. > > The thing is, even with UDMA disabled in the kernel, I still see the corruption > with 2.4.x (release) and above. Anything written while using the kernel is > corrupted. Much of the stuff will read fine (files) ... but I believe > directories get the IO error immediately and some files do also. Everything is > seen as corrupted when you fsck a partition where this kernel has been run and > created files on. This is a silent corruption without any errors reported and > I've only tested it on ext2. You cannot create FS's with these kernels (at > least on the VIA chipsets) since they too are corrupted (note, only tested ext2 > fs). I did disable UDMA everywhere and still saw it happen, this problem is > not present in older 2.4.0-test kernels so it's something in the late > pre-release stage and into the release stage. Do you have the via driver compiled in? If yes, try without, if no, try with it ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, Jan 21, 2001 at 10:51:12AM +, Alan Chandler wrote:
> On Sat, 20 Jan 2001 20:18:34 -0500 (EST), you wrote:
>
>
> >that's not the topic: Andre's talking about pci-clock-based timing
> >constants the the driver programs into the ide controller - a matter
> >of an extra few/more nanoseconds.
>
> I know, but when looking hard for a problem in one place and not
> finding it, it is sometimes helpful to consider other options.
>
> I am getting errors under 2.4.0 which didn't appear in 2.2.17 - and as
> far as I could see from hdparm - both were at UDMA mode 2 (I assume
> thats what the * means - the man page wasn't very clear). My drives
> only handle up to this mode, and I was wondering if the new driver was
> trying to run them at a mode higher than they were supposed to go.
>
> This massive difference in timing seemed significant.
No, but to me it seems that even though UDMA2 mode is selected in the
drive in 2.2.17 (that's what the * means), the kernel doesn't use DMA,
and thus everything works in PIO4. This would well explain the speed
difference.
> >quite slow in either case, at least for modern hardware (which is
> >all in the 20-40 MB/s range). this looks like a PIO vs DMA difference
> >to me, not even UDMA. of course, hdparm can tell you what mode you're in.
>
> I did discover a difference - 2.2.17 set the drives with multisector
> off, 2.4.0 was setting multisector on.
Multisector is valid only in PIO modes. If both were doing some kind of
DMA, it wouldn't change anything.
> However, I have redone the
> timing with multisector turned on in the 2.2.17 case and the
> difference is still there.
>
> Under 2.2.17 with multisector turned on
>
>
> /dev/hda:
>
> Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
> BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
> MultSect=16
> DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
> tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
> mword2
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
> UDMA modes: mode0 mode1 *mode2
>
> --
>
> /dev/hda:
> Timing buffered disk reads: 64 MB in 19.88 seconds = 3.22 MB/sec
>
>
> Under 2.4.0
>
>
> /dev/hda:
>
> Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
> BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
> MultSect=16
> DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
> tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
> mword2
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
> UDMA modes: mode0 mode1 *mode2
>
> --
>
> /dev/hda:
> Timing buffered disk reads: 64 MB in 6.58 seconds = 9.73 MB/sec
>
>
>
> I don't suppose the fact that my hdparm is oldish (3.6 I think) have
> any bearing on this?
No, 3.6 is OK I think.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, Jan 21, 2001 at 01:42:41PM +0100, Mike Galbraith wrote: > On Sun, 21 Jan 2001, Vojtech Pavlik wrote: > > > On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote: > > > > > chipset ---\ > > > | > > > \-IDC-header > > > > > > chipset ---+ > > >| > > >+--IDC-header > > > > > > These are nearly the same but the corners cause bounce and iCRC's > > I don't see how anyone can influence risetime falltime or impedance > matching [1] issues via software timing changes. > > (the top drawing is what you see on a poorly designed board.. long > rise/fall times often cause worse problems than [slight] ringing) > > > Well, there are other ways the motherboard maker can screw up the > > traces, and often this happens: > > > > chipset \ > > | > > chipset --\ | > > | \-- header > > \ header > > > > Can you compensate for these things (to any degree?) in software? Not really. Slowing the data rate down is in my opinion the only way to compensate for this. Btw, the chipset only controls the write data rate with UDMA. The read rate is controlled by the drive. > 1. Only a software guy would call it 'bounce'.. sounds funny ;-) -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE bug with WD drive?
On Wed, Nov 15, 2000 at 07:56:43PM -0500, dep wrote:
> On Wednesday 15 November 2000 19:30, Karnik, Rahul wrote:
>
> | I get the following error if I try to enable DMA on my Abit KT7
> | motherboard with a VIA2C686 chipset:
> |
> | hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest
> | } hdb: timeout waiting for DMA
> | hda: DMA disabled
> | hdb: DMA disabled
> | ide0: reset: success
>
> i get the same thing, along with a crc error, over and over on a
> 20-gig WD IDE drive. alternately puzzling and frightening.
> apparently, wd uses some nonstandard goofball error checking thing
> that just doesn't work with linux at present. it *seems* to do no
> harm.
Ok, both of you, we can try to track this down.
1) Please try with 2.4.0-latest.
2) Send me the complete dmesg.
3) Send me lspci -vvvxxx
4) Send me /proc/ide/via
I'll see what I can do about the driver.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: rdtsc to mili secs?
On Wed, Nov 15, 2000 at 01:05:27PM -0800, H. Peter Anvin wrote: > > > Intel PIIX-based systems will do duty-cycle throttling, for example. > > > > Don't think so. My toshiba is PIIX-based, AFAIC: > > Interesting. Some will, definitely. Didn't know that wasn't universal. > > Clearly, on a machine like that, there is no hope for RDTSC, at least > unless the CPU (and OS!) gets notification that the TSC needs to be > recalibrated whenever it switches. > > > Still, it is willing to run with RDTSC at 300MHz, 150MHz, and > > 40MHz. (The last one in _extreme_ cases when CPU fan fails -- running > > at 40MHz is better than cooking cpu). I believe that pulsing the STPCLK pin of the processor by connecting it to a say 32kHz signal and then changing the duty cycle of that signal could have the effect of slowing down the processor to these speeds. Somehow I can't believe a PMMX would be able to run at 40MHz. Which in turn means that STPCLK also stops TSC, which is equally bad. Anyway, this should be solvable by checking for clock change in the timer interrupt. This way we should be able to detect when the clock went weird with a 10 ms accuracy. And compensate for that. It should be possible to keep a 'reasonable' clock running even through the clock changes, where reasonable means constantly growing and as close to real time as 10 ms difference max. Yes, this is not perfect, but still keep every program quite happy and running. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4)
On Wed, Nov 15, 2000 at 11:58:27AM -0800, Barry K. Nathan wrote: > It looks like I was mistaken in my original message. I have an AMD 5x86, not > a K5. > > Nevertheless, menuconfig lists the 586 option as "586/K5/5x86/6x86/6x86MX". > But, it fails to boot on my 5x86 and I have to compile for a 486 (for 2.4). > As I mentioned in my previous message, the 586/... option boots with 2.2. > > I just noticed that, under both 2.2 and 2.4, uname -a identifies the > machine as an i486. > > Should the 486 option be changed to "486/5x86" and the 586/... option > changed to "586/K5/6x86/6x86MX"? Or is there a bug here that needs fixing? > (IIRC, Cyrix and IBM made 5x86's as well - are those more like fast 486's > or slow Pentiums? I don't remember. If they're like Pentiums, perhaps > "486/AMD 5x86" and "586/non-AMD 5x86/6x86/6x86MX"...?) If I recall correctly: Am5x86 == AMD X5 == a very fast 486 processor with a big WB cache Cx5x86 == IBM 5x86 == a slow Pentium-like processor in a 486 socket So yes, for the AMD 5x86 you have to select '486'. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Input drivers critical fixes, try #2.
Hello,
attached is a patch that fixes some critical and some less critical, but
still harmful bugs in the input drivers. It's against 2.4.0-test11-pre6.
Joysticks:
drivers/joystick/adi.c:
Fix X/Y axes on Logitech gamepads.
drivers/joystick/ns558.c:
Fix module impossible to load for ISA devices unless
CONFIG_HOTPLUG - bug added in test11-pre6. [critical]
Fix oops on unload if PCI gameports present. [critical]
Fix oops on unload if PCI gameports not present,
- bug added in test11-pre6. [critical]
Fix memory leak on unload. [critical]
drivers/char/joystick/sidewinder.c
Fix missing button on MS FF Wheel.
Input [USB+Joystick]:
drivers/input/input.c:
Fix a possible race at open - fix by Oliver Neukum. [critical]
drivers/input/evdev.c:
Fix possible overflows in connect and open. [critical]
drivers/input/joydev.c:
Fix possible overflows in connect and open. [critical]
drivers/input/mousedev.c:
Fix possible overflows in connect and open. [critical]
Add missing randomness reporting.
Please apply it.
Thanks.
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-2.4.0-test11-pre6/drivers/char/joystick/adi.c
linux/drivers/char/joystick/adi.c
--- linux-2.4.0-test11-pre6/drivers/char/joystick/adi.c Thu Jun 22 15:59:58 2000
+++ linux/drivers/char/joystick/adi.c Fri Nov 17 16:20:09 2000
@@ -418,7 +418,7 @@
adi->dev.private = port;
adi->dev.evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
- for (i = 0; i < adi->axes10 + adi->axes8 + adi->hats * 2; i++)
+ for (i = 0; i < adi->axes10 + adi->axes8 + (adi->hats + (adi->pad > 0)) * 2;
+i++)
set_bit(adi->abs[i], &adi->dev.absbit);
for (i = 0; i < adi->buttons; i++)
@@ -431,7 +431,7 @@
if (!adi->length) return;
- for (i = 0; i < adi->axes10 + adi->axes8 + adi->hats * 2; i++) {
+ for (i = 0; i < adi->axes10 + adi->axes8 + (adi->hats + (adi->pad > 0)) * 2;
+i++) {
t = adi->abs[i];
x = adi->dev.abs[t];
diff -urN linux-2.4.0-test11-pre6/drivers/char/joystick/ns558.c
linux/drivers/char/joystick/ns558.c
--- linux-2.4.0-test11-pre6/drivers/char/joystick/ns558.c Fri Nov 17 16:13:41
2000
+++ linux/drivers/char/joystick/ns558.c Fri Nov 17 16:20:51 2000
@@ -58,6 +58,7 @@
};
static struct ns558 *ns558;
+static int ns558_pci;
/*
* ns558_isa_probe() tries to find an isa gameport at the
@@ -187,12 +188,10 @@
}
memset(port, 0, sizeof(struct ns558));
- port->next = ns558;
port->type = NS558_PCI;
port->gameport.io = ioport;
port->gameport.size = iolen;
port->dev = pdev;
- ns558 = port;
pdev->driver_data = port;
@@ -315,8 +314,7 @@
* it is the least-invasive probe.
*/
- i = pci_register_driver(&ns558_pci_driver);
- if (i < 0) return i;
+ ns558_pci = !pci_module_init(&ns558_pci_driver);
/*
* Probe for ISA ports.
@@ -337,12 +335,12 @@
}
#endif
- return 0;
+ return (ns558 || ns558_pci) ? 0 : -ENODEV;
}
void __exit ns558_exit(void)
{
- struct ns558 *port = ns558;
+ struct ns558 *next, *port = ns558;
while (port) {
gameport_unregister_port(&port->gameport);
@@ -363,10 +361,13 @@
break;
}
- port = port->next;
+ next = port->next;
+ kfree(port);
+ port = next;
}
- pci_unregister_driver(&ns558_pci_driver);
+ if (ns558_pci)
+ pci_unregister_driver(&ns558_pci_driver);
}
module_init(ns558_init);
diff -urN linux-2.4.0-test11-pre6/drivers/char/joystick/sidewinder.c
linux/drivers/char/joystick/sidewinder.c
--- linux-2.4.0-test11-pre6/drivers/char/joystick/sidewinder.c Mon Aug 14 22:55:01
2000
+++ linux/drivers/char/joystick/sidewinder.cFri Nov 17 16:20:09 2000
@@ -102,7 +102,7 @@
{ BTN_TRIGGER, BTN_THUMB, BTN_TOP, BTN_TOP2, BTN_BASE, BTN_BASE2, BTN_BASE3,
BTN_BASE4, BTN_SELECT },
{ BTN_TRIGGER, BTN_THUMB, BTN_TOP, BTN_TOP2, BTN_BASE, BTN_BASE2, BTN_BASE3,
BTN_BASE4, BTN_SELECT },
{ BTN_A, BTN_B, BTN_C, BTN_X, BTN_Y, BTN_Z, BTN_TL, BTN_TR, BTN_START,
BTN_MODE, BTN_SELECT },
- { BTN_TRIGGER, BTN_TOP, BTN_THUMB, BTN_THUMB2, BTN_BASE, BTN_BASE2, BTN_BASE3
}};
+ { BTN_TRIGGER, BTN_TOP, BTN_THUMB, BTN_THUMB2, BTN_BASE, BTN_BASE2, BTN_BASE3,
+BTN_BASE4 }};
static struct {
int x;
diff -urN linux-2.4.0-test11-pre6/drivers/input/evdev.c linux/drivers/input/evdev.c
--- linux-2.4.0-test11-pre6/drivers/input/evdev.c Fri Jul 28 03:36:54 2000
+++ linux/drivers/input/evdev.c Fri Nov 17 16:20:12 2000
@@ -123,7 +123,7 @@
struct evdev_list *list;
i
Re: rdtsc to mili secs?
On Sat, Nov 18, 2000 at 09:12:31PM +0100, Pavel Machek wrote: > > Anyway, this should be solvable by checking for clock change in the > > timer interrupt. This way we should be able to detect when the clock > > went weird with a 10 ms accuracy. And compensate for that. It should be > > possible to keep a 'reasonable' clock running even through the clock > > changes, where reasonable means constantly growing and as close to real > > time as 10 ms difference max. > > > > Yes, this is not perfect, but still keep every program quite happy and > > running. > > No. Udelay has just gone wrong and your old ISA xxx card just crashed > whole system. Oops. Yes. But can you do any better than that? Anyway, I wouldn't expect to be able to put my old ISA cards into a recent notebook which fiddles with the CPU speed (or STPCLK ratio). > BTW I mailed patch to do exactly that kind of autodetection to the > list some time ago. (I just can't find it now :-( -- search archives > for 'TSC is slower than it should be'. If I recall correctly, that patch didn't create a 'reasonable clock' - it wasn't growing all the time and could skip back sometimes. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: rdtsc to mili secs?
On Sat, Nov 18, 2000 at 03:48:06PM -0800, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Pavel Machek <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Actually, on machines where RDTSC works correctly, you'd like to use > > > that to detect a lost timer interrupt. > > > > > > It's tough, it really is :( > > > > Well, my patch did not do that but you probably want lost timer > > interrupt detection so that you avoid false alarms. > > > > But that means you can no longer detect speed change after 10msec: > > > > going from 150MHz to 300MHz is very similar to one lost timer > > interrupt. > > > > That's the point. ... and, you still can have both - detection of lost timer interrupts and detection of speed changing. It'll take longer than 10ms to notice, though (I think 20 or 30 will just do it). -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: rdtsc to mili secs?
On Sun, Nov 19, 2000 at 09:24:04PM +0100, Pavel Machek wrote: > Hi! > > > > > Anyway, this should be solvable by checking for clock change in the > > > > timer interrupt. This way we should be able to detect when the clock > > > > went weird with a 10 ms accuracy. And compensate for that. It should be > > > > possible to keep a 'reasonable' clock running even through the clock > > > > changes, where reasonable means constantly growing and as close to real > > > > time as 10 ms difference max. > > > > > > > > Yes, this is not perfect, but still keep every program quite happy and > > > > running. > > > > > > No. Udelay has just gone wrong and your old ISA xxx card just crashed > > > whole system. Oops. > > > > Yes. But can you do any better than that? Anyway, I wouldn't expect to > > be able to put my old ISA cards into a recent notebook which fiddles > > with the CPU speed (or STPCLK ratio). > > PCMCIA is just that: putting old ISA crap into modern hardware. Sorry. Not really, fortunately. There are ISA-sytle NE2000's on PCMCIA, but 1) You know that you have a card there via the PCMCIA services and 2) They're not the old crappy NE2000's that'd die on a random read anyway. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre6 still very broken
On Mon, Nov 20, 2000 at 01:37:23PM +0100, Thomas Sailer wrote: > > I hope EHCI makes it all moot. Some way or another. > > Only for USB2 devices. EHCI is supposed to be paired with an existing > UHCI or OHCI controller core that is supposed to take over the USB connector > if an USB 1.x hub or device is plugged in. So we end up needing to support > UHCI and OHCI for a very long time, I don't see mice and keyboards going > USB2 anytime soon 8-) Oops? I thought the paired controller there is for OSes not being able to handle EHCI yet? So that USB works even for those ... I think EHCI should handle even 1.x devices ... I may be wrong, though. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Fix AMD PCNet32 printk's
Hi!
Someone overzealously added too many KERN_INFOs to pcnet32, so that they
appear not only at the beginning of each line, but also many times in
between words. This is wrong.
This patch removes the extraneous KERN_* from pcnet32. It leaves all
those that should be there in place. It does not change anything else.
It's against 2.4.0-test11.
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-2.4.0-test11/drivers/net/pcnet32.c linux/drivers/net/pcnet32.c
--- linux-2.4.0-test11/drivers/net/pcnet32.cTue Nov 21 23:04:24 2000
+++ linux/drivers/net/pcnet32.c Tue Nov 21 20:56:57 2000
@@ -483,7 +483,7 @@
printk(KERN_INFO "pcnet32_probe_pci: found device %#08x.%#08x\n", ent->vendor,
ent->device);
ioaddr = pci_resource_start (pdev, 0);
-printk(KERN_INFO " ioaddr=%#08lx resource_flags=%#08lx\n", ioaddr,
pci_resource_flags (pdev, 0));
+printk(KERN_INFO "ioaddr=%#08lx resource_flags=%#08lx\n", ioaddr,
+pci_resource_flags (pdev, 0));
if (!ioaddr) {
printk (KERN_ERR "no PCI IO resources, aborting\n");
return -ENODEV;
@@ -627,29 +627,29 @@
/* There is a 16 byte station address PROM at the base address.
The first six bytes are the station address. */
for (i = 0; i < 6; i++)
- printk( KERN_INFO " %2.2x", dev->dev_addr[i] = inb(ioaddr + i));
+ printk(" %2.2x", dev->dev_addr[i] = inb(ioaddr + i));
if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 or 0x2624 */
i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */
- printk(KERN_INFO"\ntx_start_pt(0x%04x):",i);
+ printk("\n" KERN_INFO "tx_start_pt(0x%04x):",i);
switch(i>>10) {
- case 0: printk(KERN_INFO " 20 bytes,"); break;
- case 1: printk(KERN_INFO " 64 bytes,"); break;
- case 2: printk(KERN_INFO " 128 bytes,"); break;
- case 3: printk(KERN_INFO "~220 bytes,"); break;
+ case 0: printk(" 20 bytes,"); break;
+ case 1: printk(" 64 bytes,"); break;
+ case 2: printk(" 128 bytes,"); break;
+ case 3: printk("~220 bytes,"); break;
}
i = a->read_bcr(ioaddr, 18); /* Check Burst/Bus control */
- printk(KERN_INFO" BCR18(%x):",i&0x);
- if (i & (1<<5)) printk(KERN_INFO "BurstWrEn ");
- if (i & (1<<6)) printk(KERN_INFO "BurstRdEn ");
- if (i & (1<<7)) printk(KERN_INFO "DWordIO ");
- if (i & (1<<11)) printk(KERN_INFO"NoUFlow ");
+ printk(" BCR18(%x):",i&0x);
+ if (i & (1<<5)) printk("BurstWrEn ");
+ if (i & (1<<6)) printk("BurstRdEn ");
+ if (i & (1<<7)) printk("DWordIO ");
+ if (i & (1<<11)) printk("NoUFlow ");
i = a->read_bcr(ioaddr, 25);
- printk(KERN_INFO "\nSRAMSIZE=0x%04x,",i<<8);
+ printk("\n" KERN_INFO "SRAMSIZE=0x%04x,",i<<8);
i = a->read_bcr(ioaddr, 26);
- printk(KERN_INFO " SRAM_BND=0x%04x,",i<<8);
+ printk(" SRAM_BND=0x%04x,",i<<8);
i = a->read_bcr(ioaddr, 27);
- if (i & (1<<14)) printk(KERN_INFO "LowLatRx,");
+ if (i & (1<<14)) printk("LowLatRx");
}
dev->base_addr = ioaddr;
@@ -662,7 +662,7 @@
memset(lp, 0, sizeof(*lp));
lp->dma_addr = lp_dma_addr;
lp->pci_dev = pdev;
-printk(KERN_INFO "pcnet32: pcnet32_private lp=%p lp_dma_addr=%#08x\n", lp,
lp_dma_addr);
+printk("\n" KERN_INFO "pcnet32: pcnet32_private lp=%p lp_dma_addr=%#08x", lp,
+lp_dma_addr);
spin_lock_init(&lp->lock);
@@ -713,7 +713,7 @@
}
if (dev->irq >= 2)
- printk(KERN_INFO " assigned IRQ %d.\n", dev->irq);
+ printk(" assigned IRQ %d.\n", dev->irq);
else {
unsigned long irq_mask = probe_irq_on();
@@ -728,9 +728,9 @@
dev->irq = probe_irq_off (irq_mask);
if (dev->irq)
- printk(KERN_INFO ", probed IRQ %d.\n", dev->irq);
+ printk(", probed IRQ %d.\n", dev->irq);
else {
- printk(KERN_ERR ", failed to detect IRQ line.\n");
+ printk(", failed to detect IRQ line.\n");
return -ENODEV;
}
}
@@ -978,14 +978,14 @@
lp->dirty_tx, lp->cur_tx, lp->tx_full ? " (full)" : "",
lp->cur_rx);
for (i = 0 ; i < RX_RING_
Re: Linux 2.4.0test11-ac1
On Wed, Nov 22, 2000 at 05:58:14PM +, Alan Cox wrote: > > > if(vendor!=INTEL && !has_apic) > > > /* No SMP */ > > > > And suddenly certain i486 systems do not work anymore? Well, I haven't > > i486 is an intel processor ... but is there a reason why for example AMD 486's couldn't work in a 82489DX-based SMP board? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW DRIVER] firestream
On Thu, Nov 23, 2000 at 09:22:09AM +0100, Rogier Wolff wrote:
> Peter Samuelson wrote:
>
> > > +int loopback = 0;
> > > +int fs_debug = 0;
> > > +struct fs_dev *fs_boards = NULL;
>
> > Aside from the 'static' issue already mentioned, these should be left
> > uninitialized. ('gcc -fassume-bss-zero' would be nice, but then again
> > in userspace it rarely matters.)
>
> Hi Peter, thanks for the feedback.
>
> Actually, I have an opinion on this matter: If the initialization
> value doesn't really matter that much, I like leave out the
> initialization, as you suggest.
>
> However, if my code assumes that the compiler needs to initialize the
> variable one way or another, I want to put in the initialization, even
> if that means an "= 0;" which is already the default.
>
> This is a form of documentation.
If it didn't matter in the object code, it would be just documentation.
But uninitialized variables are put into the .bss segment, which is not
included in the object (and is assumed to be zero on start), while
initialized ones (even to zero) are put into the .data segment, which
*is* in the object file.
Thus a difference of 12 bytes code size in your case (on a 32 bit system).
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Recent ide patches and DMA
On Thu, Nov 23, 2000 at 01:09:35PM -0800, Kafu Nagai wrote:
> With recent ide patches, the ide driver seems to try to use DMA mode even for a
>drive which dosen't support it. CONFIG_IDEDMA_PCI_AUTO is enabled but even so with
>the stock kernel this dosen't happen. older patches didn't have this behavior either.
>Is this change intentional ?
>
> hdc: 333630 sectors (171 MB) w/32KiB Cache, CHS=1011/15/22, DMA
> Partition check:
> hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
> hdc:hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hdc: dma_intr: error=0x04 { DriveStatusError }
> hdc: DMA disabled
> ide1: reset: success
> hdc1
>
> ~ $ hdparm -i /dev/hdc
>
> /dev/hdc:
>
> Model=QUANTUM ELS170A, FwRev=4.20, SerialNo=166304085456
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs RotSpdTol>.5% }
> RawCHS=1011/15/22, TrkSize=11264, SectSize=512, ECCbytes=4
> BuffType=3(DualPortCache), BuffSize=32kB, MaxMultSect=8, MultSect=off
> DblWordIO=no, OldPIO=2, DMA=no
> CurCHS=1011/15/22, CurSects=333629, LBA=no
Which chipset are you using?
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
On Thu, Nov 23, 2000 at 10:01:53PM +1100, Rusty Russell wrote: > In message <[EMAIL PROTECTED]> you write: > > > On Tue, 21 Nov 2000 22:25:01 Bartlomiej Zolnierkiewicz wrote: > > > > > > > > Quick removal of unnecessary initialization to 0. > > > > Quite the contrary. The patch seems correct and useful to me. What do you > > think is wrong with it? (Linus accepted megabytes worth of the above in > > the past...) > > What irritates about these monkey-see-monkey-do patches is that if I > initialize a variable to NULL, it's because my code actually relies on > it; I don't want that information eliminated. Yes, but if it generates a bigger (== worse) binary? -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] removal of "static foo = 0" from drivers/ide (test11)
On Tue, Nov 28, 2000 at 02:19:23PM +1100, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you write:
> > On Thu, Nov 23, 2000 at 10:01:53PM +1100, Rusty Russell wrote:
> > > What irritates about these monkey-see-monkey-do patches is that if I
> > > initialize a variable to NULL, it's because my code actually relies on
> > > it; I don't want that information eliminated.
> >
> > Yes, but if it generates a bigger (== worse) binary?
>
> We're talking about a few bytes, here. If you're prepared to make my
> code less clear to save bytes, you can do much better than that...
Perhaps in your case you had just an
int a = 0;
then it's really just a few bytes, but many sources have for example
int a[1024] = { 0, 0, /* */ };
Which in turn is a big wastage.
On the other hand, if you save "just" a few bytes in every driver, in a
way that is safe and simple (and commenting out the = 0 is a safe way),
you get a lot of space saved in the sum.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: why volatile on vgacon.c?
On Wed, Nov 29, 2000 at 05:24:15PM +0100, Santiago Garcia Mantinan wrote:
> Hi!
>
> I used to be able to run my 12 ethernet ports pentium based bridge without
> vga card, but with tty1, tty2, ... still working, as the kernel used to
> recognice a kind of a cga card on my machine even though there was none. But
> the kernel could write to the memory were the card was supposed to be, and
> so it worked.
>
> That was on 2.2 series, but since I moved it to 2.4 series I don't have that
> cga card found anymore. I have looked on the kernel code and followed it to
> the __init function in vgacon.c, more concretely this piece of code...
>
> scr_writew(0xAA55, p);
> scr_writew(0x55AA, p + 1);
> if (scr_readw(p) != 0xAA55 || scr_readw(p + 1) != 0x55AA) {
>
> Well, the thing is that this code and the code in this function is almost
> the same in 2.4 as in 2.2, however reading returns the written values on 2.2
> and different ones (0x) on 2.4
>
> This is caused by the volatile declaration of *p on 2.4, so the questions
> are:
>
> was the old (I have found a CGA) behaviour considered a bug and is the
> volatile declaration its fix?
Yes. The compiler was optimizing too much.
> If so, is there any way to have /dev/tty1 on a no graphic card i386 machine?
> (besides unvolatilizating *p wich works for me)
I think you can use serial console instead, if you have serial ports in
the machine.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ATA100/UDMA100 Support on the ASUS-CUSL2 mobo
On Thu, Nov 30, 2000 at 01:57:54AM -0500, S.Salman Ahmed wrote: > > [I am not subscribed to the list, so please CC: me] > > Hi, > > How well is the ATA100/UDMA100 supported in the development kernels ? I > have a system with an ASUS CUSL2 mobo, which has built-in ATA100 IDE > channels, alongwith a Maxtor 20Gb ATA100 HD. > > I looked at the kernel config for 2.4.0-test11, but in the "IDE, ATA and > ATAPI Block devices" section couldn't find chipset-specific support for > either the: > > (1) Intel i815 chipset, which is what the ASUS-CUSL2 has > > or the > > (2) Intel I/O Controller Hub 2 (ICH2) > > I'd like to get my system working using the built-in ATA100 controller > on the ASUS CUSL2, but what options do I need in 2.4.0-test11's kernel > config ? > > Is there support for the Intel i815 chipset ? Yes, the PIIX driver should be able to handle ICH2 and ATA100. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] G450 support for matroxfb
On Sat, Nov 25, 2000 at 04:36:50PM +0100, Willy Tarreau wrote: > > BTW, XF4.0.1e is also very unhappy on this hardware. > > Best regards, > > Petr Vandrovec > > [EMAIL PROTECTED] > > does the Matrox driver work with it ? My G400 works very well with the one I > found on this site, and the G450 is also referenced : > > http://www.matrox.com/mga/support/drivers/latest/home.htm Well, XF4.0.1e should work with it if compiled with mgaHALlib.a ... The Matrox driver referenced above uses this lib. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test8-pre5
On Wed, Sep 06, 2000 at 02:21:36PM +0200, Dan Aloni wrote: > > Can someone explain this line from the VIA update? > > #define FIT(v,min,max) (((v)>(max)?(max):(v))<(min)?(min):(v)) > > Barring side effects on the variables, it is equivalent to > > #define FIT(v,min,max) ((v)<(min)?(min):(v)) > > > > Why do I get the feeling that this was *not* the intent? > Or perhaps this is a lot better: > > #define FIT(v,min,max) ((v)>(max)?(max):((v)<(min)?(min):(v))) Thanks for spotting the misplaced braces. Fixed in my copy of the driver, and I'll send a patch to Linus soon, along with a couple more enhancements to the driver (better via82c596b detection). -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] VIA IDE driver v2.3
Hi!
While version 2.1 works OK, v2.3 some more cleanups and enhancements
to the driver. These are:
* Added VIA clone chipsets to the comments at the beginning of the file.
* Simpler VIA southbridge detection using a table only now, two version
specific kludges removed.
* Removed 8-bit timing entries (they were #ifdefed out anyway), because
indeed the hardware should take care of that.
* Fixed a misplaced brace in the FIT macro.
* Enhanced the EIDE PIO & MWDMA timing setup to modify the mode timing
based on drive capabilites instead selecting a slower mode based on
the same numbers. This should give better performance on some drives.
* Use the 'recommended timing' value for MWDMA modes to enhance
performance on MWDMA drives. Using 'minimum timing', as done before
results in flowcontrol being triggered too often, which slows down
the transfers considerably.
* Don't try to set PIO_SLOW mode. Drives that need it don't support PIO
mode setting anyway.
* Check for interface presence before trying to tune it. Higher layers
still can request tuning on a nonexistent interface.
Anyone interested, please test this out, if it is as problemless as
version 2.1, I'll send this to Linus for inclusion in the kernel.
--
Vojtech Pavlik
SuSE Labs
--- via82cxxx.c-2.1 Tue Aug 29 11:19:27 2000
+++ via82cxxx.c Tue Sep 12 13:02:22 2000
@@ -1,5 +1,5 @@
/*
- * $Id: via82cxxx.c,v 2.1 2000/08/29 01:34:60 vojtech Exp $
+ * $Id: via82cxxx.c,v 2.3 2000/09/12 12:52:60 vojtech Exp $
*
* Copyright (c) 2000 Vojtech Pavlik
*
@@ -18,17 +18,21 @@
*
* southbridges, which can be found in
*
- * VIA Apollo VP, VPX, VPX/97, VP2, VP2/97, VP3, MVP3, MVP4
- * VIA Apollo Pro, Pro Plus, Pro 133, Pro 133A, ProMedia 601, ProSavage 605
- * VIA Apollo KX133, KT133
- * AMD-640, AMD-750 IronGate
- *
- * chipsets. Supports PIO 0-5, MWDMA 0-2, SWDMA 0-2 and
- * UDMA 0-5 (includes UDMA33, 66 and 100) modes. UDMA100 isn't possible
- * on any of the supported chipsets yet.
- *
- * UDMA66 and higher modes are autodetected only in case the BIOS has enabled them.
- * To force UDMA66, use 'ide0=ata66' or 'ide1=ata66' on the kernel command line.
+ * VIA Apollo VP, VPX, VPX/97, VP2, VP2/97, VP3, MVP3, MVP4, Pro, Pro Plus,
+ * Pro 133, Pro 133A, ProMedia 601, ProSavage 605, ProSavage PM133, KX133, KT133
+ * PC-Chips VXPro, VXPro+, TXPro-III, TXPro-AGP, ViaGra, BXToo, BXTel
+ * AMD 640, 640 AGP, 750 IronGate
+ * ETEQ 6618, 6628, 6638
+ * Micron Samurai
+ *
+ * chipsets. Supports
+ *
+ * PIO 0-5, MWDMA 0-2, SWDMA 0-2 and UDMA 0-5
+ *
+ * (includes UDMA33, 66 and 100) modes. UDMA100 isn't possible
+ * on any of the supported chipsets yet. UDMA66 and higher modes are
+ * autodetected only in case the BIOS has enabled them. To force UDMA66,
+ * use 'ide0=ata66' or 'ide1=ata66' on the kernel command line.
*/
/*
@@ -88,17 +92,18 @@
static const struct {
char *name;
unsigned short id;
+ unsigned char rev;
unsigned char speed;
} via_isa_bridges[] = {
- { "vt8231", PCI_DEVICE_ID_VIA_8231, XFER_UDMA_4 },
- { "vt82c686a", PCI_DEVICE_ID_VIA_82C686, XFER_UDMA_4 },
- { "vt82c596b", PCI_DEVICE_ID_VIA_82C596, XFER_UDMA_4 },
- { "vt82c596a", PCI_DEVICE_ID_VIA_82C596, XFER_UDMA_2 },
- { "vt82c586b", PCI_DEVICE_ID_VIA_82C586_0, XFER_UDMA_2 },
- { "vt82c586a", PCI_DEVICE_ID_VIA_82C586_0, XFER_UDMA_2 },
- { "vt82c586", PCI_DEVICE_ID_VIA_82C586_0, XFER_MW_DMA_2 },
- { "Unknown SouthBridge",0, XFER_UDMA_4 },
- { "Unknown SouthBridge",0, XFER_UDMA_2 },
+ { "vt8231", PCI_DEVICE_ID_VIA_8231, 0x00, XFER_UDMA_4 },
+ { "vt82c686a", PCI_DEVICE_ID_VIA_82C686, 0x10, XFER_UDMA_4 },
+ { "vt82c686", PCI_DEVICE_ID_VIA_82C686, 0x00, XFER_UDMA_4 },
+ { "vt82c596b", PCI_DEVICE_ID_VIA_82C596, 0x10, XFER_UDMA_4 },
+ { "vt82c596a", PCI_DEVICE_ID_VIA_82C596, 0x00, XFER_UDMA_2 },
+ { "vt82c586b", PCI_DEVICE_ID_VIA_82C586_0, 0x30, XFER_UDMA_2 },
+ { "vt82c586a", PCI_DEVICE_ID_VIA_82C586_0, 0x20, XFER_UDMA_2 },
+ { "vt82c586", PCI_DEVICE_ID_VIA_82C586_0, 0x00, XFER_MW_DMA_2 },
+ { NULL }
};
static unsigned char via_config;
@@ -109,10 +114,6 @@
* PIO 0-5, MWDMA 0-2 and UDMA 0-5 timings (in nanoseconds).
* These were taken from ATA/ATAPI-6 standard, rev 0a, except
* for PIO 5, which is a nonstandard extension.
- *
- * Dilemma: 8-bit (register) PIO accesses need more relaxed timing.
- * Hopefully the chipset is taking care of that. If it doesn't
- * do so, define VIA_USE_8_BIT_TIMING to see if it helps.
*/
#ifndef XFER_PIO_5
@@ -148,15 +149,9 @@
Re: Update Linux 2.4 Status/TODO list
On Tue, Sep 12, 2000 at 11:37:57PM -0700, David Ford wrote: > > > 4. Boot Time Failures > > > > > > * Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC > > >Versa LX with PIIX tuning) > > > > If this is a rare version of the BX/LX that has a no fix errata, then it > > will be messy to issue resets to get out of the loop. > > > > > * PIIXn tuning can hang laptop (2.4.0-test8-pre6, David Ford) > > > > Need more details of how APM/ACPI is dorking with DMA settins by the OEM. > > These two are both reported by me, are the same issue. The exact same kernel, > one with PIIXn tuning enabled, will hang the hardware on boot requiring a > physical power loss to restart. > > No tuning options applied, only the capability enabled in the kernel, makes it > crash. > > If necessary I can again provide the boot log and a verbose lspci and whatever > else is desired. I'll even let you log in and look at it. I can look into this. I don't guarantee I'll find the problem, but I've got all the PIIX datasheets handy now and some time on my hands ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Update Linux 2.4 Status/TODO list
On Tue, Sep 12, 2000 at 11:55:55PM -0700, David Ford wrote: > > * Possible ppp problem (fail to connect; may be user error; reported > >by Matt Spong; claims worked on 2.3.40) > > I use ppp frequently w/ current kernels, works fine. Most likely an user error, yes, for 2.4.0 the latest pppd is needed, older pppd's causing the above described error. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][minor] Re: [patch] VIA IDE driver v2.3
On Thu, Sep 14, 2000 at 01:36:39AM +0200, Bartlomiej Zolnierkiewicz wrote: > On Tue, 12 Sep 2000, Vojtech Pavlik wrote: > > > Anyone interested, please test this out, if it is as problemless as > > version 2.1, I'll send this to Linus for inclusion in the kernel. > > Seems to be ok. Works ok. Please consider appling *crappy* patch > which corrects one entry in /proc/ide/via and beautifies code :-) Thanks; applied. By the way, what would you think about getting rid of amd7409.c and integrating it's functionality to the VIA driver? The difference between the VIA and AMD chipset is in two bits in one register -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][minor] Re: [patch] VIA IDE driver v2.3
Hi! Still, the 7411 is just an extension of the 7409 in that it adds some extra meaning to some register bits. This is still similar enough to say the vt82c586b to be in the same driver IMHO. The only differences are in UDMA mode and UDMA mode is different even between different VIA chips. I don't know about the 7403 (amd-745?) chip. Do you have any docs for it? Can you send them to me? I'd bet the 7403 is very very much like the amd-645 chip. Vojtech On Thu, Sep 14, 2000 at 12:23:01AM -0700, Andre Hedrick wrote: > > No, because there is a Ultra 100 7411 that is to be out and the fixes for > Cobra 7403 need to be added to make it a generic amd74xx.c > > Cheers, > > On Thu, 14 Sep 2000, Vojtech Pavlik wrote: > > > On Thu, Sep 14, 2000 at 01:36:39AM +0200, Bartlomiej Zolnierkiewicz wrote: > > > > > On Tue, 12 Sep 2000, Vojtech Pavlik wrote: > > > > > > > Anyone interested, please test this out, if it is as problemless as > > > > version 2.1, I'll send this to Linus for inclusion in the kernel. > > > > > > Seems to be ok. Works ok. Please consider appling *crappy* patch > > > which corrects one entry in /proc/ide/via and beautifies code :-) > > > > Thanks; applied. By the way, what would you think about getting rid of > > amd7409.c and integrating it's functionality to the VIA driver? The > > difference between the VIA and AMD chipset is in two bits in one > > register > > > > -- > > Vojtech Pavlik > > SuSE Labs > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > Andre Hedrick > The Linux ATA/IDE guy -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
> Okay who can teach me how to force hooks and ram this down the PPC
>
> pci_write_config_word(dev, PCI_COMMAND, 0x05);
>
> I have all the address registered.
> My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> alive. Thus I get some of the most beuatiful lockups ever.
> I suspect that this needs to be handled down in the arch.
>
> ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
>
> Basically I can not get the IO's active, regardless of BIOS on the card.
> Yes this is the old trick that used to work of making ix86 cards run in
> non ix86-pci slots.
>
> Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> under Mac OS, but the IO's are not enable in linux and it crash like a big
> dog also.
The same happens for OHCI on new Macs. The correct function to use is:
pci_enable_device(dev);
This function will enable the i/o, mem and irqs, and assign them if they
were not assigned for some reason, too.
And you should use it on any PCI device you want to use before using
it, on all architectures. Also check its return value.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
VIA IDE v3.0 preview
Hi!
For those who are interested in testing my VIA IDE code, here is another
release that configures the thing even better. IDE timing is black
magic. ;) It's a drop-in replacement for the 2.1 driver.
I'm interested in failure/success reports.
Thanks.
--
Vojtech Pavlik
SuSE Labs
#ifndef _IDE_TIMING_H
#define _IDE_TIMING_H
/*
* $Id: ide-timing.h,v 1.0 2000/09/17 00:34:56 vojtech Exp $
*
* Copyright (c) 1999-2000 Vojtech Pavlik
*
* Sponsored by SuSE
*/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Should you need to contact me, the author, you can do so either by
* e-mail - mail your message to <[EMAIL PROTECTED]>, or by paper mail:
* Vojtech Pavlik, Ucitelska 1576, Prague 8, 182 00 Czech Republic
*/
#include
#ifndef XFER_PIO_5
#define XFER_PIO_5 0x0d
#endif
struct ide_timing {
short mode;
short setup;/* t1 */
short act8b;/* t2 for 8-bit io */
short rec8b;/* t2i for 8-bit io */
short cyc8b;/* t0 for 8-bit io */
short active; /* t2 or tD */
short recover; /* t2i or tK */
short cycle;/* t0 */
short udma; /* t2CYCTYP/2 */
};
/*
* PIO 0-5, MWDMA 0-2 and UDMA 0-5 timings (in nanoseconds).
* These were taken from ATA/ATAPI-6 standard, rev 0a, except
* for PIO 5, which is a nonstandard extension.
*/
static struct ide_timing ide_timing[] = {
{ XFER_UDMA_5, 0, 0, 0, 0, 0, 0, 0, 20 },
{ XFER_UDMA_4, 0, 0, 0, 0, 0, 0, 0, 30 },
{ XFER_UDMA_3, 0, 0, 0, 0, 0, 0, 0, 45 },
{ XFER_UDMA_2, 0, 0, 0, 0, 0, 0, 0, 60 },
{ XFER_UDMA_1, 0, 0, 0, 0, 0, 0, 0, 80 },
{ XFER_UDMA_0, 0, 0, 0, 0, 0, 0, 0, 120 },
{ XFER_MW_DMA_2, 25, 0, 0, 0, 70, 25, 120, 0 },
{ XFER_MW_DMA_1, 45, 0, 0, 0, 80, 50, 150, 0 },
{ XFER_MW_DMA_0, 60, 0, 0, 0, 215, 215, 480, 0 },
{ XFER_SW_DMA_2, 60, 0, 0, 0, 120, 120, 240, 0 },
{ XFER_SW_DMA_1, 90, 0, 0, 0, 240, 240, 480, 0 },
{ XFER_SW_DMA_0, 120, 0, 0, 0, 480, 480, 960, 0 },
{ XFER_PIO_5, 20, 50, 30, 100, 50, 30, 100, 0 },
{ XFER_PIO_4, 25, 70, 25, 120, 70, 25, 120, 0 },
{ XFER_PIO_3, 30, 80, 70, 180, 80, 70, 180, 0 },
{ XFER_PIO_2, 30, 290, 40, 330, 100, 90, 240, 0 },
{ XFER_PIO_1, 50, 290, 93, 383, 125, 100, 383, 0 },
{ XFER_PIO_0, 70, 290, 240, 600, 165, 150, 600, 0 },
{ XFER_PIO_SLOW, 120, 290, 240, 960, 290, 240, 960, 0 },
{ -1 }
};
#define IDE_TIMING_SETUP0x01
#define IDE_TIMING_ACT8B0x02
#define IDE_TIMING_REC8B0x04
#define IDE_TIMING_CYC8B0x08
#define IDE_TIMING_8BIT 0x0e
#define IDE_TIMING_ACTIVE 0x10
#define IDE_TIMING_RECOVER 0x20
#define IDE_TIMING_CYCLE0x40
#define IDE_TIMING_UDMA 0x80
#define IDE_TIMING_ALL 0xff
#define MIN(a,b)((a)<(b)?(a):(b))
#define MAX(a,b)((a)>(b)?(a):(b))
#define FIT(v,min,max) MAX(MIN(v,max),min)
#define ENOUGH(v,unit) (((v)-1)/(unit)+1)
#define EZ(v,unit) ((v)?ENOUGH(v,unit):0)
#define XFER_MODE 0xf0
#define XFER_UDMA_100 0x44
#define XFER_UDMA_660x42
#define XFER_UDMA 0x40
#define XFER_MWDMA 0x20
#define XFER_SWDMA 0x10
#define XFER_EPIO 0x01
#define XFER_PIO0x00
static short ide_find_best_mode(ide_drive_t *drive, int map)
{
struct hd_driveid *id = drive->id;
short best = 0;
if (!id)
return XFER_PIO_SLOW;
if ((map & XFER_UDMA) && (id->field_valid & 4)) { /* Want UDMA and UDMA
bitmap valid */
if (map & XFER_UDMA_100)
if ((best = (id->dma_ultra & 0x0020) ? XFER_UDMA_5 : 0))
return best;
if (map & XFER_UDMA_66)
if ((best = (id->dma_ultra & 0x0010) ? XFER_UDMA_4 :
(id->dma_ultra & 0x0008) ? XFER_UDMA_3 : 0))
return
[patch] Fixes for VIA driver
Hi!
While developing the next versions, I found two 'obvious bugs' in the
2.1 version. They are not very harmful. The attached patch fixes them.
--
Vojtech Pavlik
SuSE Labs
--- linux/drivers/ide/via82cxxx.c.old Mon Sep 18 22:10:10 2000
+++ linux/drivers/ide/via82cxxx.c Mon Sep 18 22:13:29 2000
@@ -1,5 +1,5 @@
/*
- * $Id: via82cxxx.c,v 2.1 2000/08/29 01:34:60 vojtech Exp $
+ * $Id: via82cxxx.c,v 2.1a 2000/09/18 22:10:60 vojtech Exp $
*
* Copyright (c) 2000 Vojtech Pavlik
*
@@ -140,8 +140,8 @@
{ XFER_MW_DMA_1, "MDMA1", 45, 80, 50, 150, 0 },
{ XFER_MW_DMA_0, "MDMA0", 60, 215, 215, 480, 0 },
- { XFER_SW_DMA_0, "SDMA0", 60, 120, 120, 240, 0 },
- { XFER_SW_DMA_0, "SDMA0", 90, 240, 240, 480, 0 },
+ { XFER_SW_DMA_2, "SDMA2", 60, 120, 120, 240, 0 },
+ { XFER_SW_DMA_1, "SDMA1", 90, 240, 240, 480, 0 },
{ XFER_SW_DMA_0, "SDMA0",120, 480, 480, 960, 0 },
{ XFER_PIO_5, "PIO5", 20, 50, 30, 100, 0 },
@@ -214,7 +214,7 @@
via_print("BM IDE Status Register Read Retry: %s", (t & 8) ? "on" : "off" );
pci_read_config_byte(dev, VIA_MISC_2, &t);
- sprintf(p, "Interrupt Steering Swap: %s", (t & 64) ? "on" : "off");
+ via_print("Interrupt Steering Swap:%s", (t & 64) ? "on" : "off");
pci_read_config_byte(dev, VIA_MISC_3, &t);
via_print("Max DRDY Pulse Width: %s%s", via_control3[(t &
0x03)], (t & 0x03) ? "PCI clocks" : "");
Re: New via82cxxx.c - still not working here
; hdc: hdc1 hdc2 hdc3 hdc4 < hdc5 > > > VFS: Mounted root (ext2 filesystem) readonly. > > Freeing unused kernel memory: 188k freed > > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > > Adding Swap: 136544k swap-space (priority -1) > > Linux Tulip driver version 0.9.10 (September 6, 2000) > > eth0: Macronix 98715 PMAC rev 32 at 0xe800, 00:80:AD:00:DB:BE, IRQ 11. > > isapnp: Scanning for Pnp cards... > > isapnp: Card '33600 bps FAX/Voice Internal Modem ' > > isapnp: 1 Plug & Play card detected total > > Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI >ISAPNP enabled > > ttyS00 at 0x03f8 (irq = 4) is a 16550A > > ttyS01 at 0x02f8 (irq = 3) is a 16550A > > ttyS02 at port 0x03e8 (irq = 5) is a 16550A > > CSLIP: code copyright 1989 Regents of the University of California > > PPP generic driver version 2.4.1 > > ip_tables: (c)2000 Netfilter core team > > ip_conntrack (512 buckets, 4096 max) > > PPP BSD Compression module registered > > PPP Deflate Compression module registered > > > > > > /proc/pci: > > PCI devices found: > > Bus 0, device 0, function 0: > > Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 34). > > Prefetchable 32 bit memory at 0xe000 [0xe3ff]. > > Bus 0, device 1, function 0: > > PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] >(rev 0). > > Master Capable. No bursts. Min Gnt=12. > > Bus 0, device 7, function 0: > > ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 9). > > Bus 0, device 7, function 1: > > IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6). > > Master Capable. Latency=32. > > I/O at 0xe000 [0xe00f]. > > Bus 0, device 7, function 3: > > Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 0). > > Bus 0, device 8, function 0: > > Ethernet controller: Macronix, Inc. [MXIC] MX987x5 (rev 32). > > IRQ 11. > > Master Capable. Latency=32. Min Gnt=8.Max Lat=56. > > I/O at 0xe800 [0xe8ff]. > > Non-prefetchable 32 bit memory at 0xe900 [0xe9ff]. > > Bus 0, device 11, function 0: > > Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 6). > > IRQ 10. > > Master Capable. Latency=64. Min Gnt=12.Max Lat=128. > > I/O at 0xec00 [0xec3f]. > > Bus 1, device 0, function 0: > > VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 21). > > IRQ 11. > > Master Capable. Latency=32. Min Gnt=5.Max Lat=1. > > Non-prefetchable 32 bit memory at 0xe400 [0xe4ff]. > > Prefetchable 32 bit memory at 0xe600 [0xe7ff]. > > > > > > /proc/ide/via: > > Command register = 0x7 > > Master Read Cycle IRDY 1 Wait State > > Master Write Cycle IRDY 1 Wait State > > FIFO Output Data 1/2 Clock Advance: off > > Bus Master IDE Status Register Read Retry: on > > Latency timer = 32 (max. = 0) > > Interrupt Steering Swap: off > > --Primary IDESecondary IDE- > > both channels togth: yes yes > > Prefetch Buffer : on on > > Post Write Buffer: on on > > FIFO Conf/Chan. : 08 08 > > Threshold Prim. : 1/2 1/2 > > Read DMA FIFO flush: on on > > End Sect. FIFO flush: on on > > Max DRDY Pulse Width: No limitation > > Bytes Per Sector: 512 512 > > --drive0--drive1---drive0--drive1 > > DMA enabled:yes yes yes no > > Act Pls Width: 03 04 11 11 > > Recovery Time: 02 02 09 09 > > Add. Setup T.: 4T 4T 4T 4T > > --UDMA-Timing-Control > > Enable Meth.:1 00 0 > > Enable: yes no no no > > Transfer Mode: PIO DMA PIO DMA > > Cycle Time: 3T 5T 5T 5T > > > > > > > > Dan Aloni (dax) > > [EMAIL PROTECTED] > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > Andre Hedrick > The Linux ATA/IDE guy -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch - critical] Fixes for VIA IDE driver
Hi!
I have found a couple bugs in the VIA IDE kernel I'm now maintaining
that manifest themselves on hardware I don't have:
1) On old SWDMA devices the timing is programmed incorrectly. This will
result in DMA timeouts or data corruption.
2) On UDMA devices used with vt82c596a (old buggy VIA MobileSouth), the
chip will get confused, which will result in DMA timeouts and UDMA
being disabled. No data corruption here, just very poor performance.
3) One extra sprintf was forgotten in the via_display_info function.
This is harmless, but a bug nevertheless.
Here goes a detailed description of the patch that fixes the above three
bugs:
Chunk1:
Changes version number
Chunk2:
Removes UDMA66 unknown southbridge entry. We can't try to program
unknown southbridges to UDMA66, because that can result in crashes
(as shown by vt82c596a). UDMA33 should be safe, because the only
southbridge that doesn't support it is vt82c586.
Chunk3:
Fix SWDMA modes. By a typo there were 0's everywhere. This is
important, without this fix SWDMA devices will be programmed
incorrectly.
Chunk4:
Change version number in /proc
Chunk5:
Remove the sprintf().
Chunk6:
Don't program UDMA66 enable bit on UDMA33 controllers. They *should*
ignore it, but 596a doesn't, resulting in timeouts on boot. This is
critical. Also don't program UDMA at all on the old vt82c586.
Chunk7:
The correct way to check for 596a.
Chunk8:
Remove the old check for 596a. It doesn't work, because the 596a doesn't
ignore the UDMA66 bits as it should. Don't set UDMA66 on 596a at
all, it causes crashes. Critical.
I hope this will get into test9-pre6, because otherwise it's quite
unusable for vt82c596a users.
TIA.
--
Vojtech Pavlik
SuSE Labs
--- linux-old/drivers/ide/via82cxxx.c Wed Sep 6 17:07:56 2000
+++ linux/drivers/ide/via82cxxx.c Wed Sep 20 23:33:08 2000
@@ -1,5 +1,5 @@
/*
- * $Id: via82cxxx.c,v 2.1 2000/08/29 01:34:60 vojtech Exp $
+ * $Id: via82cxxx.c,v 2.1b 2000/09/20 23:19:60 vojtech Exp $
*
* Copyright (c) 2000 Vojtech Pavlik
*
@@ -97,7 +97,6 @@
{ "vt82c586b", PCI_DEVICE_ID_VIA_82C586_0, XFER_UDMA_2 },
{ "vt82c586a", PCI_DEVICE_ID_VIA_82C586_0, XFER_UDMA_2 },
{ "vt82c586", PCI_DEVICE_ID_VIA_82C586_0, XFER_MW_DMA_2 },
- { "Unknown SouthBridge",0, XFER_UDMA_4 },
{ "Unknown SouthBridge",0, XFER_UDMA_2 },
};
@@ -140,8 +139,8 @@
{ XFER_MW_DMA_1, "MDMA1", 45, 80, 50, 150, 0 },
{ XFER_MW_DMA_0, "MDMA0", 60, 215, 215, 480, 0 },
- { XFER_SW_DMA_0, "SDMA0", 60, 120, 120, 240, 0 },
- { XFER_SW_DMA_0, "SDMA0", 90, 240, 240, 480, 0 },
+ { XFER_SW_DMA_2, "SDMA2", 60, 120, 120, 240, 0 },
+ { XFER_SW_DMA_1, "SDMA1", 90, 240, 240, 480, 0 },
{ XFER_SW_DMA_0, "SDMA0",120, 480, 480, 960, 0 },
{ XFER_PIO_5, "PIO5", 20, 50, 30, 100, 0 },
@@ -193,7 +192,7 @@
via_print("--VIA BusMastering IDE Configuration");
- via_print("Driver Version: 2.1");
+ via_print("Driver Version: 2.1b");
pci_read_config_byte(isa_dev, PCI_REVISION_ID, &t);
via_print("South Bridge: VIA %s rev %#x",
via_isa_bridges[via_config].name, t);
@@ -213,9 +212,6 @@
via_print("FIFO Output Data 1/2 Clock Advance: %s", (t & 16) ? "on" : "off" );
via_print("BM IDE Status Register Read Retry: %s", (t & 8) ? "on" : "off" );
- pci_read_config_byte(dev, VIA_MISC_2, &t);
- sprintf(p, "Interrupt Steering Swap: %s", (t & 64) ? "on" : "off");
-
pci_read_config_byte(dev, VIA_MISC_3, &t);
via_print("Max DRDY Pulse Width: %s%s", via_control3[(t &
0x03)], (t & 0x03) ? "PCI clocks" : "");
@@ -337,15 +333,13 @@
* UDMA cycle
*/
- if (via_timing[i].udma) {
- t = 0xe8;
- if (via_isa_bridges[via_config].speed >= XFER_UDMA_4)
- t |= FIT(ENOUGH(via_timing[i].udma, T >> 1) - 2, 0, 7);
- else
- t |= FIT(ENOUGH(via_timing[i].udma, T ) - 2, 0, 3);
- } else t = 0x0b;
+ switch(via_isa_bridges[via_config].speed) {
+ case XFER_UDMA_2: t = via_timing[i].udma ? (0x60 |
+(FIT(via_timing[i].udma, 2, 5) - 2)) : 0x03; break;
+ case XFER_UDMA_4: t = via_timing[i].udma ? (0xe8 |
+(FIT(via_ti
Re: [patch] mousedev.c
On Fri, Sep 22, 2000 at 12:03:20AM +0900, Yoichi Imai wrote:
> I think it's a bug.
I think it's a feature.
> --- linux-2.4.0-test8/drivers/input/mousedev.c Wed Aug 23 01:06:31 2000
> +++ linux/drivers/input/mousedev.c Thu Sep 21 22:20:22 2000
> @@ -121,12 +121,12 @@
> case BTN_TOUCH:
> case BTN_LEFT: index = 0; break;
> case BTN_4:
> - case BTN_EXTRA: if (list->mode > 1)
>{ index = 4; break; }
> + case BTN_EXTRA: if (list->mode > 1)
>index = 4; break;
> case BTN_STYLUS:
> case BTN_1:
> case BTN_RIGHT: index = 1; break;
> case BTN_3:
> - case BTN_SIDE: if (list->mode > 1)
>{ index = 3; break; }
> + case BTN_SIDE: if (list->mode > 1)
>index = 3; break;
> case BTN_2:
> case BTN_STYLUS2:
> case BTN_MIDDLE: index = 2; break;
>
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Wed, Oct 18, 2000 at 10:14:01PM +0100, Alan Cox wrote: > > The only other users are 8390.h and a couple of mtd things. I don't see > > why this stuff cannot be handled in userspace with /etc/modules.conf ... > > > > should get_module_symbol() die ? > > You need it to dynamically bind to another module if its loaded and still be > loadable if that module/facility is not present. Its dynamic linking for kernel > modules Well, this is usually handled by a third module that takes care of registering/unregistering the existence of the two modules that need to be possible to load/unload separately. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Wed, Oct 18, 2000 at 02:25:41PM -0400, Rik Faith wrote: > Just to clarify -- my use of get_module_symbol has nothing to do with > load order. It has to do with allowing a drm module to work with or > without the agpgart module loaded. > > If there's some other way to do this, I'll be happy to move to that. > I'd like to preserve the ability to have one driver which works with > each chipset family and not have to have separate drivers for PCI and > AGP cards (or, rather, to have fewer instances of the drivers -- they > already depend on SMP and MODVERSIONS, and that's a lot of overhead > already if you just want to play Q3A :). I'd also like a dual-head > system to be able to load the same drm module and just have it work > for both the agp and the pci cards (this isn't supported yet, in case > anyone is wondering). Just do it the way most other subsystems do it - have a drm_[un]register_driver() functions, which are exported by the DRM generic module and have the card-specific modules call that. This way the DRM generic module will know what drivers are loaded. For an example see the PCI subsystem, USB, Input, chardevices, TTY layer, whatever ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Topic for discussion: OS Design
On Sun, Oct 22, 2000 at 04:29:19PM -0600, Dwayne C . Litzenberger wrote: > 5. Linus tends to blame patches for inadequacies in the kernel. The PC > speaker driver is a perfect example: No driver should have to do something > "dirty" in order to function, because the operating system should provide > clean ways to do this. > It would seem that a microkernel design would fix most of these problems. Well, try to implement the PC speaker driver in a microkernel. It'll have to be even uglier (and much more when at that) than what the driver is now. And, yes, this all has been discussed many many times around with little benefit. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Possible critical VIA vt82c686a chip bug
Hi!
I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge
revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2:
When there is heavy disk activity (several tars running concurrently on
UDMA66 drive, or tar'ing from one UDMA66 drive to another over two
channels), the system time, namely gettimeofday() goes crazy - now and
then it advances the time about 1:20 for a fraction of a second and then
changes back to normal time.
This causes X to blank the screen when it should not, squid to terminate
connections with a 'timeout' randomly and other nice effects.
This is because the system timer (i8253) counter is reset to a wrong
value. Possible causes include temperature problems (although the chip
ambient temp is OK), or some crosstalk stuff within the chip.
Now I'd like to know if I have a faulty chip, faulty motherboard or
whether this problem exists in more chips as well.
If anyone owning a motherboard with the vt82c686a chip (VIA with UDMA66
and audio), could test this, I'd appreciate that.
Attached is a patch that makes the problems go away by reprogramming the
chip in the problematic case.
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-test10-pre5-old/arch/i386/kernel/time.c linux/arch/i386/kernel/time.c
--- linux-test10-pre5-old/arch/i386/kernel/time.c Wed Oct 25 12:05:22 2000
+++ linux/arch/i386/kernel/time.c Thu Oct 26 15:29:23 2000
@@ -492,6 +492,14 @@
count = inb_p(0x40);/* read the latched count */
count |= inb(0x40) << 8;
+
+ if (count > LATCH-1) {
+ outb_p(0x34, 0x43);
+ outb_p(LATCH & 0xff, 0x40);
+ outb(LATCH >> 8, 0x40);
+ count = LATCH - 1;
+ }
+
spin_unlock(&i8253_lock);
count = ((LATCH-1) - count) * TICK_SIZE;
Re: Possible critical VIA vt82c686a chip bug
On Thu, Oct 26, 2000 at 03:58:21PM +0200, Yoann Vandoorselaere wrote: > > I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge > > revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2: > > > > When there is heavy disk activity (several tars running concurrently on > > UDMA66 drive, or tar'ing from one UDMA66 drive to another over two > > channels), the system time, namely gettimeofday() goes crazy - now and > > then it advances the time about 1:20 for a fraction of a second and then > > changes back to normal time. > > > > This causes X to blank the screen when it should not, > > Really strange, I'm getting exactly the same problem on a machine > with the same chipset... Could you send me your 'lspci -vvxxx' to confirm it's the very same chip? > > Now I'd like to know if I have a faulty chip, faulty motherboard or > > whether this problem exists in more chips as well. > > I've changed my motherboard thinking it was a default of it. > it is not. Ok, so this means it's not the motherboard and it's not just my chip. > > If anyone owning a motherboard with the vt82c686a chip (VIA with UDMA66 > > and audio), could test this, I'd appreciate that. > > I've this kind of motherboard without audio. Well, the audio function is integrated in the chip, possibly just disabled. > > Attached is a patch that makes the problems go away by reprogramming the > > chip in the problematic case. > > I'll try it ASAP, then do a feedback. Ok, thanks. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug
On Thu, Oct 26, 2000 at 04:13:51PM +0200, Yoann Vandoorselaere wrote: > > > > I've found a bug in my VIA SuperSouth (vt82c686a) chip (ISA bridge > > > > revision 0x12, silicon rev CD) on my FIC VA-503A rev 1.2: > > > > > > > > When there is heavy disk activity (several tars running concurrently on > > > > UDMA66 drive, or tar'ing from one UDMA66 drive to another over two > > > > channels), the system time, namely gettimeofday() goes crazy - now and > > > > then it advances the time about 1:20 for a fraction of a second and then > > > > changes back to normal time. > > > > > > > > This causes X to blank the screen when it should not, > > > > > > Really strange, I'm getting exactly the same problem on a machine > > > with the same chipset... > > > > Could you send me your 'lspci -vvxxx' to confirm it's the very same > > chip? > > 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) > Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping+ SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Oh, this is a newer revision than mine (silicon CF or CG) - I'd expect that one not to have the problem ... well, it seems it's more widespread than I expected. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug
On Thu, Oct 26, 2000 at 04:04:16PM +0100, Mark Cooke wrote: > On 26 Oct 2000, Yoann Vandoorselaere wrote: > > > This is an athlon 750 machine, with scsi and ide a disk... > > I've tryed to see where the problem was comming from for age > > ( the problem is what you describe and it happen after some time > > (1 to 24 hour, it depend) and often while or after heavy I/O... > >the only fix is to reboot the machine. ) > > xset s off will fix it (least it does for me), without needing a > reboot. At least until the 'next time'. It fixes the blanking, but squid, wmclock (and other apps using gettimeofday()) will still cause trouble. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote: > > On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote: > > > > > ... > > > > > > Have you any idea what is the relation between time and this chip ? > > > > > > Also, I'm experiencing the problem for several month on my > > > workstation and I never could find where it was comming from... > > > how did you do ? > > > > Well, it integrates both the i8253 PIT and the vt82c586 IDE controller. > > > > I first located the wrong time was coming from gettimeofday() and not > > from the other sources of time the kernel provides. And then I was > > tracking the problem (which actually is an underflow - the chip bug > > causes some time offset variables go negative - 0x microseconds > > is about 1:20 hours). And this way I got to the spot where the patch > > cures the problem. > > Ok, here is what I experienced : > > First what is strange is that : > - I'm using SCSI > - I just have an IDE disk for mp3. > The IDE subsystem is never used heavilly... > > I've experienced the problem after some time of > heavy scsi IO, my screen under X was going black (like with dpms) > When I was moving the mouse, the image was coming back > for < 1 seconds, then black screen... > > The only fix was to kill X then to reboot. > > Anyway, thanks for your explaination... > I'll do a feedback for this patch ASAP. Interesting. If it's caused by SCSI as well (might be), then it's not caused by heavy IDE activity but rather than that it could be heavy BusMastering activity instead (The IDE chip does BM as well). I'm still wondering if it could be a Linux kernel bug (bad/concurrent accesses to the i8253 registers), this has to be checked. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 12:04:21PM -0400, Richard B. Johnson wrote: > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > to the timer. It writes 0 to the control-word for timer 0. This > does the following: > > o Selects timer 0. > o Latches the timer. > o Selects mode 0. > o Programs it to a 16 bit counter. > > The result is a latched (stopped) counter. Bits 5 and 4 should have been > selected. Then you read bits 0-7 from 0x40, followed by bits 8-15 from > the same port. > > Also, there is no spin-lock protecting access to these ports. If anybody > else is mucking with the timer, all bets are off. Well, at least on 2.4.0-test9, the above timing code is #ifed to DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in include/linux/ide.h. So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote: > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > > > to the timer. It writes 0 to the control-word for timer 0. This > > > does the following: > [Snipped...] > > > > Well, at least on 2.4.0-test9, the above timing code is #ifed to > > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in > > include/linux/ide.h. > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > they're not probably the cause of the problem we see here. > > Okay, good. Ok, here is a list of places within the kernel that access the PIT timer, plus the method of locking (i386 arch only): Usage: Lock method: arch/i386/kernel/time.c:170:spin_lock() arch/i386/kernel/time.c:491:spin_lock() arch/i386/kernel/time.c:575:none (init) arch/i386/kernel/i8259.c:491: none (init) arch/i386/kernel/apm.c:871: cli() arch/i386/kernel/apic.c:398:spin_lock_irqsave() drivers/char/vt.c:121: cli() drivers/char/ftape/lowlevel/ftape-calibr.c:80: cli() drivers/char/ftape/lowlevel/ftape-calibr.c:99: cli() drivers/char/joystick/analog.c:142: cli() __cli() drivers/char/joystick/gameport.c:66:cli() drivers/ide/hd.c:137: cli() drivers/ide/ide.c:206: __cli() I guess we'll need to fix this. While races here are not likely (the most likely is a beep by vt.c at a wrong moment), they're possible. However, these don't seem to be the cause of the problem we see here anyway. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 10:11:54PM +0200, Yoann Vandoorselaere wrote: > > > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > > > > > to the timer. It writes 0 to the control-word for timer 0. This > > > > > does the following: > > > [Snipped...] > > > > > > > > Well, at least on 2.4.0-test9, the above timing code is #ifed to > > > > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in > > > > include/linux/ide.h. > > > > > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > > > they're not probably the cause of the problem we see here. > > > > > > Okay, good. > > > > Ok, here is a list of places within the kernel that access the PIT > > timer, plus the method of locking (i386 arch only): > > [...] > > Ok, I just tested if the problem was always present without > the IDE subsystem... > > The answer is it is not... so it isn't an IDE problem. Uh, guess too many negations. You wanted to say that the problem was present even when you disabled the IDE subsystem, right? So now it seems that possibly enough PCI traffic / busmastering traffic can cause the problem ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote: > yop, I 've done : > > make -j10 World > in the xfree tree and simulateously : > > while true; do make dep && make clean && make bzImage; done > in the kernel tree Now it'd be nice to verify that the problem also happens when the system is not running out of memory (which -j10 quite causes I think) ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
