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.
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
Hi Greg -
Agree -- I couldn't find it either. This may be a makefile error:
linux-2.4.19-ac4 # grep usbdrv.o * -r
Makefile:DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o
drivers/usb/Makefile:O_TARGET := usbdrv.o
The kernel compiled fine when I defined Input core support in the kernel
rather than as modules (cf. below). And USB is working great -- keyboard,
cordless mouse, webcam, scanner, printer, the works.
Cheers,
Peter
Does not compile:
#
# 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
Compiles:
#
# Input core support
#
CONFIG_INPUT=y
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
I don't know if the last two lines matter.
On Wed, Sep 04, 2002 at 01:19:33PM -0700, Peter wrote:
>
> Hi Greg -
>
> Agree -- I couldn't find it either. This may be a makefile error:
>
> linux-2.4.19-ac4 # grep usbdrv.o * -r
> Makefile:DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o
> drivers/usb/Makefile:O_TARGET := usbdrv.o
Ah, stupid me, you were building USB into the kernel, so this is the usb
.o file. Sorry for the confusion.
> The kernel compiled fine when I defined Input core support in the kernel
> rather than as modules (cf. below). And USB is working great -- keyboard,
> cordless mouse, webcam, scanner, printer, the works.
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.
thanks,
greg k-h
> 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
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
>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.
<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
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
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
> 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
Quoting Alan Cox <[email protected]>:
> > 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
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 <[email protected]>:
> > 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
>
> 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(
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 <[email protected]>:
> > 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(
>
>
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.
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: [email protected]
Maintainer, Linux USB Mass Storage Driver
THEY CASTRATED MY QUAKE BITS! I WANT THEM BACK!!!!
-- Greg
User Friendly, 3/27/1998
Quoting Matthew Dharm <[email protected]>:
> 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