2.4.19-ac4 build problem

2.4.19-ac4 build problem

[Peter]

Is there a fix for this compilation problem? I've tried gcc 2.95.3, 3.0, 
and 3.1 and get the same:

drivers/usb/usbdrv.o: In function `hidinput_hid_event':
drivers/usb/usbdrv.o(.text+0x127f1): undefined reference to `input_event'
drivers/usb/usbdrv.o(.text+0x12889): undefined reference to `input_event'
drivers/usb/usbdrv.o(.text+0x128e1): undefined reference to `input_event'
drivers/usb/usbdrv.o(.text+0x12967): undefined reference to `input_event'
drivers/usb/usbdrv.o: In function `hidinput_connect':
drivers/usb/usbdrv.o(.text+0x12bc0): undefined reference to `input_register_device'
drivers/usb/usbdrv.o: In function `hidinput_hid_event':
drivers/usb/usbdrv.o(.text+0x12848): undefined reference to `input_event'
drivers/usb/usbdrv.o: In function `hidinput_disconnect':
drivers/usb/usbdrv.o(.text+0x12bdd): undefined reference to `input_unregister_device'
make: *** [vmlinux] Error 1

I'm trying to get USB keyboard and mouse support, so I'd like to keep the 
hidinput options.

Cheers,
Peter


#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_EVDEV is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_LONG_TIMEOUT is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI=y
# CONFIG_USB_UHCI_ALT is not set
# CONFIG_USB_OHCI is not set


#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH is not set
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
CONFIG_USB_STORAGE_ISD200=y
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_WACOM is not set

#
# USB Imaging devices
#
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
CONFIG_USB_SCANNER=m
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

No additional USB devices are set.

Re: 2.4.19-ac4 build problem

[Greg KH]

On Tue, Sep 03, 2002 at 10:50:59PM -0700, Peter wrote:
> 
> Is there a fix for this compilation problem? I've tried gcc 2.95.3, 3.0, 
> and 3.1 and get the same:
> 
> drivers/usb/usbdrv.o: In function `hidinput_hid_event':

What driver is this?  It isn't in the main 2.4.x tree.

thanks,

greg k-h

Re: 2.4.19-ac4 build problem

[Peter]

> Hm, I think you will have to compile the input stuff into the core, if
> you want your USB input drivers to link properly.  So there's really no
> way around this.

In that case, why don't we remove the choice to make modules in input core
support? 

If there's some reason to keep it, let's save someone some grief and add a
note to CONFIG_INPUT:

Note that in most cases, input support must be compiled into the core for
your USB input drivers to link properly.

Alternatively, add this text to the help screens for the three device
types.

Cheers,
Peter

Re: 2.4.19-ac4 build problem

[Greg KH]

On Wed, Sep 04, 2002 at 08:59:55PM -0700, Peter wrote:
> 
> > Hm, I think you will have to compile the input stuff into the core, if
> > you want your USB input drivers to link properly.  So there's really no
> > way around this.
> 
> In that case, why don't we remove the choice to make modules in input core
> support? 

No, because it works just fine when you build the USB drivers as
modules, and the Input core as modules, which is what the majority of
people do.

> If there's some reason to keep it, let's save someone some grief and add a
> note to CONFIG_INPUT:
> 
> Note that in most cases, input support must be compiled into the core for
> your USB input drivers to link properly.

Again, not true.  It just has to match the same value for the USB input
drivers.  A patch with this kind of wording would be greatly
appreciated.

thanks,

greg k-h

Re: 2.4.19-ac4 build problem

[Peter]

>No, because it works just fine when you build the USB drivers as
>modules, and the Input core as modules, which is what the majority of
>people do.

In that case, let's add this to the help screens for the three device
types (CONFIG_INPUT_KEYBDEV, CONFIG_INPUT_MOUSEDEV, CONFIG_INPUT_JOYDEV), 
after the current text:

For the drivers to link correctly, you must make the same selection (Y or
M) here as for the USB Human Interface Device (full HID) support.

Under CONFIG_USB_HID, likewise add after the current text:

For the drivers to link correctly, you must make the same selection (Y or
M) here as for Input core support.

That said, I suggest that Input core support menu be moved into the USB
support menu, where these dependency relations can be automated and made 
visible to the user. 

I apologize for not submitting a patch -- it's a skill I lack.

Cheers,
Peter.

Re: 2.4.19-ac4 build problem

[Greg KH]

<offtopic, your site keeps refusing my direct email due to a procmail
configuration bug on your site>

On Thu, Sep 05, 2002 at 01:00:33AM -0700, Peter wrote:
> 
> In that case, let's add this to the help screens for the three device
> types (CONFIG_INPUT_KEYBDEV, CONFIG_INPUT_MOUSEDEV, CONFIG_INPUT_JOYDEV), 
> after the current text:
> 
> For the drivers to link correctly, you must make the same selection (Y or
> M) here as for the USB Human Interface Device (full HID) support.
> 
> Under CONFIG_USB_HID, likewise add after the current text:
> 
> For the drivers to link correctly, you must make the same selection (Y or
> M) here as for Input core support.

That sounds reasonable.

> That said, I suggest that Input core support menu be moved into the USB
> support menu, where these dependency relations can be automated and made 
> visible to the user. 

No, the Input core is separate from the USB code, it does not belong in
that menu.

> I apologize for not submitting a patch -- it's a skill I lack.

Take a look at Documentation/SubmittingPatches, it should help you learn
those skills :)

thanks,

greg k-h

2.4.19-ac4 Out of Memory

[cogwepeter]

Greetings --

I was using mplayer on an i686 2.4.19-ac4 just now, and it suddenly froze.  
That is to say, it wasn't entirely frozen -- if you moved the mouse and
waited ten seconds, the cursor would move. Accessing it from another
terminal (one that was already logged in), I could type at the rate of a
letter a minute. After a few minutes it resolved itself and came back to
normal.

/var/log/messages showed this:

kernel: Out of Memory: Killed process 9702 (gmplayer).

I've not encountered this in 2.4.16.

Cheers,
Peter

2.4.19 -- ac97_codec failure ALi 5451

[Peter]

Sound fails on 2.4.19 with ALi 5451 built-in audio:

        Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, 
		version 0.14.9d, 00:57:19 Jan  9 2003
        PCI: Enabling device 00:06.0 (0000 -> 0003)
        PCI: Assigned IRQ 10 for device 00:06.0
        trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
        ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)
        ali: AC97 CODEC read timed out.
        last message repeated 127 times
        ali: AC97 CODEC write timed out.
        ac97_codec: AC97  codec, id: 0x0000:0x0000 (Unknown)

The trident driver was compiled in during this run. lspci --

00:06.0 Multimedia audio controller: Acer Laboratories Inc. [ALi] M5451 
PCI AC-Link Controller Audio Device (rev 02)

I've also tried Alsa, and the snd-ali5451 module loads under lengthy
protests from

alsa-kernel/pci/ali5451/ali5451.c:389 ali_codec_ready: codec not ready

The related modules also load and everything looks fine.

No sound in either case, trident or snd-ali5451. 

This is a matrix vpr 200A5 laptop running Debian's kernel 2.4.19-5.

I've seen other people have had similar problems; is this a problem with 
recent AC-97 codec revisions?

Cheers,
Peter

Re: 2.4.19 -- ac97_codec failure ALi 5451

[Alan Cox]

>         Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, 
> 		version 0.14.9d, 00:57:19 Jan  9 2003
>         PCI: Enabling device 00:06.0 (0000 -> 0003)
>         PCI: Assigned IRQ 10 for device 00:06.0
>         trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
>         ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)

So far so good.

>         ali: AC97 CODEC read timed out.
>         last message repeated 127 times
>         ali: AC97 CODEC write timed out.
>         ac97_codec: AC97  codec, id: 0x0000:0x0000 (Unknown)

Something lost the codec. Could be power management - was the laptop
suspended before it went funny ?

Alan

Re: 2.4.19 -- ac97_codec failure ALi 5451

[Peter]

Quoting Alan Cox <alan@redhat.com>:

> >         Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, 
> > 		version 0.14.9d, 00:57:19 Jan  9 2003
> >         PCI: Enabling device 00:06.0 (0000 -> 0003)
> >         PCI: Assigned IRQ 10 for device 00:06.0
> >         trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
> >         ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)
> 
> So far so good.
> 
> >         ali: AC97 CODEC read timed out.
> >         last message repeated 127 times
> >         ali: AC97 CODEC write timed out.
> >         ac97_codec: AC97  codec, id: 0x0000:0x0000 (Unknown)
> 
> Something lost the codec. Could be power management - was the laptop
> suspended before it went funny ?

No, this happens very reliably every time on a large number of occasions, whether 
trident is compiled in or as a module, or with ALSA's snd-ali5451. Dozens of read 
and write timeouts. In fact when the codec loads, it tends to freeze the whole 
system for a short time (from a few seconds to a minute).

That said, it's close to working. There have been times when I've been able to get 
sound -- typically by doing a manual insmod ac97_codec and trident. I had hoped the 
ALSA module would work more reliably, but it seems the problem is with the ac97 
codec.

Is the driver for the ac97 codec the same for OSS and ALSA? They appear to fail in 
very similar ways.

Peter

Re: 2.4.19 -- ac97_codec failure ALi 5451

[Peter]

I've downloaded the latest driver and am running 2.4.20 (yea!) -- the trident.c here 
is actually more recent than 2.5.55. It now loads fast and with no protest from 
ac97_codec, which has a new ID (ADS114). However, there's still not a peep (I try 
cat test.mp3 > /dev/dsp) -- and when KDE Control Center tries to restart the arts 
sound server, it alarmingly fails on "CPU overload" or just freezes the whole 
system. Is there anything I can do to get more information about what is not 
happening?

Cheers,
Peter

Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version 0.14.10h, 
Enabling device 00:06.0 (0000 -> 0003)
PCI: Assigned IRQ 5 for device 00:06.0
trident: ALi Audio Accelerator found at IO 0x1000, IRQ 5
ac97_codec: AC97 Audio codec, id: ADS114(Unknown)
ac97_codec: AC97 Audio codec, id: ADS114(Unknown)
PCI: Found IRQ 5 for device 00:06.0
gameport0: Acer Laboratories Inc. [ALi] M5451 PCI AC-Link Controller Audio Device at 
pci00:06.0 speed 1924 kHz

Quoting Alan Cox <alan@redhat.com>:

> >         Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, 
> > 		version 0.14.9d, 00:57:19 Jan  9 2003
> >         PCI: Enabling device 00:06.0 (0000 -> 0003)
> >         PCI: Assigned IRQ 10 for device 00:06.0
> >         trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
> >         ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)
> 
> So far so good.
> 
> >         ali: AC97 CODEC read timed out.
> >         last message repeated 127 times
> >         ali: AC97 CODEC write timed out.
> >         ac97_codec: AC97  codec, id: 0x0000:0x0000 (Unknown)
> 
> Something lost the codec. Could be power management - was the laptop
> suspended before it went funny ?
> 
> Alan
> 

Re: 2.4.19 -- ac97_codec failure ALi 5451

[Alan Cox]

> I've downloaded the latest driver and am running 2.4.20 (yea!) -- the trident.c here 
> is actually more recent than 2.5.55. It now loads fast and with no protest from 
> ac97_codec, which has a new ID (ADS114). However, there's still not a peep (I try 
> cat test.mp3 > /dev/dsp) -- and when KDE Control Center tries to restart the arts 
> sound server, it alarmingly fails on "CPU overload" or just freezes the whole 
> system. Is there anything I can do to get more information about what is not 
> happening?

No but the info is very useful. The key change involving ac97 is that the
new code in 2.4.x waits much longer for the codec reset to finish. I'm not
sure where the audio has gone however 8(

2.4.20 USB storage (SCSI emulation)

[Peter Nome]

Booting 2.4.20 (Debian sid official release 5) with an Archos Jukebox Recorder 20, a 
USB storage device running a SCSI emulation with the ISD200 driver, produces a host 
of messages in the log, but it works fine.  I'm getting Bad target number and an 
apparently failed "Attempting to get CSW" -- any ideas what's going on? What I DON'T 
get is a message telling me where the device is, as I should and used to -- e.g., 
"Detected scsi disk sda at scsi1, channel 0, id 0, lun 0". However, mounting 
/dev/sda1 works:

Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 39070080 512-byte hdwr sectors (20004 MB)
 sda:<7>usb-storage: queuecommand() called
 sda1

In sum, two minor bugs: the queuecommand() is fruitlessly trying to do something, 
and the user is not informed where the device is placed.

Cheers,
Peter

dmesg:

SCSI subsystem driver Revision: 1.00
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
usb-storage: act_altsettting is 0
usb-storage: id_index calculated to be: 88
usb-storage: Array length appears to be: 90
usb-storage: USB Mass Storage device detected
usb-storage: Endpoints: In: 0xc15c5794 Out: 0xc15c5780 Int: 0xc15c57a8 (Period 9)
usb-storage: New GUID 05ab0060fffffffffff7d96a
usb-storage: GetMaxLUN command result is -32, data is 128
usb-storage: clearing endpoint halt for pipe 0x80000280
usb-storage: Transport: Bulk
usb-storage: Protocol: Transparent SCSI
usb-storage: *** thread sleeping.
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage: 12 00 00 00 ff 00 5b df ac e0 ed de
usb-storage: Bulk command S 0x43425355 T 0x1 Trg 0 LUN 0 L 255 F 128 CL 6
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_transfer_partial(): xfer 255 bytes
usb-storage: usb_stor_bulk_msg() returned 0 xferred 36/255
usb-storage: Bulk data transfer result 0x1
usb-storage: Attempting to get CSW...
usb-storage: clearing endpoint halt for pipe 0xc0010280
usb-storage: usb_stor_clear_halt: result=0
usb-storage: Attempting to get CSW (2nd try)...
usb-storage: Bulk status result = 0
usb-storage: Bulk status Sig 0x53425355 T 0x1 R 219 Stat 0x0
usb-storage: Fixing INQUIRY data to show SCSI rev 2
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
  Vendor: HITACHI_  Model: DK23DA-20     Rev: 00J2
  Type:  Direct-Access            ANSI SCSI revision: 02
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Bad target number (1/0)
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Bad target number (2/0)
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Bad target number (3/0)
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Bad target number (4/0)
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Bad target number (5/0)
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Bad target number (6/0)
usb-storage: *** thread sleeping.
usb-storage: queuecommand() called
usb-storage: *** thread awakened.
usb-storage: Bad target number (7/0)
usb-storage: *** thread sleeping.
WARNING: USB Mass Storage data integrity not assured
USB Mass Storage device found at 2
USB Mass Storage support registered.

Re: 2.4.20 USB storage (SCSI emulation)

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

On Mon, Jan 20, 2003 at 04:41:32PM -0800, Peter Nome wrote:
> 
> Booting 2.4.20 (Debian sid official release 5) with an Archos Jukebox Recorder 20, a 
> USB storage device running a SCSI emulation with the ISD200 driver, produces a host 
> of messages in the log, but it works fine.  I'm getting Bad target number and an 
> apparently failed "Attempting to get CSW" -- any ideas what's going on? What I DON'T 
> get is a message telling me where the device is, as I should and used to -- e.g., 
> "Detected scsi disk sda at scsi1, channel 0, id 0, lun 0". However, mounting 
> /dev/sda1 works:
> 
> Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> SCSI device sda: 39070080 512-byte hdwr sectors (20004 MB)
>  sda:<7>usb-storage: queuecommand() called
>  sda1
> 
> In sum, two minor bugs: the queuecommand() is fruitlessly trying to do something, 
> and the user is not informed where the device is placed.

To answer, the SCSI layer should tell you where it is.  In 2.5.x (in a few
more days, hopefully), devfs will tell you this.

As for queuecommand() trying to do something, this is all normal.  It's
showing you that it is properly throwing away things that don't make sense
for a USB device like this.  Turn off debugging if you don't like it.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK!!!!
					-- Greg
User Friendly, 3/27/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.20 USB storage (SCSI emulation)

[Peter Nome]

Quoting Matthew Dharm <mdharm-kernel@one-eyed-alien.net>:

> To answer, the SCSI layer should tell you where it is.  

Agree -- the SCSI layer should say where it puts a new device, and in the case of 
USB storage it doesn't (kernel 2.4.20).
 
> As for queuecommand() trying to do something, this is all normal.  It's
> showing you that it is properly throwing away things that don't make sense
> for a USB device like this.  Turn off debugging if you don't like it.

Right -- thanks for clarifying. 
 
Cheers,
Peter

Re: 2.4.19 -- ac97_codec failure ALi 5451

[peter]

Final status report

The trident driver in 2.4.20 is now working on the vpr matrix 200a5 laptop with an
ALi5451 PCI soundcard. Remaining issues:

 * It consistently fails to work with the aRts server under KDE. I get "Sound server
fatal error. CPU overload: aborting" and then ""artsmessage: unix_connect: can't
connect to server." 
 * The headphone jack is dead -- this is the greatest functional loss. The
microphone jack is working; I'm unsure about the quality.
 * It's slightly erratic for some reason -- I haven't found a pattern to it. The
codec itself is very occasionally detected as AC97 Modem codec, id: ADS114, or as
AC97 Audio codec, id: ADA68.

I discovered I could use mp3blaster to increase the volume by pressing t for mixer 
and chosing PCM; this is then available in X also. I assume there's some more 
elegant way to do this -- some audio control tool? Software volume control in xmms 
works when I use the OSS driver.

Cheers,
Peter




Quoting Alan Cox <alan@redhat.com>:

> > I've downloaded the latest driver and am running 2.4.20 (yea!) -- the
> trident.c here
> > is actually more recent than 2.5.55. It now loads fast and with no protest
> from
> > ac97_codec, which has a new ID (ADS114). However, there's still not a peep
> (I try
> > cat test.mp3 > /dev/dsp) -- and when KDE Control Center tries to restart
> the arts
> > sound server, it alarmingly fails on "CPU overload" or just freezes the
> whole
> > system. Is there anything I can do to get more information about what is
> not
> > happening?
>
> No but the info is very useful. The key change involving ac97 is that the
> new code in 2.4.x waits much longer for the codec reset to finish. I'm not
> sure where the audio has gone however 8(
>
>