Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 2 subscribers
  • Views 1680 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

reduce kernel.log

chrisys
Hi there,

is there a way to reduce the size of kernel.log? Here is an example of mine:
-rw-r-----    1 root     log          327M Jun  2 17:55 kernel.log

The fact is that most of the enties look like this:

2004:06:02-17:10:04 (none) kernel: 1f 062711f0 06271000 0001807d(1f) 00000000 00000000
2004:06:02-17:10:04 (none) kernel: TxListPtr=062710f0 netif_queue_stopped=0
2004:06:02-17:10:04 (none) kernel: cur_tx=1680(10) dirty_tx=1680(10)
2004:06:02-17:10:04 (none) kernel: cur_rx=54 dirty_rx=54
2004:06:02-17:10:04 (none) kernel: cur_task=1680

I think it's just logging of nic-traffic and not very useful?!
Thanks!


This thread was automatically locked due to age.
Parents
  • 0
    thanks for reply!

    it's a DLink DFE-580 (4 Interfaces).  Worked without problems so far. Had no problem with it under RedHat, too.
  • 0 in reply to chrisys
    In Version 4, some of our customers reported problems with this NIC under heavy load. For Version 5 we did not have the time to test ourselves (yet), so we put this NIC to unsupported on the HCL. Some customers reported the NIC as working, but none of them had high load.
    Can you please add more kernel information to your posting? I think the important part of the error message is missing...
  • 0 in reply to andreas
    Whats the definition of heavy load?

    heres more info from kernel.log:

    2004:06:04-14:00:05 (none) kernel: TxListPtr=06181150 netif_queue_stopped=0
    2004:06:04-14:00:05 (none) kernel: cur_tx=48438(16) dirty_tx=48438(16)
    2004:06:04-14:00:05 (none) kernel: cur_rx=4 dirty_rx=4
    2004:06:04-14:00:05 (none) kernel: cur_task=48438
    2004:06:04-14:00:05 (none) kernel: 00 06179000 06179010 00018001(00) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 01 06179010 06179020 00018005(01) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 02 06179020 06179030 00018009(02) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 03 06179030 06179040 0001800d(03) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 04 06179040 06179050 00018011(04) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 05 06179050 06179060 00018015(05) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 06 06179060 06179070 00018019(06) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 07 06179070 06179080 0001801d(07) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 08 06179080 06179090 00018021(08) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 09 06179090 061790a0 00018025(09) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 0a 061790a0 061790b0 00018029(0a) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 0b 061790b0 061790c0 0001802d(0b) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 0c 061790c0 061790d0 00018031(0c) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 0d 061790d0 061790e0 00018035(0d) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 0e 061790e0 061790f0 00018039(0e) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 0f 061790f0 06179100 0001803d(0f) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 10 06179100 06179110 00018041(10) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 11 06179110 06179120 00018045(11) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 12 06179120 06179130 00018049(12) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 13 06179130 06179140 0001804d(13) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 14 06179140 06179150 00018051(14) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 15 06179150 06179160 00018055(15) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 16 06179160 06179170 00018059(16) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 17 06179170 06179180 0001805d(17) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 18 06179180 06179190 00018061(18) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 19 06179190 061791a0 00018065(19) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 1a 061791a0 061791b0 00018069(1a) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 1b 061791b0 061791c0 0001806d(1b) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 1c 061791c0 061791d0 00018071(1c) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 1d 061791d0 00000000 00018075(1d) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 1e 061791e0 061791f0 00018079(1e) 00000000 00000000
    2004:06:04-14:00:05 (none) kernel: 1f 061791f0 06179000 0001807d(1f) 00000000 00000000  
    *here it starts again
    2004:06:04-14:00:05 (none) kernel: TxListPtr=061791d0 netif_queue_stopped=0
    2004:06:04-14:00:05 (none) kernel: cur_tx=31806(1e) dirty_tx=31806(1e)


    Greetings
  • 0 in reply to chrisys
    I did some hardware tinkering yesterday and put a DFE 580 TX into one of our test machines. It shows the same behaviour like yours, the kernel log looks similar. My personal opionion is that the kernel module (sundance) might be compiled with wrong flags or a debug switch turned on, but it might as well be totally broken. I have to check with our kernel maintainer.

    Since this is slightly off-topic I am going to move this thread into the hardware section on monday.

    Greets,
    andreas
  • 0 in reply to chrisys
    I think this is not a kernel problem, in fact after testing, this behavior occure  with others nic too lik edfe 570 tx ...  and it's occure only when your asl run an license. If you use these card whithout install any license, it works very well
  • 0 in reply to Chettam
    It's a driver/module issue. You'll actually get this with every card that uses this sundance driver. After checking the sources for this driver it's clear that it is the origin. Astaro should provide a driver that does not include this kind of logging. Or is there a safe way to build the driver on my own?
Reply
  • 0 in reply to Chettam
    It's a driver/module issue. You'll actually get this with every card that uses this sundance driver. After checking the sources for this driver it's clear that it is the origin. Astaro should provide a driver that does not include this kind of logging. Or is there a safe way to build the driver on my own?
Children
  • 0 in reply to Duke_01
    Duke,
    can you tell me whythese message only appends when i run asl with license installed and why there is no message like that  if you don't run your license ?
  • 0 in reply to Chettam
    Since Andreas could identify the problem on one of our testing devices I have reported the problem to our error tracking system with an adequate priority.

    read u
    o|iver
  • 0 in reply to Chettam
    [ QUOTE ]
    Duke,
    can you tell me whythese message only appends when i run asl with license installed and why there is no message like that  if you don't run your license ? 

    [/ QUOTE ]
    No, unfortunately not. As the driver appears to do the logging unconditionally, I have no idea why it does not make its way into the kernel log when there's no license installed.

    @oliver: Thanks for the heads up. Is there an ETA for a fix?
Cookie Information Banner