Re: vn, vnconfig and MFS death-warrant!
At Tue, 30 Jan 2001 11:30:30 +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: March 1st I will remove the functionality from mount_mfs and vnconfig, leaving only the message which will be an error obviously. April 1st I will remove vn, vnconfig and mount_mfs entirely. I think we should postpone the complete removing for a year (on release of 5.2), to give people a migration sugar. System upgrading (4.x - 5.x) will cause confusing situation, for example, living old 4.x vnconfig binary and new and splendid mdconfig. -- 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: vn, vnconfig and MFS death-warrant!
Uh, self castigation. Sorry for inconvenience. At Tue, 30 Jan 2001 11:30:30 +0100, Poul-Henning Kamp [EMAIL PROTECTED] wrote: March 1st I will remove the functionality from mount_mfs and vnconfig, leaving only the message which will be an error obviously. April 1st I will remove vn, vnconfig and mount_mfs entirely. I think we should postpone the complete removing for a year till (on release of 5.2), to give people a migration sugar. == Otherwise System upgrading (4.x - 5.x) will cause confusing situation, ^ for example, living old 4.x vnconfig binary and together new and splendid mdconfig. ^ -- 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
CD Extra disks on atapi-cd
Hi.
I've found that -current kernel couldn't mount CD-Extra disks on
ATAPI CD drives.
For example:
Starting track = 1, ending track = 14, TOC size = 122 bytes
track start duration block length type
-
1 0:02.00 0:11.52 0 727 audio
2 0:11.52 3:58.55 727 17755 audio
3 4:08.32 2:15.55 18482 10030 audio
4 6:22.12 3:10.50 28512 14150 audio
5 9:30.62 3:02.13 42662 13513 audio
6 12:31.00 2:54.00 56175 12900 audio
7 15:23.00 3:50.40 69075 17140 audio
8 19:11.40 2:59.12 86215 13287 audio
9 22:08.52 3:04.30 99502 13680 audio
10 25:11.07 2:06.05 1131829305 audio
11 27:15.12 2:54.35 122487 12935 audio
12 30:07.47 3:17.13 135422 14638 audio
13 33:22.60 12:53.27 150060 57852 audio
14 46:14.12 20:50.58 207912 93658 data
170 67:02.70 - 301570 - -
Tracks 1-13 are normal CD-DA in the first session,
and track 14 is the ISO9660 filesystem which consists of
XA Mode 2 Form 1 sectors (2048bytes/sector) in the second session.
This disk can be mounted on my SCSI CD drive,
but not on my ATAPI CD drive (with EINVAL).
I applied the following patch,
and then I can successfully mount the disk.
Is this a right treatment?
--- sys/dev/ata/atapi-cd.c Fri Jan 19 06:01:25 2001
+++ sys/dev/ata/atapi-cd.c.new Sun Jan 28 08:15:37 2001
@@ -1227,7 +1227,7 @@
static void
acd_read_toc(struct acd_softc *cdp)
{
-int ntracks, len;
+int ntracks, len, t;
int8_t ccb[16];
bzero(cdp-toc, sizeof(cdp-toc));
@@ -1275,7 +1275,14 @@
cdp-info.volsize = ntohl(cdp-info.volsize);
cdp-info.blksize = ntohl(cdp-info.blksize);
-cdp-block_size = (cdp-toc.tab[0].control 4) ? 2048 : 2352;
+
+cdp-block_size = 2352;
+for (t = 0; t cdp-toc.hdr.ending_track; t++) {
+if (cdp-toc.tab[t].control 4) {
+ cdp-block_size = 2048;
+ break;
+}
+}
bzero(cdp-disklabel, sizeof(struct disklabel));
strncpy(cdp-disklabel.d_typename, " ",
--
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]
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: 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: irq7 panic
Hi, At Tue, 7 Nov 100 07:39:25 -0600 (CST), Jim Bryant [EMAIL PROTECTED] wrote: I've been getting a hard panic/page fault whenever attempting to print for a few weeks now. I have the same problem on the i386/SMP from Oct 10 to date. Sep 23 world works fine. dmesg: ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 I've found that it happens during the function fork_trampoline(), and caused by calling indefinite function which shoud be set by cpu_set_fork_handler(). When I request printing (lpr), the interrupt threads (irq7: lpt0) is create, then call the function, but there is no effective codes, and panic. -- 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: vx driver patch
At Sun, 05 Nov 2000 01:26:42 -0700, Warner Losh [EMAIL PROTECTED] wrote: I think this means lnc is the last one in the tree, but I could be wrong about that. I didn't do an actual grep... # find /usr/src/sys -type f |xargs grep COMPAT_PCI_DRIVER ./dev/hea/eni.c:COMPAT_PCI_DRIVER (eni_pci, eni_pci_device); ./dev/hfa/fore_load.c:COMPAT_PCI_DRIVER(fore_pci, fore_pci_device); ./dev/pdq/if_fpa.c:COMPAT_PCI_DRIVER (fpa, fpadevice); ./dev/vx/if_vx_pci.c:COMPAT_PCI_DRIVER (vx, vxdevice); ./dev/sym/sym_hipd.c:COMPAT_PCI_DRIVER (sym, sym_pci_driver); ./dev/lmc/if_lmc_fbsd3.c:#ifdef COMPAT_PCI_DRIVER ./dev/lmc/if_lmc_fbsd3.c:COMPAT_PCI_DRIVER(ti, lmcdevice); ./dev/lmc/if_lmc_fbsd3.c:#endif /* COMPAT_PCI_DRIVER */ ./dev/lnc/if_lnc_pci.c:COMPAT_PCI_DRIVER (lnc_pci, lnc_pci_driver); ./i386/isa/rp.c:COMPAT_PCI_DRIVER (rp_pci, rp_pcidevice); ./i386/isa/stallion.c:COMPAT_PCI_DRIVER (stlpci, stlpcidriver); ./pci/cy_pci.c:COMPAT_PCI_DRIVER(cy_pci, cy_device); ./pci/if_en_pci.c:COMPAT_PCI_DRIVER (en, endevice); ./pci/if_sr_p.c:COMPAT_PCI_DRIVER (sr_pci, sr_pci_driver); ./pci/meteor.c:COMPAT_PCI_DRIVER (meteor, met_device); ./pci/simos.c:COMPAT_PCI_DRIVER (simos, simos_driver); ./pci/pcivar.h:#define COMPAT_PCI_DRIVER(name, pcidata) \ ./pci/if_ar_p.c:COMPAT_PCI_DRIVER (ar_pci, ar_pci_driver); ./pci/alpm.c:COMPAT_PCI_DRIVER (alpm, alpm_device); -- 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: pccard_ether wouldn't kill dhclient when card is removed
Please, please commit this.
At Wed, 25 Oct 2000 01:31:57 +0900,
Motomichi Matsuzaki [EMAIL PROTECTED] wrote:
patch for revision 1.20:
--- /etc/pccard_ether Thu Oct 19 16:24:35 2000
+++ pccard_ether Wed Oct 25 01:27:05 2000
@@ -46,7 +46,7 @@
interface=$1
shift
-startstop=$2
+startstop=$1
shift
case ${startstop} in
@@ -101,7 +101,7 @@
;;
# Stop the interface
*)
- /sbin/ifconfig $device delete
+ /sbin/ifconfig ${interface} delete
stop_dhcp
;;
esac
--
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: dc0: watchdog timeout
At Mon, 23 Oct 2000 22:46:26 -0400 (EDT), Andrew Gallatin [EMAIL PROTECTED] wrote: Anybody else seeing 'dc0: watchdog timeout' since SMPng integration? Yes I have. I have this several times before SMPng integration at a high load situation. But, since the integration, it occurs frequently. links. I don't have tulip cards in any PCs, so it is hard for me to tell if this is an alpha issue or an if_dc driver issue.. FreeBSD 5.0-CURRENT #15: Sat Sep 23 07:12:39 JST 2000 CPU: Pentium II/Pentium II Xeon/Celeron (451.03-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 dc0: Intel 21143 10/100BaseTX port 0x10100-0x1017f mem 0x41353100-0x4135317f irq 10 at device 9.0 on pci0 dc0: interrupting at ISA irq 10 dc0: Ethernet address: 00:00:f8:07:b6:45 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: ADMtek AL981 10/100BaseTX port 0xd400-0xd4ff mem 0xe780-0xe78000ff irq 16 at device 15.0 on pci0 dc0: Ethernet address: 00:90:cc:a2:fa:82 miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto -- 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
pccard_ether wouldn't kill dhclient when card is removed
patch for revision 1.20:
--- /etc/pccard_ether Thu Oct 19 16:24:35 2000
+++ pccard_etherWed Oct 25 01:27:05 2000
@@ -46,7 +46,7 @@
interface=$1
shift
-startstop=$2
+startstop=$1
shift
case ${startstop} in
@@ -101,7 +101,7 @@
;;
# Stop the interface
*)
- /sbin/ifconfig $device delete
+ /sbin/ifconfig ${interface} delete
stop_dhcp
;;
esac
--
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: make release breakage - dokern.sh patch 2
Hi. At Tue, 24 Oct 2000 12:15:09 -0700, David O'Brien [EMAIL PROTECTED] wrote: Other candidates I've been pointed to include the removal of /boot/boot[12] and NFS IMO NFS needs to stay. It is *very* useful to many (including me). I vote for 'remove NFS away'. Yes, there are many people using NFS install, but it is site-specific. There are no services distributing FreeBSD via NFS in public. In such site-specific situation, you can make your *specific* floppies with NFS and without INET6 or some. IMHO, making install-floppies should be more easy. -- 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: make release breakage - dokern.sh patch 2
At Tue, 24 Oct 2000 13:08:26 -0700, David O'Brien [EMAIL PROTECTED] wrote: I vote for 'remove NFS away'. Yes, there are many people using NFS install, but it is site-specific. And INET6 isn't site specific. It certainly is everywhere but maybe .jp. I think INET6 is a grobal and public feature, because there are some IPv6 servers. IPv6 networks (6bone) WORKS, and you can get full FreeBSD distribution via IPv6 network if you have connectibity to world-wide 6bone. Not site-specific, IPv6 servers open to the world. Again. There is no public NFS servers for distributing FreeBSD as I know. You can't get any FreeBSD, even if you sends NFS packets to the Internet. Can I and anybody access your favorite NFS servers? -- 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: make release breakage - dokern.sh patch 2
At Wed, 25 Oct 2000 00:28:41 +0200, Wilko Bulte [EMAIL PROTECTED] wrote: IMO NFS needs to stay. It is *very* useful to many (including me). I vote for 'remove NFS away'. Yes, there are many people using NFS install, but it is site-specific. The same argument goes for IPV6. In other words: it all depends on your viewpoint. Again. NFS is site-specific service. IPv6 is world-wide service. Indeed, world-wide NFS is capable, but is somewhat ridiculous idea. And more, IPv6 is network layer feature, and NFS is session and higher layer feature like FTP, HTTP, AFS and so on. If IPv6 is disabled in IPv6-only environment, any of FTP, HTTP, NFS does not work. Disabling NFS causes minor impact compared with that, because switching to FTP is very easy, as already pointed out. NFS is for convenience, IPv6 is for life. The same argument goes for device drivers. Device drivers of storage devices are also for their lives. -- 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: config(8) weirdness
Hi. At Sun, 27 Aug 2000 15:16:01 +0200 (CEST), Alexander Leidinger [EMAIL PROTECTED] wrote: Can anyone success compiling kernel with the following config? # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #optionsATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices I've the same problem. This is obvous BUG of config(8), newly introduced 'count' feature. In /sys/conf/files.i386 : dev/ata/atapi-all.c count atapicd dev/ata/atapi-all.c count atapifd dev/ata/atapi-all.c count atapist On the current implementation, the first line is only effective, i.e. same as: dev/ata/atapi-all.c count atapicd #dev/ata/atapi-all.c count atapifd #dev/ata/atapi-all.c count atapist Then, atapi-all.c will be copiled only when atapicd is enabled. To exchange the lines of files.i386 takes effect as a symptomatic therapy. But..., fix for config(8) is needed. -- 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
PR i386/21657: nexus without initialization causes booting failed
Caution! If your machine is in P5 generation of i386 architecture, -current kernel would not boot up. See details on PR 21657. -- 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
NS DP83932 SONIC driver for pc98
Hi. I updated 'snc' driver for -current. This driver is only for NEC pc98 machines. http://triaez.kaisei.org/~mzaki/sonic/ This is very stable for usual operation. I hope this will be merged into the tree. -- 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: SMP mega-commit complete
At 6 Sep 2000 18:35:17 -0700, Jason Evans [EMAIL PROTECTED] wrote: If you run into issues that appear related to the SMP changes, and they aren't listed as known issues, please bring them up on the -smp or -current mailing list. this breaks building GENERIC kernel. cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/opt/usr/src/sys -I/opt/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /opt/usr/src/sys/i386/i386/genassym.c In file included from /opt/usr/src/sys/sys/signalvar.h:42, from /opt/usr/src/sys/sys/user.h:59, from /opt/usr/src/sys/i386/i386/genassym.c:66: machine/smp.h:19: #error SMP not supported with I386_CPU *** Error code 1 -- 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: hints static wiring
Ahh..., I tried to summarize my opinion. If you find any misunderstandings of me, please correct them. *** What's happen if there's no /boot/device.hints? case A kernel has no built-in hints ... some devices would not work, system would stall! You can tell whole hints to the kernel interactively on /boot/loader, however it's a tiresome task. YES, this is the abominable situation. To avoid it, you should be warned at kernel-install-time. case B kernel has built-in hints (i.e. config has "hints" line) B-1: wrong hints ... some devices would not work, system could stall. You can correct hints interactively on /boot/loader. You can override hints by making /boot/device.hints also. B-2: suitable hints ... everything goes OK You can override hints by /boot/device.hints. Currently, 'make install' will be aborted in every case above, but this treatment is suitable only for case A. And it would be technically possible to limit this treatment to case A. This treatment will do accoring to Makefile, which is controled by config(8) (src/usr.sbin/config/mkmakefile.c). -- 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
config(8) weirdness
Hi, Can anyone success compiling kernel with the following config? # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #optionsATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices In my box (freshly built today), this config doesn't make atapi-all.o, so that kernel linking get fails. To make kernel, I needed enable 'atapicd'. -- 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
hints static wiring
When kernel is built with static device wiring (i.e. 'hints' line is enabled in the config file), is /boot/device.hints required? Doing 'make install' without /boot/device.hints is failed, saying "You must set up a /boot/device.hints file first." Is this right? -- 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
NS DP83932 SONIC driver
Hi. I ported SONIC ethernet driver into FreeBSD from NetBSD/pc98. The original driver (named 'sn') on NetBSD/pc98 is for several NEC C-bus(alike ISA) and PCMCIA card. There is already 'sn' driver on FreeBSD for SMC 9xxx series ethernet, so I renamed to 'snc' after "SONIC". Is there any objection to this name? And I wonder, Is there any ISA card using this chip? For both 5-current and 4-stable source codes (beta quality) are: http://triaez.kaisei.org/~mzaki/sonic/ Thank you. -- 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: Please test for 8G-OVER-Booting with /boot/loader
Hi At Tue, 28 Mar 2000 06:46:27 -0500 (EST), John Baldwin [EMAIL PROTECTED] wrote: Looks good to me, but I need to test it to make sure. I will also look at seeing if I can squeeze the int 13 extension installation check into boot1 and boot0 so that they will use packet mode automatically as well. Oh, I remember. This just checks if the controller supports LBA. You also need to check if the drive supports LBA. The problem is with older drives. Hmm, I'll look around to see if you can ask the BIOS for drive capabilities. I have convinced that there are no widespread services to query whether drive supports LBA. So I changed my patch to use Packet I/F only when we need to access over 8GB. Please review and test following patch. Thanks. -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan biosdisk.c.diff
Please test for 8G-OVER-Booting with /boot/loader
Hi. I made a patch for /sys/boot/i386/libi386/biosdisk.c (attached). This aimed to enable /boot/loader to manage 8G-OVER-Disks. 0. you need 8G-OVER-ENABLED BIOS for your motherboard (check whether your BIOS has Int 13 Extended Interface) 1. teach boot0 using extended BIOS (See boot0cfg(8)) # boot0cfg -o packet YOUR-BOOT-DEVICE 2. install boot2 which have extended BIOS support # cd /sys/boot/i386/boot2; make B1FLAGS=0x80 clean install 3. patch to libi386 and install new /boot/loader # cd /sys/boot/i386/libi386/; patch THIS-MAIL; make # cd /sys/boot/i386/loader; make install -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Science, Faculty of Sciences, Univ. of Tokyo, Japan biosdisk.c.diff
Re: pc98
who is or are the current and active maintainers of pc98? contact to [EMAIL PROTECTED] -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Science, Faculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Serious documentation problems for 4.0 and 5.0
Hi, I found serious problems on documentations of both 4.0 and 5.0. README.TXT and RELEASE.TXT have obsolete descriptions. --- README.TXT --- - FreeBSD 4.0 --- SNAPSHOT Version ,, - /()` No, 4.0 is official RELEASE, and SNAPSHOT is 5.0 \ \___ / | This is a binary snapshot of 4.0-current, the /- _ `-/ ' (HEAD) branch which is currently moving towards (/\/ \ \ /\ the release of 4.0. / / | `\ No, again. For the latest 4.0-current (HEAD branch) snapshot releases, please install from: ftp://current.freebsd.org/pub/FreeBSD No, again. --- RELEASE.TXT --- RELEASE NOTES FreeBSD Release 4.0-SNAP This is a 4.0-CURRENT release SNAPshot of FreeBSD, an active development branch which will produce its first release in early March 2000. Those features which have also been back-ported to the 3.x-stable branch (the next release for which will be 3.5) are marked [MERGED]. No, No For the latest of these 4.0-current snapshots, you should always see: ftp://current.freebsd.org/pub/FreeBSD NO. -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Science, Faculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IPv6 trouble
Hi. I built and installed current-2301 today, and use INET6 enabled kernel *without* ipv6_enable="YES" in /etc/rc.conf. (this probably is the default situation made by the installer) I receive mails by ports/mail/fetchmail from my ISP, then re-send them to local SMTP(sendmail). But, today, it doesn't work. I upgraded ports/mail/fetchmail, but nothing changes. fetchmail says: 1 message for mzaki at mail.server.of.isp (566 octets). reading message 1 of 1 (566 octets) fetchmail: SMTP connect to localhost failed fetchmail: SMTP transaction error while fetching from mail.server.of.isp fetchmail: Query status=SMTP and in syslog: /kernel: Connection attempt to TCP ::0001:25 from ::0001:1129 I suspect, * fetchmail inquire "localhost" to resolver * resolver returns "::1" because there is the entry in /etc/hosts * fetchmail try to connect port 25 on "::1" * sendmail listen on only port 25 of inet4, not of inet6 * trial failes, and fetchmail giving up Then, I commented out "::1" from /etc/hosts, works fine. By the way, WHO is responsible for this? fetchmail? resolver? my setting? -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Science, Faculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 trouble
Hi. At Thu, 02 Mar 2000 21:06:13 +0900, Yoshinobu Inoue [EMAIL PROTECTED] wrote: By the way, WHO is responsible for this? fetchmail? resolver? my setting? It seems to be fetchmail bug. It should try IPv4 if IPv6 access is failed. Could you please copy this patches as your ports/mail/fetchmail/patches/patch-ak file, and rebuild fetchmail, and try again? It's OK. Thank you quick response. -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Science, Faculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
Hi At Sun, 23 Jan 2000 18:51:25 +0100 (CET), Soren Schmidt [EMAIL PROTECTED] wrote: I updated to today's -current from -stable. My ATAPI CD-ROM drive doesn't probed, and is seemed to be halted. (The tray is locked, won't open, and the LED keeps being on.) This is fixed in the next update, due as soon as I get time Thank you for fixing, but still not probed. What can I do for your work? --kernel config-- # ATA and ATAPI devices device ata0at isa? port IO_WD1 irq 14 device ata1at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices --boot -v log-- : : ata-pci0: Intel PIIX4 ATA-33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=00 status1=00 ata0: devices = 0x4 ata0 at 0x01f0 irq 14 on ata-pci0 : ata-isa0: already registered as ata0 : ata0-master: ata_command: timeout waiting for intr ata0-master: identify failed : : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
At Tue, 25 Jan 2000 08:29:32 +0100 (CET), Soren Schmidt [EMAIL PROTECTED] wrote: Thank you for fixing, but still not probed. ata-pci0: Intel PIIX4 ATA-33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=00 status1=00 ata0: devices = 0x4 ata0 at 0x01f0 irq 14 on ata-pci0 : ata-isa0: already registered as ata0 : ata0-master: ata_command: timeout waiting for intr That has me worried, what make/version is the drive ?? wdc says: wdc0: unit 0 (atapi): CD-ROM CDU77E-NE/1.2g, removable, accel, dma,iordy -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Science, Faculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
My ATAPI CD not come ready
Hi. I updated to today's -current from -stable. My ATAPI CD-ROM drive doesn't probed, and is seemed to be halted. (The tray is locked, won't open, and the LED keeps being on.) Mother board: ABIT BH6 CD-ROM drive: ATAPI [CDU77E-NE] on primary-master other ATAs: none It worked fine on -stable. I tried to use 'obsolete' wdc/wcd driver, it works fine. --boot -v message: ata/acd-- : : ata-pci0: Intel PIIX4 ATA-33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=00 status1=00 ata0: devices = 0x4 : : ata0-master: drive wont come ready after identify --boot -v message: wdc/wcd-- : wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (atapi): CD-ROM CDU77E-NE/1.2g, removable, accel, dma,iordy wcd0: drive speed 689KB/sec, 128KB cache wcd0: supported read types: CD-DA wcd0: Audio: play, 256 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: CD-ROM unknown medium, unlocked -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Science, Faculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Unicode support for Joliet CDs
Unicode support patch for -current and -stable is now updated. See http://triaez.kaisei.org/~mzaki/joliet/ # It's not intended to merge into the repository. CHANGES: * By default, filenames are encode by UTF-8, not converted to any charset. * Add support for ISO-8859-2 and KOI8-R. * Add kernel config option CHARSET_*. They are to specify the conversion tables you need. -- Motomichi Matsuzaki mz...@e-mail.ne.jp Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Unicode support for Joliet CDs
From: Daniel C. Sobral d...@newsguy.com
Subject: Re: Unicode support for Joliet CDs
Date: Sat, 08 May 1999 02:57:25 +0900
dcs Unicode support patch for -current and -stable is now updated.
dcs BTW, some people mentioned losing case in Joliet names. Is/was this
dcs caused by the convertion? Is it fixed in this version?
I have noticed this problem right now.
Following is the patch for -current and -stable:
--- /usr/src/sys/isofs/cd9660/cd9660_util.c Sun Apr 25 02:53:58 1999
+++ /tmp/cd9660_util.c Sat May 8 09:20:44 1999
@@ -162,7 +162,7 @@
for (; infn != infnend; fnidx++) {
infn += isochar(infn, infnend, joliet_level, c);
- if (!original c = 'A' c = 'Z')
+ if (!original !joliet_level c = 'A' c = 'Z')
*outfn++ = c + ('a' - 'A');
else if (!original c == ';') {
fnidx -= (d == '.');
I will change my Unicode patch as the same.
dcs * Add kernel config option CHARSET_*.
dcsThey are to specify the conversion tables you need.
dcs
dcs And how about selecting the charset to be used? Does this still goes
dcs through sysctl, did you get it on a mount option as I suggested, or
dcs what?
Not yet, still 'sysctl'.
# I feel that adding conversion tables to kernel is ad hoc way.
# The BIG5 encoding is not filesystem-safe so that
# some userland supports is neccesary for zh_TW.BIG5.
# It is as the same for ja_JP.SJIS.
# Then, kernel should pass Unicode to userland as UTF-8 encoded,
# and we should make proper I18N on whole FreeBSD.
# ... confused.
--
Motomichi Matsuzaki mz...@e-mail.ne.jp
Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
Hey!
I've add UNICODE support to the Joliet patch.
It contains few charsets now, but to add other charsets is very easy.
Currently, iso8859-1 and euc-jp is included.
Mixture of Joliet/RockRidge Extension is also available, however untested.
How to use:
1. Pick up the patch from the URL.
http://triaez.kaisei.org/~mzaki/joliet/joliet.unicode.patch.gz
It contains huge table which provides conversion
from unicode character to euc-jp, so that the gzip'ed size is 36k.
So I give up to attach the patch to this mail.
2. Apply the patch to the source tree.
#cd /usr/src
#zcat /tmp/joliet.unicode.patch.gz|patch -p1
3. Make and install new mount_cd9660(8)
#cd /usr/src/sbin/mount_cd9660
#make; make install
4. Reconfig and reinstall your kernel and reboot.
5. Tell your kernel the charset you prefer.
#sysctl -w vfs.charset=iso8859-1
Currently, only 'none', 'iso8859-1' and 'euc-jp' is available.
none : The filenames are assumed to have 8bit character ONLY.
This is not recommended.
iso8859-1 : 8bit characters.
All 16bit characters (include russian, greek, chinese, etc.)
are replaced with numerical ('0'-'9').
euc-jp: Japanese characters.
This corresponds to the userland locale 'ja_JP.EUC'.
All characters unable to express are
replaced with numerical ('0'-'9').
How to use other charsets:
1. Look at the /sys/isofs.
charset and encoding directories are added.
For Europians, to make new charset/*.c is sufficient.
For Asians (Chinese, Korean, Japanese and so on),
to make new encoding/*.c is also required.
charset/*.c should contains Code Conversion Table.
Currently, only 'UNICODE - local charset' conversion is needed.
(in future, reverse conversion may needed for msdosfs and ntfs.)
encoding/*.c should contains multibyte encoding routines.
These are subset of rune(3) at /usr/src/lib/libc/locale/
At least, MSKanji is required for ja_JP.SJIS, BIG5 for zh_TW.BIG5,
also UTF-8 for all UNICODE locale.
2. Add new file entries to /sys/conf/files
3. Reconfig and reinstall your kernel and reboot.
More documents are now scheduled in some days at the URL
http://triaez.kaisei.org/~mzaki/joliet/
--
Motomichi Matsuzaki mz...@e-mail.ne.jp
Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
From: Daniel C. Sobral d...@newsguy.com Luoqi Chen wrote: I've add UNICODE support to the Joliet patch. It contains few charsets now, but to add other charsets is very easy. Currently, iso8859-1 and euc-jp is included. Cool! I think NTFS and VFATFS could use this code too, is it possible to move the code to place like libkern/unicode? I'm concerned about the possible size of GENERIC with this code. Remember, it has to fit in the install floppy. (Well, not really, with loader, but I'm not the one who is getting killed because of a three-disks install.) The UNICODE routines consist of these files. charset/charset.c mandatory iso8859-1.c recommended euc-jp.coptional-- BIG! the object file has 53k bytes encoding/encoding.c mandatory euc.c optional The 'mandatory + recommended' object size is no more than 5 kbytes. The GENERIC kernel does not require necessarily the euc-jp support or any other charsets. I think the iso8859-1 support alone is sufficient for GENERIC. The custom kernels can have the euc-jp support through the CHARSET_EUC_JP and ENCODING_EUC kernel configure option. (They are currently defined at the top of the source files.) Also, it adds a sysctl node, isn't that so? Directly under vfs, even, so it applies to all filesystems. Ideally, this should apply on a per-mount basis, and not even be in a sysctl. Yes. sysctl is not the best idea. I think the charset preferences should apply on per-process basis ideally. The operator mounts some disks. The users access the disks in their own preferred charset. The UNICODE is a multiligual codeset, so we shoud not suppose any specific charset on the disk. Therefore, a per-mount basis is not enough. If the routines can refer the users' environment 'LC_CTYPE', it is fine idea. But it can't, I suppose. -- Motomichi Matsuzaki mz...@e-mail.ne.jp Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
From: Harold Gutch lo...@foobar.franken.de Subject: Re: kern/5038: FreeBSD can't read MS Joliet CDs. Date: Wed, 14 Apr 1999 16:45:48 +0200 logix On Wed, Apr 14, 1999 at 10:24:38PM +0900, Daniel C. Sobral wrote: logix Motomichi Matsuzaki wrote: logixThe patch gzip+uuencoded is following. logix Do you know of any problems resulting from applying this patch? 1. this patch is for -stable. Some hunks would be failed for -current. 2. Only Page 00 Unicode is shown (for Joliet CDs). ISO-8859-1 is OK, CJK is NG. Each CJK character is replaced with '?' and file identity is lost e.g. both 'abc' and 'xyz' are shown '???', and an access to '???' is always directed for 'abc'. ( Note: 'abc', 'xyz' are CJK string, ASCII string has no such problems. ) I think it would be solved if kernel had NLS and multibyte functions(or their subsets). ( Linux 2.2.x has in-kernel-NLS and Linux's Joliet feature uses it; however, there are no official CJK supoprts.) Note. Byung's patch passes Unicode transparently. So CJK filenames are shown if terminals do Unicodes well. logix I'm not sure if this applys to _this_ patch, but a couple of logix months ago I took some 3.0-patches and backported them to 2.2. logix They had the problem of using the Joliet extensions when mounting logix a hybrid-CD (a CD with Joliet and RockRidge extensions). Would you tell me what kind of problem? Known bugs of Byung's (Already fixed): * Shortname is also shown not only longname on some Joliet CD-Rs. * Joliet support is not work with El Torito CD-ROMs. Changes from Joachim's: * With Joliet and RockRidge CD, Joachim's see Joliet, mine see RockRidge. logix Perhaps an option to mount_cd9660 would be the best idea, similar logix to the already existing -r it could get a -j which would make logix mount_cd9660 ignore the Joliet extensions. -j is also available for my patch. # I'm sorry for my poor English... -- Motomichi Matsuzaki mz...@e-mail.ne.jp Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
From: Daniel C. Sobral d...@newsguy.com Subject: Re: kern/5038: FreeBSD can't read MS Joliet CDs. Date: Thu, 15 Apr 1999 02:40:58 +0900 dcs 2. Only Page 00 Unicode is shown (for Joliet CDs). dcs ... dcs Note. dcs Byung's patch passes Unicode transparently. dcs So CJK filenames are shown if terminals do Unicodes well. dcs dcs Do you mean that your patch shows only page 00, but Byung's patch dcs passes Unicode directly? My patch: * character in page 00 is converted to ASCII(+ISO-8859-1) * character in other pages is replaced by '?' Byung's patch: * character in page 00 is converted to ASCII(+ISO-8859-1) * character in other pages is passed as is For example, suppose to be a file on Joliet CD, which filename is encoded as [ 0041 0042 0043 2525 3030 3535 ] in Unicode. The kernel applied my patch shows it to userland via readdir(2) as (41)(42)(43)(3F)(3F)(3F) ... abc??? The kernel applied Byung's patch shows it as (41)(42)(43)(25)(25)(30)(30)(35)(35) ... abc%%0055 Byung reported, With this patch, I was able to see long file names and non-english characters(such as koreanchinese) so i believe it does support unicode as long as your locale is set correctly. But with my locale 'ja_JP.EUC' (which is the major in Japan on *BSD box), these strings make no sense. To see filenames which contain Japanese characters, kernel should convert it to EUC(JP). Another possible answer is encoding to UTF-8, however, I don't know UTF-8 terminal compliant with Japanese. -- Motomichi Matsuzaki mz...@e-mail.ne.jp Dept. of Biological Science, Fuculty of Sciences, Univ. of Tokyo, Japan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
