Hi Linus & James,
I've still got problems under 2.6.13-rc6 with my DLT7000 drive on an
AIC7880 builtin controller. Here's the message I got in dmesg. My
system is a heavily upgraded Debian/unstable with dual 550mhz Xeon
processors and 768mb of RAM, dual SCSI busses. The annoying problem
is tha
hi there,
due to non supporting Marvell Network drivers for the
i have to use the syskonnect sk98lin driver from their homepage. even if these
drivers are open-source they
were rejected by kernel net maintainers until now. there is a skge driver that
is integrated into mainline kernel,
but th
"art" <[EMAIL PROTECTED]> wrote:
>
> kernel 2.6.13-rc1-git7 to 2.6.13-rc5 transfer 72MB/s on aha19160 with 15k
> rpm seagate with reiserfs3 but possible deadlock in heavy IO - rsync
> ~5-small files from /mnt/seagate15k/a to /mnt/seagate15k/b ends in
> middle with deadlock of rsync (3 instances
On Sunday 07 August 2005 20:47, Linus Torvalds wrote:
>
> James and gang found the aic7xxx slowdown that happened after 2.6.12, and
> we'd like to get particular testing that it's fixed, so if you have a
> relevant machine, please do test this.
>
I'm using the aic7xxx driver, and although I ha
kernel 2.6.13-rc1-git7 to 2.6.13-rc5 transfer 72MB/s on aha19160 with 15k rpm
seagate with reiserfs3 but possible deadlock in heavy IO - rsync ~5-small
files from /mnt/seagate15k/a to /mnt/seagate15k/b ends in middle with deadlock
of rsync (3 instances), pdflush, and gam_server all of them i
On Mon, Aug 08, 2005 at 10:31:45AM -0700, Carlos Pardo wrote:
> One question. Do the open source driver support pass-through commands ? if
> so, how ? If you do not support it, are you planning to implement
> pass-through commands sometime in the future ?
I don't know about sata_sil24 in particu
Jeff, et al -
One question. Do the open source driver support pass-through commands ? if so,
how ? If you do not support it, are you planning to implement pass-through
commands sometime in the future ?
Carlos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>James and gang found the aic7xxx slowdown that happened after 2.6.12, and
>we'd like to get particular testing that it's fixed, so if you have a
>relevant machine, please do test this.
with me, rc6 lasted 18 hours:
reboot system boot 2.6.13-rc6
On Mon, Aug 08, 2005 at 12:14:43AM +0300, Dumitru Ciobarcianu wrote:
> ??n data de Du, 07-08-2005 la 11:47 -0700, Linus Torvalds a scris:
> > Luming Yu:
> > [ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12)
> > [ACPI] CONFIG_ACPI_HOTKEY is now "n" by default
>
> IMHO yo
Linus> James and gang found the aic7xxx slowdown that happened after
Linus> 2.6.12, and we'd like to get particular testing that it's
Linus> fixed, so if you have a relevant machine, please do test this.
This might explain why my DLT7000 has been dropping off the bus at
times and requiring a full
On Mon, 2005-08-08 at 02:06 +0200, Bodo Eggert wrote:
> The wrong values are constant across reboots (see my first mail), and I
> have a CRT.
>
> Can you tell me where the timing values are read?
radeon_write_mode() programs the mode. The monitor timing infos are read
by the various bits of cod
On Aug 7, 2005, at 21:13:54, Kyle Moffett wrote:
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote:
_However_ there is an unrelated problem with some panels,
including some
of the 17": The panel doesn't always "sync" properly. This seem to be
related to some subtle timing issue in the
On Aug 7, 2005, at 12:13:38, Benjamin Herrenschmidt wrote:
I've got an LCD, and on mine
it looks like every third pixel-line gets shifted about 32-64
pixels to
the left, and they move with display refresh. My guess is that
something is interrupting radeonfb during a critical time in display
s
On Sun, 7 Aug 2005, Benjamin Herrenschmidt wrote:
> On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
> > On Sun, 7 Aug 2005, Kyle Moffett wrote:
> > > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
> > > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
> > > > t
On Sun, 2005-08-07 at 19:25 +0200, Bodo Eggert wrote:
> On Sun, 7 Aug 2005, Kyle Moffett wrote:
> > On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
>
> > > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
> > > though ... Can you try something like wrapper radeon_write_
În data de Du, 07-08-2005 la 11:47 -0700, Linus Torvalds a scris:
> Luming Yu:
> [ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12)
> [ACPI] CONFIG_ACPI_HOTKEY is now "n" by default
IMHO you really need then to make acpi_specific_hotkey the default or at
least mention it
On Sun, 2005-08-07 at 13:50 -0700, Linus Torvalds wrote:
>
> On Sun, 7 Aug 2005, Lee Revell wrote:
> >
> > It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer
> > an option). But now I get this ominous warning when I compile
> > ndiswrapper:
>
> It's still there, and it (st
On Sun, 7 Aug 2005, Lee Revell wrote:
>
> It looks like CONFIG_4KSTACKS has gone away (IOW 8K stacks are no longer
> an option). But now I get this ominous warning when I compile
> ndiswrapper:
It's still there, and it (still) depends on DEBUG_KERNEL. Nothing should
have changed afaik..
On Sun, 2005-08-07 at 11:47 -0700, Linus Torvalds wrote:
> James and gang found the aic7xxx slowdown that happened after 2.6.12, and
> we'd like to get particular testing that it's fixed, so if you have a
> relevant machine, please do test this.
>
> There are other fixes too, a number of them re
Linus Torvalds wrote:
> In general, anybody who has reported regressions since 2.6.12, please
> re-test with -rc6 and report back
> ...
> Herbert Xu:
> tcp: fix TSO cwnd caching bug
The tcp_output panic bug seems to be fixed. I'm referring to:
http://lkml.org/lkml/2005/8/7/63
--
Heikki
b routines
Check input buffer size in zisofs
ppc: Export __handle_mm_fault for MOL
Merge master.kernel.org:/.../holtmann/bluetooth-2.6
Linux 2.6.13-rc6
Luming Yu:
[ACPI] revert Embedded Controller to polling-mode by default (ala 2.6.12)
[ACPI] CONFIG_ACPI_HOTKEY is now "
On Sun, 7 Aug 2005, Kyle Moffett wrote:
> On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
> > Ah ! Interesting... I don't see why PREEMPT would affect radeonfb
> > though ... Can you try something like wrapper radeon_write_mode() with
> > preempt_disable()/preempt_enable() and tell me i
> I'm having a similar issue with my shiny new 17" Powerbook G4. The
> radeon chip works fine with framebuffer in 2.6.12.4 _with_ PREEMPT,
> but not in 2.6.13-rc5 _with_ PREEMPT (configs are virtually identical).
> I'll try your idea this afternoon when I get the chance.
Note that PREEMPT is kno
On Aug 7, 2005, at 03:51:07, Benjamin Herrenschmidt wrote:
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote:
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
My CRT is out of sync after radeonfb from 2.6.13-rc5 is
initialized.
2.6.1
On Fri, 2005-08-05 at 19:38 +0200, Bodo Eggert wrote:
> On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
> > > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
> > > 2.6.12 does not show this behaviour.
> >
> > I'm
On Fri, 5 Aug 2005, Benjamin Herrenschmidt wrote:
> On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
> > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
> > 2.6.12 does not show this behaviour.
>
> I'm out of town at the moment, could you maybe diff radeonfb between
> w
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote:
> My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
> 2.6.12 does not show this behaviour.
I'm out of town at the moment, could you maybe diff radeonfb between
working & non-working and CC me the diff ? I don't have my work
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized.
2.6.12 does not show this behaviour.
dmesg from both systems, trimmed down:
2.6.13-rc5:
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is :01:00.0
PCI: Using IRQ router VIA [1106/0686] at 0
I agree that above code should clear both. Just wanna verify. Have
you tested it and/or do you have any information confirming this? If
we don't have any further info, I think we should read PORT_SLOT_STAT
before clearing PORT_IRQ_STAT to be on the safe side.
I've implemented the clear_irq
Hi, again, Edward.
Bad news...
On Tue, Aug 02, 2005 at 03:56:05PM -0700, Edward Falk wrote:
>
> Again, you would need to fetch them from the returned FIS structure.
> Here's a code fragment derived from SiI's issue_soft_reset() function:
>
> struct Port_Registers *port_base = yadayada;
Hello, Edward.
One more question.
> > >
> > >I think this will work (adapted from sil_interrupt():
> > >
> > >static void sil_irq_clear(struct ata_port *ap)
> > >{
> > >struct sil_port_priv *pp = ap->private_data;
> > >struct Port_Registers *port_base = pp->pregs;
> > >unsig
Greetings, Edward and Jeff.
Jeff, as my previous patchset against sil24 driver hasn't been
accepted yet, and it seems that most of them can be done better with
info from Edward, please ignore the patchset. I'll post a new
patchset tomorrow (hopefully). Sorry about the hassle.
On Wed, Aug 03,
On Tuesday 02 August 2005 12:50, Rafael J. Wysocki wrote:
> Please try to ad the ec_polling parameter to the kernel command line and
> retest.
That helps a lot. Thanks, it's back to the 'old way'.
Jan
--
...Deep Hack Mode -- that mysterious and frightening state of
consciousness where Mortal Use
Edward Falk wrote:
Hi Tejun; I'm the guy at Google working on SATA drivers (port
multipliers right now). As soon as I can (next week perhaps, I'll start
looking at the driver you wrote. From what I can see, it looks quite good.
+
+static u8 sil24_check_status(struct ata_port *ap)
+{
+
Hi Tejun; I'm the guy at Google working on SATA drivers (port
multipliers right now). As soon as I can (next week perhaps, I'll start
looking at the driver you wrote. From what I can see, it looks quite good.
+
+static u8 sil24_check_status(struct ata_port *ap)
+{
+ return ATA_DRDY;
On Tue, 2005-08-02 at 12:13 -0400, Bill Davidsen wrote:
> You are hardly the first person to implement the "it doesn't work right,
> but it sure is FAST!" algorithm.
>
I would actually call it the "It works _most_ of the time, and it sure
is FAST!" algorithm. It's a step up from what you mentio
Steven Rostedt wrote:
On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote:
On Fri, 29 Jul 2005, Cal Peake wrote:
Thanks Andrew! Indeed your suspicions are correct. Adding in all the
debugging moved the problem around, it now shows itself when probing
parport. Upon further investigation r
On Tuesday, 2 of August 2005 08:43, Jan De Luyck wrote:
> On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> > Ok, one more in the series towards final 2.6.13.
>
> One thing that seems like a regression: doing
>
> $ cat /proc/acpi/battery/BAT1/info
>
> causes a two-second pause and then gi
On Mon, Aug 01, Linus Torvalds wrote:
> Give it a good testing, I'm hoping this can really turn into 2.6.13.
aic doesnt work anymore, the poweroff thing should also be fixed in some
way.
http://marc.theaimsgroup.com/?l=linux-scsi&m=112180348617932&w=2
(google did not find that posting, but it
On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> Ok, one more in the series towards final 2.6.13.
One thing that seems like a regression: doing
$ cat /proc/acpi/battery/BAT1/info
causes a two-second pause and then gives me the information, while in 2.6.12.3
that was near-instant.
$ dat
On Tuesday 02 August 2005 07:07, Linus Torvalds wrote:
> Ok, one more in the series towards final 2.6.13.
>
> This one is small enough that both shortlog and diffstat fit comfortably:
> no big architecture updates or anything like that. Some input, x86-64 and
> ppc updates, and various fairly small
Ok, one more in the series towards final 2.6.13.
This one is small enough that both shortlog and diffstat fit comfortably:
no big architecture updates or anything like that. Some input, x86-64 and
ppc updates, and various fairly small fixes in random places.
Some reverts back to 2.6.12 behavio
Hello, Jeff.
I'll answer to your comments in this mail (and several questions,
too) and will soon post patches fixing things in separate mails.
On Thu, Jul 28, 2005 at 04:27:37PM -0400, Jeff Garzik wrote:
> Tejun Heo wrote:
> > Hello, Jeff.
> >
> > This is rewritten sil24 driver against v2.6.13
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll le
Cal Peake wrote:
On Fri, 29 Jul 2005, Mickey Stein wrote:
This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
and gave it a test run. It had a bit of a problem and ground to a halt after
spewing these into the log.
If I can find the time tomorrow morning, I'll le
Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> For the bennefit of those of us who were not at LKS, could someone
> elaborate a bit on "the new release process" ?
http://lwn.net/Articles/144281/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAI
On Fri, 29 Jul 2005, Mickey Stein wrote:
> This is regarding *-rc4 and *-rc4-git1: I slapped together my favorite config
> and gave it a test run. It had a bit of a problem and ground to a halt after
> spewing these into the log.
>
> If I can find the time tomorrow morning, I'll leave parport_pc
On Fri, 2005-07-29 at 10:29 -0700, Linus Torvalds wrote:
>
> On Fri, 29 Jul 2005, Cal Peake wrote:
> >
> > Thanks Andrew! Indeed your suspicions are correct. Adding in all the
> > debugging moved the problem around, it now shows itself when probing
> > parport. Upon further investigation revert
On Fri, 29 Jul 2005, Linus Torvalds wrote:
> Thanks. Just out of interest, does this patch fix it instead?
Indeed it does, thanks Linus!
-cp
>
> diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
> --- a/include/asm-i386/bitops.h
> +++ b/include/asm-i386/bitops.h
> @@ -335,
On Fri, 29 Jul 2005, Cal Peake wrote:
>
> Thanks Andrew! Indeed your suspicions are correct. Adding in all the
> debugging moved the problem around, it now shows itself when probing
> parport. Upon further investigation reverting the commit below seems to
> have nixed the problem.
Thanks. Ju
On Thu, 28 Jul 2005, Andrew Morton wrote:
> The procfs inode IDR tree is scrogged. I'd be suspecting a random memory
> scribble. I'd suggest that you enable CONFIG_DEBUG_SLAB,
> CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_everything_else and retest.
>
> If that doesn't show anything, try eliminating s
On 7/29/05, Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
>
> > On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > >
> > > Hey everybody,
> > >
> > > as many of you are aware, we were talking (not enough) about the
> release
> > > process at LKS this year.
> > >
> > > This ain't it.
> > >
> >
> On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > Hey everybody,
> >
> > as many of you are aware, we were talking (not enough) about the
release
> > process at LKS this year.
> >
> > This ain't it.
> >
> > This is just the regular old release "process", with some LKS
backlog p
On 7/29/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Hey everybody,
>
> as many of you are aware, we were talking (not enough) about the release
> process at LKS this year.
>
> This ain't it.
>
> This is just the regular old release "process", with some LKS backlog put
> in for good measu
Hey everybody,
as many of you are aware, we were talking (not enough) about the release
process at LKS this year.
This ain't it.
This is just the regular old release "process", with some LKS backlog
put in for good measure.
But the good news is, that I'll try the new release process after 2.
Cal Peake <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Getting this nastiness when probing snd-cs46xx:
>
> Unable to handle kernel paging request at virtual address 000a75a8
> ...
> EIP is at sub_alloc+0x42/0x170
> ...
> [] idr_get_new_above_int+0x78/0x120
> [] idr_get_new+0x1f/0x50
> [] get_inode_n
Hi,
Getting this nastiness when probing snd-cs46xx:
Unable to handle kernel paging request at virtual address 000a75a8
printing eip:
c01afe52
*pde =
Oops: [#1]
Modules linked in: snd_cs46xx gameport snd_rawmidi snd_seq_device
snd_ac97_codec snd_pcm snd_timer snd soundcore snd_page
ARTs on MPC824x individual platform devices
ppc32: Add proper prototype for cpm2_reset()
I2C-MPC: Restore code removed
Kurt Wall:
Add text for dealing with "dot releases" to README
Kyle Moffett:
[NET]: Fix setsockopt locking bug
Linda Xie:
[SCSI] IBM VSCSI Client: sending cli
Tejun Heo wrote:
Hello, Jeff.
This is rewritten sil24 driver against v2.6.13-rc3. It seems to work
and am currently running stress test on it (random raw read of
concurrency 4, repeatitive mount/copy/checksup/unmount). I'll keep
running stress test for at least 12 hours and let you know if
s
Hi there,
Lately in 2.6.13-rc* I've noticed a warning pop up:
[EMAIL PROTECTED]:/usr/src/linux-2.6.13-rc2-mm2a$ make menuconfig
...
scripts/kconfig/mconf arch/i386/Kconfig
net/ipv4/Kconfig:92:warning: defaults for choice values not supported <<== ??
#
# using defaults found in .conf
At Thu, 7 Jul 2005 11:39:29 -0700,
Greg KH wrote:
>
> On Thu, Jul 07, 2005 at 11:46:26AM +0200, Takashi Iwai wrote:
> > At Wed, 6 Jul 2005 08:51:03 -0700,
> > Greg KH wrote:
> > >
> > > On Wed, Jul 06, 2005 at 08:42:16AM -0700, Linus Torvalds wrote:
> > > >
> > > >
> > > > On Wed, 6 Jul 2005, E
On Thu, Jul 07, 2005 at 11:46:26AM +0200, Takashi Iwai wrote:
> At Wed, 6 Jul 2005 08:51:03 -0700,
> Greg KH wrote:
> >
> > On Wed, Jul 06, 2005 at 08:42:16AM -0700, Linus Torvalds wrote:
> > >
> > >
> > > On Wed, 6 Jul 2005, Eyal Lebedinsky wrote:
> > > >
> > > > CC [M] sound/pci/bt87x.o
> >
Alexis Ballier wrote:
Yes, that fixed it.
Ok, it is probably the same problem, then.
However, there was no problem with rc1 with the
same .config.
That's just the nature of it. It only triggers if you're unlucky. For
more details check these threads:
http://lkml.org/lkml/2005/5/10/70
ht
At Wed, 6 Jul 2005 08:51:03 -0700,
Greg KH wrote:
>
> On Wed, Jul 06, 2005 at 08:42:16AM -0700, Linus Torvalds wrote:
> >
> >
> > On Wed, 6 Jul 2005, Eyal Lebedinsky wrote:
> > >
> > > CC [M] sound/pci/bt87x.o
> > > sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
> > > sound/pci/bt87x
nd/pci/bt87x.c:807: error: for each function it appears in.)
>make[2]: *** [sound/pci/bt87x.o] Error 1
>make[1]: *** [sound/pci] Error 2
>make: *** [sound] Error 2
>
>
Hi,
The attached patch should fix it.
Regards,
Alexandre
Signed-off-by: Alexandre Buisse <[EMAIL PROTECTED]&
On Wed, Jul 06, 2005 at 05:53:05PM +0200, Jan Dittmer wrote:
> Linus Torvalds wrote:
> >
> > On Wed, 6 Jul 2005, Jan Dittmer wrote:
> >
> >>Linus Torvalds wrote:
> >>
> >>>Ok,
> >>> -rc3 is pretty small, with the bulk of the diff being some defconfig
> >>
> >>...
> >>
> >>>Linus Torvalds:
> >>>
On Wed, 6 Jul 2005, Eyal Lebedinsky wrote:
>
> CC [M] sound/pci/bt87x.o
> sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
> sound/pci/bt87x.c:807: error: `driver' undeclared (first use in this function)
> sound/pci/bt87x.c:807: error: (Each undeclared identifier is reported only
> onc
On Wed, Jul 06, 2005 at 08:42:16AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 6 Jul 2005, Eyal Lebedinsky wrote:
> >
> > CC [M] sound/pci/bt87x.o
> > sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
> > sound/pci/bt87x.c:807: error: `driver' undeclared (first use in this
> > function)
Linus Torvalds wrote:
Ok,
-rc3 is pretty small, with the bulk of the diff being some defconfig
updates, and cleanup of xtensa (notably removal of another copy of zlib).
Greg Kroah-Hartman:
PCI: clean up dynamic pci id logic
PCI: Fix up PCI routing in parent bridge
Without CONFIG_HOTPLU
Linus Torvalds wrote:
>
> On Wed, 6 Jul 2005, Jan Dittmer wrote:
>
>>Linus Torvalds wrote:
>>
>>>Ok,
>>> -rc3 is pretty small, with the bulk of the diff being some defconfig
>>
>>...
>>
>>>Linus Torvalds:
>>> Linux v2.6.13-rc3
>>
>>Confused?!
>
>
> Constantly.
>
> Let's hope that commit namin
On Wed, 6 Jul 2005, Jan Dittmer wrote:
>
> Linus Torvalds wrote:
> > Ok,
> > -rc3 is pretty small, with the bulk of the diff being some defconfig
> ...
> > Linus Torvalds:
> > Linux v2.6.13-rc3
>
> Confused?!
Constantly.
Let's hope that commit naming bug was the worst part of the release..
On Wed, 6 Jul 2005, Greg KH wrote:
>
> --- gregkh-2.6.orig/sound/pci/bt87x.c 2005-07-06 08:48:29.0 -0700
> +++ gregkh-2.6/sound/pci/bt87x.c 2005-07-06 08:48:54.0 -0700
> @@ -798,6 +798,8 @@
> {0x270f, 0xfc00}, /* Chaintech Digitop DST-1000 DVB-S */
> };
>
> +static
On Wed, Jul 06, 2005 at 09:22:05AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 6 Jul 2005, Greg KH wrote:
> >
> > --- gregkh-2.6.orig/sound/pci/bt87x.c 2005-07-06 08:48:29.0
> > -0700
> > +++ gregkh-2.6/sound/pci/bt87x.c2005-07-06 08:48:54.0 -0700
> > @@ -798,6 +798,8 @
On Wed, Jul 06, 2005 at 11:28:49AM +0200, Rafael J. Wysocki wrote:
> PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:01.0
> PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:01.1
> PCI: Failed to allocate I/O resource #7:[EMAIL PROTECTED] for :02:01.1
On Wed, Jul 06, 2005 at 01:44:05PM +0200, Ben Castricum wrote:
>
> CC [M] sound/pci/bt87x.o
> sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
> sound/pci/bt87x.c:807: `driver' undeclared (first use in this function)
> sound/pci/bt87x.c:807: (Each undeclared identifier is reported only o
Ben Castricum wrote:
CC [M] sound/pci/bt87x.o
sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
sound/pci/bt87x.c:807: `driver' undeclared (first use in this function)
sound/pci/bt87x.c:807: (Each undeclared identifier is reported only once
sound/pci/bt87x.c:807: for each function it app
On Thu, Jul 07, 2005 at 12:15:19AM +0200, Rafael J. Wysocki wrote:
> > Does the appended one-liner fix that?
>
> Yes, it does, but I'm still getting these in dmesg:
>
> PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:01.0
> PCI: Failed to allocate mem resource #10:[EMAIL PR
On Wednesday, 6 of July 2005 23:43, Ivan Kokshaysky wrote:
> On Wed, Jul 06, 2005 at 11:28:49AM +0200, Rafael J. Wysocki wrote:
> > albercik:~ # cardmgr
> > cardmgr[4702]: no sockets found!
> ..
> > PCI: Device :02:01.0 not available because of resource collisions
> > PCI: Device :02:01.1 n
On Wed, Jul 06, 2005 at 11:28:49AM +0200, Rafael J. Wysocki wrote:
> albercik:~ # cardmgr
> cardmgr[4702]: no sockets found!
...
> PCI: Device :02:01.0 not available because of resource collisions
> PCI: Device :02:01.1 not available because of resource collisions
Thanks for the report.
Do
On Wednesday, 6 of July 2005 18:47, Greg KH wrote:
> On Wed, Jul 06, 2005 at 11:28:49AM +0200, Rafael J. Wysocki wrote:
> > PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:01.0
> > PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:01.1
> > PCI: Failed to
On Wednesday, 6 of July 2005 19:16, Linus Torvalds wrote:
>
> On Wed, 6 Jul 2005, Greg KH wrote:
> >
> > On Wed, Jul 06, 2005 at 11:28:49AM +0200, Rafael J. Wysocki wrote:
> > > PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for
> > > :02:01.0
> > > PCI: Failed to allocate mem res
On Wed, 6 Jul 2005, Greg KH wrote:
>
> On Wed, Jul 06, 2005 at 11:28:49AM +0200, Rafael J. Wysocki wrote:
> > PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:01.0
> > PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for :02:01.1
> > PCI: Failed to allocate I/O
Yes, that fixed it. However, there was no problem with rc1 with the
same .config.
2005/7/6, Paulo Marques <[EMAIL PROTECTED]>:
> Alexis Ballier wrote:
> > Hi !
> >
> > I have a problem building the rc2 (or rc3, whatever ;) )
> >
> > Here is the end of the log :
> >
> > [...]
> > Inconsistent k
Alexis Ballier wrote:
Hi !
I have a problem building the rc2 (or rc3, whatever ;) )
Here is the end of the log :
[...]
Inconsistent kallsyms data
Try setting CONFIG_KALLSYMS_EXTRA_PASS
make: *** [vmlinux] Erreur 1
Can you try to change this setting in scripts/kallsyms.c:
#define WORKING_
2005/7/6, Florian Weimer <[EMAIL PROTECTED]>:
> * Linus Torvalds:
>
> > Ok,
> > -rc3 is pretty small,
>
> Is it -rc2 or -rc3? (Makefile and log message don't agree, either.)
-rc2
--
http://paoloc.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
CC [M] sound/pci/bt87x.o
sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
sound/pci/bt87x.c:807: `driver' undeclared (first use in this function)
sound/pci/bt87x.c:807: (Each undeclared identifier is reported only once
sound/pci/bt87x.c:807: for each function it appears in.)
sound/pci/bt
[resending different route to circumvent bogus SPF restrictions]
On Tue, 05 Jul 2005, Linus Torvalds wrote:
> Ok,
> -rc3 is pretty small, with the bulk of the diff being some defconfig
> updates, and cleanup of xtensa (notably removal of another copy of zlib).
CC [M] sound/pci/bt87x.o
sound/
On Tue, 05 Jul 2005, Linus Torvalds wrote:
> Ok,
> -rc3 is pretty small, with the bulk of the diff being some defconfig
> updates, and cleanup of xtensa (notably removal of another copy of zlib).
CC [M] sound/pci/bt87x.o
sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
sound/pci/bt87x.
CC [M] sound/pci/bt87x.o
sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
sound/pci/bt87x.c:807: error: `driver' undeclared (first use in this function)
sound/pci/bt87x.c:807: error: (Each undeclared identifier is reported only once
sound/pci/bt87x.c:807: error: for each function it app
CC [M] sound/pci/bt87x.o
sound/pci/bt87x.c: In function `snd_bt87x_detect_card':
sound/pci/bt87x.c:807: error: `driver' undeclared (first use in this function)
sound/pci/bt87x.c:807: error: (Each undeclared identifier is reported only once
sound/pci/bt87x.c:807: error: for each function it appea
On Wednesday, 6 of July 2005 06:32, Linus Torvalds wrote:
>
> Ok,
> -rc3 is pretty small, with the bulk of the diff being some defconfig
> updates, and cleanup of xtensa (notably removal of another copy of zlib).
>
> But there are ia64/arm/ppc64 updates and the TSO update from Davem is
> probabl
Hi !
I have a problem building the rc2 (or rc3, whatever ;) )
Here is the end of the log :
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM.tmp_kallsyms1.S
AS .tmp_
* Linus Torvalds:
> Ok,
> -rc3 is pretty small,
Is it -rc2 or -rc3? (Makefile and log message don't agree, either.)
-
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-in
On Tue, Jul 05, 2005 at 09:32:34PM -0700, Linus Torvalds wrote:
>
> Ok,
> -rc3 is pretty small, with the bulk of the diff being some defconfig
> updates, and cleanup of xtensa (notably removal of another copy of zlib).
Hmm.
-rc2:
in title, in tags, in makefile, in patch file name
-rc3:
in git
Linus Torvalds wrote:
> Ok,
> -rc3 is pretty small, with the bulk of the diff being some defconfig
...
> Linus Torvalds:
> Linux v2.6.13-rc3
Confused?!
--
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Ok,
-rc3 is pretty small, with the bulk of the diff being some defconfig
updates, and cleanup of xtensa (notably removal of another copy of zlib).
But there are ia64/arm/ppc64 updates and the TSO update from Davem is
probably worth pointing out to people. And various smaller things which
are mor
101 - 196 of 196 matches
Mail list logo
