On Thu, 8 Sep 2005, Brown, Len wrote:
Just booted a 2.6.13 compiled with UP, ACPI, APIC, LAPIC,
sensor modules
with "nolapic noapic acpi=off".
Huh, I don't see I don't see the processor module checking
for acpi_disabled anyplace...
I assume the oops goes away when you
do not boot with
Hi
Just booted a 2.6.13 compiled with UP, ACPI, APIC, LAPIC, sensor modules
with "nolapic noapic acpi=off". The processor module was still loaded by
the hotplug. On rmmod it Oopsed:
Linux version 2.6.13 ([EMAIL PROTECTED]) (gcc version 3.3.3 (SuSE Linux)) #10
Mon Sep 5 13:25:58 CEST 2005
Hi
Just booted a 2.6.13 compiled with UP, ACPI, APIC, LAPIC, sensor modules
with nolapic noapic acpi=off. The processor module was still loaded by
the hotplug. On rmmod it Oopsed:
Linux version 2.6.13 ([EMAIL PROTECTED]) (gcc version 3.3.3 (SuSE Linux)) #10
Mon Sep 5 13:25:58 CEST 2005
...
On Thu, 8 Sep 2005, Brown, Len wrote:
Just booted a 2.6.13 compiled with UP, ACPI, APIC, LAPIC,
sensor modules
with nolapic noapic acpi=off.
Huh, I don't see I don't see the processor module checking
for acpi_disabled anyplace...
I assume the oops goes away when you
do not boot with
On Tue, 6 Sep 2005, [EMAIL PROTECTED] wrote:
On Tue, 6 Sep 2005, [EMAIL PROTECTED] wrote:
it. So far so good. Now to my actual task - touchscreen... We are using
UR7HCTS2-FG from Semtech. As I cat /dev/input/ts0 and touch the screen,
some
Ok, looks like it is not really supported by the
On Tue, 6 Sep 2005, [EMAIL PROTECTED] wrote:
it. So far so good. Now to my actual task - touchscreen... We are using
UR7HCTS2-FG from Semtech. As I cat /dev/input/ts0 and touch the screen, some
Ok, looks like it is not really supported by the stock kernel... Any
pointers to wild patches? It
On Tue, 6 Sep 2005, Antonino A. Daplas wrote:
There might be a bug with the ioremap patch that got in by the time
linux-2.6.13 was released. The intelfb maintainer is still working on it.
You can try to revert that patch (just make sure that the graphics
aperture in the BIOS is set to <= 128MB)
On Mon, 5 Sep 2005, Matthew Garrett wrote:
Yup. You probably want to take a look at Documentation/fb/vesafb.txt -
the modes are the same.
Great, thanks! I tried VESA 0x111 (Linux 0x311) - it is also what is used
by xfree86 vesa driver, after I've followed the suggestion from Tony
(cc'ed and
On Mon, 5 Sep 2005, Matthew Garrett wrote:
Yup. You probably want to take a look at Documentation/fb/vesafb.txt -
the modes are the same.
Great, thanks! I tried VESA 0x111 (Linux 0x311) - it is also what is used
by xfree86 vesa driver, after I've followed the suggestion from Tony
(cc'ed and
On Tue, 6 Sep 2005, Antonino A. Daplas wrote:
There might be a bug with the ioremap patch that got in by the time
linux-2.6.13 was released. The intelfb maintainer is still working on it.
You can try to revert that patch (just make sure that the graphics
aperture in the BIOS is set to = 128MB)
On Tue, 6 Sep 2005, [EMAIL PROTECTED] wrote:
it. So far so good. Now to my actual task - touchscreen... We are using
UR7HCTS2-FG from Semtech. As I cat /dev/input/ts0 and touch the screen, some
Ok, looks like it is not really supported by the stock kernel... Any
pointers to wild patches? It
On Tue, 6 Sep 2005, [EMAIL PROTECTED] wrote:
On Tue, 6 Sep 2005, [EMAIL PROTECTED] wrote:
it. So far so good. Now to my actual task - touchscreen... We are using
UR7HCTS2-FG from Semtech. As I cat /dev/input/ts0 and touch the screen,
some
Ok, looks like it is not really supported by the
Thanks for the reply, Matthew.
On Mon, 5 Sep 2005, Matthew Garrett wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I am trying to get intelfb running on a system with a 855GM onboard chip,
and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13, line
814:
if
Hi all,
I am trying to get intelfb running on a system with a 855GM onboard chip,
and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13, line
814:
if (FIXED_MODE(dinfo) && ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB) {
ERR_MSG("Video mode must be programmed at
Hi all,
I am trying to get intelfb running on a system with a 855GM onboard chip,
and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13, line
814:
if (FIXED_MODE(dinfo) ORIG_VIDEO_ISVGA != VIDEO_TYPE_VLFB) {
ERR_MSG(Video mode must be programmed at
Thanks for the reply, Matthew.
On Mon, 5 Sep 2005, Matthew Garrett wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I am trying to get intelfb running on a system with a 855GM onboard chip,
and the driver exits at intelfbdrv.c::intelfb_pci_register() (2.6.13, line
814:
if
Hi
This might well be my basic misunderstanding, or the test was wrong, but
the probability is pretty low, so, asking here.
I thought, if a task sleeps on, say, read() and then data come and there's
no other runnable task with a higher priority, the sleeping task should be
woken up immediately.
Hi
This might well be my basic misunderstanding, or the test was wrong, but
the probability is pretty low, so, asking here.
I thought, if a task sleeps on, say, read() and then data come and there's
no other runnable task with a higher priority, the sleeping task should be
woken up immediately.
18 matches
Mail list logo
