*** This bug is a duplicate of bug 197762 ***
https://bugs.launchpad.net/bugs/197762
sbec67:
Have you tried your device with another OS with different performance results?
>From your lsusb output is does not look like your device is listed? Was
it plugged in when you ran lsusb?
If that doesn
RishiRamraj:
You can see https://help.ubuntu.com/community/DiskPerformance for
general advice on testing performance of a disk and reporting your
issue. Your snip from dmesg tells that you plugged in a USB 2.0 device,
but that is about what can be said from that information, so further
performance
søn, 20 12 2009 kl. 20:34 +, skrev Przemysław Kulczycki:
> So it seems that some subsystem invoked by Gnome (hal? udev? gvfs?)
> is responsible for the slowdown.
> Please tell me if this is relevant to this bug or should I file a new one?
Everyone should open new reports, you should too.
Your
[1] https://bugs.launchpad.net/ubuntu/+bug/334914/comments/30
[2] https://help.ubuntu.com/community/DiskPerformance
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
ons, 10 06 2009 kl. 22:38 +, skrev jamesnmandy:
> Hiding behind a "proper bug request" gets us nowhere.
And you posting useless information in this bug does?
> It's not working like it is supposed to and that's painfully obvious.
And it should be painfully obvious by now that the issue cann
tor, 11 06 2009 kl. 01:16 +, skrev Matt Joiner:
> I get this same effect, slowing after about 200MB, on an internal NTFS
> drive.
This is just what the "Nautilus shows high transfer rate at beginning of
transfer but then slows down" part of [1] describes right? Please read
that page and please
ons, 10 06 2009 kl. 09:26 +, skrev kulight:
> This is not an issue of using usb 1
> My device and port are both usb 2
But they are still used in USB 1.1 mode, see your dmesg that says "new
full speed USB device" and lsusb that shows the USB drive is on a bus
with a 1.1 device (this is very ea
> On Mon, Jun 8, 2009 at 9:54 PM, jamesnmandy
> wrote:
>
> > There's no way all these people are seeing this behaviour because they all
> > have vastly different yet commonly "crappy" hardware. The same exact
> > hardware works great under the "other" OS. It's 100% a *nix issue and it's
> > 100
man, 08 06 2009 kl. 20:14 +, skrev epv:
> This isn't normal behavior. Obviously it behaves fine while all writes
> are going to buffer cache, but once it tries to write it out to the
> device, wait times on the partition shoot up to 30sec or more, and all
> processes trying to touch the usb dis
d3mia7: Though I only had a quick glance at your oops, I fail to see how
your problem is similar to the one reported by Beata. You should file a
new bug if it is a different problem.
--
USB stops working after a while
https://bugs.launchpad.net/bugs/228746
You received this bug notification becau
Interesting. So, either a vanilla/upstream 2.6.24 does not have the
problem, or something in your config makes the problem go away. PCMCIA
seems to generally be enabled in your config, but it would probably be
good to test 2.6.24 with a config as close to Ubuntu's edition of
2.6.24. Do you still ha
alex123: Cool, anything in particular that made you suspect a BIOS bug?
I guess everything is fine for your system then.
kulight: We'd still like to hear whether this is simply an issue of USB
1.1 being used.
--
[jaunty] usb file transfer is very very slow
https://bugs.launchpad.net/bugs/334914
u. If anybody feel like picking up the discussion on LKML they
are of course welcome.
** Changed in: linux (Ubuntu)
Status: New => Invalid
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Simon Holm Thøgersen (odie-cs)
** Changed in: linux
Status: New => Inval
A short addendum, the instructions for using the script were incomplete
and should have been
wget http://rostedt.homelinux.com/code/streamline_config.pl
cp .config config.backup
perl streamline_config.pl > new_config
mv new_config .config
make oldconfig
--
jaunty 2.6.28 freezes on pcmcia detecti
Thanks Gary. I think this problem should be easy to solve for others
that know more about automatic loading of modules than I do, so for the
sake of making it possible for others to skip right to working on a
solution, can you please verify that the following is correct?
The executive summary is t
Good, you should see https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
this page for how to checkout the sources from git and build a kernel in
general. It should be straigthforward to follow, but just ask if you
have any questions.
After step 3, you should do the following before going to step 4.
I took this question to the linux kernel mailing list with Jean-Paul
CC'ed and I think you guys should take discussion there and close this
bug appropriately afterwards. See http://lkml.org/lkml/2009/5/21/275.
--
kill(2) succeeds when no process corresponds to the given PID
https://bugs.launchpad
Jim,
it almost sounded like you had a fix to this problem, any updates?
Perhaps your findings should simply be sent to linux-usb-devel or filed
on bugzilla.kernel.org?
--
USB stops working after a while
https://bugs.launchpad.net/bugs/228746
You received this bug notification because you are a m
Since Gusty was fine and Hardy was not, we might be able to find the
patch that introduced the bug by simply inspecting the changes that went
in between 2.6.22 and 2.6.24.
git log v2.6.22..v2.6.24 drivers/pcmcia/cistpl.c
only reveals one patch, so that would be very interesting to revert.
Even if
Jean-Paul and Glyph,
by which standard or documentation do you believe the current behaviour
is incorrect? My guess is that the behaviour is completely intentional,
but if documentation says otherwise or can be clarified I'm sure we can
work something out.
--
kill(2) succeeds when no process cor
Hi Taylor,
so the oops this is present with 2.6.29 but not 2.6.29.1? I guess you
still want the fix into the ubuntu kernel, so I had a look at the
patches that went into 2.6.29.1. I couldn't find an obvious candidate,
but I can help you bisect the patches and compile a list of candidates I
find mo
Florian and Jukka,
if you still want to pursue a solution to this issue, I've got a couple
of suggestions to try.
The first is to capture the output of a failing resume with netconsole,
see https://wiki.ubuntu.com/KernelTeam/Netconsole.
Since it is a regression (for Florian at least) it might al
Leann,
seems to be -EREPORTERGONE, so just close this?
--
Network disabled when resuming from hibernate on Dell M1330
https://bugs.launchpad.net/bugs/306611
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ub
Uhm, according to the upstream bug it seems that "Ubuntu" has been made
aware of a fix. See from comment #7 and down in upstream report. Have
this made it into the updates for Hardy and can this bug be closed?
--
[i945gme] [Hardy] 3D Graphic stop working after resume and resolution change
https:/
Hi Sven-Ola,
if you still experience the problem and is interested in a solution, I
think you should try building the latest upstream kernel yourself, see
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild. Provided the problem
still exists I think you should report the problem upstream, since it
s
Gary,
does it work if you manually modprobe usb-storage and possibly other
related modules?
--
kernel 2.6.28 from 2.6.27 prevents Alcor reader working
https://bugs.launchpad.net/bugs/372232
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Richard Hull,
you should work this out together with Pierre Ossman and the rest of the
mmc and sdhci developers. You already know how to compile your own
kernel so I don't think there should be any problems. I'd suggest you
start by checking out the lastest upstream kernel from git and try that.
(
Night64,
flash devices are slow and the only reason the transfer appears to be
fast at the beginning is that data is written to OS memory and then
later to disk. Use dstat to monitor disk performance as explained on
https://help.ubuntu.com/community/DiskPerformance, And open new bug
reports please
MVDHR,
and why should we care? This bug has been open for a year and 50 people
have commented here, so news would be that the problem actually went
away. You give no information that helps further debug the issue, please
read https://help.ubuntu.com/community/DiskPerformance and diagnose your
prob
BTW it seems like you have connected your USB stick to a USB 1.1 port,
so that could certainly explain why performance might not be as
expected. It would still be useful to get the dstat trace as mentioned
before.
You can tell by a look at the output of just a simple lsusb that shows
the flash dis
kulight,
assuming that you still experience the slow transfer and the problem
with the flood of messages in dmesg is solved, can you provide us with a
dstat trace as described on
https://help.ubuntu.com/community/DiskPerformance ?
--
[jaunty] usb file transfer is very very slow
https://bugs.laun
Hi Diaa,
can you provide us with the mount options for the automatic and manual mount
cases? I.e.
grep /proc/mounts
It would also be nice with a dstat trace of the data written to disk for
both cases, see https://help.ubuntu.com/community/DiskPerformance or
Theodore's comments in
https://bugs.l
So, I believe I am the one Theodore refered to as venting how the
useless Ubuntu bug reports are. While they really are, I also really
want to help.
So, following Theodore's suggestion I've started
https://help.ubuntu.com/community/DiskPerformance on the Ubuntu Wiki. It
is pretty basic right now,
33 matches
Mail list logo
