Re: GigaByte GA-MA69VM USB+mouse problem

Michal Varga wrote:
> On Sun, 2007-10-14 at 13:53 -0400, 韓家標 Bill Hacker wrote:
> 
*snipped*

>> Option USB mouse support OFF in BIOS, mouse responds as it should.
>>
> I already said that I have "USB mouse support = OFF" in BIOS. It is
> obviously one of the first things one tries to toggle if something like
> mouse doesn't work.
>

It was anything *but* 'obvious' here, given thta there was a USb mouse pluggged in.

Defing the BIOS came after two days of tests, a new MB, and a new PSU - which 
grief and costs I've been trying to spare you.

> 
*snip*

>>>
>> ...but as you've just enumerated - the MB, its 'bridge' and USB chipset has 
>> changed, and the *BIOS* has changed....
>>
> really like to test this motherboard with a different mouse model, but I
> don't have any other nearby, just these (and a bunch of PS/2 that are of
> no use here)

But they are. See below.

> tomorrow, let's assume that the mouse is not a problem here, as it is

No such animal as 'assume' if you are having an unresolved problem.

*snip*

>>
>> Windows is an entirely different environment, and not 'of interest'.
>>
>> DragonFly was close enough to be of interest.
>>
> How it is that a different operating system running on this motherboard
> that doesn't show any symptoms with the mouse is "not of interest"? If I
> said "Linux" or "Atari TOS", would that be ok, but because it works with
> "Winbl0w$$$", such information is automatically of no interest? Well,
> what a twist.
>

It isn't about slamming Windows.  Or praising it.

'Of no interest', because Windows has a very, very, different architecture than 
any of the '*n*x'es. As does Atari.

Other *n*x'en have far more in common with FreeBSD than Windows does.

Some of the other *BSD's use identical or very similar code during boot and for 
drivers, and at least DragonFly has a similar philosophy w/r rc and friends, 
hence the sequencing of the loading of drivers.

That's why I tested that, and ignored Windows. (And Minix, Qnx, Syllable, 
Minuet, Warp Server Advanced, ForthOS, Plan9, and bunch of others I have handy).

> 

*snip*

> Ok, what should I do to convince you that I DO have
> USB/kbd/mouse/support disabled in BIOS?

It isn't about 'convinced'. I'm not the one who still has the problem.

It is about accurately reported.

That's the first time you've actually specified that the USB kbd was also DISABLED.

OTOH, one of the dmesg.boot you posted seemed to show an errmsg indicating that 
perhaps the *overall* USB subsystem was DISABLED.

What's up with that?

*snip* (things you cannot afford, even at my rates of 15 years ago....)

> 
> Really, I disabled it the next reboot that I noticed my mouse isn't
> working. I tried all combinations, tried to disable USB 2.0, legacy
> support, flashed BIOS to the latest version, it has no effect on the
> mouse problem. 

> What I need are some ideas or pointers to what should I
> try *next*,

Both of our Gigabyte MB also have PS2 mouse ports.

What happens when you try with NO USB mouse and one of those 'useless' PS2 mice?

How about with BOTH (I NOW get both drivers loading, FWIW...)

> and you are not very helpful trying to convince me that I
> don't know how to operate BIOS setup.

Your posts did NOT indicate the sort of exhaustive tests you should, at this 
stage anyway, be making, and reporting, before expecting a fix in code.

That wuold be different if many others were reporting in with the same problem, 
but that has yet to happen.

 > If disabling USB mouse support in
> BIOS helped in your case, I'm happy for you, but I have a different
> motherboard and this approach clearly doesn't work. So if you, by a
> chance, have any other ideas, I'll be more than happy to hear them.
> 
> m.
>

I'll take you at your word.  Fill in the blanks - either from your notes or from 
new tests if you have overlooked these:

What happesns when you use the PS-2 mouse instead of a USB mouse?

_______________


What happens when you try some other USB mouse - borrowed temporarily if need be 
- instead of the A4tech?


_____________


Besides what you put into loader.conf, what happens when you *manually* kldload 
'ed, kld unload 'ed ums.ko?


______________


What happens when you comment out the default mouse code in /etc/rc?


______________


What happens when you manually try different option combinations for invoking 
moused, e.g. moused -t auto -p /dev/ums0 and.. what others?


______________


What happens when you try 'startx' or start<other wm>, and what settings were 
used in /etc/X11/xorg.conf?


______________


What does /var/log/Xorg.0.log say afterwards as to pointing device?



______________


Were there ever TWO moused PID's showing in 'top'? Or one eating 100% CPU of one 
core? Or a cursor jumping all about?



_________________


FreeBSD will have a *dynamic* set of drivers showing in /dev for the USB 
'chain', i.e. usb, usb(n).  Driven by what it detect[ed| s].

ums(n) may not be among those showing right after boot, may show up after any of 
the above steps even if the mouse did not properly respond.

So... which of these are, and are NOT showing *as you alter BIOS settings* and 
reboot?


_________________


Same again as you invoke kld or moused? What comes and goes?
ls /dev/u*,   kldstat -v,  tail -f  -n 500 /var/log/messages




_________________


As to dmesg.boot, it is a footprint, not the step that led to it, so you need to 
keep track of what you did before each reoot THEN have a look at it with less or 
tail.

When older versions of FreeBSD as well as DragonFly have the same issue on the 
same hardware, I just do not think it is a FreeBSD 7-X code issue.

That does not mean there may not be a need for more clever code at some point.
These are, after all, major-vendor volume MB, Asus in particular.

But there is not yet enough evidence to clearly ID what needs to be done. If 
anything.

Bill