* [LARTC] HTB rate 0kbit
From: Thomas Jalsovsky @ 2003-01-10 12:12 UTC (permalink / raw)
To: lartc
Hello,
I would like to achieve this:
HTB qdisc with many classes. One class shouldn't have guaranteed
bandwidth, only ceil bandwidth -> if there is available bandwidth, the
this class can use it, but if everybody uses the whole bandwidth it should
get any bandwidth.
I tryed this with HTB to set rate to 0 and ceil to the max value
(rate 0kbit ceil 1920kbit) - unfortunately I got error message :(
Is it possible to have this configuration?
Thanks in advance,
Thomas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Nicholas Berry @ 2003-01-10 12:25 UTC (permalink / raw)
To: cort; +Cc: linux-kernel
>>> Cort Dougan <cort@fsmlabs.com> 01/09/03 07:36PM >>>
> If people starting doing that what would be have to argue about?
Lets see:
Calling Linux GNU/Linux
Calling Hurd Linux/Hurd
Calling my mother a computer illiterate bimbo.
BK.
That should do for now.
Nik
} Why don't you _read_ the GPL instead of making wrong statements?
^ permalink raw reply
* Re: detecting hyperthreading in linux 2.4.19
From: Mark Hounschell @ 2003-01-10 12:29 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <slrnb1rs3q.3u8.lunz@stoli.localnet>
Jason Lunz wrote:
>
> jamesclv@us.ibm.com said:
> > I don't know of any way to do this in userland. The whole point is
> > that the sibling processors are supposed to look like real ones.
>
> That's unfortunately not always true. I'm writing a program that will
> run on a system that will be doing high-load routing. Testing has shown
> that we get better performance when binding each NIC's interrupts to a
> separate physical processor using /proc/irq/*/smp_affinity (especially
> when all the interrupts would hit the first CPU, another problem i've
> yet to address). That only works for real processors, though, not
> HT siblings.
Strange, I'm doing the very same thing (not with NICs though) using the
local_irq_desc
at the driver level or via /proc/irq/*/smp_affinity method and both work fine.
2.4.18 and 2.4.20 both work here but haven't actually used 2.4.19.
>
> I'm writing a program to run on machines of unknown (by me)
> configuration, that will spread out the NIC interrupts appropriately.
> So userspace needs to know the difference, at least until interrupts can
> be automatically distributed by the kernel in a satisfactory way.
My userland app doesn't know the difference and works fine whether HT or not.
At least according to /proc/interrupts, xosview, and the actual performance of
my app.
Mark
^ permalink raw reply
* Re: [linux-lvm] LVM2 snapshot creation problem
From: Gary Windham @ 2003-01-10 12:19 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <3E1CB9E4.1030704@email.arizona.edu>
Gary Windham wrote:
> I am testing LVM2 under the 2.4.20 (vanilla) kernel running on RedHat
> 8.0. I'm Using device-mapper0.96.07 and the userspace tools
> LVM2.1.95.13 packages. I applied the device-mapper kernel patches
> located at
> http://people.sistina.com/~thornber/patches/2.4-stable/2.4.20/2.4.20-dm-2.tar.bz2.
>
>
> My problem is that I have not been able to create LV snapshots under
> LVM2. Here's an example (command and output follow):
[snip]
Thanks to Alasdair and Joe--his latest 2.4.20 patches
(http://people.sistina.com/~thornber/patches/2.4-stable/2.4.20/2.4.20-dm-4.tar.bz2)
fixed the problem. But I have a different problem now, which I believe
to be related to highmem. In fact, I believe it to be the same issue
encountered by Gregory Ade w/ LVM1 last year (e.g.,
http://lists.sistina.com/pipermail/linux-lvm/2002-December/012959.html).
When I run the snapshot command, it segfaults and I get the following
kernel bug output:
--->8--- kernel bug output --->8---
kernel BUG at vmalloc.c:242!
invalid operand: 0000
CPU: 1
EIP: 0010:[<c01345f3>] Not tainted
EFLAGS: 00010246
eax: 00000fff ebx: 00000000 ecx: 00000008 edx: 00000000
esi: f601a544 edi: 00000000 ebp: f8a3c080 esp: f3b39dc8
ds: 0018 es: 0018 ss: 0018
Process lvcreate (pid: 4205, stackpage=f3b39000)
Stack: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
f601a544
00000000 f8a3c080 c013485b 00000000 000001f2 00000163 00000000
00000000
f89c1023 00000000 00000008 00000000 f601a544 f601a500 f89c126a
f601a544
Call Trace: [<c013485b>] [<f89c1023>] [<f89c126a>] [<f89c1544>]
[<f89bdf56>]
[<c0134ba6>] [<c013467b>] [<c013485b>] [<f89bf148>] [<f89bf4a7>]
[<f89c02af>]
[<f89bf440>] [<c0150dcf>] [<c01093df>]
Code: 0f 0b f2 00 7e bc 26 c0 31 d2 8b 5c 24 18 89 d0 8b 74 24 1c
--->8--- kernel bug output --->8---
Running this through ksymoops, I get the following:
--->8--- ksymoops output --->8---
ksymoops 2.4.5 on i686 2.4.20. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.20/ (default)
-m /boot/System.map-2.4.20 (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 (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Error (expand_objects): cannot stat(/lib/lvm-mod.o) for lvm-mod
Error (expand_objects): cannot stat(/lib/qla2300.o) for qla2300
Error (expand_objects): cannot stat(/lib/megaraid.o) for megaraid
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
Warning (map_ksym_to_module): cannot match loaded module ext3 to a
unique module object. Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module qla2300 to a
unique module object. Trace may not be reliable.
kernel BUG at vmalloc.c:242!
invalid operand: 0000
CPU: 1
EIP: 0010:[<c01345f3>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000fff ebx: 00000000 ecx: 00000008 edx: 00000000
esi: f601a544 edi: 00000000 ebp: f8a3c080 esp: f3b39dc8
ds: 0018 es: 0018 ss: 0018
Process lvcreate (pid: 4205, stackpage=f3b39000)
Stack: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
f601a544
00000000 f8a3c080 c013485b 00000000 000001f2 00000163 00000000
00000000
f89c1023 00000000 00000008 00000000 f601a544 f601a500 f89c126a
f601a544
Call Trace: [<c013485b>] [<f89c1023>] [<f89c126a>] [<f89c1544>]
[<f89bdf56>]
[<c0134ba6>] [<c013467b>] [<c013485b>] [<f89bf148>] [<f89bf4a7>]
[<f89c02af>]
[<f89bf440>] [<c0150dcf>] [<c01093df>]
Code: 0f 0b f2 00 7e bc 26 c0 31 d2 8b 5c 24 18 89 d0 8b 74 24 1c
>>EIP; c01345f3 <__vmalloc+33/110> <=====
>>eax; 00000fff Before first symbol
>>esi; f601a544 <_end+35cad8e0/384933fc>
>>ebp; f8a3c080 <END_OF_CODE+a135/????>
>>esp; f3b39dc8 <_end+337cd164/384933fc>
Trace; c013485b <vcalloc+4b/70>
Trace; f89c1023 <[dm-mod]init_exception_table+23/70>
Trace; f89c126a <[dm-mod]init_hash_tables+9a/100>
Trace; f89c1544 <[dm-mod]snapshot_ctr+274/3a0>
Trace; f89bdf56 <[dm-mod]dm_table_add_target+156/1a0>
Trace; c0134ba6 <alloc_area_pmd+66/8e>
Trace; c013467b <__vmalloc+bb/110>
Trace; c013485b <vcalloc+4b/70>
Trace; f89bf148 <[dm-mod]populate_table+88/e0>
Trace; f89bf4a7 <[dm-mod]create+67/130>
Trace; f89c02af <[dm-mod]ctl_ioctl+cf/110>
Trace; f89bf440 <[dm-mod]create+0/130>
Trace; c0150dcf <sys_ioctl+ef/20f>
Trace; c01093df <system_call+33/38>
Code; c01345f3 <__vmalloc+33/110>
00000000 <_EIP>:
Code; c01345f3 <__vmalloc+33/110> <=====
0: 0f 0b ud2a <=====
Code; c01345f5 <__vmalloc+35/110>
2: f2 00 7e bc repnz add %bh,0xffffffbc(%esi)
Code; c01345f9 <__vmalloc+39/110>
6: 26 es
Code; c01345fa <__vmalloc+3a/110>
7: c0 (bad)
Code; c01345fb <__vmalloc+3b/110>
8: 31 d2 xor %edx,%edx
Code; c01345fd <__vmalloc+3d/110>
a: 8b 5c 24 18 mov 0x18(%esp,1),%ebx
Code; c0134601 <__vmalloc+41/110>
e: 89 d0 mov %edx,%eax
Code; c0134603 <__vmalloc+43/110>
10: 8b 74 24 1c mov 0x1c(%esp,1),%esi
3 warnings and 7 errors issued. Results may not be reliable.
--->8--- ksymoops output --->8---
I encountered these same problems with LVM1 on the same system. The
kernel is configured with CONFIG_SMP=y and CONFIG_HIGHMEM4G=y.
--
Gary Windham
Systems Programmer, Principal
The University of Arizona, CCIT
^ permalink raw reply
* [PATCH][RFC] 3 net drivers [etherleak]
From: Maciej Soltysiak @ 2003-01-10 12:32 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3365 bytes --]
Hi,
about a discussion about padding of ethernet frames, here are 3 patches
to 3 old popular net drivers that should do the padding:
- eexpress.c
- 3c507.c
- eepro.c
I do not have these old cards handy, it would be nice if someone who has
them, could test the drivers (which should be very easy with them compiled
as modules)
Is this a good solution?
Regards,
Maciej Soltysiak
Here are the 3 little patches:
--- linux/drivers/net/eexpress.c 2002-11-29 00:53:13.000000000 +0100
+++ linux.new/drivers/net/eexpress.c 2003-01-10 13:23:01.000000000 +0100
@@ -660,10 +654,16 @@
#endif
{
- unsigned short length = (ETH_ZLEN < buf->len) ? buf->len :
- ETH_ZLEN;
+ unsigned short length;
unsigned short *data = (unsigned short *)buf->data;
+ if (ETH_ZLEN < buf->len) {
+ length = buf->len;
+ } else {
+ length = ETH_ZLEN;
+ memset(data + buf->len, 0, length - buf->len);
+ }
+
lp->stats.tx_bytes += length;
eexp_hw_tx_pio(dev,data,length);
--- linux/drivers/net/3c507.c 2002-02-25 20:37:58.000000000 +0100
+++ linux.new/drivers/net/3c507.c 2003-01-10 13:02:02.000000000 +0100
@@ -19,6 +19,10 @@
Mark Salazar <leslie@access.digex.net> made the changes for cards with
only 16K packet buffers.
+
+ Maciej Soltysiak: Padding of ethernet frames of length less
+ than ETH_ZLEN (RFC 894, RFC 1042)
+
Things remaining to do:
Verify that the tx and rx buffers don't have fencepost errors.
Move the theory of operation and memory map documentation.
@@ -26,8 +30,8 @@
*/
#define DRV_NAME "3c507"
-#define DRV_VERSION "1.10a"
-#define DRV_RELDATE "11/17/2001"
+#define DRV_VERSION "1.11"
+#define DRV_RELDATE "01/10/2003"
static const char version[] =
DRV_NAME ".c:v" DRV_VERSION " " DRV_RELDATE " Donald Becker (becker@scyld.com)\n";
@@ -494,9 +498,16 @@
struct net_local *lp = (struct net_local *) dev->priv;
int ioaddr = dev->base_addr;
unsigned long flags;
- short length = ETH_ZLEN < skb->len ? skb->len : ETH_ZLEN;
+ short length;
unsigned char *buf = skb->data;
+ if (ETH_ZLEN < skb->len) {
+ length = skb->len;
+ } else {
+ length = ETH_ZLEN;
+ memset(buf + skb->len, 0, length - skb->len);
+ }
+
netif_stop_queue (dev);
spin_lock_irqsave (&lp->lock, flags);
--- linux/drivers/net/eepro.c 2002-11-29 00:53:13.000000000 +0100
+++ linux.new/drivers/net/eepro.c 2003-01-10 13:01:55.000000000 +0100
@@ -23,6 +23,8 @@
This is a compatibility hardware problem.
Versions:
+ 0.14 padding of ethernet frames of length less than
+ ETH_ZLEN (01/10/2003)
0.13a in memory shortage, drop packets also in board
(Michael Westermann <mw@microdata-pos.de>, 07/30/2002)
0.13 irq sharing, rewrote probe function, fixed a nasty bug in
@@ -104,7 +106,7 @@
*/
static const char version[] =
- "eepro.c: v0.13 11/08/2001 aris@cathedrallabs.org\n";
+ "eepro.c: v0.14 01/10/2003 aris@cathedrallabs.org\n";
#include <linux/module.h>
@@ -1138,9 +1140,16 @@
spin_lock_irqsave(&lp->lock, flags);
{
- short length = ETH_ZLEN < skb->len ? skb->len : ETH_ZLEN;
+ short length;
unsigned char *buf = skb->data;
+ if (ETH_ZLEN <= skb->len) {
+ length = skb->len
+ } else {
+ length = ETH_ZLEN;
+ memset(buf + skb->len, 0, length - skb->len);
+ }
+
if (hardware_send_packet(dev, buf, length))
/* we won't wake queue here because we're out of space */
lp->stats.tx_dropped++;
[-- Attachment #2: eexpress --]
[-- Type: TEXT/plain, Size: 586 bytes --]
--- linux/drivers/net/eexpress.c 2002-11-29 00:53:13.000000000 +0100
+++ linux.new/drivers/net/eexpress.c 2003-01-10 13:23:01.000000000 +0100
@@ -660,10 +654,16 @@
#endif
{
- unsigned short length = (ETH_ZLEN < buf->len) ? buf->len :
- ETH_ZLEN;
+ unsigned short length;
unsigned short *data = (unsigned short *)buf->data;
+ if (ETH_ZLEN < buf->len) {
+ length = buf->len;
+ } else {
+ length = ETH_ZLEN;
+ memset(data + buf->len, 0, length - buf->len);
+ }
+
lp->stats.tx_bytes += length;
eexp_hw_tx_pio(dev,data,length);
[-- Attachment #3: 3c507 --]
[-- Type: TEXT/plain, Size: 1305 bytes --]
--- linux/drivers/net/3c507.c 2002-02-25 20:37:58.000000000 +0100
+++ linux.new/drivers/net/3c507.c 2003-01-10 13:02:02.000000000 +0100
@@ -19,6 +19,10 @@
Mark Salazar <leslie@access.digex.net> made the changes for cards with
only 16K packet buffers.
+
+ Maciej Soltysiak: Padding of ethernet frames of length less
+ than ETH_ZLEN (RFC 894, RFC 1042)
+
Things remaining to do:
Verify that the tx and rx buffers don't have fencepost errors.
Move the theory of operation and memory map documentation.
@@ -26,8 +30,8 @@
*/
#define DRV_NAME "3c507"
-#define DRV_VERSION "1.10a"
-#define DRV_RELDATE "11/17/2001"
+#define DRV_VERSION "1.11"
+#define DRV_RELDATE "01/10/2003"
static const char version[] =
DRV_NAME ".c:v" DRV_VERSION " " DRV_RELDATE " Donald Becker (becker@scyld.com)\n";
@@ -494,9 +498,16 @@
struct net_local *lp = (struct net_local *) dev->priv;
int ioaddr = dev->base_addr;
unsigned long flags;
- short length = ETH_ZLEN < skb->len ? skb->len : ETH_ZLEN;
+ short length;
unsigned char *buf = skb->data;
+ if (ETH_ZLEN < skb->len) {
+ length = skb->len;
+ } else {
+ length = ETH_ZLEN;
+ memset(buf + skb->len, 0, length - skb->len);
+ }
+
netif_stop_queue (dev);
spin_lock_irqsave (&lp->lock, flags);
[-- Attachment #4: eepro --]
[-- Type: TEXT/plain, Size: 1179 bytes --]
--- linux/drivers/net/eepro.c 2002-11-29 00:53:13.000000000 +0100
+++ linux.new/drivers/net/eepro.c 2003-01-10 13:01:55.000000000 +0100
@@ -23,6 +23,8 @@
This is a compatibility hardware problem.
Versions:
+ 0.14 padding of ethernet frames of length less than
+ ETH_ZLEN (01/10/2003)
0.13a in memory shortage, drop packets also in board
(Michael Westermann <mw@microdata-pos.de>, 07/30/2002)
0.13 irq sharing, rewrote probe function, fixed a nasty bug in
@@ -104,7 +106,7 @@
*/
static const char version[] =
- "eepro.c: v0.13 11/08/2001 aris@cathedrallabs.org\n";
+ "eepro.c: v0.14 01/10/2003 aris@cathedrallabs.org\n";
#include <linux/module.h>
@@ -1138,9 +1140,16 @@
spin_lock_irqsave(&lp->lock, flags);
{
- short length = ETH_ZLEN < skb->len ? skb->len : ETH_ZLEN;
+ short length;
unsigned char *buf = skb->data;
+ if (ETH_ZLEN <= skb->len) {
+ length = skb->len
+ } else {
+ length = ETH_ZLEN;
+ memset(buf + skb->len, 0, length - skb->len);
+ }
+
if (hardware_send_packet(dev, buf, length))
/* we won't wake queue here because we're out of space */
lp->stats.tx_dropped++;
^ permalink raw reply
* Severe reiserfs problems
From: Robert Szentmihalyi @ 2003-01-10 12:32 UTC (permalink / raw)
To: Linux Kernel Mailing List
Hi,
I have severe file system problems on a reiserfs partition.
When I try copy files to another filesystem, the kernel panics at certain
files.
reiserfsck --fix-fixable says that I need to run
reiserfsck --rebuild-tree to fix the errors, but when I do this,
reiserfsck hangs after a few secounds.
Is there a way to rescue at least some of the data on the partition?
Any help is highly appreciated.
TIA,
Robert
--
Where do you want to be tomorrow?
Entracom. Building Linux systems.
http://www.entracom.de
^ permalink raw reply
* Re: [PATCH]Re: spin_locks without smp.
From: Alan Cox @ 2003-01-10 13:20 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: William Lee Irwin III, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.51.0301101308410.25610@dns.toxicfilms.tv>
On Fri, 2003-01-10 at 12:09, Maciej Soltysiak wrote:
> > On Fri, Jan 10, 2003 at 03:45:46AM -0800, William Lee Irwin III wrote:
> > > Buggy on preempt. Remove the #ifdef
> Yes sir. :)
>
> Is that okay?
I'm not convinced its the right way. The driver does the things it does in order
to keep performance acceptable. eexpress, 8390 and one or two other
drivers have a paticular problem that is hard to handle with our current
locks (and which at the time Linus made a decision wasn't a good thing
to try and handle generically).
We have to ensure that the IRQ path doesn't execute in parallel with
the transmit/timeout path. At the same time the packet upload to the
card is extremely slow. Sufficiently slow in fact that serial ports
just stop working when you use it without the ifdef paths.
On uniprocessor systems even with pre-empt the IRQ handler cannot be
pre-empted by normal code execution. On SMP they can run across two
processors. What the disable_irq path is doing for uniprocessor is
implementing
spin_lock_irqsavesomeirqsonly()
and on the kind of boxes that have these old cards its pretty important
to keep this.
I would argue that if we have an IRQ disabled we should forbid pre-empt.
If an IRQ is disabled and we pre-empt to a task that needs to allocate
memory and we swap to a device on that IRQ we may deadlock.
So the fix is either to make disable_irq()/enable_irq() correctly
adjust the pre-empt restrictions, which is actually quite hard to see
how to do right as the disable/enable may be in different tasks, or to
change the code to do the following
preempt_disable()
disable_irq()
#ifdef CONFIG_SMP
spin_lock_...
#endif
Note that we must disable the irq before taking the spinlock or we
have another deadlock with our irq path versus disable_irq waiting
for the IRQ completion before returning.
If my analysis of the disable_irq versus pre-empt and memory allocation
deadlock is correct we have some other cases we need to address too.
Alan
^ permalink raw reply
* Re: spin_locks without smp.
From: Alan Cox @ 2003-01-10 13:23 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Maciej Soltysiak, Linux Kernel Mailing List
In-Reply-To: <20030110114546.GN23814@holomorphy.com>
On Fri, 2003-01-10 at 11:45, William Lee Irwin III wrote:
> On Fri, Jan 10, 2003 at 12:42:34PM +0100, Maciej Soltysiak wrote:
> > while browsing through the network drivers about the etherleak issue i
> > found that some drivers have:
> > #ifdef CONFIG_SMP
> > spin_lock_irqsave(...)
> > #endif
> > and some just:
> > spin_lock_irqsave(...)
> > or similar.
> > Which version should be practiced? i thought spinlocks are irrelevant
> > without SMP so we should use #ifdef to shorten the execution path.
>
> Buggy on preempt. Remove the #ifdef
And render the driver unusable. Very clever. How about understanding *why*
something was done first 8)
^ permalink raw reply
* Re: __gpl_ksymtab
From: Geert Uytterhoeven @ 2003-01-10 12:38 UTC (permalink / raw)
To: Rusty Russell; +Cc: Russell King, Linux Kernel List, Linus Torvalds
In-Reply-To: <20030110091014.231C82C4C2@lists.samba.org>
On Fri, 10 Jan 2003, Rusty Russell wrote:
> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.55/arch/m68k/vmlinux-std.lds working-2.5.55-gpl_ksymtab/arch/m68k/vmlinux-std.lds
> --- linux-2.5.55/arch/m68k/vmlinux-std.lds 2003-01-02 14:47:57.000000000 +1100
> +++ working-2.5.55-gpl_ksymtab/arch/m68k/vmlinux-std.lds 2003-01-10 19:43:03.000000000 +1100
> @@ -24,6 +24,10 @@ SECTIONS
> __ksymtab : { *(__ksymtab) }
> __stop___ksymtab = .;
>
> + __start___ksymtab = .; /* Kernel symbol table */
> + __ksymtab : { *(__ksymtab) }
> + __stop___ksymtab = .;
Woops, where's the `gpl'?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: spin_locks without smp.
From: William Lee Irwin III @ 2003-01-10 12:41 UTC (permalink / raw)
To: Alan Cox; +Cc: Maciej Soltysiak, Linux Kernel Mailing List
In-Reply-To: <1042205036.28469.78.camel@irongate.swansea.linux.org.uk>
On Fri, Jan 10, 2003 at 12:42:34PM +0100, Maciej Soltysiak wrote:
>>> Which version should be practiced? i thought spinlocks are irrelevant
>>> without SMP so we should use #ifdef to shorten the execution path.
On Fri, 2003-01-10 at 11:45, William Lee Irwin III wrote:
>> Buggy on preempt. Remove the #ifdef
On Fri, Jan 10, 2003 at 01:23:56PM +0000, Alan Cox wrote:
> And render the driver unusable. Very clever. How about understanding *why*
> something was done first 8)
It's hard to see offhand (esp. w/o the hw) why increasing the
preempt_count temporarily would render it unusable. It looks like
there are deeper issues here from what you're telling me. I'll go
regroup and attempt to form some intelligent questions from your
other response.
Thanks,
Bill
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: David D. Hagood @ 2003-01-10 12:42 UTC (permalink / raw)
To: Matti Aarnio; +Cc: linux-kernel
In-Reply-To: <20030110065218.GE27709@mea-ext.zmailer.org>
Matti Aarnio wrote:
> What does such tape contain ?
> - DTMF tones buried in various degrees of distortions,
> which should be decodable ?
> - DTMF tones buried in varying noises which should not be
> decodable ?
> - Other multi-tone signals which should not decode ?
All that, plus voice (to detect falsing).
It's about 30 minutes long.
^ permalink raw reply
* Re: spin_locks without smp.
From: Alan Cox @ 2003-01-10 13:29 UTC (permalink / raw)
To: Maciej Soltysiak; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.51.0301101238560.6124@dns.toxicfilms.tv>
On Fri, 2003-01-10 at 11:42, Maciej Soltysiak wrote:
> Hi,
>
> while browsing through the network drivers about the etherleak issue i
> found that some drivers have:
>
> #ifdef CONFIG_SMP
> spin_lock_irqsave(...)
> #endif
>
> and some just:
>
> spin_lock_irqsave(...)
>
> or similar.
> Which version should be practiced? i thought spinlocks are irrelevant
> without SMP so we should use #ifdef to shorten the execution path.
Long answer: The network driver authors are doing some fairly clever
things to make old ISA adapters usable in Linux 2.4 and later. Linux
lacks the functionality to do
spin_lock_disable_irqmask(lock, flags, mask)
Implementing it is rather expensive and hard to do well. In general
those code paths need reviewing and probably to change to
preempt_disable()
#ifdef CONFIG_SMP
spin_lock_irqsave(..)
#endif
..
Please ensure that if you change these drivers you
a) Have the hardware and test it uniprocessor and SMP
b) Verify that with your change a serial modem port still works
c) Understand the game the author is playing
(Also d) ensure the author understands the games she/he is playing too!)
If you've been looking at the etherleak stuff btw, the -ac tree has what
is theoretically a full set of fixes. I'd love someone who is looking
at this into 2.5 to review them and merge them into the 2.5 tree. I
doubt I have them all right so more eyes is most welcome.
Alan
^ permalink raw reply
* Re: [PATCH] SCSI Core patches
From: Andre Hedrick @ 2003-01-10 12:35 UTC (permalink / raw)
To: Mike Anderson; +Cc: Luben Tuikov, linux-scsi
In-Reply-To: <20030108211306.GG1112@beaverton.ibm.com>
How about just a simple two layer with looping between the tow to hang
personalities on, and finally hooking the HBA's to handle exceptions only
against a native bus-phase (want to say state machine) fuzzy mung of, erm
SAM3 ??
Oh well not that important to model the transport/physical boundaries.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Wed, 8 Jan 2003, Mike Anderson wrote:
> Luben Tuikov [luben@splentec.com] wrote:
> > >I'm arguing for a linked list of structs that hold the minimum data we
> > >need to use them as a path - much like a scsi_device with the redundant
> > >fields removed (and if needed it can also point to the actual
> > >scsi_device). And then plugging this data (or a pointer) into a scsi_cmnd
> > >for use by the LLDD.
> >
> > This may be an easier approach, but a scsi_cmnd stands for SCSI command.
> >
>
> but struct scsi_device currently stands for more than the LLDD
> scsi_device. It stands for a block request queue, scsi mid data, and
> scsi host device data.
>
> While in the short term struct scsi_device already exists and appears to
> be the right next progression to use. Future progression of abstraction
> should look at some separation of the LLDD nexus device data and the
> other struct scsi_device data. Maybe in the future part of struct scsi_device
> will be a nexus handle given to the mid layer by the LLDD to represent
> its object which will be plugged into the scsi_cmnd.
>
> > Its a good thing to have multipathing represented as an ADT (abstract
> > data type). Say something like a linked list of structs with
> > cost/weight member and a pointer to an actual low-level device (the
> > infrastructure
> > will be more involved since multipathing will need to be notified
> > when a device goes away, but read further...). Now this ADT may be embeded
> > into a block device and char device structs -- i.e. highest hierarchy.
> > (The assumption is that there won't be a device which will present
> > a char and block interface at the same time.)
> >
> > Now since this ADT is embeded into the block/char device, we do get
> > notification when it goes away. So this should be ok.
> >
> > The effect is that when write(fd, buf, count) is done, somewhere along
> > the way *before* the actual physical device (ide,scsi,etc) is referenced
> > multipathing has already been accomplished. This preserves as much as
> > possible
> > the current infrastructure of the kernel.
> >
> > So when a low-level device (LLD) says that it cannot satisfy the request,
> > you *may* try another path.
> >
> > In effect a low-level device *as seen from the multipath code* is the tuple
> > (PATH, DEVICE), and this is where a request is sent, i.e. to the tuple
> > (PATH, DEVICE). Where for each PATH, there can be exactly one DEVICE, since
> > a PATH describes a device (or access to it), but the opposite is not
> > necessarily
> > true. I.e. for each DEVICE there can be zero/one to many PATHs.
> >
> > >As long as we have an interface (function or macro), I'm not strongly
> > >opposed to the above. We can keep the scsi_allocate_device (in dire need
> > >of a new name), and just have it allocate and init (or not) any fields as
> > >needed, so there is only one place to change the init of the allocated
> > >scsi_cmnd.
> >
> > The SCSI Core has a well-defined funtion. I'm not so sure that we
> > should muck it up with other well-defined functions, like multipathing.
> >
>
> I would counter that moving device and transport knowledge into the
> upper level might also muck up that level.
>
> While it is not difficult to link paths together inside an object it
> becomes more difficult to make good decisions on how to use the paths
> beyond simple fail-over. There are device and platform specific
> characteristics that effect performance and error policy. These
> personalities exist in multipath OS core support in AIX, MS, and
> DYNIX/ptx and vendor specific multi-path support drivers available for
> most OS's. While the implementation is unique to the OS environment the
> need for path personalities is common.
>
> These type of issues are touched on in the mid-multipath document.
>
> > It is *inevitable* that multipathing will be moved up into the
> > generic device char and block structs; sooner or later.
>
> The inevitable hopefully will wait until we get a few more versions of
> the mid-level patch out and discuss code specific pro / cons of mid vs
> upper layer implementations.
>
> -andmike
> --
> Michael Anderson
> andmike@us.ibm.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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: handling of s-record images by bootloader
From: Jon Burgess @ 2003-01-10 12:33 UTC (permalink / raw)
To: atul srivastava; +Cc: linux-mips
atul srivastava wrote:
> I am umware that, how differently s-record image need
> to be handled..?
> i just need some idea or if possible any example code for that..
On second thoughts the binutils code is probably rather large. You could try the
pmon source
http://www.carmel.com/pmon/pmon.tgz
pmon/tools/rdsrec.c might do what you want.
Jon
^ permalink raw reply
* small migration thread fix
From: Erich Focht @ 2003-01-10 12:46 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, linux-kernel, Robert Love
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
Hi,
the small patch fixes a potential problem in the migration thread for
the case that the first CPU in the cpus_allowed mask of a process is
offline. Please consider applying it to your trees.
Thanks!
Regards,
Erich
[-- Attachment #2: migration-fix-2.5.55.patch --]
[-- Type: text/x-diff, Size: 498 bytes --]
diff -urNp linux-2.5.55/kernel/sched.c linux-2.5.55-fix/kernel/sched.c
--- linux-2.5.55/kernel/sched.c 2003-01-09 05:04:22.000000000 +0100
+++ linux-2.5.55-fix/kernel/sched.c 2003-01-10 13:37:40.000000000 +0100
@@ -2108,7 +2108,7 @@ static int migration_thread(void * data)
spin_unlock_irqrestore(&rq->lock, flags);
p = req->task;
- cpu_dest = __ffs(p->cpus_allowed);
+ cpu_dest = __ffs(p->cpus_allowed & cpu_online_map);
rq_dest = cpu_rq(cpu_dest);
repeat:
cpu_src = task_cpu(p);
^ permalink raw reply
* [patch] R4k cache code synchronization
From: Maciej W. Rozycki @ 2003-01-10 12:37 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
Ralf,
Here are some bits to synchronize c-r4k.c across ports. There are no
functional changes, at least no intended ones. OK to apply?
I can't see any need for flush_cache_l1() and flush_cache_l2(). I'd like
to remove them. A single flush_cache_all() seems sufficient for our
needs. Any objections?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
patch-mips-2.4.20-pre6-20030107-mips-c-r4k-sync-0
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips/mm/c-r4k.c
--- linux-mips-2.4.20-pre6-20030107.macro/arch/mips/mm/c-r4k.c 2002-12-20 03:56:50.000000000 +0000
+++ linux-mips-2.4.20-pre6-20030107/arch/mips/mm/c-r4k.c 2003-01-09 22:23:33.000000000 +0000
@@ -948,12 +948,13 @@ static void r4k_flush_icache_page_p(stru
static void r4k_dma_cache_wback_inv_pc(unsigned long addr, unsigned long size)
{
unsigned long end, a;
- unsigned int flags;
if (size >= dcache_size) {
flush_cache_all();
} else {
#ifdef R4600_V2_HIT_CACHEOP_WAR
+ unsigned long flags;
+
/* Workaround for R4600 bug. See comment in <asm/war>. */
local_irq_save(flags);
*(volatile unsigned long *)KSEG1;
@@ -962,7 +963,7 @@ static void r4k_dma_cache_wback_inv_pc(u
a = addr & ~(dc_lsize - 1);
end = (addr + size - 1) & ~(dc_lsize - 1);
while (1) {
- flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+ flush_dcache_line(a); /* Hit_Writeback_Inv_D */
if (a == end) break;
a += dc_lsize;
}
@@ -970,6 +971,7 @@ static void r4k_dma_cache_wback_inv_pc(u
local_irq_restore(flags);
#endif
}
+
bc_wback_inv(addr, size);
}
@@ -994,12 +996,13 @@ static void r4k_dma_cache_wback_inv_sc(u
static void r4k_dma_cache_inv_pc(unsigned long addr, unsigned long size)
{
unsigned long end, a;
- unsigned int flags;
if (size >= dcache_size) {
flush_cache_all();
} else {
#ifdef R4600_V2_HIT_CACHEOP_WAR
+ unsigned long flags;
+
/* Workaround for R4600 bug. See comment in <asm/war>. */
local_irq_save(flags);
*(volatile unsigned long *)KSEG1;
@@ -1008,7 +1011,7 @@ static void r4k_dma_cache_inv_pc(unsigne
a = addr & ~(dc_lsize - 1);
end = (addr + size - 1) & ~(dc_lsize - 1);
while (1) {
- flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+ flush_dcache_line(a); /* Hit_Writeback_Inv_D */
if (a == end) break;
a += dc_lsize;
}
@@ -1016,6 +1019,7 @@ static void r4k_dma_cache_inv_pc(unsigne
local_irq_restore(flags);
#endif
}
+
bc_inv(addr, size);
}
@@ -1031,7 +1035,7 @@ static void r4k_dma_cache_inv_sc(unsigne
a = addr & ~(sc_lsize - 1);
end = (addr + size - 1) & ~(sc_lsize - 1);
while (1) {
- flush_scache_line(a); /* Hit_Writeback_Inv_SD */
+ flush_scache_line(a); /* Hit_Writeback_Inv_SD */
if (a == end) break;
a += sc_lsize;
}
@@ -1232,10 +1236,10 @@ static void __init setup_noscache_funcs(
_flush_cache_page = r4k_flush_cache_page_d32i32;
break;
}
- ___flush_cache_all = _flush_cache_all;
-
_flush_icache_page = r4k_flush_icache_page_p;
+ ___flush_cache_all = _flush_cache_all;
+
_dma_cache_wback_inv = r4k_dma_cache_wback_inv_pc;
_dma_cache_wback = r4k_dma_cache_wback_inv_pc;
_dma_cache_inv = r4k_dma_cache_inv_pc;
@@ -1317,8 +1321,10 @@ static void __init setup_scache_funcs(vo
_copy_page = r4k_copy_page_s128;
break;
}
- ___flush_cache_all = _flush_cache_all;
_flush_icache_page = r4k_flush_icache_page_s;
+
+ ___flush_cache_all = _flush_cache_all;
+
_dma_cache_wback_inv = r4k_dma_cache_wback_inv_sc;
_dma_cache_wback = r4k_dma_cache_wback_inv_sc;
_dma_cache_inv = r4k_dma_cache_inv_sc;
@@ -1373,10 +1379,10 @@ void __init ld_mmu_r4xx0(void)
}
_flush_cache_sigtramp = r4k_flush_cache_sigtramp;
- _flush_icache_range = r4k_flush_icache_range; /* Ouch */
if ((read_c0_prid() & 0xfff0) == 0x2020) {
_flush_cache_sigtramp = r4600v20k_flush_cache_sigtramp;
}
+ _flush_icache_range = r4k_flush_icache_range; /* Ouch */
__flush_cache_all();
}
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
--- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c 2002-12-20 03:56:52.000000000 +0000
+++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c 2003-01-09 23:21:39.000000000 +0000
@@ -950,7 +950,7 @@ static void r4k_dma_cache_wback_inv_pc(u
unsigned long end, a;
if (size >= dcache_size) {
- flush_cache_l1();
+ flush_cache_all();
} else {
#ifdef R4600_V2_HIT_CACHEOP_WAR
unsigned long flags;
@@ -963,7 +963,7 @@ static void r4k_dma_cache_wback_inv_pc(u
a = addr & ~(dc_lsize - 1);
end = (addr + size - 1) & ~(dc_lsize - 1);
while (1) {
- flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+ flush_dcache_line(a); /* Hit_Writeback_Inv_D */
if (a == end) break;
a += dc_lsize;
}
@@ -971,6 +971,7 @@ static void r4k_dma_cache_wback_inv_pc(u
local_irq_restore(flags);
#endif
}
+
bc_wback_inv(addr, size);
}
@@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
unsigned long end, a;
if (size >= scache_size) {
- flush_cache_l1();
+ flush_cache_all();
return;
}
@@ -997,7 +998,7 @@ static void r4k_dma_cache_inv_pc(unsigne
unsigned long end, a;
if (size >= dcache_size) {
- flush_cache_l1();
+ flush_cache_all();
} else {
#ifdef R4600_V2_HIT_CACHEOP_WAR
unsigned long flags;
@@ -1010,7 +1011,7 @@ static void r4k_dma_cache_inv_pc(unsigne
a = addr & ~(dc_lsize - 1);
end = (addr + size - 1) & ~(dc_lsize - 1);
while (1) {
- flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+ flush_dcache_line(a); /* Hit_Writeback_Inv_D */
if (a == end) break;
a += dc_lsize;
}
@@ -1027,14 +1028,14 @@ static void r4k_dma_cache_inv_sc(unsigne
unsigned long end, a;
if (size >= scache_size) {
- flush_cache_l1();
+ flush_cache_all();
return;
}
a = addr & ~(sc_lsize - 1);
end = (addr + size - 1) & ~(sc_lsize - 1);
while (1) {
- flush_scache_line(a); /* Hit_Writeback_Inv_SD */
+ flush_scache_line(a); /* Hit_Writeback_Inv_SD */
if (a == end) break;
a += sc_lsize;
}
@@ -1241,9 +1242,10 @@ static void __init setup_noscache_funcs(
_flush_cache_page = r4k_flush_cache_page_d32i32;
break;
}
-
_flush_icache_page = r4k_flush_icache_page_p;
+ ___flush_cache_all = _flush_cache_all;
+
_dma_cache_wback_inv = r4k_dma_cache_wback_inv_pc;
_dma_cache_wback = r4k_dma_cache_wback_inv_pc;
_dma_cache_inv = r4k_dma_cache_inv_pc;
@@ -1333,6 +1335,9 @@ static void __init setup_scache_funcs(vo
break;
}
_flush_icache_page = r4k_flush_icache_page_s;
+
+ ___flush_cache_all = _flush_cache_all;
+
_dma_cache_wback_inv = r4k_dma_cache_wback_inv_sc;
_dma_cache_wback = r4k_dma_cache_wback_inv_sc;
_dma_cache_inv = r4k_dma_cache_inv_sc;
@@ -1394,5 +1399,5 @@ void __init ld_mmu_r4xx0(void)
_flush_cache_l2 = r4k_flush_cache_l2;
- flush_cache_l1();
+ __flush_cache_all();
}
^ permalink raw reply
* Re: oops while unloading snd-intel8x0
From: Enrik Berkhan @ 2003-01-10 12:37 UTC (permalink / raw)
To: alsa-devel
Hi,
At Tue, 10 Dec 2002 08:39:35 -0800, Takashi Iwai wrote:
> At Tue, 10 Dec 2002 13:50:31 +0100, Christian Guggenberger wrote:
> > I get following oops while unloading snd-intel8x0 on a Dell Optiplex 260
> hmm, it's a new type of oops, which i've never seen.
I had the same problem using a Gericom Frontman (SiS 7012). It turned out
that unregistering the joystick_driver while no joystick had been found
on init caused the oops. Proposed patch:
--- intel8x0.c.orig Mon Oct 28 12:56:35 2002
+++ intel8x0.c Thu Jan 9 13:13:21 2003
@@ -1783,6 +1783,9 @@
} while (time_after_eq(end_time, jiffies));
__ok3:
+ if (chip->device_type == DEVICE_SIS) {
+ iputword(chip, 0x4c, igetword(chip, 0x4c) | 1);
+ }
return 0;
}
@@ -2451,6 +2454,8 @@
return -ENOENT;
}
+ printk("joystick_probe called\n");
+
if (joystick_port[dev] > 0 || mpu_port[dev] > 0) {
u16 val;
pci_read_config_word(pci, 0xe6, &val);
@@ -2490,6 +2495,8 @@
.id_table = snd_intel8x0_joystick_ids,
.probe = snd_intel8x0_joystick_probe,
};
+
+static int have_joystick = 0;
#endif
static int __init alsa_card_intel8x0_init(void)
@@ -2503,7 +2510,13 @@
return err;
}
#if defined(SUPPORT_JOYSTICK) || defined(SUPPORT_MIDI)
- pci_module_init(&joystick_driver);
+ if (pci_module_init(&joystick_driver) < 0) {
+ printk("no joystick found\n");
+ have_joystick = 0;
+ } else {
+ printk("joystick(s) found\n");
+ have_joystick = 1;
+ }
#endif
return 0;
@@ -2513,7 +2526,8 @@
{
pci_unregister_driver(&driver);
#if defined(SUPPORT_JOYSTICK) || defined(SUPPORT_MIDI)
- pci_unregister_driver(&joystick_driver);
+ if (have_joystick)
+ pci_unregister_driver(&joystick_driver);
#endif
}
Cheers,
Enrik
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: urgent question!
From: Cedric Blancher @ 2003-01-10 12:39 UTC (permalink / raw)
To: netfilter
In-Reply-To: <000801c2b7e2$52bcec00$f7ef6c50@dom.local>
Le jeu 09/01/2003 à 14:23, Max ZAUNER a écrit :
> i am rookie in linux. anyway, during my firewall setup everything
> installed properly. after starting my firewall a message pops up
> saying:
> cannot load module: libipt_-j.so
I think you've let a lonely -m switch, meaning without module reference.
cbr@elendil:~$ sudo iptables -A INPUT -m -j
iptables v1.2.7a: Couldn't load match
`-j':/usr/local/lib/iptables/libipt_-j.so: cannot open shared object
file: No such file or directory
--
Cédric Blancher <blancher@cartel-securite.fr>
Consultant en sécurité des systèmes et réseaux - Cartel Sécurité
Tél: +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Alan Cox @ 2003-01-10 13:35 UTC (permalink / raw)
To: Andre Hedrick; +Cc: fverscheure, Linux Kernel Mailing List, Marcelo Tosatti
In-Reply-To: <Pine.LNX.4.10.10301100256240.31168-100000@master.linux-ide.org>
On Fri, 2003-01-10 at 11:14, Andre Hedrick wrote:
> The drive does random and automatic flush caches, if an error happens it
> does not report. *sigh* When APM hits it with a flush and pray the error
> is from this flush, but it does not matter ... the kernel does not have
> the paths to deal this issue ... so bye bye data! Now it if the current
> flush is not the owner of the error OMFG is suggested.
For that matter the BIOS tends to issue the flush, in fact APM is
supposed to be transparent so the BIOS is required to handle it and
since a critical shutdown from the APM PM might not even hit the OS
it has to. Of course pigs also fly 8)
> > > I had a look at patch 2.4.21pre3 and the code looks the same.
> > >
> > > And by the way how are powered off the IDE drives ?
> > > Because a FLUSH CACHE or STANDY or SLEEP is MANDATORY before powering off the
> > > drive with cache enabled or you will enjoy lost data
> >
> > IDE disagrees with itself over this but when we get a controlled power
> > off we do this. The same ATA5/ATA6 problem may well be present there
> > too. I will review both
>
> Not true, the firmware knows to commit the data to platter.
> If it was true you would be screaming long ago.
IDE disagrees with itself because it is meant to work compatibly but if
you run it compatibly you lose data on poweroff.
>
> > Any specific opinion Andre ?
>
> A dirty trick used to date is to pop the STANDY or SLEEP, and depend on
> the drive to deal with the double dirty flush error. If the FLUSH CACHE
> was not valid, the drive would spin back up from STANDY, but not from
> SLEEP, this could be a problem. However SLEEP issued by the driver only
> happens at shutdown unless it has been changed. In the shutdown process,
> each partition unmount was flushed and also once extra when the usage
> count was set to zero. Worst case was 2 flush min.
>
The original question however is whether we are skipping issuing the flush
and sleep on ATA3-5 devices when we should not, because the test is over
strong.
It seems weakening the test is the best option, it fixes ATA-5 and any device
told to sleep, standby or flush that doesn't know the command is just going
to go "Huh ?" and we'll get a nice easy to handle error.
Alan
^ permalink raw reply
* Re: [parisc-linux] ibm-disk on a hp 735/125
From: Nahkola Mikko @ 2003-01-10 12:42 UTC (permalink / raw)
To: parisc-linux; +Cc: parisc-linux
In-Reply-To: <Pine.GSO.4.51.0301091743500.9837@sunhalle66>
On Thu, Jan 09, 2003 at 05:44:31PM +0100, ext Joerg Krebs wrote:
> im running a hp 735/125 with a st31200wd 1GB harddisk, connected to the
> fast-wide scsi-connector, which run's quit nice.
> But now I want to replace the disk with a larger 4,3GB ibm dcas-34330
> disk, but I can't get it be detected by the system, I think i used the
> same jumper settings as on the old seagate drive.
> at the search for potential boot devices nothing appears.
I'd say that probably the IBM disk isn't high-voltage. The 735's
fast-wide is fast-wide-highvoltage-differential, back then they thought
that no one in their right minds would try to do FWSE and no one had
thought about LVD yet, or something...
And IIRC the -wd in the Seagate model code means about that too. I don't
know about IBM specifically.
> So perhaps someones uses the same harddisk and can tell me the right
> jumper-settings, the disk itself works fine with a normal PC with a
> scsi-wide controller.
Well, if it works in a normal PC, that usually means that it isn't HVD. I
only know of two HVD adapters for PCs, Adaptec AHA-1744 and 2944, and
those were always expensive ...
I suppose you could get the disk to work on a single-ended interface or
get an appropriate EISA card.
Besides, do you mean that the 735 FWD interface works in Linux/parisc
nowadays? Great...
--
Mikko Nahkola <mikko.nahkola@nokia.com>
Tre-IN sysadmin <mnahkola@trein.ntc.nokia.com>
^ permalink raw reply
* Re: Severe reiserfs problems
From: Andreas Steinmetz @ 2003-01-10 12:51 UTC (permalink / raw)
To: Robert Szentmihalyi; +Cc: Linux Kernel Mailing List
In-Reply-To: <200301101332.50873.robert.szentmihalyi@entracom.de>
Robert Szentmihalyi wrote:
> Hi,
>
> I have severe file system problems on a reiserfs partition.
> When I try copy files to another filesystem, the kernel panics at certain
> files.
>
> reiserfsck --fix-fixable says that I need to run
> reiserfsck --rebuild-tree to fix the errors, but when I do this,
> reiserfsck hangs after a few secounds.
> Is there a way to rescue at least some of the data on the partition?
>
> Any help is highly appreciated.
>
> TIA,
> Robert
>
>
I had a behaviour somewhat like this once which turned out to be defunct
memory. Though I can't help you with data recovery I would advise you to
run memtest86.
--
Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH
^ permalink raw reply
* KERNEL BUG: assertion failure in reiserfs code
From: Pascal Junod @ 2003-01-10 12:49 UTC (permalink / raw)
To: linux-kernel
Hi,
My /tmp partition is using reiserfs and I get following message when
copying a large file on it (there is enough room, and fsck.reiserfs says
everything is ok...). Is this issue known ? My kernel version is the
linux-2.4.19-gentoo-r10 one.
Please CC me, as I am not on the list...
A+
Pascal
Jan 10 13:38:04 lasecpc29 kernel: reiserfs:warning: CONFIG_REISERFS_CHECK
is set ON
Jan 10 13:38:04 lasecpc29 kernel: reiserfs:warning: - it is slow mode for debugging.
Jan 10 13:38:04 lasecpc29 kernel: reiserfs: checking transaction log (device 03:06) ...
Jan 10 13:38:04 lasecpc29 kernel: journal-1153: found in header: first_unflushed_offset 871, last_flushed_trans_id 1231
Jan 10 13:38:04 lasecpc29 kernel: journal-1206: Starting replay from offset 871, trans_id 1232
Jan 10 13:38:04 lasecpc29 kernel: journal-1299: Setting newest_mount_id to 36
Jan 10 13:38:04 lasecpc29 kernel: Using r5 hash to sort names
Jan 10 13:38:04 lasecpc29 kernel: ReiserFS version 3.6.25
Jan 10 13:38:34 lasecpc29 kernel: vs-4010: is_reusable: block number is out of range 248999 (248999)
Jan 10 13:38:34 lasecpc29 kernel: 0: reiserfs_get_block
Jan 10 13:38:34 lasecpc29 kernel: reiserfs[3234]: assertion !(
(((((s)->u.reiserfs_sb.s_ap_bitmap)[i
])->b_state & (1UL << BH_Lock)) != 0) || is_reusable (s, search_start, 0)
== 0 ) failed at bitmap.c:
417:do_reiserfs_new_blocknrs: vs-4140: bitmap block is locked or bad block number found
Jan 10 13:38:34 lasecpc29 kernel: kernel BUG at prints.c:334!
Jan 10 13:38:34 lasecpc29 kernel: invalid operand: 0000
Jan 10 13:38:34 lasecpc29 kernel: CPU: 0
Jan 10 13:38:34 lasecpc29 kernel: EIP: 0010:[<c0188044>] Not tainted
Jan 10 13:38:34 lasecpc29 kernel: EFLAGS: 00010282
Jan 10 13:38:34 lasecpc29 kernel: eax: 00000101 ebx: 00000000 ecx: 00000001 edx: d8aba000
Jan 10 13:38:34 lasecpc29 kernel: esi: 0003cca7 edi: 00000000 ebp: d8935dc4 esp: d8935cd8
Jan 10 13:38:34 lasecpc29 kernel: ds: 0018 es: 0018 ss: 0018
Jan 10 13:38:34 lasecpc29 kernel: Process scp (pid: 3234, stackpage=d8935000)
Jan 10 13:38:34 lasecpc29 kernel: Stack: c02748da c0334a20 c0282ae0 d8935cf8 ddb42c00 c01769c8 00000000 c0282ae0
Jan 10 13:38:34 lasecpc29 kernel: 00000ca2 000001a1 00000001 d8935dc4 00000007 00004ca7 00000007 0003cca6
Jan 10 13:38:34 lasecpc29 kernel: db83f780 00000000 c0176caa d8935e08 d8935dc4 0003cca7 00000001 00000000
Jan 10 13:38:34 lasecpc29 kernel: Call Trace: [<c01769c8>] [<c0176caa>] [<c017e326>] [<c021e36f>] [<c021e4a4>]
Jan 10 13:38:34 lasecpc29 kernel: [<c017d7d6>] [<c01331ff>] [<c0133946>] [<c017e0ce>] [<c0180984>] [<c017e0ce>]
Jan 10 13:38:34 lasecpc29 kernel: [<c01252e1>] [<c0131150>] [<c0108577>]
Jan 10 13:38:34 lasecpc29 kernel:
Jan 10 13:38:34 lasecpc29 kernel: Code: 0f 0b 4e 01 5e 94 27 c0 85 db 68 20 4a 33 c0 74 0d 0f b7 43
^ permalink raw reply
* Problem of undefined reference
From: sakib mondal @ 2003-01-10 12:52 UTC (permalink / raw)
To: linux-kernel
Hi,
Wish you all a happy new year.
I appologize in case you are getting multiple copies of this message.
I am facing the problem of "undefined reference" for my task of using
extended functionality of linux kernel (2.4.18) as detailed below. I shall
appreciate any suggestion to solve the problem.
I would like to incorporate new functions into linux kernel. Therefore I
created a file f.c with function "void foo()". Source f.c uses header file
f.h. The header file "f.h" has declaration "extern void foo(void);". I
included f.o in the obj-y in the Makefile in the corresponding directory. I
could build the new kernel without any error or warning.
Now, I intended to use the extended functionality of the kernel from my
program. I wrote g.c which calls foo(); I have included header f.h in g.c.
However when I build g, I get the error:
"g.o(.text+ox35): undefined reference to `foo`".
I am unable to understand why "foo" is not resolved as the resident kernel
ius built with object f.o. To diagonose the problem further I did the
follwing things which could neither solve my problem.
i) Used "EXPORT_SYMBOL(foo);" in f.c and had f.o included in export-objs in
the Makefile. ==> I still get the problem of undefined reference
ii) Defined library libf.a based on f.o and included the library for
building g. ==> The kernel is agin built ok. I could see (using nm) that the
symbol foo in defined with type T. However, when building g, I am getting
lot of undefined references to kernel variables and routines that are used
in foo.
I shall appreciate any suggestion or alternative for solving the problem.
TIA.
Sakib
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
^ permalink raw reply
* Suggestion
From: Harry Sileoni @ 2003-01-10 12:52 UTC (permalink / raw)
To: linux-kernel
Hi!
While fighting for some time with my Dell Inspiron 8100 laptop and a new
kernel. No matter what I did in the APM-settings, the computer just
freezed after some minutes of uptime. Now I noticed a page witch
informed me that APIC support should not be used. I disabled APIC
support from the kernel config, and now it works perfect.
So, I suggest you add a line "This option might make your system hang
randomly" to the APIC support help page, so that other innocent people
with the same problem don't have to do hours of fighting with the APM,
which really wasn't the problem as I first though. :)
Thanks for a great kernel, and keep up the good work! :)
^ permalink raw reply
* Re: ACPI problems on Athlon MP system
From: Ducrot Bruno @ 2003-01-10 12:46 UTC (permalink / raw)
To: Martin Siegert; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20030110030741.GA2580-0ze2hujOWYhqr3d4nwidZ7Dks+cytr/Z@public.gmane.org>
On Thu, Jan 09, 2003 at 07:07:41PM -0800, Martin Siegert wrote:
> Hi,
>
> I am not sure whether this is the correct place to ask this question,
> but hopefully you can point me in the right direction.
>
...
> The machine has ACPI enabled in the bios. When I compile the kernel
> with ACPI disabled, the poweroff command shuts down the system, but
> does not shut off the power (it acts exactly like the halt command).
> In order to shutoff the machine I must press the power switch.
>
> When I compile the kernel with ACPI enabled the situation is worse:
> the halt and poweroff commands still work in exactly the same way
> (shutdown the system), but now I cannot switch off the machine
> anymore: pressing the power switch has absolutely no effect
> (regardless of how long I hold the switch). The only way to
ACPI spec require that holding the power switch for 4 second will
switch off the system in *any* case as an emergency power down.
Those if really you can not power down your machine this way,
this is more likely an hardware trouble.
BTW, have you tried the latest ACPI patch on sf.net?
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ 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.