Le jeu. 7 mars 2024, 09:39, Jan Beulich a écrit :
> On 06.03.2024 18:28, Sébastien Chaumat wrote:
> > Reasoning backward (using a kernel without the pinctrl_amd driver to
> >> ensure xen only is at stake) :
> >> checking the diff in IOAPIC between bare metal and
Le mer. 6 mars 2024 à 19:51, Mario Limonciello
a écrit :
> On 3/6/2024 12:49, Sébastien Chaumat wrote:
> >
> >
> > Le mer. 6 mars 2024 à 19:08, Mario Limonciello
> > mailto:mario.limoncie...@amd.com>> a écrit :
> >
> >
Le mer. 6 mars 2024 à 19:08, Mario Limonciello
a écrit :
> On 3/6/2024 12:05, Sébastien Chaumat wrote:
> >
> >
> > Le mer. 6 mars 2024 à 18:33, Mario Limonciello
> > mailto:mario.limoncie...@amd.com>> a écrit :
> >
> >
Le mer. 6 mars 2024 à 18:33, Mario Limonciello
a écrit :
> On 3/6/2024 11:28, Sébastien Chaumat wrote:
> >
> >
> >
> >
> > Reasoning backward (using a kernel without the pinctrl_amd driver
> > to ensure xen only is at stake) :
> > ch
Reasoning backward (using a kernel without the pinctrl_amd driver to
> ensure xen only is at stake) :
> checking the diff in IOAPIC between bare metal and xen (IRQ7 is on
> pin07 on APIC )
>
> using kernel argument : apic=debug
>
> bare metal :
> [0.715330] fedora kernel: ... APIC
Le jeu. 1 févr. 2024 à 13:30, Sébastien Chaumat a
écrit :
> I spotted the following warning for IRQ7 (along with IRQ6 and 10)
>>
>> [0.686073] fedora kernel: __irq_set_trigger: genirq: No set_type
>> function for IRQ 7 (IR-IO-APIC)
>>
>> This comes from
Le jeu. 1 févr. 2024 à 13:30, Sébastien Chaumat a
écrit :
> I spotted the following warning for IRQ7 (along with IRQ6 and 10)
>
> [0.686073] fedora kernel: __irq_set_trigger: genirq: No set_type
> function for IRQ 7 (IR-IO-APIC)
>
> This comes from kernel/irq/
quot;unknown");
return 0;
}
Could this have a role in the IRQ misconfiguration by xen ?
Le lun. 22 janv. 2024 à 21:59, Mario Limonciello
a écrit :
> On 1/22/2024 11:06, Sébastien Chaumat wrote:
> >
> >
> > Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
> > mailto
Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
a écrit :
> On 1/16/2024 10:18, Jan Beulich wrote:
> > On 16.01.2024 16:52, Sébastien Chaumat wrote:
> >> Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat a
> >> écrit :
> >>
> >>>
>
Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat a
écrit :
>
> output of gpioinfo
>>
>> kernel alone :
>>
>> line 5: unnamed input active-low consumer=interrupt
>> line 84: unnamed input active-low consumer=interrupt
>&g
> output of gpioinfo
>
> kernel alone :
>
> line 5: unnamed input active-low consumer=interrupt
> line 84: unnamed input active-low consumer=interrupt
>
> xen:
>
> line 5: unnamed input active-low
> line 84: unnamed input
Le ven. 22 déc. 2023 à 15:37, Sébastien Chaumat a
écrit :
> By request of the laptop vendor (Framework) I'm going to open the bug
> @fedora for them to jump in.
>
>
>> > I noticed that on baremetal :
>> >
>> > 53: 0 0 0
found the following issue with this similar HW setup :
https://marc.info/?l=linux-gpio=150605230614677=2
while in bare metal, I wonder if being in dom0 does not lead to the same
configuration :
Quoting :
---
"Under the I2C-HID spec, the device interrupt is level-triggered. When
the touchpad has
Le ven. 22 déc. 2023 à 15:37, Sébastien Chaumat a
écrit :
> By request of the laptop vendor (Framework) I'm going to open the bug
> @fedora for them to jump in.
>
>
https://bugzilla.redhat.com/show_bug.cgi?id=2255625
Sébastien
x, %02x\n", inb(0x4d0), inb(0x4d1));
> >>>
> >>> in, say, setup_dump_irqs()?
> >>>
> >>
> > did that but I don't know how to trigger the dump.
>
> There's no need to trigger the dump. The message will be logged during
> boot, and he
Le jeu. 21 déc. 2023 à 14:29, Juergen Gross a écrit :
> On 21.12.23 13:40, Jan Beulich wrote:
> > On 20.12.2023 17:34, Sébastien Chaumat wrote:
> >> Here are the patches I made to xen and linux kernel
> >> Plus dmesg (bare metal,xen) and "xl dme
Le mer. 20 déc. 2023 à 00:50, Sébastien Chaumat a
écrit :
>
>
> Le mer. 20 déc. 2023 à 00:11, Sébastien Chaumat a
> écrit :
>
>>
>>
>> Le mer. 20 déc. 2023 à 00:06, Sébastien Chaumat a
>> écrit :
>>
>>>
>>>
>>> Le mar. 19
Le mer. 20 déc. 2023 à 00:11, Sébastien Chaumat a
écrit :
>
>
> Le mer. 20 déc. 2023 à 00:06, Sébastien Chaumat a
> écrit :
>
>>
>>
>> Le mar. 19 déc. 2023 à 20:03, Sébastien Chaumat a
>> écrit :
>>
>>> Le mar. 19 déc. 2023 à 16:15,
Le mer. 20 déc. 2023 à 00:06, Sébastien Chaumat a
écrit :
>
>
> Le mar. 19 déc. 2023 à 20:03, Sébastien Chaumat a
> écrit :
>
>> Le mar. 19 déc. 2023 à 16:15, Sébastien Chaumat a
>> écrit :
>> >
>> > I did add an extra printk in PHYSDEVOP_s
Le mar. 19 déc. 2023 à 20:03, Sébastien Chaumat a
écrit :
> Le mar. 19 déc. 2023 à 16:15, Sébastien Chaumat a
> écrit :
> >
> > I did add an extra printk in PHYSDEVOP_setup_gsi
> > so the "first one" is my printk (available in xl dmesg)
> > the secon
Le mar. 19 déc. 2023 à 16:15, Sébastien Chaumat a écrit :
>
> I did add an extra printk in PHYSDEVOP_setup_gsi
> so the "first one" is my printk (available in xl dmesg)
> the second message is from xen_register_gsi (from linux kernel)
>
> Le mar. 19 déc. 2023 à
I did add an extra printk in PHYSDEVOP_setup_gsi
so the "first one" is my printk (available in xl dmesg)
the second message is from xen_register_gsi (from linux kernel)
Le mar. 19 déc. 2023 à 14:15, Jan Beulich a écrit :
>
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
> >
Le lun. 18 déc. 2023 à 18:04, Sébastien Chaumat a écrit :
>
>
>
> Le lun. 18 déc. 2023, 17:44, Jan Beulich a écrit :
>>
>> On 18.12.2023 17:21, Sébastien Chaumat wrote:
>> >>>>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
>> >>> T
Le lun. 18 déc. 2023, 17:44, Jan Beulich a écrit :
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
> >>>>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
> >>> This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi
> >>> (so level t
> >>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
> >>>>> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
> >>>>
> >>>> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
> >>>> i
> > Information coming from AML is required to be handed down by Dom0 to Xen.
> > May want checking that (a) Dom0 properly does so and (b) Xen doesn't screw
> > up in consuming that data. See PHYSDEVOP_setup_gsi. I wonder if this is
> > specific to it being IRQ7 which GPIO uses, as at the (master)
Le lun. 11 déc. 2023 à 12:27, Jan Beulich a écrit :
>
> On 11.12.2023 12:09, Sébastien Chaumat wrote:
> > Le lun. 11 déc. 2023 à 10:18, Sébastien Chaumat a
> > écrit :
> >>
> >>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
> >>>>> [
Le lun. 11 déc. 2023 à 10:18, Sébastien Chaumat a écrit :
>
> > On 05.12.2023 21:31, Sébastien Chaumat wrote:
> > >> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
> > >
> > > Is it expected that IRQ7 goes from fasteoi (kerne
> On 05.12.2023 21:31, Sébastien Chaumat wrote:
> >> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
> >
> > Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
> > ioapic-edge and IRQ9 to ioapic-level ?
> >
> > IR-IO-APIC
> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
ioapic-edge and IRQ9 to ioapic-level ?
IR-IO-APIC7-fasteoi pinctrl_amd
IR-IO-APIC9-fasteoi acpi
to (xen 4.18.0)
xen-pirq -ioapic-edge
Le mar. 5 déc. 2023 à 15:18, Jan Beulich a écrit :
>
> On 05.12.2023 15:14, Sébastien Chaumat wrote:
> > booting kernel with "dyndbg=file drivers/gpio/* +p"
>
> I'm afraid this doesn't tell me anything. I'm simply not familiar with
> Linux'es GPIO handling.
>
Th
booting kernel with "dyndbg=file drivers/gpio/* +p"
[1.997798] i2c_designware AMDI0010:00: using ACPI '\_SB.I2CA' for
'scl' GPIO lookup
[1.997804] acpi AMDI0010:00: GPIO: looking up scl-gpios
[1.997806] acpi AMDI0010:00: GPIO: looking up scl-gpio
[1.997807] i2c_designware
Le mar. 5 déc. 2023 à 09:50, Sébastien Chaumat a écrit :
>
> Any direction on how I can enchance the debugging at the kernel level ?
>
> There was an old issue with amd_gpio there :
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971597
> Coud the kernel be confused
:17, Jan Beulich a écrit :
> On 04.12.2023 20:17, Sébastien Chaumat wrote:
> > Le lun. 4 déc. 2023 à 10:06, Jan Beulich a écrit :
> >
> >> On 03.12.2023 10:56, Sébastien Chaumat wrote:
> >>> Hello,
> >>>
> >>> Trying t
Le lun. 4 déc. 2023 à 10:06, Jan Beulich a écrit :
> On 03.12.2023 10:56, Sébastien Chaumat wrote:
> > Hello,
> >
> > Trying to get the Framework Laptop 13 AMD to work with QubesOS I hit the
> > following Xen issue :
> >
> > Xen version : 4.17.2
>
+ te
Hello,
Trying to get the Framework Laptop 13 AMD to work with QubesOS I hit the
following Xen issue :
Xen version : 4.17.2
Kernel : 6.5.12-300.fc39.x86_64
CPU model name : AMD Ryzen 7 7840U w/ Radeon 780M Graphics
The touchpad is not working (not detected by evtest) because ( see below
for
36 matches
Mail list logo
