[patch] Remove unneeded null tty check in drivers/usb/serial/io_ti.c
The Coverity checker (and Adrian Bunk) spotted an inconsistent
NULL check of port->tty (it's blindly dereferenced later without
the check).
Alan Cox confirmed the check can go.
Signed-off-by: Ray Lee <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
cc: Greg KH <[EMAIL PROTECTED]>
cc: Adrian Bunk <[EMAIL PROTECTED]>
cc: linux-kernel@vger.kernel.org
cc: Alan Cox <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/usb/serial/io_ti.c
===
--- linux-2.6.orig/drivers/usb/serial/io_ti.c 2008-02-22 07:26:47.0
-0800
+++ linux-2.6/drivers/usb/serial/io_ti.c2008-02-22 07:28:12.0
-0800
@@ -1944,8 +1944,7 @@ static int edge_open (struct usb_serial_
if (edge_port == NULL)
return -ENODEV;
- if (port->tty)
- port->tty->low_latency = low_latency;
+ port->tty->low_latency = low_latency;
port_number = port->number - port->serial->minor;
switch (port_number) {
--
--
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/
[patch] Remove unneeded null tty check in drivers/usb/serial/io_ti.c
The Coverity checker (and Adrian Bunk) spotted an inconsistent
NULL check of port-tty (it's blindly dereferenced later without
the check).
Alan Cox confirmed the check can go.
Signed-off-by: Ray Lee [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
cc: Greg KH [EMAIL PROTECTED]
cc: Adrian Bunk [EMAIL PROTECTED]
cc: linux-kernel@vger.kernel.org
cc: Alan Cox [EMAIL PROTECTED]
Index: linux-2.6/drivers/usb/serial/io_ti.c
===
--- linux-2.6.orig/drivers/usb/serial/io_ti.c 2008-02-22 07:26:47.0
-0800
+++ linux-2.6/drivers/usb/serial/io_ti.c2008-02-22 07:28:12.0
-0800
@@ -1944,8 +1944,7 @@ static int edge_open (struct usb_serial_
if (edge_port == NULL)
return -ENODEV;
- if (port-tty)
- port-tty-low_latency = low_latency;
+ port-tty-low_latency = low_latency;
port_number = port-number - port-serial-minor;
switch (port_number) {
--
--
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: Merging of completely unreviewed drivers
On Thu, Feb 21, 2008 at 7:13 PM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> So I'd be happier with warnings about deep indentation (but how do you
> count it? Will people then try to fake things out by using 4-space indents
> and then "deep" indentations will look like just a couple of tabs?)
I suspect that 90% of the cases that people really care about would
get caught successfully just by counting brace depth.
ie, by looking at { { {} {} {{{}{}}} } } I bet you can tell me which
section should have been pulled out into a separate routine.
--
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: Merging of completely unreviewed drivers
On Thu, Feb 21, 2008 at 7:13 PM, Linus Torvalds
[EMAIL PROTECTED] wrote:
So I'd be happier with warnings about deep indentation (but how do you
count it? Will people then try to fake things out by using 4-space indents
and then deep indentations will look like just a couple of tabs?)
I suspect that 90% of the cases that people really care about would
get caught successfully just by counting brace depth.
ie, by looking at { { {} {} {{{}{}}} } } I bet you can tell me which
section should have been pulled out into a separate routine.
--
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] Document huge memory/cache overhead of memory controller in Kconfig
On Wed, Feb 20, 2008 at 7:20 AM, Balbir Singh <[EMAIL PROTECTED]> wrote: > John Stoffel wrote: > > I know this is a pedantic comment, but why the heck is it called such > > a generic term as "Memory Controller" which doesn't give any > > indication of what it does. > > > > Shouldn't it be something like "Memory Quota Controller", or "Memory > > Limits Controller"? > > > > It's called the memory controller since it controls the amount of memory > that a > user can allocate (via limits). The generic term for any resource manager > plugged into cgroups is a controller. If you look through some of the > references > in the document, we've listed our plans to support other categories of > memory as > well. Hence it's called a memory controller While logical, the term is too generic. Memory [Allocation] Governor might be closer. Memory Quota Controller actually matches the already established terminology (quotas). Regardless, Andi's point remains: At minimum, the kconfig text needs to be clear for distributors and end-users as to why they'd want to enable this, or what reasons would cause them to not enable it. -- 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] Document huge memory/cache overhead of memory controller in Kconfig
On Wed, Feb 20, 2008 at 7:20 AM, Balbir Singh [EMAIL PROTECTED] wrote: John Stoffel wrote: I know this is a pedantic comment, but why the heck is it called such a generic term as Memory Controller which doesn't give any indication of what it does. Shouldn't it be something like Memory Quota Controller, or Memory Limits Controller? It's called the memory controller since it controls the amount of memory that a user can allocate (via limits). The generic term for any resource manager plugged into cgroups is a controller. If you look through some of the references in the document, we've listed our plans to support other categories of memory as well. Hence it's called a memory controller While logical, the term is too generic. Memory [Allocation] Governor might be closer. Memory Quota Controller actually matches the already established terminology (quotas). Regardless, Andi's point remains: At minimum, the kconfig text needs to be clear for distributors and end-users as to why they'd want to enable this, or what reasons would cause them to not enable it. -- 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: usb/serial/io_ti.c: inconsequent NULL checking
On Feb 19, 2008 3:25 PM, Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Feb 20, 2008 at 12:49:15AM +0200, Adrian Bunk wrote: > > The Coverity checker spotted the following inconsequent NULL checking > > introduced by commit d5f5bcd425b771c0b7ff5a650b2ce061ac8bbb87: > > > > <-- snip --> > > It's not a real problem, that pointer can't go away. I think he meant inconsistent not "inconsequent." Either the test of port->tty here is unneeded: if (port->tty) port->tty->low_latency = low_latency; ...or the lack of test of port->tty here is a mistake: edge_set_termios (port, port->tty->termios); -- 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: usb/serial/io_ti.c: inconsequent NULL checking
On Feb 19, 2008 3:25 PM, Greg KH [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 12:49:15AM +0200, Adrian Bunk wrote: The Coverity checker spotted the following inconsequent NULL checking introduced by commit d5f5bcd425b771c0b7ff5a650b2ce061ac8bbb87: -- snip -- It's not a real problem, that pointer can't go away. I think he meant inconsistent not inconsequent. Either the test of port-tty here is unneeded: if (port-tty) port-tty-low_latency = low_latency; ...or the lack of test of port-tty here is a mistake: edge_set_termios (port, port-tty-termios); -- 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: 2.6.25-rc1/2 regression: first-time login into gnome fails
On Feb 18, 2008 2:56 AM, Romano Giannetti <[EMAIL PROTECTED]> wrote: > > Hi, > > I have a very strange, but fully reproducible, regression with > 2.6.25-rc1 -rc2. I have an ubuntu 7.10 fully updated. > > The first time after boot, when I login to gnome (through gdm) > the login half-fails with a Setting Daemon error: failed to connect to > socket /tmp/dbus-: connection refused. Nothing in the > logs, and there is no such socket in /tmp. > > If I log out and then log in again, all works ok. > > With 2.6.24.2 there is no such a problem. > > .config, dmesg (2M buffer size) and syslog here: > > http://www.dea.icai.upcomillas.es/romano/linux/info/ > > > Romano > > > (Back to 2.6.24.2, because ndiswrapper broke again, and ath5k doesn't > like (yet) my atheros adapter...) It may be a race. Please try booting up, then waiting for a minute or two once you see the gdm login screen, then try logging in. If that succeeds then something (dbus perhaps) is hanging on something that eventually times out. Ray -- 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: 2.6.25-rc1/2 regression: first-time login into gnome fails
On Feb 18, 2008 2:56 AM, Romano Giannetti [EMAIL PROTECTED] wrote: Hi, I have a very strange, but fully reproducible, regression with 2.6.25-rc1 -rc2. I have an ubuntu 7.10 fully updated. The first time after boot, when I login to gnome (through gdm) the login half-fails with a Setting Daemon error: failed to connect to socket /tmp/dbus-some random stuff: connection refused. Nothing in the logs, and there is no such socket in /tmp. If I log out and then log in again, all works ok. With 2.6.24.2 there is no such a problem. .config, dmesg (2M buffer size) and syslog here: http://www.dea.icai.upcomillas.es/romano/linux/info/ Romano (Back to 2.6.24.2, because ndiswrapper broke again, and ath5k doesn't like (yet) my atheros adapter...) It may be a race. Please try booting up, then waiting for a minute or two once you see the gdm login screen, then try logging in. If that succeeds then something (dbus perhaps) is hanging on something that eventually times out. Ray -- 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] bitmap relative operator for mempolicy extensions
On Thu, Feb 14, 2008 at 8:35 AM, Paul Jackson <[EMAIL PROTECTED]> wrote: > Kosaki-san wrote: > > i prefer another name [!relative]. > > Any suggestions? > > I'll give the name some thought myself. > I like good names, and this is the right > time to get this one right. 'Relative map' implies a constant offset. What you have there is just a map as relmap could be sparse (which, btw, would have been nice to have in the example). map_bitmap violates your naming convention, bitmap_map isn't all that clear, bitmap_remap is taken, and while it is one-to-one and onto, I think calling it bitmap_bijection would lose everyone except the mathematicians. bitmap_onto? bitmap_map_onto? bitmap_map_bitmap_onto? bitmap_read_my_kernel_doc? Minor suggestion: + * and the n-th bit of @relmap is the m-th set bit of @relmap. Perhaps s/is the/is also the/, so that the reader doesn't try to second guess if you accidentally wrote @relmap twice instead of one of them being @orig. -- 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] bitmap relative operator for mempolicy extensions
On Thu, Feb 14, 2008 at 8:35 AM, Paul Jackson [EMAIL PROTECTED] wrote: Kosaki-san wrote: i prefer another name [!relative]. Any suggestions? I'll give the name some thought myself. I like good names, and this is the right time to get this one right. 'Relative map' implies a constant offset. What you have there is just a map as relmap could be sparse (which, btw, would have been nice to have in the example). map_bitmap violates your naming convention, bitmap_map isn't all that clear, bitmap_remap is taken, and while it is one-to-one and onto, I think calling it bitmap_bijection would lose everyone except the mathematicians. bitmap_onto? bitmap_map_onto? bitmap_map_bitmap_onto? bitmap_read_my_kernel_doc? Minor suggestion: + * and the n-th bit of @relmap is the m-th set bit of @relmap. Perhaps s/is the/is also the/, so that the reader doesn't try to second guess if you accidentally wrote @relmap twice instead of one of them being @orig. -- 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: [REGRESSION]fan turns at highspeed after suspend2ram
On Feb 11, 2008 7:56 AM, Mirco Tischler <[EMAIL PROTECTED]> wrote: > On Sunday, 10 of February 2008, Rafaek J. Wysocki wrote: > > > Can you apply the appended patch on top of the current mainline and tetest? > > > > Thanks, > > Rafael > > > > Sorry, that doesn't fix it. > But I'm pretty sure it is related to that commit. Bisecting went > straight forward to it and reverting it fixes the bug. > > @Ray > I'm not sure you have the same problem. After waking up from s2ram, only > my fan runs at highest speed and keeps on, at least for half an hour. > All other acpi-related stuff works as usual. No sign of a stuck > ACPI-system. Yeah, it may just be another bug in this HP laptop. Regardless, Rafael, I'm using a kernel with the patch applied, and fan control after a couple of suspends and resumes is looking fine. But given how inconsistent this laptop is on resume, I may have just had a string of bad luck, and now several good cases in a row, I don't know. I'll run with this for a while and see if anything crops up again. -- 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: [REGRESSION]fan turns at highspeed after suspend2ram
On Feb 11, 2008 7:56 AM, Mirco Tischler [EMAIL PROTECTED] wrote: On Sunday, 10 of February 2008, Rafaek J. Wysocki wrote: Can you apply the appended patch on top of the current mainline and tetest? Thanks, Rafael Sorry, that doesn't fix it. But I'm pretty sure it is related to that commit. Bisecting went straight forward to it and reverting it fixes the bug. @Ray I'm not sure you have the same problem. After waking up from s2ram, only my fan runs at highest speed and keeps on, at least for half an hour. All other acpi-related stuff works as usual. No sign of a stuck ACPI-system. Yeah, it may just be another bug in this HP laptop. Regardless, Rafael, I'm using a kernel with the patch applied, and fan control after a couple of suspends and resumes is looking fine. But given how inconsistent this laptop is on resume, I may have just had a string of bad luck, and now several good cases in a row, I don't know. I'll run with this for a while and see if anything crops up again. -- 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: Linux 2.6.25-rc1 , syntax error near unexpected token `;'
On Feb 10, 2008 5:47 PM, Mr. James W. Laferriere <[EMAIL PROTECTED]> wrote: > Hello All , grabbed using git just moments ago . > > make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install modules_install > > ...snip... > make -f scripts/Makefile.clean obj=sound/usb/usx2y > make -f scripts/Makefile.clean obj=usr >rm -rf .tmp_versions >rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso > arch/x86/boot/mtools.conf > vmlinux System.map .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map > rm -f include/config/kernel.release > echo 2.6.25-rc1 > include/config/kernel.release > set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE > 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + > (c))';) > < /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ > -r > include/linux/version.h ] && cmp -s include/linux/version.h > include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv > -f include/linux/version.h.tmp include/linux/version.h; fi > /bin/sh: -c: line 0: syntax error near unexpected token `;' > /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/;(echo \#define > LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + > ((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile > > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s > include/linux/version.h include/linux/version.h.tmp; then rm -f > include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp > include/linux/version.h; fi' > make: *** [include/linux/version.h] Error 2 > > > # scripts/ver_linux > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux filesrv2 2.6.23-rc9 #1 SMP Wed Oct 3 02:12:33 UTC 2007 i686 pentium4 > i386 GNU/Linux > > Gnu C 3.4.6 > Gnu make 3.81 > binutils 2.15.92.0.2 > util-linux 2.12r > mount 2.12r > module-init-tools 3.2.2 > e2fsprogs 1.38 > jfsutils 1.1.11 > reiserfsprogs 3.6.19 > xfsprogs 2.8.10 > pcmciautils014 > pcmcia-cs 3.2.8 > quota-tools3.13. > PPP2.4.4 > Linux C Library2.3.6 > Dynamic linker (ldd) 2.3.6 > Linux C++ Library 6.0.3 > Procps 3.2.7 > Net-tools 1.60 > Kbd1.12 > oprofile 0.9.1 > Sh-utils 5.97 > udev 097 > Modules Loaded > > -- Please send your .config as well so someone can try to reproduce this. And have you done a make mrproper first before trying to compile? -- 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: [git pull] kgdb light, v5
On Feb 10, 2008 9:39 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Ray Lee wrote:
> > unsigned int void u64_to_hex(u64 val, unsigned char *buf)
> > {
> > int i;
> > for (i=15; i>=0; i--) {
> > buf[i] = hexchars[ val & 0x0f ];
> > val >>= 4;
> > }
> > return 16;
> > }
> > ...
> > buf += u64_to_hex(cpu_to_be64(tmp_ll), buf);
> >
> > be clearer both visually, and code-as-intent? (And equivalent helpers
> > for u32, u16 -- though they could all be rolled into one.)
>
> Yes, will come, I just produced some ETOOMANYCHANGESATONCE issue while
> improving this. The code goes down by more than 150 lines!
Thanks for responding. I'd mentioned it twice already and gotten no
response, so wasn't sure if my microphone was on :-).
If you're feeling energetic, the same sort of cleanup can be done against:
+#ifdef __BIG_ENDIAN
+ tmp_s |= hex(*buf++) << 12;
+ tmp_s |= hex(*buf++) << 8;
+ tmp_s |= hex(*buf++) << 4;
+ tmp_s |= hex(*buf++);
+#else
+ tmp_s |= hex(*buf++) << 4;
+ tmp_s |= hex(*buf++);
+ tmp_s |= hex(*buf++) << 12;
+ tmp_s |= hex(*buf++) << 8;
+#endif
+ if (probe_kernel_write(mem, tmp_s))
+ return ERR_PTR(-EINVAL);
+
+ mem += 2;
+ } else if ((count == 4) && (((long)mem & 3) == 0)) {
+ u32 tmp_l = 0;
+
+#ifdef __BIG_ENDIAN
+ tmp_l |= hex(*buf++) << 28;
+ tmp_l |= hex(*buf++) << 24;
+ tmp_l |= hex(*buf++) << 20;
+ tmp_l |= hex(*buf++) << 16;
+ tmp_l |= hex(*buf++) << 12;
+ tmp_l |= hex(*buf++) << 8;
+ tmp_l |= hex(*buf++) << 4;
+ tmp_l |= hex(*buf++);
+#else
+ tmp_l |= hex(*buf++) << 4;
+ tmp_l |= hex(*buf++);
+ tmp_l |= hex(*buf++) << 12;
+ tmp_l |= hex(*buf++) << 8;
+ tmp_l |= hex(*buf++) << 20;
+ tmp_l |= hex(*buf++) << 16;
+ tmp_l |= hex(*buf++) << 28;
+ tmp_l |= hex(*buf++) << 24;
+#endif
+ if (probe_kernel_write(mem, tmp_l))
+ return ERR_PTR(-EINVAL);
+ mem += 4;
As in, write a helper to parse a hex16, hex32, hex64, then do a
be[16|32|64]_to_cpu, and probe_kernel_write the result.
u64 hex_to_u64(unsigned char *buf)
{
int i;
u64 val = 0;
for (i=0; i<16; i++)
val = val<<4 | hex(buf[i]); /* or *buf++, take your pick */
return val;
}
...
if (probe_kernel_write(mem, be64_to_cpu(hex_to_u64(unsigned char *buf)))
return ERR_PTR(-EINVAL));
mem += 4;
buf += 16;
Or, you know, something like that.
--
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: [REGRESSION]fan turns at highspeed after suspend2ram
On Feb 10, 2008 9:21 AM, Mirco Tischler <[EMAIL PROTECTED]> wrote: > Hi > > I think I found a regression in 2.6.24-git. After waking up from suspend > 2 ram, the fan of my laptop turns constantly at highest speed. It didn't > do this in 2.6.24. > > I bisected it down to this commit: > > commit c95d47a868f35cd47643d116a3c680cdaa954df8 > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > Date: Tue Jan 8 00:05:21 2008 +0100 > > ACPI: Separate invocations of _GTS and _BFS from _PTS and _WAK > > Reverting it resolves the problem for me, but I can't say if this makes > any sense. > > My machine is a Zepto laptop with Intel Santa-Rosa chipset and I'm > running > a x86_64 Ubuntu Gutsy. I just noticed the same problem. After about ten minutes, it seems like all the ACPI events got 'unstuck' -- my screen's backlight went up and down a couple of times (and battery/AC indicator flipped a couple of times) responding to previous power loss and gain events, I think, and the fans dropped down from high speed to low. I was chalking it up to another charming bug on my HP nx6125, but if someone else is seeing it too... I'm on Ubuntu, x86_64, and git as of a couple days ago as well. I haven't tried reverting the patch. -- 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: [git pull] kgdb light, v5
On Feb 10, 2008 8:36 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_64BIT
> + } else if ((count == 8) && (((long)mem & 7) == 0)) {
> + u64 tmp_ll;
> + if (probe_kernel_address(mem, tmp_ll))
> + return ERR_PTR(-EINVAL);
> +
> + mem += 8;
> +#ifdef __BIG_ENDIAN
> + *buf++ = hexchars[(tmp_ll >> 60) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 56) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 52) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 48) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 44) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 40) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 36) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 32) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 28) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 24) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 20) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 16) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 12) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 8) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 4) & 0xf];
> + *buf++ = hexchars[tmp_ll & 0xf];
> +#else
> + *buf++ = hexchars[(tmp_ll >> 4) & 0xf];
> + *buf++ = hexchars[tmp_ll & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 12) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 8) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 20) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 16) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 28) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 24) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 36) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 32) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 44) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 40) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 52) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 48) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 60) & 0xf];
> + *buf++ = hexchars[(tmp_ll >> 56) & 0xf];
> +#endif
Am I missing something? (I'm due, so it's not really a rhetorical
question :-) .) Wouldn't
unsigned int void u64_to_hex(u64 val, unsigned char *buf)
{
int i;
for (i=15; i>=0; i--) {
buf[i] = hexchars[ val & 0x0f ];
val >>= 4;
}
return 16;
}
...
buf += u64_to_hex(cpu_to_be64(tmp_ll), buf);
be clearer both visually, and code-as-intent? (And equivalent helpers
for u32, u16 -- though they could all be rolled into one.)
--
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: [git pull] kgdb light, v5
On Feb 10, 2008 8:36 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_64BIT
+ } else if ((count == 8) (((long)mem 7) == 0)) {
+ u64 tmp_ll;
+ if (probe_kernel_address(mem, tmp_ll))
+ return ERR_PTR(-EINVAL);
+
+ mem += 8;
+#ifdef __BIG_ENDIAN
+ *buf++ = hexchars[(tmp_ll 60) 0xf];
+ *buf++ = hexchars[(tmp_ll 56) 0xf];
+ *buf++ = hexchars[(tmp_ll 52) 0xf];
+ *buf++ = hexchars[(tmp_ll 48) 0xf];
+ *buf++ = hexchars[(tmp_ll 44) 0xf];
+ *buf++ = hexchars[(tmp_ll 40) 0xf];
+ *buf++ = hexchars[(tmp_ll 36) 0xf];
+ *buf++ = hexchars[(tmp_ll 32) 0xf];
+ *buf++ = hexchars[(tmp_ll 28) 0xf];
+ *buf++ = hexchars[(tmp_ll 24) 0xf];
+ *buf++ = hexchars[(tmp_ll 20) 0xf];
+ *buf++ = hexchars[(tmp_ll 16) 0xf];
+ *buf++ = hexchars[(tmp_ll 12) 0xf];
+ *buf++ = hexchars[(tmp_ll 8) 0xf];
+ *buf++ = hexchars[(tmp_ll 4) 0xf];
+ *buf++ = hexchars[tmp_ll 0xf];
+#else
+ *buf++ = hexchars[(tmp_ll 4) 0xf];
+ *buf++ = hexchars[tmp_ll 0xf];
+ *buf++ = hexchars[(tmp_ll 12) 0xf];
+ *buf++ = hexchars[(tmp_ll 8) 0xf];
+ *buf++ = hexchars[(tmp_ll 20) 0xf];
+ *buf++ = hexchars[(tmp_ll 16) 0xf];
+ *buf++ = hexchars[(tmp_ll 28) 0xf];
+ *buf++ = hexchars[(tmp_ll 24) 0xf];
+ *buf++ = hexchars[(tmp_ll 36) 0xf];
+ *buf++ = hexchars[(tmp_ll 32) 0xf];
+ *buf++ = hexchars[(tmp_ll 44) 0xf];
+ *buf++ = hexchars[(tmp_ll 40) 0xf];
+ *buf++ = hexchars[(tmp_ll 52) 0xf];
+ *buf++ = hexchars[(tmp_ll 48) 0xf];
+ *buf++ = hexchars[(tmp_ll 60) 0xf];
+ *buf++ = hexchars[(tmp_ll 56) 0xf];
+#endif
Am I missing something? (I'm due, so it's not really a rhetorical
question :-) .) Wouldn't
unsigned int void u64_to_hex(u64 val, unsigned char *buf)
{
int i;
for (i=15; i=0; i--) {
buf[i] = hexchars[ val 0x0f ];
val = 4;
}
return 16;
}
...
buf += u64_to_hex(cpu_to_be64(tmp_ll), buf);
be clearer both visually, and code-as-intent? (And equivalent helpers
for u32, u16 -- though they could all be rolled into one.)
--
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: [REGRESSION]fan turns at highspeed after suspend2ram
On Feb 10, 2008 9:21 AM, Mirco Tischler [EMAIL PROTECTED] wrote: Hi I think I found a regression in 2.6.24-git. After waking up from suspend 2 ram, the fan of my laptop turns constantly at highest speed. It didn't do this in 2.6.24. I bisected it down to this commit: commit c95d47a868f35cd47643d116a3c680cdaa954df8 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Tue Jan 8 00:05:21 2008 +0100 ACPI: Separate invocations of _GTS and _BFS from _PTS and _WAK Reverting it resolves the problem for me, but I can't say if this makes any sense. My machine is a Zepto laptop with Intel Santa-Rosa chipset and I'm running a x86_64 Ubuntu Gutsy. I just noticed the same problem. After about ten minutes, it seems like all the ACPI events got 'unstuck' -- my screen's backlight went up and down a couple of times (and battery/AC indicator flipped a couple of times) responding to previous power loss and gain events, I think, and the fans dropped down from high speed to low. I was chalking it up to another charming bug on my HP nx6125, but if someone else is seeing it too... I'm on Ubuntu, x86_64, and git as of a couple days ago as well. I haven't tried reverting the patch. -- 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: [git pull] kgdb light, v5
On Feb 10, 2008 9:39 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Ray Lee wrote:
unsigned int void u64_to_hex(u64 val, unsigned char *buf)
{
int i;
for (i=15; i=0; i--) {
buf[i] = hexchars[ val 0x0f ];
val = 4;
}
return 16;
}
...
buf += u64_to_hex(cpu_to_be64(tmp_ll), buf);
be clearer both visually, and code-as-intent? (And equivalent helpers
for u32, u16 -- though they could all be rolled into one.)
Yes, will come, I just produced some ETOOMANYCHANGESATONCE issue while
improving this. The code goes down by more than 150 lines!
Thanks for responding. I'd mentioned it twice already and gotten no
response, so wasn't sure if my microphone was on :-).
If you're feeling energetic, the same sort of cleanup can be done against:
+#ifdef __BIG_ENDIAN
+ tmp_s |= hex(*buf++) 12;
+ tmp_s |= hex(*buf++) 8;
+ tmp_s |= hex(*buf++) 4;
+ tmp_s |= hex(*buf++);
+#else
+ tmp_s |= hex(*buf++) 4;
+ tmp_s |= hex(*buf++);
+ tmp_s |= hex(*buf++) 12;
+ tmp_s |= hex(*buf++) 8;
+#endif
+ if (probe_kernel_write(mem, tmp_s))
+ return ERR_PTR(-EINVAL);
+
+ mem += 2;
+ } else if ((count == 4) (((long)mem 3) == 0)) {
+ u32 tmp_l = 0;
+
+#ifdef __BIG_ENDIAN
+ tmp_l |= hex(*buf++) 28;
+ tmp_l |= hex(*buf++) 24;
+ tmp_l |= hex(*buf++) 20;
+ tmp_l |= hex(*buf++) 16;
+ tmp_l |= hex(*buf++) 12;
+ tmp_l |= hex(*buf++) 8;
+ tmp_l |= hex(*buf++) 4;
+ tmp_l |= hex(*buf++);
+#else
+ tmp_l |= hex(*buf++) 4;
+ tmp_l |= hex(*buf++);
+ tmp_l |= hex(*buf++) 12;
+ tmp_l |= hex(*buf++) 8;
+ tmp_l |= hex(*buf++) 20;
+ tmp_l |= hex(*buf++) 16;
+ tmp_l |= hex(*buf++) 28;
+ tmp_l |= hex(*buf++) 24;
+#endif
+ if (probe_kernel_write(mem, tmp_l))
+ return ERR_PTR(-EINVAL);
+ mem += 4;
As in, write a helper to parse a hex16, hex32, hex64, then do a
be[16|32|64]_to_cpu, and probe_kernel_write the result.
u64 hex_to_u64(unsigned char *buf)
{
int i;
u64 val = 0;
for (i=0; i16; i++)
val = val4 | hex(buf[i]); /* or *buf++, take your pick */
return val;
}
...
if (probe_kernel_write(mem, be64_to_cpu(hex_to_u64(unsigned char *buf)))
return ERR_PTR(-EINVAL));
mem += 4;
buf += 16;
Or, you know, something like that.
--
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: Linux 2.6.25-rc1 , syntax error near unexpected token `;'
On Feb 10, 2008 5:47 PM, Mr. James W. Laferriere [EMAIL PROTECTED] wrote: Hello All , grabbed using git just moments ago . make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install modules_install ...snip... make -f scripts/Makefile.clean obj=sound/usb/usx2y make -f scripts/Makefile.clean obj=usr rm -rf .tmp_versions rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso arch/x86/boot/mtools.conf vmlinux System.map .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map rm -f include/config/kernel.release echo 2.6.25-rc1 include/config/kernel.release set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) 16) + ((b) 8) + (c))';) /usr/src/linux-2.6.25-rc1-git/Makefile include/linux/version.h.tmp; if [ -r include/linux/version.h ] cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp include/linux/version.h; fi /bin/sh: -c: line 0: syntax error near unexpected token `;' /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/;(echo \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) 16) + ((b) 8) + (c))';) /usr/src/linux-2.6.25-rc1-git/Makefile include/linux/version.h.tmp; if [ -r include/linux/version.h ] cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp include/linux/version.h; fi' make: *** [include/linux/version.h] Error 2 # scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux filesrv2 2.6.23-rc9 #1 SMP Wed Oct 3 02:12:33 UTC 2007 i686 pentium4 i386 GNU/Linux Gnu C 3.4.6 Gnu make 3.81 binutils 2.15.92.0.2 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.38 jfsutils 1.1.11 reiserfsprogs 3.6.19 xfsprogs 2.8.10 pcmciautils014 pcmcia-cs 3.2.8 quota-tools3.13. PPP2.4.4 Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Linux C++ Library 6.0.3 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.1 Sh-utils 5.97 udev 097 Modules Loaded -- Please send your .config as well so someone can try to reproduce this. And have you done a make mrproper first before trying to compile? -- 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: Fwd: Re: e1000 1sec latency problem
On Feb 9, 2008 1:51 PM, Kok, Auke <[EMAIL PROTECTED]> wrote: > > Martin Rogge wrote: > > On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: > >> Hi, > >> > >> I am not so familiar with the various mailing lists and missed out on > >> [EMAIL PROTECTED] the first time. Please cc me on any > >> replies. > >> > >> I am looking for help with either making the e1000e driver work on my > >> Thinkpad T60 or fixing the 1s latency issue with e1000. > >> > >> To be honest, I do not understand why the e1000e driver failed to recognize > >> the NIC when I tried. At least, I noticed the correct device ID is defined > >> in drivers/net/e1000e/hw.h: > >> > >> #define E1000_DEV_ID_82573L0x109A > >> > >> Any help is appreciated. > >> > >> Thanks, > >> > >> Martin > >> > >> -- Forwarded Message -- > >> > >> Subject: Re: e1000 1sec latency problem > >> Date: Thursday 07 February 2008 > >> From: Martin Rogge <[EMAIL PROTECTED]> > >> To: linux-kernel@vger.kernel.org > >> > >> Pavel Machek wrote: > >>> Hi! > >>> > >>> I have the famous e1000 latency problems: > >> Hi, I have the same problem with my Thinkpad T60. > >> > >> [EMAIL PROTECTED]:~# ping arnold > >> PING arnold (192.168.158.6) 56(84) bytes of data. > >> 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms > >> > >> --- arnold ping statistics --- > >> 11 packets transmitted, 11 received, 0% packet loss, time ms > >> rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 > >> [EMAIL PROTECTED]:~# uname -a > >> Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) > >> Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux > >> [EMAIL PROTECTED]:~# lspci -vvv > > > > [stuff deleted] > > > >> Unfortunately the e1000e driver is not an option as it will not detect the > >> NIC: > >> > >> from dmesg with e1000 compiled in: > >> Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI > >> Copyright (c) 1999-2006 Intel Corporation. > >> ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 > >> PCI: Setting latency timer of device :02:00.0 to 64 > >> e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) > >> 00:15:58:c3:3a:71 > >> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > >> > >> from dmesg with e1000e compiled in: > >> e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 > >> e1000e: Copyright (c) 1999-2007 Intel Corporation. > >> > >> Any pointers? > >> > >> Thanks, > >> > >> Martin > >> > >> > >> > >> --- > > > > Just for the records, I googled the following solution for the Lenovo T60: > > > > (a) use the e1000 driver > > (b) if compiling as a module, add the following parameter to modprobe.conf: > > options e1000 RxIntDelay=5 > > (c) if compiling a static driver, use the following patch (based on 2.6.24): > > > > --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 > > +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 > > @@ -158,7 +158,7 @@ > > * Valid Range: 0-65535 > > */ > > E1000_PARAM(RxIntDelay, "Receive Interrupt Delay"); > > -#define DEFAULT_RDTR 0 > > +#define DEFAULT_RDTR 5 > > #define MAX_RXDELAY 0x > > #define MIN_RXDELAY0 > > > > After reboot, the average ping time is still factor 10 worse than it should > > be, but it stays below 2 ms (which is a remarkable improvement compared to > > 1000 ms). > > correct, this was a workaround which improved things for most people, but did > not > *fix* it. > > the real fix is to disable L1 ASPM alltogether at the cost of more power > consumption, which is what is in e1000e in 2.6.25-git. e1000e doesn't recognize his NIC. Will you be adding this to the e1000 driver as well? -- 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 1/8] kgdb: core API and gdb protocol handler
2008/2/9 Ray Lee <[EMAIL PROTECTED]>:
> On Feb 9, 2008 9:27 AM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > On Sat, Feb 09, 2008 at 07:35:07AM -0600, [EMAIL PROTECTED] wrote:
> > > +#ifdef __BIG_ENDIAN
> > > + *buf++ = hexchars[(tmp_s >> 12) & 0xf];
> > > + *buf++ = hexchars[(tmp_s >> 8) & 0xf];
> > > + *buf++ = hexchars[(tmp_s >> 4) & 0xf];
> > > + *buf++ = hexchars[tmp_s & 0xf];
> > > +#else
> > > + *buf++ = hexchars[(tmp_s >> 4) & 0xf];
> > > + *buf++ = hexchars[tmp_s & 0xf];
> > > + *buf++ = hexchars[(tmp_s >> 12) & 0xf];
> > > + *buf++ = hexchars[(tmp_s >> 8) & 0xf];
> > > +#endif
> >
> > This is really ugly, but I don't really know a good way around it
> > either.
>
> void u32_to_hex(u32 val, unsigned char *buf)
> {
> int i;
>
> for (i=7; i>=0; i--) {
> buf[i] = hexchars[ val & 0x0f ];
> val >>= 4;
> }
> }
>
> u32_to_hex(tmp_s, buf);
> buf += 8;
>
Sorry, rewrote what I thought I read, not what was there. I guess
you'd want it more along the lines of
void u32_to_hex(u32 x, unsigned char *buf)
{
int i;
int val = cpu_to_be32( x );
for (i=7; ...
--
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 1/8] kgdb: core API and gdb protocol handler
On Feb 9, 2008 9:27 AM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 09, 2008 at 07:35:07AM -0600, [EMAIL PROTECTED] wrote:
> > +#ifdef __BIG_ENDIAN
> > + *buf++ = hexchars[(tmp_s >> 12) & 0xf];
> > + *buf++ = hexchars[(tmp_s >> 8) & 0xf];
> > + *buf++ = hexchars[(tmp_s >> 4) & 0xf];
> > + *buf++ = hexchars[tmp_s & 0xf];
> > +#else
> > + *buf++ = hexchars[(tmp_s >> 4) & 0xf];
> > + *buf++ = hexchars[tmp_s & 0xf];
> > + *buf++ = hexchars[(tmp_s >> 12) & 0xf];
> > + *buf++ = hexchars[(tmp_s >> 8) & 0xf];
> > +#endif
>
> This is really ugly, but I don't really know a good way around it
> either.
void u32_to_hex(u32 val, unsigned char *buf)
{
int i;
for (i=7; i>=0; i--) {
buf[i] = hexchars[ val & 0x0f ];
val >>= 4;
}
}
u32_to_hex(tmp_s, buf);
buf += 8;
--
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 1/8] kgdb: core API and gdb protocol handler
On Feb 9, 2008 9:27 AM, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sat, Feb 09, 2008 at 07:35:07AM -0600, [EMAIL PROTECTED] wrote:
+#ifdef __BIG_ENDIAN
+ *buf++ = hexchars[(tmp_s 12) 0xf];
+ *buf++ = hexchars[(tmp_s 8) 0xf];
+ *buf++ = hexchars[(tmp_s 4) 0xf];
+ *buf++ = hexchars[tmp_s 0xf];
+#else
+ *buf++ = hexchars[(tmp_s 4) 0xf];
+ *buf++ = hexchars[tmp_s 0xf];
+ *buf++ = hexchars[(tmp_s 12) 0xf];
+ *buf++ = hexchars[(tmp_s 8) 0xf];
+#endif
This is really ugly, but I don't really know a good way around it
either.
void u32_to_hex(u32 val, unsigned char *buf)
{
int i;
for (i=7; i=0; i--) {
buf[i] = hexchars[ val 0x0f ];
val = 4;
}
}
u32_to_hex(tmp_s, buf);
buf += 8;
--
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 1/8] kgdb: core API and gdb protocol handler
2008/2/9 Ray Lee [EMAIL PROTECTED]:
On Feb 9, 2008 9:27 AM, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sat, Feb 09, 2008 at 07:35:07AM -0600, [EMAIL PROTECTED] wrote:
+#ifdef __BIG_ENDIAN
+ *buf++ = hexchars[(tmp_s 12) 0xf];
+ *buf++ = hexchars[(tmp_s 8) 0xf];
+ *buf++ = hexchars[(tmp_s 4) 0xf];
+ *buf++ = hexchars[tmp_s 0xf];
+#else
+ *buf++ = hexchars[(tmp_s 4) 0xf];
+ *buf++ = hexchars[tmp_s 0xf];
+ *buf++ = hexchars[(tmp_s 12) 0xf];
+ *buf++ = hexchars[(tmp_s 8) 0xf];
+#endif
This is really ugly, but I don't really know a good way around it
either.
void u32_to_hex(u32 val, unsigned char *buf)
{
int i;
for (i=7; i=0; i--) {
buf[i] = hexchars[ val 0x0f ];
val = 4;
}
}
u32_to_hex(tmp_s, buf);
buf += 8;
Sorry, rewrote what I thought I read, not what was there. I guess
you'd want it more along the lines of
void u32_to_hex(u32 x, unsigned char *buf)
{
int i;
int val = cpu_to_be32( x );
for (i=7; ...
--
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: Fwd: Re: e1000 1sec latency problem
On Feb 9, 2008 1:51 PM, Kok, Auke [EMAIL PROTECTED] wrote: Martin Rogge wrote: On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: Hi, I am not so familiar with the various mailing lists and missed out on [EMAIL PROTECTED] the first time. Please cc me on any replies. I am looking for help with either making the e1000e driver work on my Thinkpad T60 or fixing the 1s latency issue with e1000. To be honest, I do not understand why the e1000e driver failed to recognize the NIC when I tried. At least, I noticed the correct device ID is defined in drivers/net/e1000e/hw.h: #define E1000_DEV_ID_82573L0x109A Any help is appreciated. Thanks, Martin -- Forwarded Message -- Subject: Re: e1000 1sec latency problem Date: Thursday 07 February 2008 From: Martin Rogge [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Pavel Machek wrote: Hi! I have the famous e1000 latency problems: Hi, I have the same problem with my Thinkpad T60. [EMAIL PROTECTED]:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms --- arnold ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 [EMAIL PROTECTED]:~# uname -a Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# lspci -vvv [stuff deleted] Unfortunately the e1000e driver is not an option as it will not detect the NIC: from dmesg with e1000 compiled in: Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 16 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:58:c3:3a:71 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection from dmesg with e1000e compiled in: e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 e1000e: Copyright (c) 1999-2007 Intel Corporation. Any pointers? Thanks, Martin --- Just for the records, I googled the following solution for the Lenovo T60: (a) use the e1000 driver (b) if compiling as a module, add the following parameter to modprobe.conf: options e1000 RxIntDelay=5 (c) if compiling a static driver, use the following patch (based on 2.6.24): --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 @@ -158,7 +158,7 @@ * Valid Range: 0-65535 */ E1000_PARAM(RxIntDelay, Receive Interrupt Delay); -#define DEFAULT_RDTR 0 +#define DEFAULT_RDTR 5 #define MAX_RXDELAY 0x #define MIN_RXDELAY0 After reboot, the average ping time is still factor 10 worse than it should be, but it stays below 2 ms (which is a remarkable improvement compared to 1000 ms). correct, this was a workaround which improved things for most people, but did not *fix* it. the real fix is to disable L1 ASPM alltogether at the cost of more power consumption, which is what is in e1000e in 2.6.25-git. e1000e doesn't recognize his NIC. Will you be adding this to the e1000 driver as well? -- 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: ACPI_WMI: worst config description of all times
On Feb 7, 2008 5:19 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > On Friday 08 February 2008 00:12:24 Ray Lee wrote: > > On Feb 7, 2008 3:51 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > > > On Thursday 07 February 2008 23:33:54 Ray Lee wrote: > > > > Do you have list of hardware/platforms that require this feature to > > > > get the hardware to work? (acer abc123, tcm1100 xyz) > > > > > > I have a very long list of Acer laptops that are supported - which is far > > > too long, and changes on far too much of a regular basis to put in there. > > > > > > Perhaps adding something like "This driver is also a required dependency > > > to build the firmware specific drivers needed for many laptops, including > > > Acer and HP machines"? > > Would this be acceptable then? > > -Carlos > --- > ACPI: WMI: Improve Kconfig entry > > From: Carlos Corbacho <[EMAIL PROTECTED]> > > As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty > non-descriptive. > > Rewrite it so that it explains what ACPI-WMI is, and why anyone > would want to enable it. > > Many thanks to Ray Lee for ideas on this. > > Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> > CC: Pavel Machek <[EMAIL PROTECTED]> > CC: Ray Lee <[EMAIL PROTECTED]> > CC: Len Brown <[EMAIL PROTECTED]> > --- > > drivers/acpi/Kconfig | 19 +++ > 1 files changed, 15 insertions(+), 4 deletions(-) > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index b7fbf16..ea763ef 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -207,11 +207,22 @@ config ACPI_WMI > depends on EXPERIMENTAL > depends on X86 > help > - This driver adds support for the ACPI-WMI mapper device (PNP0C14) > - found on some systems. > + This driver adds support for the ACPI-WMI (Windows Management > + Instrumentation) mapper device (PNP0C14) found on some systems. > > - NOTE: You will need another driver or userspace application on top > of > - this to actually use anything defined in the ACPI-WMI mapper. > + ACPI-WMI is a proprietary extension to ACPI to expose parts of the > + ACPI firmware to userspace - this is done through various vendor > + defined methods and data blocks in a PNP0C14 device, which are then > + made available for userspace to call. > + > + The implementation of this in Linux currently only exposes this to > + other kernel space drivers. > + > + This driver is a required dependency to build the firmware specific > + drivers needed on many machines, including Acer and HP laptops. > + > + It is safe to enable this driver even if your DSDT doesn't define > + any ACPI-WMI devices. > > config ACPI_ASUS > tristate "ASUS/Medion Laptop Extras" > That's clear to me (whereas the original wasn't), though I would still argue for this driver being select'ed by the drivers that require it. As you note, other laptop specific drivers do so, and Linus has come down in favor of that as well in the past, so you have a friend in high places :-). -- 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: ACPI_WMI: worst config description of all times
On Feb 7, 2008 3:51 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > On Thursday 07 February 2008 23:33:54 Ray Lee wrote: > > Do you have list of hardware/platforms that require this feature to > > get the hardware to work? (acer abc123, tcm1100 xyz) > > I have a very long list of Acer laptops that are supported - which is far too > long, and changes on far too much of a regular basis to put in there. > > Perhaps adding something like "This driver is also a required dependency to > build the firmware specific drivers needed for many laptops, including Acer > and HP machines"? > (There's currently another ACPI-WMI based driver in development related to > more HP laptops, and acer-wmi also supports a handful of non-Acer laptops). > > I don't think explaining what WMI is, and how ACPI-WMI is related to it is > that useful in Kconfig here; so I agree that further elaborating on the 'why' > this should be enabled is definitely worth doing. > > > Better, if there are kernel drivers that require this (and currently > > only those drivers), then have those kernel drivers enable ACPI WMI, > > Wouldn't that require 'select' though, and I'm led to believe that's seriously > frowned upon these days? Depends who you talk to. It's certainly the fodder for a yearly flamewar. While I'm not trying to set you up for a firing squad, if you can show that the only use this driver has is as underlying support for Acer/HP xyz drivers, and that those drivers require this one, then that situation really is what select is in there for. Anyone who argues against using select in that case is really just arguing against the mere existence of the kconfig select keyword itself. -- 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: ACPI_WMI: worst config description of all times
On Feb 7, 2008 3:18 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > As for the Kconfig - I'm open to suggestions. While the kconfig text is supposed to say 'what' something is, the more valuable piece of information it provides is *why* one would want to enable it. Do you have list of hardware/platforms that require this feature to get the hardware to work? (acer abc123, tcm1100 xyz) If so, providing that information to the user/distributions is the right first step. Tell them why they want this feature. Better, if there are kernel drivers that require this (and currently only those drivers), then have those kernel drivers enable ACPI WMI, and otherwise leave it off. If/when the userspace accessible bits go in, it can be exposed to the configurator then. Ray -- 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: ACPI_WMI: worst config description of all times
On Feb 7, 2008 3:18 PM, Carlos Corbacho [EMAIL PROTECTED] wrote: As for the Kconfig - I'm open to suggestions. While the kconfig text is supposed to say 'what' something is, the more valuable piece of information it provides is *why* one would want to enable it. Do you have list of hardware/platforms that require this feature to get the hardware to work? (acer abc123, tcm1100 xyz) If so, providing that information to the user/distributions is the right first step. Tell them why they want this feature. Better, if there are kernel drivers that require this (and currently only those drivers), then have those kernel drivers enable ACPI WMI, and otherwise leave it off. If/when the userspace accessible bits go in, it can be exposed to the configurator then. Ray -- 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: ACPI_WMI: worst config description of all times
On Feb 7, 2008 3:51 PM, Carlos Corbacho [EMAIL PROTECTED] wrote: On Thursday 07 February 2008 23:33:54 Ray Lee wrote: Do you have list of hardware/platforms that require this feature to get the hardware to work? (acer abc123, tcm1100 xyz) I have a very long list of Acer laptops that are supported - which is far too long, and changes on far too much of a regular basis to put in there. Perhaps adding something like This driver is also a required dependency to build the firmware specific drivers needed for many laptops, including Acer and HP machines? nod (There's currently another ACPI-WMI based driver in development related to more HP laptops, and acer-wmi also supports a handful of non-Acer laptops). I don't think explaining what WMI is, and how ACPI-WMI is related to it is that useful in Kconfig here; so I agree that further elaborating on the 'why' this should be enabled is definitely worth doing. Better, if there are kernel drivers that require this (and currently only those drivers), then have those kernel drivers enable ACPI WMI, Wouldn't that require 'select' though, and I'm led to believe that's seriously frowned upon these days? Depends who you talk to. It's certainly the fodder for a yearly flamewar. While I'm not trying to set you up for a firing squad, if you can show that the only use this driver has is as underlying support for Acer/HP xyz drivers, and that those drivers require this one, then that situation really is what select is in there for. Anyone who argues against using select in that case is really just arguing against the mere existence of the kconfig select keyword itself. -- 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: ACPI_WMI: worst config description of all times
On Feb 7, 2008 5:19 PM, Carlos Corbacho [EMAIL PROTECTED] wrote: On Friday 08 February 2008 00:12:24 Ray Lee wrote: On Feb 7, 2008 3:51 PM, Carlos Corbacho [EMAIL PROTECTED] wrote: On Thursday 07 February 2008 23:33:54 Ray Lee wrote: Do you have list of hardware/platforms that require this feature to get the hardware to work? (acer abc123, tcm1100 xyz) I have a very long list of Acer laptops that are supported - which is far too long, and changes on far too much of a regular basis to put in there. Perhaps adding something like This driver is also a required dependency to build the firmware specific drivers needed for many laptops, including Acer and HP machines? Would this be acceptable then? -Carlos --- ACPI: WMI: Improve Kconfig entry From: Carlos Corbacho [EMAIL PROTECTED] As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty non-descriptive. Rewrite it so that it explains what ACPI-WMI is, and why anyone would want to enable it. Many thanks to Ray Lee for ideas on this. Signed-off-by: Carlos Corbacho [EMAIL PROTECTED] CC: Pavel Machek [EMAIL PROTECTED] CC: Ray Lee [EMAIL PROTECTED] CC: Len Brown [EMAIL PROTECTED] --- drivers/acpi/Kconfig | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index b7fbf16..ea763ef 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -207,11 +207,22 @@ config ACPI_WMI depends on EXPERIMENTAL depends on X86 help - This driver adds support for the ACPI-WMI mapper device (PNP0C14) - found on some systems. + This driver adds support for the ACPI-WMI (Windows Management + Instrumentation) mapper device (PNP0C14) found on some systems. - NOTE: You will need another driver or userspace application on top of - this to actually use anything defined in the ACPI-WMI mapper. + ACPI-WMI is a proprietary extension to ACPI to expose parts of the + ACPI firmware to userspace - this is done through various vendor + defined methods and data blocks in a PNP0C14 device, which are then + made available for userspace to call. + + The implementation of this in Linux currently only exposes this to + other kernel space drivers. + + This driver is a required dependency to build the firmware specific + drivers needed on many machines, including Acer and HP laptops. + + It is safe to enable this driver even if your DSDT doesn't define + any ACPI-WMI devices. config ACPI_ASUS tristate ASUS/Medion Laptop Extras nod That's clear to me (whereas the original wasn't), though I would still argue for this driver being select'ed by the drivers that require it. As you note, other laptop specific drivers do so, and Linus has come down in favor of that as well in the past, so you have a friend in high places :-). -- 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: how to tell i386 from x86-64 kernel
On Jan 31, 2008 4:42 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > Quiz: on a booted system, how do you tell 32bit from 64bit kernel? Uhm, is this a trick question? What's wrong with uname(2)? -- 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: how to tell i386 from x86-64 kernel
On Jan 31, 2008 4:42 PM, Pavel Machek [EMAIL PROTECTED] wrote: Quiz: on a booted system, how do you tell 32bit from 64bit kernel? Uhm, is this a trick question? What's wrong with uname(2)? -- 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: Unpredictable performance
On Jan 25, 2008 3:32 AM, Asbjorn Sannes <[EMAIL PROTECTED]> wrote: > Hi, > > I am experiencing unpredictable results with the following test > without other processes running (exception is udev, I believe): > cd /usr/src/test > tar -jxf ../linux-2.6.22.12 > cp ../working-config linux-2.6.22.12/.config > cd linux-2.6.22.12 > make oldconfig > time make -j3 > /dev/null # This is what I note down as a "test" result > cd /usr/src ; umount /usr/src/test ; mkfs.ext3 /dev/cc/test > and then reboot > > The kernel is booted with the parameter mem=8192 > > For 2.6.23.14 the results vary from (real time) 33m30.551s to 45m32.703s > (30 runs) > For 2.6.23.14 with nop i/o scheduler from 29m8.827s to 55m36.744s (24 runs) > For 2.6.22.14 also varied a lot.. but, lost results :( > For 2.6.20.21 only vary from 34m32.054s to 38m1.928s (10 runs) > > Any idea of what can cause this? I have tried to make the runs as equal > as possible, rebooting between each run.. i/o scheduler is cfq as default. > > sys and user time only varies a couple of seconds.. and the order of > when it is "fast" and when it is "slow" is completly random, but it > seems that the results are mostly concentrated around the mean. First off, not all tests are good tests. In particular, small timing differences can get magnified horrendously by heading into swap. That said, do you have the means and standard deviations of those runs? That's a good way to tell whether the tests are converging or not, and whether your results are telling you anything. Also as you're on a uniprocessor system, make -j2 is probably going to be faster than make -j3. Perhaps immaterial to whatever you're trying to test, but there you go. -- 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: Unpredictable performance
On Jan 25, 2008 3:32 AM, Asbjorn Sannes [EMAIL PROTECTED] wrote: Hi, I am experiencing unpredictable results with the following test without other processes running (exception is udev, I believe): cd /usr/src/test tar -jxf ../linux-2.6.22.12 cp ../working-config linux-2.6.22.12/.config cd linux-2.6.22.12 make oldconfig time make -j3 /dev/null # This is what I note down as a test result cd /usr/src ; umount /usr/src/test ; mkfs.ext3 /dev/cc/test and then reboot The kernel is booted with the parameter mem=8192 For 2.6.23.14 the results vary from (real time) 33m30.551s to 45m32.703s (30 runs) For 2.6.23.14 with nop i/o scheduler from 29m8.827s to 55m36.744s (24 runs) For 2.6.22.14 also varied a lot.. but, lost results :( For 2.6.20.21 only vary from 34m32.054s to 38m1.928s (10 runs) Any idea of what can cause this? I have tried to make the runs as equal as possible, rebooting between each run.. i/o scheduler is cfq as default. sys and user time only varies a couple of seconds.. and the order of when it is fast and when it is slow is completly random, but it seems that the results are mostly concentrated around the mean. First off, not all tests are good tests. In particular, small timing differences can get magnified horrendously by heading into swap. That said, do you have the means and standard deviations of those runs? That's a good way to tell whether the tests are converging or not, and whether your results are telling you anything. Also as you're on a uniprocessor system, make -j2 is probably going to be faster than make -j3. Perhaps immaterial to whatever you're trying to test, but there you go. -- 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: Massive IDE problems. Who leaves data here?
On Jan 22, 2008 1:04 PM, Manuel Reimer <[EMAIL PROTECTED]> wrote: > Ray Lee wrote: > > (Please always do a reply-to-all for this email list.) > > Currently I don't have a SMTP server configured. As soon as my system is > trustworthy, again, I'll do that. Oy. Just know that without CC:ing people, I'm having to add Jeff back in by hand, and we may not notice your messages. Please, with whatever you're using to send email, CC: people that you want to read your messages, okay? LKML gets a lot of messages, and it's easy to miss some. > > Bad or almost bad power supplies can cause lots of unhappy problems > > such as these. If you have another power supply laying around, it can > > be worth swapping them out. Double-checking that your CPU fan is still > > spinning, and that memtest86+ doesn't show any errors doesn't hurt > > either. > > ... that may be possible... > > I have all PCI slots filled with cards, two big IDE hard drives and one > DVD RAM writer. I already disconnected the DVD drive, as this was nearly > unusable with all those IDE errors. The power supply is (AFAIR) a 200 > watt one. > > But may the power supply cause corrupted data? Shouldn't that crash down > the PC completely? No, not in the least. When power supplies are on the edge and overloaded, the quality of power drops. 12V lines may only supply 11 or less, etc. Some components in your computer will deal with it fine, others won't. In general, if you have weird hardware problems and you're ruled out memory and overheating, the power supply is almost always the next thing to check. -- 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: Massive IDE problems. Who leaves data here?
(Please always do a reply-to-all for this email list.) On Jan 22, 2008 12:40 PM, Manuel Reimer <[EMAIL PROTECTED]> wrote: > Jeff Garzik wrote: > > If your IDE interface is complaining about BadCRC errors, then it's > > complaining about hardware problems (bad cable, etc.) > > The cable already has been replaced three times. I even got sure to > *not* bend the cable. This all doesn't help. > > May a bad cable really cause corrupted data? > > I also have such messages for my cdrom drive (the bad sector messages at > the end of the log for drive hdc). I replaced the 40 pin cable with a > new 80 pin one and still have the errors... Bad or almost bad power supplies can cause lots of unhappy problems such as these. If you have another power supply laying around, it can be worth swapping them out. Double-checking that your CPU fan is still spinning, and that memtest86+ doesn't show any errors doesn't hurt either. -- 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: Massive IDE problems. Who leaves data here?
(Please always do a reply-to-all for this email list.) On Jan 22, 2008 12:40 PM, Manuel Reimer [EMAIL PROTECTED] wrote: Jeff Garzik wrote: If your IDE interface is complaining about BadCRC errors, then it's complaining about hardware problems (bad cable, etc.) The cable already has been replaced three times. I even got sure to *not* bend the cable. This all doesn't help. May a bad cable really cause corrupted data? I also have such messages for my cdrom drive (the bad sector messages at the end of the log for drive hdc). I replaced the 40 pin cable with a new 80 pin one and still have the errors... Bad or almost bad power supplies can cause lots of unhappy problems such as these. If you have another power supply laying around, it can be worth swapping them out. Double-checking that your CPU fan is still spinning, and that memtest86+ doesn't show any errors doesn't hurt either. -- 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: Massive IDE problems. Who leaves data here?
On Jan 22, 2008 1:04 PM, Manuel Reimer [EMAIL PROTECTED] wrote: Ray Lee wrote: (Please always do a reply-to-all for this email list.) Currently I don't have a SMTP server configured. As soon as my system is trustworthy, again, I'll do that. Oy. Just know that without CC:ing people, I'm having to add Jeff back in by hand, and we may not notice your messages. Please, with whatever you're using to send email, CC: people that you want to read your messages, okay? LKML gets a lot of messages, and it's easy to miss some. Bad or almost bad power supplies can cause lots of unhappy problems such as these. If you have another power supply laying around, it can be worth swapping them out. Double-checking that your CPU fan is still spinning, and that memtest86+ doesn't show any errors doesn't hurt either. ... that may be possible... I have all PCI slots filled with cards, two big IDE hard drives and one DVD RAM writer. I already disconnected the DVD drive, as this was nearly unusable with all those IDE errors. The power supply is (AFAIR) a 200 watt one. But may the power supply cause corrupted data? Shouldn't that crash down the PC completely? No, not in the least. When power supplies are on the edge and overloaded, the quality of power drops. 12V lines may only supply 11 or less, etc. Some components in your computer will deal with it fine, others won't. In general, if you have weird hardware problems and you're ruled out memory and overheating, the power supply is almost always the next thing to check. -- 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] x86 reboot: Remove inb_p usage
On Jan 19, 2008 7:44 AM, Alan Cox <[EMAIL PROTECTED]> wrote:
> We are driving a motherboard port so use a 2uS explicit delay at this
> point.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> diff -u --new-file --recursive --exclude-from /usr/src/exclude
> linux.vanilla-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c
> linux-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c
> --- linux.vanilla-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c 2008-01-19
> 14:47:55.0 +
> +++ linux-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c 2008-01-19
> 14:53:58.0 +
> @@ -319,9 +319,11 @@
> {
> int i;
>
> - for (i = 0; i < 0x1; i++)
> - if ((inb_p(0x64) & 0x02) == 0)
> + for (i = 0; i < 0x1; i++) {
> + if ((inb(0x64) & 0x02) == 0)
> break;
> + udelay(2);
> + }
> }
>
> void machine_emergency_restart(void)
Stupid question from the peanut gallery: If you're going to go through
all this, maybe it would be better to define an inline
isa_bus_delay(void) { udelay(2); } and use that instead? I can only
imagine some poor sod coming along later and wondering why there's a
udelay(2) there. OTOH, there is an inb right above it, so .
--
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] x86 reboot: Remove inb_p usage
On Jan 19, 2008 7:44 AM, Alan Cox [EMAIL PROTECTED] wrote:
We are driving a motherboard port so use a 2uS explicit delay at this
point.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c
linux-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c
--- linux.vanilla-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c 2008-01-19
14:47:55.0 +
+++ linux-2.6.24-rc8-mm1/arch/x86/kernel/reboot.c 2008-01-19
14:53:58.0 +
@@ -319,9 +319,11 @@
{
int i;
- for (i = 0; i 0x1; i++)
- if ((inb_p(0x64) 0x02) == 0)
+ for (i = 0; i 0x1; i++) {
+ if ((inb(0x64) 0x02) == 0)
break;
+ udelay(2);
+ }
}
void machine_emergency_restart(void)
Stupid question from the peanut gallery: If you're going to go through
all this, maybe it would be better to define an inline
isa_bus_delay(void) { udelay(2); } and use that instead? I can only
imagine some poor sod coming along later and wondering why there's a
udelay(2) there. OTOH, there is an inb right above it, so shrug.
--
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: Updatedb hangs Kernel 2.6.22.9-cfs-v22
On Jan 14, 2008 7:28 AM, Renato S. Yamane <[EMAIL PROTECTED]> wrote: > Ray Lee escreveu: > > On Jan 12, 2008 10:03 AM, Renato S. Yamane wrote: > >> I can't use updatedb in Debian Etch (stable) using customized Kernel > >> 2.6.22.9-cfs-v22. > >> > >> When I ran updatedb, after ~1 minute my system hangs and "caps lock" LED > >> is blinking. No log is registered. > > > > Please switch out of X11 to a text mode console (CTRL-ALT-F1), and run > > updatedb there. Capture the oops with a digital camera, and post a > > link to the picture (not the picture itself!) to the list. Or, write > > down the oops carefully, and post the text. > > I see a infinite loop and is very fast, so I can't capture errors messages. > None is registered in /var/log/* Well, that's very odd. Please also try the latest CFS backport to see if that solves the problem. Ray -- 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: Updatedb hangs Kernel 2.6.22.9-cfs-v22
On Jan 14, 2008 7:28 AM, Renato S. Yamane [EMAIL PROTECTED] wrote: Ray Lee escreveu: On Jan 12, 2008 10:03 AM, Renato S. Yamane wrote: I can't use updatedb in Debian Etch (stable) using customized Kernel 2.6.22.9-cfs-v22. When I ran updatedb, after ~1 minute my system hangs and caps lock LED is blinking. No log is registered. Please switch out of X11 to a text mode console (CTRL-ALT-F1), and run updatedb there. Capture the oops with a digital camera, and post a link to the picture (not the picture itself!) to the list. Or, write down the oops carefully, and post the text. I see a infinite loop and is very fast, so I can't capture errors messages. None is registered in /var/log/* Well, that's very odd. Please also try the latest CFS backport to see if that solves the problem. Ray -- 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: Updatedb hangs Kernel 2.6.22.9-cfs-v22
On Jan 12, 2008 10:03 AM, Renato S. Yamane <[EMAIL PROTECTED]> wrote: > Hi, > I can't use updatedb in Debian Etch (stable) using customized Kernel > 2.6.22.9-cfs-v22. > > When I ran updatedb, after ~1 minute my system hangs and "caps lock" LED > is blinking. No log is registered. Please switch out of X11 to a text mode console (CTRL-ALT-F1), and run updatedb there. Capture the oops with a digital camera, and post a link to the picture (not the picture itself!) to the list. Or, write down the oops carefully, and post the text. -- 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: Updatedb hangs Kernel 2.6.22.9-cfs-v22
On Jan 12, 2008 10:03 AM, Renato S. Yamane [EMAIL PROTECTED] wrote: Hi, I can't use updatedb in Debian Etch (stable) using customized Kernel 2.6.22.9-cfs-v22. When I ran updatedb, after ~1 minute my system hangs and caps lock LED is blinking. No log is registered. Please switch out of X11 to a text mode console (CTRL-ALT-F1), and run updatedb there. Capture the oops with a digital camera, and post a link to the picture (not the picture itself!) to the list. Or, write down the oops carefully, and post the text. -- 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: questions on NAPI processing latency and dropped network packets
On Jan 10, 2008 9:24 AM, Chris Friesen <[EMAIL PROTECTED]> wrote: > After a recent userspace app change, we've started seeing packets being > dropped by the ethernet hardware (e1000, NAPI is enabled). The > error/dropped/fifo counts are going up in ethtool: (These are perhaps too obvious, but I didn't see the questions or answers in the thread.) Can you reproduce it with a simple userspace cpu hog? (Two, really, one per cpu.) Can you reproduce it with the newer e1000? Can you reproduce it with git head? If the answer to the first one is yes, the last no, then bisect until you get a kernel that doesn't show the problem. Backport the fix, unless the fix happens to be CFS. However, I suspect that your userpace app is just starving the system from time to time. -- 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 1/4] fs/autofs: Use time_before, time_before_eq, etc.
On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote: > - if (jiffies - ent->last_usage < timeout) > + if (time_before(jiffies, ent->last_usage + timeout)) I don't think this is a safe change? subtraction is always safe (if you think about it as 'distance'), addition isn't always safe unless you know the range. The time_before macro will expand that out to (effectively): if ( (long)(ent->last_usage + timeout) - (long)(jiffies) < 0 ) which seems to introduce an overflow condition in the first term. Dunno, I may be wrong (happens often), but at the very least what you've transformed it into is no longer obviously correct, and so it's not a great change. -- 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 1/4] fs/autofs: Use time_before, time_before_eq, etc.
On Dec 26, 2007 7:21 AM, Julia Lawall [EMAIL PROTECTED] wrote: - if (jiffies - ent-last_usage timeout) + if (time_before(jiffies, ent-last_usage + timeout)) I don't think this is a safe change? subtraction is always safe (if you think about it as 'distance'), addition isn't always safe unless you know the range. The time_before macro will expand that out to (effectively): if ( (long)(ent-last_usage + timeout) - (long)(jiffies) 0 ) which seems to introduce an overflow condition in the first term. Dunno, I may be wrong (happens often), but at the very least what you've transformed it into is no longer obviously correct, and so it's not a great change. -- 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: Debugging process hanging in D status and not responding to SIGKILL
On Dec 21, 2007 7:38 AM, Christian Hammers <[EMAIL PROTECTED]> wrote: > Hello > > Occasionally all my apache2 processes hang in "D" process status where they > are > no longer responsible to SIGKILL which makes the server almost un-rebootable. > The processes usually vanish after about 15-30min. > > I know that this usually means "I/O wait" somewhere deep inside a kernel > function where signals are not handled. > > But using "strace -p " I can only see that the last called function is > flock() (according to /proc//fd somebody produced a deadlock when using > PHP sessions). But flock() normally terminates on SIGTERM and SIGKILL. > > Could it be a problem with my SCSI driver who's involed in the flock process? > The problem usually occurs on two other webserver at the same time, one using > the same hardware and one being a Dell 6850 with Dell PERC RAID, though. > > How can I get further debugging information that could give me a hint? Do an echo t >/proc/sysrq-trigger and see what it shows. -- 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: Debugging process hanging in D status and not responding to SIGKILL
On Dec 21, 2007 7:38 AM, Christian Hammers [EMAIL PROTECTED] wrote: Hello Occasionally all my apache2 processes hang in D process status where they are no longer responsible to SIGKILL which makes the server almost un-rebootable. The processes usually vanish after about 15-30min. I know that this usually means I/O wait somewhere deep inside a kernel function where signals are not handled. But using strace -p pid I can only see that the last called function is flock() (according to /proc/pid/fd somebody produced a deadlock when using PHP sessions). But flock() normally terminates on SIGTERM and SIGKILL. Could it be a problem with my SCSI driver who's involed in the flock process? The problem usually occurs on two other webserver at the same time, one using the same hardware and one being a Dell 6850 with Dell PERC RAID, though. How can I get further debugging information that could give me a hint? Do an echo t /proc/sysrq-trigger and see what it shows. -- 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: Signed divides vs shifts (Re: [Security] /dev/urandom uses uninit bytes, leaks user data)
On Dec 17, 2007 10:10 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Dec 2007 10:05:35 -0800
> "Ray Lee" <[EMAIL PROTECTED]> wrote:
>
> > On Dec 17, 2007 9:55 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> > > - mid = (last - first) / 2 + first;
> > > + while (low <= high) {
> > > + mid = (low + high) / 2;
> >
> > I think you just introduced a bug. Think about what happens if
> > low=high=MAX_LONG/2 + 1.
> >
>
> Fortunatly this is not possible :)
>
> Hint : sizeof(struct exception_table_entry) is >= 8
>
> so high is garanteed to be <= MAX_LONG/8
Ah, my bad. One of these days I'll learn to not post before coffee.
--
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: Signed divides vs shifts (Re: [Security] /dev/urandom uses uninit bytes, leaks user data)
On Dec 17, 2007 9:55 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> - mid = (last - first) / 2 + first;
> + while (low <= high) {
> + mid = (low + high) / 2;
I think you just introduced a bug. Think about what happens if
low=high=MAX_LONG/2 + 1.
--
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: Signed divides vs shifts (Re: [Security] /dev/urandom uses uninit bytes, leaks user data)
On Dec 17, 2007 9:55 AM, Eric Dumazet [EMAIL PROTECTED] wrote:
- mid = (last - first) / 2 + first;
+ while (low = high) {
+ mid = (low + high) / 2;
I think you just introduced a bug. Think about what happens if
low=high=MAX_LONG/2 + 1.
--
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: Signed divides vs shifts (Re: [Security] /dev/urandom uses uninit bytes, leaks user data)
On Dec 17, 2007 10:10 AM, Eric Dumazet [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 10:05:35 -0800
Ray Lee [EMAIL PROTECTED] wrote:
On Dec 17, 2007 9:55 AM, Eric Dumazet [EMAIL PROTECTED] wrote:
- mid = (last - first) / 2 + first;
+ while (low = high) {
+ mid = (low + high) / 2;
I think you just introduced a bug. Think about what happens if
low=high=MAX_LONG/2 + 1.
Fortunatly this is not possible :)
Hint : sizeof(struct exception_table_entry) is = 8
so high is garanteed to be = MAX_LONG/8
Ah, my bad. One of these days I'll learn to not post before coffee.
--
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: Regression: Wireshark sees no packets in 2.6.24-rc3
On Dec 14, 2007 11:09 PM, Ray Lee <[EMAIL PROTECTED]> wrote: > On Dec 14, 2007 6:41 PM, Gabriel C <[EMAIL PROTECTED]> wrote: > Correct, absolutely no traffic. So if it works for you, then either > it's something that got fixed between -rc3 and -rc5, or something odd > when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 > kernel?) Regardless, -rc5 is currently building, and I'll try it in > the morning. -rc5 works great. Really don't know what's different between my -rc3 and -rc5 builds. The diff of .config between the two doesn't show anything obvious, so perhaps it was something fixed in the interim. I've gone ahead and closed the bugzilla entry, btw. Thanks, and sorry for the false (or tardy) alarm. Ray -- 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: Regression: Wireshark sees no packets in 2.6.24-rc3
On Dec 14, 2007 11:09 PM, Ray Lee [EMAIL PROTECTED] wrote: On Dec 14, 2007 6:41 PM, Gabriel C [EMAIL PROTECTED] wrote: Correct, absolutely no traffic. So if it works for you, then either it's something that got fixed between -rc3 and -rc5, or something odd when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 kernel?) Regardless, -rc5 is currently building, and I'll try it in the morning. -rc5 works great. Really don't know what's different between my -rc3 and -rc5 builds. The diff of .config between the two doesn't show anything obvious, so perhaps it was something fixed in the interim. I've gone ahead and closed the bugzilla entry, btw. Thanks, and sorry for the false (or tardy) alarm. Ray -- 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: Regression: Wireshark sees no packets in 2.6.24-rc3
On Dec 14, 2007 6:41 PM, Gabriel C <[EMAIL PROTECTED]> wrote: > Rafael J. Wysocki wrote: > > On Friday, 14 of December 2007, Ray Lee wrote: > >> tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just > >> fine. A quick scan of the log between 2.6.24-rc3 and current tip > >> (-rc5) doesn't show any obvious fixes, but then again, what do I know. > >> I'll check current tip on the weekend when I'll have the luxury to > >> have my main system down long enough for a test. Right now I'm kinda > >> up against a deadline, but didn't want to leave it unreported. Should > >> be easy for someone else to confirm or deny whether current tip has > >> the problem. > > > > FYI, I have created a bugzilla entry for this issue at: > > http://bugzilla.kernel.org/show_bug.cgi?id=9568 > > Hmm what do you mean by empty ? it does not capturing anything on that > interface ? Correct, absolutely no traffic. So if it works for you, then either it's something that got fixed between -rc3 and -rc5, or something odd when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 kernel?) Regardless, -rc5 is currently building, and I'll try it in the morning. > I do run -rc5-git with wireshark-0.99.6 and tshark -i eth0 or lo works here. Excellent. Thank you for checking! Rafael: I'll update the bugzilla as warranted after testing. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 12:13 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > Ray, I _do_ want to understand what is going on in your machine. > I _have_ to understand it. But I currently do not understand how the > quoted patch could fix modprobe of b43 or rfkill. I'd simply call that > impossible. Then perhaps it is. Perhaps it's a race condition in my userspace where something NetworkManager related is trying to up the interface, I don't know. More below. Regardless, I'm going to have to put off doing more debugging until tomorrow. I've rebooted back into 2.6.23.0 as wireshark doesn't show any packets using 2.6.24-rc3 (the version I've been testing), reported elsewhere, and that's preventing me from doing actual work with my system, as I'm in the middle of trying to enhance a network server for a client. Note, the wireshark issue is very much not a bcm43xx/b43 issue; I'm not trying to lay that at your feet. > So could you please try to reproduce the breakage by reverting that > patch again? Just to make really sure it is this patch fixing the issue > and not just some coincidence. I don't have the patch applied, so that's at least part of the misunderstanding here. All I have is my sequence of "load b43, ssb, nothing happens, unload them, load rfkill, rfkill-input, ssb, b43 and something happens." I could very well be wrong. But I'm at the limit of what I care to know about the b43 driver, and this is where I'm asking for your help. Hopefully tomorrow, I'll be able to build current tip and try this all again, and I'll also try to do it with NetworkManager killed in the background in case it was trying to bring the interfaces up behind my back. > Thanks for your help. Thanks for treating me like an adult. -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 11:38 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > > and nothing else.
> >
> > Well, you're wrong. Sorry, but that's just the way it is. See below.
> >
> > > It does _not_ fix loading of rfkill or b43 in any way.
> > > It does, however, fix loading of rfkill-input. But the b43 module
> > > operation does _not_ depend in any way on the rfkill-input module, except
> > > the tiny LED that doesn't blink if it's not loaded.
> > > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > > your requirement to load rfkill before b43.
> >
> > *AGAIN*, please read your message here, in particular item number
> > seven on Larry's list:
> >
> > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
> >
> > For the last fscking time, if rfkill and rfkill-input are not loaded,
> > not one line comes out in dmesg when b43 and ssb are loaded. In
> > particular, your pretty little message about needing newer firmware
> > also does not print. So, yeah, not loading rfkill{,-input} *does*
> > cause issues with b43 working, as there's no damn way to find out
> > what's broken!
>
> Guy... .
> I KNOW what the patch above does.
> What do you think does the following line?
> err = request_module("rfkill-input");
> Does it load the "rfkill-input" or the "rfkill" module.
> That's the million dollar question. You only have one try.
Oh. My. God.
Michael. I have a degree in Physics. I placed sixth in the world
finals of the ACM Collegiate programming contest in 1999, Cal Poly
Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
, I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
custom ppc platform, including writing drivers for various hardware on
it ( http://patinc.com ). I'm the guy who did all the software for a
linux-based Voice over IP call center (
http://broncocommunications.com/ ).
So, *now* do you believe I'm not an idiot?
To answer your question, it requests the rfkill-input module. But
under the version I'm trying, rfkill-input is not automatically
loaded. I've pointed to the mailing list URL that proves that. So, I
loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
necessary, I don't know, and I don't care. But once I did that, *then
and only then* did your damn b43 driver start printing out any
messages to dmesg at all, which then let me download the latest
firmware, and continue moving forward.
> You are telling me that I don't understand patches that I sign off
> and I should not take this personally?
> That is challenging.
I'm saying the patch you signed off on has a side-effect that will fix
my issue. And even if I *were* saying that, the most you should take
from it is that you are human and sometimes may make mistakes, just
like the rest of us. There's nothing challenging in that statement.
I've provided the bug report as many ways as I can think to. If you
don't agree, then I guess you'll just have to get the bug report from
someone else who can figure out exactly how to sugar coat the message
so that you'll listen to it.
Me, I'm done.
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 11:05 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 14 December 2007 19:45:02 Ray Lee wrote:
> > > > One problem related to b43 source code, patch exists, has yet to be
> > > > merged upstream.
> > >
> > > Yeah. A problem preventing a LED from blinking.
> > > That's a real regression Come on. Stop that bullshit.
> >
> > I'm going to say this one last time. If rfkill and rfkill-input aren't
> > manually loaded before sb and b43, not one damn thing comes out in
> > dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
> > find out that those modules had to be loaded by hand was to go read
> > the bcm43xx-dev archives. Once those were loaded, messages came out in
> > dmesg pointing me to the URL for updated firmware.
>
> I'm sorry. The patch that _you_ quoted fixes a blinking LED
> and nothing else.
Well, you're wrong. Sorry, but that's just the way it is. See below.
> It does _not_ fix loading of rfkill or b43 in any way.
> It does, however, fix loading of rfkill-input. But the b43 module
> operation does _not_ depend in any way on the rfkill-input module, except
> the tiny LED that doesn't blink if it's not loaded.
> I hope you understood now that the thread on bcm43xx-dev was NOT about
> your requirement to load rfkill before b43.
*AGAIN*, please read your message here, in particular item number
seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!
> > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > development archives.
>
> Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> reproduce this.
I'm not asking you to do that, this particular bug will be fixed by
Larry's patch, whether you believe that or not.
> However the fact that this does not happen on older Ubuntu platforms
> and does not happen on Fedora leads to the conclusion that it
> is a bug in Hardy Heron that I am not responsible for.
The kernel does not exist in a vacuum. It's the kernel's job to make
sure it works with properly written userspace. Broken userspace, sure,
then we can talk about breaking it.
> And you also do realise that Hardy Heron is the current development
> version of Ubuntu? Development versions have bugs.
Oy vay. I'm not an idiot. Yes, it's the current develoment version.
But tracking the latest kernel.org kernel has in the past required the
latest develoment version of the distribution, so I upgrade it as
well.
> > One last thing. I've been nice to you. Please be nice to me.
>
> If you simply stop blaming bugs on me that I am not responsible for
> at all, that is a deal. What about filing a bug at the ubuntu bugzilla?
I'm not blaming it on you. I'm merely reporting a fucking
incompatibility. Read my messages again from the top, and stop taking
this all so damn personally, will you?
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 10:11 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Ray Lee <[EMAIL PROTECTED]> wrote: > > > Now I'm going to go off, sit in the sun, sip some coffee, and think > > happy thoughts of kittens playing with yarn for a while. > > ok, and given the time-shift and apparent season-shift i'll sit in the > evening, watch the snowfall and think happy thoughts of kittens Heh :-). Sometimes I feel guilty living in coastal California. But our seasons are more along the lines of fire, flood, earthquake, and riot :-). Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
I've run out of time to donate to the kernel today, so I'll keep this short. On Dec 14, 2007 10:22 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > If you have a PCI device probing works as follows: > > > The PCI table is in ssb. So as soon as your kernel detects the PCI device > > > it will load ssb. ssb will register the PCI device. That will trigger > > > an udev event for the contained 802.11 core to get probed. This will load > > > b43. > > > > > > So, I'm not sure where's the issue with my code here. > > > > There's a patch from Larry Finger to address this and other issues. It > > hasn't made it's way fully upstream yet. Please read your message > > here, in particular item number seven on Larry's list: > > > > https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html > > 1) I sent this patch out today for inclusion in the kernel > 2) This is a _completely_ unrelated issue. >It is about "rfkill-input" being not loaded. NOT about >"b43" or "rfkill" not being loaded. [...] > > So, do you want a scorecard on this? > > > > One problem related to b43 source code, patch exists, has yet to be > > merged upstream. > > Yeah. A problem preventing a LED from blinking. > That's a real regression Come on. Stop that bullshit. I'm going to say this one last time. If rfkill and rfkill-input aren't manually loaded before sb and b43, not one damn thing comes out in dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to find out that those modules had to be loaded by hand was to go read the bcm43xx-dev archives. Once those were loaded, messages came out in dmesg pointing me to the URL for updated firmware. I have complete current userspace as of yesterday's Ubuntu Hardy Heron development archives. One last thing. I've been nice to you. Please be nice to me. If you can't manage that, then let another wireless developer take over. You apparently think I'm an idiot. I'm not, and if necessary I could supply a long list of credentials to prove I'm not an idiot. I'd rather you just accepted my emails at face value and spent more effort on trying to see how the bugs could be occurring rather than spending effort on trying to prove that I'm an idiot. Thanks. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 8:49 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Friday 14 December 2007 17:06:39 Ray Lee wrote: > > Hi all. Perhaps I can inject some facts into this? > > > > On Dec 14, 2007 5:08 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > > This user did get the following messages in dmesg: > > > > > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > > > >"or load failed.\n", path); > > > > > b43err(wl, "You must go to " > > > > >"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware " > > > > >"and download the correct firmware (version 4).\n"); > > > > > > > > > > I'm not sure how I can improve that even more. There is a full URL > > > > > describing how to get the device workin in _full_ detail. > > > > Yes, but only if you load rfkill-input and rfkill by hand, prior. > > I'm not sure what you are doing there. > Do you have module autoloading disabled? No, I don't have module autoloading disabled. modprobe-ing b43 automatically loads ssb. Neither, however, will load rfkill or rfkill-input. And if they aren't loaded, then b43/ssb are *completely* silent during load. Nothing to dmesg at all. > This all works perfectly well on all of my systems. And I never heared > such a problem before. WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list: https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html I'm going to blame this on you being tired or something, okay? But in the meantime, could you *PLEASE* start giving me the benefit of the doubt? > If you have a PCI device probing works as follows: > The PCI table is in ssb. So as soon as your kernel detects the PCI device > it will load ssb. ssb will register the PCI device. That will trigger > an udev event for the contained 802.11 core to get probed. This will load > b43. > > So, I'm not sure where's the issue with my code here. There's a patch from Larry Finger to address this and other issues. It hasn't made it's way fully upstream yet. Please read your message here, in particular item number seven on Larry's list: https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html > > That I'm one of the first people to hit that makes me think that your > > testing base so far has been miniscule. > > The driver is shipped by Fedora since quite some time. Well, then they've made changes to udev or something else to make this work okay for mere mortals such as myself, and haven't pushed those changes upstream so that others can benefit from it. > > > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in > > > > || dmesg other than lines related to the bcm43xx driver. > > > > || iwconfig/ifconfig do not see the interface either. > > > > See above. Without a modprobe of rfkill, rfkill-input that is the case. > > You can't do > modprobe ssb b43 > This will be interpreted as modprobe of "ssb" with the module > parameter "b43". At least by my modutils. Yes, I know. I'm sorry I was unclear. > If you do > modprobe b43 > it will automatically load _all_ required modules. > It works perfectly well on my systems. > Try it. Simply type "modprobe b43". It will also work for you. As I've said multiple times earlier in this thread, I did try that and it didn't work. Do you believe me now? > > Hello? I tried that. It failed. What *I'm* talking about here > > is that this everyone needs to be aware that this is *not* a drop in > > replacement for bcm43xx, and if I'm having problems (not a kernel > > hacker, but I make my living writing code), then sheesh, you're gonna > > have a flood of people needing hand-holding on this. > > All problems so far were not related to the b43 sourcecode at all. > And I think I can not be held responsible for unrelated code or bugs > in the operating system scripts. So, do you want a scorecard on this? One problem related to b43 source code, patch exists, has yet to be merged upstream. One problem related to udev rules, that may or may not be fixed in the latest udev. I have udev version 113, which is the latest shipped in Ubuntu's nightly development snapshots (hardy heron). I see that version 117 of udev is available on kernel.org, but mine is from the end of June. One would think that wouldn't be so old as to be a complete deal breaker. Especially as bcm43xx works fine with my udev. The b43 code requires the latest firmware, something that isn't quite obvious from skimming the changelogs. But is in dmesg, so thanks for that. With udev ru
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 8:59 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > What if you want to compile your own kernel? Well, then you are on > your own anyway. You have to track kernel changes anyway. I'm trying to help you test your code before it goes out to the unsuspecting masses. Do you think I do this for *fun*? Sheesh. No, fun is leaving my system exactly as it is not putting my brain into ADD (Attention Deficit Disorder) mode to track the latest rc and look for bugs. I'm trying to point out issues that are going to to come up once the full release hits. Testing, you know? Because I guarantee you that I'm a nicer and more competent tester than a lot of the people you'll have to deal with if there's a bug. (I, at least, have been writing software for 20+ years, and have been on all sides of the process.) If you *don't* want testing of b43, then I'm happy to leave it alone and go back to bcm43xx, and point out that it shouldn't be removed from the tree. None of us want that, as bcm43xx is a pile of junk. (I just tried rmmod'ing it twice. First time, it oopsed my system. I was in X, so no backtrace, just a blinking caps lock LED. Second time was a hard lock, no oops. Have I mentioned that I'm not doing this for fun?) > There are news sites (even not specific ones for the kernel) > that reported the bcm43xx->b43 change weeks ago. Perhaps so. It didn't hit kerneltrap or lwn, both of which I follow via RSS, so not sure what I should have been looking at instead. Regardless, I'm asking for three sentences to be added to the kernel release announcement. Hell, maybe Linus would even *like* to have you guys supply part of the release announcement. He's a nice guy, how about we ask? Look, this really isn't all that much about bcm43xx/b43 here. I'm trying to say that there are things that can help get more testers. If you don't care about that, then fine, ignore this message. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 8:27 AM, Ray Lee <[EMAIL PROTECTED]> wrote: > On Dec 14, 2007 6:40 AM, <[EMAIL PROTECTED]> wrote: > > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo > > suggests other ways to smooth out the transition. I haven't read > > proposals yet. > > This isn't rocket science guys. Put a file in somewhere in your tree > called ReleaseAnnouncement or something, and ask Linus to adjust his > kernel release process to include the contents of `cat $( find . -name > ReleaseAnnouncement )` in the release message he sends out. Clear out > the file after the release. > > Include things such as "bcm43xx is scheduled for removal. build both > b43 and b43legacy as a replacement. Be sure to download the latest > firmware from $URL and follow the instructions there to extract the > correct latest firmware necessary for your chip. There are known > incompatibilities with old udev versions, please ensure blah blah > blah." Or even better, keep the history, and show the diff of the old versus new in the release announcement, with an appropriate sed 's/+/ /' or somesuch. I'm sure you all will figure something out. Regardless, my point is a higher level changelog that is human readable would be helpful. (There are thousands of per-commit changelog entries to read, it's beyond what I have the time to do when testing a new kernel). Also, it seems distributing the release announcement work would be as helpful as distributing the code development work. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 6:40 AM, <[EMAIL PROTECTED]> wrote: > Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo > suggests other ways to smooth out the transition. I haven't read > proposals yet. This isn't rocket science guys. Put a file in somewhere in your tree called ReleaseAnnouncement or something, and ask Linus to adjust his kernel release process to include the contents of `cat $( find . -name ReleaseAnnouncement )` in the release message he sends out. Clear out the file after the release. Include things such as "bcm43xx is scheduled for removal. build both b43 and b43legacy as a replacement. Be sure to download the latest firmware from $URL and follow the instructions there to extract the correct latest firmware necessary for your chip. There are known incompatibilities with old udev versions, please ensure blah blah blah." Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
Hi all. Perhaps I can inject some facts into this? On Dec 14, 2007 5:08 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > This user did get the following messages in dmesg: > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > >"or load failed.\n", path); > > > b43err(wl, "You must go to " > > >"http://linuxwireless.org/en/users/Drivers/b43#devicefirmware " > > >"and download the correct firmware (version 4).\n"); > > > > > > I'm not sure how I can improve that even more. There is a full URL > > > describing how to get the device workin in _full_ detail. Yes, but only if you load rfkill-input and rfkill by hand, prior. Without those, dmesg is entirely silent, and nothing works even to the stage that I got it to last night. I had to search the bcm43xx-dev archives to find that out, and it was a message from Larry saying that he'd finally tracked down why it was working for some people and not others -- some of us build fully modular kernels. That I'm one of the first people to hit that makes me think that your testing base so far has been miniscule. Once I did that, the dmesg after loading did indeed contain the URL, and thank you for that. > > well i dont have this hardware, but the following description in this > > thread seems to contradict that: > > > > || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in > > || dmesg other than lines related to the bcm43xx driver. > > || iwconfig/ifconfig do not see the interface either. See above. Without a modprobe of rfkill, rfkill-input that is the case. > Let's quote another of Ray's statements: > "And ifconfig -a does indeed show it, sorry about that." > > So if he did then try to initialize that device, that clearly > _did_ show up in a standard place where network devices are > expected to show up, he did see the message I quoted. > Well, what if he did not try to initialize the device by doing > an "ifconfig wlanX up"? That can hardly be my fault, right? Hello? I tried that. It failed. What *I'm* talking about here is that this everyone needs to be aware that this is *not* a drop in replacement for bcm43xx, and if I'm having problems (not a kernel hacker, but I make my living writing code), then sheesh, you're gonna have a flood of people needing hand-holding on this. I still don't understand why bcm43xx is sane enough to create an eth1 entry, and b43 needs more handholding, but I'm going to hold off on commenting farther on that until I download the newer firmware. As it stands, I haven't given b43 an honest test yet. Please keep in mind that I'm really just trying to report my issues with the code before others hit the same thing, and trying to do this in a way that's productive for you all. I actually do understand what an amazing amount of effort you've poured into bcm43xx and the b43's, and again, I am thankful. I understand that bcm43xx is effectively dead, and it has architectural problems (locking, at minimum), that have been a problem for at least the past two years that *I've* been using it, probably more. The goal here is to make sure that your shiny new code will *work* for everyone, okay? Not to attack you, as I don't think you in any way deserve an attack. If I come off that way, I'm sorry. But likewise, if you could give me the benefit of the doubt, this conversation would go a lot smoother. Thanks. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
Hi all. Perhaps I can inject some facts into this? On Dec 14, 2007 5:08 AM, Michael Buesch [EMAIL PROTECTED] wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); b43err(wl, You must go to http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the correct firmware (version 4).\n); I'm not sure how I can improve that even more. There is a full URL describing how to get the device workin in _full_ detail. Yes, but only if you load rfkill-input and rfkill by hand, prior. Without those, dmesg is entirely silent, and nothing works even to the stage that I got it to last night. I had to search the bcm43xx-dev archives to find that out, and it was a message from Larry saying that he'd finally tracked down why it was working for some people and not others -- some of us build fully modular kernels. That I'm one of the first people to hit that makes me think that your testing base so far has been miniscule. Once I did that, the dmesg after loading did indeed contain the URL, and thank you for that. well i dont have this hardware, but the following description in this thread seems to contradict that: || Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in || dmesg other than lines related to the bcm43xx driver. || iwconfig/ifconfig do not see the interface either. See above. Without a modprobe of rfkill, rfkill-input that is the case. Let's quote another of Ray's statements: And ifconfig -a does indeed show it, sorry about that. So if he did then try to initialize that device, that clearly _did_ show up in a standard place where network devices are expected to show up, he did see the message I quoted. Well, what if he did not try to initialize the device by doing an ifconfig wlanX up? That can hardly be my fault, right? Hello? I tried that. It failed. What *I'm* talking about here is that this everyone needs to be aware that this is *not* a drop in replacement for bcm43xx, and if I'm having problems (not a kernel hacker, but I make my living writing code), then sheesh, you're gonna have a flood of people needing hand-holding on this. I still don't understand why bcm43xx is sane enough to create an eth1 entry, and b43 needs more handholding, but I'm going to hold off on commenting farther on that until I download the newer firmware. As it stands, I haven't given b43 an honest test yet. Please keep in mind that I'm really just trying to report my issues with the code before others hit the same thing, and trying to do this in a way that's productive for you all. I actually do understand what an amazing amount of effort you've poured into bcm43xx and the b43's, and again, I am thankful. I understand that bcm43xx is effectively dead, and it has architectural problems (locking, at minimum), that have been a problem for at least the past two years that *I've* been using it, probably more. The goal here is to make sure that your shiny new code will *work* for everyone, okay? Not to attack you, as I don't think you in any way deserve an attack. If I come off that way, I'm sorry. But likewise, if you could give me the benefit of the doubt, this conversation would go a lot smoother. Thanks. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 6:40 AM, [EMAIL PROTECTED] wrote: Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo suggests other ways to smooth out the transition. I haven't read proposals yet. This isn't rocket science guys. Put a file in somewhere in your tree called ReleaseAnnouncement or something, and ask Linus to adjust his kernel release process to include the contents of `cat $( find . -name ReleaseAnnouncement )` in the release message he sends out. Clear out the file after the release. Include things such as bcm43xx is scheduled for removal. build both b43 and b43legacy as a replacement. Be sure to download the latest firmware from $URL and follow the instructions there to extract the correct latest firmware necessary for your chip. There are known incompatibilities with old udev versions, please ensure blah blah blah. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 8:27 AM, Ray Lee [EMAIL PROTECTED] wrote: On Dec 14, 2007 6:40 AM, [EMAIL PROTECTED] wrote: Agreed. As a b43legacy maintainer, I'd be happy to know if Ingo suggests other ways to smooth out the transition. I haven't read proposals yet. This isn't rocket science guys. Put a file in somewhere in your tree called ReleaseAnnouncement or something, and ask Linus to adjust his kernel release process to include the contents of `cat $( find . -name ReleaseAnnouncement )` in the release message he sends out. Clear out the file after the release. Include things such as bcm43xx is scheduled for removal. build both b43 and b43legacy as a replacement. Be sure to download the latest firmware from $URL and follow the instructions there to extract the correct latest firmware necessary for your chip. There are known incompatibilities with old udev versions, please ensure blah blah blah. Or even better, keep the history, and show the diff of the old versus new in the release announcement, with an appropriate sed 's/+/ /' or somesuch. shrug I'm sure you all will figure something out. Regardless, my point is a higher level changelog that is human readable would be helpful. (There are thousands of per-commit changelog entries to read, it's beyond what I have the time to do when testing a new kernel). Also, it seems distributing the release announcement work would be as helpful as distributing the code development work. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 8:59 AM, Michael Buesch [EMAIL PROTECTED] wrote: What if you want to compile your own kernel? Well, then you are on your own anyway. You have to track kernel changes anyway. I'm trying to help you test your code before it goes out to the unsuspecting masses. Do you think I do this for *fun*? Sheesh. No, fun is leaving my system exactly as it is not putting my brain into ADD (Attention Deficit Disorder) mode to track the latest rc and look for bugs. I'm trying to point out issues that are going to to come up once the full release hits. Testing, you know? Because I guarantee you that I'm a nicer and more competent tester than a lot of the people you'll have to deal with if there's a bug. (I, at least, have been writing software for 20+ years, and have been on all sides of the process.) If you *don't* want testing of b43, then I'm happy to leave it alone and go back to bcm43xx, and point out that it shouldn't be removed from the tree. None of us want that, as bcm43xx is a pile of junk. (I just tried rmmod'ing it twice. First time, it oopsed my system. I was in X, so no backtrace, just a blinking caps lock LED. Second time was a hard lock, no oops. Have I mentioned that I'm not doing this for fun?) There are news sites (even not specific ones for the kernel) that reported the bcm43xx-b43 change weeks ago. Perhaps so. It didn't hit kerneltrap or lwn, both of which I follow via RSS, so not sure what I should have been looking at instead. Regardless, I'm asking for three sentences to be added to the kernel release announcement. Hell, maybe Linus would even *like* to have you guys supply part of the release announcement. He's a nice guy, how about we ask? Look, this really isn't all that much about bcm43xx/b43 here. I'm trying to say that there are things that can help get more testers. If you don't care about that, then fine, ignore this message. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 10:11 AM, Ingo Molnar [EMAIL PROTECTED] wrote: * Ray Lee [EMAIL PROTECTED] wrote: Now I'm going to go off, sit in the sun, sip some coffee, and think happy thoughts of kittens playing with yarn for a while. ok, and given the time-shift and apparent season-shift i'll sit in the evening, watch the snowfall and think happy thoughts of kittens Heh :-). Sometimes I feel guilty living in coastal California. But our seasons are more along the lines of fire, flood, earthquake, and riot :-). Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 8:49 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Friday 14 December 2007 17:06:39 Ray Lee wrote:
Hi all. Perhaps I can inject some facts into this?
On Dec 14, 2007 5:08 AM, Michael Buesch [EMAIL PROTECTED] wrote:
This user did get the following messages in dmesg:
b43err(dev-wl, Firmware file \%s\ not found
or load failed.\n, path);
b43err(wl, You must go to
http://linuxwireless.org/en/users/Drivers/b43#devicefirmware
and download the correct firmware (version 4).\n);
I'm not sure how I can improve that even more. There is a full URL
describing how to get the device workin in _full_ detail.
Yes, but only if you load rfkill-input and rfkill by hand, prior.
I'm not sure what you are doing there.
Do you have module autoloading disabled?
No, I don't have module autoloading disabled. modprobe-ing b43
automatically loads ssb. Neither, however, will load rfkill or
rfkill-input. And if they aren't loaded, then b43/ssb are *completely*
silent during load. Nothing to dmesg at all.
This all works perfectly well on all of my systems. And I never heared
such a problem before.
WTF? Please read *YOUR OWN MESSAGE* to the bcm43xx-dev list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006456.html
I'm going to blame this on you being tired or something, okay? But in
the meantime, could you *PLEASE* start giving me the benefit of the
doubt?
If you have a PCI device probing works as follows:
The PCI table is in ssb. So as soon as your kernel detects the PCI device
it will load ssb. ssb will register the PCI device. That will trigger
an udev event for the contained 802.11 core to get probed. This will load
b43.
So, I'm not sure where's the issue with my code here.
There's a patch from Larry Finger to address this and other issues. It
hasn't made it's way fully upstream yet. Please read your message
here, in particular item number seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
That I'm one of the first people to hit that makes me think that your
testing base so far has been miniscule.
The driver is shipped by Fedora since quite some time.
shrug Well, then they've made changes to udev or something else to
make this work okay for mere mortals such as myself, and haven't
pushed those changes upstream so that others can benefit from it.
|| Well, doing an `rmmod bcm43xx ; modprobe ssb b43` gives me nothing in
|| dmesg other than lines related to the bcm43xx driver.
|| iwconfig/ifconfig do not see the interface either.
See above. Without a modprobe of rfkill, rfkill-input that is the case.
You can't do
modprobe ssb b43
This will be interpreted as modprobe of ssb with the module
parameter b43. At least by my modutils.
Yes, I know. I'm sorry I was unclear.
If you do
modprobe b43
it will automatically load _all_ required modules.
It works perfectly well on my systems.
Try it. Simply type modprobe b43. It will also work for you.
As I've said multiple times earlier in this thread, I did try that and
it didn't work. Do you believe me now?
Hello? I tried that. It failed. What *I'm* talking about here
is that this everyone needs to be aware that this is *not* a drop in
replacement for bcm43xx, and if I'm having problems (not a kernel
hacker, but I make my living writing code), then sheesh, you're gonna
have a flood of people needing hand-holding on this.
All problems so far were not related to the b43 sourcecode at all.
And I think I can not be held responsible for unrelated code or bugs
in the operating system scripts.
So, do you want a scorecard on this?
One problem related to b43 source code, patch exists, has yet to be
merged upstream.
One problem related to udev rules, that may or may not be fixed in the
latest udev. I have udev version 113, which is the latest shipped in
Ubuntu's nightly development snapshots (hardy heron). I see that
version 117 of udev is available on kernel.org, but mine is from the
end of June. One would think that wouldn't be so old as to be a
complete deal breaker. Especially as bcm43xx works fine with my udev.
The b43 code requires the latest firmware, something that isn't quite
obvious from skimming the changelogs. But is in dmesg, so thanks for
that.
With udev rules hand-edited to include the ATTRS{type}==1 Larry
pointed out (thanks Larry), b43 also seems to create an odd extra
device, wmaster0. Same MAC as eth1, my wireless. It's just an odd
thing that wasn't there before with bcm43xx. May be good, may be bad,
dunno.
And yeah, in my opinion, making the kernel play well with up-to-date
userspace actually *is* part of your job, but then again, what do I
know.
Michael, you're a good guy, I believe that. You're doing unglamorous
and mostly thankless work, and I am thankful for it. I'm afraid the
only way I could make it glamorous is to offer to send you a fancy
Re: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
I've run out of time to donate to the kernel today, so I'll keep this short. On Dec 14, 2007 10:22 AM, Michael Buesch [EMAIL PROTECTED] wrote: If you have a PCI device probing works as follows: The PCI table is in ssb. So as soon as your kernel detects the PCI device it will load ssb. ssb will register the PCI device. That will trigger an udev event for the contained 802.11 core to get probed. This will load b43. So, I'm not sure where's the issue with my code here. There's a patch from Larry Finger to address this and other issues. It hasn't made it's way fully upstream yet. Please read your message here, in particular item number seven on Larry's list: https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html 1) I sent this patch out today for inclusion in the kernel 2) This is a _completely_ unrelated issue. It is about rfkill-input being not loaded. NOT about b43 or rfkill not being loaded. [...] So, do you want a scorecard on this? One problem related to b43 source code, patch exists, has yet to be merged upstream. Yeah. A problem preventing a LED from blinking. That's a real regression Come on. Stop that bullshit. I'm going to say this one last time. If rfkill and rfkill-input aren't manually loaded before sb and b43, not one damn thing comes out in dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to find out that those modules had to be loaded by hand was to go read the bcm43xx-dev archives. Once those were loaded, messages came out in dmesg pointing me to the URL for updated firmware. I have complete current userspace as of yesterday's Ubuntu Hardy Heron development archives. One last thing. I've been nice to you. Please be nice to me. If you can't manage that, then let another wireless developer take over. You apparently think I'm an idiot. I'm not, and if necessary I could supply a long list of credentials to prove I'm not an idiot. I'd rather you just accepted my emails at face value and spent more effort on trying to see how the bugs could be occurring rather than spending effort on trying to prove that I'm an idiot. Thanks. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 11:05 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Friday 14 December 2007 19:45:02 Ray Lee wrote:
One problem related to b43 source code, patch exists, has yet to be
merged upstream.
Yeah. A problem preventing a LED from blinking.
That's a real regression Come on. Stop that bullshit.
I'm going to say this one last time. If rfkill and rfkill-input aren't
manually loaded before sb and b43, not one damn thing comes out in
dmesg. Nothing. Nada. Zilch. Zero. Bupkis. Zot. Null. The only way to
find out that those modules had to be loaded by hand was to go read
the bcm43xx-dev archives. Once those were loaded, messages came out in
dmesg pointing me to the URL for updated firmware.
I'm sorry. The patch that _you_ quoted fixes a blinking LED
and nothing else.
Well, you're wrong. Sorry, but that's just the way it is. See below.
It does _not_ fix loading of rfkill or b43 in any way.
It does, however, fix loading of rfkill-input. But the b43 module
operation does _not_ depend in any way on the rfkill-input module, except
the tiny LED that doesn't blink if it's not loaded.
I hope you understood now that the thread on bcm43xx-dev was NOT about
your requirement to load rfkill before b43.
*AGAIN*, please read your message here, in particular item number
seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!
I have complete current userspace as of yesterday's Ubuntu Hardy Heron
development archives.
Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
reproduce this.
I'm not asking you to do that, this particular bug will be fixed by
Larry's patch, whether you believe that or not.
However the fact that this does not happen on older Ubuntu platforms
and does not happen on Fedora leads to the conclusion that it
is a bug in Hardy Heron that I am not responsible for.
The kernel does not exist in a vacuum. It's the kernel's job to make
sure it works with properly written userspace. Broken userspace, sure,
then we can talk about breaking it.
And you also do realise that Hardy Heron is the current development
version of Ubuntu? Development versions have bugs.
Oy vay. I'm not an idiot. Yes, it's the current develoment version.
But tracking the latest kernel.org kernel has in the past required the
latest develoment version of the distribution, so I upgrade it as
well.
One last thing. I've been nice to you. Please be nice to me.
If you simply stop blaming bugs on me that I am not responsible for
at all, that is a deal. What about filing a bug at the ubuntu bugzilla?
I'm not blaming it on you. I'm merely reporting a fucking
incompatibility. Read my messages again from the top, and stop taking
this all so damn personally, will you?
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 11:38 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Friday 14 December 2007 20:25:39 Ray Lee wrote:
I'm sorry. The patch that _you_ quoted fixes a blinking LED
and nothing else.
Well, you're wrong. Sorry, but that's just the way it is. See below.
It does _not_ fix loading of rfkill or b43 in any way.
It does, however, fix loading of rfkill-input. But the b43 module
operation does _not_ depend in any way on the rfkill-input module, except
the tiny LED that doesn't blink if it's not loaded.
I hope you understood now that the thread on bcm43xx-dev was NOT about
your requirement to load rfkill before b43.
*AGAIN*, please read your message here, in particular item number
seven on Larry's list:
https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
For the last fscking time, if rfkill and rfkill-input are not loaded,
not one line comes out in dmesg when b43 and ssb are loaded. In
particular, your pretty little message about needing newer firmware
also does not print. So, yeah, not loading rfkill{,-input} *does*
cause issues with b43 working, as there's no damn way to find out
what's broken!
Guy... .
I KNOW what the patch above does.
What do you think does the following line?
err = request_module(rfkill-input);
Does it load the rfkill-input or the rfkill module.
That's the million dollar question. You only have one try.
Oh. My. God.
Michael. I have a degree in Physics. I placed sixth in the world
finals of the ACM Collegiate programming contest in 1999, Cal Poly
Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html
, I'm the guy all the way to the right. ) I ported the 2.4 kernel to a
custom ppc platform, including writing drivers for various hardware on
it ( http://patinc.com ). I'm the guy who did all the software for a
linux-based Voice over IP call center (
http://broncocommunications.com/ ).
So, *now* do you believe I'm not an idiot?
To answer your question, it requests the rfkill-input module. But
under the version I'm trying, rfkill-input is not automatically
loaded. I've pointed to the mailing list URL that proves that. So, I
loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't
necessary, I don't know, and I don't care. But once I did that, *then
and only then* did your damn b43 driver start printing out any
messages to dmesg at all, which then let me download the latest
firmware, and continue moving forward.
You are telling me that I don't understand patches that I sign off
and I should not take this personally?
That is challenging.
I'm saying the patch you signed off on has a side-effect that will fix
my issue. And even if I *were* saying that, the most you should take
from it is that you are human and sometimes may make mistakes, just
like the rest of us. There's nothing challenging in that statement.
I've provided the bug report as many ways as I can think to. If you
don't agree, then I guess you'll just have to get the bug report from
someone else who can figure out exactly how to sugar coat the message
so that you'll listen to it.
Me, I'm done.
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 14, 2007 12:13 PM, Michael Buesch [EMAIL PROTECTED] wrote: Ray, I _do_ want to understand what is going on in your machine. I _have_ to understand it. But I currently do not understand how the quoted patch could fix modprobe of b43 or rfkill. I'd simply call that impossible. Then perhaps it is. Perhaps it's a race condition in my userspace where something NetworkManager related is trying to up the interface, I don't know. More below. Regardless, I'm going to have to put off doing more debugging until tomorrow. I've rebooted back into 2.6.23.0 as wireshark doesn't show any packets using 2.6.24-rc3 (the version I've been testing), reported elsewhere, and that's preventing me from doing actual work with my system, as I'm in the middle of trying to enhance a network server for a client. Note, the wireshark issue is very much not a bcm43xx/b43 issue; I'm not trying to lay that at your feet. So could you please try to reproduce the breakage by reverting that patch again? Just to make really sure it is this patch fixing the issue and not just some coincidence. I don't have the patch applied, so that's at least part of the misunderstanding here. All I have is my sequence of load b43, ssb, nothing happens, unload them, load rfkill, rfkill-input, ssb, b43 and something happens. I could very well be wrong. But I'm at the limit of what I care to know about the b43 driver, and this is where I'm asking for your help. Hopefully tomorrow, I'll be able to build current tip and try this all again, and I'll also try to do it with NetworkManager killed in the background in case it was trying to bring the interfaces up behind my back. Thanks for your help. Thanks for treating me like an adult. -- 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: Regression: Wireshark sees no packets in 2.6.24-rc3
On Dec 14, 2007 6:41 PM, Gabriel C [EMAIL PROTECTED] wrote: Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Ray Lee wrote: tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just fine. A quick scan of the log between 2.6.24-rc3 and current tip (-rc5) doesn't show any obvious fixes, but then again, what do I know. I'll check current tip on the weekend when I'll have the luxury to have my main system down long enough for a test. Right now I'm kinda up against a deadline, but didn't want to leave it unreported. Should be easy for someone else to confirm or deny whether current tip has the problem. FYI, I have created a bugzilla entry for this issue at: http://bugzilla.kernel.org/show_bug.cgi?id=9568 Hmm what do you mean by empty ? it does not capturing anything on that interface ? Correct, absolutely no traffic. So if it works for you, then either it's something that got fixed between -rc3 and -rc5, or something odd when I did a make oldconfig, I suppose. (Or because I'm on an x86-64 kernel?) Regardless, -rc5 is currently building, and I'll try it in the morning. I do run -rc5-git with wireshark-0.99.6 and tshark -i eth0 or lo works here. Excellent. Thank you for checking! Rafael: I'll update the bugzilla as warranted after testing. Ray -- 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/
Regression: Wireshark sees no packets in 2.6.24-rc3
tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just fine. A quick scan of the log between 2.6.24-rc3 and current tip (-rc5) doesn't show any obvious fixes, but then again, what do I know. I'll check current tip on the weekend when I'll have the luxury to have my main system down long enough for a test. Right now I'm kinda up against a deadline, but didn't want to leave it unreported. Should be easy for someone else to confirm or deny whether current tip has the problem. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 13, 2007 4:43 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Friday 14 December 2007 01:05:00 Ray Lee wrote: > > Okay, I had to modprobe rfkill-input and rfkill by hand, didn't > > realize that. Hopefully that'll be automatic soon. Regardless, upon > > doing so, and loading ssb and b43, it sees my card, but is still not > > fully functional. iwconfig sees: > > > > lono wireless extensions. > > eth0 no wireless extensions. > > tun0 no wireless extensions. > > eth1 no wireless extensions. > > wlan0_rename IEEE 802.11g ESSID:"" > > Mode:Managed Channel:0 Access Point: Not-Associated > > Tx-Power=0 dBm > > Retry min limit:7 RTS thr:off Fragment thr=2346 B > > Link Quality:0 Signal level:0 Noise level:0 > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > > > (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.) > > > > `ifconfig` doesn't see eth1 or wlan0_rename. > > > > What else might I be doing wrong? > > I don't know. Try ifconfig -a > Or tell udev to not crap up your device names. Uhm, I haven't had to tell udev to not crap up any of my *other* devices, why is b43 special? I'm using an up-to-date userspace, so I'm not going to be the only one hitting this problem. And ifconfig -a does indeed show it, sorry about that. But my understanding is that udev renames interfaces based on MAC address, so I wouldn't suspect udev to be at fault here. Digging a little farther into it, it looks like b43 is barfing partway through init as the firmware file it's looking for has changed names. Perhaps that's the issue. I'll take a longer look at this all tomorrow. > > Regardless, perhaps scheduling > > bcm43xx for removal in 2.6.26 is a bit premature. > > Oh come on. b43 is more than a year old now. How long should we wait? > Two or three? Forever? Well, it only hit the main kernel October 10th. That means no final point release of the kernel.org kernel has even had it included! So testing-wise, you still haven't hit the hordes yet. Scheduling a removal of bcm43xx (as painful as that code is [*]), seems either premature or very optimistic. So, how about scheduling the removal once you get a feel for the bug reports that'll come in once 2.6.24 is released. [*] Yeah, even as a user the code is painful. It *still* locks my keyboard if I happen to disable the wireless while it's scanning. The sooner bcm43xx is dead, the better. But b43 is quite obviously not a full replacement for everyone. I don't mean to come off harsh, I know you put an amazing amount of work into both b43 and bcm43xx, and I'm thankful for that. But requiring the end-user to go scan bcm43xx-dev archives to find out that the b43 module isn't correctly autoloading all of its dependencies is a sign that the code still hasn't had a lot of testing, no? In the meantime I'll keep plugging away at trying to figure out what's wrong. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 13, 2007 5:45 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
> > Uhm, hijacking the thread a bit here, but which driver is supposed to
> > be supporting my 4309? Neither b43 nor b43legacy found my wireless,
> > and I'm not seeing its PCI ID anywhere either of those...
> >
> > 02:02.0 0280: 14e4:4324 (rev 03)
>
> The device is supported by b43.
> The PCI ID is in the SSB PCI bridge code
>
> static const struct pci_device_id b43_pci_bridge_tbl[] = {
...
> { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
Ah, thanks, so it is. Well, doing an `rmmod bcm43xx ; modprobe ssb
b43` gives me nothing in dmesg other than lines related to the bcm43xx
driver. iwconfig/ifconfig do not see the interface either.
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lono wireless extensions.
eth0 no wireless extensions.
tun0 no wireless extensions.
eth1 no wireless extensions.
wlan0_rename IEEE 802.11g ESSID:""
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
`ifconfig` doesn't see eth1 or wlan0_rename.
What else might I be doing wrong? Regardless, perhaps scheduling
bcm43xx for removal in 2.6.26 is a bit premature.
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 13, 2007 5:45 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Thursday 13 December 2007 02:17:16 Ray Lee wrote:
Uhm, hijacking the thread a bit here, but which driver is supposed to
be supporting my 4309? Neither b43 nor b43legacy found my wireless,
and I'm not seeing its PCI ID anywhere either of those...
02:02.0 0280: 14e4:4324 (rev 03)
The device is supported by b43.
The PCI ID is in the SSB PCI bridge code
static const struct pci_device_id b43_pci_bridge_tbl[] = {
...
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
Ah, thanks, so it is. Well, doing an `rmmod bcm43xx ; modprobe ssb
b43` gives me nothing in dmesg other than lines related to the bcm43xx
driver. iwconfig/ifconfig do not see the interface either.
goes and reads bcm43xx-dev archives
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional. iwconfig sees:
lono wireless extensions.
eth0 no wireless extensions.
tun0 no wireless extensions.
eth1 no wireless extensions.
wlan0_rename IEEE 802.11g ESSID:
Mode:Managed Channel:0 Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.)
`ifconfig` doesn't see eth1 or wlan0_rename.
What else might I be doing wrong? Regardless, perhaps scheduling
bcm43xx for removal in 2.6.26 is a bit premature.
--
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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 13, 2007 4:43 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Friday 14 December 2007 01:05:00 Ray Lee wrote: Okay, I had to modprobe rfkill-input and rfkill by hand, didn't realize that. Hopefully that'll be automatic soon. Regardless, upon doing so, and loading ssb and b43, it sees my card, but is still not fully functional. iwconfig sees: lono wireless extensions. eth0 no wireless extensions. tun0 no wireless extensions. eth1 no wireless extensions. wlan0_rename IEEE 802.11g ESSID: Mode:Managed Channel:0 Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2346 B Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 (eth0 is ethernet, eth1 doesn't exist -- usually it's the wireless.) `ifconfig` doesn't see eth1 or wlan0_rename. What else might I be doing wrong? I don't know. Try ifconfig -a Or tell udev to not crap up your device names. Uhm, I haven't had to tell udev to not crap up any of my *other* devices, why is b43 special? I'm using an up-to-date userspace, so I'm not going to be the only one hitting this problem. And ifconfig -a does indeed show it, sorry about that. But my understanding is that udev renames interfaces based on MAC address, so I wouldn't suspect udev to be at fault here. Digging a little farther into it, it looks like b43 is barfing partway through init as the firmware file it's looking for has changed names. Perhaps that's the issue. I'll take a longer look at this all tomorrow. Regardless, perhaps scheduling bcm43xx for removal in 2.6.26 is a bit premature. Oh come on. b43 is more than a year old now. How long should we wait? Two or three? Forever? Well, it only hit the main kernel October 10th. That means no final point release of the kernel.org kernel has even had it included! So testing-wise, you still haven't hit the hordes yet. Scheduling a removal of bcm43xx (as painful as that code is [*]), seems either premature or very optimistic. So, how about scheduling the removal once you get a feel for the bug reports that'll come in once 2.6.24 is released. [*] Yeah, even as a user the code is painful. It *still* locks my keyboard if I happen to disable the wireless while it's scanning. The sooner bcm43xx is dead, the better. But b43 is quite obviously not a full replacement for everyone. I don't mean to come off harsh, I know you put an amazing amount of work into both b43 and bcm43xx, and I'm thankful for that. But requiring the end-user to go scan bcm43xx-dev archives to find out that the b43 module isn't correctly autoloading all of its dependencies is a sign that the code still hasn't had a lot of testing, no? In the meantime I'll keep plugging away at trying to figure out what's wrong. Ray -- 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/
Regression: Wireshark sees no packets in 2.6.24-rc3
tshark -i eth0, eth1, lo are all empty. Works under 2.6.23.0 just fine. A quick scan of the log between 2.6.24-rc3 and current tip (-rc5) doesn't show any obvious fixes, but then again, what do I know. I'll check current tip on the weekend when I'll have the luxury to have my main system down long enough for a test. Right now I'm kinda up against a deadline, but didn't want to leave it unreported. Should be easy for someone else to confirm or deny whether current tip has the problem. Ray -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 12, 2007 4:48 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > This driver is scheduled for removal, so I'd not touch it anymore > to avoid the possibility to introduce a lastminute regression. > The new drivers (b43 and b43legacy) have this fixed (in a different > way by completely removing it). Uhm, hijacking the thread a bit here, but which driver is supposed to be supporting my 4309? Neither b43 nor b43legacy found my wireless, and I'm not seeing its PCI ID anywhere either of those... $ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03) Subsystem: Hewlett-Packard Company Unknown device 12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 02:02.0 0280: 14e4:4324 (rev 03) Subsystem: 103c:12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 00: e4 14 24 43 06 00 00 00 03 00 80 02 00 40 00 00 10: 00 00 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 f9 12 30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00 -- 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 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Dec 12, 2007 4:48 PM, Michael Buesch [EMAIL PROTECTED] wrote: This driver is scheduled for removal, so I'd not touch it anymore to avoid the possibility to introduce a lastminute regression. The new drivers (b43 and b43legacy) have this fixed (in a different way by completely removing it). Uhm, hijacking the thread a bit here, but which driver is supposed to be supporting my 4309? Neither b43 nor b43legacy found my wireless, and I'm not seeing its PCI ID anywhere either of those... $ lspci -s 02:02 -v; lspci -n -s 02:02 -v -x 02:02.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03) Subsystem: Hewlett-Packard Company Unknown device 12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 02:02.0 0280: 14e4:4324 (rev 03) Subsystem: 103c:12f9 Flags: bus master, fast devsel, latency 64, IRQ 22 Memory at d001 (32-bit, non-prefetchable) [size=8K] 00: e4 14 24 43 06 00 00 00 03 00 80 02 00 40 00 00 10: 00 00 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 f9 12 30: 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00 -- 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: Why does reading from /dev/urandom deplete entropy so much?
On Dec 11, 2007 11:46 AM, Phillip Susi <[EMAIL PROTECTED]> wrote: > Theodore Tso wrote: > > Note that even paranoid applicatons should not be using /dev/random > > for session keys; again, /dev/random isn't magic, and entropy isn't > > unlimited. Instead, such an application should pull 16 bytes or so, > > and then use it to seed a cryptographic random number generator. > > What good does using multiple levels of RNG do? Why seed one RNG from > another? Wouldn't it be better to have just one RNG that everybody > uses? Not all applications need cryptographically secure random numbers. Sometimes, you just want a random number to seed your game RNG or a monte carlo simulator. -- 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: Why does reading from /dev/urandom deplete entropy so much?
On Dec 11, 2007 11:46 AM, Phillip Susi [EMAIL PROTECTED] wrote: Theodore Tso wrote: Note that even paranoid applicatons should not be using /dev/random for session keys; again, /dev/random isn't magic, and entropy isn't unlimited. Instead, such an application should pull 16 bytes or so, and then use it to seed a cryptographic random number generator. What good does using multiple levels of RNG do? Why seed one RNG from another? Wouldn't it be better to have just one RNG that everybody uses? Not all applications need cryptographically secure random numbers. Sometimes, you just want a random number to seed your game RNG or a monte carlo simulator. -- 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: 2.6.24-rc4-git5: Reported regressions from 2.6.23
On Dec 9, 2007 2:01 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > > Btw, Alan, that "math" is total and utter BULLSH*T, and you should know > > that. > > To blindly argue regressions are critical is sometimes (as in this case) > to argue that "this freeway is no longer compatible with a horse and > cart" means the freeway should be turned back into a dirt road. Honest question: If you allow regressions, then how does one guarantee forward progress? (If it were a finite set of systems, all within one group's control, then the answer is simple: count how many work. However, in this case we only have a statistical sampling available to us.) Ray -- 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: programs vanish with 2.6.22+
On Dec 8, 2007 4:25 AM, Markus <[EMAIL PROTECTED]> wrote: > Well, just tried it. Started a dozen konquerors and attached strace to > everyone. When one disapeared, I only got a "Process 9246 detached", > nothing else is printed or written in the log. You could try an ltrace instead, and see if it's one of the linked libraries having a problem. -- 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: programs vanish with 2.6.22+
On Dec 8, 2007 4:25 AM, Markus [EMAIL PROTECTED] wrote: Well, just tried it. Started a dozen konquerors and attached strace to everyone. When one disapeared, I only got a Process 9246 detached, nothing else is printed or written in the log. You could try an ltrace instead, and see if it's one of the linked libraries having a problem. -- 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: 2.6.24-rc4-git5: Reported regressions from 2.6.23
On Dec 9, 2007 2:01 PM, Alan Cox [EMAIL PROTECTED] wrote: Btw, Alan, that math is total and utter BULLSH*T, and you should know that. To blindly argue regressions are critical is sometimes (as in this case) to argue that this freeway is no longer compatible with a horse and cart means the freeway should be turned back into a dirt road. Honest question: If you allow regressions, then how does one guarantee forward progress? (If it were a finite set of systems, all within one group's control, then the answer is simple: count how many work. However, in this case we only have a statistical sampling available to us.) Ray -- 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: 2.6.24: false double-clicks from USB mouse
On Dec 7, 2007 10:32 AM, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > On Dec 7, 2007 12:59 PM, Ray Lee <[EMAIL PROTECTED]> wrote: > > On Dec 2, 2007 2:07 PM, Jiri Kosina <[EMAIL PROTECTED]> wrote: > > > Thanks. To sum up this longish thread: > > > > > > - Mark seems to be able to reproduce the problem quite easily; I was not > > > successful reproducing this no matter how hard I tried, and I also > > > didn't receive any similar bugreports from anyone else > > > - we are currently waiting for Mark to provide HID_DEBUG (and preferably > > > also usbmon) output from the situation where multiple clicks are > > > being generated incorrectly > > > > Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6. > > > > When the problem hits, my mouse (synaptics touchpad) is randomly > > moving about and clicking things whenever I have my finger on the > > trackpad. This behavior will persists for five to ten minutes (is > > happening now), and seems to be triggered by load (watching online > > videos in flash player, for example -- this matches Mark's experience > > with a make -j4). > > > > I *think* the touchpad is connected via ps2, which looks like it'd > > clear usb of any blame. It's /dev/input/event6 at any rate. > > > > This has been happening about once a day, and seems to start because > > of high CPU usage. ONce the CPU is idle, it still happens though, so > > I'm not sure why it clears up. > > > > Any clues for where I should hunt from here? > > > > Can you try replacing drivers/input/ and include/linux/input.h from > 2.6.23-rc6 and see if it works or not? That should give us idea if > input locking changes are to blame. I'm hitting a number of build errors, trying to compile a hybrid between the two. git checkout v2.6.24-rc4 git checkout v2.6.23 include/linux/input.h drivers/input make # fails with kconfig issues git checkout v2.6.24-rc4 drivers/input/misc/Kconfig make # fails ...adding to include/linux/input.h: #define KEY_CNT (KEY_MAX+1) takes the build a little farther until it dies on more missing definitions. Doing a checkout of 2.6.24-rc4's include/linux/input.h leads to different build errors. Looking at git log for drivers/input, it appears the patches you're talking about are the ones starting with 8006479c9b? If so, perhaps I should just build the revision right before that commit and test that? Ray -- 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: 2.6.24: false double-clicks from USB mouse
On Dec 2, 2007 2:07 PM, Jiri Kosina <[EMAIL PROTECTED]> wrote: > Thanks. To sum up this longish thread: > > - Mark seems to be able to reproduce the problem quite easily; I was not > successful reproducing this no matter how hard I tried, and I also > didn't receive any similar bugreports from anyone else > - we are currently waiting for Mark to provide HID_DEBUG (and preferably > also usbmon) output from the situation where multiple clicks are > being generated incorrectly Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6. When the problem hits, my mouse (synaptics touchpad) is randomly moving about and clicking things whenever I have my finger on the trackpad. This behavior will persists for five to ten minutes (is happening now), and seems to be triggered by load (watching online videos in flash player, for example -- this matches Mark's experience with a make -j4). I *think* the touchpad is connected via ps2, which looks like it'd clear usb of any blame. It's /dev/input/event6 at any rate. This has been happening about once a day, and seems to start because of high CPU usage. ONce the CPU is idle, it still happens though, so I'm not sure why it clears up. Any clues for where I should hunt from here? -- 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: 2.6.24: false double-clicks from USB mouse
On Dec 2, 2007 2:07 PM, Jiri Kosina [EMAIL PROTECTED] wrote: Thanks. To sum up this longish thread: - Mark seems to be able to reproduce the problem quite easily; I was not successful reproducing this no matter how hard I tried, and I also didn't receive any similar bugreports from anyone else - we are currently waiting for Mark to provide HID_DEBUG (and preferably also usbmon) output from the situation where multiple clicks are being generated incorrectly Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6. When the problem hits, my mouse (synaptics touchpad) is randomly moving about and clicking things whenever I have my finger on the trackpad. This behavior will persists for five to ten minutes (is happening now), and seems to be triggered by load (watching online videos in flash player, for example -- this matches Mark's experience with a make -j4). I *think* the touchpad is connected via ps2, which looks like it'd clear usb of any blame. It's /dev/input/event6 at any rate. This has been happening about once a day, and seems to start because of high CPU usage. ONce the CPU is idle, it still happens though, so I'm not sure why it clears up. Any clues for where I should hunt from here? -- 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: 2.6.24: false double-clicks from USB mouse
On Dec 7, 2007 10:32 AM, Dmitry Torokhov [EMAIL PROTECTED] wrote: On Dec 7, 2007 12:59 PM, Ray Lee [EMAIL PROTECTED] wrote: On Dec 2, 2007 2:07 PM, Jiri Kosina [EMAIL PROTECTED] wrote: Thanks. To sum up this longish thread: - Mark seems to be able to reproduce the problem quite easily; I was not successful reproducing this no matter how hard I tried, and I also didn't receive any similar bugreports from anyone else - we are currently waiting for Mark to provide HID_DEBUG (and preferably also usbmon) output from the situation where multiple clicks are being generated incorrectly Okay, I'm having a problem with 2.6.24-rc4 that I didn't with 2.6.23-rc6. When the problem hits, my mouse (synaptics touchpad) is randomly moving about and clicking things whenever I have my finger on the trackpad. This behavior will persists for five to ten minutes (is happening now), and seems to be triggered by load (watching online videos in flash player, for example -- this matches Mark's experience with a make -j4). I *think* the touchpad is connected via ps2, which looks like it'd clear usb of any blame. It's /dev/input/event6 at any rate. This has been happening about once a day, and seems to start because of high CPU usage. ONce the CPU is idle, it still happens though, so I'm not sure why it clears up. Any clues for where I should hunt from here? Can you try replacing drivers/input/ and include/linux/input.h from 2.6.23-rc6 and see if it works or not? That should give us idea if input locking changes are to blame. I'm hitting a number of build errors, trying to compile a hybrid between the two. git checkout v2.6.24-rc4 git checkout v2.6.23 include/linux/input.h drivers/input make # fails with kconfig issues git checkout v2.6.24-rc4 drivers/input/misc/Kconfig make # fails ...adding to include/linux/input.h: #define KEY_CNT (KEY_MAX+1) takes the build a little farther until it dies on more missing definitions. Doing a checkout of 2.6.24-rc4's include/linux/input.h leads to different build errors. Looking at git log for drivers/input, it appears the patches you're talking about are the ones starting with 8006479c9b? If so, perhaps I should just build the revision right before that commit and test that? Ray -- 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: Why does reading from /dev/urandom deplete entropy so much?
(Why hasn't anyone been cc:ing Matt on this?) On Dec 4, 2007 8:18 AM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Tue, Dec 04, 2007 at 12:41:25PM +0100, Marc Haber wrote: > > > While debugging Exim4's GnuTLS interface, I recently found out that > > reading from /dev/urandom depletes entropy as much as reading from > > /dev/random would. This has somehow surprised me since I have always > > believed that /dev/urandom has lower quality entropy than /dev/random, > > but lots of it. > > man 4 random > > > This also means that I can "sabotage" applications reading from > > /dev/random just by continuously reading from /dev/urandom, even not > > meaning to do any harm. > > > > Before I file a bug on bugzilla, > >... > > The bug would be closed as invalid. > > No matter what you consider as being better, changing a 12 years old and > widely used userspace interface like /dev/urandom is simply not an > option. You seem to be confused. He's not talking about changing any userspace interface, merely how the /dev/urandom data is generated. For Matt's benefit, part of the original posting: > Before I file a bug on bugzilla, can I ask why /dev/urandom wasn't > implemented as a PRNG which is periodically (say, every 1024 bytes or > even more) seeded from /dev/random? That way, /dev/random has a much > higher chance of holding enough entropy for applications that really > need "good" entropy. A PRNG is clearly unacceptable. But roughly restated, why not have /dev/urandom supply merely cryptographically strong random numbers, rather than a mix between the 'true' random of /dev/random down to the cryptographically strong stream it'll provide when /dev/random is tapped? In principle, this'd leave more entropy available for applications that really need it, especially on platforms that don't generate a lot of entropy in the first place (servers). Ray -- 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/
