date:20001227

At Wed, 27 Dec 2000 17:57:19 +0200,
Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> Proposed by me patches is no way an official direction of the Project and as I 
>advertised are merely a workaround to allow non-English
> users to read CD with native filenames until comprehensive iconv for kernel will be 
>introduced. I would be glad if someone will
> replace my hack with more generic solution.

So I have introduced you Vladimir's and my patch again.
The patch was introduced to FreeBSD lists several times since Apr 1999.
Our patch allow at least Latin-1, Latin-2, Russian, and Japasese users
to read CD with native filenames also until proper I18N will be
introduced.
Moreover, the patch already have KLD ability and easy extendability.
Your workaround never deserve of official audit in comparison to ours.

NOTE: Our patches is also a 'workaround', and is not based on 
  my "rough idea" proposed in this thread.
  NetBSD folks had already discussed on my patch a year ago,
  and I have decided that my patch couldn't deserve of audit.

-- 
Motomichi Matsuzaki <[EMAIL PROTECTED]> 
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]


On Thu, Dec 28, 2000 at 09:51:27 +0600, Boris Popov wrote:
>   The patch seems to be ok as temporary solution for CDs with
> Russian file names. And as temporary solution it well suits to the ports

To be exact, not Russian only but for any single byte character set names.

-- 
Andrey A. Chernov
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Undefined symbol on boot

2000-12-27 Thread Bill Vermillion


On Thu, Dec 28, 2000 at 12:33:29PM +0900, Munehiro Matsuda thus spoke:
> From: [EMAIL PROTECTED]
> Date: Wed, 27 Dec 2000 21:55:51 -0500 (EST)
> ::md0: Malloc disk
> ::WARNING: Driver mistake: destroy_dev on 154/0
> ::** what's this? *
> 
> I'm not sure about this one.
> 
> ::Mounting root from ufs:/dev/ad0s2a
> ::link_elf: symbol tsleep undefined
> ::***   < first error
> ::Old-style KLD file fire_saver found
> ::link_elf: symbol exit undefined
> ::   ::pid 215 (ldconfig), uid 0: exited on signal 11 (core dumped)
> ::* <3rd
> ::link_elf: symbol tsleep undefined
> ::  You must have old modules in /modules directory.
> Rename /modules to something else or remove everything in it.

> On 5-Current, kernel and kernel modules now live in /boot/kernel/.
> But /modules and /boot/modules are searched first.

>  Hope this helps,

Thanks a lot.  That fixed it.

I really appreciate this.

Bill
-- 
Bill Vermillion -   bv @ wjv . com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Undefined symbol on boot

2000-12-27 Thread Bill Vermillion


On Thu, Dec 28, 2000 at 01:15:38PM +1000, Sleepless in Brisbane thus spoke:
> On Wed, 27 Dec 2000 [EMAIL PROTECTED] wrote:

> > Reply to: [EMAIL PROTECTED]
> > X-Mailer: ELM [version 2.5 PL3]
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit

> > I'm not sure if this is the correct list or not - apologies if
> > it's wrong.

> > I just updated a machine with cvsup for the first time - and may
> > have done something wrong.  

> > When I rebuilt everything and boot a uname gives me 5.0-CURRENT.
> > [I picked the wrong one as I guess I wanted release - but that's
> > not the problem].

> Umm.. that is the problem. There is a lot more hassle normally
> involved in going from a RELEASE kernel to a CURRENT one than
> usually a make world can fix. Do you really want to be doing this
> if you are just after an updated kernel? If not - I suggest going
> back to STABLE.

I found where the errors are coming from - it's in the
compatibility modules.  If I take out compatibility for linux,
sysv, and ibcs, things run just as they are supposed to.

So how do I fix the compats - or is that something coming later.
I don't really need it at the moment.1
-- 
Bill Vermillion -   bv @ wjv . com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

2000-12-27 Thread Boris Popov

On Wed, 27 Dec 2000, Maxim Sobolev wrote:

> Several days ago I got a CD with Russian filenames on it and discovered that
> I'm unable to read those filenames. After some hacking I produced a patch,
> which should solve this problem in the manner similar to what we have in
> msdosfs module (i.e. user-provided conversion table). I have to emphasize that
> it's a temporary solution until we will have iconv support in kernel.

The patch seems to be ok as temporary solution for CDs with
Russian file names. And as temporary solution it well suits to the ports
collection, not to the main tree.

In the near future we'll have iconv interface in the kernel which
uses libiconv library written by Konstantin Chuguev. I'm really sorry for
delays, but my current job leaves nearly zero spare time to me and there
is a hope that January will be less busy.

--
Boris Popov
http://www.butya.kz/~bp/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

2000-12-27 Thread Warner Losh


[[ sorry for the minorly offtopic post ]]

In message <[EMAIL PROTECTED]> "Michael
C. Wu" writes:
: Right, and as much as you want single byte stuff to work, CJK is also
: a large market for FreeBSD.  Where else in the world is there a full-
: fledged print monthly 200page magazine for BSD but Japan?
: (Sorry, but DaemonNews is not 200 pages :)  

I think that the BSD magazine is published more like quarterly.  There
have only been 6 issues since October 1999 of BSD Magazine (issue 6
just arrived the other day).  There have been two issues of the
FreeBSD magazine in Japan since October 2000.  The second issue of
FreeBSD mag showed up last week.

However, your point about how big FreeBSD is in Japan is none the less
quite valid.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Undefined symbol on boot

2000-12-27 Thread Munehiro Matsuda


From: [EMAIL PROTECTED]
Date: Wed, 27 Dec 2000 21:55:51 -0500 (EST)
::md0: Malloc disk
::WARNING: Driver mistake: destroy_dev on 154/0
::** what's this? *

I'm not sure about this one.

::Mounting root from ufs:/dev/ad0s2a
::link_elf: symbol tsleep undefined
::***   < first error
::Old-style KLD file fire_saver found
::link_elf: symbol exit undefined
::

Re: Undefined symbol on boot

2000-12-27 Thread Bill Vermillion

On Thu, Dec 28, 2000 at 01:15:38PM +1000, Sleepless in Brisbane thus spoke:
> On Wed, 27 Dec 2000 [EMAIL PROTECTED] wrote:

> > Reply to: [EMAIL PROTECTED]
> > X-Mailer: ELM [version 2.5 PL3]
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit

> > I'm not sure if this is the correct list or not - apologies if
> > it's wrong.

> > I just updated a machine with cvsup for the first time - and may
> > have done something wrong.  

> > When I rebuilt everything and boot a uname gives me 5.0-CURRENT.
> > [I picked the wrong one as I guess I wanted release - but that's
> > not the problem].

> Umm.. that is the problem. There is a lot more hassle normally
> involved in going from a RELEASE kernel to a CURRENT one than
> usually a make world can fix. Do you really want to be doing this
> if you are just after an updated kernel? If not - I suggest going
> back to STABLE.

Well I don't hvae a problem with going to this release.  The
machine was originally booted with a 4.1 - the one with the
keyboard problem, and I upgraded it to a 4.2 - but since it was an
upgrade it didn't let me put new sources on.

>From what I read you could complete move up, buy removing
everything, and preforming the bmildworld, buildkernel,
installkernel, and installworld.

This should have removed every trace of any 4.[12] on the system,
should it not.

The machine is to replace this one - whose motherboard is getting
tired and cranky.  

It's just that one undefinded symbol and exit.  If I KNEW where
that was coming from it might help.  So this machine is a 4.0 - the
machine where I posted from was a 4.1 > 4.2 > 5.0

I figured I'd better learn this cvs method - and this seemed like a
good time.

Bill

-- 
Bill Vermillion -   bv @ wjv . com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Undefined symbol on boot

2000-12-27 Thread Sleepless in Brisbane


On Wed, 27 Dec 2000 [EMAIL PROTECTED] wrote:

> Reply to: [EMAIL PROTECTED]
> X-Mailer: ELM [version 2.5 PL3]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> I'm not sure if this is the correct list or not - apologies if
> it's wrong.
> 
> I just updated a machine with cvsup for the first time - and may
> have done something wrong.  
> 
> When I rebuilt everything and boot a uname gives me 5.0-CURRENT.
> [I picked the wrong one as I guess I wanted release - but that's
> not the problem].

Umm.. that is the problem.  There is a lot more hassle normally involved in
going from a RELEASE kernel to a CURRENT one than usually a make world can
fix.  Do you really want to be doing this if you are just after an updated
kernel?   If not - I suggest going back to STABLE.

-- Snowy Maslov aka Snowpony  My...  [ www.vulpine.pp.se/cgi-bin/furcode ]
   |\=  http://snowy.furart.org/Art  FEHuw3acdm A+ C- Dm++ H+++ M P+++
  - - = http://www.furryfaire.org/ Life  R++ T+++ W- Z++ Sf# RLCT/M a cbu$
'-  http://www.furart.org/   Dreams  d- e+ f+++ h+ iwf+++$ j+ p* sm#>f#



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Undefined symbol on boot

2000-12-27 Thread bv


Reply to: [EMAIL PROTECTED]
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm not sure if this is the correct list or not - apologies if
it's wrong.

I just updated a machine with cvsup for the first time - and may
have done something wrong.  

When I rebuilt everything and boot a uname gives me 5.0-CURRENT.
[I picked the wrong one as I guess I wanted release - but that's
not the problem].

Everything appears fine execpt during boot I get a symbol not found
and a core dump.
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Wed Dec 27 20:35:44 EST 2000
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BILVER
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 179629093 Hz
CPU: Pentium Pro (179.63-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x619  Stepping = 9
  Features=0xf9ff
real memory  = 67108864 (65536K bytes)
config> di sn0
[stuff deleted]

Preloaded userconfig_script "/boot/kernel.conf" at 0xc049909c.
Pentium Pro MTRR support enabled
md0: Malloc disk
WARNING: Driver mistake: destroy_dev on 154/0
** what's this? *
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
Correcting Natoma config for non-SMP
isab0:  at device 7.0 on pci0
[more standard stuff deleted]

ep0: <3Com 3C509-TPO EtherLink III> at port 0x300-0x30f irq 11 on isa0
ep0: Ethernet address 00:60:08:02:d0:14
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
DUMMYNET initialized (000608)
IPv6 packet filtering initialized, default to accept, logging limited to 100 
packets/entry
IP packet filtering initialized, divert enabled, rule-based forwarding enabled, 
default to accept, logging limited to 100 packets/entry by default
BRIDGE 990810, have 9 interfaces
-- index 2  type 6 phy 0 addrl 6 addr 00.60.08.02.d0.14
IP Filter: v3.4.13 initialized.  Default = pass all, Logging = enabled
ad0: 19541MB  [39703/16/63] at ata0-master WDMA2
acd0: CDROM  at ata1-master using PIO3
Mounting root from ufs:/dev/ad0s2a
link_elf: symbol tsleep undefined
***   < first error
Old-style KLD file fire_saver found
link_elf: symbol exit undefined

Re: HDD Problem

2000-12-27 Thread Kent Stewart

"David W. Chapman Jr." wrote:
> 
> I have a KT7 with an athlon 1.1, no problems with ATA66, don't have a 100
> drive though.  Works fine, does make worlds in a little over an hour with
> 384mb of pc133, but I do have to downclock the pc133 to 100 because these
> via chips have some problem with agp and pc133 at the moment.

I'm also running the slow end on the bios memory setting. The wz beta
bios is supposed to deal with some memory timing questions. I have
downloaded wz but haven't flashed the bios yet. I am running uz, which
became w? (their www server is overloaded and can't see what they
called the uz when it was released). Abit is also up to KT7a and 686B.

I have both Maxtor's (30 GB and 40 GB - ATA100's) set to do only UDMA
33 using Maxtor's udmaupdt.exe program. That didn't help FreeBSD.
Windows 2000 didn't have any problems at the UDMA66 setting and just
slowed down a little bit at the UDMA33 setting. I have three other
systems based on the bx chipset that don't have problems doing UDMA33.

If I time my upworld script, I see user times of 18xx seconds and
1.5-1.8 hours wall clock. I figure the difference between doing an
update (cvsup of RELENG_4 to installworld) in 40 minutes wall-clock
and what I have now is disk transfer speed related. Setiathome runs at
~40% cpu in the background (niced to 19). Because it is only using
available cpu time, killing setiathome before I started the builds
didn't change the build time significantly.

I have a Promise ATA66 card that I am going to try but will have to
move one of the HD's and CDROM before the 80-pin cable will reach. The
main drive is all by itself on the ide1 controller.

Kent

> >
> > I have an Abit KT7 with PC-133 memory and an Athlon 900 that doesn't
> > like FreeBSD 4.2-stable and Maxtor ATA100 drives. Right now, it is
> > running in PIO mode and that makes it less than half fast doing a
> > system build. The first install of FreeBSD resulted in a trashed
> > Win98se primary partition. There were timing issues in the bios that
> > were supposed to fix the ATA100 Maxtor drives. The bios was flashed to
> > include those fixes. I used sysctl and turned UDMA back on last night
> > and it didn't help the ata-disk. It went back to PIO mode in a hurry.
> >
> > Kent
> >
> > >
> > > -Søren
> > >
> > > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > > with "unsubscribe freebsd-stable" in the body of the message
> >
> > --
> > Kent Stewart
> > Richland, WA
> >
> > mailto:[EMAIL PROTECTED]
> > http://kstewart.urx.com/kstewart/index.html
> > FreeBSD News http://daily.daemonnews.org/
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-stable" in the body of the message
> >

-- 
Kent Stewart
Richland, WA

mailto:[EMAIL PROTECTED]
http://kstewart.urx.com/kstewart/index.html
FreeBSD News http://daily.daemonnews.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread David W. Chapman Jr.


I have a KT7 with an athlon 1.1, no problems with ATA66, don't have a 100
drive though.  Works fine, does make worlds in a little over an hour with
384mb of pc133, but I do have to downclock the pc133 to 100 because these
via chips have some problem with agp and pc133 at the moment.
>
> I have an Abit KT7 with PC-133 memory and an Athlon 900 that doesn't
> like FreeBSD 4.2-stable and Maxtor ATA100 drives. Right now, it is
> running in PIO mode and that makes it less than half fast doing a
> system build. The first install of FreeBSD resulted in a trashed
> Win98se primary partition. There were timing issues in the bios that
> were supposed to fix the ATA100 Maxtor drives. The bios was flashed to
> include those fixes. I used sysctl and turned UDMA back on last night
> and it didn't help the ata-disk. It went back to PIO mode in a hurry.
>
> Kent
>
> >
> > -Søren
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-stable" in the body of the message
>
> --
> Kent Stewart
> Richland, WA
>
> mailto:[EMAIL PROTECTED]
> http://kstewart.urx.com/kstewart/index.html
> FreeBSD News http://daily.daemonnews.org/
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread Kent Stewart




Soren Schmidt wrote:
> 
> It seems Justin W. Pauler wrote:
> > I've heard tell that there are problems with the VIA chipset and UDMA on
> > FreeBSD. Is this true, and if so, what is the problem with?
> 
> Hmm, there are no open problems as far as I'm aware...
> 
> > FreeBSD 4.2-STABLE #0: Fri Dec  8 01:52:44 EST 2000
> > CPU: Pentium III/Pentium III Xeon/Celeron (601.37-MHz 686-class CPU)
> >   Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
> > atapci0:  port 0xe000-0xe00f at device 7.1 on
> > pci0
> > ata0: at 0x1f0 irq 14 on atapci0
> > ata1: at 0x170 irq 15 on atapci0
> > ad0: 19546MB  [39714/16/63] at ata0-master UDMA66
> >
> > The drive has enough space and I have 512MB RAM. If I hit the system hard,
> > lets say, rm -rf /usr/ports, the system locks up. It doesn't just stop
> > responding for a little bit. It locks up tight. It kills all network
> > connections, doesn't respond to the console and doesn't respond to any
> > network activity. A hard reboot is the only thing that can bring it back to
> > life.
> >
> > One time, someone was able to see the console when this happened, and they
> > said something about a page fault. Trying to solve this, we ordered two brand
> > new 256MB modules and installed them. It is still happening.
> >
> > This is a production environment type of server. I've had no other problems
> > with FreeBSD 4.2-S, and i'm hoping maybe this is something that has been
> > fixed.
> 
> Hmm, my main devbox is based on the VIA '686 although with an athlon
> CPU, and there is no problems at all with it. I also dont belive that
> this is the disk drivers fault, as in almost all cases you would get
> error messages en-masse from the ATA driver

I have an Abit KT7 with PC-133 memory and an Athlon 900 that doesn't
like FreeBSD 4.2-stable and Maxtor ATA100 drives. Right now, it is
running in PIO mode and that makes it less than half fast doing a
system build. The first install of FreeBSD resulted in a trashed
Win98se primary partition. There were timing issues in the bios that
were supposed to fix the ATA100 Maxtor drives. The bios was flashed to
include those fixes. I used sysctl and turned UDMA back on last night
and it didn't help the ata-disk. It went back to PIO mode in a hurry.

Kent

> 
> -Søren
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message

-- 
Kent Stewart
Richland, WA

mailto:[EMAIL PROTECTED]
http://kstewart.urx.com/kstewart/index.html
FreeBSD News http://daily.daemonnews.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Cardbus woes

2000-12-27 Thread John Baldwin

On 27-Dec-00 Jonathan Chen wrote:
> On Thu, Dec 14, 2000 at 12:47:51PM -0800, John Baldwin wrote:
>> In other news, while wandering through the cardbus code, I discovered that
>> pccbb softc's have an internal mutex much to my surprise, and that they
>> weren't
>> quite being used properly AFAICT.  In the pccb0 kthread, they were
>> acquired/released without Giant.  However, in the rest of the pccbb driver,
>> they are acquired/released with Giant.  This leads to lock order violations 
>> which could potentially deadlock the machine at some point.  Also, the
>> pccbb0
>> kthread holds the mutex across the entire card insertion and removal events,
>> which is not quite right.  Mutexes should only be held for short periods of
>> time.  As such, I've futzed around with the mutex operations in the pccbb
>> driver some.  It may not be completely correct, but I think it is an
>> improvement.  The patch for this can be found at
>> http://www.FreeBSD.org/~jhb/patches/pccbb.patch.
> 
> [I just now recalled your mentioning this a while back, so here's my much
> delayed response]
> 
> Originally I had write the code with spl's, and at one point decided to
> convert them to mutex after finding spl's don't do anything.  However, I
> don't claim to know a whole lot about mutexes or FreeBSD's implementation
> of it.  Perhaps someone can point me to the Great Definitive Source?

There isn't one yet.  We are still getting some of the internals done to make
mutexes in drivers useful. :)  For now all drivers still run under Giant.

> The first thing I'm unclear about is the deal with Giant.  My understanding
> is that Giant is something one would acquire if he wanted to be really
> exclusive, or something like that.  John - you mentioned I was
> acquiring/releasing with/without Giant - but I don't see how I'm doing
> things differently in and out of the kthread.  The only place I mentioned
> Giant was right before kthread_exit, and that's necessary least
> kthread_exit calls panic() on me.  On your patch, you acquire Giant at the
> start of the kthread - wouldn't that hold onto the lock until the thread
> exits, and make other things attempting to lock Giant block?

Right now Giant is gotten on nearly every entry into the kernel (fast interrupt
handlers don't grab it and INTR_MPSAFE interrupt threads don't either.) 
Basically, as a mutex it protects everything in the kernel.  Thus, it is only
safe to run w/o holding Giant if _all_ of the data structures you are touching
are protected somehow.  In the kthread, you didn't acquire Giant, so all of the
data structures it touched (for example, in other driver attach and probes)
weren't protected at all.  Thus, cpu A could be running the pccbb thread doing
an attach, and cpu B could be doing something else on the same driver and they
would happily corrupt each other, crash teh system, etc.  When your thread
sleeps, it gives Giant up, so it won't block the system indefinitely.  (Giant
is special with regards to tsleep(9) in that case.)  Other kthreads grab Giant
when they first start up, see the aio daemon code for example.

> As for the 'holding onto mutex for a long time' problem, I'm not sure if
> your solution is best.  I originally put in the locks firstly because
> that's how NetBSD had it, and secondly so that card removal interrupts
> while card is still attaching wouldn't be lost.  Your patched version
> allows for wakeup() to be called while insertion/removal is being
> processed.  I've glanced through the code and didn't see anything that
> requires mutual exclusivity between the kthread the the interrupt handler,
> so perhaps a better solution would be to simply not use mutex at all?

I was mostly trying to push the locks down so that they weren't held during
attach and remove.  I was using them to protect mostly the kthread state flag
in the softc, as well as other variables in the softc.

> Comments?

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread Louis A. Mamakos



I've got two mobos with VIA MVP3 chipsets on-board.  As these systems
(until recently) had only SCSI peripherals, I didn't notice any problem.
However, when I added an IDE CDRW drive, I got these very strange system
lock-ups/hangs.  Specifically, this was an FIC VA-503+ mobo, with a
450MHz K6-2 CPU. 

I saw on a FreeBSD mailing list a suggestion to go into the BIOS setup,
and disable "PCI Dynamic Bursting".  At least that's what it's called
in my Award BIOS.  

This seemed to have "fixed" the problem for me (or at least hidden it
sufficiently well :-); perhaps it might be of some help in other situations?

louie


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread Marco Rodrigues



On Wed, 27 Dec 2000, Soren Schmidt wrote:

> It seems David W. Chapman Jr. wrote:
> 
> You guys are not overclocking are you ??
> 
> > I've recently seen the same problem on 4.2-stable, probably a early version
> > of it, I go to make my kernel and it locks up for a few mins, then I get
> > some ata error and then it says resetting devices and it all runs ok, it
> > resets the ata devices during boot also.
> > 
> > 
> > - Original Message -
> > From: "Ben Jackson" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Wednesday, December 27, 2000 2:28 PM
> > Subject: Re: HDD Problem
> > 
> > 
> > > > I've heard tell that there are problems with the VIA chipset and UDMA on
> > > > FreeBSD. Is this true, and if so, what is the problem with?
> > > >
> > > > FreeBSD 4.2-STABLE #0: Fri Dec  8 01:52:44 EST 2000
> > > > atapci0:  port 0xe000-0xe00f at device 7.1
> > on
> > > > pci0
> > > > ad0: 19546MB  [39714/16/63] at ata0-master UDMA66
> > >
> > > Sounds similar to the problem I've had with the HPT controller on my
> > > Abit BP6.  If you look at the -stable archives from the last few days
> > > you'll see some suggestions.  I should really move this drive to one
> > > of the ATA33 controllers since the drive itself only (??) does about
> > > 30M/s sustained anyway.
> > >
> > > atapci1:  port
> > 0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007 irq 18 at device 19.0 on pci0
> > > ata2: at 0xd000 on atapci1
> > > ad4: 29311MB  [59554/16/63] at ata2-master UDMA66
> > >
> > > > The drive has enough space and I have 512MB RAM. If I hit the system
> > hard,
> > > > lets say, rm -rf /usr/ports, the system locks up.
> > >
> > > I have to hit mine harder.  The more I upgrade FreeBSD, the more times
> > > it successfully resets the devices after a read timeout, but eventually
> > > it hangs while resetting.  With 4.2 (or maybe it's softupdates) it
> > > manages to save some of the errors in /var/log/messages.
> > >
> > > No page faults.  Haven't had a persistant kernel "page not present"
> > > problem since FreeBSD 1.1.5.  Also, my UDMA66 problem is happening
> > > on a machine with ECC mem.
> > >
> > > Another datapoint:  my desktop machine (until yesterday running 3.4)
> > > has an IBM disk in it which likes to spin down on its own, causing
> > > timeouts on the first access afterwards.  It's irritating (though not
> > > enough that I've investigated jumpering it for always-on) but it has
> > > never hung the system.
> > >
> > > --Ben
> > >
> > >
> > > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > > with "unsubscribe freebsd-stable" in the body of the message
> > >
> > 
> > 
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> > 
> 
> 
> -Søren
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread Soren Schmidt


It seems David W. Chapman Jr. wrote:

You guys are not overclocking are you ??

> I've recently seen the same problem on 4.2-stable, probably a early version
> of it, I go to make my kernel and it locks up for a few mins, then I get
> some ata error and then it says resetting devices and it all runs ok, it
> resets the ata devices during boot also.
> 
> 
> - Original Message -
> From: "Ben Jackson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Wednesday, December 27, 2000 2:28 PM
> Subject: Re: HDD Problem
> 
> 
> > > I've heard tell that there are problems with the VIA chipset and UDMA on
> > > FreeBSD. Is this true, and if so, what is the problem with?
> > >
> > > FreeBSD 4.2-STABLE #0: Fri Dec  8 01:52:44 EST 2000
> > > atapci0:  port 0xe000-0xe00f at device 7.1
> on
> > > pci0
> > > ad0: 19546MB  [39714/16/63] at ata0-master UDMA66
> >
> > Sounds similar to the problem I've had with the HPT controller on my
> > Abit BP6.  If you look at the -stable archives from the last few days
> > you'll see some suggestions.  I should really move this drive to one
> > of the ATA33 controllers since the drive itself only (??) does about
> > 30M/s sustained anyway.
> >
> > atapci1:  port
> 0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007 irq 18 at device 19.0 on pci0
> > ata2: at 0xd000 on atapci1
> > ad4: 29311MB  [59554/16/63] at ata2-master UDMA66
> >
> > > The drive has enough space and I have 512MB RAM. If I hit the system
> hard,
> > > lets say, rm -rf /usr/ports, the system locks up.
> >
> > I have to hit mine harder.  The more I upgrade FreeBSD, the more times
> > it successfully resets the devices after a read timeout, but eventually
> > it hangs while resetting.  With 4.2 (or maybe it's softupdates) it
> > manages to save some of the errors in /var/log/messages.
> >
> > No page faults.  Haven't had a persistant kernel "page not present"
> > problem since FreeBSD 1.1.5.  Also, my UDMA66 problem is happening
> > on a machine with ECC mem.
> >
> > Another datapoint:  my desktop machine (until yesterday running 3.4)
> > has an IBM disk in it which likes to spin down on its own, causing
> > timeouts on the first access afterwards.  It's irritating (though not
> > enough that I've investigated jumpering it for always-on) but it has
> > never hung the system.
> >
> > --Ben
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-stable" in the body of the message
> >
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread David W. Chapman Jr.


I've recently seen the same problem on 4.2-stable, probably a early version
of it, I go to make my kernel and it locks up for a few mins, then I get
some ata error and then it says resetting devices and it all runs ok, it
resets the ata devices during boot also.


- Original Message -
From: "Ben Jackson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, December 27, 2000 2:28 PM
Subject: Re: HDD Problem


> > I've heard tell that there are problems with the VIA chipset and UDMA on
> > FreeBSD. Is this true, and if so, what is the problem with?
> >
> > FreeBSD 4.2-STABLE #0: Fri Dec  8 01:52:44 EST 2000
> > atapci0:  port 0xe000-0xe00f at device 7.1
on
> > pci0
> > ad0: 19546MB  [39714/16/63] at ata0-master UDMA66
>
> Sounds similar to the problem I've had with the HPT controller on my
> Abit BP6.  If you look at the -stable archives from the last few days
> you'll see some suggestions.  I should really move this drive to one
> of the ATA33 controllers since the drive itself only (??) does about
> 30M/s sustained anyway.
>
> atapci1:  port
0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007 irq 18 at device 19.0 on pci0
> ata2: at 0xd000 on atapci1
> ad4: 29311MB  [59554/16/63] at ata2-master UDMA66
>
> > The drive has enough space and I have 512MB RAM. If I hit the system
hard,
> > lets say, rm -rf /usr/ports, the system locks up.
>
> I have to hit mine harder.  The more I upgrade FreeBSD, the more times
> it successfully resets the devices after a read timeout, but eventually
> it hangs while resetting.  With 4.2 (or maybe it's softupdates) it
> manages to save some of the errors in /var/log/messages.
>
> No page faults.  Haven't had a persistant kernel "page not present"
> problem since FreeBSD 1.1.5.  Also, my UDMA66 problem is happening
> on a machine with ECC mem.
>
> Another datapoint:  my desktop machine (until yesterday running 3.4)
> has an IBM disk in it which likes to spin down on its own, causing
> timeouts on the first access afterwards.  It's irritating (though not
> enough that I've investigated jumpering it for always-on) but it has
> never hung the system.
>
> --Ben
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread Ben Jackson


> I've heard tell that there are problems with the VIA chipset and UDMA on 
> FreeBSD. Is this true, and if so, what is the problem with?
> 
> FreeBSD 4.2-STABLE #0: Fri Dec  8 01:52:44 EST 2000 
> atapci0:  port 0xe000-0xe00f at device 7.1 on 
> pci0
> ad0: 19546MB  [39714/16/63] at ata0-master UDMA66 

Sounds similar to the problem I've had with the HPT controller on my
Abit BP6.  If you look at the -stable archives from the last few days
you'll see some suggestions.  I should really move this drive to one
of the ATA33 controllers since the drive itself only (??) does about
30M/s sustained anyway.

atapci1:  port 
0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007 irq 18 at device 19.0 on pci0
ata2: at 0xd000 on atapci1
ad4: 29311MB  [59554/16/63] at ata2-master UDMA66

> The drive has enough space and I have 512MB RAM. If I hit the system hard, 
> lets say, rm -rf /usr/ports, the system locks up.

I have to hit mine harder.  The more I upgrade FreeBSD, the more times
it successfully resets the devices after a read timeout, but eventually
it hangs while resetting.  With 4.2 (or maybe it's softupdates) it
manages to save some of the errors in /var/log/messages.

No page faults.  Haven't had a persistant kernel "page not present"
problem since FreeBSD 1.1.5.  Also, my UDMA66 problem is happening
on a machine with ECC mem.

Another datapoint:  my desktop machine (until yesterday running 3.4)
has an IBM disk in it which likes to spin down on its own, causing
timeouts on the first access afterwards.  It's irritating (though not
enough that I've investigated jumpering it for always-on) but it has
never hung the system.

--Ben


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: HDD Problem

2000-12-27 Thread Soren Schmidt


It seems Justin W. Pauler wrote:
> I've heard tell that there are problems with the VIA chipset and UDMA on 
> FreeBSD. Is this true, and if so, what is the problem with?

Hmm, there are no open problems as far as I'm aware...

> FreeBSD 4.2-STABLE #0: Fri Dec  8 01:52:44 EST 2000 
> CPU: Pentium III/Pentium III Xeon/Celeron (601.37-MHz 686-class CPU)
>   Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
> atapci0:  port 0xe000-0xe00f at device 7.1 on 
> pci0
> ata0: at 0x1f0 irq 14 on atapci0
> ata1: at 0x170 irq 15 on atapci0
> ad0: 19546MB  [39714/16/63] at ata0-master UDMA66 
> 
> The drive has enough space and I have 512MB RAM. If I hit the system hard, 
> lets say, rm -rf /usr/ports, the system locks up. It doesn't just stop 
> responding for a little bit. It locks up tight. It kills all network 
> connections, doesn't respond to the console and doesn't respond to any 
> network activity. A hard reboot is the only thing that can bring it back to 
> life. 
> 
> One time, someone was able to see the console when this happened, and they 
> said something about a page fault. Trying to solve this, we ordered two brand 
> new 256MB modules and installed them. It is still happening.
> 
> This is a production environment type of server. I've had no other problems 
> with FreeBSD 4.2-S, and i'm hoping maybe this is something that has been 
> fixed.

Hmm, my main devbox is based on the VIA '686 although with an athlon
CPU, and there is no problems at all with it. I also dont belive that
this is the disk drivers fault, as in almost all cases you would get
error messages en-masse from the ATA driver 

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

2000-12-27 Thread Mark Murray


Aimed at the thread, not the participants.

This is off-topic for audit-. Please bring it back to audit- when you have
some actual code to audit.

Thanks!

M

> On Wed, Dec 27, 2000 at 12:05:57PM +0200, Maxim Sobolev scribbled:
> | Several days ago I got a CD with Russian filenames on it and discovered tha
t
> | I'm unable to read those filenames. After some hacking I produced a patch,
> | which should solve this problem in the manner similar to what we have in
> | msdosfs module (i.e. user-provided conversion table). I have to emphasize t
hat
> | it's a temporary solution until we will have iconv support in kernel.
> | 
> | Please somebody review attached patches.
> 
> Please do not assume Unicode.  I18N/L10N efforts have been crying for
> programmers to *not* and *never* assume *anything*.  :)
> 
> Also, this belongs more on -i18n more than anything else.  I really
> do not want to generate all the traffic on -i18n alone.. :)
> 
> Have you seen ports/chinese/big5fs?  Japanese/Korean do the same thing too
> You could simply make a port of this that loads KLD's.  This enables us 
> to have the support without having hacks in src/sys.  I talked
> to Boris at length about this.  And I think this would be the best way
> to implement "temporary" hacks.
> 
> As to the progress of iconv, we should have it soon, as soon as
> itojun and I work out how to import either the Citrus code
> or Konstantin's code. 
> 
> If you make this a port, I say "go for it." :) If you wish to commit
> to src/sys, I have strong doubts about this.  I hope you do not
> mind my bluntness about this, as I really want to express the feelings.
> 
> Merry Christmas and a Happy New Year,
> Michael
> -- 
> +--+
> | [EMAIL PROTECTED] | [EMAIL PROTECTED] |
> | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
> +--+
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-audit" in the body of the message
> 
--
Mark Murray
Warning: this .sig is umop ap!sdn


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

On Wed, Dec 27, 2000 at 13:35:52 -0600, Michael C . Wu wrote:

> READ: "single byte"  
> You are breaking CJK multibyte support.  Why? Why do you want make 
> software engineering mistakes?  

1) Nobody can break something which not exist yet.
2) The stuff discussed is optional and not using it you got old
functionality.

> Why should you ignore the multibyte stuff because it is harder?

Not for this reason, but because it must be implemented at higher
abstraction level first to be considered. Since I have no much interest
in multibyte characters, it is not mine task in general, but others.

> The proposal breaks multibyte support and I do not believe it is acceptable

Again, I see no way how it can break nonexisten support. Remember that
conversion table is optional and without loading it you got exact previous
functionality variant.

Very similar stuff is in MSDOSFS for years and nobody complains.

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]



-audit trimmed, cc'ed to -i18n

On Wed, Dec 27, 2000 at 10:02:01PM +0300, áÎÄÒÅÊ þÅÒÎÏ× scribbled:
| On Wed, Dec 27, 2000 at 12:48:12 -0600, Michael C . Wu wrote:
| > On Wed, Dec 27, 2000 at 08:32:26PM +0200, Maxim Sobolev scribbled:
| > | "Michael C . Wu" wrote:
| > | > On Wed, Dec 27, 2000 at 05:57:19PM +0200, Maxim Sobolev scribbled:
| > | > | Motomichi Matsuzaki wrote:
| > | > I think that making this "hack" a russian/xxxfs port and I think
| > | > everyone can be happy. If you want unicode FS like this, perhaps you
| > | > can have a sysutils/unicodefs.  :)
| > 
| > | No, it's no way a ports- commit.
| 
| I agree.

I disagree.

| > Thank you for the one sentence reply without giving any reasons.
| > As a community, I thought we are supposed to communicate.
| > I have expressed my reasons and ideas, and you return the favor
| > with an one line comment.  :)
| 
| This is general method of telling kernel how to convert names from Unicode
| to any local charset, not particulary to Russian one. Anybody feel free to
| add their own single bytes charsets tables.

READ: "single byte"  
You are breaking CJK multibyte support.  Why? Why do you want make 
software engineering mistakes?  
 
| Yes, it is a per-FS hack, but until iconv or something like will be
| integrated, some hack needed just to read CDs selling at nearby shop.
| 
| > keichii@recursive:/usr/ports$ ls japanese/msdosfs/
| 
| Japanese etc. is _very_ different and needs tons of efforts even when
| implemented like similar hack, we currently talk about and limited to
| single bytes charsets only.

Why should you ignore the multibyte stuff because it is harder?
SMPng is hard, but no one is ignoring SMP because SMP is hard to implement.
Since device drivers for cheap hardware is hard to write/fix, should
we also ignore those?  Your logic fails to evaluate to TRUE.

| We have almost full single bytes charset localization in the
| kernel/userland, so this step is next logical extention in that direction.
| I can't say something like about double bytes charsets like Japanese etc.

Right, and as much as you want single byte stuff to work, CJK is also
a large market for FreeBSD.  Where else in the world is there a full-
fledged print monthly 200page magazine for BSD but Japan?
(Sorry, but DaemonNews is not 200 pages :)  

The proposal breaks multibyte support and I do not believe it is acceptable
to do this.  You want Russian to work, and us CJK people want CJK to work.
If you were looking at this from my point of view, would you say yes?
Probably not.  

The frustration with C charset is enough, can we please not make the mistake
that PDP-based BSD's made long ago? 

-- 
+--+
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+--+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

HDD Problem

2000-12-27 Thread Justin W. Pauler


Not sure exactly where this goes...
so, i'm sending it to everyone :P

I've heard tell that there are problems with the VIA chipset and UDMA on 
FreeBSD. Is this true, and if so, what is the problem with?

In my system is:

FreeBSD 4.2-STABLE #0: Fri Dec  8 01:52:44 EST 2000 
CPU: Pentium III/Pentium III Xeon/Celeron (601.37-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
atapci0:  port 0xe000-0xe00f at device 7.1 on 
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ad0: 19546MB  [39714/16/63] at ata0-master UDMA66 

The drive has enough space and I have 512MB RAM. If I hit the system hard, 
lets say, rm -rf /usr/ports, the system locks up. It doesn't just stop 
responding for a little bit. It locks up tight. It kills all network 
connections, doesn't respond to the console and doesn't respond to any 
network activity. A hard reboot is the only thing that can bring it back to 
life. 

One time, someone was able to see the console when this happened, and they 
said something about a page fault. Trying to solve this, we ordered two brand 
new 256MB modules and installed them. It is still happening.

This is a production environment type of server. I've had no other problems 
with FreeBSD 4.2-S, and i'm hoping maybe this is something that has been 
fixed.

-- 

Justin W. Pauler (drnet)
E-Mail: [EMAIL PROTECTED]
WWW: http://www.jwpages.com
IRC: Undernet IRC Network, #EggDrop



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

On Wed, Dec 27, 2000 at 12:48:12 -0600, Michael C . Wu wrote:
> On Wed, Dec 27, 2000 at 08:32:26PM +0200, Maxim Sobolev scribbled:
> | "Michael C . Wu" wrote:
> | > On Wed, Dec 27, 2000 at 05:57:19PM +0200, Maxim Sobolev scribbled:
> | > | Motomichi Matsuzaki wrote:
> | > I think that making this "hack" a russian/xxxfs port and I think
> | > everyone can be happy. If you want unicode FS like this, perhaps you
> | > can have a sysutils/unicodefs.  :)
> 
> | No, it's no way a ports- commit.

I agree.

> Thank you for the one sentence reply without giving any reasons.
> As a community, I thought we are supposed to communicate.
> I have expressed my reasons and ideas, and you return the favor
> with an one line comment.  :)

This is general method of telling kernel how to convert names from Unicode
to any local charset, not particulary to Russian one. Anybody feel free to
add their own single bytes charsets tables.

Yes, it is a per-FS hack, but until iconv or something like will be
integrated, some hack needed just to read CDs selling at nearby shop.

> keichii@recursive:/usr/ports$ ls japanese/msdosfs/

Japanese etc. is _very_ different and needs tons of efforts even when
implemented like similar hack, we currently talk about and limited to
single bytes charsets only.

We have almost full single bytes charset localization in the
kernel/userland, so this step is next logical extention in that direction.
I can't say something like about double bytes charsets like Japanese etc.

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

On Wed, Dec 27, 2000 at 13:44:11 +0200, Maxim Sobolev wrote:
> I'm now sure how could I obtain charset for each of dozen+ OSes that may create a CD.

There is not so much number, usualy only one Russian charset per OS :-)

> I don't see any problems, because it's likely that usual special high code table
> characters (copyright, angle quotes and so on) will be represented using Unicode
> charcodes with first byte (`base') equal to 0, so they can be mapped directly into
> native charset. In my implementation only Unicode characters with base !=0 are to be
> translated. All less usual characters (graphics and so on) can be translated by
> extending appropriate codetable to include additional translation tables with 
>different
> bases (e.g. 0x25 for graphics chars etc.).

Well, I could live with it in case you add _whole_ windows-1251 set as
Unicode to your loadable table and provide corresponding mapping for all
matching KOI8-R characters, as MSDOSFS currently does. You can get those
tables from MSDOSFS. This is minimal basis, you can make separate table
for KOI8-U, etc. I say this because I see you try to treat KOI8-R and
KOI8-U in your patch as the same charset which is not acceptable. Also
please call those tables per local charset name and not 'cd9660'.

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]


On Wed, Dec 27, 2000 at 08:32:26PM +0200, Maxim Sobolev scribbled:
| "Michael C . Wu" wrote:
| > On Wed, Dec 27, 2000 at 05:57:19PM +0200, Maxim Sobolev scribbled:
| > | Motomichi Matsuzaki wrote:
| > I think that making this "hack" a russian/xxxfs port and I think
| > everyone can be happy. If you want unicode FS like this, perhaps you
| > can have a sysutils/unicodefs.  :)

| No, it's no way a ports- commit.

Thank you for the one sentence reply without giving any reasons.
As a community, I thought we are supposed to communicate.
I have expressed my reasons and ideas, and you return the favor
with an one line comment.  :)

There is nothing wrong with have a port install a KLD, vmware does it.
And ports/emulators/linux_base depends on linux.ko. 

keichii@recursive:/usr/ports$ ls japanese/msdosfs/
Makefile files/   patches.5/   pkg-descr
distinfo patches.4/   pkg-comment  pkg-plist
keichii@recursive:/usr/ports$ ls chinese/big5fs/
Makefile distinfo files/   pkg-comment  pkg-descrpkg-plist
keichii@recursive:/usr/ports$ cat chinese/big5fs/pkg-descr 
This port installs two kernel modules, cd9660.ko and
msdos.ko, which will let users read Big5 filenames on
Joliet and VFAT filesystems.

Why do you think we did this?  You have admitted that this is an
ugly hack.  Since when did we allow ugly hacks in the kernel when
we can avoid it? Japanese/Chinese chose to do this because we
do not want dirty stuff in the kernel.  We have had this FS
support since 2.2.x.  

Please understand that we do not want hacks, and we certainly do
not want to be reliant on unicode alone.  We should never ever
assume stuff in I18N, and you are doing exactly this.  Have you
any idea what this would cause?  Do you know how hard it is to remove
something after it works for a while?  We do NOT ever want to have to
do legacy support in the future, because *you* want unicode and 
you want it now.  

In addition, this would probably mean laziness in the future to 
do this support properly.  In -SMP, they are avoiding to do hacks
to make things work temporarily.  Why should I18N do otherwise?

You can commit this to work with iconv() after iconv() gets in.
I would personally cheer you on.

I apologize for any harshness in the emails, it is quite hard
to express things without facial expressions.  I think we all
care about the project a lot.  Please be assured
that I mean no offense to you.
-- 
+--+
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+--+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]


"Michael C . Wu" wrote:

> On Wed, Dec 27, 2000 at 05:57:19PM +0200, Maxim Sobolev scribbled:
> | Motomichi Matsuzaki wrote:
> |
> | > At Wed, 27 Dec 2000 15:38:58 +0200,
> | > Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> | > > > But your solution is no effective and much harmful to multibyte users.
> | > > You are not quite right. For multibyte users my solution (workaround?) is at 
>least equial to the previous no-unicode case . I do
> | > > not see how it can be harmful.
> | >
> | > 1. In just your workaround, multibyte users will take no merits.
> | >
> | > 2. Based on your direction, the size of loadable conversion table
> | >will immensely expand for multibyte support, or be abandoned.
> | >Fundamental misdesign will lead to such unfortunate situation.
> | >So I said your solution was harmful.
> |
> | Proposed by me patches is no way an official direction of the Project and as I 
>advertised are merely a workaround to allow non-English
> | users to read CD with native filenames until comprehensive iconv for kernel will 
>be introduced. I would be glad if someone will
> | replace my hack with more generic solution.
>
> I think that making this "hack" a russian/xxxfs port and I think
> everyone can be happy. If you want unicode FS like this, perhaps you
> can have a sysutils/unicodefs.  :)

No, it's no way a ports- commit.

-Maxim



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: NFS/VM panic in current with INVARIANTS

2000-12-27 Thread Matt Dillon


:
:It looks like you guys got it! What is currently checked in (by Assar)
:is working fine! :-)
:
:M

Excellent news!

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

2000-12-27 Thread Konstantin Chuguev

"Michael C . Wu" wrote:

> As to the progress of iconv, we should have it soon, as soon as
> itojun and I work out how to import either the Citrus code
> or Konstantin's code.
>

As I could see from the CVSed Citrus code, it's a locale library rather than iconv,
and it's just got the stub calls of iconv functions. So I thought Citrus and iconv
complement each other and don't do the same. Am I wrong?

As for the iconv library itself, its userland part is complete. I'm really busy
these days despite Christmas and the New Year, but I expect to release v2.1 in 3
weeks with the following changes:

   * the two patches from ports will be incorporated;
   * a few charsets added (to provide compatibility with the libiconv port and to
 be able to use glib-1.3 with iconv - the only port still depending on
 libiconv);
   * memory and file management functions moved into a separate file; then a
 kernel-side iconv implementation can compile iconv with its own specific
 memory and file management functions (from a different file).

I tried to write a kernel module, but I don't have enough knowledge of the kernel.
If anybody would like to do it, I am ready to help.

Regards,
Konstantin.

--
  * *Konstantin Chuguev - Application Engineer
   *  *  Francis House, 112 Hills Road
 *   Cambridge CB2 1PQ, United Kingdom
 D  A  N  T  E   WWW:http://www.dante.net

N'²æìr¸zÇ§vf¢Ú&j:+v¨· è®"¶§²æìr¸yúÞy»rêëz{bØ^nr¡ûazg¬±¨

Re: Cardbus woes

2000-12-27 Thread Jonathan Chen

On Thu, Dec 14, 2000 at 12:47:51PM -0800, John Baldwin wrote:
> In other news, while wandering through the cardbus code, I discovered that
> pccbb softc's have an internal mutex much to my surprise, and that they weren't
> quite being used properly AFAICT.  In the pccb0 kthread, they were
> acquired/released without Giant.  However, in the rest of the pccbb driver,
> they are acquired/released with Giant.  This leads to lock order violations 
> which could potentially deadlock the machine at some point.  Also, the pccbb0
> kthread holds the mutex across the entire card insertion and removal events,
> which is not quite right.  Mutexes should only be held for short periods of
> time.  As such, I've futzed around with the mutex operations in the pccbb
> driver some.  It may not be completely correct, but I think it is an
> improvement.  The patch for this can be found at
> http://www.FreeBSD.org/~jhb/patches/pccbb.patch.

[I just now recalled your mentioning this a while back, so here's my much
delayed response]

Originally I had write the code with spl's, and at one point decided to
convert them to mutex after finding spl's don't do anything.  However, I
don't claim to know a whole lot about mutexes or FreeBSD's implementation
of it.  Perhaps someone can point me to the Great Definitive Source?

The first thing I'm unclear about is the deal with Giant.  My understanding
is that Giant is something one would acquire if he wanted to be really
exclusive, or something like that.  John - you mentioned I was
acquiring/releasing with/without Giant - but I don't see how I'm doing
things differently in and out of the kthread.  The only place I mentioned
Giant was right before kthread_exit, and that's necessary least
kthread_exit calls panic() on me.  On your patch, you acquire Giant at the
start of the kthread - wouldn't that hold onto the lock until the thread
exits, and make other things attempting to lock Giant block?

As for the 'holding onto mutex for a long time' problem, I'm not sure if
your solution is best.  I originally put in the locks firstly because
that's how NetBSD had it, and secondly so that card removal interrupts
while card is still attaching wouldn't be lost.  Your patched version
allows for wakeup() to be called while insertion/removal is being
processed.  I've glanced through the code and didn't see anything that
requires mutual exclusivity between the kthread the the interrupt handler,
so perhaps a better solution would be to simply not use mutex at all?

Comments?

-- 
(o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
 \\\_\Jonathan Chen  [EMAIL PROTECTED]   /_///
 <)  No electrons were harmed during production of this message (>
 ~

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]


On Wed, Dec 27, 2000 at 05:57:19PM +0200, Maxim Sobolev scribbled:
| Motomichi Matsuzaki wrote:
| 
| > At Wed, 27 Dec 2000 15:38:58 +0200,
| > Maxim Sobolev <[EMAIL PROTECTED]> wrote:
| > > > But your solution is no effective and much harmful to multibyte users.
| > > You are not quite right. For multibyte users my solution (workaround?) is at 
|least equial to the previous no-unicode case . I do
| > > not see how it can be harmful.
| >
| > 1. In just your workaround, multibyte users will take no merits.
| >
| > 2. Based on your direction, the size of loadable conversion table
| >will immensely expand for multibyte support, or be abandoned.
| >Fundamental misdesign will lead to such unfortunate situation.
| >So I said your solution was harmful.
| 
| Proposed by me patches is no way an official direction of the Project and as I 
|advertised are merely a workaround to allow non-English
| users to read CD with native filenames until comprehensive iconv for kernel will be 
|introduced. I would be glad if someone will
| replace my hack with more generic solution.

I think that making this "hack" a russian/xxxfs port and I think
everyone can be happy. If you want unicode FS like this, perhaps you
can have a sysutils/unicodefs.  :) 

After all, what are KLD's for but modularity? :)


-- 
+--+
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+--+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]


On Wed, Dec 27, 2000 at 12:05:57PM +0200, Maxim Sobolev scribbled:
| Several days ago I got a CD with Russian filenames on it and discovered that
| I'm unable to read those filenames. After some hacking I produced a patch,
| which should solve this problem in the manner similar to what we have in
| msdosfs module (i.e. user-provided conversion table). I have to emphasize that
| it's a temporary solution until we will have iconv support in kernel.
| 
| Please somebody review attached patches.

Please do not assume Unicode.  I18N/L10N efforts have been crying for
programmers to *not* and *never* assume *anything*.  :)

Also, this belongs more on -i18n more than anything else.  I really
do not want to generate all the traffic on -i18n alone.. :)

Have you seen ports/chinese/big5fs?  Japanese/Korean do the same thing too
You could simply make a port of this that loads KLD's.  This enables us 
to have the support without having hacks in src/sys.  I talked
to Boris at length about this.  And I think this would be the best way
to implement "temporary" hacks.

As to the progress of iconv, we should have it soon, as soon as
itojun and I work out how to import either the Citrus code
or Konstantin's code. 

If you make this a port, I say "go for it." :) If you wish to commit
to src/sys, I have strong doubts about this.  I hope you do not
mind my bluntness about this, as I really want to express the feelings.

Merry Christmas and a Happy New Year,
Michael
-- 
+--+
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
| http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. |
+--+


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

Motomichi Matsuzaki wrote:

> At Wed, 27 Dec 2000 15:38:58 +0200,
> Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> > > But your solution is no effective and much harmful to multibyte users.
> > You are not quite right. For multibyte users my solution (workaround?) is at least 
>equial to the previous no-unicode case . I do
> > not see how it can be harmful.
>
> 1. In just your workaround, multibyte users will take no merits.
>
> 2. Based on your direction, the size of loadable conversion table
>will immensely expand for multibyte support, or be abandoned.
>Fundamental misdesign will lead to such unfortunate situation.
>So I said your solution was harmful.

Proposed by me patches is no way an official direction of the Project and as I 
advertised are merely a workaround to allow non-English
users to read CD with native filenames until comprehensive iconv for kernel will be 
introduced. I would be glad if someone will
replace my hack with more generic solution.

-Maxim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

At Wed, 27 Dec 2000 15:38:58 +0200,
Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> > But your solution is no effective and much harmful to multibyte users.
> You are not quite right. For multibyte users my solution (workaround?) is at least 
>equial to the previous no-unicode case . I do
> not see how it can be harmful.

1. In just your workaround, multibyte users will take no merits.

2. Based on your direction, the size of loadable conversion table
   will immensely expand for multibyte support, or be abandoned.
   Fundamental misdesign will lead to such unfortunate situation.
   So I said your solution was harmful.

-- 
Motomichi Matsuzaki <[EMAIL PROTECTED]> 
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]


Motomichi Matsuzaki wrote:

> At Wed, 27 Dec 2000 14:54:00 +0200,
> Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> > > The Joliet extension are built on Unicode basis,
> > > and is the "multilingual" filesystem.
> > > We can found CDs which contain files named by all of
> > > English, French, Russian, Chinese, and Japanese languages.
> > > So charset conversion per mount is not sufficient.
> > You can specify multiple charset conversion tables for each mount point, the 
>problem is only to create appropriate conversion
> > tables (I do not have any CDs with anything than English/Russian filenames :-> ).
>
> Suppose a file which name contains multilingual characters.
>
> Think Japanese researchers of Russian literatures.
> The Microsoft Word document files about their works may have
> such complexed filenames. And Joliet can handle them.

Yeah, but unfortunately our fs interface can't. :(

> The multiple mount point solution is insufficient to these situations.
>
> > > 4. Rough idea of me
> > > My preliminary idea to the filesystem I18N:
> > Thanks for the pointing out, but I think that your proposal is too
> > generic to be committed any time soon (not even to mention MFC'ing it).
>
> Yes, you're right. I have no more than such rough idea indeed.
>
> > What I'm proposing here is quick'n'dirty (and limited as so) solution to allow 
>mounting CD's with unicode filenames on it.
> > This solution is targeted to be temporary until iconv-based kernel interfaces will 
>appear.
>
> But your solution is no effective and much harmful to multibyte users.

You are not quite right. For multibyte users my solution (workaround?) is at least 
equial to the previous no-unicode case . I do
not see how it can be harmful.

-Maxim



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]



At Wed, 27 Dec 2000 14:54:00 +0200,
Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> > The Joliet extension are built on Unicode basis,
> > and is the "multilingual" filesystem.
> > We can found CDs which contain files named by all of
> > English, French, Russian, Chinese, and Japanese languages.
> > So charset conversion per mount is not sufficient.
> You can specify multiple charset conversion tables for each mount point, the problem 
>is only to create appropriate conversion
> tables (I do not have any CDs with anything than English/Russian filenames :-> ).

Suppose a file which name contains multilingual characters.

Think Japanese researchers of Russian literatures.
The Microsoft Word document files about their works may have 
such complexed filenames. And Joliet can handle them.

The multiple mount point solution is insufficient to these situations.

> > 4. Rough idea of me
> > My preliminary idea to the filesystem I18N:
> Thanks for the pointing out, but I think that your proposal is too
> generic to be committed any time soon (not even to mention MFC'ing it).

Yes, you're right. I have no more than such rough idea indeed.

> What I'm proposing here is quick'n'dirty (and limited as so) solution to allow 
>mounting CD's with unicode filenames on it.
> This solution is targeted to be temporary until iconv-based kernel interfaces will 
>appear.

But your solution is no effective and much harmful to multibyte users.
The "loading conversion tables on every mount points" idea is totally wrong.

-- 
Motomichi Matsuzaki <[EMAIL PROTECTED]> 
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [FreeBSD-tech-jp 2990] Re: Unicode support in cd9660 [patchfor review]

2000-12-27 Thread Noriyuki Soda


> On Wed, 27 Dec 2000 21:48:52 +0900 (JST),
Kenichi Okuyama <[EMAIL PROTECTED]> said:

okuyamak> So, there's only two selection.

No. there is another one.

I.e.
3) Always use pair of "codeset" name and "codepoint" value
  for interface.

This keeps compatibility with current filesystems which use legacy
encodings like ISO-8859-1 or EUC-JP as pathnames.
My proposal follows this course.
--
soda


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]


Motomichi Matsuzaki wrote:

> At Wed, 27 Dec 2000 12:05:57 +0200,
> Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> > Several days ago I got a CD with Russian filenames on it and discovered that
> > I'm unable to read those filenames. After some hacking I produced a patch,
>
> Vladimir Kushnir's patch will be for it.
>
> 
>http://www.freebsd.org/cgi/getmsg.cgi?fetch=270425+0+/usr/local/www/db/text/2000/freebsd-hackers/20001203.freebsd-hackers
>
> and it is based on my patch:
>
> http://triaez.kaisei.org/~mzaki/joliet/
>
> > which should solve this problem in the manner similar to what we have in
> > msdosfs module (i.e. user-provided conversion table). I have to emphasize that
> > it's a temporary solution until we will have iconv support in kernel.
>
> *PLEASE* be careful about filename I18N.
>
> 1. Joliet extension
>
> The Joliet extension are built on Unicode basis,
> and is the "multilingual" filesystem.
> We can found CDs which contain files named by all of
> English, French, Russian, Chinese, and Japanese languages.
> So charset conversion per mount is not sufficient.

You can specify multiple charset conversion tables for each mount point, the problem 
is only to create appropriate conversion
tables (I do not have any CDs with anything than English/Russian filenames :-> ).

> 3. Relation to userland applications
>
> Currently, conversion table between Unicode and local charset are
> widely needed and implemented, for such as the Joliet extension,
> the FAT filesystem, TrueType rasterizers, WWW browsers, and so on.
> We should share the tables as possible for their consintency.
> So the ideal solution to code conversion are not in-kernel table
> but userland shared library.
> Therefore, filename code conversion should also be done in userland
> as possible.
>
> 4. Rough idea of me
>
> My preliminary idea to the filesystem I18N:
>
> * filenames recorded on Unix filesystems (e.g. FFS, MFS) use
>   an arbitrary codeset, for example Unicode.
>
> * interface between kernel and userland should use
>   filesystem-safe encoding, for example UTF-8.
>
> * userland applications can convert from/to the user-requested
>   charsets, such as latin-2, koi8, and euc-jp, using shared library.
>
> * the Joliet extension and UDF, which based on Unicode, need
>   no in-kernel conversion, in case Unix filesystems use Unicode.
>
> * the FAT filesystem, which use both Unicode and conventional
>   codepages, requires in-kernel conversion in order to
>   write the conventional 8.3 names.
>
> Any ideas?

Thanks for the pointing out, but I think that your proposal is too generic to be 
committed any time soon (not even to mention
MFC'ing it). Moreover, as I pointed out, currently efforts to provide generic Unicode 
functionality in kernel/userland are
underway, so it is likely that part of your work will be duplicated/obsoleted.

What I'm proposing here is quick'n'dirty (and limited as so) solution to allow 
mounting CD's with unicode filenames on it.
This solution is targeted to be temporary until iconv-based kernel interfaces will 
appear.

-Maxim



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [FreeBSD-tech-jp 2988] Re: Unicode support in cd9660 [patchfor review]

2000-12-27 Thread Kenichi Okuyama


I don't know why this mail came to me, but since I was given a
chance(^^;)


> "MM" == Motomichi Matsuzaki <[EMAIL PROTECTED]> writes:
MM> * filenames recorded on Unix filesystems (e.g. FFS, MFS) use
MM>   an arbitrary codeset, for example Unicode.

Rather, let's use "codepage + codeset" information, so that we can
find the difference between Chinese "BONE" and Japanese "BONE".
WE NEED THEM TO BE DIFFERENT, YOU KNOW.

For example, save filename using 64bit per character, containing
codepage with 32bit, and codeset using UCS-4.

# We have enough diskspace and Memory to handle them, don't worry.
# And even if we didn't now, we will, within 2 years.

Do normalization for codepage against those characters that will not
be effected by codepage, so that comparison will be easier.


Many might say it's rediculous to have filename encoding different
from system call interface coding systems. But this is so only
because BUGGY UNICODE is current trend.

If we could have codeset that does not need codepage, the problem
did not occur. And the very reason why we happend to have this BUGGY
UNICODE, is because they stint bits. We should not do the same
mistakes.

So, there's only two selection.

1) Let's use Unicode for interface, and let's have large enough
   bits per characeter internally... like 256bits/character.

2) Let's create Truely Unified coding system, which not only allow
   us to describe the "currently used language", but also,
   exterminated languages like Cuneiform Characters as well.
   And use it for internally, and interface.
   ( This, also requres lot larger coding space than current.
 I think we do need 256bits anyway ).

best regards,
 
Kenichi Okuyama@Tokyo Research Lab, IBM-Japan, Co.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [FreeBSD-tech-jp 2988] Re: Unicode support in cd9660 [patch for review]

2000-12-27 Thread Noriyuki Soda


> On Wed, 27 Dec 2000 21:28:19 +0900,
Motomichi Matsuzaki <[EMAIL PROTECTED]> said:

msaki> Any ideas?

There was dicussion about this issue on [EMAIL PROTECTED]
mailing list with Subject: "Unicode support in kernel" and
"code set recoding engine, V2" in October and November, 1999.

Summary of my proposal is the following:
http://mail-index.netbsd.org/tech-kern/1999/10/15/0009.html
http://mail-index.netbsd.org/tech-kern/1999/11/23/0002.html
(the former one is somewhat difficult, though)
--
soda


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: NFS/VM panic in current with INVARIANTS

2000-12-27 Thread Mark Murray


It looks like you guys got it! What is currently checked in (by Assar)
is working fine! :-)

M

> :--=-=-=
> :
> :Matt Dillon <[EMAIL PROTECTED]> writes:
> :> Well, yes... that's essentially what I suggested.  You didn't say
> :> anything about removing the externalized inlines, which is what you
> :> do in your patch.  Looks like a fine patch to me.
> :
> :Except it didn't work.  Now here's a patch that survived building a
> :kernel and modules.  ok?
> :
> :/assar
>
>lets see.. ok, I'm going to read the patch carefully this time..
> 
>This isn't quite what I had in mind.  You are still making an API
>change... you are now calling zalloci() from zalloc() for non-SMP boxes.
>There is no need to do that.
> 
>Instead what I would recommend is making zalloc() and zfree() real
>procedures, putting them in vm_zone.c, and removing their inlines from
>vm_zone.h.  i.e. not have *ANY* inlines at all in vm_zone.h
> 
>Then as real procedures in vm_zone.c these functions can have the
>#ifdef SMP / related code left intact.
> 
>   -Matt
> 
> :
> :--=-=-=
> :Content-Disposition: attachment; filename=zalloc-diff
> :
> :Index: vm_zone.c
> :===
> :RCS file: /home/ncvs/src/sys/vm/vm_zone.c,v
> :retrieving revision 1.35
> :diff -u -w -r1.35 vm_zone.c
> :--- vm_zone.c2000/12/13 10:01:00 1.35
> :+++ vm_zone.c2000/12/27 00:59:14
> :@@ -32,6 +32,59 @@
> : 
> : static MALLOC_DEFINE(M_ZONE, "ZONE", "Zone header");
> : 
> :+#define ZONE_ERROR_INVALID 0
> :+#define ZONE_ERROR_NOTFREE 1
> :+#define ZONE_ERROR_ALREADYFREE 2
> :+
> :+#define ZONE_ROUNDING   32
> :+
> :+#define ZENTRY_FREE 0x12342378
> :+/*
> :+ * void *zalloc(vm_zone_t zone) --
> :+ *  Returns an item from a specified zone.
> :+ *
> :+ * void zfree(vm_zone_t zone, void *item) --
> :+ *  Frees an item back to a specified zone.
> :+ */
> :+static __inline__ void *
> :+_zalloc(vm_zone_t z)
> :+{
> :+void *item;
> :+
> :+#ifdef INVARIANTS
> :+if (z == 0)
> :+zerror(ZONE_ERROR_INVALID);
> :+#endif
> :+
> :+if (z->zfreecnt <= z->zfreemin)
> :+return _zget(z);
> :+
> :+item = z->zitems;
> :+z->zitems = ((void **) item)[0];
> :+#ifdef INVARIANTS
> :+if (((void **) item)[1] != (void *) ZENTRY_FREE)
> :+zerror(ZONE_ERROR_NOTFREE);
> :+((void **) item)[1] = 0;
> :+#endif
> :+
> :+z->zfreecnt--;
> :+z->znalloc++;
> :+return item;
> :+}
> :+
> :+static __inline__ void
> :+_zfree(vm_zone_t z, void *item)
> :+{
> :+((void **) item)[0] = z->zitems;
> :+#ifdef INVARIANTS
> :+if (((void **) item)[1] == (void *) ZENTRY_FREE)
> :+zerror(ZONE_ERROR_ALREADYFREE);
> :+((void **) item)[1] = (void *) ZENTRY_FREE;
> :+#endif
> :+z->zitems = item;
> :+z->zfreecnt++;
> :+}
> :+
> : /*
> :  * This file comprises a very simple zone allocator.  This is used
> :  * in lieu of the malloc allocator, where needed or more optimal.
> :Index: vm_zone.h
> :===
> :RCS file: /home/ncvs/src/sys/vm/vm_zone.h,v
> :retrieving revision 1.13
> :diff -u -w -r1.13 vm_zone.h
> :--- vm_zone.h1999/08/28 00:52:44 1.13
> :+++ vm_zone.h2000/12/27 00:59:14
> :@@ -43,7 +43,6 @@
> : struct vm_zone  *znext; /* list of zones for sysctl */
> : } *vm_zone_t;
> : 
> :-
> : voidzerror __P((int)) __dead2;
> : vm_zone_t   zinit __P((char *name, int size, int nentries, int flags,
> :int zalloc));
> :@@ -57,77 +56,16 @@
> :int nitems));
> : void *  _zget __P((vm_zone_t z));
> : 
> :-#define ZONE_ERROR_INVALID 0
> :-#define ZONE_ERROR_NOTFREE 1
> :-#define ZONE_ERROR_ALREADYFREE 2
> :-
> :-#define ZONE_ROUNDING   32
> :-
> :-#define ZENTRY_FREE 0x12342378
> :-/*
> :- * void *zalloc(vm_zone_t zone) --
> :- *  Returns an item from a specified zone.
> :- *
> :- * void zfree(vm_zone_t zone, void *item) --
> :- *  Frees an item back to a specified zone.
> :- */
> :-static __inline__ void *
> :-_zalloc(vm_zone_t z)
> :-{
> :-void *item;
> :-
> :-#ifdef INVARIANTS
> :-if (z == 0)
> :-zerror(ZONE_ERROR_INVALID);
> :-#endif
> :-
> :-if (z->zfreecnt <= z->zfreemin)
> :-return _zget(z);
> :-
> :-item = z->zitems;
> :-z->zitems = ((void **) item)[0];
> :-#ifdef INVARIANTS
> :-if (((void **) item)[1] != (void *) ZENTRY_FREE)
> :-zerror(ZONE_ERROR_NOTFREE);
> :-((void **) item)[1] = 0;
> :-#endif
> :-
> :-z->zfreecnt--;
> :-z->znalloc++;
> :-return item;
> :-}
> :-
> :-static __inline__ void
> :-_zfree(vm_zone_t z, void *item)
> :-{
> :-((void **) item)[0] = z->zitems;
> :-#ifdef INVARIANTS
> :-if (((void **) item)[1] == (void *) ZENTRY_FREE)
> :-zerror(ZONE_ERROR_ALREADYFREE);
> :-((v

Re: Unicode support in cd9660 [patch for review]

At Wed, 27 Dec 2000 12:05:57 +0200,
Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> Several days ago I got a CD with Russian filenames on it and discovered that
> I'm unable to read those filenames. After some hacking I produced a patch,

Vladimir Kushnir's patch will be for it.

http://www.freebsd.org/cgi/getmsg.cgi?fetch=270425+0+/usr/local/www/db/text/2000/freebsd-hackers/20001203.freebsd-hackers

and it is based on my patch:

http://triaez.kaisei.org/~mzaki/joliet/

> which should solve this problem in the manner similar to what we have in
> msdosfs module (i.e. user-provided conversion table). I have to emphasize that
> it's a temporary solution until we will have iconv support in kernel.

*PLEASE* be careful about filename I18N.

1. Joliet extension

The Joliet extension are built on Unicode basis,
and is the "multilingual" filesystem.
We can found CDs which contain files named by all of
English, French, Russian, Chinese, and Japanese languages.
So charset conversion per mount is not sufficient.

2. FAT

The current FAT filesystem use Unicode, however,
the FAT filesystem is not "multilingual" because of
local codepages used for the conventional 8.3 names.
Thus, per-mount codeset conversion are sufficient,
but additional codepage conversion is needed.
This conversion is currently achieved by 128bytes tables specified in
mount_msdos(8), but this way have no consideration about
multibyte codesets such as CJK.

3. Relation to userland applications

Currently, conversion table between Unicode and local charset are
widely needed and implemented, for such as the Joliet extension,
the FAT filesystem, TrueType rasterizers, WWW browsers, and so on.
We should share the tables as possible for their consintency.
So the ideal solution to code conversion are not in-kernel table
but userland shared library.
Therefore, filename code conversion should also be done in userland
as possible.

4. Rough idea of me

My preliminary idea to the filesystem I18N:

* filenames recorded on Unix filesystems (e.g. FFS, MFS) use
an arbitrary codeset, for example Unicode.

* interface between kernel and userland should use
filesystem-safe encoding, for example UTF-8.

* userland applications can convert from/to the user-requested
charsets, such as latin-2, koi8, and euc-jp, using shared library.

* the Joliet extension and UDF, which based on Unicode, need
no in-kernel conversion, in case Unix filesystems use Unicode.

* the FAT filesystem, which use both Unicode and conventional
codepages, requires in-kernel conversion in order to
write the conventional 8.3 names.

Any ideas?

--
Motomichi Matsuzaki <[EMAIL PROTECTED]>
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

Àíäðåé ×åðíîâ wrote:

> On Wed, Dec 27, 2000 at 12:05:57 +0200, Maxim Sobolev wrote:
> > Please somebody review attached patches.
> > + u_char  *ctable[256];   /* Table for converting unicode filenames */
>
> You deside to use per- Unicode base conversion table, it takes much memory

Not too much - only 1K per cd9660 mount point for machines with sizeof(u_char *) == 4.
This also provides opportunity to load several tables with different bases
transparently.

> and don't satisfy in any case because you miss other graphics related to
> charset of OS that made CD (I mean high code table characters like
> copyright, angle quotes and so on). Better variant is to use exact to/from
> Unicode conversion tables, if you know exact charset of OS that made CD.

I'm now sure how could I obtain charset for each of dozen+ OSes that may create a CD.

> I.e. I suggest to use the method that MSDOSFS currently use which is
> foreign-charset - Unicode - native charset. It takes small memory and
> convert names without loss of some characters.

I don't see any problems, because it's likely that usual special high code table
characters (copyright, angle quotes and so on) will be represented using Unicode
charcodes with first byte (`base') equal to 0, so they can be mapped directly into
native charset. In my implementation only Unicode characters with base !=0 are to be
translated. All less usual characters (graphics and so on) can be translated by
extending appropriate codetable to include additional translation tables with different
bases (e.g. 0x25 for graphics chars etc.).

-Maxim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Unicode support in cd9660 [patch for review]

On Wed, Dec 27, 2000 at 12:05:57 +0200, Maxim Sobolev wrote:
> Please somebody review attached patches.
> + u_char  *ctable[256];   /* Table for converting unicode filenames */

You deside to use per- Unicode base conversion table, it takes much memory
and don't satisfy in any case because you miss other graphics related to
charset of OS that made CD (I mean high code table characters like
copyright, angle quotes and so on). Better variant is to use exact to/from
Unicode conversion tables, if you know exact charset of OS that made CD.
I.e. I suggest to use the method that MSDOSFS currently use which is
foreign-charset - Unicode - native charset. It takes small memory and
convert names without loss of some characters.

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Unicode support in cd9660 [patch for review]