* Re: [parisc-linux] A fix for B2k and CONFIG_PDC_CONSOLE pb
From: Matthew Wilcox @ 2004-01-26 17:25 UTC (permalink / raw)
To: Joel Soete; +Cc: Christoph Plattner, Grant Grundler, parisc-linux
In-Reply-To: <400CB8A100004C60@ocpmta3.freegates.net>
On Mon, Jan 26, 2004 at 06:00:53PM +0100, Joel Soete wrote:
>
> /* Bail if no console input device. */
> - if (!PAGE0->mem_kbd.iodc_io)
> + if ((PAGE0->mem_cons.cl_class != CL_DUPLEX) && !PAGE0->mem_kbd.iodc_io)
> return 0;
>
> /* wait for a keyboard (rs232)-input */
> spin_lock_irqsave(&pdc_lock, flags);
> - real32_call(PAGE0->mem_kbd.iodc_io,
> - (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
> - PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
> - __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
> + if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
This doesn't make sense. PAGE0->mem_cons.cl_class has to be CL_DUPLEX
otherwise the test above would have failed. Do you perhaps mean that &&
above to be an || ? If so, this would all read better as ...
/* wait for a keyboard (rs232)-input */
spin_lock_irqsave(&pdc_lock, flags);
if (PAGE0->mem_cons.cl_class == CL_DUPLEX) {
real32_call(PAGE0->mem_cons.iodc_io,
(unsigned long)PAGE0->mem_cons.hpa, ENTRY_IO_CIN,
PAGE0->mem_cons.spa, __pa(PAGE0->mem_cons.dp.layers),
__pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
} else if (PAGE0->mem_kbd.iodc_io) {
real32_call(PAGE0->mem_kbd.iodc_io,
(unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
__pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
} else {
spin_unlock_irqrestore(&pdc_lock, flags);
return 0;
}
Slightly ugly to have two unlocks for the same lock, but that's better
than duplicating the test. I haven't looked at the code, maybe we could
use a goto instead.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
^ permalink raw reply
* RE: [PATCH] Fix _STA checking in acpi_bus_add
From: Brown, Len @ 2004-01-26 17:20 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: ACPI Developers, Luck, Tony
> Now that you've applied this, we have to resolve the next issue
> I found while investigating this: the chipset config interface
> (CBN/CSFF) is reported as _STA==0x8, i.e., "functioning, but not
> present". We can't find anything in the spec on how to interpret
> this.
Sounds like broken firmware. Not only is it !present, it is !enabled.
The _STA section of the ACPI spec says that if a device isn't
(present && enabled) then it shouldn't even decode its
hardware resources.
> The problem here is that since CBN/CSFF is !present, we won't
> enumerate devices under them. Therefore, we will no longer find
> the AGP bridge on Big Sur.
Oof!
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: New IrDA drivers for 2.6.X
From: Jean Tourrilhes @ 2004-01-26 17:18 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, irda-users, jgarzik, lists
In-Reply-To: <20040123.224124.71115576.davem@redhat.com>
On Fri, Jan 23, 2004 at 10:41:24PM -0800, David S. Miller wrote:
> From: Jean Tourrilhes <jt@bougret.hpl.hp.com>
> Date: Fri, 23 Jan 2004 18:18:28 -0800
>
> Martin Diehl has finished converting all the old style dongle
> driver to the new API. This was the last major feature parity issue
> with 2.4.X, with this work, 2.6.X should support all the IrDA serial
> dongles that 2.4.X supports. Martin also did a few other cleanups and
> fixed tekram-sir so that it works with real hardware.
>
> All applied. I'll queue this up. I'll try to get it in
> now but it may be deferred to the next 2.6.x release.
No problem. Thanks !
Jean
^ permalink raw reply
* Re: partitioning
From: Ken Moffat @ 2004-01-26 17:16 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20040126150458.GA559@lnx2.w8mch.ampr.org>
On Mon, 26 Jan 2004, Hal MacArgle wrote:
> On 01-26, Ken Moffat wrote:
> >
> > If you're going to separate /usr, and the reasons for doing so probably
> > don't apply to many people here, even 3GB should be too much. Depends,
> > of course, on exactly what you put there, but assuming you don't install
> > a _lot_ of things you aren't going to use then 3GB is more than enough
> > for a _full_ system (except /home).
> >
>
> Care to comment on the reasons for putting /usr in it's
> separate partition??
>
Not particularly, but I'll do my best ;)
> For the many personal and home office work stations wouldn't
> that be overkill and not within the KISS philosophy??
>
Yes to overkill. If it's a simple way of making it harder to damage
things then perhaps it's not outwith the spirit of KISS.
> Just curious. Cheers. <grin>
>
> Hal - in Terra Alta, WV - Slackware GNU/Linux 9.0 (2.4.20)
> Utrum Per Hebdomadem Perveniam
> .
As far as I understand, the main reason to separate /usr is to do with
permissions - if it's separate, you can mount it r/o. However, you can
also mount '/' r/o with (quite a lot of planning and) messing about.
I'm sure I've read about people mounting an nfs export at /usr, but that
does assume that all clients are on a similar architecture. My security
knowledge isn't great. I'm sure I've missed out other advantages.
Ken
--
This is a job for Riviera Kid!
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* [patch] pg-r4k.c cp0 hazards for R4000/R4400
From: Maciej W. Rozycki @ 2004-01-26 17:12 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
Ralf,
The R4000/R4400 has a coprocessor 0 hazard when a P-cache operation is
less than two non-load, non-cache instructions apart from a store to the
same line. For processors without a secondary cache, the code in pg-r4k.c
currently issues a Create Dirty Exclusive D-cache operation and then
immediately executes consecutive stores to the same line, therefore
fulfilling the conditions for the hazard.
The following patch changes the problematic operations to be performed on
the cache line following the one to be written immediately. It is safe to
do so, because the cache operations are only a performance hint and are
not required for data coherency. However it is essential not to bypass
the end of the page, so the trailing area of the page is excluded from
these cache operation, similarly to what has already been done for
prefetching.
Actually, I'd like to optimize the functions a bit further, specifically
to avoid multiple cacheops to the same line (if you don't mind), but
currently I'd like to apply this change to assure correct operation. As I
have no non-SC R4000/R4400 system, this was untested, but perhaps studying
the problem covered by the -scache patch sent previously will show if the
hazard is indeed avoided.
The patch also increases the buffers a bit for three reasons:
1. copy_page_array is already too small for the 128-byte S-cache line
case. ;-)
2. The trail for non-SC R4000/R4400 increases buffer consumption and I was
too lazy to calculate the requirements.
3. The planned optimization will likely require a little bit more space as
well.
BTW, I was unable to reproduce your instruction count calculation for the
prefetch case; other results seem OK.
OK to apply?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
patch-mips-2.4.24-pre2-20040116-mips-pg-r4k-hazard-7
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c 2004-01-26 16:05:38.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c 2004-01-26 16:06:21.000000000 +0000
@@ -34,7 +34,7 @@
* With prefetching, 16 byte strides 0xa0 bytes
*/
-static unsigned int clear_page_array[0xa0 / 4];
+static unsigned int clear_page_array[0x100 / 4];
void clear_page(void * page) __attribute__((alias("clear_page_array")));
@@ -46,7 +46,7 @@ void clear_page(void * page) __attribute
* R4600 v2.0: 0x84 bytes
* With prefetching, 16 byte strides 0xb8 bytes
*/
-static unsigned int copy_page_array[0xb8 / 4];
+static unsigned int copy_page_array[0x100 / 4];
void copy_page(void *to, void *from) __attribute__((alias("copy_page_array")));
@@ -159,7 +159,7 @@ static inline void build_cdex(void)
mi.c_format.rs = 4; /* $a0 */
mi.c_format.c_op = 3; /* Create Dirty Exclusive */
mi.c_format.cache = 1; /* Data Cache */
- mi.c_format.simmediate = store_offset;
+ mi.c_format.simmediate = store_offset + cpu_dcache_line_size();
*epc++ = mi.word;
}
@@ -300,6 +300,8 @@ static inline void build_jr_ra(void)
void __init build_clear_page(void)
{
+ int lead_size, loop_size;
+
epc = (unsigned int *) &clear_page_array;
if (cpu_has_prefetch) {
@@ -316,7 +318,20 @@ void __init build_clear_page(void)
}
}
- build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
+ if (cpu_has_prefetch)
+ lead_size = PAGE_SIZE - pref_offset_clear;
+ else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+ loop_size = 4;
+ if (cpu_has_64bit_registers)
+ loop_size *= 2;
+ loop_size *= 8;
+ if (loop_size < cpu_dcache_line_size())
+ loop_size = cpu_dcache_line_size();
+ lead_size = PAGE_SIZE - loop_size;
+ } else
+ lead_size = PAGE_SIZE;
+
+ build_addiu_a2_a0(lead_size);
if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
*epc++ = 0x40026000; /* mfc0 $v0, $12 */
@@ -354,8 +369,8 @@ dest = epc;
build_bne(dest);
build_store_reg(0);
- if (cpu_has_prefetch && pref_offset_clear) {
- build_addiu_a2_a0(pref_offset_clear);
+ if (lead_size < PAGE_SIZE) {
+ build_addiu_a2_a0(PAGE_SIZE - lead_size);
dest = epc;
__build_store_reg(0);
__build_store_reg(0);
@@ -383,9 +398,26 @@ dest = epc;
void __init build_copy_page(void)
{
+ int lead_size, loop_size;
+
epc = (unsigned int *) ©_page_array;
- build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
+ if (cpu_has_prefetch)
+ lead_size = PAGE_SIZE - pref_offset_copy;
+ else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+ loop_size = 4;
+#ifdef CONFIG_MIPS64
+ loop_size *= 2;
+#endif
+ loop_size *= 8;
+ if (loop_size < cpu_dcache_line_size())
+ loop_size = cpu_dcache_line_size();
+ lead_size = PAGE_SIZE - loop_size;
+ } else
+ lead_size = PAGE_SIZE;
+
+ build_addiu_a2_a0(lead_size);
+
if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
*epc++ = 0x40026000; /* mfc0 $v0, $12 */
@@ -440,8 +472,8 @@ dest = epc;
build_bne(dest);
build_store_reg(11);
- if (cpu_has_prefetch && pref_offset_copy) {
- build_addiu_a2_a0(pref_offset_copy);
+ if (lead_size < PAGE_SIZE) {
+ build_addiu_a2_a0(PAGE_SIZE - lead_size);
dest = epc;
__build_load_reg( 8);
__build_load_reg( 9);
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c 2004-01-26 16:05:38.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c 2004-01-26 16:06:21.000000000 +0000
@@ -34,7 +34,7 @@
* With prefetching, 16 byte strides 0xa0 bytes
*/
-static unsigned int clear_page_array[0xa0 / 4];
+static unsigned int clear_page_array[0x100 / 4];
void clear_page(void * page) __attribute__((alias("clear_page_array")));
@@ -46,7 +46,7 @@ void clear_page(void * page) __attribute
* R4600 v2.0: 0x84 bytes
* With prefetching, 16 byte strides 0xb8 bytes
*/
-static unsigned int copy_page_array[0xb8 / 4];
+static unsigned int copy_page_array[0x100 / 4];
void copy_page(void *to, void *from) __attribute__((alias("copy_page_array")));
@@ -159,7 +159,7 @@ static inline void build_cdex(void)
mi.c_format.rs = 4; /* $a0 */
mi.c_format.c_op = 3; /* Create Dirty Exclusive */
mi.c_format.cache = 1; /* Data Cache */
- mi.c_format.simmediate = store_offset;
+ mi.c_format.simmediate = store_offset + cpu_dcache_line_size();
*epc++ = mi.word;
}
@@ -300,6 +300,8 @@ static inline void build_jr_ra(void)
void __init build_clear_page(void)
{
+ int lead_size, loop_size;
+
epc = (unsigned int *) &clear_page_array;
if (cpu_has_prefetch) {
@@ -316,7 +318,20 @@ void __init build_clear_page(void)
}
}
- build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
+ if (cpu_has_prefetch)
+ lead_size = PAGE_SIZE - pref_offset_clear;
+ else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+ loop_size = 4;
+ if (cpu_has_64bit_registers)
+ loop_size *= 2;
+ loop_size *= 8;
+ if (loop_size < cpu_dcache_line_size())
+ loop_size = cpu_dcache_line_size();
+ lead_size = PAGE_SIZE - loop_size;
+ } else
+ lead_size = PAGE_SIZE;
+
+ build_addiu_a2_a0(lead_size);
if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
*epc++ = 0x40026000; /* mfc0 $v0, $12 */
@@ -354,8 +369,8 @@ dest = epc;
build_bne(dest);
build_store_reg(0);
- if (cpu_has_prefetch && pref_offset_clear) {
- build_addiu_a2_a0(pref_offset_clear);
+ if (lead_size < PAGE_SIZE) {
+ build_addiu_a2_a0(PAGE_SIZE - lead_size);
dest = epc;
__build_store_reg(0);
__build_store_reg(0);
@@ -383,9 +398,26 @@ dest = epc;
void __init build_copy_page(void)
{
+ int lead_size, loop_size;
+
epc = (unsigned int *) ©_page_array;
- build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
+ if (cpu_has_prefetch)
+ lead_size = PAGE_SIZE - pref_offset_copy;
+ else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+ loop_size = 4;
+#ifdef CONFIG_MIPS64
+ loop_size *= 2;
+#endif
+ loop_size *= 8;
+ if (loop_size < cpu_dcache_line_size())
+ loop_size = cpu_dcache_line_size();
+ lead_size = PAGE_SIZE - loop_size;
+ } else
+ lead_size = PAGE_SIZE;
+
+ build_addiu_a2_a0(lead_size);
+
if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
*epc++ = 0x40026000; /* mfc0 $v0, $12 */
@@ -440,8 +472,8 @@ dest = epc;
build_bne(dest);
build_store_reg(11);
- if (cpu_has_prefetch && pref_offset_copy) {
- build_addiu_a2_a0(pref_offset_copy);
+ if (lead_size < PAGE_SIZE) {
+ build_addiu_a2_a0(PAGE_SIZE - lead_size);
dest = epc;
__build_load_reg( 8);
__build_load_reg( 9);
^ permalink raw reply
* es1968 locks up on rmmod
From: Carl-Daniel Hailfinger @ 2004-01-26 17:12 UTC (permalink / raw)
To: alsa-devel
Hi,
I have a Toshiba 4100XCDT laptop with an ES1968 chip. lspci follows:
00:0c.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E (rev 10)
Subsystem: Toshiba America Info Systems ES1978 Maestro-2E Audiodrive
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at fc00 [size=256]
Capabilities: <available only to root>
When the init scripts try to unload snd_es1968 on shutdown, my machine
freezes instantly.
Distribution is SUSE 9.0 Professional. Kernel is kernel-default-26-2.6.1-4
from ftp.suse.com/pub/people/kraxel which is basically 2.6.2-rc1.
I assume the lockup happens because interrupts are not disabled for the
device.
Debug traces are not available since SysRq-T and SysRq-P do not work. The
nmi watchdog does not work on my hardware. The only SysRq keys that work
are "O" and "B" to switch the machine off/reboot it.
Right now, I can disable the rmmod, but that's not a solution for long.
Please take a look at the module unloading function and fix it if possible.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Bluetooth USB oopses on unplug (2.6.1)
From: Marcel Holtmann @ 2004-01-26 17:09 UTC (permalink / raw)
To: Pavel Machek; +Cc: Linux Kernel Mailing List, Max Krasnyansky
In-Reply-To: <20040126161625.GB227@elf.ucw.cz>
Hi Pavel,
> > However show us the oops (through ksymoops) and show us your USB
> > hardware on your motherboard (lspci).
>
> pavel@amd:~$ lspci
> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3188 (rev 01)
> 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device b188
> 00:0a.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller
> 00:0c.0 Network controller: Broadcom Corporation BCM94306 802.11g (rev 02)
> 00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80)
> 00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80)
> 00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80)
> 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
> 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
> 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235 AC97 Audio Controller (rev 50)
> 00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80)
> 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
> 00:13.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 02)
> pavel@amd:~$
>
> I'll have to hand-copy the oops, as machine dies after unplug. Here it
> is:
>
> Oops: 2
> EIP is at uhci_remov_pending_qhs
> Call trace:
> uhci_irq
> usb_hcd_irq
> handle_irq_event
> do_IRQ
> common_interrupt_1
as I expected. It is an UHCI host adapter and it looks like the uhci_hcd
driver has problems to unlink the ISOC URB's. Look at the LKML and USB
mailing lists for similiar post. At the moment I don't know of any patch
for it. Sorry.
Regards
Marcel
^ permalink raw reply
* Re: INT14 waiting for character
From: Stas Sergeev @ 2004-01-26 17:06 UTC (permalink / raw)
To: linux-msdos; +Cc: Donald Arseneau
Hello.
Donald Arseneau wrote:
> Is there any hope of getting a version of INT14 that waits for
> a character?
Doing this is practically trivial.
You have to rewrite that subfunction
(ah=2) in asm and put it into bios.S,
since it is not possible to do a
waiting poll inside dosemu itself.
The rest of int14 will stay where
it is now, only the polling part
must go into bios.S.
We already have such a thing for the
keyboard handling (the polling part
is in bios.S, rest is in int16.c),
so you have a place where to take a
look.
> (Is Mark Rejhon still involved?)
No, but the serial code still gets
some attention nevertheless (depends
on what dosemu version you are using
however).
^ permalink raw reply
* RE: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: James Bottomley @ 2004-01-26 17:05 UTC (permalink / raw)
To: Moore, Eric Dean; +Cc: SCSI Mailing List, hch
In-Reply-To: <0E3FA95632D6D047BA649F95DAB60E5703D19D33@exa-atlanta.se.lsil.com>
On Mon, 2004-01-26 at 11:01, Moore, Eric Dean wrote:
> I will work on that.
Thanks.
> I had avoided it due the comments in the code
> from sralston and pdelaney about sg interface
> gererating wrong direction in some cases.
If you find a problem, I'll fix the generic code...
James
^ permalink raw reply
* Re: [Bluez-users] phone+heaset
From: Marcel Holtmann @ 2004-01-26 17:04 UTC (permalink / raw)
To: João Santos; +Cc: BlueZ Mailing List
In-Reply-To: <Sea2-F67d4kbAoqKLn1000424f3@hotmail.com>
Hi Joao,
> > > >ACL data: handle 0x0028 flags 0x02 dlen 21
> > > L2CAP(d): cid 0x41 len 17 [psm 1]
> > > SDP SA Req: tid 0x53 len 0xc
> > > hndl 0x804f738
> > > max 0xff
> > > aid(s) 0x0302 ((null))
> > > cont 00
> > > < ACL data: handle 0x0028 flags 0x02 dlen 14
> > > L2CAP(d): cid 0x41 len 10 [psm 1]
> > > SDP SA Rsp: tid 0x53 len 0x5
> > > cnt 0x2
> > >
> > > cont 00
> >
> >it seems that your problem is here. The SDP record must be correct
> >otherwise it won't work.
>
> Thanks for answer my last question.
> could you explain me better what's the problem, i think i 'm doing it right:
it requests the attribute 0x0302 and it is not in your record. This is
the record for the HBH-10. Look at it and compare.
Sequence
Attribute 0x0000 - Service record handle
UINT32 0x00010000
Attribute 0x0001 - Service class ID list
Sequence
UUID16 0x1203 - Generic Audio
UUID16 0x1108 - Headset
Attribute 0x0004 - Protocol descriptor list
Sequence
Sequence
UUID16 0x0100 - L2CAP
Sequence
UUID16 0x0003 - RFCOMM
UINT8 0x06
Attribute 0x0009 - Bluetooth profile descriptor list
Sequence
Sequence
UUID16 0x1108 - Headset
UINT16 0x0100
Attribute 0x0100
String Headset
Attribute 0x0302
Bool True
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* compiling kernel 2.6
From: Luca Ferrari @ 2004-01-26 17:03 UTC (permalink / raw)
To: linux-config
(posted also in linux-admin@vgr.kernel.org)
Hi to all,
I'm trying to compile the kernel 2.6 for a file server, but before I'm trying
it on my laptop (compaq nx9010), but I've got some problems.
In fact, after the reboot it doesn't appear any message on the screen, and the
disk seem freezed (i.e., the system does not load). I've followed the faq on
such problem but I haven't solved it yet. My .config file should be ok:
luca@linux:/usr/src/linux> grep CONFIG_V .config
CONFIG_VLAN_8021Q=m
CONFIG_VORTEX=m
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
# CONFIG_VIDEO_DEV is not set
CONFIG_VIDEO_SELECT=y
CONFIG_VGA_CONSOLE=y
CONFIG_VFAT_FS=m
CONFIG_VXFS_FS=m
and I've got the modutils required
fluca:~ # /usr/local/sbin/depmod --version
module-init-tools 0.9.13
I'm going crazy, why I cannot compile the new kernel?
--
Luca Ferrari,
fluca1978@virgilio.it
^ permalink raw reply
* scheduler crash 2.6.2-rc1-mm2
From: Chmouel Boudjnah @ 2004-01-26 18:02 UTC (permalink / raw)
To: linux-kernel
Hi,
I don't have a proper way to reproduce it (it crashed while the
cmputer was idle and i was in the shower) but i am going to test -rc2
and -rc1-mm3
version:
2.6.2-rc1-mm2 : gcc version 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk)
dmesg:
request_module: failed /sbin/modprobe -- char-major-81-0. error = 256
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
request_module: failed /sbin/modprobe -- sound-service-1-0. error = 256
request_module: failed /sbin/modprobe -- sound-service-1-0. error = 256
request_module: failed /sbin/modprobe -- char-major-116-0. error = 256
request_module: failed /sbin/modprobe -- char-major-116-0. error = 256
request_module: failed /sbin/modprobe -- char-major-116-0. error = 256
request_module: failed /sbin/modprobe -- sound-service-1-0. error = 256
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
Badness in interruptible_sleep_on_timeout at kernel/sched.c:2245
Call Trace:
[<c011d765>] interruptible_sleep_on_timeout+0xf5/0x130
[<c011d290>] default_wake_function+0x0/0x10
[<e08fbdcf>] cm_write+0x51f/0x7b0 [cmpci]
[<c0154de0>] vfs_write+0xb0/0x110
[<c0154ee8>] sys_write+0x38/0x60
[<c02488a6>] sysenter_past_esp+0x43/0x65
request_module: failed /sbin/modprobe -- char-major-116-0. error = 256
request_module: failed /sbin/modprobe -- sound-service-1-0. error = 256
request_module: failed /sbin/modprobe -- sound-service-1-0. error = 256
Cheers,
--
Travel's around the world - http://www.chmouel.com/
^ permalink raw reply
* Re: [ANNOUNCE] Cooperative Linux
From: Ben Pfaff @ 2004-01-26 17:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel
In-Reply-To: <20040126091900.A29544@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
> On Sun, Jan 25, 2004 at 08:59:52PM -0800, Ben Pfaff wrote:
>> For what it's worth, this has been done in the proprietary world
>> as successful commercial software, as VMware ESX Server.
>
> Which seems to be nothing more than a hacked up Linux..
Not even close to true. ESX Server includes a hacked up Linux as
part of its front end, but there's a lot more than that.
--
"...dans ce pays-ci il est bon de tuer de temps en temps un amiral
pour encourager les autres."
--Voltaire, _Candide_
^ permalink raw reply
* RE: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: Moore, Eric Dean @ 2004-01-26 17:01 UTC (permalink / raw)
To: James Bottomley; +Cc: SCSI Mailing List, hch
I will work on that.
I had avoided it due the comments in the code
from sralston and pdelaney about sg interface
gererating wrong direction in some cases.
Eric
On Monday, January 26, 2004 9:45 AM, James Bottomley wrote:
> On Mon, 2004-01-26 at 10:37, Moore, Eric Dean wrote:
> > Here is another update for the MPT Fusion drivers.
>
> Thanks.
>
> > * added CONFIG_LBA, READ16, WRITE16 support
>
> I'd like to see this routine to determine direction go away
> in favour of
> just using the direction the mid layer sends down. However,
> this isn't
> a blocking item, I'll try and get this update into early 2.6.2
>
> James
>
>
^ permalink raw reply
* [parisc-linux] A fix for B2k and CONFIG_PDC_CONSOLE pb
From: Joel Soete @ 2004-01-26 17:00 UTC (permalink / raw)
To: Grant Grundler, Christoph Plattner; +Cc: parisc-linux
In-Reply-To: <20040124210320.GA16272@colo.lackof.org>
[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]
Hi Grant, Christoph,
I find a fix for this pb. I tested successfully (I reach to login with a
ttyB0 after replacing ttyS0 in inittab and telinit q :) ) on a 32bit 2.4
kernel on my b2k and a 64bit (up) [also 2.4] kernel on my N4k.
Here is its main part:
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/firmware.c
linux-2.4.24-pa0/arch/parisc/kernel/firmware.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/firmware.c 2003-10-02 07:30:55.000000000
+0200
+++ linux-2.4.24-pa0/arch/parisc/kernel/firmware.c 2004-01-26 16:48:23.000000000
+0100
@@ -871,15 +937,21 @@
int status;
/* Bail if no console input device. */
- if (!PAGE0->mem_kbd.iodc_io)
+ if ((PAGE0->mem_cons.cl_class != CL_DUPLEX) && !PAGE0->mem_kbd.iodc_io)
return 0;
/* wait for a keyboard (rs232)-input */
spin_lock_irqsave(&pdc_lock, flags);
- real32_call(PAGE0->mem_kbd.iodc_io,
- (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
- PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
- __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
+ if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
+ real32_call(PAGE0->mem_cons.iodc_io,
+ (unsigned long)PAGE0->mem_cons.hpa, ENTRY_IO_CIN,
+ PAGE0->mem_cons.spa, __pa(PAGE0->mem_cons.dp.layers),
+ __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
+ else
+ real32_call(PAGE0->mem_kbd.iodc_io,
+ (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
+ PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
+ __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
ch = *iodc_dbuf;
status = *iodc_retbuf;
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/pdc_cons.c
linux-2.4.24-pa0/arch/parisc/kernel/pdc_cons.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/pdc_cons.c 2004-01-19 07:25:46.000000000
+0100
+++ linux-2.4.24-pa0/arch/parisc/kernel/pdc_cons.c 2004-01-26 16:53:32.000000000
+0100
@@ -113,10 +112,6 @@
return;
++pdc_console_initialized;
- /* If the console is duplex then copy the COUT parameters to CIN. */
- if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
- memcpy(&PAGE0->mem_kbd, &PAGE0->mem_cons, sizeof(PAGE0->mem_cons));
-
/* register the pdc console */
register_console(&pdc_cons);
}
==========><==========
Can somebody else could also test it on some other platform to be sure I
don't broken other stuff?
Thanks in advance,
Joel
PS: Grant I join the text file of the final backport of 2.6 work included
this patch. Thanks in advance for your attention
-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr
[-- Attachment #2: pdc_console-bp+patch.diff --]
[-- Type: application/octet-stream, Size: 23324 bytes --]
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/entry.S linux-2.4.24-pa0/arch/parisc/kernel/entry.S
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/entry.S 2003-12-05 07:42:32.000000000 +0100
+++ linux-2.4.24-pa0/arch/parisc/kernel/entry.S 2004-01-22 13:22:04.000000000 +0100
@@ -2227,9 +2227,12 @@
STREG %r28,TASK_PT_GR28-TASK_SZ_ALGN-FRAME_SIZE(%r30)
+#ifdef CONFIG_HPUX
+
/* Save other hpux returns if personality is PER_HPUX */
-#define PER_HPUX 0xe /* <linux/personality.h> cannot be easily included */
+/* <linux/personality.h> cannot be easily included */
+#define PER_HPUX 0xe
LDREG TASK_PERSONALITY-TASK_SZ_ALGN-FRAME_SIZE(%r30),%r19
CMPIB<>,n PER_HPUX,%r19,1f
@@ -2237,6 +2240,8 @@
STREG %r29,TASK_PT_GR29-TASK_SZ_ALGN-FRAME_SIZE(%r30)
1:
+#endif /* CONFIG_HPUX */
+
/* Seems to me that dp could be wrong here, if the syscall involved
* calling a module, and nothing got round to restoring dp on return.
*/
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/firmware.c linux-2.4.24-pa0/arch/parisc/kernel/firmware.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/firmware.c 2003-10-02 07:30:55.000000000 +0200
+++ linux-2.4.24-pa0/arch/parisc/kernel/firmware.c 2004-01-26 16:48:23.000000000 +0100
@@ -1,10 +1,22 @@
-/* arch/parisc/kernel/firmware.c - safe pdc access routines
+/*
+ * arch/parisc/kernel/firmware.c - safe PDC access routines
+ *
+ * PDC == Processor Dependent Code
+ *
+ * See http://www.parisc-linux.org/documentation/index.html
+ * for documentation describing the entry points and calling
+ * conventions defined below.
*
* Copyright 1999 SuSE GmbH Nuernberg (Philipp Rumpf, prumpf@tux.org)
- * portions Copyright 1999 The Puffin Group, (Alex deVries, David Kennedy)
+ * Copyright 1999 The Puffin Group, (Alex deVries, David Kennedy)
+ * Copyright 2003 Grant Grundler <grundler parisc-linux org>
*
- * only these routines should be used out of the real kernel (i.e. everything
- * using virtual addresses) for obvious reasons */
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
/* I think it would be in everyone's best interest to follow this
* guidelines when writing PDC wrappers:
@@ -41,19 +53,19 @@
* prumpf 991016
*/
+#include <stdarg.h>
+
+#include <linux/delay.h>
+#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/spinlock.h>
-#include <linux/init.h>
-#include <linux/delay.h>
#include <asm/page.h>
#include <asm/pdc.h>
#include <asm/system.h>
#include <asm/processor.h> /* for boot_cpu_data */
-#include <stdarg.h>
-
static spinlock_t pdc_lock = SPIN_LOCK_UNLOCKED;
static unsigned long pdc_result[32] __attribute__ ((aligned (8)));
static unsigned long pdc_result2[32] __attribute__ ((aligned (8)));
@@ -70,9 +82,9 @@
*/
#ifdef __LP64__
-static long real64_call(unsigned long function, ...);
+long real64_call(unsigned long function, ...);
#endif
-static long real32_call(unsigned long function, ...);
+long real32_call(unsigned long function, ...);
#if defined(__LP64__) && ! defined(CONFIG_PDC_NARROW)
#define MEM_PDC (unsigned long)(PAGE0->mem_pdc_hi) << 32 | PAGE0->mem_pdc
@@ -143,13 +155,13 @@
*/
int pdc_add_valid(unsigned long address)
{
- int retval;
+ int retval;
- spin_lock_irq(&pdc_lock);
- retval = mem_pdc_call(PDC_ADD_VALID, PDC_ADD_VALID_VERIFY, address);
- spin_unlock_irq(&pdc_lock);
+ spin_lock_irq(&pdc_lock);
+ retval = mem_pdc_call(PDC_ADD_VALID, PDC_ADD_VALID_VERIFY, address);
+ spin_unlock_irq(&pdc_lock);
- return retval;
+ return retval;
}
/**
@@ -162,18 +174,18 @@
*/
int __init pdc_chassis_info(struct pdc_chassis_info *chassis_info, void *led_info, unsigned long len)
{
- int retval;
+ int retval;
- spin_lock_irq(&pdc_lock);
- memcpy(&pdc_result, chassis_info, sizeof(*chassis_info));
- memcpy(&pdc_result2, led_info, len);
- retval = mem_pdc_call(PDC_CHASSIS, PDC_RETURN_CHASSIS_INFO,
- __pa(pdc_result), __pa(pdc_result2), len);
- memcpy(chassis_info, pdc_result, sizeof(*chassis_info));
- memcpy(led_info, pdc_result2, len);
- spin_unlock_irq(&pdc_lock);
+ spin_lock_irq(&pdc_lock);
+ memcpy(&pdc_result, chassis_info, sizeof(*chassis_info));
+ memcpy(&pdc_result2, led_info, len);
+ retval = mem_pdc_call(PDC_CHASSIS, PDC_RETURN_CHASSIS_INFO,
+ __pa(pdc_result), __pa(pdc_result2), len);
+ memcpy(chassis_info, pdc_result, sizeof(*chassis_info));
+ memcpy(led_info, pdc_result2, len);
+ spin_unlock_irq(&pdc_lock);
- return retval;
+ return retval;
}
/**
@@ -187,9 +199,9 @@
{
if (!is_pdc_pat())
return -1;
-
+
int retval = 0;
-
+
spin_lock_irq(&pdc_lock);
retval = mem_pdc_call(PDC_PAT_CHASSIS_LOG, PDC_PAT_CHASSIS_WRITE_LOG, __pa(&state), __pa(&data));
spin_unlock_irq(&pdc_lock);
@@ -224,18 +236,18 @@
*/
int __init pdc_coproc_cfg(struct pdc_coproc_cfg *pdc_coproc_info)
{
- int retval;
+ int retval;
- spin_lock_irq(&pdc_lock);
- retval = mem_pdc_call(PDC_COPROC, PDC_COPROC_CFG, __pa(pdc_result));
- convert_to_wide(pdc_result);
- pdc_coproc_info->ccr_functional = pdc_result[0];
- pdc_coproc_info->ccr_present = pdc_result[1];
- pdc_coproc_info->revision = pdc_result[17];
- pdc_coproc_info->model = pdc_result[18];
- spin_unlock_irq(&pdc_lock);
+ spin_lock_irq(&pdc_lock);
+ retval = mem_pdc_call(PDC_COPROC, PDC_COPROC_CFG, __pa(pdc_result));
+ convert_to_wide(pdc_result);
+ pdc_coproc_info->ccr_functional = pdc_result[0];
+ pdc_coproc_info->ccr_present = pdc_result[1];
+ pdc_coproc_info->revision = pdc_result[17];
+ pdc_coproc_info->model = pdc_result[18];
+ spin_unlock_irq(&pdc_lock);
- return retval;
+ return retval;
}
/**
@@ -537,8 +549,8 @@
* o cable too long (ie SE scsi 10Mhz won't support 6m length),
* o bus width exported is less than what the interface chip supports.
*/
-int pdc_get_initiator( struct hardware_path *hwpath, unsigned char *scsi_id,
- unsigned long *period, char *width, char *mode)
+int pdc_get_initiator(struct hardware_path *hwpath, unsigned char *scsi_id,
+ unsigned long *period, char *width, char *mode)
{
int retval;
@@ -556,41 +568,38 @@
/* convert Bus speed in Mhz to period (in 1/10 ns) */
switch(pdc_result[1]) {
- /*
- ** case 0: driver determines rate
- ** case -1: Settings are uninitialized.
- */
- case 5: *period = 2000; break;
- case 10: *period = 1000; break;
- case 20: *period = 500; break;
- case 40: *period = 250; break;
- default: /* Do nothing */ break;
+ /*
+ * case 0: driver determines rate
+ * case -1: Settings are uninitialized.
+ */
+ case 5: *period = 2000; break;
+ case 10: *period = 1000; break;
+ case 20: *period = 500; break;
+ case 40: *period = 250; break;
+ default: /* Do nothing */ break;
}
/*
- ** pdc_result[2] PDC suggested SCSI id
- ** pdc_result[3] PDC suggested SCSI rate
- */
+ * pdc_result[2] PDC suggested SCSI id
+ * pdc_result[3] PDC suggested SCSI rate
+ */
/* C3000 and similar workstations report period/mode */
if (IS_SPROCKETS()) {
- /*
- ** 0 == 8-bit
- ** 1 == 16-bit
- */
+ /* 0 == 8-bit, 1 == 16-bit */
*width = (char) pdc_result[4];
/* ...in case someone needs it in the future.
- ** sym53c8xx.c comments say it can't autodetect
- ** for 825/825A/875 chips.
- ** 0 == SE, 1 == HVD, 2 == LVD
- */
+ * sym53c8xx.c comments say it can't autodetect
+ * for 825/825A/875 chips.
+ * 0 == SE, 1 == HVD, 2 == LVD
+ */
*mode = (char) pdc_result[5];
}
}
spin_unlock_irq(&pdc_lock);
- return retval >= PDC_OK;
+ return (retval >= PDC_OK);
}
@@ -640,6 +649,49 @@
}
+#if 0 /* UNTEST CODE - left here in case someone needs it */
+
+/*
+ * pdc_pci_config_read - read PCI config space.
+ * @hpa token from PDC to indicate which PCI device
+ * @pci_addr configuration space address to read from
+ *
+ * Read PCI Configuration space *before* linux PCI subsystem is running.
+ */
+unsigned int pdc_pci_config_read(void *hpa, unsigned long cfg_addr)
+{
+ int retval;
+ spin_lock_irq(&pdc_lock);
+ pdc_result[0] = 0;
+ pdc_result[1] = 0;
+ retval = mem_pdc_call(PDC_PCI_INDEX, PDC_PCI_READ_CONFIG,
+ __pa(pdc_result), hpa, cfg_addr&~3UL, 4UL);
+ spin_unlock_irq(&pdc_lock);
+ return retval ? ~0 : (unsigned int) pdc_result[0];
+}
+
+
+/*
+ * pdc_pci_config_write - read PCI config space.
+ * @hpa token from PDC to indicate which PCI device
+ * @pci_addr configuration space address to write
+ * @val value we want in the 32-bit register
+ *
+ * Write PCI Configuration space *before* linux PCI subsystem is running.
+ */
+void pdc_pci_config_write(void *hpa, unsigned long cfg_addr, unsigned int val)
+{
+ int retval;
+ spin_lock_irq(&pdc_lock);
+ pdc_result[0] = 0;
+ retval = mem_pdc_call(PDC_PCI_INDEX, PDC_PCI_WRITE_CONFIG,
+ __pa(pdc_result), hpa,
+ cfg_addr&~3UL, 4UL, (unsigned long) val);
+ spin_unlock_irq(&pdc_lock);
+ return retval;
+}
+#endif /* UNTESTED CODE */
+
/**
* pdc_tod_read - Read the Time-Of-Day clock.
* @tod: The return buffer:
@@ -770,20 +822,34 @@
}
/*
- * pdc_suspend_usb - Stop USB controller
+ * pdc_io_reset - Hack to avoid overlapping range registers of Bridges devices.
+ * Primarily a problem on T600 (which parisc-linux doesn't support) but
+ * who knows what other platform firmware might do with this OS "hook".
+ */
+void pdc_io_reset(void)
+{
+ spin_lock_irq(&pdc_lock);
+ mem_pdc_call(PDC_IO, PDC_IO_RESET, 0);
+ spin_unlock_irq(&pdc_lock);
+}
+
+/*
+ * pdc_io_reset_devices - Hack to Stop USB controller
*
* If PDC used the usb controller, the usb controller
* is still running and will crash the machines during iommu
* setup, because of still running DMA. This PDC call
- * stops the USB controller
+ * stops the USB controller.
+ * Normally called after calling pdc_io_reset().
*/
-void pdc_suspend_usb(void)
+void pdc_io_reset_devices(void)
{
spin_lock_irq(&pdc_lock);
- mem_pdc_call(PDC_IO, PDC_IO_SUSPEND_USB, 0);
+ mem_pdc_call(PDC_IO, PDC_IO_RESET_DEVICES, 0);
spin_unlock_irq(&pdc_lock);
}
+
/**
* pdc_iodc_putc - Console character print using IODC.
* @c: the character to output.
@@ -871,15 +937,21 @@
int status;
/* Bail if no console input device. */
- if (!PAGE0->mem_kbd.iodc_io)
+ if ((PAGE0->mem_cons.cl_class != CL_DUPLEX) && !PAGE0->mem_kbd.iodc_io)
return 0;
/* wait for a keyboard (rs232)-input */
spin_lock_irqsave(&pdc_lock, flags);
- real32_call(PAGE0->mem_kbd.iodc_io,
- (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
- PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
- __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
+ if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
+ real32_call(PAGE0->mem_cons.iodc_io,
+ (unsigned long)PAGE0->mem_cons.hpa, ENTRY_IO_CIN,
+ PAGE0->mem_cons.spa, __pa(PAGE0->mem_cons.dp.layers),
+ __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
+ else
+ real32_call(PAGE0->mem_kbd.iodc_io,
+ (unsigned long)PAGE0->mem_kbd.hpa, ENTRY_IO_CIN,
+ PAGE0->mem_kbd.spa, __pa(PAGE0->mem_kbd.dp.layers),
+ __pa(iodc_retbuf), 0, __pa(iodc_dbuf), 1, 0);
ch = *iodc_dbuf;
status = *iodc_retbuf;
@@ -1065,7 +1137,7 @@
/* in reality, there's nearly 8k of stack after this */
};
-static long real32_call(unsigned long fn, ...)
+long real32_call(unsigned long fn, ...)
{
va_list args;
extern struct narrow_stack real_stack32;
@@ -1116,7 +1188,7 @@
/* in reality, there's nearly 8k of stack after this */
};
-static long real64_call(unsigned long fn, ...)
+long real64_call(unsigned long fn, ...)
{
va_list args;
extern struct wide_stack real_stack64;
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/inventory.c linux-2.4.24-pa0/arch/parisc/kernel/inventory.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/inventory.c 2003-08-04 08:00:00.000000000 +0200
+++ linux-2.4.24-pa0/arch/parisc/kernel/inventory.c 2004-01-26 16:36:05.000000000 +0100
@@ -167,9 +167,6 @@
static int __init
pat_query_module(ulong pcell_loc, ulong mod_index)
{
-#ifdef DEBUG_PAT
- pdc_pat_cell_mod_maddr_block_t io_pdc_cell;
-#endif
pdc_pat_cell_mod_maddr_block_t pa_pdc_cell;
unsigned long bytecnt;
unsigned long temp; /* 64-bit scratch value */
@@ -209,6 +206,7 @@
register_parisc_device(dev); /* advertise device */
#ifdef DEBUG_PAT
+ pdc_pat_cell_mod_maddr_block_t io_pdc_cell;
/* dump what we see so far... */
switch (PAT_GET_ENTITY(dev->mod_info)) {
unsigned long i;
@@ -527,12 +525,6 @@
int i;
long status = PDC_OK;
- /*
- * first stop the usb controller, otherwise the machine
- * might crash during iommu setup
- */
- pdc_suspend_usb();
-
for (i = 0; status != PDC_BAD_PROC && status != PDC_NE_MOD; i++) {
struct parisc_device *dev;
struct pdc_system_map_mod_info module_result;
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/pdc_cons.c linux-2.4.24-pa0/arch/parisc/kernel/pdc_cons.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/pdc_cons.c 2004-01-19 07:25:46.000000000 +0100
+++ linux-2.4.24-pa0/arch/parisc/kernel/pdc_cons.c 2004-01-26 16:53:32.000000000 +0100
@@ -43,7 +43,6 @@
* On production kernels EARLY_BOOTUP_DEBUG should be undefined. */
#undef EARLY_BOOTUP_DEBUG
-
#include <linux/config.h>
#include <linux/kernel.h>
#include <linux/console.h>
@@ -82,7 +81,7 @@
#if defined(CONFIG_PDC_CONSOLE) || defined(CONFIG_SERIAL_MUX)
#define PDC_CONSOLE_DEVICE pdc_console_device
-static kdev_t pdc_console_device (struct console *c)
+static kdev_t pdc_console_device(struct console *c)
{
return MKDEV(MUX_MAJOR, 0);
}
@@ -91,18 +90,18 @@
#endif
static struct console pdc_cons = {
- name: "ttyB",
- write: pdc_console_write,
+ .name = "ttyB",
+ .write = pdc_console_write,
#warning UPSTREAM 2.4.19 removed the next 4 lines but we did not
- read: NULL,
- device: PDC_CONSOLE_DEVICE,
- unblank: NULL,
- setup: pdc_console_setup,
- flags: CON_BOOT|CON_PRINTBUFFER|CON_ENABLED,
- index: -1,
+ .read = NULL,
+ .device = PDC_CONSOLE_DEVICE,
+ .unblank = NULL,
+ .setup = pdc_console_setup,
+ .flags = CON_BOOT|CON_PRINTBUFFER|CON_ENABLED,
+ .index = -1,
};
-static int pdc_console_initialized;
+static int pdc_console_initialized = 0;
extern unsigned long con_start; /* kernel/printk.c */
extern unsigned long log_end; /* kernel/printk.c */
@@ -113,10 +112,6 @@
return;
++pdc_console_initialized;
- /* If the console is duplex then copy the COUT parameters to CIN. */
- if (PAGE0->mem_cons.cl_class == CL_DUPLEX)
- memcpy(&PAGE0->mem_kbd, &PAGE0->mem_cons, sizeof(PAGE0->mem_cons));
-
/* register the pdc console */
register_console(&pdc_cons);
}
@@ -164,7 +159,7 @@
return;
while ((console = console_drivers) != NULL)
- unregister_console(console_drivers);
+ unregister_console(console);
/* Don't repeat what we've already printed */
con_start = log_end;
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/real2.S linux-2.4.24-pa0/arch/parisc/kernel/real2.S
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/real2.S 2003-09-22 09:06:22.000000000 +0200
+++ linux-2.4.24-pa0/arch/parisc/kernel/real2.S 2004-01-22 16:52:43.000000000 +0100
@@ -13,7 +13,7 @@
.section .bss
.export real_stack32
#ifdef __LP64__
- .export real_stack64
+ .export real_stack64
#endif
.align 64
real_stack32:
diff -NaurX dontdiff linux-2.4.24-pa0.orig/arch/parisc/kernel/sba_iommu.c linux-2.4.24-pa0/arch/parisc/kernel/sba_iommu.c
--- linux-2.4.24-pa0.orig/arch/parisc/kernel/sba_iommu.c 2002-12-03 08:07:12.000000000 +0100
+++ linux-2.4.24-pa0/arch/parisc/kernel/sba_iommu.c 2004-01-26 16:24:03.000000000 +0100
@@ -579,7 +579,8 @@
if (pide >= (ioc->res_size << 3)) {
pide = sba_search_bitmap(ioc, pages_needed);
if (pide >= (ioc->res_size << 3))
- panic(__FILE__ ": I/O MMU @ %lx is out of mapping resources\n", ioc->ioc_hpa);
+ panic("%s: I/O MMU @ %lx is out of mapping resources\n",
+ __FILE__, ioc->ioc_hpa);
}
#ifdef ASSERT_PDIR_SANITY
@@ -904,8 +905,8 @@
*
* See Documentation/DMA-mapping.txt
*/
-static void
-sba_unmap_single(struct pci_dev *dev, dma_addr_t iova, size_t size, int direction)
+static void sba_unmap_single(struct pci_dev *dev, dma_addr_t iova, size_t size,
+ int direction)
{
struct ioc *ioc;
#if DELAYED_RESOURCE_CNT > 0
@@ -974,8 +975,8 @@
*
* See Documentation/DMA-mapping.txt
*/
-static void *
-sba_alloc_consistent(struct pci_dev *hwdev, size_t size, dma_addr_t *dma_handle)
+static void *sba_alloc_consistent(struct pci_dev *hwdev, size_t size,
+ dma_addr_t *dma_handle)
{
void *ret;
@@ -1006,7 +1007,8 @@
* See Documentation/DMA-mapping.txt
*/
static void
-sba_free_consistent(struct pci_dev *hwdev, size_t size, void *vaddr, dma_addr_t dma_handle)
+sba_free_consistent(struct pci_dev *hwdev, size_t size, void *vaddr,
+ dma_addr_t dma_handle)
{
sba_unmap_single(hwdev, dma_handle, size, 0);
free_pages((unsigned long) vaddr, get_order(size));
@@ -1113,7 +1115,7 @@
/*
** Two address ranges are DMA contiguous *iff* "end of prev" and
-** "start of next" are both on a page boundry.
+** "start of next" are both on a page boundary.
**
** (shift left is a quick trick to mask off upper bits)
*/
@@ -1131,7 +1133,7 @@
* in the DMA stream. Allocates PDIR entries but does not fill them.
* Returns the number of DMA chunks.
*
- * Doing the fill seperate from the coalescing/allocation keeps the
+ * Doing the fill separate from the coalescing/allocation keeps the
* code simpler. Future enhancement could make one pass through
* the sglist do both.
*/
@@ -1218,7 +1220,7 @@
** can't change. And we need the offset from the first
** chunk - not the last one. Ergo Successive chunks
** must start on page boundaries and dove tail
- ** with it's predecessor.
+ ** with its predecessor.
*/
sg_dma_len(vcontig_sg) = vcontig_len;
@@ -1268,7 +1270,8 @@
* See Documentation/DMA-mapping.txt
*/
static int
-sba_map_sg(struct pci_dev *dev, struct scatterlist *sglist, int nents, int direction)
+sba_map_sg(struct pci_dev *dev, struct scatterlist *sglist, int nents,
+ int direction)
{
struct ioc *ioc;
int coalesced, filled = 0;
@@ -1350,7 +1353,8 @@
* See Documentation/DMA-mapping.txt
*/
static void
-sba_unmap_sg(struct pci_dev *dev, struct scatterlist *sglist, int nents, int direction)
+sba_unmap_sg(struct pci_dev *dev, struct scatterlist *sglist, int nents,
+ int direction)
{
struct ioc *ioc;
#ifdef ASSERT_PDIR_SANITY
@@ -1395,15 +1399,15 @@
}
static struct pci_dma_ops sba_ops = {
- sba_dma_supported,
- sba_alloc_consistent, /* allocate cacheable host mem */
- sba_free_consistent, /* release cacheable host mem */
- sba_map_single,
- sba_unmap_single,
- sba_map_sg,
- sba_unmap_sg,
- NULL, /* dma_sync_single */
- NULL /* dma_sync_sg */
+ .dma_supported = sba_dma_supported,
+ .alloc_consistent = sba_alloc_consistent, /* allocate cacheable host mem */
+ .free_consistent = sba_free_consistent, /* release cacheable host mem */
+ .map_single = sba_map_single,
+ .unmap_single = sba_unmap_single,
+ .map_sg = sba_map_sg,
+ .unmap_sg = sba_unmap_sg,
+ .dma_sync_single = NULL,
+ .dma_sync_sg = NULL,
};
@@ -1678,6 +1682,22 @@
int num_ioc;
u64 ioc_ctl;
+ if (!is_pdc_pat()) {
+ /*
+ * Shutdown the USB controller on Astro-based workstations.
+ * Once we reprogram the IOMMU, the next DMA performed by
+ * USB will HPMC the box.
+ */
+ pdc_io_reset_devices();
+
+ /*
+ * XXX May need something more sophisticated to deal
+ * with DMA from LAN. Maybe use page zero boot device
+ * as a handle to talk to PDC about which device to
+ * shutdown. This also needs to work for is_pdc_pat().
+ */
+ }
+
ioc_ctl = READ_REG(sba_dev->sba_hpa+IOC_CTRL);
DBG_INIT("%s() hpa 0x%lx ioc_ctl 0x%Lx ->",
__FUNCTION__, sba_dev->sba_hpa, ioc_ctl);
@@ -1728,9 +1748,10 @@
{
int i;
- /* add this one to the head of the list (order doesn't matter)
- ** This will be useful for debugging - especially if we get coredumps
- */
+ /*
+ * add this one to the head of the list (order doesn't matter)
+ * This will be useful for debugging - especially if we get coredumps
+ */
sba_dev->next = sba_list;
sba_list = sba_dev;
@@ -1764,7 +1785,8 @@
if (NULL == sba_dev->ioc[i].res_map)
{
- panic(__FILE__ ":%s() could not allocate resource map\n", __FUNCTION__ );
+ panic("%s:%s() could not allocate resource map\n",
+ __FILE__, __FUNCTION__);
}
memset(sba_dev->ioc[i].res_map, 0, res_size);
@@ -1918,9 +1940,9 @@
int sba_driver_callback(struct parisc_device *);
static struct parisc_driver sba_driver = {
- name: MODULE_NAME,
- id_table: sba_tbl,
- probe: sba_driver_callback,
+ .name = MODULE_NAME,
+ .id_table = sba_tbl,
+ .probe = sba_driver_callback,
};
/*
diff -NaurX dontdiff linux-2.4.24-pa0.orig/include/asm-parisc/pdc.h linux-2.4.24-pa0/include/asm-parisc/pdc.h
--- linux-2.4.24-pa0.orig/include/asm-parisc/pdc.h 2002-10-04 07:48:47.000000000 +0200
+++ linux-2.4.24-pa0/include/asm-parisc/pdc.h 2004-01-26 12:51:25.000000000 +0100
@@ -191,8 +191,8 @@
#define PDC_IO 135 /* log error info, reset IO system */
#define PDC_IO_READ_AND_CLEAR_ERRORS 0
-#define PDC_IO_READ_AND_LOG_ERRORS 1
-#define PDC_IO_SUSPEND_USB 2
+#define PDC_IO_RESET 1
+#define PDC_IO_RESET_DEVICES 2
/* sets bits 6&7 (little endian) of the HcControl Register */
#define PDC_IO_USB_SUSPEND 0xC000000000000000
#define PDC_IO_EEPROM_IO_ERR_TABLE_FULL -5 /* return value */
@@ -476,7 +476,11 @@
#define PDC_TYPE_SYSTEM_MAP 1 /* 32-bit, but supports PDC_SYSTEM_MAP */
#define PDC_TYPE_SNAKE 2 /* Doesn't support SYSTEM_MAP */
-#define is_pdc_pat() (pdc_type == PDC_TYPE_PAT)
+#ifdef CONFIG_PARISC64
+#define is_pdc_pat() (PDC_TYPE_PAT == pdc_type)
+#else
+#define is_pdc_pat() (0)
+#endif
struct pdc_chassis_info { /* for PDC_CHASSIS_INFO */
unsigned long actcnt; /* actual number of bytes returned */
@@ -897,7 +901,7 @@
__u32 pad608[126];
};
-#endif /* __ASSEMBLY__ */
+#endif /* !__ASSEMBLY__ */
/* Page Zero constant offsets used by the HPMC handler */
@@ -951,7 +955,8 @@
int pdc_do_reset(void);
int pdc_soft_power_info(unsigned long *power_reg);
int pdc_soft_power_button(int sw_control);
-void pdc_suspend_usb(void);
+void pdc_io_reset(void);
+void pdc_io_reset_devices(void);
int pdc_iodc_getc(void);
void pdc_iodc_putc(unsigned char c);
void pdc_iodc_outc(unsigned char c);
@@ -963,7 +968,6 @@
#ifdef __LP64__
int pdc_pat_chassis_send_log(unsigned long status, unsigned long data);
-
int pdc_pat_cell_get_number(struct pdc_pat_cell_num *cell_info);
int pdc_pat_cell_module(unsigned long *actcnt, unsigned long ploc, unsigned long mod,
unsigned long view_type, void *mem_addr);
@@ -1010,6 +1014,6 @@
extern void pdc_init(void);
-#endif /* __ASSEMBLY__ */
+#endif /* !__ASSEMBLY__ */
#endif /* _PARISC_PDC_H */
^ permalink raw reply
* Re: [patch] pg-r4k.c bugs for R4600 rev.2.0
From: Ralf Baechle @ 2004-01-26 17:00 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Dominik 'Rathann' Mierzejewski, linux-mips
In-Reply-To: <Pine.LNX.4.55.0401261659540.14505@jurand.ds.pg.gda.pl>
On Mon, Jan 26, 2004 at 05:31:07PM +0100, Maciej W. Rozycki wrote:
> I have two other fixes for the file -- you might try them as well, as
> I've only tested all three of them together, because of a different
> configuration of the system I've used. They fix a problem with R4k
> systems with a secondary cache and a coprocessor 0 hazard with R4000/R4400
> systems with primary caches only.
>
> Ralf, OK to apply this one?
Looks good, so please feel free to apply.
I just bent the kernel for my R4600 v2.0 machine (RM200) into shape again
and will test it later; will let you know if there's any problems.
Ralf
^ permalink raw reply
* Re: ethtool -d MCAs rx2600
From: Matthew Wilcox @ 2004-01-26 16:58 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <20040123231254.GC31911@cup.hp.com>
On Mon, Jan 26, 2004 at 10:30:23AM -0600, Jack Steiner wrote:
> On Fri, Jan 23, 2004 at 03:56:50PM -0800, Grant Grundler wrote:
> > On Fri, Jan 23, 2004 at 03:12:54PM -0800, Grant Grundler wrote:
> > > In case someone wants to dig more now, I've dropped the "errdump mca"
> > > output on
> > > ftp://gsyprf10.external.hp.com/kernels/rx2600/mca_ethtool
> > >
> > > (Matching vmlinuz, System.map, .config is also there 2.6.1-rc1.tgz)
> >
> > Alex Williams tells me it's a PIO read timeout.
> > (confirms my guess given what man page said)
> >
> > Offending address is likely 0x0000000090807000.
> > Matches nicely with what /proc/iomem thinks:
> > ...
> > 90000000-97ffffff : PCI Bus 0000:20
> > 90800000-9080ffff : tg3
> > ...
> >
> > Now just need to hunt down the code that pokes at +0x7000.
> >
> > thanks,
> > grant
>
> We see a similar problem with "ethtool -d" on the SGI SN systems. We havent
> isolated the cause, but it looks similar - PIO read timeout.
>
> FWIW, the failure occurs in the vicinity of tg3_get_regs+0xb60 called from
> tg3_ethtool_ioctl+0xbb0. (This is on 2.4.21+).
>
> Looks like it occurs here (but I dont put a lot of faith in this):
> GET_REG32_LOOP(BUFMGR_MODE, 0x58);
> GET_REG32_LOOP(RDMAC_MODE, 0x08);
> >>>> GET_REG32_LOOP(WDMAC_MODE, 0x08);
> GET_REG32_LOOP(RX_CPU_BASE, 0x280);
> GET_REG32_LOOP(TX_CPU_BASE, 0x280);
My suspicion is that some tg3 variants don't support this register, but
it's OK to read the register on x86 because it soft-fails. Most ia64
chipsets hard-fail so we need to avoid this. Jeff, Dave, can you comment?
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
^ permalink raw reply
* Re: [Bluez-users] phone+heaset
From: João Santos @ 2004-01-26 16:55 UTC (permalink / raw)
To: marcel; +Cc: bluez-users
Hi Marcel,
> > >ACL data: handle 0x0028 flags 0x02 dlen 21
> > L2CAP(d): cid 0x41 len 17 [psm 1]
> > SDP SA Req: tid 0x53 len 0xc
> > hndl 0x804f738
> > max 0xff
> > aid(s) 0x0302 ((null))
> > cont 00
> > < ACL data: handle 0x0028 flags 0x02 dlen 14
> > L2CAP(d): cid 0x41 len 10 [psm 1]
> > SDP SA Rsp: tid 0x53 len 0x5
> > cnt 0x2
> >
> > cont 00
>
>it seems that your problem is here. The SDP record must be correct
>otherwise it won't work.
Thanks for answer my last question.
could you explain me better what's the problem, i think i 'm doing it right:
[root@olivia jsantos]# sdptool browse local
Browsing FF:FF:FF:00:00:00 ...
Service Name: SDP Server
Service Description: Bluetooth service discovery server
Service Provider: BlueZ
Service RecHandle: 0x0
Service Class ID List:
"SDP Server" (0x1000)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 1
Version: 0x0001
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Service Name: Public Browse Group Root
Service Description: Root of public browse hierarchy
Service Provider: BlueZ
Service RecHandle: 0x804cd30
Service Class ID List:
"Browse Group Descriptor" (0x1001)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Service Name: Headset
Service RecHandle: 0x804f728
Service Class ID List:
"Headset" (0x1108)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 12
Profile Descriptor List:
"Headset" (0x1108)
Version: 0x0100
[root@olivia jsantos]# sdptool search HSET
Inquiring ...
Searching for HSET on 00:60:57:15:8A:A9 ...
Service Name: Audio Gateway
Service RecHandle: 0x10002
Service Class ID List:
"Headset Audio Gateway" (0x1112)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 12
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Headset" (0x1108)
Version: 0x0100
Thanks in advance,
Regards,
João Santos
_________________________________________________________________
Find high-speed ‘net deals — comparison-shop your local providers here.
https://broadband.msn.com
^ permalink raw reply
* [patch] pg-r4k.c bugs for R4k systems with a secondary cache
From: Maciej W. Rozycki @ 2004-01-26 16:55 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
Ralf,
This patch fixes a bug in build_cdex() that makes the function invoke the
Create Dirty Exclusive command for the D-cache when a secondary cache is
present. This is unnecessary as the Create Dirty Exclusive command for
the S-cache acts upon the D-cache appropriately and (for reasons yet to be
investigated) using the command on the D-cache directly leads to memory
corruption on my R4400SC system. With the patch the system appears
stable.
The patch also removes references to has_scache which currently disable
code for the S-cache line size of 128 bytes as the variable is always 0.
OK to apply?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
patch-mips-2.4.24-pre2-20040116-mips-pg-r4k-scache-0
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c 2004-01-03 03:56:38.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c 2004-01-26 12:13:22.000000000 +0000
@@ -67,7 +67,6 @@ static int pref_offset_copy __initdata
static unsigned int pref_src_mode __initdata;
static unsigned int pref_dst_mode __initdata;
-static int has_scache __initdata = 0;
static int load_offset __initdata = 0;
static int store_offset __initdata = 0;
@@ -130,16 +129,20 @@ static inline void build_cdex(void)
{
union mips_instruction mi;
- if (cpu_has_cache_cdex_s &&
- !(store_offset & (cpu_scache_line_size() - 1))) {
+ if (cpu_has_cache_cdex_s) {
+ if (!(store_offset & (cpu_scache_line_size() - 1))) {
- mi.c_format.opcode = cache_op;
- mi.c_format.rs = 4; /* $a0 */
- mi.c_format.c_op = 3; /* Create Dirty Exclusive */
- mi.c_format.cache = 3; /* Secondary Data Cache */
- mi.c_format.simmediate = store_offset;
+ mi.c_format.opcode = cache_op;
+ mi.c_format.rs = 4; /* $a0 */
+ mi.c_format.c_op = 3; /* Create Dirty
+ Exclusive */
+ mi.c_format.cache = 3; /* Secondary Data
+ Cache */
+ mi.c_format.simmediate = store_offset;
*epc++ = mi.word;
+ }
+ return;
}
if (store_offset & (cpu_dcache_line_size() - 1))
@@ -332,7 +335,7 @@ dest = epc;
build_store_reg(0);
build_store_reg(0);
build_store_reg(0);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_store_reg(0);
build_store_reg(0);
build_store_reg(0);
@@ -341,7 +344,7 @@ dest = epc;
build_addiu_a0(2 * store_offset);
build_store_reg(0);
build_store_reg(0);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_store_reg(0);
build_store_reg(0);
build_store_reg(0);
@@ -405,7 +408,7 @@ dest = epc;
build_store_reg( 9);
build_store_reg(10);
build_store_reg(11);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_load_reg( 8);
build_load_reg( 9);
build_load_reg(10);
@@ -424,7 +427,7 @@ dest = epc;
build_store_reg( 8);
build_store_reg( 9);
build_store_reg(10);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_store_reg(11);
build_load_reg( 8);
build_load_reg( 9);
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c 2004-01-03 03:56:46.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c 2004-01-26 12:13:22.000000000 +0000
@@ -67,7 +67,6 @@ static int pref_offset_copy __initdata
static unsigned int pref_src_mode __initdata;
static unsigned int pref_dst_mode __initdata;
-static int has_scache __initdata = 0;
static int load_offset __initdata = 0;
static int store_offset __initdata = 0;
@@ -130,16 +129,20 @@ static inline void build_cdex(void)
{
union mips_instruction mi;
- if (cpu_has_cache_cdex_s &&
- !(store_offset & (cpu_scache_line_size() - 1))) {
+ if (cpu_has_cache_cdex_s) {
+ if (!(store_offset & (cpu_scache_line_size() - 1))) {
- mi.c_format.opcode = cache_op;
- mi.c_format.rs = 4; /* $a0 */
- mi.c_format.c_op = 3; /* Create Dirty Exclusive */
- mi.c_format.cache = 3; /* Secondary Data Cache */
- mi.c_format.simmediate = store_offset;
+ mi.c_format.opcode = cache_op;
+ mi.c_format.rs = 4; /* $a0 */
+ mi.c_format.c_op = 3; /* Create Dirty
+ Exclusive */
+ mi.c_format.cache = 3; /* Secondary Data
+ Cache */
+ mi.c_format.simmediate = store_offset;
*epc++ = mi.word;
+ }
+ return;
}
if (store_offset & (cpu_dcache_line_size() - 1))
@@ -332,7 +335,7 @@ dest = epc;
build_store_reg(0);
build_store_reg(0);
build_store_reg(0);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_store_reg(0);
build_store_reg(0);
build_store_reg(0);
@@ -341,7 +344,7 @@ dest = epc;
build_addiu_a0(2 * store_offset);
build_store_reg(0);
build_store_reg(0);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_store_reg(0);
build_store_reg(0);
build_store_reg(0);
@@ -405,7 +408,7 @@ dest = epc;
build_store_reg( 9);
build_store_reg(10);
build_store_reg(11);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_load_reg( 8);
build_load_reg( 9);
build_load_reg(10);
@@ -424,7 +427,7 @@ dest = epc;
build_store_reg( 8);
build_store_reg( 9);
build_store_reg(10);
- if (has_scache && cpu_scache_line_size() == 128) {
+ if (cpu_scache_line_size() == 128) {
build_store_reg(11);
build_load_reg( 8);
build_load_reg( 9);
^ permalink raw reply
* Re: [Bluez-users] rfcomm shouldn't fail silently
From: Marcel Holtmann @ 2004-01-26 16:55 UTC (permalink / raw)
To: Edd Dumbill; +Cc: BlueZ Mailing List
In-Reply-To: <1075135629.12874.339.camel@saag>
Hi Edd,
> > > rfcomm shouldn't fail silently if an invalid command is given to ie.
> >
> > it does not fail silently. It show the the list of bonded devices.
>
> If none are bonded, it is silent :)
>
> The point was there should be a usage error output.
actually the problem is an unknown command with no extra parameters. Try
these two and see what happens:
rfcomm test
rfcomm test abc
I don't care so much about it, but I will accept patches for this
problem. Should not be so hard to fix, but at the moment I have to deal
with some other stuff.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: [linux-lvm] lvm on initrd
From: Luca Berra @ 2004-01-26 16:55 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <200401252110.07895.arekm@pld-linux.org>
On Sun, Jan 25, 2004 at 09:10:07PM +0100, Arkadiusz Miskiewicz wrote:
>Unfortunately this doesn't give any significant size drop:
>lvm staticly linked with uClibc and device-mapper lib with all features
>-rwxr-xr-x 1 misiek users 555815 2004-01-25 21:05 initrd-lvm
>lvm staticly linked with uClibc and device-mapper lib using my patch above (so
>only vgscan and vgchange functions available)
>-rwxr-xr-x 1 root root 482428 2004-01-25 20:51 initrd-lvm
>
>How these sizes look with dietlibc?
-rwxr-xr-x 1 root root 308180 Jan 23 22:14 /sbin/lvm2-static*
Which is still very big, but reducing it will take significantly more
work.
>Also some problems with lvm way of checking what command user wants based on
>argv[0] came out:
>[root@arm misiek]# /sbin/initrd-lvm
> No such command. Try 'help'.
...
>It would be much better if when argv[0] is not known internally for lvm then
>work as argv[0] = lvm.
>
unfortunately it seems done the other way around in lvm.c
i found it easier to add possible aliases for lvm in there
http://www.comedia.it/~bluca/cooker/lvm2/lvm2-2.00.08-7mdk/lvm2-alternatives.patch.bz2
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply
* Re: RE : RE : DOC2k booting speed ...
From: David Woodhouse @ 2004-01-26 16:51 UTC (permalink / raw)
To: Philippe; +Cc: linux-mtd
In-Reply-To: <000501c3e42a$ff0123d0$247dfea9@jennifer>
On Mon, 2004-01-26 at 17:39 +0100, Philippe wrote:
> Well I had some troubles with the /etc/mtab....
Symlink it to /proc/mounts.
See the Familiar distribution used on the iPAQ (and others) for more
clues.
--
dwmw2
^ permalink raw reply
* Re: [Bluez-users] rfcomm shouldn't fail silently
From: Edd Dumbill @ 2004-01-26 16:47 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: BlueZ Mailing List
In-Reply-To: <1075135361.25442.57.camel@pegasus>
On Mon, 2004-01-26 at 16:42, Marcel Holtmann wrote:
> Hi Edd,
>
> > As reported in this bug
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229167
> >
> > rfcomm shouldn't fail silently if an invalid command is given to ie.
>
> it does not fail silently. It show the the list of bonded devices.
If none are bonded, it is silent :)
The point was there should be a usage error output.
-- Edd
^ permalink raw reply
* Re: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: James Bottomley @ 2004-01-26 16:45 UTC (permalink / raw)
To: Moore, Eric Dean; +Cc: SCSI Mailing List, hch
In-Reply-To: <0E3FA95632D6D047BA649F95DAB60E5703D19D2F@exa-atlanta.se.lsil.com>
On Mon, 2004-01-26 at 10:37, Moore, Eric Dean wrote:
> Here is another update for the MPT Fusion drivers.
Thanks.
> * added CONFIG_LBA, READ16, WRITE16 support
I'd like to see this routine to determine direction go away in favour of
just using the direction the mid layer sends down. However, this isn't
a blocking item, I'll try and get this update into early 2.6.2
James
^ permalink raw reply
* Re: [Bluez-users] rfcomm shouldn't fail silently
From: Marcel Holtmann @ 2004-01-26 16:42 UTC (permalink / raw)
To: Edd Dumbill; +Cc: BlueZ Mailing List
In-Reply-To: <1075133668.12874.328.camel@saag>
Hi Edd,
> As reported in this bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229167
>
> rfcomm shouldn't fail silently if an invalid command is given to ie.
it does not fail silently. It show the the list of bonded devices.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ 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.