linuxconsole-dev

Re: bitkeeper source for ruby/linuxconsole?

[James S. <jsi...@in...>]

http://linuxconsole.bkbits.net/dev

Its not quite all of ruby but it is a good chunk.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

On Mon, 16 Sep 2002, Brad Hards wrote:

> On Mon, 16 Sep 2002 17:27, Andreas Schuldei wrote:
> > is there a bitkeeper source where i can pull from to get ruby
> > into my local bitkeeper repository?
> linux-input.bkbits.net ?
>
> Brad
>
>
> --
> http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> ------------ Output from gpg ------------
> gpg: Signature made Mon 16 Sep 2002 12:30:57 AM PDT using DSA key ID 8740B8E3
> gpg: Can't check signature: public key not found
>
>

Re: usb multimedia keyboards registered twice, as controlling kbds

[James S. <jsi...@in...>]

Sorry I have been away. I injured my back so I was out of business for
awhile.

> With Ruby's (and also Aivils' backstreet-ruby) console
> seperation, the virtual consoles are attached to the detected
> keyboards. Since (thanks to Brad for his explonation on lkml)
> some multimedia keyboards contain TWO usb keyboard interfaces (one
> for the normal keys and one for the add-on keys for multimedia
> keys), they both allocate one virtual console each. This messes
> up the keyboard/vc and later even the keyboard/Xserver
> assignment, since the REAL second keyboard is not associated
> with any vc and it't private void pointer stays uninitialized,
> causeing the kernel to oops on keypress.
>
> To fix this properly, two thinks have to be done:
> - Multimedia keyboard extensions (the second interface of a
>   multimedia keyboard) must not be assosiated with a vc at any
>   time. (or are there any keyboards containing realy two real
>   keyboards, which one would use to operate a vc?)
> - in the case of more keyboards then vcs, two possible valid
>   options arise: create a new vc (what would this imply? is this
>   sensible?) and associate the keyboard with it, or associate all
>   spare keyboards to a given (the first?) vc.
>
> I would love to hear from the master console seperator what he
> thinks of this (James Simmons?).

Personally I wouold ignore the extra 2nd interface on the keyboard. They
are the extended keys which the console system doesn't need. As for the X
server using these keys. I spoke to Getty some time ago about this. The
proper solution is that X uses the input interface instead of the console
system to get keyboard events.

Re: keyborad drivers under linux-ruby

[Vojtech P. <vo...@su...>]

On Tue, Sep 17, 2002 at 02:06:45PM +0300, Aivils Stoss wrote:
> Hi, Vojtech
> 
> How to is safer register new keyboard without necessary VT.
> Into kdb_connect() keyboard.c we have James comment:
>      /* If we have more keyboards than VTs we still register the handler.
>       * It is possible someone might add a graphics card thus needing the
>          * keyboard later */
> With this we have:
> handle->private == 0 ,if can't find VT.
> Can I solve this with single line in kbd_event()
> if(!handle->private) return;
> So this keyboard still registered, but no process any event.
> Or kbd_connect() return NULL pointer? Is it allowable?

If you return NULL, that means you're not interested in that device for
now and ever.

> Allow Your i386 arch oriented drivers hot remove/replug?

Yes. 

> Perform removing automatic unregistering?

Not always - PS/2 mice and AT keyboards are not unregistered until a new
device is plugged in.

> What should happen if keyboard replugged under linux-ruby?

You get a disconnect for the old one and a connect for the new one. It
might be the same keyboard, of course.

> How many USB keyboards should work independ?

Any number.

> Should work USBBP simultaneous with USB-HID keyboard?

BootProtocol shouldn't be used at all.

-- 
Vojtech Pavlik
SuSE Labs

usb multimedia keyboards registered twice, as controlling kbds

[Andreas S. <an...@sc...>]

With Ruby's (and also Aivils' backstreet-ruby) console
seperation, the virtual consoles are attached to the detected
keyboards. Since (thanks to Brad for his explonation on lkml)
some multimedia keyboards contain TWO usb keyboard interfaces (one
for the normal keys and one for the add-on keys for multimedia
keys), they both allocate one virtual console each. This messes
up the keyboard/vc and later even the keyboard/Xserver
assignment, since the REAL second keyboard is not associated
with any vc and it't private void pointer stays uninitialized,
causeing the kernel to oops on keypress. 

To fix this properly, two thinks have to be done: 
- Multimedia keyboard extensions (the second interface of a
  multimedia keyboard) must not be assosiated with a vc at any
  time. (or are there any keyboards containing realy two real
  keyboards, which one would use to operate a vc?)
- in the case of more keyboards then vcs, two possible valid
  options arise: create a new vc (what would this imply? is this
  sensible?) and associate the keyboard with it, or associate all
  spare keyboards to a given (the first?) vc.

I would love to hear from the master console seperator what he
thinks of this (James Simmons?).

keyborad drivers under linux-ruby

[Aivils S. <Aiv...@un...>]

Hi, Vojtech

How to is safer register new keyboard without necessary VT.
Into kdb_connect() keyboard.c we have James comment:
     /* If we have more keyboards than VTs we still register the handler.
      * It is possible someone might add a graphics card thus needing the
         * keyboard later */
With this we have:
handle->private == 0 ,if can't find VT.
Can I solve this with single line in kbd_event()
if(!handle->private) return;
So this keyboard still registered, but no process any event.
Or kbd_connect() return NULL pointer? Is it allowable?

Allow Your i386 arch oriented drivers hot remove/replug?
Perform removing automatic unregistering?
What should happen if keyboard replugged under linux-ruby?
How many USB keyboards should work independ?
Should work USBBP simultaneous with USB-HID keyboard?

Best regards,
Aivils Stoss

Re: What I should do for official ruby backport?

[Aivils S. <Aiv...@un...>]

Johan Deneux wrote:

>I indeed backport the force-feedback related drivers to 2.4. The reason
>for this are:
>1. I use 2.4 (2.5+ide used to be a bad combination)
>2. Users are mainly gamers. Gamers use NVidia cards. NVidida drivers are
>for 2.4. -> users probably want 2.4.

Me to is gamer. I use 3 Nvidia cards in my local system. This one
allow me emulate net gaming in my home. Triple Quake3Arena and triple
UnrealTournament works for me fine. Game may be sametimes choppy, but my
users never complain.
IMHO any bugget restricted gamer dream.

>> I will heard veteran hints. I hope You don't recommend stop it.
>
>I am not sure what your patch exactly does.

backstreet-ruby split /dev/tty's into separate range, same in ruby CVS.
8 /dev/tty's per keyboard/console pair.User can choose keyboard for
X server with X server paramether vtXX. And run several X
simultaneos with independ keyboard,mouse,monitor.

>But if it's a full ruby
>back-port, I am not sure it is really worth the pain (IMHO).

No full. Framebuffer devices removed. No real text based
multiheaded console. Only multiple X supported. X server
do not need console, but only tty drivers. I emulate additional
console for 2nd, 3rd X with dummy console.

>As far as I
>know, ruby is not going to make it into 2.4. It must be quite hard and
>time-comsuming to track the console+input thing, isn't it ?

IMHO vt-handling is complete in ruby CVS. Seems James mean similar,
because no vt.c real changes since DEC-2001.

>Are there many users out there *needing* ruby in 2.4 ? If it's only for
>testing purposes, I guess they can use 2.5.

Current 3-6 patchers, any has 2-3 X terminal (end-users unknow count).
My system use 6 peoples(gamers).
I will popularize this , but current version is buggy.
Rather I flunk.

Thanks
Aivils Stoss

Re: What I should do for official ruby backport?

[Andreas S. <an...@sc...>]

* Aivils Stoss (Aiv...@un...) [020916 11:35]:
> Motivation:
> 1. James Simons will not keep clear code in ruby CVS.

> 2. Nobody use Linux in my home , if can't start triple Freeciv,
> Quake3Arena, and so on.
I do not understand what you wanted to express with this. 

>      Sametimes I can find small bugs in one-two month time period. It's
> good enough
> for me, but my be abnormality in public area.

I have tried to get this to work for a few days now, and it seems
that there is lots of clean up to be done. 

what I notice is that the interoperation with the rest of the
kernel is suboptimal. eg: if one activates magic sysrequest keys
the serial subsytem brakes. 
Other general problems are in the area of corner cases: what
happens if you have more keyboards then vts? So the robustness in
general is not very high.

I would encourage you to work together with others (like me :-)
to improve both your documentation and patch quality. I volunteer
to go over your webpages and try to straighten out some issues in
grammar. I could also mirror the site on a box with better
connectivity or on a debian server.

I have run into several people who would be very interested in
your setup to work reliably, and once this is packaged and
it went into debian, i expect that the number of users to
mulitply.

> I will heard veteran hints. I hope You don't recommend stop it.

i certainly hope you keep up your work. i do not believe this
goes into mainline 2.4 at anytime, but i think this has the
potental to become an independent kernel patch, which provides
something many want in a stable kernel (like alsa for sound?).

Re: What I should do for official ruby backport?

[Johann D. <joh...@it...>]

Aivils Stoss wrote:
> Hi, folks
> 
> Motivation:
> 1. James Simons will not keep clear code in ruby CVS.
> 2. Nobody use Linux in my home , if can't start triple Freeciv,
> Quake3Arena, and so on.
> 
>      Sametimes I can find small bugs in one-two month time period. It's
> good enough
> for me, but my be abnormality in public area.
> 
>      Johan alwways made backport. So next time I wait for it, then release
> my
> package.
> 

I indeed backport the force-feedback related drivers to 2.4. The reason 
for this are:
1. I use 2.4 (2.5+ide used to be a bad combination)
2. Users are mainly gamers. Gamers use NVidia cards. NVidida drivers are 
for 2.4. -> users probably want 2.4.

Now, this is not a complete backport of ruby at all. It only included 
small pieces of the input layer, plus the iforce and hid drivers.

I was planning to wait until Brad's patches would be included into 
2.4.20-preX to send iforce to Alan Cox (and later hid).

> I will heard veteran hints. I hope You don't recommend stop it.

I am not sure what your patch exactly does. But if it's a full ruby 
back-port, I am not sure it is really worth the pain (IMHO). As far as I 
know, ruby is not going to make it into 2.4. It must be quite hard and 
time-comsuming to track the console+input thing, isn't it ?
Are there many users out there *needing* ruby in 2.4 ? If it's only for 
testing purposes, I guess they can use 2.5.

-- 
Johann Deneux

What I should do for official ruby backport?

[Aivils S. <Aiv...@un...>]

Hi, folks

Motivation:
1. James Simons will not keep clear code in ruby CVS.
2. Nobody use Linux in my home , if can't start triple Freeciv,
Quake3Arena, and so on.

     Sametimes I can find small bugs in one-two month time period. It's
good enough
for me, but my be abnormality in public area.

     Johan alwways made backport. So next time I wait for it, then release
my
package.

I will heard veteran hints. I hope You don't recommend stop it.

Thanks
Aivils Stoss

Re: bitkeeper source for ruby/linuxconsole?

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 16 Sep 2002 17:27, Andreas Schuldei wrote:
> is there a bitkeeper source where i can pull from to get ruby
> into my local bitkeeper repository?
linux-input.bkbits.net ?

Brad


- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9hYixW6pHgIdAuOMRAjaoAJ47HAlI41GH/4Nu9tbPeZOyywYPtgCguHBF
2c1txH+aIKo1I/6FYipWoi0=
=bf9w
-----END PGP SIGNATURE-----

bitkeeper source for ruby/linuxconsole?

[Andreas S. <an...@sc...>]

is there a bitkeeper source where i can pull from to get ruby
into my local bitkeeper repository?

new oops at keypress in puts_queue (keyboard.c)

[Andreas S. <an...@sc...>]

this oops occures when i press a key at any given keyboard, but
not allways. not sure what triggers it. it is really common.

This is again with Aivils Stoss's patches against 2.4.19.

Aivils: you need to add vc_tty to vc_struct in
include/linux/console_struct.h. I do not know how this even
compiled. is should not have worked at all like this. 

this oopes in the inline function tty_insert_flip_char(), in
put_queue(), in the file keyboard.c. I think that happens,
because the tty structure is only partly set up, and the tty-flip
pointers is not good.

I do not have a clue about what is going on on that end. Ideas?



ksymoops 2.4.6 on i686 2.4.19-backstreet-ruby.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.19-backstreet-ruby/ (default)
     -m /boot/System.map-2.4.19-backstreet-ruby (specified)

Warning (compare_maps): ksyms_base symbol ip_ct_attach_R__ver_ip_ct_attach not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol ip_route_me_harder_R__ver_ip_route_me_harder not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol neigh_app_ns_R__ver_neigh_app_ns not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_getsockopt_R__ver_nf_getsockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_hook_slow_R__ver_nf_hook_slow not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_hooks_R__ver_nf_hooks not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_register_hook_R__ver_nf_register_hook not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_register_queue_handler_R__ver_nf_register_queue_handler not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_register_sockopt_R__ver_nf_register_sockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_reinject_R__ver_nf_reinject not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_setsockopt_R__ver_nf_setsockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_unregister_hook_R__ver_nf_unregister_hook not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_unregister_queue_handler_R__ver_nf_unregister_queue_handler not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_unregister_sockopt_R__ver_nf_unregister_sockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol sk_chk_filter_R__ver_sk_chk_filter not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol sk_run_filter_R__ver_sk_run_filter not found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address ffffffff
c017634f
*pde = 00001063
Oops: 0002
CPU:    0
EIP:    0010:[<c017634f>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210256
eax: ffffffff   ebx: 0000001b   ecx: c0236143   edx: ee111000
esi: ee11113c   edi: 0000f106   ebp: 00000080   esp: c026bd90
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c026b000)
Stack: 00000001 eed20200 c0176b4c eed20200 c0236143 c01773ac eed20200 00000006
       00000000 00000001 ef172fdc ef172fdc 00000041 0000000a c01773e1 c02acec0
       00000041 00000001 c01ae34e ef1ae5a0 00000001 00000041 00000001 00000001
Call Trace:    [<c0176b4c>] [<c01773ac>] [<c01773e1>] [<c01ae34e>] [<f08be4ae>]
  [<f08be4ae>] [<f08bbf66>] [<f08bc221>] [<f08bc2d7>] [<f08bc312>] [<f08cc204>]
  [<f08cc579>] [<f08cc7c2>] [<c0110001>] [<c010985d>] [<c01099c6>] [<c0106bd0>]
  [<c0106bd0>] [<c0106bd0>] [<c0106bd0>] [<c0106bf3>] [<c0106c59>] [<c0105000>]
  [<c0105027>]
Code: c6 00 00 8b 82 64 01 00 00 ff 82 68 01 00 00 88 18 ff 82 64


>>EIP; c017634f <puts_queue+3b/88>   <=====

>>ecx; c0236143 <func_buf+1f/9c>
>>edx; ee111000 <_end+2de587c8/305f3828>
>>esi; ee11113c <_end+2de58904/305f3828>
>>esp; c026bd90 <init_task_union+1d90/2000>

Trace; c0176b4c <k_fn+24/28>
Trace; c01773ac <kbd_keycode+220/238>
Trace; c01773e1 <kbd_event+1d/3c>
Trace; c01ae34e <input_event+2ee/308>
Trace; f08be4ae <[hid]hidinput_hid_event+16a/190>
Trace; f08be4ae <[hid]hidinput_hid_event+16a/190>
Trace; f08bbf66 <[hid]hid_process_event+22/30>
Trace; f08bc221 <[hid]hid_input_field+2ad/2ec>
Trace; f08bc2d7 <[hid]hid_input_report+77/a0>
Trace; f08bc312 <[hid]hid_irq_in+12/18>
Trace; f08cc204 <[usb-uhci]process_interrupt+a8/228>
Trace; f08cc579 <[usb-uhci]process_urb+7d/200>
Trace; f08cc7c2 <[usb-uhci]uhci_interrupt+c6/12c>
Trace; c0110001 <__setup_APIC_LVTT+5/28>
Trace; c010985d <handle_IRQ_event+31/5c>
Trace; c01099c6 <do_IRQ+6a/a8>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bf3 <default_idle+23/28>
Trace; c0106c59 <cpu_idle+41/54>
Trace; c0105000 <_stext+0/0>
Trace; c0105027 <rest_init+27/28>

Code;  c017634f <puts_queue+3b/88>
00000000 <_EIP>:
Code;  c017634f <puts_queue+3b/88>   <=====
   0:   c6 00 00                  movb   $0x0,(%eax)   <=====
Code;  c0176352 <puts_queue+3e/88>
   3:   8b 82 64 01 00 00         mov    0x164(%edx),%eax
Code;  c0176358 <puts_queue+44/88>
   9:   ff 82 68 01 00 00         incl   0x168(%edx)
Code;  c017635e <puts_queue+4a/88>
   f:   88 18                     mov    %bl,(%eax)
Code;  c0176360 <puts_queue+4c/88>
  11:   ff 82 64 00 00 00         incl   0x64(%edx)

 <0>Kernel panic: Aiee, killing interrupt handler!

16 warnings issued.  Results may not be reliable.

Solution: Keyboard initialisation (was: Re: problems with the serial console)

[Andreas S. <an...@sc...>]

* Brad Hards (bh...@bi...) [020914 03:06]:
> On Sat, 14 Sep 2002 10:36, Andreas Schuldei wrote:
> > * Andreas Schuldei (an...@sc...) [020914 01:26]:
> > > * Andreas Schuldei (an...@sc...) [020913 13:13]:
> > > Code;  c0178d8b <kbd_keycode+f/21c>   <=====
> > >    0:   8b 37                     mov    (%edi),%esi   <=====
> > > Code;  c0178d8d <kbd_keycode+11/21c>
> > >    2:   83 fd 02                  cmp    $0x2,%ebp
> > > Code;  c0178d90 <kbd_keycode+14/21c>
> >
> > this oops takes place in the function kbd_keycode, because vt is
> > a nullpointer. i added a check for vt==0 and print out some
> > warning and returnd, and now it crashes no longer.
> Does this happen with "vanilla" versions of 2.4.19 (or 2.4.20-pre7) or 2.5.34?

it can not, since all those can not have multiple independent vt.


However i did dig some more and this problem occures if the
void pointer private is not initialized in kbd_connect. Then it
points to NULL, and booom. The pointer gets dereferenced in
kbd_keycode, where it is supposed to point to the vt_struct of
the controlling terminal. 

This (void pointer private not beeing initialized) 
happens, it there are more keyboards then VTs. The common case in
the bottom of the function does not catch this, it does not touch
private. 

Would it make sense to let private point to some fix point, in
that case? as a (really bad) solution i pointed it at admin_vt,
which results in funny effekts, when one types on the keyboard
and there is no controlling vt. then the characters showed up in
my root ssh session, and i could even close that session. (c:

Anyone who is better at this: what would be a sensible vt to
point to?

Re: [BK PATCH] console updates.

[Russell K. <rm...@ar...>]

On Thu, Sep 12, 2002 at 04:13:38PM -0700, James Simmons wrote:
>    Here is the latest console code that has been sitting around in Dave
> Jone's tree for some time. This patch removes the many global variables
> the console system uses. Since Vojtech input keyboards went this diff has
> shrunk. If you could apply it I would be happy.
> 
> bk://linuxconsole.bkbits.net/dev

gnu patch?  diffstat output?

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: understanding the input layer

[Svetoslav S. <ga...@st...>]

On Sat, 2002-09-14 at 01:55, Brad Hards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 13 Sep 2002 21:38, Andreas Schuldei wrote:
> > is there a way to see which devices are registered nodes in the
> > input layer?
> Trivial if you have 2.5 (/proc/bus/input/devices). I don't think this is 
> present in 2.4 yet.
> 
with the patches from Aivilis you have 
take a look at http://varna.demon.co.uk/~svetlio/proc
> > i have mice connected to my box, they are shown in
> > /proc/bus/usb/devices, but they do not seem to be connected to
> > the device special files in /dev/input and /dev/usb. none of
> > these devices works.
> http://www.linux-usb.org/linux.conf.au.02/talk/html/slide_11.html might help 
> explain things.
> 
> > the magic happens in input.c, i guess, but how can i see IF it
> > happens in the first place? Which device drivers are necessary to
> > use the usb devices? the USB maintainer tells me that hid is
> > capable to do it all, but he says that his responsibility ends
> > there and the input layer is non of his buissness. (c:
> BTW: The same guy maintains the USB HID code and the input core. 
> 
> > what device drivers do i need on the input layer, and do i need
> > one for kbd and one for mice?
> The Linux USB guide (linked off http://www.linux-usb.org) has detailed 
> instructions on getting this to work.
> 
> > I work with the backport by  Aivils Stoss to 2.4.19
> You shouldn't need this for such a basic application.
> 
> Brad
> - -- 
> http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE9gnsDW6pHgIdAuOMRApdIAJ41+V1PMjyVIlR1/VIg7zFB5AnA7QCfTK5l
> t1ExoIx9As/PpdbOhhGpK8k=
> =fc5o
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

Re: problems with the serial console

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 14 Sep 2002 10:36, Andreas Schuldei wrote:
> * Andreas Schuldei (an...@sc...) [020914 01:26]:
> > * Andreas Schuldei (an...@sc...) [020913 13:13]:
> > Code;  c0178d8b <kbd_keycode+f/21c>   <=====
> >    0:   8b 37                     mov    (%edi),%esi   <=====
> > Code;  c0178d8d <kbd_keycode+11/21c>
> >    2:   83 fd 02                  cmp    $0x2,%ebp
> > Code;  c0178d90 <kbd_keycode+14/21c>
>
> this oops takes place in the function kbd_keycode, because vt is
> a nullpointer. i added a check for vt==0 and print out some
> warning and returnd, and now it crashes no longer.
Does this happen with "vanilla" versions of 2.4.19 (or 2.4.20-pre7) or 2.5.34?

Brad



- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9goodW6pHgIdAuOMRAk/7AJ4j9I1TexjesblyI5RLalILAHYuzQCcDmz9
Qsa+K3ngAWbanQYzMbgAhl4=
=n9ZS
-----END PGP SIGNATURE-----

Re: problems with the serial console

[Andreas S. <an...@sc...>]

* Andreas Schuldei (an...@sc...) [020914 01:26]:
> * Andreas Schuldei (an...@sc...) [020913 13:13]:
> Code;  c0178d8b <kbd_keycode+f/21c>   <=====
>    0:   8b 37                     mov    (%edi),%esi   <=====
> Code;  c0178d8d <kbd_keycode+11/21c>
>    2:   83 fd 02                  cmp    $0x2,%ebp
> Code;  c0178d90 <kbd_keycode+14/21c>

this oops takes place in the function kbd_keycode, because vt is
a nullpointer. i added a check for vt==0 and print out some
warning and returnd, and now it crashes no longer.

so why would the vt pointer be NULL?

Re: understanding the input layer

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 13 Sep 2002 21:38, Andreas Schuldei wrote:
> is there a way to see which devices are registered nodes in the
> input layer?
Trivial if you have 2.5 (/proc/bus/input/devices). I don't think this is 
present in 2.4 yet.

> i have mice connected to my box, they are shown in
> /proc/bus/usb/devices, but they do not seem to be connected to
> the device special files in /dev/input and /dev/usb. none of
> these devices works.
http://www.linux-usb.org/linux.conf.au.02/talk/html/slide_11.html might help 
explain things.

> the magic happens in input.c, i guess, but how can i see IF it
> happens in the first place? Which device drivers are necessary to
> use the usb devices? the USB maintainer tells me that hid is
> capable to do it all, but he says that his responsibility ends
> there and the input layer is non of his buissness. (c:
BTW: The same guy maintains the USB HID code and the input core. 

> what device drivers do i need on the input layer, and do i need
> one for kbd and one for mice?
The Linux USB guide (linked off http://www.linux-usb.org) has detailed 
instructions on getting this to work.

> I work with the backport by  Aivils Stoss to 2.4.19
You shouldn't need this for such a basic application.

Brad
- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9gnsDW6pHgIdAuOMRApdIAJ41+V1PMjyVIlR1/VIg7zFB5AnA7QCfTK5l
t1ExoIx9As/PpdbOhhGpK8k=
=fc5o
-----END PGP SIGNATURE-----

Re: problems with the serial console

[Andreas S. <an...@sc...>]

* Andreas Schuldei (an...@sc...) [020913 13:13]:
> i tried to get the kernel messages and the oops i get to the
> serial console, and i failed.

that was because i has enable the magic sys request /kernel
hacking feature, and that broke in serial.c. Note that Aivils did
not backport ruby serial layer rewrite, so this is understandable
not working as it should. however, when the kernel hacking is
disabled, the serial consol works again and i was able to catch
the oops and decode it.

ksymoops -m /boot/System.map-2.4.19-backstreet-ruby /tmp/oops
ksymoops 2.4.6 on i686 2.4.19-backstreet-ruby.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.19-backstreet-ruby/ (default)
     -m /boot/System.map-2.4.19-backstreet-ruby (specified)

Warning (compare_maps): ksyms_base symbol ip_ct_attach_R__ver_ip_ct_attach not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol ip_route_me_harder_R__ver_ip_route_me_harder not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol neigh_app_ns_R__ver_neigh_app_ns not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_getsockopt_R__ver_nf_getsockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_hook_slow_R__ver_nf_hook_slow not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_hooks_R__ver_nf_hooks not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_register_hook_R__ver_nf_register_hook not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_register_queue_handler_R__ver_nf_register_queue_handler not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_register_sockopt_R__ver_nf_register_sockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_reinject_R__ver_nf_reinject not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_setsockopt_R__ver_nf_setsockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_unregister_hook_R__ver_nf_unregister_hook not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_unregister_queue_handler_R__ver_nf_unregister_queue_handler not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol nf_unregister_sockopt_R__ver_nf_unregister_sockopt not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol sk_chk_filter_R__ver_sk_chk_filter not found in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol sk_run_filter_R__ver_sk_run_filter not found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 00000000
c0178d8b
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0178d8b>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 0000002c   ebx: 00000001   ecx: ee98e440   edx: 00000000
esi: ee986fdc   edi: 00000000   ebp: 00000001   esp: c026fdb4
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c026f000)
Stack: 00000001 ee986fdc ee986fdc 0000002c 0000000a c0178fb5 00000000 0000002c
       00000001 c01b01be ee98e440 00000001 0000002c 00000001 00000001 ee98421c
       ee986fdc ee984000 c186e1a0 c186e1a0 ee98e440 f08be4ae ee986fdc 00000001
Call Trace:    [<c0178fb5>] [<c01b01be>] [<f08be4ae>] [<f08bbf66>] [<f08bc221>]
  [<f08bc2d7>] [<f08bc312>] [<f08cc204>] [<f08cc579>] [<f08cc7c2>] [<c0110001>]
  [<c010985d>] [<c01099c6>] [<c0106bd0>] [<c0106bd0>] [<c0106bd0>] [<c0106bd0>]
  [<c0106bf3>] [<c0106c59>] [<c0105000>] [<c0105027>]
Code: 8b 37 83 fd 02 74 16 8a 44 24 1c 00 c0 89 ea 30 d0 0f b6 c0


>>EIP; c0178d8b <kbd_keycode+f/21c>   <=====

>>ecx; ee98e440 <_end+2e6d1b28/305ef748>
>>esi; ee986fdc <_end+2e6ca6c4/305ef748>
>>esp; c026fdb4 <init_task_union+1db4/2000>

Trace; c0178fb5 <kbd_event+1d/3c>
Trace; c01b01be <input_event+2ee/308>
Trace; f08be4ae <[hid]hidinput_hid_event+16a/190>
Trace; f08bbf66 <[hid]hid_process_event+22/30>
Trace; f08bc221 <[hid]hid_input_field+2ad/2ec>
Trace; f08bc2d7 <[hid]hid_input_report+77/a0>
Trace; f08bc312 <[hid]hid_irq_in+12/18>
Trace; f08cc204 <[usb-uhci]process_interrupt+a8/228>
Trace; f08cc579 <[usb-uhci]process_urb+7d/200>
Trace; f08cc7c2 <[usb-uhci]uhci_interrupt+c6/12c>
Trace; c0110001 <apm_bios_call_simple+29/6c>
Trace; c010985d <handle_IRQ_event+31/5c>
Trace; c01099c6 <do_IRQ+6a/a8>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bd0 <default_idle+0/28>
Trace; c0106bf3 <default_idle+23/28>
Trace; c0106c59 <cpu_idle+41/54>
Trace; c0105000 <_stext+0/0>
Trace; c0105027 <rest_init+27/28>

Code;  c0178d8b <kbd_keycode+f/21c>
00000000 <_EIP>:
Code;  c0178d8b <kbd_keycode+f/21c>   <=====
   0:   8b 37                     mov    (%edi),%esi   <=====
Code;  c0178d8d <kbd_keycode+11/21c>
   2:   83 fd 02                  cmp    $0x2,%ebp
Code;  c0178d90 <kbd_keycode+14/21c>
   5:   74 16                     je     1d <_EIP+0x1d> c0178da8 <kbd_keycode+2c/21c>
Code;  c0178d92 <kbd_keycode+16/21c>
   7:   8a 44 24 1c               mov    0x1c(%esp,1),%al
Code;  c0178d96 <kbd_keycode+1a/21c>
   b:   00 c0                     add    %al,%al
Code;  c0178d98 <kbd_keycode+1c/21c>
   d:   89 ea                     mov    %ebp,%edx
Code;  c0178d9a <kbd_keycode+1e/21c>
   f:   30 d0                     xor    %dl,%al
Code;  c0178d9c <kbd_keycode+20/21c>
  11:   0f b6 c0                  movzbl %al,%eax

 <0>Kernel panic: Aiee, killing interrupt handler!

16 warnings issued.  Results may not be reliable.

Any comments?

Re: several usb keyboards?

[Svetoslav S. <ga...@st...>]

On Fri, 2002-09-13 at 13:16, Andreas Schuldei wrote:
> i try to connect several usb keyboards (and no other) to my box.
> When i press a key on the second keyboard, i get an oops. 

i was having the same problem with the patch from Aivilis, 
the one for 2.4.18, the problem is generally with the second keyboard.
i had it with one ps2 and one usb, then i tried 2 ps2 and i got the same
oopses, no progress and sadly no time to look deeper in the problem.
the same oopses probably you can find on 
http://varna.demon.co.uk/~svetlio


Best Regards,

svetljo
> (i am in the process to catch that oops with a serial console,
> hope to have that working at some point...). who else has this
> problem and how is the solution coming along?
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev

understanding the input layer

[Andreas S. <an...@sc...>]

is there a way to see which devices are registered nodes in the
input layer? 

i have mice connected to my box, they are shown in
/proc/bus/usb/devices, but they do not seem to be connected to
the device special files in /dev/input and /dev/usb. none of
these devices works. 

the magic happens in input.c, i guess, but how can i see IF it
happens in the first place? Which device drivers are necessary to
use the usb devices? the USB maintainer tells me that hid is
capable to do it all, but he says that his responsibility ends
there and the input layer is non of his buissness. (c:

what device drivers do i need on the input layer, and do i need
one for kbd and one for mice?

I work with the backport by  Aivils Stoss to 2.4.19

several usb keyboards?

[Andreas S. <an...@sc...>]

i try to connect several usb keyboards (and no other) to my box.
When i press a key on the second keyboard, i get an oops. 

(i am in the process to catch that oops with a serial console,
hope to have that working at some point...). who else has this
problem and how is the solution coming along?

problems with the serial console

[Andreas S. <an...@sc...>]

i tried to get the kernel messages and the oops i get to the
serial console, and i failed.

two minicoms can talk to each other over my nullmodem cable, but
no messages come through. 

i had fixed a obvious compilation bug (too man arguments to
handle_sysrq in serial.c), but there seems to be more wrong.

i use the patches by  Aivils Stoss and work with a backport on
2.4.19. My ultimat aim is to get a mult-console box for two (or
more) people.

[BK PATCH] console updates.

[James S. <jsi...@in...>]

Hi!

   Here is the latest console code that has been sitting around in Dave
Jone's tree for some time. This patch removes the many global variables
the console system uses. Since Vojtech input keyboards went this diff has
shrunk. If you could apply it I would be happy.

bk://linuxconsole.bkbits.net/dev

Re: /s/Drivers/Handlers in input proc interface

[Vojtech P. <vo...@su...>]

On Thu, Sep 12, 2002 at 05:26:51PM +1000, Brad Hards wrote:

> The proc interface for the input subsystem current provides entries like this 
> in /proc/bus/input/devices:
> 
> I: Bus=0003 Vendor=046d Product=c002 Version=0120
> N: Name="Logitech USB-PS/2 Mouse M-BA47"
> P: Phys=usb-00:01.2-2.2/input0
> D: Drivers=mouse0 event2
> B: EV=7
> B: KEY=f0000 0 0 0 0 0 0 0 0
> B: REL=103
> 
> I think that the D: line is wrong. Those aren't really drivers, they are the 
> handlers. Driver is a concept associated with the input_register_device() 
> call (so it'd be more like hid or atkbd or whatever).
> I guess knowing the drivers might be useful eventually, although you can 
> normally deduce it from a combination of the P: and N: lines.
> 
> The attached patch does the trivial relabelling. Please apply to your tree and 
> send to Linus if OK.
> 
> BTW: I thought about doing a Handler/Handlers test based on the number of 
> handlers, but that might make parsing the /proc entries harder. So not this 
> time.

Patch applied. I changed it to "H: Handlers" instead of "D: Handlers",
if we're changing it (and breaking potential software that parses it,
which is none at the moment), we should do it completely.

There is one more problem with "B:", and that is the numbers there are
longs, thus breaking 32-bit emulations on top of 64-bit kernels. This
needs to be fixed. I haven't found a nice way yet, though.

-- 
Vojtech Pavlik
SuSE Labs