Quoting khs...@codeaurora.org (2021-01-13 15:52:37)
> On 2021-01-13 12:25, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2021-01-13 10:59:58)
> >> Both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts.
> >> Therefore irq_hpd handler should not issues either aux or sw reset
> >> to avoid fo
On 2021-01-13 12:25, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-01-13 10:59:58)
Both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts.
Therefore irq_hpd handler should not issues either aux or sw reset
to avoid following unplug interrupt be cleared accidentally.
Kuogee Hsieh (2):
Quoting Kuogee Hsieh (2021-01-13 10:59:58)
> Both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts.
> Therefore irq_hpd handler should not issues either aux or sw reset
> to avoid following unplug interrupt be cleared accidentally.
>
> Kuogee Hsieh (2):
> drm/msm/dp: return fail when bo
Both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts.
Therefore irq_hpd handler should not issues either aux or sw reset
to avoid following unplug interrupt be cleared accidentally.
Kuogee Hsieh (2):
drm/msm/dp: return fail when both link lane and rate are 0 at dpcd
read
drm/msm/
Both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts.
Therefore irq_hpd handler should not issues either aux or sw reset
to avoid following unplug interrupt be cleared accidentally.
Kuogee Hsieh (2):
drm/msm/dp: postpone irq_hpd event during connection pending state
drm/msm/dp: unp
On 01-06-17 09:44, Hegr, Jiri wrote:
> Dears,
> We use small WiFi evaluation board WM-BN-BM-04_EVB_V1.2 with BCM43362 chip
> (Broadcom).
> This board is connected to OMAP-L138 via SDIO interface with Linux 4.9.10
> containing WiFi driver brcmfmac.
> Our problem is in OOB interrupt. The driver (an
Hello,
I think there is a bug in i2c_pca_isa driver.
Problem is interrupt running on arm720 system linux-2.6.20.1.
Description of the problem:
When driver write to pc9564 an infinite loop interrupt appear (bloquing
the system).
J think it is because the acknowledge of interrupt is not do corr
Ganesh Venkatesan wrote:
Ben:
Have you checked if the BIOS on the super micro machine is the latest
and greatest. I have had interrupt routing issues very similar to the
one you are describing due to a BIOS Interrupt Routing issue. Moving
to newer BIOS fixed it.
A new BIOS didn't help. Super-Mi
Ben:
Have you checked if the BIOS on the super micro machine is the latest
and greatest. I have had interrupt routing issues very similar to the
one you are describing due to a BIOS Interrupt Routing issue. Moving
to newer BIOS fixed it.
ganesh.
On 3/24/05, Ben Greear <[EMAIL PROTECTED]> wrote:
Dear all,
I try to modify inet_sendmsg() and inet_recvmsg().
To defer the time to notify a receiver, I use a timer for the problem.
But it causes "Scheduling in interrupt" error.
Is there any method to reform it?
Thank you for tour help
MingChieh Chang,
Taiwan
Scheduling in interrupt
invalid
Dear all,
I try to modify inet_sendmsg() and inet_recvmsg().
To defer the time to notify a receiver, I use a timer for the problem.
But it causes "Scheduling in interrupt" error.
Is there any method to reform it?
Thank you for tour help
Scheduling in interrupt
invalid operand:
CPU:0
EI
Dear all,
I try to modify inet_sendmsg() and inet_recvmsg().
To defer the time to notify a receiver, I use a timer for the problem.
But it causes "Scheduling in interrupt" error.
Is there any method to reform it?
Thank you for tour help
Error:
Scheduling in interrupt
invalid operand:
CPU:
For posterity's sake:
The problem is evidently a hardware problem, and I'll have to
return the board to the manufacturer so they can solder on another
part.
So, if you want to use 4-port NICs in slot-5 of the SuperMicro X6DVA-EG
board, then purchase the X6DVA-4G instead, as the X6DVA-EG will NOT wo
Lennert Buytenhek wrote:
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector t
Daniel Egger <[EMAIL PROTECTED]> :
[...]
> NFS machines on the Gbit network will resume operation) I popped
> in the chp RealTek card (which caused some slight problems
> like permanent hangs and bad performance before) and everything
> works like a charm. Of course, after throwing in some extr
Daniel Egger wrote:
The card is still in the system and running, so if someone wants
me to run to more tests or diagnostic, please be my guest.
What does: ethtool -t eth0
show?
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this lis
On 24.03.2005, at 03:03, Ben Greear wrote:
When trying to send/receive traffic, I get TX watchdog timeouts. The
other
interfaces seem to work just fine.
No idea whether my problem is related but due to a broken motherboard
I had to switch from a SiS based Athlon board (ECS K7S5A) to a new
one whi
Lennert Buytenhek wrote:
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector t
On Wed, Mar 23, 2005 at 06:03:30PM -0800, Ben Greear wrote:
> I have two 4-port e1000 NICs in the system, on a riser card.
How is the riser card wired? F.e. does it have a single edge
connector, and provides two PCI slots, or does it have a tiny
additional edge connector that routes REQ#/GNT#/IN
Ben Greear wrote:
I'm having a strange problem. I have an X6DVA motherboard
with dual 2.8Ghz emt-64 processors, 1GB of RAM, SATA HD, etc.
I tried kernel 2.6.11 which uses irq 26, and 2.6.10-1.770_FC2smp, which
maps the irq to 209 or something like that. Distribution is FC2, x86.
Kernel is compil
I'm having a strange problem. I have an X6DVA motherboard
with dual 2.8Ghz emt-64 processors, 1GB of RAM, SATA HD, etc.
I have two 4-port e1000 NICs in the system, on a riser card. There
are also 2 built-in e1000s and an e100 in the 32-bit slot of the PCI
riser.
Regardless of which way order I pu
I am experiencing a strange problem.
I am doing a continuous DMA for long hours using a card on my system. In my
code I enable interrupts and clear the interrupts in the interrupt handler
which is called on completion of every DMA cycle. Now, the program works
fine for say 16-20 hours but I think
On Sat, Jun 02, 2001 at 03:41:08AM -0400, Jeff Garzik wrote:
> > No, I'm afraid it doesn't :-(
> >
> Thanks for testing.
>
> Ok, how about this one? This is a more simple version of the logic
> presented, which should give you the value that Manfred asked you plug
> in manually.
>
No go, I'm a
> On Fri, Jun 01, 2001 at 04:42:40PM -0400, Jeff Garzik wrote:
> > Does this patch fix things for you, such that MPS 1.1 and MPS 1.4 both
> > work?
>
> No, I'm afraid it doesn't :-(
>
> Here are the dmesg (with some info cut out for brevity), the
> /proc/interrupts and the lspci -vvvxxx from a 2
On Fri, Jun 01, 2001 at 04:42:40PM -0400, Jeff Garzik wrote:
> Does this patch fix things for you, such that MPS 1.1 and MPS 1.4 both
> work?
No, I'm afraid it doesn't :-(
Here are the dmesg (with some info cut out for brevity), the
/proc/interrupts and the lspci -vvvxxx from a 2.4.5-ac6 kernel
Does this patch fix things for you, such that MPS 1.1 and MPS 1.4 both
work?
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
diff -urN linux-2.4.5/drivers/pci/quirks.c linux.viairq/drivers/pci/quirks.c
--- linux-2.4.5/drivers/pci/quirks.cSat May 19
On Fri, Jun 01, 2001 at 07:28:33PM +0200, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote:
> >
> > :setpci -s 00:07.2 INTERRUPT_LINE=15
> > :lspci -vx -s 00:07.2
> > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00
>[UHCI])
> > Subsystem: Unknown device 0925:1
Manfred Spraul wrote:
> Could you compile uhci as a module, set the configuration to MPS1.4 and
> find out with which interrupt line setting it works.
> I'd try both
>
> setpci -s 00:07.2 INTERRUPT_LINE=13
> setpci -s 00:07.2 INTERRUPT_LINE=3
> [even if 13 works, please try 03 as well. 13 is hexa
[EMAIL PROTECTED] wrote:
>
> :setpci -s 00:07.2 INTERRUPT_LINE=15
> :lspci -vx -s 00:07.2
> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
> Subsystem: Unknown device 0925:1234
> Flags: bus master, medium devsel, latency 32, IRQ 19
> I
On Thu, May 31, 2001 at 11:56:44AM -0700, Greg KH wrote:
> Is the BIOS set to "Plug and Play supported OS" somewhere? If not, try
> enabling it.
>
It wasn't set, but with it set there is no difference.
Greetings,
Jurriaan
--
IF MICROSOFT BUILT CARS..
New seats would force everyone to have
On Fri, Jun 01, 2001 at 01:20:23AM -0400, Jeff Garzik wrote:
> Looking at the diff of "lspci -vvvxxx" between MPS1.1 and MPS1.4 (on the
> same system) may be quite useful... maybe I missed the earlier "lspci
> -vvvxxx", but I only see one here...
Yep, I didn't want to keep sending long messages.
Looking at the diff of "lspci -vvvxxx" between MPS1.1 and MPS1.4 (on the
same system) may be quite useful... maybe I missed the earlier "lspci
-vvvxxx", but I only see one here...
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from th
On Thu, May 31, 2001 at 10:45:17PM +0200, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote:
> >
> > 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00
>[UHCI])
> > Subsystem: Unknown device 0925:1234
> > Flags: bus master, medium devsel, latency 32, IRQ 5
Manfred Spraul wrote:
>
> >
> > I know that with MPS 1.4, the USB controller finds itself at an
> > unshared interrupt 19. I can't reboot at the moment to check.
> >
> lspci -vxxx -s 00:07.0
>
> the APIC sits in the southbridge.
> the low 2 bits of offset 0x58 must be set [route USB IRQ to APIC]
[EMAIL PROTECTED] wrote:
>
> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
> Subsystem: Unknown device 0925:1234
> Flags: bus master, medium devsel, latency 32, IRQ 5
> I/O ports at a000 [size=32]
> Capabilities: [80] Power Ma
On Thu, May 31, 2001 at 10:21:55PM +0200, Manfred Spraul wrote:
> >
> > I know that with MPS 1.4, the USB controller finds itself at an
> > unshared interrupt 19. I can't reboot at the moment to check.
> >
> lspci -vxxx -s 00:07.0
>
> the APIC sits in the southbridge.
> the low 2 bits of offse
>
> I know that with MPS 1.4, the USB controller finds itself at an
> unshared interrupt 19. I can't reboot at the moment to check.
>
lspci -vxxx -s 00:07.0
the APIC sits in the southbridge.
the low 2 bits of offset 0x58 must be set [route USB IRQ to APIC], and
lspci -vx -s 00:07.2
offset 0
On Thu, May 31, 2001 at 09:48:35PM +0200, [EMAIL PROTECTED] wrote:
> On Thu, May 31, 2001 at 11:06:42AM -0700, Greg KH wrote:
> > On Thu, May 31, 2001 at 08:39:08PM +0200, [EMAIL PROTECTED] wrote:
> > > What information would be necessary to debug this?
> >
> > Which kernel version?
> >
> > greg
On Thu, May 31, 2001 at 11:06:42AM -0700, Greg KH wrote:
> On Thu, May 31, 2001 at 08:39:08PM +0200, [EMAIL PROTECTED] wrote:
> > What information would be necessary to debug this?
>
> Which kernel version?
>
> greg k-h
>
2.4.5-ac4, but I rebooted in 2.4.4 and it did the same.
I'll try and add
On Thu, May 31, 2001 at 08:39:08PM +0200, [EMAIL PROTECTED] wrote:
> What information would be necessary to debug this?
Which kernel version?
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
Hardware:
Abit VP6 (Via 694x) x86/SMP motherboard
with USB controller
If I set the bios for MPS 1.1, USB runs fine. If I set the bios
for MPS 1.4, I get this:
May 31 13:08:06 middle kernel: hub.c: USB new device connect on bus1/1, assigned
device number 4
May 31 13:08:09 middle kernel: usb_con
Can anyone shed some light on this?
I get "lost interrupt" or "timeout waiting for DMA" (and a subsequent
reset) when reading software RAID0 (striped) partitions using IDE drives,
iff I enable any of the following:
% hdparm -c1 /dev/hda /dev/hdc (enable 32-bit I/O)
% hdparm -m16
42 matches
Mail list logo
