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 xen (IRQ7 is on
> >> pin07
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 xen (IRQ7 is on
>> pin07 on APIC )
>>
>> using kernel argument : apic=debug
>>
>> bare
On 3/6/2024 15:31, Marek Marczykowski-Górecki wrote:
On Wed, Mar 06, 2024 at 02:37:20PM -0600, Mario Limonciello wrote:
On 3/6/2024 14:34, Sébastien Chaumat wrote:
Le mer. 6 mars 2024 à 19:51, Mario Limonciello
mailto:mario.limoncie...@amd.com>> a écrit :
On 3/6/2024 12:49, Sébastien
On Wed, Mar 06, 2024 at 02:37:20PM -0600, Mario Limonciello wrote:
> On 3/6/2024 14:34, Sébastien Chaumat wrote:
> >
> >
> > Le mer. 6 mars 2024 à 19:51, Mario Limonciello
> > mailto:mario.limoncie...@amd.com>> a écrit :
> >
> > On 3/6/2024 12:49, Sébastien Chaumat wrote:
> > >
> >
On 3/6/2024 14:34, Sébastien Chaumat wrote:
Le mer. 6 mars 2024 à 19:51, Mario Limonciello
mailto:mario.limoncie...@amd.com>> a écrit :
On 3/6/2024 12:49, Sébastien Chaumat wrote:
>
>
> Le mer. 6 mars 2024 à 19:08, Mario Limonciello
>
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 :
> >
> > On 3/6/2024 12:05, Sébastien Chaumat wrote:
> > >
> > >
> >
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 :
On 3/6/2024 12:05, Sébastien Chaumat wrote:
>
>
> Le mer. 6 mars 2024 à 18:33, Mario Limonciello
>
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 :
> >
> > On 3/6/2024 11:28, Sébastien Chaumat wrote:
> > >
> > >
> >
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 :
On 3/6/2024 11:28, Sébastien Chaumat wrote:
>
>
>
>
> Reasoning backward (using a kernel without the pinctrl_amd
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) :
> > checking the diff in IOAPIC between bare metal
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) :
checking the diff in IOAPIC between bare metal and xen (IRQ7 is
on pin07 on APIC )
using kernel argument : apic=debug
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 kernel/irq/manage.c
>>
>>
>> int
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/manage.c
>
>
> int
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/manage.c
int __irq_set_trigger(struct irq_desc *desc, unsigned long flags)
{
struct irq_chip *chip =
On 1/22/2024 11:06, Sébastien Chaumat wrote:
Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
mailto:mario.limoncie...@amd.com>> 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
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 :
> >>
> >>>
> >>> output of gpioinfo
>
> kernel alone :
>
>
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 :
output of gpioinfo
kernel alone :
line 5: unnamed input active-low consumer=interrupt
line 84: unnamed
On 16.01.2024 16:52, Sébastien Chaumat wrote:
> 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
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
>>
>> xen:
>>
>> line 5: unnamed
> 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 0 0 1268
>> > 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
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 0 0 1268
> > 0 0 0 0 0 0 0
> >
On 21.12.2023 21:41, Sébastien Chaumat wrote:
> 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
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 dmesg"
> >
> > So the problem looks to be that
On 21.12.2023 14:29, Juergen Gross wrote:
> 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 dmesg"
>>
>> So the problem looks to be that pci_xen_initial_domain()
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 dmesg"
So the problem looks to be that pci_xen_initial_domain() results in
permanent setup of IRQ7, when there only
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 dmesg"
So the problem looks to be that pci_xen_initial_domain() results in
permanent setup of IRQ7, when there only "static" ACPI tables (in
particular source
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 dmesg"
So only a single setup_gsi then, after all. Or else I must be missing
something. And there it's all consistent as well: Level/low like for any
other pin
On 20.12.2023 01:23, Sébastien Chaumat wrote:
> I had to triple check:
>
> The first call is from xen_register_pirq() and seem to originate from
> early_irq_init() : triggering is 1
> in this first call the HYPERVISOR_physdev_ops is called with triggering 1
> shareable 0
>
> The second call is
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 déc. 2023 à 20:03, 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, Sébastien Chaumat a
>>> écrit :
>>> >
>>> > I did add an
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_setup_gsi
>> > so the "first one" is my printk
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 second message is from xen_register_gsi (from
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 à 14:15, Jan Beulich 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 à 14:15, Jan Beulich a écrit :
>
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
> > On 05.12.2023
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-APIC7-fasteoi pinctrl_amd
> IR-IO-APIC9-fasteoi
On 19.12.2023 14:15, Jan Beulich wrote:
> On 18.12.2023 17:21, Sébastien Chaumat wrote:
>> 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 )
On 18.12.2023 17:21, Sébastien Chaumat wrote:
> 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
On 18.12.2023 18:04, Sébastien Chaumat wrote:
> 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
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:
>> >>> This issue seems that IRQ 7 (the GPIO controller) is natively
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 type) while in xen it is mapped to oapic-edge
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 type) while in xen it is mapped to oapic-edge instead of
>>> oapic-level
>>> as the SSDT indicates :
>>>
>>>
> >>> 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-APIC7-fasteoi
> > 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:
> > [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up
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:
> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
Is it expected that IRQ7 goes from fasteoi (kernel
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 (kernel 6.6.4 ) to
> > > ioapic-edge and IRQ9 to
> 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-APIC7-fasteoi pinctrl_amd
> > IR-IO-APIC
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-APIC7-fasteoi pinctrl_amd
> IR-IO-APIC9-fasteoi
> [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.
>
Thanks for your help so far.
I moved
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.
Jan
> [1.997798] i2c_designware AMDI0010:00: using ACPI '\_SB.I2CA' for
> 'scl' GPIO lookup
> [
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 by IRQ/GSI mapping ?
Any direction on how I can enhance 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 by IRQ/GSI mapping ? Any way to test this
hypothesis?
Thanks
Le mar. 5 déc. 2023 à
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 to get the Framework Laptop 13 AMD to work with QubesOS I hit the
>>> following Xen issue :
>>>
>>> Xen version :
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
>
+ tested with 4.18.0
> > Kernel :
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
> Kernel : 6.5.12-300.fc39.x86_64
> CPU model name : AMD Ryzen 7 7840U w/ Radeon 780M Graphics
>
> The touchpad
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
62 matches
Mail list logo
