On Thursday 12 July 2007 00:17, Al Boldi wrote:
> Peter Williams wrote:
>>
>> Probably the last one now that CFS is in the main line :-(.
>
> What do you mean? A pluggable scheduler framework is indispensible even in
> the presence of CFS or SD.
Indeed, and I hope it gets merged, giving
On Thursday 12 July 2007 00:17, Al Boldi wrote:
Peter Williams wrote:
Probably the last one now that CFS is in the main line :-(.
What do you mean? A pluggable scheduler framework is indispensible even in
the presence of CFS or SD.
Indeed, and I hope it gets merged, giving people the
On 4/21/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
On Fri, 20 Apr 2007, Giuseppe Bilotta wrote:
> Oh, I see. I'll blacklist those modules, maybe also issue a ticket on
> the Debian BTS.
If Debian enables usbmouse and usbkbd by default in their standard
kernels, would you be so ki
On 4/20/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
On Fri, Apr 20, 2007 at 06:09:55PM +0200, Giuseppe Bilotta wrote:
> On 4/20/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> >On 4/20/07, Giuseppe Bilotta <[EMAIL PROTECTED]> wrote:
> >>
> >>
On 4/20/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On 4/20/07, Giuseppe Bilotta <[EMAIL PROTECTED]> wrote:
>
> Sorry, it seems I was wrong, it's not usbhid but usbmouse taking over.
> After a fresh plug (e.g. at bootup) I get the following:
>
Well, the question is -
On 4/20/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
On Fri, 20 Apr 2007, Giuseppe Bilotta wrote:
> lsusb claims:
> Bus 002 Device 003: ID 0460:0004 Ace Cad Enterprise Co., Ltd
> and according to hid-core.c this *is* a blacklisted ID ...
Yes, so it definitely should be ignored
On 4/20/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
On Fri, 20 Apr 2007, Giuseppe Bilotta wrote:
> The first problem is that the usbmouse and usbhid drivers take control
> of the device, so that when I plug it in the tablet appears as a mouse,
> with extremely funny effects
On 4/20/07, Jiri Kosina [EMAIL PROTECTED] wrote:
On Fri, 20 Apr 2007, Giuseppe Bilotta wrote:
The first problem is that the usbmouse and usbhid drivers take control
of the device, so that when I plug it in the tablet appears as a mouse,
with extremely funny effects (cursor jumping around
On 4/20/07, Jiri Kosina [EMAIL PROTECTED] wrote:
On Fri, 20 Apr 2007, Giuseppe Bilotta wrote:
lsusb claims:
Bus 002 Device 003: ID 0460:0004 Ace Cad Enterprise Co., Ltd
and according to hid-core.c this *is* a blacklisted ID ...
Yes, so it definitely should be ignored and not claimed
On 4/20/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 4/20/07, Giuseppe Bilotta [EMAIL PROTECTED] wrote:
Sorry, it seems I was wrong, it's not usbhid but usbmouse taking over.
After a fresh plug (e.g. at bootup) I get the following:
Well, the question is - why do you have usbmouse module
On 4/20/07, Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Fri, Apr 20, 2007 at 06:09:55PM +0200, Giuseppe Bilotta wrote:
On 4/20/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 4/20/07, Giuseppe Bilotta [EMAIL PROTECTED] wrote:
Sorry, it seems I was wrong, it's not usbhid but usbmouse taking
On 4/21/07, Jiri Kosina [EMAIL PROTECTED] wrote:
On Fri, 20 Apr 2007, Giuseppe Bilotta wrote:
Oh, I see. I'll blacklist those modules, maybe also issue a ticket on
the Debian BTS.
If Debian enables usbmouse and usbkbd by default in their standard
kernels, would you be so kind and raise
Hello all,
I have a [EMAIL PROTECTED] Acecad USB Tablet and I've been trying for a
while to set it up to work fine under Linux, without very much
success. I've been using the stock Debian kernel (2.6.18), but also
tried rolling my own 2.6.x git series (latest tried a 2.6.21-rc7 just
this
Hello all,
I have a [EMAIL PROTECTED] Acecad USB Tablet and I've been trying for a
while to set it up to work fine under Linux, without very much
success. I've been using the stock Debian kernel (2.6.18), but also
tried rolling my own 2.6.x git series (latest tried a 2.6.21-rc7 just
this
On 2/25/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
>
> Applied. No noticeable difference, in the sense that the EDID debug
> output is still the same and so is the snow effect.
Here's a temporary workaround:
I
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
>
> Keep in mind that setting nvidiafb to totally ignore the EDID (either
> by not compiling in EDID support or by using e.g. the ignoreedid patch
> I had
On 2/24/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Sat, 2007-02-24 at 10:16 +0100, Giuseppe Bilotta wrote:
Keep in mind that setting nvidiafb to totally ignore the EDID (either
by not compiling in EDID support or by using e.g. the ignoreedid patch
I had proposed) the snow effect
On 2/25/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Sun, 2007-02-25 at 11:26 +0100, Giuseppe Bilotta wrote:
Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.
Here's a temporary workaround:
In drivers/video/nvidia
On 2/24/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
>
> The snowy is constant and abundant, and it seems to be independent of
> video size (640 through 1600) and screen occupation (single prompt
> line to ful
On 2/24/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Fri, 2007-02-23 at 14:34 +0100, Giuseppe Bilotta wrote:
The snowy is constant and abundant, and it seems to be independent of
video size (640 through 1600) and screen occupation (single prompt
line to fullscreen mc session) and usage
On 2/23/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
> No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
> and they /all/ come up snowy. This is starting to look queerer and
> queerer. I've also tr
On 2/23/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 20:08 +0100, Giuseppe Bilotta wrote:
No, it doesn't. I've tried all the methods from 640x480 to 1600x1200,
and they /all/ come up snowy. This is starting to look queerer and
queerer. I've also tried changing vf min
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
>
> However, I'm still getting the same snowy effects, which doesn't come
> as a surprise since the actual mode timings used are just the same ...
Yes, because th
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following info:
ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ 11
nvidiafb: Device ID:
On 2/22/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
>
> As mentioned in another post in this thread, I can't get any info out
> of the i2c busses, because even when I have them available (i.e. after
> loading nv
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Wed, 2007-02-07 at 00:08 +0100, Giuseppe Bilotta wrote:
As mentioned in another post in this thread, I can't get any info out
of the i2c busses, because even when I have them available (i.e. after
loading nvidiafb) I get all
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
Ah, my fault. Apply this patch on top.
We're getting closer! The patch now works, and the dmesg has the following info:
ACPI: PCI Interrupt :01:00.0[A] - Link [LNKA] - GSI 11 (level,
low) - IRQ 11
nvidiafb: Device ID: 10de0112
On 2/22/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Thu, 2007-02-22 at 16:55 +0100, Giuseppe Bilotta wrote:
However, I'm still getting the same snowy effects, which doesn't come
as a surprise since the actual mode timings used are just the same ...
Yes, because the EDID has only 1
On Wednesday 21 February 2007 02:49, Greg KH wrote:
> /* frame pointer must be last for get_wchan */
> -#define SAVE_CONTEXT"pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> +#define SAVE_CONTEXT"pushf ; pushq %%rbp ; movq
On Wednesday 21 February 2007 02:49, Greg KH wrote:
/* frame pointer must be last for get_wchan */
-#define SAVE_CONTEXTpushq %%rbp ; movq %%rsi,%%rbp\n\t
-#define RESTORE_CONTEXT movq %%rbp,%%rsi ; popq %%rbp\n\t
+#define SAVE_CONTEXTpushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t
On Sunday 18 February 2007 00:55, Michael K. Edwards wrote:
> Or they could run:
> find . -type f -exec
perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
> and be done with it. Or even just MODULE_LICENSE("GPL") in their
> module -- that's not "lying about the module license", it's
On Sunday 18 February 2007 00:55, Michael K. Edwards wrote:
Or they could run:
find . -type f -exec
perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
and be done with it. Or even just MODULE_LICENSE(GPL) in their
module -- that's not lying about the module license, it's doing the
On Saturday 17 February 2007 15:19, David Schwartz wrote:
> Static Controls argued that taking the TLP was the only practical way to
> make a cartridge that would work with that printer.
Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP
On 2/17/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Ok, now I'm confused O_o
The patch should be correct, but I fail to see how EDID reading succeded
before.
Sorry, but I have no idea on that :P
Maybe the snow was caused by the driver hammering the I2C bus. Just
guessing...
It it was
On Saturday 17 February 2007 03:42, David Schwartz wrote:
> Again, see Lexmark v. Static Controls. If "make a toner cartridge that
works
> with a particular Lexmark printer" is a functional idea, why is "make a
> graphics driver that works with a particular Linux kernel" not? What is
the
>
On Saturday 17 February 2007 03:42, David Schwartz wrote:
Again, see Lexmark v. Static Controls. If make a toner cartridge that
works
with a particular Lexmark printer is a functional idea, why is make a
graphics driver that works with a particular Linux kernel not? What is
the
difference you
On 2/17/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
Ok, now I'm confused O_o
The patch should be correct, but I fail to see how EDID reading succeded
before.
Sorry, but I have no idea on that :P
Maybe the snow was caused by the driver hammering the I2C bus. Just
guessing...
It it was so,
On Saturday 17 February 2007 15:19, David Schwartz wrote:
Static Controls argued that taking the TLP was the only practical way to
make a cartridge that would work with that printer.
Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP
(some of you might get this mail in double copy , sorry)
On 2/11/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Sorry for the delay.
Ditto!
It also seemed that my kernel compiling sk1llz had gone AWL, I
couldn't get the newly compiled kernel to run, until I realized the
initrd.img was
(some of you might get this mail in double copy , sorry)
On 2/11/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
Sorry for the delay.
Ditto!
It also seemed that my kernel compiling sk1llz had gone AWL, I
couldn't get the newly compiled kernel to run, until I realized the
initrd.img was
On 2/8/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Il Tue, Feb 06, 2007 at 09:22:00PM +, James Simmons ha scritto:
> There is no stand alone nvidia card i2c driver. Its the issue of sharing
> device interfaces with the same hardware problem again!!!
Nah, nvidiafb registers the I2C
On 2/8/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
Il Tue, Feb 06, 2007 at 09:22:00PM +, James Simmons ha scritto:
There is no stand alone nvidia card i2c driver. Its the issue of sharing
device interfaces with the same hardware problem again!!!
Nah, nvidiafb registers the I2C busses,
On 2/6/07, James Simmons <[EMAIL PROTECTED]> wrote:
If you can find post the manufacturer and model number we can place it on
the backlist in fbmon. Also we should figure out what is wrong and fix it.
It's the UltraSharp UXGA display that used to come with Dell Inspiron
8200, 15" with a
On 2/6/07, James Simmons [EMAIL PROTECTED] wrote:
If you can find post the manufacturer and model number we can place it on
the backlist in fbmon. Also we should figure out what is wrong and fix it.
It's the UltraSharp UXGA display that used to come with Dell Inspiron
8200, 15 with a
On 2/5/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
get-edid uses the BIOS, while the other two talk directly over the I2C
bus.
Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID
block, which resides at address 0x50:
i2cdump N 0x50 (where N is the bus number)
If you
On 2/5/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
get-edid uses the BIOS, while the other two talk directly over the I2C
bus.
Try loading i2c-dev (I2C_CHARDEV); With i2cdump[1] you can read the EDID
block, which resides at address 0x50:
i2cdump N 0x50 (where N is the bus number)
If you are
On 2/4/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Giuseppe, can you send me the EDID block of your monitor?
I'd gladly do it, if I knew how to retrieve it ... because apparently,
get-edid doesn't work, even though both the nv driver for X and
nvidiafb manage to retrieve it.
This is the
On 2/4/07, Luca Tettamanti [EMAIL PROTECTED] wrote:
Giuseppe, can you send me the EDID block of your monitor?
I'd gladly do it, if I knew how to retrieve it ... because apparently,
get-edid doesn't work, even though both the nv driver for X and
nvidiafb manage to retrieve it.
This is the
On 1/29/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > > Because most users won't even be aware of the module option: they'll just
> > > know that their card doesn't work right.
> >
> > This isn't a card problem this is a monitor problem, the card just
> > passes through the edid data from the
On 1/29/07, Dave Airlie [EMAIL PROTECTED] wrote:
Because most users won't even be aware of the module option: they'll just
know that their card doesn't work right.
This isn't a card problem this is a monitor problem, the card just
passes through the edid data from the monitor... or
From: Giuseppe Bilotta <[EMAIL PROTECTED]>
Some nVidia video cards have broken EDID information. Using nvidiafb
with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
framebuffer to use wrong timing information, causing the display to be
extremely 'snowy'. Since most distri
From: Giuseppe Bilotta [EMAIL PROTECTED]
Some nVidia video cards have broken EDID information. Using nvidiafb
with CONFIG_FB_NVIDIA_I2C enabled on these systems causes the console
framebuffer to use wrong timing information, causing the display to be
extremely 'snowy'. Since most distribution
On Mon, 8 Jan 2007 15:51:31 -0500, Erez Zadok wrote:
> Now, we've discussed a number of possible solutions. Thanks to suggestions
> we got at OLS, we discussed a way to hide the lower namespace, or make it
> readonly, using existing kernel facilities. But my understanding is that
> even it'd
On Mon, 8 Jan 2007 15:51:31 -0500, Erez Zadok wrote:
Now, we've discussed a number of possible solutions. Thanks to suggestions
we got at OLS, we discussed a way to hide the lower namespace, or make it
readonly, using existing kernel facilities. But my understanding is that
even it'd work,
On Sat, 6 Jan 2007 19:35:41 +, Alan wrote:
> The kernel drivers work on the basis that if you are using drivers/ide
> then the IDE driver will grab all the ports, if you are using libata then
> the PCI boot quirks will switch to split AHCI and PATA mode and the
> libata drivers will take
Hello all,
I'm using a Debain unstable 2.6.18-3 kernel on an ASRock
motherboard (VIA K8T890 chipset). The motherboard has IDE, SATA
and SATA_II controllers:
lspci:
00:00.0 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
Hello all,
I'm using a Debain unstable 2.6.18-3 kernel on an ASRock
motherboard (VIA K8T890 chipset). The motherboard has IDE, SATA
and SATA_II controllers:
lspci:
00:00.0 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
On Sat, 6 Jan 2007 19:35:41 +, Alan wrote:
The kernel drivers work on the basis that if you are using drivers/ide
then the IDE driver will grab all the ports, if you are using libata then
the PCI boot quirks will switch to split AHCI and PATA mode and the
libata drivers will take both.
On Mon, 18 Dec 2006 23:34:53 +0200, Hannu Savolainen wrote:
> For a professional developer of any software the decision of open
> sourcing it is not easy. "Just for fun" developers have no problems
> because they don't expect to be able to live on their work anyway.
> However a professional
On Mon, 18 Dec 2006 23:34:53 +0200, Hannu Savolainen wrote:
For a professional developer of any software the decision of open
sourcing it is not easy. Just for fun developers have no problems
because they don't expect to be able to live on their work anyway.
However a professional
On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:
>> Every book in my book shelf is software?
>
> If you digitalize it, yes.
AFAIK software only refers to programs, not to arbitrary sequences of
bytes. An MP3 file isn't "software". Although it surely isn't hardware
either.
--
On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote:
> I've recently made some improvements
> recently which will reduce the memory use
Does this include check for redundancy? ;)
--
Giuseppe "Oblomov" Bilotta
Hic manebimus optime
-
To unsubscribe from this list: send the line "unsubscribe
On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote:
I've recently made some improvements
recently which will reduce the memory use
Does this include check for redundancy? ;)
--
Giuseppe Oblomov Bilotta
Hic manebimus optime
-
To unsubscribe from this list: send the line unsubscribe
On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:
Every book in my book shelf is software?
If you digitalize it, yes.
AFAIK software only refers to programs, not to arbitrary sequences of
bytes. An MP3 file isn't software. Although it surely isn't hardware
either.
--
Giuseppe
--
Giuseppe "Oblomov" Bilotta
Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS
-
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/majordo
On Fri, 1 Apr 2005 08:03:16 -0500 (EST), linux-os wrote:
> This must be a joke. Where's the punch line?
It's called a fish in Italian and French.
--
Giuseppe "Oblomov" Bilotta
"They that can give up essential liberty to obtain
a little temporary safety deserve neither liberty
nor safety."
On Fri, 1 Apr 2005 08:03:16 -0500 (EST), linux-os wrote:
This must be a joke. Where's the punch line?
It's called a fish in Italian and French.
--
Giuseppe Oblomov Bilotta
They that can give up essential liberty to obtain
a little temporary safety deserve neither liberty
nor safety. Benjamin
Bilotta
Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS
-
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
> > What are the cons of using "all of" the RAM at boot time to
> > cache the boot disk?
Dave Jones wrote:
> It's memory that's otherwise unused. Once you start using the system
> anything cached will get reclaimed as its needed.
So there is no substantial loss? IOW, it would suffice to have
Lee Revell wrote:
> Yup, many people on this list seem unaware but read the XP white papers,
> then try booting it side by side with Linux. They put some serious,
> serious engineering into that problem and came out with a big win.
> Screw Longhorn, we need improve by 50% to catch up to what they
Dave Jones wrote:
> Some of the folks on our desktop team have been doing a bunch of experiments
> at getting boot times down, including laying out the blocks in a more
> optimal manner, allowing /sbin/readahead to slurp the data off the disk
> in one big chunk, and run almost entirely from cache.
Dave Jones wrote:
Some of the folks on our desktop team have been doing a bunch of experiments
at getting boot times down, including laying out the blocks in a more
optimal manner, allowing /sbin/readahead to slurp the data off the disk
in one big chunk, and run almost entirely from cache.
Lee Revell wrote:
Yup, many people on this list seem unaware but read the XP white papers,
then try booting it side by side with Linux. They put some serious,
serious engineering into that problem and came out with a big win.
Screw Longhorn, we need improve by 50% to catch up to what they can
What are the cons of using all of the RAM at boot time to
cache the boot disk?
Dave Jones wrote:
It's memory that's otherwise unused. Once you start using the system
anything cached will get reclaimed as its needed.
So there is no substantial loss? IOW, it would suffice to have
all the
> According to your patch, the C840 has 2 temp sensors. I'll have to figure
> out what the second one is (prob either the GPU or the disk drive?)
If it runs over 40 C easily it's probably the GPU :)
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and
According to your patch, the C840 has 2 temp sensors. I'll have to figure
out what the second one is (prob either the GPU or the disk drive?)
If it runs over 40 C easily it's probably the GPU :)
--
Giuseppe Oblomov Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and
Benjamin Herrenschmidt wrote:
> I'm still curious what makes a difference between module and
> built-in.
There seems to be quite some difference between module and
built-in for framebuffer drivers. Quite some time ago I
reported a problem with nVidia framebuffer driver making the
screen go
Benjamin Herrenschmidt wrote:
I'm still curious what makes a difference between module and
built-in.
There seems to be quite some difference between module and
built-in for framebuffer drivers. Quite some time ago I
reported a problem with nVidia framebuffer driver making the
screen go nuts
David Brownell wrote:
> On Sunday 06 February 2005 7:59 am, Giuseppe Bilotta wrote:
> >
> > I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I
> > found that it works pretty fine (albeit slowly) when connected
> > to the USB 1.1 ports built in my Del
David Brownell wrote:
On Sunday 06 February 2005 7:59 am, Giuseppe Bilotta wrote:
I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I
found that it works pretty fine (albeit slowly) when connected
to the USB 1.1 ports built in my Dell Inspiron 8200, but trying
to connect
kernel wrote:
> You might want to try this;
>
> Remove the keyboard, remove the cover beneath. Take a can of air dust
> (or equivalent) and *carefully* blow out the inside of the laptop.
>
> -then-
>
> Look at the back side and the right side of the laptop. You'll see the
> intake for air
John Stoffel wrote:
>
> I haven't tried lately, but my USB/FireWire enclosure never worked
> with Linux (or WinNT under firewire, sigh...) so I haven't touched it
> in months. Money down the drain.
I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I
found that it works pretty fine
Dmitry Torokhov wrote:
> On Fri, 4 Feb 2005 07:18:17 -0500, Wakko Warner <[EMAIL PROTECTED]> wrote:
> > > particular hardware (Dell Inspiron 8100)? I run Linux on 3 other
>
> Hmm, I guess it's a hit and run. I had replaced:
>
> 4. Original Hitachi hard driver died horrible death - I returned
Venkatesh Pallipadi wrote:
> + /*
> + * Some systems seems to need two writes to HPET_T0_CMP,
> + * to get interrupts working
> + */
> + hpet_writel(tick, HPET_T0_CMP);
> hpet_writel(tick, HPET_T0_CMP);
Is it known which platforms require two, and which ones require
Venkatesh Pallipadi wrote:
+ /*
+ * Some systems seems to need two writes to HPET_T0_CMP,
+ * to get interrupts working
+ */
+ hpet_writel(tick, HPET_T0_CMP);
hpet_writel(tick, HPET_T0_CMP);
Is it known which platforms require two, and which ones require
one
Dmitry Torokhov wrote:
On Fri, 4 Feb 2005 07:18:17 -0500, Wakko Warner [EMAIL PROTECTED] wrote:
particular hardware (Dell Inspiron 8100)? I run Linux on 3 other
Hmm, I guess it's a hit and run. I had replaced:
4. Original Hitachi hard driver died horrible death - I returned home
and
kernel wrote:
You might want to try this;
Remove the keyboard, remove the cover beneath. Take a can of air dust
(or equivalent) and *carefully* blow out the inside of the laptop.
-then-
Look at the back side and the right side of the laptop. You'll see the
intake for air and the
John Stoffel wrote:
I haven't tried lately, but my USB/FireWire enclosure never worked
with Linux (or WinNT under firewire, sigh...) so I haven't touched it
in months. Money down the drain.
I have a MAGNEX/ViPower USB/FirWire external HD enclosure. I
found that it works pretty fine (albeit
Dmitry Torokhov wrote:
> No I don't but by the looks of it (constant stream of bad data) it looks
> like somehow the touhcpad was reset back into PS/2 compatibility mode.
> resetafter would catch it and reinitialize touchpad restoring proper
> protocol.
My Dell Inspiron 8200 shows very sluggish
Peter Osterlund wrote:
> Only parse a "z == 127" packet as a relative Dualpoint stick packet if
> the touchpad actually is a Dualpoint device. The Glidepoint models
> don't have a stick, and can report z == 127 for a very wide finger. If
> such a packet is parsed as a stick packet, the mouse
Peter Osterlund wrote:
Only parse a z == 127 packet as a relative Dualpoint stick packet if
the touchpad actually is a Dualpoint device. The Glidepoint models
don't have a stick, and can report z == 127 for a very wide finger. If
such a packet is parsed as a stick packet, the mouse pointer
Dmitry Torokhov wrote:
No I don't but by the looks of it (constant stream of bad data) it looks
like somehow the touhcpad was reset back into PS/2 compatibility mode.
resetafter would catch it and reinitialize touchpad restoring proper
protocol.
My Dell Inspiron 8200 shows very sluggish
92 matches
Mail list logo
