On Tue, 18 Jan 2005 22:14:24 -0800, David Brownell [EMAIL PROTECTED] wrote:
Also, I don't like the idea of scattering knowledge all over the place
that the root hub is always given address 1 ...
which you didn't address yet.
Yes, I have to look why you do not like using the pipe.
Dear Russell:
I have a favour to ask of you. I need the following patch to be applied
to the USB core:
diff -urpN -X dontdiff linux-2.6.11-rc1-bk4/drivers/usb/core/hcd.c
linux-2.6.11-rc1-bk4-lem/drivers/usb/core/hcd.c
--- linux-2.6.11-rc1-bk4/drivers/usb/core/hcd.c 2005-01-12 16:35:53.0
Dear Russell:
I have a favour to ask of you. I need the following patch to be applied
to the USB core:
diff -urpN -X dontdiff linux-2.6.11-rc1-bk4/drivers/usb/core/hcd.c
linux-2.6.11-rc1-bk4-lem/drivers/usb/core/hcd.c
--- linux-2.6.11-rc1-bk4/drivers/usb/core/hcd.c 2005-01-12 16:35:53.0
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
Quite so. Linus told you many times not to send patches
in MIME and I happen to agree.
> Content-Type: TEXT/PLAIN; charset=US-ASCII;
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Quite so. Linus told you many times not to send patches
in MIME and I happen to agree.
Content-Type: TEXT/PLAIN; charset=US-ASCII;
In linux-kernel, you wrote:
> Peter Zaitsev wrote:
> >
> > That's why I thought this problem is related to raid1 swapping I'm
> > using.
>
> Well there is the potential problem that RAID1 has that it can't avoid allocating
> memory in some occasions, for the 2nd bufferhead. ATARAID raid0 has
In linux-kernel, you wrote:
Peter Zaitsev wrote:
That's why I thought this problem is related to raid1 swapping I'm
using.
Well there is the potential problem that RAID1 has that it can't avoid allocating
memory in some occasions, for the 2nd bufferhead. ATARAID raid0 has the same
> This patch adds a missing semicolon that is noticed only if you define
> IDETAPE_DEBUG_LOG_VERBOSE:
>
> John Guthrie
> [EMAIL PROTECTED]
It makes me curious, why do you need to define
IDETAPE_DEBUG_LOG_VERBOSE?
I fixed some stuff with files not restoring properly
with last block corrupt.
> When I do anything (print to it, query its ink levels with escputil,
> etc.) with my Epson 870 while it's hooked to my computer via USB, the
> whole machine locks hard. [...]
> Has anyone else has seen this problem? I posted to the gimp-print and
> linux-usb lists, but there was nary a
When I do anything (print to it, query its ink levels with escputil,
etc.) with my Epson 870 while it's hooked to my computer via USB, the
whole machine locks hard. [...]
Has anyone else has seen this problem? I posted to the gimp-print and
linux-usb lists, but there was nary a response.
I
This patch adds a missing semicolon that is noticed only if you define
IDETAPE_DEBUG_LOG_VERBOSE:
John Guthrie
[EMAIL PROTECTED]
It makes me curious, why do you need to define
IDETAPE_DEBUG_LOG_VERBOSE?
I fixed some stuff with files not restoring properly
with last block corrupt. Talking
> Lately, I have been having problems reading from from my HP Colorado IDE
> tape drive. I can use mt to get the status of the drive and to forward the
> drive to a different file. I can even use tar to write to the tape.
> But whenever I try to read the tar files that I have written to tape, I
Lately, I have been having problems reading from from my HP Colorado IDE
tape drive. I can use mt to get the status of the drive and to forward the
drive to a different file. I can even use tar to write to the tape.
But whenever I try to read the tar files that I have written to tape, I
> Well you have device drivers like the symbios scsi driver for instance that
> tries to determine if it's seen a card before. It does this by looking at the
> bus,dev etc numbers...
Can it be done by comparing struct pci_dev pointers for equal?
-- Pete
-
To unsubscribe from this list: send the
Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers...
Can it be done by comparing struct pci_dev pointers for equal?
-- Pete
-
To unsubscribe from this list: send the
> I'd like to find out if anyone has thought about how Linux will handle
> some of the new network technologies people are starting to push.
> Specifically I'm talking about "System Area Networks," that is, things
> like Infiniband, as well as TCP/IP offload.
Infiniband is doing relatively well,
I'd like to find out if anyone has thought about how Linux will handle
some of the new network technologies people are starting to push.
Specifically I'm talking about System Area Networks, that is, things
like Infiniband, as well as TCP/IP offload.
Infiniband is doing relatively well, as
> There is no such thing as a "user mode" interrupt service routine.
> There never was one, and there will never be one on any machine
> that fetches instructions from memory for execution. [...]
If memory does not deceive me, SunLab Spring processed interrupts
in user space. I do not remember
There is no such thing as a user mode interrupt service routine.
There never was one, and there will never be one on any machine
that fetches instructions from memory for execution. [...]
If memory does not deceive me, SunLab Spring processed interrupts
in user space. I do not remember for
> Then again JavaOS was an abortion on top of Slowaris. [...]
This is a false statemenet, Rob. It was an abortion, all right,
but not related to Solaris in any way at all.
JavaOS existed in two flavours minimum, which had very little
in common. The historically first of them (Luna), was a
> This [code morphing and binary tranlation]
> was set off to provide compensation for the biggest hurdle
> of VLIW design - insane code size and partially huge memmory
> bus bandwidth designs due to this. (Why do you think the itanim
> sucks on integer performance?)
First, Merced does not suck
This [code morphing and binary tranlation]
was set off to provide compensation for the biggest hurdle
of VLIW design - insane code size and partially huge memmory
bus bandwidth designs due to this. (Why do you think the itanim
sucks on integer performance?)
First, Merced does not suck on
Then again JavaOS was an abortion on top of Slowaris. [...]
This is a false statemenet, Rob. It was an abortion, all right,
but not related to Solaris in any way at all.
JavaOS existed in two flavours minimum, which had very little
in common. The historically first of them (Luna), was a
>I told device to go to sleep, it reported (over serial console that I
>looked at with minicom), that it turned off internal devices
>(including USB client), reported it is going to sleep, and turned
>serial and itself off.
What does it mean "I told device to go to sleep"?
What
> AC> 2.4.5-ac7
> AC> o Make USB require PCI(me)
> How about people from StrongArm sa11x0 port, who have USB host controller
> (in sa companion chip) but do not have PCI?
> Probably there are more such embedded architectures with USB controllers,
> but not
I told device to go to sleep, it reported (over serial console that I
looked at with minicom), that it turned off internal devices
(including USB client), reported it is going to sleep, and turned
serial and itself off.
What does it mean I told device to go to sleep?
What device?
> But, each time a user cats this proc file, the user is banging the
> hardware. What happens when a malicious user forks off 100 processes to
> continually cat this file? :)
Nothing good, probably. Same story as /proc/apm, which only
hits BIOS instead (and it's debateable what is better).
>
> From: Tim Hockin <[EMAIL PROTECTED]>
> Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)
> > i2c framework is not used, I wonder why. Someone thought that
> > it was too heavy perhaps? If so, I disagree.
>
> i2c is only in our stuff because the i2c core is not in the standard kernel
> yet. As soon
From: Tim Hockin [EMAIL PROTECTED]
Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)
i2c framework is not used, I wonder why. Someone thought that
it was too heavy perhaps? If so, I disagree.
i2c is only in our stuff because the i2c core is not in the standard kernel
yet. As soon as it is,
But, each time a user cats this proc file, the user is banging the
hardware. What happens when a malicious user forks off 100 processes to
continually cat this file? :)
Nothing good, probably. Same story as /proc/apm, which only
hits BIOS instead (and it's debateable what is better).
> Aattached is a (large, but self contained) patch for Cobalt Networks suport
> for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
> is anything that would prevent this from general inclusion in the next
> release.
Looks interesting. Seemingly literate use of spinlocks.
Aattached is a (large, but self contained) patch for Cobalt Networks suport
for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there
is anything that would prevent this from general inclusion in the next
release.
Looks interesting. Seemingly literate use of spinlocks.
> From: Oleg Drokin <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Date: Sat, 26 May 2001 14:37:24 +0400
> >>EIP; c01a3162<=
> Trace; c01a42fc
> Trace; c01a5f9c
> Trace; c01a42e0
> Trace; c019f19f
> Trace; c0118a9e
> Trace; c0117e62
>
From: Oleg Drokin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sat, 26 May 2001 14:37:24 +0400
EIP; c01a3162 call_policy+162/1f0 =
Trace; c01a42fc usb_disconnect+fc/130
Trace; c01a5f9c hub_disconnect+1c/80
Trace; c01a42e0
> From: "Adam J. Richter" <[EMAIL PROTECTED]>
> Date: Sun, 22 Apr 2001 12:53:48 -0700
> To: [EMAIL PROTECTED]
> Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
>[...]
> I believe this infringinges the copyrights of the authors
> of the code used in these drivers
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Looks ok, only a small nit: an include and 'pmdev' are left over from
> the older PM implementation, and can be removed.
Oops, here's a better one.
-- Pete
-
PM support for
I am sorry to be a poor maintainer, people were sending me patches
to enable PM support for a long time. I took most of this from
Paul Stewart, fixed a buglet, and factored common parts into
a function.
-- Pete
* PM support for suspend/resume (without pm_register, proper PCI API);
* Killed some
I am sorry to be a poor maintainer, people were sending me patches
to enable PM support for a long time. I took most of this from
Paul Stewart, fixed a buglet, and factored common parts into
a function.
-- Pete
* PM support for suspend/resume (without pm_register, proper PCI API);
* Killed some
From: Jeff Garzik [EMAIL PROTECTED]
Looks ok, only a small nit: an include and 'pmdev' are left over from
the older PM implementation, and can be removed.
Oops, here's a better one.
-- Pete
-
PM support for
From: Adam J. Richter [EMAIL PROTECTED]
Date: Sun, 22 Apr 2001 12:53:48 -0700
To: [EMAIL PROTECTED]
Subject: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
[...]
I believe this infringinges the copyrights of the authors
of the code used in these drivers who released
> May 23 02:46:24 localhost kernel: Process kudzu (pid: 219,
> stackpage=c7845000)
> May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400
> c73aa000 c122a060 c122a05c c122a058 c88fbb20
> May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80
> c73aa3f1 c7845f9c
May 23 02:46:24 localhost kernel: Process kudzu (pid: 219,
stackpage=c7845000)
May 23 02:46:24 localhost kernel: Stack: c12607e0 0400 0400
c73aa000 c122a060 c122a05c c122a058 c88fbb20
May 23 02:46:24 localhost kernel:03f1 03f1 c014ab80
c73aa3f1 c7845f9c
>[about Aunt Tullie]
> Because, for example, a kernel compile can be a part of the standard
> install now, and you will end up with a kernel built specifically for
> your machine that doesn't print 50 initialization failed messages on boot.
>[...]
> And you can also now run a kernel built for
[about Aunt Tullie]
Because, for example, a kernel compile can be a part of the standard
install now, and you will end up with a kernel built specifically for
your machine that doesn't print 50 initialization failed messages on boot.
[...]
And you can also now run a kernel built for your
> > As for the language CML2 is written in, surely C would work just as well as
> > Python if the config-ruleset file is in a known format. GCC is required
> > for the kernel to build, I don't see why anything else should be required
> > simply to configure it.
>
> Menuconfig is fairly popular,
As for the language CML2 is written in, surely C would work just as well as
Python if the config-ruleset file is in a known format. GCC is required
for the kernel to build, I don't see why anything else should be required
simply to configure it.
Menuconfig is fairly popular, and
How about this (with documentation fixes by David-B):
diff -ur -X dontdiff linux-2.4.4/Documentation/DMA-mapping.txt
linux-2.4.4-niph/Documentation/DMA-mapping.txt
--- linux-2.4.4/Documentation/DMA-mapping.txt Thu Apr 19 08:38:48 2001
+++ linux-2.4.4-niph/Documentation/DMA-mapping.txt
How about this (with documentation fixes by David-B):
diff -ur -X dontdiff linux-2.4.4/Documentation/DMA-mapping.txt
linux-2.4.4-niph/Documentation/DMA-mapping.txt
--- linux-2.4.4/Documentation/DMA-mapping.txt Thu Apr 19 08:38:48 2001
+++ linux-2.4.4-niph/Documentation/DMA-mapping.txt
> From: "David S. Miller" <[EMAIL PROTECTED]>
> Date: Tue, 8 May 2001 17:52:45 -0700 (PDT)
> Ummm... What Alan's saying is:
>
> 1) Whatever driver is trying to shut down from IRQ context
>is broken must be fixed. pci_pool is fine.
>
> 2) The Documentation/ files which suggest that such
> May 9 10:05:11 localhost kernel: EIP:0010:[call_policy+427/608]
I saw it before, but was unable to track it down.
What is your kernel version?
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> switching it back on, a problem occurs with reenabling the ports on
> that USB hub. The kernel output follows.
> Comments anyone?
Next time, post your /proc/version.
There were similar things recently (missing urb->dev
reinitialization in usb_hub_reset).
-- Pete
-
To unsubscribe from this
switching it back on, a problem occurs with reenabling the ports on
that USB hub. The kernel output follows.
Comments anyone?
Next time, post your /proc/version.
There were similar things recently (missing urb-dev
reinitialization in usb_hub_reset).
-- Pete
-
To unsubscribe from this list:
May 9 10:05:11 localhost kernel: EIP:0010:[call_policy+427/608]
I saw it before, but was unable to track it down.
What is your kernel version?
-- Pete
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
From: David S. Miller [EMAIL PROTECTED]
Date: Tue, 8 May 2001 17:52:45 -0700 (PDT)
Ummm... What Alan's saying is:
1) Whatever driver is trying to shut down from IRQ context
is broken must be fixed. pci_pool is fine.
2) The Documentation/ files which suggest that such device
Hi:
I found that every time I run a 2.4 on my laptop, APM locks up
the machine. Apparently, legacy YMF code enabled decoding of
10 bits of I/O address. A call to APM BIOS touched that and
somehow the system locked up.
If Pavel Roskin, Daisuke Nagano or someone else do not mind,
I want this in
David,
Russel King complained that you might be calling pci_consistent_free
from an interrupt, which is unsafe on ARM. Why don't you remove this
part from pci_pool_free():
+ else if (!is_page_busy (pool->blocks_per_page, page->bitmap))
+ pool_free_page (pool, page);
In that
David,
Russel King complained that you might be calling pci_consistent_free
from an interrupt, which is unsafe on ARM. Why don't you remove this
part from pci_pool_free():
+ else if (!is_page_busy (pool-blocks_per_page, page-bitmap))
+ pool_free_page (pool, page);
In that
Hi:
I found that every time I run a 2.4 on my laptop, APM locks up
the machine. Apparently, legacy YMF code enabled decoding of
10 bits of I/O address. A call to APM BIOS touched that and
somehow the system locked up.
If Pavel Roskin, Daisuke Nagano or someone else do not mind,
I want this in
Due to a pilot error, my ymfpci update would not compile
(forgot to submit .h change). Here is the missing part:
--- linux-2.4.4/drivers/sound/ymfpci.h Fri Jan 26 23:31:16 2001
+++ linux-2.4.4-niph/drivers/sound/ymfpci.h Fri May 4 11:07:17 2001
@@ -135,6 +135,8 @@
#define PCIR_LEGCTRL
Due to a pilot error, my ymfpci update would not compile
(forgot to submit .h change). Here is the missing part:
--- linux-2.4.4/drivers/sound/ymfpci.h Fri Jan 26 23:31:16 2001
+++ linux-2.4.4-niph/drivers/sound/ymfpci.h Fri May 4 11:07:17 2001
@@ -135,6 +135,8 @@
#define PCIR_LEGCTRL
Hello:
Here are updates from ALSA. The interrupt acknowledge has a
potential bug report for it in RH bugzilla. Power-up fix I include
"just because", Alan bounced it to me from sound-hackers;
Also Jeff Garzik asked for it. I wanted to include it with
full PM support, but perhaps not.
-- Pete
One of our customers has a Fujitsu laptop, poor thing...
It shares IRQ10 between Eepro, additional IDE for CD-ROM (CMD646),
and USB controllers. I talked this over with DaveM briefly,
and if I understood him right, something like the attached
patch may be in order. Anyone cares to comment?
Thank
One of our customers has a Fujitsu laptop, poor thing...
It shares IRQ10 between Eepro, additional IDE for CD-ROM (CMD646),
and USB controllers. I talked this over with DaveM briefly,
and if I understood him right, something like the attached
patch may be in order. Anyone cares to comment?
Thank
Hello:
Here are updates from ALSA. The interrupt acknowledge has a
potential bug report for it in RH bugzilla. Power-up fix I include
just because, Alan bounced it to me from sound-hackers;
Also Jeff Garzik asked for it. I wanted to include it with
full PM support, but perhaps not.
-- Pete
---
> While trying to compile the 2.4.4 kernel on a SPARC-20, I encounter the
> following error.
> make[1]: Entering directory `/usr/src/linux-2.4.4/mm'
> make all_targets
> make[2]: Entering directory `/usr/src/linux-2.4.4/mm'
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include -Wall
While trying to compile the 2.4.4 kernel on a SPARC-20, I encounter the
following error.
make[1]: Entering directory `/usr/src/linux-2.4.4/mm'
make all_targets
make[2]: Entering directory `/usr/src/linux-2.4.4/mm'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include -Wall -Wstrict-prototypes
Hello:
My box here slows down dramatically after a while, and starts
behaving as if it has very little memory, e.g. programs page
each other out. It turns out that out of 40MB total, about
35MB is used for dcache and icache, and system basically
runs in 5MB of RAM.
When I tried to discuss it
> usb-uhci.c: interrupt, status 3, frame# 1876
This is a known problem, here is the discussion that I initiated
on linux-usb-devel:
http://marc.theaimsgroup.com/?t=9860950851=2=1
The right fix is to comment that printout out.
In fact, that is what I commited for Red Hat 7.1 release.
usb-uhci.c: interrupt, status 3, frame# 1876
This is a known problem, here is the discussion that I initiated
on linux-usb-devel:
http://marc.theaimsgroup.com/?t=9860950851w=2r=1
The right fix is to comment that printout out.
In fact, that is what I commited for Red Hat 7.1 release.
Hello:
Suppose for a moment, that I have an in-kernel daemon, listening
on a TCP socket, and that the said daemon is interested to
know when connection becomes established. To that end it
puts something into sk->state_change. However, when connection
is established, state_chenge is not called
Hello:
Suppose for a moment, that I have an in-kernel daemon, listening
on a TCP socket, and that the said daemon is interested to
know when connection becomes established. To that end it
puts something into sk-state_change. However, when connection
is established, state_chenge is not called (in
> Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST)
> From: Ketil Froyn <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> While running kernel 2.4.2-ac28, I switched on spinlock debugging and
> verbose BUG() reporting (I always use sysrq). Anyway, while running this I
> got an oops after about 2
Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST)
From: Ketil Froyn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
While running kernel 2.4.2-ac28, I switched on spinlock debugging and
verbose BUG() reporting (I always use sysrq). Anyway, while running this I
got an oops after about 2 or 3
Hello, All:
I have a situation where a Dell laptop would loose its
keyboard after resume (thanks to Ben LaHaise for
diagnosing this probelm). BIOS enables touchpad
when resumed and if a user touches touchpad, "hardware"
delivers IRQ 12 and will not deliver IRQ 1 until we
process the mouse event.
Hello, All:
I have a situation where a Dell laptop would loose its
keyboard after resume (thanks to Ben LaHaise for
diagnosing this probelm). BIOS enables touchpad
when resumed and if a user touches touchpad, "hardware"
delivers IRQ 12 and will not deliver IRQ 1 until we
process the mouse event.
Here is the deal:
we have a guy here with a webcam and the following scenario:
1. ov511 disconnects, everything dies/releases/closes fine,
2. webcam soft starts polling open/sleep/open/sleep/...
3. ov511_probe works and reaches ov511_configure,
calls video_register_device().
4. Webcam
Some guy sent me the attached patch. He says it allows
him to use 2 additional keys on the 106 key USB keyboard.
I never saw a 106 key keyboard before, USB or not.
Does anyone understand what is going on? Vojtech?
-- Pete
--- drivers/input/keybdev.c.orig Sat Sep 2 19:01:55 2000
+++
Here is the deal:
we have a guy here with a webcam and the following scenario:
1. ov511 disconnects, everything dies/releases/closes fine,
2. webcam soft starts polling open/sleep/open/sleep/...
3. ov511_probe works and reaches ov511_configure,
calls video_register_device().
4. Webcam
> From: Andree Leidenfrost <[EMAIL PROTECTED]>
> To: Pete Zaitcev <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Date: 18 Mar 2001 22:50:32 +1100
>
> > > I am experiencing problems with a USB mouse: The machine boots, X
> > > starts, I log on, e
From: Andree Leidenfrost [EMAIL PROTECTED]
To: Pete Zaitcev [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: 18 Mar 2001 22:50:32 +1100
I am experiencing problems with a USB mouse: The machine boots, X
starts, I log on, everything works as expected. When I restart X or just
change
> From: Andree Leidenfrost ([EMAIL PROTECTED])
> I am experiencing problems with a USB mouse: The machine boots, X
> starts, I log on, everything works as expected. When I restart X or just
> change to an alpha terminal and back to x the mouse does not work any
> more. [...]
> Hardware is an
From: Andree Leidenfrost ([EMAIL PROTECTED])
I am experiencing problems with a USB mouse: The machine boots, X
starts, I log on, everything works as expected. When I restart X or just
change to an alpha terminal and back to x the mouse does not work any
more. [...]
Hardware is an ASUS
> Date: Wed, 14 Mar 2001 21:28:14 -0500
> From: Doug Ledford <[EMAIL PROTECTED]>
> A bug report I was charged with fixing (qla2x00 driver doesn't see all luns or
> sees multiple identical luns in different scenarios) was not a bug in the
> qla2x00 driver. [...]
> The bug is that we were
Is my fix to khubd going anywhere? Randy, David?
I have an actual, reproducible bug that I need to close.
Here's my message to linux-usb-devel with explanations:
http://marc.theaimsgroup.com/?l=linux-usb-devel=98411157628404=2
-- Pete
diff -ur -X ../dontdiff linux-2.4.2-ac12/drivers/usb/hub.c
Is my fix to khubd going anywhere? Randy, David?
I have an actual, reproducible bug that I need to close.
Here's my message to linux-usb-devel with explanations:
http://marc.theaimsgroup.com/?l=linux-usb-develm=98411157628404w=2
-- Pete
diff -ur -X ../dontdiff
size, poisoning
> and so on). And yet when Pete Zaitcev described what that
> mapping code actually involved, you didn't object. So you've
> succeeded in confusing me. Care to unconfuse?
I did not propose an API or library which would be equal amond equals
with first rate citizens of pci
> Date: Fri, 09 Mar 2001 10:29:22 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> > > extern void *
> > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> >
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
>
> Some hardware (like OHCI)
Date: Fri, 09 Mar 2001 10:29:22 -0800
From: David Brownell [EMAIL PROTECTED]
extern void *
pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
Some hardware (like OHCI) talks to drivers
Hello:
I was investigating an oops and the trace looked like this:
>>EIP; c01c54a9<=
Trace; c01c3654
Trace; c01c0f0f
Trace; c015e7e2
Trace; c01155a6
Trace; c01272a9
Trace; c0127414
Trace; c0136a2d
Trace; c012722e
Trace; c0127290
Trace; c0127414
Trace; c014cdec
Trace; c0143f80
Hello:
I was investigating an oops and the trace looked like this:
EIP; c01c54a9 lvm_do_remove_proc_entry_of_vg+9/c0 =
Trace; c01c3654 lvm_do_vg_rename+84/250
Trace; c01c0f0f lvm_chr_ioctl+30f/6d0
Trace; c015e7e2 ext2_getblk+72/e0
Trace; c01155a6 do_page_fault+166/440
Trace; c01272a9
Courtesy of Manish Singh, little bit extended
(I hope I did not break it too badly).
Supposedly it fixes bad skipping with xmms.
-- Pete
diff -ur -X dontdiff linux-2.4.1/drivers/sound/ymfpci.c
linux-2.4.1-p3/drivers/sound/ymfpci.c
--- linux-2.4.1/drivers/sound/ymfpci.c Fri Jan 26 23:31:16
Courtesy of Manish Singh, little bit extended
(I hope I did not break it too badly).
Supposedly it fixes bad skipping with xmms.
-- Pete
diff -ur -X dontdiff linux-2.4.1/drivers/sound/ymfpci.c
linux-2.4.1-p3/drivers/sound/ymfpci.c
--- linux-2.4.1/drivers/sound/ymfpci.c Fri Jan 26 23:31:16
> From: Simon Cahuk ([EMAIL PROTECTED])
> Date: Tue Jan 30 2001 - 14:22:26 EST
>
> I have a ymfpci sound chip on my motherboard. I'm using ymfpci module.
> Under Q3A I get this:
> sound inilializations:
> Sorry but your soundcard can't do this
Probably an mmap-ed sound problem or some
From: Simon Cahuk ([EMAIL PROTECTED])
Date: Tue Jan 30 2001 - 14:22:26 EST
I have a ymfpci sound chip on my motherboard. I'm using ymfpci module.
Under Q3A I get this:
sound inilializations:
Sorry but your soundcard can't do this
Probably an mmap-ed sound problem or some ioctl is
> From: Gregory Maxwell ([EMAIL PROTECTED])
> Date: Sun Jan 28 2001 - 14:42:04 EST
>
> On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
> > > There is nothing silly with the decision, davem is simply a modern day
> > > internet hero.
> >
> > No. If it were something
From: Gregory Maxwell ([EMAIL PROTECTED])
Date: Sun Jan 28 2001 - 14:42:04 EST
On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote:
There is nothing silly with the decision, davem is simply a modern day
internet hero.
No. If it were something essential, perhaps,
A minor problem here - module_init(irda_proto_init) got bracketed
by #ifdef MODULE and became ineffective if compiled without modules.
-- Pete
diff -ur -X dontdiff linux-2.4.1-pre11/net/irda/af_irda.c
linux-2.4.1-pre11-p3/net/irda/af_irda.c
--- linux-2.4.1-pre11/net/irda/af_irda.cSat
A minor problem here - module_init(irda_proto_init) got bracketed
by #ifdef MODULE and became ineffective if compiled without modules.
-- Pete
diff -ur -X dontdiff linux-2.4.1-pre11/net/irda/af_irda.c
linux-2.4.1-pre11-p3/net/irda/af_irda.c
--- linux-2.4.1-pre11/net/irda/af_irda.cSat
Sorry for the nitpicking, bust since 2.4 is now "stable"...
-- Pete
diff -ur -X dontdiff linux-2.4.0-ac9/drivers/sound/cs46xx.c
linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c
--- linux-2.4.0-ac9/drivers/sound/cs46xx.c Sun Jan 14 15:27:58 2001
+++ linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c Wed
Sorry for the nitpicking, bust since 2.4 is now "stable"...
-- Pete
diff -ur -X dontdiff linux-2.4.0-ac9/drivers/sound/cs46xx.c
linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c
--- linux-2.4.0-ac9/drivers/sound/cs46xx.c Sun Jan 14 15:27:58 2001
+++ linux-2.4.0-ac9-p3/drivers/sound/cs46xx.c Wed
401 - 500 of 521 matches
Mail list logo
