Re: UPEK/TouchChip Biometric Device problem

2007-06-23 Thread Hans Petter Selasky
On Friday 22 June 2007 22:42, Patrick Tracanelli wrote:
 Hello all,

 I have used the mentioned devices on FreeBSD 5.4 in the past, and they
 worked just fine, but now I get problems with the same device, on top of
 6.2-STABLE and also 7.0-CURRENT.

  From `usbdevs -v`, I get:

 Controller /dev/usb2:
 addr 1: full speed, self powered, config 1, UHCI root hub(0x),
 Intel(0x), rev 1.00
   port 1 addr 2: full speed, power 100 mA, config 1, Biometric
 Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01
   port 2 powered

 I have security/bsp_upektfmess, security/pam_bsdbioapi and
 security/bioapi installed. It is a 6.2-STABLE system from 2 hours ago.

 Listing bsp devices, I get:

 # bbdm -l bsp
 UUID {----}
   Example Vendor libbioapi_dummy100.so (BioAPI v1.1 Dummy BSP)
 UUID {263a41e0-71eb-11d4-9c34-12403700}
   BioAPI Consortium libpwbsp.so (BioAPI Password BSP)
 UUID {5550454b-2054-464d-2f45-535320425350}
   UPEK, Inc. libtfmessbsp.so (TouchChip TFM/ESS Fingerprint BSP)

 Backend configurations:

 # bbdm -l birdb
 Installed BIRDB modules
 filedb   Filebacked database (b-tree)
 plainPlain text file

 And now, the problem:

 # bbdm -b {5550454b-2054-464d-2f45-535320425350} -m filedb -c eksffa
 bbdm: Failed to initate BSP {5550454b-2054-464d-2f45-535320425350}

 And on /var/log/messages as well as dmesg, I get:

 All threads purged from ugen1.1
 All threads purged from ugen1.2
 All threads purged from ugen1.3

 What is this about threads purged? Also, the port want libintl.so.6
 while 6.2-STABLE has libintl.so.8. I have tried 1) linking .8 to .6 and
 also copied .6 from another system (also, 6.2-STABLE) to the current
 one. Didnt work both way. Same behavior, exactly.

 On 7.0-CURRENT things are worse. libpthread is not found, and the same
 command core dumps. Anyway, 6.2-STABLE is more important to me right
 now, since I need this device to work on FreeBSD for an ongoing project,
 but if a solution to 7.0 happens first my work can move to that version.


There is a list called [EMAIL PROTECTED] maybe we can handle this 
issue there.

First of all, can you turn on more debugging in your bbdm?

The default USB kernel is usually not compiled with USB debugging.

There exists an:

options USB_DEBUG

I think.

If you have time you can also try the my new USB stack:

See:

http://www.turbocat.net/~hselasky/usb4bsd/

Download the SVN version.

If my new USB stack solves the problem then it is probably a regression issue 
in 6.2-STABLE, and as I recall there have been lots of changes.

What kind of platform are you using?

--HPS
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Unable to use my USB MP4 player: FreeBSD hangs

2007-06-23 Thread Dominique Goncalves

Hi,

I'm trying to connect my USB MP4 player to transfer some video and
music files, but when I plug the player FreeBSD hangs at this point:

Jun 23 15:00:07 lost kernel: umass1: vendor 0x10d6 USB 2.0(HS) Flash
Disk, rev 2.00/1.00, addr 2
Jun 23 15:00:07 lost kernel: da4 at umass-sim1 bus 1 target 0 lun 0
Jun 23 15:00:07 lost kernel: da4: USB 2.0 (HS) Flash Disk 1.00
Removable Direct Access SCSI-0 device
Jun 23 15:00:07 lost kernel: da4: 40.000MB/s transfers
Jun 23 15:00:07 lost kernel: da4: 967MB (1982129 512 byte sectors: 64H
32S/T 967C)

I mean by hang that with my gnome session nothing happens when I try
to open something and it's the same on a virtual console I can't login
or type something.

Everything come back when I unplug the reader :

Jun 23 15:00:25 lost kernel: umass1: BBB reset failed, IOERROR
Jun 23 15:00:25 lost kernel: umass1: BBB bulk-in clear stall failed, IOERROR
Jun 23 15:00:25 lost kernel: umass1: BBB bulk-out clear stall failed, IOERROR
Jun 23 15:00:25 lost kernel: (da4:umass-sim1:1:0:0): Synchronize cache
failed, status == 0x4, scsi status == 0x0
Jun 23 15:00:25 lost kernel: umass1: at uhub1 port 5 (addr 2) disconnected
Jun 23 15:00:25 lost kernel: (da4:umass-sim1:1:0:0): lost device
Jun 23 15:00:25 lost kernel: (da4:dead_sim0:0:0:0): removing device entry
Jun 23 15:00:25 lost kernel: umass1: detached

Let me know if you need more informations.
Thanks for your help,
Regards.

%uname -a
FreeBSD lost 6.2-STABLE FreeBSD 6.2-STABLE #1: Sat Jun  2 15:34:52
CEST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386

%dmesg
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
   The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-STABLE #1: Sat Jun  2 15:34:52 CEST 2007
   [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
ACPI APIC Table: Nvidia AWRDACPI
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2209.90-MHz 686-class CPU)
 Origin = AuthenticAMD  Id = 0x40fb2  Stepping = 2
 
Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
 Features2=0x2001SSE3,CX16
 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow+,3DNow
 AMD Features2=0x1fLAHF,CMP,b2,b3,CR8
 Cores per package: 2
real memory  = 805240832 (767 MB)
avail memory = 770244608 (734 MB)
ioapic0: Changing APIC ID to 2
ioapic0 Version 1.1 irqs 0-23 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: Nvidia AWRDACPI on motherboard
acpi_bus_number: can't get _ADR
acpi_bus_number: can't get _ADR
acpi_bus_number: can't get _ADR
acpi_bus_number: can't get _ADR
acpi0: Power Button (fixed)
acpi_bus_number: can't get _ADR
acpi_bus_number: can't get _ADR
acpi_bus_number: can't get _ADR
acpi_bus_number: can't get _ADR
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0
cpu0: ACPI CPU on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: memory, RAM at device 0.0 (no driver attached)
isab0: PCI-ISA bridge at device 1.0 on pci0
isa0: ISA bus on isab0
pci0: serial bus, SMBus at device 1.1 (no driver attached)
pci0: memory, RAM at device 1.2 (no driver attached)
ohci0: OHCI (generic) USB controller mem 0xfe02f000-0xfe02 irq
21 at device 2.0 on pci0
ohci0: [GIANT-LOCKED]
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: OHCI (generic) USB controller on ohci0
usb0: USB revision 1.0
uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 8 ports with 8 removable, self powered
ehci0: EHCI (generic) USB 2.0 controller mem 0xfe02e000-0xfe02e0ff
irq 22 at device 2.1 on pci0
ehci0: [GIANT-LOCKED]
usb1: EHCI version 1.0
usb1: companion controller, 10 ports each: usb0
usb1: EHCI (generic) USB 2.0 controller on ehci0
usb1: USB revision 2.0
uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub1: 8 ports with 8 removable, self powered
pcib1: ACPI PCI-PCI bridge at device 4.0 on pci0
pci1: ACPI PCI bus on pcib1
xl0: 3Com 3c905-TX Fast Etherlink XL port 0xcc00-0xcc3f irq 16 at
device 5.0 on pci1
miibus0: MII bus on xl0
nsphy0: DP83840 10/100 media interface on miibus0
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:a0:24:f0:fc:71
fwohci0: Texas Instruments TSB43AB23 mem
0xfd8ff000-0xfd8ff7ff,0xfd8f8000-0xfd8fbfff irq 19 at device 9.0 on
pci1
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 00:00:0a:e6:ff:69:86:6e
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: IEEE1394(FireWire) bus on fwohci0
fwe0: Ethernet over FireWire on firewire0
if_fwe0: Fake Ethernet address: 

Re: kern/79266: [pci] [patch] RELENG_4 pci CONF1_ENABLE_MSK depend MFCed incorrectly?

2007-06-23 Thread Gavin Atkinson
Synopsis: [pci] [patch] RELENG_4 pci CONF1_ENABLE_MSK depend MFCed incorrectly?

State-Changed-From-To: open-closed
State-Changed-By: gavin
State-Changed-When: Sat Jun 23 16:05:52 UTC 2007
State-Changed-Why: 

Now that 4.x has been marked End-of-Life, this PR is no longer
relevant.  The problem discussed never existed in 5.x or later.

http://www.freebsd.org/cgi/query-pr.cgi?pr=79266
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


[vfs_bio] Re: Fatal trap 12: page fault while in kernel mode (with potential cause, fix?)

2007-06-23 Thread Adam McDougall
On Mon, Apr 23, 2007 at 11:55:52AM -0400, Kris Kennaway wrote:

  On Mon, Apr 23, 2007 at 05:35:47PM +0200, Kai wrote:
   On Thu, Apr 19, 2007 at 02:33:29PM +0200, Kai wrote:
On Wed, Apr 11, 2007 at 12:53:32PM +0200, Kai wrote:
 
 Hello all,
 
 We're running into regular panics on our webserver after upgrading
 from 4.x to 6.2-stable:

   
   Hi all,
   
   To continue this story, a colleague wrote a small program in C that launches
   40 threads to randomly append and write to 10 files on an NFS mounted
   filesystem. 
   
   If I keep removing the files on one of the other machines in a while loop,
   the first system panics:
   
   Fatal trap 12: page fault while in kernel mode
   cpuid = 1; apic id = 01
   fault virtual address   = 0x34
   fault code  = supervisor read, page not present
   instruction pointer = 0x20:0xc06bdefa
   stack pointer   = 0x28:0xeb9f69b8
   frame pointer   = 0x28:0xeb9f69c4
   code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
   processor eflags= interrupt enabled, resume, IOPL = 0
   current process = 73626 (nfscrash)
   trap number = 12
   panic: page fault
   cpuid = 1
   Uptime: 3h2m14s
   
   Sounds like a nice denial of service problem. I can hand the program to
   developers on request.
  
  Please send it to me.  Panics are always much easier to get fixed if
  they come with a test case that developer can use to reproduce it.
  
  Kris

I have been working on this problem all weekend and I have a strong hunch at 
this point 
that it is a result of 1.424 of sys/kern/vfs_bio.c which was between FreeBSD 
5.1 and 
5.2.  This hunch is currently being verified by a system that was cvsupped to 
code 
just before 1.424, and it has been running about 7 times longer than the usual 
time 
required to crash.  I am currently attempting to craft a patch for 6.2 that 
essentially 
backs out the change to see if that works, but if this information can help 
send a 
FreeBSD developer down the right trail to a proper fix, great.  I will follow 
up with 
more detailed findings and results tonight or soon.

links:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.423;r2=1.424
related to 1.424:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.420r2=1.421

Commit emails:
http://docs.freebsd.org/cgi/mid.cgi?200311150845.hAF8jawU027349
http://docs.freebsd.org/cgi/mid.cgi?20030445.hAB4jbYw093253
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]