[Regression] Blank screen with hang on boot with 5.10.x
With 5.10.x, My AMD RX580 based system hang with a blank screen on boot: no SSH access possible. There are no issues with 5.9.x. I submitted a bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=210867
Re: [PATCH] dell-laptop: add parameter to disable the backlight device.
I code, therefore I am On Sun, 12/8/13, Alex Davis wrote: Subject: Re: [PATCH] dell-laptop: add parameter to disable the backlight device. To: "mj...@srcf.ucam.org" , "linux-kernel@vger.kernel.org" , "Levente Kurusa" Date: Sunday, December 8, 2013, 3:38 PM On Sun, 12/8/13, Levente Kurusa wrote: > Subject: Re: [PATCH] dell-laptop: add parameter to disable the backlight device. > To: "Alex Davis" , "mj...@srcf.ucam.org" , >"linux->ker...@vger.kernel.org" > Date: Sunday, December 8, 2013, 9:06 AM >>2013-12-08 14:40, Alex Davis: >> I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop module is loaded, >> two backlight device devices are created; dell_backlight, and intel_backlight from the Intel >> graphics driver. The dell_backlight device is non-functional, but the graphics subsystem uses >> it instead of the functioning intel_backlight device. The result is that, when running KDE, >> screen brightness cannot be controlled. I've added a module parameter, disable_backlight >> which, when true, will disable the dell_backlight device, and leave only the intel_backlight: >> with this, screen brightness can be controlled. >> > Hi, >I think it would be better if we could figure out why the >dell_blacklight device is not working rather than disabling >it. > Regarding your patch, it creates a memory leak as you: > * allocate a platform device > * you add it > * you allocated a page for SMI > > Your if(disable_blacklight) code should go > where it checks the DMI. > > -- Regards, > Levente Kurusa Levante, >You are correct. The existing code also has a memory leak. I >will submit a patch for that. Upon further investigation, I'm not seeing the memory leak. I see the objects being allocated, but they are deallocated in the dell_exit method. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dell-laptop: add parameter to disable the backlight device.
On Sun, 12/8/13, Levente Kurusa wrote: > Subject: Re: [PATCH] dell-laptop: add parameter to disable the backlight > device. > To: "Alex Davis" , "mj...@srcf.ucam.org" > , >"linux->ker...@vger.kernel.org" > > Date: Sunday, December 8, 2013, 9:06 AM >>2013-12-08 14:40, Alex Davis: >> I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop module is loaded, >> two backlight device devices are created; dell_backlight, and intel_backlight from the Intel >> graphics driver. The dell_backlight device is non-functional, but the graphics subsystem uses >> it instead of the functioning intel_backlight device. The result is that, when running KDE, >> screen brightness cannot be controlled. I've added a module parameter, disable_backlight >> which, when true, will disable the dell_backlight device, and leave only the intel_backlight: >> with this, screen brightness can be controlled. >> > Hi, >I think it would be better if we could figure out why the >dell_blacklight device is not working rather than disabling >it. > Regarding your patch, it creates a memory leak as you: > * allocate a platform device > * you add it > * you allocated a page for SMI > > Your if(disable_blacklight) code should go > where it checks the DMI. > > -- Regards, > Levente Kurusa Levante, You are correct. The existing code also has a memory leak. I will submit a patch for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dell-laptop: add parameter to disable the backlight device.
I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop
module is loaded,
two backlight device devices are created; dell_backlight, and intel_backlight
from the Intel
graphics driver. The dell_backlight device is non-functional, but the graphics
subsystem uses
it instead of the functioning intel_backlight device. The result is that, when
running KDE,
screen brightness cannot be controlled. I've added a module parameter,
disable_backlight
which, when true, will disable the dell_backlight device, and leave only the
intel_backlight:
with this, screen brightness can be controlled.
This patch is against 3.10.
Signed-off-by: Alex Davis
--- dell-laptop.c.orig 2013-12-01 19:05:39.693149050 -0500
+++ dell-laptop.c 2013-12-01 17:29:27.613372482 -0500
@@ -35,6 +35,9 @@
/* This structure will be modified by the firmware when we enter
* system management mode, hence the volatiles */
+static bool disable_backlight;
+module_param(disable_backlight, bool, 0644);
+
struct calling_interface_buffer {
u16 class;
u16 select;
@@ -561,6 +564,9 @@ static int __init dell_init(void)
dell_laptop_dir = debugfs_create_dir("dell_laptop", NULL);
+ if (disable_backlight)
+ return 0;
+
#ifdef CONFIG_ACPI
/* In the event of an ACPI backlight being available, don't
* register the platform controller.
I code, therefore I am
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dell-laptop: add parameter to disable the backlight device.
I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop
module is loaded,
two backlight device devices are created; dell_backlight, and intel_backlight
from the Intel
graphics driver. The dell_backlight device is non-functional, but the graphics
subsystem uses
it instead of the functioning intel_backlight device. The result is that, when
running KDE,
screen brightness cannot be controlled. I've added a module parameter,
disable_backlight
which, when true, will disable the dell_backlight device, and leave only the
intel_backlight:
with this, screen brightness can be controlled.
This patch is against 3.10.
Signed-off-by: Alex Davis alex14...@yahoo.com
--- dell-laptop.c.orig 2013-12-01 19:05:39.693149050 -0500
+++ dell-laptop.c 2013-12-01 17:29:27.613372482 -0500
@@ -35,6 +35,9 @@
/* This structure will be modified by the firmware when we enter
* system management mode, hence the volatiles */
+static bool disable_backlight;
+module_param(disable_backlight, bool, 0644);
+
struct calling_interface_buffer {
u16 class;
u16 select;
@@ -561,6 +564,9 @@ static int __init dell_init(void)
dell_laptop_dir = debugfs_create_dir(dell_laptop, NULL);
+ if (disable_backlight)
+ return 0;
+
#ifdef CONFIG_ACPI
/* In the event of an ACPI backlight being available, don't
* register the platform controller.
I code, therefore I am
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dell-laptop: add parameter to disable the backlight device.
On Sun, 12/8/13, Levente Kurusa le...@linux.com wrote: Subject: Re: [PATCH] dell-laptop: add parameter to disable the backlight device. To: Alex Davis alex14...@yahoo.com, mj...@srcf.ucam.org mj...@srcf.ucam.org, linux-ker...@vger.kernel.org linux-kernel@vger.kernel.org Date: Sunday, December 8, 2013, 9:06 AM 2013-12-08 14:40, Alex Davis: I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop module is loaded, two backlight device devices are created; dell_backlight, and intel_backlight from the Intel graphics driver. The dell_backlight device is non-functional, but the graphics subsystem uses it instead of the functioning intel_backlight device. The result is that, when running KDE, screen brightness cannot be controlled. I've added a module parameter, disable_backlight which, when true, will disable the dell_backlight device, and leave only the intel_backlight: with this, screen brightness can be controlled. Hi, I think it would be better if we could figure out why the dell_blacklight device is not working rather than disabling it. Regarding your patch, it creates a memory leak as you: * allocate a platform device * you add it * you allocated a page for SMI Your if(disable_blacklight) code should go where it checks the DMI. -- Regards, Levente Kurusa Levante, You are correct. The existing code also has a memory leak. I will submit a patch for that. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dell-laptop: add parameter to disable the backlight device.
I code, therefore I am On Sun, 12/8/13, Alex Davis alex14...@yahoo.com wrote: Subject: Re: [PATCH] dell-laptop: add parameter to disable the backlight device. To: mj...@srcf.ucam.org mj...@srcf.ucam.org, linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org, Levente Kurusa le...@linux.com Date: Sunday, December 8, 2013, 3:38 PM On Sun, 12/8/13, Levente Kurusa le...@linux.com wrote: Subject: Re: [PATCH] dell-laptop: add parameter to disable the backlight device. To: Alex Davis alex14...@yahoo.com, mj...@srcf.ucam.org mj...@srcf.ucam.org, linux-ker...@vger.kernel.org linux-kernel@vger.kernel.org Date: Sunday, December 8, 2013, 9:06 AM 2013-12-08 14:40, Alex Davis: I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop module is loaded, two backlight device devices are created; dell_backlight, and intel_backlight from the Intel graphics driver. The dell_backlight device is non-functional, but the graphics subsystem uses it instead of the functioning intel_backlight device. The result is that, when running KDE, screen brightness cannot be controlled. I've added a module parameter, disable_backlight which, when true, will disable the dell_backlight device, and leave only the intel_backlight: with this, screen brightness can be controlled. Hi, I think it would be better if we could figure out why the dell_blacklight device is not working rather than disabling it. Regarding your patch, it creates a memory leak as you: * allocate a platform device * you add it * you allocated a page for SMI Your if(disable_blacklight) code should go where it checks the DMI. -- Regards, Levente Kurusa Levante, You are correct. The existing code also has a memory leak. I will submit a patch for that. Upon further investigation, I'm not seeing the memory leak. I see the objects being allocated, but they are deallocated in the dell_exit method. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] dell_laptop: add disable_backlight module parameter
>On Sunday, December 1, 2013 8:43 PM, Alex Davis wrote: >I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop >module is >loaded, >two backlight device devices are created; dell_backlight, and intel_backlight >from the >Intel >graphics driver. The dell_backlight device is non-functional, but the graphics >subsystem >uses >it instead of the functioning intel_backlight device. The result is that, when >running >KDE, >screen dimming does not work. I've added a module parameter, >disable_backlight, which when >true will disable the dell_backlight device, and leave only the >intel_backlight: with >this, >screen dimming works. > >Signed-off-by: Alex Davis This patch is against 3.10. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] dell_laptop: add disable_backlight module parameter
On Sunday, December 1, 2013 8:43 PM, Alex Davis alex14...@yahoo.com wrote: I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop module is loaded, two backlight device devices are created; dell_backlight, and intel_backlight from the Intel graphics driver. The dell_backlight device is non-functional, but the graphics subsystem uses it instead of the functioning intel_backlight device. The result is that, when running KDE, screen dimming does not work. I've added a module parameter, disable_backlight, which when true will disable the dell_backlight device, and leave only the intel_backlight: with this, screen dimming works. Signed-off-by: Alex Davis alex14...@yahoo.com This patch is against 3.10. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] dell_laptop: add disable_backlight module parameter
I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop
module is loaded,
two backlight device devices are created; dell_backlight, and intel_backlight
from the Intel
graphics driver. The dell_backlight device is non-functional, but the graphics
subsystem uses
it instead of the functioning intel_backlight device. The result is that, when
running KDE,
screen dimming does not work. I've added a module parameter, disable_backlight,
which when
true will disable the dell_backlight device, and leave only the
intel_backlight: with this,
screen dimming works.
Signed-off-by: Alex Davis
--- dell-laptop.c.orig 2013-12-01 19:05:39.693149050 -0500
+++ dell-laptop.c 2013-12-01 17:29:27.613372482 -0500
@@ -35,6 +35,9 @@
/* This structure will be modified by the firmware when we enter
* system management mode, hence the volatiles */
+static bool disable_backlight;
+module_param(disable_backlight, bool, 0644);
+
struct calling_interface_buffer {
u16 class;
u16 select;
@@ -561,6 +564,9 @@ static int __init dell_init(void)
dell_laptop_dir = debugfs_create_dir("dell_laptop", NULL);
+ if (disable_backlight)
+ return 0;
+
#ifdef CONFIG_ACPI
/* In the event of an ACPI backlight being available, don't
* register the platform controller.
I code, therefore I am
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] dell_laptop: add disable_backlight module parameter
I have a Dell Inspiron N7010 Laptop with Intel graphics. When the dell-laptop
module is loaded,
two backlight device devices are created; dell_backlight, and intel_backlight
from the Intel
graphics driver. The dell_backlight device is non-functional, but the graphics
subsystem uses
it instead of the functioning intel_backlight device. The result is that, when
running KDE,
screen dimming does not work. I've added a module parameter, disable_backlight,
which when
true will disable the dell_backlight device, and leave only the
intel_backlight: with this,
screen dimming works.
Signed-off-by: Alex Davis alex14...@yahoo.com
--- dell-laptop.c.orig 2013-12-01 19:05:39.693149050 -0500
+++ dell-laptop.c 2013-12-01 17:29:27.613372482 -0500
@@ -35,6 +35,9 @@
/* This structure will be modified by the firmware when we enter
* system management mode, hence the volatiles */
+static bool disable_backlight;
+module_param(disable_backlight, bool, 0644);
+
struct calling_interface_buffer {
u16 class;
u16 select;
@@ -561,6 +564,9 @@ static int __init dell_init(void)
dell_laptop_dir = debugfs_create_dir(dell_laptop, NULL);
+ if (disable_backlight)
+ return 0;
+
#ifdef CONFIG_ACPI
/* In the event of an ACPI backlight being available, don't
* register the platform controller.
I code, therefore I am
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Oops in 2.6.22.5
I get the following Oops after 2 or so weeks of uptime: Sep 14 04:40:16 polyergus kernel: [1664412.773070] BUG: unable to handle kernel paging request at virtual address b6ea34d0 Sep 14 04:40:16 polyergus kernel: [1664412.773077] printing eip: Sep 14 04:40:16 polyergus kernel: [1664412.773079] c0167310 Sep 14 04:40:16 polyergus kernel: [1664412.773081] *pde = Sep 14 04:40:16 polyergus kernel: [1664412.773083] Oops: [#1] Sep 14 04:40:16 polyergus kernel: [1664412.773085] Modules linked in: isofs zlib_inflate nfs udf snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_rtctimer snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq radeon drm raid456 xor md_mod sata_promise snd_pcm_oss snd_mixer_oss nfsd exportfs lockd sunrpc usb_storage uhci_hcd psmouse parport_pc parport rtc nvidia_agp i2c_nforce2 i2c_core ohci_hcd ehci_hcd forcedeth generic pata_amd ata_generic libata snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore 3c59x agpgart Sep 14 04:40:16 polyergus kernel: [1664412.773113] CPU:0 Sep 14 04:40:16 polyergus kernel: [1664412.773114] EIP:0060:[] Not tainted VLI Sep 14 04:40:16 polyergus kernel: [1664412.773115] EFLAGS: 00010282 (2.6.22.5 #1) Sep 14 04:40:16 polyergus kernel: [1664412.773121] EIP is at find_inode_fast+0x10/0x60 Sep 14 04:40:16 polyergus kernel: [1664412.773123] eax: f58fc2d0 ebx: 001ac056 ecx: b6ea34d0 edx: b6ea34d0 Sep 14 04:40:16 polyergus kernel: [1664412.773126] esi: f7919600 edi: c189195c ebp: ea197c0c esp: d08b1da4 Sep 14 04:40:16 polyergus kernel: [1664412.773129] ds: 007b es: 007b fs: gs: 0033 ss: 0068 Sep 14 04:40:16 polyergus kernel: [1664412.773132] Process updatedb (pid: 23900, ti=d08b task=c4cd9590 task.ti=d08b) Sep 14 04:40:16 polyergus kernel: [1664412.773134] Stack: 001ac056 f7919600 c189195c c016770a 001ac056 f7919600 c01678db Sep 14 04:40:16 polyergus kernel: [1664412.773139]d4addf60 ea197ba4 f7919600 c01ac8f3 c02cf8e0 d4addf60 ea197ba4 c015ba4b Sep 14 04:40:16 polyergus kernel: [1664412.773144]d08b1f00 d08b1e40 d08b1e38 d08b1f00 d08b1e40 c015bcdb 5bf011a0 Sep 14 04:40:16 polyergus kernel: [1664412.773149] Call Trace: Sep 14 04:40:16 polyergus kernel: [1664412.773153] [] ifind_fast+0xa/0x50 Sep 14 04:40:16 polyergus kernel: [1664412.773157] [] iget_locked+0x2b/0x60 Sep 14 04:40:16 polyergus kernel: [1664412.773161] [] ext2_lookup+0x63/0xa0 Sep 14 04:40:16 polyergus kernel: [1664412.773168] [] real_lookup+0xbb/0x120 Sep 14 04:40:16 polyergus kernel: [1664412.773174] [] do_lookup+0x9b/0xd0 Sep 14 04:40:16 polyergus kernel: [1664412.773179] [] __link_path_walk+0x680/0xbc0 Sep 14 04:40:16 polyergus kernel: [1664412.773188] [] link_path_walk+0x3c/0xb0 Sep 14 04:40:16 polyergus kernel: [1664412.773200] [] do_path_lookup+0xb0/0x170 Sep 14 04:40:16 polyergus kernel: [1664412.773205] [] __user_walk_fd+0x3b/0x60 Sep 14 04:40:16 polyergus kernel: [1664412.773210] [] vfs_lstat_fd+0x1f/0x70 Sep 14 04:40:16 polyergus kernel: [1664412.773224] [] sys_lstat64+0xf/0x30 Sep 14 04:40:16 polyergus kernel: [1664412.773235] [] syscall_call+0x7/0xb Sep 14 04:40:16 polyergus kernel: [1664412.773245] === Sep 14 04:40:16 polyergus kernel: [1664412.773247] Code: 00 eb b6 85 db 89 d8 75 cd 89 f6 eb c7 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 57 89 d7 56 89 c6 53 89 cb 8b 0f 85 c9 74 14 90 <8b> 11 0f 18 02 90 39 59 20 89 c8 74 13 89 d1 85 c9 75 ed 5b 5e Sep 14 04:40:16 polyergus kernel: [1664412.773265] EIP: [] find_inode_fast+0x10/0x60 SS:ESP 0068:d08b1da4 I was also getting it in 2.6.20.14. It always happens in updatedb. The only ext2 filesystem is on the root disk, which is connected to the built-in IDE controller. Here is the .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.5 # Sat Aug 25 21:34:42 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY
Oops in 2.6.22.5
I get the following Oops after 2 or so weeks of uptime: Sep 14 04:40:16 polyergus kernel: [1664412.773070] BUG: unable to handle kernel paging request at virtual address b6ea34d0 Sep 14 04:40:16 polyergus kernel: [1664412.773077] printing eip: Sep 14 04:40:16 polyergus kernel: [1664412.773079] c0167310 Sep 14 04:40:16 polyergus kernel: [1664412.773081] *pde = Sep 14 04:40:16 polyergus kernel: [1664412.773083] Oops: [#1] Sep 14 04:40:16 polyergus kernel: [1664412.773085] Modules linked in: isofs zlib_inflate nfs udf snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_rtctimer snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq radeon drm raid456 xor md_mod sata_promise snd_pcm_oss snd_mixer_oss nfsd exportfs lockd sunrpc usb_storage uhci_hcd psmouse parport_pc parport rtc nvidia_agp i2c_nforce2 i2c_core ohci_hcd ehci_hcd forcedeth generic pata_amd ata_generic libata snd_emu10k1 snd_rawmidi firmware_class snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore 3c59x agpgart Sep 14 04:40:16 polyergus kernel: [1664412.773113] CPU:0 Sep 14 04:40:16 polyergus kernel: [1664412.773114] EIP:0060:[c0167310] Not tainted VLI Sep 14 04:40:16 polyergus kernel: [1664412.773115] EFLAGS: 00010282 (2.6.22.5 #1) Sep 14 04:40:16 polyergus kernel: [1664412.773121] EIP is at find_inode_fast+0x10/0x60 Sep 14 04:40:16 polyergus kernel: [1664412.773123] eax: f58fc2d0 ebx: 001ac056 ecx: b6ea34d0 edx: b6ea34d0 Sep 14 04:40:16 polyergus kernel: [1664412.773126] esi: f7919600 edi: c189195c ebp: ea197c0c esp: d08b1da4 Sep 14 04:40:16 polyergus kernel: [1664412.773129] ds: 007b es: 007b fs: gs: 0033 ss: 0068 Sep 14 04:40:16 polyergus kernel: [1664412.773132] Process updatedb (pid: 23900, ti=d08b task=c4cd9590 task.ti=d08b) Sep 14 04:40:16 polyergus kernel: [1664412.773134] Stack: 001ac056 f7919600 c189195c c016770a 001ac056 f7919600 c01678db Sep 14 04:40:16 polyergus kernel: [1664412.773139]d4addf60 ea197ba4 f7919600 c01ac8f3 c02cf8e0 d4addf60 ea197ba4 c015ba4b Sep 14 04:40:16 polyergus kernel: [1664412.773144]d08b1f00 d08b1e40 d08b1e38 d08b1f00 d08b1e40 c015bcdb 5bf011a0 Sep 14 04:40:16 polyergus kernel: [1664412.773149] Call Trace: Sep 14 04:40:16 polyergus kernel: [1664412.773153] [c016770a] ifind_fast+0xa/0x50 Sep 14 04:40:16 polyergus kernel: [1664412.773157] [c01678db] iget_locked+0x2b/0x60 Sep 14 04:40:16 polyergus kernel: [1664412.773161] [c01ac8f3] ext2_lookup+0x63/0xa0 Sep 14 04:40:16 polyergus kernel: [1664412.773168] [c015ba4b] real_lookup+0xbb/0x120 Sep 14 04:40:16 polyergus kernel: [1664412.773174] [c015bcdb] do_lookup+0x9b/0xd0 Sep 14 04:40:16 polyergus kernel: [1664412.773179] [c015c390] __link_path_walk+0x680/0xbc0 Sep 14 04:40:16 polyergus kernel: [1664412.773188] [c015c90c] link_path_walk+0x3c/0xb0 Sep 14 04:40:16 polyergus kernel: [1664412.773200] [c015cbc0] do_path_lookup+0xb0/0x170 Sep 14 04:40:16 polyergus kernel: [1664412.773205] [c015d0eb] __user_walk_fd+0x3b/0x60 Sep 14 04:40:16 polyergus kernel: [1664412.773210] [c0157c8f] vfs_lstat_fd+0x1f/0x70 Sep 14 04:40:16 polyergus kernel: [1664412.773224] [c015837f] sys_lstat64+0xf/0x30 Sep 14 04:40:16 polyergus kernel: [1664412.773235] [c01028fe] syscall_call+0x7/0xb Sep 14 04:40:16 polyergus kernel: [1664412.773245] === Sep 14 04:40:16 polyergus kernel: [1664412.773247] Code: 00 eb b6 85 db 89 d8 75 cd 89 f6 eb c7 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 57 89 d7 56 89 c6 53 89 cb 8b 0f 85 c9 74 14 90 8b 11 0f 18 02 90 39 59 20 89 c8 74 13 89 d1 85 c9 75 ed 5b 5e Sep 14 04:40:16 polyergus kernel: [1664412.773265] EIP: [c0167310] find_inode_fast+0x10/0x60 SS:ESP 0068:d08b1da4 I was also getting it in 2.6.20.14. It always happens in updatedb. The only ext2 filesystem is on the root disk, which is connected to the built-in IDE controller. Here is the .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.5 # Sat Aug 25 21:34:42 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT
Re: Problem of USB - error 71 : how configure kernel to dongle with chipset
As you are using ndiswrapper, you won't much if any help from the kernel developers. ndiswrapper taints the kernel as it links closed-source drivers into kernel space. I strongly advise you to post this question on the ndiswrapper mailing list. Good luck. -Alex > Hi ! > I'm trying to use a dongle with ndiswrapper, but it fails because a > problem of usb. Indeed, when I put on first the dongle, a lsusb give : > Bus 001 Device 002: ID 0457:0163 Silicon Integrated Systems Corps. > Bus 001 Device 001: ID : > But, 10 to 30 seconds later, the dongle is not recognize with an error -71. > lsusb give : > Bus 001 Device 001: ID : > How can I configure the kernel to have the good configuration ? I tried > different ways, but it fails. > > Thanks for help, > Thibaud. I code, therefore I am TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem of USB - error 71 : how configure kernel to dongle with chipset
As you are using ndiswrapper, you won't much if any help from the kernel developers. ndiswrapper taints the kernel as it links closed-source drivers into kernel space. I strongly advise you to post this question on the ndiswrapper mailing list. Good luck. -Alex Hi ! I'm trying to use a dongle with ndiswrapper, but it fails because a problem of usb. Indeed, when I put on first the dongle, a lsusb give : Bus 001 Device 002: ID 0457:0163 Silicon Integrated Systems Corps. Bus 001 Device 001: ID : But, 10 to 30 seconds later, the dongle is not recognize with an error -71. lsusb give : Bus 001 Device 001: ID : How can I configure the kernel to have the good configuration ? I tried different ways, but it fails. Thanks for help, Thibaud. I code, therefore I am TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
--- Bill Davidsen <[EMAIL PROTECTED]> wrote: > Alex Davis wrote: > >>Please don't tell me to "care for closed-source drivers". > > > > ndiswrapper is NOT closed source. And I'm not asking you to "care". > > > > > >>I don't want the pain of debugging crashes on the machines which run > >>unknown code > >>in kernel space. > > > > I'm not asking you to debug crashes. I'm simply requesting that the > > kernel stack size situation remain as it is: with 8K as the default > > and 4K configurable. > > I can be happy with 4K as the default, everything I use *except* > ndiswrapper seems to run fine (I don't currently need fancy filesystems) > but laptops seem to include a lot of unsupported hardware, which can't > be replaced due to resources (money, slots, batter life). > -- I could live with any default, as long as it's configurable. The intent here, however, is to take away the option. That's what I have an issue with. Is there any problem caused by letting stack size be configurable to any (sane) arbitrary maximum value (e.g. 32K)? > -bill davidsen ([EMAIL PROTECTED]) > "The secret to procrastination is to put things off until the > last possible moment - but no longer" -me > I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
--- Bill Davidsen [EMAIL PROTECTED] wrote: Alex Davis wrote: Please don't tell me to care for closed-source drivers. ndiswrapper is NOT closed source. And I'm not asking you to care. I don't want the pain of debugging crashes on the machines which run unknown code in kernel space. I'm not asking you to debug crashes. I'm simply requesting that the kernel stack size situation remain as it is: with 8K as the default and 4K configurable. I can be happy with 4K as the default, everything I use *except* ndiswrapper seems to run fine (I don't currently need fancy filesystems) but laptops seem to include a lot of unsupported hardware, which can't be replaced due to resources (money, slots, batter life). -- I could live with any default, as long as it's configurable. The intent here, however, is to take away the option. That's what I have an issue with. Is there any problem caused by letting stack size be configurable to any (sane) arbitrary maximum value (e.g. 32K)? -bill davidsen ([EMAIL PROTECTED]) The secret to procrastination is to put things off until the last possible moment - but no longer -me I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean <[EMAIL PROTECTED]> wrote: > On Sun, September 4, 2005 11:41 pm, Alex Davis said: > > > It will never be 'appropriate' if the system doesn't somehow work on Joe's > > hardware. We currently have something that works. In my opinion it's > > pointless to take that away. The manufacturers will still stone-wall us > > regardless of ndiswrapper's existence. They were doing it before ndis- > > wrapper existed. > > There are lots and lots of systems where Linux works. Encouraging users > to buy hardware that works with Linux, can only help. Encouraging them > that it doesn't matter and that binary-only drivers are a good > alternative, can only hurt. > > > Please explain how Linux can be an 'important force' if people can't > > use it? Wireless networking is very important to people. > > Lots of people can and do use Linux without ANY binary drivers. There > are Wireless choices that don't require binary only drivers. What if you don't have a choice? When someone comes to me with their laptop containing a built-in wireless card not natively supported by Linux, am I supposed to tell them "go buy a Linux-supported card" when there's a way I can make their existing card work? I don't think so. > > Um, ever hear of 'compromise'?? All I'm saying is let people use what > > currently works until we can get an open-source solution. Ndiswrapper's > > existence is not stopping you (or anyone else) from pestering > > manufacturers > > for spec's and writing drivers. I look at ndiswrapper as a stop-gap > > solution. > > Hey, even Linus himself has said 'better a sub-optimal solution than no > > solution'. > > Nobody is stopping anyone from using what "currently works", there will be > lots of like minded people to provide crap kernels and shitty binary > drivers to people who don't know better. > So don't worry, your well > intentioned vision of the future will survive the removal of 8K stacks > from the kernel. > Regards, > Sean > > > I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean <[EMAIL PROTECTED]> wrote: > On Sun, September 4, 2005 10:29 pm, Alex Davis said: > > > Linux isn't just used by kernel developers. It's that attitude that > > helps insure Linux will always have a small userbase. Lack of numbers > > just gives the manufacturers another reason not to care about us. Joe > > User doesn't care about our philosophical issues, nor should he. When > > I install Linux on someone's machine, he wants it to work NOW, not in > > some 'perfect-world' future. > > Alex, > > > Please stop the hand wringing over not being able to convince Joe User to > install Linux today. It will happen naturally when it's appropriate, It will never be 'appropriate' if the system doesn't somehow work on Joe's hardware. We currently have something that works. In my opinion it's pointless to take that away. The manufacturers will still stone-wall us regardless of ndiswrapper's existence. They were doing it before ndis- wrapper existed. > Linux is steadily growing in power and acceptance without binary drivers. > Trying to artificially speed up the process by destroying the very thing > that makes Linux an important force is actually counterproductive. Please explain how Linux can be an 'important force' if people can't use it? Wireless networking is very important to people. > It's not a philosophical issue, it's what Linux _is_: an open source > operating system! That's what the developers are working on; not your > half-baked vision. Um, ever hear of 'compromise'?? All I'm saying is let people use what currently works until we can get an open-source solution. Ndiswrapper's existence is not stopping you (or anyone else) from pestering manufacturers for spec's and writing drivers. I look at ndiswrapper as a stop-gap solution. Hey, even Linus himself has said 'better a sub-optimal solution than no solution'. > If you want to create some bastardized version and are > willing to commit dollars and effort to maintaining the code needed to do > so, feel free. > > Regards, > Sean > > > I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean <[EMAIL PROTECTED]> wrote: > On Sun, September 4, 2005 10:00 pm, Alex Davis said: > > Dave Jones wrote: > >>- NDISwrapper / driverloader. > >> (Shock, horror - no-one cares). > > > > Shock, horror. Someone DOES care: everyone who uses ndiswrapper or > > driverloader, whether they know it or not. Are you proposing that > > we punish the end-users because of the obstinence of the hardware > > manufacturers? If/when native drivers are written, maybe we can > > revisit this. > > > Continuing the promotion of binary-only drivers _hurts_ the demand for > (and thus the development of) open source drivers. Read the comment from > Dave as something like "Nobody who matters, with regard to kernel > development, cares about NDISwrapper". If _you_ care, fork your own tree > and maintain the patch as necessary. > > Regards, > Sean Sean: Linux isn't just used by kernel developers. It's that attitude that helps insure Linux will always have a small userbase. Lack of numbers just gives the manufacturers another reason not to care about us. Joe User doesn't care about our philosophical issues, nor should he. When I install Linux on someone's machine, he wants it to work NOW, not in some 'perfect-world' future. -Alex -Alex > I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
Dave Jones wrote: >- NDISwrapper / driverloader. > (Shock, horror - no-one cares). Shock, horror. Someone DOES care: everyone who uses ndiswrapper or driverloader, whether they know it or not. Are you proposing that we punish the end-users because of the obstinence of the hardware manufacturers? If/when native drivers are written, maybe we can revisit this. I code, therefore I am __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
>The NdisWrapper FAQ already tells you that you need a patch for some of >the binary-only Windows drivers that require more than 8kB stacks. > >And the fact that NdisWrapper is mostly working hinders the development >of open source drivers for this hardware. If the hardware manufacturer won't give you the spec's then writing a driver is going to be pretty difficult, if not impossible. Reverse-engineering may be possible, but still I believe it's the lack of spec's, rather than the existence of ndiswrapper and driverloader, that hinder driver development. -Alex I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
>Please don't tell me to "care for closed-source drivers". ndiswrapper is NOT closed source. And I'm not asking you to "care". >I don't want the pain of debugging crashes on the machines which run unknown >code >in kernel space. I'm not asking you to debug crashes. I'm simply requesting that the kernel stack size situation remain as it is: with 8K as the default and 4K configurable. >vda I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
Please don't tell me to care for closed-source drivers. ndiswrapper is NOT closed source. And I'm not asking you to care. I don't want the pain of debugging crashes on the machines which run unknown code in kernel space. I'm not asking you to debug crashes. I'm simply requesting that the kernel stack size situation remain as it is: with 8K as the default and 4K configurable. vda I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
The NdisWrapper FAQ already tells you that you need a patch for some of the binary-only Windows drivers that require more than 8kB stacks. And the fact that NdisWrapper is mostly working hinders the development of open source drivers for this hardware. If the hardware manufacturer won't give you the spec's then writing a driver is going to be pretty difficult, if not impossible. Reverse-engineering may be possible, but still I believe it's the lack of spec's, rather than the existence of ndiswrapper and driverloader, that hinder driver development. -Alex I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
Dave Jones wrote: - NDISwrapper / driverloader. (Shock, horror - no-one cares). Shock, horror. Someone DOES care: everyone who uses ndiswrapper or driverloader, whether they know it or not. Are you proposing that we punish the end-users because of the obstinence of the hardware manufacturers? If/when native drivers are written, maybe we can revisit this. I code, therefore I am __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean [EMAIL PROTECTED] wrote: On Sun, September 4, 2005 10:00 pm, Alex Davis said: Dave Jones wrote: - NDISwrapper / driverloader. (Shock, horror - no-one cares). Shock, horror. Someone DOES care: everyone who uses ndiswrapper or driverloader, whether they know it or not. Are you proposing that we punish the end-users because of the obstinence of the hardware manufacturers? If/when native drivers are written, maybe we can revisit this. Continuing the promotion of binary-only drivers _hurts_ the demand for (and thus the development of) open source drivers. Read the comment from Dave as something like Nobody who matters, with regard to kernel development, cares about NDISwrapper. If _you_ care, fork your own tree and maintain the patch as necessary. Regards, Sean Sean: Linux isn't just used by kernel developers. It's that attitude that helps insure Linux will always have a small userbase. Lack of numbers just gives the manufacturers another reason not to care about us. Joe User doesn't care about our philosophical issues, nor should he. When I install Linux on someone's machine, he wants it to work NOW, not in some 'perfect-world' future. -Alex -Alex I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean [EMAIL PROTECTED] wrote: On Sun, September 4, 2005 10:29 pm, Alex Davis said: Linux isn't just used by kernel developers. It's that attitude that helps insure Linux will always have a small userbase. Lack of numbers just gives the manufacturers another reason not to care about us. Joe User doesn't care about our philosophical issues, nor should he. When I install Linux on someone's machine, he wants it to work NOW, not in some 'perfect-world' future. Alex, Please stop the hand wringing over not being able to convince Joe User to install Linux today. It will happen naturally when it's appropriate, It will never be 'appropriate' if the system doesn't somehow work on Joe's hardware. We currently have something that works. In my opinion it's pointless to take that away. The manufacturers will still stone-wall us regardless of ndiswrapper's existence. They were doing it before ndis- wrapper existed. Linux is steadily growing in power and acceptance without binary drivers. Trying to artificially speed up the process by destroying the very thing that makes Linux an important force is actually counterproductive. Please explain how Linux can be an 'important force' if people can't use it? Wireless networking is very important to people. It's not a philosophical issue, it's what Linux _is_: an open source operating system! That's what the developers are working on; not your half-baked vision. Um, ever hear of 'compromise'?? All I'm saying is let people use what currently works until we can get an open-source solution. Ndiswrapper's existence is not stopping you (or anyone else) from pestering manufacturers for spec's and writing drivers. I look at ndiswrapper as a stop-gap solution. Hey, even Linus himself has said 'better a sub-optimal solution than no solution'. If you want to create some bastardized version and are willing to commit dollars and effort to maintaining the code needed to do so, feel free. Regards, Sean I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean [EMAIL PROTECTED] wrote: On Sun, September 4, 2005 11:41 pm, Alex Davis said: It will never be 'appropriate' if the system doesn't somehow work on Joe's hardware. We currently have something that works. In my opinion it's pointless to take that away. The manufacturers will still stone-wall us regardless of ndiswrapper's existence. They were doing it before ndis- wrapper existed. There are lots and lots of systems where Linux works. Encouraging users to buy hardware that works with Linux, can only help. Encouraging them that it doesn't matter and that binary-only drivers are a good alternative, can only hurt. Please explain how Linux can be an 'important force' if people can't use it? Wireless networking is very important to people. Lots of people can and do use Linux without ANY binary drivers. There are Wireless choices that don't require binary only drivers. What if you don't have a choice? When someone comes to me with their laptop containing a built-in wireless card not natively supported by Linux, am I supposed to tell them go buy a Linux-supported card when there's a way I can make their existing card work? I don't think so. Um, ever hear of 'compromise'?? All I'm saying is let people use what currently works until we can get an open-source solution. Ndiswrapper's existence is not stopping you (or anyone else) from pestering manufacturers for spec's and writing drivers. I look at ndiswrapper as a stop-gap solution. Hey, even Linus himself has said 'better a sub-optimal solution than no solution'. Nobody is stopping anyone from using what currently works, there will be lots of like minded people to provide crap kernels and shitty binary drivers to people who don't know better. So don't worry, your well intentioned vision of the future will survive the removal of 8K stacks from the kernel. Regards, Sean I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFC: i386: kill !4KSTACKS
ndiswrapper and driverloader will not work reliably with 4k stacks. This is because of the Windoze drivers they use, to which, obviously, they do not have the source. Since quite a few laptops have built-in wireless cards by companies who will not release an open-source driver, or won't release specs, ndiswrapper and driverloader are the only way to get these cards to work. Please don't tell me to "get a linux-supported wireless card". I don't want the clutter of an external wireless adapter sticking out of my laptop, nor do I want to spend money on a card when I have a free and working solution. Thank you. -Alex I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: RFC: i386: kill !4KSTACKS
ndiswrapper and driverloader will not work reliably with 4k stacks. This is because of the Windoze drivers they use, to which, obviously, they do not have the source. Since quite a few laptops have built-in wireless cards by companies who will not release an open-source driver, or won't release specs, ndiswrapper and driverloader are the only way to get these cards to work. Please don't tell me to get a linux-supported wireless card. I don't want the clutter of an external wireless adapter sticking out of my laptop, nor do I want to spend money on a card when I have a free and working solution. Thank you. -Alex I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pty is losing bytes
Problem does not exist on 2.6.8.1. Compiling your program and running ./a.out < README | diff README - produces no output. I tested various files ranging in size from 10 to 60k. -Alex = I code, therefore I am __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pty is losing bytes
Problem does not exist on 2.6.8.1. Compiling your program and running ./a.out README | diff README - produces no output. I tested various files ranging in size from 10 to 60k. -Alex = I code, therefore I am __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for file fs/partitions/check.c
[EMAIL PROTECTED] wrote:
>
> > Are you the person I send the patch to?
>
> Send it to [EMAIL PROTECTED] and to [EMAIL PROTECTED] .
>
> Andries
Here's my patch to perform a media-change check and, if necessary,
a disk revalidate whenever /proc/partitions is accessed.
--- check.c.saveWed Feb 21 17:50:54 2001
+++ check.c Wed Feb 21 19:49:20 2001
@@ -9,6 +9,10 @@
* contained.
*
* Added needed MAJORS for new pairs, {hdi,hdj}, {hdk,hdl}
+ *
+ * Alex Davis <[EMAIL PROTECTED]>
+ * Added code to keep /proc/partitions in sync with
+ * removable media.
*/
#include
@@ -242,11 +246,25 @@
int get_partition_list(char *page, char **start, off_t offset, int
count)
{
struct gendisk *dsk;
+ kdev_t dev;
int len;
len = sprintf(page, "major minor #blocks name\n\n");
for (dsk = gendisk_head; dsk; dsk = dsk->next) {
int n;
+ int i;
+
+ if ( dsk->fops->check_media_change &&
+dsk->fops->revalidate ) {
+ for ( i = 0; i < dsk->nr_real; ++i ) {
+ dev = MKDEV(dsk->major, i << dsk->minor_shift);
+ if ( dsk->flags[i] & GENHD_FL_REMOVABLE &&
+dsk->fops->check_media_change(dev) ) {
+//printk(KERN_INFO "revalidating drive %d:%d\n", dsk->major, i);
+ dsk->fops->revalidate(dev);
+ }
+ }
+ }
for (n = 0; n < (dsk->nr_real << dsk->minor_shift); n++)
if (dsk->part[n].nr_sects) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for file fs/partitions/check.c
[EMAIL PROTECTED] wrote:
Are you the person I send the patch to?
Send it to [EMAIL PROTECTED] and to [EMAIL PROTECTED] .
Andries
Here's my patch to perform a media-change check and, if necessary,
a disk revalidate whenever /proc/partitions is accessed.
--- check.c.saveWed Feb 21 17:50:54 2001
+++ check.c Wed Feb 21 19:49:20 2001
@@ -9,6 +9,10 @@
* contained.
*
* Added needed MAJORS for new pairs, {hdi,hdj}, {hdk,hdl}
+ *
+ * Alex Davis [EMAIL PROTECTED]
+ * Added code to keep /proc/partitions in sync with
+ * removable media.
*/
#include linux/config.h
@@ -242,11 +246,25 @@
int get_partition_list(char *page, char **start, off_t offset, int
count)
{
struct gendisk *dsk;
+ kdev_t dev;
int len;
len = sprintf(page, "major minor #blocks name\n\n");
for (dsk = gendisk_head; dsk; dsk = dsk-next) {
int n;
+ int i;
+
+ if ( dsk-fops-check_media_change
+dsk-fops-revalidate ) {
+ for ( i = 0; i dsk-nr_real; ++i ) {
+ dev = MKDEV(dsk-major, i dsk-minor_shift);
+ if ( dsk-flags[i] GENHD_FL_REMOVABLE
+dsk-fops-check_media_change(dev) ) {
+//printk(KERN_INFO "revalidating drive %d:%d\n", dsk-major, i);
+ dsk-fops-revalidate(dev);
+ }
+ }
+ }
for (n = 0; n (dsk-nr_real dsk-minor_shift); n++)
if (dsk-part[n].nr_sects) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
