more into the code to
comment on the implementation of the dynrela stuff.
--
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
would apply for kGraft
automation.)
So I believe including one or more human produced examples makes most sense.
--
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
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
I also don't think including the whole kpatch automation into the kernel
tree is a viable development
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think
the consistency model should look like.
PPS.: I haven't included any handling of changed data structures in
this, that's another set of properties.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
a SWITCH_KERNEL for the 10% of complex patches. This because
(LEAVE_PATCHED_SET) SWITCH_THREAD finishes much quicker. But I'm biased
there. ;)
It seems more and more to me that we will actually want the more
powerful engine coping with the various options.
--
Vojtech Pavlik
Director SUSE Labs
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
LEAVE_PATCHED_SET
LEAVE_KERNEL
.
--
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/
/exit point over which
state isn't transferred. That is a lot of work, though, and has other
drawbacks, particularly in the realtime space.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Thu, Feb 19, 2015 at 11:32:55AM -0600, Josh Poimboeuf wrote:
On Thu, Feb 19, 2015 at 06:19:29PM +0100, Vojtech Pavlik wrote:
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
On Thu, Feb 19, 2015 at 10:24
On Thu, Feb 19, 2015 at 10:52:51AM +0100, Peter Zijlstra wrote:
On Wed, Feb 18, 2015 at 09:44:44PM +0100, Vojtech Pavlik wrote:
For live patching it doesn't matter whether code is running, sleeping or
frozen.
What matters is whether there is state before patching that may not be
valid
function, but it'd be a bit crazy indeed.
--
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
On Thu, Feb 19, 2015 at 11:03:53AM -0600, Josh Poimboeuf wrote:
On Thu, Feb 19, 2015 at 05:33:59PM +0100, Vojtech Pavlik wrote:
On Thu, Feb 19, 2015 at 10:24:29AM -0600, Josh Poimboeuf wrote:
No, these tasks will _never_ make syscalls. So you need to guarantee
they don't accidentally
);
The s390x arch used to have a TIF_SYSCALL, which was doing exactly that (well,
negated). I think it would work well, but it isn't entirely for free: two
instructions per syscall and an extra TIF bit, which are (near) exhausted on
some archs.
--
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from
implementing.
--
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/
translation layer is fairly easy, people porting software from
Windows to Linux told me numerous times that adapting isn't hard. I also
believe that at least one of the BSD's has a compatible implementation
these days based on the fact that I was asked to allow copying the
headers in the past.
--
Vojtech
to create a patch.
--
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/
scenario.
The value of live patching is in near zero disruption.
--
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
that.
--
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/
patching usecases on day 1 already ...
Feel free to start working on it. I'll stick with live patching.
--
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
discovery information between
two versions of the driver. I'm not convinced such a
mechanism is necessary in the general case.
--
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
returning.
Won't that break with sibling/tail calls? GCC can generate those, and
the ia32_ptregs_common label is an example of such a thing.
It only validates hand-written assembly, so how it could?
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe
Fix writeback_thread never finishing writing back all dirty data in bcache when
partial_stripes_expensive is set, and spinning, consuming 100% of CPU instead.
Signed-off-by: Vojtech Pavlik <vojt...@suse.com>
---
This is a fix for the current upstream bcache, not the devel
>
> LIVE PATCHING
> M: Josh Poimboeuf <jpoim...@redhat.com>
> -M: Seth Jennings <sjenn...@redhat.com>
> +M: Jessica Yu <j...@redhat.com>
> M: Jiri Kosina <ji...@kernel.org>
> -M: Vojtech Pavlik <vojt...@suse.com>
> +M: Miroslav
On Mon, Apr 04, 2016 at 01:33:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Apr 04, 2016 at 08:27:59PM +0200, Vojtech Pavlik wrote:
> > On Mon, Apr 04, 2016 at 01:21:38PM -0500, Josh Poimboeuf wrote:
> >
> > > Hm, can you explain why it should be copied from the parent?
&
?
How could a newly forked task start in the old universe if its parent
has already been migrated? Any context it inherits will already be from
the new universe.
--
Vojtech Pavlik
Director SuSE Labs
X_TIME, ANALOG_MAX_TIME + 100);
> + t = gameport_time(gameport, ANALOG_MAX_TIME);
> gameport_trigger(gameport);
> while ((gameport_read(port->gameport) & port->mask) && (u < t))
> u++;
> --
> 2.6.2
>
--
Vojtech Pavlik
= -ENODEV;
> goto fail2;
> }
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> j = sw_read_packet(gameport, idbuf, SW_LENGTH, i); /*
> Retry reading ID */
> dbg("Init 2c: ID Length %d.", j);
> }
> @@ -655,7 +655,7 @@ static int sw_connect(struct gameport *gameport, struct
> gameport_driver *drv)
>
> do {
> k--;
> - msleep(SW_TIMEOUT);
> + usleep_range(SW_TIMEOUT, SW_TIMEOUT + 100);
> i = sw_read_packet(gameport, buf, SW_LENGTH, 0);/* Read
> data packet */
> dbg("Init 3: Mode %d. Length %d. Last %d. Tries %d.", m, i, l,
> k);
>
> --
> 2.6.2
>
--
Vojtech Pavlik
struct gameport_driver *drv)
>
> gf2k_trigger_seq(gameport, gf2k_seq_reset);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> gf2k_trigger_seq(gameport, gf2k_seq_digital);
>
> - msleep(GF2K_TIMEOUT);
> + usleep_range(GF2K_TIMEOUT, GF2K_TIMEOUT + 100);
>
> if (gf2k_read_packet(gameport, GF2K_LENGTH, data) < 12) {
> err = -ENODEV;
> --
> 2.6.2
>
--
Vojtech Pavlik
o I can have caching _and_ compatibility with
> grub2 etc (and avoid 400GB move):
The common way to do that is to move the beginning of the partition,
assuming your ext4 lives in a partition.
I don't see how overlapping the ext4 and the bcache backing device
starts would give you what you want, because bcache assumes the
backing device data starts with an offset.
--
Vojtech Pavlik
er against
each kernel code address verifying the output and bail if there is a bug
in the toolchain that affects it.
--
Vojtech Pavlik
Director SuSE Labs
this way, but nevertheless, the
address isn't valid anymore, so removing it makes good sense.
--
Vojtech Pavlik
Director SUSE Labs
/
> { USB_DEVICE(0x061c, 0xc084) }, /* ACT LABS Force RS */
> + { USB_DEVICE(0x06a3, 0xff04) }, /* Saitek R440 Force Wheel */
> { USB_DEVICE(0x06f8, 0x0001) }, /* Guillemot Race Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0003) }, /* Guillemot Jet Leader Force
> Feedback */
> { USB_DEVICE(0x06f8, 0x0004) }, /* Guillemot Force Feedback
> Racing Wheel */
> --
> 2.19.1.450.ga4b8ab536
>
--
Vojtech Pavlik
Director SUSE Labs
lso true that some buses simply don't yield up physical
> locations (ISA springs to mind,
ISA is quite fine, you can use the i/o space as physical locations.
> and I gather that FC is squishy that
> way), but it's desirable to be able to make the connection all ways
> (eth# <-&g
On Wed, May 16, 2001 at 07:37:45AM -0700, Jonathan Lundell wrote:
> At 10:02 AM +0200 2001-05-16, Vojtech Pavlik wrote:
> > > It's also true that some buses simply don't yield up physical
> >> locations (ISA springs to mind,
> >
> >ISA is quite fine, you
here were no changes lately in the VIA driver. Can you spot where the
problems begun?
--
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-i
1251 is not set
> CONFIG_NLS_ISO8859_1=m
> # CONFIG_NLS_ISO8859_2 is not set
> # CONFIG_NLS_ISO8859_3 is not set
> # CONFIG_NLS_ISO8859_4 is not set
> # CONFIG_NLS_ISO8859_5 is not set
> # CONFIG_NLS_ISO8859_6 is not set
> # CONFIG_NLS_ISO8859_7 is not set
> # CONFIG_NLS_I
; That's what we like Linux for. It doesn't get confused when everything
> else does :-)
>
> Thanks for your very interesting reply.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
0bb Before first symbol
> Code; 0010 Before first symbol
> 10: 31 c9 xor%ecx,%ecx
> Code; 0012 Before first symbol
> 12: 8d 70 00 lea0x0(%eax),%esi
>
> The module loaded OK in 2.4.5-ac3. input, joydev, ns558, gamepor
On Thu, May 31, 2001 at 11:29:06AM +1000, Keith Owens wrote:
> On Wed, 30 May 2001 18:15:31 +0200,
> Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> >On Wed, May 30, 2001 at 02:46:42PM +1000, Keith Owens wrote:
> >> This is messy. gameport.h is included by code outside
On Thu, May 31, 2001 at 05:52:39PM +1000, Keith Owens wrote:
> On Thu, 31 May 2001 08:08:45 +0200,
> Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> >On Thu, May 31, 2001 at 11:29:06AM +1000, Keith Owens wrote:
> >> With your patch, if a user sele
On Thu, May 31, 2001 at 10:06:54AM +0200, Vojtech Pavlik wrote:
> On Thu, May 31, 2001 at 05:52:39PM +1000, Keith Owens wrote:
>
> > On Thu, 31 May 2001 08:08:45 +0200,
> > Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > >On Thu, May 31, 2001 at 11
so I am reporting
> it to you.
>
> I and another user thought the problem was in hid_input_field, but upon
> looking I now think not.
>
> My mouse is fairly unusable in X, and unfortunately I can not figure out
> a fix.
It is a quite stupid bug. Here is the fix (already sent to Al
On Fri, Jun 01, 2001 at 10:57:17AM +0100, Michael wrote:
> On Wed, May 30, 2001 at 09:30:39PM +0100, Alan Cox wrote:
> > 2.4.5-ac4
> > o Update USB hid drivers (Vojtech Pavlik)
>
> I think these changes have broken my USB wheel mouse.
>
>
by some. In 322 lines of code, all of
serial mouse handling. And much better than ever before.
Try it out. Installation notes are in the README file.
Patch against 2.4.5-ac9.
Have fun ...
--
Vojtech Pavlik
SuSE Labs
sermouse.tar.gz
eers: dumb serial
> port, serial mouse, joystick, etc.
Agreed. Completely.
And proposed a couple times before.
But not in my power.
So I used a N_MOUSE line discipline instead
- the best tap into the serial/tty stack I found.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from thi
it indeed is.
--
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/
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 rea
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
>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: ATA
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 (
ia?
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/
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 enable
L 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?
--
V
er- 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
]>
> > > 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
oes?
>
> 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 [
tw, 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/
ions 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 southbr
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
> > (UDMA
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 per
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 fr
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
K. 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/
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 (northbrid
bly 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/
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
> >
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/
ot;.
>
> 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: se
001 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
>
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
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 J
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?
> &
nd 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/
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
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*,
tly 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
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/
> 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 ...
--
Vojte
64, 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.
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 ---\
> > > |
> > >
hwif->autodma = 1;
> +#endif /* CONFIG_IDEDMA_AUTO */
> }
> #endif /* CONFIG_BLK_DEV_IDEDMA */
> }
>
Linus, if you haven't applied my disable-dma-in-all-cases patch I've
sent you earlier, please do apply this one - it's correct and should be
there. It conflicts with t
83 MHz FSB, you'll get 41.5 MHz
or 27.6 MHz PCI. And there are chips speced for 75 and 83 MHz FSB's -
Cyrix 6x86MX etc.
No way to get 33 here, if you *don't* want to over/under-clock the CPU.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-
ming should be always the same, independent on the PCI
clock. However, it is programmed in terms of PCI cycles, so yes, the
only thing my driver does is exactly this compensation for the PCI speed
so that the IDE timing stays constant.
Yes, my driver is doing exactly what you say.
--
Vojtech
ng here that I can not do a damn thing with until I
> stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation
> not at the kernel or anyone involved with the VIA stuff. Please don't take
> it that way.)
Sure, I'll need a more precise description, though.
--
Vojtech P
On Mon, Jan 29, 2001 at 12:49:16PM -0800, Tim Moore wrote:
> Is via82cxxx.c v3.17 a 2.4.x only patch or did I miss something else?
Yes, it's currently 2.4.x only.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Tue, Jan 30, 2001 at 10:48:26AM +0100, Vojtech Pavlik wrote:
> The current VIA driver in 2.4.0 is version 2.1e. I wouldn't push a new
> version, but VIA has released the vt82c686b chip and it's causing a lot
> of trouble.
>
> The 2.1e version can't recognize it from the vt82
be getting much less
mails about non-working 686b's.
It's against 2.4.1-pre12, but should patch cleanly against pre11 or
anything later.
Thanks.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
related anyhow.
--
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/
On Tue, Jan 30, 2001 at 11:55:25PM -0800, David Raufeisen wrote:
> On Wednesday, 31 January 2001, at 08:36:42 (+0100),
> Vojtech Pavlik wrote:
>
> > Hi!
> >
> > 1) You don't seem to have any drives on the VIA controller. If this is
> > true, I don't think thi
iveness than 2.4.x . Could this be because of via problems on
> the 2.4.x kernel or is it 2.4.x arch ?
No, probably not.
--
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/
roblems i've been talking about
Btw, if you run your FSB at 114 MHz, you need to pass 'idebus=38' to the
IDE driver so that it knows your PCI bus runs at 38 MHz (3x38 = 114).
Otherwise you'll get incorrect timing etc.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line &quo
ia) data for both
so that I can compare them?
If I find any differences, I'll know what the bug is.
--
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/
uctions are too fast. The VIA driver on 2.2 doesn't
> correctly program the PCI card, so you don't see weird behavior running 2.2
> with a faster PCI clock.
>
> (Note: 1.14 * 33 = 37.6 PCI Clk)
It's 38:
114 / 3 == 38 == 1.14 * 33.33
But definitely it isn't 34 or the default 33.
ssume 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,
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 d
: 40w
> 40w"... Is it right? I have a 80w cable, not 40.
Check your BIOS settings, if you have disabled UDMA in the BIOS, the
driver can't detect the cable. If that doesn't work, use "ide0=ata66"
on the kernel command line.
--
Vojtech Pavlik
t;Multi-Axis
>Controller"};
I'll have to verify, but either a fix got lost somewhere, or this is a
bug in the joystick. The hats were working fine.
--
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/
a
> The fact that you _can_ do so makes the patch valid, and I do agree with
> Al on the "least surprise" issue. I've already applied the patch, in fact.
> But the fact is that nobody should ever do the thing that could cause
> problems.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe
aram -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 PROTE
501 - 600 of 1085 matches
Mail list logo
