Re: nfs_update_inode: inode X mode changed, Y to Z
Dear Kernel People, Problem persists and it seems that I am not alone who hits this problem: http://lkml.org/lkml/2007/3/1/53 in my case it happens if there is a lot (>50) nfs clients which in a fast pace create a small file, close it and then open it for reading. Some times it fails saying that the file is a directory, some times it just fails to open it for writing, etc I would really appreciate any comments and/or ideas on how to troubleshoot/eliminate this issue. Cheers Yarik On Fri, 23 Feb 2007, Yaroslav Halchenko wrote: > Dear Kernel People, > I am running a tiny cluster (27 nodes). Setup is as follows: > * NFS server: >kernel: vanilla 2.6.18.2 + areca drivers >mounted partition is XFS >nfs-kernel-server: 1.0.10-1~bpo.1 (from backports.org) > * clients: >kernel: 2.6.17-2-amd64 (Debian stock from etch installed few months ago) > Today under heavy load which consisted of the nodes manipulating tons of > small files, I started to mention that software reported weird errors > like: > EOFError: EOF read where object expected > mv: cannot stat : No such file or directory > etc > Looking at the client's dmesg I found nasty: > node17.ravana.rutgers.edu: Feb 23 13:32:06 node17 kernel: nfs_update_inode: > inode 680223263 mode changed, 0042755 to 0100644 > node17.ravana.rutgers.edu: Feb 23 13:41:19 node17 kernel: nfs_update_inode: > inode 681427742 mode changed, 0042755 to 0100644 > node22.ravana.rutgers.edu: Feb 22 22:58:15 node22 kernel: nfs_update_inode: > inode 677306152 mode changed, 0042755 to 0100644 > node22.ravana.rutgers.edu: Feb 23 13:48:33 node22 kernel: nfs_update_inode: > inode 681695507 mode changed, 0100644 to 0042755 > node12.ravana.rutgers.edu: Feb 23 13:31:01 node12 kernel: nfs_update_inode: > inode 680150798 mode changed, 0100644 to 0042755 > node12.ravana.rutgers.edu: Feb 23 13:34:57 node12 kernel: nfs_update_inode: > inode 680418141 mode changed, 0100644 to 0042755 > node12.ravana.rutgers.edu: Feb 23 13:37:01 node12 kernel: nfs_update_inode: > inode 680637478 mode changed, 0100644 to 0042755 > node12.ravana.rutgers.edu: Feb 23 13:39:25 node12 kernel: nfs_update_inode: > inode 681034087 mode changed, 0100644 to 0042755 > node12.ravana.rutgers.edu: Feb 23 13:40:06 node12 kernel: nfs_update_inode: > inode 681225056 mode changed, 0042755 to 0100644 > node12.ravana.rutgers.edu: Feb 23 13:43:26 node12 kernel: nfs_update_inode: > inode 681474682 mode changed, 0100644 to 0042755 > .. > server logs didn't show any abnormal things... where should I look for the > source of the problem? googling up seems to be of no interesting result... > is there way to eliminate cause may be by tuning some performance > parameters (ie sacrificing performance for stability)? > Thanks everyone in advance for hints -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: nfs_update_inode: inode X mode changed, Y to Z
Dear Kernel People, Problem persists and it seems that I am not alone who hits this problem: http://lkml.org/lkml/2007/3/1/53 in my case it happens if there is a lot (50) nfs clients which in a fast pace create a small file, close it and then open it for reading. Some times it fails saying that the file is a directory, some times it just fails to open it for writing, etc I would really appreciate any comments and/or ideas on how to troubleshoot/eliminate this issue. Cheers Yarik On Fri, 23 Feb 2007, Yaroslav Halchenko wrote: Dear Kernel People, I am running a tiny cluster (27 nodes). Setup is as follows: * NFS server: kernel: vanilla 2.6.18.2 + areca drivers mounted partition is XFS nfs-kernel-server: 1.0.10-1~bpo.1 (from backports.org) * clients: kernel: 2.6.17-2-amd64 (Debian stock from etch installed few months ago) Today under heavy load which consisted of the nodes manipulating tons of small files, I started to mention that software reported weird errors like: EOFError: EOF read where object expected mv: cannot stat FILENAME : No such file or directory etc Looking at the client's dmesg I found nasty: node17.ravana.rutgers.edu: Feb 23 13:32:06 node17 kernel: nfs_update_inode: inode 680223263 mode changed, 0042755 to 0100644 node17.ravana.rutgers.edu: Feb 23 13:41:19 node17 kernel: nfs_update_inode: inode 681427742 mode changed, 0042755 to 0100644 node22.ravana.rutgers.edu: Feb 22 22:58:15 node22 kernel: nfs_update_inode: inode 677306152 mode changed, 0042755 to 0100644 node22.ravana.rutgers.edu: Feb 23 13:48:33 node22 kernel: nfs_update_inode: inode 681695507 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:31:01 node12 kernel: nfs_update_inode: inode 680150798 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:34:57 node12 kernel: nfs_update_inode: inode 680418141 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:37:01 node12 kernel: nfs_update_inode: inode 680637478 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:39:25 node12 kernel: nfs_update_inode: inode 681034087 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:40:06 node12 kernel: nfs_update_inode: inode 681225056 mode changed, 0042755 to 0100644 node12.ravana.rutgers.edu: Feb 23 13:43:26 node12 kernel: nfs_update_inode: inode 681474682 mode changed, 0100644 to 0042755 .. server logs didn't show any abnormal things... where should I look for the source of the problem? googling up seems to be of no interesting result... is there way to eliminate cause may be by tuning some performance parameters (ie sacrificing performance for stability)? Thanks everyone in advance for hints -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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/
nfs_update_inode: inode X mode changed, Y to Z
Dear Kernel People, I am running a tiny cluster (27 nodes). Setup is as follows: * NFS server: kernel: vanilla 2.6.18.2 + areca drivers mounted partition is XFS nfs-kernel-server: 1.0.10-1~bpo.1 (from backports.org) * clients: kernel: 2.6.17-2-amd64 (Debian stock from etch installed few months ago) Today under heavy load which consisted of the nodes manipulating tons of small files, I started to mention that software reported weird errors like: EOFError: EOF read where object expected mv: cannot stat : No such file or directory etc Looking at the client's dmesg I found nasty: node17.ravana.rutgers.edu: Feb 23 13:32:06 node17 kernel: nfs_update_inode: inode 680223263 mode changed, 0042755 to 0100644 node17.ravana.rutgers.edu: Feb 23 13:41:19 node17 kernel: nfs_update_inode: inode 681427742 mode changed, 0042755 to 0100644 node22.ravana.rutgers.edu: Feb 22 22:58:15 node22 kernel: nfs_update_inode: inode 677306152 mode changed, 0042755 to 0100644 node22.ravana.rutgers.edu: Feb 23 13:48:33 node22 kernel: nfs_update_inode: inode 681695507 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:31:01 node12 kernel: nfs_update_inode: inode 680150798 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:34:57 node12 kernel: nfs_update_inode: inode 680418141 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:37:01 node12 kernel: nfs_update_inode: inode 680637478 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:39:25 node12 kernel: nfs_update_inode: inode 681034087 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:40:06 node12 kernel: nfs_update_inode: inode 681225056 mode changed, 0042755 to 0100644 node12.ravana.rutgers.edu: Feb 23 13:43:26 node12 kernel: nfs_update_inode: inode 681474682 mode changed, 0100644 to 0042755 .. server logs didn't show any abnormal things... where should I look for the source of the problem? googling up seems to be of no interesting result... is there way to eliminate cause may be by tuning some performance parameters (ie sacrificing performance for stability)? Thanks everyone in advance for hints -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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/
nfs_update_inode: inode X mode changed, Y to Z
Dear Kernel People, I am running a tiny cluster (27 nodes). Setup is as follows: * NFS server: kernel: vanilla 2.6.18.2 + areca drivers mounted partition is XFS nfs-kernel-server: 1.0.10-1~bpo.1 (from backports.org) * clients: kernel: 2.6.17-2-amd64 (Debian stock from etch installed few months ago) Today under heavy load which consisted of the nodes manipulating tons of small files, I started to mention that software reported weird errors like: EOFError: EOF read where object expected mv: cannot stat FILENAME : No such file or directory etc Looking at the client's dmesg I found nasty: node17.ravana.rutgers.edu: Feb 23 13:32:06 node17 kernel: nfs_update_inode: inode 680223263 mode changed, 0042755 to 0100644 node17.ravana.rutgers.edu: Feb 23 13:41:19 node17 kernel: nfs_update_inode: inode 681427742 mode changed, 0042755 to 0100644 node22.ravana.rutgers.edu: Feb 22 22:58:15 node22 kernel: nfs_update_inode: inode 677306152 mode changed, 0042755 to 0100644 node22.ravana.rutgers.edu: Feb 23 13:48:33 node22 kernel: nfs_update_inode: inode 681695507 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:31:01 node12 kernel: nfs_update_inode: inode 680150798 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:34:57 node12 kernel: nfs_update_inode: inode 680418141 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:37:01 node12 kernel: nfs_update_inode: inode 680637478 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:39:25 node12 kernel: nfs_update_inode: inode 681034087 mode changed, 0100644 to 0042755 node12.ravana.rutgers.edu: Feb 23 13:40:06 node12 kernel: nfs_update_inode: inode 681225056 mode changed, 0042755 to 0100644 node12.ravana.rutgers.edu: Feb 23 13:43:26 node12 kernel: nfs_update_inode: inode 681474682 mode changed, 0100644 to 0042755 .. server logs didn't show any abnormal things... where should I look for the source of the problem? googling up seems to be of no interesting result... is there way to eliminate cause may be by tuning some performance parameters (ie sacrificing performance for stability)? Thanks everyone in advance for hints -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: no backlight on radeon after recent kernel "upgrade"s
I am sorry on the delay
> > On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko <[EMAIL PROTECTED]>
> > wrote:
> > > Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
> > > tried few times to build more recent snapshots and now finally
> > > 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
> > > >...<
> > Is 2.6.20 broken? I assume the latest 2.6.20-gitN snapshot are failing..
-mm's have been failing since some time after .19-rc6-mm1. I believe
I've tried 2.6.19-mm? with the same luck
> It would be extremely useful to know which kernel versions you tested
> and which ones failed. There are a number of backlight changes which are
> just in 2.6.20-mm1 and -mm2 which it would be useful to rule out or
> identify as the cause.
I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
Iv'e tried, but, once again, I experienced the same issue with 19-mm?
kernels.
I built 2.6.20-mm2 without backlight support
$> grep BACKLIGH /boot/config-2.6.20-mm2
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_RIVA_BACKLIGHT is not set
# CONFIG_FB_RADEON_BACKLIGHT is not set
that "eliminated" the problem. Also I can see the screen with pure
2.6.20 with backlight support (whatever it does since after
loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
*$> grep BACKLIGH /boot/config-2.6.20
# CONFIG_FB_BACKLIGHT is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
> Also, do you normally see files under /sys/class/lcd?
nope... after I load lcd module, no files under :-/ regardless either it
is mm or not. But there are files under /sys/class/backlight/ for mm2
compiled with backlight support (whenever the screen is dark as per my
original email)
--
.-.
=-- /v\ ----=
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
-
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: no backlight on radeon after recent kernel upgrades
I am sorry on the delay
On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko [EMAIL PROTECTED]
wrote:
Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
tried few times to build more recent snapshots and now finally
2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
...
Is 2.6.20 broken? I assume the latest 2.6.20-gitN snapshot are failing..
-mm's have been failing since some time after .19-rc6-mm1. I believe
I've tried 2.6.19-mm? with the same luck
It would be extremely useful to know which kernel versions you tested
and which ones failed. There are a number of backlight changes which are
just in 2.6.20-mm1 and -mm2 which it would be useful to rule out or
identify as the cause.
I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
Iv'e tried, but, once again, I experienced the same issue with 19-mm?
kernels.
I built 2.6.20-mm2 without backlight support
$ grep BACKLIGH /boot/config-2.6.20-mm2
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_RIVA_BACKLIGHT is not set
# CONFIG_FB_RADEON_BACKLIGHT is not set
that eliminated the problem. Also I can see the screen with pure
2.6.20 with backlight support (whatever it does since after
loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
*$ grep BACKLIGH /boot/config-2.6.20
# CONFIG_FB_BACKLIGHT is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
Also, do you normally see files under /sys/class/lcd?
nope... after I load lcd module, no files under :-/ regardless either it
is mm or not. But there are files under /sys/class/backlight/ for mm2
compiled with backlight support (whenever the screen is dark as per my
original email)
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
-
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/
no backlight on radeon after recent kernel "upgrade"s
Dear Kernel Developers, Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've tried few times to build more recent snapshots and now finally 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but at some point during boot (few moments after Penguin icon in the top left corner appears), light turns off... I still can see something, especially if I light a strong flashlight at a sharp angle. I've enabled back-light support and lcd support for those unsuccessful kernels (with all backlight support features disabled kernel boots ok and backlight shines as bright as always) All my changes of values for files under /sys/class/backlight/radeonbl0 had no impact on the screen. Also I had no files under /sys/class/lcd. Running radeontool light off caused complete turning off of LCD - I could not see anything anymore. sony's spictl -b had no effect as well. Config can be found at http://www.onerussian.com/Linux/bugs/nobacklight.1/config-2.6.20-mm2 lshw http://www.onerussian.com/Linux/bugs/nobacklight.1/lshw other details are available from http://www.onerussian.com/Linux/bugs/nobacklight.1/ Could you please advise? -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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/
no backlight on radeon after recent kernel upgrades
Dear Kernel Developers, Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've tried few times to build more recent snapshots and now finally 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but at some point during boot (few moments after Penguin icon in the top left corner appears), light turns off... I still can see something, especially if I light a strong flashlight at a sharp angle. I've enabled back-light support and lcd support for those unsuccessful kernels (with all backlight support features disabled kernel boots ok and backlight shines as bright as always) All my changes of values for files under /sys/class/backlight/radeonbl0 had no impact on the screen. Also I had no files under /sys/class/lcd. Running radeontool light off caused complete turning off of LCD - I could not see anything anymore. sony's spictl -b had no effect as well. Config can be found at http://www.onerussian.com/Linux/bugs/nobacklight.1/config-2.6.20-mm2 lshw http://www.onerussian.com/Linux/bugs/nobacklight.1/lshw other details are available from http://www.onerussian.com/Linux/bugs/nobacklight.1/ Could you please advise? -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
> Since this is a 2nd order allocation, it could also be that you have > memory but it's fragmented. Thanks for the info! > If you aren't using jumbograms you can > try disabling that. disabling 2nd order allocation? and I do use jumbos on that box (it is an NFS server so jumbo frames -- MTU 9000 -- presumable help a bit on CPU utilization) > Cheers, -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
Since this is a 2nd order allocation, it could also be that you have memory but it's fragmented. Thanks for the info! If you aren't using jumbograms you can try disabling that. disabling 2nd order allocation? and I do use jumbos on that box (it is an NFS server so jumbo frames -- MTU 9000 -- presumable help a bit on CPU utilization) Cheers, -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
On another box which has 4 times more RAM or a bit more than twice total memory, it had twice as high vm.min_free_kbytes on another node with even more RAM it is 13821.. hm - so what is the algorithm which sets it? percent of available RAM? For now I am adjusting it on that server to be twice from default. Thanks everyone for your help On Thu, 30 Nov 2006, Avi Kivity wrote: > Alan wrote: > >Under heavy network or I/O pressure it may not have time to swap to get > >the memory. Thus adding swap won't usually help. Adding RAM may do but > >its often not the best answer. Arjan's suggestion should sort it, and - > >yes typically boxes with very high I/O and network load need more of a > >pool of memory free for immediate use than other systems. > It could be nice if the kernel could autotune this, for example by raising > the free memory goal when memory shortage is detected, and lowering it > gradually when not. > The sysctl could be a minimum from which this is calculated. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
Thank you Arjan for advice I had 5746, made it 8619. Is that a good practice in general to have that value higher for a server with lots of I/O including networking? (there is a RAID on that system and 2 bonded gigabit interfaces) Is there any heuristic to decide on that value ? On Thu, 30 Nov 2006, Arjan van de Ven wrote: > >...< > actually since this was networking... > you probably should bump the value in > /proc/sys/vm/min_free_kbytes > a bit (like by 50%); that makes the kernel keep a bigger pool free for > emergencies/spikes... > That might be enough already if your system isn't swapping a whole lot. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
Thank you Alan Ok - I am adding more memory in my purchasing plan ;-) For now I guess adding swap space should help, right? > > >...< > Its tell us that the machine got very very tight on memory, far tighter > than it probably ever should in normal situations. It is harmless of > itself and if you only get the odd one is not a worry. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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/
kswapd/tg3 issue
Dear Kernel People, Just got a logwatch daily mail which revealed a problem: [2024412.788680] kswapd1: page allocation failure. order:2, mode:0x20 and a lengthy backtrace with head , | [2024412.795212] Call Trace: | [2024412.799768] [] __alloc_pages+0x27a/0x291 | [2024412.806452] [] kmem_getpages+0x5e/0xd8 | [2024412.812370] [] cache_grow+0xd0/0x185 | [2024412.818064] [] cache_alloc_refill+0x18c/0x1da | [2024412.824625] [] __kmalloc+0x93/0xa3 | [2024412.830145] [] __alloc_skb+0x54/0x117 | [2024412.835958] [] __netdev_alloc_skb+0x12/0x2d | [2024412.842347] [] tg3_alloc_rx_skb+0xbb/0x146 `--- full dmesg is at http://www.onerussian.com/Linux/bugs/bug.kswapd/dmesg is that critical? seems to behave ok but... More details on the system and error in particular can be http://www.onerussian.com/Linux/bugs/bug.kswapd/ -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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/
kswapd/tg3 issue
Dear Kernel People, Just got a logwatch daily mail which revealed a problem: [2024412.788680] kswapd1: page allocation failure. order:2, mode:0x20 and a lengthy backtrace with head , | [2024412.795212] Call Trace: | [2024412.799768] IRQ [8020c852] __alloc_pages+0x27a/0x291 | [2024412.806452] [802a08e3] kmem_getpages+0x5e/0xd8 | [2024412.812370] [80212c68] cache_grow+0xd0/0x185 | [2024412.818064] [80245c4f] cache_alloc_refill+0x18c/0x1da | [2024412.824625] [802a1979] __kmalloc+0x93/0xa3 | [2024412.830145] [80222e9e] __alloc_skb+0x54/0x117 | [2024412.835958] [803b8a55] __netdev_alloc_skb+0x12/0x2d | [2024412.842347] [80370292] tg3_alloc_rx_skb+0xbb/0x146 `--- full dmesg is at http://www.onerussian.com/Linux/bugs/bug.kswapd/dmesg is that critical? seems to behave ok but... More details on the system and error in particular can be http://www.onerussian.com/Linux/bugs/bug.kswapd/ -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
Thank you Alan Ok - I am adding more memory in my purchasing plan ;-) For now I guess adding swap space should help, right? ... Its tell us that the machine got very very tight on memory, far tighter than it probably ever should in normal situations. It is harmless of itself and if you only get the odd one is not a worry. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
Thank you Arjan for advice I had 5746, made it 8619. Is that a good practice in general to have that value higher for a server with lots of I/O including networking? (there is a RAID on that system and 2 bonded gigabit interfaces) Is there any heuristic to decide on that value ? On Thu, 30 Nov 2006, Arjan van de Ven wrote: ... actually since this was networking... you probably should bump the value in /proc/sys/vm/min_free_kbytes a bit (like by 50%); that makes the kernel keep a bigger pool free for emergencies/spikes... That might be enough already if your system isn't swapping a whole lot. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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: kswapd/tg3 issue
On another box which has 4 times more RAM or a bit more than twice total memory, it had twice as high vm.min_free_kbytes on another node with even more RAM it is 13821.. hm - so what is the algorithm which sets it? percent of available RAM? For now I am adjusting it on that server to be twice from default. Thanks everyone for your help On Thu, 30 Nov 2006, Avi Kivity wrote: Alan wrote: Under heavy network or I/O pressure it may not have time to swap to get the memory. Thus adding swap won't usually help. Adding RAM may do but its often not the best answer. Arjan's suggestion should sort it, and - yes typically boxes with very high I/O and network load need more of a pool of memory free for immediate use than other systems. It could be nice if the kernel could autotune this, for example by raising the free memory goal when memory shortage is detected, and lowering it gradually when not. The sysctl could be a minimum from which this is calculated. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik - 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.8 -> 2.6.11 (+ata-dev patch) -- HDD is always on
On Fri, Jul 29, 2005 at 12:25:42AM -0400, Jeff Garzik wrote: > Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? now tested both of them -- light is constantly on in both. does the HDD LED always signals about hardware activity or it can just be sticky and not reset properly? is there libata-dev patch for 2.6.8 kernel which seems to be running fine so I might just patch it to get SATA SMART? Thank you in advance for the feedback -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105 Student Ph.D. @ CS Dept. NJIT - 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.8 - 2.6.11 (+ata-dev patch) -- HDD is always on
On Fri, Jul 29, 2005 at 12:25:42AM -0400, Jeff Garzik wrote: Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? now tested both of them -- light is constantly on in both. does the HDD LED always signals about hardware activity or it can just be sticky and not reset properly? is there libata-dev patch for 2.6.8 kernel which seems to be running fine so I might just patch it to get SATA SMART? Thank you in advance for the feedback -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105 Student Ph.D. @ CS Dept. NJIT - 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.8 -> 2.6.11 (+ata-dev patch) -- HDD is always on
> > > Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? tried clear 2.6.11 ( with no libata patch -- light is on :-( ) /booted 2.6.8 Debian kernel -- everything is fine, but no libata-dev patch for SATA makes me wonder if you should try 2.6.13-rc4/ once again -- details of the system can be found http://www.onerussian.com/Linux/bugs/ata/ -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105 Student Ph.D. @ CS Dept. NJIT - 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.8 -> 2.6.11 (+ata-dev patch) -- HDD is always on
Damn me - sorry for the misinformation... I've compiled the kernel without Debian-loved initrd image... so I've booted 2.6.12.3 -- LED light is on - so I bet no blame on libata patch, although I've mentioned few patches from that patch migrated into the mainstream kernel. Any ideas on which next step to take? 2.6.13-rc4? or vanilla 2.6.11? On Fri, Jul 29, 2005 at 01:58:20AM -0400, Yaroslav Halchenko wrote: > On Fri, Jul 29, 2005 at 12:25:42AM -0400, Jeff Garzik wrote: > > Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? > just tried unpatched 2.6.12.3. > The Box stalls booting with > "Uncompressing Linux... Ok, booting the kernel. > _" > interesting though that led hdd light is off at first, blinks few > times, and 1-2 secs after it stalls with above message - it gets its > steady green light on. > Could I screw up some NEW kernel configuration parameters when pulling > config from 2.6.8 from Debian? I don't know :-/ > I will try 2.6.13-rc4 now... heh heh -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105 Student Ph.D. @ CS Dept. NJIT - 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.8 -> 2.6.11 (+ata-dev patch) -- HDD is always on
On Fri, Jul 29, 2005 at 12:25:42AM -0400, Jeff Garzik wrote: > Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? just tried unpatched 2.6.12.3. The Box stalls booting with "Uncompressing Linux... Ok, booting the kernel. _" interesting though that led hdd light is off at first, blinks few times, and 1-2 secs after it stalls with above message - it gets its steady green light on. Could I screw up some NEW kernel configuration parameters when pulling config from 2.6.8 from Debian? I don't know :-/ I will try 2.6.13-rc4 now... heh heh -- Yaroslav Halchenko Graduate Student CS Dept. UNM, ABQ Linux User 17 - 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.8 - 2.6.11 (+ata-dev patch) -- HDD is always on
On Fri, Jul 29, 2005 at 12:25:42AM -0400, Jeff Garzik wrote: Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? just tried unpatched 2.6.12.3. The Box stalls booting with Uncompressing Linux... Ok, booting the kernel. _ interesting though that led hdd light is off at first, blinks few times, and 1-2 secs after it stalls with above message - it gets its steady green light on. Could I screw up some NEW kernel configuration parameters when pulling config from 2.6.8 from Debian? I don't know :-/ I will try 2.6.13-rc4 now... heh heh -- Yaroslav Halchenko Graduate Student CS Dept. UNM, ABQ Linux User 17 - 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.8 - 2.6.11 (+ata-dev patch) -- HDD is always on
Damn me - sorry for the misinformation... I've compiled the kernel without Debian-loved initrd image... so I've booted 2.6.12.3 -- LED light is on - so I bet no blame on libata patch, although I've mentioned few patches from that patch migrated into the mainstream kernel. Any ideas on which next step to take? 2.6.13-rc4? or vanilla 2.6.11? On Fri, Jul 29, 2005 at 01:58:20AM -0400, Yaroslav Halchenko wrote: On Fri, Jul 29, 2005 at 12:25:42AM -0400, Jeff Garzik wrote: Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? just tried unpatched 2.6.12.3. The Box stalls booting with Uncompressing Linux... Ok, booting the kernel. _ interesting though that led hdd light is off at first, blinks few times, and 1-2 secs after it stalls with above message - it gets its steady green light on. Could I screw up some NEW kernel configuration parameters when pulling config from 2.6.8 from Debian? I don't know :-/ I will try 2.6.13-rc4 now... heh heh -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105 Student Ph.D. @ CS Dept. NJIT - 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.8 - 2.6.11 (+ata-dev patch) -- HDD is always on
Does this happen in unpatched 2.6.12.3 or 2.6.13-rc4? tried clear 2.6.11 ( with no libata patch -- light is on :-( ) /booted 2.6.8 Debian kernel -- everything is fine, but no libata-dev patch for SATA makes me wonder if you should try 2.6.13-rc4/ once again -- details of the system can be found http://www.onerussian.com/Linux/bugs/ata/ -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07105 Student Ph.D. @ CS Dept. NJIT - 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/
2.6.8 -> 2.6.11 (+ata-dev patch) -- HDD is always on
I've been running debian stable with 2.6.8 kernel but due to recent failure of the SATA harddrive I've decided to upgrade to 2.6.11 + libata patch (2.6.11-libata-dev1.patch.gz) and recent smartmontools After everything worked out and I decided to rest in piece but I've found that HDD LED light nomater what. It seems to turn off during BIOS checks and then kicks in 1-2 secs after kernel starts booting. No prominent harddrive activity noise can be heard but this drive is quite silent so it is hard to say. SATA drivers were compiled in the kernel to don't mess with initrd. QUESTION: LED constantly ON - does it signal about a problem or may be just that some status bit is hanging? Should I worry and try differen kernel version? YIKES: ran hddtemp /dev/sda and whole box hanged... SysRq keys - no effect... heh heh... reboot -> nothing in logs Detailed information on the system and drives (outputs of smartctl -a) can be found http://www.onerussian.com/Linux/bugs/ata/ Thank you in advance for ideas P.S. was ata-dev patch incorporated in recent kernel versions so I could use SMART with vanilla kernel? -- Yaroslav Halchenko Graduate Student CS Dept. UNM, ABQ Linux User 17 - 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/
2.6.8 - 2.6.11 (+ata-dev patch) -- HDD is always on
I've been running debian stable with 2.6.8 kernel but due to recent failure of the SATA harddrive I've decided to upgrade to 2.6.11 + libata patch (2.6.11-libata-dev1.patch.gz) and recent smartmontools After everything worked out and I decided to rest in piece but I've found that HDD LED light nomater what. It seems to turn off during BIOS checks and then kicks in 1-2 secs after kernel starts booting. No prominent harddrive activity noise can be heard but this drive is quite silent so it is hard to say. SATA drivers were compiled in the kernel to don't mess with initrd. QUESTION: LED constantly ON - does it signal about a problem or may be just that some status bit is hanging? Should I worry and try differen kernel version? YIKES: ran hddtemp /dev/sda and whole box hanged... SysRq keys - no effect... heh heh... reboot - nothing in logs Detailed information on the system and drives (outputs of smartctl -a) can be found http://www.onerussian.com/Linux/bugs/ata/ Thank you in advance for ideas P.S. was ata-dev patch incorporated in recent kernel versions so I could use SMART with vanilla kernel? -- Yaroslav Halchenko Graduate Student CS Dept. UNM, ABQ Linux User 17 - 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/
tired of wireless + WEP... uff
Dear Kernel People Please advise... Long ago when I didn't use WEP I had my intenal (Network controller: Intersil Corporation: Unknown device 3872) and pcmcia belkin F5D6020 (probably version 1) working as charm wo tweeking (although I thought I had to set RTS to 256 or call cardctl reset from time to time...) Then I moved to Netgear WG511 using prism54 driver. Everything was working well till (after some of the upgrades around 2.6.7-8) it start freezing up my laptop completely. Although SysRq combination still can reboot it, nothing else works. First I thought that it has something to do with hardware (I got inside the laptop couple of times either to fix LCD or touchpad or fan) because it seem to coincide with movement of laptop -- I move it and it dies... but it died couple of times without any physical effect... also it doesn't die with other kinds of pcmcia wireless cards but died with the same model when I exchanged it... Then I switched to my internal card and I came back to issues which seems to be general for my laptop and pcmcia orinoco cards because I've tried belkin as well and after 1-2 minutes of work they start start reporting Mar 14 21:56:28 localhost kernel: eth3: Error -16 transmitting packet Mar 14 21:56:28 localhost kernel: hermes @ IO 0x100: Error -16 issuing command. syslog and cardmgr become busy as hell... laptop becomes useless... I had to take Belkin card away from slot but here are some details: (I'm running 2.6.11.3 at the moment) eth3: Station identity 001f:0003::0008 eth3: Looks like an Intersil firmware version 0.8.3 eth3: Ad-hoc demo mode supported eth3: IEEE standard IBSS ad-hoc mode supported eth3: WEP supported, 104-bit key eth3: MAC address 00:30:BD:61:20:D9 eth3: Station name "Prism I" eth3: ready eth3: index 0x01: Vcc 5.0, irq 3, io 0x0100-0x013f eth3: New link status: Connected (0001) Socket 0: product info: "Belkin", "11Mbps Wireless Notebook Network Adapter", "Version 01.02", "" manfid: 0x0156, 0x0002 function: 6 (network) Socket 0: dev_info NULL 0ns, 512b attr_dev_info SRAM 500ns, 1kb vers_1 5.0, "Belkin", "11Mbps Wireless Notebook Network Adapter", "Version 01.02", "" manfid 0x0156, 0x0002 funcid network_adapter lan_technology wireless lan_speed 1 mb/sec lan_speed 2 mb/sec lan_speed 5 mb/sec lan_speed 11 mb/sec lan_media 2.4_GHz lan_node_id 00 30 bd 61 20 d9 lan_connector Closed connector standard config base 0x03e0 mask 0x0001 last_index 0x01 cftable_entry 0x01 [default] Vcc Vmin 4750mV Vmax 5250mV Iavg 300mA Ipeak 300mA Idown 10mA io 0x-0x003f [lines=6] [16bit] irq mask 0x [level] [pulse] Please advise on where to look for reasons of this weird behavior... I want to be friendly with WEP :-) -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers Office (973) 353-5440 x263 Fax (973) 353-1171 Ph.D. Student CS Dept. NJIT - 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/
tired of wireless + WEP... uff
Dear Kernel People Please advise... Long ago when I didn't use WEP I had my intenal (Network controller: Intersil Corporation: Unknown device 3872) and pcmcia belkin F5D6020 (probably version 1) working as charm wo tweeking (although I thought I had to set RTS to 256 or call cardctl reset from time to time...) Then I moved to Netgear WG511 using prism54 driver. Everything was working well till (after some of the upgrades around 2.6.7-8) it start freezing up my laptop completely. Although SysRq combination still can reboot it, nothing else works. First I thought that it has something to do with hardware (I got inside the laptop couple of times either to fix LCD or touchpad or fan) because it seem to coincide with movement of laptop -- I move it and it dies... but it died couple of times without any physical effect... also it doesn't die with other kinds of pcmcia wireless cards but died with the same model when I exchanged it... Then I switched to my internal card and I came back to issues which seems to be general for my laptop and pcmcia orinoco cards because I've tried belkin as well and after 1-2 minutes of work they start start reporting Mar 14 21:56:28 localhost kernel: eth3: Error -16 transmitting packet Mar 14 21:56:28 localhost kernel: hermes @ IO 0x100: Error -16 issuing command. syslog and cardmgr become busy as hell... laptop becomes useless... I had to take Belkin card away from slot but here are some details: (I'm running 2.6.11.3 at the moment) eth3: Station identity 001f:0003::0008 eth3: Looks like an Intersil firmware version 0.8.3 eth3: Ad-hoc demo mode supported eth3: IEEE standard IBSS ad-hoc mode supported eth3: WEP supported, 104-bit key eth3: MAC address 00:30:BD:61:20:D9 eth3: Station name Prism I eth3: ready eth3: index 0x01: Vcc 5.0, irq 3, io 0x0100-0x013f eth3: New link status: Connected (0001) Socket 0: product info: Belkin, 11Mbps Wireless Notebook Network Adapter, Version 01.02, manfid: 0x0156, 0x0002 function: 6 (network) Socket 0: dev_info NULL 0ns, 512b attr_dev_info SRAM 500ns, 1kb vers_1 5.0, Belkin, 11Mbps Wireless Notebook Network Adapter, Version 01.02, manfid 0x0156, 0x0002 funcid network_adapter lan_technology wireless lan_speed 1 mb/sec lan_speed 2 mb/sec lan_speed 5 mb/sec lan_speed 11 mb/sec lan_media 2.4_GHz lan_node_id 00 30 bd 61 20 d9 lan_connector Closed connector standard config base 0x03e0 mask 0x0001 last_index 0x01 cftable_entry 0x01 [default] Vcc Vmin 4750mV Vmax 5250mV Iavg 300mA Ipeak 300mA Idown 10mA io 0x-0x003f [lines=6] [16bit] irq mask 0x [level] [pulse] Please advise on where to look for reasons of this weird behavior... I want to be friendly with WEP :-) -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers Office (973) 353-5440 x263 Fax (973) 353-1171 Ph.D. Student CS Dept. NJIT - 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/
wifi craziness: hermes_read_ltv(): rid (0xfd43) does not match type (0xfdc6)
Dear Developers, Since I've secured WiFi card (internal of Vaio PCG-v505ACK) using WEP I get my logs filled in with message which start appearing after putting some load on the connection (torrents) hermes @ MEM 0xf98ca000: hermes_read_ltv(): rid (0xfdc6) does not match type (0xfd44) hermes @ MEM 0xf98ca000: hermes_read_ltv(): rid (0xfd43) does not match type (0xfdc6) hermes @ MEM 0xf98ca000: Truncating LTV record from 10 to 6 bytes.(rid=0xfd43, len=0x0006) What can be a reason? I'm running the recent kernel patched with swsusp2 Details of the system (config, more messages, lspci etc) can be found http://www.onerussian.com/Linux/bugs/badwifi/ Thank you in advance -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 Student Ph.D. @ CS Dept. NJIT, Master @ CS Dept. UNM lynx -source http://www.onerussian.com/gpg-yoh.asc | gpg --import GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8 - 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/
wifi craziness: hermes_read_ltv(): rid (0xfd43) does not match type (0xfdc6)
Dear Developers, Since I've secured WiFi card (internal of Vaio PCG-v505ACK) using WEP I get my logs filled in with message which start appearing after putting some load on the connection (torrents) hermes @ MEM 0xf98ca000: hermes_read_ltv(): rid (0xfdc6) does not match type (0xfd44) hermes @ MEM 0xf98ca000: hermes_read_ltv(): rid (0xfd43) does not match type (0xfdc6) hermes @ MEM 0xf98ca000: Truncating LTV record from 10 to 6 bytes.(rid=0xfd43, len=0x0006) What can be a reason? I'm running the recent kernel patched with swsusp2 Details of the system (config, more messages, lspci etc) can be found http://www.onerussian.com/Linux/bugs/badwifi/ Thank you in advance -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 Student Ph.D. @ CS Dept. NJIT, Master @ CS Dept. UNM lynx -source http://www.onerussian.com/gpg-yoh.asc | gpg --import GPG fingerprint 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8 - 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/
