* Re: [Qemu-devel] ./configure --help and gcc checks
From: Kevin F. Quinn @ 2006-04-06 22:59 UTC (permalink / raw)
To: qemu-devel; +Cc: spetreolle
In-Reply-To: <20060406123330.44792.qmail@web26804.mail.ukl.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
On Thu, 6 Apr 2006 14:33:30 +0200 (CEST)
Sylvain Petreolle <spetreolle@yahoo.fr> wrote:
> Hi people,
> I have gcc 3.2.3 (run as gcc32) and gcc 4.1.0.
>
> ./configure --help runs the gcc check, thus displaying the following
> error : ERROR: "gcc" looks like gcc 4.x
>
> IMHO this should be changed to avoid running things like this :
> ./configure --cc=gcc32 --help
I see what you mean now :)
It would enough to just move the gcc check in the configure script to
after the help processing.
--
Kevin F. Quinn
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Lee Revell @ 2006-04-06 22:54 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144363591.9219.16.camel@localhost.localdomain>
On Thu, 2006-04-06 at 23:46 +0100, Adrian McMenamin wrote:
> On Thu, 2006-04-06 at 18:25 -0400, Lee Revell wrote:
> > On Thu, 2006-04-06 at 23:16 +0100, Adrian McMenamin wrote:
> > > checking for directory with kernel
> > > source... /home/adrian/linux-2.6.15.2
> > > checking for directory with kernel
> > > build... /home/adrian/linux-2.6.15.2
> >
> > It's not ignoring them. It sounds like you just need to add aica to the
> > build scripts.
> >
> > What is the output of "grep aica ./configure"?
> >
> How do I add aica to it anyway? :)
>
I'm not sure (is it in the driver guide?). For starters I would just
copy the "emu10k1" entry in ./configure and substitute "aica" etc
Lee
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [ALSA - driver 0001826]: No line, mic, front-mic
From: bugtrack @ 2006-04-06 22:54 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1826>
======================================================================
Reported By: andreid1303
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1826
Category: PCI - hda-intel
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 02-06-2006 22:35 CET
Last Modified: 04-07-2006 00:54 CEST
======================================================================
Summary: No line, mic, front-mic
Description:
Line, mic, front-mic sound is dead on build-in Sigmatel 9221.
First I was not able to get it in Windows as well but found there a switch
assigning capture input then rised capture level and it is working now.
I tried to do the same via alsamixer but with no result.
======================================================================
----------------------------------------------------------------------
mate - 04-06-06 03:42
----------------------------------------------------------------------
I have same problem too (I tried the latest cvs version from 6. Apr.
2006).
Please fix this issue or if somebody have any idea please send me about
it.
Thanx.
----------------------------------------------------------------------
sharpen047 - 04-07-06 00:54
----------------------------------------------------------------------
i have seen several threads about this i have one too... and i cant find
ANY solution for me thus.. im on windows *bleh*
Issue History
Date Modified Username Field Change
======================================================================
02-06-06 22:35 andreid1303 New Issue
02-07-06 09:23 hweigel Issue Monitored: hweigel
04-06-06 03:42 mate Note Added: 0009122
04-07-06 00:54 sharpen047 Note Added: 0009128
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Lee Revell @ 2006-04-06 22:52 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144362544.9219.14.camel@localhost.localdomain>
On Thu, 2006-04-06 at 23:29 +0100, Adrian McMenamin wrote:
> On Thu, 2006-04-06 at 18:25 -0400, Lee Revell wrote:
> > On Thu, 2006-04-06 at 23:16 +0100, Adrian McMenamin wrote:
> > > checking for directory with kernel
> > > source... /home/adrian/linux-2.6.15.2
> > > checking for directory with kernel
> > > build... /home/adrian/linux-2.6.15.2
> >
> > It's not ignoring them. It sounds like you just need to add aica to the
> > build scripts.
> >
> > What is the output of "grep aica ./configure"?
> >
>
>
> I know that aica isn't in there - but the general build should still
> work and it doesn't...
>
> make[2]: Leaving directory `/home/adrian/alsa-driver-1.0.11rc4/pci'
> make[1]: Leaving directory `/home/adrian/alsa-driver-1.0.11rc4'
> make -C /lib/modules/2.6.12-10-686/build
> SUBDIRS=/home/adrian/alsa-driver-1.0.11rc4 O=/home/adrian/linux-2.6.15.2
> modules
> make[1]: Entering directory `/usr/src/linux-headers-2.6.12-10-686'
> /usr/src/linux-headers-2.6.12-10-686/Makefile:530: /usr/src/linux-headers-2.6.12-10-686/arch//Makefile: No such file or directory
> /bin/sh: /home/adrian/buildroot/build_sh4/staging_dir/bin/sh4-linux-gcc-3.4: No such file or directory
> make[2]: *** No rule to make target
> `/usr/src/linux-headers-2.6.12-10-686/arch//Makefile'. Stop.
> make[1]: *** [modules] Error 2
> make[1]: Leaving directory `/usr/src/linux-headers-2.6.12-10-686'
>
If the configure script bombs out, then I would not expect running make
afterwards to work. It's probably an old Makefile.
Try adding your device to ./configure
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Porting new MPC5200 based Board to linux kernel
From: Wolfgang Denk @ 2006-04-06 22:50 UTC (permalink / raw)
To: bukhari; +Cc: Linuxppc-embedded
In-Reply-To: <20060406205251.7511E67B16@ozlabs.org>
In message <20060406205251.7511E67B16@ozlabs.org> you wrote:
>
> Is that config file what I need to get linux running, didn't I need any
> board special code. Like tqm5xxx.c etc. which located on arch\ppc\platforms
What has the TQM code (fot TQ boards) to do with MEN boards? You must
be missing something.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming
^ permalink raw reply
* Re: problem building UML kernel with 2.6.16.1 -- dies when linking vmlinux
From: Jeff Dike @ 2006-04-06 21:51 UTC (permalink / raw)
To: Christopher Friesen; +Cc: linux-kernel
In-Reply-To: <443580A4.1020806@nortel.com>
On Thu, Apr 06, 2006 at 02:57:08PM -0600, Christopher Friesen wrote:
> gcc -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc
> -o vmlinux -Wl,-T,arch/um/kernel/vmlinux.lds init/built-in.o
> -Wl,--start-group usr/built-in.o arch/um/kernel/built-in.o
> arch/um/drivers/built-in.o arch/um/os-Linux/built-in.o
> arch/um/sys-i386/built-in.o arch/i386/crypto/built-in.o
> kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a
> lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o
> -Wl,--end-group -lutil .tmp_kallsyms2.o ; rm -f linux
> collect2: ld returned 1 exit status
You can't extract an error message from that somehow?
There isn't much to go on there.
Jeff
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Greg KH @ 2006-04-06 22:46 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060406222359.GA30037@austin.ibm.com>
On Thu, Apr 06, 2006 at 05:24:00PM -0500, Linas Vepstas wrote:
> + if(pci_enable_device(pdev)) {
Add a space after "if" and before "(" please.
You do this in a few different places.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Greg KH @ 2006-04-06 22:46 UTC (permalink / raw)
To: Linas Vepstas
Cc: Jeff Garzik, netdev, linux-pci, linux-kernel, linuxppc-dev,
john.ronciak, jesse.brandeburg, jeffrey.t.kirsher
In-Reply-To: <20060406222359.GA30037@austin.ibm.com>
On Thu, Apr 06, 2006 at 05:24:00PM -0500, Linas Vepstas wrote:
> + if(pci_enable_device(pdev)) {
Add a space after "if" and before "(" please.
You do this in a few different places.
thanks,
greg k-h
^ permalink raw reply
* Re: Porting new MPC5200 based Board to linux kernel
From: Wolfgang Denk @ 2006-04-06 22:48 UTC (permalink / raw)
To: Amir Bukhari; +Cc: Linuxppc-embedded
In-Reply-To: <EE3E34EBE104B24DA5DF5DBC1EA998D528801E@loretta.fzi.de>
In message <EE3E34EBE104B24DA5DF5DBC1EA998D528801E@loretta.fzi.de> you wrote:
> We have a MEN mpc5200 base board and we want to get linux running on it.
> MEN has a bios and can load linux kernel and passing to parameters. I have
> tried to configure kernel manualy but without success. MEN bios load kernel,
> but nothing happend after that, I don't see anything on console.
Is this by any chance a PP01 board? If yes, then see our
linuxppc_2_4_devel kernel tree which supports this board.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"...and the fully armed nuclear warheads, are, of course, merely a
courtesy detail."
^ permalink raw reply
* [linux-lvm] Recovering data from a damaged LVM partition?
From: Shawn @ 2006-04-06 21:45 UTC (permalink / raw)
To: linux-lvm
First post to this list, so please forgive me if I'm not on topic, or
repeating a common issue.
I have been asked to try to get data from a drive with a damaged partition.
In the past I've done this with ddrescue, and then mounted the resulting
image file. That's not working in this case because the partition in
question was part of an LVM volume.
My experience with LVM is not that great, as I've never seen a need for it on
my systems. But, I've installed the LVM tools, and modified my kernel for
LVM support, and can at least see the volume on the damaged drive now. But I
want to focus on the image file, not the drive.
So, the question is how to mount an image file of an LVM partition? Anytime I
try the mount command, it's complaining about the file system type. I've
tried the different options for the -t argument, (and am using the -o loop as
well).
I'm hesitant to run any of the LVM commands to create a volume set, or
intialize a partition, for fear of loosing the data. (though I could run
ddrescue again I suppose, as long as I don't touch the source drive).
Does anyone have any experience here they'd care to share? Thanks.
BTW, the disk in question is from a default install of Fedora Core 4, and the
system only had a single drive. So LVM probably wasn't needed in this case,
but the person that installed the system is not comfortable with the file
system details.
Shawn
^ permalink raw reply
* [Xenomai-core] [Xenoscope] GDB error
From: Bruno Rouchouse @ 2006-04-06 22:47 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
Hi,
someone using xenoscope for running simulation ?
I'm getting a "GDB error: No symbol "mvm_bp" in current context." while
launching my simulation under the xenoscope.
Other information: I'm using GNU gdb 6.3-debian and simulation process works
fine directly under gdb (can break in code, run simulation etc.)
I'm investigating but just in case someone has already stumbled over that !
Thanks.
--
Bruno Rouchouse
[-- Attachment #2: Type: text/html, Size: 512 bytes --]
^ permalink raw reply
* [RFC: 2.6 patch] the overdue removal of RAW1394_REQ_ISO_{LISTEN,SEND}
From: Adrian Bunk @ 2006-04-06 22:47 UTC (permalink / raw)
To: scjody; +Cc: linux1394-devel, linux-kernel
This patch contains the overdue removal of the RAW1394_REQ_ISO_SEND and
RAW1394_REQ_ISO_LISTEN request types plus all support code for them.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
Documentation/feature-removal-schedule.txt | 9 --
drivers/ieee1394/highlevel.c | 15 ---
drivers/ieee1394/highlevel.h | 4
drivers/ieee1394/ieee1394_core.c | 2
drivers/ieee1394/ieee1394_transactions.c | 30 -------
drivers/ieee1394/ieee1394_transactions.h | 3
drivers/ieee1394/raw1394.c | 88 ---------------------
drivers/ieee1394/raw1394.h | 4
8 files changed, 3 insertions(+), 152 deletions(-)
--- linux-2.6.17-rc1-mm1-full/Documentation/feature-removal-schedule.txt.old 2006-04-06 22:45:55.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/Documentation/feature-removal-schedule.txt 2006-04-06 22:46:04.000000000 +0200
@@ -48,15 +48,6 @@
---------------------------
-What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
-When: November 2005
-Why: Deprecated in favour of the new ioctl-based rawiso interface, which is
- more efficient. You should really be using libraw1394 for raw1394
- access anyway.
-Who: Jody McIntyre <scjody@steamballoon.com>
-
----------------------------
-
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
When: July 2006
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
--- linux-2.6.17-rc1-mm1-full/drivers/ieee1394/raw1394.h.old 2006-04-06 22:44:51.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ieee1394/raw1394.h 2006-04-06 22:45:44.000000000 +0200
@@ -17,11 +17,11 @@
#define RAW1394_REQ_ASYNC_WRITE 101
#define RAW1394_REQ_LOCK 102
#define RAW1394_REQ_LOCK64 103
-#define RAW1394_REQ_ISO_SEND 104
+/* removed: RAW1394_REQ_ISO_SEND 104 */
#define RAW1394_REQ_ASYNC_SEND 105
#define RAW1394_REQ_ASYNC_STREAM 106
-#define RAW1394_REQ_ISO_LISTEN 200
+/* removed: RAW1394_REQ_ISO_LISTEN 200 */
#define RAW1394_REQ_FCP_LISTEN 201
#define RAW1394_REQ_RESET_BUS 202
#define RAW1394_REQ_GET_ROM 203
--- linux-2.6.17-rc1-mm1-full/drivers/ieee1394/raw1394.c.old 2006-04-06 22:46:15.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ieee1394/raw1394.c 2006-04-06 22:47:11.000000000 +0200
@@ -636,43 +636,6 @@
return sizeof(struct raw1394_request);
}
-static void handle_iso_listen(struct file_info *fi, struct pending_request *req)
-{
- int channel = req->req.misc;
-
- if ((channel > 63) || (channel < -64)) {
- req->req.error = RAW1394_ERROR_INVALID_ARG;
- } else if (channel >= 0) {
- /* allocate channel req.misc */
- if (fi->listen_channels & (1ULL << channel)) {
- req->req.error = RAW1394_ERROR_ALREADY;
- } else {
- if (hpsb_listen_channel
- (&raw1394_highlevel, fi->host, channel)) {
- req->req.error = RAW1394_ERROR_ALREADY;
- } else {
- fi->listen_channels |= 1ULL << channel;
- fi->iso_buffer = int2ptr(req->req.recvb);
- fi->iso_buffer_length = req->req.length;
- }
- }
- } else {
- /* deallocate channel (one's complement neg) req.misc */
- channel = ~channel;
-
- if (fi->listen_channels & (1ULL << channel)) {
- hpsb_unlisten_channel(&raw1394_highlevel, fi->host,
- channel);
- fi->listen_channels &= ~(1ULL << channel);
- } else {
- req->req.error = RAW1394_ERROR_INVALID_ARG;
- }
- }
-
- req->req.length = 0;
- queue_complete_req(req);
-}
-
static void handle_fcp_listen(struct file_info *fi, struct pending_request *req)
{
if (req->req.misc) {
@@ -846,50 +809,6 @@
return sizeof(struct raw1394_request);
}
-static int handle_iso_send(struct file_info *fi, struct pending_request *req,
- int channel)
-{
- unsigned long flags;
- struct hpsb_packet *packet;
-
- packet = hpsb_make_isopacket(fi->host, req->req.length, channel & 0x3f,
- (req->req.misc >> 16) & 0x3,
- req->req.misc & 0xf);
- if (!packet)
- return -ENOMEM;
-
- packet->speed_code = req->req.address & 0x3;
-
- req->packet = packet;
-
- if (copy_from_user(packet->data, int2ptr(req->req.sendb),
- req->req.length)) {
- req->req.error = RAW1394_ERROR_MEMFAULT;
- req->req.length = 0;
- queue_complete_req(req);
- return sizeof(struct raw1394_request);
- }
-
- req->req.length = 0;
- hpsb_set_packet_complete_task(packet,
- (void (*)(void *))queue_complete_req,
- req);
-
- spin_lock_irqsave(&fi->reqlists_lock, flags);
- list_add_tail(&req->list, &fi->req_pending);
- spin_unlock_irqrestore(&fi->reqlists_lock, flags);
-
- /* Update the generation of the packet just before sending. */
- packet->generation = req->req.generation;
-
- if (hpsb_send_packet(packet) < 0) {
- req->req.error = RAW1394_ERROR_SEND_ERROR;
- queue_complete_req(req);
- }
-
- return sizeof(struct raw1394_request);
-}
-
static int handle_async_send(struct file_info *fi, struct pending_request *req)
{
unsigned long flags;
@@ -2272,9 +2191,6 @@
queue_complete_req(req);
return sizeof(struct raw1394_request);
- case RAW1394_REQ_ISO_SEND:
- return handle_iso_send(fi, req, node);
-
case RAW1394_REQ_ARM_REGISTER:
return arm_register(fi, req);
@@ -2290,10 +2206,6 @@
case RAW1394_REQ_RESET_NOTIFY:
return reset_notification(fi, req);
- case RAW1394_REQ_ISO_LISTEN:
- handle_iso_listen(fi, req);
- return sizeof(struct raw1394_request);
-
case RAW1394_REQ_FCP_LISTEN:
handle_fcp_listen(fi, req);
return sizeof(struct raw1394_request);
--- linux-2.6.17-rc1-mm1-full/drivers/ieee1394/highlevel.h.old 2006-04-06 22:55:51.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ieee1394/highlevel.h 2006-04-06 22:56:09.000000000 +0200
@@ -152,11 +152,9 @@
u64 start);
/*
- * Enable or disable receving a certain isochronous channel through the
+ * Disable receving a certain isochronous channel through the
* iso_receive op.
*/
-int hpsb_listen_channel(struct hpsb_highlevel *hl, struct hpsb_host *host,
- unsigned int channel);
void hpsb_unlisten_channel(struct hpsb_highlevel *hl, struct hpsb_host *host,
unsigned int channel);
--- linux-2.6.17-rc1-mm1-full/drivers/ieee1394/highlevel.c.old 2006-04-06 22:56:17.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ieee1394/highlevel.c 2006-04-06 22:56:22.000000000 +0200
@@ -439,21 +439,6 @@
return retval;
}
-int hpsb_listen_channel(struct hpsb_highlevel *hl, struct hpsb_host *host,
- unsigned int channel)
-{
- if (channel > 63) {
- HPSB_ERR("%s called with invalid channel", __FUNCTION__);
- return -EINVAL;
- }
-
- if (host->iso_listen_count[channel]++ == 0) {
- return host->driver->devctl(host, ISO_LISTEN_CHANNEL, channel);
- }
-
- return 0;
-}
-
void hpsb_unlisten_channel(struct hpsb_highlevel *hl, struct hpsb_host *host,
unsigned int channel)
{
--- linux-2.6.17-rc1-mm1-full/drivers/ieee1394/ieee1394_core.c.old 2006-04-06 22:56:30.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ieee1394/ieee1394_core.c 2006-04-06 22:56:48.000000000 +0200
@@ -1223,7 +1223,6 @@
EXPORT_SYMBOL(hpsb_make_lockpacket);
EXPORT_SYMBOL(hpsb_make_lock64packet);
EXPORT_SYMBOL(hpsb_make_phypacket);
-EXPORT_SYMBOL(hpsb_make_isopacket);
EXPORT_SYMBOL(hpsb_read);
EXPORT_SYMBOL(hpsb_write);
EXPORT_SYMBOL(hpsb_packet_success);
@@ -1234,7 +1233,6 @@
EXPORT_SYMBOL(hpsb_register_addrspace);
EXPORT_SYMBOL(hpsb_unregister_addrspace);
EXPORT_SYMBOL(hpsb_allocate_and_register_addrspace);
-EXPORT_SYMBOL(hpsb_listen_channel);
EXPORT_SYMBOL(hpsb_unlisten_channel);
EXPORT_SYMBOL(hpsb_get_hostinfo);
EXPORT_SYMBOL(hpsb_create_hostinfo);
--- linux-2.6.17-rc1-mm1-full/drivers/ieee1394/ieee1394_transactions.h.old 2006-04-06 22:56:59.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ieee1394/ieee1394_transactions.h 2006-04-06 22:57:03.000000000 +0200
@@ -20,9 +20,6 @@
octlet_t arg);
struct hpsb_packet *hpsb_make_phypacket(struct hpsb_host *host,
quadlet_t data) ;
-struct hpsb_packet *hpsb_make_isopacket(struct hpsb_host *host,
- int length, int channel,
- int tag, int sync);
struct hpsb_packet *hpsb_make_writepacket (struct hpsb_host *host, nodeid_t node,
u64 addr, quadlet_t *buffer, size_t length);
struct hpsb_packet *hpsb_make_streampacket(struct hpsb_host *host, u8 *buffer,
--- linux-2.6.17-rc1-mm1-full/drivers/ieee1394/ieee1394_transactions.c.old 2006-04-06 22:57:11.000000000 +0200
+++ linux-2.6.17-rc1-mm1-full/drivers/ieee1394/ieee1394_transactions.c 2006-04-06 22:58:21.000000000 +0200
@@ -79,18 +79,6 @@
packet->expect_response = 1;
}
-static void fill_iso_packet(struct hpsb_packet *packet, int length, int channel,
- int tag, int sync)
-{
- packet->header[0] = (length << 16) | (tag << 14) | (channel << 8)
- | (TCODE_ISO_DATA << 4) | sync;
-
- packet->header_size = 4;
- packet->data_size = length;
- packet->type = hpsb_iso;
- packet->tcode = TCODE_ISO_DATA;
-}
-
static void fill_phy_packet(struct hpsb_packet *packet, quadlet_t data)
{
packet->header[0] = data;
@@ -446,24 +434,6 @@
return p;
}
-struct hpsb_packet *hpsb_make_isopacket(struct hpsb_host *host,
- int length, int channel,
- int tag, int sync)
-{
- struct hpsb_packet *p;
-
- p = hpsb_alloc_packet(length);
- if (!p)
- return NULL;
-
- p->host = host;
- fill_iso_packet(p, length, channel, tag, sync);
-
- p->generation = get_hpsb_generation(host);
-
- return p;
-}
-
/*
* FIXME - these functions should probably read from / write to user space to
* avoid in kernel buffers for user space callers
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Adrian McMenamin @ 2006-04-06 22:46 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144362329.12038.22.camel@mindpipe>
On Thu, 2006-04-06 at 18:25 -0400, Lee Revell wrote:
> On Thu, 2006-04-06 at 23:16 +0100, Adrian McMenamin wrote:
> > checking for directory with kernel
> > source... /home/adrian/linux-2.6.15.2
> > checking for directory with kernel
> > build... /home/adrian/linux-2.6.15.2
>
> It's not ignoring them. It sounds like you just need to add aica to the
> build scripts.
>
> What is the output of "grep aica ./configure"?
>
How do I add aica to it anyway? :)
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [PATCH/RFC] powerpc: could not stop CPU(s) even with soft-reset when debugger enabled
From: Haren Myneni @ 2006-04-06 20:47 UTC (permalink / raw)
To: linuxppc-dev, fastboot; +Cc: michael, David Wilder, paulus, miltonm
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
- During CPU(s) hang scenarios, kdump could not stop these CPUs. However,
the user could invoke soft-reset to shoot down CPUs reliably. But, when
the debugger is enabled, these CPUs are returned to hang state after they
exited from the debugger. This patch fixes this issue by calling
crash_kexec_secondary() before returns to previous state.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
--- 2617-rc1/arch/powerpc/kernel/traps.c.orig 2006-04-05
13:25:22.000000000 -0700
+++ 2617-rc1/arch/powerpc/kernel/traps.c 2006-04-05
13:25:33.000000000 -0700
@@ -206,6 +206,16 @@ void system_reset_exception(struct pt_re
die("System Reset", regs, SIGABRT);
+ /*
+ * Some CPUs which got released from debugger will
execute this path.
+ * These CPUs entered debugger first time via soft-reset
- Means,
+ * could be possible that these CPUs may not repond to an
IPI later.
+ * Therefore, has to call kdump func directly.
+ * Not a problem if we exited from debugger to recover.
In this case
+ * there will not be any primary kexec CPU. Hence, will
be returned.
+ */
+ crash_kexec_secondary(regs);
+
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
panic("Unrecoverable System Reset");
[-- Attachment #2: Type: text/html, Size: 2420 bytes --]
^ permalink raw reply
* Re: problem compiling 2.6.16.1
From: Adrian Bunk @ 2006-04-06 22:43 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Linux Kernel Mailing List
In-Reply-To: <4d8e3fd30604060221i1d49cf2brd5fd786b6ce75822@mail.gmail.com>
On Thu, Apr 06, 2006 at 11:21:46AM +0200, Paolo Ciarrocchi wrote:
> Hi all,
> a friend of mine got this error compiling 2.6.16.1 and we don't know
> what's wrong:
>
> uno:/usr/src/linux-2.6.16.1# make O=/home/dan/build/kernel menuconfig
> HOSTCC scripts/basic/fixdep
>...
> /usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or directory
>...
> Any hint?
Your friend has gcc installed, but not the kernel headers that should
be provided by his distribution for usage with his libc (although they
are similar, these are _not_ the headers of the kernel he is trying
to compile).
> Paolo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [ALSA - driver 0002008]: No Sound with snd-hda-intel driver Asus P5VDC-MX
From: bugtrack @ 2006-04-06 22:43 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2008>
======================================================================
Reported By: mborsick
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2008
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Redhat/Fedora
Kernel Version: 2.6.16-1.2080 and with Xen
======================================================================
Date Submitted: 04-07-2006 00:43 CEST
Last Modified: 04-07-2006 00:43 CEST
======================================================================
Summary: No Sound with snd-hda-intel driver Asus P5VDC-MX
Description:
Kernel is up-to-date Xen kernel.
Initial install did not recognize the sound on an ASUS P5VDC-MX
motherboard.
Motherboard has southbridge VIA VT8251. CODEC is Realtek ACL653 AC'97 6
channel
Audio. Tried the updated drivers in 002404, but was unsuccessful. Also
tried
drivers on VIA site and Realltek site. The last couple of tries show no
errors
in compiling, make, etc. However, as I am just above novice in
understanding
everything about Linux, this has thrown me for a loop.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
04-07-06 00:43 mborsick New Issue
04-07-06 00:43 mborsick Distribution => Redhat/Fedora
04-07-06 00:43 mborsick Kernel Version => 2.6.16-1.2080 and
with Xen
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [NETFILTER 03/12]: Fix section mismatch warnings
From: Patrick McHardy @ 2006-04-06 22:42 UTC (permalink / raw)
To: David S. Miller; +Cc: netfilter-devel
In-Reply-To: <20060406.141309.51862771.davem@davemloft.net>
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Thu, 6 Apr 2006 12:04:56 +0200 (MEST)
>
>
>>[NETFILTER]: Fix section mismatch warnings
>>
>>Fix section mismatch warnings caused by netfilter's init_or_cleanup
>>functions used in many places by splitting the init from the cleanup
>>parts.
>>
>>Signed-off-by: Patrick McHardy <kaber@trash.net>
>
>
> Applied, but lots of trailing whitespace I had to clean up
> before applying. Please test your patches with:
>
> git apply --check --whitespace=error-all $1
Sorry, I know you already mentioned this. I already had the feeling
something is wrong with my whitespace-stripping regexes recently,
but didn't investigate. Most of my scripts need a rework anyway,
I'll make sure to fix this before submitting the next batch.
^ permalink raw reply
* Re: [PATCH] Allow menuconfig to cycle through choices
From: Randy.Dunlap @ 2006-04-06 22:40 UTC (permalink / raw)
To: John Rigby; +Cc: zippel, sam, linux-kernel
In-Reply-To: <4b73d43f0604061358v1c619e21rc6f3af2cdc4545a3@mail.gmail.com>
On Thu, 6 Apr 2006 14:58:34 -0600 John Rigby wrote:
>
>
Subject: [PATCH] Allow menuconfig to cycle through choices
Added cycling logic to dialog_checklist identical to what
dialog_menu already has.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi,
Can you give an example of a checklist (aka radiolist in menuconfig)
where this change has an effect?
I expected Timer frequency (choosing between 100, 250, 1000 HZ) to
cycle, but it does not. And I expected Default I/O scheduler
to cycle, but it does not. So where can I look for a change
after applying this patch?
Thanks,
---
~Randy
^ permalink raw reply
* Re: 2.6.17-rc1-mm1: KEXEC became SMP-only
From: Adrian Bunk @ 2006-04-06 22:37 UTC (permalink / raw)
To: Zachary Amsden
Cc: Andrew Morton, linux-kernel, ebiederm, rdunlap, fastboot,
James.Bottomley
In-Reply-To: <4432AB57.1040006@vmware.com>
On Tue, Apr 04, 2006 at 10:22:31AM -0700, Zachary Amsden wrote:
>...
> Voyager SMP builds don't compile with kexec(), and it isn't clear how to
> shootdown CPUs using NMIs without an APIC.
>...
> config KEXEC
> bool "kexec system call (EXPERIMENTAL)"
> - depends on EXPERIMENTAL && (!X86_VOYAGER && SMP)
> + depends on EXPERIMENTAL && !(X86_VOYAGER && SMP)
>...
Unless James disagrees with me, I'd prefer to let X86_VOYAGER depend on
SMP (the CONFIG_SMP=n case is anyways not compiling), and you could
express this simply as "&& !X86_VOYAGER".
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: fs/binfmt_elf.c:maydump()
From: David S. Miller @ 2006-04-06 22:35 UTC (permalink / raw)
To: dan; +Cc: linux-kernel
In-Reply-To: <20060406221519.GA5453@nevyn.them.org>
From: Daniel Jacobowitz <dan@debian.org>
Date: Thu, 6 Apr 2006 18:15:19 -0400
> On Thu, Apr 06, 2006 at 02:03:57PM -0700, David S. Miller wrote:
> > Yes, this means we might hit the core dump limits quicker but we
> > shouldn't be doing anything which makes less debugging information
> > than necessary available. Software development is hard enough as
> > it is right? :)
>
> > - /* If it hasn't been written to, don't write it out */
> > - if (!vma->anon_vma)
> > - return 0;
> > -
>
> Isn't this, um, a little more extreme than what you really want?
> What goes into coredumps with this patch applied? I bet it includes
> the complete text segments of every executable and shared library
> involved in the link. You're going to need those if you want to debug,
> anyway.
With this patch applied, yes, it includes the complete text segments of
every executable and shared library mapped into the program which is
dumping core.
What's a good check to avoid shared libraries and executables? And do
we really want to avoid including them? What if a new version of one
of the shared libraries is installed on the system after the core file
is generated? Wouldn't you want the complete original image so that
the program could be debugged accurately in the face of such changes?
Anyways a possible check would be if the object was mapped with
execute permission, so a test on VM_EXEC being set in vma->vm_flags.
But like the comment above maydump() seems to suggest, I'm of the
opinion that we should include as much as possible into the core
file image.
^ permalink raw reply
* Re: [NETFILTER 08/12]: H.323 helper: update Changelog
From: Patrick McHardy @ 2006-04-06 22:36 UTC (permalink / raw)
To: David S. Miller; +Cc: netfilter-devel
In-Reply-To: <20060406.141705.22962861.davem@davemloft.net>
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Thu, 6 Apr 2006 12:05:04 +0200 (MEST)
>
>
>>[NETFILTER]: H.323 helper: update Changelog
>>
>>Signed-off-by: Jing Min Zhao <zhaojingmin@users.sourceforge.net>
>>Signed-off-by: Patrick McHardy <kaber@trash.net>
>
>
> This doesn't make any sense. We have source revision control
> for keeping this kind of information around, so adding it to
> the source file is unnecessary duplication.
>
> I'm not applying this, sorry.
Fine with me, I already suggested to Jing Min to remove
the changelogs. Just tried to be polite by letting the
decision up to him :)
^ permalink raw reply
* Re: RT task scheduling
From: Darren Hart @ 2006-04-06 22:35 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Thomas Gleixner, Stultz, John, Peter Williams,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604061116.02429.darren@dvhart.com>
On Thursday 06 April 2006 11:16, you wrote:
> On Thursday 06 April 2006 00:37, Ingo Molnar wrote:
> > * Darren Hart <darren@dvhart.com> wrote:
> > > My last mail specifically addresses preempt-rt, but I'd like to know
> > > people's thoughts regarding this issue in the mainline kernel. Please
> > > see my previous post "realtime-preempt scheduling - rt_overload
> > > behavior" for a testcase that produces unpredictable scheduling
> > > results.
> >
...
> > in any case, i'll check your -rt testcase to see why it fails.
>
> Just as an example, here is the output a failing test case on a 4way
> machine running 2.6.16-rt13 (a successful run would have a final ball
> position of 0).
>
> [root@box sched_football]# ./sched_football 4 10
> Starting 4 offense threads at priority 15
> Starting 4 defense threads at priority 30
> Starting referee thread
> Game On (10 seconds)!
> Game Over!
> Final ball position: 5
> [root@box sched_football]#
>
> --Darren
On a related note, I tried observing the rt stats in /proc/stats while running
sched_football on 2.6.16-rt13. The entire log is nearly a MB so I placed it
on my website for reference
(http://www.dvhart.com/~dvhart/sched_football_stats.log), an excerpt follows:
---------------------
The following is the output of sched_football run with 1 thread for offense
and 1 thread for defense on a 4 way machine. The ball position is irrelevant
in this case since there are more CPUs than threads (they should all be able
to run). What is disturbing is that over the entire run, I never see RT
tasks on every CPU. Even though there are usually 5 total runnnable threads,
we constantly see groupings of 2 and 3 on the runqueues while the others have
no running rt tasks.
Looking back, I should have added a sleep to the loop - oops - still, I think
the data is interesting and suggests a problem with sceduling RT tasks across
all available CPUs. Does this seem like a valid test to everyone? Is there
perhaps some explanation as to why this would be expected (when the cat
process get's to read the proc information or something) ?
# ./sched_football 1 60
Starting 1 offense threads at priority 15
Starting 1 defense threads at priority 30
Starting referee thread
Game On (60 seconds)!
Game Over!
Final ball position: 20359767
# while true; do clear; cat /proc/stat | grep rt >> sched_football_stats.log;
done
sched_football_stats.log
------------------------------
rt_overload_schedule: 57768
rt_overload_wakeup: 157501
rt_overload_pulled: 13722934
rt_nr_running(0): 0
rt_nr_running(1): 0
rt_nr_running(2): 0
rt_nr_running(3): 0
rt_overload: 0
rt_overload_schedule: 57769
rt_overload_wakeup: 157514
rt_overload_pulled: 13722937
rt_nr_running(0): 0
rt_nr_running(1): 2
rt_nr_running(2): 3
rt_nr_running(3): 0
rt_overload: 2
...
rt_overload_schedule: 57774
rt_overload_wakeup: 157738
rt_overload_pulled: 13722941
rt_nr_running(0): 0
rt_nr_running(1): 2
rt_nr_running(2): 4
rt_nr_running(3): 0
rt_overload: 2
...
rt_overload_schedule: 57791
rt_overload_wakeup: 158650
rt_overload_pulled: 13722964
rt_nr_running(0): 0
rt_nr_running(1): 2
rt_nr_running(2): 0
rt_nr_running(3): 3
rt_overload: 2
...
rt_overload_schedule: 57808
rt_overload_wakeup: 166924
rt_overload_pulled: 13722973
rt_nr_running(0): 0
rt_nr_running(1): 0
rt_nr_running(2): 0
rt_nr_running(3): 2
rt_overload: 1
rt_overload_schedule: 57808
rt_overload_wakeup: 166927
rt_overload_pulled: 13722973
rt_nr_running(0): 0
rt_nr_running(1): 0
rt_nr_running(2): 0
rt_nr_running(3): 0
rt_overload: 0
---------------------
^ permalink raw reply
* Routing directed broadcast
From: Matthew Clark @ 2006-04-06 22:32 UTC (permalink / raw)
To: netfilter
Hi List,
I am wondering if there is any way to route directed broadcast packets
through a linux box using iptables.
So far I have tried (through a friends suggestion) to mark the packet
in the mangle table of the PREROUTING chain, change the packet to be a
packet that will route and then change it back to a broadcast on the
OUTPUT chain.
i.e.
Broadcasting to 10.200.172.255
Packets are coming in to eth0 (10.14.172.250/24)
Packets need to go out eth1 (10.200.172.250/24)
Have tried
iptables -t mangle -A PREROUTING -i eth0 -d 10.200.172.255 -j MARK
--set-mark 0x10
iptables -t nat -A PREROUTING -i eth0 -d 10.200.172.255 -j DNAT
--to-dest 10.200.172.254
iptables -v -t nat -A OUTPUT -d 10.200.172.254 --match mark --mark
0x10 -j DNAT --to-dest 10.200.172.255
But the problem I find is that whilst matching in the mangle table
Chain PREROUTING (policy ACCEPT 246K packets, 35M bytes)
pkts bytes target prot opt in out source destination
79687 19M MARK all -- eth0 * 0.0.0.0/0
10.200.172.255 MARK set 0x10
The packets don't make it to the nat table
Chain PREROUTING (policy ACCEPT 9014 packets, 567K bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT all -- eth0 * 0.0.0.0/0
10.200.172.255 to:10.200.172.254
Why are the packets not making to the nat PREROUTING chain?
Is there a better way of doing this?
Thanks in advance,
Matt.
Apologies if this email arrived twice, but I received an email saying
my first post failed because my source email address was not from a
subscribed member (rectified).
^ permalink raw reply
* Re: Cross compiling alsa-driver
From: Adrian McMenamin @ 2006-04-06 22:29 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1144362329.12038.22.camel@mindpipe>
On Thu, 2006-04-06 at 18:25 -0400, Lee Revell wrote:
> On Thu, 2006-04-06 at 23:16 +0100, Adrian McMenamin wrote:
> > checking for directory with kernel
> > source... /home/adrian/linux-2.6.15.2
> > checking for directory with kernel
> > build... /home/adrian/linux-2.6.15.2
>
> It's not ignoring them. It sounds like you just need to add aica to the
> build scripts.
>
> What is the output of "grep aica ./configure"?
>
I know that aica isn't in there - but the general build should still
work and it doesn't...
make[2]: Leaving directory `/home/adrian/alsa-driver-1.0.11rc4/pci'
make[1]: Leaving directory `/home/adrian/alsa-driver-1.0.11rc4'
make -C /lib/modules/2.6.12-10-686/build
SUBDIRS=/home/adrian/alsa-driver-1.0.11rc4 O=/home/adrian/linux-2.6.15.2
modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.12-10-686'
/usr/src/linux-headers-2.6.12-10-686/Makefile:530: /usr/src/linux-headers-2.6.12-10-686/arch//Makefile: No such file or directory
/bin/sh: /home/adrian/buildroot/build_sh4/staging_dir/bin/sh4-linux-gcc-3.4: No such file or directory
make[2]: *** No rule to make target
`/usr/src/linux-headers-2.6.12-10-686/arch//Makefile'. Stop.
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.12-10-686'
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [LARTC] Multi default gateway and 2.4.30
From: Alexander Samad @ 2006-04-06 22:27 UTC (permalink / raw)
To: lartc
In-Reply-To: <20060406220418.GB7764@hufpuf.lan1.hme1.samad.com.au>
[-- Attachment #1.1: Type: text/plain, Size: 1538 bytes --]
On Fri, Apr 07, 2006 at 08:04:18AM +1000, Alexander Samad wrote:
> Hi
>
> I have just moved my firewall from a 2.6 debian machine to a 2.4.30
> openwrt (linksys wrt54gs) box.
>
> I orginially had this working with 2 isp, 1 cable 1 adsl and dyndns.
>
> Now when i have moved to 2.4.30 I am having problems. Everything else
> is working fine except when I DNAT packets from the firewall to an
> internal address, ie my web browser is inside so I DNAT from the
> external IP to the internal web server.
>
> now I am getting time outs, upon investigation what is happening is that
> packets are coming in, getting DNAT'ed, the web server is returning
> them, they get un DNAT, but a new call to the routing table is made and
> it seems to bypass the ip rules rules I have, all traffic that
> terminates on the external IP is okay and doesn't suffer from the
> problem.
>
> I remember reading about patches for the iproute and the kernel but I
> haven't kept up to date with those since I started using 2.6
>
> Am i missing a patch ??
>
> Thanks
>
>
Had anothe look through the archives, via google and found a thread
about 2.4.29 and the fact that the default routes shouldn't be in the
main table.
I have removed the default routes and placed them in the default table
and things seem to be okay now.
Is this a know problem ????
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.