Re: problems mounting usb device in FBSD 7.1 [partial solution]

On Sun, 22 Feb 2009 15:42:17 -0600, DaveG <nospam@xxxxxxxxxx> wrote:

On Sun, 22 Feb 2009 20:49:28 +0000, Chris wrote:

On Sun, 22 Feb 2009 12:08:22 -0600, DaveG <nospam@xxxxxxxxxx> wrote:

On Thu, 12 Feb 2009 19:45:36 +0000, DaveG wrote:

Sort of fixed. There was a typo in devfs.rules. Why it worked from
the command line and not from the script still escapes me. Maybe
devfs.conf had something to do with it.

But, now it won't download pics from the camera without corrupting
them. This might be a USB2/USB1 issue. The mount command is exactly
as used on my FBSD5.5 system. The first JPeG image partially
downloads, ie the first 5% or so is decodable. Any further image
files are so corrupt that nothing can decode them.

Anyone seen this sort of thing before and solved it?

OK, I've eliminated almost everything. csup'ed source, rebuilt GENERIC
as a custom kernel (removing ehci as well all the debug/trace settings,
unwanted SCSI/RAID/Ethernet stuff, *NOT* the scsi stuff required for
USB though), rebuilt world, put all the devfs stuff back to defaults
and test mounted both the camera and a pendrive.

Files still get corrupted when reading/copying from them.

The one remaining item which is different is a PCI USB2.0 card I added
just before installing 7.1 (the devices are not plugged into it). This
has no effect on my 5.5Stable install still sitting there on the other
HDD. I can boot that, and have done a number of times, and copy files
from the camera with no problems, both as root and as a user with
correct devfs settings.

I'll pull the PCI USB card tonight and see what happens.


If you know what you are doing, try to play with cvsup and bring in
patches which were either added or removed and pinpoint where the
problem started with a patch that was added, then you can speak to the
person who added that patch and either have it reverted or fixed.

Playing with it for days will not fix the problem without any hackering.
Something broke the code.

I can see your point in suggesting that, but since no one else seems to
have seen this problem, it seems more likely to be me who is the source
of the problem.

As Warren suggested, I've tested the RAM and memtest was well through
test#9 before I killed it. That suggests to me that the RAM and it's
underlying hardware are all fine unless it's a far more exotic RAM error
than anything I've come across before. RAM errors almost always show up
no later that test#4 on memtest86.

I'm going to drop in a spare hard disk now and do a clean, minimal
install of 7.1 and see what happens.


I did that with a habu mouse issue, after days of adding and removing revisions I pinpointed one which fixes my mouse issue so I saved that patch and manually added it after each build world until it was fixed, to this day my habu mouse doesn't work completely. I play a lot of games so the mouse is a nice touch, but I don't use FreeBSD or Linux as a everyday OS but I do use the FreeBSD for a firewall/router and Linux as a testing bed for some small projects.

Saying that if it works fine in 5.5 but not 7.1 try to figure out what changes were made as the locking tends to do more harm than good without proper testing. Due to the nature of FreeBSD it can not be tested on every piece of hardware, just the hardware which is sent in or donated to the FreeBSD project so maybe your MB or other hardware isn't supported 100% and causes the corypt files.

But you should look into that as if it works fine in 5.5 but not 7.1 something broke the code or they do this on purpose which I highly doubt it :)

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
.

Relevant Pages

  • Re: Is FreeBSD ready for desktop (Mozilla Flash)
    ... A number of hardware vendors ... > happen to be using a hardware/software combination blessed by Macromedia. ... >> layer for running the Linux version of the plugin exists. ... copies of FreeBSD running on i386 than on any of the other hardware ...
    (comp.unix.bsd.freebsd.misc)
  • RE: Anthonys drive issues.Re: ssh password delay
    ... The dmesg you sent indicated that the 2 disks were negotiating at ... > possible cause in the universe before blaming it on FreeBSD. ... to take the risk of it being hardware, ... believe is that it's a bug in the FreeBSD driver. ...
    (freebsd-questions)
  • Re: Quality of FreeBSD
    ... And wouldn't mind to wait longer for real production quality ... on the hardware you know ... and FreeBSD users to do some of the testing. ... This change will help shake out software bugs relating to ...
    (freebsd-stable)
  • Re: FreeBSD and hardware??
    ... Installing on laptop type hardware is a tricky proposition: ... FreeBSD project already has a very good world-wide on-line distribution ... Driver support really is the kicker in all of this. ... Apple MacOSX doesn't ...
    (freebsd-questions)
  • Re: i give up
    ... The list of supported hardware is often written in terms ... I've installed ethernet cards named "compex" to PCs and they worked well ... compatible with FreeBSD. ... nVidia sucks for use on Unix platforms. ...
    (freebsd-current)