* Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel
From: Takashi Iwai @ 2002-01-08 10:34 UTC (permalink / raw)
To: Jaroslav Kysela
Cc: Abramo Bagnara, Linus Torvalds, J.A. Magallon, Alan Cox, Alan Cox,
Christoph Hellwig, sound-hackers@zabbo.net,
linux-kernel@vger.kernel.org
In-Reply-To: <Pine.LNX.4.31.0201081116300.482-100000@pnote.perex-int.cz>
At Tue, 8 Jan 2002 11:18:34 +0100 (CET),
Jaroslav wrote:
>
> On Tue, 8 Jan 2002, Takashi Iwai wrote:
>
> >
> > > I still have some doubts about hardware specific include files:
> > > a) sound/include
> > > b) drivers/sound/{i2c,isa,pci,ppc}
> > > c) drivers/sound/include
> > >
> > > Currently my vote would go for b), but I see drawbacks for this solution
> > > (for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
> > > better to have a mixed solution (partly b) and partly c)
> >
> > Agreed. The hw specific header files should be bound with *.c code
> > together.
>
> The problem is that we should export some header files to user space as
> well to allow access to hardware related features.
Hmm.. but such programs require the kernel tree anyway, since
/usr/include/linux is ususally no longer symlinked to /usr/src/linux.
Takashi
^ permalink raw reply
* Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel
From: Abramo Bagnara @ 2002-01-08 10:28 UTC (permalink / raw)
To: Takashi Iwai
Cc: Linus Torvalds, Jaroslav Kysela, J.A. Magallon, Alan Cox,
Alan Cox, Christoph Hellwig, sound-hackers, linux-sound,
linux-kernel
In-Reply-To: <s5hk7utgnh3.wl@alsa1.suse.de>
Takashi Iwai wrote:
>
> At Tue, 08 Jan 2002 10:52:16 +0100,
> Abramo wrote:
> >
> >
> > So we'd have:
> > sound/
> > sound/oss_native
> > sound/oss_emul
> > sound/synth
> > sound/include
> > drivers/sound/i2c
> > drivers/sound/isa
> > drivers/sound/pci
> > drivers/sound/ppc
>
> On the list above, to where OSS (hw specific) codes come? Into a
> single directory, sound/oss_native?
Yes
> Or both ALSA and OSS drivers are
> mixed into drivers/sound/*?
> I'd like to see ALSA and OSS codes are separated into different
> directories... Otherwise it's too confusing.
I think that in this way they are separated enough. Do you agree?
>
> And how about drivers/sound/generic for generic hardware codes such as
> ac97_codec.c?
Currently Jaroslav has put that in alsa-kernel/pci/ac97. If we follow
this guideline they go in drivers/pci/ac97 (although I'm not sure
whether ac97 is PCI only).
--
Abramo Bagnara mailto:abramo@alsa-project.org
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
^ permalink raw reply
* Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel
From: Jaroslav Kysela @ 2002-01-08 10:18 UTC (permalink / raw)
To: Takashi Iwai
Cc: Abramo Bagnara, Linus Torvalds, J.A. Magallon, Alan Cox, Alan Cox,
Christoph Hellwig, sound-hackers@zabbo.net,
linux-kernel@vger.kernel.org
In-Reply-To: <s5hk7utgnh3.wl@alsa1.suse.de>
On Tue, 8 Jan 2002, Takashi Iwai wrote:
> At Tue, 08 Jan 2002 10:52:16 +0100,
> Abramo wrote:
> >
> > "J.A. Magallon" wrote:
> > >
> > > On 20020108 Linus Torvalds wrote:
> > > >
> > > >On Mon, 7 Jan 2002, Alan Cox wrote:
> > > >> > Would't it be better to split drivers:
> > > >> >
> > > >> > sound/core.c
> > > >> > sound/alsa/alsa-core.c
> > > >> > sound/alsa/drivers/alsa-emu10k.c
> > > >> > sound/oss/oss-core.c
> > > >> > sound/oss/drivers/oss-emu10k.c
> > > >>
> > > >> Thats much harder to do randomg greps on and to find stuff,than drivers
> > > >> first
> > > >
> > > >I agree. Put drivers separately, let's not split it up more than that.
> > > >
> > >
> > > What would you do with drivers with the same name (source code file)
> > > in alsa and oss ?
> > > Sound is special because you have two implementations of the same subsystem
> > > living together. And eventually in a (near?) future, the oss subtree
> > > will be killed and the alsa one would go up one level, just as is. Much
> > > cleaner. And you will end with
> > >
> > > sound/alsa-core.c
> > > sound/drivers/alsa-driver.c
> >
> > I think it's better to face this big change once and to move the OSS
> > stuff now in its definitive place (where it might be removed in future).
> >
> > So we'd have:
> > sound/
> > sound/oss_native
> > sound/oss_emul
> > sound/synth
> > sound/include
> > drivers/sound/i2c
> > drivers/sound/isa
> > drivers/sound/pci
> > drivers/sound/ppc
>
> On the list above, to where OSS (hw specific) codes come? Into a
> single directory, sound/oss_native? Or both ALSA and OSS drivers are
> mixed into drivers/sound/*?
> I'd like to see ALSA and OSS codes are separated into different
> directories... Otherwise it's too confusing.
>
> And how about drivers/sound/generic for generic hardware codes such as
> ac97_codec.c?
>
>
> > I still have some doubts about hardware specific include files:
> > a) sound/include
> > b) drivers/sound/{i2c,isa,pci,ppc}
> > c) drivers/sound/include
> >
> > Currently my vote would go for b), but I see drawbacks for this solution
> > (for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
> > better to have a mixed solution (partly b) and partly c)
>
> Agreed. The hw specific header files should be bound with *.c code
> together.
The problem is that we should export some header files to user space as
well to allow access to hardware related features.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
^ permalink raw reply
* Re: PCI SCSI interrupt clash
From: Reid Hekman @ 2002-01-08 10:17 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <5.1.0.14.0.20020108203421.00af4940@pop-server.bigpond.net.au>
On Tue, 2002-01-08 at 03:46, Glenn Geers wrote:
> enclose the win2k interrupt allocation for your perusal and comment (it's
> weird!)
...
> System Information report written at: 08/01/2002 08:44:11 PM
> [IRQs]
>
> IRQ Number Device
> 5 Sound Blaster 16 or AWE32 or compatible (WDM)
> 128 Matrox Millennium G400 DualHead MAX
> 14 Primary IDE Channel
> 15 Secondary IDE Channel
> 11 Intel 82371AB/EB PCI to USB Universal Host Controller
> 36 Adaptec AHA-2940U2/U2W PCI SCSI Controller
> 52 Realtek RTL8139/810X Family PCI Fast Ethernet NIC
> 56 Hauppauge Win/TV 878/9 VFW Video Driver
> 56 Hauppauge Win/TV 878/9 VFW Audio Driver
> 60 Creative SB Live! Value (WDM)
> 64 Texas Instruments OHCI Compliant IEEE 1394 Host Controller
> 1 PC/AT Enhanced PS/2 Keyboard (101/102-Key)
> 4 Communications Port (COM1)
> 3 Communications Port (COM2)
> 6 Standard floppy disk controller
> 8 System CMOS/real time clock
> 13 Numeric data processor
> 12 Other Logitech Mouse PS/2
>
> I hope someone can shed some light on the very high (>20) interrupt
> numbers. I'd really like and will help to get to the bottom of the problem.
Win2k with the ACPI HAL will reroute IRQ's to 256 "virtual" IRQ's, hence
the high numbers.
What happens if you twiddle ACPI/PnP OS in the BIOS?
And do you really expect a PCI bus overclocked past 37MHz to survive
with 5 PCI cards? You get 40 lashes with a wet noodle >:-(
Regards,
Reid
^ permalink raw reply
* Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel
From: Takashi Iwai @ 2002-01-08 10:12 UTC (permalink / raw)
To: Abramo Bagnara
Cc: Linus Torvalds, Jaroslav Kysela, J.A. Magallon, Alan Cox,
Alan Cox, Christoph Hellwig, sound-hackers, linux-sound,
linux-kernel
In-Reply-To: <3C3AC150.BE4FFAFE@alsa-project.org>
At Tue, 08 Jan 2002 10:52:16 +0100,
Abramo wrote:
>
> "J.A. Magallon" wrote:
> >
> > On 20020108 Linus Torvalds wrote:
> > >
> > >On Mon, 7 Jan 2002, Alan Cox wrote:
> > >> > Would't it be better to split drivers:
> > >> >
> > >> > sound/core.c
> > >> > sound/alsa/alsa-core.c
> > >> > sound/alsa/drivers/alsa-emu10k.c
> > >> > sound/oss/oss-core.c
> > >> > sound/oss/drivers/oss-emu10k.c
> > >>
> > >> Thats much harder to do randomg greps on and to find stuff,than drivers
> > >> first
> > >
> > >I agree. Put drivers separately, let's not split it up more than that.
> > >
> >
> > What would you do with drivers with the same name (source code file)
> > in alsa and oss ?
> > Sound is special because you have two implementations of the same subsystem
> > living together. And eventually in a (near?) future, the oss subtree
> > will be killed and the alsa one would go up one level, just as is. Much
> > cleaner. And you will end with
> >
> > sound/alsa-core.c
> > sound/drivers/alsa-driver.c
>
> I think it's better to face this big change once and to move the OSS
> stuff now in its definitive place (where it might be removed in future).
>
> So we'd have:
> sound/
> sound/oss_native
> sound/oss_emul
> sound/synth
> sound/include
> drivers/sound/i2c
> drivers/sound/isa
> drivers/sound/pci
> drivers/sound/ppc
On the list above, to where OSS (hw specific) codes come? Into a
single directory, sound/oss_native? Or both ALSA and OSS drivers are
mixed into drivers/sound/*?
I'd like to see ALSA and OSS codes are separated into different
directories... Otherwise it's too confusing.
And how about drivers/sound/generic for generic hardware codes such as
ac97_codec.c?
> I still have some doubts about hardware specific include files:
> a) sound/include
> b) drivers/sound/{i2c,isa,pci,ppc}
> c) drivers/sound/include
>
> Currently my vote would go for b), but I see drawbacks for this solution
> (for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
> better to have a mixed solution (partly b) and partly c)
Agreed. The hw specific header files should be bound with *.c code
together.
Takashi
^ permalink raw reply
* Re: CONFIG_HIMEM instability?
From: Tony Hoyle @ 2002-01-08 10:01 UTC (permalink / raw)
To: Anthony DeRobertis; +Cc: linux-kernel
In-Reply-To: <A44AD072-0364-11D6-BB09-00039355CFA6@suespammers.org>
Anthony DeRobertis wrote:
>> Unfortunately memtest86 is incompatible with this mobo, but the memory
>> checks out on another machine I tried it on, so I expect it's OK.
>
I've had no other instablility problems, and downgrading gkrellm to the
previous version seems to have stopped it dying. Mozilla started being
very unstable at the same time.. it could just be a coincidence that
they all happened at the same time.
> I've had DIMMs not get along. So have other people. This little tester
> seems to find that fairly well, stunningly --- even when Memtest86 can't
> find them at all. It found mine in about 30min (512mb box); another
> persons in an hour or two.
I'll run it & see if anything fails.
> PS: You did report the failure to the memtest86 people, right?
Their website says not to report bugs unless you're prepared to do a
fair bit of debugging yourself. It also says individual problems won't
normally be dealt with... I took the hint and didn't bother.
Tony
^ permalink raw reply
* RE: [PATCH] C undefined behavior fix
From: Bernard Dautrevaux @ 2002-01-08 9:44 UTC (permalink / raw)
To: 'jtv', Bernard Dautrevaux
Cc: 'dewar@gnat.com', paulus, gcc, linux-kernel, trini, velco
> -----Original Message-----
> From: jtv [mailto:jtv@xs4all.nl]
> Sent: Monday, January 07, 2002 10:49 PM
> To: Bernard Dautrevaux
> Cc: 'dewar@gnat.com'; paulus@samba.org; gcc@gcc.gnu.org;
> linux-kernel@vger.kernel.org; trini@kernel.crashing.org;
> velco@fadata.bg
> Subject: Re: [PATCH] C undefined behavior fix
>
>
> On Mon, Jan 07, 2002 at 02:24:35PM +0100, Bernard Dautrevaux wrote:
> >
> > Note however that some may not have noticed, in the
> volatile-using examples,
> > that there is a difference between a "pointer to volatile
> char" and a
> > "volatile pointer to char"; the former, defined as
> "volatile char*" does not
> > help in the case of the RELOC macro, while the latter, written "char
> > *volatile" (note that volatile is now AFTER the '*', not
> before) is a sure
> > fix as the semantics of "volatile" ensure that the compiler
> will NO MORE use
> > the value it PREVIOUSLY knows was the one of the pointer.
>
> One problem I ran into considering 'char *volatile' was this one: the
> compiler is supposed to disable certain optimizations involving
> registerization and such, but isn't it still allowed to do constant
> folding? That would eliminate the pointer from the intermediate code
> altogether, and so the volatile qualifier would be quickly
> forgotten.
> No fixo breako.
>
> Nothing's taking the pointer's address, so the compiler
> _will_ be able
> to prove that (in a sensible universe) no other thread, interrupt,
> kernel code or Angered Rain God will be able to find our
> pointer--much
> less change it.
NO; the standard here is clear: any access to a volatile object is a side
effect (see , and optimization is NOT allowed to eliminate side effects, and
must do them respecting sequence points, even if it determines that the code
will in fact do nothing (see 5.1.2.3, at least in the document I have which
one of the last draft, dated 18th January 1999). That's the whole point of
the volatile specifier.
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------
^ permalink raw reply
* Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel
From: Abramo Bagnara @ 2002-01-08 9:52 UTC (permalink / raw)
To: Linus Torvalds, Jaroslav Kysela
Cc: J.A. Magallon, Alan Cox, Alan Cox, Christoph Hellwig,
sound-hackers, linux-sound, linux-kernel
In-Reply-To: <20020108103046.A3545@werewolf.able.es>
"J.A. Magallon" wrote:
>
> On 20020108 Linus Torvalds wrote:
> >
> >On Mon, 7 Jan 2002, Alan Cox wrote:
> >> > Would't it be better to split drivers:
> >> >
> >> > sound/core.c
> >> > sound/alsa/alsa-core.c
> >> > sound/alsa/drivers/alsa-emu10k.c
> >> > sound/oss/oss-core.c
> >> > sound/oss/drivers/oss-emu10k.c
> >>
> >> Thats much harder to do randomg greps on and to find stuff,than drivers
> >> first
> >
> >I agree. Put drivers separately, let's not split it up more than that.
> >
>
> What would you do with drivers with the same name (source code file)
> in alsa and oss ?
> Sound is special because you have two implementations of the same subsystem
> living together. And eventually in a (near?) future, the oss subtree
> will be killed and the alsa one would go up one level, just as is. Much
> cleaner. And you will end with
>
> sound/alsa-core.c
> sound/drivers/alsa-driver.c
I think it's better to face this big change once and to move the OSS
stuff now in its definitive place (where it might be removed in future).
So we'd have:
sound/
sound/oss_native
sound/oss_emul
sound/synth
sound/include
drivers/sound/i2c
drivers/sound/isa
drivers/sound/pci
drivers/sound/ppc
I still have some doubts about hardware specific include files:
a) sound/include
b) drivers/sound/{i2c,isa,pci,ppc}
c) drivers/sound/include
Currently my vote would go for b), but I see drawbacks for this solution
(for generic chip include files, like ac97 or ak4531 ones). Perhaps it's
better to have a mixed solution (partly b) and partly c)
Will this solution be able to satisfy everybody? ;-)
--
Abramo Bagnara mailto:abramo@alsa-project.org
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
^ permalink raw reply
* Re: [LARTC] Gre Tunneling Problem
From: Christoph Simon @ 2002-01-08 9:48 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101039544916808@msgid-missing>
On Mon, 7 Jan 2002 17:40:47 +0800
"glynn" <glynn@itextron.com> wrote:
> when you configure that tunneling did you reconfigure your kernel? what
> should i enable in my kernel? by the way when i log-on to the linux A, I
> could ping the linux B eth0(internet) and eth1(let say "192.168.1.1")
> but when i ping the "192.168.1.2" which is a windows workstation
> connected to hub it wont pass thru. how do i sniff the interface where
> the packets go, can you help me about that pls. Thanks
So you can ping from 192.168.2.1 to 192.168.1.1, this is good, as it
means that the tunnel definitively is working.
Now, if you try to ping from 192.168.2.1 to 192.168.1.2, the Windows
box, it seems to fail. First I would try to ping from 192.168.1.1 to
192.168.1.2, just to make sure, everything is working fine locally. If
this works too, I would make tcpdump listen at the external interface
of 192.168.2.1. Does the packet actually go out? If not, the routing
or filter problem must be there. If it works, I'd listen on the
external interface of 192.168.1.1; obviously these must arrive because
the tunnel is working and the packet left at the other side. Now you
can listen to the internal interface, seeing if the packet is actually
being forwarded. If this fails, your problem is routing, filtering or
forwarding on 192.168.1.1. Don't know how to sniff on a Windows, but
as the ping from 192.168.1.1 to 192.168.1.2 presumibly worked, there
shouldn't be a need.
If you have access and there is no other traffic, a much simpler
method would be just to watch the leds on the modems, network cards,
hubs, etc. This will help finding out where your problem is. As you
can ping the first computer after the tunnel, I feel sure, the tunnel
is working fine, the problem must be in another place, probably a
stupid little detail.
Note that the suggestion of introducing a different network address
for the tunnel interfaces themselves will slightly complicate
routing. But if you pay attention, this shouldn't be a problem.
--
Christoph Simon
ciccio@kiosknet.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
^ permalink raw reply
* PCI SCSI interrupt clash
From: Glenn Geers @ 2002-01-08 9:46 UTC (permalink / raw)
To: linux-kernel
Hi,
I check the kernel archive and found reference to the PCI interrupt clash
between the 2940 (aic7xxx) and other cards. I also have the problem and it
can lock up my entire machine.
The problem really rears its head when I overclock my box (BX400 dual PIII
450 MHZ) by as little as 10% (504 MHz, 112 MHZ bus). Both my soundblaster
live and my onboard AIC7891 are assigned IRQ 19. My PCI slots are full
(ethernet, 1394 card, soundblaster live, tv card, and Matrox G400). I
enclose the win2k interrupt allocation for your perusal and comment (it's
weird!)
Current kernel version is 2.4.17 but the problem has been evident since
2.4.5 (at least). The 2.2 series does not exhibit the problem.
System Information report written at: 08/01/2002 08:44:11 PM
[IRQs]
IRQ Number Device
5 Sound Blaster 16 or AWE32 or compatible (WDM)
128 Matrox Millennium G400 DualHead MAX
14 Primary IDE Channel
15 Secondary IDE Channel
11 Intel 82371AB/EB PCI to USB Universal Host Controller
36 Adaptec AHA-2940U2/U2W PCI SCSI Controller
52 Realtek RTL8139/810X Family PCI Fast Ethernet NIC
56 Hauppauge Win/TV 878/9 VFW Video Driver
56 Hauppauge Win/TV 878/9 VFW Audio Driver
60 Creative SB Live! Value (WDM)
64 Texas Instruments OHCI Compliant IEEE 1394 Host Controller
1 PC/AT Enhanced PS/2 Keyboard (101/102-Key)
4 Communications Port (COM1)
3 Communications Port (COM2)
6 Standard floppy disk controller
8 System CMOS/real time clock
13 Numeric data processor
12 Other Logitech Mouse PS/2
I hope someone can shed some light on the very high (>20) interrupt
numbers. I'd really like and will help to get to the bottom of the problem.
Regards,
Glenn
^ permalink raw reply
* PATCH 2.5.2-pre9 scsi cleanup
From: Martin Dalecki @ 2002-01-08 9:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
In-Reply-To: <Pine.LNX.4.33.0201011402560.13397-100000@penguin.transmeta.com>
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
The attached patch does the following.
1. Clean up some ifdef confusion in do_mount
2. Clean up the scsi code to make ppa.c work.
3. Clean up some unneccessary unneeded globals from scsi code.
4. Make a bit more sure, that the minor() and friends end up in
unsigned int's.
[-- Attachment #2: cleanup-scsi-2.5.2-pre9.patch --]
[-- Type: text/plain, Size: 16309 bytes --]
diff -ur linux-old/drivers/scsi/dpt_i2o.c linux/drivers/scsi/dpt_i2o.c
--- linux-old/drivers/scsi/dpt_i2o.c Sat May 4 09:11:43 2002
+++ linux/drivers/scsi/dpt_i2o.c Sat May 4 06:54:58 2002
@@ -1551,7 +1551,7 @@
static int adpt_open(struct inode *inode, struct file *file)
{
- int minor;
+ unsigned int minor;
adpt_hba* pHba;
//TODO check for root access
@@ -1584,7 +1584,7 @@
static int adpt_close(struct inode *inode, struct file *file)
{
- int minor;
+ unsigned int minor;
adpt_hba* pHba;
minor = minor(inode->i_rdev);
@@ -1878,7 +1878,7 @@
static int adpt_ioctl(struct inode *inode, struct file *file, uint cmd,
ulong arg)
{
- int minor;
+ unsigned int minor;
int error = 0;
adpt_hba* pHba;
ulong flags;
diff -ur linux-old/drivers/scsi/fcal.c linux/drivers/scsi/fcal.c
--- linux-old/drivers/scsi/fcal.c Fri Feb 9 20:30:23 2001
+++ linux/drivers/scsi/fcal.c Sat May 4 07:47:15 2002
@@ -249,8 +249,6 @@
if (scd->host->host_no == hostno && scd->id == target) {
SPRINTF (" [AL-PA: %02x, Id: %02d, Port WWN: %08x%08x, Node WWN: %08x%08x] ",
alpa, target, u1[0], u1[1], u2[0], u2[1]);
- SPRINTF ("%s ", (scd->type < MAX_SCSI_DEVICE_CODE) ?
- scsi_device_types[(short) scd->type] : "Unknown device");
for (j = 0; (j < 8) && (scd->vendor[j] >= 0x20); j++)
SPRINTF ("%c", scd->vendor[j]);
diff -ur linux-old/drivers/scsi/g_NCR5380.c linux/drivers/scsi/g_NCR5380.c
--- linux-old/drivers/scsi/g_NCR5380.c Sun Sep 30 21:26:07 2001
+++ linux/drivers/scsi/g_NCR5380.c Sat May 4 07:48:21 2002
@@ -789,7 +789,6 @@
struct NCR5380_hostdata *hostdata;
#ifdef NCR5380_STATS
Scsi_Device *dev;
- extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
#endif
save_flags(flags);
cli();
@@ -833,7 +832,7 @@
long tr = hostdata->time_read[dev->id] / HZ;
long tw = hostdata->time_write[dev->id] / HZ;
- PRINTP(" T:%d %s " ANDP dev->id ANDP (dev->type < MAX_SCSI_DEVICE_CODE) ? scsi_device_types[(int)dev->type] : "Unknown");
+ PRINTP(" T:%d " ANDP dev->id );
for (i=0; i<8; i++)
if (dev->vendor[i] >= 0x20)
*(buffer+(len++)) = dev->vendor[i];
diff -ur linux-old/drivers/scsi/ppa.c linux/drivers/scsi/ppa.c
--- linux-old/drivers/scsi/ppa.c Sun Sep 30 21:26:07 2001
+++ linux/drivers/scsi/ppa.c Sat May 4 07:45:50 2002
@@ -115,11 +115,6 @@
int i, nhosts, try_again;
struct parport *pb;
- /*
- * unlock to allow the lowlevel parport driver to probe
- * the irqs
- */
- spin_unlock_irq(&io_request_lock);
pb = parport_enumerate();
printk("ppa: Version %s\n", PPA_VERSION);
@@ -128,7 +123,6 @@
if (!pb) {
printk("ppa: parport reports no devices.\n");
- spin_lock_irq(&io_request_lock);
return 0;
}
retry_entry:
@@ -154,7 +148,6 @@
"pardevice is owning the port for too longtime!\n",
i);
parport_unregister_device(ppa_hosts[i].dev);
- spin_lock_irq(&io_request_lock);
return 0;
}
}
@@ -223,15 +216,12 @@
printk(" supported by the imm (ZIP Plus) driver. If the\n");
printk(" cable is marked with \"AutoDetect\", this is what has\n");
printk(" happened.\n");
- spin_lock_irq(&io_request_lock);
return 0;
}
try_again = 1;
goto retry_entry;
- } else {
- spin_lock_irq(&io_request_lock);
+ } else
return 1; /* return number of hosts detected */
- }
}
/* This is to give the ppa driver a way to modify the timings (and other
@@ -847,9 +837,9 @@
tmp->cur_cmd = 0;
- spin_lock_irqsave(&io_request_lock, flags);
+ spin_lock_irqsave(&cmd->host->host_lock, flags);
cmd->scsi_done(cmd);
- spin_unlock_irqrestore(&io_request_lock, flags);
+ spin_unlock_irqrestore(&cmd->host->host_lock, flags);
return;
}
diff -ur linux-old/drivers/scsi/scsi.c linux/drivers/scsi/scsi.c
--- linux-old/drivers/scsi/scsi.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/scsi.c Sat May 4 07:49:19 2002
@@ -139,25 +139,7 @@
*/
unsigned int scsi_logging_level;
-const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE] =
-{
- "Direct-Access ",
- "Sequential-Access",
- "Printer ",
- "Processor ",
- "WORM ",
- "CD-ROM ",
- "Scanner ",
- "Optical Device ",
- "Medium Changer ",
- "Communications ",
- "Unknown ",
- "Unknown ",
- "Unknown ",
- "Enclosure ",
-};
-
-/*
+/*
* Function prototypes.
*/
extern void scsi_times_out(Scsi_Cmnd * SCpnt);
diff -ur linux-old/drivers/scsi/scsi.h linux/drivers/scsi/scsi.h
--- linux-old/drivers/scsi/scsi.h Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/scsi.h Sat May 4 07:49:38 2002
@@ -89,9 +89,6 @@
#define FALSE 0
#endif
-#define MAX_SCSI_DEVICE_CODE 14
-extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
-
#ifdef DEBUG
#define SCSI_TIMEOUT (5*HZ)
#else
diff -ur linux-old/drivers/scsi/scsi_proc.c linux/drivers/scsi/scsi_proc.c
--- linux-old/drivers/scsi/scsi_proc.c Thu Jun 28 02:10:55 2001
+++ linux/drivers/scsi/scsi_proc.c Sat May 4 07:51:31 2002
@@ -260,7 +260,6 @@
{
int x, y = *size;
- extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
y = sprintf(buffer + len,
"Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n Vendor: ",
@@ -285,13 +284,8 @@
else
y += sprintf(buffer + len + y, " ");
}
- y += sprintf(buffer + len + y, "\n");
-
- y += sprintf(buffer + len + y, " Type: %s ",
- scd->type < MAX_SCSI_DEVICE_CODE ?
- scsi_device_types[(int) scd->type] : "Unknown ");
- y += sprintf(buffer + len + y, " ANSI"
- " SCSI revision: %02x", (scd->scsi_level - 1) ? scd->scsi_level - 1 : 1);
+ y += sprintf(buffer + len + y, "\n ANSI SCSI revision: %02x",
+ (scd->scsi_level - 1) ? scd->scsi_level - 1 : 1);
if (scd->scsi_level == 2)
y += sprintf(buffer + len + y, " CCS\n");
else
diff -ur linux-old/drivers/scsi/scsi_scan.c linux/drivers/scsi/scsi_scan.c
--- linux-old/drivers/scsi/scsi_scan.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/scsi_scan.c Sat May 4 07:52:25 2002
@@ -231,13 +231,7 @@
printk(" ");
}
- printk("\n");
-
- i = data[0] & 0x1f;
-
- printk(" Type: %s ",
- i < MAX_SCSI_DEVICE_CODE ? scsi_device_types[i] : "Unknown ");
- printk(" ANSI SCSI revision: %02x", data[2] & 0x07);
+ printk("\n ANSI SCSI revision: %02x", data[2] & 0x07);
if ((data[2] & 0x07) == 1 && (data[3] & 0x0f) == 1)
printk(" CCS\n");
else
diff -ur linux-old/drivers/scsi/scsi_syms.c linux/drivers/scsi/scsi_syms.c
--- linux-old/drivers/scsi/scsi_syms.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/scsi_syms.c Sat May 4 07:52:50 2002
@@ -87,7 +87,6 @@
EXPORT_SYMBOL(scsi_hostlist);
EXPORT_SYMBOL(scsi_hosts);
EXPORT_SYMBOL(scsi_devicelist);
-EXPORT_SYMBOL(scsi_device_types);
/*
* Externalize timers so that HBAs can safely start/restart commands.
diff -ur linux-old/drivers/scsi/sg.c linux/drivers/scsi/sg.c
--- linux-old/drivers/scsi/sg.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/sg.c Sat May 4 06:56:26 2002
@@ -254,7 +254,7 @@
static int sg_open(struct inode * inode, struct file * filp)
{
- int dev = minor(inode->i_rdev);
+ unsigned int dev = minor(inode->i_rdev);
int flags = filp->f_flags;
Sg_device * sdp;
Sg_fd * sfp;
@@ -1035,7 +1035,7 @@
static void sg_cmd_done_bh(Scsi_Cmnd * SCpnt)
{
Scsi_Request * SRpnt = SCpnt->sc_request;
- int dev = minor(SRpnt->sr_request.rq_dev);
+ unsigned int dev = minor(SRpnt->sr_request.rq_dev);
Sg_device * sdp = NULL;
Sg_fd * sfp;
Sg_request * srp = NULL;
@@ -2687,7 +2687,8 @@
Sg_fd * fp;
Sg_request * srp;
struct scsi_device * scsidp;
- int dev, k, m, blen, usg;
+ unsigned int dev;
+ int k, m, blen, usg;
scsidp = sdp->device;
if (NULL == scsidp) {
diff -ur linux-old/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- linux-old/drivers/scsi/sr.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/sr.c Sat May 4 07:58:13 2002
@@ -99,11 +99,13 @@
static void sr_release(struct cdrom_device_info *cdi)
{
- if (scsi_CDs[minor(cdi->dev)].device->sector_size > 2048)
- sr_set_blocklength(minor(cdi->dev), 2048);
- scsi_CDs[minor(cdi->dev)].device->access_count--;
- if (scsi_CDs[minor(cdi->dev)].device->host->hostt->module)
- __MOD_DEC_USE_COUNT(scsi_CDs[minor(cdi->dev)].device->host->hostt->module);
+ unsigned int minor = minor(cdi->dev);
+
+ if (scsi_CDs[minor].device->sector_size > 2048)
+ sr_set_blocklength(minor, 2048);
+ scsi_CDs[minor].device->access_count--;
+ if (scsi_CDs[minor].device->host->hostt->module)
+ __MOD_DEC_USE_COUNT(scsi_CDs[minor].device->host->hostt->module);
if (sr_template.module)
__MOD_DEC_USE_COUNT(sr_template.module);
}
@@ -145,12 +147,14 @@
int sr_media_change(struct cdrom_device_info *cdi, int slot)
{
int retval;
+ unsigned int minor;
if (CDSL_CURRENT != slot) {
/* no changer support */
return -EINVAL;
}
- retval = scsi_ioctl(scsi_CDs[minor(cdi->dev)].device,
+ minor = minor(cdi->dev);
+ retval = scsi_ioctl(scsi_CDs[minor].device,
SCSI_IOCTL_TEST_UNIT_READY, 0);
if (retval) {
@@ -159,13 +163,13 @@
* and we will figure it out later once the drive is
* available again. */
- scsi_CDs[minor(cdi->dev)].device->changed = 1;
+ scsi_CDs[minor].device->changed = 1;
return 1; /* This will force a flush, if called from
* check_disk_change */
};
- retval = scsi_CDs[minor(cdi->dev)].device->changed;
- scsi_CDs[minor(cdi->dev)].device->changed = 0;
+ retval = scsi_CDs[minor].device->changed;
+ scsi_CDs[minor].device->changed = 0;
/* If the disk changed, the capacity will now be different,
* so we force a re-read of this information */
if (retval) {
@@ -179,9 +183,9 @@
* be trying to use something that is too small if the disc
* has changed.
*/
- scsi_CDs[minor(cdi->dev)].needs_sector_size = 1;
+ scsi_CDs[minor].needs_sector_size = 1;
- scsi_CDs[minor(cdi->dev)].device->sector_size = 2048;
+ scsi_CDs[minor].device->sector_size = 2048;
}
return retval;
}
@@ -250,18 +254,21 @@
static request_queue_t *sr_find_queue(kdev_t dev)
{
+ unsigned int minor = minor(dev);
/*
* No such device
*/
- if (minor(dev) >= sr_template.dev_max || !scsi_CDs[minor(dev)].device)
+ if (minor >= sr_template.dev_max || !scsi_CDs[minor].device)
return NULL;
- return &scsi_CDs[minor(dev)].device->request_queue;
+ return &scsi_CDs[minor].device->request_queue;
}
static int sr_init_command(Scsi_Cmnd * SCpnt)
{
- int dev, devm, block=0, this_count, s_size;
+ int dev;
+ unsigned int devm;
+ int block=0, this_count, s_size;
devm = minor(SCpnt->request.rq_dev);
dev = DEVICE_NR(SCpnt->request.rq_dev);
@@ -397,22 +404,22 @@
static int sr_open(struct cdrom_device_info *cdi, int purpose)
{
+ unsigned int minor = minor(cdi->dev);
check_disk_change(cdi->dev);
- if (minor(cdi->dev) >= sr_template.dev_max
- || !scsi_CDs[minor(cdi->dev)].device) {
+ if (minor >= sr_template.dev_max || !scsi_CDs[minor].device) {
return -ENXIO; /* No such device */
}
/*
* If the device is in error recovery, wait until it is done.
* If the device is offline, then disallow any access to it.
*/
- if (!scsi_block_when_processing_errors(scsi_CDs[minor(cdi->dev)].device)) {
+ if (!scsi_block_when_processing_errors(scsi_CDs[minor].device)) {
return -ENXIO;
}
- scsi_CDs[minor(cdi->dev)].device->access_count++;
- if (scsi_CDs[minor(cdi->dev)].device->host->hostt->module)
- __MOD_INC_USE_COUNT(scsi_CDs[minor(cdi->dev)].device->host->hostt->module);
+ scsi_CDs[minor].device->access_count++;
+ if (scsi_CDs[minor].device->host->hostt->module)
+ __MOD_INC_USE_COUNT(scsi_CDs[minor].device->host->hostt->module);
if (sr_template.module)
__MOD_INC_USE_COUNT(sr_template.module);
@@ -421,8 +428,8 @@
* this is the case, and try again.
*/
- if (scsi_CDs[minor(cdi->dev)].needs_sector_size)
- get_sectorsize(minor(cdi->dev));
+ if (scsi_CDs[minor].needs_sector_size)
+ get_sectorsize(minor);
return 0;
}
@@ -616,7 +623,6 @@
n = buffer[3] + 4;
scsi_CDs[i].cdi.speed = ((buffer[n + 8] << 8) + buffer[n + 9]) / 176;
scsi_CDs[i].readcd_known = 1;
- scsi_CDs[i].readcd_cdda = buffer[n + 5] & 0x01;
/* print some capability bits */
printk("sr%i: scsi3-mmc drive: %dx/%dx %s%s%s%s%s%s\n", i,
((buffer[n + 14] << 8) + buffer[n + 15]) / 176,
@@ -671,13 +677,14 @@
*/
static int sr_packet(struct cdrom_device_info *cdi, struct cdrom_generic_command *cgc)
{
- Scsi_Device *device = scsi_CDs[minor(cdi->dev)].device;
+ unsigned int minor = minor(cdi->dev);
+ Scsi_Device *device = scsi_CDs[minor].device;
/* set the LUN */
if (device->scsi_level <= SCSI_2)
cgc->cmd[1] |= device->lun << 5;
- cgc->stat = sr_do_ioctl(minor(cdi->dev), cgc->cmd, cgc->buffer, cgc->buflen, cgc->quiet, cgc->data_direction, cgc->sense);
+ cgc->stat = sr_do_ioctl(minor, cgc->cmd, cgc->buffer, cgc->buflen, cgc->quiet, cgc->data_direction, cgc->sense);
return cgc->stat;
}
@@ -761,7 +768,6 @@
scsi_CDs[i].device->ten = 1;
scsi_CDs[i].device->remap = 1;
scsi_CDs[i].readcd_known = 0;
- scsi_CDs[i].readcd_cdda = 0;
sr_sizes[i] = scsi_CDs[i].capacity >> (BLOCK_SIZE_BITS - 9);
scsi_CDs[i].cdi.ops = &sr_dops;
diff -ur linux-old/drivers/scsi/sr.h linux/drivers/scsi/sr.h
--- linux-old/drivers/scsi/sr.h Fri Jul 20 06:18:31 2001
+++ linux/drivers/scsi/sr.h Sat May 4 07:58:37 2002
@@ -30,7 +30,6 @@
unsigned use:1; /* is this device still supportable */
unsigned xa_flag:1; /* CD has XA sectors ? */
unsigned readcd_known:1; /* drive supports READ_CD (0xbe) */
- unsigned readcd_cdda:1; /* reading audio data using READ_CD */
struct cdrom_device_info cdi;
} Scsi_CD;
diff -ur linux-old/drivers/scsi/sr_ioctl.c linux/drivers/scsi/sr_ioctl.c
--- linux-old/drivers/scsi/sr_ioctl.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/sr_ioctl.c Sat May 4 06:59:15 2002
@@ -333,7 +333,8 @@
int sr_audio_ioctl(struct cdrom_device_info *cdi, unsigned int cmd, void *arg)
{
u_char sr_cmd[10];
- int result, target = minor(cdi->dev);
+ int result;
+ unsigned int target = minor(cdi->dev);
unsigned char buffer[32];
memset(sr_cmd, 0, sizeof(sr_cmd));
@@ -539,7 +540,7 @@
int sr_dev_ioctl(struct cdrom_device_info *cdi,
unsigned int cmd, unsigned long arg)
{
- int target;
+ unsigned int target;
target = minor(cdi->dev);
diff -ur linux-old/drivers/scsi/sr_vendor.c linux/drivers/scsi/sr_vendor.c
--- linux-old/drivers/scsi/sr_vendor.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/sr_vendor.c Sat May 4 06:59:49 2002
@@ -156,7 +156,8 @@
unsigned long sector;
unsigned char *buffer; /* the buffer for the ioctl */
unsigned char cmd[MAX_COMMAND_SIZE]; /* the scsi-command */
- int rc, no_multi, minor;
+ int rc, no_multi;
+ unsigned int minor;
minor = minor(cdi->dev);
if (scsi_CDs[minor].cdi.mask & CDC_MULTI_SESSION)
diff -ur linux-old/drivers/scsi/wd7000.c linux/drivers/scsi/wd7000.c
--- linux-old/drivers/scsi/wd7000.c Sat May 4 09:11:44 2002
+++ linux/drivers/scsi/wd7000.c Sat May 4 07:59:58 2002
@@ -1469,8 +1469,6 @@
if (scd->host->host_no == hostno) {
SPRINTF (" [Channel: %02d, Id: %02d, Lun: %02d] ",
scd->channel, scd->id, scd->lun);
- SPRINTF ("%s ", (scd->type < MAX_SCSI_DEVICE_CODE) ?
- scsi_device_types[(short) scd->type] : "Unknown device");
for (i = 0; (i < 8) && (scd->vendor[i] >= 0x20); i++)
SPRINTF ("%c", scd->vendor[i]);
diff -ur linux-old/init/do_mounts.c linux/init/do_mounts.c
--- linux-old/init/do_mounts.c Sat May 4 09:11:56 2002
+++ linux/init/do_mounts.c Sat May 4 05:20:30 2002
@@ -364,6 +364,7 @@
return sys_symlink(path + n + 5, name);
}
+#ifdef CONFIG_BLK_DEV_RAM
static void __init change_floppy(char *fmt, ...)
{
struct termios termios;
@@ -392,8 +393,6 @@
}
}
-#ifdef CONFIG_BLK_DEV_RAM
-
int __initdata rd_prompt = 1; /* 1 = prompt for RAM disk, 0 = don't prompt */
static int __init prompt_ramdisk(char *str)
@@ -843,6 +842,7 @@
}
#ifdef BUILD_CRAMDISK
+# ifdef CONFIG_BLK_DEV_RAM
/*
* gzip declarations
@@ -986,5 +986,5 @@
kfree(window);
return result;
}
-
+# endif
#endif /* BUILD_CRAMDISK */
^ permalink raw reply
* Re: [s-h] Re: ALSA patch for 2.5.2pre9 kernel
From: J.A. Magallon @ 2002-01-08 9:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Cox, J.A. Magallon, Alan Cox, Christoph Hellwig,
Jaroslav Kysela, sound-hackers, linux-sound, linux-kernel
In-Reply-To: <20020108102833.A2927@werewolf.able.es>
On 20020108 Linus Torvalds wrote:
>
>On Mon, 7 Jan 2002, Alan Cox wrote:
>> > Would't it be better to split drivers:
>> >
>> > sound/core.c
>> > sound/alsa/alsa-core.c
>> > sound/alsa/drivers/alsa-emu10k.c
>> > sound/oss/oss-core.c
>> > sound/oss/drivers/oss-emu10k.c
>>
>> Thats much harder to do randomg greps on and to find stuff,than drivers
>> first
>
>I agree. Put drivers separately, let's not split it up more than that.
>
What would you do with drivers with the same name (source code file)
in alsa and oss ?
Sound is special because you have two implementations of the same subsystem
living together. And eventually in a (near?) future, the oss subtree
will be killed and the alsa one would go up one level, just as is. Much
cleaner. And you will end with
sound/alsa-core.c
sound/drivers/alsa-driver.c
By
/juan
--
J.A. Magallon # Let the source be with you...
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-pre2-beo #1 SMP Tue Jan 8 03:18:18 CET 2002 i686
^ permalink raw reply
* [Linux-ia64] can we make anonymous memory non-EXECUTABLE?
From: David Mosberger @ 2002-01-08 9:26 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590698805770@msgid-missing>
The traditional intended behavior of Linux is that anonymous memory
has the EXECUTE permission turned on. The reason I say "intended"
behavior is that there appears to be an old bug in the kernel in this
respect. Specifically, the ELF data section is normally mapped with
READ+WRITE permission (no EXECUTE permission). The initial break
value starts at the end of the bss segment and if that value does not
fall on a page boundary (usually it doesn't), it means that the first
few bytes allocated with sbrk() will NOT be EXECUTABLE. Now, on x86
this doesn't matter, because READ permission implies RIGHT permission,
but on ia64 and any other architecture that has a separate EXECUTE
permission, this means that programs cannot rely on memory returned by
malloc() being executable. There is obviously several ways to fix
this problem, but I'm wondering whether it's not time to just say NO
to turning on execute permission by default on anonymous memory.
I discussed this briefly with Linus and his comments are reproduced
below. While I see Linus' points, I do think that turning off EXECUTE
permission on anonymous would improve the security in practice, if not
in theory. But I'd be interested in other people's opinion. Also, as
a practical matter, we currently have special hacks in the ia64 page
fault handler that are needed to work around performance problems that
arise from the fact that we map anonymous memory with EXECUTE rights
by default. Those hacks avoid having to flush the cache for memory
that's mapped executable but never really executed. So clearly there
are technical advantages to not turning on EXECUTE permission, even if
we ignore the security argument.
What I'm wondering: how do others feel about this issue? Since x86
wont be affected by this, I'm especially interested in the opinion of
the maintainers of non-x86 platforms.
It seems to me that for portability reasons, dynamic code generators
should always do an mmap() call to ensure that the generated code is
executable. If we can agree on this as the recommended practice, then
I don't see much of a problem with not turning on the EXECUTE right by
default.
Opinions?
--david
--------------
Comments by Linus:
I would say that the BSS has to be mapped the same way brk() maps things.
They _are_ the same thing, after all - I consider "brk()" to be a system
call that just dynamically changes the BSS limits.
So I would say that we have a few options:
- just explicitly make bss/brk() be non-executable, and tell Compaq that
if they want to do dynamic code generation they should use an anonymous
mapping with MAP_EXEC.
- make both of them always be executable, and say "this is how x86 does
it, security issues don't help", x86 is the Borg, and you _have_ been
assimilated.
- add a per-process flag (that gets copied at fork() and stays alive over
exec()) that allows the system to decide between the two above
dynamically on a process-per-process basis. We could default to the
stricter thing, and people who aren't happy would just make a wrapper
executable (no setuid needed) that sets the flag and executes whatever
process it wants to run that needs to execute BSS.
Quite frankly, my personal preference is "We are the borg of x86" choice,
especially on ia64. The security issue with stack smashing etc is a
complete non-issue: if the program allows a buffer overrun it is insecure
whether EXEC is set or not.
But I suspect you should talk this over on ia64 lists and possibly people
like Alan &co. Feel free to quote this email.
Linus
^ permalink raw reply
* [linux-lvm] summary of what I need to do to mount snapshot on XFS
From: Jeremy Hansen @ 2002-01-08 9:22 UTC (permalink / raw)
To: linux-lvm
I've seen a lot of posts that people do have this working. I was hoping
someone could give a good summary for the steps involved. The goal is
being able to mount the snapshots volume while the live filesystem is
mounted. I see bits and pieces of the answer in various posts, so could
someone break it down for me in a single mail?
Thanks
-jeremy
^ permalink raw reply
* IDE Patch (fwd)
From: Andre Hedrick @ 2002-01-08 9:15 UTC (permalink / raw)
To: linux-kernel
---------- Forwarded message ----------
Date: Sat, 5 Jan 2002 14:17:00 -0500 (EST)
From: Rob Radez <rob@osinvestor.com>
To: Andre Hedrick <andre@linux-ide.org>
Subject: IDE Patch
Hi,
I'm using your ide.2.4.16.12102001 patch with a Promise PDC20269
controller and a Maxtor 160GB hard drive on 2.4.17, and I just wanted to
tell you that it's working great so far.
Thanks for all the great code,
Rob Radez
^ permalink raw reply
* Re: [PATCH] MAX_MP_BUSSES increase
From: James Cleverdon @ 2002-01-08 9:14 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0112261341470.9842-100000@freak.distro.conectiva>
Back from holiday.
On Wednesday 26 December 2001 07:43 am, Marcelo Tosatti wrote:
> James,
>
> Don't remove the "#ifdef CONFIG_MULTIQUAD" on your patch: Let the old max
> (32) for non-multiquad machines.
There's a problem with that -- despite its name, CONFIG_MULTIQUAD is used for
the old NUMA-Q hardware. It turns on some memory mapped port I/O code that
doesn't have any purpose for other machines. The PCI bus overflow happens on
our new Foster-based boxes that may or may not contain multiple quad CPU
boards.
Still, CONFIG_MULTIQUAD is better than nothing. It just may take a little
bit of redefinition, so long as we can coax the various distros to build
their installation and working kernels with CONFIG_MULTIQUAD turned on....
> Please resend me the patch this way.
OK, what do you think about this:
diff -ru 2.4.17/include/asm-i386/mpspec.h
jamesc-2.4.17/include/asm-i386/mpspec.h
--- 2.4.17/include/asm-i386/mpspec.h Thu Nov 22 11:46:18 2001
+++ jamesc-2.4.17/include/asm-i386/mpspec.h Tue Jan 8 01:00:12 2002
@@ -185,12 +186,13 @@
*/
#ifdef CONFIG_MULTIQUAD
-#define MAX_IRQ_SOURCES 512
+#define MAX_MP_BUSSES 257 /* Need max PCI busses for hotplug + 1 for ISA. */
+#define MAX_IRQ_SOURCES (MAX_MP_BUSSES * 4) /* Four intrs per PCI slot. */
#else /* !CONFIG_MULTIQUAD */
+#define MAX_MP_BUSSES 32
#define MAX_IRQ_SOURCES 256
#endif /* CONFIG_MULTIQUAD */
-#define MAX_MP_BUSSES 32
enum mp_bustype {
MP_BUS_ISA = 1,
MP_BUS_EISA,
> On Wed, 19 Dec 2001, James Cleverdon wrote:
> > We've run into a bit of a problem with a forthcoming system. The BIOS
> > reserves so many PCI bus numbers for hotplug when maxed out PCI expansion
> > box(es) are present that some arrays (mp_bus_id_to_node[],
> > mp_bus_id_to_pci_bus[], etc) overflow, splattering important variables.
--
James Cleverdon, IBM xSeries Platform (NUMA), Beaverton
jamesclv@us.ibm.com | cleverdj@us.ibm.com
^ permalink raw reply
* Re: [LARTC] Gre Tunneling Problem
From: Christoph Simon @ 2002-01-08 9:14 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101039544916808@msgid-missing>
On Mon, 7 Jan 2002 14:35:08 +0800
"glynn" <glynn@itextron.com> wrote:
> now im trying to install a new slackware 7, maybe it work :(
I'm running debian here. But I do think, you should try to trace the
problem. Send a ping and sniff on each interface, step by step, where
the packets go and what they look like. Trying different distributions
seems little reasonable for me, but mabe you want to recompile the
kernel just to make sure, everything's OK, no strange patches, etc.
--
Christoph Simon
ciccio@kiosknet.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
^ permalink raw reply
* Re: i810_audio
From: Doug Ledford @ 2002-01-08 9:02 UTC (permalink / raw)
To: Doug Ledford; +Cc: Thomas Gschwind, Nathan Bryant, linux-kernel
In-Reply-To: <3C3AA9AD.6070203@redhat.com>
Doug Ledford wrote:
> Doug Ledford wrote:
>
>
>>> Fixes it applies except for the SiS integration:
>>> * drain_dac
>>> Use interruptible_sleep_on_timeout instead of schedule_timeout.
>>> I think this is cleaner.
>>
>>
>>
>>
>> This is fine.
>
>
>
> Oops, this is one of the mistakes Ben pointed out to me.
> interruptible_sleep_on_timeout(wait_queue head, timeout) overwrites the
> wait queue that we've already added ourselves to. schedule_timeout()
> does the right thing here. (interruptible_sleep_on_timeout doesn't
> really buy us much of anything we care about either, so it's find to
> stay with schedule_timeout)
>
>
>
>
OK, various clean ups made, and enough of the SiS code included that I think
it should work, plus one change to the i810 interrupt handler that will
(hopefully) render the other change you made to get_dma_addr and drain_dac
unnecessary. If people could please download and test the new 0.14 version
of the driver on my site, I would appreciate it.
http://people.redhat.com/dledford/i810_audio.c.gz
--
Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
^ permalink raw reply
* Re: How to Sync properly ?
From: David Woodhouse @ 2002-01-08 9:08 UTC (permalink / raw)
To: Patrick Allaire; +Cc: linux-mtd
In-Reply-To: <9A1957CB9FC45A4FA6F35961093ABB84064B132B@srvmail-mtl.montreal.ubisoft.org>
pallaire@gameloft.com said:
> Do you know any of the standard FS that will support sync ??
Linux has no way to signal to the block device driver that it should flush
the write cache - so _no_ Linux filesystem can get it right, even on
disc drives with write caches. It's just more obvious with the large write
cache on the mtdblock device, that's all.
Linux is broken. Unless Linux gets unbroken and starts to deal with block
devices having internal write caches, the only option you have is to
disable the caching completely.
> because for the moment the dirver for my ST falsh will only write 128k
> at a time ... I would have to change my hardware to use Intel Flash,
> to be able to use JFFS 1 or 2.
I thought you could write the ST flash in 8-byte chunks?
--
dwmw2
^ permalink raw reply
* Question about bi-directional pipes.
From: Martin Rode @ 2002-01-08 8:47 UTC (permalink / raw)
To: linux-kernel
I was just wondering if it is possible under Linux to use popen in a
bi-directional way? I want to use popen under php and must write _and_
read from and to the pipe. Some guy at the php mailing list stated that
this is possible to do with BSD, he wasn't sure about linux.
If this is a kernel issue and not a glibc one, is there a way to get
popen work bi-directionally under linux? Say I want a
pipe = popen ('somefile', 'w+');
return a valid pipe. As it is now, popen (at least under php, but I
think this should be the same), does not return a handle for mode 'w+'.
It does return a handle only for modes 'r' and 'w'.
Regards,
;Martin
--
Dipl.-Kfm. Martin Rode
martin.rode@programmfabrik.de
Programmfabrik GmbH
Frankfurter Allee 73d
10247 Berlin
http://www.programmfabrik.de/
Fon +49-(0)30-4281-8001
Fax +49-(0)30-4281-8008
Funk +49-(0)163-5321400
^ permalink raw reply
* Re: [linux-lvm] SuSe 7.3 snapshot / reiserfs /
From: Chris Mason @ 2002-01-08 8:46 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <3C3AA736.82F90806@knief.net>
On Tuesday, January 08, 2002 12:00:54 AM -0800 Herman Knief
<herman@knief.net> wrote:
> I believe, if you check, that SuSE already has applied thispatch for you.
> If LVM snapshot fails with Reiser, then you should send an email to the
> SuSE list, as they would want to know that they left it out.
Correct, the suse kernel supports lvm snapshots on reiserfs out of the box.
I'd advise grabbing the suse kernel update, as it fixes a few security
problems and updates things to 2.4.16 (+ most patches in 2.4.17).
-chris
^ permalink raw reply
* Re: [patch] O(1) scheduler, -D1, 2.5.2-pre9, 2.4.17
From: FD Cami @ 2002-01-08 8:49 UTC (permalink / raw)
To: mingo; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0201072222100.15970-100000@localhost.localdomain>
Hi all
I'm joining the host of beta testers involved in that patch...
It's currently running on a production machine :
dual PII350 on ASUS P2B-DS
3 SCSI hard drives
512MB of RAM
3C905C
This is a network server running squid-cache www proxy with
a medium load (700 clients on a T3), mysqld, apache, proftpd.
kernel is stock 2.4.17 - and so far, so good.
Cheers,
François Cami
Ingo Molnar wrote:
> On Mon, 7 Jan 2002, Linus Torvalds wrote:
>
>
>>Ingo, looks true. A quick -D2?
>>
>
> yep, Brian is right. I've uploaded -D2:
>
> http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.5.2-D2.patch
>
> other changes:
>
> - make rt_priority 99 map to p->prio 0, rt_priority 0 map to p->prio 99.
>
> - display 'top' priorities correctly, 0-39 for normal processes, negative
> values for RT tasks. (it works just fine it appears.) We did not use to
> display the real priority of RT tasks, but now it's natural.
>
>
>>Oh, and please move console_init() back, other consoles (sparc?) may
>>depend on having PCI layers initialized.
>>
>
> (doh, done too, fix is in -D2.)
>
>
>>Oh, and _I_ don't like "cpu()". What's wrong with the already
>>existing "smp_processor_id()"?
>>
>
> nothing serious, my main problem with it is that it's often too long for
> my 80 chars wide consoles, and it's also too long to type and i use it
> quite often in SMP code.
>
> IIRC we had a 'hard_smp_processor_id()' initially, partly to make it
> harder to use it. (it was very slow because it did an APIC read). But
> these days smp_processor_id() is just as fast (or even faster) as
> 'current'. So i wanted to use cpu() in new code to make it easier to read
> and to make it more compact. But if this is a problem i can remove it.
> I've verified that there is no obvious namespace collisions.
>
> (i've done a quick UP sanity compile + boot of 2.5.2-pre9 + D2, it all
> works as expected.)
>
> Ingo
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* [parisc-linux] any info on 710/Bushmaster Audio available?
From: Enrik Berkhan @ 2002-01-08 8:37 UTC (permalink / raw)
To: parisc-linux
Hi,
I'd like to make the audio part of my 710 usable, even if it's only
'voice quality' according to the LASI docs.
Actually, I can't find much documentation for this part. It's
mentioned in the LASI docs, but no details of course. I understand
that it should be in the "Cobra/Coral I/O ESR", that is not available
yet(?). I found some mails in the list archive promising to make it
available in 1999 ;-) Is there a status? Maybe something like the
"Vivace ESR" would be helpful, too.
Thanks,
Enrik
--
Enrik Berkhan plan b. GmbH
Rüppurrer Straße 4
+49-721-388582 (voice) 76137 Karlsruhe
+49-721-388581 (fax) Germany
^ permalink raw reply
* Re: Hardware Inventory [was: Re: ISA slot detection on PCI systems?]
From: Kevin Easton @ 2002-01-08 8:36 UTC (permalink / raw)
To: linux-kernel; +Cc: david-b
In-Reply-To: <17d401c197ca$a78e66c0$6800000a@brownell.org>
> > Hopefully, integration of /sbin/hotplug during the boot process (using
> > dietHotplug) will reduce the number of things the "coldplug" issue will
> > have to handle.
>
>
> Somewhat -- though it only handles the "load a module"
> subproblem. When new devices need any more setup
> than that, "dietHotplug" isn't enough.
>
>
> - Dave
What if this was handled by the kernel not sending hotplug messages until it
had been told that the system was ready to load drivers etc.
init.d/hotplug tells the kernel that userspace is ready to hear about hotplug
events, and the kernel kicks off by telling /sbin/hotplug about the devices
that are already in the system at startup.
It should probably be a priority or bitmask, rather than a simple on/off
switch, so that the diethotplug in initramfs can be told about the devices
needed for booting (but the TV tuner can wait until the heavyweight hotplug
is around).
...or have I totally misunderstood the coldplug problem?
- Kevin.
^ permalink raw reply
* Re: i810_audio
From: Martin Dalecki @ 2002-01-08 8:22 UTC (permalink / raw)
To: Thomas Gschwind; +Cc: linux-kernel, Nathan Bryant
In-Reply-To: <20020105031329.B6158@infosys.tuwien.ac.at>
Thomas Gschwind wrote:
>
>I have integrated the SiS patches into Doug's code. Chances are that
>
I would just like to report a full sccess with the aforementioned patch.
Hardware is a SIS7012, on a SIS735 chipset board. Even artsd seems to
work fine.
^ 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.