> You said above that there's no evidence that a device reset would help.
> You need to find a way to get that evidence, either positive or negative.
>
Ok. Tried one other thing. Read about gcc-incompatibilities/fixes in the
the sourcecode (kernel Makefile). So I tried to use
another gcc-version (
On Saturday 04 February 2006 05:57, Mike Isely wrote:
> On Sat, 4 Feb 2006, Helmut Toplitzer wrote:
> > On Saturday 04 February 2006 02:08, Helmut Toplitzer wrote:
> >> Hi!
> >>
> >>
> >> Just in case
> >>
> >> Maybe Ingo Fl
HI!
As you suggested I bought a new USB controller (ALi, ohci/ehci) and disabled
the old one.
OK. It now works great. Well, until it stops. (Without hang
this time but it stops. I need too restart mythtv.)
Feb 3 18:13:45 kernel: pvrusb2 /*---TRACE_CTL*/ pvr2_encoder_start
Feb 3 18:13
Hi again!
Ok. Maybe this is of interest too:
lsusb shows the following changes when disconnecting
the usb-storage and keeping the pvrusb2 device connected:
@@ -300,11 +162,11 @@
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable0x08
- Por
Hi!
Alan, I used your patch for the following tests:
I solved my problem (at least a part of it).
Plugging in another USB device on another port does NOT
make my PVR hang anymore. Unplugging it will
result in hangs after a few minutes.
Logs of lspci -xxx are attached:
1 initial state with pvrus
> experiencing the same problem after all. I feel so alone again...
However, at least temperatur goes slightly up (2K) wenn i load ehci-hcd
and I can confirm the ASYNC problem:
bus pci, device :00:10.3 (driver 10 Dec 2004)
EHCI Host Controller
EHCI 1.00, hcd state 1
ownership 0101 linux
S
>
> Some stylistic suggestions. The new routines should be surrounded by
>
> #if defined(CONFIG_BLK_DEV_VIA82CXXX) and defined(HAVE_VIA_HALT)
>
> In the #else part, make ide_disable_hlt and ide_enable_hlt inline.
>
> You don't need the #ifdef protecting the calls to to ide_disable_hlt and
> ide_en
Is this adequate?
You need a VIA82xxx board, HLT and pass disableviahlt on boot.
Tested on my system with success. Please check for
errors.
Helmut
--
My GNUpg fingerprint http://www.gnupg.org
4563 F4FB 0B7E 8698 53CD 00E9 E319 35BD 6A91 1656
--- linux-2.6.15/drivers/ide/ide-dma.c 2006-01-19
>
> Yes, this mail explains it more:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0207.0/0004.html
>
> If "HALT Command Detect is enabled" is enabled
> STPGNT is issued on detection of HALT command.
>
> If "Disconnect Enable When STPGNT Detect" is enabled
> bus disconnect is done on detection of
Ok. I found another possible reason, did I?
I read in several forums that HLT in KT333 chipsets
of VIA is not enough to get the processor in powersafe
and to disconnect from the FSB. You need to issuse
the STPGNT command which also needs first
to set some registers (because it degrades overall pe
>
> Did disabling ACPI change something?
>
No, it didn't
>
> When CPU is idle HLT instruction is used by default (for power saving).
> Probably chipset detects when CPU is entering low power mode and
> also enters low power mode. Switching between low and normal power
> modes is slow and results
> Just wild guesses but please try:
> * booting with "cpu=poll" parameter
> * kernel with ACPI and Power Management disabled
>
Ok. Here it goes.
Did your tests which doesn't change anything. But
I couldn't find the cpu= parameter in kernel-parameters.txt
so I tried something else too:
both kerne
Hi!
> >
> > 37MB/s with CPU not utilized
> > 55MB/s with CPU 100% utilized
>
> I can't reproduce this locally, please send me your kernel
> config. Although I have Intel chipset it is still worth a try
> if it is generic kernel bug. I don't remember seeing anything
> like that on my old VIA syst
So. After a looong time I decided to drop you a note
whats going on with my "small but funny" usb/ide problem:
(Maybe others are interested into this too)
First: I didn't bought a new USB controller.
Alan, your patch went quite well and it looks like the device
isn't disconnecting any longer. So
> > Any chance you can attach a separate USB controller to your system and
> > test with that?
> Yes, that would be the best way to test. Helmut, it's up to you...
Oh. That's funny.
*Big pause, calm down*
So isn't there a way to tune the debug output to get
a point where things are going wron
>
> I know nothing at all about this pvrusb driver. Your stack trace seems to
> indicate that it might the problem (as opposed to any other part of the
> USB stack).
OK. Maybe it's a pvrusb2 problem then. I'll cc to the pvrusb2-list.
The problem is that playing video stops sometimes. (Normaly af
>
> Try doing this test in single-user mode. When you plug in the storage
> device and it doesn't initialize, get a stack trace (Alt-SysRq-T). That
> may help show where things are hanging up.
>
Sorry for the late answer. It was realy hard to reproduce today.
Sometimes it worked for more than 60
hi again!
Did what you said, but card hangs again after a few seconds.
This time without a debug message. it's not possible
to recover without reboot. Unplugging/Replugging doesn't
reinit device nor produces any debug-info.
Killing process wakes up the driver of the device:
23:12:35 kernel: pvrus
>
> This may be related to the PCI configuration values, as initialized by
> your chipset. What do you get from "lspci -xxx -s 10.3"?
>
:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00: 06 11 04 31 17 00 10 02 82 20 03 0c 10 f8 00 00
10: 00 ff ff df 00 00 00 00 00 00 00 00
Ok because of the long thread a short summary:
My transferrate tests were running on a normal IDE device.
VIA IDE, USB and so on ... systems are intefering.
USB-system affects IDE system, sometimes in
a dramatic way (diff. 20MB/s on IDE transferrate).
Beside this sometimes the ehci-driver disc
Ok. Sorry for spamming. I should have known the next question before:
# modprobe ehci-hcd
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 66 MB in 3.06 seconds = 21.57 MB/sec
== Starting cpuburn ==
# hdparm -t /dev/hda
/dev/hda:
Timing buffered
> And lird ist starting to consume all the processor-power. This is where
> the PCI BusMastering takes place when CPU has no time to do so? This is
Ok. verified this using cpuburn:
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 102 MB in 3.03 seconds = 33.68 MB/sec
=== Start
Alan, thanks for your response.
> > === REBOOT =
> Which HCD modules are loaded when you reboot? Only uhci-hcd?
Yes. Only uhci-hcd.
> > # hdparm -t /dev/hda
> >
> > /dev/hda:
> > Timing buffered disk reads: 44 MB in 3.13 seconds =
This is not funny anymore:
--
My GNUpg fingerprint http://www.gnupg.org
4563 F4FB 0B7E 8698 53CD 00E9 E319 35BD 6A91 1656
=== REBOOT =
# hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 44 MB in 3.13 seconds = 14.05 MB/s
Ok. :-) finaly we found at least one channel to communicate.
So I only use linux-usb-devel for further communication.
Hardware industries are not always as honest as we are used to be.
So we've got to develop our test methods ourselves.
So I suggest:
a drop in IDE communicatio
25 matches
Mail list logo
