On Saturday 14 October 2006 01:02, Open Source wrote:
Either the problem is in the ehci code or in devio.c. In
devio.c the user space process calls an ioctl to reap the
urb (blocking until it is complete). The asynchronous
callback for the urb is called when the urb is unlinked
and that
您好!
本公司为税务机关代开发 /票授权公司，本公司现有全国各地各种行业固定纳税公司的余额发 /票，可以优惠
对外开具。普通发 /票收取税率为1-2%，详细税率可根据地区、行业、票额大小商谈!
普通国税发 /票为商品销售（包含所有行业的商品）。普通地税发 /票为建筑、安装、广告、设计、运输、租
赁、咨询、培训、旅游、住宿等其它服务行业。本公司与全国各地区各行业的公司有发 /票业务来往。本公司只需
收到贵公司的开 /票内容后，便会通过税务机关筛选出相匹配的行业及适合的公司开具发 /票。
This email lists some known regressions in 2.6.19-rc2 compared to 2.6.18
with patches available.
Unless there are specific reasons against doing so, we should try to get
these patches into -rc3.
(Especially the lad who wrote the patch for the third entry should ush
his patch...)
If you find
Hi all,
Yes, I am on board with both Alans. I did not know
about this very nifty option in strace. I will look into
it in detail on Mon/Tue and report back.
Clearly something is weird, because there are no
other load-intensive processes running on the system.
I would think that the scheduler
Hi Wolfgang,
I'm not so sure about that. Once the interrupt is finished being
serviced, the scheduler should immediately wake up
and service any blocked processes rather than sitting
idle for one CONFIG_HZ period (4 ms when CONFIG_HZ=250).
At least that's my intuition.
As I mentioned in
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_4.45137023925781E-03
Command '--=_nextpart_4.45137023925781e-03' not recognized.
Content-Type: text/html; format=flowed
Command 'content-type:' not recognized.
On Saturday 14 October 2006 18:40, Open Source wrote:
I'm not so sure about that. Once the interrupt is finished being
serviced, the scheduler should immediately wake up
and service any blocked processes rather than sitting
idle for one CONFIG_HZ period (4 ms when CONFIG_HZ=250).
At least
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_7.97285258769989E-02
Command '--=_nextpart_7.97285258769989e-02' not recognized.
Content-Type: text/html; format=flowed
Command 'content-type:' not recognized.
On Sun, Oct 08, 2006 at 10:56:40PM -0700, Phil Dibowitz wrote:
Tobias Lorenz wrote:
Hi,
-p1 in the wrong place, unfortunately.
The change itself is good - so if you want to re-submit the patch with the
right diff'ing, that's fine, if not, I'll re-diff it and send it up stream
in
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_5.64412713050842E-02
Command '--=_nextpart_5.64412713050842e-02' not recognized.
Content-Type: text/html; format=flowed
Command 'content-type:' not recognized.
Hi Wolfgang and all,
I really don't want to belabor this point, and there are surely
more qualified people to chime in than myself, but let's take
this thought experiment:
1) User space wants to access some data on the disk.
2) System calls enters the kernel
3) A request is sent to the disk.
4)
Am Donnerstag, 12. Oktober 2006 23:17 schrieb Alan Stern:
OK, of course. Please disregard my last remark.
In fact the usb_autpm_{get|put}_interface API is a little clumsy. It
works okay if you do nothing but suspend on close and resume on open. But
for anything more substantial it tends
On Sat, 14 Oct 2006 11:07:37 -0700 (PDT), Open Source [EMAIL PROTECTED] wrote:
4) The process sleeps to wait for the disk.
(No other processes are running so only the idle loop
is running at this point.)
5) An interrupt triggers back from the disk.
6) The process wakes up.
Now if #6
Hi Pete,
Thanks for the info. A couple of very quick questions:
1) I presume this means that if there was some other
user mode process running at the time of the interrupt, this
other process will continue to run after the interrupt
rather than waking up the blocked process?
2) If that other
14 matches
Mail list logo
