* [ALSA - driver 0001090]: Support for new Prodigy 7.1 LT
From: bugtrack @ 2005-07-20 23:25 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1090>
======================================================================
Reported By: Demosthenes
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1090
Category: PCI - ice1724
Reproducibility: always
Severity: feature
Priority: normal
Status: new
Distribution: Ubuntu (Hoary Hedgehog)
Kernel Version: 2.6.10
======================================================================
Date Submitted: 05-06-2005 17:34 CEST
Last Modified: 07-21-2005 01:25 CEST
======================================================================
Summary: Support for new Prodigy 7.1 LT
Description:
Could you please try to add support for the Audiotrak Prodigy 7.1 LT, as
far as I am aware this card is essentially the same as the Produgy 7.1 but
low profile and with a couple of physical changes such as no digital in.
ALSA does not detect the card currently and when I try to load the
snd-1724 module it fails with an EEPROM error.
I have tried compiling a new kernel with the subdevice id for the Prodigy
7.1 in aureon.h changed to correspond to my device (as detailed here for
another card
http://linux.derkeiler.com/Newsgroups/comp.os.linux.hardware/2004-10/0340.html).
Alsa then detects the card and I can load modules and change volumes in
alsamixer but I haven't been able to produce any sound.
Hopefully support will be easy to add as this card is almost exactly the
same as the Prodigy 7.1 (and Aureon Space etc.) which already have
support.
I would be very happy to give any further information needed.
======================================================================
----------------------------------------------------------------------
Demosthenes - 07-20-05 21:04
----------------------------------------------------------------------
I have sound coming out yes, however from the front speakers socket the
sound is extremely quiet, out of the headphone socket the sound seems
pretty reasonable. We have had trouble with the external amp and I am not
sure if this would be the reason for the sound issues, Ungod will probably
give you a better insight than I have.
I have not tried the digital outs, it is possible that I could if ever it
was needed but not without a small amount of difficulty.
It will be good to have another person to test the driver and someone else
who knows what they are doing as far as the code is concerned can't hurt.
P.S. I am not sure what you mean by you have been using precompiled
drivers and now you will use the source, it was my impression that only
the module for the ice1724 needed to be compiled from cvs with the patch
applied.
----------------------------------------------------------------------
darins - 07-21-05 01:25
----------------------------------------------------------------------
You are correct about only needing to compile the ice1724 driver.
Up until I started having problems with sound, I have just been using
modules that were already built as part of the Fedora Core 3 distribution
(or updates to it).
Now I am going to just go straight to the source and compile my own
module, using the patches here; and start experimenting with that.
Looking at the list of components:
1. WM8770IFT --> this is the audio CODEC
2. 3CZ09FJ --> unknown right now, someone else mentioned a Texas logo, so
probaby a TI part--I used to work for TI, but so far I haven't found this
in their product list, I'm guessing it is a buffer, probably similar to
chip https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3; or maybe it is
the S/PDIF transcoder.
3. HC125A, PAU139 --> buffer IC, commodity part available from TI,
Motorola, ON, etc.
4. IL1117-33, 451 --> low-dropout voltage regulator--power conditioning
for the chip
5. ATMEL426, 24C02N --> 256x8 EEPROM
6. H17A, 316BJ --> from the photo and part number, I'd guess a transistor
or diode
7. NCO-3.3V, 49.152MHz, NTE --> oscillator that probably sources the
codec
I will look at my card tonight, but it does appear that they are using 6
amps (makes sense, 6 amplified channels). The parts in the diagram marked
"voltage regulator?" are definitely voltage regulators. Looks like one
resistor pack a little close to one, but not too bad.
I will focus on looking at the amps, figuring out how they are controlled,
where the gain setting comes from, etc. Basically how it is supposed to
work. Once I understand that, it shouldn't take long to figure out how to
command it to do what we want. I found the datasheet to the CODEC here:
http://www.profusionplc.com/static/images/data%20sheets/wm8770ift.pdf
Looks like it has its own amps with builtin digital pots, so this is where
all the volume control is really being done. If those other chips are
amps, then they probably just have a constant gain on them...maybe they
are with unity gain and just isolating signals--dunno at the moment. SPI
is probably being used to control this--the chip supports an SPI or CCB
(Sanyo-specific 3-wire bus) control bus. From what I can tell on the
Envy24 family (ice chip) it looks like a codec that supported a I2C
control bus would've been easier. Maybe they do control by bit-banging
some GPIOs, since there are plenty of them around?
Interesting. I'll let you know as soon as I have something.
Issue History
Date Modified Username Field Change
======================================================================
05-06-05 17:34 Demosthenes New Issue
05-06-05 17:35 Demosthenes Distribution => Ubuntu (Hoary
Hedgehog)
05-06-05 17:35 Demosthenes Kernel Version => 2.6.10
05-06-05 22:44 ungod Note Added: 0004597
05-06-05 22:48 ungod Note Added: 0004598
05-07-05 01:38 Demosthenes Note Added: 0004600
05-07-05 01:47 Demosthenes Note Edited: 0004600
05-08-05 00:45 ungod Note Added: 0004608
05-08-05 17:30 Demosthenes Note Added: 0004610
05-08-05 17:39 ungod File Added: aureon-prodigy71lt-fix.diff
05-08-05 17:40 ungod Note Added: 0004611
05-08-05 19:09 Demosthenes Note Added: 0004612
05-08-05 19:12 Demosthenes Note Edited: 0004612
05-08-05 19:12 Demosthenes Note Edited: 0004612
05-08-05 20:08 ungod Note Added: 0004614
05-08-05 20:18 Demosthenes Note Added: 0004615
05-08-05 20:23 ungod Note Added: 0004616
05-08-05 20:27 ungod Note Added: 0004617
05-08-05 20:37 Demosthenes Note Added: 0004618
05-09-05 01:01 ungod Note Added: 0004620
05-09-05 13:15 Demosthenes Note Added: 0004624
05-09-05 14:49 ungod Note Added: 0004625
05-09-05 15:03 Demosthenes Note Added: 0004626
05-10-05 09:36 ungod Note Added: 0004632
05-10-05 15:50 Demosthenes Note Added: 0004633
05-14-05 15:18 Demosthenes Note Added: 0004658
05-14-05 20:24 Demosthenes Note Edited: 0004658
06-14-05 16:02 baesyspem Note Added: 0005018
06-14-05 16:03 baesyspem Issue Monitored: baesyspem
06-14-05 16:03 baesyspem Issue End Monitor: baesyspem
06-14-05 18:30 Demosthenes Note Added: 0005019
06-14-05 18:50 Demosthenes Note Edited: 0005019
06-14-05 21:26 ungod Note Added: 0005020
06-14-05 21:27 ungod Note Edited: 0005020
06-29-05 18:30 Demosthenes Note Added: 0005307
06-30-05 01:03 ungod Note Added: 0005321
06-30-05 01:08 ungod Issue Monitored: ungod
06-30-05 01:46 baesyspem Note Added: 0005322
06-30-05 02:27 Demosthenes Note Added: 0005323
06-30-05 02:29 Demosthenes Note Edited: 0005323
06-30-05 02:29 Demosthenes Note Edited: 0005323
06-30-05 02:36 Demosthenes Note Edited: 0005323
06-30-05 02:38 Demosthenes Note Edited: 0005323
06-30-05 21:21 ungod Note Added: 0005328
07-01-05 14:25 baesyspem Note Added: 0005333
07-01-05 16:09 baesyspem Note Added: 0005335
07-01-05 20:41 ungod File Added: aureon-prodigy71lt-fix2.diff
07-01-05 20:43 ungod Note Added: 0005339
07-01-05 22:08 Demosthenes Note Added: 0005341
07-01-05 22:46 ungod Note Added: 0005342
07-01-05 23:09 Demosthenes Note Added: 0005344
07-01-05 23:10 Demosthenes Note Edited: 0005344
07-02-05 00:31 Demosthenes Note Edited: 0005344
07-02-05 03:29 ungod Note Added: 0005350
07-02-05 03:30 ungod File Added: prodigytest.tar.gz
07-02-05 03:37 ungod Note Edited: 0005350
07-02-05 16:50 Demosthenes Note Added: 0005353
07-02-05 18:10 Demosthenes Note Edited: 0005344
07-02-05 18:27 ungod Note Added: 0005354
07-02-05 18:36 Demosthenes Note Added: 0005355
07-02-05 20:20 ungod Note Added: 0005358
07-02-05 20:59 Demosthenes Note Added: 0005359
07-02-05 21:43 ungod File Added: peak.tar.gz
07-02-05 21:44 ungod Note Added: 0005360
07-02-05 22:30 Demosthenes Note Added: 0005362
07-03-05 00:21 ungod Note Added: 0005363
07-03-05 01:49 Demosthenes Note Added: 0005364
07-03-05 01:55 ungod Note Added: 0005365
07-03-05 02:46 Demosthenes Note Added: 0005366
07-03-05 02:47 Demosthenes Note Edited: 0005366
07-03-05 03:18 Demosthenes Note Added: 0005367
07-03-05 03:21 Demosthenes Note Edited: 0005367
07-03-05 11:35 ungod File Added: aureon-prodigy71lt-fix3.diff
07-03-05 11:47 ungod Note Added: 0005373
07-03-05 15:29 Demosthenes Note Added: 0005377
07-03-05 17:06 ungod Note Added: 0005379
07-04-05 14:34 miljan Issue Monitored: miljan
07-04-05 14:35 miljan Issue End Monitor: miljan
07-04-05 14:35 miljan Issue Monitored: miljan
07-06-05 19:19 Demosthenes Note Added: 0005392
07-08-05 22:52 ungod Note Added: 0005437
07-13-05 03:57 ungod Note Added: 0005457
07-13-05 03:58 ungod File Added: gpio.tar.gz
07-13-05 04:12 Demosthenes Note Added: 0005458
07-13-05 04:24 ungod Note Added: 0005459
07-13-05 04:28 Demosthenes Note Added: 0005460
07-13-05 04:46 ungod Note Added: 0005461
07-13-05 04:57 Demosthenes Note Added: 0005462
07-13-05 04:59 Demosthenes Note Added: 0005463
07-13-05 05:00 Demosthenes Note Edited: 0005463
07-13-05 19:39 Demosthenes Note Added: 0005466
07-14-05 13:19 ungod Note Added: 0005472
07-14-05 13:31 Demosthenes Note Added: 0005473
07-14-05 13:54 Demosthenes Note Added: 0005474
07-15-05 15:08 ungod Note Added: 0005481
07-15-05 15:17 Demosthenes Note Added: 0005482
07-15-05 15:23 Demosthenes Note Edited: 0005474
07-20-05 18:01 darins Issue Monitored: darins
07-20-05 19:07 darins Note Added: 0005534
07-20-05 20:56 Demosthenes Note Added: 0005535
07-20-05 21:04 Demosthenes Note Edited: 0005535
07-21-05 01:25 darins Note Added: 0005537
======================================================================
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
^ permalink raw reply
* Re: [Qemu-devel] Weird bahaviour of TOP and cdrom under Qemu-system-ppc
From: Tero Kaarlela @ 2005-07-20 23:04 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <1121892393.9483.19.camel@rapid>
J. Mayer wrote:
>
>Fabrice has a fix for this.
>You can also edit hw/ide.c and comment the one-line Darwin hack (easy to
>find).
>
>
If this is what you mean:
#ifdef TARGET_PPC
/* XXX: currently a workaround for Darwin/PPC. Need to check
the IDE spec to see if it is correct */
- ide_set_signature(s);
+ //ide_set_signature(s);
It seems to be removed from CVS.
Tero
^ permalink raw reply
* RE: Re: drop counts
From: Brandeburg, Jesse @ 2005-07-20 23:23 UTC (permalink / raw)
To: P; +Cc: netdev, netdev, e1000-devel
I apologize for my misconfigured email client, this is my correct
address
PS machine rebuilds suck.
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Jesse Brandeburg
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
^ permalink raw reply
* Re: amd64-agp vs. swsusp
From: Rafael J. Wysocki @ 2005-07-20 23:23 UTC (permalink / raw)
To: Michal Schmidt; +Cc: Andreas Steinmetz, Pavel Machek, Dave Jones, linux-kernel
In-Reply-To: <42DECB21.5020903@stud.feec.vutbr.cz>
On Thursday, 21 of July 2005 00:07, Michal Schmidt wrote:
> Rafael J. Wysocki wrote:
> > On Tuesday, 19 of July 2005 23:26, Michal Schmidt wrote:
> >>I have rebuilt agpgart and amd64-agp into the kernel and now it has
> >>resumed successfully for the first time. Thank you for the hint!
> >>
> >>But I still wonder, why that makes a difference.
> >
> >
> > Before resume the module is not present. When it gets loaded from the
> > image it probably runs with the assumption that the hardware was initialized
> > which is not correct.
>
> It seems that the module doesn't even get a chance to run after resume.
> I've put some printks and udelays into kernel/power/swsusp.c and other
> places and I've found that the spontaneous reset occurs already in
> swsusp_arch_resume(), ie. before the drivers get their resume methods
> called. This is what I have in swsusp_suspend() now:
> ...
> save_processor_state();
> if ((error = swsusp_arch_suspend()))
> printk(KERN_ERR "Error %d suspending\n", error);
> /* Restore control flow magically appears here */
> restore_processor_state();
> printk(KERN_INFO "processor state restored!\n");/*I added this*/
> BUG_ON (nr_copy_pages_check != nr_copy_pages);
> restore_highmem();
> device_power_up();
> ...
>
> I'm recording the screen during resuming with a digital camera to see if
> the added printk is displayed before the reset and I am now sure that
> the reset occurs before that. The last thing I see is:
>
> Stopping tasks: --|
> Freeing memory... done (0 pages freed)
> swsusp: Need to copy 8121 pages
Please note that printk() only places the string in a buffer and it does not
get actually printed before it can be displayed which is probably after your
screen is set up (including the AGP resume, I'd guess). :-)
You may be able to get more from eg. the serial console, but this requires
some tampering with the serial code, AFAIR.
> Then on the next frame of the recorded MPEG, the display is already
> beginning to dim as the computer is resetting.
>
> I also tried putting a printk before restore_processor_state(), but I'm
> not sure if it is safe to use printk there.
Yes, it is, but you may be unable to see the message if the box reboots before
it can be displayed.
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
^ permalink raw reply
* kernel oops with x64_86 crossing 4Gb boundary
From: Francois Pepin @ 2005-07-20 23:18 UTC (permalink / raw)
To: linux-kernel
Hi,
I am getting pseudo-random kernel oops on my Opteron box (Tyan Thunder
K8W) with 4Gb RAM. I am running RedHad FC3 with kernel
2.6.11-1.35_FC3smp.
It runs well with default BIOS settings, but only 3.5Gb RAM are visible.
Using the "Software Memory Hole" option in the BIOS (version 3.02)
remaps the last 2Gb to 4-6Gb. This causes kernel oops with various
applications, generally killing them.
I can reproduce it by loading lots of data into R (which caused the oops
below). Various other applications have caused it too.
Oops: 0000 [1] SMP
CPU 1
Modules linked in: nfs lockd parport_pc lp parport autofs4 sunrpc pcmcia
yenta_socket rsrc_nonstatic pcmcia_core dm_mod video button battery ac
nvidia(U) md5 ipv6 ohci1394 ieee1394 ohci_hcd uhci_hcd ehci_hcd
i2c_amd8111 i2c_core hw_random sata_sil libata scsi_mod snd_intel8x0
snd_ca0106 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer
snd soundcore snd_page_alloc e1000 floppy ext3 jbd
Pid: 5288, comm: R Tainted: P 2.6.11-1.35_FC3smp
RIP: 0010:[<ffffffff8016be0a>] <ffffffff8016be0a>{pte_alloc_map+170}
RSP: 0000:ffff8101553f5db8 EFLAGS: 00010293
RAX: ffffffff7fffffff RBX: 00002aaad0c00000 RCX: 0000000000000000
RDX: ffff810107c95000 RSI: ffff81000000f800 RDI: ffff81000000f000
RBP: ffff81012d20a430 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000007f71c R11: 0000000000000000 R12: 0000000000000000
R13: ffff810173270040 R14: ffff8101732700b8 R15: ffff81012d20a430
FS: 00002aaaaae6b900(0000) GS:ffffffff804dd680(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000002730 CR3: 0000000156775000 CR4: 00000000000006e0
Process R (pid: 5288, threadinfo ffff8101553f4000, task
ffff8101559f3810)
Stack: ffff8101567752a8 00002aaad0c00000 ffff810159fe9a68
ffff810173270040
0000000000000001 ffffffff8016ed05 0000000000000000
ffff8101732700b8
ffff81015a033a80 00002aaaad975000
Call Trace:<ffffffff8016ed05>{handle_mm_fault+293}
<ffffffff80122994>{do_page_fault+1172}
<ffffffff8014f100>{autoremove_wake_function+0}
<ffffffff801b87be>{dnotify_parent+46}
<ffffffff8018132c>{vfs_read+268} <ffffffff8010f0a1>{error_exit+0}
Code: 48 8b b1 30 27 00 00 76 0d b8 00 00 00 80 eb 10 66 66 90 66
RIP <ffffffff8016be0a>{pte_alloc_map+170} RSP <ffff8101553f5db8>
CR2: 0000000000002730
Please tell me if more information is necessary.
Francois
^ permalink raw reply
* resize.reiser4
From: Lucas Clemente Vella @ 2005-07-20 23:17 UTC (permalink / raw)
To: reiserfs-list
Where can I find 'resize.reiser4'?
It is not in 'reiser4progs-1.0.4.tar.gz', there are only it's man page
there. In Google, all I could find is the man page.
--
Lucas Clemente Vella
lvella@gmail.com
^ permalink raw reply
* Re: [LARTC] Transfer rate above the desired (tc+htb)
From: Francisco Pereira @ 2005-07-20 23:14 UTC (permalink / raw)
To: lartc
In-Reply-To: <3941d81c0507201042563b5e45@mail.gmail.com>
Alvaro Motta wrote:
> Hi folks.
Hola.
> I started to play with tc+htb last week, and I must confess that this
> thing is really driving me nuts.
If you started last week, you have a loooong way to go.... :-)
> All we want to do is control bw, with no borrowing.
>
> In order to get the feeling on this subject, I have setup the
> following test bed.
>
> ---A---B---C---
>
> On B: eth0 connecting A and eth1 connecting C.
>
> The script.
>
> tc qdisc del dev eth0 root
> tc qdisc add dev eth0 root handle 1: htb default 50
> tc class add dev eth0 parent 1: classid 1:1 htb rate 32kbit ceil 32kbit
> tc filter add dev eth0 protocol ip parent 1:0 prio 100 u32 match ip
> src 10.4.0.0/16 match ip dst 0.0.0.0/0 classid 1:1
>
> If I try to transfer a 1M file from C to A:
>
> [root@localpost tmp]# wget 192.168.0.23/1M
> --09:22:32-- http://192.168.0.23/1M => `1M.8'
> Connecting to 192.168.0.23:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 1,024,000 [text/plain]
> 100%[===========>] 1,024,000 183.12K/s ETA 00:00
> 09:22:38 (182.88 KB/s) - `1M' saved [1,024,000/1,024,000]
>
> Wasn't it supposed to be around the 32KB/s?
Around 32 kilobits/s. Besides this, the rate calculation includes not
only the ip packet effective payload, but all the packet size, and I
guess that wget's speed calculation only includes the payload.
The tc manpage have a section on "Units".
> If I play with the numbers (rateÎil) I get the following results:
> 128k => 404.78 KB/s
> 64k => 337.9 KB/s
> 16k => 68.86 KB/s
> 8k => 31.12 KB/s
> 1k => 3.77 KB/s
>
> I even tried to set the rate to 1kbps in root, but also led to pretty
> much the same results.
>
> With no qdisc, the rate will go close to 1000 KB/s
>
> B machine:
> 2.6.11-1.1369_FC4
> iproute-2.6.11-1
> TC HTB version 3.3
>
> I have no clue on what I am doing wrong. Could anyone browse the above
> script and give me hint?
>
> Thanks in advance,
>
> AL
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Rates just dropped
From: Megan Block @ 2005-07-20 23:13 UTC (permalink / raw)
To: blah
Cc: kernel, linux-aio, linux-mm, linux-mm-archive, mailer-daemon,
owner-linux-aio, owner-linux-mm, owner-majordomo
Hello,
We tried contacting you awhile ago about your low interest morta(ge rate.
You have been selected for our lowest rate in years...
You could get over $420,000 for as little as $400 a month!
Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what!
To get a free, no obli,gation consultation click below:
http://www.discounted-rates.com/i/LzMvaW5kZXgvaW5rL3ZnczJ0
Best Regards,
Mae Winston
to be remov(ed: http://www.discounted-rates.com/i/LzMvaW5kZXgvaW5rL3ZnczJ0
this process takes one week, so please be patient. we do our
best to take your email/s off but you have to fill out a rem/ove
or else you will continue to recieve email/s.
^ permalink raw reply
* Obsolete files in 2.6 tree
From: Jiri Slaby @ 2005-07-20 23:10 UTC (permalink / raw)
To: Linux Kernel Mailing List
Are these files obsolete and could be deleted from tree.
Does anybody use them? Could anybody compile them?
drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c
drivers/char/scan_keyb.c
drivers/char/scan_keyb.h
drivers/input/power.c
drivers/isdn/hisax/elsa_ser.c
drivers/media/video/zr36120.c
drivers/media/video/zr36120_i2c.c
drivers/media/video/zr36120_mem.c
drivers/net/wan/sdladrv.c
drivers/scsi/aic7xxx_old*
drivers/scsi/NCR5380.c
drivers/scsi/NCR5380.h
drivers/scsi/scsi_module.c
drivers/video/pm3fb.c
fs/befs/attribute.c
fs/binfmt_som.c
fs/binfmt_flat.c
sound/oss/skeleton.c
--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~ jirislaby@gmail.com ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10
^ permalink raw reply
* THEY FOUND NEW ANTIDOTE
From: Simon @ 2005-07-20 23:08 UTC (permalink / raw)
To: sparclinux
The Ancient Secret of Life
'THE ANTIDOTE'
Kills ALL known deadly Viruses & Bacteria in the body that keep diseases, namely:
Influenza, SARS, Cancer, HIV etc. etc. active.
http://www.dghsfaes.com/fvd
A disease must be made DORMANT to stop infection.
'The ANTIDOTE' is the answer.
WE ARE THE ONLY COMPANY IN THE WORLD WHO HAVE DEVELOPED AND
ENHANCED THIS PRODUCT FOR SALE.
http://www.dghsfaes.com/fvd
If you cannot access the site it maybe busy due to high demand for this product.
Please try again later in a few hours or the next day.
Nah not for me
http://www.dghsfaes.com/backhome
^ permalink raw reply
* THEY FOUND NEW ANTIDOTE
From: Simon @ 2005-07-20 23:08 UTC (permalink / raw)
To: sparclinux
The Ancient Secret of Life
'THE ANTIDOTE'
Kills ALL known deadly Viruses & Bacteria in the body that keep diseases, namely:
Influenza, SARS, Cancer, HIV etc. etc. active.
http://www.dghsfaes.com/fvd
A disease must be made DORMANT to stop infection.
'The ANTIDOTE' is the answer.
WE ARE THE ONLY COMPANY IN THE WORLD WHO HAVE DEVELOPED AND
ENHANCED THIS PRODUCT FOR SALE.
http://www.dghsfaes.com/fvd
If you cannot access the site it maybe busy due to high demand for this product.
Please try again later in a few hours or the next day.
Nah not for me
http://www.dghsfaes.com/backhome
^ permalink raw reply
* THEY FOUND NEW ANTIDOTE
From: Simon @ 2005-07-20 23:08 UTC (permalink / raw)
To: sparclinux
The Ancient Secret of Life
'THE ANTIDOTE'
Kills ALL known deadly Viruses & Bacteria in the body that keep diseases, namely:
Influenza, SARS, Cancer, HIV etc. etc. active.
http://www.dghsfaes.com/fvd
A disease must be made DORMANT to stop infection.
'The ANTIDOTE' is the answer.
WE ARE THE ONLY COMPANY IN THE WORLD WHO HAVE DEVELOPED AND
ENHANCED THIS PRODUCT FOR SALE.
http://www.dghsfaes.com/fvd
If you cannot access the site it maybe busy due to high demand for this product.
Please try again later in a few hours or the next day.
Nah not for me
http://www.dghsfaes.com/backhome
^ permalink raw reply
* New healing power is here!!!
From: Wilbert @ 2005-07-20 23:08 UTC (permalink / raw)
To: linux-scsi
The Ancient Secret of Life
'THE ANTIDOTE'
Kills ALL known deadly Viruses & Bacteria in the body that keep diseases, namely:
Influenza, SARS, Cancer, HIV etc. etc. active.
http://www.dghsfaes.com/fvd
A disease must be made DORMANT to stop infection.
'The ANTIDOTE' is the answer.
WE ARE THE ONLY COMPANY IN THE WORLD WHO HAVE DEVELOPED AND
ENHANCED THIS PRODUCT FOR SALE.
http://www.dghsfaes.com/fvd
If you cannot access the site it maybe busy due to high demand for this product.
Please try again later in a few hours or the next day.
Nah not for me
http://www.dghsfaes.com/backhome
^ permalink raw reply
* [lm-sensors] Re: [PATCH 2.6] I2C: Separate non-i2c hwmon drivers
From: Jean Delvare @ 2005-07-20 23:04 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, LM Sensors
In-Reply-To: <20050720042622.GC26552@kroah.com>
Hi Greg,
> > +/* Next four are needed by i2c-isa */
> > +EXPORT_SYMBOL(i2c_adapter_dev_release);
> > +EXPORT_SYMBOL(i2c_adapter_driver);
> > +EXPORT_SYMBOL(i2c_adapter_class);
> > +EXPORT_SYMBOL(i2c_bus_type);
>
> EXPORT_SYMBOL_GPL() instead? As these were, core, GPL only symbols
> before you exported them.
Sure, no problem. I would even use EXPORT_SYMBOL_I2C_ISA_ONLY() if it
happened to exist ;)
Updated patch follows, thanks.
Temporarily export a few structures and functions from i2c-core, because we
will soon need them in i2c-isa.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
drivers/i2c/i2c-core.c | 14 ++++++++++----
include/linux/i2c.h | 7 +++++++
2 files changed, 17 insertions(+), 4 deletions(-)
--- linux-2.6.13-rc3.orig/drivers/i2c/i2c-core.c 2005-07-17 20:15:52.000000000 +0200
+++ linux-2.6.13-rc3/drivers/i2c/i2c-core.c 2005-07-20 18:19:46.000000000 +0200
@@ -61,7 +61,7 @@
return rc;
}
-static struct bus_type i2c_bus_type = {
+struct bus_type i2c_bus_type = {
.name = "i2c",
.match = i2c_device_match,
.suspend = i2c_bus_suspend,
@@ -78,13 +78,13 @@
return 0;
}
-static void i2c_adapter_dev_release(struct device *dev)
+void i2c_adapter_dev_release(struct device *dev)
{
struct i2c_adapter *adap = dev_to_i2c_adapter(dev);
complete(&adap->dev_released);
}
-static struct device_driver i2c_adapter_driver = {
+struct device_driver i2c_adapter_driver = {
.name = "i2c_adapter",
.bus = &i2c_bus_type,
.probe = i2c_device_probe,
@@ -97,7 +97,7 @@
complete(&adap->class_dev_released);
}
-static struct class i2c_adapter_class = {
+struct class i2c_adapter_class = {
.name = "i2c-adapter",
.release = &i2c_adapter_class_dev_release,
};
@@ -1171,6 +1171,12 @@
}
+/* Next four are needed by i2c-isa */
+EXPORT_SYMBOL_GPL(i2c_adapter_dev_release);
+EXPORT_SYMBOL_GPL(i2c_adapter_driver);
+EXPORT_SYMBOL_GPL(i2c_adapter_class);
+EXPORT_SYMBOL_GPL(i2c_bus_type);
+
EXPORT_SYMBOL(i2c_add_adapter);
EXPORT_SYMBOL(i2c_del_adapter);
EXPORT_SYMBOL(i2c_add_driver);
--- linux-2.6.13-rc3.orig/include/linux/i2c.h 2005-07-17 20:15:52.000000000 +0200
+++ linux-2.6.13-rc3/include/linux/i2c.h 2005-07-20 18:19:01.000000000 +0200
@@ -34,6 +34,13 @@
#include <linux/device.h> /* for struct device */
#include <asm/semaphore.h>
+/* --- For i2c-isa ---------------------------------------------------- */
+
+extern void i2c_adapter_dev_release(struct device *dev);
+extern struct device_driver i2c_adapter_driver;
+extern struct class i2c_adapter_class;
+extern struct bus_type i2c_bus_type;
+
/* --- General options ------------------------------------------------ */
struct i2c_msg;
--
Jean Delvare
^ permalink raw reply
* [ALSA - firmware 0000209]: Sometimes XMMS stop playing songs (dmix used)
From: bugtrack @ 2005-07-20 23:03 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=209>
======================================================================
Reported By: srr
Assigned To:
======================================================================
Project: ALSA - firmware
Issue ID: 209
Category:
Reproducibility: sometimes
Severity: minor
Priority: normal
Status: new
======================================================================
Date Submitted: 04-14-2004 11:41 CEST
Last Modified: 07-21-2005 01:03 CEST
======================================================================
Summary: Sometimes XMMS stop playing songs (dmix used)
Description:
Sometimes XMMS stop playing songs and show message that says "Audio device
not
properly configured or busy". It happends when new song just start
playing. If I click on Play button, songs continued playing.
I can't repeat this bug, it happends 3-5 times in day.
If i start mpg123 and xmms they are play simultaniously (even if i start
10
copies of mpg123)
This is output from xmms:
ALSA lib pcm_hw.c:1057:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed:
Device
or resource busy
ALSA lib pcm_dmix.c:868:(snd_pcm_dmix_open) unable to open slave
** WARNING **: alsa_setup(): Failed to open pcm device (default): Device
or
resource busy
======================================================================
----------------------------------------------------------------------
tiwai - 01-19-05 16:54
----------------------------------------------------------------------
It's likely a problem of xmms alsa output plugin.
Try the attached patch.
----------------------------------------------------------------------
Steve Fink - 07-21-05 01:03
----------------------------------------------------------------------
I have a very similar problem with mplayer (mplayer-1.0pre3try2). I set the
default device to go through dmix. After some combination of starting and
stopping mplayers (some of them overlap in time), I will end up with an
mplayer that sits and sleeps for half a second, over and over again.
That kind of sucks, but it's an mplayer problem. My real problem is that
then when I start up the next program that uses ALSA (another mplayer, my
application, aplay, or whatever), it gets the "open /dev/snd/pcmC0D0p
failed: Device or resource busy" error.
If I kill the offending mplayer process, it fixes it.
I am using alsa-driver 1.0.8 and alsa-lib 1.0.8. I tried compiling a 1.0.9
(or something calling itself that) and using it, but it didn't help.
Could anyone tell me what sort of thing is happening? I thought that if
everything went through dmix, you should never be able to get into an
EBUSY state. But it seems that the kernel driver is doing something behind
the pcmC?D?p device that can get into this state? (I see similar output
when I have a user play an ALSA sound app, and then try to play something
from the root account. So it does seem like some state is sticking to the
device somehow.) Is there anything that will dump out the state of a
device? Where can I read more about how this all works?
I don't have a simple test script that shows the problem yet. How I
actually see it is that I start up my application (which itself opens up
the pcm device, via SDL with SDL_AUDIODRIVER=alsa), and it forks off an
mplayer (with -ao sdl:alsa). Then I flip rapidly between two different
movies, where each flip kill -TERM's the old mplayer and starts up a new
one. Oddly, every one of these mplayers is able to play sound. Then I shut
down my app, and wait for the mplayers to stop. If I get the bug, which I
do 80% of the time, then one of them will never stop, and when I try to
restart my app (or aplay, or mplayer), it gives me the error message and
fails to play sound.
fuser /dev/snd/pcmC0D0p shows only the mplayer processes (when my app has
exited and there is an mplayer lurking around.)
Issue History
Date Modified Username Field Change
======================================================================
04-14-04 11:41 srr New Issue
04-16-04 11:54 tiwai Note Added: 0000832
04-20-04 07:39 srr Note Added: 0000869
04-20-04 07:41 srr Issue Monitored: srr
10-14-04 22:40 chtephan Note Added: 0002160
10-20-04 20:42 martin Note Added: 0002218
11-28-04 18:33 martin Note Added: 0002626
01-12-05 10:41 leahcim Note Added: 0003161
01-12-05 10:41 leahcim Issue Monitored: leahcim
01-12-05 20:26 Dawid Gajownik Issue Monitored: Dawid Gajownik
01-19-05 16:54 tiwai Note Added: 0003296
01-19-05 16:54 tiwai File Added: xmms-1.2.10-alsa-multithread.diff
07-20-05 17:34 Steve Fink Issue Monitored: Steve Fink
07-21-05 01:03 Steve Fink Note Added: 0005536
======================================================================
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
^ permalink raw reply
* HELP: NFS mount hangs when attempting to copy file
From: Timothy Miller @ 2005-07-20 22:56 UTC (permalink / raw)
To: linux-kernel
My research suggests that NFS client mounting is kernel-based, so
that's why I'm posting here. If there's a more appropriate list to
post to, I apologise, but I am not a list member.
I'm having a bit of a problem doing simple copies over an NFS mount.
The client is running Linux (2.6.11), and the server is running
Solaris (5.8).
When I first boot the client, getting NFS directory listings works
just fine. But the instant I try to copy a file (to or from), the NFS
mount hangs. While I can still do other network activity (even rlogin
to the server), any NFS access I try to do after that point hangs,
including directory listings.
I have had this same client and server working flawlessly for years.
The only change is that the client is now on a VPN (Watchguard SOHO
box). However, I have a Sun machine on the same VPN network segment,
and it can copy files with no problem, so it's not the router/SOHO
that's blocking anything. (NIS and DNS also work just fine for both
machines.)
Also, after it hangs like that, I cannot reboot the machine normally.
When attempting to unmount the network filesystems, the shutdown
hangs, and I have to hard-reset the machine.
Is there anyone who could please help me to debug this problem? As
far as I know, I have NFS setup properly, but I don't know enough
about it to know what options I might try. I don't even care if the
fix degrades performance; I just want it to not hang.
Does anyone have any ideas?
Thanks very much in advance!
^ permalink raw reply
* Re: [uml-devel] compile errors for UMLPPC
From: Jeff Dike @ 2005-07-20 22:53 UTC (permalink / raw)
To: ashwin tanugula; +Cc: user-mode-linux-devel, user-mode-linux-user
In-Reply-To: <838f7c50050720115954d28b25@mail.gmail.com>
On Wed, Jul 20, 2005 at 02:59:34PM -0400, ashwin tanugula wrote:
> Hi,
> I am working on the UML/PPC port and I got the following errors. Can
> anybody tell me how to solve the ptrace_link and ptrace_unlink errors
> in linux/ptrace.h file?
> CC arch/um/util/mk_task_kern.o
> In file included from include/asm/arch/user.h:7,
> from include/asm/processor-i386.h:20,
> from include/asm/processor-generic.h:17,
> from include/asm/processor.h:11,
> from include/asm/thread_info.h:11,
> from include/linux/thread_info.h:21,
> from include/linux/spinlock.h:12,
> from include/linux/capability.h:45,
> from include/linux/sched.h:7,
> from arch/um/util/mk_task_kern.c:1:
First of all, there's something very wrong when you're trying to build
UML/ppc and you're pulling in include/asm/processor-i386.h. Somehow,
your pool is corrupted by a previous i386 build.
Second, this is caused by a recursive include, where include/asm-ppc
is including linux/ptrace.h, which is trying to include sched.h.
We're in the middle of sched.h, so the that include doesn't happen,
but the task struct hasn't been defined yet in the outer sched.h so
the references to it fail.
The fix is to break this include chain somehow (after fixing the
processor-i386 thing). Find one of those includes which is unecessary
(hopefully in UML code) and remove it.
Jeff
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Mortage rates all time low
From: Patrick Guy @ 2005-07-20 22:48 UTC (permalink / raw)
To: er-linux-mm; +Cc: inux-aio
Hello,
We tried contacting you awhile ago about your low interest morta(ge rate.
You have been selected for our lowest rate in years...
You could get over $420,000 for as little as $400 a month!
Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what!
To get a free, no obli,gation consultation click below:
http://www.discounted-rates.com/i/LzMvaW5kZXgvaW5rL3ZnczJ0
Best Regards,
Jana James
to be remov(ed: http://www.discounted-rates.com/i/LzMvaW5kZXgvaW5rL3ZnczJ0
this process takes one week, so please be patient. we do our
best to take your email/s off but you have to fill out a rem/ove
or else you will continue to recieve email/s.
^ permalink raw reply
* Re: amd64 Interbench Results
From: Gabriel Devenyi @ 2005-07-20 22:44 UTC (permalink / raw)
To: Con Kolivas; +Cc: ck, linux-kernel
In-Reply-To: <200507201442.10679.kernel@kolivas.org>
If these are reasonable numbers, is there any methods available to improve the
responsiveness of X? I find I can't get smooth drawing, both scrolling text
(in konsole) and dragging windows around, yields "skips" where the drawing
isn't fluid.
Secondly, what are the suggested settings for preempt in the ck kernel
configuration?
Thanks for your time.
--
Gabriel Devenyi
ace@staticwave.ca
On July 20, 2005 00:42, Con Kolivas wrote:
> On Wed, 20 Jul 2005 12:46 pm, Gabriel Devenyi wrote:
> > I've been using the the -ck patchset for a very long time, and I recently
> > switched to a amd64 arch. I found that while my throughput improved, my
> > system responsiveness has "felt" much lower than it did on my old x86
> > machine.
> >
> > Now that interbench is around, I have some quantitative results. Attached
> > is my interbench results with *nothing* running other than agetty and a
> > single bash console. My system is an AMD Athlon(tm) 64 Processor 3200+,
> > with 1gig DDR400 RAM. Also attached is my kernel config.
> >
> > Seems to me there are some pretty high latencies for such a powerful
> > system, is there anything I can do to improve this? Thanks for all your
> > help.
>
> Those results don't look too bad to me. Absolute numbers don't mean much in
> their own right unless you compare them to something else. Try a vanilla
> kernel and then compare the results side by side.
>
> Cheers,
> Con
^ permalink raw reply
* [PATCH] format-patch: --mbox and --check.
From: Junio C Hamano @ 2005-07-20 22:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vpstdf6rr.fsf@assigned-by-dhcp.cox.net>
Add --mbox option to export patches in a format resembling UNIX
mbox, so that later they can be concatenated and fed to
applymbox.
Add --check to look for lines that introduce bogus whitespaces.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-format-patch-script | 49 +++++++++++++++++++++++++++++++++++++++++------
1 files changed, 43 insertions(+), 6 deletions(-)
b9d503a8a5e3d83059836c939a09d5f6abdf5406
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -4,7 +4,7 @@
#
usage () {
- echo >&2 "usage: $0"' [-n] [-o dir] [-<diff options>...] upstream [ our-head ]
+ echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [-<diff options>...] upstream [ our-head ]
Prepare each commit with its patch since our-head forked from upstream,
one file per patch, for e-mail submission. Each output file is
@@ -16,6 +16,10 @@ the current working directory.
When -n is specified, instead of "[PATCH] Subject", the first line is formatted
as "[PATCH N/M] Subject", unless you have only one patch.
+
+When --mbox is specified, the output is formatted to resemble
+UNIX mailbox format, and can be concatenated together for processing
+with applymbox.
'
exit 1
}
@@ -25,13 +29,19 @@ IFS='
'
LF='
'
-outdir=./
+outdir=./
while case "$#" in 0) break;; esac
do
case "$1" in
+ -a|--a|--au|--aut|--auth|--autho|--author)
+ author=t ;;
+ -c|--c|--ch|--che|--chec|--check)
+ check=t ;;
-d|--d|--da|--dat|--date)
date=t ;;
+ -m|--m|--mb|--mbo|--mbox)
+ date=t author=t mbox=t ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
-o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
@@ -71,6 +81,7 @@ trap 'rm -f $tmp-*' 0 1 2 3 15
series=$tmp-series
commsg=$tmp-commsg
+filelist=$tmp-files
titleScript='
/./d
@@ -115,16 +126,27 @@ do
file=`printf '%04d-%stxt' $i "$title"`
i=`expr "$i" - 1`
- echo "$file"
+ echo >&2 "* $file"
{
mailScript='
/./d
/^$/n
- s|^\[PATCH[^]]*\] *||
- s|^|[PATCH'"$num"'] |'
+ s|^\[PATCH[^]]*\] *||'
+
+ case "$mbox" in
+ t)
+ echo 'From nobody Mon Sep 17 00:00:00 2001' ;# UNIX "From" line
+ mailScript="$mailScript"'
+ s|^|Subject: [PATCH'"$num"'] |'
+ ;;
+ *)
+ mailScript="$mailScript"'
+ s|^|[PATCH'"$num"'] |'
+ ;;
+ esac
eval "$(sed -ne "$whosepatchScript" $commsg)"
- test "$au" = "$me" || {
+ test "$author,$au" = ",$me" || {
mailScript="$mailScript"'
a\
From: '"$au"
@@ -147,5 +169,20 @@ Date: '"$ad"
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
echo
git-diff-tree -p $diff_opts "$commit" | sed -e "$stripCommitHead"
+
+ case "$mbox" in
+ t)
+ echo
+ ;;
+ esac
} >"$outdir$file"
+ case "$check" in
+ t)
+ # This is slightly modified from Andrew Morton's Perfect Patch.
+ # Lines you introduce should not have trailing whitespace.
+ # Also check for an indentation that has SP before a TAB.
+ grep -n '^+\([ ]* .*\|.*[ ]\)$' "$outdir$file"
+
+ : do not exit with non-zero because we saw no problem in the last one.
+ esac
done <$series
^ permalink raw reply
* RE: OLS meeting with ATI about BIOS & PM
From: Hui Yu @ 2005-07-20 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Patrick Mochel
Cc: Linux-pm mailing list, Pavel Machek
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
Tomorrow or Friday? Sounds good to me anyway. Michel and I will be
there.
Hui
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Wednesday, July 20, 2005 5:38 PM
> To: Patrick Mochel
> Cc: Linux-pm mailing list; Len Brown; Pavel Machek; Hui Yu
> Subject: Re: OLS meeting with ATI about BIOS & PM
>
> On Wed, 2005-07-20 at 14:25 -0700, Patrick Mochel wrote:
> >
> >
> > On Wed, 20 Jul 2005, Benjamin Herrenschmidt wrote:
> >
> > > PM folks at OLS, can we schedule some time tomorrow or Friday to
talk
> > > with Hui Yu from ATI ?
> >
> > How about 1:30, and we can meet in the basement?
>
> Works for me, Hui i that ok with you ?
>
> Ben.
>
>
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [uml-devel] compile errors for UMLPPC
From: Blaisorblade @ 2005-07-20 22:37 UTC (permalink / raw)
To: user-mode-linux-devel, ashwin tanugula; +Cc: user-mode-linux-user
In-Reply-To: <838f7c50050720115954d28b25@mail.gmail.com>
On Wednesday 20 July 2005 20:59, ashwin tanugula wrote:
> Hi,
> I am working on the UML/PPC port and I got the following errors. Can
> anybody tell me how to solve the ptrace_link and ptrace_unlink errors
> in linux/ptrace.h file?
Well, you should add, before the offending lines, the inclusion of the missing
header which is needed for that code.
I.e. if that's using a member of task_struct, then you need to include the
definition of task_struct, which is in <linux/sched.h>.
If that is already included, then it means that you have a ciclic dependency
chain; for instance, sched.h includes ptrace.h at its beginning, before
declaring task_struct, and then ptrace.h includes sched.h because it needs
it; but the content of sched.h is going to be skipped because of the "double
inclusion" guard (_LINUX_SCHED_H will have already been defined).
> root@slemieux:/home/ashwin/Desktop/ashwin/linux-2.6.0-test9 # make linux
> ARCH=um CHK include/linux/version.h
> UPD include/linux/version.h
> SYMLINK include/asm -> include/asm-um
> HOSTCC scripts/genksyms/genksyms.o
> SHIPPED scripts/genksyms/lex.c
> SHIPPED scripts/genksyms/parse.h
> SHIPPED scripts/genksyms/keywords.c
> HOSTCC scripts/genksyms/lex.o
> SHIPPED scripts/genksyms/parse.c
> HOSTCC scripts/genksyms/parse.o
> HOSTLD scripts/genksyms/genksyms
> HOSTCC scripts/split-include
> HOSTCC scripts/conmakehash
> HOSTCC scripts/docproc
> HOSTCC scripts/kallsyms
> CC scripts/empty.o
> HOSTCC scripts/mk_elfconfig
> MKELF scripts/elfconfig.h
> HOSTCC scripts/file2alias.o
> HOSTCC scripts/modpost.o
> HOSTLD scripts/modpost
> HOSTCC scripts/pnmtologo
> HOSTCC scripts/bin2c
> SPLIT include/linux/autoconf.h -> include/config/*
> sed 's/ CONFIG/ UML_CONFIG/'
> /home/ashwin/Desktop/ashwin/linux-2.6.0-test9/include/linux/autoconf.h
>
> > arch/um/include/uml-config.h
>
> make -f scripts/Makefile.build obj=arch/um/util
> gcc -o arch/um/util/mk_task_user.o -c arch/um/util/mk_task_user.c
> CC arch/um/util/mk_task_kern.o
> In file included from include/asm/arch/user.h:7,
> from include/asm/processor-i386.h:20,
> from include/asm/processor-generic.h:17,
> from include/asm/processor.h:11,
> from include/asm/thread_info.h:11,
> from include/linux/thread_info.h:21,
> from include/linux/spinlock.h:12,
> from include/linux/capability.h:45,
> from include/linux/sched.h:7,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/ptrace.h: In function `ptrace_link':
> include/linux/ptrace.h:88: error: dereferencing pointer to incomplete type
> include/linux/ptrace.h: In function `ptrace_unlink':
> include/linux/ptrace.h:93: error: dereferencing pointer to incomplete type
> In file included from include/asm/arch/semaphore.h:21,
> from include/asm/semaphore.h:4,
> from include/linux/sched.h:18,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/wait.h: At top level:
> include/linux/wait.h:83: warning: `regparm' attribute directive ignored
> include/linux/wait.h:84: warning: `regparm' attribute directive ignored
> include/linux/wait.h:85: warning: `regparm' attribute directive ignored
> include/linux/wait.h:107: warning: `regparm' attribute directive ignored
> include/linux/wait.h:108: warning: `regparm' attribute directive ignored
> include/linux/wait.h:109: warning: `regparm' attribute directive ignored
> include/linux/wait.h:228: warning: `regparm' attribute directive ignored
> include/linux/wait.h:229: warning: `regparm' attribute directive ignored
> include/linux/wait.h:231: warning: `regparm' attribute directive ignored
> include/linux/wait.h:232: warning: `regparm' attribute directive ignored
> include/linux/wait.h:238: warning: `regparm' attribute directive ignored
> include/linux/wait.h:240: warning: `regparm' attribute directive ignored
> include/linux/wait.h:242: warning: `regparm' attribute directive ignored
> In file included from include/linux/rwsem.h:25,
> from include/asm/arch/semaphore.h:22,
> from include/asm/semaphore.h:4,
> from include/linux/sched.h:18,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/rwsem-spinlock.h:55: warning: `regparm' attribute
> directive ignoredinclude/linux/rwsem-spinlock.h:56: warning: `regparm'
> attribute directive ignoredinclude/linux/rwsem-spinlock.h:57: warning:
> `regparm' attribute directive
> ignoredinclude/linux/rwsem-spinlock.h:58: warning: `regparm' attribute
> directive ignoredinclude/linux/rwsem-spinlock.h:59: warning: `regparm'
> attribute directive ignoredinclude/linux/rwsem-spinlock.h:60: warning:
> `regparm' attribute directive
> ignoredinclude/linux/rwsem-spinlock.h:61: warning: `regparm' attribute
> directive ignoredinclude/linux/rwsem-spinlock.h:62: warning: `regparm'
> attribute directive ignoredIn file included from
> include/linux/sched.h:23,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/smp.h:33: warning: `regparm' attribute directive ignored
> In file included from include/linux/sched.h:29,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/completion.h:30: warning: `regparm' attribute directive
> ignored include/linux/completion.h:31: warning: `regparm' attribute
> directive ignored include/linux/completion.h:32: warning: `regparm'
> attribute directive ignored In file included from include/linux/sched.h:30,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/pid.h:36: warning: `regparm' attribute directive ignored
> include/linux/pid.h:38: warning: `regparm' attribute directive ignored
> include/linux/pid.h:43: warning: `regparm' attribute directive ignored
> include/linux/pid.h:49: warning: `regparm' attribute directive ignored
> include/linux/pid.h:52: warning: `regparm' attribute directive ignored
> In file included from include/linux/slab.h:15,
> from include/linux/percpu.h:4,
> from include/linux/sched.h:31,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/gfp.h:66: warning: `regparm' attribute directive ignored
> include/linux/gfp.h:80: warning: `regparm' attribute directive ignored
> include/linux/gfp.h:81: warning: `regparm' attribute directive ignored
> include/linux/gfp.h:89: warning: `regparm' attribute directive ignored
> include/linux/gfp.h:90: warning: `regparm' attribute directive ignored
> include/linux/gfp.h:91: warning: `regparm' attribute directive ignored
> include/linux/gfp.h:92: warning: `regparm' attribute directive ignored
> In file included from include/linux/percpu.h:4,
> from include/linux/sched.h:31,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/slab.h:103: warning: `regparm' attribute directive ignored
> In file included from arch/um/util/mk_task_kern.c:1:
> include/linux/sched.h:175: warning: `regparm' attribute directive ignored
> In file included from include/linux/aio.h:5,
> from include/linux/sched.h:183,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/workqueue.h:55: warning: `regparm' attribute directive
> ignored include/linux/workqueue.h:56: warning: `regparm' attribute
> directive ignored include/linux/workqueue.h:57: warning: `regparm'
> attribute directive ignored include/linux/workqueue.h:59: warning:
> `regparm' attribute directive ignored include/linux/workqueue.h:60:
> warning: `regparm' attribute directive ignored In file included from
> include/linux/sched.h:183,
> from arch/um/util/mk_task_kern.c:1:
> include/linux/aio.h:143: warning: `regparm' attribute directive ignored
> include/linux/aio.h:144: warning: `regparm' attribute directive ignored
> include/linux/aio.h:145: warning: `regparm' attribute directive ignored
> include/linux/aio.h:146: warning: `regparm' attribute directive ignored
> include/linux/aio.h:147: warning: `regparm' attribute directive ignored
> include/linux/aio.h:149: warning: `regparm' attribute directive ignored
> include/linux/aio.h:151: warning: `regparm' attribute directive ignored
> include/linux/aio.h:156: warning: `regparm' attribute directive ignored
> In file included from arch/um/util/mk_task_kern.c:1:
> include/linux/sched.h:574: warning: `regparm' attribute directive ignored
> include/linux/sched.h:575: warning: `regparm' attribute directive ignored
> include/linux/sched.h:576: warning: `regparm' attribute directive ignored
> include/linux/sched.h:577: warning: `regparm' attribute directive ignored
> include/linux/sched.h:578: warning: `regparm' attribute directive ignored
> include/linux/sched.h:668: warning: `regparm' attribute directive ignored
> include/linux/sched.h:743: warning: `regparm' attribute directive ignored
> include/linux/sched.h:871: warning: `regparm' attribute directive ignored
> make[1]: *** [arch/um/util/mk_task_kern.o] Error 1
> make: *** [arch/um/util] Error 2
>
> Thanks in advance
>
> --Ashwin
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=Click
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: kernel guide to space
From: Krzysztof Halasa @ 2005-07-20 22:37 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Michael S. Tsirkin, linux-kernel
In-Reply-To: <9a87484905072005596f2c2b51@mail.gmail.com>
Jesper Juhl <jesper.juhl@gmail.com> writes:
> I don't think that's a hard rule, there's plenty of code that does
> "sizeof(type)" and not "sizeof (type)", and whitespace cleanup
> patches I've done that change "sizeof (type)" into "sizeof(type)" have
> generally been accepted.
Sure, the common rule is that function names and alike (including "sizeof")
are not followed by a space. Statements such as "if", "while" etc. - are.
--
Krzysztof Halasa
^ permalink raw reply
* IA64 Server / IA32 Client Problem
From: Brett Petrusek @ 2005-07-20 22:37 UTC (permalink / raw)
To: nfs
I'm not sure if this is a bug or what, but I am experiencing severe
performace problems between an IA64 NFS server and IA32 NFS client. I
have tried every combination of socket buffer sizes as well as many
other nfs options, but none of them seem to have any effect. I have
tried RHEL21 to RHEL3U5 with all of these socket combos and still no
difference. The command I am running is:
time dd if=/dev/zero of=/scratch_dir_across_nfs bs=1M count=128
Between two IA32 machines this takes 4-5 seconds. Between IA64 server
and IA32 client this takes on the order of minutes. Network performance
has been eliminated from the equation as after kernel tuning we have
achieved consistent 94% of peak tcp throughput and 95.7% of peak udp
throughput on our GigE network. This is both between IA32 and IA64
systems.
Let me know if there is an other info I should provide to help
troubleshoot this problem.
Any help is appreciated.
Thanks, Brett P
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Simulator bootloader fails with gcc 4
From: James E Wilson @ 2005-07-20 22:34 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <20050720053139.GC13188@cse.unsw.EDU.AU>
On Tue, 2005-07-19 at 22:31, Ian Wienand wrote:
> After some investigation I believe this is do with differences between
> the alignment of variables on the stack between gcc 3 and 4 and the
> ski simulator.
There has been no change to the natural alignment for the variable
here. It has always been 4 bytes. There has been a change to the
placement of variables into stack slots. This stuff was completely
written as part of the tree-ssa work.
If gcc-3.4 and earlier, some structures (BLKmode structures) were being
over-aligned when allocated to stack slots. They always got the maximum
alignment (16 bytes for IA-64) instead of their natural alignment. It
isn't clear why. I think this was an accident of implementation. We
were basing variable alignment on modes instead of type alignment, and
since some BLKmode structures do require max alignment, we had to give
it to all of them.
In gcc-4.0, we get this right. The variable/type alignment is used to
determine the stack alignment needed. If the alignment is less than the
stack slot size, then we don't pad to the next stack slot regardless of
the size or type or mode of the variable. We only pad to the alignment
boundary. This results in smaller frame sizes. In this case though, we
end up with the structure being allocated across two stack slots, even
though it would fit in one. Again, I think this is an accident of
implementation. We might get better code if this structure was
allocated to a single stack slot, as then we could use ld8/st8 to move
it around. This would be at the expense of a small increase in frame
size in general, though we would still have smaller frames than gcc-3.4
and earlier. Probably no one has considered this issue because no one
has noticed it before.
^ 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.