* Re: [PATCH] set_cpus_allowed() for 2.4
From: Christoph Hellwig @ 2002-12-14 4:55 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel
In-Reply-To: <20021213213458.GG4817@fs.tum.de>
On Fri, Dec 13, 2002 at 10:34:59PM +0100, Adrian Bunk wrote:
> On Fri, Dec 13, 2002 at 06:08:14PM -0500, Christoph Hellwig wrote:
>
> >...
> > now that all vendors ship a backport of Ingo's O(1) scheduler, external
> >...
>
> #include <all-vendors-except-Debian> ;-)
OOPS, I reused the first template again. I think I owe you a beer :)
^ permalink raw reply
* Re: [BK][PATCH] ReiserFS CPU and memory bandwidth efficient large writes
From: Andrew Morton @ 2002-12-13 21:40 UTC (permalink / raw)
To: Hans Reiser; +Cc: Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <3DFA2D4F.3010301@namesys.com>
Hans Reiser wrote:
> ..
> These three changesets implement reiserfs_file_write.
What a big patch.
I'd be interested in testing it a bit. Could you please
describe under what circumstances the new code paths are
executed? Is it simply appending to a normal old file? No
special mount options?
A few little comments, and maybe a security problem....
> +int reiserfs_can_fit_pages ( struct super_block *sb /* superblock of filesystem
> + to estimate space */ )
> +{
> + unsigned long space;
> +
> + spin_lock(&REISERFS_SB(sb)->bitmap_lock);
> + space = (SB_FREE_BLOCKS(sb) - REISERFS_SB(sb)->reserved_blocks) / ( PAGE_CACHE_SIZE/sb->s_blocksize);
> + spin_unlock(&REISERFS_SB(sb)->bitmap_lock);
> +
> + return space;
> }
Both of the divisions here can be replaced with shifts. Divides are expensive.
The locking here is peculiar:
spin_lock(lock);
value = calculation();
spin_unlock(lock);
return value;
Surely, if the calculation relies on the lock then the returned value is invalidated
as soon as you drop the lock?
> - offset = le_ih_k_offset( ih ) + (old_len - tb->rbytes );
> + offset = le_ih_k_offset( ih ) + (old_len - tb->rbytes )*(is_indirect_le_ih(ih)?tb->tb_sb->s_blocksize/UNFM_P_SIZE:1);
Can use a shift.
> + if (is_indirect_le_key(version,B_N_PKEY(tb->R[0],0))){
> + temp_rem = (n_rem / UNFM_P_SIZE) *
> + tb->tb_sb->s_blocksize;
Shift by i_blkbits (all over the place)
> +/* this function from inode.c would be used here, too */
> +extern void restart_transaction(struct reiserfs_transaction_handle *th,
> + struct inode *inode, struct path *path);
This decl should be in a header file.
> +
> +/* I really do not want to play with memory shortage right now, so
> + to simplify the code, we are not going to write more than this much pages at
> + a time. This still should considerably improve performance compared to 4k
> + at a time case. */
> +#define REISERFS_WRITE_PAGES_AT_A_TIME 32
Page sizes vary. A better value may be
(128 * 1024) / PAGE_CACHE_SIZE
so that consistent behaviour is seem on platforms which have page sizes larger
than 4k.
> +int reiserfs_allocate_blocks_for_region(
> ...
> + b_blocknr_t allocated_blocks[blocks_to_allocate]; // Pointer to a place where allocated blocknumbers would be stored. Right now statically allocated, later that will change.
This is a variable-sized array (aka: alloca). It's not a problem IMO, but
worth pointing out...
> + reiserfs_blocknr_hint_t hint; // hint structure for block allocator.
> + size_t res; // return value of various functions that we call.
> + int curr_block; // current block used to keep track of unmapped blocks.
> + int i; // loop counter
> + int itempos; // position in item
> + unsigned int from = (pos & (PAGE_CACHE_SIZE - 1)); // writing position in
> + // first page
> + unsigned int to = ((pos + write_bytes - 1) & (PAGE_CACHE_SIZE - 1)) + 1; /* last modified byte offset in last page */
> + __u64 hole_size ; // amount of blocks for a file hole, if it needed to be created.
> + int modifying_this_item = 0; // Flag for items traversal code to keep track
> + // of the fact that we already prepared
> + // current block for journal
How much stack is this function using, worst-case?
> + for ( i = 0; i < num_pages; i++) {
> + prepared_pages[i] = grab_cache_page(mapping, index + i); // locks the page
OK. But note that locking multiple pages here is only free from AB/BA deadlocks
because this is the only path which does it, and it is singly-threaded via i_sem.
> + if ( from != 0 ) {/* First page needs to be partially zeroed */
> + char *kaddr = kmap_atomic(prepared_pages[0], KM_USER0);
> + memset(kaddr, 0, from);
> + kunmap_atomic( kaddr, KM_USER0);
> + SetPageUptodate(prepared_pages[0]);
> + }
> + if ( to != PAGE_CACHE_SIZE ) { /* Last page needs to be partially zeroed */
> + char *kaddr = kmap_atomic(prepared_pages[num_pages-1], KM_USER0);
> + memset(kaddr+to, 0, PAGE_CACHE_SIZE - to);
> + kunmap_atomic( kaddr, KM_USER0);
> + SetPageUptodate(prepared_pages[num_pages-1]);
> + }
This seems wrong. This could be a newly-allocated pagecache page. It is not
yet fully uptodate. If (say) the subsequent copy_from_user gets a fault then
it appears that this now-uptodate pagecache page will leak uninitialised stuff?
> + set_bit(BH_Uptodate, &bh->b_state);
set_buffer_uptodate(bh) is more conventional (two instances).
> + /* We need to mark new file size in case this function will be
> + interrupted/aborted later on. And we may do this only for
> + holes. */
> + inode->i_size += inode->i_sb->s_blocksize * blocks_needed;
64-bit multiply, should be a shift.
^ permalink raw reply
* Re: [Printing-architecture] Lower level diagram update (bidi update)
From: Michael Sweet @ 2002-12-13 21:30 UTC (permalink / raw)
To: Pete Zannucci; +Cc: printing-architecture, toratani.yasumasa
In-Reply-To: <OFC9AAF355.096AA195-ON85256C8E.006B3739@pok.ibm.com>
Pete Zannucci wrote:
> ...
> Capabilities is another subject altogether. Since using .ppd
> files is the current implementation under CUPS, nobody has
> really started to discuss how to tie in dynamic capabilities
> from either a printer or a driver into the system.
Actually, several vendors have implemented this within CUPS by
actually updating the PPD file on-the-fly with the current
printer configuration. The interface is straight-forward and
allows for a (relatively) small static representation of the
current capabilities which provides extremely fast access to
the information with little overhead. Updates can be made
asynchronously via background processes or at print time.
> ...
> It would be nice if our solution didn't need to have multiple
> drivers configured between systems and worry about keeping them
> all in sync. if wanted to get the properties in a networked
> environment. This will likely be up for debate when we start
> working out the issue of client vs. server side rendering though.
One of CUPS's major "selling" points is that the clients don't
maintain a local copy of the printer configuration, just the
basic information (URI, name, description, location, make/model,
type) to allow the user to choose the printer. The client then
grabs the current PPD file for the printer via HTTP and/or gets
additional IPP attributes directly from the server for that printer
queue.
Another advantage of this architecture is that it can also support
client-side rendering assuming that client has the driver programs
locally installed - the PPD file determines what filters are run
and how they interact with the device. Unfortunately, client-
side rendering does not allow for bidirectional communications
with the printer, and that is something we will *not* be adding
to CUPS for (obvious) security reasons, so the client-side rendering
might be limited to the PS/PDF/image RIP'ing, although the overhead
of transferring raster data over the network is prohibitive...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike@easysw.com
Printing Software for UNIX http://www.easysw.com
^ permalink raw reply
* Re: [PATCH] set_cpus_allowed() for 2.4
From: Adrian Bunk @ 2002-12-13 21:34 UTC (permalink / raw)
To: Christoph Hellwig, linux-kernel
In-Reply-To: <20021213180814.A2658@sgi.com>
On Fri, Dec 13, 2002 at 06:08:14PM -0500, Christoph Hellwig wrote:
>...
> now that all vendors ship a backport of Ingo's O(1) scheduler, external
>...
#include <all-vendors-except-Debian> ;-)
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: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Doug Ledford @ 2002-12-13 21:23 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-scsi
In-Reply-To: <20021213210215.A15074@infradead.org>
On Fri, Dec 13, 2002 at 09:02:15PM +0000, Christoph Hellwig wrote:
> On Thu, Dec 12, 2002 at 03:20:52PM -0500, Doug Ledford wrote:
> > On Wed, Dec 11, 2002 at 06:17:46PM +0000, Christoph Hellwig wrote:
> > >
> > > Yupp, it currently crashes when I have both compiled in. Dough, any chance
> > > you could fix that? A PCI driver is not supposed to stop over already
> > > claimed device.
> >
> > If you've got a test machine, the attached patch would I think fix the
> > problem. Let me know if it does in fact work for you and I'll commit it
> > to the tree.
>
> Still doesn't work. I think you really need to set and check the driver
> field like justin suggested.
Hmmm...what's the failure mode here? And if it doesn't work this way,
then how's it ever suppossed to work on the non-PCI controllers both of
our modules support since last I knew, you never get called by the pci hot
plug core on non-PCI controllers so the lockout method between our drivers
can *not* be pci specific and still work in all cases. The request_region
stuff always was and still is the only truly generic io space protection
mechanism that works on all devices on all busses.
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
^ permalink raw reply
* Serial Console Problem
From: David Rees @ 2002-12-13 21:21 UTC (permalink / raw)
To: linux-kernel
Not sure if this is quite on topic for linux-kernel but I couldn't find
answers anywhere else so here goes:
I've got a couple systems where I've configured ttyS0 as a serial
console. Everything works fine when a cable is plugged in and a
terminal is listening on the other side. The kernel in question is
2.4.20.
However, unplugging the cable and rebooting results in the boot process
hanging. It appears that the kernel is waiting for the serial port
acknoledge the fact that it is writing data.
What's strange is that this is a problem on one machine, but doesn't
appear to be a problem on another.
Anyone have any ideas on how to work around this issue besides leaving a
terminal hooked up all the time?
-Dave
^ permalink raw reply
* mmap() and NFS server performance
From: Matthew Mitchell @ 2002-12-13 21:09 UTC (permalink / raw)
To: nfs
Hello,
We've noticed some interesting behavior regarding mmap file IO and were
wondering if anyone here had some clues as to what might be going on.
We have some applications that mmap() files into memory for the purpose
of updating some potentially scattered word-sized data values. These
apps were originally written on Solaris with Solaris NFS servers assumed
to be the data source; the Sun guys said that mmap would be much faster
than read/write and they were correct. However, now that we have a few
Linux NFS servers, we're seeing the opposite.
It takes, for example, 20-24 hours to update a 2GB file (there are on
the order of 1M words to update) via mmap, whereas reading in the whole
file, updating it in memory, and writing it out again takes about 30
minutes (limited by network speed in our case). This when the file
resides on the Linux server. On Solaris the mmap update runs on the
order of 15-20 minutes. Client in both cases is a Solaris 8 machine.
What we are speculating is that the Solaris NFS server is "cheating" by
keeping file state information between NFS reads and writes. (The
updates do occur in sequence.) Are there any heuristics or
optimizations done by the Linux NFS server that might help the
performance here?
All things, alas, are not equal in this comparison -- the Solaris server
in question is an 8 CPU Enterprise 4500 with 8GB of RAM, and the Linux
server is a single-processor P4 with 512MB of RAM. The Solaris server
is much busier than the Linux server, though (I know it cannot be
caching the whole file in memory). The Linux server is running Red
Hat's 2.4.18-14 kernel.
Anyone have any ideas as to why this is happening and what, if anything,
we can do to speed up the mmap IO when using the Linux server?
--
Matthew Mitchell
Systems Programmer/Administrator matthew@geodev.com
Geophysical Development Corporation phone 713 782 1234
1 Riverway Suite 2100, Houston, TX 77056 fax 713 782 1829
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Networking/Becker et al [was Re: pci-skeleton duplex check]
From: Jeff Garzik @ 2002-12-13 21:19 UTC (permalink / raw)
To: Larry McVoy
Cc: Donald Becker, David S. Miller, Roger Luethi, netdev,
Linux Kernel Mailing List
In-Reply-To: <20021213092229.D9973@work.bitmover.com>
Larry McVoy wrote:
> Don is a careful, thoughtful guy. He is quite conservative when it comes
> to programming. His style most closely matches the Sun kernel style of
> development; it does not match the Linux style at all. The Linux style
> is a lot more free wheeling, stuff changes a lot and the kernel team
> depends heavily on the fact that it is has this vast army of free testers.
> Without that army, I shudder to think what things would be like, I do not
> think the current development style would work anywhere near as well.
>
> But it does work, and it violates a lot of engineering disciplines that
> old farts, like me and Don, respect. I've learned to live with it, even
> respect the fact that the Linux team does so well. Don is having a much
> tougher time. He really wants the Linux team to work more like he works
> and the Linux team doesn't want to do that at all, they point at their
> success and believe that their development style is part of that success.
This meshes with what I've observed, too...
I'm not sure which is the bigger issue, Don's devel style versus Linux
devel style, or use of kernel APIs, but both I think cut to the core of
the differences in this situation.
> It is worth putting on the record that Don has done a lot for the Linux
> effort, a huge amount, in fact. Without Don, Linux would be dramatically
> less far along than it is. I've been here since before it had networking
> and it really took off when Don started writing drivers.
I give him a lot of credit too, though it's often in the way of trying
to apply lessons learned from him to current net drivers and such.
> It's also pointing out that I think he's right about the networking
> regressions, suspend/resume on laptops used to work and now the network
> is almost always hosed after I do that.
suspend/resume in Linux has always been a hack, and will continue to be
until the 2.5.x sysfs/device model is fully fleshed out. Specifically
for 2.4.x, let me know if your net driver doesn't suspend/resume
correctly. The cases I've tested work fine. Make sure your distro is
properly calling the /sbin/hotplug agent when suspend/resume occurs though.
> I doubt that either side is likely to change their view. But, the real
> point is how to we get Don's brain engaged on the kernel networking
> drivers? A few thoughts:
>
> a) Don is going to have to accept that the Linux kernel approach is
> the way it is. Sitting on the sidelines and whining is not going
> to change how the kernel is developed. Either get with the
> program or not, but don't sit there and complain but refuse
> to work the way the rest of the people work.
indeed... central problem
> b) The kernel folks need to listen to Don more. Draw him into the
> conversations about interface changes, try and extract the
> knowledge he has, it's worth it. Not doing so just means you
> are wasting time.
I try to do this, and I can point to many specific instances in the past
when he's been very helpful.
I would love to get Don more involved in interface discussions though...
typically where he pops up [where I see him] is more in the area of
hardware experience and knowledge than interface discussions.
> c) Don needs to kill those mailing lists he maintains or merge them
> with the appropriate kernel lists. That is a big part of the
> problem, the interesting stuff seems to be happening over in
> Don's part of the world and the mainstream kernel team isn't
> aware of it.
This is really a matter of getting his driver changes into the kernel,
too... Some mailing list users [not me] would probably complain about
seeing support traffic for drivers that are not in the kernel.
> d) Beer. More beer. Much more beer and some face time. If there
> is a tech conference coming up, I think we should get Don to
> come and give him the first lifetime achievement award for
> Linux kernel development. Then shove him and the other network
> hackers into a room with a keg and not let them out until they
> are smiling. BitMover will kick in some money towards this if
> needed.
mmmmmmm, beer :)
^ permalink raw reply
* Re: The Parallel port API- I need to write a device driver...!
From: Adrian Bunk @ 2002-12-13 21:17 UTC (permalink / raw)
To: Dean McEwan; +Cc: linux-kernel, dean_mcewan
In-Reply-To: <JJKENKGENPBHAAAA@whowhere.com>
On Fri, Dec 13, 2002 at 01:13:04PM +0000, Dean McEwan wrote:
> Where can I find information on how to write a
> parallel port driver for a device im working on that
> needs to connect to a parallel port, I don't want
> to write a driver for the parallel port just the device
> that uses it.
>...
cd path_to_your_kernel_source
make psdocs # "htmldocs" and "pdfdocs" are available, too
gv Documentation/DocBook/parportbook.ps
> --- Cheers, Dean.
HTH
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: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Christoph Hellwig @ 2002-12-13 21:06 UTC (permalink / raw)
To: Jens Axboe; +Cc: Justin T. Gibbs, James Bottomley, linux-scsi
In-Reply-To: <20021212173818.GA6481@suse.de>
On Thu, Dec 12, 2002 at 06:38:18PM +0100, Jens Axboe wrote:
> > 1) You have to set a flag when you've already told the system you
> > dma capabilities.
>
> All drivers blindly copy the setting of the dma mask, typically means
> nothing.
Maybe it's a bit to dangerous for 2.4, but for 2.5 Justin's suggestion
looks very nice, IMHO.
> > 2) That flag is not documented in hosts.h or in the Documentation directory.
>
> That is true. Name of the member is a good clue, though.
Hmm, actually I documented it at some point, I just can't remember
in what tree that was..
> > 4) highio requires that all SCSI drivers support single length S/G lists,
> > but since single buffers are still allowed by the interfaces, even
> > compliant SCSI drivers cannot strip out this code.
>
> This is not a new requirement, it's just spelled out now. The special
> casing of an sg request with one entry was silly, imho. And yes you do
> have to support both single entry sg requests and non-sg requests. I
> wouldn't mind getting rid of that, but this is the 2.4 series and
> changes must be kept small(ish).
IIRC Alan planned to kill non-sg requests for 2.5. But I don't know how
far he got.
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Christoph Hellwig @ 2002-12-13 21:02 UTC (permalink / raw)
To: linux-scsi
In-Reply-To: <20021212202052.GC8842@redhat.com>
On Thu, Dec 12, 2002 at 03:20:52PM -0500, Doug Ledford wrote:
> On Wed, Dec 11, 2002 at 06:17:46PM +0000, Christoph Hellwig wrote:
> >
> > Yupp, it currently crashes when I have both compiled in. Dough, any chance
> > you could fix that? A PCI driver is not supposed to stop over already
> > claimed device.
>
> If you've got a test machine, the attached patch would I think fix the
> problem. Let me know if it does in fact work for you and I'll commit it
> to the tree.
Still doesn't work. I think you really need to set and check the driver
field like justin suggested.
^ permalink raw reply
* 2.5.51 fixed mouse & keyboard in X
From: Murray J. Root @ 2002-12-13 21:01 UTC (permalink / raw)
To: linux-kernel
Since 2.5.4<something> my mouse and keyboard would get lost when
starting X.
Fixed in 2.5.51
(Haven't tried to see what fixed it - no time)
--
Murray J. Root
------------------------------------------------
DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/
------------------------------------------------
Mandrake on irc.freenode.net:
#mandrake & #mandrake-linux = help for newbies
#mdk-cooker = Mandrake Cooker
^ permalink raw reply
* [PATCH] Minor fixes (was Re: [PATCH] S4Bios support for 2.4.20 + acpi-20021205)
From: Ducrot Bruno @ 2002-12-13 20:52 UTC (permalink / raw)
To: Nils Faerber; +Cc: Ducrot Bruno, acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <20021213210359.266e4417.nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]
On Fri, Dec 13, 2002 at 09:03:59PM +0100, Nils Faerber wrote:
> On Fri, 13 Dec 2002 20:17:58 +0100
> Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> > On Fri, Dec 13, 2002 at 07:49:07PM +0100, Nils Faerber wrote:
> > [...]
> > > My result:
> > > S4BIOS_REQ: 0x00
> > >
> > > > For ./acpidmp FACS | ./acpitbl:
> > > > Flags have bit 0 set.
> > >
> > > Signature: FACS
> > > Length: 64
> > > Hardware Signature: 0x00000000
> > > Firmware Waking Vector: 0x00000000
> > > Global Lock: 0x00000000
> > > Flags: 0x00000000
> > >
> > > Hmm ... and now?
> > > What does that mean?
> > Your BIOS cry loudly that it do not support S4Bios (certainly due
> > to a lack of a suspend partition). I supposed that my patch does it
> > right, so that if someone insist, it give up, but that is not the
> > case. I have to look what stupid brain-damaged bogosity I have written
> > then.
>
> Oh well, many thanks again!
> I already thought something like this.
> Now, this just leaves the question what f*ckin' type of partition this
> BIOS wants. I already tried almost everything: lphdisk, zvhdd (DOS
> utility), simple VFAT32 partition, nothing. Oh well ... mybe I'll
> disassemble the BIOS - just joking :) I think best bet would be to ask
> Asus for a hint.
>
This incremental patch should give you the oportunity to not go to s4bios
if bios do not support. It fix also a printk introduced by me (sorry).
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
[-- Attachment #2: 00_system_fix_s4bios-2.4.20-acpi-20021205.diff --]
[-- Type: text/plain, Size: 1947 bytes --]
--- linux-2.4.20/drivers/acpi/system.c 2002/12/13 20:15:23 1.2
+++ linux-2.4.20/drivers/acpi/system.c 2002/12/13 20:43:18
@@ -300,11 +300,16 @@
return AE_ERROR;
- /* For s4bios, we need a wakeup address. */
- if (state == ACPI_STATE_S4) {
- if (!acpi_wakeup_address)
+ if (ACPI_STATE_S4 == state) {
+ /* For s4bios, we need a wakeup address. */
+ if (1 == acpi_gbl_FACS->S4bios_f &&
+ 0 != acpi_gbl_FADT->smi_cmd) {
+ if (!acpi_wakeup_address)
+ return AE_ERROR;
+ acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
+ } else
+ /* We don't support S4 under 2.4. Give up */
return AE_ERROR;
- acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
}
acpi_enter_sleep_state_prep(state);
@@ -366,8 +371,12 @@
p += sprintf(p, "states: ");
for (i=0; i<ACPI_S_STATE_COUNT; i++) {
- if (system->states[i])
+ if (system->states[i])
p += sprintf(p, "S%d ", i);
+ if (i == ACPI_STATE_S4 &&
+ acpi_gbl_FACS->S4bios_f &&
+ 0 != acpi_gbl_FADT->smi_cmd)
+ p += sprintf(p, "S4Bios ");
}
p += sprintf(p, "\n");
@@ -671,7 +680,7 @@
p += sprintf(p,"S%d ", i);
if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f &&
acpi_gbl_FADT->smi_cmd != 0)
- p += sprintf(p, "S4bios ");
+ p += sprintf(p, "S4Bios ");
}
}
@@ -716,7 +725,7 @@
printk(KERN_DEBUG "acpi: sleep %d\n", state);
if (!system->states[state])
return_VALUE(-ENODEV);
- printk(KERN_DEBUG "acpi: GO!\n", state);
+ printk(KERN_DEBUG "acpi: GO!\n");
/*
* If S4 is supported by the OS, then we should assume that
@@ -1223,7 +1232,8 @@
status = acpi_get_sleep_type_data(i, &type_a, &type_b);
switch (i) {
case ACPI_STATE_S4:
- if (acpi_gbl_FACS->S4bios_f && 0 != acpi_gbl_FADT->smi_cmd) {
+ if (acpi_gbl_FACS->S4bios_f &&
+ 0 != acpi_gbl_FADT->smi_cmd) {
printk(" S4bios");
system->states[i] = 1;
}
^ permalink raw reply
* pcibios_fixup
From: ghannon @ 2002-12-13 20:51 UTC (permalink / raw)
To: linuxppc-dev
We are developing a custom 74xx based board with a gt64260b.
On board is a device we are acessing through pci0 on the gt64260b.
I've noticed that in the device's configuration header, the cache line
size parameter is not what I want it to be. Is pcibios_fixup the
place in the kernel to make such a change?
(that is in my specific platform_setup.c file)
Or, should I do it in the
driver that uses that device?
Thanks for any direction.
Gary Hannon
CSPI
ghannon@cspi.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: pci-skeleton duplex check
From: Jeff Garzik @ 2002-12-13 20:57 UTC (permalink / raw)
To: Donald Becker; +Cc: Roger Luethi, netdev, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212121743500.10674-100000@beohost.scyld.com>
Donald Becker wrote:
> On Thu, 12 Dec 2002, Jeff Garzik wrote:
>
>>Donald Becker wrote:
>>
>>>On Thu, 12 Dec 2002, Jeff Garzik wrote:
>>>
>>>>Donald Becker wrote:
>>
>> [[ I don't know why I bother. The people that now control what
>> goes into the kernel would rather put in random patches from
>> other people than accept a correct fix from me. ]]
>>I'm sure you'll continue making snide comments on every mailing list you
>>maintain, but the fact remains:
>>I would much rather accept a fix from you.
>
>
> Perhaps we have a different idea of "fix".
>
> You want are looking for a patch to modifications you have made to code
> I have written. In the meantime I have been providing working code, and
> have been updating that code to work with new hardware. So a fix is the
> working, continuously maintained version of the driver.
>
> To put an admittedly simplified spin on it, you are saying "I want you
> to tell me what I have broken when I changed this", and to continuously
> monitor and test your changes, made for unknown reasons on a very
> divergent source base.
No, that's not it at all.
I would ecstatic if you even posted the changes made to your own drivers
to netdev@oss.sgi.com or similar...
I'm asking for _any_ contributions at all. The more fine-grained the
better...
>>>The drivers in the kernel are now heavily modified and have significantly
>>>diverged from my version. Sure, you are fine with having someone else
>>>do the difficult and unrewarding debugging and maintenance work, while
>>>you work on just the latest cool hardware, change the interfaces and are
>>>concerned only with the current kernel version.
>>
>>While I disagree with this assessment, I think we can safely draw the
>>conclusion that the problem is _not_ people ignoring your patches, or
>>preferring other patches over yours.
>
>
> I can point to specific instances. Just looking at the drivers in the
> kernel, it is clear that this has happened.
There is an admitted preference to people who actually send me patches.
That sometimes translates to "other change" being preferred over logic
in one of your drivers.
I would still greatly prefer patches from you, however. And your
comments on other people's patches are very welcome [and there have been
plenty of those in past -- thanks].
> But it existed before, and was discarded!
> Yes, the kernel is now _returning_ to a stable state while making
> improvements. But there was a period of time when interface stability
> and detailed correctness was thrown away in favor of many inexperienced
> people quickly and repeatedly restructuring interfaces without
> understanding the underlying requirements.
>
> I could mention VM, but I'll go back to one that had a very large direct
> impacted on me: CardBus. CardBus is a difficult case of hot-swap PCI --
> the device can go away without warning, and it's usually implemented on
> machines where suspend and resume must work correctly. We had perhaps
> the best operational implementation in the industry, and I had written
> about half of the CardBus drivers. Yet my proven interface
> implementation was completely discarded in favor one that needed to be
> repeatedly changed as the requirements were slowly understood.
But... this is how Linux development works. Believe me, I understand
you don't like that very much, but here is a central question to you:
what can we do to move forward?
The CardBus implementation still fails on some systems, and still wants
work. However, the pci_driver API is not only codified in 2.4.x, but it
is extended to the more generic driver model in 2.5.x. _And_ I have
proven it works just fine under 2.2.x (see kcompat24 toolkit).
What can we as kernel developers do to reintegrate you back into kernel
development? Some of the APIs you obviously don't like, but pretending
they don't exist is not a solution. This is the Linux game, for better
or worse. At the end of the day, if we don't like Linus's decisions, we
can either swallow our pride and continue with Linux, or fork a Linux
tree and make it work "the right way." The driver model (nee
pci_driver) is the direction of Linux.
>>I would love to integrate your drivers directly, but they don't come
>>anywhere close to using current kernel APIs. The biggie of biggies is
>>not using the pci_driver API. So, given that we cannot directly merge
>
>
> Yup, that is just what I was talking about. Let me continue:
>
> The result is that today other systems now have progressed to a great
> implementation of suspend/resume, while Linux distributions now default
> to unloading and reloading drivers to avoid various suspend bugs. And
> when the driver cannot be unloaded because some part of the networking
> stack is holding the interface, things go horribly wrong...
>
> You might be able to naysay the individual details, but the end
> technical result is clear.
That's what is currently in development in 2.5.x: sane suspend and
resume. I would dispute that other systems have a decently designed
suspend/resume -- that said, working is obviously better right now than
non-working but nicer design ;-)
>>your drivers, and you don't send patches to kernel developers, what is
>>the next best alternative? (a) let kernel net drivers bitrot, or (b)
>>maintain them as best we can without Don Becker patches? I say that "b"
>>is far better than "a" for Linux users.
>
>
> Or perhaps recognizing that when someone that has been a significant,
> continuous contributer since the early days of Linux says "this is
> screwed up", they might have a point. When Linux suddenly had thousands
> of people wanting to submit patches, that didn't means that there were
> more people that could understand, implement and maintain complex
> systems.
Shit, dude, _I_ recognize this. Probably better than most people, since
I see on a daily basis the benefits of your overall design in the net
drivers, and want to push good elements of that design into the kernel
net drivers. At the end of the day you'd be surprised how much I wind
up defending your code to other kernel hackers, and educating them on
why -not- to do certain things.
IMO the bigger sticking point is - at what point do you say "yeah,
2.4.x/2.5.x APIs may suck in my opinion, but they are the official APIs
so I will use them"? There are tons of reasons why Red Hat (my current
employer) is very leery of taking patches which will not eventually find
their way to the mainline kernel.org kernel. A lot of those reasons
apply in the case of your drivers, too. Using non-standard APIs has all
sorts of software engineering implications which wind up with a negative
developer and user experience.
Jeff
^ permalink raw reply
* usb audio + mandrake 9.0 foobar :(
From: iriXx @ 2002-12-13 20:38 UTC (permalink / raw)
To: alsa-devel, linux-audio-user
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi
just upgraded mandrake from 8.2 to 9.0....
and found out that it seems to have made my alsa all foobar.... :(
i recompiled and reinstalled alsa 0.9.rc5 after upgrading... but i dont
seem to be able to get it working.
im running a quattro usb audio unit... modprobe snd-usb-audio,
snd-pcm-oss, snd-mixer-oss, snd-seq-oss all goes fine... but on opening
any sound or DVD apps i get error messages that there is no sound
support / no sound device found....
anyone got any ideas what may have happened?... is there a problem with
the supplied kernel perhaps ? it appears to be 2.4.19-16mdk
thanx
m~
- --
iriXx
www.iriXx.org
copyleft: creativity, technology and freedom?
info@copyleftmedia.org.uk
www.copyleftmedia.org.uk
~ _
( ) ascii ribbon against html email
~ X
/ \ cat /dev/sda1 > /dev/dsp
~ *** stopping make sense ***
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE9+kU4GlmEEIa9/8YRAgZQAKChzE/GDsXnV2ibWGVeukLIhMuuXgCfaSS6
JhI8H299qo4awD86T56vJ5M=
=1Pwa
-----END PGP SIGNATURE-----
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* RE: Integrating Linux Desktop With MS Exchange Server
From: Dan_Caulfield @ 2002-12-13 20:36 UTC (permalink / raw)
To: Pradeep.Kumar, linux-admin
Try looking at Samba winbind or pam_smb. They both allow Linux desktops to
authenticate against a Windows DC. You might also want to look at the
pam_mount module (http://freshmeat.net/projects/pam-mount/?topic_id=150).
If you don't want to use a browser to access Exchange, Ximian offers a
Ximian Evolution/Connector that can access an Exchange 2000 server. I think
it cost $70USD per copy and it requires that Outlook Web Access is enabled
on the Exchange server.
-----Original Message-----
From: Kumar, Pradeep (MED, TCS) [mailto:Pradeep.Kumar@med.ge.com]
Sent: Friday, December 13, 2002 12:54 PM
To: 'linux-admin@vger.kernel.org'
Subject: Integrating Linux Desktop With MS Exchange Server
Hi,
I am sorry if I am posting this to a wrong mailing list. In that case,
please suggest me the correct one.
We are currently running Microsoft Exchange 5.5 server. Now we would
like to run Red Hat Linux on some desktops.
But we would like to have a unified logon procedure i.e all the windows
users should be able to login on the linux desktop
with their windows username and passwords. Whenever a user wants to
login to the linux desktop, the authentication
should be redirected to the Windows Primary Domain Controller. As a
whole , it is just putting a linux desktop into
a Windows domain. But all the usernames and passwords are created and
maintained on the Exchange Server database and
and authentication of all users should be done on the Exchange server.
Please help me how to proceed on this. I would appreciate any useful
information provided. What should I do to achieve this?
What and all should be ruuning at Linux side? How to achieve this
integration?
Thanks in anticipation,
Regards,
Pradeep
S.Pradeep Kumar
Pradeep.Kumar@med.ge.com
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
From: Nakajima, Jun @ 2002-12-13 20:41 UTC (permalink / raw)
To: jamesclv, Zwane Mwaikambo; +Cc: Martin Bligh, John Stultz, Linux Kernel
Do you have performance data when you program TPR? Today, in 2.5, for
example, we are distributing interrupts among CPUs with Ingo's patch in
software. Doing that in software is fine because it's relatively simple, but
the chipset has more information on the on-going interrupt activities. So
using TPR might work better in general.
One issue with lowest priority delivery mode (as well as Ingo's) is that it
could have negative impacts on L2 caches (actually we saw such instances).
So we also have a patch to balance interrupts load (using statistic data)
without moving them around frequently (mostly static) and I think we can
combine that patch and lowest priority delivery mode.
Jun
> -----Original Message-----
> From: James Cleverdon [mailto:jamesclv@us.ibm.com]
> Sent: Thursday, December 12, 2002 7:32 PM
> To: Zwane Mwaikambo; Nakajima, Jun
> Cc: Martin Bligh; John Stultz; Linux Kernel
> Subject: Re: [PATCH][2.5][RFC] Using xAPIC apic address space on !Summit
>
> On Thursday 12 December 2002 07:26 pm, Zwane Mwaikambo wrote:
> > On Thu, 12 Dec 2002, Nakajima, Jun wrote:
> > > BTW, we are working on a xAPIC patch that supports more than 8 CPUs in
> a
> > > generic fashion (don't use hardcode OEM checking). We already tested
> it
> > > on two OEM systems with 16 CPUs.
> > > - It uses clustered mode. We don't want to use physical mode because
> it
> > > does not support lowest priority delivery mode.
> >
> > Wouldn't that only be for all including self? Or is the documentation
> > incorrect?
> >
> > Thanks,
> > Zwane
>
> I'm not sure I understand your question. Lowest Priority delivery mode
> only
> works with logical interrupts. (I've tried it with physical intrs. It
> fails
> miserably.) The "all including self" and "all excluding self" destination
> shorthands don't do lowest priority arbitration. They always deliver the
> interrupt to the CPUs mentioned in the shortand.
>
> Lowest priority delivery mode isn't _too_ useful in Linux yet. It would
> be
> nice to preferentially target idle CPUs with interrupts in real time.
> That
> means changing each CPU's Task Priority Register (TPR) to represent how
> busy
> it is. I've got some patches to do that, but haven't posted them as
> anything
> more than a RFC.
>
> --
> James Cleverdon
> IBM xSeries Linux Solutions
> {jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
^ permalink raw reply
* [Printing-architecture] Lower level diagram update (bidi update)
From: Pete Zannucci @ 2002-12-13 20:32 UTC (permalink / raw)
To: printing-architecture; +Cc: toratani.yasumasa
All,
I have put an updated version of the lower level architecture
diagrams in the pwg site.
ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch1-121302.jpg
ftp://ftp.pwg.org/pub/pwg/fsg/architecture/arch2-121302.jpg
I realized when I looked at them the points that Michael
Sweet was making because the bidi drawing had a connection
directly to the printer which was incorrect. I updated page
2 to more accurately reflect what the thought was. Sorry
for any confusion.
As far as the notification and event management scheme,
we have been looking at http://evlog.sourceforge.net/ for
starters. It would have to be able to handle large volumes
of information though along with a lot of additional function
that we haven't even started discussing yet.
Capabilities is another subject altogether. Since using .ppd
files is the current implementation under CUPS, nobody has
really started to discuss how to tie in dynamic capabilities
from either a printer or a driver into the system.
Dynamic capabilities would definitely require additional function,
possibly processes, to enable the system (most likely a local
store of sorts) updated with the latest device information. Of
course there are other ways to do this but I would worry that
if we don't have a current configuration cached, in some instances,
the amount of time to initiate a print job may become too large,
especially if we are going to populate dialogs for the user based
on the current settings.
It would be nice if our solution didn't need to have multiple
drivers configured between systems and worry about keeping them
all in sync. if wanted to get the properties in a networked
environment. This will likely be up for debate when we start
working out the issue of client vs. server side rendering though.
Just a couple of thoughts on dynamic capabilities.
Thanks,
Peter Zannucci
IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pzaan@us.ibm.com
^ permalink raw reply
* Re: Raid 5 on 2.5.50/2.5.51, dirty array, kernel panic
From: Eurijk @ 2002-12-13 20:22 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <3DF7847D.1050606@mvista.com>
>I set up an IDE raid array as such:
> /dev/md1 hda1 hdc1 hde1 hdg1 RAID 1 (ext2)
> /dev/md0 hda2 hdc2 hde2 hdg2 RAID 5 (reiserfs)
>... and physically remove a drive (hda) ...
> <0>Kernel panic: Attempted to kill init!
^^^ The above also applies if you put hda back in after
it has been marked bad by it not being there after the
goto abort (see below) has been removed.
This appears to be stemming from a 3.5.33/34? patch that included:
if (mddev->degraded == 1 &&
!(mddev->state & (1<<MD_SB_CLEAN))) {
printk(KERN_ERR "raid5: cannot start dirty degraded array for md%d\n", mdidx(mddev));
goto abort;
}
If you remove the goto abort; there this fixes the problem.
I imagine this needs to check to see if only one device is bad,
and if so, continue.
I would have expected an "unable to mount root" error rather then a kernel
panic so there must be something wrong (probably not very critical) elsewhere.
Can someone more familiar with linux-2.5.51/drivers/md/raid5.c and kernel
modules take a look at this please? Thanks!
-eurijk!
^ permalink raw reply
* RE: natting specific ports
From: Ranjeet Shetye @ 2002-12-13 20:14 UTC (permalink / raw)
To: netfilter
In-Reply-To: <CAFAAEC91CC8D511952000062938C6F12ECDC6@ozlan.fcdomain.net>
Aargh! My apologies.
You are right, you need to SNAT the packet, not DNAT. And therefore you
will have to use POSTROUTING.
Also, you still need to use "-p tcp --dport 23" for Telnet or "-p tcp
--dport 25" for mail servers (that are using SMTP).
Sorry about the confusion there. :D
Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
Ranjeet.Shetye@Zultys.com
http://www.zultys.com/
> -----Original Message-----
> From: Simpson, Doug [mailto:DSimpson@friedmancorp.com]
> Sent: Friday, December 13, 2002 11:50 AM
> To: 'Ranjeet Shetye'
> Subject: RE: natting specific ports
>
>
> Do I still use POSTROUTING or PRE . . .
>
> -----Original Message-----
> From: Ranjeet Shetye [mailto:ranjeet.shetye@zultys.com]
> Sent: Friday, December 13, 2002 1:34 PM
> To: netfilter@lists.netfilter.org
> Subject: RE: natting specific ports
>
>
>
> Yes,
>
> You need to DNAT the destination ports and therefore you need
> to look for them using the --dport flag extension of the -p
> tcp/udp flag.
>
> i.e. for telnet you'll have "-p tcp --dport 23".
>
> Ranjeet Shetye
> Senior Software Engineer
> Zultys Technologies
> 771 Vaqueros Avenue
> Sunnyvale CA 94085
> USA
> Ranjeet.Shetye@Zultys.com
> http://www.zultys.com/
>
>
>
>
> > -----Original Message-----
> > From: Simpson, Doug [mailto:DSimpson@friedmancorp.com]
> > Sent: Friday, December 13, 2002 11:19 AM
> > To: 'Ranjeet Shetye'
> > Subject: RE: natting specific ports
> >
> >
> > I want this for traffic going out. So that my internal
> > clients can send mail and telnet to servers out on the Public
> > Net. I need to use -dport instead of -sport? Thanks, Doug
> >
> > -----Original Message-----
> > From: Ranjeet Shetye [mailto:ranjeet.shetye@zultys.com]
> > Sent: Friday, December 13, 2002 11:58 AM
> > To: netfilter@lists.netfilter.org
> > Subject: RE: natting specific ports
> >
> >
> >
> > Hi Doug,
> >
> > Do you want to NAT for traffic coming in or for traffic going out ?
> >
> > If you want your internal network to be able to reach
> > external telnet and smtp servers, then your destination port
> > will be 23 or 25, not your source port.
> >
> > If you want to host telnet and smtp servers behind a firewall
> > and allow only NATted access to these servers, then you
> > should be using DNAT, not SNAT.
> >
> > Hope this helps,
> >
> > Ranjeet Shetye
> > Senior Software Engineer
> > Zultys Technologies
> > 771 Vaqueros Avenue
> > Sunnyvale CA 94085
> > USA
> > Ranjeet.Shetye@Zultys.com
> > http://www.zultys.com/
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: netfilter-admin@lists.netfilter.org
> > > [mailto:netfilter-admin@lists.netfilter.org] On Behalf Of
> > > Simpson, Doug
> > > Sent: Friday, December 13, 2002 9:49 AM
> > > To: 'netfilter@lists.netfilter.org'
> > > Subject: natting specific ports
> > >
> > >
> > > I want to "NAT" just specific ports to my Public IP. Do the
> > > commands below make sense? I want my internal network to
> be able to
> > > telnet and send email. (eth0 is my External NIC - it is
> exposed to
> > > the internet) iptables -t nat -A POSTROUTING -p tcp --sport 25 -o
> > > eth0 -s $INTERNAL_IP -j SNAT --to $EXTERNAL_IP iptables -t nat -A
> > > POSTROUTING -p tcp --sport 23 -o eth0 -s $INTERNAL_IP -j SNAT
> > > --to $EXTERNAL_IP
> > >
> > > Thank you,
> > > Doug
> > >
> >
> >
>
>
>
^ permalink raw reply
* RE: Integrating Linux Desktop With MS Exchange Server
From: Shaw, Marco @ 2002-12-13 20:10 UTC (permalink / raw)
To: 'linux-admin@vger.kernel.org'
The obvious simple solution is Outlook Web Access. Is this an option with it's more limited functionality? It seems to "mostly" work with Netscape/Mozilla. I know the calendering isn't fully functional with I try OWA from Mozilla, but haven't bothered Googling for a fix, if one exists.
Other than that, are you using AD or NT4 PDCs? In the back of my mind, I'm thinking of what Jorge mentioned with regards to Samba...
Marco
-----Original Message-----
From: Kumar, Pradeep (MED, TCS) [mailto:Pradeep.Kumar@med.ge.com]
Sent: Friday, December 13, 2002 2:54 PM
To: 'linux-admin@vger.kernel.org'
Subject: Integrating Linux Desktop With MS Exchange Server
Hi,
I am sorry if I am posting this to a wrong mailing list. In that case, please suggest me the correct one.
We are currently running Microsoft Exchange 5.5 server. Now we would like to run Red Hat Linux on some desktops.
But we would like to have a unified logon procedure i.e all the windows users should be able to login on the linux desktop with their windows username and passwords. Whenever a user wants to login to the linux desktop, the authentication should be redirected to the Windows Primary Domain Controller. As a whole , it is just putting a linux desktop into a Windows domain. But all the usernames and passwords are created and maintained on the Exchange Server database and
and authentication of all users should be done on the Exchange server.
Please help me how to proceed on this. I would appreciate any useful information provided. What should I do to achieve this? What and all should be ruuning at Linux side? How to achieve this integration?
Thanks in anticipation,
Regards,
Pradeep
S.Pradeep Kumar
Pradeep.Kumar@med.ge.com
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 2.5.51 oops saa7134
From: Marco d'Itri @ 2002-12-13 20:18 UTC (permalink / raw)
To: linux-kernel; +Cc: Gerd Knorr
Looks like that the ALSA modules have not been loaded so the TV card
mixer become /dev/mixer instead of the usual /dev/mixer1 (yes, I have
the mixer_nr=1 option in modprobe.conf but it's ignored like other
saa7134 options). Then mplayer tried to use it and something unexpected
happened:
ksymoops 2.4.6 on i686 2.5.51. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.5.51/ (default)
-m /boot/System.map-2.5.51 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Dec 13 21:04:20 wonderland kernel: kernel BUG at drivers/media/video/saa7134/saa7134-core.c:287!
Dec 13 21:04:20 wonderland kernel: invalid operand: 0000
Dec 13 21:04:20 wonderland kernel: CPU: 0
Dec 13 21:04:20 wonderland kernel: EIP: 0060:[<e08452d0>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Dec 13 21:04:20 wonderland kernel: EFLAGS: 00010246
Dec 13 21:04:20 wonderland kernel: eax: dff8c1d0 ebx: dff8c1d0 ecx: d5c06800 edx: 00000000
Dec 13 21:04:20 wonderland kernel: esi: 00000000 edi: dff8c000 ebp: cb7fdee4 esp: cb7fded4
Dec 13 21:04:20 wonderland kernel: ds: 0068 es: 0068 ss: 0068
Dec 13 21:04:20 wonderland kernel: Stack: dff8c1d0 00000000 dff8c000 dff8c000 cb7fdf0c e084672c c15ccc00 dff8c1d0
Dec 13 21:04:20 wonderland kernel: d5c06800 00000040 00000000 dff8c000 dff8c184 00000000 cb7fdf24 e08472e5
Dec 13 21:04:20 wonderland kernel: dff8c000 00000000 dc747740 00000000 cb7fdf64 c0148196 dc747740 00000000
Dec 13 21:04:20 wonderland kernel: Call Trace:
Dec 13 21:04:20 wonderland kernel: [<e084672c>] dsp_rec_start+0x4c/0x260 [saa7134]
Dec 13 21:04:20 wonderland kernel: [<e08472e5>] dsp_poll+0x55/0x80 [saa7134]
Dec 13 21:04:20 wonderland kernel: [<c0148196>] do_select+0xe6/0x1e0
Dec 13 21:04:20 wonderland kernel: [<c0147f50>] __pollwait+0x0/0xa0
Dec 13 21:04:20 wonderland kernel: [<c01485cc>] sys_select+0x30c/0x430
Dec 13 21:04:20 wonderland kernel: [<c0108aa3>] syscall_call+0x7/0xb
Dec 13 21:04:20 wonderland kernel: Code: 0f 0b 1f 01 40 d3 84 e0 8b 50 04 8b 45 18 8d 14 82 31 c0 3b
>>EIP; e08452d0 <END_OF_CODE+204bf088/????> <=====
Trace; e084672c <END_OF_CODE+204c04e4/????>
Trace; e08472e5 <END_OF_CODE+204c109d/????>
Trace; c0148196 <do_select+e6/1e0>
Trace; c0147f50 <__pollwait+0/a0>
Trace; c01485cc <sys_select+30c/430>
Trace; c0108aa3 <syscall_call+7/b>
Code; e08452d0 <END_OF_CODE+204bf088/????>
00000000 <_EIP>:
Code; e08452d0 <END_OF_CODE+204bf088/????> <=====
0: 0f 0b ud2a <=====
Code; e08452d2 <END_OF_CODE+204bf08a/????>
2: 1f pop %ds
Code; e08452d3 <END_OF_CODE+204bf08b/????>
3: 01 40 d3 add %eax,0xffffffd3(%eax)
Code; e08452d6 <END_OF_CODE+204bf08e/????>
6: 84 e0 test %ah,%al
Code; e08452d8 <END_OF_CODE+204bf090/????>
8: 8b 50 04 mov 0x4(%eax),%edx
Code; e08452db <END_OF_CODE+204bf093/????>
b: 8b 45 18 mov 0x18(%ebp),%eax
Code; e08452de <END_OF_CODE+204bf096/????>
e: 8d 14 82 lea (%edx,%eax,4),%edx
Code; e08452e1 <END_OF_CODE+204bf099/????>
11: 31 c0 xor %eax,%eax
Code; e08452e3 <END_OF_CODE+204bf09b/????>
13: 3b 00 cmp (%eax),%eax
1 warning and 1 error issued. Results may not be reliable.
mplayer output:
Cache fill: 0,00% (0 bytes) Detected AVI file format!
VIDEO: [DX50] 608x320 24bpp 25,00 fps 843,9 kbps (103,0 kbyte/s)
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, 16 bit (0x10), ratio: 12000->176400 (96,0 kbit)
Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
vo: X11 running at 1024x768 with depth 24 and 32 bpp (":0.0" => local display)
Disabling DPMS
Opening video filter: [eq]
==========================================================================
Trying to force video codec driver family ffmpeg ...
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm:ffmpeg (FFmpeg MPEG-4)
==========================================================================
audio_setup: driver doesn't support SNDCTL_DSP_GETOSPACE :-(
Segmentation fault
[Exit 139 (SIGSEGV)]
Module Size Used by
ppp_deflate 4418 0 [unsafe]
zlib_deflate 20403 1 ppp_deflate [permanent]
zlib_inflate 20547 1 ppp_deflate [permanent]
bsd_comp 4892 0 [unsafe]
af_packet 14583 2 [unsafe]
ppp_async 8524 1 [unsafe]
ppp_generic 19950 6 ppp_deflate bsd_comp ppp_async [unsafe]
slhc 6087 1 ppp_generic
ne2k_pci 6594 1
8390 7419 1 ne2k_pci
crc32 1851 2 8390 [unsafe]
psmouse 5702 0
mousedev 6627 1
saa7134 58725 1
video_buf 13505 1 saa7134 [permanent]
v4l1_compat 10519 1 saa7134 [permanent]
soundcore 5787 1 saa7134
i2c_core 19408 1 saa7134
v4l2_common 3242 1 saa7134 [permanent]
videodev 7090 1 saa7134
--
ciao,
Marco
^ permalink raw reply
* Re: [PATCH] S4Bios support for 2.4.20 + acpi-20021205
From: Nils Faerber @ 2002-12-13 20:03 UTC (permalink / raw)
Cc: ducrot-kk6yZipjEM5g9hUCZPvPmw, acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <20021213191758.GP4327-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
On Fri, 13 Dec 2002 20:17:58 +0100
Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> On Fri, Dec 13, 2002 at 07:49:07PM +0100, Nils Faerber wrote:
> [...]
> > My result:
> > S4BIOS_REQ: 0x00
> >
> > > For ./acpidmp FACS | ./acpitbl:
> > > Flags have bit 0 set.
> >
> > Signature: FACS
> > Length: 64
> > Hardware Signature: 0x00000000
> > Firmware Waking Vector: 0x00000000
> > Global Lock: 0x00000000
> > Flags: 0x00000000
> >
> > Hmm ... and now?
> > What does that mean?
> Your BIOS cry loudly that it do not support S4Bios (certainly due
> to a lack of a suspend partition). I supposed that my patch does it
> right, so that if someone insist, it give up, but that is not the
> case. I have to look what stupid brain-damaged bogosity I have written
> then.
Oh well, many thanks again!
I already thought something like this.
Now, this just leaves the question what f*ckin' type of partition this
BIOS wants. I already tried almost everything: lphdisk, zvhdd (DOS
utility), simple VFAT32 partition, nothing. Oh well ... mybe I'll
disassemble the BIOS - just joking :) I think best bet would be to ask
Asus for a hint.
Anyway, thanks for your help!
> Ducrot Bruno
CU
nils faerber
--
kernel concepts Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen D1 : +49-170-2729106
--
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: 2.5.50-mm2
From: Andrew Morton @ 2002-12-13 19:58 UTC (permalink / raw)
To: Christoph Hellwig, linux-xfs@oss.sgi.com; +Cc: lkml, linux-mm
In-Reply-To: <20021213175526.C2581@sgi.com>
Christoph Hellwig wrote:
>
> On Mon, Dec 09, 2002 at 12:26:48AM -0800, Andrew Morton wrote:
> > +remove-PF_SYNC.patch
> >
> > remove the current->flags:PF_SYNC abomination. Adds a `sync' arg to
> > all writepage implementations to tell them whether they are being
> > called for memory cleansing or for data integrity.
>
> Any chance you could pass down a struct writeback_control instead of
> just the sync flag? XFS always used ->writepage similar to the
> ->vm_writeback in older kernel releases because writing out more
> than one page of delalloc space is really needed to be efficient and
> this would allow us to get a few more hints about the VM's intentions.
Yup, no probs.
It would be good to measure how often that codepath actually gets invoked
during testing and use. It's typically quite rare. It should be just
MAP_SHARED stuff, although there are probably some highmem-related scenarii
in which it will happen.
I'll add a writeback_control.for_reclaim boolean so we don't have to play
games with PF_MEMALLOC to reverse engineer the calling context.
If XFS is going to writearound extra pages in ->writepage() then it would
be best to set PG_reclaim (if wbc->for_reclaim) so end_page_writeback()
will rotate them.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ 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.