linux-kernel - Re: hpet_late

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200801161404.33519.balajirrao@gmail.com>
Date:	Wed, 16 Jan 2008 14:04:33 +0530
From:	Balaji Rao <balajirrao@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: hpet_late_init hang

On Wednesday 16 January 2008 12:21:33 pm Ingo Molnar wrote:
Hi Ingo,
> * Yinghai Lu <yhlu.kernel@...il.com> wrote:
> > "
> > commit e5ed385fa0d6f35406e3e3ed75e5eb9adeb811df
> > Author: Balaji Rao <balajirrao@...il.com>
> > Date:   Tue Jan 15 16:53:29 2008 +0100
> >
> >     Assign IRQs to HPET Timers
> > "
> > in x86.git
> >
> > cause my servers hang
> > after
> > Calling initcall 0xffffffff80b9a465: hpet_late_init+0x0/0x100()
>
> i'm wondering, where does it hang exactly and why?
>
> > after reverting that I got:
> >
> > initcall 0xffffffff80b947d1 ran for 19 msecs: pci_iommu_init+0x0/0x13()
> > Calling initcall 0xffffffff80b9a465: hpet_late_init+0x0/0x100()
> > hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31
> > hpet0: 3 32-bit timers, 25000000 Hz
> > initcall 0xffffffff80b9a465: hpet_late_init+0x0/0x100() returned 0.
> > initcall 0xffffffff80b9a465 ran for 7 msecs: hpet_late_init+0x0/0x100()
> >
Looks like IRQ 31 is assigned to timer 3, even without the patch! I wonder who wrote the number 31. But the manual says 
that it is zero by default.

I think we should check whether the timer has been allocated an IRQ before proceeding to assign one to it.
Here is a patch that does this.

Yinghai, could you please apply this on top of my patch and check ?

---
Index: linux-2.6/arch/x86/kernel/hpet.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/hpet.c
+++ linux-2.6/arch/x86/kernel/hpet.c
@@ -116,7 +116,8 @@ int is_hpet_enabled(void)
 static void hpet_reserve_platform_timers(unsigned long id)
 {
 	struct hpet __iomem *hpet = hpet_virt_address;
-	unsigned int nrtimers;
+	struct hpet_timer __iomem *timer = &hpet->hpet_timers[2];
+	unsigned int nrtimers, i;
 	struct hpet_data hd;
 
 	nrtimers = ((id & HPET_ID_NUMBER) >> HPET_ID_NUMBER_SHIFT) + 1;
@@ -134,10 +135,9 @@ static void hpet_reserve_platform_timers
 	hd.hd_irq[0] = HPET_LEGACY_8254;
 	hd.hd_irq[1] = HPET_LEGACY_RTC;
 
-	/*
-	 * IRQs for the other timers are assigned dynamically
-	 * in hpet_alloc
-	 */
+       for (i = 2; i < nrtimers; timer++, i++)
+	       hd.hd_irq[i] = (timer->hpet_config & Tn_INT_ROUTE_CNF_MASK) >>
+		       Tn_INT_ROUTE_CNF_SHIFT;
 	hpet_alloc(&hd);
 }
 #else
Index: linux-2.6/drivers/char/hpet.c
===================================================================
--- linux-2.6.orig/drivers/char/hpet.c
+++ linux-2.6/drivers/char/hpet.c
@@ -852,6 +852,12 @@ int hpet_alloc(struct hpet_data *hdp)
 
 		timer = &hpet->hpet_timers[devp - hpetp->hp_dev];
 
+		/* Check if there's already an IRQ assigned to the timer */
+		if (hdp->hd_irq[i]) {
+			hpetp->hp_dev[i].hd_hdwirq = hdp->hd_irq[i];
+			continue;
+		}
+
 		hpet_config = readq(&timer->hpet_config);
 		irq_bitmap = (hpet_config & Tn_INT_ROUTE_CAP_MASK)
 			>> Tn_INT_ROUTE_CAP_SHIFT;

---
regards,
balaji rao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/