Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22

[Giuseppe Bilotta]

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 chance to test out
different schedulers easily, without having to do patching, de-patching,
re-patching and blah blah blah.

But somehow I doubt it'll get merged now. My bet is that it won't even be
taken into consideration, for the same reasons that ultimately drove Con
Kolivas to giving up on development of SD. And if it's so, chances are
people will get tired of trying to get it merged. :/

>> A patch for 2.6.22 is available at:
>>
>> 
>>
>> Very Brief Documentation:
>>
>> You can select a default scheduler at kernel build time.  If you wish to
>> boot with a scheduler other than the default it can be selected at boot
>> time by adding:
>>
>> cpusched=
>>
>> to the boot command line where  is one of: ingosched,
>> ingo_ll, nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs
>> or zaphod.  If you don't change the default when you build the kernel
>> the default scheduler will be ingosched (which is the normal scheduler).
> 
> Can't PlugSched include CFS and SD?

If I read the announcement correctly, those are the ones referred to as
'ingosched' and 'staircase' :)

-- 
Giuseppe "Oblomov" Bilotta

-
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: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22

[Giuseppe Bilotta]

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 chance to test out
different schedulers easily, without having to do patching, de-patching,
re-patching and blah blah blah.

But somehow I doubt it'll get merged now. My bet is that it won't even be
taken into consideration, for the same reasons that ultimately drove Con
Kolivas to giving up on development of SD. And if it's so, chances are
people will get tired of trying to get it merged. :/

 A patch for 2.6.22 is available at:

 http://downloads.sourceforge.net/cpuse/plugsched-6.5.1-for-2.6.22.patch

 Very Brief Documentation:

 You can select a default scheduler at kernel build time.  If you wish to
 boot with a scheduler other than the default it can be selected at boot
 time by adding:

 cpusched=scheduler

 to the boot command line where scheduler is one of: ingosched,
 ingo_ll, nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs
 or zaphod.  If you don't change the default when you build the kernel
 the default scheduler will be ingosched (which is the normal scheduler).
 
 Can't PlugSched include CFS and SD?

If I read the announcement correctly, those are the ones referred to as
'ingosched' and 'staircase' :)

-- 
Giuseppe Oblomov Bilotta

-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 a proper ticket on them not to do
so? Thanks.

This also makes me to speed up with one of my items on TODO list - rename
usbmouse and usbkbd to something that wouldn't be so confusing and
wouldn't make people think that they should enable these drivers if they
want support for USB keyboards/mice. Will queue this for 2.6.22.


Actually, I just found out that usbmouse and usbkbd are in the
blacklist file (/etc/modprobe.d/blacklist), so the fact that they are
being called reveals some kind of fscked up setup on my side. I'll try
to fix that, sorry for the noise.


--
Giuseppe "Oblomov" Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 over.
> >> After a fresh plug (e.g. at bootup) I get the following:
> >>
> >
> >Well, the question is - why do you have usbmouse module on your system?
>
> Stock Debian kernel 2.6.18 comes with it.
>
> With my custom kernels I can probably skip compiling it at all, if you
> so suggest; should I blacklist it for the distro kernel? Or is there a
> chance that some random USB mouse plugged in would fail to function by
> doing so?

usbmouse and usbkbd are only intended for embedded systems where the
full usbhid doesn't fit and for testing purposes: Normal distros
shouldn't have them enabled.


Oh, I see. I'll blacklist those modules, maybe also issue a ticket on
the Debian BTS.

Thanks all.

--
Giuseppe "Oblomov" Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 your system?


Stock Debian kernel 2.6.18 comes with it.

With my custom kernels I can probably skip compiling it at all, if you
so suggest; should I blacklist it for the distro kernel? Or is there a
chance that some random USB mouse plugged in would fail to function by
doing so?

(sorry for the double-send, forgot to reply to all)

--
Giuseppe "Oblomov" Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 by the usbhid
subsystem.



Could you please verify in /sys/bus/usb/drivers/usbhid whether this device
is really claimed by the usbhid driver? Do you have other HID devices in
the system?


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:

dmesg:

usb 1-1: new low speed USB device using uhci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
input: ACECAD USB Graphics Tablet  as /class/input/input4
usbcore: registered new interface driver usbmouse
drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usbcore: registered new interface driver usb_acecad
drivers/usb/input/acecad.c: v3.2:USB Acecad Flair tablet driver

/proc/bus/input/devices

I: Bus=0003 Vendor=0460 Product=0004 Version=0130
N: Name="ACECAD USB Graphics Tablet "
P: Phys=usb-:00:1d.0-1/input0
S: Sysfs=/class/input/input4
H: Handlers=mouse2 event4
B: EV=7
B: KEY=1f 0 0 0 0 0 0 0 0
B: REL=103

ls /sys/bus/usb/drivers/usbmouse

total 0
lrwxrwxrwx 1 root root0 2007-04-20 17:30 1-1:1.0 ->
../../../../devices/pci:00/:00:1d.0/usb1/1-1/1-1:1.0
--w--- 1 root root 4096 2007-04-20 17:30 bind
lrwxrwxrwx 1 root root0 2007-04-20 17:30 module ->
../../../../module/usbmouse
--w--- 1 root root 4096 2007-04-20 17:30 new_id
--w--- 1 root root 4096 2007-04-20 17:30 unbind

So it seems that the greedy driver is usbmouse. I'm adding Vojtech to
the CC: list, since he's listed as the usbmouse author.

Notice that if I rmmod usbmouse and rmmod acecad and then modprobe
acecad again (or maybe I should learn to use the bind/unbind features)
without unplugging the tablet, I get more 'correct'
/proc/bus/input/devices

I: Bus=0003 Vendor=0460 Product=0004 Version=0130
N: Name="ACECAD USB Graphics Tablet "
P: Phys=usb-:00:1d.0-1/input0
S: Sysfs=/class/input/input8
H: Handlers=mouse2 event4
B: EV=b
B: KEY=1c01 0 7 0 0 0 0 0 0 0 0
B: ABS=103

and ls /sys/bus/usb/drivers/*

/sys/bus/usb/drivers/hiddev:
bind
module
new_id
unbind

/sys/bus/usb/drivers/hub:
1-0:1.0
2-0:1.0
bind
module
new_id
unbind

/sys/bus/usb/drivers/usb:
1-1
bind
module
unbind
usb1
usb2

/sys/bus/usb/drivers/usb_acecad:
1-1:1.0
bind
module
new_id
unbind

/sys/bus/usb/drivers/usbfs:
bind
module
new_id
unbind

/sys/bus/usb/drivers/usbhid:
bind
module
new_id
unbind

so just letting usbmouse ignore the device (or maybe have acecad claim
it from usbmouse automagically, if this kind of thing is possible)
should fix the kernel side of the issue (xinput/evdev on X is still
confused by the tablet, even if do the driver gimmick before starting
X, but I'll take that over to the xorg mailing list as soon as I've
fixed the thing kernel side).

Any suggestions or patches welcome.

--
Giuseppe "Oblomov" Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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, buttons clicking
> out of nowhere, and other strange stuff).I have to rmmod usbmouse and
> usbhid and then re-modprobe acecad to get proper data from the tablet
> (where by 'proper' I mean that input-events reports apparently correct
> values for X, Y, pressure and keypresses.

Hi Giuseppe,

could you please send me the product ID of the hardware in question? (you
could get it for example by running lsusb). Currently the usbhid driver
blacklists just product ids 0x0004 and 0x0008 (so that for these product
ids, the HID driver doesn't claim the device and lets other driver -
acecad - to claim it). I guess you have some newer version of the device,
so just adding it to blacklist should suffice.


Hello Jiri,

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

--
Giuseppe "Oblomov" Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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, buttons clicking
 out of nowhere, and other strange stuff).I have to rmmod usbmouse and
 usbhid and then re-modprobe acecad to get proper data from the tablet
 (where by 'proper' I mean that input-events reports apparently correct
 values for X, Y, pressure and keypresses.

Hi Giuseppe,

could you please send me the product ID of the hardware in question? (you
could get it for example by running lsusb). Currently the usbhid driver
blacklists just product ids 0x0004 and 0x0008 (so that for these product
ids, the HID driver doesn't claim the device and lets other driver -
acecad - to claim it). I guess you have some newer version of the device,
so just adding it to blacklist should suffice.


Hello Jiri,

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

--
Giuseppe Oblomov Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 by the usbhid
subsystem.



Could you please verify in /sys/bus/usb/drivers/usbhid whether this device
is really claimed by the usbhid driver? Do you have other HID devices in
the system?


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:

dmesg:

usb 1-1: new low speed USB device using uhci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
input: ACECAD USB Graphics Tablet  as /class/input/input4
usbcore: registered new interface driver usbmouse
drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usbcore: registered new interface driver usb_acecad
drivers/usb/input/acecad.c: v3.2:USB Acecad Flair tablet driver

/proc/bus/input/devices

I: Bus=0003 Vendor=0460 Product=0004 Version=0130
N: Name=ACECAD USB Graphics Tablet 
P: Phys=usb-:00:1d.0-1/input0
S: Sysfs=/class/input/input4
H: Handlers=mouse2 event4
B: EV=7
B: KEY=1f 0 0 0 0 0 0 0 0
B: REL=103

ls /sys/bus/usb/drivers/usbmouse

total 0
lrwxrwxrwx 1 root root0 2007-04-20 17:30 1-1:1.0 -
../../../../devices/pci:00/:00:1d.0/usb1/1-1/1-1:1.0
--w--- 1 root root 4096 2007-04-20 17:30 bind
lrwxrwxrwx 1 root root0 2007-04-20 17:30 module -
../../../../module/usbmouse
--w--- 1 root root 4096 2007-04-20 17:30 new_id
--w--- 1 root root 4096 2007-04-20 17:30 unbind

So it seems that the greedy driver is usbmouse. I'm adding Vojtech to
the CC: list, since he's listed as the usbmouse author.

Notice that if I rmmod usbmouse and rmmod acecad and then modprobe
acecad again (or maybe I should learn to use the bind/unbind features)
without unplugging the tablet, I get more 'correct'
/proc/bus/input/devices

I: Bus=0003 Vendor=0460 Product=0004 Version=0130
N: Name=ACECAD USB Graphics Tablet 
P: Phys=usb-:00:1d.0-1/input0
S: Sysfs=/class/input/input8
H: Handlers=mouse2 event4
B: EV=b
B: KEY=1c01 0 7 0 0 0 0 0 0 0 0
B: ABS=103

and ls /sys/bus/usb/drivers/*

/sys/bus/usb/drivers/hiddev:
bind
module
new_id
unbind

/sys/bus/usb/drivers/hub:
1-0:1.0
2-0:1.0
bind
module
new_id
unbind

/sys/bus/usb/drivers/usb:
1-1
bind
module
unbind
usb1
usb2

/sys/bus/usb/drivers/usb_acecad:
1-1:1.0
bind
module
new_id
unbind

/sys/bus/usb/drivers/usbfs:
bind
module
new_id
unbind

/sys/bus/usb/drivers/usbhid:
bind
module
new_id
unbind

so just letting usbmouse ignore the device (or maybe have acecad claim
it from usbmouse automagically, if this kind of thing is possible)
should fix the kernel side of the issue (xinput/evdev on X is still
confused by the tablet, even if do the driver gimmick before starting
X, but I'll take that over to the xorg mailing list as soon as I've
fixed the thing kernel side).

Any suggestions or patches welcome.

--
Giuseppe Oblomov Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 your system?


Stock Debian kernel 2.6.18 comes with it.

With my custom kernels I can probably skip compiling it at all, if you
so suggest; should I blacklist it for the distro kernel? Or is there a
chance that some random USB mouse plugged in would fail to function by
doing so?

(sorry for the double-send, forgot to reply to all)

--
Giuseppe Oblomov Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 over.
  After a fresh plug (e.g. at bootup) I get the following:
 
 
 Well, the question is - why do you have usbmouse module on your system?

 Stock Debian kernel 2.6.18 comes with it.

 With my custom kernels I can probably skip compiling it at all, if you
 so suggest; should I blacklist it for the distro kernel? Or is there a
 chance that some random USB mouse plugged in would fail to function by
 doing so?

usbmouse and usbkbd are only intended for embedded systems where the
full usbhid doesn't fit and for testing purposes: Normal distros
shouldn't have them enabled.


Oh, I see. I'll blacklist those modules, maybe also issue a ticket on
the Debian BTS.

Thanks all.

--
Giuseppe Oblomov Bilotta
-
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: Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 a proper ticket on them not to do
so? Thanks.

This also makes me to speed up with one of my items on TODO list - rename
usbmouse and usbkbd to something that wouldn't be so confusing and
wouldn't make people think that they should enable these drivers if they
want support for USB keyboards/mice. Will queue this for 2.6.22.


Actually, I just found out that usbmouse and usbkbd are in the
blacklist file (/etc/modprobe.d/blacklist), so the fact that they are
being called reveals some kind of fscked up setup on my side. I'll try
to fix that, sorry for the noise.


--
Giuseppe Oblomov Bilotta
-
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/

Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 evening). The problems still appear.

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, buttons
clicking out of nowhere, and other strange stuff).I have to rmmod
usbmouse and usbhid and then re-modprobe acecad to get proper data
from the tablet (where by 'proper' I mean that input-events reports
apparently correct values for X, Y, pressure and keypresses.

So the first question is: is there a way to let acecad control the
tablet without blacklisting usbmouse and usbhid?

The second question is more user-space related, so this might not be
the right place to ask; feel free to address me to more appropriate
discussion places for the following issues.

Basically, in console the tablet works 'almost' correctly, with gpm
set to read from /dev/input/mice with protocol autops2: if I wrap the
pen from one side to the opposite side without passing through the
tablet, the cursor jumps to the correct place. However, if I move the
pen across the tablet, the motion seems to be always either too fast
or too slow, so that either the mouse reaches the opposite side of the
screen while I'm still halfway throught the tablet, or conversely.

In X (X.org 7.2.0), I cannot use the acecad driver (it fails to
initialize the device, probably because it's managed by the kernel
already, I assume), so I have to use the evdev driver version 1.1.0
(xinput version 1.2.0). With this setup, programs such as Inkscape or
Gimp 'know' that the Tablet is a tablet and correctly configure the
3rd axis for pressure, but the cursor movement is extremely jerky, and
neither pressure nor button presses seem to be received, making the
tablet essentially useless.

I've tried setting CONFIG_INPUT_MOUSEDEV_SCREEN_{X,Y} to match my
screen resolution {1600,1200}, but this has barely improved the motion
jerkiness, if at all (Why is there a need for the kernel to know the
resolution used by X, anyway? Shouldn't userspace itself take care of
scaling input->screen coordinates?) Moreover, it hasn't solved the
missing buttons/pressure.

Is this an evdev/X bug, a kernel limitation, neither or both?

--
Giuseppe "Oblomov" Bilotta
-
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/

Acecad USB Tablet: usbmouse takeover and odd motion

[Giuseppe Bilotta]

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 evening). The problems still appear.

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, buttons
clicking out of nowhere, and other strange stuff).I have to rmmod
usbmouse and usbhid and then re-modprobe acecad to get proper data
from the tablet (where by 'proper' I mean that input-events reports
apparently correct values for X, Y, pressure and keypresses.

So the first question is: is there a way to let acecad control the
tablet without blacklisting usbmouse and usbhid?

The second question is more user-space related, so this might not be
the right place to ask; feel free to address me to more appropriate
discussion places for the following issues.

Basically, in console the tablet works 'almost' correctly, with gpm
set to read from /dev/input/mice with protocol autops2: if I wrap the
pen from one side to the opposite side without passing through the
tablet, the cursor jumps to the correct place. However, if I move the
pen across the tablet, the motion seems to be always either too fast
or too slow, so that either the mouse reaches the opposite side of the
screen while I'm still halfway throught the tablet, or conversely.

In X (X.org 7.2.0), I cannot use the acecad driver (it fails to
initialize the device, probably because it's managed by the kernel
already, I assume), so I have to use the evdev driver version 1.1.0
(xinput version 1.2.0). With this setup, programs such as Inkscape or
Gimp 'know' that the Tablet is a tablet and correctly configure the
3rd axis for pressure, but the cursor movement is extremely jerky, and
neither pressure nor button presses seem to be received, making the
tablet essentially useless.

I've tried setting CONFIG_INPUT_MOUSEDEV_SCREEN_{X,Y} to match my
screen resolution {1600,1200}, but this has barely improved the motion
jerkiness, if at all (Why is there a need for the kernel to know the
resolution used by X, anyway? Shouldn't userspace itself take care of
scaling input-screen coordinates?) Moreover, it hasn't solved the
missing buttons/pressure.

Is this an evdev/X bug, a kernel limitation, neither or both?

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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/nv_i2c.c:nvidia_probe_i2c_connector(),comment
this out:

if (par->chan[conn - 1].par)
edid = fb_ddc_read(>chan[conn - 1].adapter);

and make sure CONFIG_FIRMWARE_EDID=y.


With this patch, I don't get any dmesg info about my monitor EDID, but
I still get the snow. Could it be that there's something else on my
system which is setting the video to some absurd timings when I
switchg on the framebuffer console? I'm running an up-to-date debian
unstable.

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 is extremely reduced,

I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption.  It also incorporates Luca's i2c fix.


Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 is extremely reduced,

I did not know that, just scanned the entire thread. Try this patch, it
makes use of fb_ddc_read*() which I believe has extra steps to prevent
display corruption.  It also incorporates Luca's i2c fix.


Applied. No noticeable difference, in the sense that the EDID debug
output is still the same and so is the snow effect.

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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/nv_i2c.c:nvidia_probe_i2c_connector(),comment
this out:

if (par-chan[conn - 1].par)
edid = fb_ddc_read(par-chan[conn - 1].adapter);

and make sure CONFIG_FIRMWARE_EDID=y.


With this patch, I don't get any dmesg info about my monitor EDID, but
I still get the snow. Could it be that there's something else on my
system which is setting the video to some absurd timings when I
switchg on the framebuffer console? I'm running an up-to-date debian
unstable.

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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.
>
> > I presume that X's nv driver or vesafb does not exhibit this problem?
>
> X's nv gives a very clean display, /unless/ I load nvidiafb before: if
> I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
> this reason), then the screen is very snowy with X's nv too.
>

Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.


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 is extremely reduced, to the point of
being barely perceptible during normal usage (not as clean as X, but
still very good).

Also, I'm wondering if it might be worth looking at the progress done
in nouveau, and the drm stuff they've implemented (or at least the new
memory management and maybe some of the 2D stuff).

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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.

  I presume that X's nv driver or vesafb does not exhibit this problem?

 X's nv gives a very clean display, /unless/ I load nvidiafb before: if
 I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
 this reason), then the screen is very snowy with X's nv too.


Hmm..., I really don't know how to fix this except to look at Xorg's
code and look for a difference.


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 is extremely reduced, to the point of
being barely perceptible during normal usage (not as clean as X, but
still very good).

Also, I'm wondering if it might be worth looking at the progress done
in nouveau, and the drm stuff they've implemented (or at least the new
memory management and maybe some of the 2D stuff).

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 and max as you suggested:

Before we proceed, do you agree that the patch will allow you to change
video modes without disabling DDC support?  So this is still a valid
fix?


You're right, I hadn't realized that. I can now access all the sizes
from 640 to 1600, so I would say the fix is valid.


When does your display become snowy? Is the snow constant or does it
only snow when doing heavy text operations, such as scrolling?


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.


I presume that X's nv driver or vesafb does not exhibit this problem?


X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 and max as you suggested:

Before we proceed, do you agree that the patch will allow you to change
video modes without disabling DDC support?  So this is still a valid
fix?


You're right, I hadn't realized that. I can now access all the sizes
from 640 to 1600, so I would say the fix is valid.


When does your display become snowy? Is the snow constant or does it
only snow when doing heavy text operations, such as scrolling?


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.


I presume that X's nv driver or vesafb does not exhibit this problem?


X's nv gives a very clean display, /unless/ I load nvidiafb before: if
I modprobe nvidiafb (it's a module, and it's blacklisted precisely for
this reason), then the screen is very snowy with X's nv too.

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work.


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 and max as you suggested:


 You might want to change  vfmin and vfmax to 59 and 61


and even the M and MR methods which you suggested in the other email.
Since nvidiafb is being loaded from the command line because it's a
blacklisted module otherwise, I've been using the mode_option option.
However, neither the mode_option nor fbset seem to give me anything
not snowy.

Damn.

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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
fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
fbmon: trying to fix monitor timings
nvidiafb: EDID found from BUS2

Display Information (EDID)

  EDID Version 1.3
  Manufacturer: SHP
  Model: 138e
  Serial#: 0
  Year: 1990 Week 0
  Display Characteristics:
 Monitor Operating Limits: From EDID
  H: 30-75KHz V: 60-60Hz DCLK: 170MHz
 Digital Display Input
 Sync:
 Max H-size in cm: 30
 Max V-size in cm: 23
 Gamma: 2.20
 DPMS: Active no, Suspend yes, Standby yes
 RGB Color Display
 Chroma
RedX: 0.599 RedY: 0.335
GreenX:   0.313 GreenY:   0.552
BlueX:0.150 BlueY:0.145
WhiteX:   0.313 WhiteY:   0.328
 First DETAILED Timing is preferred
  Detailed Timings
 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync

  Supported VESA Modes
 Manufacturer's mask: 0
  Standard Timings
 [EMAIL PROTECTED]

nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
nvidiafb: Panel size is 1600 x 1200
nvidiafb: Panel is TMDS
nvidiafb: MTRR set to ON
nvidiafb: Flat panel dithering disabled
Console: switching to colour frame buffer device 200x75
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE000)




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


--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 around (on all three of them).
> Suggestions on how to get the information welcome.

Is this the same monitor you posted here?

http://marc.theaimsgroup.com/?l=linux-kernel=112807065616218=2

If yes, we already have the manufacturer and model code. The main
problem is that the EDID of this display has no sync range (H: 75-75kHz
and V: 60-60Hz).  Extending Hsync from 30-75kHz as a fix to the EDID
block shouldn't be too hard.


Yes, that's it! Jeepers, I can't believe that even re-reading the past
LKML posts (even those!) I couldn't find the EDID info and how we had
gotten them. I guess I need stronger glasses.

Wonder why Luca's proposed patch makes the EDID undetectable, now, and
why can't it be retrieved at a later time via i2c. Timeouts too small?


I already have a patch for this which I forgot to send to you
before :-).  If you can confirm that this is still the same hardware,
I'll send you a test patch


Yes, it's the same hardware. I can try the patch, with or without Luca's.


--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 around (on all three of them).
 Suggestions on how to get the information welcome.

Is this the same monitor you posted here?

http://marc.theaimsgroup.com/?l=linux-kernelm=112807065616218w=2

If yes, we already have the manufacturer and model code. The main
problem is that the EDID of this display has no sync range (H: 75-75kHz
and V: 60-60Hz).  Extending Hsync from 30-75kHz as a fix to the EDID
block shouldn't be too hard.


Yes, that's it! Jeepers, I can't believe that even re-reading the past
LKML posts (even those!) I couldn't find the EDID info and how we had
gotten them. I guess I need stronger glasses.

Wonder why Luca's proposed patch makes the EDID undetectable, now, and
why can't it be retrieved at a later time via i2c. Timeouts too small?


I already have a patch for this which I forgot to send to you
before :-).  If you can confirm that this is still the same hardware,
I'll send you a test patch


Yes, it's the same hardware. I can try the patch, with or without Luca's.


--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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
fbmon: The EDID Block of Manufacturer: SHP Model: 0x138e is known to be broken,
fbmon: trying to fix monitor timings
nvidiafb: EDID found from BUS2

Display Information (EDID)

  EDID Version 1.3
  Manufacturer: SHP
  Model: 138e
  Serial#: 0
  Year: 1990 Week 0
  Display Characteristics:
 Monitor Operating Limits: From EDID
  H: 30-75KHz V: 60-60Hz DCLK: 170MHz
 Digital Display Input
 Sync:
 Max H-size in cm: 30
 Max V-size in cm: 23
 Gamma: 2.20
 DPMS: Active no, Suspend yes, Standby yes
 RGB Color Display
 Chroma
RedX: 0.599 RedY: 0.335
GreenX:   0.313 GreenY:   0.552
BlueX:0.150 BlueY:0.145
WhiteX:   0.313 WhiteY:   0.328
 First DETAILED Timing is preferred
  Detailed Timings
 160 MHz 1600 1664 1856 2112 1200 1201 1204 1250 -HSync -VSync

  Supported VESA Modes
 Manufacturer's mask: 0
  Standard Timings
 [EMAIL PROTECTED]

nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
nvidiafb: Panel size is 1600 x 1200
nvidiafb: Panel is TMDS
nvidiafb: MTRR set to ON
nvidiafb: Flat panel dithering disabled
Console: switching to colour frame buffer device 200x75
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE000)




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


--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 mode entry. But now you can use 'fbset
1024x768-60' (or any mode smaller than 1600x1200-60) for example and it
should work.


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 and max as you suggested:


 You might want to change  vfmin and vfmax to 59 and 61


and even the M and MR methods which you suggested in the other email.
Since nvidiafb is being loaded from the command line because it's a
blacklisted module otherwise, I've been using the mode_option option.
However, neither the mode_option nor fbset seem to give me anything
not snowy.

Damn.

--
Giuseppe Oblomov Bilotta
-
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 03/18] Dont leak NT bit into next task

[Giuseppe Bilotta]

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 %%rsi,%%rbp\n\t"
> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"

No idea if this is a problem or not, but you forgot a \n after popf.

-- 
Giuseppe "Oblomov" Bilotta

-
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 03/18] Dont leak NT bit into next task

[Giuseppe Bilotta]

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
 +#define RESTORE_CONTEXT movq %%rbp,%%rsi ; popq %%rbp ; popf\t

No idea if this is a problem or not, but you forgot a \n after popf.

-- 
Giuseppe Oblomov Bilotta

-
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: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

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
> minimum necessary in order to interoperate efficiently with the
> kernel".  Atari v. Nintendo is still good law, but only to the
> extent that it does not conflict with Lexmark, which now has the seal
> of Supreme Court approval.  And (IMHO, IANAL) if writing
> MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
> achieve the goal of interoperation with the kernels that people
> already have on their systems

Except that this is not about a driver that is supposed to interoperated
with the kernels people already have on their systems. This is about
shipping new (embedded) systems with a modified (if you go the s/_GPL//g
route, even more so) Linux kernel, and distribution a modified kernel *has*
to comply with the GPL, since this is *exactly* what the GPL is about:
redistribution of modified copies of the work.

-- 
Giuseppe "Oblomov" Bilotta

-
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: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

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
 minimum necessary in order to interoperate efficiently with the
 kernel.  Atari v. Nintendo is still good law, but only to the
 extent that it does not conflict with Lexmark, which now has the seal
 of Supreme Court approval.  And (IMHO, IANAL) if writing
 MODULE_LICENSE(GPL) is obviously the only remotely efficient way to
 achieve the goal of interoperation with the kernels that people
 already have on their systems

Except that this is not about a driver that is supposed to interoperated
with the kernels people already have on their systems. This is about
shipping new (embedded) systems with a modified (if you go the s/_GPL//g
route, even more so) Linux kernel, and distribution a modified kernel *has*
to comply with the GPL, since this is *exactly* what the GPL is about:
redistribution of modified copies of the work.

-- 
Giuseppe Oblomov Bilotta

-
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: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

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 was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static major/minors instead of dynamics ones, they
could skip sysfs, or they could even reimplement something like sysfs
themselves, or whatever other interface they deem useful for the purpose of
plopping in their own binary blob on top of it, sort of like what nVidia
and ATi do for their stuff.

-- 
Giuseppe "Oblomov" Bilotta

-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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, it wouldn't appear when I disabled EDID parsing because
it wouldn't touch the I2C bus at all. But it appears just the same.


Can you send me X.org log?



X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux oblomov 2.6.18-4-686 #1 SMP Fri Feb 2
15:10:49 UTC 2007 i686
Build Date: 03 February 2007
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Feb 13 10:09:25 2007
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Inspiron built-in monitor" (0)
(**) |   |-->Monitor "Dell Inspiron 8200 built-in monitor"
(**) |   |-->Device "NVIDIA Corporation NV11 [GeForce2 Go]"
(**) |-->Input Device "Inspiron built-in keyboard"
(**) |-->Input Device "Inspiron built-in touchpad"
(**) |-->Input Device "ACECAD Tablet"
(**) FontPath set to:
unix/:7100,
/usr/lib/X11/fonts/TrueType,
/usr/share/fonts/X11/Type1,
/usr/lib/X11/fonts/Speedo,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.3
X.Org Video Driver: 1.0
X.Org XInput driver : 0.6
X.Org Server Extension : 0.3
X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so
(II) Module bitmap: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.0
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.5
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules/libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 1.0.0
ABI class: X.Org Video Driver, version 1.0
(--) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,1a30 card , rev 04 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01
(II) PCI: 00:1d:0: chip 8086,2482 card 8086,4541 rev 02 class 0c,03,00 hdr 80
(II) PCI: 00:1d:2: chip 8086,2487 card 8086,4541 rev 02 class 0c,03,00 hdr 00
(II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01
(II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80
(II) PCI: 00:1f:1: chip 8086,248a card 8086,4541 rev 02 class 01,01,8a hdr 00
(II) PCI: 00:1f:5: chip 8086,2485 card 1013,5959 rev 02 class 04,01,00 hdr 00
(II) PCI: 00:1f:6: chip 8086,2486 card 14f1,5421 rev 02 class 07,03,00 hdr 00
(II) PCI: 01:00:0: chip 10de,0112 card 1028,00d4 rev b2 class 03,00,00 hdr 00
(II) PCI: 02:00:0: chip 10b7,9200 card 1028,00d4 rev 78 class 02,00,00 hdr 00
(II) PCI: 02:01:0: chip 104c,ac42 card e000, rev 00 class 06,07,00 hdr 82
(II) PCI: 02:01:1: chip 104c,ac42 card e800, rev 00 class 06,07,00 hdr 82
(II) PCI: 02:01:2: chip 104c,8027 card 1028,00d4 rev 00 class 0c,00,10 hdr 80
(II) PCI: End of PCI scan
(II) Intel Bridge workaround enabled
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,7), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
[0] -1  0   0x - 0x (0x1) IX[B]
(II) Bus 0 non-prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000e (VGA_EN is set)
(II) Bus 1 I/O range:
[0] -1  0   0xc000 - 0xc0ff (0x100) IX[B]
[1] -1  0   0xc400 - 0xc4ff (0x100) IX[B]
[2] -1  0   0xc800 - 0xc8ff (0x100) IX[B]
[3] -1  0   0xcc00 - 0xccff (0x100) IX[B]
(II) Bus 1 non-prefetchable memory range:
[0] -1  0   0xfc00 - 0xfdff (0x200) MX[B]
(II) Bus 1 prefetchable memory range:
[0] -1  0   0xe000 - 0xe7ff (0x800) MX[B]
(II) Subtractive PCI-to-PCI bridge:
(II) Bus 2: bridge is at (0:30:0), (0,2,16), BCTRL: 0x0006 (VGA_EN is cleared)
(II) Bus 2 I/O range:
[0] -1  0   

RE: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

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 think matters?

That you cannot build such modules without integrating parts of actual Linux
kernel code (via #includes etc), whereas you can build compatible toner
cartridges without using any original component.

-- 
Giuseppe "Oblomov" Bilotta

-
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: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

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 think matters?

That you cannot build such modules without integrating parts of actual Linux
kernel code (via #includes etc), whereas you can build compatible toner
cartridges without using any original component.

-- 
Giuseppe Oblomov Bilotta

-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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, it wouldn't appear when I disabled EDID parsing because
it wouldn't touch the I2C bus at all. But it appears just the same.


Can you send me X.org log?



X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux oblomov 2.6.18-4-686 #1 SMP Fri Feb 2
15:10:49 UTC 2007 i686
Build Date: 03 February 2007
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Tue Feb 13 10:09:25 2007
(==) Using config file: /etc/X11/xorg.conf
(==) ServerLayout Default Layout
(**) |--Screen Inspiron built-in monitor (0)
(**) |   |--Monitor Dell Inspiron 8200 built-in monitor
(**) |   |--Device NVIDIA Corporation NV11 [GeForce2 Go]
(**) |--Input Device Inspiron built-in keyboard
(**) |--Input Device Inspiron built-in touchpad
(**) |--Input Device ACECAD Tablet
(**) FontPath set to:
unix/:7100,
/usr/lib/X11/fonts/TrueType,
/usr/share/fonts/X11/Type1,
/usr/lib/X11/fonts/Speedo,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi
(==) RgbPath set to /etc/X11/rgb
(==) ModulePath set to /usr/lib/xorg/modules
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.3
X.Org Video Driver: 1.0
X.Org XInput driver : 0.6
X.Org Server Extension : 0.3
X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: bitmap
(II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so
(II) Module bitmap: vendor=X.Org Foundation
compiled for 7.1.1, module version = 1.0.0
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.5
(II) Loading font Bitmap
(II) LoadModule: pcidata
(II) Loading /usr/lib/xorg/modules/libpcidata.so
(II) Module pcidata: vendor=X.Org Foundation
compiled for 7.1.1, module version = 1.0.0
ABI class: X.Org Video Driver, version 1.0
(--) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,1a30 card , rev 04 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01
(II) PCI: 00:1d:0: chip 8086,2482 card 8086,4541 rev 02 class 0c,03,00 hdr 80
(II) PCI: 00:1d:2: chip 8086,2487 card 8086,4541 rev 02 class 0c,03,00 hdr 00
(II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01
(II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80
(II) PCI: 00:1f:1: chip 8086,248a card 8086,4541 rev 02 class 01,01,8a hdr 00
(II) PCI: 00:1f:5: chip 8086,2485 card 1013,5959 rev 02 class 04,01,00 hdr 00
(II) PCI: 00:1f:6: chip 8086,2486 card 14f1,5421 rev 02 class 07,03,00 hdr 00
(II) PCI: 01:00:0: chip 10de,0112 card 1028,00d4 rev b2 class 03,00,00 hdr 00
(II) PCI: 02:00:0: chip 10b7,9200 card 1028,00d4 rev 78 class 02,00,00 hdr 00
(II) PCI: 02:01:0: chip 104c,ac42 card e000, rev 00 class 06,07,00 hdr 82
(II) PCI: 02:01:1: chip 104c,ac42 card e800, rev 00 class 06,07,00 hdr 82
(II) PCI: 02:01:2: chip 104c,8027 card 1028,00d4 rev 00 class 0c,00,10 hdr 80
(II) PCI: End of PCI scan
(II) Intel Bridge workaround enabled
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,7), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
[0] -1  0   0x - 0x (0x1) IX[B]
(II) Bus 0 non-prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
[0] -1  0   0x - 0x (0x0) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000e (VGA_EN is set)
(II) Bus 1 I/O range:
[0] -1  0   0xc000 - 0xc0ff (0x100) IX[B]
[1] -1  0   0xc400 - 0xc4ff (0x100) IX[B]
[2] -1  0   0xc800 - 0xc8ff (0x100) IX[B]
[3] -1  0   0xcc00 - 0xccff (0x100) IX[B]
(II) Bus 1 non-prefetchable memory range:
[0] -1  0   0xfc00 - 0xfdff (0x200) MX[B]
(II) Bus 1 prefetchable memory range:
[0] -1  0   0xe000 - 0xe7ff (0x800) MX[B]
(II) Subtractive PCI-to-PCI bridge:
(II) Bus 2: bridge is at (0:30:0), (0,2,16), BCTRL: 0x0006 (VGA_EN is cleared)
(II) Bus 2 I/O range:
[0] -1  0   0xe000 - 0xe0ff (0x100) IX[B]
 

RE: GPL vs non-GPL device drivers

[Giuseppe Bilotta]

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 was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static major/minors instead of dynamics ones, they
could skip sysfs, or they could even reimplement something like sysfs
themselves, or whatever other interface they deem useful for the purpose of
plopping in their own binary blob on top of it, sort of like what nVidia
and ATi do for their stuff.

-- 
Giuseppe Oblomov Bilotta

-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

(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 mislinked. Anyway.

Your patch has an immediately visible effect of reducing snow: it
seems that now that you fixed the access bug the EDID is properly
/not/ used. dmesg | grep nvidiafb now claims the following:

"""

nvidiafb: Device ID: 10de0112
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.

(it actually gave the "I2C probe failed ..." message on console, but
it's not appearing in the dmesg, obviously, since it's a simple
printk)

nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
nvidiafb: Panel size is 1600 x 1200
nvidiafb: Panel is TMDS
nvidiafb: MTRR set to ON
nvidiafb: Flat panel dithering disabled
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE000)

"""

So the EDID still seems to be totally inaccessible (which means I
can't really tell why/when/where it's b0rked).

Finally, as I mentioned, console still has a little snow. It's barely
perceptible in common console usage because the monitor is mostly
black, but can get annoying with fullscreen apps à la mc.

This extra snow *might* be the effect of bandwidth limits Antonino
Daplas was referring to in this lkml message:
http://lkml.org/lkml/2005/10/1/7 but I'll have to enquire on this
further.

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

(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 mislinked. Anyway.

Your patch has an immediately visible effect of reducing snow: it
seems that now that you fixed the access bug the EDID is properly
/not/ used. dmesg | grep nvidiafb now claims the following:



nvidiafb: Device ID: 10de0112
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.

(it actually gave the I2C probe failed ... message on console, but
it's not appearing in the dmesg, obviously, since it's a simple
printk)

nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb :01:00.0: Unable to read EDID block.
nvidiafb: CRTC 1 is currently programmed for DFP
nvidiafb: Using DFP on CRTC 1
nvidiafb: Panel size is 1600 x 1200
nvidiafb: Panel is TMDS
nvidiafb: MTRR set to ON
nvidiafb: Flat panel dithering disabled
nvidiafb: PCI nVidia NV11 framebuffer (32MB @ 0xE000)



So the EDID still seems to be totally inaccessible (which means I
can't really tell why/when/where it's b0rked).

Finally, as I mentioned, console still has a little snow. It's barely
perceptible in common console usage because the monitor is mostly
black, but can get annoying with fullscreen apps à la mc.

This extra snow *might* be the effect of bandwidth limits Antonino
Daplas was referring to in this lkml message:
http://lkml.org/lkml/2005/10/1/7 but I'll have to enquire on this
further.

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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, you can drive them with whatever
you want through the devices exported by I2C core.
The fact the none of them work makes me think that the EDID is coming
from the BIOS, we do VBE calls in real mode during early kernel setup.


So what am I supposed to do to dump it, since neither i2cdump neither
get-edid seem to work?

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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, you can drive them with whatever
you want through the devices exported by I2C core.
The fact the none of them work makes me think that the EDID is coming
from the BIOS, we do VBE calls in real mode during early kernel setup.


So what am I supposed to do to dump it, since neither i2cdump neither
get-edid seem to work?

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 resolution of 1600x1200. I've been looking all around
for more info on it, but the only things I could find were posts that
remarked the problems Windows nVidia drivers have with some of these
(no image when running at 1600x1200), and other posts about banded
gradients with Windows drivers on Radeon video cards (but I get banded
gradients also win my nVidia card, on Linux, regardless of which
driver I use, binary, nv or nouveau).

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 around (on all three of them).
Suggestions on how to get the information welcome.

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 resolution of 1600x1200. I've been looking all around
for more info on it, but the only things I could find were posts that
remarked the problems Windows nVidia drivers have with some of these
(no image when running at 1600x1200), and other posts about banded
gradients with Windows drivers on Radeon video cards (but I get banded
gradients also win my nVidia card, on Linux, regardless of which
driver I use, binary, nv or nouveau).

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 around (on all three of them).
Suggestions on how to get the information welcome.

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 unshure about bus number try with all the available
/dev/i2c-* devices (you may want to unload HW monitor drivers first, so
you don't poke at random stuff).


No luck. i2c-dev and dependencies are loaded
""" lsmod | grep i2c reports """
i2c_i8017404  0
i2c_isa 5152  0
i2c_piix4   8140  0
i2c_algo_pcf6180  0
i2c_algo_pca5380  0
i2c_algo_bit8424  0
i2c_dev 8548  0
i2c_core   19680  7
i2c_i801,i2c_isa,i2c_piix4,i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_dev


There is no such thing as /dev/i2c* UNLESS I load nvidiafb. When I
load that, I get three busses (i2c-0, -1, and -2), but i2cdump N 0x50
gives me a nice tableau of X's all around, for all values of N. This
is using kernel 2.6.18-3 stock Debian kernel. I'll keep trying with
some variations, to see if I can get more sensible information.

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 unshure about bus number try with all the available
/dev/i2c-* devices (you may want to unload HW monitor drivers first, so
you don't poke at random stuff).


No luck. i2c-dev and dependencies are loaded
 lsmod | grep i2c reports 
i2c_i8017404  0
i2c_isa 5152  0
i2c_piix4   8140  0
i2c_algo_pcf6180  0
i2c_algo_pca5380  0
i2c_algo_bit8424  0
i2c_dev 8548  0
i2c_core   19680  7
i2c_i801,i2c_isa,i2c_piix4,i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_dev


There is no such thing as /dev/i2c* UNLESS I load nvidiafb. When I
load that, I get three busses (i2c-0, -1, and -2), but i2cdump N 0x50
gives me a nice tableau of X's all around, for all values of N. This
is using kernel 2.6.18-3 stock Debian kernel. I'll keep trying with
some variations, to see if I can get more sensible information.

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 output from get-edid

"""
get-edid: get-edid version 1.4.1

Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful

VBE version 300
VBE string at 0x0 "NVidia"

VBE/DDC service about to be called
Report DDC capabilities

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful

Monitor and video card combination does not support DDC1 transfers
Monitor and video card combination does not support DDC2 transfers
0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
Read EDID

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
Function supported
Call failed

The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
"""

Anything else I can try?

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 output from get-edid


get-edid: get-edid version 1.4.1

Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful

VBE version 300
VBE string at 0x0 NVidia

VBE/DDC service about to be called
Report DDC capabilities

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful

Monitor and video card combination does not support DDC1 transfers
Monitor and video card combination does not support DDC2 transfers
0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
Read EDID

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
Function supported
Call failed

The EDID data should not be trusted as the VBE call failed
Error: output block unchanged


Anything else I can try?

--
Giuseppe Oblomov Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 else the
> > programming of the card registers from edid is wrong..
>
> In which case the same problem would occur with different video cards, so
> this patch should be some generic thing, available to all drivers, no?

It should be in the fb layer not card specific.. as it may happen on any card...


Although solving the problem at the fb layer level is probably the
correct/best way to do it, I am not aware of people having problems
with broken EDIDs and non-nVidia cards. By contrast, workarounds for
nVidia and broken EDIDs is a very common thing to do even on Windows.
Both the Windows and the Linux proprietary drivers need SoftEDID
specifications to work around these problems. I don't know if this is
just because of the way the driver are written, though, or if nVidia
cards are particularly unable to handle monitors with broken EDIDs.

Plus, providing an fb-layer-level solution is way beyond my kernel
programming experience :)

--
Giuseppe "Oblomov" Bilotta
-
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-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 else the
  programming of the card registers from edid is wrong..

 In which case the same problem would occur with different video cards, so
 this patch should be some generic thing, available to all drivers, no?

It should be in the fb layer not card specific.. as it may happen on any card...


Although solving the problem at the fb layer level is probably the
correct/best way to do it, I am not aware of people having problems
with broken EDIDs and non-nVidia cards. By contrast, workarounds for
nVidia and broken EDIDs is a very common thing to do even on Windows.
Both the Windows and the Linux proprietary drivers need SoftEDID
specifications to work around these problems. I don't know if this is
just because of the way the driver are written, though, or if nVidia
cards are particularly unable to handle monitors with broken EDIDs.

Plus, providing an fb-layer-level solution is way beyond my kernel
programming experience :)

--
Giuseppe Oblomov Bilotta
-
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] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 kernels are compiled with
CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
framebuffer on said broken system without recompiling the kernel
(or at least the nvidiafb module).

Solve the issue by introducing a new boolean module parameter (useedid)
which can be set to 0 to prevent the driver from using the EDID
information.

Signed-off-by: Giuseppe Bilotta <[EMAIL PROTECTED]>

---

If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C
altogether.


diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index 8454adf..6387f2b 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -25,6 +25,8 @@
 
 #include "../edid.h"
 
+extern int useedid;
+
 static void nvidia_gpio_setscl(void *data, int state)
 {
struct nvidia_i2c_chan *chan = data;
@@ -128,6 +130,9 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan 
*chan, const char *name)
 
 void nvidia_create_i2c_busses(struct nvidia_par *par)
 {
+   if (!useedid)
+   return;
+
par->bus = 3;
 
par->chan[0].par = par;
@@ -146,6 +151,9 @@ void nvidia_create_i2c_busses(struct nvidia_par *par)
 
 void nvidia_delete_i2c_busses(struct nvidia_par *par)
 {
+   if (!useedid)
+   return;
+
if (par->chan[0].par)
i2c_del_adapter(>chan[0].adapter);
par->chan[0].par = NULL;
@@ -195,6 +203,9 @@ static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan 
*chan)
 
 int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
 {
+   if (!useedid)
+   return -1;
+
struct nvidia_par *par = info->par;
u8 *edid = NULL;
int i;
diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
index 538e947..179fd67 100644
--- a/drivers/video/nvidia/nvidia.c
+++ b/drivers/video/nvidia/nvidia.c
@@ -83,6 +83,9 @@ static int bpp __devinitdata = 8;
 #ifdef CONFIG_MTRR
 static int nomtrr __devinitdata = 0;
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+int useedid __devinitdata = 1;
+#endif
 
 static char *mode_option __devinitdata = NULL;
 
@@ -1506,6 +1509,11 @@ module_param(nomtrr, bool, 0);
 MODULE_PARM_DESC(nomtrr, "Disables MTRR support (0 or 1=disabled) "
 "(default=0)");
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+module_param(useedid, bool, 0);
+MODULE_PARM_DESC(useedid, "Use EDID to detect video modes (0 or 1) "
+"(default=1, use EDID)");
+#endif
 
 MODULE_AUTHOR("Antonino Daplas");
 MODULE_DESCRIPTION("Framebuffer driver for nVidia graphics chipset");




-- 
Giuseppe "Oblomov" Bilotta

-
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] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

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 kernels are compiled with
CONFIG_FB_NVIDIA_I2C enabled, this prevents usage of the nvidia
framebuffer on said broken system without recompiling the kernel
(or at least the nvidiafb module).

Solve the issue by introducing a new boolean module parameter (useedid)
which can be set to 0 to prevent the driver from using the EDID
information.

Signed-off-by: Giuseppe Bilotta [EMAIL PROTECTED]

---

If this patch is accepted, we can probably get rid of CONFIG_FB_NVIDIA_I2C
altogether.


diff --git a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
index 8454adf..6387f2b 100644
--- a/drivers/video/nvidia/nv_i2c.c
+++ b/drivers/video/nvidia/nv_i2c.c
@@ -25,6 +25,8 @@
 
 #include ../edid.h
 
+extern int useedid;
+
 static void nvidia_gpio_setscl(void *data, int state)
 {
struct nvidia_i2c_chan *chan = data;
@@ -128,6 +130,9 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan 
*chan, const char *name)
 
 void nvidia_create_i2c_busses(struct nvidia_par *par)
 {
+   if (!useedid)
+   return;
+
par-bus = 3;
 
par-chan[0].par = par;
@@ -146,6 +151,9 @@ void nvidia_create_i2c_busses(struct nvidia_par *par)
 
 void nvidia_delete_i2c_busses(struct nvidia_par *par)
 {
+   if (!useedid)
+   return;
+
if (par-chan[0].par)
i2c_del_adapter(par-chan[0].adapter);
par-chan[0].par = NULL;
@@ -195,6 +203,9 @@ static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan 
*chan)
 
 int nvidia_probe_i2c_connector(struct fb_info *info, int conn, u8 **out_edid)
 {
+   if (!useedid)
+   return -1;
+
struct nvidia_par *par = info-par;
u8 *edid = NULL;
int i;
diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
index 538e947..179fd67 100644
--- a/drivers/video/nvidia/nvidia.c
+++ b/drivers/video/nvidia/nvidia.c
@@ -83,6 +83,9 @@ static int bpp __devinitdata = 8;
 #ifdef CONFIG_MTRR
 static int nomtrr __devinitdata = 0;
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+int useedid __devinitdata = 1;
+#endif
 
 static char *mode_option __devinitdata = NULL;
 
@@ -1506,6 +1509,11 @@ module_param(nomtrr, bool, 0);
 MODULE_PARM_DESC(nomtrr, Disables MTRR support (0 or 1=disabled) 
 (default=0));
 #endif
+#ifdef CONFIG_FB_NVIDIA_I2C
+module_param(useedid, bool, 0);
+MODULE_PARM_DESC(useedid, Use EDID to detect video modes (0 or 1) 
+(default=1, use EDID));
+#endif
 
 MODULE_AUTHOR(Antonino Daplas);
 MODULE_DESCRIPTION(Framebuffer driver for nVidia graphics chipset);




-- 
Giuseppe Oblomov Bilotta

-
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 01/24] Unionfs: Documentation

[Giuseppe Bilotta]

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, it'd only address new processes: if an existing process has
> an open fd in a lower branch before we "lock up" the lower branch's name
> space, that process may still be able to make lower-level changes.
> Detecting such processes may not be easy.  What to do with them, once
> detected, is also unclear.  We welcome suggestions.

As a simple user without much knowledge of kernel internals, much less
so filesystems, couldn't something based on the same principle of
lsof+fam be used to handle these situations? lsof, if I'm not
mistaken, can tell a user if someone (and who) has fd opened on a file
system; and fam can notify other processes that a particular file has
been modified. Unionfs could use something like lsof (or som similar
ad hoc solution) to see if something has anything opened on a
filesystem, and it could use something like fam to detect changes in
the underlying filesystem and flush caches as appropriate.

Of course, this wouldn't solve "concurrent changes" problems, but this
could be made possible by having a system to synchronize locks across
filesystems.

-- 
Giuseppe "Oblomov" Bilotta

[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance? Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and
tyrants.
-- Thomas Jefferson, letter to Col. William S. Smith, 1787

-
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 01/24] Unionfs: Documentation

[Giuseppe Bilotta]

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, it'd only address new processes: if an existing process has
 an open fd in a lower branch before we lock up the lower branch's name
 space, that process may still be able to make lower-level changes.
 Detecting such processes may not be easy.  What to do with them, once
 detected, is also unclear.  We welcome suggestions.

As a simple user without much knowledge of kernel internals, much less
so filesystems, couldn't something based on the same principle of
lsof+fam be used to handle these situations? lsof, if I'm not
mistaken, can tell a user if someone (and who) has fd opened on a file
system; and fam can notify other processes that a particular file has
been modified. Unionfs could use something like lsof (or som similar
ad hoc solution) to see if something has anything opened on a
filesystem, and it could use something like fam to detect changes in
the underlying filesystem and flush caches as appropriate.

Of course, this wouldn't solve concurrent changes problems, but this
could be made possible by having a system to synchronize locks across
filesystems.

-- 
Giuseppe Oblomov Bilotta

[W]hat country can preserve its liberties, if its rulers are not
warned from time to time that [the] people preserve the spirit of
resistance? Let them take arms...The tree of liberty must be
refreshed from time to time, with the blood of patriots and
tyrants.
-- Thomas Jefferson, letter to Col. William S. Smith, 1787

-
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: JMicron JMB363 SATA hard disk appears twice (sda + hdg)

[Giuseppe Bilotta]

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. 
> 
> If you build both IDE and libata support for the same hardware into your
> kernel it should generally end up with only one driver claiming the
> hardware but the AHCI case doesn't handle this in 2.6.18.

[and in another post:]

> You have both the drivers for the Jmicron via drivers/ide and via
> drivers/ata (libata) loaded. In that specific combination the two drivers
> don't use the same resources so don't spot the other one is busy.

Thanks for the explanation. I had suspected such an interaction,
especially since browsing the LKML it seems that this doubling of the
interfaces with the JMicron controllers is an intentional change:
http://lkml.org/lkml/2006/7/12/133>.

So the only problem is how to tell the kernel to not use ide on the
SATA channels, and this is what I had tried to do with ide2=noprobe
ide3=noprobe. However, this doesn't seem to happen. Am I
misinterpreting the meaning of the idex=noprobe parameter?

BTW, is there a preference for libata or the jmicron ide driver?
Assuming I finally manage to only make it appear once, which one
should I go for?

-- 
Giuseppe "Oblomov" Bilotta

"I weep for our generation" -- Charlie Brown

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

JMicron JMB363 SATA hard disk appears twice (sda + hdg)

[Giuseppe Bilotta]

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
00:00.2 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.5 PIC: VIA Technologies, Inc. VT3351 I/O APIC Interrupt Controller
00:00.7 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. [K8T890 North / VT8237 South] PCI 
Bridge
00:02.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.1 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.2 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.3 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller 
(rev 46)
00:0f.0 IDE interface: VIA Technologies, Inc. VT8237A SATA 2-Port Controller 
(rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)
00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237A PCI to ISA Bridge
00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
00:13.0 Host bridge: VIA Technologies, Inc. VT8237A Host Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
02:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI 
Controller (rev 02)
02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI 
Controller (rev 02)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI 
Express Gigabit Ethernet controller (rev 01)
06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev 
a2)
80:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio 
Controller (rev 10)

I have a DVD burner attached to the first IDE channel and a hard
disk (THE hard disk) attached to the SATA_II controller.

The BIOS is set to use the SATA controllers in AHCI mode, not IDE.
However, the hard disk appears twice, first as hdg, then as sda.
Passing ide2=noprobe ide3=noprobe as boot parameters to the kernel
doesn't seem to have any effect:

ATA/IDE-relative dmesg without noprobe:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
JMB363: IDE controller at PCI slot :02:00.1
ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:DMA, hdh:pio
Probing IDE interface ide2...
Probing IDE interface ide3...
hdg: ST3320620AS, ATA DISK drive
ide3 at 0xd800-0xd807,0xd482 on irq 74
ahci :02:00.0: AHCI 0001. 32 slots 2 ports 3 Gbps 0x3 impl
SATA mode
ata1: SATA max UDMA/133 cmd 0xF8874100 ctl 0x0 bmdma 0x0 irq 122
ata2: SATA max UDMA/133 cmd 0xF8874180 ctl 0x0 bmdma 0x0 irq 122
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth
31/32)
ata2: SATA link down (SStatus 0 SControl 300)
  Vendor: ATA   Model: ST3320620AS   Rev: 3.AA
VP_IDE: IDE controller at PCI slot :00:0f.1
VP_IDE: chipset revision 7
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237a (rev 00) IDE UDMA133 controller on
pci:00:0f.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
ide3: reset: master: error (0xff?); slave: failed
ide3: reset: master: error (0xff?); slave: failed
hda: PHILIPS DVDR1668P1, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ata3: SATA max UDMA/133 cmd 0xCC00 ctl 0xC882 bmdma 0xC400 irq 106
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xC482 bmdma 0xC408 irq 106
hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
ata3: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0xCC07
ata4: SATA link down 

JMicron JMB363 SATA hard disk appears twice (sda + hdg)

[Giuseppe Bilotta]

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
00:00.2 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:00.5 PIC: VIA Technologies, Inc. VT3351 I/O APIC Interrupt Controller
00:00.7 Host bridge: VIA Technologies, Inc. VT3351 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. [K8T890 North / VT8237 South] PCI 
Bridge
00:02.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.1 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.2 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:03.3 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller
00:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller 
(rev 46)
00:0f.0 IDE interface: VIA Technologies, Inc. VT8237A SATA 2-Port Controller 
(rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)
00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 
Controller (rev a0)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237A PCI to ISA Bridge
00:11.7 Host bridge: VIA Technologies, Inc. VT8251 Ultra VLINK Controller
00:13.0 Host bridge: VIA Technologies, Inc. VT8237A Host Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
02:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI 
Controller (rev 02)
02:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI 
Controller (rev 02)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI 
Express Gigabit Ethernet controller (rev 01)
06:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev 
a2)
80:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio 
Controller (rev 10)

I have a DVD burner attached to the first IDE channel and a hard
disk (THE hard disk) attached to the SATA_II controller.

The BIOS is set to use the SATA controllers in AHCI mode, not IDE.
However, the hard disk appears twice, first as hdg, then as sda.
Passing ide2=noprobe ide3=noprobe as boot parameters to the kernel
doesn't seem to have any effect:

ATA/IDE-relative dmesg without noprobe:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
JMB363: IDE controller at PCI slot :02:00.1
ide2: BM-DMA at 0xd400-0xd407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xd408-0xd40f, BIOS settings: hdg:DMA, hdh:pio
Probing IDE interface ide2...
Probing IDE interface ide3...
hdg: ST3320620AS, ATA DISK drive
ide3 at 0xd800-0xd807,0xd482 on irq 74
ahci :02:00.0: AHCI 0001. 32 slots 2 ports 3 Gbps 0x3 impl
SATA mode
ata1: SATA max UDMA/133 cmd 0xF8874100 ctl 0x0 bmdma 0x0 irq 122
ata2: SATA max UDMA/133 cmd 0xF8874180 ctl 0x0 bmdma 0x0 irq 122
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth
31/32)
ata2: SATA link down (SStatus 0 SControl 300)
  Vendor: ATA   Model: ST3320620AS   Rev: 3.AA
VP_IDE: IDE controller at PCI slot :00:0f.1
VP_IDE: chipset revision 7
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237a (rev 00) IDE UDMA133 controller on
pci:00:0f.1
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
ide3: reset: master: error (0xff?); slave: failed
ide3: reset: master: error (0xff?); slave: failed
hda: PHILIPS DVDR1668P1, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ata3: SATA max UDMA/133 cmd 0xCC00 ctl 0xC882 bmdma 0xC400 irq 106
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xC482 bmdma 0xC408 irq 106
hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
ata3: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0xCC07
ata4: SATA link down 

Re: JMicron JMB363 SATA hard disk appears twice (sda + hdg)

[Giuseppe Bilotta]

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. 
 
 If you build both IDE and libata support for the same hardware into your
 kernel it should generally end up with only one driver claiming the
 hardware but the AHCI case doesn't handle this in 2.6.18.

[and in another post:]

 You have both the drivers for the Jmicron via drivers/ide and via
 drivers/ata (libata) loaded. In that specific combination the two drivers
 don't use the same resources so don't spot the other one is busy.

Thanks for the explanation. I had suspected such an interaction,
especially since browsing the LKML it seems that this doubling of the
interfaces with the JMicron controllers is an intentional change:
URL:http://lkml.org/lkml/2006/7/12/133.

So the only problem is how to tell the kernel to not use ide on the
SATA channels, and this is what I had tried to do with ide2=noprobe
ide3=noprobe. However, this doesn't seem to happen. Am I
misinterpreting the meaning of the idex=noprobe parameter?

BTW, is there a preference for libata or the jmicron ide driver?
Assuming I finally manage to only make it appear once, which one
should I go for?

-- 
Giuseppe Oblomov Bilotta

I weep for our generation -- Charlie Brown

-
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: Open letter to Linux kernel developers (was Re: Binary Drivers)

[Giuseppe Bilotta]

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 developer can release software under GPL only if 
> it's considered invaluable or if there is some way to guarantee 
> sufficient income. Releasing something under GPL without a guaranteed 
> backup plan is like jumping from an airplane without parasuit.

Except that we're talking about *hardware* companies here, not
*software* companies. *Hardware* companies make money by selling
*hardware*, not the software that drives it: in fact, they always
distribute the 'software' they write (the drivers) for free (gratis).

So while what you say is perfectly sensible for *software* developers,
it has absolutely nothing to do with the closed source drivers
*hardware* companies distribute.

This all being said, I think that the only thing that can shake
companies such as nVidia and ATI is a project such as the Open
Graphics Card
http://wiki.duskglow.com/tiki-index.php?page=Open-Graphics
to succeed.

-- 
Giuseppe "Oblomov" Bilotta

Hic manebimus optime

-
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: Open letter to Linux kernel developers (was Re: Binary Drivers)

[Giuseppe Bilotta]

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 developer can release software under GPL only if 
 it's considered invaluable or if there is some way to guarantee 
 sufficient income. Releasing something under GPL without a guaranteed 
 backup plan is like jumping from an airplane without parasuit.

Except that we're talking about *hardware* companies here, not
*software* companies. *Hardware* companies make money by selling
*hardware*, not the software that drives it: in fact, they always
distribute the 'software' they write (the drivers) for free (gratis).

So while what you say is perfectly sensible for *software* developers,
it has absolutely nothing to do with the closed source drivers
*hardware* companies distribute.

This all being said, I think that the only thing that can shake
companies such as nVidia and ATI is a project such as the Open
Graphics Card
http://wiki.duskglow.com/tiki-index.php?page=Open-Graphics
to succeed.

-- 
Giuseppe Oblomov Bilotta

Hic manebimus optime

-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Giuseppe Bilotta]

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 "Oblomov" Bilotta

"E la storia dell'umanità, babbo?"
"Ma niente: prima si fanno delle cazzate,
 poi si studia che cazzate si sono fatte"
(Altan)
("And what about the history of the human race, dad?"
 "Oh, nothing special: first they make some foolish things,
  then you study what foolish things have been made")

-
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: Kernel SCM saga..

[Giuseppe Bilotta]

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 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: Kernel SCM saga..

[Giuseppe Bilotta]

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 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Giuseppe Bilotta]

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 Oblomov Bilotta

E la storia dell'umanità, babbo?
Ma niente: prima si fanno delle cazzate,
 poi si studia che cazzate si sono fatte
(Altan)
(And what about the history of the human race, dad?
 Oh, nothing special: first they make some foolish things,
  then you study what foolish things have been made)

-
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: PCI: increase the size of the pci.ids strings

[Giuseppe Bilotta]

On Fri, 1 Apr 2005 15:47:48 -0800, Greg KH wrote:

> -#define PCI_NAME_SIZE96
> +#define PCI_NAME_SIZE255
>  #define PCI_NAME_HALF__stringify(43) /* less than half to handle 
> slop */

Shouldn't PCI_NAME_HALF be changed too? To something like 109 or 113?

-- 
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] : remove unreliable, unused and unmainained arch from kernel.

[Giuseppe Bilotta]

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 Franklin

-
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] : remove unreliable, unused and unmainained arch from kernel.

[Giuseppe Bilotta]

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 Franklin

-
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: PCI: increase the size of the pci.ids strings

[Giuseppe Bilotta]

On Fri, 1 Apr 2005 15:47:48 -0800, Greg KH wrote:

 -#define PCI_NAME_SIZE96
 +#define PCI_NAME_SIZE255
  #define PCI_NAME_HALF__stringify(43) /* less than half to handle 
 slop */

Shouldn't PCI_NAME_HALF be changed too? To something like 109 or 113?

-- 
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/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dmesg verbosity [was Re: AGP bogosities]

[Giuseppe Bilotta]

> > 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 "loaded at boot" stuff in the first 
bytes of the hard disk?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: dmesg verbosity [was Re: AGP bogosities]

[Giuseppe Bilotta]

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 do
> NOW.
> 
> The solution is fairly well known.  Rather than treating the zillions of
> disk seeks during the boot process as random unconnected events, you
> analyze the I/O done during the boot process, then lay out those disk
> blocks optimally based on this information so on the next boot you just
> do one big streaming read.  The patent side has been discussed and there
> seems to be plenty of prior art.
> 
> Someone needs to just do it.  All the required information is right
> there.

Hm. My previous WinXP box (this same machine, different hard 
disk) was VERY fast in booting WinXP, out of the box. After two 
years of usage, installations, uninstallations and whatnot it 
had become slow as molasses. The Linux installation on the SAME 
machine was not affected.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: dmesg verbosity [was Re: AGP bogosities]

[Giuseppe Bilotta]

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.

What are the cons of using "all of" the RAM at boot time to 
cache the boot disk?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: dmesg verbosity [was Re: AGP bogosities]

[Giuseppe Bilotta]

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.

What are the cons of using all of the RAM at boot time to 
cache the boot disk?

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: dmesg verbosity [was Re: AGP bogosities]

[Giuseppe Bilotta]

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 do
 NOW.
 
 The solution is fairly well known.  Rather than treating the zillions of
 disk seeks during the boot process as random unconnected events, you
 analyze the I/O done during the boot process, then lay out those disk
 blocks optimally based on this information so on the next boot you just
 do one big streaming read.  The patent side has been discussed and there
 seems to be plenty of prior art.
 
 Someone needs to just do it.  All the required information is right
 there.

Hm. My previous WinXP box (this same machine, different hard 
disk) was VERY fast in booting WinXP, out of the box. After two 
years of usage, installations, uninstallations and whatnot it 
had become slow as molasses. The Linux installation on the SAME 
machine was not affected.

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: dmesg verbosity [was Re: AGP bogosities]

[Giuseppe Bilotta]

  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 loaded at boot stuff in the first amount of RAM
bytes of the hard disk?

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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 0/5] I8K driver facelift

[Giuseppe Bilotta]

> 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 cents
Pounds shillings and pence
  (Roger Waters)

-
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 0/5] I8K driver facelift

[Giuseppe Bilotta]

 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 cents
Pounds shillings and pence
  (Roger Waters)

-
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: Re: 2.6.11-rc5

[Giuseppe Bilotta]

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 or simply blank (but no lock-up; could still 
blind type). I finally discovered that the problem only 
happened when the driver was compiled as a module.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: Re: 2.6.11-rc5

[Giuseppe Bilotta]

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 or simply blank (but no lock-up; could still 
blind type). I finally discovered that the problem only 
happened when the driver was compiled as a module.

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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-usb-devel] 2.6: USB disk unusable level of data corruption

[Giuseppe Bilotta]

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 it via the Hamlet PCMCIA USB2 Card Adapter doesn't 
> > work (it seems it gets assigned minors 1,2,3,4,5,6,... and so 
> > on forever until I unplug it).
> 
> What do you mean "minors"?  Addresses or actual /dev/sdN numbers?
> 
> If it's addresses, that would be an an enumeration problem.  Some
> recent changes have caused prolems there, 2.6.11-rc3-mm2 ought to
> have a patch making it better.  (Well, working around one of the
> two problems that'd suggest.)

Sorry, it's addresses.

usb 5-1: new high speed USB device using ehci_hcd and address 4
usb 5-1: new high speed USB device using ehci_hcd and address 5
usb 5-1: new high speed USB device using ehci_hcd and address 6

blah blah blah, neverending. So yes, it's probably the 
enumeration problem.

Also, when I plug in the PCMCIA card I get (sorry for the 
wrapping, Gravity sucks)

PCI: Enabling device :07:00.0 ( -> 0002)
ACPI: PCI interrupt :07:00.0[A] -> GSI 11 (level, low) -> 
IRQ 11
ohci_hcd :07:00.0: NEC Corporation USB
PCI: Setting latency timer of device :07:00.0 to 64
ohci_hcd :07:00.0: irq 11, pci mem 0x2900
ohci_hcd :07:00.0: new USB bus registered, assigned bus 
number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
PCI: Enabling device :07:00.1 ( -> 0002)
ACPI: PCI interrupt :07:00.1[B] -> GSI 11 (level, low) -> 
IRQ 11
ohci_hcd :07:00.1: NEC Corporation USB (#2)
PCI: Setting latency timer of device :07:00.1 to 64
ohci_hcd :07:00.1: irq 11, pci mem 0x29001000
ohci_hcd :07:00.1: new USB bus registered, assigned bus 
number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PCI: Enabling device :07:00.2 ( -> 0002)
ACPI: PCI interrupt :07:00.2[C] -> GSI 11 (level, low) -> 
IRQ 11
ehci_hcd :07:00.2: NEC Corporation USB 2.0
ehci_hcd :07:00.2: irq 11, pci mem 0x29002000
ehci_hcd :07:00.2: new USB bus registered, assigned bus 
number 5
ehci_hcd :07:00.2: USB 2.0 initialized, EHCI 0.95, driver 
26 Oct 2004
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 5 ports detected 

The card only has 2 USB ports .. why 5 ports here? Is this the 
same bug?

Another interesting tidbit is that I get:

USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt :00:1d.0[A] -> GSI 11 (level, low) -> 
IRQ 11
uhci_hcd :00:1d.0: Intel Corp. 82801CA/CAM USB (Hub #1)
PCI: Setting latency timer of device :00:1d.0 to 64
uhci_hcd :00:1d.0: irq 11, io base 0xbf80
uhci_hcd :00:1d.0: new USB bus registered, assigned bus 
number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI interrupt :00:1d.2[C] -> GSI 11 (level, low) -> 
IRQ 11
uhci_hcd :00:1d.2: Intel Corp. 82801CA/CAM USB (Hub #3)
PCI: Setting latency timer of device :00:1d.2 to 64
uhci_hcd :00:1d.2: irq 11, io base 0xbf20
uhci_hcd :00:1d.2: new USB bus registered, assigned bus 
number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected 

for the built-in ports ... I only have two USB ports on this 
machine though, why does it see 4 of them?

(Do you also need the lspci and/or lsusb and/or dmesg of the 
error that happens when I disable the EHCI driver and only let 
the OHCI manage the PCMCIA card?)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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-usb-devel] 2.6: USB disk unusable level of data corruption

[Giuseppe Bilotta]

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 it via the Hamlet PCMCIA USB2 Card Adapter doesn't 
  work (it seems it gets assigned minors 1,2,3,4,5,6,... and so 
  on forever until I unplug it).
 
 What do you mean minors?  Addresses or actual /dev/sdN numbers?
 
 If it's addresses, that would be an an enumeration problem.  Some
 recent changes have caused prolems there, 2.6.11-rc3-mm2 ought to
 have a patch making it better.  (Well, working around one of the
 two problems that'd suggest.)

Sorry, it's addresses.

usb 5-1: new high speed USB device using ehci_hcd and address 4
usb 5-1: new high speed USB device using ehci_hcd and address 5
usb 5-1: new high speed USB device using ehci_hcd and address 6

blah blah blah, neverending. So yes, it's probably the 
enumeration problem.

Also, when I plug in the PCMCIA card I get (sorry for the 
wrapping, Gravity sucks)

PCI: Enabling device :07:00.0 ( - 0002)
ACPI: PCI interrupt :07:00.0[A] - GSI 11 (level, low) - 
IRQ 11
ohci_hcd :07:00.0: NEC Corporation USB
PCI: Setting latency timer of device :07:00.0 to 64
ohci_hcd :07:00.0: irq 11, pci mem 0x2900
ohci_hcd :07:00.0: new USB bus registered, assigned bus 
number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
PCI: Enabling device :07:00.1 ( - 0002)
ACPI: PCI interrupt :07:00.1[B] - GSI 11 (level, low) - 
IRQ 11
ohci_hcd :07:00.1: NEC Corporation USB (#2)
PCI: Setting latency timer of device :07:00.1 to 64
ohci_hcd :07:00.1: irq 11, pci mem 0x29001000
ohci_hcd :07:00.1: new USB bus registered, assigned bus 
number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PCI: Enabling device :07:00.2 ( - 0002)
ACPI: PCI interrupt :07:00.2[C] - GSI 11 (level, low) - 
IRQ 11
ehci_hcd :07:00.2: NEC Corporation USB 2.0
ehci_hcd :07:00.2: irq 11, pci mem 0x29002000
ehci_hcd :07:00.2: new USB bus registered, assigned bus 
number 5
ehci_hcd :07:00.2: USB 2.0 initialized, EHCI 0.95, driver 
26 Oct 2004
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 5 ports detected 

The card only has 2 USB ports .. why 5 ports here? Is this the 
same bug?

Another interesting tidbit is that I get:

USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt :00:1d.0[A] - GSI 11 (level, low) - 
IRQ 11
uhci_hcd :00:1d.0: Intel Corp. 82801CA/CAM USB (Hub #1)
PCI: Setting latency timer of device :00:1d.0 to 64
uhci_hcd :00:1d.0: irq 11, io base 0xbf80
uhci_hcd :00:1d.0: new USB bus registered, assigned bus 
number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI interrupt :00:1d.2[C] - GSI 11 (level, low) - 
IRQ 11
uhci_hcd :00:1d.2: Intel Corp. 82801CA/CAM USB (Hub #3)
PCI: Setting latency timer of device :00:1d.2 to 64
uhci_hcd :00:1d.2: irq 11, io base 0xbf20
uhci_hcd :00:1d.2: new USB bus registered, assigned bus 
number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected 

for the built-in ports ... I only have two USB ports on this 
machine though, why does it see 4 of them?

(Do you also need the lspci and/or lsusb and/or dmesg of the 
error that happens when I disable the EHCI driver and only let 
the OHCI manage the PCMCIA card?)

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: Dell Inspiron sensors (was: Re: Huge unreliability - does Linux have something to do with it?)

[Giuseppe Bilotta]

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 A/C unit.  Take that air dust and blow in such
> that the plastic fan whirls away.   Take a snapshot of the dust bunnies
> and send them to Dell.
> 
> I have a 5150 Inspiron.  In less than 1 year this thing started powering
> off (hard) on its own, no matter the OS installed (multi-boot).  I dug
> around the 'net and found similar issues, all relating to OVERHEATING. 
> Poorly designed was the culprit, but Dell has not yet admitted to this
> (but look at the Dell Linux forum or just Dell laptop forum and see
> Dell's techs replies) - think of the numbers sold and it makes sense.

Thank you very much for the pointers. I had just reached the 
same conclusion this afternoon, when pissed off by finding the 
CPU was at 85 C despite the fans being on at the max I did 
exactly what you suggest; although I didn't find any dust 
bunny, a thorough cleanup and blowing plus some toothpicking of 
hair and whatnot, I find myself with a computer that is running 
finely --again :)

Too bad, I'll need another excuse to buy myself the new hard disk ...

What about the sensors?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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-usb-devel] 2.6: USB disk unusable level of data corruption

[Giuseppe Bilotta]

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 slowly) when connected 
to the USB 1.1 ports built in my Dell Inspiron 8200, but trying 
to connect it via the Hamlet PCMCIA USB2 Card Adapter doesn't 
work (it seems it gets assigned minors 1,2,3,4,5,6,... and so 
on forever until I unplug it).

OTOH, I'm not sure if it's a PCMCIA adapter problem or USB2 
enclosure problem. Indeed, if I don't load the EHCI modules, 
and thus limit myself to the USB1.1 capabilities of the PCMCIA 
adapters, I get other errors (I'll have to write a cleaner bug 
report on this. And try the PCMCIA card with some other USB 
device. Wish I could use my softmodem under Linux :(). (Using 
kernel 2.6.10-3 from Debian.)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

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

Dell Inspiron sensors (was: Re: Huge unreliability - does Linux have something to do with it?)

[Giuseppe Bilotta]

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 heard it making grinding sounds and hitting heads against
> something.

I have a Dell Inspiron 8200, from March 2002. Since end of 
December 2004 I've started having system lockups which at first 
I couldn't identify, although they seemed to be overheating 
related. So I started monitoring the temperatures on all the 
components in my system (I can monitor CPU, GPU and HD temp; 
more on this later), and noticed that the lockups happen when 
the HD temp gets around 40 C. Indeed, they are 99% of the time 
preceded by a loud "click" coming from the HD wereabouts ... 
haven't lost any data yet but I've started backing up 
everything and getting ready to get a replacement HD.

Concerning sensors, though: under Windows I can use the 
i8kfangui applet to monitor all the sensors provided in the 
computer, but under Linux I only seem able to get the CPU 
temperature, using the i8k module, and no other sensor module 
seems to be loadable. Does anybody know how to access the other 
sensors on the Dell Inspiron? Or should I suggest Massimo to 
upgrade the i8k module to add the new sensors (i8kfangui has a 
GPL source code so it shouldn't be a problem) and possibly 
interface it all with the Linux sensors framework?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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][i386] HPET setup, duplicate HPET_T0_CMP needed for some platforms

[Giuseppe Bilotta]

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 write? Is it cost-effective to #if CONFIG_ the second 
write?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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][i386] HPET setup, duplicate HPET_T0_CMP needed for some platforms

[Giuseppe Bilotta]

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 write? Is it cost-effective to #if CONFIG_ the second 
write?

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

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

Dell Inspiron sensors (was: Re: Huge unreliability - does Linux have something to do with it?)

[Giuseppe Bilotta]

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 heard it making grinding sounds and hitting heads against
 something.

I have a Dell Inspiron 8200, from March 2002. Since end of 
December 2004 I've started having system lockups which at first 
I couldn't identify, although they seemed to be overheating 
related. So I started monitoring the temperatures on all the 
components in my system (I can monitor CPU, GPU and HD temp; 
more on this later), and noticed that the lockups happen when 
the HD temp gets around 40 C. Indeed, they are 99% of the time 
preceded by a loud click coming from the HD wereabouts ... 
haven't lost any data yet but I've started backing up 
everything and getting ready to get a replacement HD.

Concerning sensors, though: under Windows I can use the 
i8kfangui applet to monitor all the sensors provided in the 
computer, but under Linux I only seem able to get the CPU 
temperature, using the i8k module, and no other sensor module 
seems to be loadable. Does anybody know how to access the other 
sensors on the Dell Inspiron? Or should I suggest Massimo to 
upgrade the i8k module to add the new sensors (i8kfangui has a 
GPL source code so it shouldn't be a problem) and possibly 
interface it all with the Linux sensors framework?

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: Dell Inspiron sensors (was: Re: Huge unreliability - does Linux have something to do with it?)

[Giuseppe Bilotta]

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 A/C unit.  Take that air dust and blow in such
 that the plastic fan whirls away.   Take a snapshot of the dust bunnies
 and send them to Dell.
 
 I have a 5150 Inspiron.  In less than 1 year this thing started powering
 off (hard) on its own, no matter the OS installed (multi-boot).  I dug
 around the 'net and found similar issues, all relating to OVERHEATING. 
 Poorly designed was the culprit, but Dell has not yet admitted to this
 (but look at the Dell Linux forum or just Dell laptop forum and see
 Dell's techs replies) - think of the numbers sold and it makes sense.

Thank you very much for the pointers. I had just reached the 
same conclusion this afternoon, when pissed off by finding the 
CPU was at 85 C despite the fans being on at the max I did 
exactly what you suggest; although I didn't find any dust 
bunny, a thorough cleanup and blowing plus some toothpicking of 
hair and whatnot, I find myself with a computer that is running 
finely --again :)

Too bad, I'll need another excuse to buy myself the new hard disk ...

What about the sensors?

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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-usb-devel] 2.6: USB disk unusable level of data corruption

[Giuseppe Bilotta]

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 slowly) when connected 
to the USB 1.1 ports built in my Dell Inspiron 8200, but trying 
to connect it via the Hamlet PCMCIA USB2 Card Adapter doesn't 
work (it seems it gets assigned minors 1,2,3,4,5,6,... and so 
on forever until I unplug it).

OTOH, I'm not sure if it's a PCMCIA adapter problem or USB2 
enclosure problem. Indeed, if I don't load the EHCI modules, 
and thus limit myself to the USB1.1 capabilities of the PCMCIA 
adapters, I get other errors (I'll have to write a cleaner bug 
report on this. And try the PCMCIA card with some other USB 
device. Wish I could use my softmodem under Linux :(). (Using 
kernel 2.6.10-3 from Debian.)

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: Touchpad problems with 2.6.11-rc2

[Giuseppe Bilotta]

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 keyboad AND Touchpad 
responsiveness *under Windows* after plugging (and subsequently 
unplugging) an external PS/2 device (mouse OR keyboard) (I have 
never tried this under Linux though), so it might be a hardware 
issue.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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 3/4] Fix "pointer jumps to corner of screen" problem on ALPS Glidepoint touchpads.

[Giuseppe Bilotta]

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 will
> typically jump to one corner of the screen.

I remember reading specs of a touchpad (can't remember if it 
was ALPS or Synaptics) (driver) which could do "palm 
detection" (basically ignoring events when a large part of the 
hand accidentally touched/pressed the pad, FWICS).

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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 3/4] Fix pointer jumps to corner of screen problem on ALPS Glidepoint touchpads.

[Giuseppe Bilotta]

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 will
 typically jump to one corner of the screen.

I remember reading specs of a touchpad (can't remember if it 
was ALPS or Synaptics) (driver) which could do palm 
detection (basically ignoring events when a large part of the 
hand accidentally touched/pressed the pad, FWICS).

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

-
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: Touchpad problems with 2.6.11-rc2

[Giuseppe Bilotta]

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 keyboad AND Touchpad 
responsiveness *under Windows* after plugging (and subsequently 
unplugging) an external PS/2 device (mouse OR keyboard) (I have 
never tried this under Linux though), so it might be a hardware 
issue.

-- 
Giuseppe Oblomov Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
  (Roger Waters)

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