Re: HPT366 and FreeBSD-CURRENT ?
It seems Alexandr Listopad wrote: Hello! What about subj? Did FreeBSD support HPT366 in the CURRENT??? Yes it does. And if "yes" then what shall I do for it??? Use the ata driver. If I boot from floppies - then error and reboot after 15sec, and don't find this drive on IDE... what shall I do??? Uhm, I'm not sure I get the meaning here, is that for an install ?? If so the new ata driver isn't use in GENERIC just yet, you could however test out the boot floppies I've put on ftp.freebsd.dk/pub/ -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NewATA on ISA and PCI
It seems Maxim Sobolev wrote: Sheldon Hearn wrote: On Fri, 19 Nov 1999 01:16:55 +0200, Maxim Sobolev wrote: Does anybody can explain why kernel with NewATA driver booted on machine with ISA based IDE adapter trying to mount wd* as root f/s, while exactly *the same* kernel booted on PCI based mobo mounts ad* as root? /etc/fstab ? No, I do not talking about /etc/fstab, I'm talking about what device kernel is using to mount root *before* starting /sbin/init (e.g. "changing root device to ..." in dmesg). Hmm, the bootblock or the loader might be responsible -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
It seems Julian Elischer wrote: I am ready to do my megga-commit to add the first stage of KSE-threading support to the kernel. If there is any argument as to the wisdom of this move, then this is the time to speak up! At this stage a commit would break alpha and ia64 until they are patched. From experience I can say that it's not a horrific change to the machine dependent code so patches PRE commit would be welcome. Could we have an URL to these changes, so we could see what its all about, I dont like to comment on code before I've seen it -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel builds failing
It seems [EMAIL PROTECTED] wrote: For the last two days, my kernel builds have been failing with: linking kernel.debug ata-all.o: In function `ataioctl': /usr/src/sys/dev/ata/ata-all.c(.text+0x791): undefined reference to `atapi_queue _cmd' *** Error code 1 I'm looking at how to solve this, commit to follow soon... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current (ACPI) fails on Dell Latitude ...
It craps out with: ACPI-0170: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES ACPI-0222: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES ACPI: table load failed: AE_NO_ACPI_TABLES Needless to say, -current is now unusable on this latitude CPi since suspend doesn't work without APM, and PCCCARD/PCMCIA support is also broken.. *SIGH* -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: HEADS UP (ACPI CA update)
It seems Mike Smith wrote: Outstanding issues: - The ACPI timecounter does not work on some ALi chipsets. - ACPI mode results in some PCI devices not being configured by the BIOS. Power off on some VIA based boards (Epox8kta3 etc) doesn't work (reboot). Suspend on some VIA based boards (Epox8kta3 etc) doesn't work (reboot). Where was it I should send that acpidump etc to ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! DAO mode added to burncd/ATA driver...
Due to new ioctl's and a rearrange of the old ones make sure that burncd kernel is in sync or wierd things can happen. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't write CD-Rs with or without new DAO mode
It seems Brian Fundakowski Feldman wrote:
After updating my system I can't burn CD-Rs successfully. Can anyone else?
What happens is pretty simple:
{/home/green/toxicity}$ burncd -s 8 -d audio /dev/null $(ls | trackclassify
burncd: ioctl(CDRIOCINITWRITER): Input/output error
acd0: MODE_SELECT_BIG - ILLEGAL REQUEST asc=0x26 ascq=0x00 error=0x00
Are you absolutely sure your kernel userland are in sync ?
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: can't write CD-Rs with or without new DAO mode
It seems Brian F. Feldman wrote: OK, try this patch (kernel burncd need both to be remade) I don't know... I got a page fault during an attempt to burncd and it seems there are no messages in dmesg but acd0's softc was freed. I can't test any more because my CD-RW doesn't probe on boot (or let me eject, etc...) Hmm, was that with the patch ? There is no reason why the device shouldn't probe anymore, but it could be in a state where are powercycle is needed to bring it back to sanity.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't write CD-Rs with or without new DAO mode
It seems Brian F. Feldman wrote:
Søren Schmidt [EMAIL PROTECTED] wrote:
It seems Brian Fundakowski Feldman wrote:
After updating my system I can't burn CD-Rs successfully. Can anyone else?
What happens is pretty simple:
{/home/green/toxicity}$ burncd -s 8 -d audio /dev/null $(ls | trackclassify
burncd: ioctl(CDRIOCINITWRITER): Input/output error
acd0: MODE_SELECT_BIG - ILLEGAL REQUEST asc=0x26 ascq=0x00 error=0x00
Are you absolutely sure your kernel userland are in sync ?
recompiling burncd to the exact same effect.
OK, try this patch (kernel burncd need both to be remade)
Index: sys/dev/ata/atapi-cd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v
retrieving revision 1.100
diff -u -r1.100 atapi-cd.c
--- sys/dev/ata/atapi-cd.c 10 Sep 2001 11:43:20 - 1.100
+++ sys/dev/ata/atapi-cd.c 15 Sep 2001 08:25:55 -
@@ -1407,9 +1407,7 @@
static int
acd_init_writer(struct acd_softc *cdp, int test_write)
{
-struct write_param param;
int8_t ccb[16];
-int error;
bzero(ccb, sizeof(ccb));
ccb[0] = ATAPI_REZERO;
@@ -1417,23 +1415,7 @@
ccb[0] = ATAPI_SEND_OPC_INFO;
ccb[1] = 0x01;
atapi_queue_cmd(cdp-atp, ccb, NULL, 0, ATPR_F_QUIET, 30, NULL, NULL);
-
-if ((error = acd_mode_sense(cdp, ATAPI_CDROM_WRITE_PARAMETERS_PAGE,
- (caddr_t)param, sizeof(param
- return error;
-param.data_length = 0;
-param.page_code = ATAPI_CDROM_WRITE_PARAMETERS_PAGE;
-param.page_length = 0x32;
-param.test_write = test_write ? 1 : 0;
-param.write_type = CDR_WTYPE_SESSION;
-param.session_type = CDR_SESS_NONE;
-param.fp = 0;
-param.packet_size = 0;
-param.track_mode = CDR_TMODE_AUDIO;
-param.datablock_type = CDR_DB_RAW;
-param.session_format = CDR_SESS_CDROM;
-
-return acd_mode_select(cdp, (caddr_t)param, param.page_length + 10);
+return 0;
}
static int
@@ -1613,6 +1595,7 @@
static int
acd_send_cue(struct acd_softc *cdp, struct cdr_cuesheet *cuesheet)
{
+struct write_param param;
int8_t ccb[16] = { ATAPI_SEND_CUE_SHEET, 0, 0, 0, 0, 0,
cuesheet-len16, cuesheet-len8, cuesheet-len,
0, 0, 0, 0, 0, 0, 0 };
@@ -1621,6 +1604,24 @@
#ifdef ACD_DEBUG
int i;
#endif
+
+if ((error = acd_mode_sense(cdp, ATAPI_CDROM_WRITE_PARAMETERS_PAGE,
+ (caddr_t)param, sizeof(param
+ return error;
+param.data_length = 0;
+param.page_code = ATAPI_CDROM_WRITE_PARAMETERS_PAGE;
+param.page_length = 0x32;
+param.test_write = cuesheet-test_write ? 1 : 0;
+param.write_type = CDR_WTYPE_SESSION;
+param.session_type = CDR_SESS_NONE;
+param.fp = 0;
+param.packet_size = 0;
+param.track_mode = CDR_TMODE_AUDIO;
+param.datablock_type = CDR_DB_RAW;
+param.session_format = CDR_SESS_CDROM;
+if ((error = acd_mode_select(cdp, (caddr_t)param, param.page_length + 10)))
+ return error;
+
buffer = malloc(cuesheet-len, M_ACD, M_NOWAIT);
if (!buffer)
return ENOMEM;
Index: sys/sys/cdrio.h
===
RCS file: /home/ncvs/src/sys/sys/cdrio.h,v
retrieving revision 1.4
diff -u -r1.4 cdrio.h
--- sys/sys/cdrio.h 10 Sep 2001 11:42:27 - 1.4
+++ sys/sys/cdrio.h 15 Sep 2001 08:19:38 -
@@ -71,6 +71,7 @@
struct cdr_cuesheet {
int32_t len;
struct cdr_cue_entry *entries;
+ int test_write;
};
#define CDRIOCBLANK_IOW('c', 100, int)
Index: usr.sbin/burncd/burncd.c
===
RCS file: /home/ncvs/src/usr.sbin/burncd/burncd.c,v
retrieving revision 1.16
diff -u -r1.16 burncd.c
--- usr.sbin/burncd/burncd.c11 Sep 2001 12:14:20 - 1.16
+++ usr.sbin/burncd/burncd.c15 Sep 2001 08:19:07 -
@@ -58,7 +58,7 @@
static int fd, quiet, verbose, saved_block_size, notracks;
void add_track(char *, int, int);
-void do_DAO(void);
+void do_DAO(int);
void do_TAO(int, int);
int write_file(struct track_info *);
int roundup_blocks(struct track_info *);
@@ -245,7 +245,7 @@
cdopen = 1;
}
if (dao)
- do_DAO();
+ do_DAO(test_write);
else
do_TAO(test_write, preemp);
}
@@ -308,7 +308,7 @@
}
void
-do_DAO(void)
+do_DAO(int test_write)
{
struct cdr_cuesheet sheet;
struct cdr_cue_entry cue[100];
@@ -390,6 +390,7 @@
sheet.len = j * 8;
sheet.entries = cue;
+ sheet.test_write = test_write;
if (verbose) {
u_int8_t *ptr = (u_int8_t *)sheet.entries;
@@ -404,9 +405,10 @@
if (ioctl(fd, CDRIOCSENDCUE, sheet) 0)
err(EX_IOERR, ioctl(CDRIOCSENDCUE));
-
+#if 0
Re: Some CDIO ioctl's are broken
It seems Maxim Sobolev wrote: Hi Soren, It seems that after a commit to reduce stack usage in ata driver some CDIO ioctl's stopped working. Particularly, CDIOCREADSUBCHANNEL now returns an 'Invalid argument'. This could be verified by executing `cdcontrol stat'. Uhm: sos cdcontrol -f acd0 stat No current status info available No media catalog info available Left volume = 255, right volume = 255 That looks pretty OK to me ... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP kernel burncd change..
Kernel and burncd must be in sync again, a make kernel followed by a make world should do it. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI and APM interoperability?
It seems Scott Long wrote: On Mon, Oct 01, 2001 at 10:50:17AM +0200, Georg-W. Koltermann wrote: I also was able to suspend and resume my machine (DELL Inspiron 7500) with APM being configured (and ACPI being active by default). Sound is dead after a resume, What sound card? PCMCIA is dead after a couple of resumes, Resource leak? Warner? It has been like that on -current for about a month or so on my Latitude as well, try to use slot1 instead of slot0, that makes it work better here... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: inthand_add: Can't initialize ICU
It seems John Baldwin wrote: I found that I am no longer able to boot -current kernel on my machine. The system panices right after initialising ed0 driver: [...] ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xe800-0xe81f irq 9 at device 9.0 on pci0 panic: inthand_add: can't initialize ICU Attached please find verbose kernel bootup messages obtained from the last good kernel from about a week ago. Please fix. Could you, say, add a printf to icu_set() to print out the passed in interrupt number before it returns EINVAL? Also, adding a call to debugger (Debugger(foo);) and getting a stack trace would be very helpful. I see the same thing here on my latitude, the passed irq is 0xb, I dont have the stack trace written down (too damn long) but its when it attaches the pcic controller.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: S.M.A.R.T.?
It seems Matthew Jacob wrote: I have experimented a bit with it for ATA disks, and have some very rough code to deal with simple SMART commands, but nothing official yet. However it is on my TODO list for items to support in the not too distant future, its more a question of me having time to implement it properly in a way I can live with :) What is it more precisely you want support for ? please keep in mind that lots of the usefull stuff in SMART is vendor specific... There was some talk about it. There was some notion of trying to incorporate it with the existing SES/SAFTE driver, for example. But then that foundered on the issue of CAM not supporting ATAPI yet. I believe Soren has a more definitive answer than this tho. Actually, hackers is where more of the bleeding wedge stuff is. On Fri, 5 Oct 2001, Sean Kelly wrote: Since nobody answered me on -questions, I thought I'd try here since this is the active bed of development. Does anybody know if there is planend or active development for S.M.A.R.T. monitoring of IDE/SCSI hard drives? I would think this would be a desirable feature for small server environments, which FreeBSD is used for a lot. -- Sean Kelly | PGP KeyID: 77042C7B [EMAIL PROTECTED] | http://www.zombie.org For PGP key, send e-mail with subject send pgp key 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
HEADSUP ATA support for newer SiS chipsets added
Well, I finally got to it, please report back to me if this works for you on newer SiS chipsets, especially: SiS 630, 633, 635, 730, 733 and 735 Also, support for the older: SiS 530, 540 and 620 Should be in place now. Anyhow If you have one of the above, please test with a new -current, and report to me how it goes, I dont have any of those chipsets, so I cant test it myself, donations of such boards are welcome :)... If it seems to work then please do the following on an idle system: for n in 1 2 3 4 5 do dd if=/dev/adX of=/dev/null bs=512K count=1 done Where X is the drive connected to the SiS chipset (ad0, ad1 etc) and mail me the output from the script and a copy of dmesg.. Thanks! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP ATA support for newer SiS chipsets added
It seems Greg Lehey wrote: for n in 1 2 3 4 5 do dd if=/dev/adX of=/dev/null bs=512K count=1 Don't you mean dd if=/dev/ad$n of=/dev/null bs=512K count=1 ? No, I mean it exactly as written (X is the number of the disk to test). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP ATA support for newer SiS chipsets added
It seems Miklos Niedermayer wrote: On Mon, Dec 03, 2001 at 09:28:26AM +0100, S_ren Schmidt wrote: No, I mean it exactly as written (X is the number of the disk to test). Ah, you mean just do it 5 times? Yeps, the idea here is that I want the drive to cache the data, so that I can get the raw interface speed, that will show if the ATA modes has been set correctly Does this work for you? I always get around 20 MB/sec on both ATA33 and ATA66/ATA100 systems... Yes it does : 1+0 records in 1+0 records out 524288 bytes transferred in 0.037292 secs (14059037 bytes/sec) 1+0 records in 1+0 records out 524288 bytes transferred in 0.006199 secs (84576191 bytes/sec) 1+0 records in 1+0 records out 524288 bytes transferred in 0.006204 secs (84507936 bytes/sec) But the disk needs to be idle or you risk getting another request inbetween ruining the cached data, or if you disk has less cache that 512k it will also fail. If that all is OK, you should see something close to the real transfer speed of the interface, IF the ATA support code has setup your HW correctly. What controller and disks are we talking about here ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP ATA support for newer SiS chipsets added
It seems Miklos Niedermayer wrote: I think they are idle (looking at vmstat -i), but i can't be sure. However i have 2 machines here with VIA 82C596 chipset... atapci0: VIA 82C596 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ad0: 28629MB QUANTUM FIREBALLlct20 30 [58168/16/63] at ata0-master UDMA66 524288 bytes transferred in 0.025247 secs (20766367 bytes/sec) It's idle (the LED isn't blinking after/before dd and vmstat -i doesn't show any ata0 activity). Even my Intel PIIX4 ATA33 controller with the same disk performs better (a little)... Hmm, yes that looks somewhat on the low side... Well, two things, the older VIA chips are not the best performers, but I still think it should be better than that, I'll run some tests here, I might have messed up something... Are we talking -current or -stable here ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP ATA support for newer SiS chipsets added
It seems nuzrin yaapar wrote: Hmm, yes that looks somewhat on the low side... Well, two things, the older VIA chips are not the best performers, but I still think it should be better than that, I'll run some tests here, I might have messed up something... Are we talking -current or -stable here ? -Søren dmesg: atapci0: VIA 82C686 ATA100 controller port 0xd000-0xd00f at device 7.1 on pci0 ad0: 12416MB QUANTUM FIREBALL CX13.0A [25228/16/63] at ata0-master UDMA66 output: 1+0 records in 1+0 records out 524288 bytes transferred in 0.023098 secs (22698423 bytes/sec) Hmm, I've just played around a bit, it seems we are hit by interrupt latency or something, if you limit the transfer to 128k, which allows the ATA controller to fetch it in one go, you will see the expected transfer rates. Now I dont see this on PCI based controllers, and that hints that the problem could be the fact that the two onboard controllers sits on irq 14 15 making them the lowest priority devices in the system, and that could cause the interrupt latency I'm seeing which then again causes the bad transfer rates on transfers that need to transfer more that one transaction full of data (ie max 128k). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP ATA support for newer SiS chipsets added
It seems Matthew Dillon wrote: :Hmm, I've just played around a bit, it seems we are hit by interrupt :latency or something, if you limit the transfer to 128k, which allows :the ATA controller to fetch it in one go, you will see the expected :transfer rates. Now I dont see this on PCI based controllers, and that :hints that the problem could be the fact that the two onboard controllers :sits on irq 14 15 making them the lowest priority devices in the system, :and that could cause the interrupt latency I'm seeing which then again :causes the bad transfer rates on transfers that need to transfer more :that one transaction full of data (ie max 128k). : :-Søren The larger transfers are probably choking the IDE drive's pipelining capabilities. That's my guess, anyway. I avoid IDE like the plague. No, not true, if the same drive is put on a PCI based ATA controller you get the expected transfer speed upto the drives cache size. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADSUP!! kernel burncd must be in sync again.
I've just added VCD/SVCD support and that needs the kernel and burncd to be in sync. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IBM DTLA drives (was: Re: Dangerously dedicated yet again (was:cvs commit: src/sys/kern subr_diskmbr.c) )
It seems Peter Wemm wrote: Yes there are two problems. The physical failure problem seems to be mostly restricted to the 75GXP. However the electronics/bandwidth/ density/whatever-it-is problem is uniform across the entire DTLA line. We stopped using 75GXP's at work a while back, but we still regularly suffer from the electronics/bandwidth/whatever-it-is problem on 30G DTLA drives on a daily basis. It seems this problem only affects the newer versions of the DTLA, the first models (of which type most of mine are) doesn't seem to suffer from this problem. The first models looks like the older DPTA drives, whereas the newer ones has at least a different top cover. Anyhow, the problem seem to be an electronics malfunction (IBM doesn't tell exactly) and it is triggered by the drive being very sensitive to the power supply being top quality. At any rate I think the hysteria about these drives is somewhat overrated, but thats only my oppinion... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another tweak to burncd msinfo
It seems Stephen McKay wrote: Now that burncd msinfo returns the correct values I noticed another small problem: it displays the result on stderr instead of stdout. Hmm, that was intentional... Since very few people (nobody?) would be using this option yet because of the previous problem, it seems like nobody would be adversely affected by changing the output to stdout. Also, removing the whitespace in the output would help script writers. Can I commit the obvious patch? Could you just hang on for now, since I'm doing large changes to burncd just now in order to support other things, and keeping everybody changes to the stock sources is not making things easier... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another tweak to burncd msinfo
It seems Stephen McKay wrote: Are these changes intended for 4.5? I'm hoping the small change I proposed would be accepted into 4.5, before anybody starts using burncd msinfo in practice. I think this is sensible, even if a much improved burncd is scheduled for 4.6. You should ask permission from the release engineer to commit it to 4.5, but it really should be committed to -current first. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another tweak to burncd msinfo
It seems Søren Schmidt wrote: It seems Stephen McKay wrote: Are these changes intended for 4.5? I'm hoping the small change I proposed would be accepted into 4.5, before anybody starts using burncd msinfo in practice. I think this is sensible, even if a much improved burncd is scheduled for 4.6. You should ask permission from the release engineer to commit it to 4.5, but it really should be committed to -current first. I forgot to say that I already committed the change to current... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 48bit ATA addressing problems / Promise TX2 ata133 problem?
It seems Mike Brancato wrote: I'm running -current and have a Maxtor 160GB hdd hooked to the promise ata133 card that came with it it will flake out for no apparent reason. any clues? maybe bad hardware? anyone else getting these? ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. done ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. done ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. done ad4: READ command timeout tag=0 serv=0 - resetting ad4: trying fallback to PIO mode ata2: resetting devices .. done I know that the 48bit code works, but the support code for the Promise ATA133 controller hasn't been tested much (I dont have such an animal). However if you move the disk to another controller, does the problem persist ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! ATA subsystem has changed..
In order to make some real progress on the ATA RAID support code I've also made some rather trivial but many changes all over the ATA subsystem, so if behavior changes on ordinary system I'd like to know... In short - you have been warned ... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: Hi! I checked and compiled the recent -CURRENT tree, buildworld and buildkernel goes all fine. When booting it seems to crash on initialization of my Promise controller and get bad ivar request (4). I stripped all possible drivers out of the kernelconfig, except for the ata driver, and it still crashes. I then see a couple of pci0: sumdevice (no driver attached), and when it should come to my Promise, BAM! The bad ivar request (4) message does *not* come from the ATA driver, you must have something else that is ruining your day... Does it boot if you take out the promise board ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: The bad ivar request (4) message does *not*?come from the ATA driver, you must have something else that is ruining your day... Does it boot if you take out the promise board ? I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg Here's the box: Asus CUV4X-D mainboard, VIA 694X, dual-capable 2x P3-933, 768MB PC133 RAM in 3 DIMM(s) Two IBM IC35L 60.1GB disks on first IDE Pioneer DVD-A05SZ on second IDE Two IBM IC35L 60.1GB on Promise Fasttrak TX2 (PDC20268/70) in RAID0 How do I dump the dmesg when it crashs into the debugger? With a current kernel from before you found it failed ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. This is strange, the error message you got is *not* from the ATA driver, and putting a TX2 in a system here work just fine, I'm out of ideas -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Support for atapi cdrw as scsi in -current?
It seems Gerhard Sittig wrote: On Thu, Feb 07, 2002 at 12:38 +0100, Søren Schmidt wrote: [ snipped ATAPI - SCSI conversion ] Doesn't burncd work for you on -current ? Well, since you asked about it ... :) I asked for *problems* not cosmetic issues :) The bug (talking about a few million percent completion of the job, while one hundred should suffice) is still there. Can you have one more look at http://www.freebsd.org/cgi/query-pr.cgi?pr=30893 please? Especially the simple and straight fix in its opening. This shouldn't take eight months to wait for or doing hard fights to get it fixed ... :( (I know you were busy back then changing jobs and moving, but the later closing wasn't appropriate without a fix.) It is on my TODO list, but its fairly long, and functional errors plus supporting new hardware keeps getting top priority... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: The bad ivar request (4) message does *not*?come from the ATA driver, you must have something else that is ruining your day... Does it boot if you take out the promise board ? I was in a hurry yesterday and let the kernel compile w/o the ata driver while being under the shower. Without the ata driver it does boot. Just wanted to let you know. I'll take the Promise out when I got some more time (latest friday evening). Hmm, I need alot more info the, board chipset, what exact Promise controller etc etc, and of cause the usual dmesg -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Promise/ATA-Raid making panic in -CURRENT?
It seems Tom Servo wrote: I finally pulled the Promise out and it boots. Since I need it for some Windows apps on the same box I put it back in and commented some lines in ata driver regarding the detection of Promise Fasttrak controllers and it boots now w/o detecting it. This is strange, the error message you got is *not* from the ATA driver, and putting a TX2 in a system here work just fine, I'm out of ideas -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Support for atapi cdrw as scsi in -current?
It seems Gerhard Sittig wrote: On Thu, Feb 07, 2002 at 12:38 +0100, Søren Schmidt wrote: [ snipped ATAPI - SCSI conversion ] Doesn't burncd work for you on -current ? Well, since you asked about it ... :) I asked for *problems* not cosmetic issues :) The bug (talking about a few million percent completion of the job, while one hundred should suffice) is still there. Can you have one more look at http://www.freebsd.org/cgi/query-pr.cgi?pr=30893 please? Especially the simple and straight fix in its opening. This shouldn't take eight months to wait for or doing hard fights to get it fixed ... :( (I know you were busy back then changing jobs and moving, but the later closing wasn't appropriate without a fix.) It is on my TODO list, but its fairly long, and functional errors plus supporting new hardware keeps getting top priority... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Syscons mouse char range redefine proposal
It seems Andrey A. Chernov wrote: Currently SC_MOUSE_CHAR occupes 0xd0-0xd4 range which produce conflict with several languages code tables. I plan to redefine it by default to 0x03-0x07 leaving possibility to redefine it to any range as currently present. This way minimizes arcane information needed for user to setup its language correctly. Any objections? Wont work, it needs to be in the (IIRC) 0xd0 - 0xe0 range for the HW to DTRT with the ninth bit on VGA HW. The has been beaten to death several times before, check the archives... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: evil ATA
It seems Brian F. Feldman wrote: Welp, this is the n-dozenth time that the ATA driver has wedged large parts of my entire system because it feels it needs to reset my CD-R when I'm trying to start burning a CD. I get the good old acd0: WRITE_BIG command timeout - resetting ata3: resetting devices .. and then, like always, tons of random applications lock up thereafter, including the burncd (stuck in physstr and cannot be killed, at all), Window Maker, my panel, etc. etc. etc. Oh, and the sleep(2)-related system calls don't sleep for the right time anymore; they just freeze. All sorts of stuff like this. Is there _any_ hope for not having such horrible behavior? Am I at the very least not the only person to have seen it? This is the _only_ problem I've had with -current lockups this entire year. I have never ever seen this behavior... I can understand why the process that uses the failing device can hang or do irratic things, but I have trouble understanding the rest... A dmesg would be nice :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP ata ioctls changed
It seems [EMAIL PROTECTED] wrote: Which ports break? There are no other consumers (AFAIK) than atacontrol (yet) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request for CDR/CDRW drives working status
I've decided to do a quick poll on which CDR/CDRW drives people have that either work or doesn't work. I'll collect all the info and make a web page that will show which drives are supported, and which are not, and hopefully this will help me find a solution that works for all. Please send a message to [EMAIL PROTECTED] with [CDR INFO] in the subject, stating: Drive model/version (from dmesg and possibly from the label on the drive). Does it work with burncd ? If it fails, please add the error messages from the kernel from a failed burn so I have something to go by. Does it work with PIO and/or DMA ? Thanks! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Supported ATAPI cdr/cdrw drives
As promised I've made up a list of reports I've received so far go to http://freebsd.dk/ and follow the link. I also have a patch for the Yamaha's (yamaha-cdr.p1) which also can be found via the above URL. Let me know if that make things work... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
It seems Terry Lambert wrote: Jonathan Smith wrote: That's good enough. :) Thanks Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. You lost me here, what version of FreeBSD are we talking about ? I thought it was 4.3 but that doesn't contain any ifdef's about DMA at all -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
It seems Terry Lambert wrote: Søren Schmidt wrote: This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... This was a 4.3 system -- things seem to have changed in the source tree since then. Nope. In 4.3, it's not possible to disable DMA, because it gets reenabled in many places (atapi.c, etc.). there is no atapi.c... This was off-topic for -current, unless the original poster was running 4.3-RELEASE or a RELENG_4_3_0_RELEASE... Sorry for the confusion. I think you are confused :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: More ATA disks with tagged queueing ?
It seems [EMAIL PROTECTED] wrote: After applaying the next patch I can now see in dmesg output: ad4: 19574MB IBM-DPTA-372050 [39770/16/63] at ata2-master tagged UDMA66 ad6: 19623MB IC35L020AVER07-0 [39870/16/63] at ata3-master tagged UDMA66 . This configuration (ad6 is the IBM's Deskstar 60GXP(?) series disk) was 'tested' by the 'make -j32 buildworld' with the /usr/obj on the ad6 disk. Does this mean that this disk really support tagged queueing ? Yups, else it would have failed bitterly.. The diskid (IC...) has me somewhat stumped though, I would have thougt the used something like all other IBM disks. Is this a genuine IBM disk or is it some kind of OEM/rebadged device ? Is there any way to test/demonstarte this ? Not without instrumenting the code currently -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: More ATA disks with tagged queueing ?
It seems Nickolay N. Dudorov wrote: The diskid (IC...) has me somewhat stumped though, I would have thougt the used something like all other IBM disks. Is this a genuine IBM disk or is it some kind of OEM/rebadged device ? Yes, this IS genuine IBM disk. See: http://www.storage.ibm.com/hardsoft/diskdrdl/desk/ds60gxp.htm So I'll continue to use patched 'sys/dev/ata/ata-disk.c' and hope this will work ;-) :) well could you try this patch instead, that should work with all future IBM ATA disks (as long a they stick to this scheme that is, and still support tags) Index: ata-disk.c === RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v retrieving revision 1.108 diff -u -r1.108 ata-disk.c --- ata-disk.c 2001/06/08 05:24:13 1.108 +++ ata-disk.c 2001/06/21 07:43:55 @@ -856,6 +856,14 @@ return 1; i++; } + /* +* check IBM's new obscure way of naming drives +* we want IC (IBM CORP) and AV (ATA interface) +* but doesn't care about the other crap (size, capacity etc) +*/ + if (!strncmp(AD_PARAM-model, IC, 2) + !strncmp(AD_PARAM-model + 8, AV, 2) ) + return 1; } return 0; } -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PCM sound problems in -current ??
I'm having problems with both an internal VIA'686 and a PCI base ESS Solo1, both seem to loose interrupts. The interrupts doesn't even show up in a vmstat -i / systat so something is definitly wrong. BTW the exact same HW work just fine with -stable ? Cameron ? anyone ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PCM sound problems in -current ??
It seems Cameron Grant wrote: I'm having problems with both an internal VIA'686 and a PCI base ESS Solo1, both seem to loose interrupts. The interrupts doesn't even show up in a vmstat -i / systat so something is definitly wrong. BTW the exact same HW work just fine with -stable ? while i've not tested either of these chips for a while (lack of slots, anyone know of a motherboard with ~20 pci and ~10 isa slots?) i can't think of any changes that might cause this except possibly the introduction of INTR_TYPE_AV - and then only if you're using modules and your modules are built from newer source than your kernel. Maybe you should test them now :) Anyhow, the VIA driver doesn't use INTR_TYPE_AV it uses 0, and a quick grep amongst the pci sound card drivers reveals that 0, .._AV, .._MPSAFE is used in a way that doesn't make sense to me at least... To make it short I tried playing with those, no effect i still get the dreaded channel dead message. An no I dont use modules, its all compiled into the kernel.. And yes, its still works in -stable... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems with ata probing twice.
It seems Makoto MATSUSHITA wrote: % atacontrol info 0 Master: ad0 IBM-DJSA-220/JS4OAC3A ATA/ATAPI rev 5 Slave: no device present % atacontrol info 1 Master: no device present Slave: no device present % atacontrol info 2 % Hmm, ata driver says there are two buses. But why? 4-stable kernel doesn't recognize ata1. Thats because of the runtime attach/detach code in current, if the channel HW is there, its attached so you can add a device later with atacontrol without having to boot. In -stable the channel is not attached if no devices are present at probe time. If it's true that this machine has _actually_ two ata buses, I'll try to change irq of fxp0 (hope BIOS menu helps me...) It does, most ATA chips does not allow to disable only one of the channels. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current kernel compile broken...
sos make In current as of 5 mins ago: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../dev -I../../contrib/dev/acpica -I../../contrib/ipfilter -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../kern/subr_mbuf.c ../../kern/subr_mbuf.c: In function `mb_init': ../../kern/subr_mbuf.c:382: `mp_ncpus' undeclared (first use in this function) ../../kern/subr_mbuf.c:382: (Each undeclared identifier is reported only once ../../kern/subr_mbuf.c:382: for each function it appears in.) ../../kern/subr_mbuf.c: In function `mb_alloc_wait': ../../kern/subr_mbuf.c:620: `mp_ncpus' undeclared (first use in this function) *** Error code 1 Stop in /u1/SRC/current/sys/compile/SOS. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problems with ata probing twice.
It seems Makoto MATSUSHITA wrote: sos Thats because of the runtime attach/detach code in current, if the sos channel HW is there, its attached so you can add a device later sos with atacontrol without having to boot. In -stable the channel is sos not attached if no devices are present at probe time. Thanks for your clear explanation, I just understand what and why. OK, glad to be of help.. If it's true that this machine has _actually_ two ata buses, I'll try to change irq of fxp0 (hope BIOS menu helps me...) sos It does, most ATA chips does not allow to disable only one of the sos channels. Hmm, maybe this problem (fxp0 doesn't attach) comes from that the driver doesn't allow to use shared IRQ. Anybody knows why? is it by hardware itself? Well, sortof, the ata driver doesn't allow for sharing irq1415 since lots of boards doesn't work that way. However if you need it you can try to add the shared flag in the driver and see if it works on yours. Hmm, maybe I should make this tunable... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Supported ATAPI cdr/cdrw drives
It seems Gerhard Sittig wrote: On Sat, Jun 23, 2001 at 11:25 +0100, Matthew Frost wrote: On Tue, May 29, 2001 at 10:12:35AM -0500, Ken Wills wrote: This patch (well, yamaha-cdr.p2), allows my Yamaha 2100E to fixate disks now! Thanks Soren and others! Yes. It's fixed it for our Yamaha 2100E too (CDRW and CDR single session ISO burns tested so far). Hopefully it can be MFC'd at some point? The above patch (MFC'd manually) fixes burning with a YAMAHA CRW8824E, too. Before, close_disk(sp?) - i.e. fixate - caused an error. Now everything's fine. Great!, I've added it to the list of working drives.. I hope to MFC this soon, but I'm very busy at the moment... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is there a way to power-down IDE HDD?
It seems Maxim Sobolev wrote: [ Charset KOI8-R unsupported, converting... ] Hi, Is there a way to forcefully power-down one of the IDE HDD drives attached to the system? On my primary workstation I have two - one for FreeBSD and second for W2K, so it would be nice to suspend one that is currently inactive to reduce noice and heat generation. Not in the official sources, but I have local changes that allow suspension of ATA/ATAPI devices. With a little luck I'll get to it when my summer vacation is over... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA disks problem in -CURRENT
It seems Samuel Tardieu wrote: With recent -CURRENT kernels (including one from yesterday), I get random strange behaviours as far as my ATA disk is concerned: - the disk light stays on; - I can read from the disk but cannot write anything to it (sync blocks, writes from vi block, ...); - suspending then resuming the laptop doesn't help; - I can get to DDB and use panic to dump the kernel, but it points me to the keyboard interrupt since I used ctrl-alt-esc to get there. It is on a Sony VAIO PCG-Z600NE, with the bundled 12GB HDD: atapci0: Intel PIIX4 ATA33 controller port 0xfcb0-0xfcbf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 11513MB IBM-DARA-212000 [23392/16/63] at ata0-master UDMA33 Hmm, I havn't changed anything in the ATA driver lately, so I dont know what should have caused this malfunction. When was the last date -current worked for you ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Sound broken on -current again...
One gets the first DMA buffer full, then the process hangs... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
It seems Richard Todd wrote: I found much the same thing; specifically, the problematic change is this one: jhb 2001/08/10 14:08:57 PDT Modified files: sys/kern kern_synch.c Log: Work around a race between msleep() and endtsleep() where it was possible for endtsleep() to be executing when msleep() resumed, for endtsleep() to spin on sched_lock long enough for the other process to loop on msleep() and sleep again resulting in endtsleep() waking up the wrong msleep. Obtained from:BSD/OS Revision ChangesPath 1.154 +24 -4 src/sys/kern/kern_synch.c Yups, reverting this, even in a newer kernel makes sound work again, well the VIA support is still not sounding proberly, but it didn't before as well so thats not related to this bogon... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
Revision ChangesPath 1.154 +24 -4 src/sys/kern/kern_synch.c Yups, reverting this, even in a newer kernel makes sound work again, well the VIA support is still not sounding proberly, but it didn't before as well so thats not related to this bogon... Perhaps the bug in the chipset^wPCI-spec? I dont think so, before the latest changes it worked just fine... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
It seems Alexander Leidinger wrote: On 19 Aug, Søren Schmidt wrote: Yups, reverting this, even in a newer kernel makes sound work again, well the VIA support is still not sounding proberly, but it didn't before as well so thats not related to this bogon... Perhaps the bug in the chipset^wPCI-spec? I dont think so, before the latest changes it worked just fine... What's the problem? I didn't noticed anything. It seems that there is either a slight pause, or random noise between each DMA buffer played... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
It seems Jim Bryant wrote: Yups, reverting this, even in a newer kernel makes sound work again, well the VIA support is still not sounding proberly, but it didn't before as well so thats not related to this bogon... Perhaps the bug in the chipset^wPCI-spec? I dont think so, before the latest changes it worked just fine... What's the problem? I didn't noticed anything. It seems that there is either a slight pause, or random noise between each DMA buffer played... -Søren Was this chipset or motherboard-dependant? That particualar problem is dependend on the VIA 82c686[ab] I'd say, but having no other sound HW right now, I really cant tell, I think I've seen other sound HW with this problem too lately on the lists... Like I said, I had no problems running SMP and with a SB/Live!-Value... Current as of yesterday morning [6-7AMish CDT], Tyan S1696DLUA motherboard, 2 Pentium-II/333's, SB/Live! Value card. Did not produce thse issues. I'm pretty sure the problem with no sound due to jhb's commit mentioned earlier hoses more than just the VIA chips... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound broken on -current again...
It seems John Baldwin wrote: In servalan.mailinglist.fbsd-current Maxim Sobolev writes: I found that after reverting the following deltas (jhb's 10 August commit) sound starts working again: [list of deltas deleted] I found much the same thing; specifically, the problematic change is this one: What wait channel is the process (xmms, mpg123, whatever) in? mpg123 hangs on sbwait Oh and btw the same commits seem to have broken USB too (at least on my VIA based board). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: diskcheckd is poo
It seems David O'Brien wrote: diskcheckd is very annoying. Many doubt its usefulness in detecting errors before it is too late. It thinks 40% of my disks are bad (which I don't). I've turned it off, I know many that have. I would like to remove it from the base system and put it in ports. I really don't see what justifies keeping it in /usr/src. YES! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Kenneth D. Merry wrote: On Thu, Feb 28, 2002 at 10:49:18 -0800, Julian Elischer wrote: This is definitly something that is needed.. The question is whether the CAM and ATAPI authors feel it is right. We are guided by them (even though we desperatly need this). Personally even if not perfect.. it's better than nothing and we should probably commit something like it. or based on it.. (having looked at it I think it seems fine.) I think it's a good idea as well. Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? So here's my vote for a quick commit. No. See below. There are still problems with it. I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. There are alot of issues here that needs solutions. It will need a *serious* maintainer that handles all aspects of it, especially dealing with error reports for one thing, technically it needs to be brought to a state where it works on alot more HW that seems to be the case for now, and the integration into the ATA driver should be dealt with a bit differently. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Matthew N. Dodd wrote: On Thu, 28 Feb 2002, Søren Schmidt wrote: I'll quit the ATA/ATAPI development/maintenance if this goes in quickly. What? Are you looking at the same patches that everyone else is? Read the rest of my mail, the problem is not the patches as much as it is all the issues getting it to work and helping users that has problems with it. I have more than enough to do already, getting X mails extra a day asking why app XX doesn't work with drive YY is not what I'm looking for. I'd expect this sort of foot-dragging if the patch were intrusive to the ATA drivers but its not. As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays (some of us cannot afford the weight of those extra layers, nor loose functionality). I'd do the integration somewhat differently to even further minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Kenneth Culver wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... What functionality is lost by this ability? Compare the features of the ATAPI vs SCSI CD drivers.. If it has so many problems... why not just clean it up? Just curious... Fine by me, but do you also volounteer the time and expertise to do that ? This is the usual case of we want it all but noone is willing to invest the time and energy to keep it floating. I'll state it again, I have no problem with having ATAPI being available through CAM, I'll even do the initial commit to ensure integration is done in a way I can live with in the ATA/ATAPI driver. But I do have a problem with what comes after that, I do *not* have the time nor motivation for keeping this working and upto date, let alone answering end user questions about what works and what doesn't. Do you guys have any idea what amount of time it takes to keep modern device drivers etc up to date on HW that gets new versions and types by the week ? I could use the hours I put into this each and every week (and have done for the past 3 years in case of the ATA/ATAPI driver mind you) for playing with my kids or take the vife for a dinner in town, so excuse me for beeing a little bit pissed when you say why not just clean it up... Now, I ask for someone with the time, the knowledge and the motivation to do the maintenance work on this when/if it gets into the sources, thats all. This is a volounteer driven project guys, you give some and then you may be getting some.. I'm getting tired of giving and only getting requests for more in return... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Scott Long wrote: As I have stated several times, I have no problem with ATAPI being sent through CAM as long as the usual way stays (some of us cannot afford the weight of those extra layers, nor loose functionality). I'd do the integration somewhat differently to even further minimise the diffs, but that is really not the issue here... So if we can get *serious* commitment from a committer to take up these loose ends, lets talk about what to do, if not my offer stands :) I'll raise my hand here. I've been keenly interested in this for a while, since it will make my UDF work much simpler. I'm also getting my Hmm, your UDF code should know nothing about the lower layers, but we've been over that already :) feet wet in CAM, and I have the two CAM gurus nearby if things get too hairy. I fully indend for this to be a cooperative effort with Thomas; I'm mainly raising my hand to take the abuse that will no doubt happen once in a while. Sure, maybe we should make Thomas a committer so he could look after it himself ? Interested ? Got the time ? I'm all ears for volounteers... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Justin T. Gibbs wrote: What functionality is lost by this ability? Compare the features of the ATAPI vs SCSI CD drivers.. This is exactly why I'd like to see this code merged. The hardware changes too rapidly. The specs change too rapidly but MMC is MMC. Exactly. More of us are getting wives we need to take out to dinner and children to play with, so having duplicated functionality like this just ensures that too many of us are sacrificing our free time instead of working together to get a clean solution. I will go on record right now and as I've said before, there are changes that are needed in CAM land in order for me to accept this change. Due to the growing pressure to get this stuff in, I'll work with Scott and Ken to make sure we have *the right* solution for this in the next couple of weeks. Thomas' code is a great prototype, but we need to do this right so that Soren can concentrate on making X, Y, and Z new ATA chip work, we can collaborate on making our MMC device support the best in the OpenSource world, and we all have free time left over to tend to our personal lives. Agreed, but that means that not only CAM but also the SCSI CD driver needs to learn lots of new tricks, but if that can be done I'm all ears.. Are we done with the commit it quickly now ? :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Scott Long wrote: I'm mainly raising my hand to take the abuse that will no doubt happen once in a while. Sure, maybe we should make Thomas a committer so he could look after it himself ? Interested ? Got the time ? I'm all ears for volounteers... Ummm, I'm volunteering to shepherd these initiatives. The thought of making Thomas a committer had crossed my mind, but I hadn't brought it up with anyone yet. If you're not comfortable with me volunteering for this, please say so. I have no problem with you doing it, I was just fishing for getting Thomas into the net also, we need all the hands we can get :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Updated ATAPI/CAM patches
It seems Max Khon wrote: On Thu, Feb 28, 2002 at 09:58:00PM +0100, S?ren Schmidt wrote: Hmm, why do we need to add new layers and loss of functionality to the ATAPI devices ? Many many many people would like to be able to use cdrecord to burn data to cd's so that all the front-ends to cdrecord will work. It's much nicer than memorizing mkisofs commandline switches :-) Hmm, cdrecord can be used with the ATAPI sunsystem as it is, I did patches for this long ago, but noone picked it up as a port... what about cdrdao? Since cdrdao uses the cdrecord backend (at least it did last time I looked), that should be an easy one... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request for testers of ATA RAID support
As some might have noticed I've done some significant work on the ATA RAID support (for Promise Highpoint controllers) all thanks to Advanis which has made this possible. The code as it is now in -current allows for RAID1's (mirrors) to be properly handled when a disk dies, that means the system continues on the good disk and logs the loss of mirror to the console. The hotswap part of the ATA driver has been extended with functions to enable the bad disk to be detached with atacontrol and if it is in a removeable enclosure, it can be swapped with a new good disk even while the system is running. When the new disk is attached again with atacontrol, the ATA driver will mark it as a SPARE disk if its located where the failed disk was before. Now the really interesting part is the new rebuild command in atacontrol, that will bring the SPARE disk up to date, and when done will set the RAID to fully functional again. All the above is properly written to the config sectors on the disks, so that the BIOS will pick up any changes that happend when the ATA driver was in control. If you have Promise SuperSwap enclosures, the state of the disks will be shown by the LEDs, red for broken disk, orange for rebuilding and green for online. All this said I need testers to really give this new functionality a run for its money, so please, if you have the HW needed for this (Promise Fasttrak or a Highpoint controller with ATA disks) please give it a whirl and let me know how it works out. Thanks! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cdrecord for ATAPI burners available..
For those that have problems with burncd or simply cannot live without, I've put up the source for an ATAPI enabled cdrecord on: ftp://freebsd.dk/pub/ATA/cdrtools-1.10-ATA.tgz On -stable it needs the ATA driver update I did a yesterday. It does *not* need CAM or the atapicam patches, it uses the ATA driver directly.. Enjoy! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATAPICAM
It seems Samuel Tardieu wrote: Has the ATAPICAM patch entered the kernel sources already? I cannot seem to find the option in LINT. No, Justin has called for a timeout on that -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Thomas Quinot wrote: Le 2002-03-19, Søren Schmidt écrivait : ftp://freebsd.dk/pub/ATA/cdrtools-1.10-ATA.tgz On -stable it needs the ATA driver update I did a yesterday. It does *not* need CAM or the atapicam patches, it uses the ATA driver directly.. Alternatively, for those who'd like to use stock issue cdr tools (or any other tool that manipulates CAM devices) there also is a new release of the ATAPI/CAM patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ that resolves the 'hang at boot' issue reported by several testers with Toshiba units. Oh yes, I forgot, there is also a cdrdao on: ftp://freebsd.dk/pub/ATA/cdrdao-1.1.5-ATA.tgz Again no CAM or atapicam needed :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Kenneth Culver wrote: Oh yes, I forgot, there is also a cdrdao on: ftp://freebsd.dk/pub/ATA/cdrdao-1.1.5-ATA.tgz Again no CAM or atapicam needed :) Is this a competition??? :-) Not that I know of, but I recently got permission to share the (very limitted BTW) changes I did to cdrecord/cdrdao over a year ago, and now that the infrastructure for using it is in both -stable and -current, it seemed worthwhile to release it to the unsuspecting world... Judging by the number of downloads already it is VERY popular :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Stijn Hoop wrote: You and Thomas rock! Any chance of a cdparanoia-ATA.tgz ? :) No idea what it is, I cant seem to find it in ports either... URL ? Does it work on FreeBSD already with CAM or ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Kenneth Culver wrote: Not that I know of, but I recently got permission to share the (very limitted BTW) changes I did to cdrecord/cdrdao over a year ago, and now that the infrastructure for using it is in both -stable and -current, it seemed worthwhile to release it to the unsuspecting world... Judging by the number of downloads already it is VERY popular :) Yeah, I've downloaded it, however, I'm using gmake to try to build it, and while something compiles, I can't find where it actually puts anything, and when I do a gmake install, it doesn't install anything, at least not by the name of cdrecord It puts its stuff in /usr/local/bin -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Thomas Quinot wrote: Le 2002-03-19, Søren Schmidt écrivait : ftp://freebsd.dk/pub/ATA/cdrdao-1.1.5-ATA.tgz Again no CAM or atapicam needed :) Hum this package does not compile out of the box: c++ -DHAVE_CONFIG_H -I.. -I. -I/usr/local/include/pccts -O -pipe -c TocParser.cpp -o TocParser.o TocParser.cpp:512: macro `zzsetmatch' used with too many (2) args gmake[1]: *** [TocParser.o] Error 1 You need to have pccts installed to compile cdrdao Furhtermore it looks to me like it has a serious drawback. Please feel free to correct me if I am wrong (I am not familiar with libscg internals) but this patched version works /only/ with ATAPI units, which means that if you have both proper SCSI drives and ATAPI drives, then you cannot use the same cdrdao binary for both. This also means that you cannot do on-the-fly cd copies in such a situation. These utils are ATA only (as the name implies), if our ports people wants to merge it into whats already there I wont complain :) That said I think the ATA only version covers more than a significant percentage of our userbase -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Kenneth Culver wrote: It puts its stuff in /usr/local/bin Wierd, for me it put everything in /opt/schily/blah... I hate it when people do that. :-) I've put up a new version with the default changed to /usr/local... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Thomas Quinot wrote: Le 2002-03-19, Søren Schmidt écrivait : gmake[1]: *** [TocParser.o] Error 1 You need to have pccts installed to compile cdrdao I do, and as I mentioned in my first message, the compileation completed after a gmake distclean. okies... These utils are ATA only (as the name implies), if our ports people wants to merge it into whats already there I wont complain :) That said I think the ATA only version covers more than a significant percentage of our userbase In which case I'll be more than happy to continue maintaining ATAPI/CAM as an alternative solution, which addresses 100% of our user base and does not impose any additional work upon application authors or port maintainers. I thought there was work on this already ? Justin called for a timeout to get it done the right way in CAM, I was sort of expecting to hear about how that should integrate in the ATA/ATAPI world... However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have a use for them, be it in the official sources or locally, that all depends on how the cake is to be cut... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Scott Long wrote: In the past you've objected to ATAPI-CAM on two grounds, fear that it won't be done right, and fear that it will add more work to yourself. I think that there are enough highly intelligent people interested in the project that the first issue can be put to rest. While I highly respect what you have done with this port, I think that you are eroding your defense of the second issue. I fail to see how porting (and presumably maintaining) a multitude of CD utilities will be less work for you than allowing someone to put a CAM hook into your acd driver, and then sitting back as they maintain that work. I released these mods (which was actually done over a year ago on a contract, but I couldnt release them until now) just so people experiencing problems could try that route. This could reveal the problems that some has with burncd, and which I would like to get fixed, even if the 'pure' ATAPI driver suite is to be replaced with CAM (I have a use for it at least without CAM).. I was trying to be helpfull here, so please take a deep breath before accusing me of anything else.. If you object to ATAPI-CAM, just come out and and admit it. This isn't a battle of egos of wills, and nobody is trying to discredit your work. You are a valuable member of the FreeBSD community, and everybody appreciates the work that you have put it. ATAPI-CAM is not meant to replace you, since we still need your expertise in every other part of the ATA/ATAPI/IDE framework. It is meant to help users who want a simple way to do cool stuff with their ATAPI devices. I have said repeatedly on these lists, that I have no problem with CAM as long as the integration is done in a sensible way, and that I am not the one to maintain the CAM translation layer. I was under the impression that Justin was working with you guys on how to do this right from the CAM perspective, at least that was the way I interpreted his mail to this list. I'm not the one slowing things down here, so please point your flak in another direction :) However, the 'pure' ATAPI drivers will continue to live since I have uses for it, if its not to be in the official sources, thats something I'll have to consider how to handle then... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cdrecord for ATAPI burners available..
It seems Thomas Quinot wrote: Le 2002-03-20, Søren Schmidt écrivait : I thought there was work on this already ? Justin called for a timeout to get it done the right way in CAM, I was sort of expecting to hear about how that should integrate in the ATA/ATAPI world... Well I have not heard of any specific requirements on that matter. Me neither, maybe somebody should ping Justin on this.. However, I will maintain the ATA/ATAPI only cd/fd/tape drivers as I have a use for them, be it in the official sources or locally, that all depends on how the cake is to be cut... Currently, the ATAPI/CAM patches can coexist peacefully with acd/ast/afd, and it is my intention to keep it that way. :) Well, since Justin is MrCAM I think we should at least wait for him to comment on this before spending too much work on it to find that it should be done differently. And yes, I'm all for coexistance as I've stated several times... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mirrored disk on HPT370 is not detected.
It seems NAKAJI Hiroyuki wrote: I checked the difference between them to find that ata device on HPT370 is not detected, +pcib2: device atapci0 requested unsupported I/O range 0x0-0x9c00 (decoding 0x9000-0xafff) +ata2: probe allocation failed You need the options PCI_ALLOW_UNSUPPORTED_IO_RANGE option in your kernel config file, the changes Warner did to the sanity checking of io ranges breaks on more or less all PCI based ATA controllers :( -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: atacontrol breaks world
It seems Steve Kargl wrote: === sbin/atacontrol cc -O -pipe -c /usr/src/sbin/atacontrol/atacontrol.c /usr/src/sbin/atacontrol/atacontrol.c: In function `cap_print': /usr/src/sbin/atacontrol/atacontrol.c:121: structure has no member named `lba_size' /usr/src/sbin/atacontrol/atacontrol.c:122: structure has no member named `lba_size' /usr/src/sbin/atacontrol/atacontrol.c:127: structure has no member named `lba_size48' /usr/src/sbin/atacontrol/atacontrol.c:128: structure has no member named `lba_size48' *** Error code 1 Fixed. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata problems (was: Re: ld-elf.so.1 broken with world from yesterday)
It seems Alexander Leidinger wrote: Something about a missing or wrong ELF header. I thought it was a general problem so everyone would see it, but it turned out to be a problem in the ata driver. After turning off tagged queuing everything was fine. I'm not the only one with problems with tagged queuing. Søren, as a data point: a Mar 12 kernel was fine for me, a Mar 27 kernel too, but a Apr 6-8 kernel spills alot of tag related errors (I think you already have those errors from someone else, no need to repeat them here) and goes into PIO mode after some time. Turning of tagged queuing works. Yes, I'm aware of some having problems with tags, but I cant seem to reproduce the problem here no matter what I try... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata problems (was: Re: ld-elf.so.1 broken with world from yesterday)
It seems Alexander Leidinger wrote: On 9 Apr, Søren Schmidt wrote: Søren, as a data point: a Mar 12 kernel was fine for me, a Mar 27 kernel too, but a Apr 6-8 kernel spills alot of tag related errors (I think you already have those errors from someone else, no need to repeat them here) and goes into PIO mode after some time. Turning of tagged queuing works. Yes, I'm aware of some having problems with tags, but I cant seem to reproduce the problem here no matter what I try... I first had problems to reproduce it too, but yesterday I got hit by it. Do you want my complete system configuration (kernel config, dmesg) to perhaps try to reproduce it with a specific -current (cvs ... -D 200204080900) in your lab? Sure, anything that can get me to get my hands on the problem.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Giorgos Keramidas wrote: ad0: READ command timeout tag=1 serv=1 - resetting ata0: resetting devices .. ad0: invalidating queued requests done Turn off tagged queing. S?ren knows about this error and tries to reproduce it (but fails as far as I know). I've seen this quite a few times, but I can't reliably reproduce it yet. It seems to hit me a lot when the ad0 drive spins like crazy doing stuff that is heavy on disk I/O. Disabling tag queueing now to see if this fixes things. But even if it does, I think I should enable it again and help S?ren track this down, if I can. Is your drive perchance an IBM DTLA? It's known to have these problems. Cool! would you like to share where that information is available so I can possibly work around the problem ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Alexander Leidinger wrote:
I've seen this quite a few times, but I can't reliably reproduce it
yet. It seems to hit me a lot when the ad0 drive spins like crazy
doing stuff that is heavy on disk I/O. Disabling tag queueing now to
see if this fixes things. But even if it does, I think I should
enable it again and help S?ren track this down, if I can.
There are a lot of people which want to help him...
First I got it only once (as you in a heavy disk I/O situation). After
another new world I got it at every boot...
Some people see this after the mega MFC on -stable too.
Could I have you guys try this simple patch ?
Index: ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.149
diff -u -r1.149 ata-all.c
--- ata-all.c 10 Apr 2002 11:18:07 - 1.149
+++ ata-all.c 15 Apr 2002 08:05:49 -
@@ -1009,13 +1009,12 @@
rman_get_start(atadev-channel-r_io),
command, lba, count, feature, flags);
#endif
-
-/* select device */
-ATA_OUTB(atadev-channel-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
-
/* disable interrupt from device */
if (atadev-channel-flags ATA_QUEUED)
ATA_OUTB(atadev-channel-r_altio, ATA_ALTSTAT, ATA_A_IDS | ATA_A_4BIT);
+
+/* select device */
+ATA_OUTB(atadev-channel-r_io, ATA_DRIVE, ATA_D_IBM | atadev-unit);
/* ready to issue command ? */
if (ata_wait(atadev, 0) 0) {
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Alexander Leidinger wrote: On 15 Apr, Søren Schmidt wrote: Some people see this after the mega MFC on -stable too. Could I have you guys try this simple patch ? Does not work. As in: No change or breaks completely (if so how)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Søren Schmidt wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Cool! would you like to share where that information is available so I can possibly work around the problem ?? IBM DTLA drives are known to be problematic. If you use that in a search engine, it will find numerous references to the drive electronics being too slow for sustained access to the sectors closes to the spindle. This thread is about tagged queueing problems on IBM drives since they are the only ones that supports it, it is not specific to the DTLA series at all, which this thread has already explained. So Terry, do you have anything to share, or just noise like this ? (I dont care about if the DTLA may have other problems) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: IBM DTLA drives are known to be problematic. If you use that in a search engine, it will find numerous references to the drive electronics being too slow for sustained access to the sectors closes to the spindle. This thread is about tagged queueing problems on IBM drives since they are the only ones that supports it, it is not specific to the DTLA series at all, which this thread has already explained. So Terry, do you have anything to share, or just noise like this ? (I dont care about if the DTLA may have other problems) Sorry; all I can give you is hear-say, which I guess you could consider to be noise, except we confirmed that the problem disk in this case was an IBM drive, which tends to support the theory. Indeed, the problem at hand here show up on *any* tagged queueing capable drive, it is not specific to a certain model. For a more scientific test, downloading the firmware tool and setting the DMA transfer rate down, and checking for problems, would be pretty overwhelming evidence. Personally, I don't have any of the buggers lying around to test with any more. Why on earth would you do that ? (hint man atacontrol) Besides I dont see this as any evidence at all, but thats another matter... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Søren Schmidt wrote: For a more scientific test, downloading the firmware tool and setting the DMA transfer rate down, and checking for problems, would be pretty overwhelming evidence. Personally, I don't have any of the buggers lying around to test with any more. Why on earth would you do that ? (hint man atacontrol) Besides I dont see this as any evidence at all, but thats another matter... If it fixes the problem, then the problem is most likely related to what firmware setting the tool changes. AFAIK it only set the maximum DMA speed the drive will allow, that you can do with atacontrol as well... Obviously, turning off tagged commands works, according to at least one person who is reporting the problem. Again that has *nothing* to do with the DTLA drives and DMA speed and the phase of the moon... But it shows (as we already know) that using tags on any drive that supports it, can fail on some systems. I wonder if limiting outstanding tagged commands to less than the number advertised by the drive would also work... can't be worse than the initialization reordering patch that failed (e.g the worst case is it still has the problems). A lot safer than banging bits in the firmware, I'm sure, though... Limiting the outstanding tagged commands to less than the advertised amount would actually be my first choice of a hack for a software workaround. Thats not the problem either, the problem is that I apparently changed some subtle bits that make it fail on some systems, regardless of controller and disk type, but which is marginal enough that I cant reproduce the problem here in the lab... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Giorgos Keramidas wrote: On 2002-04-14 23:46, Terry Lambert wrote: Is your drive perchance an IBM DTLA? It's known to have these problems. Nay. A Western Digital disk I bought about 2.5 years ago. Hmm, AFAIK WD newer had a disk that worked right with tags, and I've newer been able to find a workaround on those I have here in the lab -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
It seems Andrey A. Chernov wrote: This mega-commit: date: 2002/04/05 13:13:XX; author: sos; Make the ATA driver compile work on the sparc64 platform. breaks i386 ATA at least for following card: atapci0: Intel ICH2 ATA100 controller port 0xb800-0xb80f at device 31.1 on pci0 Last working kernel is from date=2002.04.05.13.09.00, all kernels after this mega-commit including very recent -current are broken. Symptoms are very strange, no error diagnostics at all but rtld's map_object() can't map any shared library with invalid file format error. Programs can't start from /etc/rc too. Hmm, I dont think so Have you recompiled both kernel and potential kld's ? I just had wierd behavior here using old kld's... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
It seems Andrey A. Chernov wrote: On Wed, Apr 17, 2002 at 21:42:19 +0200, Alexander Leidinger wrote: If you are running with tagged queing: turn it off. I got the same Thanks, turning tags off helps! It means that sparc64 ATA commit breaks tags. They work nice before it. I know, I have a partial solution to it, the problem being (surprise) busdma, more later what I have it tested some more... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: My other hunch is that there will need to be a channel reserved for reset commands to be queued to the disk, so that you can queue more commands to it later (e.g. can't connect to send the reset because of the already disconnected commands in progress). Terry, read the ATA spec, it doesn't work that way, tags on ATA is very different from tags on SCSI, and beside a reset is not a command, but a bit in a HW port.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
It seems Doug Barton wrote: Given the impending 4.6-release, might it make sense to back off ata in The busdma/sparc64 code is *not* in stable... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
It seems Alexander Leidinger wrote: On 18 Apr, Doug Barton wrote: Given the impending 4.6-release, might it make sense to back off ata in -stable to the last known-good state? We have some time until the code freeze, so give him some days to track it down. If he is able to fix it: fine, else he can still back it out. I'll see what I can do, but my time is VERY limitted for the next 2-3 weeks, if I get any spare time at all... However, if its decided to back out whats in -stable, remember that it will bring ATA support back to what was in 4.5, which will severely reduce our chipset support etc, which is alot worse IMNHO. The right solution would be to just disable tagged queing, and state that in the docs, but I'm not the RE@ :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Søren Schmidt wrote: It seems Terry Lambert wrote: My other hunch is that there will need to be a channel reserved for reset commands to be queued to the disk, so that you can queue more commands to it later (e.g. can't connect to send the reset because of the already disconnected commands in progress). Terry, read the ATA spec, it doesn't work that way, tags on ATA is very different from tags on SCSI, and beside a reset is not a command, but a bit in a HW port.. I didn't mean for the reset itself, I meant for the process. You can't take back writes that are in progress and not acknowledged, in order to retry them after the reset, so as to not lose data. Oh yes you can, the ATA driver does just that in case of the drive loosing its marbels. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Matthias Schuendehuette wrote: I didn't mean for the reset itself, I meant for the process. You can't take back writes that are in progress and not acknowledged, in order to retry them after the reset, so as to not lose data. Oh yes you can, the ATA driver does just that in case of the drive loosing its marbels. Does that mean that the driver isn't aware of the 'tags-problem'? If I understand you right, it should be possible to reset the drive and continue, maybe without tags or at a reduced UDMA-Speed or whatever actions seem appropriate... ...ahh, I mean, the driver *does* take an action (it/he(?) switches back to PIO4), but why is any UDMA-Mode no longer usable afterwards? Is the drive been reset or just switched back? What is the impact of a reset compared to a switch back? The driver always resets the ATA channel if a command times out, thats the only way to gain control of the device(s) again. The driver always falls back to PIO if it encounters a DMA problem, be it with tags or not, as chances are DMA doesn't work at all if a problem shows up. Now this could be changed, but in 99% of the cases it will just make the pain last longer, until it finally switches back to PIO. I chose this route because most users prefers to keep thier data intact at (almost) any price. However in -current and recent -stables you can switch on DMA again with atacontrol, if you think it was a fluke that got it set back to PIO. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Søren Schmidt wrote: I didn't mean for the reset itself, I meant for the process. You can't take back writes that are in progress and not acknowledged, in order to retry them after the reset, so as to not lose data. Oh yes you can, the ATA driver does just that in case of the drive loosing its marbels. If it worked, people wouldn't be having this problem. Hmm, since I havn't been able to get my hands on the problem (I've been running 3 systems here with tags all over since the first report, not a single hickup yet :( ) I can't tell whats going on, it might be that the drive somehow gets really confused I dont know, for now those having tags problems should just not enable it... What's your theory on it? None so far, I've instrumented the code here, and I simply cannot see what should go wrong (yet). BUT recent current with the busdma'd ATA driver screws up with tags, fix is coming as soon as I get a few hours to commit it... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: Hmm, since I havn't been able to get my hands on the problem (I've been running 3 systems here with tags all over since the first report, not a single hickup yet :( ) I can't tell whats going on, it might be that the drive somehow gets really confused I dont know, for now those having tags problems should just not enable it... I wish someone who is having the problem would try the three hacks I suggested, and report back. I personally can't reproduce the problem here, either. Thats life I guess, but eventually I'll get the combination together that fails (I hope), since this is more or less impossible to debug remotely... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
It seems Alexander Leidinger wrote: On 18 Apr, Søren Schmidt wrote: What's your theory on it? None so far, I've instrumented the code here, and I simply cannot see what should go wrong (yet). Does it make sense to give this instrumentation to someone who can reproduce it? Not directly since its tied in with special HW to look for interrupts etc, a real hackers delight setup :) Now I have this patch that fixes the mess from the busdma integration that will go in later tonight when my test machine has finished its current test round. When thats done I need -current users with tag problems to upgrade and those with problems should mail me thers dmesg so I can try to get a grasp on what HW fails exactly. Semilar for -stable users, if you have problems with tags, mail me your dmesg... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
