2010年3月31日 星期三

12V鉛酸電池充電

UC2906/3906鉛酸電池充電監控IC簡介
http://designer.mech.yzu.edu.tw/article/articles/technical/file/(2004-06-03)%20UC29063906%B9%5D%BB%C4%B9q%A6%C0%A5R%B9q%BA%CA%B1%B1IC%C2%B2%A4%B6.pdf

(1) 涓流充電(trickle charge):電壓供應給充電器後,充電器第11腳位(trickle bias output)輸出一微小恆定電流IT,此作法可避免因蓄電池反接而造成迴路短路。

(2) 大電流充電(bulk charge):當充電器輸出電壓上升至VT時,則進入此狀態,大電流Imax由外部電晶體(PNP pass transistor)導通輸出至電池,蓄電池主要的電量亦在此階段回充。

(3) 過充電(over-charge):在完成大電流充電階段時,電池電壓達到過充電電壓VOC的95%時(即圖5中V23),即進入過充電狀態,充電電流逐漸下降,當充電器的電壓達到VOC後,充電電流亦從大容量充電電流IMAX下降至過充電終止電流IOCT,充電器將進入浮動充電狀態。

(4) 浮動充電(float charge):此狀態下充電電壓由VOC下降,並維持在VF,電池充電程序近乎完成;當電池接上負載而放電後,充電器將直接提供電源輸出,而電池電壓也勢必下降,當電壓下降至V41(V41=0.9VF)時,則充電模式重新設定回涓流充電階段,重新執行新的充電循環程序。浮動充電程序對於延長蓄電池的壽命是有必要的,當蓄電池充電完成後,若移除充電電壓,則蓄電池又會立即自行放電,因此必須對電池施加一個適當電壓以及微小的電流以避免電放電,因此浮動充電狀態又可稱為待機充電狀態(standby charge)。


VF=13.8V
VOC=15V
IMAX=0.5A
IOCT=IMAX/10

2010年3月27日 星期六

Highmem with VIPT cache and DMA

Highmem issues with MMC filesystem
http://www.spinics.net/lists/linux-mmc/msg01473.html

there's more changes between ARMv5 and ARMv6 than just
the cache model. There's weak memory ordering effects too.

(.............)

at the moment we have:

- ARMv5 without highmem -> works

- ARMv5 with highmem -> works

- ARMv6 without highmem -> works

- ARMv6 with highmem -> fails

In all four cases the SATA driver, the hard disk and the filesystem on
it are identical. In the two ARMv5 cases the system and the kernel are
identical. Ditto for the two ARMv6 cases.

And the kernel used is the very latest i.e. v2.6.34-rc1-1642-gfc7f99c.

(.............)

Marvell 88AP510 aka Dove. But the same issue was reported on OMAP.

(.............)

Any block device using DMA is affected. Drivers using PIO are not,
neither is NFS. And again, using the _same_ kernel with mem=512m so to
be sure highmem doesn't kick in exhibits no issue even with DMA.

(.............)

(.............)


[PATCH] ARM: fix highmem with VIPT cache and DMA
http://www.spinics.net/lists/linux-mmc/msg01537.html
The VIVT cache of a highmem page is always flushed before the page is unmapped. This cache flush is explicit through flush_cache_kmaps() in flush_all_zero_pkmaps(), or through _cpuc_flush_dcache_area() in kunmap_atomic(). There is also an implicit flush of those highmem pages that were part of a process that just terminated making those pages free as the whole VIVT cache has to be flushed on every task switch. Hence unmapped highmem pages need no cache maintenance in that case.

However unmapped pages may still be cached with a VIPT cache because the cache is tagged with physical addresses. There is no need for a whole cache flush during task switching for that reason, and despite the explicit cache flushes in flush_all_zero_pkmaps() and kunmap_atomic(), some highmem pages that were mapped in user space end up still cached even when they become unmapped.

So, we do have to perform cache maintenance on those unmapped highmem pages in the context of DMA when using a VIPT cache. Unfortunately, it is not possible to perform that cache maintenance using physical addresses as all the L1 cache maintenance coprocessor functions accept virtual addresses only. Therefore we have no choice but to set up a temporary virtual mapping for that purpose.

And of course the explicit cache flushing when unmapping a highmem page on a system with a VIPT cache now can go, which should increase performance.

While at it, because the code in __flush_dcache_page() has to be modified anyway, let's also make sure the mapped highmem pages are pinned with kmap_high_get() for the duration of the cache maintenance operation. Because kunmap() does unmap highmem pages lazily, it was reported by Gary King <GKing@xxxxxxxxxx> that those pages ended up being unmapped during cache maintenance on SMP causing segmentation faults.

2010年3月26日 星期五

Adjust MAX_ORDER from 11 to 12 or higher cause e1000e error?

(not fixed yet)

2.6.31.1
e1000e, WG82574L, v1.0.2-k2
Adjust MAX_ORDER from 11 to 12 or higher, iozone a samba share on DUT would cause following dump around 128M~2G tests. e1000e is temporarily down, and then up again. But would occur again and again.

[  247.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  247.040000]   TDH                  <da>
[  247.040000]   TDT                  <8>
[  247.040000]   next_to_use          <8>
[  247.040000]   next_to_clean        <d7>
[  247.040000] buffer_info[next_to_clean]:
[  247.040000]   time_stamp           <ffffea9f>
[  247.040000]   next_to_watch        <da>
[  247.040000]   jiffies              <ffffeb50>
[  247.040000]   next_to_watch.status <0>
[  249.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  249.040000]   TDH                  <da>
[  249.040000]   TDT                  <8>
[  249.040000]   next_to_use          <8>
[  249.040000]   next_to_clean        <d7>
[  249.040000] buffer_info[next_to_clean]:
[  249.040000]   time_stamp           <ffffea9f>
[  249.040000]   next_to_watch        <da>
[  249.040000]   jiffies              <ffffec18>
[  249.040000]   next_to_watch.status <0>
[  251.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  251.040000]   TDH                  <da>
[  251.040000]   TDT                  <8>
[  251.040000]   next_to_use          <8>
[  251.040000]   next_to_clean        <d7>
[  251.040000] buffer_info[next_to_clean]:
[  251.040000]   time_stamp           <ffffea9f>
[  251.040000]   next_to_watch        <da>
[  251.040000]   jiffies              <ffffece0>
[  251.040000]   next_to_watch.status <0>
[  253.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  253.040000]   TDH                  <da>
[  253.040000]   TDT                  <8>
[  253.040000]   next_to_use          <8>
[  253.040000]   next_to_clean        <d7>
[  253.040000] buffer_info[next_to_clean]:
[  253.040000]   time_stamp           <ffffea9f>
[  253.040000]   next_to_watch        <da>
[  253.040000]   jiffies              <ffffeda8>
[  253.040000]   next_to_watch.status <0>
[  255.040000] ------------[ cut here ]------------
[  255.050000] WARNING: at net/sched/sch_generic.c:246 dev_watchdog+0x140/0x220()
[  255.060000] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
[  255.070000] Modules linked in: dwc_otg ohci_hcd ehci_hcd e1000e
[  255.090000] [<c0031bac>] (unwind_backtrace+0x0/0xdc) from [<c0045b4c>] (warn_slowpath_common+0x4c/0x80)
[  255.120000] [<c0045b4c>] (warn_slowpath_common+0x4c/0x80) from [<c0045bbc>] (warn_slowpath_fmt+0x28/0x38)
[  255.140000] [<c0045bbc>] (warn_slowpath_fmt+0x28/0x38) from [<c0223e14>] (dev_watchdog+0x140/0x220)
[  255.170000] [<c0223e14>] (dev_watchdog+0x140/0x220) from [<c004e660>] (run_timer_softirq+0x184/0x208)
[  255.200000] [<c004e660>] (run_timer_softirq+0x184/0x208) from [<c004a538>] (__do_softirq+0x78/0x100)
[  255.220000] [<c004a538>] (__do_softirq+0x78/0x100) from [<c002b070>] (_text+0x70/0x8c)
[  255.250000] [<c002b070>] (_text+0x70/0x8c) from [<c002ba58>] (__irq_svc+0x38/0x80)
[  255.270000] Exception stack(0xc037ff78 to 0xc037ffc0)
[  255.280000] ff60:                                                       c0383998 00000000 
[  255.300000] ff80: c037e000 00000000 c037e000 c0381c84 c03a5c8c c0381c78 00000000 410fb024 
[  255.330000] ffa0: 00022b2c 00000000 c037ff90 c037ffc0 c002ce1c c002ce20 60000013 ffffffff 
[  255.350000] [<c002ba58>] (__irq_svc+0x38/0x80) from [<c002ce20>] (default_idle+0x24/0x2c)
[  255.370000] [<c002ce20>] (default_idle+0x24/0x2c) from [<c002d2d8>] (cpu_idle+0x3c/0x78)
[  255.400000] [<c002d2d8>] (cpu_idle+0x3c/0x78) from [<c0008918>] (start_kernel+0x248/0x2ac)
[  255.420000] [<c0008918>] (start_kernel+0x248/0x2ac) from [<0000802c>] (0x802c)
[  255.440000] ---[ end trace d9e3a5e60e497ff6 ]---
[  255.450000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  255.450000]   TDH                  <da>
[  255.450000]   TDT                  <8>
[  255.450000]   next_to_use          <8>
[  255.450000]   next_to_clean        <d7>
[  255.450000] buffer_info[next_to_clean]:
[  255.450000]   time_stamp           <ffffea9f>
[  255.450000]   next_to_watch        <da>
[  255.450000]   jiffies              <ffffee99>
[  255.450000]   next_to_watch.status <0>
[  257.870000] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[  257.880000] 0000:00:01.0: eth0: 10/100 speed: disabling TSO
[  262.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  262.040000]   TDH                  <3>
[  262.040000]   TDT                  <4>
[  262.040000]   next_to_use          <4>
[  262.040000]   next_to_clean        <0>
[  262.040000] buffer_info[next_to_clean]:
[  262.040000]   time_stamp           <fffff00d>
[  262.040000]   next_to_watch        <3>
[  262.040000]   jiffies              <fffff12c>
[  262.040000]   next_to_watch.status <0>
[  264.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  264.040000]   TDH                  <3>
[  264.040000]   TDT                  <4>
[  264.040000]   next_to_use          <4>
[  264.040000]   next_to_clean        <0>
[  264.040000] buffer_info[next_to_clean]:
[  264.040000]   time_stamp           <fffff00d>
[  264.040000]   next_to_watch        <3>
[  264.040000]   jiffies              <fffff1f4>
[  264.040000]   next_to_watch.status <0>
[  266.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  266.040000]   TDH                  <3>
[  266.040000]   TDT                  <4>
[  266.040000]   next_to_use          <4>
[  266.040000]   next_to_clean        <0>
[  266.040000] buffer_info[next_to_clean]:
[  266.040000]   time_stamp           <fffff00d>
[  266.040000]   next_to_watch        <3>
[  266.040000]   jiffies              <fffff2bc>
[  266.040000]   next_to_watch.status <0>
[  268.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  268.040000]   TDH                  <3>
[  268.040000]   TDT                  <4>
[  268.040000]   next_to_use          <4>
[  268.040000]   next_to_clean        <0>
[  268.040000] buffer_info[next_to_clean]:
[  268.040000]   time_stamp           <fffff00d>
[  268.040000]   next_to_watch        <3>
[  268.040000]   jiffies              <fffff384>
[  268.040000]   next_to_watch.status <0>
[  270.450000] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[  270.460000] 0000:00:01.0: eth0: 10/100 speed: disabling TSO
[  275.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  275.040000]   TDH                  <5>
[  275.040000]   TDT                  <7>
[  275.040000]   next_to_use          <7>
[  275.040000]   next_to_clean        <2>
[  275.040000] buffer_info[next_to_clean]:
[  275.040000]   time_stamp           <fffff58d>
[  275.040000]   next_to_watch        <5>
[  275.040000]   jiffies              <fffff640>
[  275.040000]   next_to_watch.status <0>
[  277.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  277.040000]   TDH                  <5>
[  277.040000]   TDT                  <7>
[  277.040000]   next_to_use          <7>
[  277.040000]   next_to_clean        <2>
[  277.040000] buffer_info[next_to_clean]:
[  277.040000]   time_stamp           <fffff58d>
[  277.040000]   next_to_watch        <5>
[  277.040000]   jiffies              <fffff708>
[  277.040000]   next_to_watch.status <0>
[  279.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  279.040000]   TDH                  <5>
[  279.040000]   TDT                  <7>
[  279.040000]   next_to_use          <7>
[  279.040000]   next_to_clean        <2>
[  279.040000] buffer_info[next_to_clean]:
[  279.040000]   time_stamp           <fffff58d>
[  279.040000]   next_to_watch        <5>
[  279.040000]   jiffies              <fffff7d0>
[  279.040000]   next_to_watch.status <0>
[  281.040000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  281.040000]   TDH                  <5>
[  281.040000]   TDT                  <7>
[  281.040000]   next_to_use          <7>
[  281.040000]   next_to_clean        <2>
[  281.040000] buffer_info[next_to_clean]:
[  281.040000]   time_stamp           <fffff58d>
[  281.040000]   next_to_watch        <5>
[  281.040000]   jiffies              <fffff898>
[  281.040000]   next_to_watch.status <0>
[  283.450000] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[  283.460000] 0000:00:01.0: eth0: 10/100 speed: disabling TSO
[  304.000000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  304.000000]   TDH                  <6b>
[  304.000000]   TDT                  <a0>
[  304.000000]   next_to_use          <a0>
[  304.000000]   next_to_clean        <68>
[  304.000000] buffer_info[next_to_clean]:
[  304.000000]   time_stamp           <8d>
[  304.000000]   next_to_watch        <6b>
[  304.000000]   jiffies              <190>
[  304.000000]   next_to_watch.status <0>
[  306.000000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  306.000000]   TDH                  <6b>
[  306.000000]   TDT                  <a0>
[  306.000000]   next_to_use          <a0>
[  306.000000]   next_to_clean        <68>
[  306.000000] buffer_info[next_to_clean]:
[  306.000000]   time_stamp           <8d>
[  306.000000]   next_to_watch        <6b>
[  306.000000]   jiffies              <258>
[  306.000000]   next_to_watch.status <0>
[  308.000000] 0000:00:01.0: eth0: Detected Tx Unit Hang:
[  308.000000]   TDH                  <6b>
[  308.000000]   TDT                  <a0>
[  308.000000]   next_to_use          <a0>
[  308.000000]   next_to_clean        <68>
[  308.000000] buffer_info[next_to_clean]:
[  308.000000]   time_stamp           <8d>
[  308.000000]   next_to_watch        <6b>
[  308.000000]   jiffies              <320>
[  308.000000]   next_to_watch.status <0>
[  311.520000] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[  311.530000] 0000:00:01.0: eth0: 10/100 speed: disabling TSO


Intel Wired Ethernet: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
http://sourceforge.net/tracker/download.php?group_id=42302&atid=447451&file_id=172710&aid=1460945

[Bug 30476] Re: e1000_clean_tx_irq: Detected Tx Unit Hang
https://lists.ubuntu.com/archives/kernel-bugs/2007-July/028088.html
Several NIC's with the 82573 chipset display "TX unit hang" messages
during normal operation with the linux e1000 driver. The issue appears
both with TSO enabled and disabled, and is caused by a power management
function that is enabled in the EEPROM. Early releases of the chipsets
to vendors had the EEPROM bit that enabled the feature. After the issue
was discovered newer adapters were released with the feature disabled in
the EEPROM.

See : http://e1000.sourceforge.net/wiki/index.php/Issues#82573.28V.2FL.2FE.29_TX_Unit_Hang_messages
Run the script fixeep-82573-dspd.sh in order to fix the problem !


e1000_clean_tx_irq: Detected Tx Unit Hang
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/30476
Please note, there are multiple causes of this symptom.

As posted by Dominique Gallot above, if you have an adapter (on board or standalone) based on the Intel 82573 chipset, this issue may be caused by an improper setting in the adapter's EEPROM. It will occur regardless of TSO setting, and even in the new 2.6.27 kernel shipping with Intrepid Ibex. The following document from Intel has additional information, under the section "82573(V/L/E) TX Unit Hang Messages".
http://downloadmirror.intel.com/9180/eng/README.txt

The script to automatically detect and permanently fix this issue can be downloaded at:
http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh

Note: The link provided in the comment above is now broken.


http://downloadmirror.intel.com/9180/eng/README.txt
CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection (controller 82547), setting InterruptThrottleRate to a value greater than 75,000, may hang (stop transmitting) adapters under certain network conditions. If this occurs a NETDEV WATCHDOG message is logged in the system event log. In addition, the controller is automatically reset, restoring the network connection. To eliminate the potential for the hang, ensure that InterruptThrottleRate is set no greater than 75,000 and is not set to 0.

(.................)

CAUTION: When setting RxIntDelay to a value other than 0, adapters may hang (stop transmitting) under certain network conditions. If this occurs a NETDEV WATCHDOG message is logged in the system event log. In addition, the controller is automatically reset, restoring the network connection. To eliminate the potential for the hang ensure that RxIntDelay is set to 0.

(.................)

ignore_64bit_dma
----------------
Valid Range: 0-xxxxxxx (0=off)
Default Value: 0
Usage: insmod e1000.ko ignore_64bit_dma=1

When non zero the driver will only request DMA mapping of host memory
in the lower 4GB region. This provides a workaround for users of AMD platforms
GA-MA78G-DS3H & SM4021M-T2R+ that have reported TXHangs on system that have
>4GB RAM, suspected caused by some (no deep root cause) issue in the Dual
Address Cycle (DAC) DMA mechanism needed to access addresses above 4GB.
Setting ignore_64bit_dma to 1 activates the workaround.

This parameter is different than other parameters, in that it is a
single (not 1,1,1 etc.) parameter applied to all driver instances and
it is also available during runtime at
/sys/module/e1000/parameters/ignore_64bit_dma

(.................)

Detected Tx Unit Hang in Quad Port Adapters
-------------------------------------------
In some cases ports 3 and 4 don't pass traffic and report 'Detected Tx Unit
Hang' followed by 'NETDEV WATCHDOG: ethX: transmit timed out' errors. Ports
1 and 2 don't show any errors and will pass traffic.

This issue MAY be resolved by updating to the latest kernel and BIOS. The
user is encouraged to run an OS that fully supports MSI interrupts. You can
check your system's BIOS by downloading the Linux Firmware Developer Kit
that can be obtained at http://www.linuxfirmwarekit.org/

82573(V/L/E) TX Unit Hang Messages
----------------------------------
Several adapters with the 82573 chipset display "TX unit hang" messages
during normal operation with the e1000 driver. The issue appears both with
TSO enabled and disabled, and is caused by a power management function that
is enabled in the EEPROM. Early releases of the chipsets to vendors had the
EEPROM bit that enabled the feature. After the issue was discovered newer
adapters were released with the feature disabled in the EEPROM.

If you encounter the problem in an adapter, and the chipset is an 82573-based
one, you can verify that your adapter needs the fix by using ethtool:

# ethtool -e eth0
Offset Values
------ ------
0x0000 00 12 34 56 fe dc 30 0d 46 f7 f4 00 ff ff ff ff
0x0010 ff ff ff ff 6b 02 8c 10 d9 15 8c 10 86 80 de 83

The value at offset 0x001e (de) has bit 0 unset. This enables the problematic
power saving feature. In this case, the EEPROM needs to read "df" at offset
0x001e.

A one-time EEPROM fix is available as a shell script. This script will verify
that the adapter is applicable to the fix and if the fix is needed or not. If
the fix is required, it applies the change to the EEPROM and updates the
checksum. The user must reboot the system after applying the fix if changes
were made to the EEPROM.

Example output of the script:

# bash fixeep-82573-dspd.sh eth0
eth0: is a "82573E Gigabit Ethernet Controller"
This fixup is applicable to your hardware
executing command: ethtool -E eth0 magic 0x109a8086 offset 0x1e value 0xdf
Change made. You *MUST* reboot your machine before changes take effect!

The script can be downloaded at
http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh

(.................)


(not fixed yet...) I'm using WG82574L, instead of 82573.
Set MAX_ORDER from 11 to 12, pageblock_order=(MAX_ORDER-1), if pageblock_nr_pages = (1<<10) instead of (1<<pageblock_order) could avoid the problem.

2010年3月25日 星期四

git-format-patch

git-format-patch(1) Manual Page
http://kernel.org/pub/software/scm/git/docs/git-format-patch.html


git-format-patch v2.6.31.1 -o patches -n

PPPoE client connected to server, can ping, but cannot iperf

Linux-2.6.31.1
Running PPPoE client to server, ping is ok, but iperf-ing failed.

After some debug, found that the kernel loop in the for loop of ppp_async_push endlessly

__qdisc_run
qdisc_restart
dev_hard_start_xmit
ppp_start_xmit
ppp_xmit_process
ppp_push
ppp_async_send
ppp_async_push

pty_write

flush_to_ldisc


ChangeLog-2.6.31.2
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.31.2
commit a7207f0d215647ce7ee5f0e6308d6afab6f3584c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri Sep 18 07:05:58 2009 -0700

pty_write: don't do a tty_wakeup() when the buffers are full

commit 202c4675c55ddf6b443c7e057d2dff6b42ef71aa upstream.

Commit ac89a9174 ("pty: don't limit the writes to 'pty_space()' inside
'pty_write()'") removed the pty_space() checking, in order to let the
regular tty buffer code limit the buffering itself.

That was all good, but as a subtle side effect it meant that we'd be
doing a tty_wakeup() even in the case where the buffers were all filled
up, and didn't actually make any progress on the write.

Which sounds innocuous, but it interacts very badly with the ppp_async
code, which has an infinite loop in ppp_async_push() that tries to push
out data to the tty. When we call tty_wakeup(), that loop ends up
thinking that progress was made (see the subtle interactions between
XMIT_WAKEUP and 'tty_stuffed' for details). End result: one unhappy ppp
user.

Fixed by noticing when tty_insert_flip_string() didn't actually do
anything, and then not doing any more processing (including, very much
not calling tty_wakeup()).

Bisected-and-tested-by: Peter Volkov <pva@gentoo.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

https://www.codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=a7207f0d215647ce7ee5f0e6308d6afab6f3584c



[linux-usb-devel] quick hack to make ipaq USB serial driver work again
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg18279.html

Paul Mackerras: [PATCH] Make ppp_async callable from hard interrupt
http://lkml.org/lkml/2003/12/20/97


BUG: scheduling while atomic
http://lists.openwall.net/linux-kernel/2009/06/19/306

Bug 13522 - BUG: scheduling while atomic
https://bugzilla.kernel.org/show_bug.cgi?id=13522

Re: [Bug #13522] BUG: scheduling while atomic
http://lkml.org/lkml/2009/6/29/237

Re: BUG: scheduling while atomic
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-07/msg02597.html

BUG: scheduling while atomic reintroduced
http://groups.google.co.kr/group/linux.kernel/browse_thread/thread/3c55a8c8358940f0

Linux PPP 数据收发流程
http://student.csdn.net/space.php?uid=120684&do=blog&id=10522

2010年3月23日 星期二

Linux highmem

HighMemory
http://linux-mm.org/HighMemory

Feature: High Memory In The Linux Kernel
http://kerneltrap.org/node/2450

Highmem (MIPS)
http://www.linux-mips.org/wiki/Highmem

先转一篇帖子,把HIMEM的概念讲的很清楚.
http://hi.baidu.com/lpfwd/blog/item/56c1e716d95a494120a4e9db.html

MAX_ORDER

[ 104.490000] [<c0044a0c>] (warn_slowpath_common+0x4c/0x80) from [<c0075874>] (__alloc_pages_nodemask+0x130/0x51c)

__alloc_pages_slowpath

         * In the slowpath, we sanity check order to avoid ever trying to
         * reclaim >= MAX_ORDER areas which will never succeed. Callers may
         * be using allocators in order of preference for an area that is
         * too large.
         */
        if (order >= MAX_ORDER) {
                WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
                return NULL;
        }

[ 104.520000] [<c0075874>] (__alloc_pages_nodemask+0x130/0x51c) from [<c0031530>] (__dma_alloc+0x148/0x3ac)
[ 104.550000] [<c0031530>] (__dma_alloc+0x148/0x3ac) from [<c0031810>] (dma_alloc_coherent+0x50/0x5c)
[ 104.580000] [<c0031810>] (dma_alloc_coherent+0x50/0x5c) from [<bf02d39c>]


Linux的存儲管理(一)
http://www.lslnet.com/linux/f/docs1/i31/big5242556.htm

6.2.6内存管理区
http://www.kerneltravel.net/kernel-book/%E7%AC%AC%E5%85%AD%E7%AB%A0%20Linux%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86/6.2.6.htm

Linux kernel memory management buddy system (linux内核内存管理的伙伴算法)
http://blog.csdn.net/VIV777/archive/2007/07/05/1680363.aspx

第3节 内存的分配和回收
http://www.eefocus.com/article/09-06/74976s.html

2010年3月22日 星期一

Linux SMP

http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/ch09.pdf

max_cpus Maximum number of CPUs to use.
maxcpus=n
Specify the maximum number of processors that a SMPkernel
should use, even if there are more processors present in the system.

isolcpus Isolate CPUs from the kernel scheduler.
isolcpus=cpu_number[,cpu_number,...]
Remove the specified CPUs, as defined by the cpu_number values,
from the general kernel SMPbalancing and scheduler algroithms.
The only way to move a process onto or off an “isolated” CPU is
via the CPU affinity syscalls. cpu_number begins at 0, so the
maximum value is one less than the number of CPUs on the
system.
This option is the preferred way to isolate CPUs. The alternative,
manually setting the CPU mask of all tasks in the system, can cause
problems and suboptimal load-balancer performance.


Re: Inquiry: Should we remove "isolcpus= kernel boot option? (mayhave realtime uses)
http://lkml.indiana.edu/hypermail/linux/kernel/0806.0/0759.html
http://lkml.indiana.edu/hypermail/linux/kernel/0806.0/1241.html



To bring cpuN offline
echo 0 > /sys/devices/system/cpu/cpuN/online

(..............)

Boot your system with maxcpus=1. That way the kernel will only bring up processor 0. I'm assuming cpu0 is "good" otherwise your system is totally busted :). Other cpus will stay off-line and will not be initialized.

Then once the system boots you can selectively bring "good" processors online by doing
echo 1 > /sys/devices/system/cpu/cpuN/online


(Following is talking about the altitude that kernel treat "unused" functions)
http://lkml.indiana.edu/hypermail/linux/kernel/0806.0/1262.html
A key reason that Linux has succeeded is that it actively seeks to work
for a variety of people, purposes and products. One operating system is
now a strong player in the embedded market, the real time market, and
the High Performance Computing market, as well as being an important
player in a variety of other markets. That's a rather stunning success.

If you went to your local grocery store with your (if you have one)
young child, and found that they had no Lucky Charms breakfast cereal
(your childs favorite) you would not be pleased if the store manager
tried to sell you Fruit Loops instead ... just as much sugar and food
coloring.

If we have features that seem to duplicate functionality, in a
different way, and that aren't causing us substantial grief to
maintain, and that aren't significantly hurting our performance or
robustness or security or seriously getting in the way of further
development, then we usually leave those features in.

Please understand, Max, that for every kernel hacker working in this
corner of the Linux kernel, there are a hundred or a thousand users
depending on what we do, and who will have to adapt to any incompatible
changes we make. If we save ourselves an hour by removing "unnecessary"
features, we can cost a hundred others each some time adapting to this
change. A few of those others may get hit for substantial effort, if
the change catches them unawares at the wrong time and place.


As good citizens of the universe, we should seek to optimize the
aggregate effort we spend to obtain a particular level of quality and
functionality.


Saving yourself an hour while you cost a hundred others ten minutes
each is not a net gain.
Sometimes this means not enforcing a "one way,
and one way only, to do any given task." I wouldn't go as far as Perl
does in this regard, but we do run a more polyglot product than say
Python.

Try thinking a little more like a WalMart product manager than a
Ferrari designer. If it is currently selling to our customers, and if
we can fit it into our supply and distribution chain, and if we can
continue to make an adequate profit per foot of shelf space, then
continue to buy it, stock it, ship it, and sell it.

2010年3月13日 星期六

SKI SK02SE 卡啦OK點歌機
















SKi數位媒體播放器
http://www.wach.com.tw/
官網目前都連不到, 這是Google的網頁備份
http://74.125.153.132/search?q=cache:TPc9TIKMWiEJ:www.wach.com.tw/+ski&cd=3&hl=zh-TW&ct=clnk&gl=tw&client=firefox-a

省錢伴唱機SKI SK02se
http://blog.xuite.net/cuteman/blog/30318218

SKI大容量硬碟式點歌機SK 02,有了他家裡就是錢櫃KTV
http://www.mobile01.com/topicdetail.php?f=168&t=577311

卡啦OK機的選擇[SK02、SK02SE]
http://www.mobile01.com/topicdetail.php?f=168&t=715589&last=17628501#



SKi SK02SE 640G卡拉OK點歌歡樂套組..原價9900元..特價供應
http://tw.page.bid.yahoo.com/tw/auction/d43155755?.r=1025047233

☆銓易☆ SKI SK02SE 卡啦OK點歌機 另可撥電影/MP3/照片($3000)
http://goods.ruten.com.tw/item/show?11091110979076

☆銓易☆ SKI SK02 卡啦OK點歌機 另可撥電影/MP3/照片($4500)
http://goods.ruten.com.tw/item/show?11091110982294

☆銓易☆ SKi SK01 SK02SE SK02 RM02 點歌專用無線鍵盤 特大按鍵
http://goods.ruten.com.tw/item/show?11090630767819

☆銓易☆ 高級點歌本 (點歌本皮套+內頁膠套*120+雙面花框色紙*120) SKI SK01 SK02SE SK02 卡啦OK點歌機 可用
http://goods.ruten.com.tw/item/show?11090630011250

2010年3月11日 星期四

arch/arm/kernel/process.o: Error: can't resolve `.text' {.text section} - `.LFB955' {.ARM.extab section}

Linux-2.6.31.1

Compiling failed after enable following two config:
CONFIG_FUNCTION_TRACER
CONFIG_ARM_UNWIND

  CC      arch/arm/kernel/process.o
/tmp/ccFkIp0z.s: Assembler messages:
/tmp/ccFkIp0z.s:1757: Error: can't resolve `.text' {.text section} - `.LFB955' {.ARM.extab section}
make[1]: *** [arch/arm/kernel/process.o] Error 1
make: *** [arch/arm/kernel] Error 2

Remove CONFIG_ARM_UNWIND could avoid the problem.


process.o fails to compile w/ ARM_UNWIND
http://article.gmane.org/gmane.linux.ports.arm.kernel/63682
After applying this patch, compiling would passed. However, the bootpImage wouldn't boot, even without CONFIG_TRACE_FUNCTION (with CONFIG_ARM_UNWIND):
[    3.610000] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[    3.640000] List of all partitions:
[    3.650000] No filesystem could mount root, tried:  ext3 ext2 cramfs vfat
[    3.660000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
[    3.670000] Backtrace: 
[    3.680000] [<c0035154>] (dump_backtrace+0x0/0x110) from [<c0302c54>] (dump_stack+0x1c/0x20)
[    3.700000]  r7:c80d9000 r6:c0028850 r5:c80d9016 r4:c8021f58
[    3.720000] [<c0302c38>] (dump_stack+0x0/0x20) from [<c0302ca0>] (panic+0x48/0x124)
[    3.740000] [<c0302c58>] (panic+0x0/0x124) from [<c0008f78>] (mount_block_root+0x264/0x2bc)
[    3.770000]  r3:00000000 r2:80000000 r1:c8021f58 r0:c038eb3d
[    3.780000] [<c0008d14>] (mount_block_root+0x0/0x2bc) from [<c0009024>] (mount_root+0x54/0x6c)
[    3.810000] [<c0008fd0>] (mount_root+0x0/0x6c) from [<c00091ac>] (prepare_namespace+0x170/0x1d4)
[    3.830000]  r5:c0028808 r4:c041ad38
[    3.840000] [<c000903c>] (prepare_namespace+0x0/0x1d4) from [<c0008470>] (kernel_init+0xdc/0x110)
[    3.870000]  r5:c0026e3c r4:c041ab18
[    3.880000] [<c0008394>] (kernel_init+0x0/0x110) from [<c005440c>] (do_exit+0x0/0x698)
[    3.910000]  r5:00000000 r4:00000000


without CONFIG_ARM_UNWIND and CONFIG_TRACE_FUNCTION: ....

what is stack winding and stack unwinding
http://www.unix.com/high-level-programming/41253-what-stack-winding-stack-unwinding.html
When program run, each function(data, registers, program counter, etc) is mapped onto the stack as it is called. Because the function calls other functions, they too are mapped onto the stack. This is stack winding.

Unwinding is the removal of the functions from the stack in the reverse order.


透過 User-Mode-Linux 來學習核心設計 (1)
http://blog.linux.org.tw/~jserv/archives/001871.html

[wiki]Call stack
http://en.wikipedia.org/wiki/Call_stack
[wiki] Unwinding
http://en.wikipedia.org/wiki/Call_stack#Unwinding

Using as: Using as, the Gnu Assembler, Chapter 8. Assembler Directives

8.78. .section name
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-assembler/section.html
assemble the following code into a section named name.

8.67. .previous
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-assembler/previous.html
In terms of the section stack, this directive swaps the current section with the top section on the section stack.

8.73. .pushsection name, subsection
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-assembler/pushsection.html
This directive pushes the current section (and subsection) onto the top of the section stack, and then replaces the current section and subsection with name and subsection.

8.68. .popsection
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-assembler/popsection.html
This directive replaces the current section (and subsection) with the top section (and subsection) on the section stack. This section is popped off the stack.

ftrace(1) - Linux man page
http://linux.die.net/man/1/ftrace

A look at ftrace
http://lwn.net/Articles/322666/

ftrace 简介
http://www.ibm.com/developerworks/cn/linux/l-cn-ftrace/index.html

2010年3月8日 星期一

Linux Memory Management

探索 Linux Memory Model (上)
http://blog.linux.org.tw/~jserv/archives/001461.html

探索 Linux Memory Model (下)
http://blog.linux.org.tw/~jserv/archives/001463.html

Chapter 3
Memory Management
http://tldp.org/LDP/tlk/mm/memory.html

7. Linux Memory Management
http://tldp.org/HOWTO/KernelAnalysis-HOWTO-7.html

Overview of memory management
http://www.linuxhowtos.org/System/Linux%20Memory%20Management.htm

Anatomy of a Program in Memory
http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory

Inside memory management
http://www.ibm.com/developerworks/linux/library/l-memory/

Kernel comparison: Improved memory management in the 2.6 kernel
http://www.ibm.com/developerworks/linux/library/l-mem26/

Linux, outside the (x86) box
http://www.ibm.com/developerworks/linux/library/l-nonx86.html

Linux memory management
http://www.miljan.org/main/2009/07/10/linux-memory-management/

The Linux Page Cache and pdflush:
Theory of Operation and Tuning for Write-Heavy Loads
http://www.westnet.com/~gsmith/content/linux-pdflush.htm

Linux Memory Management
http://knowledgelayer.softlayer.com/questions/205/Linux+Memory+Management

15.1. Memory Management in Linux
http://makelinux.com/ldd3/chp-15-sect-1.shtml

Memory Allocation
http://www.linuxjournal.com/article/1133



direct-mapped memory region
virt_to_phys
dma_map_single
dma_map_sg
scatterlist


vmap
kmap

2010年3月5日 星期五

Altina A800 - PAPAGO! X3 程式+圖資

http://www.papago.com.tw/Download/DownloadProjectSoftware.aspx

ftp://dl.mactiontech.com/dl/BRAND/PND/Altina/A800/ALTINA_A800_X3_090324.rar

ftp://dl.mactiontech.com/dl/BRAND/PND/MAP/X3/X3_MAP_10Q103V1.0.part1.rar
ftp://dl.mactiontech.com/dl/BRAND/PND/MAP/X3/X3_MAP_10Q103V1.0.part2.rar
ftp://dl.mactiontech.com/dl/BRAND/PND/MAP/X3/X3_MAP_10Q103V1.0.part3.rar
ftp://dl.mactiontech.com/dl/BRAND/PND/MAP/X3/X3_MAP_10Q103V1.0.part4.rar
ftp://dl.mactiontech.com/dl/BRAND/PND/MAP/X3/X3_MAP_10Q103V1.0.part5.rar

ping time is always 0ms...

Linux-2.6.31.1
It is due to HZ is 100, and the clocksource is jiffies, such that the time resolution is 10ms, so anything below 10ms, is 0.

A hardware timer is used to generate interrupt at HZ per second, and a clockevent is implemented.
So I added a clocksource for the same timer. However, the timer isn't a free-run timer, it is configured to count-down with a reload value, ie, the timer count down from reload value to 0, then generate an interrupt, and repeat, so it's somehow tricky to return value for clocksource::read():

  1. directly return the counter value isn't make sense, since it is the value "not counted", while we need the value "counted"
  2. so I return the value (reload - counter), but for reason unknown, the date/sleep just stop functioning....
  3. so I have to add jiffies to the value returned. Return ns2cyc(jiffies * NSEC_PER_JIFFY) + (reload-counter). Kernel doesn't provde ns2cyc, but there is reference in include/linux/clocksource.h:
    static inline void clocksource_calculate_interval(struct clocksource *c,
                                                      unsigned long length_nsec)
    {
            u64 tmp;

            /* Do the ns -> cycle conversion first, using original mult */
            tmp = length_nsec;
            tmp <<= c->shift;
            tmp += c->mult_orig/2;
            do_div(tmp, c->mult_orig);



busybox-1.12.2/networking/ping.c: sendping4
busybox-1.12.2/libb/time.c: monotonic_us
sysctl(__NR_clock_gettime,1)
kernel/posix-timers.c: sys_clock_gettime = SYSCALL_DEFINE2(clock_gettime, const clockid_t, which_clock, struct timespec __user *,tp)
kernel/posix-timers.c: posix_ktime_get_ts
kernel/hrtimer.c: ktime_get_ts
kernel/time/timekeeping.c: getnstimeofday
include/linux/clocksource.h: clocksource_read


./kernel/time.c: SYSCALL_DEFINE2(gettimeofday, struct timeval __user *, tv, struct timezone __user *, tz)
kernel/time/timekeeping.c: do_gettimeofday
kernel/time/timekeeping.c: getnstimeofday



kernel/hrtimer.c: SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp, struct timespec __user *, rmtp)
kernel/hrtimer.c: hrtimer_nanosleep



sysfs_override_clocksource

2010年3月4日 星期四

OpenSSL

Don't know why, but the __-evp__ is required, or the test will be done without the engin

openssl speed -evp $OP -engine XXXXX;


OpenSSL Command-Line HOWTO
http://www.madboa.com/geek/openssl/

CA建置工具Openssl的管理與使用介紹(下)
http://www.ascc.sinica.edu.tw/nl/91/1819/02.txt

產生 private key 私密金鑰 及 憑證 cert (365 天, 1024 bits)
http://ssorc.tw/rewrite.php/read-42.html

openssl speed
http://www.mkssoftware.com/docs/man1/openssl_speed.1.asp

My Notes on Patching 2.6.22 with OCF - Docunext Tech Stuff
http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF

Openssl Engine Performance Benchmarks
http://old.nabble.com/Openssl-Engine-Performance-Benchmarks-td22819097.html