Re: 2.6.24-rc7: memory leak?
On Thu, Jan 17, 2008 at 09:22:50PM +0900, KOSAKI Motohiro wrote: > Hi > > > > > Should all this cache usage not be counted towards the > > > > 'Cached' entry in meminfo rather then getting counted as part of used > > > > ram. > > > > > > Cached is only the page-cache, not all the other caches we have.. > > > This someones confuses people, but one gets used to it. slabinfo allows > > > one to easily view others. > > > > So what would I have to do to find out the real amount of memory free? > > Would that be the MemFree field in /proc/meminfo plus, from > > /proc/slabinfo, *_cache and size-*? > > SReclaimable field can't fill requilrement? :) Ah. Hmm. *pokes about* That does seem to correspond pretty closely to what happens with the echo 3 >/proc/ Though it never seems to get to 0 (~4 meg is as close as it gets on this box) which seems to jive with what Peter said in the other email. Hmm. I think tomorrow I'll be writing free.pl and modifying my graphing and monitoring stuff to take this into account somehow. :) Thanks! -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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-rc7: memory leak?
On Thu, Jan 17, 2008 at 01:21:51PM +0100, Peter Zijlstra wrote: > > If that's the case it would seem to be somewhat of a pain to get and > > kind of out of left field as I'd say most people would expect MemFree to > > indicate the amount of memory that's no longer freely available > > (ignoring swapping it out for simplicities sake). > > I'm somewhat confused as to what you're saying. How would anyone expect > MemFree to be memory that is _not_ freely available? I think we have conflicting ideas of what 'freely available' means here which is causing the confusion. :) > Or are you asking how to compute the amount of freeable memory, that is > memory that isn't currently free, but could be freed up under pressure? Yes. I think I am. (heh) > If that is indeed your question, then yes, thats rather hard as slabinfo > and the like don't indicate which buckets have shrinkers (but even if Ah. Foo. > they would have shrinkers there is no guarantee they'd be able to shrink > 100%) Whacky. :/ -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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-rc7: memory leak?
On Thu, Jan 17, 2008 at 01:07:12PM +0100, Peter Zijlstra wrote: > On Thu, 2008-01-17 at 22:40 +1100, CaT wrote: > > > How much memory does: > > > > > > echo 3 > /proc/sys/vm/drop_caches > > > > > > gain you? > > > > 56M used now. > > Good :-) Indeed. :) > > Should all this cache usage not be counted towards the > > 'Cached' entry in meminfo rather then getting counted as part of used > > ram. > > Cached is only the page-cache, not all the other caches we have.. > This someones confuses people, but one gets used to it. slabinfo allows > one to easily view others. So what would I have to do to find out the real amount of memory free? Would that be the MemFree field in /proc/meminfo plus, from /proc/slabinfo, *_cache and size-*? If that's the case it would seem to be somewhat of a pain to get and kind of out of left field as I'd say most people would expect MemFree to indicate the amount of memory that's no longer freely available (ignoring swapping it out for simplicities sake). I'm wondering as I'm trying to monitor this stuff and I've just found out that the easily accessible values are not as useful as I previously thought. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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-rc7: memory leak?
On Thu, Jan 17, 2008 at 12:22:03PM +0100, Peter Zijlstra wrote: > On Thu, 2008-01-17 at 17:34 +1100, CaT wrote: > > cache). During the rsync the memory used grew to just shy of 1.6gig and > > now, about 2 hours after the rsync has well and truly finished, the used > > memory is at 1.23gig. This is what free reports: > > > > total used free sharedbuffers cached > > Mem: 20581281994468 63660 0 688604 11432 > > -/+ buffers/cache:1294432 763696 > > Swap: 1048568 01048568 > > How much memory does: > > echo 3 > /proc/sys/vm/drop_caches > > gain you? 56M used now. Should all this cache usage not be counted towards the 'Cached' entry in meminfo rather then getting counted as part of used ram. I assume that this would not cause an oom situation and would be freed up if all that memory really did need to be used. > > ext3_inode_cache 1235577 124056576851 : tunables 54 27 > > 8 : slabdata 248113 248113 0 > > dentry703661 749797200 191 : tunables 120 608 > > : slabdata 39463 39463 0 > > buffer_head 174535 209087104 371 : tunables 120 608 > > : slabdata 5651 5651 0 > > would get freed by doing that. They were indeed. > this one: > > > size-64 537590 850249 64 591 : tunables 120 608 > > : slabdata 14411 14411 0 > > I'm unsure about, if that one sticks around that'd be something to worry > about. See if you can monitor this value and try to determine: This went away also. > - if it ever drops > - what makes it grow (fastest) > > I guess we could stick some instrumentation in there to track that > bucket. Might help prevent upraised eyebrows or worse. :) -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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-rc7: memory leak?
On Thu, Jan 17, 2008 at 12:22:03PM +0100, Peter Zijlstra wrote: On Thu, 2008-01-17 at 17:34 +1100, CaT wrote: cache). During the rsync the memory used grew to just shy of 1.6gig and now, about 2 hours after the rsync has well and truly finished, the used memory is at 1.23gig. This is what free reports: total used free sharedbuffers cached Mem: 20581281994468 63660 0 688604 11432 -/+ buffers/cache:1294432 763696 Swap: 1048568 01048568 How much memory does: echo 3 /proc/sys/vm/drop_caches gain you? 56M used now. Should all this cache usage not be counted towards the 'Cached' entry in meminfo rather then getting counted as part of used ram. I assume that this would not cause an oom situation and would be freed up if all that memory really did need to be used. ext3_inode_cache 1235577 124056576851 : tunables 54 27 8 : slabdata 248113 248113 0 dentry703661 749797200 191 : tunables 120 608 : slabdata 39463 39463 0 buffer_head 174535 209087104 371 : tunables 120 608 : slabdata 5651 5651 0 would get freed by doing that. They were indeed. this one: size-64 537590 850249 64 591 : tunables 120 608 : slabdata 14411 14411 0 I'm unsure about, if that one sticks around that'd be something to worry about. See if you can monitor this value and try to determine: This went away also. - if it ever drops - what makes it grow (fastest) I guess we could stick some instrumentation in there to track that bucket. Might help prevent upraised eyebrows or worse. :) -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- 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-rc7: memory leak?
On Thu, Jan 17, 2008 at 01:07:12PM +0100, Peter Zijlstra wrote: On Thu, 2008-01-17 at 22:40 +1100, CaT wrote: How much memory does: echo 3 /proc/sys/vm/drop_caches gain you? 56M used now. Good :-) Indeed. :) Should all this cache usage not be counted towards the 'Cached' entry in meminfo rather then getting counted as part of used ram. Cached is only the page-cache, not all the other caches we have.. This someones confuses people, but one gets used to it. slabinfo allows one to easily view others. So what would I have to do to find out the real amount of memory free? Would that be the MemFree field in /proc/meminfo plus, from /proc/slabinfo, *_cache and size-*? If that's the case it would seem to be somewhat of a pain to get and kind of out of left field as I'd say most people would expect MemFree to indicate the amount of memory that's no longer freely available (ignoring swapping it out for simplicities sake). I'm wondering as I'm trying to monitor this stuff and I've just found out that the easily accessible values are not as useful as I previously thought. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- 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-rc7: memory leak?
On Thu, Jan 17, 2008 at 01:21:51PM +0100, Peter Zijlstra wrote: If that's the case it would seem to be somewhat of a pain to get and kind of out of left field as I'd say most people would expect MemFree to indicate the amount of memory that's no longer freely available (ignoring swapping it out for simplicities sake). I'm somewhat confused as to what you're saying. How would anyone expect MemFree to be memory that is _not_ freely available? I think we have conflicting ideas of what 'freely available' means here which is causing the confusion. :) Or are you asking how to compute the amount of freeable memory, that is memory that isn't currently free, but could be freed up under pressure? Yes. I think I am. (heh) If that is indeed your question, then yes, thats rather hard as slabinfo and the like don't indicate which buckets have shrinkers (but even if Ah. Foo. they would have shrinkers there is no guarantee they'd be able to shrink 100%) Whacky. :/ -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- 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-rc7: memory leak?
On Thu, Jan 17, 2008 at 09:22:50PM +0900, KOSAKI Motohiro wrote: Hi Should all this cache usage not be counted towards the 'Cached' entry in meminfo rather then getting counted as part of used ram. Cached is only the page-cache, not all the other caches we have.. This someones confuses people, but one gets used to it. slabinfo allows one to easily view others. So what would I have to do to find out the real amount of memory free? Would that be the MemFree field in /proc/meminfo plus, from /proc/slabinfo, *_cache and size-*? SReclaimable field can't fill requilrement? :) Ah. Hmm. *pokes about* That does seem to correspond pretty closely to what happens with the echo 3 /proc/ Though it never seems to get to 0 (~4 meg is as close as it gets on this box) which seems to jive with what Peter said in the other email. Hmm. I think tomorrow I'll be writing free.pl and modifying my graphing and monitoring stuff to take this into account somehow. :) Thanks! -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- 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.24-rc7: memory leak?
Not sure where to begin so here goes anway. Today I did an rsync backup of a server with 2million+ files. Before doing so the used memory on the server this was initiated from was under 200meg (excluding buffers and cache). During the rsync the memory used grew to just shy of 1.6gig and now, about 2 hours after the rsync has well and truly finished, the used memory is at 1.23gig. This is what free reports: total used free sharedbuffers cached Mem: 20581281994468 63660 0 688604 11432 -/+ buffers/cache:1294432 763696 Swap: 1048568 01048568 There are 75 processes on the box of which almost 47 are kernel processes + init. Of the rest, the top 3 have an RSS of 9.4meg, 6.2meg and 4.8meg, 7 are at around 2meg and the rest are below 2meg with the majority below 1. So unless I'm misunderstanding something, processess alone do not account for the amount of used memory. The destination of the rsync was an ext3 filesystem over raid5 over ahci sata. I've included /proc/meminfo, /proc/slabinfo and config.gz. If there's anything else please shout. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby slabinfo - version: 2.1 # name : tunables: slabdata ip_fib_alias 10 59 64 591 : tunables 120 608 : slabdata 1 1 0 ip_fib_hash 10 59 64 591 : tunables 120 608 : slabdata 1 1 0 raid5-md325626182492 : tunables 54 278 : slabdata 29 29 0 UNIX 5 22704 112 : tunables 54 278 : slabdata 2 2 0 xt_hashlimit 0 0 88 441 : tunables 120 608 : slabdata 0 0 0 flow_cache 0 0128 301 : tunables 120 608 : slabdata 0 0 0 dm_snap_pending_exception128136112 341 : tunables 120 60 8 : slabdata 4 4 0 dm_snap_exception 0 0 32 1121 : tunables 120 608 : slabdata 0 0 0 dm_crypt_io0 0 56 671 : tunables 120 608 : slabdata 0 0 0 dm_uevent 0 0 260832 : tunables 24 128 : slabdata 0 0 0 dm_target_io 827864 24 1441 : tunables 120 608 : slabdata 6 6 0 dm_io826828 40 921 : tunables 120 608 : slabdata 9 9 0 scsi_cmd_cache50 50384 101 : tunables 54 278 : slabdata 5 5 0 cfq_io_context92225152 251 : tunables 120 608 : slabdata 9 9 0 cfq_queue 98224136 281 : tunables 120 608 : slabdata 8 8 0 bsg_cmd0 0312 121 : tunables 54 278 : slabdata 0 0 0 mqueue_inode_cache 1 489641 : tunables 54 278 : slabdata 1 1 0 udf_inode_cache0 065661 : tunables 54 278 : slabdata 0 0 0 isofs_inode_cache 0 063261 : tunables 54 278 : slabdata 0 0 0 fat_inode_cache0 066461 : tunables 54 278 : slabdata 0 0 0 fat_cache 0 0 32 1121 : tunables 120 608 : slabdata 0 0 0 ext2_inode_cache 0 075251 : tunables 54 278 : slabdata 0 0 0 journal_handle32144 24 1441 : tunables 120 608 : slabdata 1 1 0 journal_head 129200 96 401 : tunables 120 608 : slabdata 5 5 0 revoke_table 10202 16 2021 : tunables 120 608 : slabdata 1 1 0 revoke_record 0 0 32 1121 : tunables 120 608 : slabdata 0 0 0 ext3_inode_cache 1235577 124056576851 : tunables 54 278 : slabdata 248113 248113 0 dnotify_cache 0 0 40 921 : tunables 120 608 : slabdata 0 0 0 inotify_event_cache 0 0 40 921 : tunables 120 608 : slabdata 0 0 0 inotify_watch_cache 0 0 72 531 : tunables 120 608 : slabdata 0 0 0 kioctx 0 0320 121 : tunables 54 278 : slabdata 0 0 0 kiocb 0 0256 151 : tunables 120 608 : slabdata 0 0 0 fasync_cache 0 0 24 1441 : tunables 120 608 : slabdata 0 0 0 shmem_inode_cache 6 1577651 : tunables 54
2.6.24-rc7: memory leak?
Not sure where to begin so here goes anway. Today I did an rsync backup of a server with 2million+ files. Before doing so the used memory on the server this was initiated from was under 200meg (excluding buffers and cache). During the rsync the memory used grew to just shy of 1.6gig and now, about 2 hours after the rsync has well and truly finished, the used memory is at 1.23gig. This is what free reports: total used free sharedbuffers cached Mem: 20581281994468 63660 0 688604 11432 -/+ buffers/cache:1294432 763696 Swap: 1048568 01048568 There are 75 processes on the box of which almost 47 are kernel processes + init. Of the rest, the top 3 have an RSS of 9.4meg, 6.2meg and 4.8meg, 7 are at around 2meg and the rest are below 2meg with the majority below 1. So unless I'm misunderstanding something, processess alone do not account for the amount of used memory. The destination of the rsync was an ext3 filesystem over raid5 over ahci sata. I've included /proc/meminfo, /proc/slabinfo and config.gz. If there's anything else please shout. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby slabinfo - version: 2.1 # nameactive_objs num_objs objsize objperslab pagesperslab : tunables limit batchcount sharedfactor : slabdata active_slabs num_slabs sharedavail ip_fib_alias 10 59 64 591 : tunables 120 608 : slabdata 1 1 0 ip_fib_hash 10 59 64 591 : tunables 120 608 : slabdata 1 1 0 raid5-md325626182492 : tunables 54 278 : slabdata 29 29 0 UNIX 5 22704 112 : tunables 54 278 : slabdata 2 2 0 xt_hashlimit 0 0 88 441 : tunables 120 608 : slabdata 0 0 0 flow_cache 0 0128 301 : tunables 120 608 : slabdata 0 0 0 dm_snap_pending_exception128136112 341 : tunables 120 60 8 : slabdata 4 4 0 dm_snap_exception 0 0 32 1121 : tunables 120 608 : slabdata 0 0 0 dm_crypt_io0 0 56 671 : tunables 120 608 : slabdata 0 0 0 dm_uevent 0 0 260832 : tunables 24 128 : slabdata 0 0 0 dm_target_io 827864 24 1441 : tunables 120 608 : slabdata 6 6 0 dm_io826828 40 921 : tunables 120 608 : slabdata 9 9 0 scsi_cmd_cache50 50384 101 : tunables 54 278 : slabdata 5 5 0 cfq_io_context92225152 251 : tunables 120 608 : slabdata 9 9 0 cfq_queue 98224136 281 : tunables 120 608 : slabdata 8 8 0 bsg_cmd0 0312 121 : tunables 54 278 : slabdata 0 0 0 mqueue_inode_cache 1 489641 : tunables 54 278 : slabdata 1 1 0 udf_inode_cache0 065661 : tunables 54 278 : slabdata 0 0 0 isofs_inode_cache 0 063261 : tunables 54 278 : slabdata 0 0 0 fat_inode_cache0 066461 : tunables 54 278 : slabdata 0 0 0 fat_cache 0 0 32 1121 : tunables 120 608 : slabdata 0 0 0 ext2_inode_cache 0 075251 : tunables 54 278 : slabdata 0 0 0 journal_handle32144 24 1441 : tunables 120 608 : slabdata 1 1 0 journal_head 129200 96 401 : tunables 120 608 : slabdata 5 5 0 revoke_table 10202 16 2021 : tunables 120 608 : slabdata 1 1 0 revoke_record 0 0 32 1121 : tunables 120 608 : slabdata 0 0 0 ext3_inode_cache 1235577 124056576851 : tunables 54 278 : slabdata 248113 248113 0 dnotify_cache 0 0 40 921 : tunables 120 608 : slabdata 0 0 0 inotify_event_cache 0 0 40 921 : tunables 120 608 : slabdata 0 0 0 inotify_watch_cache 0 0 72 531 : tunables 120 608 : slabdata 0 0 0 kioctx 0 0320 121 : tunables 54 278 : slabdata 0 0 0 kiocb 0 0256 151 : tunables 120 608 : slabdata 0 0 0 fasync_cache 0 0 24 1441 : tunables 120
Re: 2.6.22.15: kernel processes stuck in D state
On Sat, Jan 12, 2008 at 09:15:16AM +1100, CaT wrote: > On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote: > > CaT wrote: > > > Not sure what other info to provide > > > > Is the bug present in 2.6.24-rc7? > > Can't rightly say. I didn't try it before because 2.6.23 fails to > compile under debian sarge. 2.6.24-rc7 did compile but it has failed to > come back up. Don't know why as the box is remote (though it wasn't in > use again yet due to the afore mentioned problems so this is merely an > annoyance). I'll find out more on Monday. Ok. Not sure why it didn't boot the first time (black screen) but it booted the second time. This time both CPUs got initialised and are in use, no kernel oops during init and no kernel processes stuck in D state. Should've tried .24 earlier but .23 failed to compile under sarge due to a buggy binutils so I figured .24 would too. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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.22.15: kernel processes stuck in D state
On Sat, Jan 12, 2008 at 09:15:16AM +1100, CaT wrote: On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote: CaT wrote: Not sure what other info to provide Is the bug present in 2.6.24-rc7? Can't rightly say. I didn't try it before because 2.6.23 fails to compile under debian sarge. 2.6.24-rc7 did compile but it has failed to come back up. Don't know why as the box is remote (though it wasn't in use again yet due to the afore mentioned problems so this is merely an annoyance). I'll find out more on Monday. Ok. Not sure why it didn't boot the first time (black screen) but it booted the second time. This time both CPUs got initialised and are in use, no kernel oops during init and no kernel processes stuck in D state. Should've tried .24 earlier but .23 failed to compile under sarge due to a buggy binutils so I figured .24 would too. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- 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.22.15: kernel processes stuck in D state
On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote: > CaT wrote: > > Not sure what other info to provide > > Is the bug present in 2.6.24-rc7? Can't rightly say. I didn't try it before because 2.6.23 fails to compile under debian sarge. 2.6.24-rc7 did compile but it has failed to come back up. Don't know why as the box is remote (though it wasn't in use again yet due to the afore mentioned problems so this is merely an annoyance). I'll find out more on Monday. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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.22.15: kernel processes stuck in D state
On Fri, Jan 11, 2008 at 07:12:33PM +1100, CaT wrote: > I recently upgraded from an amd 64bit system to an intel one and changed my > kernekl accordingly. Everything's great except this: > > root 6 0.0 0.0 00 ?D< 17:11 0:00 [migration/1] > root 7 0.0 0.0 00 ?D< 17:11 0:00 [ksoftirqd/1] > root 8 0.0 0.0 00 ?D< 17:11 0:00 [watchdog/1] > > I've tried various kernel configs and that stays the same, including a > constant load of 3. My current kernel config and dmesg is attached > (compressed as I think the ml limit is 40k). > > Not sure what other info to provide so if anything else would be > helpful, please shout. I'm just taking a closer look at things now that I've recovered from spending a day in a nice, loud server room and things are popping up that make me wonder if 2.6.22.15 is just too old for this motherboard. > MPTABLE: OEM ID: OEM0 MPTABLE: Product ID: PROD MPTABLE: APIC at: > 0xFEE0 > Processor #0 (Bootup-CPU) > Processor #1 > I/O APIC #4 at 0xFEC0. > Setting APIC routing to flat > Processors: 2 As it should be. Dual core. > Booting processor 1/2 APIC 0x1 > Not responding. > Inquiring remote APIC #1... > ... APIC #1 ID: failed > ... APIC #1 VERSION: failed > ... APIC #1 SPIV: failed > Brought up 1 CPUs Ook? Shouldn't that be 2? Infact, /proc/cpuinfo confirms this. I only have one core up. > Initializing CPU#1 ... > Kernel panic - not syncing: smp_callin: CPU1 started up but did not get a > callout! Eek! This doesn't look so good. So I now have a nice, brand new, spiffy motherboard and a dual core cpu... with one core not in use, a weird panic relating to CPUs and kernel processes hung in D state. Whee! :) -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby -- 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.22.15: kernel processes stuck in D state
I recently upgraded from an amd 64bit system to an intel one and changed my kernekl accordingly. Everything's great except this: root 6 0.0 0.0 00 ?D< 17:11 0:00 [migration/1] root 7 0.0 0.0 00 ?D< 17:11 0:00 [ksoftirqd/1] root 8 0.0 0.0 00 ?D< 17:11 0:00 [watchdog/1] I've tried various kernel configs and that stays the same, including a constant load of 3. My current kernel config and dmesg is attached (compressed as I think the ml limit is 40k). Not sure what other info to provide so if anything else would be helpful, please shout. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby config.gz Description: Binary data dmesg.gz Description: Binary data
2.6.22.15: kernel processes stuck in D state
I recently upgraded from an amd 64bit system to an intel one and changed my kernekl accordingly. Everything's great except this: root 6 0.0 0.0 00 ?D 17:11 0:00 [migration/1] root 7 0.0 0.0 00 ?D 17:11 0:00 [ksoftirqd/1] root 8 0.0 0.0 00 ?D 17:11 0:00 [watchdog/1] I've tried various kernel configs and that stays the same, including a constant load of 3. My current kernel config and dmesg is attached (compressed as I think the ml limit is 40k). Not sure what other info to provide so if anything else would be helpful, please shout. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby config.gz Description: Binary data dmesg.gz Description: Binary data
Re: 2.6.22.15: kernel processes stuck in D state
On Fri, Jan 11, 2008 at 07:12:33PM +1100, CaT wrote: I recently upgraded from an amd 64bit system to an intel one and changed my kernekl accordingly. Everything's great except this: root 6 0.0 0.0 00 ?D 17:11 0:00 [migration/1] root 7 0.0 0.0 00 ?D 17:11 0:00 [ksoftirqd/1] root 8 0.0 0.0 00 ?D 17:11 0:00 [watchdog/1] I've tried various kernel configs and that stays the same, including a constant load of 3. My current kernel config and dmesg is attached (compressed as I think the ml limit is 40k). Not sure what other info to provide so if anything else would be helpful, please shout. I'm just taking a closer look at things now that I've recovered from spending a day in a nice, loud server room and things are popping up that make me wonder if 2.6.22.15 is just too old for this motherboard. MPTABLE: OEM ID: OEM0 MPTABLE: Product ID: PROD MPTABLE: APIC at: 0xFEE0 Processor #0 (Bootup-CPU) Processor #1 I/O APIC #4 at 0xFEC0. Setting APIC routing to flat Processors: 2 As it should be. Dual core. Booting processor 1/2 APIC 0x1 Not responding. Inquiring remote APIC #1... ... APIC #1 ID: failed ... APIC #1 VERSION: failed ... APIC #1 SPIV: failed Brought up 1 CPUs Ook? Shouldn't that be 2? Infact, /proc/cpuinfo confirms this. I only have one core up. Initializing CPU#1 ... Kernel panic - not syncing: smp_callin: CPU1 started up but did not get a callout! Eek! This doesn't look so good. So I now have a nice, brand new, spiffy motherboard and a dual core cpu... with one core not in use, a weird panic relating to CPUs and kernel processes hung in D state. Whee! :) -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- 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.22.15: kernel processes stuck in D state
On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote: CaT wrote: Not sure what other info to provide Is the bug present in 2.6.24-rc7? Can't rightly say. I didn't try it before because 2.6.23 fails to compile under debian sarge. 2.6.24-rc7 did compile but it has failed to come back up. Don't know why as the box is remote (though it wasn't in use again yet due to the afore mentioned problems so this is merely an annoyance). I'll find out more on Monday. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby -- 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] [13/45] x86_64: Increase VDSO_TEXT_OFFSET for ancient binutils
On Fri, Sep 21, 2007 at 10:44:54PM +0200, Andi Kleen wrote: > For some reason old binutils genertate larger headers so > increase the text offset of the vdso to avoid linker errors. > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > > --- > arch/x86_64/vdso/voffset.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux/arch/x86_64/vdso/voffset.h > === > --- linux.orig/arch/x86_64/vdso/voffset.h > +++ linux/arch/x86_64/vdso/voffset.h > @@ -1 +1 @@ > -#define VDSO_TEXT_OFFSET 0x500 > +#define VDSO_TEXT_OFFSET 0x600 This still breaks under Debian sarge. There is this (german) forum thread about it: http://www.debianforum.de/forum/viewtopic.php?p=570102 Robotic english translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.debianforum.de%2Fforum%2Fviewtopic.php%3Fp%3D569756%26sid%3D20278bfd231c5dac45fa0f2763c7ec54%23569756=de%7Cen=en=UTF-8 And it indicates that 0x510 would be the better offset due to 0x600 making it clash with the data section beneath. Indeed when I change it to 0x510 I can compile the kernel with binutils 2.15-6. I'm hoping this wont cause the kernel to eat my grandma. :) -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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] [13/45] x86_64: Increase VDSO_TEXT_OFFSET for ancient binutils
On Fri, Sep 21, 2007 at 10:44:54PM +0200, Andi Kleen wrote: For some reason old binutils genertate larger headers so increase the text offset of the vdso to avoid linker errors. Signed-off-by: Andi Kleen [EMAIL PROTECTED] --- arch/x86_64/vdso/voffset.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/arch/x86_64/vdso/voffset.h === --- linux.orig/arch/x86_64/vdso/voffset.h +++ linux/arch/x86_64/vdso/voffset.h @@ -1 +1 @@ -#define VDSO_TEXT_OFFSET 0x500 +#define VDSO_TEXT_OFFSET 0x600 This still breaks under Debian sarge. There is this (german) forum thread about it: http://www.debianforum.de/forum/viewtopic.php?p=570102 Robotic english translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.debianforum.de%2Fforum%2Fviewtopic.php%3Fp%3D569756%26sid%3D20278bfd231c5dac45fa0f2763c7ec54%23569756langpair=de%7Cenhl=enie=UTF-8 And it indicates that 0x510 would be the better offset due to 0x600 making it clash with the data section beneath. Indeed when I change it to 0x510 I can compile the kernel with binutils 2.15-6. I'm hoping this wont cause the kernel to eat my grandma. :) -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: Kernel utf-8 handling
On Fri, Jun 01, 2007 at 04:20:58PM +0200, DervishD wrote: > This said, I know that the console will give me no problems > regarding character representantion (heck, I'm pretty sure that I will > be able to use even the same font I'm using right now in the console if > I get the proper unicode map), but probably will give me problems when > *entering* characters. I've read that the kernel handles accented chars, > and things like '?' (ntilde) because it assumes that any composed > character (composed using dead keys, for example) is in the latin1 > range. While this is not a perfect behaviour, it will work for me. Hmmm. I've not yet played with moving to utf-8 but would man console_codes be of help to you? -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: Kernel utf-8 handling
On Fri, Jun 01, 2007 at 04:20:58PM +0200, DervishD wrote: This said, I know that the console will give me no problems regarding character representantion (heck, I'm pretty sure that I will be able to use even the same font I'm using right now in the console if I get the proper unicode map), but probably will give me problems when *entering* characters. I've read that the kernel handles accented chars, and things like '?' (ntilde) because it assumes that any composed character (composed using dead keys, for example) is in the latin1 range. While this is not a perfect behaviour, it will work for me. Hmmm. I've not yet played with moving to utf-8 but would man console_codes be of help to you? -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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] LogFS take three
On Wed, May 16, 2007 at 03:53:19PM +0200, J??rn Engel wrote: > Imo they all suck. LogFS also sucks, but it allows me to make a stupid > joke and keep my logfs.org domain. Well if stupid jokes are a goer there's always gordonfs. :) *hides* -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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] LogFS take three
On Wed, May 16, 2007 at 01:50:03PM +0200, J??rn Engel wrote: > On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote: > > > > But if akpm can't pronounce it, how about FFFS for faster flash > > filesystem ;-) > > How many of you have worked for IBM before? Vowels are not evil. ;) > > Grouping four or more consonants to name anything will cause similar > expressions on people's faces. Numbers don't help much either. > > Ext2 is a great name, because "ext" actually is a pronouncable syllable. > MinixFS, ChunkFS, TileFS are great too. XFS and JFS are ok, at least > they only have three consonants. But FFS exists, so I'd rather go for a > syllable. FlashFS? -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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] LogFS take three
On Wed, May 16, 2007 at 01:50:03PM +0200, J??rn Engel wrote: On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote: But if akpm can't pronounce it, how about FFFS for faster flash filesystem ;-) How many of you have worked for IBM before? Vowels are not evil. ;) Grouping four or more consonants to name anything will cause similar expressions on people's faces. Numbers don't help much either. Ext2 is a great name, because ext actually is a pronouncable syllable. MinixFS, ChunkFS, TileFS are great too. XFS and JFS are ok, at least they only have three consonants. But FFS exists, so I'd rather go for a syllable. FlashFS? -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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] LogFS take three
On Wed, May 16, 2007 at 03:53:19PM +0200, J??rn Engel wrote: Imo they all suck. LogFS also sucks, but it allows me to make a stupid joke and keep my logfs.org domain. Well if stupid jokes are a goer there's always gordonfs. :) *hides* -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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/8] Universal power supply class (was: battery class)
On Thu, May 03, 2007 at 03:53:46PM -0700, Greg KH wrote: > > # cat /sys/class/power\ supply/ > > ac/ main-battery/ usb/ > > Um, shouldn't that be an error? Isn't /sys/class/power\ supply/ a > directory? I think that's more of a case of: cat /sys/class/power\ supply/ -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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/8] Universal power supply class (was: battery class)
On Thu, May 03, 2007 at 03:53:46PM -0700, Greg KH wrote: # cat /sys/class/power\ supply/ ac/ main-battery/ usb/ Um, shouldn't that be an error? Isn't /sys/class/power\ supply/ a directory? I think that's more of a case of: cat /sys/class/power\ supply/tabtab -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Mon, Apr 16, 2007 at 12:10:51PM -0700, Michael Chan wrote: > On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote: > > > I also like Andi's idea of using change_page_attr() to isolate the > > problem. I'll try to send you a debug patch in the next few days to try > > that out. Thanks. > > Here's the debug patch for x86 only that will change the statistics > memory block to read-only. If the kernel is corrupting it, you should > get a page fault that will crash the system. If you continue to see > bogus counters, it is definitely a firmware or hardware problem. Please > try it and let me know. Thanks. Ahh. Would truly love to but the moment you said 'crash the system' I had to bail. These boxes are in production and as such a crash would be, shall we say, unwelcome. I might be able to fenagle something but I very-much doubt it. Perhaps Jean-Daniel, who is also experiencing this problem and seemingly more frequently then I, has a box that he could run your patch on. I think we both run pretty-much the same hardware (Dell [12]950s). I've CCed him. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Mon, Apr 16, 2007 at 12:10:51PM -0700, Michael Chan wrote: On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote: I also like Andi's idea of using change_page_attr() to isolate the problem. I'll try to send you a debug patch in the next few days to try that out. Thanks. Here's the debug patch for x86 only that will change the statistics memory block to read-only. If the kernel is corrupting it, you should get a page fault that will crash the system. If you continue to see bogus counters, it is definitely a firmware or hardware problem. Please try it and let me know. Thanks. Ahh. Would truly love to but the moment you said 'crash the system' I had to bail. These boxes are in production and as such a crash would be, shall we say, unwelcome. I might be able to fenagle something but I very-much doubt it. Perhaps Jean-Daniel, who is also experiencing this problem and seemingly more frequently then I, has a box that he could run your patch on. I think we both run pretty-much the same hardware (Dell [12]950s). I've CCed him. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Thu, Apr 12, 2007 at 04:18:24PM -0700, Roland Dreier wrote: > > > Apr 11 22:14:02 ' eth0:220898233988841368 66750274000 0 > > > 0 86458738 52386430545 101089219 19931300 0 199313 > > > 0 ' > > > > Apr 11 22:15:02 ' eth0:17227454818 81381144000 0 > > > 0 0 33091307388 86658381000 0 0 0 > > > ' > > > But in fact I think you're saying that the numbers go bad, and then stay > > bad. > > Doesn't look like it -- one minute after the first hiccup the eth0 #s > look reasonable again. Yeah. Sorry for not making it clear. I included good values on either side of the bad one. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Mon, Apr 02, 2007 at 12:13:00AM -0700, Andrew Morton wrote: > On Mon, 2 Apr 2007 11:43:19 +1000 CaT <[EMAIL PROTECTED]> wrote: > > > I take minute by minute snapshots of network traffic by sampling > > /proc/net/dev and most of the time everything works fine. Occasionally > > though I get petabyte byte traffic and corresponding packet traffic. > > How frequently? > > Are you able to provide some actual numbers (expected and actual values), > so we can look at the bit patterns? I have some now. These are raw lines from /proc/net/dev. In this case it's eth0 at 22:14 that chucked a wee wibbly. Apr 11 22:13:02 ' eth0:17227166357 81379716000 0 0 0 33090495625 86656584000 0 0 0 ' Apr 11 22:13:02 ' eth1:30708022097 91219466000 0 0 0 122989582024 125073786000 0 0 0 ' Apr 11 22:14:02 ' eth0:220898233988841368 66750274000 0 0 86458738 52386430545 101089219 19931300 0 199313 0 ' Apr 11 22:14:02 ' eth1:30708307787 91220183000 0 0 0 122989665004 125074344000 0 0 0 ' Apr 11 22:15:02 ' eth0:17227454818 81381144000 0 0 0 33091307388 86658381000 0 0 0 ' Apr 11 22:15:02 ' eth1:30708569308 91220742000 0 0 0 122989732601 125074712000 0 0 0 ' On another server (same hardware except for 2ru case, more ram and more hds): Apr 9 06:18:05 ' eth0:1556640056941 3598105481000 0 0 0 2281147324747 3318270401000 0 0 0 ' Apr 9 06:18:05 ' eth1:912389249044 1190286687000 0 0 0 642943095469 991257887000 0 0 0 ' Apr 9 06:19:04 ' eth0:14250798570591813804 2284720007938 1863800 18638 0 27375938 1556640980159 3345714490000 0 0 0 ' Apr 9 06:19:04 ' eth1:912389281939 1190287072000 0 0 0 642943219035 991258183000 0 0 0 ' Apr 9 06:20:05 ' eth0:1556643514710 3598121584000 0 0 0 2281154391794 3318284878000 0 0 0 ' Apr 9 06:20:05 ' eth1:912389305767 1190287354000 0 0 0 642943273879 991258351000 0 0 0 ' > > This happens on an AMD64, dual core smp box with Broadcom NetXtreme II > > nics. > > What driver drivers that? b44.c? To clarify it's an Intel Dual Core Xeon (I just wound up as thinking of them all as amd64s). Network card driver in use is the one defined by CONFIG_BNX2. Kernel's monolithic. > We do perform racy 64-bit updates of some of the stats counters. But > that'll only affect 32-bit kernels and I'm assuming you're running a 64-bit > kernel on that AMD64 box (are you?) Yes. With 32bit compat for executables built in. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Mon, Apr 02, 2007 at 12:13:00AM -0700, Andrew Morton wrote: On Mon, 2 Apr 2007 11:43:19 +1000 CaT [EMAIL PROTECTED] wrote: I take minute by minute snapshots of network traffic by sampling /proc/net/dev and most of the time everything works fine. Occasionally though I get petabyte byte traffic and corresponding packet traffic. How frequently? Are you able to provide some actual numbers (expected and actual values), so we can look at the bit patterns? I have some now. These are raw lines from /proc/net/dev. In this case it's eth0 at 22:14 that chucked a wee wibbly. Apr 11 22:13:02 ' eth0:17227166357 81379716000 0 0 0 33090495625 86656584000 0 0 0 ' Apr 11 22:13:02 ' eth1:30708022097 91219466000 0 0 0 122989582024 125073786000 0 0 0 ' Apr 11 22:14:02 ' eth0:220898233988841368 66750274000 0 0 86458738 52386430545 101089219 19931300 0 199313 0 ' Apr 11 22:14:02 ' eth1:30708307787 91220183000 0 0 0 122989665004 125074344000 0 0 0 ' Apr 11 22:15:02 ' eth0:17227454818 81381144000 0 0 0 33091307388 86658381000 0 0 0 ' Apr 11 22:15:02 ' eth1:30708569308 91220742000 0 0 0 122989732601 125074712000 0 0 0 ' On another server (same hardware except for 2ru case, more ram and more hds): Apr 9 06:18:05 ' eth0:1556640056941 3598105481000 0 0 0 2281147324747 3318270401000 0 0 0 ' Apr 9 06:18:05 ' eth1:912389249044 1190286687000 0 0 0 642943095469 991257887000 0 0 0 ' Apr 9 06:19:04 ' eth0:14250798570591813804 2284720007938 1863800 18638 0 27375938 1556640980159 3345714490000 0 0 0 ' Apr 9 06:19:04 ' eth1:912389281939 1190287072000 0 0 0 642943219035 991258183000 0 0 0 ' Apr 9 06:20:05 ' eth0:1556643514710 3598121584000 0 0 0 2281154391794 3318284878000 0 0 0 ' Apr 9 06:20:05 ' eth1:912389305767 1190287354000 0 0 0 642943273879 991258351000 0 0 0 ' This happens on an AMD64, dual core smp box with Broadcom NetXtreme II nics. What driver drivers that? b44.c? To clarify it's an Intel Dual Core Xeon (I just wound up as thinking of them all as amd64s). Network card driver in use is the one defined by CONFIG_BNX2. Kernel's monolithic. We do perform racy 64-bit updates of some of the stats counters. But that'll only affect 32-bit kernels and I'm assuming you're running a 64-bit kernel on that AMD64 box (are you?) Yes. With 32bit compat for executables built in. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Thu, Apr 12, 2007 at 04:18:24PM -0700, Roland Dreier wrote: Apr 11 22:14:02 ' eth0:220898233988841368 66750274000 0 0 86458738 52386430545 101089219 19931300 0 199313 0 ' Apr 11 22:15:02 ' eth0:17227454818 81381144000 0 0 0 33091307388 86658381000 0 0 0 ' But in fact I think you're saying that the numbers go bad, and then stay bad. Doesn't look like it -- one minute after the first hiccup the eth0 #s look reasonable again. Yeah. Sorry for not making it clear. I included good values on either side of the bad one. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: I give up
On Mon, Apr 09, 2007 at 11:34:44PM -0400, Gene Heskett wrote: > I haven't seen any 200GB for $55 yet, more like $129 & maybe a rebate at > Circuit City. We don't have a Fry's around here. Wow. 200GB HDs can be had for AUD91 here. I think you need to shop around. The internet can be your friend. :) -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: I give up
On Mon, Apr 09, 2007 at 11:34:44PM -0400, Gene Heskett wrote: I haven't seen any 200GB for $55 yet, more like $129 maybe a rebate at Circuit City. We don't have a Fry's around here. Wow. 200GB HDs can be had for AUD91 here. I think you need to shop around. The internet can be your friend. :) -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Mon, Apr 02, 2007 at 12:13:00AM -0700, Andrew Morton wrote: > On Mon, 2 Apr 2007 11:43:19 +1000 CaT <[EMAIL PROTECTED]> wrote: > > > I take minute by minute snapshots of network traffic by sampling > > /proc/net/dev and most of the time everything works fine. Occasionally > > though I get petabyte byte traffic and corresponding packet traffic. > > How frequently? I can count about 6 over the past month. > Are you able to provide some actual numbers (expected and actual values), > so we can look at the bit patterns? I have them in an rrd file. I think though that the numbers will be 'adjusted' to fit in with the timekeeping. The logging code I've added should provide exact numbers as it'll just dump what it reads from /proc into syslog. > > This happens on an AMD64, dual core smp box with Broadcom NetXtreme II > > nics. > > What driver drivers that? b44.c? bnx2 > > The issue happens with both nics but at different times. The same > > sampling code runs on p4 boxes with ht on and e1000 nics without issues > > so I don't believe it's an issue with my code (famous last words :) > > which just does an re to extract the data on a per-line basis and prints > > it out. Still, I'll be adding code to log any big readings and hopefully > > it'll happen again sooner rather then later. > > > > There is no preemption involved and the kernel is a monolythic build of > > 2.6.19.[12] (there are two servers). > > We do perform racy 64-bit updates of some of the stats counters. But > that'll only affect 32-bit kernels and I'm assuming you're running a 64-bit > kernel on that AMD64 box (are you?) Correct. The environment is 64bit clean, though the kernel is compiled with 32bit support so that I can run static 32bit binaries if need be. > Plus it's odd that both the byte-counters and the packet-counters go wonky > at the same time. If you want I can toss you the rrd graphs that result from the data. The values do not appear to be static. For example, the resent 2 hits (within 10 minutes of each other) gave almost 3petabytes and just over 4 petabytes. Interesting is that the incoming data is driven upto petabytes whilst the outgoing data hits megabytes at that point. This is consistant and the server is generally quiet. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: intermittant petabyte usage reported with broadcom nic
On Mon, Apr 02, 2007 at 12:13:00AM -0700, Andrew Morton wrote: On Mon, 2 Apr 2007 11:43:19 +1000 CaT [EMAIL PROTECTED] wrote: I take minute by minute snapshots of network traffic by sampling /proc/net/dev and most of the time everything works fine. Occasionally though I get petabyte byte traffic and corresponding packet traffic. How frequently? I can count about 6 over the past month. Are you able to provide some actual numbers (expected and actual values), so we can look at the bit patterns? I have them in an rrd file. I think though that the numbers will be 'adjusted' to fit in with the timekeeping. The logging code I've added should provide exact numbers as it'll just dump what it reads from /proc into syslog. This happens on an AMD64, dual core smp box with Broadcom NetXtreme II nics. What driver drivers that? b44.c? bnx2 The issue happens with both nics but at different times. The same sampling code runs on p4 boxes with ht on and e1000 nics without issues so I don't believe it's an issue with my code (famous last words :) which just does an re to extract the data on a per-line basis and prints it out. Still, I'll be adding code to log any big readings and hopefully it'll happen again sooner rather then later. There is no preemption involved and the kernel is a monolythic build of 2.6.19.[12] (there are two servers). We do perform racy 64-bit updates of some of the stats counters. But that'll only affect 32-bit kernels and I'm assuming you're running a 64-bit kernel on that AMD64 box (are you?) Correct. The environment is 64bit clean, though the kernel is compiled with 32bit support so that I can run static 32bit binaries if need be. Plus it's odd that both the byte-counters and the packet-counters go wonky at the same time. If you want I can toss you the rrd graphs that result from the data. The values do not appear to be static. For example, the resent 2 hits (within 10 minutes of each other) gave almost 3petabytes and just over 4 petabytes. Interesting is that the incoming data is driven upto petabytes whilst the outgoing data hits megabytes at that point. This is consistant and the server is generally quiet. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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/
intermittant petabyte usage reported with broadcom nic
I take minute by minute snapshots of network traffic by sampling /proc/net/dev and most of the time everything works fine. Occasionally though I get petabyte byte traffic and corresponding packet traffic. This happens on an AMD64, dual core smp box with Broadcom NetXtreme II nics. The issue happens with both nics but at different times. The same sampling code runs on p4 boxes with ht on and e1000 nics without issues so I don't believe it's an issue with my code (famous last words :) which just does an re to extract the data on a per-line basis and prints it out. Still, I'll be adding code to log any big readings and hopefully it'll happen again sooner rather then later. There is no preemption involved and the kernel is a monolythic build of 2.6.19.[12] (there are two servers). -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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/
intermittant petabyte usage reported with broadcom nic
I take minute by minute snapshots of network traffic by sampling /proc/net/dev and most of the time everything works fine. Occasionally though I get petabyte byte traffic and corresponding packet traffic. This happens on an AMD64, dual core smp box with Broadcom NetXtreme II nics. The issue happens with both nics but at different times. The same sampling code runs on p4 boxes with ht on and e1000 nics without issues so I don't believe it's an issue with my code (famous last words :) which just does an re to extract the data on a per-line basis and prints it out. Still, I'll be adding code to log any big readings and hopefully it'll happen again sooner rather then later. There is no preemption involved and the kernel is a monolythic build of 2.6.19.[12] (there are two servers). -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: IT8212/ITE RAID
On Sun, Aug 14, 2005 at 02:33:05PM +0100, Alan Cox wrote: > On Sul, 2005-08-14 at 13:44 +0100, Daniel Drake wrote: > > > [227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, > > > CHS=24321/255/63, BUG > > Thats probably the fact other patches from -ac are missing in base. It > should be harmless. Just remembered that I was seeing the above with 11ac7 aswell. -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: IT8212/ITE RAID
On Sun, Aug 14, 2005 at 02:33:05PM +0100, Alan Cox wrote: On Sul, 2005-08-14 at 13:44 +0100, Daniel Drake wrote: [227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG Thats probably the fact other patches from -ac are missing in base. It should be harmless. Just remembered that I was seeing the above with 11ac7 aswell. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: IT8212/ITE RAID
On Sun, Aug 14, 2005 at 02:33:05PM +0100, Alan Cox wrote: > What does a full identify data set for the drive look like ? Here it is for the two drives. Please note that multisect was turned on manually as well as the security freeze. /dev/hda: ATA device, with non-removable media Model Number: ST3200822A Serial Number: 3LJ22Y8F Firmware Revision: 3.01 Standards: Used: ATA/ATAPI-6 T13 1410D revision 2 Supported: 6 5 4 3 Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors:4128705 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 390721968 device size with M = 1024*1024: 190782 MBytes device size with M = 1000*1000: 200049 MBytes (200 GB) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 4 Queue depth: 1 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns Commands/features: Enabled Supported: *READ BUFFER cmd *WRITE BUFFER cmd *Host Protected Area feature set *Look-ahead *Write cache *Power Management feature set Security Mode feature set *FLUSH CACHE EXT command *Mandatory FLUSH CACHE command *48-bit Address feature set SET MAX security extension Security: supported not enabled not locked frozen not expired: security count not supported: enhanced erase HW reset results: CBLID- above Vih Device num = 0 determined by CSEL Checksum: correct /dev/hdc: ATA device, with non-removable media powers-up in standby; SET FEATURES subcmd spins-up. Model Number: IC35L060AVV207-0 Serial Number: VNVB01G2RAK8XH Firmware Revision: V22OA63A Standards: Used: ATA/ATAPI-6 T13 1410D revision 3a Supported: 6 5 4 3 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 120103200 LBA48 user addressable sectors: 120103200 device size with M = 1024*1024: 58644 MBytes device size with M = 1000*1000: 61492 MBytes (61 GB) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 52 Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Advanced power management level: unknown setting (0x) Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns Commands/features: Enabled Supported: *NOP cmd *READ BUFFER cmd *WRITE BUFFER cmd *Host Protected Area feature set Release interrupt *Look-ahead *Write cache *Power Management feature set Security Mode feature set *FLUSH CACHE EXT command *Mandatory FLUSH CACHE command *48-bit Address feature set Automatic Acoustic Management feature set SET MAX security extension Address Offset Reserved Area Boot SET FEATURES subcommand required to spinup after power up Power-Up In Standby feature set Advanced Power Management feature set *General Purpose Logging feature set Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase 30min for SECURITY ERASE UNIT. HW reset results: CBLID- above Vih Device num = 0 determined by the jumper Checksum: correct -- "To the extent that we overreact, we
Re: IT8212/ITE RAID
On Sun, Aug 14, 2005 at 12:08:42PM +0100, Daniel Drake wrote:
> CaT wrote:
> >1. Alan Cox's IDE driver that was included in his ac patchset, which
> > seems to have died at 2.6.11ac7.
> >2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
> > It lived a brief but noted life before being taken out without any
> > reason (that I spotted) in 2.6.12-rc4-mm1
>
> Alan's driver has been merged into 2.6.13. You can get the up-to-date
Wooo!
> patches here:
>
> http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2315_ide-no-lba.patch
> http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/4345_it8212.patch
Didn't use these patches. Just went to 13-rc6 for now to test. All works
as before with the following errors on bootup:
[227523.229512] hda: max request size: 128KiB
[227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache,
CHS=24321/255/63, BUG
[227523.229631] hda: cache flushes not supported
[227523.229932] hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete
Error }
[227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
[227523.230952] ide: failed opcode was: unknown
[227524.379085] hda1
[227524.379710] hdc: max request size: 128KiB
[227524.379752] hdc: 120103200 sectors (61492 MB) w/1821KiB Cache,
CHS=16383/255/63, BUG
[227524.379825] hdc: cache flushes not supported
[227524.379991] hdc:hdc: recal_intr: status=0x51 { DriveReady SeekComplete
Error }
[227524.380702] hdc: recal_intr: error=0x04 { DriveStatusError }
[227524.380748] ide: failed opcode was: unknown
[227525.536757] hdc1 hdc2
/dev/hda:
Model=ST3200822A, FwRev=3.01, SerialNo=3LJ22Y8F
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
AdvancedPM=no
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:
* signifies the current active mode
/dev/hdc:
Model=IC35L060AVV207-0, FwRev=V22OA63A, SerialNo=VNVB01G2RAK8XH
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
BuffType=DualPortCache, BuffSize=1821kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
AdvancedPM=no
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:
* signifies the current active mode
--
"To the extent that we overreact, we proffer the terrorists the
greatest tribute."
- High Court Judge Michael Kirby
-
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: IT8212/ITE RAID
On Sun, Aug 14, 2005 at 12:08:42PM +0100, Daniel Drake wrote:
CaT wrote:
1. Alan Cox's IDE driver that was included in his ac patchset, which
seems to have died at 2.6.11ac7.
2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
It lived a brief but noted life before being taken out without any
reason (that I spotted) in 2.6.12-rc4-mm1
Alan's driver has been merged into 2.6.13. You can get the up-to-date
Wooo!
patches here:
http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2315_ide-no-lba.patch
http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/4345_it8212.patch
Didn't use these patches. Just went to 13-rc6 for now to test. All works
as before with the following errors on bootup:
[227523.229512] hda: max request size: 128KiB
[227523.229557] hda: 390721968 sectors (200049 MB) w/8192KiB Cache,
CHS=24321/255/63, BUG
[227523.229631] hda: cache flushes not supported
[227523.229932] hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete
Error }
[227523.230905] hda: recal_intr: error=0x04 { DriveStatusError }
[227523.230952] ide: failed opcode was: unknown
[227524.379085] hda1
[227524.379710] hdc: max request size: 128KiB
[227524.379752] hdc: 120103200 sectors (61492 MB) w/1821KiB Cache,
CHS=16383/255/63, BUG
[227524.379825] hdc: cache flushes not supported
[227524.379991] hdc:hdc: recal_intr: status=0x51 { DriveReady SeekComplete
Error }
[227524.380702] hdc: recal_intr: error=0x04 { DriveStatusError }
[227524.380748] ide: failed opcode was: unknown
[227525.536757] hdc1 hdc2
/dev/hda:
Model=ST3200822A, FwRev=3.01, SerialNo=3LJ22Y8F
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs RotSpdTol.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
AdvancedPM=no
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:
* signifies the current active mode
/dev/hdc:
Model=IC35L060AVV207-0, FwRev=V22OA63A, SerialNo=VNVB01G2RAK8XH
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
BuffType=DualPortCache, BuffSize=1821kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
AdvancedPM=no
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:
* signifies the current active mode
--
To the extent that we overreact, we proffer the terrorists the
greatest tribute.
- High Court Judge Michael Kirby
-
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: IT8212/ITE RAID
On Sun, Aug 14, 2005 at 02:33:05PM +0100, Alan Cox wrote: What does a full identify data set for the drive look like ? Here it is for the two drives. Please note that multisect was turned on manually as well as the security freeze. /dev/hda: ATA device, with non-removable media Model Number: ST3200822A Serial Number: 3LJ22Y8F Firmware Revision: 3.01 Standards: Used: ATA/ATAPI-6 T13 1410D revision 2 Supported: 6 5 4 3 Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors:4128705 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 390721968 device size with M = 1024*1024: 190782 MBytes device size with M = 1000*1000: 200049 MBytes (200 GB) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 4 Queue depth: 1 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns Commands/features: Enabled Supported: *READ BUFFER cmd *WRITE BUFFER cmd *Host Protected Area feature set *Look-ahead *Write cache *Power Management feature set Security Mode feature set *FLUSH CACHE EXT command *Mandatory FLUSH CACHE command *48-bit Address feature set SET MAX security extension Security: supported not enabled not locked frozen not expired: security count not supported: enhanced erase HW reset results: CBLID- above Vih Device num = 0 determined by CSEL Checksum: correct /dev/hdc: ATA device, with non-removable media powers-up in standby; SET FEATURES subcmd spins-up. Model Number: IC35L060AVV207-0 Serial Number: VNVB01G2RAK8XH Firmware Revision: V22OA63A Standards: Used: ATA/ATAPI-6 T13 1410D revision 3a Supported: 6 5 4 3 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 120103200 LBA48 user addressable sectors: 120103200 device size with M = 1024*1024: 58644 MBytes device size with M = 1000*1000: 61492 MBytes (61 GB) Capabilities: LBA, IORDY(can be disabled) bytes avail on r/w long: 52 Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Advanced power management level: unknown setting (0x) Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=240ns IORDY flow control=120ns Commands/features: Enabled Supported: *NOP cmd *READ BUFFER cmd *WRITE BUFFER cmd *Host Protected Area feature set Release interrupt *Look-ahead *Write cache *Power Management feature set Security Mode feature set *FLUSH CACHE EXT command *Mandatory FLUSH CACHE command *48-bit Address feature set Automatic Acoustic Management feature set SET MAX security extension Address Offset Reserved Area Boot SET FEATURES subcommand required to spinup after power up Power-Up In Standby feature set Advanced Power Management feature set *General Purpose Logging feature set Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase 30min for SECURITY ERASE UNIT. HW reset results: CBLID- above Vih Device num = 0 determined by the jumper Checksum: correct -- To the extent that we overreact, we proffer
IT8212/ITE RAID
Having an IDE card with one of these chipsets has left me with a bit of a quandry. I've seen 2 different patch, both seemingly not going anywhere. 1. Alan Cox's IDE driver that was included in his ac patchset, which seems to have died at 2.6.11ac7. 2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset. It lived a brief but noted life before being taken out without any reason (that I spotted) in 2.6.12-rc4-mm1 Now, I'd like to upgrade my kernel to cover the security patches releases since 11ac7 but... do I extract the ac driver or the mm driver and try to use it? Will my data be eaten? Is there any chance of seeing either driver in the kernel, proper? Just wondering which way to go and stuff. :/ -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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/
IT8212/ITE RAID
Having an IDE card with one of these chipsets has left me with a bit of a quandry. I've seen 2 different patch, both seemingly not going anywhere. 1. Alan Cox's IDE driver that was included in his ac patchset, which seems to have died at 2.6.11ac7. 2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset. It lived a brief but noted life before being taken out without any reason (that I spotted) in 2.6.12-rc4-mm1 Now, I'd like to upgrade my kernel to cover the security patches releases since 11ac7 but... do I extract the ac driver or the mm driver and try to use it? Will my data be eaten? Is there any chance of seeing either driver in the kernel, proper? Just wondering which way to go and stuff. :/ -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: Announcing kernelplanet.org
On Wed, Mar 30, 2005 at 09:21:46AM +0100, Dave Airlie wrote: > we have the aggregated blogs of : > Alan Cox, Dave Airlie, Dave Jones, David Woodhouse, Greg Kroah-Hartman, I think a link to the corresponding blog of Telsa as a sort of behind-the-scenes, making of blog might be fun. ;) -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - 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: Announcing kernelplanet.org
On Wed, Mar 30, 2005 at 09:21:46AM +0100, Dave Airlie wrote: we have the aggregated blogs of : Alan Cox, Dave Airlie, Dave Jones, David Woodhouse, Greg Kroah-Hartman, I think a link to the corresponding blog of Telsa as a sort of behind-the-scenes, making of blog might be fun. ;) -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - 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: ipv6 and ipv4 interaction weirdness
On Fri, Mar 11, 2005 at 08:58:15AM -0600, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > If it bound to :: port 22 then 0.0.0.0:22 would fail. > > > > On the other hand if I got it to bind to each address individually then > > both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. > > > > Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere > > with each other? > > It is 100% intended, even it is not similar to BSD variants do. > > IPv4 and IPv6 share address/port space. > :: and 0.0.0.0 is special "any" address, thus they confict. > :::a.b.c.d and a.b.c.d also conflict. Argh! Ofcourse. That makes sense. In the IPv6 ip space, IPv4 was made a subset so anything that decides to bind 0.0.0.0:22 (for eg) would prevent another bind to :: much like binding to 10.1.1.1:22 would prevent a 0.0.0.0:22 bind. Having changed ListenAddress to :: it works as it should and I get responses in the IPv4 ip space. Joy. Thanks for the clue. I've so rarely come across the ::: ip space that I completely forgot about it. -- "It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organising thoughts, devoting attention to detail and learning to be self-critical?" -- Alan Perlis - 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/
ipv6 and ipv4 interaction weirdness
I just had some issues with ssh and trying to get it to bind to all ipv6 and ipv4 addresses to it via :: and 0.0.0.0. The problem was that it'd only let one succeed. If 0.0.0.0:22 was successful then :: port 22 could not happen and neither could my ipv6 addy port 22 as it would get the 'address already in use' error from bind(). The reverse was also true. If it bound to :: port 22 then 0.0.0.0:22 would fail. On the other hand if I got it to bind to each address individually then both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere with each other? I'm using kernel 2.6.11-ac2 with OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 and glibc 2.3.2 (debian version 2.3.2.ds1-20). -- "It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organising thoughts, devoting attention to detail and learning to be self-critical?" -- Alan Perlis - 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/
ipv6 and ipv4 interaction weirdness
I just had some issues with ssh and trying to get it to bind to all ipv6 and ipv4 addresses to it via :: and 0.0.0.0. The problem was that it'd only let one succeed. If 0.0.0.0:22 was successful then :: port 22 could not happen and neither could my ipv6 addy port 22 as it would get the 'address already in use' error from bind(). The reverse was also true. If it bound to :: port 22 then 0.0.0.0:22 would fail. On the other hand if I got it to bind to each address individually then both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere with each other? I'm using kernel 2.6.11-ac2 with OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 and glibc 2.3.2 (debian version 2.3.2.ds1-20). -- It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organising thoughts, devoting attention to detail and learning to be self-critical? -- Alan Perlis - 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: ipv6 and ipv4 interaction weirdness
On Fri, Mar 11, 2005 at 08:58:15AM -0600, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: If it bound to :: port 22 then 0.0.0.0:22 would fail. On the other hand if I got it to bind to each address individually then both ipv4 (2 addresses) and ipv6 (1 address) binds would succeed. Maybe I'm just looking at it wrong but shouldn't ipv4 and ipv6 interfere with each other? It is 100% intended, even it is not similar to BSD variants do. IPv4 and IPv6 share address/port space. :: and 0.0.0.0 is special any address, thus they confict. :::a.b.c.d and a.b.c.d also conflict. Argh! Ofcourse. That makes sense. In the IPv6 ip space, IPv4 was made a subset so anything that decides to bind 0.0.0.0:22 (for eg) would prevent another bind to :: much like binding to 10.1.1.1:22 would prevent a 0.0.0.0:22 bind. Having changed ListenAddress to :: it works as it should and I get responses in the IPv4 ip space. Joy. Thanks for the clue. I've so rarely come across the ::: ip space that I completely forgot about it. -- It goes against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organising thoughts, devoting attention to detail and learning to be self-critical? -- Alan Perlis - 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: ITE8212
On Thu, Mar 10, 2005 at 02:51:35PM +, Alan Cox wrote:
> On Iau, 2005-03-10 at 12:28, CaT wrote:
> > hda: max request size: 128KiB
> > hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
> > hda: cache flushes not supported
> > hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
> > hda: recal_intr: error=0x04 { DriveStatusError }
>
> Ooh great stuff, definitely want to know more. A couple of folks report
> that and mine won't do it.
I've got another one of these cards and it does not display these
issues. That box is running 2.6.9-ac10 whilst mine is running 2.6.11-ac2
though and the HD is a western digital whilst my HDs are a Seagate and an
IBM. I can't really test on that box (but I can give out any 'doesn't
require me to poke it hard' info) as it's in production but my g/w is
fine for testing stuff.
Should I be worried about the BUG bit on the hda and hdc lines as above?
> Ok its correctly trimmed the modes, but not it seems the current mode.
> I'll send you a tweak to avoid multisect being played with.
Cool. BTW I set multisec manually and flipped unmaskirq on and did a
copy of 37GB of data from hdc to hda. The promise card used to fail
abysmally at this task (either with both drives on the one card or (and
this was worse) one drive per card). This fills me with more joy then I
can say. I've been wanting to make this box my mail server for yonks and
now it looks like I'll be able to. Thanks! :)
/dev/hdc2 39411702 37471662 0 100% /data/share
/dev/hda1192292124 37610568 144913636 21% /mnt
*dance*
--
Red herrings strewn hither and yon.
-
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/
ITE8212
Well I got my ITE8212 today (only ordered it last night - whee) and here
are the happy fun results. Basically the card shoved itself to the front
of the queue, gave some weird errors on bootup and had no multisec set
on the drives attached to it. I can boot the machine though and am using
it right now to route my traffic (amongst other things). Am quite happy
to help debug - just need to know what to do. :)
Thanks.
IT8212: IDE controller at PCI slot :00:0d.0
PCI: Found IRQ 11 for device :00:0d.0
IT8212: chipset revision 17
it821x: controller in smart mode.
IT8212: 100% native mode on irq 11
ide0: BM-DMA at 0x1040-0x1047, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1048-0x104f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: ST3200822A, ATA DISK drive
hda: Performing identify fixups.
ide0 at 0x1050-0x1057,0x1072 on irq 11
Probing IDE interface ide1...
hdc: IC35L060AVV207-0, ATA DISK drive
hdc: Performing identify fixups.
ide1 at 0x1058-0x105f,0x1076 on irq 11
PIIX4: IDE controller at PCI slot :00:14.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0x10a0-0x10a7, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0x10a8-0x10af, BIOS settings: hdg:DMA, hdh:DMA
Probing IDE interface ide2...
hde: SAMSUNG SV1022D, ATA DISK drive
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide3...
hdg: AOPEN CD-RW CRW3248 1.12 20020417, ATAPI CD/DVD-ROM drive
hdh: QUANTUM FIREBALLlct20 10, ATA DISK drive
ide3 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
hda: cache flushes not supported
hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hda: recal_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda1
hdc: max request size: 128KiB
hdc: 120103200 sectors (61492 MB) w/1821KiB Cache, CHS=16383/255/63, BUG
hdc: cache flushes not supported
hdc:hdc: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: recal_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hdc1 hdc2
hde: max request size: 128KiB
hde: 19931184 sectors (10204 MB) w/472KiB Cache, CHS=19773/16/63
hde: cache flushes not supported
hde: hde1 hde2 hde3 hde4 < hde5 hde6 hde7 >
hdh: max request size: 128KiB
hdh: 20044080 sectors (10262 MB) w/418KiB Cache, CHS=19885/16/63
hdh: cache flushes not supported
hdh: hdh1 hdh2
hdg: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache
[EMAIL PROTECTED]:~# hdparm -v /dev/hda
/dev/hda:
multcount= 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 24321/255/63, sectors = 200049647616, start = 0
[EMAIL PROTECTED]:~# hdparm -v /dev/hdc
/dev/hdc:
multcount= 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 16383/255/63, sectors = 61492838400, start = 0
Both drives have a multcount:
/dev/hda:
Model=ST3200822A, FwRev=3.01, SerialNo=3LJ22Y8F
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
AdvancedPM=no
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:
* signifies the current active mode
/dev/hda:
ATA device, with non-removable media
Model Number: ST3200822A
Serial Number: 3LJ22Y8F
Firmware Revision: 3.01
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 2
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 65535
heads 16 1
sectors/track 63 63
--
CHS current addressable sectors:4128705
LBAuser addressable sectors: 268435455
LBA48 user addressable sectors: 390721968
device size with M = 1024*1024: 190782 MBytes
device size with M = 1000*1000: 200049 MBytes (200 GB)
Capabilities:
LBA, IORDY(can be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Recommended acoustic management value: 128, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*READ BUFFER cmd
ITE8212
Well I got my ITE8212 today (only ordered it last night - whee) and here
are the happy fun results. Basically the card shoved itself to the front
of the queue, gave some weird errors on bootup and had no multisec set
on the drives attached to it. I can boot the machine though and am using
it right now to route my traffic (amongst other things). Am quite happy
to help debug - just need to know what to do. :)
Thanks.
IT8212: IDE controller at PCI slot :00:0d.0
PCI: Found IRQ 11 for device :00:0d.0
IT8212: chipset revision 17
it821x: controller in smart mode.
IT8212: 100% native mode on irq 11
ide0: BM-DMA at 0x1040-0x1047, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1048-0x104f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: ST3200822A, ATA DISK drive
hda: Performing identify fixups.
ide0 at 0x1050-0x1057,0x1072 on irq 11
Probing IDE interface ide1...
hdc: IC35L060AVV207-0, ATA DISK drive
hdc: Performing identify fixups.
ide1 at 0x1058-0x105f,0x1076 on irq 11
PIIX4: IDE controller at PCI slot :00:14.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0x10a0-0x10a7, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0x10a8-0x10af, BIOS settings: hdg:DMA, hdh:DMA
Probing IDE interface ide2...
hde: SAMSUNG SV1022D, ATA DISK drive
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide3...
hdg: AOPEN CD-RW CRW3248 1.12 20020417, ATAPI CD/DVD-ROM drive
hdh: QUANTUM FIREBALLlct20 10, ATA DISK drive
ide3 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
hda: cache flushes not supported
hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hda: recal_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda1
hdc: max request size: 128KiB
hdc: 120103200 sectors (61492 MB) w/1821KiB Cache, CHS=16383/255/63, BUG
hdc: cache flushes not supported
hdc:hdc: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hdc: recal_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hdc1 hdc2
hde: max request size: 128KiB
hde: 19931184 sectors (10204 MB) w/472KiB Cache, CHS=19773/16/63
hde: cache flushes not supported
hde: hde1 hde2 hde3 hde4 hde5 hde6 hde7
hdh: max request size: 128KiB
hdh: 20044080 sectors (10262 MB) w/418KiB Cache, CHS=19885/16/63
hdh: cache flushes not supported
hdh: hdh1 hdh2
hdg: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache
[EMAIL PROTECTED]:~# hdparm -v /dev/hda
/dev/hda:
multcount= 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 24321/255/63, sectors = 200049647616, start = 0
[EMAIL PROTECTED]:~# hdparm -v /dev/hdc
/dev/hdc:
multcount= 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq= 0 (off)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
geometry = 16383/255/63, sectors = 61492838400, start = 0
Both drives have a multcount:
/dev/hda:
Model=ST3200822A, FwRev=3.01, SerialNo=3LJ22Y8F
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs RotSpdTol.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455
IORDY=on/off
PIO modes: pio0 pio1 pio2
DMA modes: mdma0 mdma1 mdma2
AdvancedPM=no
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:
* signifies the current active mode
/dev/hda:
ATA device, with non-removable media
Model Number: ST3200822A
Serial Number: 3LJ22Y8F
Firmware Revision: 3.01
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 2
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 65535
heads 16 1
sectors/track 63 63
--
CHS current addressable sectors:4128705
LBAuser addressable sectors: 268435455
LBA48 user addressable sectors: 390721968
device size with M = 1024*1024: 190782 MBytes
device size with M = 1000*1000: 200049 MBytes (200 GB)
Capabilities:
LBA, IORDY(can be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Recommended acoustic management value: 128, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*READ BUFFER cmd
Re: ITE8212
On Thu, Mar 10, 2005 at 02:51:35PM +, Alan Cox wrote:
On Iau, 2005-03-10 at 12:28, CaT wrote:
hda: max request size: 128KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, BUG
hda: cache flushes not supported
hda:hda: recal_intr: status=0x51 { DriveReady SeekComplete Error }
hda: recal_intr: error=0x04 { DriveStatusError }
Ooh great stuff, definitely want to know more. A couple of folks report
that and mine won't do it.
I've got another one of these cards and it does not display these
issues. That box is running 2.6.9-ac10 whilst mine is running 2.6.11-ac2
though and the HD is a western digital whilst my HDs are a Seagate and an
IBM. I can't really test on that box (but I can give out any 'doesn't
require me to poke it hard' info) as it's in production but my g/w is
fine for testing stuff.
Should I be worried about the BUG bit on the hda and hdc lines as above?
Ok its correctly trimmed the modes, but not it seems the current mode.
I'll send you a tweak to avoid multisect being played with.
Cool. BTW I set multisec manually and flipped unmaskirq on and did a
copy of 37GB of data from hdc to hda. The promise card used to fail
abysmally at this task (either with both drives on the one card or (and
this was worse) one drive per card). This fills me with more joy then I
can say. I've been wanting to make this box my mail server for yonks and
now it looks like I'll be able to. Thanks! :)
/dev/hdc2 39411702 37471662 0 100% /data/share
/dev/hda1192292124 37610568 144913636 21% /mnt
*dance*
--
Red herrings strewn hither and yon.
-
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.11-ac1
On Wed, Mar 09, 2005 at 05:43:02PM +0100, Bartlomiej Zolnierkiewicz wrote: > On Wed, 09 Mar 2005 16:38:43 +, Alan Cox <[EMAIL PROTECTED]> wrote: > > On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote: > > > It can be merged if somebody fix it to always force controller into > > > non-RAID mode and remove RAID mode support (which currently > > > does nothing more besides complicating the driver and making special > > > commands unusable). > > > > Incorrect > > Very helpful Argh! Ok. I guess I shouldn't've just bought the card based on this driver then so that I could better debug my problems with my promise cards. 8( -- Red herrings strewn hither and yon. - 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.11-ac1
On Wed, Mar 09, 2005 at 05:43:02PM +0100, Bartlomiej Zolnierkiewicz wrote: On Wed, 09 Mar 2005 16:38:43 +, Alan Cox [EMAIL PROTECTED] wrote: On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote: It can be merged if somebody fix it to always force controller into non-RAID mode and remove RAID mode support (which currently does nothing more besides complicating the driver and making special commands unusable). Incorrect Very helpful Argh! Ok. I guess I shouldn't've just bought the card based on this driver then so that I could better debug my problems with my promise cards. 8( -- Red herrings strewn hither and yon. - 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.11-ac1
On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote: > For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this > diff should actually apply to either right now. > > 2.6.11-ac1 > o Fix jbd race in ext3(Stephen Tweedie) > > Carried over from 2.6.10-ac BTW. What's the probability of the ITE driver making it into the stock kernel? -- Red herrings strewn hither and yon. - 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.11-ac1
On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote: For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this diff should actually apply to either right now. 2.6.11-ac1 o Fix jbd race in ext3(Stephen Tweedie) Carried over from 2.6.10-ac BTW. What's the probability of the ITE driver making it into the stock kernel? -- Red herrings strewn hither and yon. - 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: IDE locking (was: Re: RFD: Kernel release numbering)
On Fri, Mar 04, 2005 at 12:44:16PM +1100, CaT wrote:
> The problems were weird. The fs I was copying from decided it was
> corrupt. Unmounting the partition and trying an fsck reported that it
> couldn't find the partition. After a reboot all was well and a fsck
> reported no problems.
Similar stuff with ac12 if dma is on on both drives.
Mar 4 15:15:55 nessie kernel: hdi: dma_timer_expiry: dma status == 0x21
Mar 4 15:16:10 nessie kernel: hdi: DMA timeout error
Mar 4 15:16:10 nessie kernel: hdi: dma timeout error: status=0x58 { DriveReady
SeekComplete DataRequest }
Mar 4 15:16:10 nessie kernel:
Mar 4 15:16:10 nessie kernel: ide: failed opcode was: unknown
Should be noted that hdi does not boot with multisec or dma on.
--
Red herrings strewn hither and yon.
-
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/
IDE locking (was: Re: RFD: Kernel release numbering)
On Fri, Mar 04, 2005 at 12:44:04AM +, Alan Cox wrote: > On Gwe, 2005-03-04 at 00:19, CaT wrote: > > Working IDE locking? Does this mean if I have 2 promise cards, a HD > > on each card and I copy from one to the other it wont all blow up in my > > face? > > Depends on your PCI bus and also if the are on the same IRQ. In the same Hmm. How can I check on this? What should I look for? > IRQ case you may find 2.6.11 is a bit saner as Bartlomiej may have > sorted one of the IRQ masking problems now. /proc/interrupts reports different irqs for each ide device: 5:5018683 XT-PIC ide4 11: 167995 XT-PIC ide2, eth0 14: 39799 XT-PIC ide0 15: 10704 XT-PIC ide1 The problems were weird. The fs I was copying from decided it was corrupt. Unmounting the partition and trying an fsck reported that it couldn't find the partition. After a reboot all was well and a fsck reported no problems. -- Red herrings strewn hither and yon. - 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: RFD: Kernel release numbering
On Thu, Mar 03, 2005 at 11:51:42PM +, Alan Cox wrote: > -ac is essentially base security fixes + working IDE locking + pwc + > fixes for the bugs everyone hit that needed fixing urgently. I consider > working locking on my storage essential because I like my data to still > be there. Working IDE locking? Does this mean if I have 2 promise cards, a HD on each card and I copy from one to the other it wont all blow up in my face? Please say yes. :) -- Red herrings strewn hither and yon. - 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: IDE locking (was: Re: RFD: Kernel release numbering)
On Fri, Mar 04, 2005 at 12:44:16PM +1100, CaT wrote:
The problems were weird. The fs I was copying from decided it was
corrupt. Unmounting the partition and trying an fsck reported that it
couldn't find the partition. After a reboot all was well and a fsck
reported no problems.
Similar stuff with ac12 if dma is on on both drives.
Mar 4 15:15:55 nessie kernel: hdi: dma_timer_expiry: dma status == 0x21
Mar 4 15:16:10 nessie kernel: hdi: DMA timeout error
Mar 4 15:16:10 nessie kernel: hdi: dma timeout error: status=0x58 { DriveReady
SeekComplete DataRequest }
Mar 4 15:16:10 nessie kernel:
Mar 4 15:16:10 nessie kernel: ide: failed opcode was: unknown
Should be noted that hdi does not boot with multisec or dma on.
--
Red herrings strewn hither and yon.
-
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: RFD: Kernel release numbering
On Thu, Mar 03, 2005 at 11:51:42PM +, Alan Cox wrote: -ac is essentially base security fixes + working IDE locking + pwc + fixes for the bugs everyone hit that needed fixing urgently. I consider working locking on my storage essential because I like my data to still be there. Working IDE locking? Does this mean if I have 2 promise cards, a HD on each card and I copy from one to the other it wont all blow up in my face? Please say yes. :) -- Red herrings strewn hither and yon. - 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/
IDE locking (was: Re: RFD: Kernel release numbering)
On Fri, Mar 04, 2005 at 12:44:04AM +, Alan Cox wrote: On Gwe, 2005-03-04 at 00:19, CaT wrote: Working IDE locking? Does this mean if I have 2 promise cards, a HD on each card and I copy from one to the other it wont all blow up in my face? Depends on your PCI bus and also if the are on the same IRQ. In the same Hmm. How can I check on this? What should I look for? IRQ case you may find 2.6.11 is a bit saner as Bartlomiej may have sorted one of the IRQ masking problems now. /proc/interrupts reports different irqs for each ide device: 5:5018683 XT-PIC ide4 11: 167995 XT-PIC ide2, eth0 14: 39799 XT-PIC ide0 15: 10704 XT-PIC ide1 The problems were weird. The fs I was copying from decided it was corrupt. Unmounting the partition and trying an fsck reported that it couldn't find the partition. After a reboot all was well and a fsck reported no problems. -- Red herrings strewn hither and yon. - 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/
synaptics touchpad not working with 2.4.x
I;ve had this with 2.4.0 but have just tried with 2.4.6ac2 and still have it. Under 2.2.x the touchpad works like a dream. Under 2.4.x it stutters, freezes and so on. Did something about /dec/psaux change between 2.2.x and 2.4.x? Will I need to recompile glibc and/or gpm? if I cat /dev/psaux I get data flowing through but gpm stays frozen. :/ Hope someone can help as, now that ext3 is being well and truly ported to 2.4.x, this is the last stumbling block for me having 2.4.x on my laptop. gpm options: /usr/sbin/gpm -m /dev/psaux -t synps2 -Rmsc -2 glibc: 2.1.3 compiled for 2.2.x -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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/
synaptics touchpad not working with 2.4.x
I;ve had this with 2.4.0 but have just tried with 2.4.6ac2 and still have it. Under 2.2.x the touchpad works like a dream. Under 2.4.x it stutters, freezes and so on. Did something about /dec/psaux change between 2.2.x and 2.4.x? Will I need to recompile glibc and/or gpm? if I cat /dev/psaux I get data flowing through but gpm stays frozen. :/ Hope someone can help as, now that ext3 is being well and truly ported to 2.4.x, this is the last stumbling block for me having 2.4.x on my laptop. gpm options: /usr/sbin/gpm -m /dev/psaux -t synps2 -Rmsc -2 glibc: 2.1.3 compiled for 2.2.x -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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/
nonzero shared ram and 2.4.x
I thought it wasn't meant to try and count it: 0 [22:40:59] bowman@europa:/home/bowman>> uname -a Linux europa 2.4.5-ac9 #4 Wed Jun 13 12:54:18 EST 2001 i686 unknown 0 [22:41:29] bowman@europa:/home/bowman>> more /proc/meminfo total:used:free: shared: buffers: cached: Mem: 260530176 228261888 3226828865536 31141888 51003392 Swap: 2704998400 270499840 MemTotal: 254424 kB MemFree: 31512 kB MemShared: 64 kB Buffers: 30412 kB Cached: 49808 kB Active: 65848 kB Inact_dirty: 14436 kB Inact_clean: 0 kB Inact_target: 24 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 254424 kB LowFree: 31512 kB SwapTotal: 264160 kB SwapFree: 264160 kB -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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/
nonzero shared ram and 2.4.x
I thought it wasn't meant to try and count it: 0 [22:40:59] bowman@europa:/home/bowman uname -a Linux europa 2.4.5-ac9 #4 Wed Jun 13 12:54:18 EST 2001 i686 unknown 0 [22:41:29] bowman@europa:/home/bowman more /proc/meminfo total:used:free: shared: buffers: cached: Mem: 260530176 228261888 3226828865536 31141888 51003392 Swap: 2704998400 270499840 MemTotal: 254424 kB MemFree: 31512 kB MemShared: 64 kB Buffers: 30412 kB Cached: 49808 kB Active: 65848 kB Inact_dirty: 14436 kB Inact_clean: 0 kB Inact_target: 24 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 254424 kB LowFree: 31512 kB SwapTotal: 264160 kB SwapFree: 264160 kB -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: The difference between Linus's kernel and Alan Cox's kernel
On Fri, May 25, 2001 at 11:32:18PM +0200, Erik Mouw wrote: > On Fri, May 25, 2001 at 05:12:39PM -0300, Thiago Vinhas de Moraes wrote: > > Why there are two different kernel trees? There is always the official > > release, provided by Torvalds, and then Alan provides a patch merging Linus's > > stuff, and adding (?) tons of bug fixes. > > I just added this to the kernelnewbies FAQ: > > http://www.kernelnewbies.org/faq.php3 Typo: First para, last sentence: s/Linux/Linus/ -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: The difference between Linus's kernel and Alan Cox's kernel
On Fri, May 25, 2001 at 11:32:18PM +0200, Erik Mouw wrote: On Fri, May 25, 2001 at 05:12:39PM -0300, Thiago Vinhas de Moraes wrote: Why there are two different kernel trees? There is always the official release, provided by Torvalds, and then Alan provides a patch merging Linus's stuff, and adding (?) tons of bug fixes. I just added this to the kernelnewbies FAQ: http://www.kernelnewbies.org/faq.php3 Typo: First para, last sentence: s/Linux/Linus/ -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 03:59:28PM +0100, Alan Cox wrote: > What is this gid mail crap ? You don't need priviledge. You get the mail by > asking the daemon for it. procmail needs no priviledge either if it is done > right. > > You just need to think about the security models in the right way. Linux gives > you the ability to do authenticated uid/gid checking over a socket connection. > That is an incredibly powerful model for real compartmentalisation. Ok. My experience isn't all that great so I may well be missing something here. But what? 1. email -> sendmail 2. sendmail figures out what it has to do with it. turns out it's deliver it locally for user blah 3. sendmail starts procmail so that it delivers the email. 4. procmail goes through the recepie list for user blah and eventually delivers the email (one way or another) Now, in order for step 4 to be done safely, procmail should be running as the user it's meant to deliver the mail for. for this to happen sendmail needs to start it as that user in step 3 and to do that it needs extra privs, above and beyond that of a normal user. Now as I said, I'm not a UNIX God[tm] and so I may well be missing something vital. If so, what is it? This sounds like something that would be way useful to learn. :) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 04:49:57PM +0200, Pjotr Kourzanoff wrote: > > use port 2525 as SMTP port in your MTA. I've succeed to setup such a > > configuration. > > This requires you to ensure that your MTA is started first on that > port...Might be difficult to achieve reliably in an automatic way > without root privileges :-( > > mailuser@foo% /etc/rc.d/init.d/sendmail stop > badguy@foo% ./suck 2525 > mailuser@foo% /etc/rc.d/init.d/sendmail start Not necessarily. While I have no yet used the feature, iptables permits firewalling on userid. I presume this includes wether or not a program can listen on a port, right? (and all the other fun things). If so then all you'd have to do is deny external access to port 2525 and only permit mailuser to listen etc on it and you're set. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 03:37:34PM +0100, Alan Cox wrote: > What role requires priviledge once the port is open ? > > DNS lookup does not > Spooling to disk does not > Accepting a connection from a client does not > Doing peercred auth with a client does not > Copying spool articles matching the peercred to the client does not Running procmail as the user who is to receive the email for local mail delivery as running it with gid mail (for eg) would allow one user to modify another's mail. (just a thought - the above's valid with sendmail at least) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 03:37:34PM +0100, Alan Cox wrote: What role requires priviledge once the port is open ? DNS lookup does not Spooling to disk does not Accepting a connection from a client does not Doing peercred auth with a client does not Copying spool articles matching the peercred to the client does not Running procmail as the user who is to receive the email for local mail delivery as running it with gid mail (for eg) would allow one user to modify another's mail. (just a thought - the above's valid with sendmail at least) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 04:49:57PM +0200, Pjotr Kourzanoff wrote: use port 2525 as SMTP port in your MTA. I've succeed to setup such a configuration. This requires you to ensure that your MTA is started first on that port...Might be difficult to achieve reliably in an automatic way without root privileges :-( mailuser@foo% /etc/rc.d/init.d/sendmail stop badguy@foo% ./suck 2525 mailuser@foo% /etc/rc.d/init.d/sendmail start Not necessarily. While I have no yet used the feature, iptables permits firewalling on userid. I presume this includes wether or not a program can listen on a port, right? (and all the other fun things). If so then all you'd have to do is deny external access to port 2525 and only permit mailuser to listen etc on it and you're set. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: [OFFTOPIC] Re: [PATCH] Single user linux
On Tue, Apr 24, 2001 at 03:59:28PM +0100, Alan Cox wrote: What is this gid mail crap ? You don't need priviledge. You get the mail by asking the daemon for it. procmail needs no priviledge either if it is done right. You just need to think about the security models in the right way. Linux gives you the ability to do authenticated uid/gid checking over a socket connection. That is an incredibly powerful model for real compartmentalisation. Ok. My experience isn't all that great so I may well be missing something here. But what? 1. email - sendmail 2. sendmail figures out what it has to do with it. turns out it's deliver it locally for user blah 3. sendmail starts procmail so that it delivers the email. 4. procmail goes through the recepie list for user blah and eventually delivers the email (one way or another) Now, in order for step 4 to be done safely, procmail should be running as the user it's meant to deliver the mail for. for this to happen sendmail needs to start it as that user in step 3 and to do that it needs extra privs, above and beyond that of a normal user. Now as I said, I'm not a UNIX God[tm] and so I may well be missing something vital. If so, what is it? This sounds like something that would be way useful to learn. :) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: PCI power management
On Thu, Apr 19, 2001 at 11:19:31AM +0100, Benjamin Herrenschmidt wrote: > Hi ! Glad to see things moving around Power Management ;) > > >This was originally a private reply to Patrick Mochel, but the e-mail > >kept getting longer and longer :) > > Note: we have setup a list for PM issues > > http://lists.sourceforge.net/lists/listinfo/linux-pm-devel Oo *tries to subscribe* Doh! The silly thing is trying to use the From_ header on the confirm rather then the From: header and so I can't subscribe. Can this get fixed? -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: PCI power management
On Thu, Apr 19, 2001 at 11:19:31AM +0100, Benjamin Herrenschmidt wrote: Hi ! Glad to see things moving around Power Management ;) This was originally a private reply to Patrick Mochel, but the e-mail kept getting longer and longer :) Note: we have setup a list for PM issues http://lists.sourceforge.net/lists/listinfo/linux-pm-devel Oo *tries to subscribe* Doh! The silly thing is trying to use the From_ header on the confirm rather then the From: header and so I can't subscribe. Can this get fixed? -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: P-III Oddity.
On Sat, Apr 07, 2001 at 09:56:40PM +0200, Dave Jones wrote: > On Sat, 7 Apr 2001, Rogier Wolff wrote: > > > One machine regularly crashes. > > Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 >19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000 > > Probably unrelated to the issue below. Try a more recent 2.2 ? 2.2.19pre16 here. I don't have an SMP kernel but is this right: cpuid level : 3 Vendor ID: "GenuineIntel"; Max CPUID level 2 That line is the only line I could find that mentioned cpuid in your code so I seem to be getting two different answers... -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: P-III Oddity.
On Sat, Apr 07, 2001 at 09:56:40PM +0200, Dave Jones wrote:
On Sat, 7 Apr 2001, Rogier Wolff wrote:
One machine regularly crashes.
Linux version 2.2.16-3 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #1 Mon Jun 19 19:11:44 EDT 2000
Probably unrelated to the issue below. Try a more recent 2.2 ?
2.2.19pre16 here. I don't have an SMP kernel but is this right:
cpuid level : 3
Vendor ID: "GenuineIntel"; Max CPUID level 2
That line is the only line I could find that mentioned cpuid in your
code so I seem to be getting two different answers...
--
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
cat speaking of mental giants..
Jenna me, a giant, bullshit
Jenna And i'm not mental
- An IRC session, 20/12/2000
-
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.4.3-ac2 and D state process
I have mozilla stuck in D state: 25 [16:44:06] bowman@europa:/home/bowman>> ps -eo pid,tt,user,fname,tmout,f,wchan | grep mozilla 435 ?bowman mozilla- - 040 down_write_failed 2646 ?bowman mozilla- - 040 down_write_failed Would this be a mozilla issue or a kernel issue? I can't kill this sucker nor can I attache an strace to it and have it return something. System is a Debian 2.2r2 system, kernel 2.4.3-ac2, glibc 2.1.3 (dunno what else you folks may need - if you do need more info, holler) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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.4.3-ac2 and D state process
I have mozilla stuck in D state: 25 [16:44:06] bowman@europa:/home/bowman ps -eo pid,tt,user,fname,tmout,f,wchan | grep mozilla 435 ?bowman mozilla- - 040 down_write_failed 2646 ?bowman mozilla- - 040 down_write_failed Would this be a mozilla issue or a kernel issue? I can't kill this sucker nor can I attache an strace to it and have it return something. System is a Debian 2.2r2 system, kernel 2.4.3-ac2, glibc 2.1.3 (dunno what else you folks may need - if you do need more info, holler) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: ide.2.2.18.02122001.patch
On Mon, Mar 19, 2001 at 09:09:21AM -0800, Andre Hedrick wrote: > > Write-caching flushing upon closing/unmounting each partition. Would it be possible to have such info included on the webpage and/or on the release emails? I often wonder what, if any, goodness might come from these patches but it's a wee bit hard to tell as it stands. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: ide.2.2.18.02122001.patch
On Mon, Mar 19, 2001 at 09:09:21AM -0800, Andre Hedrick wrote: Write-caching flushing upon closing/unmounting each partition. Would it be possible to have such info included on the webpage and/or on the release emails? I often wonder what, if any, goodness might come from these patches but it's a wee bit hard to tell as it stands. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote: > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote: > [snip] > > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout >with(0x70)! > > Please try the attached patch. > Actually, it's designed to solve another problem, but may be your one has the > same origin as that other. > Index: eepro100.c Patch appears to have worked. After 2 weeks of actually using the right module (*sheepish grin*) I've not had the card popup the above error message. woo. So thanks for that. :) Majorly happy about things now. :) And now... to put ext3 on my laptop. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote: On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote: [snip] Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! Please try the attached patch. Actually, it's designed to solve another problem, but may be your one has the same origin as that other. Index: eepro100.c Patch appears to have worked. After 2 weeks of actually using the right module (*sheepish grin*) I've not had the card popup the above error message. woo. So thanks for that. :) Majorly happy about things now. :) And now... to put ext3 on my laptop. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Tue, Feb 20, 2001 at 02:00:31AM -0800, Ion Badulescu wrote: > Are you sure this driver has my patch applied? There is no way you could > have gotten these messages without getting the other printk as well.. > > Can you check it again, please? *sigh* too much kernel bouncing. I got the right kernel this time. applied the patch and I'm off again. sorry about that. whacky day. :/ -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Tue, Feb 20, 2001 at 02:00:31AM -0800, Ion Badulescu wrote: Are you sure this driver has my patch applied? There is no way you could have gotten these messages without getting the other printk as well.. Can you check it again, please? *sigh* too much kernel bouncing. I got the right kernel this time. applied the patch and I'm off again. sorry about that. whacky day. :/ -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Tue, Feb 20, 2001 at 11:31:52AM +1100, CaT wrote: > On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote: > > > In my experiments wait_for_cmd timeouts almost always were related to > > > DumpStats command. > > > I think, we need to investigate what time constraints are related to this > > > command. > > > > Nothing documented... > > > > CaT, can you apply this debugging patch and let us know what you get in the > > logs? It should allow us to pinpoint the error a bit more precisely. > > patched, old removed, new installed, waiting for fubar. :) Ok. this is what I got in my kern.log. this is on a fresh reboot. Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)! Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0xff90) timedout with(0xff90)! Feb 20 18:32:21 theirongiant last message repeated 29 times Feb 20 18:33:15 theirongiant last message repeated 31 times Feb 20 18:33:16 theirongiant kernel: eth0: Transmit timed out: status 0c90 at 0/63 command 0001a000. Feb 20 18:33:16 theirongiant kernel: eth0: Tx ring dump, Tx queue 63 / 0: Feb 20 18:33:16 theirongiant kernel: eth0: * 0 0001a000. Feb 20 18:33:16 theirongiant kernel: eth0: 1 0002. Feb 20 18:33:16 theirongiant kernel: eth0: 2 0003. Feb 20 18:33:16 theirongiant kernel: eth0: 3 0003. Feb 20 18:33:16 theirongiant kernel: eth0: 4 0003. Feb 20 18:33:16 theirongiant kernel: eth0: 5 0003. Feb 20 18:33:16 theirongiant kernel: eth0: 6 0003. Feb 20 18:33:16 theirongiant kernel: eth0: 7 0003. Feb 20 18:33:16 theirongiant kernel: eth0: 8 0002. Feb 20 18:33:16 theirongiant kernel: eth0: 9 0003. Feb 20 18:33:16 theirongiant kernel: eth0:10 0003. Feb 20 18:33:16 theirongiant kernel: eth0:11 0003. Feb 20 18:33:16 theirongiant kernel: eth0:12 0003. Feb 20 18:33:16 theirongiant kernel: eth0:13 000c. Feb 20 18:33:16 theirongiant kernel: eth0:14 000c. Feb 20 18:33:16 theirongiant kernel: eth0:15 0003. Feb 20 18:33:16 theirongiant kernel: eth0:16 200c. Feb 20 18:33:16 theirongiant kernel: eth0:17 000c. Feb 20 18:33:16 theirongiant kernel: eth0:18 0003. Feb 20 18:33:16 theirongiant kernel: eth0:19 000c. Feb 20 18:33:16 theirongiant kernel: eth0:20 000c. Feb 20 18:33:16 theirongiant kernel: eth0:21 0003. Feb 20 18:33:16 theirongiant kernel: eth0:22 0003. Feb 20 18:33:16 theirongiant kernel: eth0:23 0003. Feb 20 18:33:16 theirongiant kernel: eth0:24 0003. Feb 20 18:33:16 theirongiant kernel: eth0:25 0003. Feb 20 18:33:16 theirongiant kernel: eth0:26 0003. Feb 20 18:33:16 theirongiant kernel: eth0:27 0003. Feb 20 18:33:16 theirongiant kernel: eth0:28 0003. Feb 20 18:33:16 theirongiant kernel: eth0:29 0003. Feb 20 18:33:16 theirongiant kernel: eth0:30 0003. Feb 20 18:33:16 theirongiant kernel: eth0:31 0003. Feb 20 18:33:16 theirongiant kernel: eth0:32 0003. Feb 20 18:33:16 theirongiant kernel: eth0:33 0003. Feb 20 18:33:16 theirongiant kernel: eth0:34 0003. Feb 20 18:33:16 theirongiant kernel: eth0:35 0003. Feb 20 18:33:16 theirongiant kernel: eth0:36 0003. Feb 20 18:33:16 theirongiant kernel: eth0:37 0003. Feb 20 18:33:16 theirongiant kernel: eth0:38 0003. Feb 20 18:33:16 theirongiant kernel: eth0:39 0003. Feb 20 18:33:16 theirongiant kernel: eth0:40 0003. Feb 20 18:33:16 theirongiant kernel: eth0:41 0003. Feb 20 18:33:16 theirongiant kernel: eth0:42 0003. Feb 20 18:33:16 theirongiant kernel: eth0:43 0003. Feb 20 18:33:16 theirongiant kernel: eth0:44 0003. Feb 20 18:33:16 theirongiant kernel: eth0:45 0003. Feb 20 18:33:16 theirongiant kernel: eth0:46 0003. Feb 20 18:33:16 theirongiant kernel: eth0:47 0003. Feb 20 18:33:16 theirongiant kernel: eth0:48 0003. Feb 20 18:33:16 theirongiant kernel: eth0:49 0003. Feb 20 18:33:16 theirongiant kernel: eth0:50 0003. Feb 20 18:33:16 theirongiant kernel: eth0:51 0003. Feb 20 18:33:16 theirongiant kernel: eth0:52 0003. Feb 20 18:33:16 theirongiant kernel: eth0:53 0003. Feb 20 18:33:16 theirongiant kernel: eth0:54 0003. Feb 20 18:33:16 theirongiant kernel: eth0:55 000c. Feb 20 18:33:16 theirongiant kernel: eth0:56 000c. Feb 20 18:33:16 theirongiant kernel: eth0:57 0003. Feb 20 18:33:16 theirongiant kernel: eth0:58 000c. Feb 20 18:33:16 theirongiant kernel: eth0:59 000c. Feb 20 18:33:16 theirongiant kernel: eth0:60 0003. Feb 20 18:33:16 theirongiant kernel: eth0:61 0003. Feb 20 18:33:16 theirongiant kernel: eth0:62 400
Re: eepro100 + 2.2.18 + laptop problems
On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote: > > In my experiments wait_for_cmd timeouts almost always were related to > > DumpStats command. > > I think, we need to investigate what time constraints are related to this > > command. > > Nothing documented... > > CaT, can you apply this debugging patch and let us know what you get in the > logs? It should allow us to pinpoint the error a bit more precisely. patched, old removed, new installed, waiting for fubar. :) still with 2.2.18 -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Mon, Feb 19, 2001 at 03:44:10PM -0800, Dragan Stancevic wrote: > On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote: > ; > ; None. This is before any traffic gets put through it. At worst the > ; card has the wrong IP for the network but that is not always the case > ; from memory. > > So where does that card get the address from, are you doing DHCP? Set manually. In debian-speak: ifup eth0 where: iface eth0 inet static address 10.1.1.2 netmask 255.255.255.0 network 10.1.1.0 broadcast 10.1.1.255 gateway 10.1.1.1 So basically that does an ifconfig and route command I believe (or the equivalent) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Mon, Feb 19, 2001 at 03:37:02PM -0800, Dragan Stancevic wrote: > On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote: > ; > 100% accuracy and so it'll take me a wee while before I decide ' > ; > a... that rocks my boat. it's fixed.'. :) > ; > ; It happened again. Same deal. Once was after a reboot and this time > ; was after a resume. :/ > > What kind of trafic are you running? None. This is before any traffic gets put through it. At worst the card has the wrong IP for the network but that is not always the case from memory. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote: > On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote: > > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote: > > [snip] > > > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout >with(0x70)! > > > > Please try the attached patch. > > Actually, it's designed to solve another problem, but may be your one has the > > same origin as that other. > > Cool. Thanks. I recompiled the module and am trying it now. So far the > ethernet connection is fine but the above problem isn't reproducable with > 100% accuracy and so it'll take me a wee while before I decide ' > a... that rocks my boat. it's fixed.'. :) It happened again. Same deal. Once was after a reboot and this time was after a resume. :/ Help? -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. speaking of mental giants.. me, a giant, bullshit And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote: On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote: On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote: [snip] Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)! Please try the attached patch. Actually, it's designed to solve another problem, but may be your one has the same origin as that other. Cool. Thanks. I recompiled the module and am trying it now. So far the ethernet connection is fine but the above problem isn't reproducable with 100% accuracy and so it'll take me a wee while before I decide ' a... that rocks my boat. it's fixed.'. :) It happened again. Same deal. Once was after a reboot and this time was after a resume. :/ Help? -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Mon, Feb 19, 2001 at 03:37:02PM -0800, Dragan Stancevic wrote: On Tue, Feb 20, 2001, CaT [EMAIL PROTECTED] wrote: ; 100% accuracy and so it'll take me a wee while before I decide ' ; a... that rocks my boat. it's fixed.'. :) ; ; It happened again. Same deal. Once was after a reboot and this time ; was after a resume. :/ What kind of trafic are you running? None. This is before any traffic gets put through it. At worst the card has the wrong IP for the network but that is not always the case from memory. -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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: eepro100 + 2.2.18 + laptop problems
On Mon, Feb 19, 2001 at 03:44:10PM -0800, Dragan Stancevic wrote: On Tue, Feb 20, 2001, CaT [EMAIL PROTECTED] wrote: ; ; None. This is before any traffic gets put through it. At worst the ; card has the wrong IP for the network but that is not always the case ; from memory. So where does that card get the address from, are you doing DHCP? Set manually. In debian-speak: ifup eth0 where: iface eth0 inet static address 10.1.1.2 netmask 255.255.255.0 network 10.1.1.0 broadcast 10.1.1.255 gateway 10.1.1.1 So basically that does an ifconfig and route command I believe (or the equivalent) -- CaT ([EMAIL PROTECTED])*** Jenna has joined the channel. cat speaking of mental giants.. Jenna me, a giant, bullshit Jenna And i'm not mental - An IRC session, 20/12/2000 - 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/
